Best Practices for Securing RTP Media Signaled with SIP

The Session Initiation Protocol (SIP) includes a suite of security services, ranging from Digest authentication for authenticating entities with a shared secret, to TLS for transport security, to S/MIME (optionally) for body security. SIP is frequently used to establish media sessions, in particular audio or audiovisual sessions, which have their own security mechanisms available, such as Secure RTP. However, the practices needed to bind security at the media layer to security at the SIP layer, to provide an assurance that protection is in place all the way up the stack, rely on a great many external security mechanisms and practices, and require a central point of documentation to explain their optimal use as a best practice. Revelations about widespread pervasive monitoring of the Internet have led to a reevaluation of the threat model for Internet communications . In order to maximize the use of security features, especially of media confidentiality, opportunistic measures must often serve as a stopgap when a full suite of services cannot be negotiated all the way up the stack. This document explains the limitations that may inhibit the use of comprehensive protection, and provides recommendations for which external security mechanisms implementers should use to negotiate secure media with SIP. It moreover gives a gap analysis of the limitations of existing solutions, and specifies solutions to address them. Various specifications that user agents must implement to support media confidentiality are given in the sections below; a summary of the best current practices appears in .

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 and RFC 6919.

There are two approaches to providing confidentiality for media sessions set up with SIP: comprehensive protection and opportunistic security (as defined in ).

Comprehensive protection for media sessions established by SIP requires the interaction of three protocols: SIP, the Session Description Protocol (SDP), and the Real-time Protocol (RTP), in particular its secure profile Secure RTP (SRTP). Broadly, it is the responsibility of SIP to provide integrity protection for the media keying attributes conveyed by SDP, and those attributes will in turn identify the keys used by endpoints in the RTP media session(s) that SDP negotiates. Note that this framework does not apply to keys that also require confidentiality protection in the signaling layer, such as the SDP "k=" line, which MUST NOT be used in conjunction with this profile. In that way, once SIP and SDP have exchanged the necessary information to initiate a session, media endpoints will have a strong assurance that the keys they exchange have not been tampered with by third parties, and that end-to-end confidentiality is available. To establishing the identity of the endpoints of a SIP session, this specification uses STIR. The STIR Identity header has been designed to prevent a class of impersonation attacks that are commonly used in robocalling, voicemail hacking, and related threats. STIR generates a signature over certain features of SIP requests, including header field values that contain an identity for the originator of the request, such as the From header field or P-Asserted-Identity field, and also over the media keys in SDP if they are present. As currently defined, STIR only provides a signature over the "a=fingerprint" attribute, which is a key fingerprint utilized by DTLS-SRTP; consequently, STIR only offers comprehensive protection for SIP sessions, in concert with SDP and SRTP, when DTLS-SRTP is the media security service. The underlying PASSporT object used by STIR is extensible, however, and it would be possible to provide signatures over other SDP attributes that contain alternate keying material. A profile for using STIR to provide media confidentiality is given in .

Work is already underway on defining approaches to opportunistic media security for SIP in , which builds on the prior efforts of . The major protocol change proposed by that specification is to signal the use of opportunistic encryption by negotiating the AVP profile in SDP, rather than the SAVP profile (as specified in ) that would ordinarily be used when negotiating SRTP. Opportunistic encryption approaches typically have no integrity protection for the keying material in SDP. Sending SIP over TLS hop-by-hop between user agents and any intermediaries will reduce the prospect that active attackers can alter keys for session requests on the wire. However, opportunistic confidentiality for media will prevent passive attacks of the form most common in the threat of pervasive monitoring.

STIR defines the Identity header field for SIP, which provides a cryptographic attestation of the source of communications. This profile of STIR assumes that a STIR verification service will act in concert with an SRTP media endpoint to ensure that the key fingerprints, as given in SDP, match the keys exchanged to establish DTLS-SRTP. To satisfy this condition, the verification service function would in this case be implemented in the SIP UAS, which would be composed with the media endpoint. If the STIR authentication service or verification service functions are implemented at an intermediary rather than an endpoint, this introduces the possibility that the intermediary could act as a man in the middle, altering key fingerprints. As this attack is not in STIR's core threat model, which focuses on impersonation rather than man-in-the-middle attacks, STIR offers no specific protections against such interference. The SIPBRANDY deployment profile of STIR for media confidentiality thus shifts these responsibilities to the endpoints rather than the intermediaries. While intermediaries MAY provide the verification service function of STIR for SIPBRANDY transactions, intermediaries supporting this specification MUST NOT block or otherwise redirects calls if they do not trust the signing credential. The SIPBRANDY profile is based on an end-to-end trust model, so it is up to the endpoints to determine if they support signing credentials, not intermediaries. In order to be compliant with best practices for SIP media confidentiality with comprehensive protection, user agent implementations MUST implement both the authentication service and verification service roles described in . STIR authentication services MUST signal their compliance with this specification by adding the "msec" header element defined in this specification to the PASSporT header. Implementations MUST provide key fingerprints in SDP and the appropriate signatures over them per . When generating either an offer or an answer, compliant implementations MUST include an "a=fingerprint" attribute containing the fingerprint of an appropriate key (see ).

