idnits 2.17.1 draft-ietf-xmpp-e2e-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 21, 2003) is 7673 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 366 == Outdated reference: A later version (-24) exists of draft-ietf-xmpp-core-10 == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-09 ** Obsolete normative reference: RFC 2440 (ref. '4') (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 2633 (ref. '5') (Obsoleted by RFC 3851) == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-04 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Jabber Software Foundation 4 Expires: October 20, 2003 J. Hildebrand 5 Jabber, Inc. 6 April 21, 2003 8 End-to-End Object Encryption in XMPP 9 draft-ietf-xmpp-e2e-02 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 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 http:// 27 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 October 20, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document describes an end-to-end object signing and encryption 41 method for use in the Extensible Messaging and Presence Protocol 42 (XMPP). 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.3 Intellectual Property Notice . . . . . . . . . . . . . . . . . 3 50 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Encrypting Stanzas . . . . . . . . . . . . . . . . . . . . . . 5 52 3.1 General Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.2 Encrypting Messages . . . . . . . . . . . . . . . . . . . . . 6 54 3.3 Encrypting Presence . . . . . . . . . . . . . . . . . . . . . 7 55 3.4 Encrypting IQs . . . . . . . . . . . . . . . . . . . . . . . . 8 56 4. Signing Encrypted Content . . . . . . . . . . . . . . . . . . 9 57 5. Signing Broadcasted Presence . . . . . . . . . . . . . . . . . 10 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 60 Normative References . . . . . . . . . . . . . . . . . . . . . 13 61 Informative References . . . . . . . . . . . . . . . . . . . . 14 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 63 A. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 15 64 A.1 urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . . . . . . 15 65 A.2 urn:ietf:params:xml:ns:xmpp-e2e#payload . . . . . . . . . . . 16 66 B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 17 67 B.1 Changes from draft-ietf-xmpp-e2e-01 . . . . . . . . . . . . . 17 68 B.2 Changes from draft-ietf-xmpp-e2e-00 . . . . . . . . . . . . . 17 69 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 71 1. Introduction 73 This document describes an end-to-end signing and encryption method 74 for use in the Extensible Messaging and Presence Protocol (XMPP) as 75 defined by XMPP Core [1] and XMPP IM [2]. Object signing and 76 encryption enable a sender to encrypt an XML stanza sent to a 77 specific recipient, sign such a stanza, sign broadcasted presence, 78 and signal support for the method defined herein. This document 79 thereby helps the XMPP specifications meet the requirements defined 80 in RFC 2779 [6]. 82 1.1 Terminology 84 This document inherits the terminology defined in XMPP Core [1]. 86 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 87 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 88 "OPTIONAL" in this document are to be interpreted as described in RFC 89 2119 [3]. 91 1.2 Discussion Venue 93 The authors welcome discussion and comments related to the topics 94 presented in this document. The preferred forum is the 95 mailing list, for which archives and subscription 96 information are available at . 99 1.3 Intellectual Property Notice 101 This document is in full compliance with all provisions of Section 10 102 of RFC 2026. Parts of this specification use the term "jabber" for 103 identifying namespaces and other protocol syntax. Jabber[tm] is a 104 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 105 to the IETF for use of the Jabber trademark in association with this 106 specification and its successors, if any. 108 2. Requirements 110 For the purposes of this document, we stipulate the following 111 requirements: 113 1. Encryption must work with any stanza type (message, presence, or 114 IQ). 116 2. The full XML stanza must be encrypted. 118 3. Encryption must be possible using either OpenPGP [4] or S/MIME 119 [5]. 121 4. It must be possible to sign encrypted content. 123 5. It must be possible to sign broadcasted presence. 125 6. Any namespaces used must conform to The IETF XML Registry [7]. 127 3. Encrypting Stanzas 129 3.1 General Syntax 131 Any stanza MAY be encrypted. The full stanza MUST be inserted as a 132 direct child of a element scoped by the 133 'urn:ietf:params:xml:ns:xmpp-e2e#payload' namespace. The stanza data 134 MUST be preceded by another direct child of the element, 135 namely an element. The CDATA of the element MUST be 136 constructed according to the following algorithm: 138 1. concatenate the sender's full JID (user@host/resource) with the 139 recipient's full JID 141 2. concatenate the resulting string with a full ISO-8601 UTC 142 timestamp including year, month, day, hours, minutes, seconds in 143 the following format: yyyy-mm-dd-Thh:mm:ssZ (the timestamp must 144 be UTC, no offsets are allowed) 146 3. hash the resulting string according to the SHA1 algorithm 148 4. convert the hexidecimal SHA1 output to all lowercase. 150 Before encryption, the XML to be encrypted will thus be of the 151 following form: 153 154 someID 155 [stanza] 156 158 The full element (including all XML tag names and angle 159 brackets) MUST then be encrypted using either OpenPGP or S/MIME. The 160 output MUST be armored US-ASCII with any headers removed. The 161 resulting cipher text MUST then be provided as the CDATA of the 162 child of an element scoped by the 163 'urn:ietf:params:xml:ns:xmpp-e2e' namespace, with the value of the 164 'type' attribute set to either "openpgp" or "smime" depending on 165 which method was used. 167 The format of the stanza that results from the foregoing procedure is 168 as follows (no 'from' address is included in the stanza to be 169 encrypted, since that is stamped by the sender's server): 171 <[stanza-name] 172 to='recipient' 173 type='[value if provided]' 174 id='[value if provided]' 175 xml:lang='[value if provided]'> 176 178 179 [encrypted content] 180 181 182 184 3.2 Encrypting Messages 186 Message stanzas may be encrypted using the syntax defined above. 188 Example: Sender generates encrypted message ('from' address is 189 stamped by sender's server): 191 192 193 194 hQEOA+fczQLixGb6EAP/SmSRmrzpZQ9OPrjbS2HoZ4VkfNEodykB/TiDt86NdtPE 195 zmeLBduajZEQQhslUbBu8355fvy/ykDom1Xe/S1q56ZMEsSXkDO4x1xt/3OE/Hru 196 ovLXkTAVNX9pfTQb4rC2CC9G+X/ZsRiUf53ug/9PGBDMByiqWRWUBWipWqxoBbID 197 /2j83fQTGopp//tKijmhyMK7/xC73p/9TezvIz1ESqJY2NwSoRo0us6mKu4bBQ3G 198 EtOmMJZZUToNZwgDfLODzZHGOyiT4tdUL9eCln2a5FAgN75NnCUDHdRw0zpaCVIK 199 El389vMl8L0irlmxBMhVYLDyxAwsB8evXkAJeYu0mLuJ0sBZAbyfSlnGr8sAZ7c4 200 peSUpSBMhA4lAOnUASra2tYNsvOdfiFU2V7k1QEoR4c0HBB+ORX5HElPFdgzYM6Q 201 yhxSNWxTqBD1CfYSHM2KNzSJnEimSeL6/bhO32tAXIK+rigywLyCDAFEpYOjLXhp 202 9TA5pQw5ADMzmJnYlq3H5q4kn7s7RfzUuWflQjzhU4u2YFj3lJIRpO1szyXAACTG 203 hJbxpwL0I2Gz4YezWnzIKWU5xTna+V+0heP+lfUfmkP9CtTZZEmxEPKkWTnCt7Fk 204 wUlr9DeqqO5dGd+1KT94QY7clAnb7IRIgGP/ZeGQpn6A4XRvIDwe3/kMAdWLVSR7 205 aYHSCl6JG9ozHGlwIR3HF8K09je/oQwhXvnzimQ= 206 =zjBS 207 208 209 211 The decoded payload is: 213 214 e0ffe42b28561960c6b12b944a092794b9683a38 215 218 Imploring 219 O Romeo, Romeo! Wherefore art thou Romeo? 220 221 223 3.3 Encrypting Presence 225 Presence stanzas may be encrypted using the syntax defined above. An 226 encrypted presence stanza MUST be an instance of directed presence; 227 i.e., the element MUST possess a 'to' attribute 228 specifying a specific intended recipient. Presence information that 229 is intended for broadcasting to all subscribers MUST NOT be 230 encrypted. 232 Example: Sender generates encrypted presence ('from' address is 233 stamped by sender's server): 235 236 237 238 hQEOA+fczQLixGb6EAP/YOqZS+jgzDrXdqIyuDDJI2oxH2LXZf10LeR6EeBdGqX8 239 ewI8Nsf3CR4Mou58tRZ1QG5EOsCl6aylUxAiJuSe5f+Lv97dRWGQnrAQ4RNVpJ8O 240 jzPf+UQJ6mBZhgBgrtPB8XML7dORJqWBR69ralLcGhOtBr0CsNo7RyoZUWrfl74D 241 /0yJ7y3ZyHmA1gDRd9f7CZuMwdNF+xCfQtZjtAdc+t7HNsoJSNxGBeQdJbdpIaJo 242 jvHfiVG6jvrGDzWceyj4SnFkxOfxb+xu1x7mcmiXW0Jb58wsddttmhqBDdDd4B3H 243 QKnZCkyMPUcldzCBXUf4JPbC5EcUnNOmT6mth9+Qj0GJ0sAPAW2tZu5LOLVQU5Wo 244 zMJBZJOlaiyEv74YSYCjGNwKP9Yh+f+rBL1UkmnKqfiZVxSQo50ccPkJ45Syq85j 245 v8RSvYsU27bTQdCNL/ZS5aILQHryD2iXoLDk9XkzVDTBDNahOk1IWUaJwU5Qy1Lw 246 olEYwndAQi0ieXQklW+2HRmq5fZNslItCPJBGWmxAdGO6xyKbkbqCfq6ytw9kXjW 247 wAoBMgWZFfIbBh5EdBd7NO8u9bF3oDXxKO7c4dkg6WXUjJTZzEIWZCNaFa1PcW+3 248 /FoQ 249 =HT9r 250 251 252 254 The decoded payload is: 256 257 e0ffe42b28561960c6b12b944a092794b9683a38 258 259 away 260 retired to the chamber 261 262 264 3.4 Encrypting IQs 266 IQ stanzas may be encrypted using the syntax defined above. 268 Example: Sender generates encrypted IQ ('from' address is stamped by 269 sender's server): 271 272 273 274 hQEOA+fczQLixGb6EAP/ejh9XMAbiFTA4WRIOyBXiiiAHtKCe/AKcn5I1M+HI/AR 275 8K3LdWbg4CzuBfDv/Sb9zesVXIZZEvHHQF6ihjxQpW0V0a1lvgDq49Dc0bR4uPsz 276 sFRr9auTnouZ5062ubwGk3Uic8CChC/JZxlfdRXO4ac3jS+uzafC0aJ9hkn0QkoD 277 /0b9PpTC3OYq5JoMpFSvBHeHOyixqKQh6xhBgJLzr2/6ZId/axOpgq7ru1GyYmHg 278 +dg/wuizJLgMaSSLwmEM58JiGKs44RHcQMUlnEruQvSbbCCNKIaLCMVQPLXS+oaD 279 Ly2ZG8BW+lb0j0d2E0dXbM30TvTfCW9w76xvOnX/BLRT0sA6AVmuJLz6+UN55roD 280 dE7HncBV0J/NmWksTHL/e4521O9aWSrqTYFsG6Fvvu7In5o0iKHIkLVzosW49zA9 281 McDna2krEtjWCsx5feHbxGrBWOpuPPHqD+uuSvD7f7RLWOKvW+Jz2/OXBOJUJ2+x 282 +xX9uaTdP08TlfBa4BrsX5mM+eFhkPC5oDg3O8Jy612A2Jf8IRQ4lYZDoz6SWoHl 283 scfHcSWjqont7hUTXtdTEnHcs9UkaxXlrbwLBaEfix0J7ALgjAESfEjG88eHm5oj 284 49I9rju8kw+HEsSl/moI+icDmuc0mN7bjOcKM3rIeU/roqWD0llWFIyWWrMNLg== 285 =6H0T 286 287 288 290 The decoded payload is: 292 293 e0ffe42b28561960c6b12b944a092794b9683a38 294 295 296 297 299 4. Signing Encrypted Content 301 OpenPGP and S/MIME both allow an entity to either encrypt then sign, 302 or sign then encrypt. When signing first, the signatories are 303 obscured by the encryption; when encrypting first, the signatories 304 are exposed but the signatures can be verified without decrypting. 305 Because in XMPP the signatories are exposed by the very act of 306 exchanging a stanza (since the 'from' and 'to' addresses must be 307 exposed for routing purposes), there would be no use in signing first 308 and encrypting second. Therefore, if signing is desired, it SHOULD 309 be performed after encrypting. 311 5. Signing Broadcasted Presence 313 An entity may want to sign presence information for broadcasting to 314 all subscribers (i.e., the presence stanza is not directed to a 315 particular recipient, but is sent to all other entites that that have 316 subscribed to the sender's presence). Because encrypted presence 317 MUST be directed to a particular recipient, signed presence for 318 broadcasting MUST NOT be encrypted, only signed. However, there is 319 little to no value in signing the entire stanza; therefore it is 320 enough to sign only the user-provided CDATA of the element 321 (note that this requires a signed presence broadcast to include some 322 CDATA in the element). The process is as follows: 324 1. User provides CDATA for the element. 326 2. Client application signs CDATA using OpenPGP or S/MIME. 328 3. Client application inserts signed ASCII output as CDATA of the 329 child of an element that is scoped by the 330 'urn:ietf:params:xml:ns:xmpp-e2e' namespace and that includes a 331 'type' attribute whose value is either "openpgp" or "smime". 333 4. Client application adds element to remainder of presence 334 stanza and sends to server with no 'to' attribute. 336 5. Server stamps 'from' address, enabling recipient to check bare 337 JID (user@domain) of 'from' address against User-IDs defined in 338 the sender's key or certificate. 340 Example: Sender generates signed presence: 342 343 away 344 retired to the chamber 345 346 347 iD8DBQE+kgpNEWF4x4jKHUYRAuthAJ9L1BjML9GIpagVGbEEJr0C7F3k9ACeJRL4 348 obxiSG72h3ggH0Xr3BmGyjE= 349 =T4rw 350 351 352 354 6. IANA Considerations 356 A URN sub-namespace for signed and encrypted content in the 357 Extensible Messaging and Presence Protocol (XMPP) is defined as 358 follows. 360 URI: urn:ietf:params:xml:ns:xmpp-e2e 362 Specification: [RFCXXXX] 364 Description: This is the XML namespace name for signed and encrypted 365 content in the Extensible Messaging and Presence Protocol as 366 defined by [RFCXXXX]. 368 Registrant Contact: IETF, XMPP Working Group, 370 7. Security Considerations 372 Replay attacks are made more difficult using this method because of 373 the inclusion of a unique ID in the encrypted object. Key exchange 374 may rely on the web of trust model used on the OpenPGP keys network. 375 There is no method to check a fingerprint or ownership of a key other 376 than checking the user IDs on a key. A key or certificate SHOULD 377 have associated with it the Jabber ID of the sender. One of the 378 User-IDs defined in a sender's key or certificate MUST be the bare 379 JID (user@domain) of the 'from' address stamped by the sender's 380 server on the XML stanzas that the sender generates; a client that 381 receives signed or encypted stanzas from the sender MUST check the 382 sender's bare JID against the User-IDs defined in the sender's key or 383 certificate, and SHOULD discard the stanza or warn the recipient 384 before presenting the stanza to the recipient if the bare JID does 385 not match. 387 Normative References 389 [1] Saint-Andre, P. and J. Miller, "XMPP Core (draft-ietf-xmpp-core- 390 10, work in progress)", April 2003. 392 [2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging (draft- 393 ietf-xmpp-im-09, work in progress)", April 2003. 395 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 396 Levels", BCP 14, RFC 2119, March 1997. 398 [4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP 399 Message Format", RFC 2440, November 1998. 401 [5] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 402 2633, June 1999. 404 Informative References 406 [6] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for 407 Presence and Instant Messaging", RFC 2779, February 2000, 408 . 410 [7] Mealling, M., "The IANA XML Registry", draft-mealling-iana- 411 xmlns-registry-04 (work in progress), June 2002. 413 Authors' Addresses 415 Peter Saint-Andre 416 Jabber Software Foundation 418 EMail: stpeter@jabber.org 419 URI: http://www.jabber.org/people/stpeter.php 421 Joe Hildebrand 422 Jabber, Inc. 424 EMail: jhildebrand@jabber.com 425 URI: http://www.jabber.org/people/hildjj.php 427 Appendix A. XML Schemas 429 The following XML schemas are descriptive, not normative. 431 A.1 urn:ietf:params:xml:ns:xmpp-e2e 433 435 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 458 459 461 463 A.2 urn:ietf:params:xml:ns:xmpp-e2e#payload 465 467 473 474 475 476 477 478 480 482 484 Appendix B. Revision History 486 Note to RFC Editor: please remove this entire appendix, and the 487 corresponding entries in the table of contents, prior to publication. 489 B.1 Changes from draft-ietf-xmpp-e2e-01 491 o Removed old Section 6 (Signalling Support via Presence) -- the 492 ability to sign broadcasted presence made it redundant. 494 o Made small editorial changes to address RFC Editor requirements. 496 B.2 Changes from draft-ietf-xmpp-e2e-00 498 o Added support for all stanza types. 500 o Specified that the full stanza is encrypted. 502 o Added support for S/MIME in addition to OpenPGP. 504 o Specified that encrypted presence must be directed to a specific 505 recipient. 507 o Specified order of encrypting and signing. 509 o Added support for signing broadcasted presence. 511 o Added IANA considerations. 513 o Changed namespace to 'urn:ietf:params:xml:ns:xmpp-e2e'. 515 o Added XML schema. 517 Full Copyright Statement 519 Copyright (C) The Internet Society (2003). All Rights Reserved. 521 This document and translations of it may be copied and furnished to 522 others, and derivative works that comment on or otherwise explain it 523 or assist in its implementation may be prepared, copied, published 524 and distributed, in whole or in part, without restriction of any 525 kind, provided that the above copyright notice and this paragraph are 526 included on all such copies and derivative works. However, this 527 document itself may not be modified in any way, such as by removing 528 the copyright notice or references to the Internet Society or other 529 Internet organizations, except as needed for the purpose of 530 developing Internet standards in which case the procedures for 531 copyrights defined in the Internet Standards process must be 532 followed, or as required to translate it into languages other than 533 English. 535 The limited permissions granted above are perpetual and will not be 536 revoked by the Internet Society or its successors or assigns. 538 This document and the information contained herein is provided on an 539 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 540 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 541 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 542 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 543 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 545 Acknowledgement 547 Funding for the RFC Editor function is currently provided by the 548 Internet Society.