JEP-0116: Encrypted Sessions

This JEP specifies a protocol for session-based, end-to-end encryption of XMPP communications.

WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.

JEP Information

Status: Experimental
Type: Standards Track
Number: 0116
Version: 0.6
Last Updated: 2004-08-12
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, RFC 2104, RFC 2409, RFC 3526, RFC 3548, xml-c14n, JEP-0004, JEP-0020, JEP-0030, JEP-0068, JEP-0079, JEP-0155
Supersedes: None
Superseded By: None
Short Name: esession

Author Information

Ian Paterson

Email: ian.paterson@clientside.co.uk
JID: ian@zoofy.com

Peter Saint-Andre

Email: stpeter@jabber.org
JID: stpeter@jabber.org

Dave Smith

Email: dizzyd@jabber.org
JID: dizzyd@jabber.org

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Given that this JEP normatively references IETF technologies, discussion on the JSF-IETF list may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/jsf-ietf> for details).

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Table of Contents

1. Introduction
2. Background
3. Terminology
3.1. Dramatis Personae
4. Requirements
4.1. Security Requirements
4.1.1. Confidentiality
4.1.2. Integrity
4.1.3. Replay Protection
4.1.4. Perfect Forward Secrecy
4.1.5. Authentication
4.1.6. Repudiability
4.2. Application Requirements
4.2.1. Generality
4.2.2. Implementability
4.2.3. Usability
4.2.4. Flexibility
4.2.5. Interoperability
4.2.6. Offline Sessions
4.2.7. Object Encryption
5. Discovering Support
6. ESession Initiation
6.1. Online Diffie-Hellman Key Exchange
6.1.1. Esession Request
6.1.2. Diffie-Hellman Preparation (Bob)
6.1.3. Esession Response
6.1.4. Diffie-Hellman Preparation (Alice)
6.1.5. Diffie-Hellman Completion
6.2. Offline Diffie-Hellman Key Exchange
6.2.1. Publishing Esession Options
6.2.2. Requesting Offline Esession Options
6.2.3. Diffie-Hellman Preparation (Offline)
6.2.4. Starting an Offline Esession
6.2.5. Accepting Offline Esessions
6.3. Generating Session Keys
7. Exchanging Stanzas
7.1. Encryptable Content
7.2. Encryption
7.3. Sending an Encrypted Stanza
7.4. Decryption
8. Re-Key Exchange
8.1. Re-Key Initiation
8.2. Re-Key Acceptance
8.3. Publishing Old MAC Values
9. Esession Termination
10. Signature Generation
10.1. Canonical Form (Informative)
11. Security Considerations
11.1. Random Numbers
11.2. Re-Keying Limits
11.3. Verifying Keys
11.4. Replay Attacks
11.5. Unencrypted Esessions
11.6. Storage
11.7. Offline Esessions
11.8. Extra Responsabilities of Implementors
11.9. Mandatory to Implement Technologies
11.9.1. Encryption Algorithms
11.9.2. Key Signing Algorithms
11.9.3. Public Signature-Verification-Key Formats
11.9.4. Hash Algorithms
11.9.5. Compression Algorithms
12. IANA Considerations
13. Jabber Registrar Considerations
13.1. Namespaces
13.2. Field Standardization
14. XML Schemas
15. Public Key Publication and Retrieval
16. Open Issues
16.1. To Think About
16.2. To Do
Notes
Revision History

1. Introduction

End-to-end encryption is a desirable feature for any communication technology. Ideally, such a technology would design encryption in from the beginning and would forbid unencrypted communications. Realistically, most communication technologies have not been designed in that manner, and Jabber/XMPP technologies are no exception. In particular, the original Jabber technologies developed in 1999 did not include end-to-end encryption by default. PGP-based encryption of message bodies and signing of presence information was added as an extension to the core protocols in the year 2000; this extension is documented in Current Jabber OpenPGP Usage [1]. When the core protocols were formalized within the Internet Standards Process by the IETF's XMPP Working Group in 2003, a different extension was defined using S/MIME-based signing and encryption of CPIM-formatted messages (see RFC 3862 [2]) and PIDF-formatted presence information (see RFC 3863 [3]); this extension is specified in RFC 3923 [4].

For reasons described more fully below, the foregoing proposals (and others not mentioned) have not been widely implemented and deployed. This is unfortunate, since an open communication protocol needs to enable end-to-end encryption in order to be seriously considered for deployment by a broad range of users. This proposal describes a different approach to end-to-end encryption for use by entities that communicate using XMPP. The approach taken herein essentially translates the semantics of the secure shell protocol (SSH) into the syntax of XMPP, with some adjustments that reflect reports of security issues with SHA-1 and insights gleaned from implementation of "off-the-record" (OTR) communication in the Gaim encryption plugin as described in Off-the-Record Communication [5]. The result is a protocol for encrypted sessions or "ESessions".

2. Background

As specified in RFC 3920 [6], XMPP is an XML streaming protocol that enables the near-real-time exchange of XML fragments between any two (or more) network endpoints. To date, the main application built on top of the core XML streaming layer is instant messaging (IM) and presence, the base extensions for which are specified in RFC 3921 [7]. There are three first-level elements of XML streams (<message/>, <presence/>, and <iq/>); each of these "XML stanza" types has different semantics, which can complicate the task of defining a generalized approach to end-to-end encryption for XMPP. In addition, XML stanzas can be extended (via properly-namespaced child elements) for a wide variety of functionality. The chosen approach should enable encryption of several complete XML elements rather than only parts thereof (e.g., only the XML character data of the message <body/> element as in JEP-0027).

XMPP is a session-oriented communication technology: normally, a client authenticates with a server and maintains a long-lived connection that defines the client's XMPP session. Such stream-level sessions are secured via channel encryption using Transport Level Security (RFC 2246 [8]), as specified in Section 5 of RFC 3920. However, there is no guarantee that all hops will implement or enforce channel encryption (or that intermediate routers are trustworthy), which makes end-to-end encryption desirable.

The session metaphor also applies to communication between endpoints: for instance, in IM applications, most instant messaging exchanges occur in bursts within limited time periods (e.g., two people may send a fairly large number of messages during a five-minute chat and then not exchange messages again for hours or even days). The XML stanzas exchanged during such a session may not be limited to <message/> stanzas; for instance, the session may be triggered by a change in one of the parties' presence status (e.g., changing from away to available) and the session may involve the exchange of <iq/> stanzas (e.g., to transfer a file as specified in File Transfer [9]). Endpoints may want to encrypt the stanzas they send to each other in such a way that the stanzas cannot be understood by untrusted mediating entities (such as servers) except to the extent required to understand the necessary routing information. (One complicating factor is that routing information may include not only the stanza's 'to', 'from', 'type, and 'id' attributes, but also Advanced Message Processing [10] extensions.)

The foregoing XMPP communications exist in the context of a one-to-one communication session between two entities. However, several forms of XMPP communication exist outside the context of one-to-one communication sessions:

Ideally, any technology for end-to-end encryption in XMPP could be extended to cover these scenarios as well as one-to-one communication sessions. However, both many-to-many sessions and one-to-many broadcast are deemed out of scope for this JEP. Offline communications are handled via a simple extension to the protocol for one-to-one sessions between two entities that are online simultaneously (see below).

Because XMPP is a session-oriented communication technology, encryption schemes that are appropriate for less dynamic technologies may not be appropriate for XMPP. XMPP, with its in-order delivery of XML stanzas, is able to take advantage of encryption approaches that are not feasible for less dynamic technologies. In particular, existing approaches to encryption of Internet communications have generally assumed that the "thing" to be encrypted has a stable identity or is best understood as a standalone object (e.g., a file or email message); the term "object encryption" well captures this assumption. Both JEP-0027 and RFC 3923 assume that XMPP communications are more like the exchange of email messages than they are like an interactive session -- while JEP-0027 uses "old-style" PGP object encryption and RFC 3923 uses "new-style" S/MIME object encryption, both specify the use of object encryption.

However, the session-oriented nature of XMPP may imply that the focus should be on "session encryption" rather than "object encryption". The paradigm for XMPP encryption may be something closer to the widely-deployed Secure Shell technology (see SSH Protocol Architecture [13] and SSH Transport Layer Protocol [14]) than to traditional encryption of files and standalone email messages. In many ways, Secure Shell (or, more specifically, OTR) is the conceptual model for the current proposal.

