Requirements for End-to-End Encryption in the Extensible Messaging and Presence Protocol (XMPP)
Cisco
psaintan@cisco.com
Applications
XMPP
Internet-Draft
This document describes requirements for end-to-end encryption in the Extensible Messaging and Presence Protocol (XMPP).
End-to-end or "e2e" encryption of traffic sent over the Extensible Messaging and Presence Protocol (XMPP) is a desirable goal. Since 1999, the Jabber/XMPP developer community has experimented with several such technologies, including OpenPGP , S/MIME , and encrypted sessions . More recently, the community has explored the possibility of using Transport Layer Security as the base technology for e2e encryption. In order to provide a foundation for deciding on a sustainable approach to e2e encryption, this document specifies a set of requirements that the ideal technology would meet.
The preferred venue for discussion of this document is the xmpp@ietf.org mailing list; visit for further information.
Much of the text in this document has been copied from .
There are several different kinds of communications between XMPP entitites:
One-to-one communication sessions between two entities, where each entity is online and available during the life of the session so that all of the communications occur in real time.
One-to-one messages that are not transferred in real time but that instead are stored when sent and then forwarded when the recipient is next online; these are usually called "offline messages" as described in .
One-to-many information broadcast, such as undirected presence stanzas sent from one user to many contacts as described in and data syndication as described in .
Many-to-many communication sessions among more than two entities, such as a text conference in a chatroom as described in .
Ideally, any technology for end-to-end encryption in XMPP could be extended to cover all the scenarios above. However, both one-to-many broadcast and many-to-many sessions are deemed out-of-scope for this document, and this document puts more weight on one-to-one communication sessions (the typical scenario for XMPP) than on offline messages.
XMPP technologies are typically deployed using a client-server architecture. As a result, XMPP endpoints (often but not always controlled by human users) need to communicate through one or more servers. For example, the user juliet@capulet.lit connects to the capulet.lit server and the user romeo@montague.lit connects to the montague.lit server, but in order for Juliet to send a message to Romeo the message will be routed over her client-to-server connection with capulet.lit, over a server-to-server connection between capulet.lit and montague.lit, and over Romeo's client-to-server connection with montague.lit. Although requires support for Transport Layer Security to make it possible to encrypt all of these connections, when XMPP is deployed any of these connections might be unencrypted. Furthermore, even if the server-to-server connection is encrypted and both of the client-to-server connections are encrypted, the message would still be in the clear while processed by both the capulet.lit and montague.lit servers.
In this specification we primarily address communications security ("commsec") between two parties, especially confidentiality, data integrity, and peer entity authentication. Communications security can be subject to a variety of attacks, which divides into passive and active categories. In a passive attack, information is leaked (e.g., a passive attacker could read all of the messages that Juliet sends to Romeo). In an active attack, the attacker can add, modify, or delete messages between the parties, thus disrupting communications.
Traditionally, it seems that XMPP users have been concerned more about passive attacks (such as eavesdropping) than about active attacks (such as man-in-the-middle), perhaps because they have thought that their communications are "just chat", because they have had no expectation that endpoints could be authenticated, or because they have believed that hijacked communications would be detected socially (e.g., because the other party did not have an authentic "voice" in a text conversation). However, both forms of attack are of concern in this protocol.
In particular, we consider the following types of attacks and attackers:
One type of passive attack might involve monitoring all the conversations of a given party. To help prevent this, it is important for the party to ensure that its connection with its server is protected using TLS. However, in this case the eavesdropper could monitor outbound traffic from the party's server, either to other connected clients or to other servers, since that traffic might be unencrypted. In addition, the eavesdropper could attack the party's server so that it gains access to all traffic within the server, or masquerade as the party's server so that the party is fooled into connecting to the attacker rather than directly to the party's server.
Another type of passive attack might involve monitoring of a single conversation between two particular parties. In this case the eavesdropper could monitor communications over the server-to-server connection between the parties' servers, or over the client-to-server connection between either party and that party's server.
One type of active attack would involve modification of the XML stanzas used to advertise support for the protocol "building blocks" that make it possible to negotiate a secure session; as a result, other parties would be led to believe that the party does not have the ability to negotate a secure session and therefore would not attempt such a negotiation.
Another type of active attack would involve modification or outright deletion of the XML stanzas used to negotiate a secure session (such as those described in this document), with the result that the parties would think the negotiation has failed for legitimate reasons such as incompatibilities between the parties' clients.
A more sophisticated active attack would involve a cryptanalytic attack on the keying material or other credentials used to establish trust between the parties, such as an ephemeral password exchanged during an initial certificate exchange if Secure Remote Password is used.
Other attacks are possible, and the foregoing list is best considered incomplete at this time.
This document stipulates the following security requirements for end-to-end encryption of XMPP communications:
The one-to-one XML stanzas exchanged between two entities (conventionally, "Alice" and "Bob") must not be understandable to any other entity that might intercept the communications. The encrypted stanzas should be understood by an intermediate server only to the extent required to route them.
Alice and Bob must be sure that no other entity can change the content of the XML stanzas they exchange, or remove or insert stanzas undetected.
Alice or Bob must be able to identify and reject any communications that are copies of their previous communications resent by another entity.
The encrypted communication should not be revealed even if long-lived keys are compromised in the future (e.g., Steve steals Bob's computer). For long-lived sessions it must be possible to periodically change the decryption keys.
The protocol must not force the use of any public key infrastructure (PKI), certification authority, web of trust, or any other trust model that is external to the trust established between Alice and Bob. However, if external authentication or trust models are available then Alice and Bob should be able to use such trust models to enhance any trust that exists between them.
Each party to a conversation must know that the other party is who they want to communicate with (Alice must be able to know that Bob really is Bob, and vice versa). Note: Authentication can be as simple as Alice confirming that Bob is the same Bob that she communicated with yesterday or that she talked to on the telephone. The reliable association between an entity and its public keys is "identification" and therefore beyond the scope of this document.
No other entity should be able to identify Alice or Bob. The JabberIDs they use to route their stanzas are unavoidably vulnerable to interception. Therefore, even if Alice and Bob protect their identities by using different JabberIDs for each session, it must be possible for their user agents to authenticate them transparently, without any other entity identifying them via an active ("man-in-the-middle") attack, or even linking them to their previous sessions. If that is not possible because Alice and Bob choose to authenticate using public keys instead of retained shared secrets, then the public keys must not be revealed to other entities using a passive attack. Bob should also be able to choose between protecting either his public key or Alice's public key from disclosure through an active attack.
The protocol should provide more than one difficult challenge that has to be overcome before an attack can succeed (for example, by generating encryption keys using as many shared secrets as possible, such as retained secrets or optional passwords).
The protocol must be upgradable so that, if a vulnerability is discovered, a new version can fix it. Alice must tell Bob which versions of the protocol she is prepared to support.
In addition to the foregoing security profile, this document also stipulates the following application-specific requirements:
The solution must be generally applicable to the full content of any XML stanza type (<message/>, <presence/>, and <iq/>) sent between two entities. It is deemed acceptable if the solution does not apply to many-to-many stanzas (e.g., groupchat messages sent within the context of multi-user chat) or one-to-many stanzas (e.g., presence "broadcasts" and publish-subscribe notifications); end-to-end encryption of such stanzas might require separate solutions.
The only good security technology is an implemented security technology. The solution should be one that XMPP client developers can implement in a relatively straightforward and interoperable fashion. Ideally the solution would reuse existing technologies so that client developers can also reuse existing libraries, as they already do for security features such as Transport Layer Security and the Simple Authentication and Security Layer .
The requirement of usability takes implementability one step further by stipulating that the solution should be one that organizations can deploy and humans can use with the ease-of-use of, say, "https:" URLs. Experience has shown that solutions requiring a full public key infrastructure do not get widely deployed and that solutions requiring any user action are not widely used. If, however, Alice and/or Bob are prepared to verify the integrity of their copies of each other's keys (thus enabling them to discover targeted active attacks or even the mass surveilance of a population), then the actions necessary for them to achieve that should be minimal (requiring no more effort than a one-time out-of-band verification of a string of up to 8 alphanumeric characters).
Cryptographic operations are highly CPU intensive, particularly public key and Diffie-Hellman operations. Cryptographic data structures can be relatively large, especially public keys and certificates. Network round trips can introduce unacceptable delays, especially over high-latency wireless connections. The solution must perform efficiently even when CPU and network bandwidth are constrained. The number of stanzas required for negotiation of encrypted communication should be minimized.
The solution must be compatible with a variety of existing and future cryptographic algorithms and identity certification schemes, including and . The protocol must also be able to evolve to correct the weaknesses that are inevitably discovered once any cryptographic protocol is in widespread use.
It should be possible to encrypt one-to-one communications that are stored for later delivery (so-called "offline messages") and still benefit from Perfect Forward Secrecy (with a slightly longer period of vulnerability than if both parties were online simultaneously). However, any vulnerabilities introduced into the solution in order to enable such offline communications must not make real-time communications more vulnerable.
Security issues are discussed throughout this document.
This document has no actions for the IANA.
Encrypted Session Negotiation
ian.paterson@clientside.co.uk
dizzyd@jabber.org
Multi-User Chat
Best Practices for Handling Offline Messages
OpenPGP Message Format
This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.</t><t> OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS TRACK]
Publish-Subscribe
ralphm@ik.nu
Guidelines for Writing RFC Text on Security Considerations
All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Simple Authentication and Security Layer (SASL)
<p>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.</p><p> 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.</p><p> This document obsoletes RFC 2222. [STANDARDS TRACK]</p>
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]
Using the Secure Remote Password (SRP) Protocol for TLS Authentication
This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. 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]
Requirements for Encrypted Sessions
ian.paterson@clientside.co.uk
Extensible Messaging and Presence Protocol (XMPP): Core
This document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements for the purpose of exchanging structured information in close to real time between any two or more network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions. This document also specifies the format for XMPP addresses, which are fully internationalizable.This document obsoletes RFC 3920.
Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
This document describes extensions to the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with RFC 2779. This document obseletes RFC 3921.
Current Jabber OpenPGP Usage
temas@jabber.org
End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
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 methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP).