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.9
Last Updated: 2005-11-29
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, RFC 2104, RFC 2409, RFC 3526, RFC 3548, xml-c14n, JEP-0004, JEP-0020, JEP-0030, JEP-0068, JEP-0079, JEP-0155, JEP-0163
Supersedes: None
Superseded By: None
Short Name: esession
Wiki Page: <http://wiki.jabber.org/index.php/Encrypted Sessions (JEP-0116)>
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 Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
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 conceptual model for this encrypted sessions or "ESessions" approach was inspired by "off-the-record" (OTR) communication, as implemented in the Gaim encryption plugin and described in Off-the-Record Communication [5].
As specified in RFC 3920 [6], XMPP is an XML streaming protocol that enables the near-real-time exchange of XML fragments between any two (or more) network endpoints. To date, the main application built on top of the core XML streaming layer is instant messaging (IM) and presence, the base extensions for which are specified in RFC 3921 [7]. There are three first-level elements of XML streams (<message/>, <presence/>, and <iq/>); each of these "XML stanza" types has different semantics, which can complicate the task of defining a generalized approach to end-to-end encryption for XMPP. In addition, XML stanzas can be extended (via properly-namespaced child elements) for a wide variety of functionality. The chosen approach should enable encryption of several complete XML elements rather than only parts thereof (e.g., only the XML character data of the message <body/> element as in JEP-0027).
XMPP is a session-oriented communication technology: normally, a client authenticates with a server and maintains a long-lived connection that defines the client's XMPP session. Such stream-level sessions are secured via channel encryption using Transport Level Security (RFC 2246 [8]), as specified in Section 5 of RFC 3920. However, there is no guarantee that all hops will implement or enforce channel encryption (or that intermediate routers are trustworthy), which makes end-to-end encryption desirable.
The session metaphor also applies to communication between endpoints: for instance, in IM applications, most instant messaging exchanges occur in bursts within limited time periods (e.g., two people may send a fairly large number of messages during a five-minute chat and then not exchange messages again for hours or even days). The XML stanzas exchanged during such a session may not be limited to <message/> stanzas; for instance, the session may be triggered by a change in one of the parties' presence status (e.g., changing from away to available) and the session may involve the exchange of <iq/> stanzas (e.g., to transfer a file as specified in File Transfer [9]). Endpoints may want to encrypt the stanzas they send to each other in such a way that the stanzas cannot be understood by untrusted mediating entities (such as servers) except to the extent required to understand the necessary routing information. (One complicating factor is that routing information may include not only the stanza's 'to', 'from', 'type, and 'id' attributes, but also Advanced Message Processing [10] extensions.)
The foregoing XMPP communications exist in the context of a one-to-one communication session between two entities. However, several forms of XMPP communication exist outside the context of one-to-one communication sessions:
Ideally, any technology for end-to-end encryption in XMPP could be extended to cover these scenarios as well as one-to-one communication sessions. However, both many-to-many sessions and one-to-many broadcast are deemed out of scope for this JEP. Offline communications are handled via a simple extension to the protocol for one-to-one sessions between two entities that are online simultaneously (see below).
Because XMPP is a session-oriented communication technology, encryption schemes that are appropriate for less dynamic technologies may not be appropriate for XMPP. XMPP, with its in-order delivery of XML stanzas, is able to take advantage of encryption approaches that are not feasible for less dynamic technologies. In particular, existing approaches to encryption of Internet communications have generally assumed that the "thing" to be encrypted has a stable identity or is best understood as a standalone object (e.g., a file or email message); the term "object encryption" well captures this assumption. Both JEP-0027 and RFC 3923 assume that XMPP communications are more like the exchange of email messages than they are like an interactive session -- while JEP-0027 uses "old-style" PGP object encryption and RFC 3923 uses "new-style" S/MIME object encryption, both specify the use of object encryption.
However, the session-oriented nature of XMPP may imply that the focus should be on "session encryption" rather than "object encryption". The paradigm for XMPP encryption may be something closer to the widely-deployed Secure Shell technology (see SSH Protocol Architecture [13] and SSH Transport Layer Protocol [14]) than to traditional encryption of files and standalone email messages.
Therefore, this JEP specifies a method for encrypted sessions ("ESessions") that takes advantage of the inherent possibilities and strengths of session encryption as opposed to object encryption. The basic concept is that of an encrypted session which acts as a secure tunnel between two endpoints. Once the tunnel is established, the content of all one-to-one XML stanzas exchanged between the endpoints will be encrypted and then transmitted within a "wrapper" protocol element.
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.
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.
Alice or Bob MUST be able to identify and reject any communications that are copies of their previous communications resent by another entity.
The encrypted communication MUST NOT be revealed even if long-lived keys are compromised 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). [15]
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.
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 implement in a relatively straightforward and interoperable fashion.
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.
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.
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.
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".
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".
Note: Implementors of ESessions may ignore this section since it is purely informative.
Authenticated key-exchange is the most challenging part of the design of any secure communication protocol. The ESessions key exchange essentially translates the SIGMA [17] [18] key-exchange protocol into the syntax of XMPP. This section provides an overview of SIGMA. The SIGMA approach underpins several standard key-exchange protocols including the Internet Key Exchange (IKE) protocol versions 1 and 2 (see RFC 2409 [19] and IKEv2 [20]).
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.
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 |
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)
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.
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)
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)
Note: Implementors of ESessions may ignore this section since it is purely informative.
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.
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 ESession parameter (see ESession Request) |
| 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 | The IDs of all the public keys that Alice can sign for |
* Offline negotiation only
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)
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)
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, pubKeysA} signsA = multi_sign(signKeysA, formA) store(NA, x1...xZ) 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) 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.
Before attempting to engage in an ESession with Bob, Alice SHOULD discover whether he supports this protocol, using either Service Discovery [21] or the presence-based profile of JEP-0030 specified in Entity Capabilities [22].
The normal course of events is for Alice to authenticate with her server, retrieve her roster (see RFC 3921), send initial presence to her server, and then receive presence information from all the contacts in her roster. If the presence information she receives from some contacts does not include capabilities data (per JEP-0115), Alice SHOULD then send a service discovery information ("disco#info") request to each of those contacts (in accordance with JEP-0030). Such initial service discovery stanzas MUST NOT be considered part of encrypted communication sessions for the purposes of this JEP, since they perform a "bootstrapping" function that is a prerequisite to encrypted communications. The disco#info request sent from Alice to Bob might look as follows:
Example 1. Alice Queries Bob for ESession Support via Disco
<iq type='get'
from='alice@example.org/pda'
to='bob@example.com/laptop'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
If Bob sends a disco#info reply and he supports the protocol defined herein, then he MUST include a service discovery feature variable of "http://jabber.org/protocol/esession".
Example 2. Bob Returns disco#info Data
<iq type='result'
from='bob@example.com/laptop'
to='alice@example.org/pda'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='client' type='pc'/>
...
<feature var='http://jabber.org/protocol/esession'/>
...
</query>
</iq>
The process for establishing a secure session over an insecure transport is essentially a negotiation of various ESession algorithms and other parameters, combined with a translation into XMPP syntax of the SIGMA approach to Diffie-Hellman (see RFC 2631 [23]) key agreement.
When Alice wishes to establish an ESession with Bob, Alice may choose between two different methods of performing the initial Diffie-Hellman key exchange, depending on whether Bob is online or not. Note: Alice MUST NOT initiate a new ESession with Bob if she already has one established with him.
If Alice believes Bob may be online then she SHOULD use the protocol specified in Chat Session Negotiation [24] to negotiate the ESession options and the keys.
In addition to the "accept" and "logging" fields specified in Chat Session Negotiation, Alice MUST specify each of the ESession options (see list below) that she is willing to use, in her order of preference (see Mandatory to Implement Technologies). Note: Alice SHOULD NOT include a "reason" field since Aunt Tillie may not be aware the ESession request is not encrypted.
Whether or not both entities MUST be connected securely to their servers (see Section 5 of RFC 3920)
The list of Modular Exponential (MODP) group numbers (as specified in RFC 2409 or RFC 3526 [25]) that MAY be used for Diffie-Hellman key exchange (valid group numbers include 1,2,3,4,5,14,15,16,17 and 18)
Symmetric block cipher algorithm names
Hash algorithm names
Signature algorithm names
Compression algorithm names
The list of stanza types that MAY be encrypted and decrypted
Whether or not the other entity MUST send the fingerprint (PKID) of its public signature-verification key instead of the full key
The minimum and maximum versions of this document that are supported
The minimum number of stanzas that MUST be exchanged before an entity MAY initiate a key re-exchange (1 - every stanza, 100 - every hundred stanzas). Note: This value MUST be less than 232 (see Re-Keying Limits)
Each MODP group has at least two well known constants: a large prime number p, and a generator g for a subgroup of GF(p). For each MODP group that Alice specifies she MUST perform the following computations to calculate her Diffie-Hellman keys (where n is the number of bits per cipher block for the block cipher algorithm with the largest block size out of those she specified):
Generate a secret random number x (where 22n-1 < x < p - 1)
Calculate e = gx mod p
Alice MUST send all her calculated values of e to Bob. She MUST also specify randomly generated Base64 encoded (in accordance with Section 3 of RFC 3548 [26]) value of NA (her ESession ID).
Example 3. Alice Requests an ESession
<message from='alice@example.org/pda' to='bob@example.com'>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x type='form' xmlns='jabber:x:data'>
<field type="hidden" var="FORM_TYPE">
<value>http://jabber.org/protocol/chatneg</value>
</field>
<field type="boolean" var="accept">
<value>1</value>
</field>
<field type="boolean" var="logging">
<value>1</value>
</field>
<field type="boolean" var="secure">
<value>0</value>
</field>
<field type="list-single" var="modp">
<option><value>5</value></option>
<option><value>14</value></option>
<option><value>2</value></option>
</field>
<field type="list-single" var="crypt_algs">
<option><value>aes256-ctr</value></option>
<option><value>twofish256-ctr</value></option>
<option><value>aes128-ctr</value></option>
</field>
<field type="list-single" var="hash_algs">
<option><value>whirlpool</value></option>
<option><value>sha256</value></option>
</field>
<field type="list-single" var="sign_algs">
<option><value>rsa</value></option>
<option><value>dsa</value></option>
</field>
<field type="list-single" var="compress">
<option><value>none</value></option>
</field>
<field type="list-multi" var="stanzas">
<option><value>message</value></option>
<option><value>iq</value></option>
<option><value>presence</value></option>
</field>
<field type="boolean" var="pk_hash">
<value>0</value>
</field>
<field type="list-single" var="ver">
<option><value>1.0</value></option>
<option><value>1.3</value></option>
</field>
<field type="text-single" var="rekey_freq">
<value>1</value>
</field>
<field var="my_nonce">
<value> ** Base64 encoded ESession ID ** </value>
</field>
<field var="keys">
<value> ** Base64 encoded value of e5 ** </value>
<value> ** Base64 encoded value of e14 ** </value>
<value> ** Base64 encoded value of e2 ** </value>
</field>
</x>
</feature>
<amp xmlns='http://jabber.org/protocol/amp' per-hop='true'>
<rule action='drop' condition='deliver' value='stored'/>
</amp>
</message>
If Bob does not support one or more of the options in each ESession field, then he SHOULD return a <feature-not-implemented/> error (but he MAY return no error if, for example, he does not want to reveal his presence to Alice for whatever reason):
Example 4. Bob Informs Alice that Her Options Are Not Supported
<message type='error'
from='bob@example.com/laptop'
to='alice@example.org/pda'>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
...
</feature>
<error type='cancel'>
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<unsupported-options xmlns='http://jabber.org/protocol/esession#error'/>
</error>
</message>
Either Bob or Alice MAY attempt to initiate a new ESession after any error during the negotiation process. However, both MUST consider the previous negotiation to have failed and MUST discard any information learned through the previous negotiation.
If Bob is unwilling to start an ESession, but he is ready to initiate a one-to-one chat session with Alice (see Chat Session Negotiation), then he SHOULD accept the Chat Session and terminate the ESession negotiation by not including a 'nonce' field in his response.
Example 5. Bob Accepts Chat Session
<message from='bob@example.com/laptop' to='alice@example.org/pda'>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x type='submit' xmlns='jabber:x:data'>
<field var="FORM_TYPE">
<value>http://jabber.org/protocol/chatneg</value>
</field>
<field var="accept"><value>1</value></field>
<field var="logging"><value>0</value></field>
<field var="secure"><value>0</value></field>
</x>
</feature>
</message>
If Bob supports one or more of each of Alice's ESession options and is willing to start an ESession with Alice, then he MUST select one of the options from each of the ESession fields he received from Alice including one hash algorithm ("HASH"), and one of the MODP groups and Alice's corresponding value of e (see RFC 3766 [27] or RFC 3526 for recommendations regarding balancing the sizes of symmetric cipher blocks and Diffie-Hellman moduli).
Each MODP group has at least two well known constants: a large prime number p, and a generator g for a subgroup of GF(p). Bob SHOULD return a <feature-not-implemented/> error unless: 1 < e < p - 1
Bob MUST then perform the following computations (where n is the number of bits per cipher block for the selected block cipher algorithm):
Generate a random number NB (his ESession ID)
Generate an n-bit random number CA (the block cipher counter for stanzas sent from Alice to Bob)
Set CB = CA XOR 2n-1 (where CB is the block 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
Calculate K = HASH(ey mod p) (the shared secret)
Bob MUST use the shared secret ("K") and the selected hash algorithm ("HASH") to generate two sets of three keys, one set for each direction of the ESession.
For stanzas that Alice will send to Bob, the keys are calculated as:
Encryption key KCA = HASH(K, 0)
Integrity key KMA = HASH(K, 2)
SIGMA key KSA = HASH(K, 4)
For stanzas that Bob will send to Alice the keys are calculated as:
Encryption key KCB = HASH(K, 1)
Integrity key KMB = HASH(K, 3)
SIGMA key KSB = HASH(K, 5)
Once the sets of keys have been calculated the value of K MUST be securely destroyed.
Note: As many bits of key data as are needed for each key MUST be taken from the least significant bits of the hash output. When negotiating a hash, entities MUST ensure that the hash output is no shorter than the required key data. For algorithms with variable-length keys the maximum length (up to the hash output length) SHOULD be used.
Bob MUST perform the following steps before he can prove his identity to Alice while protecting it from third parties.
Select pubKeyB, the public key Alice should use to authenticate his signature with the signature algorithm he selected ("SIGN"). Note: If the value of the 'pk_hash' field that Alice sent Bob was true then Bob SHOULD set pubKeyB to HASH(pubKeyB).
Set formB to the Normalized content of the reponse data form he will send back to Alice (including his responses for all the fields he received from Alice).
Bob MUST encapsulate the Base64 encoded values of CA and Alice's NA in two new 'counter' and 'nonce' fields and add them to formB. Note: The 'pk_hash' field specifies whether or not Alice MUST send the fingerprint (PKID) of her public signature-verification key instead of her full key. Note: The value of the 'rekey_freq' field MUST be less than 232 and greater than or equal to the value specified by Alice. Note: Bob MUST place his Base64 encoded values of NB and d in the 'my_nonce' and 'keys' fields. Bob MUST NOT return Alice's values of e.
Concatenate Alice's ESession ID, Bob's ESession ID, d, pubKeyB and formB, and calculate the HMAC (as defined in Section 2 of RFC 2104 [28]) of the resulting byte string using the selected hash algorithm ("HASH") and the key KSB.
macB = HMAC(HASH, KSB, {NA, NB, d, pubKeyB, formB})
Calculate signB, the signature of the HMAC result using his private signature key that corresponds to pubKeyB
signB = SIGN(signKeyB, macB)
Concatenate pubKeyB and signB and encrypt the resulting byte string with the agreed algorithm ("CIPHER") in counter mode (see Recommendation for Block Cipher Modes of Operation [29]), using the encryption key KCB and block counter CB. Note: CB MUST be incremented by 1 for each encrypted block or partial block (i.e. CB = (CB + 1) mod 2n, where n is the number of bits per cipher block for the agreed block cipher algorithm).
IDB = CIPHER(KCB, CB, {pubKeyB, signB})
Calculate the HMAC of the encrypted identity (IDB) and the value of Bob's block cipher counter CB before the encryption using the selected hash algorithm ("HASH") and the integrity key KMB.
MB = HMAC(HASH, KMB, CB, IDB)
If Bob prefers the 3-message ESession negotiation, where Alice's identity is protected from active attacks instead of his own, then he should encapsulate the Base64 encoded values of IDB and MB in data form fields ('identity' and 'mac'), and append the new fields to formB.
Bob responds to Alice by sending her formB.
Example 6. Bob Responds to Alice (3-Message Negotiation)
<message from='bob@example.com/laptop' to='alice@example.org/pda'>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x type='submit' xmlns='jabber:x:data'>
<field var="FORM_TYPE">
<value>http://jabber.org/protocol/chatneg</value>
</field>
<field var="accept"><value>1</value></field>
<field var="logging"><value>0</value></field>
<field var="secure"><value>0</value></field>
<field var="modp"><value>5</value></field>
<field var="crypt_algs"><value>aes256-ctr</value></field>
<field var="hash_algs"><value>sha256</value></field>
<field var="sign_algs"><value>rsa</value></field>
<field var="compress"><value>none</value></field>
<field var="stanzas"><value>message</value></field>
<field var="pk_hash"><value>1</value></field>
<field var="ver"><value>1.3</value></field>
<field var="rekey_freq"><value>50</value></field>
<field var="my_nonce">
<value> ** Base64 encoded ESession ID ** </value>
</field>
<field var="keys">
<value> ** Base64 encoded value of d ** </value>
</field>
<field var="nonce">
<value> ** Base64 encoded ESession ID ** </value>
</field>
<field var="counter">
<value> ** Base64 encoded block counter ** </value>
</field>
<field var="identity">
<value> ** Encrypted identity ** </value>
</field>
<field var="mac">
<value> ** Integrity of identity ** </value>
</field>
</x>
</feature>
</message>
Example 7. Bob Responds to Alice (4-Message Negotiation)
<message from='bob@example.com/laptop' to='alice@example.org/pda'>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x type='submit' xmlns='jabber:x:data'>
<field var="FORM_TYPE">
<value>http://jabber.org/protocol/chatneg</value>
</field>
<field var="accept"><value>1</value></field>
<field var="logging"><value>0</value></field>
<field var="secure"><value>0</value></field>
<field var="modp"><value>5</value></field>
<field var="crypt_algs"><value>aes256-ctr</value></field>
<field var="hash_algs"><value>sha256</value></field>
<field var="sign_algs"><value>rsa</value></field>
<field var="compress"><value>none</value></field>
<field var="stanzas"><value>message</value></field>
<field var="pk_hash"><value>1</value></field>
<field var="ver"><value>1.3</value></field>
<field var="rekey_freq"><value>50</value></field>
<field var="my_nonce">
<value> ** Base64 encoded ESession ID ** </value>
</field>
<field var="keys">
<value> ** Base64 encoded value of d ** </value>
</field>
<field var="nonce">
<value> ** Base64 encoded ESession ID ** </value>
</field>
<field var="counter">
<value> ** Base64 encoded block counter ** </value>
</field>
</x>
</feature>
</message>
After Alice receives Bob's response, she MUST use the value of d and the ESession options specified in Bob's response to perform the following steps (where p and g are the constants associated with the selected MODP group, HASH is the selected hash algorithm, and n is the number of bits per cipher block for the agreed block cipher algorithm):
Return a <feature-not-implemented/> error to Bob if she is not prepared to support any of the ESession options specified by Bob (if any of the options were not included in her initial ESession request)
Return a <feature-not-implemented/> error to Bob unless: 1 < d < p - 1
Set CB = CA XOR 2n-1 (where CB is the block counter for stanzas sent from Bob to Alice)
Select her values of x and e that correspond to the selected MODP group (from all the values of x and e she calculated previously)
Calculate K = HASH(dx mod p) (the shared secret)
Generate the session keys (KCA, KMA, KSA, KCB, KMB and KSB) in the same way as Bob did (see Generating Session Keys)
If Bob included 'identity' and 'mac' fields in his response then Alice MUST also perform the following steps:
Calculate the HMAC of the encrypted identity (IDB) and the value of Bob's block cipher counter using HASH and the integrity key KMB.
MB = HMAC(HASH, KMB, CB, IDB)
Return a <feature-not-implemented/> error to Bob unless the value of MB she calculated matches the one she received in the 'mac' field
Obtain pubKeyB and signB by decrypting IDB with the agreed symmetric block cipher algorithm ("DECIPHER") in counter mode, using the encryption key KCB and block counter CB. Note: CB MUST be incremented by 1 for each encrypted block or partial block (i.e. CB = (CB + 1) mod 2n, where n is the number of bits per cipher block for the agreed block cipher algorithm).
{pubKeyB, signB} = DECIPHER(KCB, CB, IDB)If the value of the 'pk_hash' field she sent to Bob in her ESession Request was true, then Alice SHOULD change the value of pubKeyB to be her copy of the public key whose HASH matches the value of pubKeyB that she received from Bob. Note: If she cannot find a copy of the public key then Alice MUST terminate the ESession. She MAY then request a new ESession with the 'pk_hash' field set to false.
Return a <feature-not-implemented/> error to Bob unless she can confirm (or has previously confirmed) that pubKeyB really is Bob's public key, for examples, via secure out-of-band communication, or through a third-party authority (see Verifying Keys).
Set the value of formB to be the Normalized content of the form she received from Bob without the 'identity' and 'mac' fields.
Concatenate Alice's ESession ID, Bob's ESession ID, d, pubKeyB and formB, and calculate the HMAC of the resulting byte string using HASH and the key KSB.
macB = HMAC(HASH, KSB, {NA, NB, d, pubKeyB, formB})
Return a <feature-not-implemented/> error to Bob unless she can use pubKeyB with the selected signature verification algorithm ("VERIFY") to confirm that signB is the signature of the HMAC result (see Signature Verification).
VERIFY(signB, pubKeyB, macB)
Alice MUST then prove her identity to Bob while protecting it from third parties. She MUST perform the steps equivalent to those Bob performed above (see Hiding Identity for a more detailed description). Alice's calculations are summarised below (pay attention to the order of NB and NA when calculating macA). Note: formA is the Normalized content of the ESession Request data form that she sent to Bob previously.
macA = HMAC(HASH, KSA, {NB, NA, e, pubKeyA, formA})
signA = SIGN(signKeyA, macA)
IDA = CIPHER(KCA, CA, {pubKeyA, signA})
MA = HMAC(HASH, KMA, CA, IDA)
Alice MUST send the Base64 encoded values of NB, IDA and MA to Bob. If Alice has already confirmed Bob's identity (i.e. if Bob included 'identity' and 'mac' fields in his response), then she MAY also send encrypted content (see Exchanging Stanzas) in the same stanza as the proof of her identity.
Example 8. Alice Sends Bob Her Identity
<message from='alice@example.org/pda' to='bob@example.com/laptop'>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x type='result' xmlns='jabber:x:data'>
<field var="FORM_TYPE"><value>http://jabber.org/protocol/chatneg</value></field>
<field var="nonce"><value> ** Base64 encoded ESession ID ** </value></field>
<field var="identity"><value> ** Encrypted identity ** </value></field>
<field var="mac"><value> ** Integrity of identity ** </value></field>
</x>
</feature>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data> ** Base64 encoded m_final ** </data>
<mac> ** Base64 encoded a_mac ** </mac>
</encrypted>
</message>
If Alice also includes a <terminate/> element (see ESession Termination) within the <encrypted/> element then the ESession is terminated immediately. Note: This special case, where a single stanza is encrypted and sent in isolation, is equivalent to object encryption (or object signing if no encryption is specified).
After receiving Alice's identity Bob MUST verify it by performing steps equivalent to those described in the section Verifying Bob's Identity above. Bob's calculations are summarised below (pay attention to the order of NB and NA when calculating macA). Note: formA is the Normalized content of the ESession Request data form (the first form) that Alice sent him. Note: If Bob sends an error to Alice then he SHOULD ignore any encrypted content he received in the stanza.
MA = HMAC(HASH, KMA, CA, IDA)
{pubKeyA, signA} = DECIPHER(KCA, CA, IDA)macA = HMAC(HASH, KSA, {NB, NA, e, pubKeyA, formA})
VERIFY(signA, pubKeyA, macA)
If Alice has already confirmed Bob's identity (i.e. if Bob included 'identity' and 'mac' fields in his response above), then the ESession negotiation is complete.
Otherwise, one more step is necessary. Bob MUST send Alice the Base64 encoded values of NA, IDB and MB that he calculated previously (see Hiding Identity). Note: He MAY also send encrypted content (see Exchanging Stanzas) in the same stanza.
Example 9. Bob Sends Alice His Identity
<message from='bob@example.com/laptop' to='alice@example.org/pda'>
<init xmlns='http://jabber.org/protocol/esession#init'>
<x type='result' xmlns='jabber:x:data'>
<field var="FORM_TYPE"><value>http://jabber.org/protocol/chatneg</value></field>
<field var="nonce"><value> ** Base64 encoded ESession ID ** </value></field>
<field var="identity"><value> ** Encrypted identity ** </value></field>
<field var="mac"><value> ** Integrity of identity ** </value></field>
</x>
</init>
</message>
After receiving Bob's identity Alice MUST verify it by performing steps described in the section Verifying Bob's Identity above. Note: If Alice sends an error to Bob then she SHOULD ignore any encrypted content she received in the stanza.
As described below, offline negotiation of an ESession is in essence a special case of 3-message online ESession negotiation. Alice MAY publish a set of ESession options just before she goes offline (see Offline ESessions Security Considerations) to allow entities that subscribe to her presence to initiate ESessions and send encrypted stanzas to her while she is offline. She MAY also publish another similar set of relatively long-lived [30] ESession options that any entity MAY use for the same purpose.
In order to publish either set of her offline ESession options Alice MUST create an options data form in exactly the same way as she would create an ESession Request data form except she MUST omit The 'accept' and 'pk_hash' fields. Note: The list of stanza types she is willing to decrypt MUST NOT include the value 'iq'.
Alice MUST store her value of NA (her ESession ID) and all her values of x (one for each MODP group) in a secure way, so that she can retrieve them when she comes back online (idealy even if that is using a different client and/or a different machine)
If Alice would not be able to decrypt stanzas if she came back online using a different client and/or a different machine then she SHOULD also encapsulate the resource of her client in a 'match_resource' field and append it to her options data form. In this case, the list of stanza types she is willing to decrypt MUST include only 'message'.
Alice MUST also append to the content of the form the list of the fingerprints (PKIDs) of all her public signature-verification keys that she can sign for in a 'pkids' field, and the corresponding list of signatures (see Signature Generation) of the content of the data form (excluding the 'signs' field).
Alice MUST publish the ESession options data form through her own server using Simplified Personal Publish-Subscribe [31].
Note: Version 0.1 of the SPPS protocol is Experimental, planned modifications will allow access to be limited to subscribers.
Example 10. Alice Publishes Her ESession Options for Her Subscribers
<iq type='set' from='alice@example.org/pda' id='es2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/esession#subscription'>
<item>
<x type='form' xmlns='jabber:x:data'>
<field type="hidden" var="FORM_TYPE">
<value>http://jabber.org/protocol/chatneg</value>
</field>
<field type="boolean" var="logging">
<value>1</value>
</field>
<field type="boolean" var="secure">
<value>0</value>
</field>
<field type="list-single" var="modp">
<option><value>5</value></option>
<option><value>14</value></option>
<option><value>2</value></option>
</field>
<field type="list-single" var="crypt_algs">
<option><value>aes256-ctr</value></option>
<option><value>twofish256-ctr</value></option>
<option><value>aes128-ctr</value></option>
</field>
<field type="list-single" var="hash_algs">
<option><value>whirlpool</value></option>
<option><value>sha256</value></option>
</field>
<field type="list-single" var="sign_algs">
<option><value>rsa</value></option>
<option><value>dsa</value></option>
</field>
<field type="list-single" var="compress">
<option><value>none</value></option>
</field>
<field type="list-multi" var="stanzas">
<option><value>message</value></option>
</field>
<field type="list-single" var="ver">
<option><value>1.0</value></option>
<option><value>1.3</value></option>
</field>
<field type="text-single" var="rekey_freq">
<value>1</value>
</field>
<field var="my_nonce">
<value> ** Base64 encoded ESession ID ** </value>
</field>
<field var="keys">
<value> ** Base64 encoded value of e5 ** </value>
<value> ** Base64 encoded value of e14 ** </value>
<value> ** Base64 encoded value of e2 ** </value>
</field>
<field var="match_resource">
<value>pda</value>
</field>
<field var="pkids">
<value> ** PKID ** </value>
<value> ** PKID ** </value>
</field>
<field var="signs">
<value> ** signature of form ** </value>
<value> ** signature of form ** </value>
</field>
</x>
</item>
</publish>
</pubsub>
</iq>
Alice MAY publish her ESession options for all entities using the same protocol except for the 'node' attribute of the <publish/> element:
Example 11. Alice Publishes Her ESession Options for All Entities
<iq type='set' from='alice@example.org/pda' id='es3'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/esession'>
...
</publish>
</pubsub>
</iq>
If Bob believes Alice is offline he SHOULD request her ESession options and her long-term public signature-verification keys (see Public Key Publication and Retrieval) from her server using Simplified Personal Publish-Subscribe.
Note: Version 0.1 of the SPPS protocol is Experimental, planned modifications will allow the persistence and retrieval of the last published item.
If Bob is subscribing to Alice's presence he MUST request her ESession Options exclusively for subscribers.
Example 12. Bob asks Alice's Server for her ESession Options (Subscribers)
<iq type='get'
from='bob@example.com/laptop'
to='alice@example.org'
id='es4'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<get node='http://jabber.org/protocol/esession#subscription'/>
</pubsub>
</iq>
If Bob is not subscribing to Alice's presence (or if Alice has no ESession options exclusively for subscribers) he MUST use the following request instead.
Example 13. Bob asks Alice's Server for her ESession Options (All Entities)
<iq type='get'
from='bob@example.com/laptop'
to='alice@example.org'
id='es4'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<get node='http://jabber.org/protocol/esession'/>
</pubsub>
</iq>
If, after receiving Alice's public keys and ESession options, Bob is unable to verify any of Alice's signatures of her offline options data form (see Signature Verification) then he MAY decide to proceed no further, since he cannot be sure who will be able to decrypt his stanzas.
If Bob does not support one or more of the options in each Alice's ESession fields, then he MUST NOT send encrypted stanzas to her while she is offline.
Bob MUST now continue as if Alice had requested an online ESession, performing the steps described in three of the online negotiation sections:
Diffie-Hellman Preparation (Bob) Note: If the value of e he selected is not valid, Bob SHOULD terminate the ESession without sending an error.
Hiding Identity Note: Since Bob did not receive a 'pk_hash' field, he MUST assume its value is false. Bob SHOULD NOT include a 'pk_hash' field in formB since Alice has already proved her identity.
As with 3-message ESession negotiation, Bob should encapsulate the Base64 encoded values of IDB and MB in data form fields ('identity' and 'mac'), and append the new fields to formB.
Bob MAY also send encrypted content (see the Exchanging Stanzas section of this document) in the same stanza. Note: If he also includes a <terminate/> element (see ESession Termination) within the <encrypted/> element then the ESession is terminated immediately. This special case, where a single stanza is encrypted and sent in isolation, is equivalent to object encryption (or object signing if no encryption is specified).
If Alice included a 'match_resource' field in her ESession options, then Bob MUST address all the stanzas he sends within the offline ESession to the specified resource and use the Advanced Message Processing protocol to ensure that they are not delivered to any other resource.
After sending formB to Alice, Bob can assume that the ESession negotiation is complete.
Example 14. Bob Establishes an ESession Without Negotiation
<message from='bob@example.com/laptop' to='alice@example.org/pda' type='chat'>
<init xmlns='http://jabber.org/protocol/esession#init'>
<x type='submit' xmlns='jabber:x:data'>
<field var="FORM_TYPE">
<value>http://jabber.org/protocol/chatneg</value>
</field>
<field var="logging"><value>0</value></field>
<field var="secure"><value>0</value></field>
<field var="modp"><value>5</value></field>
<field var="crypt_algs"><value>aes256-ctr</value></field>
<field var="hash_algs"><value>sha256</value></field>
<field var="sign_algs"><value>rsa</value></field>
<field var="compress"><value>none</value></field>
<field var="stanzas"><value>message</value></field>
<field var="ver"><value>1.3</value></field>
<field var="rekey_freq"><value>50</value></field>
<field var="my_nonce">
<value> ** Base64 encoded ESession ID ** </value>
</field>
<field var="keys">
<value> ** Base64 encoded value of d ** </value>
</field>
<field var="nonce">
<value> ** Base64 encoded ESession ID ** </value>
</field>
<field var="counter">
<value> ** Base64 encoded block counter ** </value>
</field>
<field var="identity">
<value> ** Encrypted identity ** </value>
</field>
<field var="mac">
<value> ** Integrity of identity ** </value>
</field>
</x>
</init>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data> ** Base64 encoded m_final ** </data>
<mac> ** Base64 encoded a_mac ** </mac>
</encrypted>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='??????' condition='match-resource' value='exact'/>
</amp>
</message>
When Alice comes online she MUST perform the following steps:
Ensure she is no longer publishing offline ESession options exclusively for entities that are subscribing to her presence.
Example 15. Alice Stops Publishing Her ESession Options
<iq type='set' from='alice@example.org/pda' id='es5'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/esession#subscription'>
<item/>
</publish>
</pubsub>
</iq>
Retrieve any values of NA and x (one for each MODP group for each NA) that she stored before going offline, and destroy in a secure way any persistently stored copies that correspond to ESession options exclusively for subscribers.
When Alice receives an offline ESession request stanza from Bob then she MUST perform the following steps:
Select her value of x that corresponds to the 'nonce' and 'modp' fields she received from Bob. [32]
Confirm that she has not already received a key exchange stanza from Bob with the same value of d or NB ('my_nonce' field) since she published her ESession options (see Replay Attacks). If the options were for subscribers, that means since she came online.
Alice MUST now continue as if Bob had responded to her online ESession request, performing the steps described in two of the online negotiation sections:
Diffie-Hellman Preparation (Alice) Note: If she is not prepared to support any of the ESession options specified by Bob, or if the value of d she selected is not valid, then Alice SHOULD terminate the ESession without sending an error.
Verifying Bob's Identity Note: Since Alice did not send a 'pk_hash' field to Bob, she MUST assume its value is false. If the value of MB she calculated does not match the one she received, or if she cannot confirm that pubKeyB really is Bob's public key, or if she cannot confirm that signB is the signature of the HMAC result, then Alice SHOULD terminate the ESession without sending an error.
Once ESession negotiation is complete, Alice and Bob MUST exchange only encrypted forms of the one-to-one stanza types they agreed upon (e.g., <message/> and <iq/> stanzas).
Whenever Alice wants to send Bob an encrypted stanza she MUST only encrypt the XML content that would normally be ignored by the intermediate servers. She MUST NOT encrypt stanza wrapper elements or Advanced Message Processing elements.
If this is an offline ESession then Alice SHOULD include a 'Created' SHIM header in the encrypted content. Bob SHOULD trust this header and ignore the unencrypted Delayed Delivery [33] element inserted by his server.
Example 16. Unencrypted Stanza
<message from='alice@example.org/pda'
to='bob@example.com/laptop'
type='chat'>
<body>Hello, Bob!</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='error' condition='match-resource' value='exact'/>
</amp>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='Created'>2005-02-10T03:01:52Z</header>
</headers>
<active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
Example 17. XML Content to be Encrypted
<body>Hello, Bob!</body> <headers xmlns='http://jabber.org/protocol/shim'> <header name='Created'>2005-02-10T03:01:52Z</header> </headers> <active xmlns='http://jabber.org/protocol/chatstates'/>
Alice MUST perform the following steps to encrypt the XML content. Note: if there is no XML content to be encrypted (e.g. if this is an empty Re-Keying or Termination stanza), then CA MUST be incremented by 1 (see below), and only the last two steps (normalization and MAC calculation) should be performed.
Serialize the XML content she wishes to send into an array of UTF-8 bytes, m. [34]
Compress m using the negotiated algorithm. If a compression algorithm other than 'none' was agreed, the compression context is typically initialized after key exchange and passed from one stanza to the next, with only a partial flush at the end of each stanza. [35]
m_compressed = compress(m)
Encrypt the data with the agreed algorithm in counter mode, using the encryption key KCA. Note: CA MUST be incremented by 1 for each encrypted block or partial block (i.e. CA = (CA + 1) mod 2n, where n is the number of bits per cipher block for the agreed block cipher algorithm). Note: if the block cipher algorithm 'none' was agreed (see Unencrypted ESessions) then encryption MUST NOT be performed and CA MUST be incremented by 1 (for replay protection).
m_final = encrypt(KCA, CA, m_compressed)
Alice MUST now create the Normalized XML content of the <encrypted/> XML element. If there is encrypted XML content, the XML MUST include the Base64 encoded value of m_final wrapped in a <data/> element. Note: the <encrypted/> element MAY also contain one <terminate/> element (see Termination), one <key/> element and one or more <old/> elements (see Re-Keying).
m_content = '<data> ** Base64 encoded m_final ** </data>'
The XML content and the value of Alice's block cipher counter CA before the data was encrypted, are now processed through the HMAC algorithm, along with the agreed hash algorithm ("HASH") and the integrity key KMA.
a_mac = HMAC(HASH, KMA, m_content, CA)
Before sending the stanza to Bob, Alice MUST wrap m_content and the Base64 encoded value of a_mac (wrapped in a <mac/> element) inside an <encrypted/> element and insert it into the stanza in place of the original content. There MUST NOT be more than one <encrypted/> element per stanza.
Example 18. Message Stanza with Encrypted Content
<message from='alice@example.org/pda'
to='bob@example.com/laptop'
type='chat'>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data> ** Base64 encoded m_final ** </data>
<mac> ** Base64 encoded a_mac ** </mac>
</encrypted>
<amp xmlns='http://jabber.org/protocol/amp' per-hop='true'>
<rule action='error' condition='match-resource' value='exact'/>
</amp>
</message>
When Bob receives the stanza from Alice, he extracts and Base64 decodes the values of m_final and a_mac from the content and performs the following steps.
Remove the <mac/> element from the <encrypted/> element and Normalize the remaining XML content. Calculate the Message Authentication Code (MAC) for the content.
b_mac = HMAC(HASH, KMA, m_content, CA)
Verify that b_mac and a_mac match. If they are not identical, the content has been tampered with and Bob MUST terminate the ESession, he MAY send a <not-acceptable/> error to Alice. [36]
Decrypt m_final using the agreed algorithm, KCA and CA. Note: CA MUST be incremented by 1 for each decrypted block (see Encryption). Note: if the block cipher algorithm 'none' was agreed decryption MUST NOT be performed and CA MUST be incremented by 1.
m_compressed = decrypt(KCA, CA, m_final)
Decompress m_compressed using the negotiated algorithm (usually 'none').
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, he MAY send a <not-acceptable/> error to Alice. [37]
Once an attacker has discovered an encryption key it could be used to decrypt all stanzas within a session, including stanzas that were intercepted before the key was discovered. To reduce the window of vulnerability, both Alice and Bob SHOULD change their values of x and y and re-exchange the encryption key as regularly as possible. They MUST also destroy all copies of keys as soon as they are no longer needed.
Note: Although most entities are capable of re-keying after each stanza, clients running in constrained runtime environments may require a few seconds to re-key. During ESession negotiation these clients MAY negotiate the minimum number of stanzas to be exchanged between re-keys at the cost of a larger window of vulnerability. Entities MUST NOT initiate key re-exchanges more frequently than the agreed limit.
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 cipher block for the agreed block cipher algorithm)
Calculate e = gx mod p
Calculate K = dx mod p (the new shared secret)
Calculate KCA, KMA, KCB, KMB from K (see Generating Session Keys)
To avoid extra stanzas, the new value of e SHOULD be sent to Bob along with an encrypted stanza. Note: Alice MUST NOT use the new KCA and KMA to encrypt this stanza or to calculate the MAC. However, she MUST use them when sending subsequent stanzas.
Note: There is no need for Alice to provide a signature because the calculation of the MAC includes the new value of e, see Exchanging Stanzas).
Example 19. Alice Sends Re-Key Stanza
<message from='alice@example.org/pda' to='bob@example.com/laptop'>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data> ** Base64 encoded m_final ** </data>
<key> ** Base64 encoded value of new e ** </key>
<mac> ** Base64 encoded a_mac ** </mac>
</encrypted>
</message>
Note: Bob may not receive the new key before he sends his next stanzas (they may cross in transit). So, before destroying her old values of KCB and KMB, Alice MUST wait until either she receives a stanza encrypted with the new key, or a reasonable time has passed (60 seconds should cover a network round-trip and calculations by a constrained client). Similarly she MUST wait before destroying her old value of x, in case Bob sends two stanzas before receiving Alice's new key (the first stanza might include a re-key).
After Bob receives a stanza with a new value of e and confirmed it is greater than one, and he has decrypted the stanza with the old value of KCA, he MUST securely destroy all copies of KCA and KCB and perform the following calculations with the new value of e:
Calculate K = ey mod p
Calculate KCA, KMA, KCB, KMB from K (see Generating Session Keys)
He MUST use these new values to encrypt and decrypt all subsequent stanzas. [38]
The next time Bob sends Alice a stanza he MUST specify the number of rekeys he has received from her since he sent her his last stanza. He does that by setting the 'rekeys' attribute of the <data/> element. Note: The default value of the 'rekeys' attribute is zero.
Example 20. Bob's First Stanza After Receiving a Re-Key
<message from='bob@example.com/laptop' to='alice@example.org/pda'>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data rekeys='1'> ** Base64 encoded m_final ** </data>
<mac> ** Base64 encoded b_mac ** </mac>
</encrypted>
</message>
When Alice receives the stanza from Bob she MUST use the 'rekeys' attribute to decide which of her values of KCB and KMB (or x) she should use to decrypt the stanza - otherwise she would not know if Bob received her rekey(s) before he sent the stanza. Once she is sure Bob has received her rekey(s) she MUST discard all her older values of KCB, KMB and x.
Once the expired MAC keys have been published, anyone could create valid arbitrary stanzas with them. This prevents anyone being able to prove the authenticity of a transcript of the ESession in the future.
Either entity MAY publish old values of KMA and/or KMB within any encrypted stanza as long as it knows that all the stanzas that MAY use the old values have been received and validated. Note: A 'man-in-the-middle' could delay the delivery of stanzas indefinitely. So, before Alice publishes KMA (and KMB), she MUST wait until she has both sent a re-key to Bob and received a stanza from Bob encrypted with her new key. (She MAY also publish KMB after she has received a re-key from Bob.)
Example 21. Publishing Expired MAC Keys
<message from='alice@example.org/pda' to='bob@example.com/laptop'>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data> ** Base64 encoded m_final ** </data>
<old> ** Base64 encoded old MAC key ** </old>
<old> ** Base64 encoded old MAC key ** </old>
<mac> ** Base64 encoded a_mac ** </mac>
</encrypted>
</message>
Entities SHOULD ignore any <old/> elements they receive.
Either entity MAY terminate an ESession at any time. Entities MUST terminate all open ESessions before they go offline. To terminate an ESession Alice MUST send a stanza to Bob including a <terminate/> element with content "1" [39]. Note: She MAY publish old values of KMA and/or KMB within her termination stanza as long as she is sure all the stanzas that MAY use the old values have been received and validated (see Publishing Old MAC Values). She MUST then securely destroy all keys associated with the ESession.
Example 22. Alice Terminates an ESession
<message from='alice@example.org/pda' to='bob@example.com/laptop'>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<terminate>1</terminate>
<old> ** Base64 encoded old MAC key ** </old>
<mac> ** Base64 encoded a_mac ** </mac>
</encrypted>
</message>
When Bob receives a termination stanza he MUST verify the MAC (to be sure he received all the stanzas Alice sent him during the ESession) and, if the stanza was sent to him while he was online, immediately send a termination stanza back to Alice. Note: He MAY publish any old values of KMA or KMB within the termination stanza. He MUST then securely destroy all keys associated with the ESession.
Example 23. Bob Confirms ESession Termination
<message from='alice@example.org/pda' to='bob@example.com/laptop'>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<terminate>1</terminate>
<old> ** Base64 encoded old MAC key ** </old>
<mac> ** Base64 encoded b_mac ** </mac>
</encrypted>
</message>
When Alice receives the stanza she MUST verify the MAC to be sure she received all the stanzas Bob sent her during the ESession. Once an entity has sent a termination stanza it MUST NOT send another stanza within the ESession.
Note: If Alice notices that Bob comes online during her offline ESession with him then she MUST terminate the ESession immediately. If required she may then negotiate a new (more secure) online ESession.
Note: Bob MUST NOT send encrypted content within an ESession started by Alice. If Alice is conducting an offline ESession with Bob when he is online (e.g., if she is not subscribing to his presence), then if Bob wants to send a stanza to Alice, he MUST terminate the offline ESession and start a new online ESession first.
Before the signature or MAC of a block of XML is generated or verified, all character data between all elements MUST be removed and the XML MUST be converted to canonical form (see Canonical XML [40]).
All the XML this protocol requires to be signed or MACed is very simple, so in this case, canonicalization SHOULD only require the following changes:
Implementations MAY conceivably also need to make the following changes. Note: Empty elements and special characters SHOULD NOT appear in the signed or MACed XML specified in this protocol.
Before the signature or MAC of a block of XML is generated or verified, the agreed hash algorithm MUST be used to generate the hash of the normalized XML.
m_hash = HASH(m_content)
The signature generation depends on the type of private key being used.
The signature formats are the same for all public key formats. All integers are stored in big-endian byte order.
Base64 encoding of the signature_rsa multiprecision integer (without any header or length prefix).
Base64 encoding of the following structure:
The signature verification depends on the type of public key being used.
The rsa_modulus and rsa_public_exponent multiprecision integers are extracted from the other entity's authenticated public key. The signature_rsa multiprecision integer is the signature received from the other entity.
boolean = rsa_verify(signature_rsa, m_hash, hashOID, rsa_modulus, rsa_public_exponent)
The dsa_p, dsa_q, dsa_g and dsa_y multiprecision integers are extracted from the other entity's authenticated public key. The sig_dsa_r and sig_dsa_s multiprecision integers are the signature received from the other entity.
boolean = dsa_verify(sig_dsa_r, sig_dsa_s, m_hash, dsa_p, dsa_q, dsa_g, dsa_y)
Weak pseudo-random number generators (PRNG) enable successful attacks. Implementors MUST use a cryptographically strong PRNG to generate all random numbers (see RFC 1750 [43]).
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 [44]). Note: This limitation also ensures the same key and counter values are never used to encrypt two different blocks using counter mode (thus preventing simple attacks).
In order to reduce the Perfect Forward Secrecy window of vulnerability, after an extended period of activity, entities SHOULD either re-key or terminate the ESession.
The trust system outlined in this document is based on Alice trusting that the public key presented by Bob is actually Bob's key (and vice versa). Determining this trust may be done in a variety of ways depending on the entities' support for different public key (certificate) formats, signing algorithms and signing authorities. For instance, if Bob publishes a PGP/GPG public key, Alice MAY verify that his key is signed by another key that she knows to be good. Or, if Bob provides an X.509 certificate, she MAY check that his key has been signed by a Certificate Authority that she trusts.
When trust cannot be achieved automatically, methods that are not transparent to the users may be employed. For example, Bob could communicate the SHA-256 fingerprint of his public key to Alice via secure out-of-band communication (e.g. face-to-face). This would enable Alice to confirm that the public key she receives in-band is valid. Note however that very few people bother to verify fingerprints in this way. So this method is exceptionally vulnerable to 'man-in-the-middle' attacks. In order to reduce the window of vulnerability, an entity SHOULD remember the fingerprints of all user-validated public keys and alert the user in the future if ever the fingerprint(s) it stored for an entity do not match any of the received public keys.
Alternatively Alice and Bob could agree a shared secret via secure out-of-band communication, Bob could then use it to create an HMAC of his public key that only Alice could verify.
Note: If no keys are acceptable to Alice (because Alice has never verified any of the keys, and because either the keys are not signed, or Alice does not support the signature algorithms of the keys, or she cannot parse the certificate formats, or she does not recognise the authorities that signed the keys) then, although the ESession can still be encrypted, she cannot be sure she is communicating with Bob.
The block cipher counters maintained implicitly by Alice and Bob (CA and CB) prevent stanzas being replayed within any ESession. They ensure that the MAC will be different for all stanzas, even if the HMAC key and the content of the stanza are identical.
Alice and Bob MUST ensure that the value of e or d they provide when negotiating each online ESession is unique. This prevents complete online ESessions being replayed.
Since Alice supplies the same set of values of e for all offline ESessions, to prevent complete offline ESessions being replayed to her, she MUST take care to securely store new values (or destroy existing values) of NA and x for subscribers whenever she goes offline (see Publishing ESession Options). Also, when Alice comes online again, she MUST remember all the values of d he receives in offline ESession negotiation stanzas, and reject any offline ESessions that specify a value of d she has already received (see Accepting an Offline ESession).
Note: If Alice publishes ESession options for non-subscribers, and if she does not update them whenever she comes online then, until she updates the options, she MUST save all the values of d she receives to secure persistent storage (along with the values of NA and x).
Alice MAY decide not to support Offline ESessions since they are significantly less secure than online ESessions. The Perfect Forward Secrecy window of vulnerability is much longer. More seriously, Alice MUST store her private Diffie-Hellman keys, x1...xZ, to local disk or to a server (perhaps symmetrically encrypted with a password). It is really hard to securely erase something from a disk.
Note: If Alice does not support Offline ESessions then, while she is offline, Bob, or Aunt Tillie, will probably send her completely unprotected messages!
Organisations with full disclosure policies may require entities to disable encryption to enable the logging of all messages on their server. Unencrypted ESessions meet all the Security Requirements except for Confidentiality. This enables Alice to use the 'secure' ESession option to confirm securely with Bob that both client-server connections are secure.
If either entity stores a (re-encrypted) transcript of an ESession for future consultation then the Perfect Forward Secrecy offered by this protocol is lost. If the negotiated value of the 'logging' Chat Session Negotiation field is false the entities SHOULD NOT store any part of the ESession content (not even in encrypted form).
Cryptography plays only a small part in an entity's security. Even if it implements this protocol perfectly it may still be vulnerable to other attacks. For examples, an implementation might store ESession keys on swap space or save private keys to a file in cleartext! Implementors MUST take very great care when developing applications with secure technologies.
An implementation of ESession MUST support the Diffie-Hellman Key Agreement and HMAC algorithms. Note: The parameter names mentioned below are related to secure shell; see SSH Transport Layer Encryption Modes for block cipher algorithm details; see the IANA Secure Shell Protocol Parameters Registry [45] for other names.
An implementation of ESession MUST support at least the following block cipher algorithm:
The block length of an block cipher algorithm's cipher SHOULD be at least 128 bits. An implementation of ESession MAY also support the following block cipher algorithms:
An implementation of ESession MUST support at least the following signing algorithm:
An implementation of ESession SHOULD also support at least the following signing algorithm:
An implementation of ESession MUST support the following public key formats:
An implementation of ESession SHOULD also support at least the following public key formats:
An implementation of ESession MAY also support the following public key formats:
An implementation of ESession MUST support the following hash algorithm:
An implementation of ESession SHOULD also support at least the following hash algorithm (sha1 and md5 are NOT RECOMMENDED):
An implementation of ESession MUST support the following compression algorithm:
Support for other algorithms is NOT RECOMMENDED since compression partially defeats the Repudiability requirement of this JEP by making it more difficult for a third party (with some knowledge of the plaintext) to modify a transcript of an encrypted session in a meaningful way. However, encrypted content is pseudo-random and cannot be compressed, so, in those cases where bandwidth is severely constrained, an implementation of ESession MAY support the following algorithms to compress content before it is encrypted:
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [54].
Upon approval of this JEP, the Jabber Registrar [55] shall register the following namespaces:
Field Standardization for Data Forms [56] defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. The following fields shall be registered for use in both Encrypted Sessions and Chat Session Negotiation:
Registry Submission
<form_type>
<name>http://jabber.org/protocol/esession</name>
<jep>JEP-0116</jep>
<desc>ESession negotiation forms</desc>
<field
var='match_resource'
type='text-single'
label='Target resource for offline ESessions'/>
<field
var='secure'
type='boolean'
label='Require encrypted client-server streams'/>
<field
var='modp'
type='list-single'
label='MODP group number'/>
<field
var='crypt_algs'
type='list-single'
label='Symmetric block cipher options'/>
<field
var='hash_algs'
type='list-single'
label='Hash algorithm options'/>
<field
var='sign_algs'
type='list-single'
label='Signature algorithm options'/>
<field
var='compress'
type='list-single'
label='Compression algorithm options'/>
<field
var='stanzas'
type='list-multi'
label='Stanzas types to encrypt'/>
<field
var='pk_hash'
type='boolean'
label='Respond with public key fingerprint'/>
<field
var='ver'
type='list-single'
label='Supported versions of JEP-0116'/>
<field
var='rekey_freq'
type='text-single'
label='Minimum number of stanzas between key exchanges'/>
<field
var='keys'
type='hidden'
label='Diffie-Hellman keys'/>
<field
var='my_nonce'
type='hidden'
label='ESession ID of Sender'/>
<field
var='nonce'
type='hidden'
label='ESession ID of Receiver'/>
<field
var='counter'
type='hidden'
label='Initial block counter'/>
<field
var='pkids'
type='list-single'
label='Public key IDs'/>
<field
var='signs'
type='list-single'
label='Data form signatures'/>
</form_type>
<form_type>
<name>http://jabber.org/protocol/chatneg</name>
<jep>JEP-0155</jep>
...
</form_type>
To follow.
The authors would like to thank Ian Goldberg for the time he spent reviewing this protocol and for his invaluable suggestions and comments.
Note: This section is depricated and will be specified in a separate proposal before this document reaches draft status.
Entities SHOULD publish their long-term public signature-verification keys to all entities through their own server using SPPS.
Example 24. Entity Publishes Public Keys to Server
<iq type='set' from='alice@example.org/pda' id='dp1'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/publickeys'>
<x type='submit' xmlns='jabber:x:data'>
<field var='FORM_TYPE'>
<value>http://jabber.org/protocol/publickeys</value>
</field>
<field var='types'>
<value>x509v3-sign-rsa</value>
<value>pgp-sign-dss</value>
<value>ssh-rsa</value>
<value>ssh-dss</value>
</field>
<field var='keys'>
<value> ** Base64 encoded x509 certificate containing RSA public key ** </value>
<value> ** Base64 encoded OpenPGP certificate containing DSS public key ** </value>
<value> ** Base64 encoded unsigned RSA public key ** </value>
<value> ** Base64 encoded unsigned DSS public key ** </value>
</field>
</x>
</query>
</iq>
Before initiating an ESession, if Bob does not already possess one of Alice's signature-verification keys, he SHOULD retrieve them from Alice's server.
Example 25. Bob Requests Public Keys from Alice's Server
<iq type='get'
from='bob@example.com/laptop'
to='alice@example.org'
id='dp2'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/publickeys'/>
</iq>
Example 26. Server Returns Public Keys
<iq type='result'
from='alice@example.org'
to='bob@example.com/laptop'
id='dp2'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/publickeys'>
<x type='result' xmlns='jabber:x:data'>
<field var='FORM_TYPE'>
<value>http://jabber.org/protocol/publickeys</value>
</field>
<field var='types'>
<value>x509v3-sign-rsa</value>
<value>pgp-sign-dss</value>
<value>ssh-rsa</value>
<value>ssh-dss</value>
</field>
<field var='keys'>
<value> ** Base64 encoded x509 certificate containing RSA public key ** </value>
<value> ** Base64 encoded OpenPGP certificate containing DSS public key ** </value>
<value> ** Base64 encoded unsigned RSA public key ** </value>
<value> ** Base64 encoded unsigned DSS public key ** </value>
</field>
</x>
</query>
</iq>
Bob should examine all the public keys and identify which ones are acceptable (see Verifying Keys).
1. JEP-0027: Current Jabber OpenPGP Usage <http://www.jabber.org/jeps/jep-0027.html>.
2. RFC 3862: Common Presence and Instant Messaging (CPIM): Message Format <http://www.ietf.org/rfc/rfc3862.txt>.
3. RFC 3863: Presence Information Data Format (PIDF) <http://www.ietf.org/rfc/rfc3863.txt>.
4. RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) <http://www.ietf.org/rfc/rfc3923.txt>.
5. Off-the-Record Communication, or, Why Not to Use PGP <http://www.isaac.cs.berkeley.edu/~iang/pubs/otr-wpes.pdf>.
6. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.
7. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.
8. RFC 2246: The TLS Protocol Version 1.0 <http://www.ietf.org/rfc/rfc2246.txt>.
9. JEP-0096: File Transfer <http://www.jabber.org/jeps/jep-0096.html>.
10. JEP-0079: Advanced Message Processing <http://www.jabber.org/jeps/jep-0079.html>.
11. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.
12. JEP-0060: Publish-Subscribe <http://www.jabber.org/jeps/jep-0060.html>.
13. SSH Protocol Architecture <http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-22.txt>. Work in progress.
14. SSH Transport Layer Protocol <http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-24.txt>. Work in progress.
15. The reliable association between an entity and its public keys is beyond the scope of this JEP.
16. Naturally, it is possible that Alice or Bob may retain cleartext versions of the exchanged communications; however, that threat is out of scope for this JEP.
17. 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>.
18. Like RFC 2409, this protocol uses variant (ii), as described in Secion 5.4 of the SIGMA paper.
19. RFC 2409: The Internet Key Exchange (IKE) <http://www.ietf.org/rfc/rfc2409.txt>.
20. Internet Key Exchange (IKEv2) Protocol <http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-17.txt>.
21. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.
22. JEP-0115: Entity Capabilities <http://www.jabber.org/jeps/jep-0115.html>.
23. RFC 2631: Diffie-Hellman Key Agreement Method <http://www.ietf.org/rfc/rfc2631.txt>.
24. JEP-0155: Chat Session Negotiation <http://www.jabber.org/jeps/jep-0155.html>.
25. RFC 3526: More Modular Exponential (MODP) Diffie-Hellman Groups <http://www.ietf.org/rfc/rfc3526.txt>.
26. RFC 3548: The Base16, Base32, and Base64 Data Encodings <http://www.ietf.org/rfc/rfc3548.txt>.
27. RFC 3766: Determining Strengths For Public Keys Used For Exchanging Symmetric Keys <http://www.ietf.org/rfc/rfc3766.txt>.
28. RFC 2104: HMAC: Keyed-Hashing for Message Authentication <http://www.ietf.org/rfc/rfc2104.txt>.
29. Recommendation for Block Cipher Modes of Operation: Federal Information Processing Standards Publication 800-38a <http://csrc.nist.gov/publications/ nistpubs/800-38a/sp800-38a.pdf>.
30. The more often Alice changes her published ESession options, the shorter the Perfect Forward Secrecy window of vulnerability. However, whenever she changes them she divulges her presence to all the entities that are monitoring them.
31. JEP-0163: Simplified Personal Publish-Subscribe <http://www.jabber.org/jeps/jep-0163.html>.
32. Alice may not be able to find the specified value of x if, for example, she went offline using a different client and/or a different machine without publishing a 'match_resource' field. In this case Alice cannot decrypt the offline ESession!
33. JEP-0091: Delayed Delivery <http://www.jabber.org/jeps/jep-0091.html>.
34. Although counter mode encryption requires no padding, implementations MAY still disguise the length of m by appending a random number of white-space characters.
35. If Bob were to receive a stanza out-of-order, then he would fail to decrypt the stanza and be forced to terminate the ESession.
36. If Bob were to receive a stanza out-of-order, then the MACs would not match because the values of CA would not be synchronized.
37. Bob MUST NOT send a stream error to his server since intermediate entities are not responsible for encoded content.
38. 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.
39. Content is specified for the <terminate/> element to facilitate XML Normalization.
40. Canonical XML 1.0 <http://www.w3.org/TR/xml-c14n>.
41. RFC 3447: Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 <http://www.ietf.org/rfc/rfc3447.txt>.
42. Digital Signature Standard: Federal Information Processing Standards Publication 186 <http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf>.
43. RFC 1750: Randomness Recommendations for Security <http://www.ietf.org/rfc/rfc1750.txt>.
44. SSH Transport Layer Encryption Modes <http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-05.txt>. Work in progress.
45. IANA registry of parameters related to secure shell <http://www.iana.org/assignments/ssh-parameters>.
46. Advanced Encryption Standard: Federal Information Processing Standards Publication 197 <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.
47. The Twofish Block Cipher <http://www.schneier.com/twofish.html>.
48. The Serpent Block Cipher <http://www.cl.cam.ac.uk/~rja14/serpent.html>.
49. X.509 Authentication in SSH2 <http://www.ietf.org/internet-drafts/draft-ietf-secsh-x509-02.txt>. Work in progress.
50. Secure Hash Standard: Federal Information Processing Standards Publication 180-2 <http://csrc.nist.gov/publications/fips/fips180-2/fips186-2withchangenotice.pdf>.
51. The Whirlpool Hash Function <http://paginas.terra.com.br/informatica/paulobarreto/WhirlpoolPage.html>.
52. Standard ECMA-151: Data Compression for Information Interchange - Adaptive Coding with Embedded Dictionary - DLCZ Algorithm <http://www.ecma-international.org/publications/standards/Ecma-151.htm>.
53. RFC 1950: ZLIB Compressed Data Format Specification version 3.3 <http://www.ietf.org/rfc/rfc1950.txt>.
54. 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/>.
55. 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/>.
56. JEP-0068: Field Data Standardization for Data Forms <http://www.jabber.org/jeps/jep-0068.html>.
57. JEP-0013: Flexible Offline Message Retrieval <http://www.jabber.org/jeps/jep-0013.html>.
END