XEP-0116: Encrypted Sessions

This document specifies an XMPP protocol extension for session-based, end-to-end encryption.


WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol 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.


XEP Information

Status: Experimental
Type: Standards Track
Number: 0116
Version: 0.12
Last Updated: 2006-10-05
Publishing Organization: Jabber Software Foundation
Approving Body: XMPP Council
Dependencies: XMPP Core, RFC 2104, RFC 2409, RFC 3526, RFC 3548, xml-c14n, XEP-0004, XEP-0020, XEP-0030, XEP-0068, XEP-0155
Supersedes: None
Superseded By: None
Short Name: esession
Wiki Page: <http://wiki.jabber.org/index.php/Encrypted Sessions (XEP-0116)>

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 XMPP Extension Protocol is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.xmpp.org/extensions/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

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 XMPP Extension Protocol 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 document 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 following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


Table of Contents

1. Introduction
2. Dramatis Personae
3. Discovering Support
4. Online ESession Negotiation
4.1. ESession Request
4.2. Diffie-Hellman Preparation (Bob)
4.3. Generating Session Keys
4.4. Hiding Identity
4.5. ESession Response
4.6. Diffie-Hellman Preparation (Alice)
4.7. Verifying Bob's Identity
4.8. ESession Completion
5. Exchanging Stanzas
5.1. Encryptable Content
5.2. Encryption
5.3. Sending an Encrypted Stanza
5.4. Decryption
6. Re-Key Exchange
6.1. Re-Key Initiation
6.2. Re-Key Acceptance
6.3. Publishing Old MAC Values
7. ESession Termination
8. Signature Generation and Verification
8.1. XML Normalization
8.2. Hash
8.3. Generation
8.3.1. RSA
8.3.2. DSA
8.4. Signature Format
8.4.1. RSA
8.4.2. DSA
8.5. Verification
8.5.1. RSA
8.5.2. DSA
9. Security Considerations
9.1. Random Numbers
9.2. Re-Keying Limits
9.3. Verifying Keys
9.4. Replay Attacks
9.5. Unencrypted ESessions
9.6. Storage
9.7. Extra Responsabilities of Implementors
9.8. Mandatory to Implement Technologies
9.8.1. Block Cipher Algorithms
9.8.2. Key Signing Algorithms
9.8.3. Public Signature-Verification-Key Formats
9.8.4. Hash Algorithms
9.8.5. Compression Algorithms
10. IANA Considerations
11. XMPP Registrar Considerations
11.1. Namespaces
11.2. Field Standardization
12. XML Schemas
13. Open Issues
13.1. To Think About
13.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 in Cryptographic Design of Encrypted Sessions [5], 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 requirements and the consequent cryptographic design that underpin this protocol are described in Cryptographic Design of Encrypted Sessions. 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 each one-to-one XML stanza exchanged between the endpoints will be encrypted and then transmitted within a "wrapper" stanza.

2. Dramatis Personae

This document 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 document, 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 document, his fully-qualified JID is: <bob@example.com/laptop>.
  3. "Aunt Tillie" the archetypal typical user (i.e. non-technical, with only very limited knowledge of how to use a computer, and averse to performing any procedures that are not familiar).

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.

3. Discovering Support

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

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 XEP-0115), Alice SHOULD then send a service discovery information ("disco#info") request to each of those contacts (in accordance with XEP-0030). Such initial service discovery stanzas MUST NOT be considered part of encrypted communication sessions for the purposes of this document, 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>
  

4. Online ESession Negotiation

The process for establishing a secure session over an insecure transport is essentially a negotiation of various ESession algorithms and other parameters, combined with a translation into XMPP syntax of the SIGMA [8] approach to key exchange (see Cryptographic Design of Encrypted Sessions).

If Alice believes Bob may be online then she SHOULD use the protocol specified in Chat Session Negotiation [9] and in this section to negotiate the ESession options and the keys.

Note: If Alice believes Bob is offline then she SHOULD NOT use this negotiation protocol. However, she MAY use the protocol specified in Offline Encrypted Sessions to establish the ESession options and keys. Alternatively, she MAY send stanzas without encryption - in which case her client MUST make absolutely clear to her that the stanzas will not be protected and give her the option not to send the stanzas.

Note: In any case, Alice MUST NOT initiate a new ESession with Bob if she already has one established with him.

4.1 ESession Request

