Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)
ietf@stpeter.im
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.
The Extensible Messaging and Presence Protocol (XMPP) (along with its precursor, the so-called "Jabber protocol") has used Transport Layer Security (TLS) (along with its precursor, Secure Sockets Layer or SSL) since 1999. Both and its predecessor provided recommendations regarding the use of TLS in XMPP. In order to address the evolving threat model on the Internet today (see, for example, ), this document provides stronger recommendations (see also ). This document updates .
Various security-related terms are to be understood in the sense defined in .
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 .
The discussion venue for this document is the mailing list of the XMPP Working Group, for which archives and subscription information can be found at . Discussion might also occur on the mailing list of the UTA Working Group, for which archives and subscription information can be found at .
Support for TLS (specifically, the XMPP profile of STARTTLS) is mandatory for XMPP implementations, as already specified in and its predecessor .
If the server to which an XMPP client or peer server connects does not offer a stream feature of <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> (thus indicating that it is an XMPP 1.0 server that supports TLS), the initiating entity MUST NOT proceed with the stream negotiation and MUST instead abort the connection attempt. Although XMPP servers SHOULD include the <required/> child element to indicate that negotiation of TLS is mandatory, clients and peer servers MUST NOT depend on receiving the <required/> flag in determining whether TLS will be enforced for the stream.
It is important both to stop using old, less secure versions of SSL/TLS and to start using modern, more secure versions. Therefore:
XMPP implementations MUST NOT negotiate SSL version 2.
Rationale: SSLv2 has serious security vulnerabilities .
XMPP implementations MAY negotiate SSL version 3.
Rationale: SSLv3 was an improvement over SSLv2 and plugged some significant security holes, but did not support strong cipher suites.
XMPP implementations MAY negotiate TLS version 1.0 .
Rationale: TLS 1.0 (published in 1999) includes a way to downgrade the connection to SSLv3 and does not support more modern, strong cipher suites.
XMPP implementations MAY negotiate TLS version 1.1 .
Rationale: TLS 1.1 (published in 2006) prevents downgrade attacks to SSL, but does not support certain stronger cipher suites.
XMPP implementations MUST support, and prefer to negotiate, TLS version 1.2 .
Rationale: Several stronger cipher suites are available only with TLS 1.2 (published in 2008).
As of the date of this writing, the latest version of TLS is 1.2. When TLS is updated to a newer version, this document will be updated to recommend support for the latest version. If this document is not updated in a timely manner, it can be assumed that support for the latest version of TLS is recommended.
NOTE: Currently this document provides its own recommendations regarding TLS cipher suites. However, eventually it will be updated to instead reference .
It is important both to stop using old, insecure cipher suites and to start using modern, more secure cipher suites. Therefore:
XMPP implementations MUST NOT negotiate the NULL cipher suites.
Rationale: The NULL cipher suites offer no encryption whatsoever and thus are completely insecure.
XMPP implementations MUST NOT negotiate RC4 cipher suites
Rationale: The RC4 stream cipher has a variety of cryptographic weaknesses, as documented in .
XMPP implementations MUST NOT negotiate cipher suites offering only so-called "export-level" encryption (including algorithms with 40 bits or 56 bits of security).
Rationale: These cipher suites are deliberately "dumbed down" and are very easy to break.
XMPP implementations MUST NOT negotiate cipher suites that use algorithms offering less than 128 bits of security (even if they advertise more bits, such as the 168-bit 3DES cipher suites).
Rationale: Although these cipher suites are not actively subject to breakage, their useful life is short enough that stronger cipher suites are desirable.
XMPP implementations SHOULD prefer cipher suites that use algorithms with at least 256 bits of security.
Rationale: The useful life of such cipher suites is probably at least 3-5 years.
XMPP implementations MUST support, and SHOULD prefer to negotiate, cipher suites offering authentication, such as the "AES-GCM" family.
Rationale: Authenticated connections are better than unauthenticated connections (although, as explained under , unauthenticated connections are better than nothing).
XMPP implementations MUST support, and SHOULD prefer to negotiate, cipher suites offering forward secrecy, such as those in the "EDH", "DHE", and "ECDHE" families.
Rationale: Forward secrecy (sometimes called "perfect forward secrecy") prevents the recovery of information that was encrypted with older session keys, thus limiting the amount of time during which attacks can be successful.
Given the foregoing considerations, implementation of the following cipher suites is RECOMMENDED:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Unfortunately, those cipher suites are supported only in TLS 1.2. A future version of this document might recommend cipher suites for earlier versions of TLS.
Because Diffie-Hellman keys of 1024 bits are estimated to be roughly equivalent to 80-bit symmetric keys, it is better to use longer keys for the "DH" family of cipher suites. Unfortunately, some existing software cannot handle (or cannot easily handle) key lengths greater than 1024 bits. The most common workaround for these systems is to prefer the "ECDHE" family of cipher suites instead of the "DH" family, then use longer keys. Key lengths of at least 2048 bits are RECOMMENDED, since they are estimated to be roughly equivalent to 112-bit symmetric keys and might be sufficient for at least the next 10 years.
Note: The foregoing recommendations are preliminary and will likely be corrected and enhanced in a future version of this document.
Both the core XMPP specification and the "CertID" specification provide recommendations and requirements for certificate checking. This document does not supersede those specifications.
The core XMPP specification states a preference for the use of TLS for encryption along with SASL for authentication. In general, it is preferable for a connection to be authenticated, including proper identity checking as defined by the "CertID" specification . However, given the pervasiveness of passive eavesdropping, even an unauthenticated connection might be better than an unencrypted connection (this is similar to the "better than nothing security" approach for IPsec ). In particular, given current deployment challenges for authenticated connections between XMPP servers (see for details), it might be reasonable for XMPP server implementations to accept unauthenticated connections when the Server Dialback protocol is used for weak identity verification; this will at least enable encryption of server-to-server connections. Unauthenticated connections include connections negotiated using anonymous Diffie-Hellman algorithms or using self-signed certificates, among other scenarios.
Although there is no harm in supporting the TLS Server Name Indication (SNI) extension , 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 .
If TLS session resumption is used (e.g., in concert with the XMPP Stream Management extension ), care ought to be taken to do so safely. In particular, the resumption information (either session IDs or session tickets ) needs to be authenticated and encrypted to prevent modification or eavesdropping by an attacker.
Use of session IDs is RECOMMENDED instead of session tickets , since session tickets mandate a relatively small key size and a relatively weak cipher suite (AES_128_CBC_SHA256) that does not support forward secrecy.
XMPP is not generally subject to attacks based on TLS-layer compression (e.g., the "CRIME" attack), since it is not typically used to communicate static strings of the kind communicated over HTTP, such as "cookies" . However, because XMPP also supports an application-layer compression technology , implementers might wish to prefer XMPP compression over TLS compression in order to avoid any potential security issues with TLS-layer compression. (See for related discussion.)
It is RECOMMENDED that XMPP clients provide ways for end users (and that XMPP servers provide ways for administators) to complete the following tasks:
Determine if a client-to-server or server-to-server connection is encrypted and authenticated.
Determine the version of TLS used for a client-to-server or server-to-server connection.
Inspect the certificate offered by an XMPP server.
Determine the cipher suite used to encrypt a connection.
Be warned if the certificate changes for a given server.
Some governments enforce legislation prohibiting the export of strong cryptographic technologies. Nothing in this document ought to be taken as advice to violate such prohibitions.
This document requests no actions of the IANA.
As noted in "A Threat Model for Pervasive Passive Surveillance" ), 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 (sending 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, along with actions currently being taken to improve the security of the XMPP network, do not assume widespread compromise of XMPP servers and clients or their underlying operating systems or hardware. Thus it is assumed that ubiquitous use of per-hop TLS channel encryption and more significant deployment of end-to-end object encryption technologies will serve to protect XMPP communications to a measurable degree, compared to the alternatives.
Key words for use in RFCs to Indicate Requirement Levels
Harvard University
1350 Mass. Ave.
Cambridge
MA 02138
- +1 617 495 3864
sob@harvard.edu
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.
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.
Transport Layer Security (TLS) Session Resumption without Server-Side State
This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]
The Transport Layer Security (TLS) Protocol Version 1.2
This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]
Extensible Messaging and Presence Protocol (XMPP): Core
The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]
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)
Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]
Prohibiting Secure Sockets Layer (SSL) Version 2.0
This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0. This document updates the backward compatibility sections found in the Transport Layer Security (TLS). [STANDARDS-TRACK]
Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)
This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how "prooftypes" can establish a strong association between a domain name and an XML stream. Second, it describes how to securely delegate a source domain to a derived domain, which is especially important in virtual hosting environments.
Prohibiting RC4 Cipher Suites
This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections.
Recommendations for Secure Use of TLS and DTLS
Over the last few years there have been several serious attacks on TLS, including attacks on its most commonly used ciphers and modes of operation. This document offers recommendations on securely using the TLS and DTLS protocols, given existing standards and implementations.
A Threat Model for Pervasive Passive Surveillance
This document elaborates a threat model for pervasive surveillance. We assume an adversary with an interest in indiscriminate eavesdropping that can passively observe network traffic at every layer at every point in the network between the endpoints. It is intended to demonstrate to protocol designers and implementors the observability and inferability of information and metainformation transported over their respective protocols, to assist in the evaluation of the performance of these protocols and the effectiveness of their protection mechanisms under pervasive passive surveillance.
The TLS Protocol Version 1.0
Certicom
tdierks@certicom.com
Certicom
callen@certicom.com
This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
Extensible Messaging and Presence Protocol (XMPP): Core
Jabber Software Foundation
stpeter@jabber.org
Applications
XMPP Working Group
RFC
Request for Comments
I-D
Internet-Draft
XMPP
Extensible Messaging and Presence Protocol
Jabber
IM
Instant Messaging
Presence
XML
Extensible Markup Language
This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.
The Transport Layer Security (TLS) Protocol Version 1.1
This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]
Simple Authentication and Security Layer (SASL)
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.</t><t> This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.</t><t> This document obsoletes RFC 2222. [STANDARDS-TRACK]
Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No changes to IKEv2 bits-on-the-wire are required, but Peer Authorization Database (PAD) and Security Policy Database (SPD) extensions are specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better-Than-Nothing Security). [STANDARDS-TRACK]
Transport Layer Security (TLS) Extensions: Extension Definitions
This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]
The Secure Sockets Layer (SSL) Protocol Version 3.0
This document is published as a historical record of the SSL 3.0 protocol. The original Abstract follows.</t><t> This document specifies version 3.0 of the Secure Sockets Layer (SSL 3.0) protocol, a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. This document defines a Historic Document for the Internet community.
HTTP State Management Mechanism
This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]
Stream Compression
jhildebr@cisco.com
stpeter@jabber.org
Stream Management
justin@affinix.com
stpeter@jabber.org
jhildebr@cisco.com
fabio.forno@gmail.com
dave.cridland@isode.com
mwild1@gmail.com
Server Dialback
jer@jabber.org
stpeter@jabber.org
Thanks to the following individuals for their input: Thijs Alkemade, Dave Cridland, Philipp Hancke, Olle Johansson, Steve Kille, Tobias Markmann, Matt Miller, and Rene Treffer.