Edvina AB

Runbovägen 10 Sollentuna SE-192 48 SE oej@edvina.net

Real Time Applications and Infrastructure (RAI) Dispatch I-D Internet-Draft Use of TLS in the SIP protocol is defined in multiple documents, starting with RFC 3261. The actual verification that happens when setting up a SIP TLS connection to a SIP server based on a SIP URI is described in detail in RFC 5922 - SIP Domain Certificates. In this document, an alternative method is defined, using DNS-Based Authentication of Named Entities (DANE). By looking up TLSA DNS records and using DNSsec protection of the required queries, including lookups for NAPTR and SRV records, a SIP Client can verify the identity of the TLS SIP server in a different way, matching on the SRV host name in the X.509 PKIX certificate instead of the SIP domain. This provides more scalability in hosting solutions and make it easier to use standard CA certificates (if needed at all).

RFC 3261 defines how to use TLS in the SIP protocol, but doesn't describe the actual verification between a SIP request and a TLS server certificate in detail. RFC 5922 updates RFC 3261 with a definition of how a SIP client matches a PKIX X.509 certificate provided by a TLS-enabled SIP server with the domain of a SIP request that caused the connection to be set up. Verification is done using the domain part of the SIP URI and the X.509 SubjectAltName extension of type dNSName or uniformResourceIdentifier. This is called "domain verification" as opposed to "host verification" in RFC 5922. Including all domains hosted by a server in a server's certificate doesn't provide for a scalable and easy-managed solution. Every time a service adds a domain, a new certificate will need to be provided, unless TLS Server Name Identification (SNI) is used, where each domain can have it's own certificate. Having one certificate per domain and subdomain adds to the administration of a service. In addition, no known commercial CA offers certificate services with SIP URI's in the certificates. Using DNSsec and DNS-based Authentication of Named Entities (DANE) the chain from a SIP uri to a TLS certificate changes, as outlined in this document. With DNSsec, the DNS lookups are authenticated and can be verified and trusted. describes a DANE-based chain of trust, matching the SRV host name with the contents of the certificate. This document describes how a SIP implementation can use DANE to set up a secure connection to a SIP server with TLS support. In addition, we describe how a server can provide support for RFC 5922-style clients with the same certificate, if needed. This document adds an alternative to RFC5922 so that SIP implementations supporting DANE can validate a SIP domain identity using secure DNS queries and the identity of the SIP host by verifying the certificate using the SRV host name found in a SubjectAltName extension of type DNSName in the certificate. The domain verification will now happen based on DNSsec and the TLS verification will be based on host names (host verification in RFC 5922). In order to learn about DANE and the different ways a TLSA record can be constructed, readers of this document needs to also read RFC 6698 .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 . RFC 3261 defines additional terms used in this document that are specific to the SIP domain such as "proxy"; "registrar"; "redirect server"; "user agent server" or "UAS"; "user agent client" or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog"; "transaction"; "server transaction". This document uses the term "SIP Server" that is defined to include the following SIP entities: user agent server (UAS), registrar, redirect server, a SIP proxy in the role of user agent server, and a B2BUA in the role of a user agent server. This document uses the term "SIP client" that is defined to include the following SIP entities: user agent client(UAC), a SIP proxy in the role of user agent client, and a B2BUA in the role of a user agent client.

RFC 3263 describes how a SIP implementation use DNS to find the next hop server. The first step is to look up a DNS NAPTR record for the domain part of the URI. NAPTR records are used by the target domain to indicate reachability using different transports. NAPTR may be used to indicate a preference for TLS/TCP connections. The result of the NAPTR lookup is a DNS name used to query for DNS SRV records. The list of DNS SRV records indicate host names that are queried for to find A or AAAA records with IP addresses. SIP SRV records for TLS/TCP are using the prefix _sips._tcp, as in the DNS name _sips._tcp.example.com. A SIP implementation with no support for NAPTR may, based on configuration or URI scheme, choose to set up a TLS session to the target domain. In rare cases, no SRV lookup is done. This means that the implementation lacks capability to do load balancing and failover based on the information in the DNS. These type of clients are not considered in this document.

