Domain Certificates in the Session Initiation Protocol (SIP)
updates
- rfc-3261 — SIP: Session Initiation Protocol
Extracted elements (26)
S/MIME certificates in SIP bind the identity of an individual user (end-to-end), while TLS certificates bind per-hop domain identities. This distinction motivated separate, more specific guidance for TLS certificate use that RFC 3261 did not provide.
The subjectAltName extension is strongly preferred over the Subject CN field because: (1) it can hold multiple values enabling one certificate to cover multiple SIP domains, and (2) the Subject field has no fixed syntax, forcing heuristic extraction that increases misinterpretation.
Wildcards are prohibited in SIP domain certificates because RFC 3261 provides no guidance on wildcard handling and the potential for misidentification in a federated environment is significant; this is a deliberate departure from the HTTPS practice in RFC 2818.
For backward compatibility with legacy certificates, implementations MAY accept a DNS name from the Subject CN field if and only if the subjectAltName extension is absent. New certificates SHOULD use the subjectAltName extension instead.
This document updates RFC 3261 Section 26.3.1: the recommended text is changed from requiring a certificate whose subject corresponds to the server's canonical hostname to one whose subjects include the name of the SIP domain for which the server is authoritative.
Unlike RFC 2818 (HTTP over TLS), which allows wildcard dNSName values such as '*.example.com', this document explicitly prohibits wildcard matching in certificates for SIP domains; '*.example.com' matches only '*.example.com' and not 'foo.example.com'.
A client MUST determine the SIP domain identities from the server certificate using Section 7.1 procedures, compare them to the domain from the original SIP AUS, and if the server is not authenticated, MUST close the connection immediately.
A SIP implementation SHOULD NOT use the Digest Authentication of one message on a TCP connection or from a UDP peer to infer authentication of any other messages on that connection or from that peer. Domain authentication SHOULD be accomplished using TLS and certificate validation.
A SIP service provider MUST ensure that the SIP domain used to reach the server appears as an identity in the subjectAltName field, or for compatibility with existing certificates, the Subject field of the certificate.
An implementation MUST accept a DNS-type subjectAltName identifier as a SIP domain identity if and only if no other identity is found that matches the 'sip' URI type.
If a proxy inserts a Record-Route with the expectation that the route uses secure connections, the proxy MUST insert into the Record-Route header a URI that corresponds to an identity for which the proxy has a certificate.
If and only if the subjectAltName does not appear in the certificate, the implementation MAY examine the CN field of the Subject. Accepting a DNS name from the CN is allowed only for backward compatibility.
If the client does not present a certificate when requested by the server, the client MUST NOT be considered authenticated. Whether to close the connection is a matter of local policy.
If the TLS client hello 'server_name' extension (RFC 4366) is supported, the client SHOULD use that extension to request a certificate corresponding to the specific SIP domain (from the AUS) with which it seeks to establish a connection.
Implementations MUST determine the validity of a certificate by following the procedures described in RFC 5280, and MUST check for restrictions declared by any extendedKeyUsage extensions in the certificate.
Implementations MUST NOT match suffixes (e.g., 'foo.example.com' does not match 'example.com') and MUST NOT match any form of wildcard such as a leading '.' or '*.' with any other DNS label or sequence of labels.
In the subjectAltName field, only URI and DNS types are acceptable for encoding a SIP domain identity. For URI type, the scheme must be 'sip' and no userinfo component (no '@') may be present; if a userpart is present, the implementation MUST NOT accept it as a SIP domain identity.
When authenticating the client, the server MUST obtain the set of SIP domain identities from the client certificate as described in Section 7.1, and may use these identities to make authorization decisions.
When comparing SIP domain identities, implementations MUST compare only the DNS name component, MUST perform a case-insensitive comparison per RFC 4343, and MUST handle Internationalized Domain Names in accordance with RFC 5280 Section 7.2.
A SIP domain identity is an identity (e.g., 'sip:example.com') contained in an X.509 certificate bound to a subject that identifies the subject as an authoritative SIP server for a domain. It is encoded in the subjectAltName extension as a URI of scheme 'sip' without a userinfo component, or as a DNS name.
For virtual SIP servers hosting multiple domains, a single certificate can contain multiple SIP domain identities by including distinct values in the subjectAltName extension. Clients authenticate by matching the AUS domain against the set of identities extracted per Section 7.1.
Proxy-to-proxy interdomain authentication via TLS requires each proxy to present a certificate and for the receiving proxy to extract and verify domain identities from it; the passive server (Proxy-B) lacks an AUS anchor and must rely on policy-based comparison of the client certificate's identity set.
Routing in SIP uses RFC 3263 procedures on the Application Unique String (AUS): the domain portion of the SIP URI is extracted, DNS is queried to obtain an ordered set of IP addresses with port and transport, and if TLS is indicated, a TLS connection is opened and the server certificate is verified against the AUS domain.
The subjectAltName extension of type uniformResourceIdentifier (URI) is the preferred field for encoding a SIP domain identity in an X.509 certificate; it can hold multiple values, enabling one certificate to identify multiple SIP domains or servers.
Digest authentication in SIP provides only very limited integrity protection and no binding to the transport. Using Digest authentication of one message to authenticate an entire TCP connection or UDP peer address goes beyond the mechanism's designed assurances and SHOULD NOT be done.
Proper use of TLS with domain certificates provides application-level confidentiality, integrity, and mutual domain authentication across the SIP trapezoid: messages can only be read or modified by the originating user, the terminating user, and proxies holding domain certificates for the relevant domains.