idnits 2.17.1 draft-ietf-xmpp-e2e-03.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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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 (May 20, 2003) is 7647 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 370 == Outdated reference: A later version (-24) exists of draft-ietf-xmpp-core-12 == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-11 ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '4') == Outdated reference: A later version (-04) exists of draft-ietf-impp-im-02 == Outdated reference: A later version (-04) exists of draft-ietf-impp-pres-02 ** Obsolete normative reference: RFC 2633 (ref. '10') (Obsoleted by RFC 3851) ** Obsolete normative reference: RFC 3369 (ref. '11') (Obsoleted by RFC 3852) == Outdated reference: A later version (-07) exists of draft-ietf-smime-aes-alg-06 == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-04 Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 4 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: November 18, 2003 May 20, 2003 6 End-to-End Object Encryption in XMPP 7 draft-ietf-xmpp-e2e-03 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on November 18, 2003. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document defines a method for end-to-end object signing and 38 encryption in the Extensible Messaging and Presence Protocol (XMPP). 40 Table of Contents 42 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 43 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.3 Intellectual Property Notice . . . . . . . . . . . . . . . . . 3 46 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 3. Securing Messages . . . . . . . . . . . . . . . . . . . . . . 6 48 4. Securing Presence . . . . . . . . . . . . . . . . . . . . . . 8 49 5. Secure Communications Through a Gateway . . . . . . . . . . . 10 50 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 51 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 52 Normative References . . . . . . . . . . . . . . . . . . . . . 13 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 54 A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . 15 55 B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 16 56 B.1 Changes from draft-ietf-xmpp-e2e-02 . . . . . . . . . . . . . 16 57 B.2 Changes from draft-ietf-xmpp-e2e-01 . . . . . . . . . . . . . 16 58 B.3 Changes from draft-ietf-xmpp-e2e-00 . . . . . . . . . . . . . 16 59 Intellectual Property and Copyright Statements . . . . . . . . 17 61 1. Introduction 63 This document define a method for end-to-end signing and encryption 64 in the Extensible Messaging and Presence Protocol (XMPP). (For 65 information about XMPP, see XMPP Core [1] and XMPP IM [2].) The 66 method defined herein enables a sender to encrypt and/or sign an 67 instant message sent to a specific recipient, encrypt and/or sign 68 presence information that is directed to a specific user, and sign 69 presence information that is broadcasted to a specific user. This 70 document thereby helps the XMPP specifications meet the requirements 71 defined in RFC 2779 [3]. 73 1.1 Terminology 75 This document inherits terminology defined in XMPP Core [1] and RFC 76 2778 [4]. 78 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 79 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 80 "OPTIONAL" in this document are to be interpreted as described in RFC 81 2119 [5]. 83 1.2 Discussion Venue 85 The authors welcome discussion and comments related to the topics 86 presented in this document. The preferred forum is the 87 mailing list, for which archives and subscription 88 information are available at . 91 1.3 Intellectual Property Notice 93 This document is in full compliance with all provisions of Section 10 94 of RFC 2026. Parts of this specification use the term "jabber" for 95 identifying namespaces and other protocol syntax. Jabber[tm] is a 96 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 97 to the IETF for use of the Jabber trademark in association with this 98 specification and its successors, if any. 100 2. Requirements 102 For the purposes of this document, we stipulate the following 103 requirements: 105 1. The method defined MUST address encryption and signing 106 requirements for minimal instant messaging and presence only, as 107 those are defined in RFC 2779 [3]. The method is NOT REQUIRED to 108 support non-IM applications of XMPP, nor to support advanced 109 instant messaging and presence functionality that is outside the 110 scope of RFC 2799. In particular, the method MUST address the 111 following requirements defined in RFC 2779: 113 * The protocol MUST provide means to ensure confidence that a 114 received message (NOTIFICATION or INSTANT MESSAGE) has not 115 been corrupted or tampered with. (Section 2.5.1) 117 * The protocol MUST provide means to ensure confidence that a 118 received message (NOTIFICATION or INSTANT MESSAGE) has not 119 been recorded and played back by an adversary. (Section 2.5.2) 121 * The protocol MUST provide means to ensure that a sent message 122 (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES 123 that the sender allows. (Section 2.5.3) 125 * The protocol MUST allow any client to use the means to ensure 126 non-corruption, non-playback, and privacy, but the protocol 127 MUST NOT require that all clients use these means at all 128 times. (Section 2.5.4) 130 * When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION, 131 the protocol MUST provide A means of verifying the accurate 132 receipt of the content B chooses to disclose to A. (Section 133 5.1.4) 135 * The protocol MUST provide A means of verifying that the 136 presence information is accurate, as sent by B. (Section 137 5.3.1) 139 * The protocol MUST provide A means of ensuring that no other 140 PRINCIPAL C can see the content of M. (Section 5.4.6) 142 * The protocol MUST provide A means of ensuring that no other 143 PRINCIPAL C can tamper with M, and B means to verify that no 144 tampering has occurred. (Section 5.4.7) 146 2. The method defined MUST enable interoperability with non-XMPP 147 messaging systems that support Common Presence and Instant 148 Messaging (CPIM) as defined by the Instant Messaging and Presence 149 (IMPP) Working Group. Therefore: 151 * Prior to encrypting or signing, the format of an instant 152 message must conform to the CPIM Message Format defined in 153 MSGFMT [6]. 155 * Prior to encrypting or signing, the format of presence 156 information must conform to the CPIM Presence Information Data 157 Format defined in PIDF [7]. 159 3. The method MUST follow the procedures (including the specific 160 algorithms) defined in Common Profile for Instant Messaging [8] 161 and Common Profile for Presence [9]. In particular, these 162 documents specify: 164 * Encryption MUST use S/MIME [10] encryption with CMS [11] 165 EnvelopeData. 167 * Signing MUST use S/MIME [10] signatures with CMS [11] 168 SignedData. 170 * The S/MIME algorithm SHOULD be AES [12]. 172 3. Securing Messages 174 In order to encrypt a message, a sending entity MUST use the 175 following procedure: 177 1. Generate a "Message/CPIM" object as defined in MSGFMT [6]. 179 2. Encrypt and/or sign both the headers and content of the "Message/ 180 CPIM" object as specified in Requirement 3 of Section 2 above. 182 3. Provide the resulting multipart S/MIME object (see RFC 1847 [13]) 183 as the CDATA of an child of a stanza, with the 184 element scoped by the 'urn:ietf:params:xml:ns:xmpp-e2e' 185 namespace (note that this namespace name adheres to the format 186 defined in The IANA XML Registry [14]). 188 Example 1: Sender generates "Message/CPIM" object: 190 Content-type: Message/CPIM 192 From: Juliet Capulet 193 To: Romeo Montague 194 DateTime: 2003-05-14T11:45:36Z 195 Subject: Imploring 197 Content-type: text/xml; charset=utf-8 198 Content-ID: <1234567890@capulet.com> 200 201 Wherefore art thou, Romeo? 202 203 Example 2: Sender generates signed message (the 'from' address on the 204 XMPP message stanza is stamped by sender's server): 206 207 208 Content-Type: multipart/signed; boundary=next; 209 micalg=sha1; 210 protocol=application/pkcs7-signature 212 --next 213 Content-type: Message/CPIM 215 From: Juliet Capulet 216 To: Romeo Montague 217 DateTime: 2003-05-14T23:45:36Z 218 Subject: Imploring 220 Content-type: text/xml; charset=utf-8 221 Content-ID: <1234567890@capulet.com> 223 224 Wherefore art thou, Romeo? 225 226 --next 227 Content-Type: application/pkcs7-signature 229 [signed body part] 231 --next-- 232 233 235 4. Securing Presence 237 In order to encrypt presence information, a sending entity MUST use 238 the following procedure: 240 1. Generate an "application/cpim-pidf+xml" object defined in PIDF 241 [7]. 243 2. Encrypt and/or sign the "application/cpim-pidf+xml" object as 244 specified in Requirement 3 of Section 2 above. 246 3. Provide the resulting S/MIME object as the CDATA of an 247 child of a stanza, with the element scoped by 248 the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace (note that this 249 namespace name adheres to the format defined in The IANA XML 250 Registry [14]). The stanza MUST include a 'to' 251 attribute, i.e., it must be an instance of directed presence as 252 defined in XMPP IM [2]. 254 Example 3: Sender generates "application/cpim-pidf+xml" object: 256 Content-type: application/cpim-pidf+xml 258 From: Juliet Capulet 259 To: Romeo Montague 260 DateTime: 2003-05-14T23:53:11Z 262 Content-type: text/xml; charset=utf-8 263 Content-ID: <2345678901@capulet.com> 265 266 269 271 open 272 away 273 274 retired to the chamber 275 2003-05-14T23:53:11Z 276 277 279 Example 4: Sender generates signed presence (the 'from' address on 280 the XMPP presence stanza is stamped by sender's server): 282 283 284 Content-Type: multipart/signed; boundary=next; 285 micalg=sha1; 286 protocol=application/pkcs7-signature 288 --next 289 Content-type: application/cpim-pid+xml 291 From: Juliet Capulet 292 To: Romeo Montague 293 DateTime: 2003-05-14T23:53:11Z 295 Content-type: text/xml; charset=utf-8 296 Content-ID: <2345678901@capulet.com> 298 299 302 304 open 305 away 306 307 retired to the chamber 308 2003-05-14T23:53:11Z 309 310 311 --next 312 Content-Type: application/pkcs7-signature 314 [signed body part] 316 --next-- 317 318 320 5. Secure Communications Through a Gateway 322 A common method for achieving interoperability between two disparate 323 services is through the use of a "gateway" that interprets the 324 protocols of each service and translates them into the protocols of 325 the other. CPIM [8] and CPP [9] define the common profiles to be used 326 for interoperability between instant messaging and presence services 327 that comply with RFC 2779 [3]. In the case of communications between 328 an XMPP service and a non-XMPP service, we can visualize this 329 relationship as follows: 331 +-------------+ +-------------+ +-------------+ 332 | | | | | | 333 | XMPP | | CPIM/CPP | | Non-XMPP | 334 | Service | <----> | Gateway | <----> | Service | 335 | | | | | | 336 +-------------+ +-------------+ +-------------+ 338 The end-to-end encryption method defined herein enables the exchange 339 of encrypted and/or signed instant messages and presence through 340 CPIM/CPP gateways. In particular: 342 o When a gateway receives a secured XMPP message or presence stanza 343 from the XMPP service that addressed to a user on the non-XMPP 344 service, it MUST remove the XMPP "wrapper" (everything down to and 345 including the and tags) in order to reveal the 346 multipart S/MIME object, then route the object to the non-XMPP 347 service (first wrapping it in the protocol used by the non-XMPP 348 service if necessary). 350 o When a gateway receives a secured non-XMPP instant message or 351 presence document from the non-XMPP service that is addressed to a 352 user on the XMPP service, it MUST remove the non-XMPP "wrapper" 353 (if any) in order to reveal the multipart S/MIME object, wrap the 354 object in an XMPP message or presence "wrapper" (including the 355 and tags), and then route the XMPP stanza to the XMPP 356 service. 358 6. IANA Considerations 360 A URN sub-namespace for signed and encrypted content in the 361 Extensible Messaging and Presence Protocol (XMPP) is defined as 362 follows. 364 URI: urn:ietf:params:xml:ns:xmpp-e2e 366 Specification: [RFCXXXX] 368 Description: This is the XML namespace name for signed and encrypted 369 content in the Extensible Messaging and Presence Protocol as 370 defined by [RFCXXXX]. 372 Registrant Contact: IETF, XMPP Working Group, 374 7. Security Considerations 376 Detailed security considerations for instant messaging and presence 377 protocols are given in RFC 2779 [3], specifically in Sections 5.1 378 through 5.4. 380 The end-to-end security method defined here MAY result in exchanging 381 secured instant messages and presence information through a gateway 382 that implements CPIM [8] and CPP [9]. Such a gateway MUST be 383 compliant with the minimum security requirements of the instant 384 messaging and presence protocols with which it interfaces. The 385 introduction of gateways to the security model of instant messaging 386 and presence in RFC 2779 also introduces some new risks. End-to-end 387 security properties (especially confidentiality and integrity) 388 between instant messaging and presence user agents that interface 389 through a CPIM/CPP gateway can be provided only if common formats are 390 supported. The need for end-to-end security is thus met by this 391 specification through the use of common formats, specifically MSGFMT 392 [6] for instant messages and PIDF [7] for presence information. 393 Common formats are further ensured by requiring the use of multipart 394 S/MIME [10] objects, as well as CMS [11] EnvelopeData for encryption 395 and CMS [11] SignedData for signing. Finally, the algorithm used 396 SHOULD be AES [12], since it is expected that AES best suits the 397 capabilities of many platforms. However, an IETF specification for 398 the use of AES is still incomplete at the time of writing. 400 Normative References 402 [1] Saint-Andre, P. and J. Miller, "XMPP Core", 403 draft-ietf-xmpp-core-12 (work in progress), May 2003. 405 [2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging", 406 draft-ietf-xmpp-im-11 (work in progress), May 2003. 408 [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 409 Presence Protocol Requirements", RFC 2779, February 2000. 411 [4] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 412 Instant Messaging", RFC 2778, February 2000, . 415 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 416 Levels", BCP 14, RFC 2119, March 1997. 418 [6] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging 419 Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in 420 progress), January 2003. 422 [7] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. and 423 J. Peterson, "CPIM Presence Information Data Format", 424 draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. 426 [8] Crocker, D. and J. Peterson, "Common Profile for Instant 427 Messaging (CPIM)", draft-ietf-impp-im-02 (work in progress), 428 March 2003. 430 [9] Crocker, D. and J. Peterson, "Common Profile for Presence 431 (CPP)", draft-ietf-impp-pres-02 (work in progress), March 2003. 433 [10] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 434 2633, June 1999. 436 [11] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 437 August 2002. 439 [12] Housley, R. and J. Schaad, "Use of the AES Encryption Algorithm 440 and RSA-OAEP Key Transport in CMS", draft-ietf-smime-aes-alg-06 441 (work in progress), January 2003. 443 [13] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security 444 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", 445 RFC 1847, October 1995. 447 [14] Mealling, M., "The IANA XML Registry", 448 draft-mealling-iana-xmlns-registry-04 (work in progress), June 449 2002. 451 Author's Address 453 Peter Saint-Andre 454 Jabber Software Foundation 456 EMail: stpeter@jabber.org 457 URI: http://www.jabber.org/people/stpeter.php 459 Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e 461 The following XML schema is descriptive, not normative. 463 465 471 473 475 Appendix B. Revision History 477 Note to RFC Editor: please remove this entire appendix, and the 478 corresponding entries in the table of contents, prior to publication. 480 B.1 Changes from draft-ietf-xmpp-e2e-02 482 o Completely revised to use CPIM/CPP. 484 B.2 Changes from draft-ietf-xmpp-e2e-01 486 o Removed old Section 6 (Signalling Support via Presence) -- the 487 ability to sign broadcasted presence made it redundant. 489 o Made small editorial changes to address RFC Editor requirements. 491 B.3 Changes from draft-ietf-xmpp-e2e-00 493 o Added support for all stanza types. 495 o Specified that the full stanza is encrypted. 497 o Added support for S/MIME in addition to OpenPGP. 499 o Specified that encrypted presence must be directed to a specific 500 recipient. 502 o Specified order of encrypting and signing. 504 o Added support for signing broadcasted presence. 506 o Added IANA considerations. 508 o Changed namespace to 'urn:ietf:params:xml:ns:xmpp-e2e'. 510 o Added XML schema. 512 Intellectual Property Statement 514 The IETF takes no position regarding the validity or scope of any 515 intellectual property or other rights that might be claimed to 516 pertain to the implementation or use of the technology described in 517 this document or the extent to which any license under such rights 518 might or might not be available; neither does it represent that it 519 has made any effort to identify any such rights. Information on the 520 IETF's procedures with respect to rights in standards-track and 521 standards-related documentation can be found in BCP-11. Copies of 522 claims of rights made available for publication and any assurances of 523 licenses to be made available, or the result of an attempt made to 524 obtain a general license or permission for the use of such 525 proprietary rights by implementors or users of this specification can 526 be obtained from the IETF Secretariat. 528 The IETF invites any interested party to bring to its attention any 529 copyrights, patents or patent applications, or other proprietary 530 rights which may cover technology that may be required to practice 531 this standard. Please address the information to the IETF Executive 532 Director. 534 Full Copyright Statement 536 Copyright (C) The Internet Society (2003). All Rights Reserved. 538 This document and translations of it may be copied and furnished to 539 others, and derivative works that comment on or otherwise explain it 540 or assist in its implementation may be prepared, copied, published 541 and distributed, in whole or in part, without restriction of any 542 kind, provided that the above copyright notice and this paragraph are 543 included on all such copies and derivative works. However, this 544 document itself may not be modified in any way, such as by removing 545 the copyright notice or references to the Internet Society or other 546 Internet organizations, except as needed for the purpose of 547 developing Internet standards in which case the procedures for 548 copyrights defined in the Internet Standards process must be 549 followed, or as required to translate it into languages other than 550 English. 552 The limited permissions granted above are perpetual and will not be 553 revoked by the Internet Society or its successors or assignees. 555 This document and the information contained herein is provided on an 556 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 557 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 558 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 559 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 560 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 562 Acknowledgement 564 Funding for the RFC Editor function is currently provided by the 565 Internet Society.