Section 21. Security Considerations

The security considerations and threats around RTSP and its usage can
   be divided into considerations around the signaling protocol itself
   and the issues related to the media-stream delivery.  However, when
   it comes to mitigation of security threats, a threat depending on the
   media-stream delivery may in fact be mitigated by a mechanism in the
   signaling protocol.
   There are several chapters and an appendix in this document that
   define security solutions for the protocol.  These sections will be
   referenced when discussing the threats below.  However, the reader
   should take special notice of the Security Framework (Section 19) and
   the specification of how to use SRTP and its key-management
   (Appendix C.1.4) to achieve certain aspects of the media security.
21.1.  Signaling Protocol Threats
   This section focuses on issues related to the signaling protocol.
   Because of the similarity in syntax and usage between RTSP servers
   and HTTP servers, the security considerations outlined in [RFC7230],
   [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235] apply as
   well.
   Specifically, please note the following:
   Abuse of Server Log Information:  A server is in the position to save
         personal data about a user's requests that might identify their
         media consumption patterns or subjects of interest.  This
         information is clearly confidential in nature, and its handling
         can be constrained by law in certain countries.  Log
         information needs to be securely stored and appropriate
         guidelines followed for its analysis.  See Section 9.8 of
         [RFC7230] for additional guidelines.
   Transfer of Sensitive Information:  There is no reason to believe
         that information transferred in RTSP message, such as the URI
         and the content of headers, especially the Server, Via,
         Referrer, and From headers, may be any less sensitive than when
         used in HTTP.  Therefore, all of the precautions regarding the
         protection of data privacy and user privacy apply to
         implementers of RTSP clients, servers, and proxies.  See
         Sections 9.3-9.6 of [RFC7231] for further details.
         The RTSP methods defined in this document are primarily used to
         establish and control the delivery of the media data
         represented by the URI; thus, the RTSP message bodies are
         generally less sensitive than the ones in HTTP.  Where HTTP
         bodies could contain, for example, your medical records, in
         RTSP, the sensitive video of your medical operation would be in
         the media stream over the media-transport protocol, not in the
         RTSP message.  Still, one has to take note of what potential
         sensitive information is included in RTSP.  The protection of
         the media data is separate, can be applied directly between
         client and server, and is dependent on the media-transport
         protocol in use.  See Section 21.2 for further discussion.
         This possibility for separation of security between media-
         resource content and the signaling protocol mitigates the risk
         of exposing the media content when using hop-by-hop security
         for RTSP signaling using proxies (Section 19.3).
   Attacks Based On File and Path Names:  Though RTSP URIs are opaque
         handles that do not necessarily have file-system semantics, it
         is anticipated that many implementations will translate
         portions of the Request-URIs directly to file-system calls.  In
         such cases, file systems SHOULD follow the precautions outlined
         in Section 9.1 of [RFC7231], such as checking for ".." in path
         components.
   Personal Information:  RTSP clients are often privy to the same
         information that HTTP clients are (username, location, etc.)
         and thus should be equally sensitive.  See Section 9.8 of
         [RFC7230], Sections 9.3-9.7 of [RFC7231], and Section 8 of
         [RFC7234] for further recommendations.
   Privacy Issues Connected to Accept Headers:  Since similar usages of
         the "Accept" headers exist in RTSP as in HTTP, the same caveats
         outlined in Section 9.4 of [RFC7231] with regard to their use
         should be followed.
   Establishing Authority:  RTSP shares with HTTP the question of how a
         client communicates with the authoritative source for media
         streams (Section 9.1 of [RFC7230]).  The used DNS servers, the
         security of the communication, and any possibility of a man in
         the middle, and the trust in any RTSP proxies all affect the
         possibility that a client has received a non-authoritative
         response to a request.  Ensuring that a client receives an
         authoritative response is challenging, although using the
         secure communication for RTSP signaling (rtsps) simplifies it
         significantly as the server can provide a hostname identity
         assertion in the TLS handshake.
   Location Headers and Spoofing:  If a single server supports multiple
         organizations that do not trust each another, then it MUST
         check the values of the 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 (see
         Section 15.4 of [RFC2616]).
   In addition to the recommendations in the current HTTP specifications
   ([RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235]
   as of this writing) and also those of the previous relevant RFCs
   [RFC2068] [RFC2616], future HTTP specifications may provide
   additional guidance on security issues.
   The following are added considerations for RTSP implementations.
   Session Hijacking:  Since there is no or little relation between a
         transport-layer connection and an RTSP session, it is possible
         for a malicious client to issue requests with random session
         identifiers that could affect other clients of an unsuspecting
         server.  To mitigate this, the server SHALL use a large, random
         and non-sequential session identifier to minimize the
         possibility of this kind of attack.  However, unless the RTSP
         signaling is always confidentiality protected, e.g., using TLS,
         an on-path attacker will be able to hijack a session.  Another
         choice for preventing session hijacking is to use client
         authentication and only allow the authenticated client creating
         the session to access that session.
   Authentication:  Servers SHOULD implement both basic and Digest
         [RFC2617] authentication.  In environments requiring tighter
         security for the control messages, the transport-layer
         mechanism TLS [RFC5246] SHOULD be used.
   Suspicious Behavior:  Upon detecting instances of behavior that is
         deemed a security risk, RTSP servers SHOULD return error code
         403 (Forbidden).  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 from clients
         that are deemed to be in violation of local security policy.
   TLS through Proxies:  If one uses the possibility to connect TLS in
         multiple legs (Section 19.3), one really needs to be aware of
         the trust model.  This procedure requires trust in all proxies
         part of the path to the server.  The proxies one connects
         through are identified, assuming the proxies so far connected
         through are well behaved and fulfilling the trust.  The
         accepted proxies are men in the middle and have access to all
         that goes on over the TLS connection.  Thus, it is important to
         consider if that trust model is acceptable in the actual
         application.  Further discussion of the actual trust model is
         in Section 19.3.  It is important to note what difference in
         security properties, if any, may exist with the used media-
         transport protocol and its security mechanism.  Using SRTP and
         the MIKEY-based key-establishment defined in Appendix C.1.4.1
         enables media key-establishment to be done end-to-end without
         revealing the keys to the proxies.
   Resource Exhaustion:  As RTSP is a stateful protocol and establishes
         resource usage on the server, there is a clear possibility to
         attack the server by trying to overbook these resources to
         perform a DoS attack.  This attack can be both against ongoing
         sessions and to prevent others from establishing sessions.
         RTSP agents will need to have mechanisms to prevent single
         peers from consuming extensive amounts of resources.  The
         methods for guarding against this are varied and depend on the
         agent's role and capabilities and policies.  Each
         implementation has to carefully consider its methods and
         policies to mitigate this threat.  There are recommendations
         regarding the handling of connections in Section 10.7.
   The above threats and considerations have resulted in a set of
   security functions and mechanisms built into or used by the protocol.
   The signaling protocol relies on two security features defined in the
   Security Framework (Section 19): namely client authentication using
   HTTP authentication and TLS-based transport protection of the
   signaling messages.  Both of these mechanisms are required to be
   implemented by any RTSP agent.
   A number of different security mitigations have been designed into
   the protocol and will be instantiated if the specification is
   implemented as written, for example, by ensuring sufficient amounts
   of entropy in the randomly generated session identifiers when not
   using client authentication to minimize the risk of session
   hijacking.  When client authentication is used, protection against
   hijacking will be greatly improved by scoping the accessible sessions
   to the one this client identity has created.  Some of the above
   threats are such that the implementation of the RTSP functionality
   itself needs to consider which policy and strategy it uses to
   mitigate them.
