TLS 1.3 and Certificate Identity for the Session Initiation Protocol

Introduction The use of TLS with SIP is defined principally by , which introduced TLS as a SIP transport, and by , which specifies how the identity of a SIP domain is represented in a certificate and matched by a peer. Both predate the current state of TLS and of certificate identity practice, and in two respects they now state requirements that cannot be followed. requires support for a specific cipher suite that uses static RSA key exchange. That suite does not exist in TLS 1.3 , and static RSA key exchange was removed from the protocol, so an implementation that supports only TLS 1.3 cannot conform to the requirement. Recommendations for the secure use of TLS are now maintained in , and earlier TLS versions have been deprecated . prefers that a SIP domain identity be carried in a subjectAltName entry of type uniformResourceIdentifier containing a "sip" URI, accepts a dNSName entry only when no matching URI entry is present, and permits the Subject common name to be examined when no subjectAltName extension appears at all. , which obsoletes the general service identity guidance that was written against, establishes that service identity may be expressed only in the subjectAltName extension, that the common name is no longer valid for this purpose, and that the identifiers it covers are domain names, IP addresses, and SRV service names. Deployed general purpose TLS implementations verify dNSName entries and commonly do not examine URI entries at all. There is also a reason not to leave these updates for later. Post-quantum key agreement is defined for TLS 1.3 and not for earlier versions, and deprecates the key agreement algorithms in current use after 2030. SIP signaling carries call records whose confidentiality matters for years, and where SRTP keys travel in the session description it carries those too. A SIP implementation that cannot negotiate TLS 1.3 cannot protect any of that against later decryption. Making TLS 1.3 the baseline for SIP is the one change SIP needs in order to follow the transition; the algorithms themselves are selected in TLS, and this document says nothing about them. This document updates and accordingly. It does not otherwise change the use of TLS with SIP, and it does not address the use of certificates to convey authority over telephone numbers .

Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Updates to RFC 3261: TLS Versions and Cipher Suites Section 26.2.2 of requires that proxy servers, redirect servers, and registrars support TLS and implement the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. That requirement is removed by this document. An implementation that supports TLS as a SIP transport MUST support TLS 1.3 and SHOULD negotiate it in preference to earlier versions. TLS 1.2 MAY be supported for interoperability with deployed implementations. TLS versions 1.0 and 1.1 are already deprecated for by , which updates it for that purpose, and MUST NOT be used. Cipher suite selection follows . Where TLS 1.2 is used, a cipher suite providing ephemeral key exchange and authenticated encryption MUST be selected; static RSA key exchange MUST NOT be used, as it provides no forward secrecy. This document specifies no mandatory cipher suite. Interoperability at the cipher suite level is provided by TLS 1.3, which defines a small mandatory set within the protocol itself, and by the recommendations of for earlier versions. This document specifies no key agreement group or signature algorithm; they are selected by TLS negotiation. The certificates used for SIP over TLS where telephone number authority is involved are the subject of .

Updates to RFC 5922: Certificate Identity for SIP Domains This section replaces the rules in for representing a SIP domain identity in a certificate, for finding such identities in a presented certificate, and for comparing them against the domain a peer intended to reach. The comparison model of is retained, as are its procedures for what a peer does with the result of a comparison; only the identifiers used and the manner of comparing them are changed.

Representation A certificate identifying a SIP domain MUST carry that domain in a subjectAltName entry of type dNSName. A certificate MAY additionally carry a subjectAltName entry of type uniformResourceIdentifier containing a "sip" URI with no user part, as described in , for compatibility with implementations that follow those rules. Where both are present, they are expected to designate the same domain. The Subject common name MUST NOT be used to convey a SIP domain identity. This removes the allowance in for examining the common name when no subjectAltName extension is present.

Verification A peer verifying a certificate MUST verify a dNSName entry against the domain it intended to reach, applying the matching rules of , including its restriction that a wildcard may appear only as the complete leftmost label of a domain name. A peer MUST NOT accept a "sip" URI subjectAltName entry as the sole basis for identifying a SIP domain. A peer MAY examine such an entry in addition to a dNSName entry, and MAY use it where its local policy requires consistency between the two. A peer MUST NOT examine the Subject common name for this purpose. If no dNSName entry matches, the comparison fails, and the peer applies the behavior specified in for a failed comparison.

Interaction with the SIP Domain Extended Key Usage , an Experimental specification, defines an extended key usage, id-kp-sipDomain, indicating that a certificate is issued for SIP domain use and restricting the names in it to use by a SIP service. Its validation steps are defined as an addition to the identity-finding procedure of that this document replaces. An implementation that applies applies its extended key usage checks in addition to, and independently of, the representation and verification rules of this section. This document neither requires nor precludes the presence of that extended key usage, and does not change the behavior specifies for a certificate that carries no extended key usage extension.

Requesting the Use of TLS Two mechanisms exist for requesting that a SIP request be carried over TLS, and a third is deprecated. Deployments continue to combine them, which produces requests whose intent is ambiguous. The "transport=tls" URI parameter MUST NOT be used to request TLS. Section 26.2.2 of deprecated it, and confirms that deprecation; the parameter remains in the grammar of but carries no meaning for this purpose. A request is not carried over TLS by virtue of the parameter being present, and a peer receiving it is under no obligation as a result. A SIPS URI in the Request-URI requests that the request be carried over TLS on every hop toward the target, as specified in . Where that cannot be achieved, the request fails rather than being delivered without TLS. The requirement propagates: the Contact header field must also carry a SIPS URI, and subsequent requests within the dialog are subject to the same condition. A SIPS URI is therefore appropriate where a deployment requires TLS on every hop and prefers failure to insecure delivery. A SIP URI carried over a TLS connection requests nothing about any other hop. The connection on which the request is carried is protected, and any requirement that other hops be protected comes from the local policy of the deployment or from a profile that specifies it, rather than from the URI. As stated in , this is the appropriate construction where TLS is used on a hop without invoking the requirements the SIPS scheme places on the remainder of the path. A deployment MUST use one of these two constructions consistently. The scheme of the URI being resolved, the procedure used to resolve it as described in , and the scheme used in the Contact and Record-Route header fields refer to the same mechanism, and a request in which they differ is ambiguous. In particular, resolving a SIP URI using the service label defined for the SIPS scheme, or populating a SIPS URI while carrying the request over an unprotected hop, are both inconsistent. Where a profile requires that TLS be used on a given interface, that requirement is stated by the profile and applies whether or not a SIPS URI is used.

Interaction with Resolution Where a SIP URI is resolved to a host through NAPTR and SRV records , the name verified against the certificate is the domain of the URI that was resolved, and not the target name returned by the SRV record. This preserves the property established in that the identity verified is the identity to which the request was addressed. Verifying the SRV target name instead would allow a party able to influence resolution to direct a connection to a host holding a valid certificate for an unrelated domain, and to have that certificate accepted.

Security Considerations The changes in this document narrow the set of identifiers a peer will accept as a SIP domain identity. Removing the Subject common name removes a source of identity that has no defined syntax for this purpose and that issuers populate inconsistently. Requiring a dNSName entry aligns SIP with the identifier type that deployed TLS implementations verify, reducing the likelihood that an implementation accepts a certificate on the basis of an identifier its peer did not intend as authoritative. Removing the mandatory cipher suite of removes a requirement to implement static RSA key exchange, which provides no forward secrecy. A recorded session protected by such a suite can be decrypted by an adversary that later obtains the server private key. The considerations of and apply to implementations of this document.

IANA Considerations This document has no IANA actions.

Acknowledgments Thanks to Russ Housley for his review.