Section 19. Security Framework

The RTSP security framework consists of two high-level components:
   the pure authentication mechanisms based on HTTP authentication and
   the message transport protection based on TLS, which is independent
   of RTSP.  Because of the similarity in syntax and usage between RTSP
   servers and HTTP servers, the security for HTTP is reused to a large
   extent.
19.1.  RTSP and HTTP Authentication
   RTSP and HTTP share common authentication schemes; thus, they follow
   the same framework as specified in [RFC7235].  RTSP uses the
   corresponding RTSP error codes (401 and 407) and headers (WWW-
   Authenticate, Authorization, Proxy-Authenticate, Proxy-Authorization)
   by importing the definitions from [RFC7235].  Servers SHOULD
   implement both the Basic [RFC7617] and the Digest [RFC7616]
   authentication schemes.  Clients MUST implement both the Basic and
   the Digest authentication schemes so that a server that requires the
   client to authenticate can trust that the capability is present.  If
   implementing the Digest authentication scheme, then the additional
   considerations specified below in Section 19.1.1 MUST be followed.
   It should be stressed that using the HTTP authentication alone does
   not provide full RTSP message security.  Therefore, TLS SHOULD be
   used; see Section 19.2.  Any RTSP message containing an Authorization
   header using the Basic authentication scheme MUST be using a TLS
   connection with confidentiality protection enabled, i.e., no NULL
   encryption.
   In cases where there is a chain of proxies between the client and the
   server, each proxy may individually request the client or previous
   proxy to authenticate itself.  This is done using the Proxy-
   Authenticate (Section 18.34), the Proxy-Authorization
   (Section 18.36), and the Proxy-Authentication-Info (Section 18.35)
   headers.  These headers are hop-by-hop headers and are only scoped to
   the current connection and hop.  Thus, if a proxy chain exists, a
   proxy connecting to another proxy will have to act as a client to
   authorize itself towards the next proxy.  The WWW-Authenticate
   (Section 18.58), Authorization (Section 18.8), and Authentication-
   Info (Section 18.7) headers are end-to-end and MUST NOT be modified
   by proxies.
   This authentication mechanism works only for client-to-server
   requests as currently defined.  This leaves server-to-client request
   outside of the context of TLS-based communication more vulnerable to
   message-injection attacks on the client.  Based on the server-to-
   client methods that exist, the potential risks are various: hijacking
   (REDIRECT), denial of service (TEARDOWN and PLAY_NOTIFY), or attacks
   with uncertain results (SET_PARAMETER).
19.1.1.  Digest Authentication
   This section describes the modifications and clarifications required
   to apply the HTTP Digest authentication scheme to RTSP.  The RTSP
   scheme usage is almost completely identical to that for HTTP
   [RFC7616].  These modifications are based on the procedures defined
   for SIP 2.0 [RFC3261] (in Section 22.4) but updated to use RFC 7235,
   RFC 7616 and RFC 7615 instead of RFC 2617.
   Digest authentication uses two additional headers, Authentication-
   Info and Proxy-Authentication-Info, that are defined as in [RFC7615].
   The rules for Digest authentication follow those defined in
   [RFC7616], with "HTTP/1.1" replaced by "RTSP/2.0" in addition to the
   following differences:
   1.  Use the ABNF specified in the referenced documents, with the
       difference that the URI parameter uses the request URI format for
       RTSP, i.e. the ABNF element: Request-URI (see Section 20.2.1).
       The domain parameter uses the RTSP-URI-Ref element for absolute
       and relative URIs.
   2.  If MTags are used, then the example procedure for choosing a
       nonce based on ETag can work, based on replacing the ETag with
       the MTag.
   3.  As a clarification to the calculation of the A2 value for message
       integrity assurance in the Digest authentication scheme,
       implementers should assume, when the entity-body is empty (that
       is, when the RTSP messages have no message body) that the hash of
       the message body resolves to the hash of an empty string, or:
       H(entity-body), example MD5("") =
       "d41d8cd98f00b204e9800998ecf8427e".
