draft-ietf-xmpp-e2e-03.txt   draft-ietf-xmpp-e2e-04.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Jabber Software Foundation Internet-Draft Jabber Software Foundation
Expires: November 18, 2003 May 20, 2003 Expires: December 28, 2003 June 29, 2003
End-to-End Object Encryption in XMPP End-to-End Object Encryption in XMPP
draft-ietf-xmpp-e2e-03 draft-ietf-xmpp-e2e-04
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 30 skipping to change at page 1, line 30
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 November 18, 2003. This Internet-Draft will expire on December 28, 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 defines a method for end-to-end object signing and This document defines a method for end-to-end object signing and
encryption in the Extensible Messaging and Presence Protocol (XMPP). encryption in the Extensible Messaging and Presence Protocol (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. Securing Messages . . . . . . . . . . . . . . . . . . . . . . 6 3. Securing Messages . . . . . . . . . . . . . . . . . . . . . . 6
4. Securing Presence . . . . . . . . . . . . . . . . . . . . . . 8 4. Securing Presence . . . . . . . . . . . . . . . . . . . . . . 8
5. Secure Communications Through a Gateway . . . . . . . . . . . 10 5. Securing Arbitrary XMPP Data . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Rules for S/MIME Generation and Handling . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6.1 Certificate Enrollment . . . . . . . . . . . . . . . . . . . . 12
Normative References . . . . . . . . . . . . . . . . . . . . . 13 6.2 Certificate Retrieval . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 6.3 Certificate Names . . . . . . . . . . . . . . . . . . . . . . 12
A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . 15 6.4 Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 13
B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 16 6.5 Attachment of Signatures . . . . . . . . . . . . . . . . . . . 13
B.1 Changes from draft-ietf-xmpp-e2e-02 . . . . . . . . . . . . . 16 6.6 Inclusion of Certificates . . . . . . . . . . . . . . . . . . 13
B.2 Changes from draft-ietf-xmpp-e2e-01 . . . . . . . . . . . . . 16 6.7 Mandatory to Implement Technologies . . . . . . . . . . . . . 13
B.3 Changes from draft-ietf-xmpp-e2e-00 . . . . . . . . . . . . . 16 7. Secure Communications Through a Gateway . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1 Content-type Registration for "application/xmpp+xml" . . . . . 15
8.2 XML Namespace Name for e2e Data in XMPP . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
Normative References . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . 20
B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 21
B.1 Changes from draft-ietf-xmpp-e2e-03 . . . . . . . . . . . . . 21
B.2 Changes from draft-ietf-xmpp-e2e-02 . . . . . . . . . . . . . 21
B.3 Changes from draft-ietf-xmpp-e2e-01 . . . . . . . . . . . . . 21
B.4 Changes from draft-ietf-xmpp-e2e-00 . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 23
1. Introduction 1. Introduction
This document define a method for end-to-end signing and encryption This document define a method for end-to-end signing and encryption
in the Extensible Messaging and Presence Protocol (XMPP). (For in the Extensible Messaging and Presence Protocol (XMPP). (For
information about XMPP, see XMPP Core [1] and XMPP IM [2].) The information about XMPP, see XMPP Core [1] and XMPP IM [2].) The
method defined herein enables a sender to encrypt and/or sign an method defined herein enables a sender to encrypt and/or sign an
instant message sent to a specific recipient, encrypt and/or sign instant message sent to a specific recipient, encrypt and/or sign
presence information that is directed to a specific user, and sign presence information that is directed to a specific user, and sign
presence information that is broadcasted to a specific user. This presence information that is broadcasted to a specific user. This
document thereby helps the XMPP specifications meet the requirements document thereby helps the XMPP specifications meet the requirements
defined in RFC 2779 [3]. defined in RFC 2779 [3].
1.1 Terminology 1.1 Terminology
This document inherits terminology defined in XMPP Core [1] and RFC This document inherits terminology defined in RFC 2633 [4], RFC 2778
2778 [4]. [5], RFC 3369 [6], and XMPP Core [1].
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 [5]. 2119 [7].
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 52 skipping to change at page 4, line 52
5.3.1) 5.3.1)
* The protocol MUST provide A means of ensuring that no other * The protocol MUST provide A means of ensuring that no other
PRINCIPAL C can see the content of M. (Section 5.4.6) PRINCIPAL C can see the content of M. (Section 5.4.6)
* The protocol MUST provide A means of ensuring that no other * The protocol MUST provide A means of ensuring that no other
PRINCIPAL C can tamper with M, and B means to verify that no PRINCIPAL C can tamper with M, and B means to verify that no
tampering has occurred. (Section 5.4.7) tampering has occurred. (Section 5.4.7)
2. The method defined MUST enable interoperability with non-XMPP 2. The method defined MUST enable interoperability with non-XMPP
messaging systems that support Common Presence and Instant messaging systems that support the Common Presence and Instant
Messaging (CPIM) as defined by the Instant Messaging and Presence Messaging (CPIM) specifications defined by the Instant Messaging
(IMPP) Working Group. Therefore: and Presence (IMPP) Working Group. Therefore:
* Prior to encrypting or signing, the format of an instant * Prior to encrypting or signing, the format of an instant
message must conform to the CPIM Message Format defined in message must conform to the CPIM Message Format defined in
MSGFMT [6]. MSGFMT [8].
* Prior to encrypting or signing, the format of presence * Prior to encrypting or signing, the format of presence
information must conform to the CPIM Presence Information Data information must conform to the CPP Presence Information Data
Format defined in PIDF [7]. Format defined in PIDF [9].
3. The method MUST follow the procedures (including the specific 3. The method MUST follow the required procedures (including the
algorithms) defined in Common Profile for Instant Messaging [8] specific algorithms) defined in Common Profile for Instant
and Common Profile for Presence [9]. In particular, these Messaging [10] and Common Profile for Presence [11]. In
documents specify: particular, these documents specify:
* Encryption MUST use S/MIME [10] encryption with CMS [11] * Encryption MUST use S/MIME [4] encryption with CMS [6]
EnvelopeData. EnvelopeData.
* Signing MUST use S/MIME [10] signatures with CMS [11] * Signing MUST use S/MIME [4] signatures with CMS [6]
SignedData. SignedData.
* The S/MIME algorithm SHOULD be AES [12]. 4. In order to enable interoperable implementations, sending and
receiving applications MUST implement the algorithms defined
under Section 6.7.
3. Securing Messages 3. Securing Messages
In order to encrypt a message, a sending entity MUST use the In order to encrypt a message, a sending entity MUST use the
following procedure: following procedure:
1. Generate a "Message/CPIM" object as defined in MSGFMT [6]. 1. Generate a "Message/CPIM" object as defined in MSGFMT [8].
2. Encrypt and/or sign both the headers and content of the "Message/ 2. Encrypt and/or sign both the headers and content of the "Message/
CPIM" object as specified in Requirement 3 of Section 2 above. CPIM" object as specified in Requirement 3 of Section 2 above.
3. Provide the resulting multipart S/MIME object (see RFC 1847 [13]) 3. Provide the resulting multipart S/MIME object (see RFC 1847 [12])
as the CDATA of an <e2e/> child of a <message/> stanza, with the 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' <e2e/> element scoped by the 'urn:ietf:params:xml:ns:xmpp-e2e'
namespace (note that this namespace name adheres to the format namespace (note that this namespace name adheres to the format
defined in The IANA XML Registry [14]). defined in The IANA XML Registry [13]).
Example 1: Sender generates "Message/CPIM" object: Example 1: Sender generates "Message/CPIM" object:
Content-type: Message/CPIM Content-type: Message/CPIM
From: Juliet Capulet <im:juliet@capulet.com> From: Juliet Capulet <im:juliet@capulet.com>
To: Romeo Montague <im:romeo@montague.net> To: Romeo Montague <im:romeo@montague.net>
DateTime: 2003-05-14T11:45:36Z DateTime: 2003-05-14T11:45:36Z
Subject: Imploring Subject: Imploring
Content-type: text/xml; charset=utf-8 Content-type: text/plain; charset=utf-8
Content-ID: <1234567890@capulet.com> Content-ID: <1234567890@capulet.com>
<body>
Wherefore art thou, Romeo? Wherefore art thou, Romeo?
</body>
Example 2: Sender generates signed message (the 'from' address on the Example 2: Sender generates signed message (the 'from' address on the
XMPP message stanza is stamped by sender's server): 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'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'> <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
<![CDATA[
Content-Type: multipart/signed; boundary=next; Content-Type: multipart/signed; boundary=next;
micalg=sha1; micalg=sha1;
protocol=application/pkcs7-signature protocol=application/pkcs7-signature
--next --next
Content-type: Message/CPIM Content-type: Message/CPIM
From: Juliet Capulet <im:juliet@capulet.com> From: Juliet Capulet <im:juliet@capulet.com>
To: Romeo Montague <im:romeo@montague.net> To: Romeo Montague <im:romeo@montague.net>
DateTime: 2003-05-14T23:45:36Z DateTime: 2003-05-14T23:45:36Z
Subject: Imploring Subject: Imploring
Content-type: text/xml; charset=utf-8 Content-type: text/plain; charset=utf-8
Content-ID: <1234567890@capulet.com> Content-ID: <1234567890@capulet.com>
<body>
Wherefore art thou, Romeo? Wherefore art thou, Romeo?
</body>
--next --next
Content-Type: application/pkcs7-signature Content-Type: application/pkcs7-signature
[signed body part] [signed body part]
--next-- --next--
]]>
</e2e> </e2e>
</message> </message>
4. Securing Presence 4. Securing Presence
In order to encrypt presence information, a sending entity MUST use In order to encrypt presence information, a sending entity MUST use
the following procedure: the following procedure:
1. Generate an "application/cpim-pidf+xml" object defined in PIDF 1. Generate an "application/pidf+xml" object as defined in PIDF [9].
[7].
2. Encrypt and/or sign the "application/cpim-pidf+xml" object as 2. Encrypt and/or sign the "application/pidf+xml" object as
specified in Requirement 3 of Section 2 above. specified in Requirement 3 of Section 2 above.
3. Provide the resulting S/MIME object as the CDATA of an <e2e/> 3. Provide the resulting S/MIME object as the CDATA of an <e2e/>
child of a <presence/> stanza, with the <e2e/> element scoped by child of a <presence/> stanza, with the <e2e/> element scoped by
the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace (note that this the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace (note that this
namespace name adheres to the format defined in The IANA XML namespace name adheres to the format defined in The IANA XML
Registry [14]). The <presence/> stanza MUST include a 'to' Registry [13]). The <presence/> stanza MUST include a 'to'
attribute, i.e., it must be an instance of directed presence as attribute, i.e., it must be an instance of directed presence as
defined in XMPP IM [2]. defined in XMPP IM [2].
Example 3: Sender generates "application/cpim-pidf+xml" object: Example 3: Sender generates "application/pidf+xml" object:
Content-type: application/cpim-pidf+xml
From: Juliet Capulet <pres:juliet@capulet.com>
To: Romeo Montague <pres:romeo@montague.net>
DateTime: 2003-05-14T23:53:11Z
Content-type: text/xml; charset=utf-8
Content-ID: <2345678901@capulet.com>
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:im="urn:ietf:params:xml:ns:pidf:im" xmlns:im="urn:ietf:params:xml:ns:pidf:im"
entity="pres:juliet@capulet.com"> entity="pres:juliet@capulet.com">
<tuple id="h40zny" <tuple id="h40zny"
<status> <status>
<basic>open</basic> <basic>open</basic>
<im:im>away</im:im> <im:im>away</im:im>
</status> </status>
skipping to change at page 8, line 48 skipping to change at page 9, line 4
entity="pres:juliet@capulet.com"> entity="pres:juliet@capulet.com">
<tuple id="h40zny" <tuple id="h40zny"
<status> <status>
<basic>open</basic> <basic>open</basic>
<im:im>away</im:im> <im:im>away</im:im>
</status> </status>
<note xml:lang="en">retired to the chamber</note> <note xml:lang="en">retired to the chamber</note>
<timestamp>2003-05-14T23:53:11Z</timestamp> <timestamp>2003-05-14T23:53:11Z</timestamp>
</tuple> </tuple>
</presence> </presence>
Example 4: Sender generates signed presence (the 'from' address on Example 4: Sender generates signed presence (the 'from' address on
the XMPP presence stanza is stamped by sender's server): the XMPP presence stanza is stamped by sender's server):
<presence to='romeo@montague.net/orchard'> <presence to='romeo@montague.net/orchard'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'> <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
<![CDATA[
Content-Type: multipart/signed; boundary=next; Content-Type: multipart/signed; boundary=next;
micalg=sha1; micalg=sha1;
protocol=application/pkcs7-signature protocol=application/pkcs7-signature
--next --next
Content-type: application/cpim-pid+xml Content-type: application/pidf+xml
From: Juliet Capulet <pres:juliet@capulet.com>
To: Romeo Montague <pres:romeo@montague.net>
DateTime: 2003-05-14T23:53:11Z
Content-type: text/xml; charset=utf-8
Content-ID: <2345678901@capulet.com> Content-ID: <2345678901@capulet.com>
<?xml version="1.0" encoding="UTF-8"?> <xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:im="urn:ietf:params:xml:ns:pidf:im" xmlns:im="urn:ietf:params:xml:ns:pidf:im"
entity="pres:juliet@capulet.com"> entity="pres:juliet@capulet.com">
<tuple id="h40zny" <tuple id="h40zny"
<status> <status>
<basic>open</basic> <basic>open</basic>
<im:im>away</im:im> <im:im>away</im:im>
</status> </status>
<note xml:lang="en">retired to the chamber</note> <note xml:lang="en">retired to the chamber</note>
<timestamp>2003-05-14T23:53:11Z</timestamp> <timestamp>2003-05-14T23:53:11Z</timestamp>
</tuple> </tuple>
</presence> </presence>
--next --next
Content-Type: application/pkcs7-signature Content-Type: application/pkcs7-signature
[signed body part] [signed body part]
--next-- --next--
]]>
</e2e> </e2e>
</presence> </presence>
5. Secure Communications Through a Gateway 5. Securing Arbitrary XMPP Data
The foregoing sections of this document describe how to secure "least
common denominator" messaging and presence data of the kind that can
be directly translated into the MSGFMT or PIDF formats. However, XMPP
possesses a third base-level stanza type (<iq/>) in addition to
<message/> and <presence/>, as well as the ability to include
extended XML data within arbitrary child elements of the three core
stanza types. Therefore it would be desirable to secure such data if
possible.
Because MSGFMT [8] specifies the ability to encapsulate any MIME
type, the approach taken in this document is to include arbitrary
XMPP data in a new MIME type, "application/xmpp+xml". The root
element for this MIME type is <xmpp/>, and the root element MUST
contain one and only one child element, corresponding to one of the
XMPP stanza types (i.e., message, presence, or iq) if the default
namespace is 'jabber:client' or 'jabber:server' as defined in XMPP
Core [1].
The following examples illustrate the structure of the "application/
xmpp+xml" MIME type.
Example 5: Message stanza with extended data contained in
"application/xmpp+xml" MIME type:
<?xml version='1.0' encoding='UTF-8'?>
<xmpp xmlns='jabber:client'>
<message
from='iago@shakespeare.lit/pda'
to='emilia@shakespeare.lit/cell'>
<body>
I told him what I thought, and told no more
Than what he found himself was apt and true.
</body>
<evil xmlns='http://jabber.org/protocol/evil'/>
</message>
</xmpp>
Example 6: Presence stanza with extended data contained in
"application/xmpp+xml" MIME type:
<?xml version='1.0' encoding='UTF-8'?>
<xmpp xmlns='jabber:client'>
<presence from='iago@shakespeare.lit/pda'>
<show>dnd</show>
<status>Fomenting dissension</status>
<evil xmlns='http://jabber.org/protocol/evil'/>
</presence>
</xmpp>
Example 7: IQ stanza with extended data contained in "application/
xmpp+xml" MIME type:
<?xml version='1.0' encoding='UTF-8'?>
<xmpp xmlns='jabber:client'>
<iq type='result'
from='iago@shakespeare.lit/pda'
to='emilia@shakespeare.lit/cell'
id='evil1'>
<query xmlns='jabber:iq:version'>
<name>Stabber</name>
<version>666</version>
<os>FiendOS</os>
</query>
<evil xmlns='http://jabber.org/protocol/evil'/>
</iq>
</xmpp>
6. Rules for S/MIME Generation and Handling
6.1 Certificate Enrollment
S/MIME v3 does not specify how to obtain a certificate from a
certificate authority, but instead mandates that every sending agent
must already have a certificate. The PKIX Working Group has, at the
time of this writing, produced two separate standards for certificate
enrollment: CMP (RFC 2510) and CMC (RFC 2792). Which method to use
for certificate enrollment is outside the scope of this document.
6.2 Certificate Retrieval
A receiving agent MUST provide some certificate retrieval mechanism
in order to gain access to certificates for recipients of digital
envelopes. This document does not cover how S/MIME agents handle
certificates, only what they do after a certificate has been
validated or rejected. S/MIME certification issues are covered in RFC
2632 [14].
At a minimum, for initial S/MIME deployment, a user agent could
automatically generate a message to an intended recipient requesting
that recipient's certificate in a signed return message. Receiving
and sending agents SHOULD also provide a mechanism to allow a user to
"store and protect" certificates for correspondents in such a way so
as to guarantee their later retrieval.
6.3 Certificate Names
End-entity certificates used in the context of this document SHOULD
contain a XMPP address as described in XMPP Core [1]. The address
SHOULD be in the form of a "bare JID", i.e., <node@domain>, although
any valid JID form MAY be used. The JID SHOULD be in the
subjectAltName extension, and SHOULD NOT be in the subject
distinguished name.
The value of the JID contained in the XMPP 'from' attribute SHOULD
match the JID provided in the signer's certificate, with the
exception that the resource identifier portion of the JID contained
in the 'from' attribute MAY be ignored for matching purposes.
Receiving agents MUST recognize XMPP addresses (JIDs) in the
subjectAltName field.
Receiving agents SHOULD check that sending JID matches a JID provided
in the signer's certificate, with the exception that the resource
identifier portion of the JID contained in the 'from' attribute MAY
be ignored for matching purposes. A receiving agent SHOULD provide
some explicit alternate processing of the message if this comparison
fails, which may be to display a message that shows the recipient the
addresses in the certificate or other certificate details.
The subject alternative name extension is used in S/MIME as the
preferred means to convey the JID that corresponds to the entity for
this certificate. Any JIDs present SHOULD be encoded using the
otherName CHOICE of the subjectAltName type, where the type-id is
"xmpp" and the value is the bare JID of the entity.
6.4 Transfer Encoding
According to various S/MIME specifications for message wrapping, CMS
objects MAY optionally be wrapped in MIME to dynamically support
7-bit transport. Because it is expected that XMPP will not be used to
interface with older 7-bit systems, this outer wrapping is NOT
REQUIRED for XMPP transport, and generally SHOULD NOT be applied in a
homogeneous XMPP environment or in an environment that supports
XMPP-CPIM gateways.
6.5 Attachment of Signatures
Sending agents SHOULD attach a signature to each encrypted message or
presence stanza, but are NOT REQUIRED to do so.
6.6 Inclusion of Certificates
Sending agents are NOT REQUIRED to include the sender's certificate
along with each encrypted message or presence stanza.
6.7 Mandatory to Implement Technologies
At a minimum, all implementations MUST support the following CMS
algorithms as defined in RFC 3370 [15]:
for digest: DIGEST-MD5
for signing: RSA
for content encryption: Triple-DES CBC
7. Secure Communications Through a Gateway
A common method for achieving interoperability between two disparate A common method for achieving interoperability between two disparate
services is through the use of a "gateway" that interprets the services is through the use of a "gateway" that interprets the
protocols of each service and translates them into the protocols of 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 the other. The CPIM specifications (specifically MSGFMT [8] and PIDF
for interoperability between instant messaging and presence services [9] define the common profiles to be used for interoperability
that comply with RFC 2779 [3]. In the case of communications between between instant messaging and presence services that comply with RFC
an XMPP service and a non-XMPP service, we can visualize this 2779 [3]. In the case of communications between an XMPP service and a
relationship as follows: non-XMPP service, we can visualize this relationship as follows:
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +------------+
| | | | | | | | | | | |
| XMPP | | CPIM/CPP | | Non-XMPP | | XMPP | | XMPP-CPIM | | Non-XMPP |
| Service | <----> | Gateway | <----> | Service | | Service | <----> | Gateway | <----> | Service |
| | | | | | | | | | | |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +------------+
The end-to-end encryption method defined herein enables the exchange The end-to-end encryption method defined herein enables the exchange
of encrypted and/or signed instant messages and presence through of encrypted and/or signed instant messages and presence through an
CPIM/CPP gateways. In particular: XMPP-CPIM gateways. In particular:
o When a gateway receives a secured XMPP message or presence stanza o When a gateway receives a secured XMPP message or presence stanza
from the XMPP service that addressed to a user on the non-XMPP from the XMPP service that is addressed to a user on the non-XMPP
service, it MUST remove the XMPP "wrapper" (everything down to and service, it MUST remove the XMPP "wrapper" (everything down to and
including the <e2e> and </e2e> tags) in order to reveal the including the <e2e> and </e2e> tags) in order to reveal the
multipart S/MIME object, then route the object to the non-XMPP multipart S/MIME object, then route the object to the non-XMPP
service (first wrapping it in the protocol used by the non-XMPP service (first wrapping it in the protocol used by the non-XMPP
service if necessary). service if necessary).
o When a gateway receives a secured non-XMPP instant message or o When a gateway receives a secured non-XMPP instant message or
presence document from the non-XMPP service that is addressed to a presence document from the non-XMPP service that is addressed to a
user on the XMPP service, it MUST remove the non-XMPP "wrapper" 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 (if any) in order to reveal the multipart S/MIME object, wrap the
object in an XMPP message or presence "wrapper" (including the object in an XMPP message or presence "wrapper" (including the
<e2e> and </e2e> tags), and then route the XMPP stanza to the XMPP <e2e> and </e2e> tags), and then route the XMPP stanza to the XMPP
service. service.
6. IANA Considerations The wrapped S/MIME object MUST be immutable and MUST NOT be modified
by an XMPP-CPIM gateway.
8. IANA Considerations
8.1 Content-type Registration for "application/xmpp+xml"
To: ietf-types@iana.org
Subject: Registration of MIME media type application/xmpp+xml
MIME media type name: application
MIME subtype name: xmpp+xml
Required parameters: (none)
Optional parameters: charset Indicates the character encoding of the
enclosed XML; the default encoding is UTF-8.
Encoding considerations: Contains XML, which can employ 8-bit
characters, depending on the character encoding used.
Security considerations: Contains a message, presence information, or
IQ (request-response) data in XMPP, which may be considered
private. Appropriate precautions should be adopted to limit
disclosure of this information.
Interoperability considerations: (none)
Specification: [RFCXXXX]
Applications which use this media type: XMPP-compliant instant
messaging and presence systems.
Additional information: (none)
Person and email address to contact for further information: IETF,
XMPP Working Group, <xmppwg@jabber.org>
Intended usage: COMMON
Author/Change controller: IETF, XMPP Working Group
8.2 XML Namespace Name for e2e Data in XMPP
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 9. Security Considerations
Detailed security considerations for instant messaging and presence This entire document discusses security. Detailed security
protocols are given in RFC 2779 [3], specifically in Sections 5.1 considerations for instant messaging and presence protocols are given
through 5.4. in RFC 2779 [3] (Sections 5.1 through 5.4), and for XMPP in
particular are given in XMPP Core [1] (Sections 12.1 through 12.6).
The end-to-end security method defined here MAY result in exchanging The end-to-end security method defined here MAY result in exchanging
secured instant messages and presence information through a gateway secured instant messages and presence information through a gateway
that implements CPIM [8] and CPP [9]. Such a gateway MUST be that implements the CPIM specifications. Such a gateway MUST be
compliant with the minimum security requirements of the instant compliant with the minimum security requirements of the instant
messaging and presence protocols with which it interfaces. The messaging and presence protocols with which it interfaces.
introduction of gateways to the security model of instant messaging
and presence in RFC 2779 also introduces some new risks. End-to-end
security properties (especially confidentiality and integrity)
between instant messaging and presence user agents that interface
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", [1] Saint-Andre, P. and J. Miller, "XMPP Core",
draft-ietf-xmpp-core-12 (work in progress), May 2003. draft-ietf-xmpp-core-15 (work in progress), June 2003.
[2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging", [2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging",
draft-ietf-xmpp-im-11 (work in progress), May 2003. draft-ietf-xmpp-im-14 (work in progress), June 2003.
[3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000. Presence Protocol Requirements", RFC 2779, February 2000.
[4] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and [4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000, <http:// Instant Messaging", RFC 2778, February 2000, <http://
www.ietf.org/rfc/rfc2778.txt>. www.ietf.org/rfc/rfc2778.txt>.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
August 2002.
[7] 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.
[6] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging [8] Atkins, D. and G. Klyne, "Common Presence and Instant
Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08
progress), January 2003. (work in progress), January 2003.
[7] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. and [9] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. and
J. Peterson, "CPIM Presence Information Data Format", J. Peterson, "Presence Information Data Format",
draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003.
[8] Crocker, D. and J. Peterson, "Common Profile for Instant [10] Crocker, D. and J. Peterson, "Common Profile for Instant
Messaging (CPIM)", draft-ietf-impp-im-02 (work in progress), Messaging (CPIM)", draft-ietf-impp-im-03 (work in progress),
March 2003. May 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.
[11] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
August 2002.
[12] Housley, R. and J. Schaad, "Use of the AES Encryption Algorithm [11] Crocker, D. and J. Peterson, "Common Profile for Presence
and RSA-OAEP Key Transport in CMS", draft-ietf-smime-aes-alg-06 (CPP)", draft-ietf-impp-pres-03 (work in progress), May 2003.
(work in progress), January 2003.
[13] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security [12] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995. RFC 1847, October 1995.
[14] Mealling, M., "The IANA XML Registry", [13] Mealling, M., "The IANA XML Registry",
draft-mealling-iana-xmlns-registry-04 (work in progress), June draft-mealling-iana-xmlns-registry-05 (work in progress), June
2002. 2003.
[14] Ramsdell, B., "S/MIME Version 3 Certificate Handling", RFC
2632, June 1999.
[15] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms",
RFC 3370, August 2002.
Author's Address 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
Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e
The following XML schema is descriptive, not normative. 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'
skipping to change at page 16, line 10 skipping to change at page 21, line 10
<xs:element name='e2e' type='xs:string'/> <xs:element name='e2e' 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-02 B.1 Changes from draft-ietf-xmpp-e2e-03
o Completely revised to use CPIM/CPP. o Specified that S/MIME multipart objects are enclosed in a CDATA
section.
B.2 Changes from draft-ietf-xmpp-e2e-01 o Changed "text/xml" to "text/plain" for message examples.
o Specified must-implement technologies, transfer encodings,
certificate enrollment, certificate retrieval, and certificate
names (including subjectAltName for JIDs).
o Specified requirements regarding attachment of signatures and
inclusion of certificates.
o Fixed some small terminological errors.
B.2 Changes from draft-ietf-xmpp-e2e-02
o Completely revised to use formats defined in the CPIM
specifications.
B.3 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.3 Changes from draft-ietf-xmpp-e2e-00 B.4 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.
 End of changes. 60 change blocks. 
128 lines changed or deleted 331 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/