\section{Security Considerations}
\label{sec:security}

Because of the similarity in syntax and usage between RTSP servers and
HTTP servers, the security considerations outlined in [H15] apply.
Specifically, please note the following:

\begin{description} 

\item[Authentication Mechanisms:] RTSP and HTTP share common
authentication schemes, and thus should follow the same prescriptions
with regards to authentication.  See [H15.1] for client authentication
issues, and [H15.2] for issues regarding support for multiple
authentication mechanisms.

\item[Abuse of Server Log Information:] RTSP and HTTP servers will
presumably have similar logging mechanisms, and thus should be equally
guarded in protecting the contents of those logs, thus protecting the
privacy of the users of the servers.  See [H15.3] for HTTP server
recommendations regarding server logs.

\item[Transfer of Sensitive Information:] There is no reason to believe
that information transferred via RTSP may be any less sensitive than
that normally transmitted via HTTP.  Therefore, all of the precautions
regarding the protection of data privacy and user privacy apply to
implementors of RTSP clients, servers, and proxies.  See [H15.4] for
further details.

\item[Attacks Based On File and Path Names:] Though RTSP URLs are
opaque handles that do not necessarily have file system semantics, it
is anticipated that many implementations will translate portions of
the request URLs directly to file system calls.  In such cases, file
systems SHOULD follow the precautions outlined in [H15.5], such as
checking for ``..'' in path components.

\item[Personal Information:] RTSP clients are often privy to
the same information that HTTP clients are (user name, location, etc.)
and thus should be equally.  See [H15.6] for further recommendations.

\item[Privacy Issues Connected to Accept Headers:] Since may of the
same ``Accept'' headers exist in RTSP as in HTTP, the same caveats
outlined in [H15.7] with regards to their use should be followed.

\item[DNS Spoofing:] Presumably, given the longer connection times
typically associated to RTSP sessions relative to HTTP sessions, RTSP
client DNS optimizations should be less prevalent.  Nonetheless, the
recommendations provided in [H15.8] are still relevant to any
implementation which attempts to rely on a DNS-to-IP mapping to hold
beyond a single use of the mapping.

\item[Location Headers and Spoofing:] If a single server supports
multiple organizations that do not trust one another, then it must check
the values of \header{Location} and \header{Content-Location} header
fields in responses that are generated under control of said
organizations to make sure that they do not attempt to invalidate
resources over which they have no authority.  ([H15.9])

\end{description} 

In addition to the recommendations in the current HTTP specification
(RFC 2068 \cite{rfc2068}, as of this writing), future HTTP
specifications may provide additional guidance on security issues.

The following are added considerations for RTSP implementations.

\begin{description} 

\item[Concentrated denial-of-service attack:] The protocol offers the
opportunity for a remote-controlled denial-of-service attack.
 
The attacker may initiate traffic flows to one or more IP addresses by
specifying them as the destination in \header{SETUP} requests.  While
the attacker's IP address may be known in this case, this is not always
useful in prevention of more attacks or ascertaining the attackers
identity.  Thus, an RTSP server SHOULD only allow client-specified
destinations for RTSP-initiated traffic flows if the server has verified
the client's identity, either against a database of known users using
RTSP authentication mechanisms (preferably digest authentication or
stronger), or other secure means.

\item[Session hijacking:] Since there is no relation between a
transport layer connection and an RTSP session, it is possible for a
malicious client to issue requests with random session identifiers
which would affect unsuspecting clients.  The server SHOULD use a
large, random and non-sequential session identifier to minimize the
possibility of this kind of attack.

\item[Authentication:] Servers SHOULD implement both basic and digest
\cite{rfc2069} authentication.  In environments requiring tighter
security for the control messages, transport layer mechanisms such as
TLS (RFC 2246 \cite{rfc2246}) {\SHOULD} be used.

\item[Stream issues:] RTSP only provides for stream control.  Stream
delivery issues are not covered in this section, nor in the rest of this
draft.  RTSP implementations will most likely rely on other protocols
such as RTP, IP multicast, RSVP and IGMP, and should address security
considerations brought up in those and other applicable specifications.

\item[Persistently suspicious behavior:] RTSP servers SHOULD return error
code 403 (Forbidden) upon receiving a single instance of behavior which is
deemed a security risk.  RTSP servers SHOULD also be aware of attempts to
probe the server for weaknesses and entry points and MAY arbitrarily
disconnect and ignore further requests clients which are deemed to be in
violation of local security policy.
\end{description} 