19.2.  RTSP over TLS
   RTSP agents MUST implement RTSP over TLS as defined in this section
   and the next Section 19.3.  RTSP MUST follow the same guidelines with
   regard to TLS [RFC5246] usage as specified for HTTP; see [RFC2818].
   RTSP over TLS is separated from unsecured RTSP both on the URI level
   and the port level.  Instead of using the "rtsp" scheme identifier in
   the URI, the "rtsps" scheme identifier MUST be used to signal RTSP
   over TLS.  If no port is given in a URI with the "rtsps" scheme, port
   322 MUST be used for TLS over TCP/IP.
   When a client tries to set up an insecure channel to the server
   (using the "rtsp" URI), and the policy for the resource requires a
   secure channel, the server MUST redirect the client to the secure
   service by sending a 301 redirect response code together with the
   correct Location URI (using the "rtsps" scheme).  A user or client
   MAY upgrade a non secured URI to a secured by changing the scheme
   from "rtsp" to "rtsps".  A server implementing support for "rtsps"
   MUST allow this.
   It should be noted that TLS allows for mutual authentication (when
   using both server and client certificates).  Still, one of the more
   common ways TLS is used is to provide only server-side authentication
   (often to avoid client certificates).  TLS is then used in addition
   to HTTP authentication, providing transport security and server
   authentication, while HTTP Authentication is used to authenticate the
   client.
   RTSP includes the possibility to keep a TCP session up between the
   client and server, throughout the RTSP session lifetime.  It may be
   convenient to keep the TCP session, not only to save the extra setup
   time for TCP, but also the extra setup time for TLS (even if TLS uses
   the resume function, there will be almost two extra round trips).
   Still, when TLS is used, such behavior introduces extra active state
   in the server, not only for TCP and RTSP, but also for TLS.  This may
   increase the vulnerability to DoS attacks.
   There exists a potential security vulnerability when reusing TCP and
   TLS state for different resources (URIs).  If two different hostnames
   point at the same IP address, it can be desirable to reuse the TCP/
   TLS connection to that server.  In that case, the RTSP agent having
   the TCP/TLS connection MUST verify that the server certificate
   associated with the connection has a SubjectAltName matching the
   hostname present in the URI for the resource an RTSP request is to be
   issued.
   In addition to these recommendations, Section 19.3 gives further
   recommendations of TLS usage with proxies.
19.3.  Security and Proxies
   The nature of a proxy is often to act as a "man in the middle", while
   security is often about preventing the existence of one.  This
   section provides clients with the possibility to use proxies even
   when applying secure transports (TLS) between the RTSP agents.  The
   TLS proxy mechanism allows for server and proxy identification using
   certificates.  However, the client cannot be identified based on
   certificates.  The client needs to select between using the procedure
   specified below or using a TLS connection directly (bypassing any
   proxies) to the server.  The choice may be dependent on policies.
   In general, there are two categories of proxies: the transparent
   proxies (of which the client is not aware) and the non-transparent
   proxies (of which the client is aware).  This memo specifies only
   non-transparent RTSP proxies, i.e., proxies visible to the RTSP
   client and RTSP server.  An infrastructure based on proxies requires
   that the trust model be such that both client and server can trust
   the proxies to handle the RTSP messages correctly.  To be able to
   trust a proxy, the client and server also need to be aware of the
   proxy.  Hence, transparent proxies cannot generally be seen as
   trusted and will not work well with security (unless they work only
   at the transport layer).  In the rest of this section, any reference
   to "proxy" will be to a non-transparent proxy, which inspects or
   manipulates the RTSP messages.
   HTTP Authentication is built on the assumption of proxies and can
   provide user-proxy authentication and proxy-proxy/server
   authentication in addition to the client-server authentication.
   When TLS is applied and a proxy is used, the client will connect to
   the proxy's address when connecting to any RTSP server.  This implies
   that for TLS, the client will authenticate the proxy server and not
   the end server.  Note that when the client checks the server
   certificate in TLS, it MUST check the proxy's identity (URI or
   possibly other known identity) against the proxy's identity as
   presented in the proxy's Certificate message.
   The problem is that for a proxy accepted by the client, the proxy
   needs to be provided information on which grounds it should accept
   the next-hop certificate.  Both the proxy and the user may have rules
   for this, and the user should have the possibility to select the
   desired behavior.  To handle this case, the Accept-Credentials header
   (see Section 18.2) is used, where the client can request the proxy or
   proxies to relay back the chain of certificates used to authenticate
   any intermediate proxies as well as the server.  The assumption that
   the proxies are viewed as trusted gives the user a possibility to
   enforce policies on each trusted proxy of whether it should accept
   the next agent in the chain.  However, it should be noted that not
   all deployments will return the chain of certificates used to
   authenticate any intermediate proxies as well as the server.  An
   operator of such a deployment may want to hide its topology from the
   client.  It should be noted well that the client does not have any
   insight into the proxy's operation.  Even if the proxy is trusted, it
   can still return an incomplete chain of certificates.
   A proxy MUST use TLS for the next hop if the RTSP request includes an
   "rtsps" URI.  TLS MAY be applied on intermediate links (e.g., between
   client and proxy or between proxy and proxy) even if the resource and
   the end server are not required to use it.  The chain of proxies used
   by a client to reach a server and its TLS sessions MUST have
   commensurate security.  Therefore, a proxy MUST, when initiating the
   next-hop TLS connection, use the incoming TLS connections cipher-
   suite list, only modified by removing any cipher suites that the
   proxy does not support.  In case a proxy fails to establish a TLS
   connection due to cipher-suite mismatch between proxy and next-hop
   proxy or server, this is indicated using error code 472 (Failure to
   Establish Secure Connection).
