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