In addition to the "accept", "otr" and "security" fields specified in Chat Session Negotiation, Alice MUST send to Bob each of the ESession options (see list below) that she is willing to use, in her order of preference (see Mandatory to Implement Technologies). Note: Alice SHOULD NOT include a "reason" field since Aunt Tillie may not be aware the ESession request is not encrypted.

  1. The list of Modular Exponential (MODP) group numbers (as specified in RFC 2409 [10] or RFC 3526 [11]) that MAY be used for Diffie-Hellman key exchange (valid group numbers include 1,2,3,4,5,14,15,16,17 and 18)

  2. Symmetric block cipher algorithm names

  3. Hash algorithm names

  4. Signature algorithm names

  5. Compression algorithm names

  6. The list of stanza types that MAY be encrypted and decrypted

  7. Whether or not the other entity MUST send the fingerprint of its public signature-verification key instead of the full key [12]

  8. The different versions of this protocol that are supported [13]

  9. 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). Note: This value MUST be less than 232 (see Re-Keying Limits)

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). For each MODP group that Alice specifies she MUST perform the following computations to calculate her Diffie-Hellman keys (where n is the number of bits per cipher block for the block cipher algorithm with the largest block size out of those she specified):

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

  2. Calculate e = gx mod p

Alice MUST send all her calculated values of e to Bob (in the same order as the associated MODP groups are being sent). She MUST also specify randomly generated Base64 encoded (in accordance with Section 3 of RFC 3548 [14]) value of NA (her ESession ID).

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="accept">
        <value>1</value>
      </field>
      <field type="list-single" var="otr">
        <option><value>false</value></option>
        <option><value>true</value></option>
      </field>
      <field type="list-single" var="security">
        <option><value>e2e</value></option>
        <option><value>c2s</value></option>
      </field>
      <field type="list-single" var="modp">
        <option><value>5</value></option>
        <option><value>14</value></option>
        <option><value>2</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="sign_algs">
        <option><value>rsa</value></option>
        <option><value>dsa</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="pk_hash">
        <value>0</value>
      </field>
      <field type="list-single" var="ver">
        <option><value>1.3</value></option>
        <option><value>1.2</value></option>
      </field>
      <field type="text-single" var="rekey_freq">
        <value>1</value>
      </field>
      <field var="my_nonce">
        <value> ** Base64 encoded ESession ID ** </value>
      </field>
      <field var="keys">
        <value> ** Base64 encoded value of e5 ** </value>
        <value> ** Base64 encoded value of e14 ** </value>
        <value> ** Base64 encoded value of e2 ** </value>
      </field>
    </x>
  </feature>
  <amp xmlns='http://jabber.org/protocol/amp' per-hop='true'>
    <rule action='drop' condition='deliver' value='stored'/>
  </amp>
</message>
      

If Bob does not want to reveal presence to Alice for whatever reason then Bob SHOULD return no response or error.

If Bob supports none of the options for one or more ESession fields, then he SHOULD return a <not-acceptable/> error and SHOULD specify the field(s) with unsupported options in a comma-separated list in the XMPP <text/> element:

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 type='cancel'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>modp,ver</text>
  </error>
</message>
      

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

If Bob is unwilling to start an ESession, but he is ready to initiate a one-to-one chat session with Alice (see Chat Session Negotiation), and if Alice included an option for the "security" field with the value "none" or "c2s", then Bob SHOULD accept the Chat Session and terminate the ESession negotiation by specifying "none" or "c2s" for the value of the "security" field in his response.

Example 5. Bob Accepts Chat Session

<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="accept"><value>1</value></field>
      <field var="otr"><value>true</value></field>
      <field var="security"><value>c2s</value></field>
    </x>
  </feature>
</message>
      

4.2 Diffie-Hellman Preparation (Bob)