Therefore, this JEP specifies a method for encrypted sessions ("ESessions") that takes advantage of the inherent possibilities and strengths of session encryption as opposed to object encryption. The basic concept is that of an encrypted session which acts as a secure tunnel between two endpoints. Once the tunnel is established, the content of all one-to-one XML stanzas exchanged between the endpoints will be encrypted and then transmitted within a "wrapper" protocol element.

3. Terminology

3.1 Dramatis Personae

This JEP introduces two characters to help the reader follow the necessary exchanges:

  1. "Alice" is the name of the initiator of the ESession. Within the scope of this JEP, we stipulate that her fully-qualified JID is: <alice@example.org/pda>.
  2. "Bob" is the name of the other participant in the ESession started by Alice. Within the scope of this JEP, his fully-qualified JID is: <bob@example.com/laptop>.

While Alice and Bob are introduced as "end users", they are simply meant to be examples of Jabber entities. Any directly addressable Jabber entity may participate in an Esession.

4. Requirements

4.1 Security Requirements

This JEP stipulates the following security requirements for end-to-end encryption of XMPP communications:

Each of these requirements is explained in greater depth below.

4.1.1 Confidentiality

The one-to-one XML stanzas exchanged between two entities MUST NOT be understandable to any other entity that might intercept the communications.

4.1.2 Integrity

Alice and Bob MUST be sure that no other entity may change the content of the XML stanzas they exchange, or remove or insert stanzas into the Esession undetected.

4.1.3 Replay Protection

Alice or Bob MUST be able to identify and reject any communications that are copies of their previous communications resent by another entity.

4.1.4 Perfect Forward Secrecy