21.2.  Media Stream Delivery Threats
   The fact that RTSP establishes and controls a media-stream delivery
   results in a set of security issues related to the media streams.
   This section will attempt to analyze general threats; however, the
   choice of media-stream transport protocol, such as RTP, will result
   in some differences in threats and what mechanisms exist to mitigate
   them.  Thus, it becomes important that each specification of a new
   media-stream transport and delivery protocol usable by RTSP requires
   its own security analysis.  This section includes one for RTP.
   The set of general threats from or by the media-stream delivery
   itself are:
   Concentrated Denial-of-Service Attack:  The protocol offers the
      opportunity for a remote-controlled DoS attack, where the media
      stream is the hammer in that DoS attack.  See Section 21.2.1.
   Media Confidentiality:  The media delivery may contain content of any
      type, and it is not possible, in general, to determine how
      sensitive this content is from a confidentiality point.  Thus, it
      is a strong requirement that any media delivery protocol supply a
      method for providing confidentiality of the actual media content.
      In addition to the media-level confidentiality, it becomes
      critical that no resource identifiers used in the signaling be
      exposed to an attacker as they may have human-understandable names
      or may be available to the attacker, allowing it to determine the
      content the user received.  Thus, the signaling protocol must also
      provide confidentiality protection of any information related to
      the media resource.
   Media Integrity and Authentication:  There are several reasons why an
      attacker will be interested in substituting the media stream sent
      out from the RTSP server with one of the attacker's creation or
      selection, such as discrediting the target and misinformation
      about the target.  Therefore, it is important that the media
      protocol provide mechanisms to verify the source authentication
      and integrity and to prevent replay attacks on the media stream.
   Scope of Multicast:  If RTSP is used to control the transmission of
      media onto a multicast network, the scope of the delivery must be
      considered.  RTSP supports the TTL Transport header parameter to
      indicate this scope for IPv4.  IPv6 has a different mechanism for
      the scope boundary.  However, such scope control has risks, as it
      may be set too large and distribute media beyond the intended
      scope.
   Below (Section 21.2.2) a protocol-specific analysis of security
   considerations for RTP-based media transport is included.  In that
   section, the requirements on implementing security functions for RTSP
   agents supporting media delivery over RTP are made clear.
