idnits 2.17.1 draft-ietf-xmpp-e2e-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2010) is 5155 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-3920bis-05 == Outdated reference: A later version (-20) exists of draft-ietf-xmpp-3921bis-05 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XMPP P. Saint-Andre, Ed. 3 Internet-Draft Cisco 4 Intended status: Informational March 8, 2010 5 Expires: September 9, 2010 7 Requirements for End-to-End Encryption in the Extensible Messaging and 8 Presence Protocol (XMPP) 9 draft-ietf-xmpp-e2e-requirements-01 11 Abstract 13 This document describes requirements for end-to-end encryption in the 14 Extensible Messaging and Presence Protocol (XMPP). 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 9, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 5 60 5. Application Requirements . . . . . . . . . . . . . . . . . . . 7 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 64 9. Informative References . . . . . . . . . . . . . . . . . . . . 8 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 End-to-end or "e2e" encryption of traffic sent over the Extensible 70 Messaging and Presence Protocol (XMPP) is a desirable goal. Since 71 1999, the Jabber/XMPP developer community has experimented with 72 several such technologies, including OpenPGP [XMPP-PGP], S/MIME 73 [XMPP-SMIME], and encrypted sessions [XMPP-SESS]. More recently, the 74 community has explored the possibility of using Transport Layer 75 Security [TLS] as the base technology for e2e encryption. In order 76 to provide a foundation for deciding on a sustainable approach to e2e 77 encryption, this document specifies a set of requirements that the 78 ideal technology would meet. 80 The preferred venue for discussion of this document is the 81 xmpp@ietf.org mailing list; visit 82 for further information. 84 2. Scope 86 There are several different forms of communication between XMPP 87 entitites: 89 1. One-to-one communication sessions between two entities, where 90 each entity is online and available during the life of the 91 session so that all of the communications occur in real time. 92 2. One-to-one messages that are not transferred in real time but 93 that instead are stored when sent and then forwarded when the 94 recipient is next online; these are usually called "offline 95 messages" as described in [OFFLINE]. 96 3. One-to-many information broadcast, such as undirected presence 97 stanzas sent from one user to many contacts as described in 98 [XMPP-IM] and data syndication as described in [PubSub]. 99 4. Many-to-many communication sessions among more than two entities, 100 such as a text conference in a chatroom as described in [MUC]. 102 Ideally, any technology for end-to-end encryption in XMPP could be 103 extended to cover all of the foregoing communication methods. 104 However, both one-to-many broadcast and many-to-many sessions are 105 deemed out-of-scope for this document, and this document puts more 106 weight on one-to-one communication sessions (the typical scenario for 107 XMPP) than on offline messages. 109 3. Threat Analysis 111 XMPP technologies are typically deployed using a client-server 112 architecture. As a result, XMPP endpoints (often but not always 113 controlled by human users) need to communicate through one or more 114 servers. For example, the user juliet@capulet.lit connects to the 115 capulet.lit server and the user romeo@montague.lit connects to the 116 montague.lit server, but in order for Juliet to send a message to 117 Romeo the message will be routed over her client-to-server connection 118 with capulet.lit, over a server-to-server connection between 119 capulet.lit and montague.lit, and over Romeo's client-to-server 120 connection with montague.lit. Although [XMPP-CORE] requires support 121 for Transport Layer Security [TLS] to make it possible to encrypt all 122 of these connections, when XMPP is deployed any of these connections 123 might be unencrypted. Furthermore, even if the server-to-server 124 connection is encrypted and both of the client-to-server connections 125 are encrypted, the message would still be in the clear while 126 processed by both the capulet.lit and montague.lit servers. 128 In this specification we primarily address communications security 129 ("commsec") between two parties, especially confidentiality, data 130 integrity, and peer entity authentication. Communications security 131 can be subject to a variety of attacks, which [RFC3552] divides into 132 passive and active categories. In a passive attack, information is 133 leaked (e.g., a passive attacker could read all of the messages that 134 Juliet sends to Romeo). In an active attack, the attacker can add, 135 modify, or delete messages between the parties, thus disrupting 136 communications. 138 Traditionally, it seems that XMPP users have been concerned more 139 about passive attacks (such as eavesdropping) than about active 140 attacks (such as man-in-the-middle), perhaps because they have 141 thought that their communications are "just chat", because they have 142 had no expectation that endpoints could be authenticated, or because 143 they have believed that hijacked communications would be detected 144 socially (e.g., because the other party did not have an authentic 145 "voice" in a text conversation). However, both forms of attack are 146 of concern in this protocol. 148 In particular, we consider the following types of attacks and 149 attackers: 151 o One type of passive attack might involve monitoring all the 152 conversations of a given party. To help prevent this, it is 153 important for the party to ensure that its connection with its 154 server is protected using TLS. However, in this case the 155 eavesdropper could monitor outbound traffic from the party's 156 server, either to other connected clients or to other servers, 157 since that traffic might be unencrypted. In addition, the 158 eavesdropper could attack the party's server so that it gains 159 access to all traffic within the server, or masquerade as the 160 party's server so that the party is fooled into connecting to the 161 attacker rather than directly to the party's server. 162 o Another type of passive attack might involve monitoring of a 163 single conversation between two particular parties. In this case 164 the eavesdropper could monitor communications over the server-to- 165 server connection between the parties' servers, or over the 166 client-to-server connection between either party and that party's 167 server. 168 o One type of active attack would involve modification of the XML 169 stanzas used to advertise support for the protocol "building 170 blocks" that make it possible to negotiate a secure session; as a 171 result, other parties would be led to believe that the party does 172 not have the ability to negotate a secure session and therefore 173 would not attempt such a negotiation. 174 o Another type of active attack would involve modification or 175 outright deletion of the XML stanzas used to negotiate a secure 176 session (such as those described in this document), with the 177 result that the parties would think the negotiation has failed for 178 legitimate reasons such as incompatibilities between the parties' 179 clients. 180 o A more sophisticated active attack would involve a cryptanalytic 181 attack on the keying material or other credentials used to 182 establish trust between the parties, such as an ephemeral password 183 exchanged during an initial certificate exchange if Secure Remote 184 Password [TLS-SRP] is used. 186 Other attacks are possible, and the foregoing list is best considered 187 incomplete at this time. 189 Although an attacker might be able to launch an attack once, it is 190 possible that the attacker cannot launch an attack multiple times. 191 Given that the communication pattern in XMPP is typically to hold 192 multiple different conversations that are separated in time, many end 193 users might consider it acceptable to engage in a "leap of faith" the 194 first time two parties negotiate a secure communication session, then 195 check to make sure that the credentials are the same in subsequent 196 communication sessions. 198 4. Security Requirements 200 This document stipulates the following security requirements for end- 201 to-end encryption of XMPP communications: 203 Confidentiality: The one-to-one XML stanzas exchanged between two 204 entities (conventionally, "Alice" and "Bob") must not be 205 understandable to any other entity that might intercept the 206 communications. The encrypted stanzas should be understood by an 207 intermediate server only to the extent absolutely required to 208 route them (i.e., the 'from' and 'to' addresses). However, note 209 that some intermediaries might require or desire access to more 210 detailed information in order to route XMPP stanzas (e.g., data 211 about confidentiality levels or delivery semantics). 212 Integrity: Alice and Bob must be sure that no other entity can 213 change the content of the XML stanzas they exchange, or remove or 214 insert stanzas undetected. 215 Replay Protection: Alice or Bob must be able to identify and reject 216 any communications that are copies of their previous 217 communications resent by another entity. 218 Perfect Forward Secrecy: The encrypted communication should not be 219 revealed even if long-lived keys are compromised in the future 220 (e.g., Steve steals Bob's computer). For long-lived sessions it 221 must be possible to periodically change the decryption keys. 222 Trust: The protocol must enable Alice and Bob to establish trust in 223 each other's credentials either within the protocol or using 224 outside channels. The supported credential types might include 225 self-signed certificates, pre-shared keys, and shared secrets, 226 either as stable credentials or as mechanisms for bootstrapping 227 trust in ephemeral keying material. The protocol must not force 228 the use of any public key infrastructure (PKI), certification 229 authority, web of trust, or any other trust model that is external 230 to the trust established between Alice and Bob; however, if 231 external authentication or trust models are available then Alice 232 and Bob should be able to use such trust models to enhance any 233 trust that exists between them. 234 Authentication: Each party to a conversation should be able to 235 determine that the other party is who they want to communicate 236 with (Alice must be able to know that Bob really is Bob, or at 237 least is an entity that possesses a credential to which only Bob 238 is expected to have access). Authentication can be as simple as 239 Alice confirming that Bob is the same Bob that she communicated 240 with yesterday or that she talked with on the telephone (identity 241 coherence across time). The reliable association between an 242 entity and its public keys is "identification" and therefore 243 beyond the scope of this document. 244 Identity Protection: No entity other than the intermediate servers 245 and the parties themselves should be able to identify Alice or 246 Bob. Naturally, the JabberIDs they use to route their stanzas are 247 unavoidably vulnerable to interception. Therefore, even if Alice 248 and Bob protect their identities by using different JabberIDs for 249 each session, it must be possible for their user agents to 250 authenticate them transparently, without any other entity 251 identifying them via an active ("man-in-the-middle") attack, or 252 even linking them to their previous sessions. If that is not 253 possible because Alice and Bob choose to authenticate using public 254 keys instead of retained shared secrets, then the public keys must 255 not be revealed to other entities using a passive attack. Bob 256 should also be able to choose between protecting either his public 257 key or Alice's public key from disclosure through an active 258 attack. 259 Robustness: The protocol should have multiple lines of defense and 260 should force an attacker to surmount more than one difficult 261 challenge before an attack can succeed (for example, by generating 262 encryption keys using as many shared secrets as possible, such as 263 retained secrets or optional passwords). 264 Upgradability: The protocol must be upgradable so that, if a 265 vulnerability is discovered, a new version can fix it. Alice must 266 tell Bob which versions of the protocol she is prepared to 267 support. Upgradability refers to the protocol as a whole as well 268 as to components thereof (e.g., cryptographic hashing algorithms). 270 5. Application Requirements 272 In addition to the foregoing security profile, this document also 273 stipulates the following application-specific requirements: 275 Generality: The solution must be generally applicable to the full 276 content of any XML stanza type (, , and 277 ) sent between two entities. It is deemed acceptable if the 278 solution does not apply to many-to-many stanzas (e.g., groupchat 279 messages sent within the context of multi-user chat) or one-to- 280 many stanzas (e.g., presence "broadcasts" and publish-subscribe 281 notifications); end-to-end encryption of such stanzas might 282 require separate solutions. 283 Implementability: The only good security technology is an 284 implemented security technology. The solution should be one that 285 XMPP client developers can implement in a relatively 286 straightforward and interoperable fashion. Ideally the solution 287 would reuse existing technologies so that client developers can 288 also reuse existing libraries, as they already do for security 289 features such as Transport Layer Security [TLS] and the Simple 290 Authentication and Security Layer [SASL]. 291 Usability: The requirement of usability takes implementability one 292 step further by stipulating that the solution should be one that 293 organizations can deploy and humans can use with the ease-of-use 294 of, say, "https:" URLs. Experience has shown that solutions 295 requiring a full public key infrastructure do not get widely 296 deployed and that solutions requiring any user action are not 297 widely used. If, however, Alice and/or Bob are prepared to verify 298 the integrity of their copies of each other's keys (thus enabling 299 them to discover targeted active attacks or even the mass 300 surveilance of a population), then the actions necessary for them 301 to achieve that should be minimal (requiring no more effort than a 302 one-time out-of-band verification of a string of up to 8 303 alphanumeric characters). 304 Efficiency: Cryptographic operations are highly CPU intensive, 305 particularly public key and Diffie-Hellman operations. 306 Cryptographic data structures can be relatively large, especially 307 public keys and certificates. Network round trips can introduce 308 unacceptable delays, especially over high-latency wireless 309 connections. The solution must perform efficiently even when CPU 310 and network bandwidth are constrained. The number of stanzas 311 required for negotiation of encrypted communication should be 312 minimized. 313 Flexibility: The solution must be compatible with a variety of 314 existing and future cryptographic algorithms and identity 315 certification schemes, including [X509] and [OpenPGP]. The 316 protocol must also be able to evolve to correct the weaknesses 317 that are inevitably discovered once any cryptographic protocol is 318 in widespread use. 319 Offline messages: It should be possible to encrypt one-to-one 320 communications that are stored for later delivery (so-called 321 "offline messages") and still benefit from Perfect Forward Secrecy 322 (with a slightly longer period of vulnerability than if both 323 parties were online simultaneously). However, any vulnerabilities 324 introduced into the solution in order to enable such offline 325 communications must not make real-time communications more 326 vulnerable. 328 6. Security Considerations 330 Security issues are discussed throughout this document. 332 7. IANA Considerations 334 This document has no actions for the IANA. 336 8. Acknowledgements 338 Much of the text in this document has been copied from [XEP-0210]. 339 The editor wishes to thank Ian Paterson for his work on that document 340 and the ESessions technology in general. 342 Thanks also to Bernard Aboba for his feedback. 344 9. Informative References 346 [MUC] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 347 July 2008. 349 [OFFLINE] Saint-Andre, P., "Best Practices for Handling Offline 350 Messages", XSF XEP 0160, January 2006. 352 [OpenPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 353 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 355 [PubSub] Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 356 Subscribe", XSF XEP 0060, September 2008. 358 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 359 Text on Security Considerations", BCP 72, RFC 3552, 360 July 2003. 362 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 363 Security Layer (SASL)", RFC 4422, June 2006. 365 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 366 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 368 [TLS-SRP] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 369 "Using the Secure Remote Password (SRP) Protocol for TLS 370 Authentication", RFC 5054, November 2007. 372 [X509] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 373 Housley, R., and W. Polk, "Internet X.509 Public Key 374 Infrastructure Certificate and Certificate Revocation List 375 (CRL) Profile", RFC 5280, May 2008. 377 [XEP-0210] 378 Paterson, I., "Requirements for Encrypted Sessions", XSF 379 XEP 0210, May 2007. 381 [XMPP-CORE] 382 Saint-Andre, P., "Extensible Messaging and Presence 383 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-05 (work 384 in progress), March 2010. 386 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 387 Protocol (XMPP): Instant Messaging and Presence", 388 draft-ietf-xmpp-3921bis-05 (work in progress), March 2010. 390 [XMPP-PGP] 391 Muldowney, T., "Current Jabber OpenPGP Usage", XSF 392 XEP 0027, November 2006. 394 [XMPP-SESS] 395 Paterson, I., Saint-Andre, P., and D. Smith, "Encrypted 396 Session Negotiation", XSF XEP 0116, May 2007. 398 [XMPP-SMIME] 399 Saint-Andre, P., "End-to-End Signing and Object Encryption 400 for the Extensible Messaging and Presence Protocol 401 (XMPP)", RFC 3923, October 2004. 403 Author's Address 405 Peter Saint-Andre (editor) 406 Cisco 408 Email: psaintan@cisco.com