The encrypted communication MUST NOT be revealed even if long-lived keys are compromised in the future (e.g., Steve steals Bob's computer).

4.1.5 Authentication

Each party to a conversation MUST know that the other party is who he says he is (Alice must be able to know that Bob really is Bob, and vice versa). [15]

4.1.6 Repudiability

Alice and Bob MUST be able to repudiate any stanza that occurs within an Esession. After an Esession has finished, it SHOULD NOT be possible to prove cryptographically that any transcript has not been modified by a third party. [16]

4.2 Application Requirements

In addition to the foregoing security profile, this JEP also stipulates the following application-specific requirements for encrypted communication in the context of Jabber/XMPP technologies:

Each of these is explained in greater depth below.

4.2.1 Generality

The solution should be generally applicable to any XML stanza type (<message/>, <presence/>, <iq/>) sent between two entities. It is deemed acceptable for now if the solution does not apply to many-to-many stanzas (e.g., groupchat messages sent within the context of multi-user chat) or one-to-many stanzas (e.g., presence "broadcasts" and pubsub notifications); end-to-end encryption of such stanzas may require separate solutions or extensions to the one-to-one session solution.

4.2.2 Implementability

The only good security technology is an implemented security technology. The solution should be one that typical client developers can implement in a relatively straightforward and consistent fashion.

4.2.3 Usability

The requirement of usability takes implementability one step further by stipulating that the solution must be one that organizations may deploy and humans may use with 100% transparency (with the ease-of-use of https:). Experience has shown that: solutions requiring a full public key infrastructure do not get widely deployed, and solutions requiring any user action are not widely used. We can do better.

4.2.4 Flexibility

The solution should be compatible with existing (and future) cryptographic algorithms and identity certification schemes (including X.509 and PGP).

4.2.5 Interoperability

Ideally, it would be possible for an XMPP user to exchange encrypted messages (and, potentially, presence information) with users of non-XMPP messaging systems.

4.2.6 Offline Sessions

Ideally, it should be possible to encrypt one-to-one communications that are stored for later delivery rather than delivered immediately, such as so-called "offline messages".

4.2.7 Object Encryption

For cases where a session is not desired, it should be possible to encrypt, sign and send a single stanza in isolation, so-called "object encryption".

5. Discovering Support

Before attempting to engage in an ESession with Bob, Alice SHOULD discover whether he supports this protocol, using either Service Discovery [17] or the presence-based profile of JEP-0030 specified in Entity Capabilities [18].

The normal course of events is for Alice to authenticate with her server, retrieve her roster (see RFC 3921), send initial presence to her server, and then receive presence information from all the contacts in her roster. If the presence information she receives from some contacts does not include capabilities data (per JEP-0115), Alice SHOULD then send a service discovery information ("disco#info") request to each of those contacts (in accordance with JEP-0030). Such initial service discovery stanzas MUST NOT be considered part of encrypted communication sessions for the purposes of this JEP, since they perform a "bootstrapping" function that is a prerequisite to encrypted communications. The disco#info request sent from Alice to Bob might look as follows:

Example 1. Alice Queries Bob for Esession Support via Disco

<iq type='get'
    from='alice@example.org/pda'
    to='bob@example.com/laptop'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

If Bob sends a disco#info reply and he supports the protocol defined herein, then he MUST include a service discovery feature variable of "http://jabber.org/protocol/esession".

Example 2. Bob Returns disco#info Data

<iq type='result'
    from='bob@example.com/laptop'
    to='alice@example.org/pda'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='client' type='pc'/>
    ...
    <feature var='http://jabber.org/protocol/esession'/>
    ...
  </query>
</iq>

6. ESession Initiation

The process for establishing an ESession is essentially a translation into XMPP syntax of the SSH transport mechanism for establishing a secure session over an insecure transport (see SSH Transport Layer Protocol). Specifically, as in SSH, ESession uses a Diffie-Hellman key exchange algorithm (see RFC 2631 [19]) in the initial negotation (although, as we shall see, it does not use SHA-1 as the hashing algorithm).

When Alice wishes to establish an ESession with Bob, Alice may choose between two different methods of performing the initial Diffie-Hellman key exchange, depending on whether Bob is online or not. Note: Alice MUST NOT initiate a new Esession with Bob if she already has one established with him.

6.1 Online Diffie-Hellman Key Exchange

If Alice believes Bob may be online then she SHOULD retrieve Bob's long-term public signature-verification keys (see Public Key Publication and Retrieval) and then use the protocol specified in Chat Session Negotiation [20] to negotiate the initial Diffie-Hellman key. In this aggressive exchange the first two messages negotiate policy, swap Diffie-Hellman public values and the ancillary data necessary for the exchange and authentication. The second message also authenticates the responder. The third message authenticates the initiator and exchanges the final Diffie-Hellman public value.

6.1.1 Esession Request

Alice MUST specify each of the Esession options (algorithms etc.) she is willing to use, in her order of preference (see Mandatory to Implement Technologies):

  1. The list of Modular Exponential (MODP) group numbers (as specified in RFC 2409 [21] or RFC 3526 [22]) she is willing to use for Diffie-Hellman key exchange (valid group numbers include 1,2,3,4,5,14,15,16,17 and 18)

  2. Stanza symmetric encryption algorithm names

  3. Hash algorithm names

  4. Compression algorithm names

  5. The list of stanza types she is willing to encrypt and decrypt

  6. Whether or not both entities MUST be connected securely to their servers (see Section 5 of RFC 3920)

  7. The minimum number of stanzas that MUST be exchanged before an entity MAY initiate a key re-exchange (1 - every stanza, 100 - every hundred stanzas). This value MUST be less than 232 (see Re-Keying Limits)

  8. The Base64 encoded (in accordance with Section 3 of RFC 3548 [23]) SHA-256 fingerprint (PKID) of each of Bob's public signature-verification keys that she found acceptable (see Verifying Keys)

Example 3. Alice Requests an ESession

<message from='alice@example.org/pda' to='bob@example.com'>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x type='form' xmlns='jabber:x:data'>
      <field type='hidden' var='FORM_TYPE'>
        <value>http://jabber.org/protocol/chatneg</value>
      </field>
      <field type='boolean' var='logging'>
        <value>1</value>
      </field>
      ...
      <field type='list-single' var='modp'>
        <option><value>5</value></option>
        <option><value>14</value></option>
        <option><value>2</value></option>
        <option><value>1</value></option>
      </field>
      <field type='list-single' var='crypt_algs'>
        <option><value>aes256-ctr</value></option>
        <option><value>twofish256-ctr</value></option>
        <option><value>aes128-ctr</value></option>
      </field>
      <field type='list-single' var='hash_algs'>
        <option><value>whirlpool</value></option>
        <option><value>sha256</value></option>
      </field>
      <field type='list-single' var='compress'>
        <option><value>none</value></option>
      </field>
      <field type='list-multi' var='stanzas'>
        <option><value>message</value></option>
        <option><value>iq</value></option>
        <option><value>presence</value></option>
      </field>
      <field type='boolean' var='secure'>
        <value>0</value>
      </field>
      <field type='text-single' var='rekey_freq'>
        <value>1</value>
      </field>
      <field type='list-multi' var='accept_pkids'>
        <option><value> ** PKID ** </value></option>
        <option><value> ** PKID ** </value></option>
      </field>
      ...
    </x>
  </feature>
</message>

If Bob does not support one or more of the options in each Esession field (except the 'accept_pkids' field), then he SHOULD return a <feature-not-implemented/> error (but he MAY return no error if, for example, he does not want to reveal his presence to Alice for whatever reason):

Example 4. Bob Informs Alice that Her Options Are Not Supported

<message type='error'
         from='bob@example.com/laptop'
         to='alice@example.org/pda'>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    ...
  </feature>
  <error code='501' type='cancel'>
    <feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</message>

Either Bob or Alice MAY attempt to initiate a new ESession after any error during the initiation process. However, both MUST consider the previous negotiation to have failed and MUST discard any information learned through the previous negotiation.

6.1.2 Diffie-Hellman Preparation (Bob)

If Bob is willing to start an ESession with Alice, he SHOULD retrieve Alice's long-term public signature-verification keys. He MUST select one of the options from each of the Esession fields he received from Alice including one of the MODP groups (see RFC 3766 [24] or RFC 3526 for recommendations regarding balancing the sizes of symmetric cipher blocks and Diffie-Hellman moduli). Each MODP group has at least two well known constants: a large prime number p, and a generator g for a subgroup of GF(p). Bob MUST then perform the following computations (where n is the number of bits per encryption block for the selected encryption algorithm):

  1. Generate the initial value of CA with n-1 random bits (CA is the encryption block counter for stanzas sent from Alice to Bob)

  2. Set CB = CA + 2n-1 (where CB is the counter for stanzas sent from Bob to Alice)

  3. Generate a secret random number y (where 22n-1 < y < p - 1)

  4. Calculate d = gy mod p

  5. Generate an opaque unique key identifier (KID) for d

6.1.3 Esession Response

Bob responds to Alice specifying the Esession options he selected.

If Bob is willing to start an ESession with Alice, then instead of providing the PKID of his public key that he selected, Bob MUST specify the Base64 encoded SHA-256 fingerprint (PKID) of each of Alice's public signature-verification keys that he finds acceptable (see Verifying Keys). Note: The submited values for the 'accept_pkids' field do not correspond to the options he received. The value of the 'rekey_freq' field MUST be less than 232 and greater than or equal to the value specified by Alice.

In addition to the fields he received from Alice, Bob MUST include the KID and the Base64 encoded values of d and CA. If Alice selected one or more of his public keys, and if Bob has access to a long-lived private signing key that corresponds to one of those keys [25], then he MUST also include the PKID. Otherwise (for example, if Bob is unable to publish keys to his server or if Alice is unable to access keys published via his server [26]), Bob MAY include one of his Base64 encoded public keys. In either case, Bob MUST include the Base64 encoded signature (see Signature Generation) of the content of the data form (excluding the 'signs' field).

However, if Bob is ready to initiate a one-to-one chat session with Alice (see Chat Session Negotiation) but he is unwilling to start an ESession, then he SHOULD terminate the Esession negotiation by not specifying any of the five extra values in his response.

Example 5. Bob Responds to Alice (with Public Key)

<message from='bob@example.com/laptop' to='alice@example.org/pda'>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x type='submit' xmlns='jabber:x:data'>
      <field var='FORM_TYPE'>
        <value>http://jabber.org/protocol/chatneg</value>
      </field>
      <field var='logging'><value>0</value></field>
      ...
      <field var='modp'><value>5</value></field>
      <field var='crypt_algs'><value>aes256-ctr</value></field>
      <field var='hash_algs'><value>sha256</value></field>
      <field var='compress'><value>none</value></field>
      <field var='stanzas'><value>message</value></field>
      <field var='secure'><value>0</value></field>
      <field var='rekey_freq'><value>50</value></field>
      <field var='accept_pkids'>
        <value> ** PKID ** </value>
        <value> ** PKID ** </value>
      </field>
      ...
      <field var='counter'>
        <value> ** Base64 encoded initial counter value ** </value>
      </field>
      <field var='kid'>
        <value> ** KID ** </value>
      </field>
      <field var='key'>
        <value> ** Base64 encoded value of d ** </value>
      </field>
      <field var='pkey'>
        <value> ** Base64 encoded public key ** </value>
      </field>
      <field var='signs'>
        <value> ** Base64 encoded signature of form ** </value>
      </field>
    </x>
  </feature>
</message>

Example 6. Bob Responds to Alice (with PKID)

<message from='bob@example.com/laptop' to='alice@example.org/pda'>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x type='submit' xmlns='jabber:x:data'>
      ...
      <field var='counter'>
        <value> ** Base64 encoded initial counter value ** </value>
      </field>
      <field var='kid'>
        <value> ** KID ** </value>
      </field>
      <field var='key'>
        <value> ** Base64 encoded value of d ** </value>
      </field>
      <field var='pkids'>
        <value> ** PKID ** </value>
      </field>
      <field var='signs'>
        <value> ** Base64 encoded signature of form ** </value>
      </field>
    </x>
  </feature>
</message>

If Alice provided a PKID but Bob did not provide a signature then she MAY send a failure notice to him. If Bob sent Alice a public key but she could not verify it belongs to him via secure out-of-band communication (see Verifying Keys) then she SHOULD send a failure notice to him. If Bob provided an invalid signature (see Signature Generation) then she MUST send a failure notice to him.

Example 7. Alice Signals that ESession Negotiation Failed (Unacceptable Signature)

<message type='error'
         from='alice@example.org/pda'
         to='bob@example.com/laptop'>
  <error code='406' type='modify'>
    <feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <invalid-signature xmlns='http://jabber.org/protocol/esession#error'/>
  </error>
</message>

6.1.4 Diffie-Hellman Preparation (Alice)

After verifying Bob's signature, Alice can be certain that the value of d was actually generated by Bob. Alice MUST use the value of d and the Esession options specified in Bob's response to perform the following steps (where n is the number of bits per encryption block for the agreed encryption algorithm):

  1. Set the initial value of CA to the counter value she received from Bob

  2. Set CB = CA + 2n-1

  3. Generate a secret random number x (where 22n-1 < x < p - 1)

  4. Calculate e = gx mod p

  5. Generate an opaque unique key identifier (KID) for e

  6. Calculate K = dx mod p (this is the shared secret)

6.1.5 Diffie-Hellman Completion

Alice then completes the Diffie-Hellman negotiation by sending Bob the KID and the Base64 encoded value of e. If Bob selected one or more of her public keys, and if Alice has access to a long-lived private signing key that corresponds to one of those keys, then she MUST also include the PKID. Otherwise, Alice MAY include one of her Base64 encoded public keys (see Esession Response example). In either case, Alice MUST include the Base64 encoded signatures (see Signature Generation) of the content of the data form from her initial Esession request and of the content of this data form (excluding the 'signs' field).

Alice MAY also send encrypted content (see Exchanging Stanzas) in the same stanza as the Diffie-Hellman completion. Note: If she also includes a <terminate/> element (see Esession Termination) within the <encrypted/> element then the Esession is terminated immediately. This special case, where a single stanza is encrypted and sent in isolation, is equivalent to object encryption (or object signing if no encryption is specified).

Example 8. Alice Completes Diffie-Hellman Negotitation (with PKID)

<message from='alice@example.org/pda' to='bob@example.com/laptop'>
  <init xmlns='http://jabber.org/protocol/esession#init'>
    <x xmlns='jabber:x:data'>
      <field var='kid'><value> ** KID ** </value></field>
      <field var='key'><value> ** Base64 encoded value of e ** </value></field>
      <field var='pkids'><value> ** PKID ** </value></field>
      <field var='req_sign'><value> ** Base64 encoded signature of her previous form ** </value></field>
      <field var='signs'><value> ** Base64 encoded signature of this form ** </value></field>
    </x>
  </init>
  <encrypted xmlns='http://jabber.org/protocol/esession'>
    <kid> ** KID ** </kid>
    <data> ** Base64 encoded m_final ** </data>
    <mac> ** Base64 encoded a_mac ** </mac>
  </encrypted>
</message>

If Bob provided a PKID but Alice did not provide a signature then he MAY send a failure notice to her. If Alice sent Bob a public key but he could not verify it belongs to her via secure out-of-band communication (see Verifying Keys) then he SHOULD send a failure notice to her. If Alice provided an invalid signature (see Signature Generation) then he MUST send a failure notice to her. If Bob sends a failure notice then he SHOULD ignore any encrypted content in the stanza.

If no error occurs, Bob MUST calculate K = ey mod p (the shared secret). Alice and Bob then have the same value for K and the key exchange is complete.

6.2 Offline Diffie-Hellman Key Exchange

As described below, offline negotiation of an Esession is in essence a special case of online negotiation. Bob MAY publish a set of Esession options just before he goes offline (see Offline Esessions Security Considerations) to allow entities that subscribe to his presence to initiate Esessions and send encrypted stanzas to him while he is offline. He MAY also publish another similar set of relatively long-lived [27] Esession options that any entity MAY use for the same purpose.

6.2.1 Publishing Esession Options

In order to publish either set of his offline Esession options Bob MUST perform the following steps:

  1. Generate a secret random number y (where 22n-1 < y < p - 1, where n is the largest number of bits per encryption block for the encryption algorithms he is willing to use)

  2. Select a MODP group (that defines the constants p and g)

  3. Calculate d = gy mod p

  4. Generate an opaque unique key identifier (KID) for d (typically by calculating a hash of d, since this KID SHOULD be unique across all Esessions)

  5. Store the values of y and d and the KID in a secure way, so that he can retrieve them when he comes back online (idealy even if that is using a different client and/or a different machine)

  6. Publish each of the Esession options he is willing to use (see Esession Request) including the value of d and the KID. He SHOULD do this through his own server using the disco#publish-info feature (as NOT SPECIFIED in JEP-0030) or a similar protocol (out of scope for this JEP).

Note: The single specified MODP group MUST be the one Bob used to generate d. The list of stanza types he is willing to decrypt MUST NOT include the value 'iq'. Bob MUST also include the list of the PKIDs of all his public signature-verification keys that he can sign for, and the corresponding list of Base64 encoded signatures (see Signature Generation) of the content of the data form (excluding the 'signs' field).

Note: This publishing protocol is highly preliminary and depends on a separate proposal.

Example 9. Bob Publishes His Esession Options for His Subscribers

<iq type='set' from='bob@example.com/laptop' id='es2'>
  <query xmlns='http://jabber.org/protocol/disco#info-subscription'
         node='http://jabber.org/protocol/esession#subscription'>
    <x type='submit' xmlns='jabber:x:data'>
      <field var='FORM_TYPE'>
        <value>http://jabber.org/protocol/esession</value>
      </field>
      <field var='logging'>
        <value>0</value>
      </field>
      ...
      <field var='modp'>
        <value>2</value>
      </field>
      <field var='crypt_algs'>
        <value>aes256-ctr</value>
        <value>twofish256-ctr</value>
        <value>aes128-ctr</value>
      </field>
      <field var='hash_algs'>
        <value>whirlpool</value>
        <value>sha256</value>
      </field>
      <field var='compress'>
        <value>none</value>
      </field>
      <field var='stanzas'>
        <value>message</value>
      </field>
      <field var='secure'>
        <value>0</value>
      </field>
      <field var='rekey_freq'>
        <value>1</value>
      </field>
      <field var='kid'>
        <value> ** KID ** </value>
      </field>
      <field var='key'>
        <value> ** Base64 encoded value of d ** </value>
      </field>
      <field var='pkids'>
        <value> ** PKID ** </value>
        <value> ** PKID ** </value>
      </field>
      <field var='signs'>
        <value> ** Base64 encoded signature of form ** </value>
        <value> ** Base64 encoded signature of form ** </value>
      </field>
    </x>
  </query>
</iq>

Bob MAY publish his Esession options for all entities using the same protocol except for the 'xmlns' and 'node' attributes of the <query/> element:

Example 10. Bob Publishes His Esession Options for All Entities

<iq type='set' from='bob@example.com/laptop' id='es2'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://jabber.org/protocol/esession'>
    <x type='submit' xmlns='jabber:x:data'>
      ...
    </x>
  </query>
</iq>

6.2.2 Requesting Offline Esession Options

If Alice believes Bob is offline she SHOULD request his Esession options and his long-term public signature-verification keys (see Public Key Publication and Retrieval) from his server.

If Alice is subscribing to Bob's presence she MUST request his Esession Options exclusively for subscribers.

Example 11. Alice asks Bob's Server for his Esession Options (Subscribers)

<iq type='get'
    from='alice@example.org/pda'
    to='bob@example.com'
    id='es3'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://jabber.org/protocol/esession#subscription'/>
</iq>

If Alice is not subscribing to Bob's presence (or if Bob has no Esession Options exclusively for subscribers) she MUST use the following request instead.

Example 12. Alice asks Bob's Server for his Esession Options (All Entities)

<iq type='get'
    from='alice@example.org/pda'
    to='bob@example.com'
    id='es3'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://jabber.org/protocol/esession'/>
</iq>

If, after receiving Bob's public keys and Esession options, Alice is unable to verify any of Bob's signatures (see Signature Generation) then she MAY decide to proceed no further, since she cannot be sure who will be able to decrypt her stanzas.

6.2.3 Diffie-Hellman Preparation (Offline)

Alice MUST select one of the options from each of Bob's Esession fields. If she cannot support any of the options in a field (except the 'pkids' and 'signs' fields) then she MUST not send encrypted stanzas to Bob while he is offline.

Alice MUST use the value of d and the MODP group specified in Bob's Esession options to perform the following steps (where n is the number of bits per encryption block for the selected encryption algorithm):

  1. Generate the initial value of CA with n-1 random bits (CA is the encryption block counter for stanzas sent from Alice to Bob)

  2. Set CB = CA + 2n-1 (where CB is the counter for stanzas sent from Bob to Alice - in case Bob comes online before Alice terminates the Esession)

  3. Generate a secret random number x (where 22n-1 < x < p - 1)

  4. Calculate e = gx mod p

  5. Generate an opaque unique key identifier (KID) for e

  6. Calculate K = dx mod p (the shared secret)

6.2.4 Starting an Offline Esession

Alice then sends Bob the KID and the Base64 encoded values of e and CA. She SHOULD also include the list of the PKIDs of all her public signature-verification keys that she can sign for, and the corresponding list of Base64 encoded signatures (see Signature Generation) of the content of the data form (excluding the 'signs' field).

She also specifies which of Bob's Esession options she selected. Note: The value of the 'rekey_freq' field MUST be less than 232 and greater than or equal to the value specified by Bob.

Alice MAY also send encrypted content (see the Exchanging Stanzas section of this document) in the same stanza. Note: If she also includes a <terminate/> element (see Esession Termination) within the <encrypted/> element then the Esession is terminated immediately. This special case, where a single stanza is encrypted and sent in isolation, is equivalent to object encryption (or object signing if no encryption is specified).

Example 13. Alice Establishes an ESession Without Negotiation

<message from='alice@example.org/pda' to='bob@example.com' type='chat'>
  <init xmlns='http://jabber.org/protocol/esession#init'>
    <x xmlns='jabber:x:data'>
      <field var='logging'><value>0</value></field>
      <field var='modp'><value>5</value></field>
      <field var='crypt_algs'><value>aes256-ctr</value></field>
      <field var='hash_algs'><value>sha256</value></field>
      <field var='compress'><value>none</value></field>
      <field var='rekey_freq'><value>1</value></field>
      <field var='stanzas'><value>message</value></field>
      <field var='secure'><value>0</value></field>
      <field var='counter'><value> ** Base64 encoded initial counter value ** </value></field>
      <field var='kid'><value> ** KID ** </value></field>
      <field var='key'><value> ** Base64 encoded value of e ** </value></field>
      <field var='pkids'>
        <value> ** PKID ** </value>
        <value> ** PKID ** </value>
      </field>
      <field var='signs'>
        <value> ** Base64 encoded signature of form ** </value>
        <value> ** Base64 encoded signature of form ** </value>
      </field>
    </x>
  </init>
  <encrypted xmlns='http://jabber.org/protocol/esession'>
    <kid> ** KID ** </kid>
    <data> ** Base64 encoded m_final ** </data>
    <mac> ** Base64 encoded a_mac ** </mac>
  </encrypted>
</message>

Alice can assume that she and Bob have the same value for K and that the key exchange is complete.

6.2.5 Accepting Offline Esessions

When Bob comes online he MUST perform the following steps:

  1. Retrieve the two sets of Esession options he MAY have published (see Publishing Esession Options)

  2. Ensure he is no longer publishing offline Esession options exclusively for entities that are subscribing to his presence

    Example 14. Bob Stops Publishing His Esession Options

    <iq type='set' from='bob@example.com/laptop' id='es4'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://jabber.org/protocol/esession#subscription'>
    <x type='submit' xmlns='jabber:x:data'/>
  </query>
</iq>

  3. Retrieve any values of y, d and KID that he stored before going offline, and destroy in a secure way any persistently stored copies that correspond to Esession options exclusively for subscribers

  4. Confirm those values of d and KID match the published values. They may not match if, for example, he went offline using a different client and/or a different machine. Note: if they do not match then he cannot decrypt any offline Esessions he receives.

When Bob receives a key exchange stanza from Alice then he MUST perform the following steps:

  1. Confirm that the KID he received from Alice matches one of the KIDs he published

  2. Confirm that he can support all the Esession options he received from Alice

  3. Confirm that he has not already received a key exchange stanza from Alice with the same value of e since he came online (see Replay Attacks)

  4. Request Alice's public keys and, if possible, verify one of her signatures (see Signature Generation; if he is unable to verify any of her signatures then he MAY decide to proceed no further, since he cannot be sure who started the Esession)

  5. Set the initial value of CA to the counter value he received from Alice

  6. Set CB = CA + 2n-1 (in case Alice has not yet terminated the Esession)

  7. Calculate K = ey mod p (the shared secret)

6.3 Generating Session Keys

Whichever method Alice used to perform the Diffie-Hellman key exchange (online or offline), once it is complete, then before Alice and Bob can start encrypting and decrypting stanzas they MUST both use the agreed hash algorithm ("HASH") and their full JIDs to generate two pairs of keys, one for each direction of the ESession. Note: JIDB MUST be Bob's bare JID throughout an offline Esession, even if he comes online in the middle of the Esession and the key is re-exchanged.

For stanzas that Alice will send to Bob, the keys are calculated as:

  1. Encryption key K-EA = HASH(K, JIDA)

  2. Integrity key K-MA = HASH(K-EA, JIDB) [28]

For stanzas that Bob will send to Alice the keys are calculated as:

  1. Encryption key K-EB = HASH(K, JIDB)

  2. Integrity key K-MB = HASH(K-EB, JIDA)

Once the two pairs of keys have been calculated the value of K MUST be securely destroyed.

As many bytes of key data as are needed MUST be taken from the beginning of the hash output. When negotiating a hash, entities MUST ensure that the hash output is no shorter than the required key data. For algorithms with variable-length keys the maximum length (up to the hash output length) SHOULD be used.

With these keys computed and the algorithms agreed upon, ESession initiation is now complete. From this point forward, Alice and Bob MUST exchange only encrypted forms of the one-to-one stanza types they agreed upon (e.g., <message/> and <iq/> stanzas).

7. Exchanging Stanzas

7.1 Encryptable Content

Once an Esession has been established, whenever Alice wants to send Bob an encrypted stanza she MUST only encrypt the XML content that would normally be ignored by the intermediate servers. She MUST NOT encrypt stanza wrapper elements or Advanced Message Processing elements.

If this is an offline Esession then Alice SHOULD include a 'Created' SHIM header in the encrypted content. Bob SHOULD trust this header and ignore the unencrypted Delayed Delivery [29] element inserted by his server.

Example 15. Unencrypted Stanza

<message from='alice@example.org/pda'
         to='bob@example.com/laptop'
         type='chat'>
  <body>Hello, Bob!</body>
  <amp per-hop='true' xmlns='http://jabber.org/protocol/amp'>
    <rule action='error' condition='match-resource' value='exact'/>
  </amp>
  <headers xmlns='http://jabber.org/protocol/shim'>
    <header name='Created'>2005-02-10T03:01:52Z</header>
  </headers>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>

Example 16. XML Content to be Encrypted

<body>Hello, Bob!</body>
<headers xmlns='http://jabber.org/protocol/shim'>
  <header name='Created'>2005-02-10T03:01:52Z</header>
</headers>
<active xmlns='http://jabber.org/protocol/chatstates'/>

7.2 Encryption

Alice MUST perform the following steps to encrypt the XML content. Note: if there is no XML content to be encrypted (e.g. if this is an empty Re-Keying or Termination stanza), then CA MUST be incremented by 1 (see below), and only the last two steps (canonicalization and MAC calculation) should be performed.

  1. Serialize the XML content she wishes to send into an array of UTF-8 bytes, m. [30]

  2. Compress m using the negotiated algorithm. If a compression algorithm other than 'none' was agreed, the compression context is typically initialized after key exchange and passed from one stanza to the next, with only a partial flush at the end of each stanza. [31]

    m_compressed = compress(m)

  3. Encrypt the data with the agreed algorithm in counter mode, using the encryption key K-EA. Note: CA MUST be incremented for each encrypted block or partial block, and if CA=2n-1 (where n is the number of bits per encryption block for the agreed encryption algorithm) then CA MUST be "incremented" to 1. Note: if the encryption algorithm 'none' was agreed (see Unencrypted Esessions) then encryption MUST NOT be performed and CA MUST be incremented by 1.

    m_final = encrypt(K-EA, CA, m_compressed)

  4. Alice MUST now create the XML content of the <encrypted/> XML element (with no CDATA between any of the elements) in canonical form (see Canonical XML [32]). The XML MUST include Bob's KID (the one that corresponds to the value of d she used to encrypt the data) wrapped in a <kid/> element and, if there is XML content, the Base64 encoded value of m_final wrapped in a <data/> element. Note: it MAY also contain one <terminate/> element (see Termination), one <key/> element and one or more <old/> elements (see Re-Keying).

    m_content = '<kid> ** KID ** </kid><data> ** Base64 encoded m_final ** </data>'

  5. The XML content and the value of Alice's encryption block counter CA before the data was encrypted, are now processed through the HMAC algorithm (as defined in Section 2 of RFC 2104 [33]), along with the agreed hash algorithm ("HASH") and the integrity key K-MA.

    a_mac = HMAC(HASH, K-MA, m_content, CA)

7.3 Sending an Encrypted Stanza

Before sending the stanza to Bob, Alice MUST wrap m_content and the Base64 encoded value of a_mac (wrapped in a <mac/> element) inside an <encrypted/> element and insert it into the stanza in place of the original content. There MUST NOT be more than one <encrypted/> element per stanza.

Example 17. Message Stanza with Encrypted Content

<message from='alice@example.org/pda'
         to='bob@example.com/laptop'
         type='chat'>
  <encrypted xmlns='http://jabber.org/protocol/esession'>
    <kid> ** KID ** </kid>
    <data> ** Base64 encoded m_final ** </data>
    <mac> ** Base64 encoded a_mac ** </mac>
  </encrypted>
  <amp per-hop='true' xmlns='http://jabber.org/protocol/amp'>
    <rule action='error' condition='match-resource' value='exact'/>
  </amp>
</message>

7.4 Decryption

When Bob receives the stanza from Alice, he extracts and Base64 decodes the values of m_final and a_mac from the content and performs the following steps. Note: Alice may not have received Bob's last re-key (see Re-Keying) before sending the stanza. So Bob MUST ensure he uses the values of K-EA and K-MA that correspond to his KID that Alice specified in the <kid/> element of the stanza he received (and the current value of e that Alice sent him previously).

  1. Remove the <mac/> element from the <encrypted/> element and convert the remaining XML content into canonical form (with no CDATA between any of the elements, see Canonical XML). Calculate the Message Authentication Code (MAC) for the content.

    b_mac = HMAC(HASH, K-MA, m_content, CA)

  2. Verify that b_mac and a_mac match. If they are not identical, the content has been tampered with and Bob MUST terminate the ESession by sending an error to Alice. [34]

  3. Decrypt m_final using the agreed algorithm, K-EA and CA. Note: CA MUST be incremented for each decrypted block, and if CA=2n-1 (where n is the number of bits per encryption block for the agreed encryption algorithm) then CA MUST be "incremented" to 1. Note: if the encryption algorithm 'none' was agreed decryption MUST NOT be performed and CA MUST be incremented by 1.

    m_compressed = decrypt(K-EA, CA, m_final)

  4. Decompress m_compressed using the negotiated algorithm (usually 'none').

    m = decompress(m_compressed)

  5. Replace the <encrypted/> element in the serialized XML stanza with m and feed the stanza into an XML parser. If the parser returns an XML format error then Bob MUST terminate the ESession by sending an error to Alice. [35]

8. Re-Key Exchange

Once an attacker has discovered an encryption key it could be used to decrypt all stanzas within a session, including stanzas that were intercepted before the key was discovered. To reduce the window of vulnerability, both Alice and Bob SHOULD change their values of x and y and re-exchange the encryption key as regularly as possible. They MUST also destroy all copies of keys as soon as they are no longer needed.

Note: Although most entities are capable of re-keying after each stanza, clients running in constrained runtime environments may require a few seconds to re-key. During Esession initiation these clients MAY negotiate the minimum number of stanzas to be exchanged between re-keys at the cost of a larger window of vulnerability. Entities MUST NOT initiate key re-exchanges more frequently than the agreed limit.

8.1 Re-Key Initiation

Either Alice or Bob MAY initiate a key re-exchange. Here we describe the process initiated by Alice. First she MUST calculate new values for the encryption parameters:

  1. Generate a secret random number x (where 22n-1 < x < p - 1, where n is the number of bits per encryption block for the agreed encryption algorithm)

  2. Calculate e = gx mod p

  3. Generate an opaque unique key identifier (KID) for e

  4. Calculate K = dx mod p (the new shared secret)

  5. Calculate K-EA, K-MA, K-EB, K-MB (see Generating Session Keys)

To avoid extra stanzas, the new value of e SHOULD be sent to Bob along with an encrypted stanza. Note: Alice MUST NOT use the new K-EA and K-MA to encrypt this stanza or to calculate the MAC. However, she MUST use them when sending subsequent stanzas.

Note: There is no need for Alice to provide a signature because the calculation of the MAC includes the new value of e, see Exchanging Stanzas).

