Using DNS Security Extensions (DNSSEC) and DNS-based Authentication of Named Entities (DANE) as a Prooftype for XMPP Domain Name Associations
Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver
CO
80202
USA
mamille2@cisco.com
Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver
CO
80202
USA
psaintan@cisco.com
RAI
Internet-Draft
XMPP
Extensible Messaging and Presence Protocol
Jabber
DNSSEC
DANE
This document defines a prooftype that uses DNS-based Authentication of Named Entities (DANE) for associating a domain name with an XML stream in the Extensible Messaging and Presence Protocol (XMPP). It also defines a method that uses DNS Security (DNSSEC) for securely delegating a source domain to a derived domain in XMPP.
The specification defines a framework for secure delegation and authenticated domain name associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP). This document defines a a secure delegation method that uses DNS Security (DNSSEC) in conjuction with the standard DNS SRV records employed in domain name resolution in XMPP, with the result that a client or peer server that inititates an XMPP stream can legitimately treat a derived domain as a reference identifier during stream negotiation. This document also defines a prooftype for DNA that uses DNS-based Authentication of Named Entities to verify TLS certificates containing source domains or derived domains during stream negotiation.
This document inherits XMPP-related terminology from , DNS-related terminology from , , and , and security-related terminology from and . The terms "source domain", "derived domain", "reference identifier", and "presented identifier" are used as defined in the "CertID" specification .
This document is applicable to connections made from an XMPP client to an XMPP server ("_xmpp-client._tcp") or between XMPP servers ("_xmpp-server._tcp"). In both cases, the XMPP initiating entity acts as a TLS client and the XMPP receiving entity acts as a TLS server. Therefore, to simplify discussion this document uses "_xmpp-client._tcp" to describe to both cases, unless otherwise indicated.
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 .
An XMPP initiating entity (TLS client) that wishes to use this prooftype MUST do so before exchanging stanzas addressed to the source domain. In general, this means that the proof MUST be completed before the XMPP stream is restarted following STARTTLS negotiation (as specified in ). However, connections between XMPP servers MAY also use this prooftype to verify the addition of new source domains onto an existing connection, such as multiplexing or "piggybacking" via .
An XMPP initiating entity (TLS client) that wishes to use this prooftype performs the following actions:
Query for the appropriate SRV resource record for the source domain (e.g. "_xmpp-client._tcp.im.example.com").
If there is no SRV resource record, pursue the fallback methods described in .
If there is an SRV resource record, validate that the SRV record answer is secure according to . If the answer is insecure, then delegation to the derived domain(s), as indicated by the "target host" field, is insecure and the TLS client MUST treat only the source domain as a reference identifier during certificate verification, as described in ; if the answer is bogus, the TLS client MUST abort.
If the answer is secure, the TLS client SHOULD consider any derived domain(s) in the answer as securely delegated; during certificate verification, the TLS client MUST treat both the source domain and the derived domain to which it has connected as reference identifiers.
provides additional tools to verify the keys used in TLS connections. A TLS client MAY use for TLS certificate verification; its use depends on the delegation status of the source domain, as described in the following sections.
If no SRV records are found for the source domain, then the TLS client MUST query for a TLSA resource record as described in , where the prepared domain name MUST contain the source domain and the IANA-registered port 5222 for client-to-server streams (e.g. "_5222._tcp.im.example.com") or the IANA-registered port 5269 for server-to-server streams (e.g. "_5269._tcp.im.example.com").
In this case, the TLS client MUST treat only the source domain as its reference identifier during certificate verification, as described in .
If the delegation of a source domain to a derived domain is not secure, then the TLS client MUST NOT make a TLSA record query to the derived domain as described in . Instead, the TLS client MUST treat only the source domain as its reference identifier during certificate verification, as described in , and MUST NOT use .
If the source domain has been delegated to a derived domain in a secure manner as described under , then the TLS client MUST query for a TLSA resource record as described in , where the prepared domain name MUST contain the derived domain and a port obtained from the SRV answer (e.g., "_5555._tcp/hosting.example.net" for an SRV record such as "_xmpp-client._tcp.im.example.com IN TLSA 1 1 5555 hosting.example.net").
If no TLSA resource records exist for the specified service, then the TLS client MUST perform certificate verification as described under .
If TLSA resource records exist for the specified service, then the TLS client MUST treat the derived domain(s) as its reference identifier during certificate verification, using the information from the TLSA answer as the basis for verification as described in .
If the SRV, A/AAAA, and TLSA record queries are for an internationalized domain name, then they need to use the A-label form as defined in .
This document supplements but does not supersede the security considerations provided in , , , and .
This document has no actions for the IANA.
The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
VPN Consortium
paul.hoffman@vpnc.org
Kirei AB
jakob@kirei.se
Domain names - concepts and facilities
Information Sciences Institute (ISI)
Domain names - implementation and specification
USC/ISI
4676 Admiralty Way
Marina del Rey
CA
90291
US
+1 213 822 1511
Key words for use in RFCs to Indicate Requirement Levels
Harvard University
1350 Mass. Ave.
Cambridge
MA 02138
- +1 617 495 3864
-
General
keyword
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their 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.
Note that the force of these words is modified by the requirement level of the document in which they are used.
A DNS RR for specifying the location of services (DNS SRV)
Troll Tech
Waldemar Thranes gate 98B
Oslo
N-0175
NO
+47 22 806390
+47 22 806380
arnt@troll.no
Internet Software Consortium
950 Charter Street
Redwood City
CA
94063
US
+1 650 779 7001
Microsoft Corporation
One Microsoft Way
Redmond
WA
98052
US
levone@microsoft.com
This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.
DNS Security Introduction and Requirements
Telematica Instituut
roy.arends@telin.nl
Internet Systems Consortium
sra@isc.org
VeriSign, Inc.
mlarson@verisign.com
Colorado State University
massey@cs.colostate.edu
National Institute for Standards and Technology
scott.rose@nist.gov
Internet Security Glossary, Version 2
This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS TRACK]
Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]
Extensible Messaging and Presence Protocol (XMPP): Core
Cisco
psaintan@cisco.com
Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
Cisco
psaintan@cisco.com
PayPal
jeff.hodges@paypal.com
Server Dialback
jer@jabber.org
Cisco
psaintan@cisco.com
fippo@goodadvice.pages.de
Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)
Cisco
psaintan@cisco.com
Cisco
mamille2@cisco.com