Internet DRAFT - draft-johansson-dane-sip
draft-johansson-dane-sip
Dispatch O. Johansson
Internet-Draft Edvina AB
Updates: 5922 (if approved) July 10, 2013
Intended status: Standards Track
Expires: January 11, 2014
TLS sessions in SIP using DNS-based Authentication of Named Entities
(DANE) TLSA records
draft-johansson-dane-sip-00
Abstract
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).
This document updates RFC 5922.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 11, 2014.
Copyright Notice
Johansson Expires January 11, 2014 [Page 1]
Internet-Draft SIP TLS connection setup using DANE July 2013
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions Used in This Document . . . . . . 3
3. Using DNS in the SIP protocol . . . . . . . . . . . . . . . . 4
4. Why DNSsec is important for SIP . . . . . . . . . . . . . . . 4
5. Secure delegation is required for DANE to apply . . . . . . . 4
6. TLSA record name . . . . . . . . . . . . . . . . . . . . . . 5
7. Procedures for DANE-capable SIP implementations . . . . . . . 5
8. X.509 certicate validation . . . . . . . . . . . . . . . . . 5
9. Backward Compatibility with RFC 5922 . . . . . . . . . . . . 5
10. Examples on certificate content . . . . . . . . . . . . . . . 6
10.1. Example 1: johansson.example.com . . . . . . . . . . . . 6
10.2. Example 2: lundholm.example.com . . . . . . . . . . . . 6
11. Security Considerations . . . . . . . . . . . . . . . . . . . 7
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
14.1. Normative References . . . . . . . . . . . . . . . . . . 7
14.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Appendix A. Implementation notes . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
RFC 3261 [RFC3261] 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 [RFC5922] updates RFC
3261 with a definition of how a SIP client matches a PKIX X.509
[RFC5280] 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.
Johansson Expires January 11, 2014 [Page 2]
Internet-Draft SIP TLS connection setup using DANE July 2013
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)[RFC6698] 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.
[I-D.ietf-dane-srv] 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 updates 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
[RFC6698].
2. Terminology and Conventions Used in This Document
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 [RFC2119].
RFC 3261 [RFC3261] 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".
Johansson Expires January 11, 2014 [Page 3]
Internet-Draft SIP TLS connection setup using DANE July 2013
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.
3. Using DNS in the SIP protocol
RFC 3263[RFC3263] 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.
4. Why DNSsec is important for SIP
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.
5. Secure delegation is required for DANE to apply
It is important for implementors to understand the concept of
"secure" DNSsec validation according to RFC 4033[RFC4033]. For this
Johansson Expires January 11, 2014 [Page 4]
Internet-Draft SIP TLS connection setup using DANE July 2013
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[RFC5922] behaviour. If
any of the responses are "bogus" according to DNSsec validation, the
client MUST abort the connection.
6. TLSA record name
For the SIP protocol DANE usage, TLSA records are to be found in
accordance with [I-D.ietf-dane-srv]. 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.
7. Procedures for DANE-capable SIP implementations
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.
8. X.509 certicate validation
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
9. Backward Compatibility with RFC 5922
RFC 5922[RFC5922] 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.
Johansson Expires January 11, 2014 [Page 5]
Internet-Draft SIP TLS connection setup using DANE July 2013
[I-D.ietf-dane-srv] requires use of the TLS Server Name Indication
(SNI) extension [RFC6066]. 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.
10. Examples on certificate content
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.
10.1. Example 1: johansson.example.com
o Domain: johansson.example.com
o DNS SRV host for TLS: siphosting.example.net
Certificate content:
o CN: siphosting.example.net
o SAN-URI: -
o SAN-DNS: -
o Matching for DANE-aware SIP clients: Yes
o Matching for only RFC 5922 SIP clients: No
o Matching on CNAME only: No
10.2. Example 2: lundholm.example.com
o Domain: lundholm.example.com
o DNS SRV host for TLS: sipcrew.example.net
Certificate content:
o CN: randomname.example.net
o SAN-URI: sip:lundholm.example.com
Johansson Expires January 11, 2014 [Page 6]
Internet-Draft SIP TLS connection setup using DANE July 2013
o SAN-DNS: lundholm.example.com
o Matching for DANE-aware SIP clients: Yes
o Matching for only RFC 5922 SIP clients: Yes
Note: More examples is coming here.
11. Security Considerations
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.
12. IANA Considerations
This document does not require actions by IANA.
13. Acknowledgements
The author wishes to acknowledge Jakob Schlyter for inspiration and
.SE for promoting DNSsec and DANE. Victor Dubovn
14. References
14.1. Normative References
[I-D.ietf-dane-srv]
Finch, T., "Using DNS-Based Authentication of Named
Entities (DANE) TLSA records with SRV and MX records.",
draft-ietf-dane-srv-02 (work in progress), February 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
Johansson Expires January 11, 2014 [Page 7]
Internet-Draft SIP TLS connection setup using DANE July 2013
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, June
2002.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, June 2010.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012.
14.2. Informative References
[I-D.ogud-dane-vocabulary]
Gudmundsson, O., "Harmonizing how applications specify
DANE-like usage", draft-ogud-dane-vocabulary-00 (work in
progress), June 2013.
[RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session
Initiation Protocol (SIP) Call Control - Transfer", BCP
149, RFC 5589, June 2009.
Appendix A. Appendix A. Implementation notes
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
Johansson Expires January 11, 2014 [Page 8]
Internet-Draft SIP TLS connection setup using DANE July 2013
the TLS libraries and make sure that the implementation supports new
versions of TLS - TLS 1.1 [RFC4346] and TLS 1.2 [RFC5246].
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.
Author's Address
Olle E. Johansson
Edvina AB
Runbovaegen 10
Sollentuna SE-192 48
SE
Email: oej@edvina.net
Johansson Expires January 11, 2014 [Page 9]
