draft-ietf-xmpp-e2e-05.txt   draft-ietf-xmpp-e2e-06.txt 
Network Working Group P. Saint-Andre XMPP Working Group P. Saint-Andre
Internet-Draft Jabber Software Foundation Internet-Draft Jabber Software Foundation
Expires: February 20, 2004 August 22, 2003 Expires: May 20, 2004 November 20, 2003
End-to-End Object Encryption in XMPP End-to-End Object Encryption in the Extensible Messaging and Presence
draft-ietf-xmpp-e2e-05 Protocol (XMPP)
draft-ietf-xmpp-e2e-06
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 31
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 February 20, 2004. This Internet-Draft will expire on May 20, 2004.
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 memo 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 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 3 3. Securing Messages . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Intellectual Property Notice . . . . . . . . . . . . . . . . . 3 4. Securing Presence . . . . . . . . . . . . . . . . . . . . . . 6
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Securing Arbitrary XMPP Data . . . . . . . . . . . . . . . . . 8
3. Securing Messages . . . . . . . . . . . . . . . . . . . . . . 6 6. Rules for S/MIME Generation and Handling . . . . . . . . . . . 9
4. Securing Presence . . . . . . . . . . . . . . . . . . . . . . 8 7. Secure Communications Through a Gateway . . . . . . . . . . . 11
5. Securing Arbitrary XMPP Data . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Rules for S/MIME Generation and Handling . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1 Certificate Enrollment . . . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . . 14
6.2 Certificate Retrieval . . . . . . . . . . . . . . . . . . . . 12 Informative References . . . . . . . . . . . . . . . . . . . . 15
6.3 Certificate Names . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
6.4 Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 13 A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . 15
6.5 Attachment of Signatures . . . . . . . . . . . . . . . . . . . 13 B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 16
6.6 Inclusion of Certificates . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 18
6.7 Mandatory to Implement Technologies . . . . . . . . . . . . . 13
7. Secure Communications Through a Gateway . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1 Content-type Registration for "application/xmpp+xml" . . . . . 16
8.2 XML Namespace Name for e2e Data in XMPP . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
Normative References . . . . . . . . . . . . . . . . . . . . . 19
Informative References . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . 22
B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 23
B.1 Changes from draft-ietf-xmpp-e2e-04 . . . . . . . . . . . . . 23
B.2 Changes from draft-ietf-xmpp-e2e-03 . . . . . . . . . . . . . 23
B.3 Changes from draft-ietf-xmpp-e2e-02 . . . . . . . . . . . . . 23
B.4 Changes from draft-ietf-xmpp-e2e-01 . . . . . . . . . . . . . 23
B.5 Changes from draft-ietf-xmpp-e2e-00 . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 25
1. Introduction 1. Introduction
This document define a method for end-to-end signing and encryption This memo define a method for end-to-end signing and encryption in
in the Extensible Messaging and Presence Protocol (XMPP). (For 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] and [XMPP-IM].) The method
method defined herein enables a sender to encrypt and/or sign an defined herein enables a sender to encrypt and/or sign an instant
instant message sent to a specific recipient, encrypt and/or sign message sent to a specific recipient, encrypt and/or sign presence
presence information that is directed to a specific user, and sign information that is directed to a specific user, and sign presence
presence information that is broadcasted to a specific user. This information that is broadcasted to a specific user. This memo
document thereby helps the XMPP specifications meet the requirements thereby helps the XMPP specifications meet the requirements defined
defined in RFC 2779 [3]. in [IMP-REQS].
1.1 Terminology 1.1 Terminology
This document inherits terminology defined in RFC 2633 [4], RFC 2778 This document inherits terminology defined in [SMIME], [IMP-MODEL],
[5], RFC 3369 [6], and XMPP Core [1]. [CMS], and [XMPP-CORE].
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
2119 [7]. [TERMS].
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
This document is in full compliance with all provisions of Section 10 This document is in full compliance with all provisions of Section 10
of RFC 2026. Parts of this specification use the term "jabber" for of RFC 2026. Parts of this specification use the term "jabber" for
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 memo, we stipulate the following
requirements: requirements:
1. The method defined MUST address encryption and signing 1. The method defined MUST address encryption and signing
requirements for minimal instant messaging and presence only, as requirements for minimal instant messaging and presence only, as
those are defined in RFC 2779 [3]. The method is NOT REQUIRED to those are defined in [IMP-REQS]. The method is NOT REQUIRED to
support non-IM applications of XMPP, nor to support advanced support non-IM applications of XMPP, nor to support advanced
instant messaging and presence functionality that is outside the instant messaging and presence functionality that is outside the
scope of RFC 2799. In particular, the method MUST address the scope of [IMP-REQS]. In particular, the method MUST address the
following requirements defined in RFC 2779: following requirements defined in [IMP-REQS]:
* The protocol MUST provide means to ensure confidence that a * The protocol MUST provide means to ensure confidence that a
received message (NOTIFICATION or INSTANT MESSAGE) has not received message (NOTIFICATION or INSTANT MESSAGE) has not
been corrupted or tampered with. (Section 2.5.1) been corrupted or tampered with. (Section 2.5.1)
* The protocol MUST provide means to ensure confidence that a * The protocol MUST provide means to ensure confidence that a
received message (NOTIFICATION or INSTANT MESSAGE) has not received message (NOTIFICATION or INSTANT MESSAGE) has not
been recorded and played back by an adversary. (Section 2.5.2) been recorded and played back by an adversary. (Section
2.5.2)
* The protocol MUST provide means to ensure that a sent message * The protocol MUST provide means to ensure that a sent message
(NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES
that the sender allows. (Section 2.5.3) that the sender allows. (Section 2.5.3)
* The protocol MUST allow any client to use the means to ensure * The protocol MUST allow any client to use the means to ensure
non-corruption, non-playback, and privacy, but the protocol non-corruption, non-playback, and privacy, but the protocol
MUST NOT require that all clients use these means at all MUST NOT require that all clients use these means at all
times. (Section 2.5.4) times. (Section 2.5.4)
skipping to change at page 5, line 9 skipping to change at page 4, line 49
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 the Common Presence and Instant messaging systems that support the Common Presence and Instant
Messaging (CPIM) specifications defined by the Instant Messaging Messaging (CPIM) specifications defined by the Instant Messaging
and Presence (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 [8]. [MSGFMT].
* Prior to encrypting or signing, the format of presence * Prior to encrypting or signing, the format of presence
information must conform to the CPP Presence Information Data information must conform to the CPP Presence Information Data
Format defined in PIDF [9]. Format defined in [PIDF].
3. The method MUST follow the required procedures (including the 3. The method MUST follow the required procedures (including the
specific algorithms) defined in Common Profile for Instant specific algorithms) defined in [CPIM] and [CPP]. In particular,
Messaging [10] and Common Profile for Presence [11]. In these documents specify:
particular, these documents specify:
* Encryption MUST use S/MIME [4] encryption with CMS [6] * Encryption MUST use [SMIME] encryption with [CMS]
EnvelopeData. EnvelopeData.
* Signing MUST use S/MIME [4] signatures with CMS [6] * Signing MUST use [SMIME] signatures with [CMS] SignedData.
SignedData.
4. In order to enable interoperable implementations, sending and 4. In order to enable interoperable implementations, sending and
receiving applications MUST implement the algorithms defined receiving applications MUST implement the algorithms defined
under Section 6.7. 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 [8]. 1. Generate a "Message/CPIM" object as defined in [MSGFMT].
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 [12]) 3. Provide the resulting multipart S/MIME object (see [MULTI])
as the CDATA of an <e2e/> child of a <message/> stanza, with the within a CDATA section of an <e2e/> child of a <message/> stanza,
<e2e/> element scoped by the 'urn:ietf:params:xml:ns:xmpp-e2e' where the <e2e/> element is qualified by the
namespace (note that this namespace name adheres to the format 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
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@example.com> From: Juliet Capulet <im:juliet@example.com>
To: Romeo Montague <im:romeo@example.net> To: Romeo Montague <im:romeo@example.net>
DateTime: 2003-05-14T11:45:36Z DateTime: 2003-05-14T11:45:36Z
Subject: Imploring Subject: Imploring
skipping to change at page 8, line 10 skipping to change at page 6, line 39
--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/pidf+xml" object as defined in PIDF [9]. 1. Generate an "application/pidf+xml" object as defined in [PIDF].
2. Encrypt and/or sign the "application/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 within a CDATA section of an
child of a <presence/> stanza, with the <e2e/> element scoped by <e2e/> child of a <presence/> stanza, where the <e2e/> element is
the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace (note that this qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
namespace name adheres to the format defined in The IANA XML The <presence/> stanza MUST include a 'to' attribute, i.e., it
Registry [13]). The <presence/> stanza MUST include a 'to' must be an instance of directed presence as defined in [XMPP-IM].
attribute, i.e., it must be an instance of directed presence as
defined in XMPP IM [2].
Example 3: Sender generates "application/pidf+xml" object: Example 3: Sender generates "application/pidf+xml" object:
<?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@example.com"> entity="pres:juliet@example.com">
<tuple id="h40zny" <tuple id="h40zny"
<status> <status>
<basic>open</basic> <basic>open</basic>
skipping to change at page 10, line 7 skipping to change at page 8, line 9
[signed body part] [signed body part]
--next-- --next--
]]> ]]>
</e2e> </e2e>
</presence> </presence>
5. Securing Arbitrary XMPP Data 5. Securing Arbitrary XMPP Data
The foregoing sections of this document describe how to secure "least The foregoing sections of this memo describe how to secure "least
common denominator" messaging and presence data of the kind that can common denominator" messaging and presence data of the kind that can
be directly translated into the MSGFMT or PIDF formats. However, XMPP be directly translated into the MSGFMT or PIDF formats. However,
possesses a third base-level stanza type (<iq/>) in addition to XMPP possesses a third base-level stanza type (<iq/>) in addition to
<message/> and <presence/>, as well as the ability to include <message/> and <presence/>, as well as the ability to include
extended XML data within arbitrary child elements of the three core extended XML data within arbitrary child elements of the three core
stanza types. Therefore it would be desirable to secure such data if stanza types. Therefore it would be desirable to secure such data if
possible. possible.
Because MSGFMT [8] specifies the ability to encapsulate any MIME Because [MSGFMT] specifies the ability to encapsulate any MIME type,
type, the approach taken in this document is to include arbitrary the approach taken in this memo is to include arbitrary XMPP data in
XMPP data in a new MIME type, "application/xmpp+xml". The root a new MIME type, "application/xmpp+xml". The root element for this
element for this MIME type is <xmpp/>, and the root element MUST MIME type is <xmpp/>, and the root element MUST contain one and only
contain one and only one child element, corresponding to one of the one child element, corresponding to one of the XMPP stanza types
XMPP stanza types (i.e., message, presence, or iq) if the default (i.e., message, presence, or iq) if the default namespace is
namespace is 'jabber:client' or 'jabber:server' as defined in XMPP 'jabber:client' or 'jabber:server' as defined in [XMPP-CORE].
Core [1].
The following examples illustrate the structure of the "application/ The following examples illustrate the structure of the "application/
xmpp+xml" MIME type. xmpp+xml" MIME type.
Example 5: Message stanza with extended data contained in Example 5: Message stanza with extended data contained in
"application/xmpp+xml" MIME type: "application/xmpp+xml" MIME type:
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xmpp xmlns='jabber:client'> <xmpp xmlns='jabber:client'>
<message <message
skipping to change at page 12, line 13 skipping to change at page 9, line 36
</xmpp> </xmpp>
6. Rules for S/MIME Generation and Handling 6. Rules for S/MIME Generation and Handling
6.1 Certificate Enrollment 6.1 Certificate Enrollment
S/MIME v3 does not specify how to obtain a certificate from a S/MIME v3 does not specify how to obtain a certificate from a
certificate authority, but instead mandates that every sending agent certificate authority, but instead mandates that every sending agent
must already have a certificate. The PKIX Working Group has, at the must already have a certificate. The PKIX Working Group has, at the
time of this writing, produced two separate standards for certificate time of this writing, produced two separate standards for certificate
enrollment: CMP (RFC 2510) and CMC (RFC 2792). Which method to use enrollment: [CMP] and [CMC]. Which method to use for certificate
for certificate enrollment is outside the scope of this document. enrollment is outside the scope of this memo.
6.2 Certificate Retrieval 6.2 Certificate Retrieval
A receiving agent MUST provide some certificate retrieval mechanism A receiving agent MUST provide some certificate retrieval mechanism
in order to gain access to certificates for recipients of digital in order to gain access to certificates for recipients of digital
envelopes. This document does not cover how S/MIME agents handle envelopes. This memo does not cover how S/MIME agents handle
certificates, only what they do after a certificate has been certificates, only what they do after a certificate has been
validated or rejected. S/MIME certification issues are covered in RFC validated or rejected. S/MIME certification issues are covered in
2632 [14]. [CERT].
At a minimum, for initial S/MIME deployment, a user agent could At a minimum, for initial S/MIME deployment, a user agent could
automatically generate a message to an intended recipient requesting automatically generate a message to an intended recipient requesting
that recipient's certificate in a signed return message. Receiving that recipient's certificate in a signed return message. Receiving
and sending agents SHOULD also provide a mechanism to allow a user to and sending agents SHOULD also provide a mechanism to allow a user to
"store and protect" certificates for correspondents in such a way so "store and protect" certificates for correspondents in such a way so
as to guarantee their later retrieval. as to guarantee their later retrieval.
6.3 Certificate Names 6.3 Certificate Names
End-entity certificates used in the context of this document SHOULD a End-entity certificates used in the context of this memo SHOULD a
valid instant messaging address. The address SHOULD be one of the valid instant messaging address. The address SHOULD be one of the
following: following:
1. An "instant inbox address" as defined in RFC 2778 [5] and MSGFMT 1. An XMPP address (also referred to as a Jabber Identifier or JID)
[8]. As explained in XMPP CPIM Mapping [16], an instant inbox as defined in [XMPP-CORE]; the address should be of the form
address maps to a "bare JID" (XMPP <node@domain>) once the 'im:' <node@domain> (i.e., a "bare JID"), although any valid JID form
URI scheme has been removed. The appropriate container for MAY be used. The JID SHOULD be contained in the subjectAltName
instant inbox address shall be defined in MSGFMT [8]. extension, and SHOULD NOT be in the subject distinguished name.
2. An XMPP address (JID) as defined in XMPP Core [1]; the address 2. An "instant inbox address" as defined in [IMP-MODEL] and
should be of the form <node@domain> (i.e., a "bare JID"), [MSGFMT]. As explained in [XMPP-CPIM], an instant inbox address
although any valid JID form MAY be used. The JID SHOULD be maps to a "bare JID" (<node@domain>) once the 'im:' URI scheme
contained in the subjectAltName extension, and SHOULD NOT be in has been removed. The appropriate container for instant inbox
the subject distinguished name. address shall be defined in [MSGFMT].
The value of the JID contained in the XMPP 'from' attribute SHOULD The value of the JID contained in the XMPP 'from' attribute SHOULD
match the JID provided in the signer's certificate, with the match the JID provided in the signer's certificate, with the
exception that the resource identifier portion of the JID contained exception that the resource identifier portion of the JID contained
in the 'from' attribute MAY be ignored for matching purposes. in the 'from' attribute MAY be ignored for matching purposes.
Receiving agents MUST recognize XMPP addresses (JIDs) in the Receiving agents MUST recognize XMPP addresses (JIDs) in the
subjectAltName field. subjectAltName field.
Receiving agents SHOULD check that sending JID matches a JID provided Receiving agents SHOULD check that sending JID matches a JID provided
skipping to change at page 13, line 25 skipping to change at page 10, line 50
addresses in the certificate or other certificate details. addresses in the certificate or other certificate details.
The subject alternative name extension is used in S/MIME as the The subject alternative name extension is used in S/MIME as the
preferred means to convey the JID that corresponds to the entity for preferred means to convey the JID that corresponds to the entity for
this certificate. Any JIDs present SHOULD be encoded using the this certificate. Any JIDs present SHOULD be encoded using the
otherName CHOICE of the subjectAltName type, where the type-id is otherName CHOICE of the subjectAltName type, where the type-id is
"xmpp" and the value is the bare JID of the entity. "xmpp" and the value is the bare JID of the entity.
6.4 Transfer Encoding 6.4 Transfer Encoding
According to various S/MIME specifications for message wrapping, CMS According to various S/MIME specifications for message wrapping,
objects MAY optionally be wrapped in MIME to dynamically support [CMS] objects MAY optionally be wrapped in MIME to dynamically
7-bit transport. Because it is expected that XMPP will not be used to support 7-bit transport. Because it is expected that XMPP will not
interface with older 7-bit systems, this outer wrapping is NOT be used to interface with older 7-bit systems, this outer wrapping is
REQUIRED for XMPP transport, and generally SHOULD NOT be applied in a NOT REQUIRED for XMPP transport, and generally SHOULD NOT be applied
homogeneous XMPP environment or in an environment that supports in a homogeneous XMPP environment or in an environment that supports
XMPP-CPIM gateways. XMPP-CPIM gateways.
6.5 Attachment of Signatures 6.5 Attachment of Signatures
Sending agents SHOULD attach a signature to each encrypted message or Sending agents SHOULD attach a signature to each encrypted message or
presence stanza, but are NOT REQUIRED to do so. presence stanza, but are NOT REQUIRED to do so.
6.6 Inclusion of Certificates 6.6 Inclusion of Certificates
Sending agents are NOT REQUIRED to include the sender's certificate Sending agents are NOT REQUIRED to include the sender's certificate
along with each encrypted message or presence stanza. along with each encrypted message or presence stanza.
6.7 Mandatory to Implement Technologies 6.7 Mandatory to Implement Technologies
At a minimum, all implementations MUST support the following CMS At a minimum, all implementations MUST support the following CMS
algorithms as defined in RFC 3370 [15]: algorithms as defined in [CMS-ALG]:
for digest: DIGEST-MD5 for digest: DIGEST-MD5
for signing: RSA for signing: RSA
for content encryption: Triple-DES CBC for content encryption: Triple-DES CBC
7. Secure Communications Through a Gateway 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. The CPIM specifications (specifically MSGFMT [8] and PIDF the other. The CPIM specifications (specifically [MSGFMT] and [PIDF]
[9] define the common profiles to be used for interoperability define the common profiles to be used for interoperability between
between instant messaging and presence services that comply with RFC instant messaging and presence services that comply with [IMP-REQS].
2779 [3]. In the case of communications between an XMPP service and a In the case of communications between an XMPP service and a non-XMPP
non-XMPP service, we can visualize this relationship as follows: service, we can visualize this relationship as follows:
+-------------+ +-------------+ +------------+ +-------------+ +-------------+ +------------+
| | | | | | | | | | | |
| XMPP | | XMPP-CPIM | | 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 an of encrypted and/or signed instant messages and presence through an
skipping to change at page 16, line 5 skipping to change at page 12, line 25
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.
The wrapped S/MIME object MUST be immutable and MUST NOT be modified The wrapped S/MIME object MUST be immutable and MUST NOT be modified
by an XMPP-CPIM gateway. by an XMPP-CPIM gateway.
8. IANA Considerations 8. Security Considerations
8.1 Content-type Registration for "application/xmpp+xml" This entire memo discusses security. Detailed security
considerations for instant messaging and presence protocols are given
in [IMP-REQS] (Sections 5.1 through 5.4), and for XMPP in particular
are given in [XMPP-CORE] (Sections 12.1 through 12.6).
The end-to-end security method defined here MAY result in exchanging
secured instant messages and presence information through a gateway
that implements the CPIM specifications. Such a gateway MUST be
compliant with the minimum security requirements of the instant
messaging and presence protocols with which it interfaces.
9. IANA Considerations
9.1 Content-type Registration for "application/xmpp+xml"
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/xmpp+xml Subject: Registration of MIME media type application/xmpp+xml
MIME media type name: application MIME media type name: application
MIME subtype name: xmpp+xml MIME subtype name: xmpp+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Indicates the character encoding of the Optional parameters: charset Indicates the character encoding of the
enclosed XML; the default encoding is UTF-8. enclosed XML; the default encoding is UTF-8.
Encoding considerations: Contains XML, which can employ 8-bit Encoding considerations: Contains XML, which can employ 8-bit
characters, depending on the character encoding used. characters, depending on the character encoding used.
Security considerations: Contains a message, presence information, or Security considerations: Contains a message, presence information, or
IQ (request-response) data in XMPP, which may be considered IQ (request-response) data in XMPP, which may be considered
skipping to change at page 16, line 32 skipping to change at page 13, line 19
Encoding considerations: Contains XML, which can employ 8-bit Encoding considerations: Contains XML, which can employ 8-bit
characters, depending on the character encoding used. characters, depending on the character encoding used.
Security considerations: Contains a message, presence information, or Security considerations: Contains a message, presence information, or
IQ (request-response) data in XMPP, which may be considered IQ (request-response) data in XMPP, which may be considered
private. Appropriate precautions should be adopted to limit private. Appropriate precautions should be adopted to limit
disclosure of this information. disclosure of this information.
Interoperability considerations: (none) Interoperability considerations: (none)
Specification: [RFCXXXX] Specification: XXXX
Applications which use this media type: XMPP-compliant instant Applications which use this media type: XMPP-compliant instant
messaging and presence systems. messaging and presence systems.
Additional information: (none) Additional information: (none)
Person and email address to contact for further information: IETF, Person and email address to contact for further information: IETF,
XMPP Working Group, <xmppwg@jabber.org> XMPP Working Group, <xmppwg@jabber.org>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: IETF, XMPP Working Group Author/Change controller: IETF, XMPP Working Group
8.2 XML Namespace Name for e2e Data in XMPP 9.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. (This namespace name adheres to the format defined in
[XML-REG].)
URI: urn:ietf:params:xml:ns:xmpp-e2e URI: urn:ietf:params:xml:ns:xmpp-e2e
Specification: [RFCXXXX] Specification: XXXX
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 XXXX.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org> Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
9. Security Considerations
This entire document discusses security. Detailed security
considerations for instant messaging and presence protocols are given
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
secured instant messages and presence information through a gateway
that implements the CPIM specifications. Such a gateway MUST be
compliant with the minimum security requirements of the instant
messaging and presence protocols with which it interfaces.
Normative References Normative References
[CERT] Ramsdell, B., "S/MIME Version 3 Certificate Handling", RFC
2632, June 1999.
[1] Saint-Andre, P. and J. Miller, "XMPP Core", [CMC] Blaze, M., Ioannidis, J. and A. Keromytis, "DSA and RSA
draft-ietf-xmpp-core-17 (work in progress), August 2003. Key and Signature Encoding for the KeyNote Trust
Management System", RFC 2792, March 2000.
[2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging", [CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key
draft-ietf-xmpp-im-16 (work in progress), August 2003. Infrastructure Certificate Management Protocols", RFC
2510, March 1999.
[3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
Presence Protocol Requirements", RFC 2779, February 2000. 3369, August 2002.
[4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS)
2633, June 1999. Algorithms", RFC 3370, August 2002.
[5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and [CPIM] Crocker, D. and J. Peterson, "Common Profile for Instant
Instant Messaging", RFC 2778, February 2000, <http:// Messaging (CPIM)", draft-ietf-impp-im-03 (work in
www.ietf.org/rfc/rfc2778.txt>. progress), May 2003.
[6] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, [CPP] Crocker, D. and J. Peterson, "Common Profile for Presence
August 2002. (CPP)", draft-ietf-impp-pres-03 (work in progress), May
2003.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement [IMP-MODEL]
Levels", BCP 14, RFC 2119, March 1997. 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>.
[8] Atkins, D. and G. Klyne, "Common Presence and Instant [IMP-REQS]
Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000.
[MSGFMT] Atkins, D. and G. Klyne, "Common Presence and Instant
Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08 Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08
(work in progress), January 2003. (work in progress), January 2003.
[9] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. and [MULTI] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
J. Peterson, "Presence Information Data Format", "Security Multiparts for MIME: Multipart/Signed and
draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. Multipart/Encrypted", RFC 1847, October 1995.
[10] Crocker, D. and J. Peterson, "Common Profile for Instant
Messaging (CPIM)", draft-ietf-impp-im-03 (work in progress),
May 2003.
[11] Crocker, D. and J. Peterson, "Common Profile for Presence [PIDF] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W.
(CPP)", draft-ietf-impp-pres-03 (work in progress), May 2003. and J. Peterson, "Presence Information Data Format",
draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003.
[12] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security [SMIME] Ramsdell, B., "S/MIME Version 3 Message Specification",
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 2633, June 1999.
RFC 1847, October 1995.
[13] Mealling, M., "The IANA XML Registry", [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
draft-mealling-iana-xmlns-registry-05 (work in progress), June Requirement Levels", BCP 14, RFC 2119, March 1997.
2003.
[14] Ramsdell, B., "S/MIME Version 3 Certificate Handling", RFC [XMPP-CORE]
2632, June 1999. Saint-Andre, P., "XMPP Core", draft-ietf-xmpp-core-20
(work in progress), November 2003.
[15] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", [XMPP-IM] Saint-Andre, P., "XMPP Instant Messaging",
RFC 3370, August 2002. draft-ietf-xmpp-im-19 (work in progress), November 2003.
Informative References Informative References
[16] Saint-Andre, P. and T. Bamonti, "XMPP CPIM Mapping", [XML-REG] Mealling, M., "The IANA XML Registry",
draft-ietf-xmpp-cpim-02 (work in progress), August 2003. draft-mealling-iana-xmlns-registry-05 (work in progress),
June 2003.
[XMPP-CPIM]
Saint-Andre, P., "Mapping the Extensible Messaging and
Presence Protocol (XMPP) to Common Presence and Instant
Messaging (CPIM)", draft-ietf-xmpp-cpim-03 (work in
progress), November 2003.
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
Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e
skipping to change at page 23, line 10 skipping to change at page 16, 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-04 B.1 Changes from draft-ietf-xmpp-e2e-05
o Addressed I-D nits and RFC Editor formatting.
B.2 Changes from draft-ietf-xmpp-e2e-04
o Added text about instant inbox addresses. o Added text about instant inbox addresses.
B.2 Changes from draft-ietf-xmpp-e2e-03 B.3 Changes from draft-ietf-xmpp-e2e-03
o Specified that S/MIME multipart objects are enclosed in a CDATA o Specified that S/MIME multipart objects are enclosed in a CDATA
section. section.
o Changed "text/xml" to "text/plain" for message examples. o Changed "text/xml" to "text/plain" for message examples.
o Specified must-implement technologies, transfer encodings, o Specified must-implement technologies, transfer encodings,
certificate enrollment, certificate retrieval, and certificate certificate enrollment, certificate retrieval, and certificate
names (including subjectAltName for JIDs). names (including subjectAltName for JIDs).
o Specified requirements regarding attachment of signatures and o Specified requirements regarding attachment of signatures and
inclusion of certificates. inclusion of certificates.
o Fixed some small terminological errors. o Fixed some small terminological errors.
B.3 Changes from draft-ietf-xmpp-e2e-02 B.4 Changes from draft-ietf-xmpp-e2e-02
o Completely revised to use formats defined in the CPIM o Completely revised to use formats defined in the CPIM
specifications. specifications.
B.4 Changes from draft-ietf-xmpp-e2e-01 B.5 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.5 Changes from draft-ietf-xmpp-e2e-00 B.6 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. 65 change blocks. 
179 lines changed or deleted 177 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/