In order to implement the authentication service function in the user agent, SIP endpoints will need to acquire the credentials needed to sign for their own identity. That identity is typically carried in the From header field of a SIP request, and either contains a greenfield SIP URI (e.g. "sip:alice@example.com") or a telephone number, which can appear in a variety of ways (e.g. "sip:+17004561212@example.com;user=phone"). Section 8 contains guidance for separating the two, and determining what sort of credential is needed to sign for each. To date, few commercial certificate authorities issue certificates for SIP URIs or telephone numbers; though work is ongoing on systems for this purpose (such as ) it is not mature enough to be recommended as a best practice. This is one reason why the STIR standard is architected to permit intermediaries to act as an authentication service on behalf of an entire domain, just as in SIP an proxy server can provide domain-level SIP service. While certificate authorities that offered proof-of-possession certificates similar to those used in the email world could be offered for SIP, either for greenfield identifiers or for telephone numbers, this specification does not require their use. For users who do not possess such certificates, DTLS-SRTP permits the use of self-signed keys. This profile of STIR therefore relaxes the authority requirements of to allow the use of self-signed keys for authentication services that are composed with user agents, by generating a certificate (per the guidance of ) with a subject corresponding to the user's identity. Such a credential could be used for trust on first use (see ) by relying parties. Note that relying parties SHOULD NOT use certificate revocation mechanisms or real-time certificate verification systems for self-signed certificates as they will not increase confidence in the certificate. Users who wish to remain anonymous can instead generate self-signed certificates as described in . Generally speaking, without access to out-of-band information about which certificates were issued to whom, it will be very difficult for relying parties to ascertain whether or not the signer of a SIP request is genuinely an "endpoint." Even the term "endpoint" is a problematic one, as SIP user agents can be composed in a variety of architectures and may not be devices under direct user control. While it is possible that techniques based on certificate transparency or similar practices could help user agents to recognize one another's certificates, those operational systems will need to ramp up with the certificate authorities that issue credentials to end user devices going forward.

In some cases, the identity of the initiator of a SIP session may be withheld due to user or provider policy. Per the recommendations of , this may involve using an identity such as "anonymous@anonymous.invalid" in the identity fields of a SIP request. does not currently permit authentication services to sign for requests that supply this identity. It does however permit signing for valid domains, such as "anonymous@example.com," as a way of implementation an anonymization service as specified in . Even for anonymous sessions, providing media confidentiality and partial SDP integrity is still desirable. This specification RECOMMENDS using one-time self-signed certificates for anonymous communications, with a subjectAltName of "sip:anonymous@anonymous.invalid". After a session is terminated, the certificate SHOULD be discarded, and a new one, with new keying material, SHOULD be generated before each future anonymous call. As with self-signed certificates, relying parties SHOULD NOT use certificate revocation mechanisms or real-time certificate verification systems for anonymous certificates as they will not increase confidence in the certificate. Note that when using one-time anonymous self-signed certificates, any man in the middle could strip the Identity header and replace it with one signed by its own one-time certificate, changing the "mkey" parameters of PASSporT and any "a=fingerprint" attributes in SDP as it chooses. This signature only provides protection against non-Identity aware entities that might modify SDP without altering the PASSporT conveyed in the Identity header.

STIR provides integrity protection for the SDP bodies of SIP requests, but not SIP responses. When a session is established, therefore, any SDP body carried by a 200 class response in the backwards direction will not be protected by an authentication service and cannot be verified. Thus, sending a secured SDP body in the backwards direction will require an extra RTT, typically a request sent in the backwards direction. The problem of providing "Connected Identity" for the original RFC4474 was explored in , which uses a provisional or mid-dialog UPDATE request in the backwards direction to convey an Identity header for the recipient of an INVITE. The procedures in that specification are largely compatible with the revision of the Identity header in . However, the following updates to are required: The UPDATE carrying signed SDP with a fingerprint in the backwards direction MUST be sent during dialog establishment, following the receipt of a PRACK after a provisional 1xx response. For use with this STIR Profile for media confidentiality, the UAS that responds to the INVITE request MUST act as an authentication service for the UPDATE sent in the backwards direction. The text in RFC4916 Section 4.4.1 regarding the receipt at a UAC of error codes 428, 436, 437 and 438 in response to a mid-dialog request RECOMMENDS treating the dialog as terminated. allows the retransmission of requests with repairable error conditions (see section 6.1.1) in a way that can override that SHOULD in RFC4916. In particular, an authentication service MAY retry a mid-dialog as allows rather than treating the dialog as terminated, though note that only one such retry is permitted. The examples in RFC4916 are based on the original RFC4474, and will not match signatures using . Future work may be done to revise RFC4916 for STIR; that work should take into account any impacts on the profile described in this document. The use of RFC4916 has some further interactions with ICE; see .