Example 18. Alice Sends Re-Key Stanza

<message from='alice@example.org/pda' to='bob@example.com/laptop'>
  <encrypted xmlns='http://jabber.org/protocol/esession'>
    <kid> ** KID ** </kid>
    <data> ** Base64 encoded m_final ** </data>
    <key kid=' ** KID ** '> ** Base64 encoded value of new e ** </key>
    <mac> ** Base64 encoded a_mac ** </mac>
  </encrypted>
</message>

Note: Bob may not receive the new key before he sends his next stanzas (they may cross in transit). So, before destroying her old values of K-EB and K-MB, Alice MUST wait until either she receives a stanza encrypted with the new key, or a reasonable time has passed (60 seconds should cover a network round-trip and calculations by a constrained client). Similarly she MUST wait before destroying her old value of x, in case Bob sends two stanzas before receiving Alice's new key (the first stanza might include a re-key).

8.2 Re-Key Acceptance

After Bob receives a stanza with a new value of e and he has decrypted the stanza with the old value of K-EA, he MUST securely destroy all copies of K-EA and K-EB and perform the following calculations with the new value of e:

  1. Calculate K = ey mod p

  2. Calculate K-EA, K-MA, K-EB, K-MB (see Generating Session Keys)

He MUST use these new values to encrypt and decrypt all subsequent stanzas. [36]

