This JEP specifies a protocol for session-based, end-to-end encryption of XMPP communications.
WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.
Status: Experimental
Type: Standards Track
Number: 0116
Version: 0.3
Last Updated: 2005-08-02
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, RFC 2409, RFC 2631, RFC 3526, JEP-0004, JEP-0020, JEP-0030, JEP-0068, JEP-0155
Supersedes: None
Superseded By: None
Short Name: esession
Email: ian.paterson@clientside.co.uk
JID: ian@zoofy.com
Email: stpeter@jabber.org
JID: stpeter@jabber.org
Email: dizzyd@jabber.org
JID: dizzyd@jabber.org
This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
Given that this JEP normatively references IETF technologies, discussion on the JSF-IETF list may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/jsf-ietf> for details).
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
End-to-end encryption is a desirable feature for any communication technology. Ideally, such a technology would design encryption in from the beginning and would forbid unencrypted communications. Realistically, most communication technologies have not been designed in that manner, and Jabber/XMPP technologies are no exception. In particular, the original Jabber technologies developed in 1999 did not include end-to-end encryption by default. PGP-based encryption of message bodies and signing of presence information was added as an extension to the core protocols in the year 2000; this extension is documented in Current Jabber OpenPGP Usage [1]. When the core protocols were formalized within the Internet Standards Process by the IETF's XMPP Working Group in 2003, a different extension was defined using S/MIME-based signing and encryption of CPIM-formatted messages (see RFC 3862 [2]) and PIDF-formatted presence information (see RFC 3863 [3]); this extension is specified in RFC 3923 [4].
For reasons described more fully below, the foregoing proposals (and others not mentioned) have not been widely implemented and deployed. This is unfortunate, since an open communication protocol needs to enable end-to-end encryption in order to be seriously considered for deployment by a broad range of users. This proposal describes a different approach to end-to-end encryption for use by entities that communicate using XMPP. The approach taken herein essentially translates the semantics of the secure shell protocol (SSH) into the syntax of XMPP, with some adjustments that reflect reports of security issues with SHA-1 and insights gleaned from implementation of "off-the-record" (OTR) communication in the Gaim encryption plugin as described in Off-the-Record Communication [5]. The result is a protocol for encrypted sessions or "ESessions".
As specified in RFC 3920 [6], XMPP is an XML streaming protocol that enables the near-real-time exchange of XML fragments between any two (or more) network endpoints. To date, the main application built on top of the core XML streaming layer is instant messaging (IM) and presence, the base extensions for which are specified in RFC 3921 [7]. There are three first-level elements of XML streams (<message/>, <presence/>, and <iq/>); each of these "XML stanza" types has different semantics, which can complicate the task of defining a generalized approach to end-to-end encryption for XMPP. In addition, XML stanzas can be extended (via properly-namespaced child elements) for a wide variety of functionality. The chosen approach should enable encryption of several complete XML elements rather than only parts thereof (e.g., only the XML character data of the message <body/> element as in JEP-0027).
XMPP is a session-oriented communication technology: normally, a client authenticates with a server and maintains a long-lived connection that defines the client's XMPP session. Such stream-level sessions are secured via channel encryption using Transport Level Security (RFC 2246 [8]), as specified in Section 5 of RFC 3920. However, there is no guarantee that all hops will implement or enforce channel encryption (or that intermediate routers are trustworthy), which makes end-to-end encryption desirable.
The session metaphor also applies to communication between endpoints: for instance, in IM applications, most instant messaging exchanges occur in bursts within limited time periods (e.g., two people may send a fairly large number of messages during a five-minute chat and then not exchange messages again for hours or even days). The XML stanzas exchanged during such a session may not be limited to <message/> stanzas; for instance, the session may be triggered by a change in one of the parties' presence status (e.g., changing from away to available) and the session may involve the exchange of <iq/> stanzas (e.g., to transfer a file as specified in File Transfer [9]). Endpoints may want to encrypt the stanzas they send to each other in such a way that the stanzas cannot be understood by untrusted mediating entities (such as servers) except to the extent required to understand the necessary routing information. (One complicating factor is that routing information may include not only the stanza's 'to', 'from', 'type, and 'id' attributes, but also Advanced Message Processing [10] and Stanza Headers and Internet Metadata (SHIM) [11] data extensions.)
The foregoing XMPP communications exist in the context of a one-to-one communication session between two entities. However, several forms of XMPP communication exist outside the context of one-to-one communication sessions:
Ideally, any technology for end-to-end encryption in XMPP could be extended to cover these scenarios as well as one-to-one communication sessions. However, for both many-to-many sessions and one-to-many broadcast are are deemed out of scope for this JEP. Offline communications are handled via a simple extension to the protocol for one-to-one sessions between two entities that are online simultaneously (see below).
Because XMPP is a session-oriented communication technology, encryption schemes that are appropriate for less dynamic technologies may not be appropriate for XMPP, and XMPP may be able to take advantage of encryption approaches that are not feasible for less dynamic technologies. In particular, existing approaches to encryption of Internet communications have generally assumed that the "thing" to be encrypted has a stable identity or is best understood as a standalone object (e.g., a file or email message); the term "object encryption" well captures this assumption. Both JEP-0027 and RFC 3923 assume that XMPP communications are more like the exchange of email messages than they are like an interactive session -- while JEP-0027 uses "old-style" PGP object encryption and RFC 3923 uses "new-style" S/MIME object encryption, both specify the use of object encryption.
However, the session-oriented nature of XMPP may imply that the focus should be on "session encryption" rather than "object encryption". The paradigm for XMPP encryption may be something closer to the widely-deployed Secure Shell technology (see SSH Protocol Architecture [14] and SSH Transport Layer Protocol [15]) than to traditional encryption of files and standalone email messages. In many ways, Secure Shell (or, more generally, opportunistic security) is the conceptual model for the current proposal.
Therefore, this JEP specifies a method for encrypted sessions ("ESessions") that takes advantage of the inherent possibilities and strengths of session encryption as opposed to object encryption. The basic concept is that of an encrypted session which acts as a secure tunnel between two endpoints. Once the tunnel is established, all one-to-one XML stanzas exchanged between the endpoints will be encrypted and then transmitted within a "wrapper" protocol element.
This JEP introduces two characters to help the reader follow the necessary exchanges:
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.
This JEP stipulates the following security requirements for end-to-end encryption of XMPP communications:
Each of these requirements is explained in greater depth below.
The one-to-one XML stanzas exchanged between two entities MUST NOT be understandable to any other entity that might intercept the communications.
The encrypted communication MUST NOT be revealed even if a system compromise occurs in the future (e.g., Steve steals Bob's computer).
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).
Alice and Bob MUST be able to repudiate any stanza that occurs within an Esession. After an Esession has finished, it SHOULD NOT be possible to prove cryptographically that any transcript has not been modified by a third party. [16]
In addition to the foregoing security profile, this JEP also stipulates the following application-specific requirements for encrypted communication in the context of Jabber/XMPP technologies:
Each of these is explained in greater depth below.
The solution should be generally applicable to any XML stanza type (<message/>, <presence/>, <iq/>) sent between two entities. It is deemed acceptable for now if the solution does not apply to many-to-many stanzas (e.g., groupchat messages sent within the context of multi-user chat) or one-to-many stanzas (e.g., presence "broadcasts" and pubsub notifications); end-to-end encryption of such stanzas may require separate solutions or extensions to the one-to-one session solution.
The only good security technology is an implemented security technology. The solution should be one that typical client developers can implemented in a relatively straightforward and consistent fashion.
The requirement of usability takes implementability one step further by stipulating that the solution must be one that organizations can deploy and humans can use with 100% transparency (like 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.
Ideally, it would be possible for an XMPP user to exchange encrypted messages (and, potentially, presence information) with users of non-XMPP messaging systems.
Ideally, it should be possible to encrypt one-to-one communications that are stored for later delivery rather than delivered immediately, such as so-called "offline messages".
Before attempting to engage in an ESession with Bob, Alice SHOULD discover whether he supports this protocol, using either Service Discovery [17] or the presence-based profile of JEP-0030 specified in Entity Capabilities [18].
The normal course of events is for Alice to authenticate with her server, retrieve her roster (see RFC 3921), send initial presence to her server, and then receive presence information from all the contacts in her roster. If the presence information she receives from some contacts does not include capabilities data (per JEP-0115), Alice SHOULD then send a service discovery information ("disco#info") request to each of those contacts (in accordance with JEP-0030). Such initial service discovery stanzas MUST NOT be considered part of encrypted communication sessions for the purposes of this JEP, since they perform a "bootstrapping" function that is a prerequisite to encrypted communications. The disco#info request sent from Alice to Bob might look as follows:
Example 1. Alice Queries Bob for Esession Support via Disco
<iq from='alice@example.org/pda'
to='bob@example.com/laptop'
id='disco1'
type='get'>
<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 from='bob@example.com/laptop'
from='alice@example.org/pda'
id='disco1'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='client' type='pc'/>
...
<feature var='http://jabber.org/protocol/esession'/>
...
</query>
</iq>
The process for establishing an ESession is essentially a translation into XMPP syntax of the SSH transport mechanism for establishing a secure session over an insecure transport (see SSH Transport Layer Protocol). Specifically, as in SSH, ESession uses a Diffie-Hellman key exchange algorithm (see RFC 2631 [19]) in the initial negotation (although, as we shall see, it does not use SHA-1 as the hashing algorithm).
When Alice wishes to establish an ESession with Bob, Alice may choose between two different methods of performing the initial Diffie-Hellman key exchange, depending on whether Bob is online or not.
If Alice believes Bob may be online then she SHOULD retrieve Bob's long-term public signature-verification keys (see Public Key Publication and Retrieval) and then use the protocol specified in Chat Session Negotiation [20] to negotiate the initial Diffie-Hellman key. In this aggressive exchange the first two messages negotiate policy, swap Diffie-Hellman public values and the ancillary data necessary for the exchange and authentication. The second message also authenticates the responder. The third message authenticates the initiator and exchanges the final Diffie-Hellman public value.
Alice MUST provide information about each of the Esession options (algorithms etc.) that she is willing to use, in her order of preference (see the Mandatory to Implement Technologies section of this document for further information):
The list of Modular Exponential (MODP) group numbers (as specified in RFC 2409 [21] or RFC 3526 [22]) she is willing to use for Diffie-Hellman key exchange (valid group numbers include 1,2,3,4,5,14,15,16,17 and 18)
Stanza symmetric encryption algorithm names
Hash algorithm names
Compression algorithm names
The list of stanza types she is willing to encrypt and decrypt
The minimum number of stanzas that MUST be exchanged before an entity MAY initiate a key re-exchange (1 - every stanza, 100 - every hundred stanzas). This value MUST be less than 232 (see Re-Keying Limits)
The Base64 encoded (in accordance with Section 3 of RFC 3548 [23]) SHA-256 fingerprint (PKID) of each of Bob's public signature-verification keys that she found acceptable (see Verifying Keys)
Example 3. Alice Requests an ESession
<message from='alice@example.org/pda'
to='bob@example.com'
id='es1'>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/chatneg</value>
</field>
...
<field var='modp' type='list-single'>
<option><value>5</value></option>
<option><value>14</value></option>
<option><value>2</value></option>
<option><value>1</value></option>
</field>
<field var='encryption_algorithms' type='list-single'>
<option><value>aes256-ctr</value></option>
<option><value>twofish256-ctr</value></option>
<option><value>aes128-ctr</value></option>
</field>
<field var='hash_algorithms' type='list-single'>
<option><value>whirlpool</value></option>
<option><value>sha256</value></option>
</field>
<field var='compression' type='list-single'>
<option><value>none</value></option>
<option><value>zlib</value></option>
</field>
<field var='stanzas' type='list-multi'>
<option><value>message</value></option>
<option><value>iq</value></option>
<option><value>presence</value></option>
</field>
<field var='max_rekey_freq' type='text-single'>
<value>1</value>
</field>
<field var='publickey_ids' type='list-multi'>
<option><value> ** PKID ** </value></option>
<option><value> ** PKID ** </value></option>
</field>
...
</x>
</feature>
</message>
If Bob does not support one or more of the options in each Esession field (except the 'publickey_ids' field), then he SHOULD return a <feature-not-implemented/> error (but he MAY return no error if, for example, he does not want to reveal his presence to Alice for whatever reason):
Example 4. Bob Informs Alice that Her Options Are Not Supported
<message type='error'
from='bob@example.com/laptop'
to='alice@example.org/pda'
id='es1'>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='form'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/chatneg</value>
</field>
...
</x>
</feature>
<error code='501' type='cancel'>
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</message>
Either Bob or Alice MAY attempt to initiate a new ESession after any error during the initiation process. However, both MUST consider the previous negotiation to have failed and MUST discard any information learned through the previous negotiation.
If Bob is willing to start an ESession with Alice, he SHOULD retrieve Alice's long-term public signature-verification keys. He MUST select one of the options from each of the Esession fields he received from Alice including one of the MODP groups (see the Conclusion of RFC 3766 [24] for recommendations regarding balancing the sizes of symmetric cipher blocks and Diffie-Hellman moduli). Each MODP group has at least two well known constants: a large prime number p, and a generator g for a subgroup of GF(p).
Bob MUST then perform the following computations (where n is the number of bits per encryption block for the selected encryption algorithm):
Generate the initial value of CA with n-1 random bits (CA is the encryption block counter for stanzas sent from Alice to Bob)
Set CB = CA + 2n-1 (where CB is the counter for stanzas sent from Bob to Alice)
Generate a secret random number y (where 22n-1 < y < p - 1)
Calculate d = gy mod p
Generate an opaque unique key identifier (KID) for d
If Alice selected one or more of his public keys, and if Bob has access to a long-lived private signing key that corresponds to one of those keys (note that the keys may only be accessible to another of Bob's clients), calculate the signature of d using the selected private key
Bob responds to Alice specifying the Esession options he selected. Note: The value of the 'max_rekey_freq' field MUST be less than 232 and greater than or equal to the value specified by Alice. Instead of providing the PKID of his public key that he selected, Bob MUST specify the Base64 encoded SHA-256 fingerprint (PKID) of each of Alice's public signature-verification keys that he finds acceptable (see Verifying Keys). Note: The submited values for the 'publickey_ids' field do not correspond to the options he received.
Bob also includes CA, the value of d and the signature of d (if it was possible to create one), all Base64 encoded.
Example 5. Bob Responds to Alice
<message from='bob@example.com/laptop'
to='alice@example.org/pda'
id='es1'>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/chatneg</value>
</field>
...
<field var='modp'><value>5</value></field>
<field var='encryption_algorithms'><value>aes256-ctr</value></field>
<field var='hash_algorithms'><value>sha256</value></field>
<field var='compression'><value>none</value></field>
<field var='stanzas'><value>message</value></field>
<field var='max_rekey_freq'><value>50</value></field>
<field var='publickey_ids'>
<value> ** PKID ** </value>
<value> ** PKID ** </value>
</field>
...
</x>
</feature>
<init xmlns='http://jabber.org/protocol/esession#init'>
<key kid=' ** KID ** '> ** base64 encoded value of d ** </key>
<sign pkid=' ** PKID ** '> ** base64 encoded signature of d ** </sign>
<counter> ** base64 encoded initial counter value ** </counter>
</init>
</message>
If Alice provided a PKID but Bob did not provide a signature then she MAY send a failure notice to Bob. If Bob provided an invalid signature then she MUST send a failure notice to Bob.
Example 6. Alice Signals that ESession Negotiation Failed (Unacceptable Signature)
<message type='error'
from='alice@example.org/pda'
to='bob@example.com/laptop'
id='es2'>
<error code='406' type='modify'>
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<invalid-signature xmlns='http://jabber.org/protocol/esession#error'/>
</error>
</message>
After verifying Bob's signature, Alice can be certain that the value of d was actually generated by Bob. Alice MUST use the value of d and the Esession options specified in Bob's response to perform the following steps (where n is the number of bits per encryption block for the agreed encryption algorithm):
Set the initial value of CA to the counter value she received from Bob
Set CB = CA + 2n-1
Generate a secret random number x (where 22n-1 < x < p - 1)
Calculate e = gx mod p
Generate an opaque unique key identifier (KID) for e
If Bob selected one or more of her public keys, and if Alice has access to a long-lived private signing key that corresponds to one of those keys, calculate the signature of e using the selected private key
Calculate K = dx mod p (this is the shared secret)
Alice then completes the Diffie-Hellman negotiation by sending Bob the value of e and the signature of e (if it was possible to create one), both Base64 encoded. Alice MAY also send encrypted content (see the Exchanging Stanzas section of this document) in the same stanza as the Diffie-Hellman completion.
Example 7. Alice Completes Diffie-Hellman Negotitation
<message from='alice@example.org/pda'
to='bob@example.com/laptop'>
<init xmlns='http://jabber.org/protocol/esession#init'>
<key kid=' ** KID ** '> ** base64 encoded value of e ** </key>
<sign pkid=' ** PKID ** '> ** base64 encoded signature of e ** </sign>
</init>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data kid=' ** KID ** '> ** base64 encoded m_final ** </data>
<mac> ** base64 encoded a_mac ** </mac>
</encrypted>
</message>
If Bob provided a PKID but Alice did not provide a valid signature, then he MUST ignore any encrypted content in the stanza and send a failure notice to Alice.
If no error occurs, Bob MUST calculate K = ey mod p (the shared secret). Alice and Bob then have the same value for K and the key exchange is complete.
As described below, offline negotiation of an ESession is in essence a special case of the online negotiation flow.
Just before Bob goes offline he SHOULD:
Select a MODP group (that defines the constants p and g)
Generate a secret random number y (where 22n-1 < y < p - 1, where n is the largest number of bits per encryption block for the encryption algorithms he is willing to use)
Calculate d = gy mod p
Generate an opaque unique key identifier (KID) for d
Bob SHOULD publish d and the KID along with information about each of the Esession options he is willing to use (see Esession Request) through his own server using the disco#publish-info feature (as NOT SPECIFIED in JEP-0030) or a similar protocol (out of scope for this JEP). Note: The single specified MODP group MUST be the one he used to generate d. The list of stanza types he is willing to decrypt MUST NOT include the value 'iq'. It is also RECOMMENDED that he includes a list of his public signature-verification keys and the corresponding signatures of d.
Note: This publishing protocol is highly preliminary and depends on a separate proposal.
Example 8. Bob Publishes His Esession Options
<iq from='bob@example.com/laptop'
type='set'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/esession'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/esession</value>
</field>
<field var='modp'>
<value>2</value>
</field>
<field var='encryption_algorithms'>
<value>aes256-ctr</value>
<value>twofish256-ctr</value>
<value>aes128-ctr</value>
</field>
<field var='hash_algorithms'>
<value>whirlpool</value>
<value>sha256</value>
</field>
<field var='compression'>
<value>none</value>
<value>zlib</value>
</field>
<field var='stanzas'>
<value>message</value>
</field>
<field var='max_rekey_freq'>
<value>1</value>
</field>
<field var='kid'>
<value> ** KID ** </value>
</field>
<field var='key'>
<value> ** base64 encoded value of d ** </value>
</field>
<field var='publickey_ids'>
<value> ** PKID ** </value>
<value> ** PKID ** </value>
</field>
<field var='sign'>
<value> ** base64 encoded signature of d ** </value>
<value> ** base64 encoded signature of d ** </value>
</field>
</x>
</query>
</iq>
Bob MUST store the secret value of y that he used to calculate d in a secure way so that he can retrieve it when he next comes online. Note: Bob should idealy be able to access the value of y even if he comes online with a different client on a different machine, otherwise he will not be able to decrypt the stanzas sent to him while he was offline.
If Alice believes Bob is offline then she SHOULD request his Esession options and his long-term public signature-verification keys (see Public Key Publication and Retrieval) from his server.
Example 9. Alice asks Bob's Server for his Esession Options
<iq type='get'
from='alice@example.org/pda'
to='bob@example.com'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/esession'/>
</iq>
If, after receiving Bob's Esession options and public keys, Alice is unable to verify any of Bob's Esession signatures then she MAY decide to proceed no further, since she cannot be sure who will be able to decrypt her stanzas.
Alice MUST select one of the options from each of Bob's Esession fields. If she cannot support any of the options in a field (except the public key and signature fields) then she MUST not send encrypted stanzas to Bob while he is offline.
Alice MUST use the value of d and the MODP group specified in Bob's Esession options to perform the following steps (where n is the number of bits per encryption block for the selected encryption algorithm):
Generate the initial value of CA with n-1 random bits (CA is the encryption block counter for stanzas sent from Alice to Bob)
Set CB = CA + 2n-1 (where CB is the counter for stanzas sent from Bob to Alice - in case Bob comes online before Alice terminates the Esession)
Generate a secret random number x (where 22n-1 < x < p - 1)
Calculate e = gx mod p
Generate an opaque unique key identifier (KID) for e
Calculate signatures of e using each of her long-lived private signing keys
Calculate K = dx mod p (the shared secret)
Alice then sends Bob all the signatures of e, the value of e and CA (all Base64 encoded). She also specifies which of his Esession options she selected. Note: The value of the 'max_rekey_freq' field MUST be less than 232 and greater than or equal to the value specified by Bob. Alice MAY also send encrypted content (see the Exchanging Stanzas section of this document) in the same stanza.
Example 10. Alice Establishes an ESession Without Negotiation
<message from='alice@example.org/pda'
to='bob@example.com'>
<init xmlns='http://jabber.org/protocol/esession#init'>
<key kid=' ** KID ** '> ** base64 encoded value of e ** </key>
<sign pkid=' ** PKID ** '> ** base64 encoded signature of e ** </sign>
<sign pkid=' ** PKID ** '> ** base64 encoded signature of e ** </sign>
<counter> ** base64 encoded initial counter value ** </counter>
<x xmlns='jabber:x:data'>
<field var='modp'><value>5</value></field>
<field var='encryption_algorithms'><value>aes256-ctr</value></field>
<field var='hash_algorithms'><value>sha256</value></field>
<field var='compression'><value>none</value></field>
<field var='max_rekey_freq'><value>1</value></field>
<field var='stanzas'><value>message</value></field>
</x>
</init>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data kid=' ** KID ** '> ** base64 encoded m_final ** </data>
<mac> ** base64 encoded a_mac ** </mac>
</encrypted>
</message>
Alice can assume that she and Bob have the same value for K and that the key exchange is complete.
When Bob comes online and receives the key exchange stanza from Alice then he MUST perform the following steps:
Request Alice's public keys and, if possible, confirm that one of her signatures matches her value of e (if he is unable to verify any of her signatures then he MAY decide to proceed no further, since he cannot be sure who started the Esession)
Set the initial value of CA to the counter value he received from Alice
Set CB = CA + 2n-1 (in case Alice has not yet terminated the Esession)
Calculate K = ey mod p (the shared secret)
Whichever method Alice used to perform the Diffie-Hellman key exchange (online or offline), once it is complete, then before Alice and Bob can start encrypting and decrypting stanzas they must both use the agreed hash algorithm ("HASH") to generate two sets of key data, one for each direction of the ESession.
For stanzas that Alice will send to Bob, the keys are calculated as:
Encryption key K-EA = HASH(K, "A")
Integrity key K-MA = HASH(K-EA, "C") [25]
For stanzas that Bob will send to Alice the keys are calculated as:
Encryption key K-EB = HASH(K, "B")
Integrity key K-MB = HASH(K-EB, "D")
Once the two sets of key data have been calculated the value of K MUST be securely destroyed.
As many bytes of key data as are needed MUST be taken from the beginning of the hash output. When negotiating a hash, entities MUST ensure that the hash output is no shorter than the required key data. For algorithms with variable-length keys the maximum length (up to the hash output length) SHOULD be used.
With these keys computed and the algorithms agreed upon, ESession initiation is now complete. From this point forward, Alice and Bob MUST exchange only encrypted forms of the one-to-one stanza types they agreed upon (e.g., <message/> and <iq/> stanzas).
Once an Esession has been established, whenever Alice wants to send Bob an encrypted stanza she MUST only encrypt the XML content that would normally be ignored by the intermediate servers.
Example 11. 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' per-hop='true'>
<rule condition='match-resource' value='exact' action='error'/>
</amp>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='Store'>false</header>
</headers>
<active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
Example 12. XML Content to be encrypted
<body>Hello, Bob!</body> <active xmlns='http://jabber.org/protocol/chatstates'/>
Alice MUST perform the following steps to encrypt the XML content.
Serialize the XML content she wishes to send into an array of UTF-8 bytes, m. [26]
If compression was agreed upon, compress m using the negotiated algorithm. Typically, the compression context will be initialized after key exchange and is passed from one stanza to the next, with only a partial flush being performed at the end of the stanza. Note this means if Bob receives a stanza out-of-order, then he will fail to decrypt the stanza and be forced to terminate the Esession.
m_compressed = compress(m)
Encrypt the data with the agreed algorithm in counter mode, using the encryption key K-EA. Note: CA MUST be incremented for each encrypted block, and if CA=2n-1 (where n is the number of bits per encryption block for the agreed encryption algorithm) then CA MUST be "incremented" to 1.
m_final = encrypt(K-EA, CA, m_compressed)
The encrypted data and the value of Alice's encryption block counter CA before the data was encrypted, are now processed through the HMAC algorithm (as defined in Section 2 of RFC 2104 [27]), along with the agreed hash algorithm ("HASH") and the integrity key K-MA.
a_mac = HMAC(HASH, K-MA, m_final, CA)
Note: CA and CB prevent replay attacks by ensuring that the Message Authentication Code (MAC) for a given stanza never repeats, even if the content of the stanza is identical.
Alice MUST now create an <encrypted/> XML element using a_mac, m_final and Bob's KID (the one that corresponds to the value of d used to encrypt the data). She MUST insert the element into the stanza in place of the original content and send it to Bob. There MUST NOT be more than one <encrypted/> element per stanza.
Example 13. Stanza with Encrypted Content
<message from='alice@example.org/pda' to='bob@example.com/laptop'>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data kid=' ** KID ** '> ** base64 encoded m_final ** </data>
<mac> ** base64 encoded a_mac ** </mac>
</encrypted>
<amp xmlns='http://jabber.org/protocol/amp' per-hop='true'>
<rule condition='match-resource' value='exact' action='error'/>
</amp>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='Store'>false</header>
</headers>
</message>
When Bob receives the stanza from Alice, he extracts the values of m_final and a_mac from the content and performs the following steps. Note: Alice may not have received Bob's last re-key (see Re-Keying) before sending the stanza. So Bob MUST ensure he uses the values of K-EA and K-MA that correspond to his KID that Alice sent him in this stanza (and the current value of e that Alice sent him previously).
Calculate the MAC for the encrypted data.
b_mac = HMAC(HASH, K-MA, m_final, CA)
Verify that b_mac and a_mac match. If they are not identical, the encrypted content has been tampered with and Bob MUST terminate the ESession by sending an error to Alice. Note: If Bob receives a stanza out-of-order, then the MACs will not match because the values of CA are not synchronized.
Decrypt m_final using the agreed algorithm, K-EA and CA. Note: CA MUST be incremented for each decrypted block, and if CA=2n-1 (where n is the number of bits per encryption block for the agreed encryption algorithm) then CA MUST be "incremented" to 1.
m_compressed = decrypt(K-EA, CA, m_final)
If compression was agreed upon, decompress m_compressed using the negotiated algorithm.
m = decompress(m_compressed)
Replace the <encrypted/> element in the serialized XML stanza with m and feed the stanza into an XML parser. If the parser returns an XML format error then Bob MUST terminate the ESession by sending an error to Alice.
Once an attacker has discovered an encryption key it could be used to decrypt all stanzas within a session, including stanzas that were intercepted before the key was discovered. To reduce the window of vulnerability, both Alice and Bob SHOULD change their values of x and y and re-exchange the encryption key as regularly as possible. They MUST also destroy all copies of keys as soon as they are no longer needed.
Note: Although most entities are capable of re-keying after each stanza, clients running in constrained runtime environments may require a few seconds to re-key. During Esession initiation these clients MAY negotiate the minimum number of stanzas to be exchanged between re-keys at the cost of a larger window of vulnerability. Entities MUST NOT initiate key re-exchanges more frequently than the agreed limit.
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:
Generate a secret random number x (where 22n-1 < x < p - 1, where n is the number of bits per encryption block for the agreed encryption algorithm)
Calculate e = gx mod p
Generate an opaque unique key identifier (KID) for e
Calculate K = dx mod p (the new shared secret)
Calculate K-EA, K-MA, K-EB, K-MB (see Generating Initial Session Keys)
To avoid extra stanzas, the new value of e SHOULD be sent to Bob along with an encrypted stanza. Note: Alice MUST NOT use the new K-EA and K-MA to encrypt this stanza or to calculate the MAC. However, she MUST use them when sending subsequent stanzas.
There is no need for Alice to provide a signature for e because the calculation of the MAC MUST include the new value of e (a_mac = HMAC(HASH, K-MA, m_final, CA, e), see Exchanging Stanzas).
Example 14. Alice Sends Re-Key Stanza
<message from='alice@example.org/pda' to='bob@example.com/laptop'>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data kid=' ** KID ** '> ** base64 encoded m_final ** </data>
<key kid=' ** KID ** '> ** base64 encoded value of new e ** </key>
<mac> ** base64 encoded a_mac ** </mac>
</encrypted>
</message>
Note: Bob may not receive the new key before he sends his next stanzas (they may cross in transit). So, before destroying her old values of K-EB and K-MB, Alice MUST wait until either she receives a stanza encrypted with the new key, or a reasonable time has passed (60 seconds should cover a network round-trip and calculations by a constrained client). Similarly she MUST wait before destroying her old value of x, in case Bob sends two stanzas before receiving Alice's new key (the first stanza might include a re-key).
After Bob receives a stanza with a new value of e and he has decrypted the stanza with the old value of K-EA, he MUST securely destroy all copies of K-EA and K-EB and perform the following calculations with the new value of e:
Calculate K = ey mod p
Calculate K-EA, K-MA, K-EB, K-MB (see Generating Initial Session Keys)
He MUST use these new values to encrypt and decrypt all subsequent stanzas.
Note: 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.
Either entity MAY publish old values of K-MA and/or K-MB as part of any encrypted stanza as long as it knows that all the stanzas that MAY use the old values have been received and validated. It MUST wait until it has received either a re-key or a stanza encrypted with a newer key from the other entity.
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.
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 kid=' ** KID ** '> ** base64 encoded m_final ** </data>
<mac> ** base64 encoded a_mac ** </mac>
<old> ** base64 encoded old MAC key ** </old>
<old> ** base64 encoded old MAC key ** </old>
</encrypted>
</message>
Entities MUST ignore any <old/> elements they receive.
Weak pseudo-random number generators (PRNG) enable successful attacks. Implementors MUST use a cryptographically strong PRNG to generate all random numbers (see RFC 1750 [28]).
After a key exchange an entity MUST NOT exchange a total of 232 encrypted blocks before it initiates a key re-exchange (see SSH Transport Layer Encryption Modes [29]).
Note: This policy also ensures the same key and counter values are never used to encrypt two different blocks using counter mode. This is necessary to prevent simple attacks.
The trust system outlined herein is based on Alice trusting that the public key presented by Bob is actually Bob's key. 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.
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 example, an implementation might save private keys to a file in cleartext! Implementors MUST take very great care when developing applications with secure technologies.
Note: The security parameter names mentioned below are related to secure shell; see SSH Transport Layer Encryption Modes for encryption algorithm details; see the IANA Secure Shell Protocol Parameters [30] for other names.
An implementation of ESession MUST support at least the following encryption algorithm:
The block length of an encryption algorithm's cipher SHOULD be at least 128 bits. Other compliant algorithm names include:
An implementation of ESession MUST support at least the following signing algorithms:
An implementation of ESession MUST support at least 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:
An implementation of ESession MUST support at least the following hash algorithms (sha1 and md5 are NOT RECOMMENDED):
An implementation of ESession MUST support the following compression algorithm:
It is RECOMMENDED that an implementation of ESession also support the following compression algorithm:
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [40].
Upon approval of this JEP, the Jabber Registrar [41] shall register the following namespaces:
The Jabber Registrar shall reserve the following fields within the scope of Data Forms used for ESession negotation:
Registry Submission
<form_type>
<name>http://jabber.org/protocol/esession</name>
<jep>JEP-0116</jep>
<desc>ESession negotiation forms</desc>
<field
var='modp'
type='list-single'
label='MODP group number'/>
<field
var='encryption_algorithms'
type='list-single'
label='Symmetric block cipher options'/>
<field
var='hash_algorithms'
type='list-single'
label='Hash algorithm options'/>
<field
var='compression'
type='list-single'
label='Compression algorithm options'/>
<field
var='stanzas'
type='list-multi'
label='Stanzas types to encrypt'/>
<field
var='max_rekey_freq'
type='text-single'
label='Minimum number of stanzas between key exchanges'/>
<field
var='publickey_ids'
type='list-multi'
label='Public key IDs'/>
<field
var='kid'
type='text-single'
label='Diffie-Hellman key ID'/>
<field
var='key'
type='text-single'
label='Diffie-Hellman key'/>
<field
var='sign'
type='list-multi'
label='Diffie-Hellman key signatures'/>
</form_type>
To follow.
Note: This section is highly preliminary and will probably be specified in a separate proposal.
Entities SHOULD publish their long-term public signature-verification keys through their own server using the disco#publish-info feature (as NOT SPECIFIED in JEP-0030).
Example 16. Entity Publishes Public Keys to Server
<iq type='set'
from='alice@example.org/pda'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/publickeys'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/publickeys</value>
</field>
<field var='types'>
<value>x509v3-sign-rsa</value>
<value>pgp-sign-dss</value>
<value>ssh-rsa</value>
<value>ssh-dss</value>
</field>
<field var='keys'>
<value> ** base64 encoded x509 certificate containing RSA public key ** </value>
<value> ** base64 encoded OpenPGP certificate containing DSS public key ** </value>
<value> ** base64 encoded unsigned RSA public key ** </value>
<value> ** base64 encoded unsigned DSS public key ** </value>
</field>
</x>
</query>
</iq>
Before initiating an ESession, if Bob does not already possess one of Alice's signature-verification keys, he SHOULD retrieve them from Alice's server.
Example 17. Bob Requests Public Keys from Alice's Server
<iq type='get'
from='bob@example.com/laptop'
to='alice@example.org'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/publickeys'/>
</iq>
Example 18. Server Returns Public Keys
<iq type='result'
from='alice@example.org'
to='bob@example.com/laptop'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/publickeys'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/publickeys</value>
</field>
<field var='types'>
<value>x509v3-sign-rsa</value>
<value>pgp-sign-dss</value>
<value>ssh-rsa</value>
<value>ssh-dss</value>
</field>
<field var='keys'>
<value> ** base64 encoded x509 certificate containing RSA public key ** </value>
<value> ** base64 encoded OpenPGP certificate containing DSS public key ** </value>
<value> ** base64 encoded unsigned RSA public key ** </value>
<value> ** base64 encoded unsigned DSS public key ** </value>
</field>
</x>
</query>
</iq>
Bob should examine all the public keys and identify which ones are acceptable (see Verifying Keys).
1. JEP-0027: Current Jabber OpenPGP Usage <http://www.jabber.org/jeps/jep-0027.html>.
2. RFC 3862: Common Presence and Instant Messaging (CPIM): Message Format <http://www.ietf.org/rfc/rfc3862.txt>.
3. RFC 3863: Presence Information Data Format (PIDF) <http://www.ietf.org/rfc/rfc3863.txt>.
4. RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) <http://www.ietf.org/rfc/rfc3923.txt>.
5. Off-the-Record Communication, or, Why Not to Use PGP <http://www.isaac.cs.berkeley.edu/~iang/pubs/otr-wpes.pdf>.
6. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.
7. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.
8. RFC 2246: The TLS Protocol Version 1.0 <http://www.ietf.org/rfc/rfc2246.txt>.
9. JEP-0096: File Transfer <http://www.jabber.org/jeps/jep-0096.html>.
10. JEP-0079: Advanced Message Processing <http://www.jabber.org/jeps/jep-0079.html>.
11. JEP-0131: Stanza Headers and Internet Metadata (SHIM) <http://www.jabber.org/jeps/jep-0131.html>.
12. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.
13. JEP-0060: Publish-Subscribe <http://www.jabber.org/jeps/jep-0060.html>.
14. SSH Protocol Architecture <http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-22.txt>. Work in progress.
15. SSH Transport Layer Protocol <http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-24.txt>. Work in progress.
16. Naturally, it is possible that Alice or Bob may retain cleartext versions of the exchanged communications; however, that threat is out of scope for this JEP.
17. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.
18. JEP-0115: Entity Capabilities <http://www.jabber.org/jeps/jep-0115.html>.
19. RFC 2631: Diffie-Hellman Key Agreement Method <http://www.ietf.org/rfc/rfc2631.txt>.
20. JEP-0155: Chat Session Negotiation <http://www.jabber.org/jeps/jep-0155.html>.
21. RFC 2409: The Internet Key Exchange (IKE) <http://www.ietf.org/rfc/rfc2409.txt>.
22. RFC 3526: More Modular Exponential (MODP) Diffie-Hellman Groups <http://www.ietf.org/rfc/rfc3526.txt>.
23. RFC 3548: The Base16, Base32, and Base64 Data Encodings <http://www.ietf.org/rfc/rfc3548.txt>.
24. RFC 3766: Determining Strengths For Public Keys Used For Exchanging Symmetric Keys <http://www.ietf.org/rfc/rfc3766.txt>.
25. K-MA is a hash of K-EA (not K) to ensure that if an attacker recovers the decryption key she will not be able to cryptographically convince anyone that it was not her who created the stanza.
26. Although counter mode encryption requires no padding, implementations MAY still disguise the length of m by appending a random number of white-space characters.
27. RFC 2104: HMAC: Keyed-Hashing for Message Authentication <http://www.ietf.org/rfc/rfc2104.txt>.
28. RFC 1750: Randomness Recommendations for Security <http://www.ietf.org/rfc/rfc1750.txt>.
29. SSH Transport Layer Encryption Modes <http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-04.txt>. Work in progress.
30. IANA registry of parameters related to secure shell <http://www.iana.org/assignments/ssh-parameters>.
31. Advanced Encryption Standard: Federal Information Processing Standards Publication 197 <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.
32. The Twofish Block Cipher <http://www.schneier.com/twofish.html>.
33. The Serpent Block Cipher <http://www.cl.cam.ac.uk/~rja14/serpent.html>.
34. RFC 2437: PKCS #1: RSA Cryptography Specifications Version 2.0 <http://www.ietf.org/rfc/rfc2437.txt>.
35. Digital Signature Standard: Federal Information Processing Standards Publication 186 <http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf>.
36. X.509 Authentication in SSH2 <http://www.ietf.org/internet-drafts/draft-ietf-secsh-x509-02.txt>. Work in progress.
37. Secure Hash Standard: Federal Information Processing Standards Publication 180-2 <http://csrc.nist.gov/publications/fips/fips180-2/fips186-2withchangenotice.pdf>.
38. The Whirlpool Hash Function <http://paginas.terra.com.br/informatica/paulobarreto/WhirlpoolPage.html>.
39. RFC 1950: ZLIB Compressed Data Format Specification version 3.3 <http://www.ietf.org/rfc/rfc1950.txt>.
40. 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/>.
41. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
END