If Bob supports one or more of each of Alice's ESession options and is willing to start an ESession with Alice, then he MUST select one of the options from each of the ESession fields he received from Alice including one hash algorithm ("HASH"), and one of the MODP groups and Alice's corresponding value of e (see RFC 3766 [15] 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 SHOULD return a <feature-not-implemented/> error unless: 1 < e < p - 1

Bob MUST then perform the following computations (where n is the number of bits per cipher block for the selected block cipher algorithm):

  1. Generate a random number NB (his ESession ID)

  2. Generate an n-bit random number CA (the block cipher counter for stanzas sent from Alice to Bob)

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

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

  5. Calculate d = gy mod p

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

4.3 Generating Session Keys

Bob MUST use the shared secret ("K") and the selected hash algorithm ("HASH") to generate two sets of three keys, one set for each direction of the ESession.

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

  1. Encryption key KCA = HASH(K, 0)

  2. Integrity key KMA = HASH(K, 2)

  3. SIGMA key KSA = HASH(K, 4)

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

  1. Encryption key KCB = HASH(K, 1)

  2. Integrity key KMB = HASH(K, 3)

  3. SIGMA key KSB = HASH(K, 5)

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

Note: As many bits of key data as are needed for each key MUST be taken from the least significant bits 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.

4.4 Hiding Identity

Bob MUST perform the following steps before he can prove his identity to Alice while protecting it from third parties.

  1. Select pubKeyB, the public key Alice should use to authenticate his signature with the signature algorithm he selected ("SIGN").

  2. Set formB to the Normalized content of the reponse data form he will send back to Alice (including his responses for all the fields he received from Alice).

    Bob MUST encapsulate the Base64 encoded values of CA and Alice's NA in two new 'counter' and 'nonce' fields and add them to formB. Note: The 'pk_hash' field specifies whether or not Alice MUST send the fingerprint of her public signature-verification key instead of her full key. Note: The value of the 'rekey_freq' field MUST be less than 232 and greater than or equal to the value specified by Alice. Note: Bob MUST place his Base64 encoded values of NB and d in the 'my_nonce' and 'keys' fields. Bob MUST NOT return Alice's values of e.

  3. Concatenate Alice's ESession ID, Bob's ESession ID, d, pubKeyB and formB, and calculate the HMAC (as defined in Section 2 of RFC 2104 [16]) of the resulting byte string using the selected hash algorithm ("HASH") and the key KSB.

    macB = HMAC(HASH, KSB, {NA, NB, d, pubKeyB, formB})
  4. Calculate signB, the signature of the HMAC result using his private signature key that corresponds to pubKeyB

    signB = SIGN(signKeyB, macB)
  5. If the value of the 'pk_hash' field that Alice sent Bob was true then Bob SHOULD set pubKeyB to the key's fingerprint

    if (pk_hash) pubKeyB = HASH(pubKeyB)
  6. Concatenate pubKeyB and signB and encrypt the resulting byte string with the agreed algorithm ("CIPHER") in counter mode (see Recommendation for Block Cipher Modes of Operation [17]), using the encryption key KCB and block counter CB. Note: CB MUST be incremented by 1 for each encrypted block or partial block (i.e. CB = (CB + 1) mod 2n, where n is the number of bits per cipher block for the agreed block cipher algorithm).

    IDB = CIPHER(KCB, CB, {pubKeyB, signB})
  7. Calculate the HMAC of the encrypted identity (IDB) and the value of Bob's block cipher counter CB before the encryption above using the selected hash algorithm ("HASH") and the integrity key KMB.

    MB = HMAC(HASH, KMB, CB, IDB)

4.5 ESession Response

Bob responds to Alice by sending her formB.

Example 6. Bob Responds to Alice (4-Message Negotiation)

<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="accept"><value>1</value></field>
      <field var="otr"><value>true</value></field>
      <field var="security"><value>e2e</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="sign_algs"><value>rsa</value></field>
      <field var="compress"><value>none</value></field>
      <field var="stanzas"><value>message</value></field>
      <field var="pk_hash"><value>1</value></field>
      <field var="ver"><value>1.3</value></field>
      <field var="rekey_freq"><value>50</value></field>
      <field var="my_nonce">
        <value> ** Base64 encoded ESession ID ** </value>
      </field>
      <field var="keys">
        <value> ** Base64 encoded value of d ** </value>
      </field>
      <field var="nonce">
        <value> ** Base64 encoded ESession ID ** </value>
      </field>
      <field var="counter">
        <value> ** Base64 encoded block counter ** </value>
      </field>
    </x>
  </feature>
</message>
    

If Bob prefers the RECOMMENDED 3-message ESession negotiation, where Alice's identity is protected from active attacks instead of his own, then he should encapsulate the Base64 encoded values of IDB and MB in data form fields ('identity' and 'mac'), and append the new fields to formB before sending it to Alice.

Example 7. Bob Responds to Alice (3-Message Negotiation)

<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="accept"><value>1</value></field>
      <field var="otr"><value>true</value></field>
      <field var="security"><value>e2e</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="sign_algs"><value>rsa</value></field>
      <field var="compress"><value>none</value></field>
      <field var="stanzas"><value>message</value></field>
      <field var="pk_hash"><value>1</value></field>
      <field var="ver"><value>1.3</value></field>
      <field var="rekey_freq"><value>50</value></field>
      <field var="my_nonce">
        <value> ** Base64 encoded ESession ID ** </value>
      </field>
      <field var="keys">
        <value> ** Base64 encoded value of d ** </value>
      </field>
      <field var="nonce">
        <value> ** Base64 encoded ESession ID ** </value>
      </field>
      <field var="counter">
        <value> ** Base64 encoded block counter ** </value>
      </field>
      <field var="identity">
        <value> ** Encrypted identity ** </value>
      </field>
      <field var="mac">
        <value> ** Integrity of identity ** </value>
      </field>
    </x>
  </feature>
</message>
    

4.6 Diffie-Hellman Preparation (Alice)

After Alice receives Bob's response, she MUST use the value of d and the ESession options specified in Bob's response to perform the following steps (where p and g are the constants associated with the selected MODP group, HASH is the selected hash algorithm, and n is the number of bits per cipher block for the agreed block cipher algorithm):

  1. Return a <feature-not-implemented/> error to Bob if she is not prepared to support any of the ESession options specified by Bob (if any of the options were not included in her initial ESession request)

  2. Return a <feature-not-implemented/> error to Bob unless: 1 < d < p - 1

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

  4. Select her values of x and e that correspond to the selected MODP group (from all the values of x and e she calculated previously)

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

  6. Generate the session keys (KCA, KMA, KSA, KCB, KMB and KSB) in the same way as Bob did (see Generating Session Keys)

4.7 Verifying Bob's Identity

If Bob included 'identity' and 'mac' fields in his response then Alice MUST also perform the following steps:

  1. Calculate the HMAC of the encrypted identity (IDB) and the value of Bob's block cipher counter using HASH and the integrity key KMB.

    MB = HMAC(HASH, KMB, CB, IDB)
  2. Return a <feature-not-implemented/> error to Bob unless the value of MB she calculated matches the one she received in the 'mac' field

  3. Obtain pubKeyB and signB by decrypting IDB with the agreed symmetric block cipher algorithm ("DECIPHER") in counter mode, using the encryption key KCB and block counter CB. Note: CB MUST be incremented by 1 for each encrypted block or partial block (i.e. CB = (CB + 1) mod 2n, where n is the number of bits per cipher block for the agreed block cipher algorithm).

    {pubKeyB, signB} = DECIPHER(KCB, CB, IDB)
  4. If the value of the 'pk_hash' field she sent to Bob in her ESession Request was true, then Alice SHOULD change the value of pubKeyB to be her copy of the public key whose HASH matches the value of pubKeyB that she received from Bob. Note: If she cannot find a copy of the public key then Alice MUST terminate the ESession. She MAY then request a new ESession with the 'pk_hash' field set to false.

  5. Return a <feature-not-implemented/> error to Bob unless she can confirm (or has previously confirmed) that pubKeyB really is Bob's public key, for examples, via secure out-of-band communication, or through a third-party authority (see Verifying Keys).

  6. Set the value of formB to be the Normalized content of the form she received from Bob without any 'identity' or 'mac' fields.

  7. Concatenate Alice's ESession ID, Bob's ESession ID, d, pubKeyB and formB, and calculate the HMAC of the resulting byte string using HASH and the key KSB.

    macB = HMAC(HASH, KSB, {NA, NB, d, pubKeyB, formB})
  8. Return a <feature-not-implemented/> error to Bob unless she can use pubKeyB with the selected signature verification algorithm ("VERIFY") to confirm that signB is the signature of the HMAC result (see Signature Verification).

    VERIFY(signB, pubKeyB, macB)

4.8 ESession Completion

Alice MUST then prove her identity to Bob while protecting it from third parties. She MUST perform the steps equivalent to those Bob performed above (see Hiding Identity for a more detailed description). Alice's calculations are summarised below (pay attention to the order of NB and NA when calculating macA). Note: formA is the Normalized content of the ESession Request data form that she sent to Bob previously.

macA = HMAC(HASH, KSA, {NB, NA, e, pubKeyA, formA})

signA = SIGN(signKeyA, macA)

if (pk_hash) pubKeyA = HASH(pubKeyA)

IDA = CIPHER(KCA, CA, {pubKeyA, signA})

MA = HMAC(HASH, KMA, CA, IDA)

Alice MUST send the Base64 encoded values of NB, IDA and MA to Bob. If Alice has already confirmed Bob's identity (i.e. if Bob included 'identity' and 'mac' fields in his response), then she MAY also send encrypted content (see Exchanging Stanzas) in the same stanza as the proof of her identity.

Example 8. Alice Sends Bob Her Identity

<message from='alice@example.org/pda' to='bob@example.com/laptop'>
  <feature xmlns='http://jabber.org/protocol/feature-neg'>
    <x type='result' xmlns='jabber:x:data'>
      <field var="FORM_TYPE"><value>http://jabber.org/protocol/chatneg</value></field>
      <field var="nonce"><value> ** Base64 encoded ESession ID ** </value></field>
      <field var="identity"><value> ** Encrypted identity ** </value></field>
      <field var="mac"><value> ** Integrity of identity ** </value></field>
    </x>
  </feature>
  <encrypted xmlns='http://jabber.org/protocol/esession'>
    <data> ** Base64 encoded m_final ** </data>
    <mac> ** Base64 encoded a_mac ** </mac>
  </encrypted>
</message>
      

If Alice also includes a 'terminate' field with its value set to "1" or "true" (see ESession Termination) within the form then the ESession is terminated immediately. Note: 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) and offers several significant advantages over non-session approaches - including perfect forward secrecy.