8.3 Publishing Old MAC Values

Once the expired MAC keys have been published, anyone could create valid arbitrary stanzas with them. This prevents anyone being able to prove the authenticity of a transcript of the Esession in the future.

Either entity MAY publish old values of K-MA and/or K-MB within any encrypted stanza as long as it knows that all the stanzas that MAY use the old values have been received and validated. Note: A 'man-in-the-middle' could delay the delivery of stanzas indefinitely. So, before Alice publishes K-MA (and K-MB), she MUST wait until she has both sent a re-key to Bob and received a stanza from Bob encrypted with her new key. (She MAY also publish K-MB after she has received a re-key from Bob.)

Example 19. Publishing Expired MAC Keys

<message from='alice@example.org/pda' to='bob@example.com/laptop'>
  <encrypted xmlns='http://jabber.org/protocol/esession'>
    <kid> ** KID ** </kid>
    <data> ** Base64 encoded m_final ** </data>
    <old> ** Base64 encoded old MAC key ** </old>
    <old> ** Base64 encoded old MAC key ** </old>
    <mac> ** Base64 encoded a_mac ** </mac>
  </encrypted>
</message>

Entities SHOULD ignore any <old/> elements they receive.

9. Esession Termination

Either entity MAY terminate an Esession at any time. To terminate a session Alice MUST send a stanza to Bob including a <terminate/> element. Note: She MAY publish old values of K-MA and/or K-MB within her termination stanza as long as she is sure all the stanzas that MAY use the old values have been received and validated (see Publishing Old MAC Values). She MUST then securely destroy all keys associated with the Esession.

