idnits 2.17.1 draft-ietf-xmpp-e2e-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (February 03, 2003) is 7743 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) == Outdated reference: A later version (-24) exists of draft-ietf-xmpp-core-02 == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-02 ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '4') Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 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: August 4, 2003 J. Hildebrand 5 Jabber, Inc. 6 February 03, 2003 8 End-to-End Object Encryption in XMPP 9 draft-ietf-xmpp-e2e-00 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 August 4, 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 encryption method for 41 use in the eXtensible Messaging and Presence Protocol (XMPP). 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.3 Intellectual Property Notice . . . . . . . . . . . . . . . . . 3 49 2. Encrypting Messages . . . . . . . . . . . . . . . . . . . . . 4 50 3. Signaling Support via Presence . . . . . . . . . . . . . . . . 6 51 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 52 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 54 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 56 1. Introduction 58 This document describes an end-to-end encryption method for use in 59 the eXtensible Messaging and Presence Protocol (XMPP) as defined in 60 XMPP Core [1] and XMPP IM [2]. Object encryption enables a sender to 61 encrypt a message sent to a specific recipient and assists the XMPP 62 specifications in meeting the requirements of RFC 2779 [4]. Object 63 encryption is accomplished by sending the encrypted form of the 64 message body along with a unique message ID to help prevent replay 65 attacks. The public key used for message encryption SHOULD match the 66 KeyID sent when signaling support for this protocol via presence 67 broadcast. 69 All operations described herein may be completed using standard 70 OpenPGP [3] software. All program output is US-ASCII armored output 71 with the headers removed, which allows for straightforward 72 encapsulation of the program output directly as XML CDATA. It is 73 assumed that keys may be exchanged using OpenPGP key servers; for 74 example, the key of another user may be retrieved automatically when 75 an appropriate presence stanza is received from that user. 77 1.1 Terminology 79 This document inherits the terminology defined in XMPP Core [1]. 81 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 82 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 83 "OPTIONAL" in this document are to be interpreted as described in RFC 84 2119 [5]. 86 1.2 Discussion Venue 88 The authors welcome discussion and comments related to the topics 89 presented in this document. The preferred forum is the 90 mailing list, for which archives and subscription 91 information are available at . 94 1.3 Intellectual Property Notice 96 This document is in full compliance with all provisions of Section 10 97 of RFC 2026. Parts of this specification use the term "jabber" for 98 identifying namespaces and other protocol syntax. Jabber[tm] is a 99 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 100 to the IETF for use of the Jabber trademark in association with this 101 specification and its successors, if any. 103 2. Encrypting Messages 105 The encrypted payload contains what would be the main element 106 if the message were not encrypted, along with a message ID to help 107 prevent replay attacks; both pieces of information are wrapped in a 108 element scoped by the 'http://jabber.org/protocol/ 109 e2e#payload' namespace, as shown in the following example: 111 112 someID 113 Wherefore art thou? 114 116 The encrypted payload MUST include an element. The CDATA of 117 the element SHOULD be constructed according to the following 118 algorithm: (1) concatenate the sender's full JID (user@host/resource) 119 with the recipient's full JID; (2) concatenate these JID strings with 120 a full ISO-8601 timestamp including year, month, day, hours, minutes, 121 seconds, and UTC offset if appropriate in the following format: yyyy- 122 mm-dd-Thh:mm:ss-hh:mm; (3) hash the resulting string according to the 123 SHA1 algorithm; (4) convert the hexidecimal SHA1 output to all 124 lowercase. 126 The full element (including all XML tag names and angle 127 brackets) MUST then be encrypted according to the OpenPGP algorithm 128 using the sender's KeyID. The armored output MUST be US-ASCII and 129 have the headers removed. The resulting cipher text MUST then be 130 provided as the CDATA of an element scoped by the 'http:// 131 jabber.org/protocol/e2e' namespace. 133 Finally, the message stanza SHOULD contain an unencrypted 134 child element whose CDATA informs the recipient that the actual 135 message body is encrypted. 137 The format of the full message stanza that results from the foregoing 138 procedure is shown in the following example. 140 143 Encrypted is this message. 144 145 hQEOA+fczQLixGb6EAP/Uv0JNo1x/h9d6ia75foKB1sViwAeXnrAwUDuxFhTBdt3 146 HDOeF61b/sqaHBi4B4L50xn4W+dZd0sxgf4QNoWucI6WfqcV5BT3K62iTGLVJ7Lc 147 RoXTylekNsDiNsMVMJBHoYqeoRmTuMt3uuljBHHnXVya7XGMmyxbM/QtdxuykssD 148 /jsvER1EyIfYSWT+G/djvymd9FfgTwLrgyBjC1S0GfQ6oEjmEz5FK+BpwfRDzxjD 149 eR08Q6m7Y8C84OC4Dq4UCSCcdzhhKHH0pACizjeG/2N+DlEwDkwK3b/2ED8fFPE1 150 tCUIl6Z8uvAw5Q6OBeFabgbjdi3QjqY32fV5tOtUkkvk0sAEAcRBF9HqEHNDMEb/ 151 bGza03mV58dlEOjhZEu2rCffR4mqYSDoF8hNb/XuOssDuIvp342ILfAPjyx/AE1/ 152 ffdN0tSWt3kEZzDzeJfFOBzv2n8OPNUKrRAoinnRr9vdFH5KlIQbTFte0Fk/r7YA 153 7PghNWtPZJ/mXQPoCylaK86wGc/KHld8Y+RopWeZSoicpIqGBrpuwdl/o/OtEm0b 154 VnDh3dJpz89aJj2RAAiTaKLotLg/AkmwfQGLZnmv416jxm6zy1p1rQ== 155 =1rou 156 157 159 The decoded payload is: 161 162 e0ffe42b28561960c6b12b944a092794b9683a38 163 O Romeo, Romeo! Wherefore art thou Romeo? 164 166 3. Signaling Support via Presence 168 In order to signal support for this method oof encrypting message 169 bodies, an entity MUST broadcast its KeyID in all outgoing presence 170 stanzas, contained in an element scoped by the 'http:// 171 jabber.org/protocol/e2e' namespace. 173 176 away 177 be right back 178 88CA1D46 179 181 4. Security Considerations 183 Replay attacks are made more difficult using this method because of 184 the inclusion of a unique ID in the encrypted object. Key exchange 185 may rely on the web of trust model used on the OpenPGP keys network. 186 There is no method to check a fingerprint or ownership of a key other 187 than checking the user IDs on a key. 189 References 191 [1] Saint-Andre, P. and J. Miller, "XMPP Core (draft-ietf-xmpp-core- 192 02, work in progress)", February 2003. 194 [2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging (draft- 195 ietf-xmpp-im-02, work in progress)", February 2003. 197 [3] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME 198 Security with OpenPGP", RFC 3156, August 2001. 200 [4] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for 201 Presence and Instant Messaging", RFC 2779, February 2000, 202 . 204 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 205 Levels", BCP 14, RFC 2119, March 1997. 207 Authors' Addresses 209 Peter Saint-Andre 210 Jabber Software Foundation 212 EMail: stpeter@jabber.org 213 URI: http://www.jabber.org/people/stpeter.php 215 Joe Hildebrand 216 Jabber, Inc. 218 EMail: jhildebrand@jabber.com 219 URI: http://www.jabber.org/people/hildjj.php 221 Full Copyright Statement 223 Copyright (C) The Internet Society (2003). All Rights Reserved. 225 This document and translations of it may be copied and furnished to 226 others, and derivative works that comment on or otherwise explain it 227 or assist in its implementation may be prepared, copied, published 228 and distributed, in whole or in part, without restriction of any 229 kind, provided that the above copyright notice and this paragraph are 230 included on all such copies and derivative works. However, this 231 document itself may not be modified in any way, such as by removing 232 the copyright notice or references to the Internet Society or other 233 Internet organizations, except as needed for the purpose of 234 developing Internet standards in which case the procedures for 235 copyrights defined in the Internet Standards process must be 236 followed, or as required to translate it into languages other than 237 English. 239 The limited permissions granted above are perpetual and will not be 240 revoked by the Internet Society or its successors or assigns. 242 This document and the information contained herein is provided on an 243 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 244 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 245 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 246 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 247 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 249 Acknowledgement 251 Funding for the RFC Editor function is currently provided by the 252 Internet Society.