| Network Working Group | P. Saint-Andre |
| Internet-Draft | M. Miller |
| Intended status: Standards Track | Cisco Systems, Inc. |
| Expires: December 27, 2012 | June 27, 2012 |
Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)
draft-saintandre-xmpp-dna-00
This document defines a framework for improving the security of the Extensible Messaging and Presence Protocol (XMPP) in two respects. First, it introduces the concept of a prooftype for establishing a strong association between a domain name and an XML stream. Second, it provides guidelines for securely delegating a source domain to a derived domain, which is especially important in virtual hosting environments.
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 December 27, 2012.
Copyright (c) 2012 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.
This document defines a framework for improving the security of the Extensible Messaging and Presence Protocol (XMPP) in two respects. First, it introduces the concept of a prooftype for establishing a strong association between a domain name and an XML stream (i.e., a domain name association or "DNA"). Second, it provides guidelines for securely delegating a source domain to a derived domain, which is especially important in virtual hosting environments.
The need to establish a strong association between a domain name and an XML stream arises in both client-to-server and server-to-server communication using XMPP, because XMPP servers are typically identified by domain names. However, a client or peer server needs to verify the identity of a server to which it connects. To date, such verification has been established based on information obtained from the Domain Name System (DNS), the Public Key Infrastructure (PKI), or similar sources. This document generalizes the model currently in use so that additional prooftypes can be defined, and also provides a basis for modernizing some prooftypes (e.g., Server Dialback [XEP-0220]) to reflect progress in several underlying technologies, especially DNS Security [RFC4033].
The process for resolving the domain name of an XMPP service into the IP address at which an XML stream will be negotiated (defined in [RFC6120]) can involve delegation of a source domain (say, im.example.com) to a derived domain (say, hosting.example.net). If such delegation is not done in a secure manner, then the domain name association cannot be authenticated. Therefore, this document also provides guidelines for defining secure delegation methods.
This document does not define any DNA prooftypes or secure delegation methods; such technologies are defined in companion documents.
This document inherits XMPP-related terminology from [RFC6120] and [XEP-0220], DNS-related terminology from [RFC1034], [RFC1035], [RFC2782] and [RFC4033], and security-related terminology from [RFC4949] and [RFC5280]. The terms "source domain", "derived domain", "reference identity", and "presented identity" are used as defined in the "CertID" specification [RFC6125]. The terms "permissive federation", "verified federation", and "encrypted federation" are derived from [XEP-0238], although we substitute the term "authenticated federation" for the term "trusted federation" from that document.
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 [RFC2119].
In XMPP, each party to a stream expects the other party to provide some proof of its identity. For example, in client-to-server streams the server expects the client to present some credentials (such as a username and password or a client certificate), and ideally the client also expects the server to provide a certificate that identifies the domain(s) of the server. Similar considerations hold true for server-to-server streams, also called "interdomain federation".
When the Jabber.org open-source community developed the precursor to XMPP in 1999, it defined methods for interdomain federation but no mechanisms for authenticating or checking the identity of peer servers. We could describe this as "permissive federation", which is clearly sub-optimal given the strong potential for domain spoofing. In the year 2000, the community filled the gap to some extent by defining a technology called Server Dialback (first documented in [RFC3920] and since moved to [XEP-0220]). Although Server Dialback does not provide a strong mechanism for identity checking without the use of DNSSEC, it does provide DNS-based verification and thus has effectively prevented most instances of domain spoofing on the XMPP network since late 2000. Also, because Server Dialback typically does not involve the use of server certificates, it does not result in an encrypted stream; thus we refer to it as a technology for "verified federation".
In 2002-2004, the IETF's XMPP Working Group hardened the original Jabber.org protocols by adding Transport Layer Security (TLS) and Simple Authentication and Security Layer (SASL), thus making it possible for two servers to engage in "authenticated federation" (i.e., when two peer servers present PKIX certificates anchored to trusted roots during negotiation of a server-to-server stream) or "encrypted federation" (i.e., when two peer servers present PKIX certificates that are self-signed or not anchored to trusted roots during negotiation of a server-to-server stream).
Unfortunately, authenticated federation has not been widely deployed on the XMPP network (indeed, even encrypted federation is not widely deployed because verified federation is perceived as "good enough"); one of the primary reasons is that it is feasible (although not always easy) for single-domain servers to obtain the proper certificates, but much more difficult (or practically impossible) for large XMPP hosting providers to do so. The primary challenge here is operational: it is highly unlikely that an organization (say, example.com) wishing to delegate its XMPP service (say, im.example.com) to a hosting provider (say, hosting.example.net) will hand over its private key to the hosting provider. Even if that were feasible, further operational challenges (e.g., maintaining large numbers of certificates for hosted domains, and configuring XMPP software to present the correct certificate based on the 'to' address of the initial stream header) have also discouraged deployment of authenticated federation in virtual hosting environments, which happen to be a common deployment scenario.
Furthermore, the prevalence of delegation to hosting providers leads to one additional shortcoming, caused by the use of DNS SRV records [RFC2782] in XMPP: if DNSSEC is not used, the act of delegation is inherently insecure. Unfortunately, no existing documentation explains how to use DNSSEC for secure delegation, with the result that clients and servers often take a "leap of faith" if using an SRV record to determine that when communicating with, say, im.example.com they actually need to connect to, say, hosting.example.net.
In order to meet the requirements for strong security [RFC3365], both authenticated federation and secure delegation are needed so that the association between a domain name and an XML stream can be trusted by XMPP entities. Unfortunately, authenticated federation is uncommon and secure delegation is unheard of on the XMPP network today. Because the current situation is clearly sub-optimal, this document defines a framework for both authenticated federation and secure delegation in XMPP.
In essence, we need to establish an association between a domain and an XML stream: is the XMPP server to which a client or peer server connects "allowed" to accept stanzas for or send stanzas from a given domain? If so, we say that there is a domain name association ("DNA") for the stream.
For TLS in general, the TLS client has some expectations about the identity of the TLS server (in the language of the "CertID" specification [RFC6125], the TLS client has a "reference identity"), and then checks some material presented by the TLS server (the "presented identity" within the server certificate) to verify that its expectations have been met. In XMPP, Server Dialback follows a similar model, except that the verification material takes the form of a token instead of a certificate. The DNS-Based Authentication of Named Entities protocol [DANE], at least in some of its modes, adds another kind of verification material: not the presented identity within a PKIX certificate, but a complete certificate or hash thereof. And other kinds of verification material could be envisioned (e.g., OpenPGP keys, Kerberos tickets, OAuth tokens), although they are not considered here.
No matter what kind of verification material is used, an XMPP client or peer server that wishes to verify a domain name association needs a way to obtain the verification material it will refer to when establishing the association. For instance, when a server presents a PKIX certificate during TLS negotiation, the connecting client or peer server has traditionally obtained its verification material out of band or via configuration from a certification authority (i.e., in the form of a root certificate contained in a certificate bundle). In the Server Dialback protocol, the verification material is a token that is obtained over XMPP itself. In DANE, the verification material is obtained from the Domain Name System. In the PKIX Over Secure HTTP ("POSH") method described in an accompanying specification, the verification material is obtained over secure HTTP. And other methods for obtaining verification material could be envisioned (e.g., IPsec), although they are not considered here.
Furthermore, the matching rules for checking the verification material will depend on the nature of that material; for example, [RFC6120] defines a profile of the rules from the "CertID" specification [RFC6125], Server Dialback [XEP-0220] typically performs a character-for-character comparison of tokens, DANE might compare the SubjectPublicKeyInfo data or the full certificate, and so on.
Finally, given the relationship between XMPP and the DNS (XMPP services are usually identified by domain name, not IP address), it is important to make it clear whether a given verification method can (or must) be used only with secure DNS or also with insecure DNS.
Putting these pieces together, we define a "DNA prooftype" as follows.
The following sections outline several prooftypes that are used, or could be used, in XMPP; detailed definitions are provided in separate specifications.
Note: So far, our definition of a prooftype does not include the exact protocol mechanism that is used to assert a domain name; this is explained further under Section 6.
The PKI prooftype is a DNA proof that follows the rules from [RFC6120]: that is, the verification materials consist of a PKIX certificate that is checked according to a profile of the matching rules from [RFC6125], the client's verification materials are obtained out of band in the form of a trusted root, and secure DNS is not necessary.
In the DANE prooftype, the verification materials consist of a PKIX certificate that is compared as an exact match or a hash of either the SubjectPublicKeyInfo or the full certificate, and the verification materials are obtained via secure DNS. See the accompanying [XMPP-DANE] spec for complete discussion and examples.
POSH stands for PKIX Over Secure HTTP: the verification materials consist of a PKIX certificate, it is obtained by retrieving it over HTTPS at a well-known URI [RFC5785], the certificate is checked according to the rules from [RFC6120] and [RFC6125], and secure DNS is not necessary since the HTTPS retrieval mechanism relies on the chain of trust from the public key infrastructure. See the accompanying [XMPP-POSH] spec for complete discussion and examples.
The Dialback Keys prooftype formalizes the existing Server Dialback protocol: the verification materials consist of a token obtained over XMPP, the token is checked by the authoritative server for a given domain using implementation-specific methods such as character-by-character comparison, and secure DNS is needed in order to place significant trust in such tokens, although it is known that at the time of this writing many domains use Dialback Keys even in the absence of secure DNS.
An assertion is a server's statement that an XML stream is to be associated with the asserted domain.
During TLS negotiation, an XMPP server acting as a TLS server sends its certificate to the connecting client or peer server acting as a TLS client. This certificate is interpreted as an assertion of the server's identity.
During SASL negotiation after TLS negotiation, an XMPP server acting as a TLS server can include an authorization identity; such an authzid is an assertion of the server's identity.
When two servers use the Server Dialback protocol [XEP-0220], the originating server asserts its identity by sending a <db:result/> element to the receiving server, where the 'from' attribute specifies the domain name being asserted by the originating server.
Note: Although historically the <db:result/> element has contained a dialback key as XML character data, the <db:result/> element can also be used without dialback keys as a mere assertion; this usage is sometimes colloquially referred to as "dialback without dialback".
XML streams include 'to' and 'from' attributes. However, these are not assertions of identity, and are merely early indications of the identity that a client or server will later assert during TLS negotiation, SASL negotiation, or Server Dialback negotiation.
Although domain name associations are closely tied to delegation in some scenarios, delegation is irrelevant when the source domain is exactly the same as the hostname of the XMPP service, as is often the case with single-domain services. There are two methods for secure delegation: DNSSEC (see the [XMPP-DANE] spec) and HTTPS Redirect (see the [XMPP-POSH] spec).
This document supplements but does not supersede the security considerations provided in [RFC6120] and [RFC6125].
This document has no actions for the IANA.
| [RFC3920] | Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004. |
| [XEP-0238] | Saint-Andre, P., "XMPP Protocol Flows for Inter-Domain Federation", XSF XEP 0238, March 2008. |