XEP-0188: Cryptographic Design of Encrypted Sessions

This document describes the requirements and cryptographic design that underpin the XMPP protocol extensions Encrypted Sessions and Offline Encrypted Sessions.


WARNING: This Informational document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the best practice or protocol profile described herein is encouraged in exploratory implementations, although production systems should not deploy implementations of this protocol until it advances to a status of Draft.


XEP Information

Status: Experimental
Type: Informational
Number: 0188
Version: 0.2
Last Updated: 2006-07-19
Publishing Organization: Jabber Software Foundation
Approving Body: XMPP Council
Dependencies: XMPP Core, RFC 2104
Supersedes: None
Superseded By: None
Short Name: cryptoesession
Wiki Page: <http://wiki.jabber.org/index.php/Cryptographic Design of Encrypted Sessions (XEP-0188)>

Author Information

Ian Paterson

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

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. Scope
3. The Session Approach
4. Dramatis Personae
5. Requirements
5.1. Security Requirements
5.1.1. Confidentiality
5.1.2. Integrity
5.1.3. Replay Protection
5.1.4. Perfect Forward Secrecy
5.1.5. Authentication
5.1.6. Identity Protection
5.1.7. Repudiability
5.1.8. Upgradability
5.2. Application Requirements
5.2.1. Generality
5.2.2. Implementability
5.2.3. Usability
5.2.4. Efficiency
5.2.5. Flexibility
5.2.6. Interoperability
5.2.7. Offline Sessions
5.2.8. Object Encryption
6. Cryptographic Origins - SIGMA
6.1. Introduction
6.2. SIGMA Parameter Descriptions
6.3. SIGMA-I Overview
6.4. SIGMA-R Overview
6.5. SIGMA-I Key Exchange
6.6. SIGMA-R Key Exchange
7. Cryptographic Design
7.1. ESession Parameter Descriptions
7.2. Online ESession-I Negotiation
7.3. Online ESession-R Negotiation
7.4. Offline ESession Negotiation
8. Security Considerations
9. IANA Considerations
10. XMPP Registrar Considerations
11. Acknowledgments
Notes
Revision History


1. Introduction

Note: The protocols developed according to the requirements and cryptographic design described in this document are described in Encrypted Sessions [1] and Offline Encrypted Sessions [2]. The information in those documents should be sufficient for implementors. This purely informative document is primarily for people interested in the design and analysis of those protocols.

As specified in RFC 3920 [3], 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 [4]. 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.

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 may be secured via channel encryption using Transport Level Security (RFC 2246 [5]), 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 servers are trustworthy), which makes end-to-end encryption desirable.

The encrypted stanzas should be understood by an intermediate server only to the extent required to route them. (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 [6] extensions.)

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

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:

2. Scope

Ideally, any technology for end-to-end encryption in XMPP could be extended to cover all the scenarios above 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 document.

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

3. The Session Approach

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 Current Jabber OpenPGP Usage [10] and RFC 3923 [11] assume that XMPP communications are more like the exchange of email messages than they are like an interactive session -- while Current Jabber OpenPGP Usage uses "old-style" PGP object encryption and RFC 3923 uses "new-style" S/MIME object encryption, both specify the use of object encryption.

However, because XMPP is a session-oriented communication technology, encryption schemes that are appropriate for other Internet technologies may not be appropriate for XMPP. XMPP, with its in-order delivery of XML stanzas, is able to take advantage of more secure approaches to encryption that are not feasible for less dynamic technologies (like email).

The session-oriented nature of XMPP implies that the focus should be on "session encryption" rather than "object encryption". The paradigm for XMPP encryption should be something closer to the widely-deployed Secure Shell technology (see RFC 4301 [12] and RFC 4253 [13]) than to traditional encryption of files and standalone email messages.

Therefore, this document 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 conceptual model for this approach was inspired by "off-the-record" (OTR) communication, as implemented in the Gaim encryption plugin and described in Off-the-Record Communication [14]. 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.

Note: In order to gain a thorough understanding of this document, it is recommended that the Off-the-Record Communication paper is read first.

4. 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.
  2. "Bob" is the name of the other participant in the ESession started by Alice.

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.

5. Requirements

5.1 Security Requirements

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

Each of these requirements is explained in greater depth below.

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

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

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

5.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). [15]

5.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). [16]

5.1.6 Identity Protection