Example 20. Alice Terminates an Esession

<message from='alice@example.org/pda' to='bob@example.com/laptop'>
  <encrypted xmlns='http://jabber.org/protocol/esession'>
    <kid> ** KID ** </kid>
    <terminate/>
    <old> ** Base64 encoded old MAC key ** </old>
    <mac> ** Base64 encoded a_mac ** </mac>
  </encrypted>
</message>

When Bob receives a termination stanza he MUST verify the MAC (to be sure he received all the stanzas Alice sent him during the Esession) and, if the stanza was sent to him while he was online, immediately send a termination stanza back to Alice. Note: He MAY publish any old values of K-MA or K-MB within the termination stanza. He MUST then securely destroy all keys associated with the Esession.

Example 21. Bob Confirms Esession Termination

<message from='alice@example.org/pda' to='bob@example.com/laptop'>
  <encrypted xmlns='http://jabber.org/protocol/esession'>
    <kid> ** KID ** </kid>
    <terminate/>
    <old> ** Base64 encoded old MAC key ** </old>
    <mac> ** Base64 encoded b_mac ** </mac>
  </encrypted>
</message>

When Alice receives the stanza she MUST verify the MAC to be sure she received all the stanzas Bob sent her during the Esession. Once an entity has sent a termination stanza it MUST NOT send another stanza within the Esession.

10. Signature Generation

Before the signature of a block of XML is calculated, all CDATA between all elements must be removed and the XML MUST be converted to canonical form (see Canonical XML).

10.1 Canonical Form (Informative)

11. Security Considerations

11.1 Random Numbers

Weak pseudo-random number generators (PRNG) enable successful attacks. Implementors MUST use a cryptographically strong PRNG to generate all random numbers (see RFC 1750 [37]).

11.2 Re-Keying Limits

After a key exchange an entity MUST NOT exchange a total of 232 encrypted blocks before it initiates a key re-exchange (see SSH Transport Layer Encryption Modes [38]). Note: This limitation also ensures the same key and counter values are never used to encrypt two different blocks using counter mode (thus preventing simple attacks).

In order to reduce the Perfect Forward Secrecy window of vulnerability, after an extended period of activity, entities SHOULD either re-key or terminate the Esession.

11.3 Verifying Keys

The trust system outlined in this document is based on Alice trusting that the public key presented by Bob is actually Bob's key (and vice versa). Determining this trust may be done in a variety of ways depending on the entities' support for different public key (certificate) formats, signing algorithms and signing authorities. For instance, if Bob publishes a PGP/GPG public key, Alice MAY verify that his key is signed by another key that she knows to be good. Or, if Bob provides an X.509 certificate, she MAY check that his key has been signed by a Certificate Authority that she trusts.

When trust cannot be achieved automatically, methods that are not transparent to the users may be employed. For example, Bob could communicate the SHA-256 fingerprint of his public key to Alice via secure out-of-band communication (e.g. face-to-face). This would enable Alice to confirm that the public key she receives in-band is valid. Note however that very few people bother to verify fingerprints in this way. So this method is exceptionally vulnerable to 'man-in-the-middle' attacks. In order to reduce the window of vulnerability, an entity SHOULD remember the fingerprints of all user-validated public keys and alert the user in the future if ever the fingerprint(s) it stored for an entity do not match any of the received public keys.

Alternatively Alice and Bob could agree a shared secret via secure out-of-band communication, Bob could then use it to create an HMAC of his public key that only Alice could verify.

Note: If no keys are acceptable to Alice (because Alice has never verified any of the keys, and because either the keys are not signed, or Alice does not support the signature algorithms of the keys, or she cannot parse the certificate formats, or she does not recognise the authorities that signed the keys) then, although the Esession can still be encrypted, she cannot be sure she is communicating with Bob.