After receiving Alice's identity Bob MUST verify it by performing steps equivalent to those described in the section Verifying Bob's Identity above. Some of Bob's calculations are summarised below (pay attention to the order of NB and NA when calculating macA). Note: formA is the Normalized content of the ESession Request data form (the first form) that Alice sent him. Note: If Bob sends an error to Alice then he SHOULD ignore any encrypted content he received in the stanza.

MA = HMAC(HASH, KMA, CA, IDA)

{pubKeyA, signA} = DECIPHER(KCA, CA, IDA)

macA = HMAC(HASH, KSA, {NB, NA, e, pubKeyA, formA})

VERIFY(signA, pubKeyA, macA)

If Alice has already confirmed Bob's identity (i.e. if Bob included 'identity' and 'mac' fields in his response above), then the ESession negotiation is complete.

Otherwise, one more step is necessary. Bob MUST send Alice the Base64 encoded values of NA, IDB and MB that he calculated previously (see Hiding Identity). Note: He MAY also send encrypted content (see Exchanging Stanzas) in the same stanza.

Example 9. Bob Sends Alice His Identity

<message from='bob@example.com/laptop' to='alice@example.org/pda'>
  <init xmlns='http://jabber.org/protocol/esession#init'>
    <x type='result' xmlns='jabber:x:data'>
      <field var="FORM_TYPE"><value>http://jabber.org/protocol/chatneg</value></field>
      <field var="nonce"><value> ** Base64 encoded ESession ID ** </value></field>
      <field var="identity"><value> ** Encrypted identity ** </value></field>
      <field var="mac"><value> ** Integrity of identity ** </value></field>
    </x>
  </init>
