--- 1/draft-ietf-uta-xmpp-06.txt 2015-04-23 11:14:53.180150776 -0700 +++ 2/draft-ietf-uta-xmpp-07.txt 2015-04-23 11:14:53.200151268 -0700 @@ -1,20 +1,20 @@ Network Working Group P. Saint-Andre Internet-Draft &yet Updates: 6120 (if approved) T. Alkemade Intended status: Standards Track -Expires: October 16, 2015 April 14, 2015 +Expires: October 25, 2015 April 23, 2015 Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) - draft-ietf-uta-xmpp-06 + draft-ietf-uta-xmpp-07 Abstract This document provides recommendations for the use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP). This document updates RFC 6120. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -23,21 +23,21 @@ 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 October 16, 2015. + This Internet-Draft will expire on October 25, 2015. Copyright Notice Copyright (c) 2015 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 @@ -48,31 +48,31 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Support for TLS . . . . . . . . . . . . . . . . . . . . . 3 3.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 3 3.3. Session Resumption . . . . . . . . . . . . . . . . . . . 3 - 3.4. Authenticated Connections . . . . . . . . . . . . . . . . 3 - 3.5. Server Name Indication . . . . . . . . . . . . . . . . . 4 + 3.4. Authenticated Connections . . . . . . . . . . . . . . . . 4 + 3.5. Server Name Indication . . . . . . . . . . . . . . . . . 5 3.6. Human Factors . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 - 6.2. Informative References . . . . . . . . . . . . . . . . . 6 + 6.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 8 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] (along with its precursor, the so-called "Jabber protocol") has used Transport Layer Security (TLS) [RFC5246] (along with its precursor, Secure Sockets Layer or SSL) since 1999. Both [RFC6120] and its predecessor [RFC3920] provided recommendations regarding the use of TLS in XMPP. In order to address the evolving threat model on the Internet today, this document provides stronger recommendations. @@ -128,68 +128,81 @@ 3.2. Compression XMPP supports an application-layer compression technology [XEP-0138]. Although this XMPP extension might have slightly stronger security properties than TLS-layer compression (since it is enabled after SASL authentication, as described in [XEP-0170]), this document neither encourages nor discourages use of XMPP-layer compression. 3.3. Session Resumption - In XMPP, TLS session resumption can be used in concert with the XMPP - Stream Management extension; see [XEP-0198] for further details. + To improve the reliability of communications over XMPP, it is common + practice for clients and servers to implement the stream management + extension [XEP-0198]. Although that specification includes a method + for resumption of XMPP streams at the application layer, also using + session resumption at the TLS layer further optimizes the overall + process of resuming an XMPP session (see [XEP-0198] for detailed + information). Whether or not XEP-0198 is used for application-layer + session resumption, implementations MUST follow the recommendations + provided in [I-D.ietf-uta-tls-bcp] regarding TLS-layer session + resumption. 3.4. Authenticated Connections Both the core XMPP specification [RFC6120] and the "CertID" specification [RFC6125] provide recommendations and requirements for certificate validation in the context of authenticated connections. This document does not supersede those specifications (e.g., it does not modify the recommendations in [RFC6120] regarding the Subject Alternative Names or other certificate details that need to be supported for authentication of XMPP connections using PKIX certificates). Wherever possible, it is best to prefer authenticated connections (along with SASL [RFC4422]), as already stated in the core XMPP - specification [RFC6120]. In particular, clients MUST authenticate - servers and servers MUST authenticate clients. + specification [RFC6120]. In particular: + + o Clients MUST authenticate servers. + + o Servers MUST authenticate clients. + + o Servers SHOULD authenticate other servers. This document does not mandate that servers need to authenticate peer - servers, although such authentication is strongly preferred and - servers SHOULD authenticate each other. Unfortunately, in multi- - tenanted environments it can be extremely difficult to obtain and - deploy PKIX certificates with the proper Subject Alternative Names - (see [I-D.ietf-xmpp-dna] and [I-D.ietf-xmpp-posh] for details). To - overcome that difficulty, the Domain Name Associations (DNA) - specification [I-D.ietf-xmpp-dna] describes a framework for XMPP - server authentication methods, which include not only PKIX but also - DNS-Based Authentication of Named Entities (DANE) as defined in - [I-D.ietf-dane-srv] and PKIX over Secure HTTP (POSH) as defined in - [I-D.ietf-xmpp-posh]. These methods can provide a basis for server - identity verification when appropriate PKIX certificates cannot be - obtained and deployed. + servers, although such authentication is strongly preferred. + Unfortunately, in multi-tenanted environments it can be extremely + difficult to obtain and deploy PKIX certificates with the proper + Subject Alternative Names (see [I-D.ietf-xmpp-dna] and + [I-D.ietf-xmpp-posh] for details). To overcome that difficulty, the + Domain Name Associations (DNA) specification [I-D.ietf-xmpp-dna] + describes a framework for XMPP server authentication methods, which + include not only PKIX but also DNS-Based Authentication of Named + Entities (DANE) as defined in [I-D.ietf-dane-srv] and PKIX over + Secure HTTP (POSH) as defined in [I-D.ietf-xmpp-posh]. These methods + can provide a basis for server identity verification when appropriate + PKIX certificates cannot be obtained and deployed. - Given the pervasiveness of eavesdropping [RFC7258], even an - unauthenticated connection might be better than an unencrypted + Given the pervasiveness of eavesdropping [RFC7258], even an encrypted + but unauthenticated connection might be better than an unencrypted connection in these scenarios (this is similar to the "better than - nothing security" approach for IPsec [RFC5386]). Unauthenticated - connections include connections negotiated using anonymous Diffie- - Hellman mechanisms or using self-signed certificates, among others. - In particular for XMPP server-to-server interactions, it can be - reasonable for XMPP server implementations to accept unauthenticated - but encrypted connections when Server Dialback keys [XEP-0220] are - used; such keys on their own provide only weak identity verification - (made stronger through the use of DNSSEC [RFC4033]), but this at - least enables encryption of server-to-server connections. The DNA - prooftypes described above are intended to mitigate the residual need - for unauthenticated connections in these scenarios. + nothing security" approach for IPsec [RFC5386]). Encrypted but + unauthenticated connections include connections negotiated using + anonymous Diffie-Hellman mechanisms or using self-signed + certificates, among others. In particular for XMPP server-to-server + interactions, it can be reasonable for XMPP server implementations to + accept encrypted but unauthenticated connections when Server Dialback + keys [XEP-0220] are used; such keys on their own provide only weak + identity verification (made stronger through the use of DNSSEC + [RFC4033]), but this at least enables encryption of server-to-server + connections. The DNA prooftypes described above are intended to + mitigate the residual need for encrypted but unauthenticated + connections in these scenarios. 3.5. Server Name Indication Although there is no harm in supporting the TLS Server Name Indication (SNI) extension [RFC6066], this is not necessary since the same function is served in XMPP by the 'to' address of the initial stream header as explained in Section 4.7.2 of [RFC6120]. 3.6. Human Factors @@ -213,28 +226,29 @@ o Be warned if the certificate changes for a given server. 4. IANA Considerations This document requests no actions of the IANA. 5. Security Considerations The use of TLS can help limit the information available for - correlation to the network and transport layer headers as opposed to - the application layer. As typically deployed, XMPP technologies do - not leave application-layer routing data (such as XMPP 'to' and - 'from' addresses) at rest on intermediate systems, since there is - only one hop between any two given XMPP servers. As a result, - encrypting all hops (sender's client to sender's server, sender's - server to recipient's server, recipient's server to recipient's - client) can help to limit the amount of "metadata" that might leak. + correlation between the XMPP application layer and the underlying + network and transport layers. As typically deployed, XMPP + technologies do not leave application-layer routing data (such as + XMPP 'to' and 'from' addresses) at rest on intermediate systems, + since there is only one hop between any two given XMPP servers. As a + result, encrypting all hops (sender's client to sender's server, + sender's server to recipient's server, recipient's server to + recipient's client) can help to limit the amount of "metadata" that + might leak. It is possible that XMPP servers themselves might be compromised. In that case, per-hop encryption would not protect XMPP communications, and even end-to-end encryption of (parts of) XMPP stanza payloads would leave addressing information and XMPP roster data in the clear. By the same token, it is possible that XMPP clients (or the end-user devices on which such clients are installed) could also be compromised, leaving users utterly at the mercy of an adversary. This document and related actions to strengthen the security of the @@ -276,22 +290,22 @@ 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)", RFC 6125, March 2011. 6.2. Informative References [I-D.ietf-dane-srv] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- Based Authentication of Named Entities (DANE) TLSA records - with SRV and MX records.", draft-ietf-dane-srv-12 (work in - progress), March 2015. + with SRV and MX records.", draft-ietf-dane-srv-13 (work in + progress), April 2015. [I-D.ietf-stox-im] Saint-Andre, P., Houri, A., and J. Hildebrand, "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging", draft-ietf-stox-im-13 (work in progress), March 2015. [I-D.ietf-xmpp-dna] Saint-Andre, P. and M. Miller, "Domain Name Associations @@ -359,20 +373,23 @@ Appendix B. Acknowledgements The authors would like to thank the following individuals for their input: Dave Cridland, Philipp Hancke, Olle Johansson, Steve Kille, Tobias Markmann, Matt Miller, and Rene Treffer. Roni Even caught several important issues in his review on behalf of the General Area Review Team. + Ben Campbell, Spencer Dawkins, and Barry Leiba provided helpful input + during IESG review. + Thanks to Leif Johansson and Orit Levin as chairs of the UTA WG, Ben Campbell and Joe Hildebrand as chairs of the XMPP WG, and Stephen Farrell as the sponsoring Area Director. Authors' Addresses Peter Saint-Andre &yet Email: peter@andyet.com