draft-ietf-xmpp-e2e-requirements-00.txt   draft-ietf-xmpp-e2e-requirements-01.txt 
XMPP P. Saint-Andre XMPP P. Saint-Andre, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational August 27, 2009 Intended status: Informational March 8, 2010
Expires: February 28, 2010 Expires: September 9, 2010
Requirements for End-to-End Encryption in the Extensible Messaging and Requirements for End-to-End Encryption in the Extensible Messaging and
Presence Protocol (XMPP) Presence Protocol (XMPP)
draft-ietf-xmpp-e2e-requirements-00 draft-ietf-xmpp-e2e-requirements-01
Abstract
This document describes requirements for end-to-end encryption in the
Extensible Messaging and Presence Protocol (XMPP).
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 28, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes requirements for end-to-end encryption in the described in the BSD License.
Extensible Messaging and Presence Protocol (XMPP).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 3
4. Security Requirements . . . . . . . . . . . . . . . . . . . . . 5 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 5
5. Application Requirements . . . . . . . . . . . . . . . . . . . 7 5. Application Requirements . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
End-to-end or "e2e" encryption of traffic sent over the Extensible End-to-end or "e2e" encryption of traffic sent over the Extensible
Messaging and Presence Protocol (XMPP) is a desirable goal. Since Messaging and Presence Protocol (XMPP) is a desirable goal. Since
1999, the Jabber/XMPP developer community has experimented with 1999, the Jabber/XMPP developer community has experimented with
several such technologies, including OpenPGP [XMPP-PGP], S/MIME several such technologies, including OpenPGP [XMPP-PGP], S/MIME
[XMPP-SMIME], and encrypted sessions [ESessions]. More recently, the [XMPP-SMIME], and encrypted sessions [XMPP-SESS]. More recently, the
community has explored the possibility of using Transport Layer community has explored the possibility of using Transport Layer
Security [TLS] as the base technology for e2e encryption. In order Security [TLS] as the base technology for e2e encryption. In order
to provide a foundation for deciding on a sustainable approach to e2e to provide a foundation for deciding on a sustainable approach to e2e
encryption, this document specifies a set of requirements that the encryption, this document specifies a set of requirements that the
ideal technology would meet. ideal technology would meet.
The preferred venue for discussion of this document is the The preferred venue for discussion of this document is the
xmpp@ietf.org mailing list; visit xmpp@ietf.org mailing list; visit
<https://www.ietf.org/mailman/listinfo/xmpp> for further information. <https://www.ietf.org/mailman/listinfo/xmpp> for further information.
Much of the text in this document has been copied from [XEP-0210].
2. Scope 2. Scope
There are several different kinds of communications between XMPP There are several different forms of communication between XMPP
entitites: entitites:
1. One-to-one communication sessions between two entities, where 1. One-to-one communication sessions between two entities, where
each entity is online and available during the life of the each entity is online and available during the life of the
session so that all of the communications occur in real time. session so that all of the communications occur in real time.
2. One-to-one messages that are not transferred in real time but 2. One-to-one messages that are not transferred in real time but
that instead are stored when sent and then forwarded when the that instead are stored when sent and then forwarded when the
recipient is next online; these are usually called "offline recipient is next online; these are usually called "offline
messages" as described in [OFFLINE]. messages" as described in [OFFLINE].
3. One-to-many information broadcast, such as undirected presence 3. One-to-many information broadcast, such as undirected presence
stanzas sent from one user to many contacts as described in stanzas sent from one user to many contacts as described in
[XMPP-IM] and data syndication as described in [PubSub]. [XMPP-IM] and data syndication as described in [PubSub].
4. Many-to-many communication sessions among more than two entities, 4. Many-to-many communication sessions among more than two entities,
such as a text conference in a chatroom as described in [MUC]. such as a text conference in a chatroom as described in [MUC].
Ideally, any technology for end-to-end encryption in XMPP could be Ideally, any technology for end-to-end encryption in XMPP could be
extended to cover all the scenarios above. However, both one-to-many extended to cover all of the foregoing communication methods.
broadcast and many-to-many sessions are deemed out-of-scope for this However, both one-to-many broadcast and many-to-many sessions are
document, and this document puts more weight on one-to-one deemed out-of-scope for this document, and this document puts more
communication sessions (the typical scenario for XMPP) than on weight on one-to-one communication sessions (the typical scenario for
offline messages. XMPP) than on offline messages.
3. Threat Analysis 3. Threat Analysis
XMPP technologies are typically deployed using a client-server XMPP technologies are typically deployed using a client-server
architecture. As a result, XMPP endpoints (often but not always architecture. As a result, XMPP endpoints (often but not always
controlled by human users) need to communicate through one or more controlled by human users) need to communicate through one or more
servers. For example, the user juliet@capulet.lit connects to the servers. For example, the user juliet@capulet.lit connects to the
capulet.lit server and the user romeo@montague.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 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 Romeo the message will be routed over her client-to-server connection
skipping to change at page 5, line 36 skipping to change at page 5, line 32
clients. clients.
o A more sophisticated active attack would involve a cryptanalytic o A more sophisticated active attack would involve a cryptanalytic
attack on the keying material or other credentials used to attack on the keying material or other credentials used to
establish trust between the parties, such as an ephemeral password establish trust between the parties, such as an ephemeral password
exchanged during an initial certificate exchange if Secure Remote exchanged during an initial certificate exchange if Secure Remote
Password [TLS-SRP] is used. Password [TLS-SRP] is used.
Other attacks are possible, and the foregoing list is best considered Other attacks are possible, and the foregoing list is best considered
incomplete at this time. 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.
4. Security Requirements 4. Security Requirements
This document stipulates the following security requirements for end- This document stipulates the following security requirements for end-
to-end encryption of XMPP communications: to-end encryption of XMPP communications:
Confidentiality: The one-to-one XML stanzas exchanged between two Confidentiality: The one-to-one XML stanzas exchanged between two
entities (conventionally, "Alice" and "Bob") must not be entities (conventionally, "Alice" and "Bob") must not be
understandable to any other entity that might intercept the understandable to any other entity that might intercept the
communications. The encrypted stanzas should be understood by an communications. The encrypted stanzas should be understood by an
intermediate server only to the extent required to route them. 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).
Integrity: Alice and Bob must be sure that no other entity can Integrity: Alice and Bob must be sure that no other entity can
change the content of the XML stanzas they exchange, or remove or change the content of the XML stanzas they exchange, or remove or
insert stanzas undetected. insert stanzas undetected.
Replay Protection: Alice or Bob must be able to identify and reject Replay Protection: Alice or Bob must be able to identify and reject
any communications that are copies of their previous any communications that are copies of their previous
communications resent by another entity. communications resent by another entity.
Perfect Forward Secrecy: The encrypted communication should not be Perfect Forward Secrecy: The encrypted communication should not be
revealed even if long-lived keys are compromised in the future revealed even if long-lived keys are compromised in the future
(e.g., Steve steals Bob's computer). For long-lived sessions it (e.g., Steve steals Bob's computer). For long-lived sessions it
must be possible to periodically change the decryption keys. must be possible to periodically change the decryption keys.
PKI Independence: The protocol must not force the use of any public Trust: The protocol must enable Alice and Bob to establish trust in
key infrastructure (PKI), certification authority, web of trust, each other's credentials either within the protocol or using
or any other trust model that is external to the trust established outside channels. The supported credential types might include
between Alice and Bob. However, if external authentication or self-signed certificates, pre-shared keys, and shared secrets,
trust models are available then Alice and Bob should be able to either as stable credentials or as mechanisms for bootstrapping
use such trust models to enhance any trust that exists between trust in ephemeral keying material. The protocol must not force
them. the use of any public key infrastructure (PKI), certification
Authentication: Each party to a conversation must know that the authority, web of trust, or any other trust model that is external
other party is who they want to communicate with (Alice must be to the trust established between Alice and Bob; however, if
able to know that Bob really is Bob, and vice versa). Note: external authentication or trust models are available then Alice
Authentication can be as simple as Alice confirming that Bob is and Bob should be able to use such trust models to enhance any
the same Bob that she communicated with yesterday or that she trust that exists between them.
talked to on the telephone. The reliable association between an Authentication: 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 entity and its public keys is "identification" and therefore
beyond the scope of this document. beyond the scope of this document.
Identity Protection: No other entity should be able to identify Identity Protection: No entity other than the intermediate servers
Alice or Bob. The JabberIDs they use to route their stanzas are 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 unavoidably vulnerable to interception. Therefore, even if Alice
and Bob protect their identities by using different JabberIDs for and Bob protect their identities by using different JabberIDs for
each session, it must be possible for their user agents to each session, it must be possible for their user agents to
authenticate them transparently, without any other entity authenticate them transparently, without any other entity
identifying them via an active ("man-in-the-middle") attack, or identifying them via an active ("man-in-the-middle") attack, or
even linking them to their previous sessions. If that is not even linking them to their previous sessions. If that is not
possible because Alice and Bob choose to authenticate using public possible because Alice and Bob choose to authenticate using public
keys instead of retained shared secrets, then the public keys must keys instead of retained shared secrets, then the public keys must
not be revealed to other entities using a passive attack. Bob not be revealed to other entities using a passive attack. Bob
should also be able to choose between protecting either his public should also be able to choose between protecting either his public
key or Alice's public key from disclosure through an active key or Alice's public key from disclosure through an active
attack. attack.
Robustness: The protocol should provide more than one difficult Robustness: The protocol should have multiple lines of defense and
challenge that has to be overcome before an attack can succeed should force an attacker to surmount more than one difficult
(for example, by generating encryption keys using as many shared challenge before an attack can succeed (for example, by generating
secrets as possible, such as retained secrets or optional encryption keys using as many shared secrets as possible, such as
passwords). retained secrets or optional passwords).
Upgradability: The protocol must be upgradable so that, if a Upgradability: The protocol must be upgradable so that, if a
vulnerability is discovered, a new version can fix it. Alice must vulnerability is discovered, a new version can fix it. Alice must
tell Bob which versions of the protocol she is prepared to tell Bob which versions of the protocol she is prepared to
support. support. Upgradability refers to the protocol as a whole as well
as to components thereof (e.g., cryptographic hashing algorithms).
5. Application Requirements 5. Application Requirements
In addition to the foregoing security profile, this document also In addition to the foregoing security profile, this document also
stipulates the following application-specific requirements: stipulates the following application-specific requirements:
Generality: The solution must be generally applicable to the full Generality: The solution must be generally applicable to the full
content of any XML stanza type (<message/>, <presence/>, and content of any XML stanza type (<message/>, <presence/>, and
<iq/>) sent between two entities. It is deemed acceptable if the <iq/>) sent between two entities. It is deemed acceptable if the
solution does not apply to many-to-many stanzas (e.g., groupchat solution does not apply to many-to-many stanzas (e.g., groupchat
skipping to change at page 8, line 22 skipping to change at page 8, line 37
vulnerable. vulnerable.
6. Security Considerations 6. Security Considerations
Security issues are discussed throughout this document. Security issues are discussed throughout this document.
7. IANA Considerations 7. IANA Considerations
This document has no actions for the IANA. This document has no actions for the IANA.
8. Informative References 8. Acknowledgements
[ESessions] Much of the text in this document has been copied from [XEP-0210].
Paterson, I., Saint-Andre, P., and D. Smith, "Encrypted The editor wishes to thank Ian Paterson for his work on that document
Session Negotiation", XSF XEP 0116, May 2007. and the ESessions technology in general.
Thanks also to Bernard Aboba for his feedback.
9. Informative References
[MUC] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, [MUC] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
July 2008. July 2008.
[OFFLINE] Saint-Andre, P., "Best Practices for Handling Offline [OFFLINE] Saint-Andre, P., "Best Practices for Handling Offline
Messages", XSF XEP 0160, January 2006. Messages", XSF XEP 0160, January 2006.
[OpenPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [OpenPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
skipping to change at page 9, line 20 skipping to change at page 9, line 40
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[XEP-0210] [XEP-0210]
Paterson, I., "Requirements for Encrypted Sessions", XSF Paterson, I., "Requirements for Encrypted Sessions", XSF
XEP 0210, May 2007. XEP 0210, May 2007.
[XMPP-CORE] [XMPP-CORE]
Saint-Andre, P., "Extensible Messaging and Presence Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-00 (work Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-05 (work
in progress), June 2009. in progress), March 2010.
[XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", Protocol (XMPP): Instant Messaging and Presence",
draft-ietf-xmpp-3921bis-00 (work in progress), June 2009. draft-ietf-xmpp-3921bis-05 (work in progress), March 2010.
[XMPP-PGP] [XMPP-PGP]
Muldowney, T., "Current Jabber OpenPGP Usage", XSF Muldowney, T., "Current Jabber OpenPGP Usage", XSF
XEP 0027, November 2006. XEP 0027, November 2006.
[XMPP-SESS]
Paterson, I., Saint-Andre, P., and D. Smith, "Encrypted
Session Negotiation", XSF XEP 0116, May 2007.
[XMPP-SMIME] [XMPP-SMIME]
Saint-Andre, P., "End-to-End Signing and Object Encryption Saint-Andre, P., "End-to-End Signing and Object Encryption
for the Extensible Messaging and Presence Protocol for the Extensible Messaging and Presence Protocol
(XMPP)", RFC 3923, October 2004. (XMPP)", RFC 3923, October 2004.
Author's Address Author's Address
Peter Saint-Andre Peter Saint-Andre (editor)
Cisco Cisco
Email: psaintan@cisco.com Email: psaintan@cisco.com
 End of changes. 24 change blocks. 
64 lines changed or deleted 96 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/