From: http://www.ietf.org/internet-drafts/draft-ietf-xmpp-e2e-00.txt End-to-End Object Encryption in XMPP Reference: draft-ietf-xmpp-e2e-00 ------------------------------------------------------------------------ Network Working Group P. Saint-Andre Internet-Draft Jabber Software Foundation Expires: August 4, 2003 J. Hildebrand Jabber, Inc. February 03, 2003 End-to-End Object Encryption in XMPP draft-ietf-xmpp-e2e-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 4, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes an end-to-end object encryption method for use in the eXtensible Messaging and Presence Protocol (XMPP). Saint-Andre & Hildebrand Expires August 4, 2003 [Page 1] Internet-Draft End-to-End Object Encryption in XMPP February 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Intellectual Property Notice . . . . . . . . . . . . . . . . . 3 2. Encrypting Messages . . . . . . . . . . . . . . . . . . . . . 4 3. Signaling Support via Presence . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 Saint-Andre & Hildebrand Expires August 4, 2003 [Page 2] Internet-Draft End-to-End Object Encryption in XMPP February 2003 1. Introduction This document describes an end-to-end encryption method for use in the eXtensible Messaging and Presence Protocol (XMPP) as defined in XMPP Core [1] and XMPP IM [2]. Object encryption enables a sender to encrypt a message sent to a specific recipient and assists the XMPP specifications in meeting the requirements of RFC 2779 [4]. Object encryption is accomplished by sending the encrypted form of the message body along with a unique message ID to help prevent replay attacks. The public key used for message encryption SHOULD match the KeyID sent when signaling support for this protocol via presence broadcast. All operations described herein may be completed using standard OpenPGP [3] software. All program output is US-ASCII armored output with the headers removed, which allows for straightforward encapsulation of the program output directly as XML CDATA. It is assumed that keys may be exchanged using OpenPGP key servers; for example, the key of another user may be retrieved automatically when an appropriate presence stanza is received from that user. 1.1 Terminology This document inherits the terminology defined in XMPP Core [1]. The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5]. 1.2 Discussion Venue The authors welcome discussion and comments related to the topics presented in this document. The preferred forum is the mailing list, for which archives and subscription information are available at . 1.3 Intellectual Property Notice This document is in full compliance with all provisions of Section 10 of RFC 2026. Parts of this specification use the term "jabber" for identifying namespaces and other protocol syntax. Jabber[tm] is a registered trademark of Jabber, Inc. Jabber, Inc. grants permission to the IETF for use of the Jabber trademark in association with this specification and its successors, if any. Saint-Andre & Hildebrand Expires August 4, 2003 [Page 3] Internet-Draft End-to-End Object Encryption in XMPP February 2003 2. Encrypting Messages The encrypted payload contains what would be the main element if the message were not encrypted, along with a message ID to help prevent replay attacks; both pieces of information are wrapped in a element scoped by the 'http://jabber.org/protocol/ e2e#payload' namespace, as shown in the following example: someID Wherefore art thou? The encrypted payload MUST include an element. The CDATA of the element SHOULD be constructed according to the following algorithm: (1) concatenate the sender's full JID (user@host/resource) with the recipient's full JID; (2) concatenate these JID strings with a full ISO-8601 timestamp including year, month, day, hours, minutes, seconds, and UTC offset if appropriate in the following format: yyyy- mm-dd-Thh:mm:ss-hh:mm; (3) hash the resulting string according to the SHA1 algorithm; (4) convert the hexidecimal SHA1 output to all lowercase. The full element (including all XML tag names and angle brackets) MUST then be encrypted according to the OpenPGP algorithm using the sender's KeyID. The armored output MUST be US-ASCII and have the headers removed. The resulting cipher text MUST then be provided as the CDATA of an element scoped by the 'http:// jabber.org/protocol/e2e' namespace. Finally, the message stanza SHOULD contain an unencrypted child element whose CDATA informs the recipient that the actual message body is encrypted. The format of the full message stanza that results from the foregoing procedure is shown in the following example. Saint-Andre & Hildebrand Expires August 4, 2003 [Page 4] Internet-Draft End-to-End Object Encryption in XMPP February 2003 Encrypted is this message. hQEOA+fczQLixGb6EAP/Uv0JNo1x/h9d6ia75foKB1sViwAeXnrAwUDuxFhTBdt3 HDOeF61b/sqaHBi4B4L50xn4W+dZd0sxgf4QNoWucI6WfqcV5BT3K62iTGLVJ7Lc RoXTylekNsDiNsMVMJBHoYqeoRmTuMt3uuljBHHnXVya7XGMmyxbM/QtdxuykssD /jsvER1EyIfYSWT+G/djvymd9FfgTwLrgyBjC1S0GfQ6oEjmEz5FK+BpwfRDzxjD eR08Q6m7Y8C84OC4Dq4UCSCcdzhhKHH0pACizjeG/2N+DlEwDkwK3b/2ED8fFPE1 tCUIl6Z8uvAw5Q6OBeFabgbjdi3QjqY32fV5tOtUkkvk0sAEAcRBF9HqEHNDMEb/ bGza03mV58dlEOjhZEu2rCffR4mqYSDoF8hNb/XuOssDuIvp342ILfAPjyx/AE1/ ffdN0tSWt3kEZzDzeJfFOBzv2n8OPNUKrRAoinnRr9vdFH5KlIQbTFte0Fk/r7YA 7PghNWtPZJ/mXQPoCylaK86wGc/KHld8Y+RopWeZSoicpIqGBrpuwdl/o/OtEm0b VnDh3dJpz89aJj2RAAiTaKLotLg/AkmwfQGLZnmv416jxm6zy1p1rQ== =1rou The decoded payload is: e0ffe42b28561960c6b12b944a092794b9683a38 O Romeo, Romeo! Wherefore art thou Romeo? Saint-Andre & Hildebrand Expires August 4, 2003 [Page 5] Internet-Draft End-to-End Object Encryption in XMPP February 2003 3. Signaling Support via Presence In order to signal support for this method oof encrypting message bodies, an entity MUST broadcast its KeyID in all outgoing presence stanzas, contained in an element scoped by the 'http:// jabber.org/protocol/e2e' namespace. away be right back 88CA1D46 Saint-Andre & Hildebrand Expires August 4, 2003 [Page 6] Internet-Draft End-to-End Object Encryption in XMPP February 2003 4. Security Considerations Replay attacks are made more difficult using this method because of the inclusion of a unique ID in the encrypted object. Key exchange may rely on the web of trust model used on the OpenPGP keys network. There is no method to check a fingerprint or ownership of a key other than checking the user IDs on a key. Saint-Andre & Hildebrand Expires August 4, 2003 [Page 7] Internet-Draft End-to-End Object Encryption in XMPP February 2003 References [1] Saint-Andre, P. and J. Miller, "XMPP Core (draft-ietf-xmpp-core- 02, work in progress)", February 2003. [2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging (draft- ietf-xmpp-im-02, work in progress)", February 2003. [3] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. [4] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for Presence and Instant Messaging", RFC 2779, February 2000, . [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Peter Saint-Andre Jabber Software Foundation EMail: stpeter@jabber.org URI: http://www.jabber.org/people/stpeter.php Joe Hildebrand Jabber, Inc. EMail: jhildebrand@jabber.com URI: http://www.jabber.org/people/hildjj.php Saint-Andre & Hildebrand Expires August 4, 2003 [Page 8] Internet-Draft End-to-End Object Encryption in XMPP February 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Saint-Andre & Hildebrand Expires August 4, 2003 [Page 9]