DNS relies on DNS lookups not only to find the next hop server, but also for server administrators to provide failover and to load balance clients. The result of querying for one domain may need to SRV records or host names in another domain. Without DNSsec, an attacker can forge DNS replies and issue bogus DNS records, directing traffic to a bad server. This applies to calls as well as instant messaging, chat and presense.

It is important for implementors to understand the concept of "secure" DNSsec validation according to RFC 4033. For this specification to take effect, all DNS RRsets in the chain from SIP URI to IP address and TLSA record must be secure. (This corresponds to the A.D. bit being set in the responses). If any RRset is not secure, this specification doesn't apply and the implementation should fall back to RFC 5922 behaviour. If any of the responses are "bogus" according to DNSsec validation, the client MUST abort the connection.

For the SIP protocol DANE usage, TLSA records are to be found in accordance with . If the domain example.com's TLS SRV records points to sip01.example.com port 5042 then the corresponding TLSA record will be found using the name _5042._tcp.sip01.example.com.

DANE capable SIP implementations follow the procedures above to find a SRV host name and look for a TLSA record. If no TLSA record is found, the client should fall back to RFC 5922 behaviour. If a TLSA record is found, the client should never fall back to RFC 5922 behaviour. If TLSA-based validation fails, the client MUST abort the connection attempt.

When using DANE-based validation the client validates the SRV hostname with the certificate using RFC 5922 rules. A DANE-capable SIP implementation looks for the SRV hostname in the list of SubjAltName DNSName extension fields. Only if there are no SubjAltName extension fields may the client look in the CN of the X.509 certificate (according to RFC 5922). If the SRV host name is not found in the certificate, DANE validation fails and the client MUST abort the connection. Using the SRV host name for validation of a SIP domain identity is an update to RFC 5922

RFC 5922 implementations with no DANE support will be able to connect with the matching described in that document. SIP Servers can use certificates that are compatible with both this specification and RFC5922. requires use of the TLS Server Name Indication (SNI) extension . This is not a requirement in this document, since SIP certificates can support both RFC 5922 style validation and DANE-based validation with the same certificate.

This section gives examples on certificate content and how the match a given URI. The X.509 PKIX Subject field CN value is abbreviated as "CN", the SubjectAltName extension DNSName and uniformResourceIdentifier are abbreviated as "SAN-DNS" and "SAN-URI". The certificates are tested with three different clients. A DANE-aware client, a RFC 5922 client with no DANE support and a client that matches the SIP domain with the Common Name in the Subject of the certificate. The last example is not really covered by any SIP-related RFC and should be avoided.

Domain: johansson.example.com DNS SRV host for TLS: siphosting.example.net Certificate content: CN: siphosting.example.net SAN-URI: - SAN-DNS: - Matching for DANE-aware SIP clients: Yes Matching for only RFC 5922 SIP clients: No Matching on CNAME only: No

Domain: lundholm.example.com DNS SRV host for TLS: sipcrew.example.net Certificate content: CN: randomname.example.net SAN-URI: sip:lundholm.example.com SAN-DNS: lundholm.example.com Matching for DANE-aware SIP clients: Yes Matching for only RFC 5922 SIP clients: Yes Note: More examples is coming here.

This document use already published solutions for providing credentials for setting up a secure connection to a SIP server. By depending on secure lookups of DNS NAPTR and SRV records as well as using TLSA records to verify a SIP servers TLS certificate it describes a secure method for making sure that a SIP request for a domain is sent to an authoritative server. In addition to this document, many security considerations are covered in ID.ietf-dane-srv.

This document does not require actions by IANA.

The author wishes to acknowledge Jakob Schlyter for inspiration and .SE for promoting DNSsec and DANE. Victor Dubovn

Developers of SIP implementations are strongly encouraged to implement RFC 5922 and this document for secure verification of a SIP domain with a TLS server. This document also encourages implementation of TLS SNI both in client and server implementations. In order to get support of this function, update to new versions of the TLS libraries and make sure that the implementation supports new versions of TLS - TLS 1.1 and TLS 1.2 . Implementatinos that do support TLS are encouraged to always start with attempting TLS, even if the URI is a SIP: uri. If there are NAPTR records for the domain and the domain indicates support of TLS, use it. If there are no NAPTR records, start SRV lookup with the _sips._tcp prefix. This way, the SIP network will gradually shift to always using secure and authenticated TLS sessions.