21.2.1.  Remote DoS Attack
   The attacker may initiate traffic flows to one or more IP addresses
   by specifying them as the destination in SETUP requests.  While the
   attacker's IP address may be known in this case, this is not always
   useful in the prevention of more attacks or ascertaining the
   attacker's identity.  Thus, an RTSP server MUST only allow client-
   specified destinations for RTSP-initiated traffic flows if the server
   has ensured that the specified destination address accepts receiving
   media through different security mechanisms.  Security mechanisms
   that are acceptable in order of increasing generality are:
   o  Verification of the client's identity against a database of known
      users using RTSP authentication mechanisms (preferably Digest
      authentication or stronger)
   o  A list of addresses that have consented to be media destinations,
      especially considering user identity
   o  Verification based on media path
   The server SHOULD NOT allow the destination field to be set unless a
   mechanism exists in the system to authorize the request originator to
   direct streams to the recipient.  It is preferred that this
   authorization be performed by the media recipient (destination)
   itself and the credentials be passed along to the server.  However,
   in certain cases, such as when the recipient address is a multicast
   group or when the recipient is unable to communicate with the server
   in an out-of-band manner, this may not be possible.  In these cases,
   the server may choose another method such as a server-resident
   authorization list to ensure that the request originator has the
   proper credentials to request stream delivery to the recipient.
   One solution that performs the necessary verification of acceptance
   of media suitable for unicast-based delivery is the NAT traversal
   method based on Interactive Connectivity Establishment (ICE)
   [RFC5245] described in [RFC7825].  This mechanism uses random
   passwords and a username so that the probability of unintended
   indication as a valid media destination is very low.  In addition,
   the server includes in its Session Traversal Utilities for NAT (STUN)
   [RFC5389] requests a cookie (consisting of random material) that the
   destination echoes back; thus, the solution also safeguards against
   having an off-path attacker being able to spoof the STUN checks.
   This leaves this solution vulnerable only to on-path attackers that
   can see the STUN requests go to the target of attack and thus forge a
   response.
   For delivery to multicast addresses, there is a need for another
   solution that is not specified in this memo.
21.2.2.  RTP Security Analysis
   RTP is a commonly used media-transport protocol and has been the most
   common choice for RTSP 1.0 implementations.  The core RTP protocol
   has been in use for a long time, and it has well-known security
   properties and the RTP security consideration (Section 9 of
   [RFC3550]) needs to be reviewed.  In perspective of the usage of RTP
   in the context of RTSP, the following properties should be noted:
   Stream Additions:  RTP has support for multiple simultaneous media
      streams in each RTP session.  As some use cases require support
      for non-synchronized adding and removal of media streams and their
      identifiers, an attacker can easily insert additional media
      streams into a session context that, according to protocol design,
      is intended to be played out.  Another threat vector is one of DoS
      by exhausting the resources of the RTP session receiver, for
      example, by using a large number of SSRC identifiers
      simultaneously.  The strong mitigation of this is to ensure that
      one cryptographically authenticates any incoming packet flow to
      the RTP session.  Weak mitigations like blocking additional media
      streams in session contexts easily lead to a DoS vulnerability in
      addition to preventing certain RTP extensions or use cases that
      rely on multiple media streams, such as RTP retransmission
      [RFC4588] to function.
   Forged Feedback:  The built-in RTCP also offers a large attack
      surface for a couple of different types of attacks.  One venue is
      to send RTCP feedback to the media sender indicating large amounts
      of packet loss and thus trigger a media bitrate adaptation
      response from the sender resulting in lowered media quality and
      potentially a shutdown of the media stream.  Another attack is to
      perform a resource-exhaustion attack on the receiver by using many
      SSRC identifiers to create large state tables and increase the
      RTCP-related processing demands.
   RTP/RTCP Extensions:  RTP and RTCP extensions generally provide
      additional and sometimes extremely powerful tools for DoS attacks
      or service disruption.  For example, the Code Control Message
      [RFC5104] RTCP extensions enables both the lock down of the
      bitrate to low values and disruption of video quality by
      requesting intra-frames.
   Taking into account the above general discussion in Section 21.2 and
   the RTP-specific discussion in this section, it is clear that it is
   necessary that a strong security mechanism be supported to protect
   RTP.  Therefore, this specification has the following requirements on
   RTP security functions for all RTSP agents that handle media streams
   and where media-stream transport is completed using RTP.
   RTSP agents supporting RTP MUST implement Secure RTP (SRTP) [RFC3711]
   and, thus, SAVP.  In addition, SAVPF [RFC5124] MUST also be supported
   if AVPF is implemented.  This specification requires no additional
   cryptographic transforms or configuration values beyond those
   specified as mandatory to implement in RFC 3711, i.e., AES-CM and
   HMAC-SHA1.  The default key-management mechanism that MUST be
   implemented is the one defined in MIKEY Key Establishment
   (Appendix C.1.4.1).  The MIKEY implementation MUST implement the
   necessary functions for MIKEY-RSA-R mode [RFC4738] and the SRTP
   parameter negotiation necessary to negotiate the supported SRTP
   transforms and parameters.