</message>
      

After receiving Bob's identity Alice MUST verify it by performing steps described in the section Verifying Bob's Identity above. Note: If Alice sends an error to Bob then she SHOULD ignore any encrypted content she received in the stanza.

5. Exchanging Stanzas

5.1 Encryptable Content

Once ESession negotiation is complete, Alice and Bob MUST exchange only encrypted forms of the one-to-one stanza types they agreed upon (e.g., <message/> and <iq/> stanzas).

Either Alice or Bob MAY send encrypted stanzas. Here we describe the process where Alice sends 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.

Example 10. Unencrypted Stanza

<message from='alice@example.org/pda'
         to='bob@example.com/laptop'
         type='chat'>
  <body>Hello, Bob!</body>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule action='error' condition='match-resource' value='exact'/>
  </amp>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>

Example 11. XML Content to be Encrypted

<body>Hello, Bob!</body>
<active xmlns='http://jabber.org/protocol/chatstates'/>

5.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 stanza), then CA MUST be incremented by 1 (see below), and only the last two steps (normalization and MAC calculation) should be performed.

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

  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. [19]

    m_compressed = compress(m)
  3. Encrypt the data with the agreed algorithm in counter mode, using the encryption key KCA. Note: CA MUST be incremented by 1 for each encrypted block or partial block (i.e. CA = (CA + 1) mod 2n, where n is the number of bits per cipher block for the agreed block cipher algorithm). Note: if the block cipher algorithm 'none' was agreed (see Unencrypted ESessions) then encryption MUST NOT be performed and CA MUST be incremented by 1 (for replay protection).

    m_final = encrypt(KCA, CA, m_compressed)
  4. Alice MUST now create the Normalized XML content of the <encrypted/> XML element. If there is encrypted XML content, the XML MUST include the Base64 encoded value of m_final wrapped in a <data/> element. Note: the <encrypted/> element MAY also contain one <key/> element and one or more <old/> elements (see Re-Keying).

    m_content = '<data> ** Base64 encoded m_final ** </data>'
  5. The XML content and the value of Alice's block cipher counter CA before the data was encrypted, are now processed through the HMAC algorithm, along with the agreed hash algorithm ("HASH") and the integrity key KMA.

    a_mac = HMAC(HASH, KMA, m_content, CA)

5.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 12. 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'>
    <data> ** Base64 encoded m_final ** </data>
    <mac> ** Base64 encoded a_mac ** </mac>
  </encrypted>
  <amp xmlns='http://jabber.org/protocol/amp' per-hop='true'>
    <rule action='error' condition='match-resource' value='exact'/>
  </amp>
</message>
    

