One document matched: draft-miller-3923bis-01.txt
Differences from draft-miller-3923bis-00.txt
Network Working Group M. Miller
Internet-Draft P. Saint-Andre
Obsoletes: 3923 (if approved) Cisco
Intended status: Standards Track March 8, 2010
Expires: September 9, 2010
End-to-End Object Encryption for the Extensible Messaging and Presence
Protocol (XMPP)
draft-miller-3923bis-01
Abstract
This document defines a method of end-to-end object encryption for
the Extensible Messaging and Presence Protocol (XMPP). The protocol
defined herein is a simplified version of the protocol defined in RFC
3923.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Miller & Saint-Andre Expires September 9, 2010 [Page 1]
Internet-Draft XMPP E2E March 2010
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Securing XMPP Stanzas . . . . . . . . . . . . . . . . . . . . 3
3.1. Example of Securing Messages . . . . . . . . . . . . . . . 4
3.2. Example of Securing IQs . . . . . . . . . . . . . . . . . 5
4. Interaction with Stanza Semantics . . . . . . . . . . . . . . 6
5. Handling of Inbound Stanzas . . . . . . . . . . . . . . . . . 6
6. Inclusion and Checking of Timestamps . . . . . . . . . . . . . 8
7. Mandatory-to-Implement Cryptographic Algorithms . . . . . . . 8
8. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10.1. XML Namespace Name for e2e Data in XMPP . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-objenc . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Miller & Saint-Andre Expires September 9, 2010 [Page 2]
Internet-Draft XMPP E2E March 2010
1. Introduction
End-to-end encryption of traffic sent over the Extensible Messaging
and Presence Protocol [XMPP-CORE] is a desirable goal. Requirements
and a threat analysis for XMPP encryption are provided in [E2E-REQ].
Many possible approaches to meet those (or similar) requirements have
been proposed over the years, including methods based on PGP, S/MIME,
SIGMA, and TLS.
The S/MIME approach defined in RFC 3923 has never been implemented in
XMPP clients to the best of our knowledge, but has some attractive
features, especially the ability to store-and-forward an encrypted
message at a user's server if the user is not online when the message
is received (in the XMPP community this is called "offline storage"
and the message is referred to as an "offline message"). The authors
surmise that RFC 3923 has not been implemented mainly because it adds
several new dependencies to XMPP clients, especially MIME (along with
the CPIM and MSGFMT media types). Therefore this document explores
the possibility of an approach that is similar to but simpler than
RFC 3923, while retaining the same basic object encryption model.
2. Terminology
This document inherits terminology defined in [XMPP-CORE].
Security-related terms are to be understood in the sense defined in
[SECTERMS].
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14, RFC 2119 [TERMS].
3. Securing XMPP Stanzas
The process that a sending agent follows for securing stanzas is very
similar regardless of the form of stanza (i.e., <iq/>, <message/>, or
<presence/>).
1. Constructs a cleartext version of the stanza, S.
2. Notes the current UTC date and time N when this stanza is
constructed, formatted as per [DATETIME] and including the
seconds and fractions of a second to three digits (resulting in a
datetime string 24 characters in length, such as "2010-02-
28T18:00:00.314Z").
Miller & Saint-Andre Expires September 9, 2010 [Page 3]
Internet-Draft XMPP E2E March 2010
3. Hashes the datetime N using a cryptographic hashing algorithm,
i.e., hash(N) = N'.
4. Converts the stanza to a UTF-8 encoded string, optionally
removing line breaks and other insignificant whitespace between
elements and attributes, i.e., UTF8-encode(S) = S'. We call S' a
"stanza-string" because for purposes of encryption and decryption
it is treated not as XML but as an opaque string (this avoids the
need for complex canonicalization of the XML input).
5. Encrypts (N' + S') using the recipient's public key to produce
encrypted data T. (Known issue: This step is under-specified and
will be expanded in a later version of this document.)
6. Base64-encodes T to produce the encrypted data T'.
7. Constructs an <e2e/> element qualified by the
"urn:ietf:params:xml:ns:xmpp-objenc" namespace as follows:
The attribute 'stamp' set to the timestamp N from step 2;
The attribute 'hash' set to the cryptographic hashing
algorithm used in step 3;
The attribute 'cipher' set to the encryption scheme used in
step 5;
The XML character data as T' from step 6.
8. Sends the <e2e/> element as the payload of a stanza that matches
the stanza from step 1 in both kind (e.g., <message/>) and type
(e.g., "chat").
3.1. Example of Securing Messages
The sender begins with the cleartext version of the <message/> stanza
"S":
<message xmlns='jabber:client'
from='juliet@capulet.net/balcony'
id='183ef129'
to='romeo@montague.net'
type='chat'>
<thread>8996aef0-061d-012d-347a-549a200771aa</thread>
<body>Wherefore art thou, Romeo?</body>
</message>
The sender then performs the steps from above, and sends the
following:
Miller & Saint-Andre Expires September 9, 2010 [Page 4]
Internet-Draft XMPP E2E March 2010
<message xmlns='jabber:client'
from='juliet@capulet.net/balcony'
id='6410ed123'
to='romeo@montague.net'
type='chat'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-objenc'
cipher='RSAES-PKCS1-v1_5'
hash='SHA-256'
stamp='2010-02-28T18:00:00.203Z'>
Ysocyy9I2jUACcChThqCuVxqB9qdFJ+mKzpbABiF+a5wMavDnQf
z1Rda1OAL\nzs5M8+uSnQA643bGlpVvuzbi1zdfmuRtqIHzopz2
3CNq5cz8nuIPOLcWZvWP\nmDa5tbhB+loItG8roCYuF7Y4h+RkG
CwXBpV+Kwe9ZKhM1vklJ4znCfcghDXU\nORQiY29W2r/Vrqhd6U
u+ftp0mFm+7s45NjIOSYm7T+Fl5e7wu1FUtr9CmcPd\n22WRLNT
wZ+iKu0AdGUUSqLWqAUBtERA85hhj/3vNCdawOf6dm/K9eLmoLF
zH\nph7vc0519w5mqUktKnfzuh/4/iXGRHWJ27jZLfCcag==
</e2e>
</message>
3.2. Example of Securing IQs
The sender begins with the cleartext version of the <iq/> stanza "S":
<iq xmlns='jabber:client'
from='juliet@capulet.net/crypt'
id='a543bc3ee'
to='romeo@montague.net'
type='resut'>
<mood xmlns='http://jabber.org/protocol/mood'>
<dejected/>
<text>
Romeo, what's here? Poison? Drunk all, and left no
friendly drop to help me after?
</text>
</mood>
</iq>
The sender then performs the steps from above, and sends the
following:
Miller & Saint-Andre Expires September 9, 2010 [Page 5]
Internet-Draft XMPP E2E March 2010
<iq xmlns='jabber:client'
from='juliet@capulet.net/crypt'
id='a543bc3ee'
to='romeo@montague.net/crypt'
type='result'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-objenc'
cipher='RSAES-PKCS1-v1_5'
hash='SHA-256'
stamp='2010-03-06T20:53:18.082Z'>
Up3uZr1j0H9UCdG91ec8h4bIbgmHNZ6Gu/UHr03XsPtc4Qamb/8
hpc4h+JL5\n6G8hhIkPeUN2ieCrXbCa84RtsJ/TuFONLw/tNe2Y
Fm7Js7RKgTrTRzjWCTAh\nKTp2rvjkN1T15c9N0kE2m4QX5nnYo
zv+bV/i/mFFCwY1UdDQqIpKhd0eaHV/\n9FYikzp319fDu6op8/
kbyce2rUBzAbYRAPCxM1E1sd11UERR0VwWoOTMEDCz\n+g3/Rhd
vT5HOIVBHYEFKl+NQeHTJIAIsVWRl9Bn1+CdgZxM8phoRidtYFk
18\nOaPvVABy65HBeUIYaye7Mzi0Qg2oNwRkLy1Brf/m9Q==
</e2e>
</iq>
4. Interaction with Stanza Semantics
The following limitations and caveats apply:
o Undirected <presence/> stanzas MUST NOT be encrypted. Such
stanzas are delivered to anyone the sender has authorized, and
therefore it is highly unlikely that the send can find an
appropriate certificate.
o Stanzas directed to multiplexing services (e.g. multi-user chat)
SHOULD NOT be encrypted, unless the sender has established an
acceptable trust relationship with the multiplexing service.
5. Handling of Inbound Stanzas
Several scenarios are possible when an entity receives an encrypted
stanza:
Case #1: The receiving application does not understand the protocol.
Case #2: The receiving application understands the protocol and is
able to decrypt the payload.
Case #3: The receiving application understands the protocol and is
able to decrypt the payload, but the timestamps fail the checks
specified under Checking of Timestamps (Section 6).
Miller & Saint-Andre Expires September 9, 2010 [Page 6]
Internet-Draft XMPP E2E March 2010
Case #4: The receiving application understands the protocol but is
unable to decrypt the payload.
In Case #1, the receiving application MUST do one and only one of the
following: (1) ignore the <e2e/> extension, (2) ignore the entire
stanza, or (3) return a <service-unavailable/> error to the sender,
as described in [XMPP-CORE].
In Case #2, the receiving application MUST NOT return a stanza error
to the sender, since this is the success case.
In Case #3, the receiving application MAY return a <not-acceptable/>
error to the sender (as described in [XMPP-CORE]), optionally
supplemented by an application-specific error condition element of
<bad-timestamp/> as shown below:
<message from='romeo@example.net/orchard'
id='6410ed123'
to='juliet@capulet.net/balcony'
type='error'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-objenc'>
XML-character-data-here
</e2e>
<error type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<bad-timestamp xmlns='urn:ietf:params:xml:xmpp-e2e'/>
</error>
</message>
In Case #4, the receiving application SHOULD return a <bad-request/>
error to the sender (as described in [XMPP-CORE]), optionally
supplemented by an application-specific error condition element of
<decryption-failed/> as shown below:
<message from='romeo@example.net/orchard'
id='6410ed123'
to='juliet@capulet.net/balcony'
type='error'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-objenc'>
XML-character-data-here
</e2e>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<decryption-failed xmlns='urn:ietf:params:xml:xmpp-e2e'/>
</error>
</message>
In addition to returning an error in Case #4, the receiving
Miller & Saint-Andre Expires September 9, 2010 [Page 7]
Internet-Draft XMPP E2E March 2010
application SHOULD NOT present the stanza to the intended recipient
(human or application) and SHOULD provide some explicit alternate
processing of the stanza (which may be to display a message informing
the recipient that it has received a stanza that cannot be
decrypted).
6. Inclusion and Checking of Timestamps
Timestamps are included to help prevent replay attacks. All
timestamps MUST conform to [DATETIME] and be presented as UTC with no
offset, always including the seconds and fractions of a second to
three digits (resulting in a datetime 24 characters in length).
Absent a local adjustment to the sending agent's perceived time or
the underlying clock time, the sending agent MUST ensure that the
timestamps it sends to the receiver increase monotonically (if
necessary by incrementing the seconds fraction in the timestamp if
the clock returns the same time for multiple requests). The
following rules apply to the receiving application:
o It MUST verify that the timestamp received is within five minutes
of the current time, except as described below for offline
messages.
o It SHOULD verify that the timestamp received is greater than any
timestamp received in the last 10 minutes which passed the
previous check.
o If any of the foregoing checks fails, the timestamp SHOULD be
presented to the receiving entity (human or application) marked as
"old timestamp", "future timestamp", or "decreasing timestamp",
and the receiving entity MAY return a stanza error to the sender.
The foregoing timestamp checks assume that the recipient is online
when the message is received. However, if the recipient is offline
then the server will probably store the message for delivery when the
recipient is next online (offline storage does not apply to <iq/> or
<presence/> stanzas, only <message/> stanzas). As described in
[OFFLINE], when sending an offline message to the recipient, the
server SHOULD include delayed delivery data as specified in [DELAY]
so that the recipient knows that this is an offline message and also
knows the original time of receipt at the server. In this case, the
recipient SHOULD verify that the timestamp received in the encrypted
message is within five minutes of the time stamped by the recipient's
server in the <delay/> element.
7. Mandatory-to-Implement Cryptographic Algorithms
All implementations MUST support the following algorithms.
Miller & Saint-Andre Expires September 9, 2010 [Page 8]
Internet-Draft XMPP E2E March 2010
Implementations MAY support other algorithms as well.
o The RSA (PKCS #1 v1.5) key transport, as specified in [CMS-ALG]
section 4.2.1.
o The AES-128 encryption algorithm in CBC mode, as specified in
[CMS-AES].
o The SHA-256 hashing algorithm, as specified in [X509-ALGO].
8. Certificates
To participate in end-to-end encryption using the methods defined in
this document, a client needs to possess an X.509 certificate. It is
expected that many clients will generate their own (self-signed)
certificates rather than obtain a certificate issued by a
certification authority (CA). In any case the certificate MUST
include an XMPP address that is represented using the ASN.1 Object
Identifier "id-on-xmppAddr" as specified in Section 5.1.1 of
[XMPP-CORE].
9. Security Considerations
The recipient's server might store any <message/> stanzas received
until the recipient is next available; this duration could be
anywhere from a few minutes to several months.
10. IANA Considerations
10.1. XML Namespace Name for e2e Data in XMPP
A URN sub-namespace of signed and encrypted content for the
Extensible Messaging and Presence Protocol (XMPP) is defined as
follows.
URI: urn:ietf:params:xml:ns:xmpp-objenc
Specification: RFC XXXX
Description: This is an XML namespace name of signed and encrypted
content for the Extensible Messaging and Presence Protocol as
defined by RFC XXXX.
Registrant Contact: IESG, <iesg@ietf.org>
11. References
Miller & Saint-Andre Expires September 9, 2010 [Page 9]
Internet-Draft XMPP E2E March 2010
11.1. Normative References
[CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES)
Encryption Algorithm in Cryptographic Message Syntax
(CMS)", RFC 3565, July 2003.
[CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[DATETIME]
Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[E2E-REQ] Saint-Andre, P., "Requirements for End-to-End Encryption
in the Extensible Messaging and Presence Protocol (XMPP)",
draft-saintandre-xmpp-e2e-requirements-01 (work in
progress), March 2010.
[SECTERMS]
Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[X509-ALGO]
Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[XMPP-CORE]
Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
11.2. Informative References
[DELAY] Saint-Andre, P., "Delayed Delivery", XSF XEP 0203,
September 2009.
[OFFLINE] Saint-Andre, P., "Best Practices for Handling Offline
Messages", XSF XEP 0160, January 2006.
Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-objenc
The following XML schema is descriptive, not normative.
Miller & Saint-Andre Expires September 9, 2010 [Page 10]
Internet-Draft XMPP E2E March 2010
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-objenc'
xmlns='urn:ietf:params:xml:ns:xmpp-objenc'
elementFormDefault='qualified'>
<xs:element name='e2e'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='cipher'
type='xs:string'
use='optional'/>
<xs:attribute name='hash'
type='xs:string'
use='optional'/>
<xs:attribute name='timestamp'
type='xs:string'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='decryption-failed' type='empty'/>
<xs:element name='bad-timestamp' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Authors' Addresses
Matthew Miller
Cisco
Email: mamille2@cisco.com
Miller & Saint-Andre Expires September 9, 2010 [Page 11]
Internet-Draft XMPP E2E March 2010
Peter Saint-Andre
Cisco
Email: psaintan@cisco.com
Miller & Saint-Andre Expires September 9, 2010 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 22:23:58 |