11.4 Replay Attacks

The encryption block counters maintained implicitly by Alice and Bob (CA and CB) prevent stanzas being replayed within any Esession. They ensure that the MAC will be different for all stanzas, even if the HMAC key and the content of the stanza are identical.

Alice and Bob MUST ensure that the value of e or d they provide when negotiating each online Esession is unique. This prevents complete online Esessions being replayed.

Since Bob supplies the same value of d for all offline Esessions, to prevent complete offline Esessions being replayed to him, he MUST take care to securely store new values (or destroy existing values) of y and KID whenever he goes offline (see Publishing Esession Options). Also, when Bob next comes online, he MUST remember all the values of e he receives in offline Esession initiation stanzas, and reject any offline Esessions that specify a value of e he has already received (see Accepting an Offline Esession).

11.5 Unencrypted Esessions

Organisations with full disclosure policies may require entities to disable encryption to enable the logging of all messages on their server. Unencrypted Esessions meet all the Security Requirements except for Confidentiality. This enables Alice to use the 'secure' Esession option to confirm securely with Bob that both client-server connections are secure.

11.6 Storage

If either entity stores a (re-encrypted) transcript of an Esession for future consultation then the Perfect Forward Secrecy offered by this protocol is lost. If the negotiated value of the 'logging' Chat Session Negotiation field is false the entities SHOULD NOT store any part of the Esession content (not even in encrypted form).

11.7 Offline Esessions

Bob MAY decide not to support Offline Esessions since they are significantly less secure than online Esessions. The Perfect Forward Secrecy window of vulnerability is much longer. More seriously, Bob MUST store his private Diffie-Hellman key, y, to local disk or to a server (perhaps symmetrically encrypted with a password). It is really hard to securely erase something from a disk. Note: If Bob does not support Offline Esessions then, while he is offline, Alice will probably send him completely unprotected messages!

11.8 Extra Responsabilities of Implementors

Cryptography plays only a small part in an entity's security. Even if it implements this protocol perfectly it may still be vulnerable to other attacks. For examples, an implementation might store Esession keys on swap space or save private keys to a file in cleartext! Implementors MUST take very great care when developing applications with secure technologies.

11.9 Mandatory to Implement Technologies

An implementation of ESession MUST support the Diffie-Hellman Key Agreement and HMAC algorithms. Note: The parameter names mentioned below are related to secure shell; see SSH Transport Layer Encryption Modes for encryption algorithm details; see the IANA Secure Shell Protocol Parameters [39] for other names.

11.9.1 Encryption Algorithms

An implementation of ESession MUST support at least the following encryption algorithm:

The block length of an encryption algorithm's cipher SHOULD be at least 128 bits. An implementation of ESession MAY also support the following encryption algorithms:

11.9.2 Key Signing Algorithms

An implementation of ESession MUST support at least the following signing algorithm:

An implementation of ESession SHOULD also support at least the following signing algorithm:

11.9.3 Public Signature-Verification-Key Formats

An implementation of ESession MUST support the following public key formats:

An implementation of ESession SHOULD also support at least the following public key formats:

An implementation of ESession MAY also support the following public key formats:

11.9.4 Hash Algorithms

An implementation of ESession MUST support the following hash algorithm:

An implementation of ESession SHOULD also support at least the following hash algorithm (sha1 and md5 are NOT RECOMMENDED):

11.9.5 Compression Algorithms

An implementation of ESession MUST support the following compression algorithm:

Support for other algorithms is NOT RECOMMENDED since compression partially defeats the Repudiability requirement of this JEP by making it more difficult for a third party (with some knowledge of the plaintext) to modify a transcript of an encrypted session in a meaningful way. However, encrypted content is pseudo-random and cannot be compressed, so, in those cases where bandwidth is severely constrained, an implementation of ESession MAY support the following algorithm to compress content before it is encrypted:

12. IANA Considerations

This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [49].

13. Jabber Registrar Considerations

13.1 Namespaces

Upon approval of this JEP, the Jabber Registrar [50] shall register the following namespaces:

13.2 Field Standardization

The Jabber Registrar shall reserve the following fields within the scope of Data Forms used for ESession negotation:

Registry Submission

<form_type>
  <name>http://jabber.org/protocol/esession</name>
  <jep>JEP-0116</jep>
  <desc>ESession negotiation forms</desc>
  <field
      var='modp'
      type='list-single'
      label='MODP group number'/>
  <field
      var='crypt_algs'
      type='list-single'
      label='Symmetric block cipher options'/>
  <field
      var='hash_algs'
      type='list-single'
      label='Hash algorithm options'/>
  <field
      var='compress'
      type='list-single'
      label='Compression algorithm options'/>
  <field
      var='stanzas'
      type='list-multi'
      label='Stanzas types to encrypt'/>
  <field
      var='secure'
      type='boolean'
      label='Require encrypted client-server streams'/>
  <field
      var='rekey_freq'
      type='text-single'
      label='Minimum number of stanzas between key exchanges'/>
  <field
      var='accept_pkids'
      type='list-multi'
      label='Acceptable public key IDs'/>
  <field
      var='counter'
      type='hidden'
      label='Initial block counter'/>
  <field
      var='kid'
      type='hidden'
      label='Diffie-Hellman key ID'/>
  <field
      var='key'
      type='hidden'
      label='Diffie-Hellman key'/>
  <field
      var='pkey'
      type='hidden'
      label='Public key'/>
  <field
      var='pkids'
      type='list-single'
      label='Public key IDs'/>
  <field
      var='signs'
      type='list-single'
      label='Data form signatures'/>
  <field
      var='req_sign'
      type='hidden'
      label='Signature of initial request data form'/>
</form_type>

14. XML Schemas

To follow.

15. Public Key Publication and Retrieval

Note: This section is highly preliminary and will be specified in a separate proposal before this document reaches draft status.

Entities SHOULD publish their long-term public signature-verification keys to all entities through their own server using the disco#publish-info feature (as NOT SPECIFIED in JEP-0030).

Example 22. Entity Publishes Public Keys to Server

<iq type='set' from='alice@example.org/pda' id='dp1'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://jabber.org/protocol/publickeys'>
    <x type='submit' xmlns='jabber:x:data'>
      <field var='FORM_TYPE'>
        <value>http://jabber.org/protocol/publickeys</value>
      </field>
      <field var='types'>
        <value>x509v3-sign-rsa</value>
        <value>pgp-sign-dss</value>
        <value>ssh-rsa</value>
        <value>ssh-dss</value>
      </field>
      <field var='keys'>
        <value> ** Base64 encoded x509 certificate containing RSA public key ** </value>
        <value> ** Base64 encoded OpenPGP certificate containing DSS public key ** </value>
        <value> ** Base64 encoded unsigned RSA public key ** </value>
        <value> ** Base64 encoded unsigned DSS public key ** </value>
      </field>
    </x>
  </query>
</iq>

Before initiating an ESession, if Bob does not already possess one of Alice's signature-verification keys, he SHOULD retrieve them from Alice's server.

Example 23. Bob Requests Public Keys from Alice's Server

<iq type='get'
    from='bob@example.com/laptop'
    to='alice@example.org'
    id='dp2'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://jabber.org/protocol/publickeys'/>
</iq>

Example 24. Server Returns Public Keys

<iq type='result'
    from='alice@example.org'
    to='bob@example.com/laptop'
    id='dp2'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://jabber.org/protocol/publickeys'>
    <x type='result' xmlns='jabber:x:data'>
      <field var='FORM_TYPE'>
        <value>http://jabber.org/protocol/publickeys</value>
      </field>
      <field var='types'>
        <value>x509v3-sign-rsa</value>
        <value>pgp-sign-dss</value>
        <value>ssh-rsa</value>
        <value>ssh-dss</value>
      </field>
      <field var='keys'>
        <value> ** Base64 encoded x509 certificate containing RSA public key ** </value>
        <value> ** Base64 encoded OpenPGP certificate containing DSS public key ** </value>
        <value> ** Base64 encoded unsigned RSA public key ** </value>
        <value> ** Base64 encoded unsigned DSS public key ** </value>
      </field>
    </x>
  </query>
</iq>

Bob should examine all the public keys and identify which ones are acceptable (see Verifying Keys).

16. Open Issues