5.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.

  1. Remove the <mac/> element from the <encrypted/> element and Normalize the remaining XML content. Calculate the Message Authentication Code (MAC) for the content.

    b_mac = HMAC(HASH, KMA, 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, he MAY send a <not-acceptable/> error to Alice. [20]

  3. Decrypt m_final using the agreed algorithm, KCA and CA. Note: CA MUST be incremented by 1 for each decrypted block (see Encryption). Note: if the block cipher algorithm 'none' was agreed decryption MUST NOT be performed and CA MUST be incremented by 1.

    m_compressed = decrypt(KCA, 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, he MAY send a <not-acceptable/> error to Alice. [21]

6. 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 negotiation 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.

6.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 cipher block for the agreed block cipher algorithm)

  2. Calculate e = gx mod p

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

  4. Calculate KCA, KMA, KCB, KMB from K (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 KCA and KMA 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 13. Alice Sends Re-Key Stanza

<message from='alice@example.org/pda' to='bob@example.com/laptop'>
  <encrypted xmlns='http://jabber.org/protocol/esession'>
    <data> ** Base64 encoded m_final ** </data>
    <key> ** 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 KCB and KMB, 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).

6.2 Re-Key Acceptance

After Bob has received a stanza with a new value of e, has confirmed it is greater than one, and has decrypted the stanza with the old value of KCA, he MUST securely destroy all copies of KCA and KCB and perform the following calculations with the new value of e:

  1. Calculate K = ey mod p

  2. Calculate KCA, KMA, KCB, KMB from K (see Generating Session Keys)

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

The next time Bob sends Alice a stanza he MUST specify the number of rekeys he has received from her since he sent her his last stanza. He does that by setting the 'rekeys' attribute of the <data/> element. Note: The default value of the 'rekeys' attribute is zero.

Example 14. Bob's First Stanza After Receiving a Re-Key

<message from='bob@example.com/laptop' to='alice@example.org/pda'>
  <encrypted xmlns='http://jabber.org/protocol/esession'>
    <data rekeys='1'> ** Base64 encoded m_final ** </data>
    <mac> ** Base64 encoded b_mac ** </mac>
  </encrypted>
</message>
    

When Alice receives the stanza from Bob she MUST use the 'rekeys' attribute to decide which of her values of KCB and KMB (or x) she should use to decrypt the stanza - otherwise she would not know if Bob received her rekey(s) before he sent the stanza. Once she is sure Bob has received her rekey(s) she MUST discard all her older values of KCB, KMB and x.

6.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 KMA and/or KMB 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 KMA (and KMB), 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 KMB after she has received a re-key from Bob.)

Example 15. Publishing Expired MAC Keys

<message from='alice@example.org/pda' to='bob@example.com/laptop'>
  <encrypted xmlns='http://jabber.org/protocol/esession'>
    <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.

7. ESession Termination

Either entity MAY terminate an ESession at any time. Entities MUST terminate all open ESessions before they go offline. To terminate an ESession Alice MUST send an encrypted stanza to Bob including within the encrypted XML of the <data/> element a chat negotiation form with a "terminate" field (as specified in the Termination section of Chat Session Negotiation). Note: She MAY publish old values of KMA and/or KMB 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 16. Alice Terminates an ESession

<message from='alice@example.org/pda' to='bob@example.com/laptop'>
  <encrypted xmlns='http://jabber.org/protocol/esession'>
    <data> ** Base64 encoded encrypted terminate form ** </data>
    <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 immediately send an encrypted termination acknowledgement form (as specified in the Termination section of Chat Session Negotiation) back to Alice. Note: He MAY publish any old values of KMA or KMB within the acknowledgement stanza. He MUST then securely destroy all keys associated with the ESession.

Example 17. Bob Acknowledges ESession Termination

<message from='bob@example.com/laptop' to='alice@example.org/pda'>
  <encrypted xmlns='http://jabber.org/protocol/esession'>
    <data> ** Base64 encoded encrypted acknowledgement form ** </data>
    <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 or termination acknowledgement stanza it MUST NOT send another stanza within the ESession.

8. Signature Generation and Verification

8.1 XML Normalization

Before the signature or MAC of a block of XML is generated or verified, all character data between all elements MUST be removed and the XML MUST be converted to canonical form (see Canonical XML [23]).

All the XML this protocol requires to be signed or MACed is very simple, so in this case, canonicalization SHOULD only require the following changes:

Implementations MAY conceivably also need to make the following changes. Note: Empty elements and special characters SHOULD NOT appear in the signed or MACed XML specified in this protocol.

8.2 Hash

Before the signature or MAC of a block of XML is generated or verified, the agreed hash algorithm MUST be used to generate the hash of the normalized XML.

