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 10, 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 (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
2.  Terminology
3.  Securing XMPP Stanzas
    3.1.  Example of Securing Messages
    3.2.  Example of Securing IQs
4.  Interaction with Stanza Semantics
5.  Handling of Inbound Stanzas
6.  Inclusion and Checking of Timestamps
7.  Mandatory-to-Implement Cryptographic Algorithms
8.  Certificates
9.  Security Considerations
10.  IANA Considerations
    10.1.  XML Namespace Name for e2e Data in XMPP
11.  References
    11.1.  Normative References
    11.2.  Informative References
Appendix A.  Schema for urn:ietf:params:xml:ns:xmpp-objenc
§  Authors' Addresses

1.  Introduction

End-to-end encryption of traffic sent over the Extensible Messaging and Presence Protocol [XMPP‑CORE] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) is a desirable goal. Requirements and a threat analysis for XMPP encryption are provided in [E2E‑REQ] (Saint-Andre, P., “Requirements for End-to-End Encryption in the Extensible Messaging and Presence Protocol (XMPP),” March 2010.). 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] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.).

Security-related terms are to be understood in the sense defined in [SECTERMS] (Shirey, R., “Internet Security Glossary, Version 2,” August 2007.).

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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] (Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) 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").
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:

<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:

<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:

• 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.
• 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 (Inclusion and Checking of Timestamps).

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] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.).

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] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.)), 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] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.)), 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 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] (Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) 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:

• It MUST verify that the timestamp received is within five minutes of the current time, except as described below for offline messages.
• It SHOULD verify that the timestamp received is greater than any timestamp received in the last 10 minutes which passed the previous check.
• 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] (Saint-Andre, P., “Best Practices for Handling Offline Messages,” January 2006.), when sending an offline message to the recipient, the server SHOULD include delayed delivery data as specified in [DELAY] (Saint-Andre, P., “Delayed Delivery,” September 2009.) 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. Implementations MAY support other algorithms as well.

• The RSA (PKCS #1 v1.5) key transport, as specified in [CMS‑ALG] (Housley, R., “Cryptographic Message Syntax (CMS) Algorithms,” August 2002.) section 4.2.1.
• The AES-128 encryption algorithm in CBC mode, as specified in [CMS‑AES] (Schaad, J., “Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS),” July 2003.).
• The SHA-256 hashing algorithm, as specified in [X509‑ALGO] (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.).

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] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.).

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

11.1. Normative References

11.2. Informative References

Appendix A.  Schema for urn:ietf:params:xml:ns:xmpp-objenc

The following XML schema is descriptive, not normative.

<?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