No other entity should be able to identify Alice or Bob. The JIDs they use to route their stanzas are unavoidably vulnerable to interception. However, the public keys they use SHOULD NOT be revealed to other entities using a passive attack. Bob SHOULD also be able to choose between protecting either his public key or Alice's public key from disclosure through active ("man-in-the-middle") attacks.

5.1.7 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. [17]

5.1.8 Upgradability

The protocol must be upgradable so that, if a vulnerability is discovered, a new version can fix it. Alice MUST tell Bob which versions of the protocol she is prepared to support. Then Bob MUST either choose one or reject the ESession. [18]

5.2 Application Requirements

In addition to the foregoing security profile, this document 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.

5.2.1 Generality

The solution should be generally applicable to the full content of 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.

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

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

5.2.4 Efficiency

Cryptographic operations are highly CPU intensive, particularly public key and Diffie-Hellman operations. Cryptographic data structures can be relatively large especially public keys and certificates. The solution should perform efficiently even when CPU and network bandwidth are constrained. The number of stanzas required for ESession negotiation should be minimized.

5.2.5 Flexibility

The solution should be compatible with existing (and future) cryptographic algorithms and identity certification schemes (including X.509 and PGP). The protocol should also be able to evolve to correct the weaknesses that are inevitably discovered once any cryptographic protocol is in widespread use.

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

5.2.7 Offline Sessions

Ideally, it should be possible to encrypt one-to-one communications that are stored for later delivery instead of being delivered immediately, such as so-called "offline messages". However, any vulnerabilities introduced to enable offline communications must not make online communications more vulnerable.

5.2.8 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".

6. Cryptographic Origins - SIGMA

6.1 Introduction

Authenticated key-exchange is the most challenging part of the design of any secure communication protocol. The ESessions key exchange essentially translates the SIGMA [19] [20] key-exchange protocol into the syntax of XMPP. The SIGMA approach to Diffie-Hellman Key Agreement (see RFC 2631 [21]) underpins several standard key-exchange protocols including the Internet Key Exchange (IKE) protocol versions 1 and 2 (see RFC 2409 [22] and RFC 4306 [23]).

Note: Although this section provides an overview of SIGMA, it is recommended that the SIGMA paper is read first in order to gain a thorough understanding of this document.

The 3-message SIGMA-I-based key exchange protects the identity of the initiator against active attacks. The 4-message SIGMA-R-based key exchange defends the responder's identity against active attacks. The differences between the two versions of the SIGMA protocol are highlighted in the diagrams below.

6.2 SIGMA Parameter Descriptions

Table 1: SIGMA Overview Parameters

Parameter Description
g Diffie-Hellman generator
x, y Alice and Bob's private Diffie-Hellman keys
gx, gy Alice and Bob's public Diffie-Hellman keys
KSA, KSB The MAC keys that Alice and Bob use to calculate macA and macB
pubKeyA, pubKeyB The public keys that represent the identity of Alice and Bob, and are used to verify their signatures
macA, macB The MAC values that associate the shared secret with the identity of Alice or Bob
signKeyA, signKeyB The private keys that Alice and Bob use to sign
signA, signB Alice's and Bob's signatures of the shared secret
KCA, KCB The cipher keys that Alice and Bob use to encrypt
IDA, IDB The encrypted parameters that identify Alice and Bob to each other

Table 2: Key Exchange Parameters

Parameter Description
p Diffie-Hellman prime
e, d Alice and Bob's public Diffie-Hellman keys (the same as gx, gy)
K Shared secret
HASH Selected hash algorithm
NA, NB Alice and Bob's session freshness nonces (ESession IDs)
CA, CB Block cipher initial counter value for blocks sent by Alice and Bob
n Block size of selected cipher algorithm in bits
KMA, KMB The MAC keys that Alice and Bob use to protect the integrity of encrypted data
MA, MB The MAC values that Alice and Bob use to confirm the integrity of encrypted data

6.3 SIGMA-I Overview

The diagram below demonstrates the barest cryptographic skeleton of the SIGMA-I key exchange protocol. Here Bob allows Alice to protect her identity from active attacks, by allowing her to authenticate him before she communicates her identity. Note: The cipher keys (KCA and KCB) are different in each direction, making this exchange slightly more conservative than SIGMA.

ALICE                                                BOB 
                                            gx
                                      ------------>

                                                     macB = HMAC(KSB, {gx, gy, pubKeyB})
                                                     signB = sign(signKeyB, macB)
                                                     IDB = cipher(KCB, {pubKeyB, signB})
                                         gy, IDB 
                                      <------------