m_hash = HASH(m_content)

8.3 Generation

The signature generation depends on the type of private key being used.

8.3.1 RSA

signature_rsa = rsa_sign(rsa_private_key, m_hash, hashOID)

The multiprecision integer signature_rsa is the signature (see RFC 3447 [24]).

8.3.2 DSA

sig_dsa_r, sig_dsa_s = dsa_sign(dsa_private_key, m_hash)

The multiprecision integers sig_dsa_r and sig_dsa_s are the signature (see Digital Signature Standard [25]).

8.4 Signature Format

The signature formats are the same for all public key formats. All integers are stored in big-endian byte order.

8.4.1 RSA

Base64 encoding of the signature_rsa multiprecision integer (without any header or length prefix).

8.4.2 DSA

Base64 encoding of the following structure:

8.5 Verification

The signature verification depends on the type of public key being used.

8.5.1 RSA

The rsa_modulus and rsa_public_exponent multiprecision integers are extracted from the other entity's authenticated public key. The signature_rsa multiprecision integer is the signature received from the other entity.

boolean = rsa_verify(signature_rsa, m_hash, hashOID, rsa_modulus, rsa_public_exponent)

8.5.2 DSA

The dsa_p, dsa_q, dsa_g and dsa_y multiprecision integers are extracted from the other entity's authenticated public key. The sig_dsa_r and sig_dsa_s multiprecision integers are the signature received from the other entity.

boolean = dsa_verify(sig_dsa_r, sig_dsa_s, m_hash, dsa_p, dsa_q, dsa_g, dsa_y)

9. Security Considerations

9.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 [26]).

9.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 RFC 4344 [27]). 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.

9.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.

9.4 Replay Attacks

The block cipher 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.

9.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. Unencrypted ESessions enable Alice to to confirm securely with Bob that both client-server connections are secure. i.e. that the value of the 'security' option (as specified in Chat Session Negotiation) has not been tampered with.

9.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 'otr' Chat Session Negotiation field is 'true' the entities SHOULD NOT store any part of the ESession content (not even in encrypted form).

9.7 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.

9.8 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 block cipher algorithm details; see the IANA Secure Shell Protocol Parameters Registry [28] for other names.

9.8.1 Block Cipher Algorithms

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

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

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

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

9.8.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):

9.8.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 document 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 algorithms to compress content before it is encrypted:

10. IANA Considerations

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

11. XMPP Registrar Considerations

11.1 Namespaces

Upon approval of this document, the XMPP Registrar [38] shall register the following namespaces:

11.2 Field Standardization

Field Standardization for Data Forms [39] defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. The following fields shall be registered for use in both Encrypted Sessions and Chat Session Negotiation:

Registry Submission

<form_type>
  <name>http://jabber.org/protocol/esession</name>
  <jep>XEP-0116</jep>
  <desc>ESession negotiation forms</desc>
  <field
      var='compress'
      type='list-single'
      label='Compression algorithm options'/>
  <field
      var='counter'
      type='hidden'
      label='Initial block counter'/>
  <field
      var='crypt_algs'
      type='list-single'
      label='Symmetric block cipher options'/>
  <field
      var='expires'
      type='hidden'
      label='Expiry time of offline ESession options'/>
  <field
      var='hash_algs'
      type='list-single'
      label='Hash algorithm options'/>
  <field
      var='keys'
      type='hidden'
      label='Diffie-Hellman keys'/>
  <field
      var='match_resource'
      type='text-single'
      label='Target resource for offline ESessions'/>
  <field
      var='modp'
      type='list-single'
      label='MODP group number'/>
  <field
      var='my_nonce'
      type='hidden'
      label='ESession ID of Sender'/>
  <field
      var='nonce'
      type='hidden'
      label='ESession ID of Receiver'/>
  <field
      var='pk_hash'
      type='boolean'
      label='Respond with public key fingerprint'/>
  <field
      var='rekey_freq'
      type='text-single'
      label='Minimum number of stanzas between key exchanges'/>
  <field
      var='sign_algs'
      type='list-single'
      label='Signature algorithm options'/>
  <field
      var='signs'
      type='list-single'
      label='Data form signatures'/>
  <field
      var='stanzas'
      type='list-multi'
      label='Stanzas types to encrypt'/>
  <field
      var='ver'
      type='list-single'
      label='Supported versions of XEP-0116'/>
</form_type>

<form_type>
  <name>http://jabber.org/protocol/chatneg</name>
  <jep>XEP-0155</jep>
  ...
</form_type>
    