grants STIR verification services a great deal of latitude when making authorization decisions based on the presence of the Identity header field. It is largely a matter of local policy whether an endpoint rejects a call based on absence of an Identity header field, or even the presence of a header that fails an integrity check against the request. For this profile, however, a compliant verification service that receives a dialog-forming SIP request containing an Identity header with a PASSporT type of "msec", after validating the request per the steps described in Section 6.2, MUST reject the request if there is any failure in that validation process with the appropriate status code per Section 6.2.2. If the request is valid, then if a terminating user accepts the request, it MUST then follow the steps in to act as an authentication service and send a signed request with the "msec" PASSPorT type in its Identity header as well, in order to enable end-to-end bidirectional confidentiality. For the purposes of this profile, the "msec" PASSporT type can be used by authentication services in one of two ways: as a mandatory request for media security, or as a merely opportunistic request for media security. As any verification service that receives an Identity header in a SIP request with an unrecognized PASSporT type will simply ignore that Identity header, an authentication service will know whether or not the terminating side supports "msec" based on whether or not its user agent receives a signed request in the backwards direction per . If no such requests are received, the UA may do one or two things: shut down the dialog, if the policy of the UA requires that "msec" be supported by the terminating side for this dialog; or, if policy permits, allow the dialog to continue without media security.

As there are several ways to negotiate media security with SDP, any of which might be used with either opportunistic or comprehensive protection, further guidance to implementers is needed. In , opportunistic approaches considered include DTLS-SRTP, security descriptions, and ZRTP. Support for DTLS-SRTP is REQUIRED by this specification. The "mkey" claim of PASSporT provides integrity protection for "a=fingerprint" attributes in SDP, including cases where multiple "a=fingerprint" attributes appear in the same SDP.

Providing end-to-end media confidentiality for SIP is complicated by the presence of many forms of media relays. While many media relays merely proxy media to a destination, others present themselves as media endpoints and terminate security associations before re-originating media to its destination. Centralized conference bridges are one type of entity that typically terminates a media session in order to mux media from multiple sources and then to re-originate the muxed media to conference participants. In many such implementations, only hop-by-hop media confidentiality is possible. Work is ongoing to specify a means to encrypt both the hop-by-hop media between a user agent and a centralized server as well as the end-to-end media between user agents, but is not sufficiently mature at this time to make a recommendation for a best practice here. Those protocols are expected to identify their own best practice recommendations as they mature. Another class of entities that might relay SIP media are back-to-back user agents (B2BUAs). If a B2BUA follows the guidance in , it may be possible for those devices to act as media relays while still permitting end-to-end confidentiality between user agents. Ultimately, if an endpoint can decrypt media it receives, then that endpoint can forward the decrypted media without the knowledge or consent of the media's originator. No media confidentiality mechanism can protect against these sorts of relayed disclosures, or trusted entities that can decrypt media and then record a copy to be sent elsewhere (see ).

Providing confidentiality for media with comprehensive protection requires careful timing of when media streams should be sent and when a user interface should signify that confidentiality is in place. In order to best enable end-to-end connectivity between user agents, and to avoid media relays as much as possible, implementations of this specification must support ICE. To speed up call establishment, it is RECOMMENDED that implementations support trickle ICE. Note that in the comprehensive protection case, the use of Connected Identity with ICE entails that the answer containing the key fingerprints, and thus the STIR signature, will come in an UPDATE sent in the backwards direction a provisional response and acknowledgment (PRACK), rather than in any earlier SDP body. Only at such a time as that UPDATE is received will the media keys be considered exchanged in this case. Similarly, in order to prevent, or at least mitigate, the denial-of-service attack envisioned in Section 18.5.1, this specification incorporates best practices for ensuring that recipients of media flows have consented to receive such flows. Implementations of this specification MUST implement the STUN usage for consent freshness defined in .

The following are the best practices for SIP user agents to provide media confidentiality for SIP sessions. Implementations MUST support the STIR endpoint profile given in , and signal that in PASSporT with the "msec" header element. Implementations MUST follow the authorization decision behavior in . Implementations MUST support DTLS-SRTP for key-management, as described in . Implementations MUST support the ICE, and the STUN consent freshness mechanism, as specified in .

We would like to thank Eric Rescorla, Adam Roach, Andrew Hutton, and Ben Campbell for contributions to this problem statement and framework.

This specification defines a new values for the PASSporT Type registry called "msec," and the IANA is requested to add that to the registry with a value pointing to [RFCThis].

This document describes the security features that provide media sessions established with SIP with confidentiality, integrity, and authentication.