This document describes requirements for end-to-end encryption in the Extensible Messaging and Presence Protocol (XMPP).
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
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.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright (c) 2010 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 BSD License.
3. Threat Analysis
4. Security Requirements
5. Application Requirements
6. Security Considerations
7. IANA Considerations
9. Informative References
§ Author's Address
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 [XMPP‑PGP] (Muldowney, T., “Current Jabber OpenPGP Usage,” November 2006.), S/MIME [XMPP‑SMIME] (Saint-Andre, P., “End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP),” October 2004.), and encrypted sessions [XMPP‑SESS] (Paterson, I., Saint-Andre, P., and D. Smith, “Encrypted Session Negotiation,” May 2007.). More recently, the community has explored the possibility of using Transport Layer Security [TLS] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) 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 email@example.com mailing list; visit https://www.ietf.org/mailman/listinfo/xmpp for further information.
There are several different forms of communication between XMPP entitites:
Ideally, any technology for end-to-end encryption in XMPP could be extended to cover all of the foregoing communication methods. 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 firstname.lastname@example.org connects to the capulet.lit server and the user email@example.com 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 [XMPP‑CORE] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” March 2010.) requires support for Transport Layer Security [TLS] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) 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 [RFC3552] (Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations,” July 2003.) 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:
Other attacks are possible, and the foregoing list is best considered incomplete at this time.
Although an attacker might be able to launch an attack once, it is possible that the attacker cannot launch an attack multiple times. Given that the communication pattern in XMPP is typically to hold multiple different conversations that are separated in time, many end users might consider it acceptable to engage in a "leap of faith" the first time two parties negotiate a secure communication session, then check to make sure that the credentials are the same in subsequent communication sessions.
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 absolutely required to route them (i.e., the 'from' and 'to' addresses). However, note that some intermediaries might require or desire access to more detailed information in order to route XMPP stanzas (e.g., data about confidentiality levels or delivery semantics).
- 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.
- Replay Protection:
- Alice or Bob must be able to identify and reject any communications that are copies of their previous communications resent by another entity.
- Perfect Forward Secrecy:
- 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 enable Alice and Bob to establish trust in each other's credentials either within the protocol or using outside channels. The supported credential types might include self-signed certificates, pre-shared keys, and shared secrets, either as stable credentials or as mechanisms for bootstrapping trust in ephemeral keying material. 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 should be able to determine that the other party is who they want to communicate with (Alice must be able to know that Bob really is Bob, or at least is an entity that possesses a credential to which only Bob is expected to have access). Authentication can be as simple as Alice confirming that Bob is the same Bob that she communicated with yesterday or that she talked with on the telephone (identity coherence across time). The reliable association between an entity and its public keys is "identification" and therefore beyond the scope of this document.
- Identity Protection:
- No entity other than the intermediate servers and the parties themselves should be able to identify Alice or Bob. Naturally, 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 have multiple lines of defense and should force an attacker to surmount more than one difficult challenge 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. Upgradability refers to the protocol as a whole as well as to components thereof (e.g., cryptographic hashing algorithms).
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 [TLS] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) and the Simple Authentication and Security Layer [SASL] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.).
- 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 [X509] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) and [OpenPGP] (Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” November 2007.). The protocol must also be able to evolve to correct the weaknesses that are inevitably discovered once any cryptographic protocol is in widespread use.
- Offline messages:
- 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.
Much of the text in this document has been copied from [XEP‑0210] (Paterson, I., “Requirements for Encrypted Sessions,” May 2007.). The editor wishes to thank Ian Paterson for his work on that document and the ESessions technology in general.
Thanks also to Bernard Aboba for his feedback.
|[MUC]||Saint-Andre, P., “Multi-User Chat,” XSF XEP 0045, July 2008.|
|[OFFLINE]||Saint-Andre, P., “Best Practices for Handling Offline Messages,” XSF XEP 0160, January 2006.|
|[OpenPGP]||Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” RFC 4880, November 2007 (TXT).|
|[PubSub]||Millard, P., Saint-Andre, P., and R. Meijer, “Publish-Subscribe,” XSF XEP 0060, September 2008.|
|[RFC3552]||Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations,” BCP 72, RFC 3552, July 2003 (TXT).|
|[SASL]||Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” RFC 4422, June 2006 (TXT).|
|[TLS]||Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT).|
|[TLS-SRP]||Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, “Using the Secure Remote Password (SRP) Protocol for TLS Authentication,” RFC 5054, November 2007 (TXT).|
|[X509]||Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” RFC 5280, May 2008 (TXT).|
|[XEP-0210]||Paterson, I., “Requirements for Encrypted Sessions,” XSF XEP 0210, May 2007.|
|[XMPP-CORE]||Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” draft-ietf-xmpp-3920bis-05 (work in progress), March 2010 (TXT).|
|[XMPP-IM]||Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” draft-ietf-xmpp-3921bis-05 (work in progress), March 2010 (TXT).|
|[XMPP-PGP]||Muldowney, T., “Current Jabber OpenPGP Usage,” XSF XEP 0027, November 2006.|
|[XMPP-SESS]||Paterson, I., Saint-Andre, P., and D. Smith, “Encrypted Session Negotiation,” XSF XEP 0116, May 2007.|
|[XMPP-SMIME]||Saint-Andre, P., “End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP),” RFC 3923, October 2004 (TXT, HTML, XML).|
|Peter Saint-Andre (editor)|