authenticate(IDB) 
macA = HMAC(KSA, {gy, gx, pubKeyA})
signA = sign(signKeyA, macA)
IDA = cipher(KCA, {pubKeyA, signA})
                                            IDA
                                      ------------>

                                                     authenticate(IDA)
    

6.4 SIGMA-R Overview

The logic of the SIGMA-R protocol is similar to the SIGMA-I protocol. The diagram below demonstrates the skeleton of the key exchange. After receiving the first message from Alice, Bob chooses to protect his identity from active attacks by by delaying communicating his identity to Alice until he has authenticated her.

ALICE                                                BOB 
                                            gx
                                      ------------>

                                                     macB = HMAC(KSB, {gx, gy, pubKeyB})
                                                     signB = sign(signKeyB, macB)
                                                     IDB = cipher(KCB, {pubKeyB, signB})
                                            gy
                                      <------------

macA = HMAC(KSA, {gy, gx, pubKeyA})
signA = sign(signKeyA, macA)
IDA = cipher(KCA, {pubKeyA, signA})
                                           IDA
                                      ------------>

                                                     authenticate(IDA)
                                           IDB
                                      <------------

authenticate(IDB)
    

Note: In practice, Bob could delay calculating IDB until after he has authenticated IDA.

6.5 SIGMA-I Key Exchange

The diagram below describes exactly the same SIGMA-I key exchange protocol as the SIGMA-I skeleton above. It provides much more detail, without specifying any ESession-specific details. Note: The block cipher function, cipher, uses CTR mode.

ALICE                                        BOB 

x = random()
e = gx mod p
NA = random()
                                 e, NA
                             ------------>
                                             CA = random()
                                             y = random()
                                             d = gy mod p
                                             CB = CA XOR 2n-1 
                                             assert 1 < e < p-1
                                             K = HASH(ey mod p)
                                             KCA = HASH(0, K)
                                             KCB = HASH(1, K)
                                             KMA = HASH(2, K)
                                             KMB = HASH(3, K)
                                             KSA = HASH(4, K)
                                             KSB = HASH(5, K)
                                             NB = random()
                                             macB = HMAC(HASH, KSB, {NA, NB, d, pubKeyB, CA})
                                             signB = sign(signKeyB, macB)
                                             IDB = cipher(KCB, CB, {pubKeyB, signB})
                                             MB = HMAC(HASH, KMB, CB, IDB)
                               d, CA, NB
                             <------------
                                IDB, MB 
CB = CA XOR 2n-1 
assert 1 < d < p-1
K = HASH(dx mod p)
KCA = HASH(0, K)
KCB = HASH(1, K)
KMA = HASH(2, K)
KMB = HASH(3, K)
KSA = HASH(4, K)
KSB = HASH(5, K)
assert MB = HMAC(HASH, KMB, CB, IDB)
{pubKeyB, signB} = decipher(KCB, CB, IDB)
macB = HMAC(HASH, KSB, {NA, NB, d, pubKeyB, CA})
verify(signB, pubKeyB, macB) 
macA = HMAC(HASH, KSA, {NB, NA, e, pubKeyA})
signA = sign(signKeyA, macA)
IDA = cipher(KCA, CA, {pubKeyA, signA})
MA = HMAC(HASH, KMA, CA, IDA)
                                  IDA
                             ------------>
                                   MA 
                                             assert MA = HMAC(HASH, KMA, CA, IDA)
                                             {pubKeyA, signA} = decipher(KCA, CA, IDA)
                                             macA = HMAC(HASH, KSA, {NB, NA, e, pubKeyA})
                                             verify(signA, pubKeyA, macA)
    

6.6 SIGMA-R Key Exchange

The diagram below describes exactly the same SIGMA-R key exchange protocol as the SIGMA-R skeleton above. It provides much more detail, without specifying any ESession-specific details. Note: The block cipher function, cipher, uses CTR mode.

ALICE                                        BOB 

x = random()
e = gx mod p
NA = random()
                                 e, NA
                             ------------>
                                             CA = random()
                                             y = random()
                                             d = gy mod p
                                             CB = CA XOR 2n-1 
                                             assert 1 < e < p-1
                                             K = HASH(ey mod p)
                                             KCA = HASH(0, K)
                                             KCB = HASH(1, K)
                                             KMA = HASH(2, K)
                                             KMB = HASH(3, K)
                                             KSA = HASH(4, K)
                                             KSB = HASH(5, K)
                                             NB = random()
                                             macB = HMAC(HASH, KSB, {NA, NB, d, pubKeyB, CA})
                                             signB = sign(signKeyB, macB)
                                             IDB = cipher(KCB, CB, {pubKeyB, signB})
                                             MB = HMAC(HASH, KMB, CB, IDB)
                               d, CA, NB
                             <------------