16.1 To Think About

  1. Object signing is relatively inefficient if the same message will be sent to many entities (borderline one-to-many)
  2. What challenges exist to make the OTR Gaim Plugin use this protocol natively when talking to Jabber entities? Can these be mitigated by 'non-critical' protocol changes?
  3. Would anything in this protocol (e.g., its dependency on in-order stanza delivery) prevent an XMPP entity using it to exchange encrypted messages and presence with a user of a non-XMPP messaging system, assuming that the gateway both supports this protocol and is compatible with a purpose-built security plugin on the other user's client (e.g. a Gaim plugin connects to the gateway via a non-XMPP network)?
  4. Could the protocol approximate SSH (or IPsec) more closely without losing the benefits of OTR?

16.2 To Do

  1. Perhaps the JEP needs to specify more carefully how block counters are handled between messages, especially in the event of partial blocks?
  2. Define names for X.509 SubjectPublicKeyInfo public key formats (different to X.509 certificates). This format must be used when keys are distributed within session initiation.
  3. Discuss signature formats in greater detail.
  4. Give examples of specific errors and discuss error scenarios throughout document (e.g., what should Bob do if he is not offline and he receives an offline key exchange stanza?).
  5. Update Dependencies list
  6. Separate public key publishing into another JEP. Should there be a disco item for each key?
  7. Define an optional protocol that would allow Bob to store y (and the PKIDs he trusts) 'securely' on his own server (before he goes offline). After going online Bob should retrieve the values of y that he stored before going offline (if any), and then use Flexible Offline Message Retrieval [51] to prevent any offline Esessions he can't decrypt being delivered to him (Each <item/> that corresponds to an Esession message MUST contain a <kid/> child. This allows Bob to discover which of his KIDs was used to encrypt the message. N.B. This requires a new server feature, only Jive and XCP support FOMR!). Bob SHOULD NOT request messages whose KID does not correspond to one of the values of y he retrieved. This is most likely to occur if he prefered not to store y on his server (because local storage is more secure), and he went offline using a different client and/or a different machine.

Notes

1. JEP-0027: Current Jabber OpenPGP Usage <http://www.jabber.org/jeps/jep-0027.html>.

2. RFC 3862: Common Presence and Instant Messaging (CPIM): Message Format <http://www.ietf.org/rfc/rfc3862.txt>.

3. RFC 3863: Presence Information Data Format (PIDF) <http://www.ietf.org/rfc/rfc3863.txt>.

4. RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) <http://www.ietf.org/rfc/rfc3923.txt>.

5. Off-the-Record Communication, or, Why Not to Use PGP <http://www.isaac.cs.berkeley.edu/~iang/pubs/otr-wpes.pdf>.

6. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.

7. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.

8. RFC 2246: The TLS Protocol Version 1.0 <http://www.ietf.org/rfc/rfc2246.txt>.

9. JEP-0096: File Transfer <http://www.jabber.org/jeps/jep-0096.html>.

10. JEP-0079: Advanced Message Processing <http://www.jabber.org/jeps/jep-0079.html>.

11. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.

12. JEP-0060: Publish-Subscribe <http://www.jabber.org/jeps/jep-0060.html>.

13. SSH Protocol Architecture <http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-22.txt>. Work in progress.

14. SSH Transport Layer Protocol <http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-24.txt>. Work in progress.

15. The reliable association between an entity and its public keys is beyond the scope of this JEP.

16. Naturally, it is possible that Alice or Bob may retain cleartext versions of the exchanged communications; however, that threat is out of scope for this JEP.

17. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.

18. JEP-0115: Entity Capabilities <http://www.jabber.org/jeps/jep-0115.html>.

19. RFC 2631: Diffie-Hellman Key Agreement Method <http://www.ietf.org/rfc/rfc2631.txt>.

20. JEP-0155: Chat Session Negotiation <http://www.jabber.org/jeps/jep-0155.html>.

21. RFC 2409: The Internet Key Exchange (IKE) <http://www.ietf.org/rfc/rfc2409.txt>.

22. RFC 3526: More Modular Exponential (MODP) Diffie-Hellman Groups <http://www.ietf.org/rfc/rfc3526.txt>.

23. RFC 3548: The Base16, Base32, and Base64 Data Encodings <http://www.ietf.org/rfc/rfc3548.txt>.

24. RFC 3766: Determining Strengths For Public Keys Used For Exchanging Symmetric Keys <http://www.ietf.org/rfc/rfc3766.txt>.

25. The private signing keys may only be accessible to another of Bob's clients.

26. Some servers may not support public key publishing.

27. The more often Bob changes his published Esession options, the shorter the Perfect Forward Secrecy window of vulnerability. However, whenever he changes them he divulges his presence to all the entities that are monitoring them.

28. K-MA is a hash of K-EA (not K) to ensure that if an attacker recovers the decryption key she will not be able to cryptographically convince anyone that it was not her who created the stanza.

29. JEP-0091: Delayed Delivery <http://www.jabber.org/jeps/jep-0091.html>.

30. Although counter mode encryption requires no padding, implementations MAY still disguise the length of m by appending a random number of white-space characters.

31. If Bob were to receive a stanza out-of-order, then he would fail to decrypt the stanza and be forced to terminate the Esession.

32. Canonical XML 1.0 <http://www.w3.org/TR/xml-c14n>.

33. RFC 2104: HMAC: Keyed-Hashing for Message Authentication <http://www.ietf.org/rfc/rfc2104.txt>.

34. If Bob were to receive a stanza out-of-order, then the MACs would not match because the values of CA would not be synchronized.

35. Bob MUST NOT send a stream error to his server since intermediate entities are not responsible for encoded content.

36. If an entity fails to receive any stanza that includes a new key in the correct order, then it will fail to decrypt the next stanza it receives and be forced to terminate the Esession.

37. RFC 1750: Randomness Recommendations for Security <http://www.ietf.org/rfc/rfc1750.txt>.

38. SSH Transport Layer Encryption Modes <http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-04.txt>. Work in progress.

39. IANA registry of parameters related to secure shell <http://www.iana.org/assignments/ssh-parameters>.

40. Advanced Encryption Standard: Federal Information Processing Standards Publication 197 <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.

41. The Twofish Block Cipher <http://www.schneier.com/twofish.html>.

42. The Serpent Block Cipher <http://www.cl.cam.ac.uk/~rja14/serpent.html>.

43. RFC 2437: PKCS #1: RSA Cryptography Specifications Version 2.0 <http://www.ietf.org/rfc/rfc2437.txt>.

44. Digital Signature Standard: Federal Information Processing Standards Publication 186 <http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf>.

45. X.509 Authentication in SSH2 <http://www.ietf.org/internet-drafts/draft-ietf-secsh-x509-02.txt>. Work in progress.

46. Secure Hash Standard: Federal Information Processing Standards Publication 180-2 <http://csrc.nist.gov/publications/fips/fips180-2/fips186-2withchangenotice.pdf>.

47. The Whirlpool Hash Function <http://paginas.terra.com.br/informatica/paulobarreto/WhirlpoolPage.html>.

48. RFC 1950: ZLIB Compressed Data Format Specification version 3.3 <http://www.ietf.org/rfc/rfc1950.txt>.

49. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

50. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.

51. JEP-0013: Flexible Offline Message Retrieval <http://www.jabber.org/jeps/jep-0013.html>.

Revision History

Version 0.6 (2004-08-12)

Extended termination procedure; added object encryption/signing requirement and special case; clarified expired MAC publishing; added Flexible Offline Message Retrieval to Open Issues. (ip)

Version 0.5 (2004-08-10)

Added flexibility requirement; added late signature of initial request; added termination MAC. (ip)

Version 0.4 (2004-08-09)

Added (offline) replay protection; required offline Created header; compression is NOT RECOMMENDED; added second set of offline options for subscribers; added JIDs to session key generation; unencrypted sessions; added secure option; sign whole data form; HMAC whole <encrypted/> element; added Esession termination; option to distribute public keys within session initiation; added Integrity requirement; several clarifications (ip)

Version 0.3 (2005-08-02)

Restored status to Experimental; complete rewrite; new Introduction, Background, Requirements and Security Considerations; new OTR-inspired protocol; JEP-0155-based negotiation; counter mode encryption; more secure hashes; offline sessions; re-keying; mac publishing; preliminary key and options publishing protocol. (ip/psa)

Version 0.2 (2004-07-26)

At the request of the JEP author, changed status to Retracted. (psa)

Version 0.1 (2003-09-09)

Initial version. (dss/psa)

END