Using DNSSEC and DANE as a Prooftype for XMPP Delegation
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 model for securely delegating an XMPP service for a domain to a host associated with a different domain.
In the core XMPP specification , the domain to which an XMPP initiating entity wants to connect is asserted via the 'to' attribute of the <stream:stream> header, and the TLS certificate offered by the receiving server is required to match this source domain (e.g., "im.example.com"). However, this model can cause problems if the source domain is delegated (via DNS SRV records ) to a host associated with a different domain that is derived via SRV (e.g., "hosting.example.net"), since the derived domain might also be the delegate for a number of other source domains and, for operational and security reasons, a hosting server is rarely able to present a certificate that matches the source domain.
Absent the use of DNS Security , delegation via SRV does not provide a strong basis for checking the derived domain rather than the source domain. This document describes how the use of DNSSEC with SRV results in more secure delegation, such that the initiating XMPP server can legitimately check the derived domain rather than the source domain.
This document inherits XMPP-related terminology from , DNS-related terminology from , , and , and security-related terminology from and . The terms "source domain" and "derived domain" 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 the prooftype 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 delegations of additional source domains onto an existing connection, such as multiplexing 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 or bogus, then delegation to the derived domain (as indicated by the "target host" field) is insecure and the TLS client MUST verify the certificate against the source domain as described in .
If there is an SRV record, for each derived domain from the SRV record answer (e.g. "hosting.example.net"), query for the "A" and/or "AAAA" resource records as described in .
For each derived domain, validate that the address record answers are provably secure according to
If any answer is insecure or bogus, then the TLS client MUST NOT consider a connection to that derived domain as securely delegated from the source domain; when verifying the certificate, the TLS client MUST do so against the source domain as described in .
For each address record answer that is a provably secure, the TLS client SHOULD consider a connection to that derived domain as securely delegated; when verifying the certificate (as described in ), the TLS client SHOULD do so against the derived domain but MAY also verify the certificate against the source domain.
provides additional tools to verify the keys used in TLS connections. Whether it is appropriate to use for TLS certificate verification depends on the delegation status of the source domain, as described in the following sections.
If the source domain has not been delegated to a derived domain, i.e., if the source domain and the derived domain are identical (e.g., "im.example.com"), then the TLS client MAY query for a TLSA resource record as described in , where the prepared domain name MUST contain the source domain and a port of 5222 for client-to-server streams (e.g. "_5222._tcp.im.example.com") or 5269 for server-to-server streams (e.g. "_5269._tcp.im.example.com").
In this case, the TLS client MUST perform certificate verification against the source domain 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 perform certificate verification against the source domain as described in , and MAY make a TLSA query against the source domain.
If the source domain has been delegated to a derived domain in a secure manner as described under , then the TLS client SHOULD query for a TLSA resource record as described in , where the prepared domain name MUST contain the derived domain and a port of 5222 for client-to-server streams or 5269 for server-to-server streams (e.g. "_5222._tcp.hosting.example.net").
If no TLSA resource records exist for the specified service, then the TLA client MUST perform certificate verification against the source domain as described in .
If TLSA resource records exist for the specified service, then the TLS client MUST perform certificate verification against the derived domain, using the information from the TLSA answer as the basis for verification as described in .
If a TLSA resource record specifies certificate usage 3 (also known as "domain-issued certificate"), verification MUST NOT consider the source or derived domain. Instead, the target certificate MUST match the TLSA record, as specified in . If matched, the TLS connection MUST considered valid for the source domain regardless of the target certificate's information.
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