CB = CA XOR 2n-1 
assert 1 < d < p-1
K = HASH(dx mod p)
KCA = HASH(0, K)
KCB = HASH(1, K)
KMA = HASH(2, K)
KMB = HASH(3, K)
KSA = HASH(4, K)
KSB = HASH(5, K)
macA = HMAC(HASH, KSA, {NB, NA, e, pubKeyA})
signA = sign(signKeyA, macA)
IDA = cipher(KCA, CA, {pubKeyA, signA})
MA = HMAC(HASH, KMA, CA, IDA)
                                  IDA
                             ------------>
                                   MA 
                                             assert MA = HMAC(HASH, KMA, CA, IDA)
                                             {pubKeyA, signA} = decipher(KCA, CA, IDA)
                                             macA = HMAC(HASH, KSA, {NB, NA, e, pubKeyA})
                                             verify(signA, pubKeyA, macA)
                                  IDB
                             <------------
                                   MB 

assert MB = HMAC(HASH, KMB, CB, IDB)
{pubKeyB, signB} = decipher(KCB, CB, IDB)
macB = HMAC(HASH, KSB, {NA, NB, d, pubKeyB, CA})
verify(signB, pubKeyB, macB)
    

7. Cryptographic Design

This section provides an overview of the full ESession key-exchange protocol from a cryptographic point of view. This protocol is based on the full fledge protocol, as described in Appendix B of the SIGMA paper. It also uses variant (ii), as described in Secion 5.4 of the same paper.

7.1 ESession Parameter Descriptions

The table below describes the parameters that are not found in the Parameter Descriptions tables at the start of the previous section.

Table 3: ESession Negotiation Parameters

Parameter Description
options Includes a set of possible values for each and every ESession parameter (see the ESession Request sub-section in Encrypted Sessions), including sets of possible values for p, g, HASH, CIPHER, SIGN
chosen Includes a chosen value for each ESession parameter
CIPHER Selected CTR-mode block cipher algorithm
DECIPHER Selected CTR-mode block decipher algorithm (corresponds to CIPHER)
SIGN Selected signature algorithm
VERIFY The selected signature verification algorithm (corresponds to SIGN)
x1...xZ Alice's private Diffie-Hellman keys - each value corresponds to one of Z different DH groups
e1...eZ The choice of public Diffie-Hellman keys that Alice offers Bob - each value corresponds to one of Z different DH groups (and a different value of x)
*signKeysA All the private keys that Alice is able to use to create signatures
*signsB The set of signatures of formB (one for each of Bob's private keys)
*pubKeysA All of Alice's public keys that Bob has access to

* Offline negotiation only

7.2 Online ESession-I Negotiation

Alice uses this protocol when Bob is Online. In addition to the key exchange described in the SIGMA-I Key Exchange protocol above, she offers Bob a choice of Diffie-Hellman groups with her corresponding values of e, various algorithms and other parameters.

ALICE                                    BOB 

for g,p ∈ options
    x = random()
    e = gx mod p
NA = random()
formA = {e1...eZ, options, NA}
                                formA
                             --------->

                                         chosen = {p,g,HASH,CIPHER,SIGN...} = choose(options)
                                         e = choose(e1...eZ, p)
                                         CA = random()
                                         y = random()
                                         d = gy mod p
                                         CB = CA XOR 2n-1 
                                         assert 1 < e < p-1
                                         K = HASH(ey mod p)
                                         KCA = HASH(0, K)
                                         KCB = HASH(1, K)
                                         KMA = HASH(2, K)
                                         KMB = HASH(3, K)
                                         KSA = HASH(4, K)
                                         KSB = HASH(5, K)
                                         NB = random()
                                         formB = {CA, chosen, d, NA, NB}
                                         macB = HMAC(HASH, KSB, {NA, NB, d, pubKeyB, formB})
                                         signB = SIGN(signKeyB, macB)
                                         IDB = CIPHER(KCB, CB, {pubKeyB, signB})
                                         MB = HMAC(HASH, KMB, CB, IDB)
                                formB
                             <---------
                               IDB, MB 
assert chosen ∈ options
x = choose(x1...xZ, p)
e = gx mod p
CB = CA XOR 2n-1 
assert 1 < d < p-1
K = HASH(dx mod p)
KCA = HASH(0, K)
KCB = HASH(1, K)
KMA = HASH(2, K)
KMB = HASH(3, K)
KSA = HASH(4, K)
KSB = HASH(5, K)
assert MB = HMAC(HASH, KMB, CB, IDB)
{pubKeyB, signB} = DECIPHER(KCB, CB, IDB)
macB = HMAC(HASH, KSB, {NA, NB, d, pubKeyB, formB})
VERIFY(signB, pubKeyB, macB) 
macA = HMAC(HASH, KSA, {NB, NA, e, pubKeyA, formA})
signA = SIGN(signKeyA, macA)
IDA = CIPHER(KCA, CA, {pubKeyA, signA})
MA = HMAC(HASH, KMA, CA, IDA)
                                 IDA
                             --------->
                               NB, MA 
                                         assert 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)
    

