draft-ietf-xmpp-e2e-02.txt   draft-ietf-xmpp-e2e-03.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Jabber Software Foundation Internet-Draft Jabber Software Foundation
Expires: October 20, 2003 J. Hildebrand Expires: November 18, 2003 May 20, 2003
Jabber, Inc.
April 21, 2003
End-to-End Object Encryption in XMPP End-to-End Object Encryption in XMPP
draft-ietf-xmpp-e2e-02 draft-ietf-xmpp-e2e-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 20, 2003. This Internet-Draft will expire on November 18, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes an end-to-end object signing and encryption This document defines a method for end-to-end object signing and
method for use in the Extensible Messaging and Presence Protocol encryption in the Extensible Messaging and Presence Protocol (XMPP).
(XMPP).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Intellectual Property Notice . . . . . . . . . . . . . . . . . 3 1.3 Intellectual Property Notice . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encrypting Stanzas . . . . . . . . . . . . . . . . . . . . . . 5 3. Securing Messages . . . . . . . . . . . . . . . . . . . . . . 6
3.1 General Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Securing Presence . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Encrypting Messages . . . . . . . . . . . . . . . . . . . . . 6 5. Secure Communications Through a Gateway . . . . . . . . . . . 10
3.3 Encrypting Presence . . . . . . . . . . . . . . . . . . . . . 7
3.4 Encrypting IQs . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Signing Encrypted Content . . . . . . . . . . . . . . . . . . 9
5. Signing Broadcasted Presence . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
Normative References . . . . . . . . . . . . . . . . . . . . . 13 Normative References . . . . . . . . . . . . . . . . . . . . . 13
Informative References . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . 15
A. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 15 B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 16
A.1 urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . . . . . . 15 B.1 Changes from draft-ietf-xmpp-e2e-02 . . . . . . . . . . . . . 16
A.2 urn:ietf:params:xml:ns:xmpp-e2e#payload . . . . . . . . . . . 16 B.2 Changes from draft-ietf-xmpp-e2e-01 . . . . . . . . . . . . . 16
B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 17 B.3 Changes from draft-ietf-xmpp-e2e-00 . . . . . . . . . . . . . 16
B.1 Changes from draft-ietf-xmpp-e2e-01 . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 17
B.2 Changes from draft-ietf-xmpp-e2e-00 . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document describes an end-to-end signing and encryption method This document define a method for end-to-end signing and encryption
for use in the Extensible Messaging and Presence Protocol (XMPP) as in the Extensible Messaging and Presence Protocol (XMPP). (For
defined by XMPP Core [1] and XMPP IM [2]. Object signing and information about XMPP, see XMPP Core [1] and XMPP IM [2].) The
encryption enable a sender to encrypt an XML stanza sent to a method defined herein enables a sender to encrypt and/or sign an
specific recipient, sign such a stanza, sign broadcasted presence, instant message sent to a specific recipient, encrypt and/or sign
and signal support for the method defined herein. This document presence information that is directed to a specific user, and sign
thereby helps the XMPP specifications meet the requirements defined presence information that is broadcasted to a specific user. This
in RFC 2779 [6]. document thereby helps the XMPP specifications meet the requirements
defined in RFC 2779 [3].
1.1 Terminology 1.1 Terminology
This document inherits the terminology defined in XMPP Core [1]. This document inherits terminology defined in XMPP Core [1] and RFC
2778 [4].
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [3]. 2119 [5].
1.2 Discussion Venue 1.2 Discussion Venue
The authors welcome discussion and comments related to the topics The authors welcome discussion and comments related to the topics
presented in this document. The preferred forum is the presented in this document. The preferred forum is the
<xmppwg@jabber.org> mailing list, for which archives and subscription <xmppwg@jabber.org> mailing list, for which archives and subscription
information are available at <http://www.jabber.org/cgi-bin/mailman/ information are available at <http://www.jabber.org/cgi-bin/mailman/
listinfo/xmppwg/>. listinfo/xmppwg/>.
1.3 Intellectual Property Notice 1.3 Intellectual Property Notice
skipping to change at page 4, line 10 skipping to change at page 4, line 10
identifying namespaces and other protocol syntax. Jabber[tm] is a identifying namespaces and other protocol syntax. Jabber[tm] is a
registered trademark of Jabber, Inc. Jabber, Inc. grants permission registered trademark of Jabber, Inc. Jabber, Inc. grants permission
to the IETF for use of the Jabber trademark in association with this to the IETF for use of the Jabber trademark in association with this
specification and its successors, if any. specification and its successors, if any.
2. Requirements 2. Requirements
For the purposes of this document, we stipulate the following For the purposes of this document, we stipulate the following
requirements: requirements:
1. Encryption must work with any stanza type (message, presence, or 1. The method defined MUST address encryption and signing
IQ). requirements for minimal instant messaging and presence only, as
those are defined in RFC 2779 [3]. The method is NOT REQUIRED to
support non-IM applications of XMPP, nor to support advanced
instant messaging and presence functionality that is outside the
scope of RFC 2799. In particular, the method MUST address the
following requirements defined in RFC 2779:
2. The full XML stanza must be encrypted. * The protocol MUST provide means to ensure confidence that a
received message (NOTIFICATION or INSTANT MESSAGE) has not
been corrupted or tampered with. (Section 2.5.1)
3. Encryption must be possible using either OpenPGP [4] or S/MIME * The protocol MUST provide means to ensure confidence that a
[5]. received message (NOTIFICATION or INSTANT MESSAGE) has not
been recorded and played back by an adversary. (Section 2.5.2)
4. It must be possible to sign encrypted content. * The protocol MUST provide means to ensure that a sent message
(NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES
that the sender allows. (Section 2.5.3)
5. It must be possible to sign broadcasted presence. * The protocol MUST allow any client to use the means to ensure
non-corruption, non-playback, and privacy, but the protocol
MUST NOT require that all clients use these means at all
times. (Section 2.5.4)
6. Any namespaces used must conform to The IETF XML Registry [7]. * When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION,
the protocol MUST provide A means of verifying the accurate
receipt of the content B chooses to disclose to A. (Section
5.1.4)
3. Encrypting Stanzas * The protocol MUST provide A means of verifying that the
presence information is accurate, as sent by B. (Section
5.3.1)
3.1 General Syntax * The protocol MUST provide A means of ensuring that no other
PRINCIPAL C can see the content of M. (Section 5.4.6)
Any stanza MAY be encrypted. The full stanza MUST be inserted as a * The protocol MUST provide A means of ensuring that no other
direct child of a <payload/> element scoped by the PRINCIPAL C can tamper with M, and B means to verify that no
'urn:ietf:params:xml:ns:xmpp-e2e#payload' namespace. The stanza data tampering has occurred. (Section 5.4.7)
MUST be preceded by another direct child of the <payload/> element,
namely an <id/> element. The CDATA of the <id/> element MUST be
constructed according to the following algorithm:
1. concatenate the sender's full JID (user@host/resource) with the 2. The method defined MUST enable interoperability with non-XMPP
recipient's full JID messaging systems that support Common Presence and Instant
Messaging (CPIM) as defined by the Instant Messaging and Presence
(IMPP) Working Group. Therefore:
2. concatenate the resulting string with a full ISO-8601 UTC * Prior to encrypting or signing, the format of an instant
timestamp including year, month, day, hours, minutes, seconds in message must conform to the CPIM Message Format defined in
the following format: yyyy-mm-dd-Thh:mm:ssZ (the timestamp must MSGFMT [6].
be UTC, no offsets are allowed)
3. hash the resulting string according to the SHA1 algorithm * Prior to encrypting or signing, the format of presence
information must conform to the CPIM Presence Information Data
Format defined in PIDF [7].
4. convert the hexidecimal SHA1 output to all lowercase. 3. The method MUST follow the procedures (including the specific
algorithms) defined in Common Profile for Instant Messaging [8]
and Common Profile for Presence [9]. In particular, these
documents specify:
Before encryption, the XML to be encrypted will thus be of the * Encryption MUST use S/MIME [10] encryption with CMS [11]
following form: EnvelopeData.
<payload xmlns='urn:ietf:params:xml:ns:xmpp-e2e#payload'> * Signing MUST use S/MIME [10] signatures with CMS [11]
<id>someID</id> SignedData.
[stanza]
</payload>
The full <payload/> element (including all XML tag names and angle * The S/MIME algorithm SHOULD be AES [12].
brackets) MUST then be encrypted using either OpenPGP or S/MIME. The
output MUST be armored US-ASCII with any headers removed. The
resulting cipher text MUST then be provided as the CDATA of the
<stanza/> child of an <x/> element scoped by the
'urn:ietf:params:xml:ns:xmpp-e2e' namespace, with the value of the
'type' attribute set to either "openpgp" or "smime" depending on
which method was used.
The format of the stanza that results from the foregoing procedure is 3. Securing Messages
as follows (no 'from' address is included in the stanza to be
encrypted, since that is stamped by the sender's server):
<[stanza-name] In order to encrypt a message, a sending entity MUST use the
to='recipient' following procedure:
type='[value if provided]'
id='[value if provided]'
xml:lang='[value if provided]'>
<x type='[openpgp|smime]'
xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
<stanza>
[encrypted content]
</stanza>
</x>
</[stanza-name]>
3.2 Encrypting Messages 1. Generate a "Message/CPIM" object as defined in MSGFMT [6].
Message stanzas may be encrypted using the syntax defined above. 2. Encrypt and/or sign both the headers and content of the "Message/
CPIM" object as specified in Requirement 3 of Section 2 above.
Example: Sender generates encrypted message ('from' address is 3. Provide the resulting multipart S/MIME object (see RFC 1847 [13])
stamped by sender's server): as the CDATA of an <e2e/> child of a <message/> stanza, with the
<e2e/> element scoped by the 'urn:ietf:params:xml:ns:xmpp-e2e'
namespace (note that this namespace name adheres to the format
defined in The IANA XML Registry [14]).
Example 1: Sender generates "Message/CPIM" object:
Content-type: Message/CPIM
From: Juliet Capulet <im:juliet@capulet.com>
To: Romeo Montague <im:romeo@montague.net>
DateTime: 2003-05-14T11:45:36Z
Subject: Imploring
Content-type: text/xml; charset=utf-8
Content-ID: <1234567890@capulet.com>
<body>
Wherefore art thou, Romeo?
</body>
Example 2: Sender generates signed message (the 'from' address on the
XMPP message stanza is stamped by sender's server):
<message to='romeo@montague.net/orchard' type='chat'> <message to='romeo@montague.net/orchard' type='chat'>
<x type='openpgp' xmlns='urn:ietf:params:xml:ns:xmpp-e2e'> <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
<stanza> Content-Type: multipart/signed; boundary=next;
hQEOA+fczQLixGb6EAP/SmSRmrzpZQ9OPrjbS2HoZ4VkfNEodykB/TiDt86NdtPE micalg=sha1;
zmeLBduajZEQQhslUbBu8355fvy/ykDom1Xe/S1q56ZMEsSXkDO4x1xt/3OE/Hru protocol=application/pkcs7-signature
ovLXkTAVNX9pfTQb4rC2CC9G+X/ZsRiUf53ug/9PGBDMByiqWRWUBWipWqxoBbID
/2j83fQTGopp//tKijmhyMK7/xC73p/9TezvIz1ESqJY2NwSoRo0us6mKu4bBQ3G
EtOmMJZZUToNZwgDfLODzZHGOyiT4tdUL9eCln2a5FAgN75NnCUDHdRw0zpaCVIK
El389vMl8L0irlmxBMhVYLDyxAwsB8evXkAJeYu0mLuJ0sBZAbyfSlnGr8sAZ7c4
peSUpSBMhA4lAOnUASra2tYNsvOdfiFU2V7k1QEoR4c0HBB+ORX5HElPFdgzYM6Q
yhxSNWxTqBD1CfYSHM2KNzSJnEimSeL6/bhO32tAXIK+rigywLyCDAFEpYOjLXhp
9TA5pQw5ADMzmJnYlq3H5q4kn7s7RfzUuWflQjzhU4u2YFj3lJIRpO1szyXAACTG
hJbxpwL0I2Gz4YezWnzIKWU5xTna+V+0heP+lfUfmkP9CtTZZEmxEPKkWTnCt7Fk
wUlr9DeqqO5dGd+1KT94QY7clAnb7IRIgGP/ZeGQpn6A4XRvIDwe3/kMAdWLVSR7
aYHSCl6JG9ozHGlwIR3HF8K09je/oQwhXvnzimQ=
=zjBS
</stanza>
</x>
</message>
The decoded payload is: --next
Content-type: Message/CPIM
<payload xmlns='urn:ietf:params:xml:ns:xmpp-e2e#payload'> From: Juliet Capulet <im:juliet@capulet.com>
<id>e0ffe42b28561960c6b12b944a092794b9683a38</id> To: Romeo Montague <im:romeo@montague.net>
<message DateTime: 2003-05-14T23:45:36Z
to='romeo@montague.net/orchard' Subject: Imploring
type='chat'>
<subject>Imploring</subject> Content-type: text/xml; charset=utf-8
<body>O Romeo, Romeo! Wherefore art thou Romeo?</body> Content-ID: <1234567890@capulet.com>
<body>
Wherefore art thou, Romeo?
</body>
--next
Content-Type: application/pkcs7-signature
[signed body part]
--next--
</e2e>
</message> </message>
</payload>
3.3 Encrypting Presence 4. Securing Presence
Presence stanzas may be encrypted using the syntax defined above. An In order to encrypt presence information, a sending entity MUST use
encrypted presence stanza MUST be an instance of directed presence; the following procedure:
i.e., the <presence/> element MUST possess a 'to' attribute
specifying a specific intended recipient. Presence information that
is intended for broadcasting to all subscribers MUST NOT be
encrypted.
Example: Sender generates encrypted presence ('from' address is 1. Generate an "application/cpim-pidf+xml" object defined in PIDF
stamped by sender's server): [7].
<presence to='romeo@montague.net/orchard'> 2. Encrypt and/or sign the "application/cpim-pidf+xml" object as
<x type='openpgp' xmlns='urn:ietf:params:xml:ns:xmpp-e2e'> specified in Requirement 3 of Section 2 above.
<stanza>
hQEOA+fczQLixGb6EAP/YOqZS+jgzDrXdqIyuDDJI2oxH2LXZf10LeR6EeBdGqX8
ewI8Nsf3CR4Mou58tRZ1QG5EOsCl6aylUxAiJuSe5f+Lv97dRWGQnrAQ4RNVpJ8O
jzPf+UQJ6mBZhgBgrtPB8XML7dORJqWBR69ralLcGhOtBr0CsNo7RyoZUWrfl74D
/0yJ7y3ZyHmA1gDRd9f7CZuMwdNF+xCfQtZjtAdc+t7HNsoJSNxGBeQdJbdpIaJo
jvHfiVG6jvrGDzWceyj4SnFkxOfxb+xu1x7mcmiXW0Jb58wsddttmhqBDdDd4B3H
QKnZCkyMPUcldzCBXUf4JPbC5EcUnNOmT6mth9+Qj0GJ0sAPAW2tZu5LOLVQU5Wo
zMJBZJOlaiyEv74YSYCjGNwKP9Yh+f+rBL1UkmnKqfiZVxSQo50ccPkJ45Syq85j
v8RSvYsU27bTQdCNL/ZS5aILQHryD2iXoLDk9XkzVDTBDNahOk1IWUaJwU5Qy1Lw
olEYwndAQi0ieXQklW+2HRmq5fZNslItCPJBGWmxAdGO6xyKbkbqCfq6ytw9kXjW
wAoBMgWZFfIbBh5EdBd7NO8u9bF3oDXxKO7c4dkg6WXUjJTZzEIWZCNaFa1PcW+3
/FoQ
=HT9r
</stanza>
</x>
</presence>
The decoded payload is: 3. Provide the resulting S/MIME object as the CDATA of an <e2e/>
child of a <presence/> stanza, with the <e2e/> element scoped by
the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace (note that this
namespace name adheres to the format defined in The IANA XML
Registry [14]). The <presence/> stanza MUST include a 'to'
attribute, i.e., it must be an instance of directed presence as
defined in XMPP IM [2].
<payload xmlns='urn:ietf:params:xml:ns:xmpp-e2e#payload'> Example 3: Sender generates "application/cpim-pidf+xml" object:
<id>e0ffe42b28561960c6b12b944a092794b9683a38</id>
<presence to='romeo@montague.net/orchard'>
<show>away</show>
<status>retired to the chamber</status>
</presence>
</payload>
3.4 Encrypting IQs Content-type: application/cpim-pidf+xml
IQ stanzas may be encrypted using the syntax defined above. From: Juliet Capulet <pres:juliet@capulet.com>
To: Romeo Montague <pres:romeo@montague.net>
DateTime: 2003-05-14T23:53:11Z
Example: Sender generates encrypted IQ ('from' address is stamped by Content-type: text/xml; charset=utf-8
sender's server): Content-ID: <2345678901@capulet.com>
<iq to='romeo@montague.net/orchard' type='get' id='eq7-2521'> <?xml version="1.0" encoding="UTF-8"?>
<x type='openpgp' xmlns='urn:ietf:params:xml:ns:xmpp-e2e'> <presence xmlns="urn:ietf:params:xml:ns:pidf"
<stanza> xmlns:im="urn:ietf:params:xml:ns:pidf:im"
hQEOA+fczQLixGb6EAP/ejh9XMAbiFTA4WRIOyBXiiiAHtKCe/AKcn5I1M+HI/AR entity="pres:juliet@capulet.com">
8K3LdWbg4CzuBfDv/Sb9zesVXIZZEvHHQF6ihjxQpW0V0a1lvgDq49Dc0bR4uPsz <tuple id="h40zny"
sFRr9auTnouZ5062ubwGk3Uic8CChC/JZxlfdRXO4ac3jS+uzafC0aJ9hkn0QkoD <status>
/0b9PpTC3OYq5JoMpFSvBHeHOyixqKQh6xhBgJLzr2/6ZId/axOpgq7ru1GyYmHg <basic>open</basic>
+dg/wuizJLgMaSSLwmEM58JiGKs44RHcQMUlnEruQvSbbCCNKIaLCMVQPLXS+oaD <im:im>away</im:im>
Ly2ZG8BW+lb0j0d2E0dXbM30TvTfCW9w76xvOnX/BLRT0sA6AVmuJLz6+UN55roD </status>
dE7HncBV0J/NmWksTHL/e4521O9aWSrqTYFsG6Fvvu7In5o0iKHIkLVzosW49zA9 <note xml:lang="en">retired to the chamber</note>
McDna2krEtjWCsx5feHbxGrBWOpuPPHqD+uuSvD7f7RLWOKvW+Jz2/OXBOJUJ2+x <timestamp>2003-05-14T23:53:11Z</timestamp>
+xX9uaTdP08TlfBa4BrsX5mM+eFhkPC5oDg3O8Jy612A2Jf8IRQ4lYZDoz6SWoHl </tuple>
scfHcSWjqont7hUTXtdTEnHcs9UkaxXlrbwLBaEfix0J7ALgjAESfEjG88eHm5oj </presence>
49I9rju8kw+HEsSl/moI+icDmuc0mN7bjOcKM3rIeU/roqWD0llWFIyWWrMNLg==
=6H0T
</stanza>
</x>
</iq>
The decoded payload is: Example 4: Sender generates signed presence (the 'from' address on
the XMPP presence stanza is stamped by sender's server):
<payload xmlns='urn:ietf:params:xml:ns:xmpp-e2e#payload'> <presence to='romeo@montague.net/orchard'>
<id>e0ffe42b28561960c6b12b944a092794b9683a38</id> <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
<iq to='romeo@montague.net/orchard' type='get' id='eq7-2521'> Content-Type: multipart/signed; boundary=next;
<query xmlns='jabber:iq:version'/> micalg=sha1;
</iq> protocol=application/pkcs7-signature
</payload>
4. Signing Encrypted Content --next
Content-type: application/cpim-pid+xml
OpenPGP and S/MIME both allow an entity to either encrypt then sign, From: Juliet Capulet <pres:juliet@capulet.com>
or sign then encrypt. When signing first, the signatories are To: Romeo Montague <pres:romeo@montague.net>
obscured by the encryption; when encrypting first, the signatories DateTime: 2003-05-14T23:53:11Z
are exposed but the signatures can be verified without decrypting.
Because in XMPP the signatories are exposed by the very act of
exchanging a stanza (since the 'from' and 'to' addresses must be
exposed for routing purposes), there would be no use in signing first
and encrypting second. Therefore, if signing is desired, it SHOULD
be performed after encrypting.
5. Signing Broadcasted Presence Content-type: text/xml; charset=utf-8
Content-ID: <2345678901@capulet.com>
An entity may want to sign presence information for broadcasting to <?xml version="1.0" encoding="UTF-8"?>
all subscribers (i.e., the presence stanza is not directed to a <presence xmlns="urn:ietf:params:xml:ns:pidf"
particular recipient, but is sent to all other entites that that have xmlns:im="urn:ietf:params:xml:ns:pidf:im"
subscribed to the sender's presence). Because encrypted presence entity="pres:juliet@capulet.com">
MUST be directed to a particular recipient, signed presence for <tuple id="h40zny"
broadcasting MUST NOT be encrypted, only signed. However, there is <status>
little to no value in signing the entire stanza; therefore it is <basic>open</basic>
enough to sign only the user-provided CDATA of the <status/> element <im:im>away</im:im>
(note that this requires a signed presence broadcast to include some </status>
CDATA in the <status/> element). The process is as follows: <note xml:lang="en">retired to the chamber</note>
<timestamp>2003-05-14T23:53:11Z</timestamp>
</tuple>
</presence>
--next
Content-Type: application/pkcs7-signature
1. User provides CDATA for the <status/> element. [signed body part]
2. Client application signs CDATA using OpenPGP or S/MIME. --next--
</e2e>
</presence>
3. Client application inserts signed ASCII output as CDATA of the 5. Secure Communications Through a Gateway
<signed/> child of an <x/> element that is scoped by the
'urn:ietf:params:xml:ns:xmpp-e2e' namespace and that includes a
'type' attribute whose value is either "openpgp" or "smime".
4. Client application adds <x/> element to remainder of presence A common method for achieving interoperability between two disparate
stanza and sends to server with no 'to' attribute. services is through the use of a "gateway" that interprets the
protocols of each service and translates them into the protocols of
the other. CPIM [8] and CPP [9] define the common profiles to be used
for interoperability between instant messaging and presence services
that comply with RFC 2779 [3]. In the case of communications between
an XMPP service and a non-XMPP service, we can visualize this
relationship as follows:
5. Server stamps 'from' address, enabling recipient to check bare +-------------+ +-------------+ +-------------+
JID (user@domain) of 'from' address against User-IDs defined in | | | | | |
the sender's key or certificate. | XMPP | | CPIM/CPP | | Non-XMPP |
| Service | <----> | Gateway | <----> | Service |
| | | | | |
+-------------+ +-------------+ +-------------+
Example: Sender generates signed presence: The end-to-end encryption method defined herein enables the exchange
of encrypted and/or signed instant messages and presence through
CPIM/CPP gateways. In particular:
<presence> o When a gateway receives a secured XMPP message or presence stanza
<show>away</show> from the XMPP service that addressed to a user on the non-XMPP
<status>retired to the chamber</status> service, it MUST remove the XMPP "wrapper" (everything down to and
<x type='openpgp' xmlns='urn:ietf:params:xml:ns:xmpp-e2e'> including the <e2e> and </e2e> tags) in order to reveal the
<signed> multipart S/MIME object, then route the object to the non-XMPP
iD8DBQE+kgpNEWF4x4jKHUYRAuthAJ9L1BjML9GIpagVGbEEJr0C7F3k9ACeJRL4 service (first wrapping it in the protocol used by the non-XMPP
obxiSG72h3ggH0Xr3BmGyjE= service if necessary).
=T4rw
</signed> o When a gateway receives a secured non-XMPP instant message or
</x> presence document from the non-XMPP service that is addressed to a
</presence> user on the XMPP service, it MUST remove the non-XMPP "wrapper"
(if any) in order to reveal the multipart S/MIME object, wrap the
object in an XMPP message or presence "wrapper" (including the
<e2e> and </e2e> tags), and then route the XMPP stanza to the XMPP
service.
6. IANA Considerations 6. IANA Considerations
A URN sub-namespace for signed and encrypted content in the A URN sub-namespace for signed and encrypted content in the
Extensible Messaging and Presence Protocol (XMPP) is defined as Extensible Messaging and Presence Protocol (XMPP) is defined as
follows. follows.
URI: urn:ietf:params:xml:ns:xmpp-e2e URI: urn:ietf:params:xml:ns:xmpp-e2e
Specification: [RFCXXXX] Specification: [RFCXXXX]
Description: This is the XML namespace name for signed and encrypted Description: This is the XML namespace name for signed and encrypted
content in the Extensible Messaging and Presence Protocol as content in the Extensible Messaging and Presence Protocol as
defined by [RFCXXXX]. defined by [RFCXXXX].
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org> Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
7. Security Considerations 7. Security Considerations
Replay attacks are made more difficult using this method because of Detailed security considerations for instant messaging and presence
the inclusion of a unique ID in the encrypted object. Key exchange protocols are given in RFC 2779 [3], specifically in Sections 5.1
may rely on the web of trust model used on the OpenPGP keys network. through 5.4.
There is no method to check a fingerprint or ownership of a key other
than checking the user IDs on a key. A key or certificate SHOULD The end-to-end security method defined here MAY result in exchanging
have associated with it the Jabber ID of the sender. One of the secured instant messages and presence information through a gateway
User-IDs defined in a sender's key or certificate MUST be the bare that implements CPIM [8] and CPP [9]. Such a gateway MUST be
JID (user@domain) of the 'from' address stamped by the sender's compliant with the minimum security requirements of the instant
server on the XML stanzas that the sender generates; a client that messaging and presence protocols with which it interfaces. The
receives signed or encypted stanzas from the sender MUST check the introduction of gateways to the security model of instant messaging
sender's bare JID against the User-IDs defined in the sender's key or and presence in RFC 2779 also introduces some new risks. End-to-end
certificate, and SHOULD discard the stanza or warn the recipient security properties (especially confidentiality and integrity)
before presenting the stanza to the recipient if the bare JID does between instant messaging and presence user agents that interface
not match. through a CPIM/CPP gateway can be provided only if common formats are
supported. The need for end-to-end security is thus met by this
specification through the use of common formats, specifically MSGFMT
[6] for instant messages and PIDF [7] for presence information.
Common formats are further ensured by requiring the use of multipart
S/MIME [10] objects, as well as CMS [11] EnvelopeData for encryption
and CMS [11] SignedData for signing. Finally, the algorithm used
SHOULD be AES [12], since it is expected that AES best suits the
capabilities of many platforms. However, an IETF specification for
the use of AES is still incomplete at the time of writing.
Normative References Normative References
[1] Saint-Andre, P. and J. Miller, "XMPP Core (draft-ietf-xmpp-core- [1] Saint-Andre, P. and J. Miller, "XMPP Core",
10, work in progress)", April 2003. draft-ietf-xmpp-core-12 (work in progress), May 2003.
[2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging (draft- [2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging",
ietf-xmpp-im-09, work in progress)", April 2003. draft-ietf-xmpp-im-11 (work in progress), May 2003.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000.
[4] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000, <http://
www.ietf.org/rfc/rfc2778.txt>.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP [6] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging
Message Format", RFC 2440, November 1998. Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in
progress), January 2003.
[5] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC [7] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. and
J. Peterson, "CPIM Presence Information Data Format",
draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003.
[8] Crocker, D. and J. Peterson, "Common Profile for Instant
Messaging (CPIM)", draft-ietf-impp-im-02 (work in progress),
March 2003.
[9] Crocker, D. and J. Peterson, "Common Profile for Presence
(CPP)", draft-ietf-impp-pres-02 (work in progress), March 2003.
[10] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999. 2633, June 1999.
Informative References [11] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
August 2002.
[6] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for [12] Housley, R. and J. Schaad, "Use of the AES Encryption Algorithm
Presence and Instant Messaging", RFC 2779, February 2000, and RSA-OAEP Key Transport in CMS", draft-ietf-smime-aes-alg-06
<http://www.ietf.org/rfc/rfc2779.txt>. (work in progress), January 2003.
[7] Mealling, M., "The IANA XML Registry", draft-mealling-iana- [13] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
xmlns-registry-04 (work in progress), June 2002. Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995.
Authors' Addresses [14] Mealling, M., "The IANA XML Registry",
draft-mealling-iana-xmlns-registry-04 (work in progress), June
2002.
Author's Address
Peter Saint-Andre Peter Saint-Andre
Jabber Software Foundation Jabber Software Foundation
EMail: stpeter@jabber.org EMail: stpeter@jabber.org
URI: http://www.jabber.org/people/stpeter.php URI: http://www.jabber.org/people/stpeter.php
Joe Hildebrand Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e
Jabber, Inc.
EMail: jhildebrand@jabber.com
URI: http://www.jabber.org/people/hildjj.php
Appendix A. XML Schemas
The following XML schemas are descriptive, not normative.
A.1 urn:ietf:params:xml:ns:xmpp-e2e The following XML schema is descriptive, not normative.
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xs:schema <xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-e2e' targetNamespace='urn:ietf:params:xml:ns:xmpp-e2e'
xmlns='urn:ietf:params:xml:ns:xmpp-e2e' xmlns='urn:ietf:params:xml:ns:xmpp-e2e'
elementFormDefault='qualified'> elementFormDefault='qualified'>
<xs:element name='x'> <xs:element name='e2e' type='xs:string'/>
<xs:complexType>
<xs:choice>
<xs:element ref='signed' minOccurs='0' maxOccurs='1'/>
<xs:element ref='stanza' minOccurs='0' maxOccurs='1'/>
</xs:choice>
<xs:attribute name='type' use='required'/>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='openpgp'/>
<xs:enumeration value='smime'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name='signed' type='xs:string'/>
<xs:element name='stanza' type='xs:string'/>
</xs:schema>
A.2 urn:ietf:params:xml:ns:xmpp-e2e#payload
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-e2e#payload'
xmlns='urn:ietf:params:xml:ns:xmpp-e2e#payload'
elementFormDefault='qualified'>
<xs:element name='payload'>
<xs:complexType>
<xs:element ref='id' maxOccurs='1'/>
<xs:any namespace='jabber:client' maxOccurs='1'/>
</xs:complexType>
</xs:element>
<xs:element name='id' type='xs:string'/>
</xs:schema> </xs:schema>
Appendix B. Revision History Appendix B. Revision History
Note to RFC Editor: please remove this entire appendix, and the Note to RFC Editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to publication. corresponding entries in the table of contents, prior to publication.
B.1 Changes from draft-ietf-xmpp-e2e-01 B.1 Changes from draft-ietf-xmpp-e2e-02
o Completely revised to use CPIM/CPP.
B.2 Changes from draft-ietf-xmpp-e2e-01
o Removed old Section 6 (Signalling Support via Presence) -- the o Removed old Section 6 (Signalling Support via Presence) -- the
ability to sign broadcasted presence made it redundant. ability to sign broadcasted presence made it redundant.
o Made small editorial changes to address RFC Editor requirements. o Made small editorial changes to address RFC Editor requirements.
B.2 Changes from draft-ietf-xmpp-e2e-00 B.3 Changes from draft-ietf-xmpp-e2e-00
o Added support for all stanza types. o Added support for all stanza types.
o Specified that the full stanza is encrypted. o Specified that the full stanza is encrypted.
o Added support for S/MIME in addition to OpenPGP. o Added support for S/MIME in addition to OpenPGP.
o Specified that encrypted presence must be directed to a specific o Specified that encrypted presence must be directed to a specific
recipient. recipient.
o Specified order of encrypting and signing. o Specified order of encrypting and signing.
o Added support for signing broadcasted presence. o Added support for signing broadcasted presence.
o Added IANA considerations. o Added IANA considerations.
o Changed namespace to 'urn:ietf:params:xml:ns:xmpp-e2e'. o Changed namespace to 'urn:ietf:params:xml:ns:xmpp-e2e'.
o Added XML schema. o Added XML schema.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
 End of changes. 75 change blocks. 
311 lines changed or deleted 328 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/