19.3.1.  Accept-Credentials
   The Accept-Credentials header can be used by the client to distribute
   simple authorization policies to intermediate proxies.  The client
   includes the Accept-Credentials header to dictate how the proxy
   treats the server / next proxy certificate.  There are currently
   three methods defined:
   Any:  With "any", the proxy (or proxies) MUST accept whatever
         certificate is presented.  Of course, this is not a recommended
         option to use, but it may be useful in certain circumstances
         (such as testing).
   Proxy:  For the "proxy" method, the proxy (or proxies) MUST use its
         own policies to validate the certificate and decide whether or
         not to accept it.  This is convenient in cases where the user
         has a strong trust relation with the proxy.  Reasons why a
         strong trust relation may exist are personal/company proxy or
         the proxy has an out-of-band policy configuration mechanism.
   User: For the "user" method, the proxy (or proxies) MUST send
         credential information about the next hop to the client for
         authorization.  The client can then decide whether or not the
         proxy should accept the certificate.  See Section 19.3.2 for
         further details.
   If the Accept-Credentials header is not included in the RTSP request
   from the client, then the "Proxy" method MUST be used as default.  If
   a method other than the "Proxy" is to be used, then the Accept-
   Credentials header MUST be included in all of the RTSP requests from
   the client.  This is because it cannot be assumed that the proxy
   always keeps the TLS state or the user's previous preference between
   different RTSP messages (in particular, if the time interval between
   the messages is long).
   With the "Any" and "Proxy" methods, the proxy will apply the policy
   as defined for each method.  If the policy does not accept the
   credentials of the next hop, the proxy MUST respond with a message
   using status code 471 (Connection Credentials Not Accepted).
   An RTSP request in the direction server to client MUST NOT include
   the Accept-Credentials header.  As for the non-secured communication,
   the possibility for these requests depends on the presence of a
   client established connection.  However, if the server-to-client
   request is in relation to a session established over a TLS secured
   channel, it MUST be sent in a TLS secured connection.  That secured
   connection MUST also be the one used by the last client-to-server
   request.  If no such transport connection exists at the time when the
   server desires to send the request, the server MUST discard the
   message.
   Further policies MAY be defined and registered, but this should be
   done with caution.
19.3.2.  User-Approved TLS Procedure
   For the "User" method, each proxy MUST perform the following
   procedure for each RTSP request:
   o  Set up the TLS session to the next hop if not already present
      (i.e., run the TLS handshake, but do not send the RTSP request).
   o  Extract the peer certificate chain for the TLS session.
   o  Check if a matching identity and hash of the peer certificate are
      present in the Accept-Credentials header.  If present, send the
      message to the next hop and conclude these procedures.  If not, go
      to the next step.
   o  The proxy responds to the RTSP request with a 470 or 407 response
      code.  The 407 response code MAY be used when the proxy requires
      both user and connection authorization from user or client.  In
      this message the proxy MUST include a Connection-Credentials
      header, see Section 18.13, with the next hop's identity and
      certificate.
   The client MUST upon receiving a 470 (Connection Authorization
   Required) or 407 (Proxy Authentication Required) response with
   Connection-Credentials header take the decision on whether or not to
   accept the certificate (if it cannot do so, the user SHOULD be
   consulted).  Using IP addresses in the next-hop URI and certificates
   rather than domain names makes it very difficult for a user to
   determine whether or not it should approve the next hop.  Proxies are
   RECOMMENDED to use domain names to identify themselves in URIs and in
   the certificates.  If the certificate is accepted, the client has to
   again send the RTSP request.  In that request, the client has to
   include the Accept-Credentials header including the hash over the
   DER-encoded certificate for all trusted proxies in the chain.
   Example:
   C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
         CSeq: 2
         Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
                    "192.0.2.5:4589"
         Accept-Ranges: npt, smpte, clock
         Accept-Credentials: User
   P->C: RTSP/2.0 470 Connection Authorization Required
         CSeq: 2
         Connection-Credentials: "rtsps://test.example.org";
         MIIDNTCCAp...
   C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
         CSeq: 3
         Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
                    "192.0.2.5:4589"
         Accept-Credentials: User "rtsps://test.example.org";sha-256;
         dPYD7txpoGTbAqZZQJ+vaeOkyH4=
         Accept-Ranges: npt, smpte, clock
   P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
         CSeq: 3
         Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
                    "192.0.2.5:4589"
         Via: RTSP/2.0 proxy.example.org
         Accept-Credentials: User "rtsps://test.example.org";sha-256;
         dPYD7txpoGTbAqZZQJ+vaeOkyH4=
         Accept-Ranges: npt, smpte, clock
   One implication of this process is that the connection for secured
   RTSP messages may take significantly more round-trip times for the
   first message.  A complete extra message exchange between the proxy
   connecting to the next hop and the client results because of the
   process for approval for each hop.  However, if each message contains
   the chain of proxies that the requester accepts, the remaining
   message exchange should not be delayed.  The procedure of including
   the credentials in each request rather than building state in each
   proxy avoids the need for revocation procedures.