12. XML Schemas

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/esession'
    xmlns='http://jabber.org/protocol/esession'
    elementFormDefault='qualified'>

  <xs:element name='data'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='xs:string'>
          <xs:attribute name='rekeys' type='xs:nonNegativeInteger' use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='encrypted'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='data' minOccurs='0' maxOccurs='1'/>
        <xs:element ref='key' minOccurs='0' maxOccurs='1'/>
        <xs:element ref='mac' minOccurs='0' maxOccurs='1'/>
        <xs:element ref='old' minOccurs='0' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='key' type='xs:string'/>

  <xs:element name='mac' type='xs:string'/>

  <xs:element name='old' type='xs:string'/>

</xs:schema>
  

13. Open Issues

13.1 To Think About

  1. Standardise on the X.509 public key and signature formats?
  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 use Flexible Offline Message Retrieval [40] (FOMR) instead of AMP to prevent any offline ESessions Bob can't decrypt being delivered to him. (Each <item/> that corresponds to an ESession message would have to contain a <ESessionID/> child, to allow Bob to discover which of his stored values of y was used to encrypt the message.)

13.2 To Do

  1. Ask the authors of AMP to explain how to achieve the match_resource functionality specified in XEP-0187.
  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 negotiation.
  3. Add non-repudiable signing option
  4. Perhaps the document needs to specify more carefully how block counters are handled between messages, especially in the event of partial blocks?
  5. 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?).
  6. Define an optional protocol that would allow Alice to store values of NA and x (and the PKIDs she trusts) 'securely' on her own server (before she goes offline).


Notes

1. XEP-0027: Current Jabber OpenPGP Usage <http://www.xmpp.org/extensions/xep-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. XEP-0188: Cryptographic Design of Encrypted Sessions <http://www.xmpp.org/extensions/xep-0188.html>.

6. XEP-0030: Service Discovery <http://www.xmpp.org/extensions/xep-0030.html>.

7. XEP-0115: Entity Capabilities <http://www.xmpp.org/extensions/xep-0115.html>.

8. SIGMA: the 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols (Hugo Krawczyk, June 12 2003) <http://www.ee.technion.ac.il/~hugo/sigma.ps>.

9. XEP-0155: Chat Session Negotiation <http://www.xmpp.org/extensions/xep-0155.html>.

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

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

12. If the entity already possesses one of the other entity's public keys then it is RECOMMENDED that only the fingerprint is requested from the other entity - since this saves bandwidth.

13. This version of this document describes version 1.0 of this protocol.

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

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

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

17. Recommendation for Block Cipher Modes of Operation: Federal Information Processing Standards Publication 800-38a <http://csrc.nist.gov/publications/ nistpubs/800-38a/sp800-38a.pdf>.

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

19. 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.

20. 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.

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

22. 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.

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

24. RFC 3447: Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 <http://www.ietf.org/rfc/rfc3447.txt>.

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

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

27. RFC 4344: SSH Transport Layer Encryption Modes <http://www.ietf.org/rfc/rfc4344.txt>.

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

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

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

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

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

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

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

35. Standard ECMA-151: Data Compression for Information Interchange - Adaptive Coding with Embedded Dictionary - DLCZ Algorithm <http://www.ecma-international.org/publications/standards/Ecma-151.htm>.

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

37. 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/>.

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

39. XEP-0068: Field Data Standardization for Data Forms <http://www.xmpp.org/extensions/xep-0068.html>.

40. XEP-0013: Flexible Offline Message Retrieval <http://www.xmpp.org/extensions/xep-0013.html>.


Revision History

Version 0.12 (2006-10-05)

Replaced secure field with security field; changed otr field to list-single

(ip)

Version 0.11 (2006-10-02)

Harmonised session termination with the protocol added to XEP-0155; added XML schema; minor clarifications

(ip)

Version 0.10 (2006-07-18)

Added Upgradability requirement; added expires field to offline options; updated in line with latest version of PEP; moved some content to new XEPs (0187, 0188 and 0189)

(ip)

Version 0.9 (2005-11-29)

Modified protocol in line with SIGMA: added Identity Protection requirement, no pre-indication of acceptable keys, send multiple values of e with ESession request, offline options published via SPPS, added LZW compression

(ip)

Version 0.8 (2005-09-27)

Added diagramatic synopses; Added match_resource field; replaced req_mac and kid fields with prev_hash; Alice specifies initial counter (doubles as nonce); many other improvements

(ip)

Version 0.7 (2005-08-26)

Simplified XML normalization; added Synopsis and Efficiency requirement; defined signature formats

(ip)

Version 0.6 (2005-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 (2005-08-10)

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

(ip)

Version 0.4 (2005-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 negotiation; 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; XEP-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 author, changed status to Retracted.

(psa)

Version 0.1 (2003-09-09)

Initial version.

(dss/psa)


END