7.3 Online ESession-R Negotiation

This protocol is similar to the Online ESession-I Negotiation above, except that after receiving the first message from Alice, Bob chooses to protect his identity from active attacks (by by delaying communicating his identity to Alice until he has authenticated her).

ALICE                                    BOB 

for g,p ∈ options
    x = random()
    e = gx mod p
NA = random()
formA = {e1...eZ, options, NA}
                                formA
                             --------->

                                         chosen = {p,g,HASH,CIPHER,SIGN...} = choose(options)
                                         e = choose(e1...eZ, p)
                                         CA = random()
                                         y = random()
                                         d = gy mod p
                                         CB = CA XOR 2n-1 
                                         assert 1 < e < p-1
                                         K = HASH(ey mod p)
                                         KCA = HASH(0, K)
                                         KCB = HASH(1, K)
                                         KMA = HASH(2, K)
                                         KMB = HASH(3, K)
                                         KSA = HASH(4, K)
                                         KSB = HASH(5, K)
                                         NB = random()
                                         formB = {CA, chosen, d, NA, NB}
                                         macB = HMAC(HASH, KSB, {NA, NB, d, pubKeyB, formB})
                                         signB = SIGN(signKeyB, macB)
                                         IDB = CIPHER(KCB, CB, {pubKeyB, signB})
                                         MB = HMAC(HASH, KMB, CB, IDB)

                                formB
                             <---------
assert chosen ∈ options
x = choose(x1...xZ, p)
e = gx mod p
CB = CA XOR 2n-1 
assert 1 < d < p-1
K = HASH(dx mod p)
KCA = HASH(0, K)
KCB = HASH(1, K)
KMA = HASH(2, K)
KMB = HASH(3, K)
KSA = HASH(4, K)
KSB = HASH(5, K)
macA = HMAC(HASH, KSA, {NB, NA, e, pubKeyA, formA})
signA = SIGN(signKeyA, macA)
IDA = CIPHER(KCA, CA, {pubKeyA, signA})
MA = HMAC(HASH, KMA, CA, IDA)
                                 IDA
                             --------->
                               NB, MA 
                                        assert 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)
                                 IDB
                             <---------
                               NA, MB 

assert MB = HMAC(HASH, KMB, CB, IDB)
{pubKeyB, signB} = DECIPHER(KCB, CB, IDB)
macB = HMAC(HASH, KSB, {NA, NB, d, pubKeyB, formB})
VERIFY(signB, pubKeyB, macB)
    

7.4 Offline ESession Negotiation

Bob uses this protocol to send stanzas to Alice when she is Offline. Note: Since the full SIGMA protocol cannot be used if Alice is offline, her identity is not protected.

The diagram is split into three phases. First Alice publishes her ESession options before going offline. Later Bob completes the key exchange (and sends her encrypted stanzas that are not shown below) these are all stored by Alice's server. Finally when Alice comes online again she verifies and calculates the decryption key.

The differences between this offline protocol and the Online ESession-I Negotiation protocol above are highlighted in the diagram below.

ALICE                    ALICE'S SERVER              BOB 

for g,p ∈ options
    x = random()
    e = gx mod p
NA = random()
formA = {e1...eZ, options, NA}
signsA = multi_sign(signKeysA, formA)
store(NA, x1...xZ, expireTime)
                   formA
                 -------->
                   signsA 

                         store(formA, signsA)
---------------------------------------------------------------------------------------------------------
                         retrieve(formA, signsA)

                                             formA
                                           -------->
                                             signsA 

                                                     verify_one(signsA, pubKeysA, formA)
                                                     chosen = {p,g,HASH,CIPHER,SIGN...} = choose(options)
                                                     e = choose(e1...eZ, p)
                                                     CA = random()
                                                     y = random()
                                                     d = gy mod p
                                                     CB = CA XOR 2n-1 
                                                     assert 1 < e < p-1
                                                     K = HASH(ey mod p)
                                                     KCA = HASH(0, K)
                                                     KCB = HASH(1, K)
                                                     KMA = HASH(2, K)
                                                     KMB = HASH(3, K)
                                                     KSA = HASH(4, K)
                                                     KSB = HASH(5, K)
                                                     NB = random()
                                                     formB = {CA, chosen, d, NA, NB}
                                                     macB = HMAC(HASH, KSB, {NA, NB, d, pubKeyB, formB})
                                                     signB = SIGN(signKeyB, macB)
                                                     IDB = CIPHER(KCB, CB, {pubKeyB, signB})
                                                     MB = HMAC(HASH, KMB, CB, IDB)

                                             formB
                                           <--------
                                            IDB, MB 

                         store(formB,IDB,MB)
---------------------------------------------------------------------------------------------------------
                         retrieve(formB,IDB,MB) 
                   formB
                 <--------
                  IDB, MB 

retrieve(NA, x1...xZ, expireTime) 
assert now < expireTime
assert chosen ∈ options
x = choose(x1...xZ, p)
e = gx mod p
CB = CA XOR 2n-1 
assert 1 < d < p-1
K = HASH(dx mod p)
KCA = HASH(0, K)
KCB = HASH(1, K)
KMA = HASH(2, K)
KMB = HASH(3, K)
KSA = HASH(4, K)
KSB = HASH(5, K)
assert MB = HMAC(HASH, KMB, CB, IDB)
{pubKeyB, signB} = DECIPHER(KCB, CB, IDB)
macB = HMAC(HASH, KSB, {NA, NB, d, pubKeyB, formB})
VERIFY(signB, pubKeyB, macB)
    

Note: KMB is necessary only to allow Bob to terminate the ESession if he comes online before Alice terminates it. The calculation of KCB and KSB is not strictly necessary.

8. Security Considerations

The security considerations are described in Encrypted Sessions and Offline Encrypted Sessions.

9. IANA Considerations

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

10. XMPP Registrar Considerations

This document requires no interaction with the XMPP Registrar [25].

11. Acknowledgments

The author would like to thank Ian Goldberg for the time he spent reviewing this protocol and for his invaluable suggestions and comments.


Notes

1. XEP-0116: Encrypted Sessions <http://www.xmpp.org/extensions/xep-0116.html>.

2. XEP-0187: Offline Encrypted Sessions <http://www.xmpp.org/extensions/xep-0187.html>.

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

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

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

6. XEP-0079: Advanced Message Processing <http://www.xmpp.org/extensions/xep-0079.html>.

7. XEP-0096: File Transfer <http://www.xmpp.org/extensions/xep-0096.html>.

8. XEP-0045: Multi-User Chat <http://www.xmpp.org/extensions/xep-0045.html>.

9. XEP-0060: Publish-Subscribe <http://www.xmpp.org/extensions/xep-0060.html>.

10. XEP-0027: Current Jabber OpenPGP Usage <http://www.xmpp.org/extensions/xep-0027.html>.

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

12. RFC 4301: Security Architecture for the Internet Protocol <http://www.ietf.org/rfc/rfc4301.txt>.

13. RFC 4253: The Secure Shell (SSH) Transport Layer Protocol <http://www.ietf.org/rfc/rfc4253.txt>.

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

15. Long-lived keys are typically used for a few years, whereas Offline ESession keys are destroyed as soon as the stanza is decrypted - they typically exist for just a few hours. So Perfect Forward Secrecy should significantly enhance the security even of Offline ESessions.

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

17. 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 document.

18. It is exceptionally difficult to design a truly secure authenticated key-exchange protocol. Weaknesses are often only discovered after years of expert cryptographic analysis. In many cases, only the widespread use of a protocol will motivate experts to undertake exhaustive analyses and recommend enhancements.

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

20. Like RFC 2409, this protocol uses variant (ii), as described in Secion 5.4 of the SIGMA paper.

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

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

23. RFC 4306: Internet Key Exchange (IKEv2) Protocol <http://www.ietf.org/rfc/rfc4306.txt>.

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

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


Revision History

Version 0.2 (2006-07-19)

Removed public key IDs from Offline options

(ip)

Version 0.1 (2006-07-18)

Initial version (extracted from XEP-0116 version 0.9).

(ip)


END