Added PKI Independence and Robustness requirements; added optional public key independence, hash commitment, SAS authentication, retained secrets and other secrets to SIGMA-R key exchange
Removed public key IDs from Offline options
Initial version (extracted from XEP-0116 version 0.9).
Note: The protocols developed according to the requirements and cryptographic design described in this document are described in &xep0116;, &xep0187; and &xep0200;. The information in those documents should be sufficient for implementors. This purely informative document is primarily for people interested in the design and analysis of those protocols.
As specified in &rfc3920;, 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 &rfc3921;. There are three first-level elements of XML streams (&MESSAGE;, &PRESENCE;, and &IQ;); each of these "XML stanza" types has different semantics, which can complicate the task of defining a generalized approach to end-to-end encryption for XMPP. In addition, XML stanzas can be extended (via properly-namespaced child elements) for a wide variety of functionality.
XMPP is a session-oriented communication technology: normally, a client authenticates with a server and maintains a long-lived connection that defines the client's XMPP session. Such stream-level sessions may be secured via channel encryption using Transport Level Security (&rfc2246;), as specified in Section 5 of RFC 3920. However, there is no guarantee that all hops will implement or enforce channel encryption (or that intermediate servers are trustworthy), which makes end-to-end encryption desirable.
The encrypted stanzas should be understood by an intermediate server only to the extent required to route them. (One complicating factor is that routing information may include not only the stanza's 'to', 'from', 'type, and 'id' attributes, but also &xep0079; extensions.)
The session metaphor also applies to communication between endpoints: for instance, in IM applications, most instant messaging exchanges occur in bursts within limited time periods (e.g., two people may send a fairly large number of messages during a five-minute chat and then not exchange messages again for hours or even days). The XML stanzas exchanged during such a session may not be limited to &MESSAGE; stanzas; for instance, the session may be triggered by a change in one of the parties' presence status (e.g., changing from away to available) and the session may involve the exchange of &IQ; stanzas (e.g., to transfer a file as specified in &xep0096;).
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 all the scenarios above as well as one-to-one communication sessions. However, both many-to-many sessions and one-to-many broadcast are deemed out of scope for this document.
Offline communications are handled via a simple extension to the protocol for one-to-one sessions between two entities that are online simultaneously (see below).
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 &xep0027; and &rfc3923; assume that XMPP communications are more like the exchange of email messages than they are like an interactive session -- while Current Jabber OpenPGP Usage uses "old-style" PGP object encryption and RFC 3923 uses "new-style" S/MIME object encryption, both specify the use of object encryption.
However, because XMPP is a session-oriented communication technology, encryption schemes that are appropriate for other Internet technologies may not be appropriate for XMPP. XMPP, with its in-order delivery of XML stanzas, is able to take advantage of much more secure approaches to encryption (including Perfect Forward Secrecy) that are not feasible for less dynamic technologies (like email).
The session-oriented nature of XMPP implies that the focus should be on "session encryption" rather than "object encryption". The paradigm for XMPP encryption should be something closer to the widely-deployed Secure Shell technology (see &rfc4301; and &rfc4253;) or &zrtp; (an acclaimed &rfc3711; key agreement protocol) than to traditional encryption of files and standalone email messages.
Therefore, this document specifies a method for encrypted sessions ("ESessions") that takes advantage of the inherent possibilities and strengths of session encryption as opposed to object encryption. The conceptual model for this approach was inspired by "off-the-record" (OTR) communication, as implemented in the Gaim encryption plugin and described in &otr;. The basic concept is that of an encrypted session which acts as a secure tunnel between two endpoints. Once the tunnel is established, the content of all one-to-one XML stanzas exchanged between the endpoints will be encrypted and then transmitted within a "wrapper" protocol element.
Note: In order to gain a thorough understanding of this document, it is recommended that the Off-the-Record Communication paper and the ZRTP Internet-Draft are read first.
This document 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 XMPP entities. Any directly addressable XMPP entity may participate in an ESession.
This document stipulates the following security requirements for end-to-end encryption of XMPP communications:
Each of these requirements is explained in greater depth below.
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).
The protocol must not rely on any public key infrastructure (PKI), certification authority, web of trust, or any other trust model that is external to the trust established between Alice and Bob. However, if external authentication or trust models are available then Alice and Bob must be able to use them to enhance any trust that exists between them.
Each party to a conversation MUST know that the other party is who they want to communicate with (Alice must be able to know that Bob really is Bob, and vice versa).
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.
The protocol must provide more than one difficult challenge that must be overcome before an attack can succeed (for example, by generating encryption keys using as many shared secrets as possible - like retained secrets or optional passwords).
The protocol must be upgradable so that, if a vulnerability is discovered, a new version can fix it. Alice MUST tell Bob which versions of the protocol she is prepared to support. Then Bob MUST either choose one or reject the ESession.
In addition to the foregoing security profile, this document also stipulates the following application-specific requirements for encrypted communication in the context of Jabber/XMPP technologies:
Each of these is explained in greater depth below.
The solution should be generally applicable to the full content of any XML stanza type (&MESSAGE;, &PRESENCE;, &IQ;) sent between two entities. It is deemed acceptable for now if the solution does not apply to many-to-many stanzas (e.g., groupchat messages sent within the context of multi-user chat) or one-to-many stanzas (e.g., presence "broadcasts" and pubsub notifications); end-to-end encryption of such stanzas may require separate solutions or extensions to the one-to-one session solution.
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. If the users are prepared to verify the integrity of their copies of each other's keys then the necessary actions should be limited to a one-time out-of-band verification of a string of up to 6 alphanumeric characters.
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 instead of being delivered immediately, such as so-called "offline messages". However, any vulnerabilities introduced to enable offline communications must not make online communications more vulnerable.
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".
Authenticated key-exchange is the most challenging part of the design of any secure communication protocol. The ESessions key exchange essentially translates the σ
Note: Although this section provides an overview of SIGMA, it is strongly recommended that the SIGMA paper is read first in order to gain a thorough understanding of this document.
The 3-message SIGMA-I-based key exchange protects the identity of the initiator against active attacks. This SHOULD NOT be used to establish client to client sessions since the responder's identity is not protected against active attacks. However, it SHOULD be used to establish client to service (server) sessions, especially where the identity of the service is well known to third parties.
The two 4-message SIGMA-R-based key exchanges with hash commitment defend the responder's identity against active attacks and facilitate detection of a Man in the Middle attack. They SHOULD be used to establish client to client sessions.
Note: The block cipher function, cipher, uses CTR mode.
| Parameter | Description |
|---|---|
| g | Diffie-Hellman generator |
| x, y | Alice and Bob's private Diffie-Hellman keys |
| &gsupx;, &gsupy; | Alice and Bob's public Diffie-Hellman keys |
| H&gsupx; | Hash of Alice's public Diffie-Hellman key |
| &KSsubA;, &KSsubB; | The MAC keys (derived from K) 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 |
| &KCsubA;, &KCsubB; | The cipher keys (derived from K) that Alice and Bob use to encrypt |
| &IDA;, &IDB; | The encrypted parameters that identify Alice and Bob to each other |
| SAS | Short Authentication string |
| Parameter | Description |
|---|---|
| p | Diffie-Hellman prime |
| e, d | Alice and Bob's public Diffie-Hellman keys (the same as &gsupx;, &gsupy;) |
| He | Hash of Alice's public Diffie-Hellman key |
| K | Shared secret (derived by Alice from &gsupy; and x, or by Bob from &gsupx; and y) |
| HASH | Selected hash algorithm |
| &NsubA;, &NsubB; | Alice and Bob's session freshness nonces (ESession IDs) |
| &CsubA;, &CsubB; | Block cipher initial counter value for blocks sent by Alice and Bob |
| n | Block size of selected cipher algorithm in bits |
| &KMsubA;, &KMsubB; | The MAC keys (derived from K) that Alice and Bob use to protect the integrity of encrypted data |
| &MsubA;, &MsubB; | The MAC values that Alice and Bob use to confirm the integrity of encrypted data |
| SRS | Shared retained secret (derived from K in previous session between the clients) |
| &RS1ARSZA; | Retained secrets Alice shares with Bob (one for each client he uses) |
| &RS1BRSZB; | Retained secrets Bob shares with Alice (one for each client she uses) |
| &RSH1ARSHZA; | HMACs of retained secrets Alice shares with Bob |
| SRSH | Bob's HMAC of SRS |
| OSS | Other shared secret of Alice and Bob (e.g. a shared password) defaults to "secret" |
| &isPKsubA;, &isPKsubB; | Whether or not Alice and Bob prefer to receive a public key (booleans) |
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 (&KCsubA; and &KCsubB;) are different in each direction, making this exchange slightly more conservative than SIGMA.
ALICE BOB
&gsupx;
------------>
&macB; = HMAC(&KSsubB;, {&gsupx;, &gsupy;, &pubKeyB;})
&signB; = sign(&signKeyB;, &macB;)
&IDB; = cipher(&KCsubB;, {&pubKeyB;, &signB;})
&gsupy;, &IDB;
<------------
authenticate(&IDB;)
&macA; = HMAC(&KSsubA;, {&gsupy;, &gsupx;, &pubKeyA;})
&signA; = sign(&signKeyA;, &macA;)
&IDA; = cipher(&KCsubA;, {&pubKeyA;, &signA;})
&IDA;
------------>
authenticate(&IDA;)
The diagram below demonstrates the skeleton of the Diffie-Hellman key exchange that employs out-of-band SAS authentication. If Alice and Bob's public keys are not yet trusted, or if their private keys have been compromised, then the hash commitment sent in the first step enables Alice and Bob to verify their copies of each other's Diffie-Hellman (and public) keys and detect a Man in the Middle more easily.
If a Man in the Middle changes the public Diffie-Hellman keys that Alice and Bob receive, then he could potentially use his knowledge of the SAS that Bob will eventually calculate when choosing the key he will send to Alice in the second step. However, the fact that the value he received in the first step is only a hash means the Man in the Middle must choose the key he sends to Alice before he can predict the SAS that she will calculate with it. Therefore, even if the SAS is very short, he is unable to use his resources to choose a key that will (have a better than random chance to) result in a SAS that matches Bob's. So only a truncated version of the HASH of Alice and Bob's keys needs to be verified out-of-band in the final step.
ALICE BOB
H&gsupx;
------------>
&gsupy;
<------------
SAS = truncate(HASH(&gsupx; | &gsupy;))
&gsupx;
------------>
assert H&gsupx; = HASH(&gsupx;)
SAS = truncate(HASH(&gsupx; | &gsupy;))
SAS
<===========>
The logic of the four-step SIGMA-R protocol is similar to the three-step SIGMA-I protocol. The difference being that Bob protects his identity from active attacks by by delaying communicating his identity to Alice until he has authenticated her. The diagram below demonstrates the skeleton of the key exchange. Note that it also takes advantage of the extra step required for SIGMA-R to incorporate a hash commitment, thus enabling optional out-of-band SAS authentication.
ALICE BOB
H&gsupx;
------------>
&gsupy;
<------------
&macA; = HMAC(&KSsubA;, {&gsupy;, &gsupx;, &pubKeyA;})
&signA; = sign(&signKeyA;, &macA;)
&IDA; = cipher(&KCsubA;, {&pubKeyA;, &signA;})
SAS = truncate(HASH(&gsupx; | &gsupy;))
&gsupx;, &IDA;
------------>
assert H&gsupx; = HASH(&gsupx;)
SAS = truncate(HASH(&gsupx; | &gsupy;))
SAS
<===========>
authenticate(&IDA;)
&macB; = HMAC(&KSsubB;, {&gsupx;, &gsupy;, &pubKeyB;})
&signB; = sign(&signKeyB;, &macB;)
&IDB; = cipher(&KCsubB;, {&pubKeyB;, &signB;})
&IDB;
<------------
authenticate(&IDB;)
The diagram below describes exactly the same SIGMA-I key exchange protocol as the SIGMA-I Overview above. It provides much more detail, without specifying any ESession-specific details. The differences between it and the SIGMA-R with SAS Key Exchange are highlighted.
ALICE BOB
&NsubA; = random()
x = random()
e = &gsupx; mod p
e, &NsubA;
------------>
&NsubB; = random()
&CsubA; = random()
&CBeCAx2n1;
y = random()
d = &gsupy; mod p
assert 1 < e < p-1
K = HASH(&esupy; mod p)
&KCsubA; = HMAC(HASH, K, "Initiator Cipher Key")
&KCsubB; = HMAC(HASH, K, "Responder Cipher Key")
&KMsubA; = HMAC(HASH, K, "Initiator MAC Key")
&KMsubB; = HMAC(HASH, K, "Responder MAC Key")
&KSsubA; = HMAC(HASH, K, "Initiator SIGMA Key")
&KSsubB; = HMAC(HASH, K, "Responder SIGMA Key")
&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &CsubA;})
&signB; = sign(&signKeyB;, &macB;)
&IDB; = cipher(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
&MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
d, &CsubA;, &NsubB;
<------------
&IDB;, &MsubB;
&CBeCAx2n1;
assert 1 < d < p-1
K = HASH(&dsupx; mod p)
&KCsubA; = HMAC(HASH, K, "Initiator Cipher Key")
&KCsubB; = HMAC(HASH, K, "Responder Cipher Key")
&KMsubA; = HMAC(HASH, K, "Initiator MAC Key")
&KMsubB; = HMAC(HASH, K, "Responder MAC Key")
&KSsubA; = HMAC(HASH, K, "Initiator SIGMA Key")
&KSsubB; = HMAC(HASH, K, "Responder SIGMA Key")
assert &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
{&pubKeyB;, &signB;} = decipher(&KCsubB;, &CsubB;, &IDB;)
&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &CsubA;})
verify(&signB;, &pubKeyB;, &macB;)
&macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;})
&signA; = sign(&signKeyA;, &macA;)
&IDA; = cipher(&KCsubA;, &CsubA;, {&pubKeyA;, &signA;})
&MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;)
&IDA;
------------>
&MsubA;
assert &MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;)
{&pubKeyA;, &signA;} = decipher(&KCsubA;, &CsubA;, &IDA;)
&macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;})
verify(&signA;, &pubKeyA;, &macA;)
The Short Authentication String technique enables protection against a Man in the Middle without the need to generate, distribute or authenticate any public keys. As long as a hash commitment is used at the start of the key exchange then only a short human-friendly string needs to be verified out-of-band (e.g. by recognizable voice communication).
Furthermore, if retained secrets associated with a client/user combination are employed consistently during key exchanges, then the Man in the Middle would need to be present for every session, including the first, and the out-of-band verification would only need to be performed once to verify the absence of a Man in the Middle for all sessions between the parties (past, present and future).
Public keys are optional in the diagram below. It describes the same SIGMA-R with SAS key exchange protocol as the SIGMA-R Overview. It provides much more detail including the use of retained secrets and other secrets. Note: These optional security enhancements are especially important when the protocol is being used without public keys.
The diagram does not specify any ESession-specific details. The differences between it and the SIGMA-I Key Exchange are highlighted.
ALICE BOB &NsubA; = random() x = random() e = &gsupx; mod p He = SHA256(e) He, &isPKsubA; ------------> &NsubA; &NsubB; = random() &CsubA; = random() &CBeCAx2n1; y = random() d = &gsupy; mod p d, &CsubA;, &NsubB; <------------ &isPKsubB; &CBeCAx2n1; assert 1 < d < p-1 K = HASH(&dsupx; mod p) &KCsubA; = HMAC(HASH, K, "Initiator Cipher Key") &KMsubA; = HMAC(HASH, K, "Initiator MAC Key") &KSsubA; = HMAC(HASH, K, "Initiator SIGMA Key") SAS = truncate(HASH(e | d | "Short Authentication String")) &RSH1ARSHZA; = HMAC(HASH, &NsubA;, &RS1ARSZA;) if &isPKsubB; equals false then: &macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &RSH1ARSHZA;}) &IDA; = cipher(&KCsubA;, &CsubA;, &macA;) else: &macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &RSH1ARSHZA;}) &signA; = sign(&signKeyA;, &macA;) &IDA; = cipher(&KCsubA;, &CsubA;, {&pubKeyA;, &signA;}) &MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;) &IDA;, &MsubA; ------------> e, &RSH1ARSHZA; assert He = SHA256(e) SAS = truncate(HASH(e | d | "Short Authentication String") )) SAS <===========> assert 1 < e < p-1 K = HASH(&esupy; mod p) &KCsubA; = HMAC(HASH, K, "Initiator Cipher Key") &KMsubA; = HMAC(HASH, K, "Initiator MAC Key") &KSsubA; = HMAC(HASH, K, "Initiator SIGMA Key") assert &MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;) if &isPKsubB; equals false then: &macA; = decipher(&KCsubA;, &CsubA;, &IDA;) assert &macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &RSH1ARSHZA;}) else: {&pubKeyA;, &signA;} = decipher(&KCsubA;, &CsubA;, &IDA;) &macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &RSH1ARSHZA;}) verify(&signA;, &pubKeyA;, &macA;) SRS = choose(&RS1BRSZB;, &RSH1ARSHZA;, &NsubA;) K = HASH(K | SRS | OSS) &KCsubA; = HMAC(HASH, K, "Initiator Cipher Key") &KCsubB; = HMAC(HASH, K, "Responder Cipher Key") &KMsubA; = HMAC(HASH, K, "Initiator MAC Key") &KMsubB; = HMAC(HASH, K, "Responder MAC Key") &KSsubB; = HMAC(HASH, K, "Responder SIGMA Key") SRSH = HMAC(HASH, SRS, "Shared Retained Secret") retain(HMAC(HASH, K, "New Retained Secret")) if &isPKsubA; equals false then: &macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &CsubA;}) &IDB; = cipher(&KCsubB;, &CsubB;, &macB;) else: &macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &CsubA;}) &signB; = sign(&signKeyB;, &macB;) &IDB; = cipher(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;}) &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;) &IDB; <------------ &MsubB;, SRSH SRS = choose(&RS1ARSZA;, SRSH) K = HASH(K | SRS | OSS) &KCsubA; = HMAC(HASH, K, "Initiator Cipher Key") &KCsubB; = HMAC(HASH, K, "Responder Cipher Key") &KMsubA; = HMAC(HASH, K, "Initiator MAC Key") &KMsubB; = HMAC(HASH, K, "Responder MAC Key") &KSsubB; = HMAC(HASH, K, "Responder SIGMA Key") retain(HMAC(HASH, K, "New Retained Secret")) assert &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;) if &isPKsubA; equals false then: &macB; = decipher(&KCsubB;, &CsubB;, &IDB;) assert &macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &CsubA;}) else: {&pubKeyB;, &signB;} = decipher(&KCsubB;, &CsubB;, &IDB;) &macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &CsubA;}) verify(&signB;, &pubKeyB;, &macB;)
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 above.
| Parameter | Description |
|---|---|
| options | Includes a set of possible values for each and every ESession parameter (see the ESession Request sub-section in Encrypted Session Negotiation), including sets of possible values for p, g, HASH, CIPHER, SIGN |
| chosen | Includes a chosen value for each ESession parameter |
| CIPHER | Selected CTR-mode block cipher algorithm |
| DECIPHER | Selected CTR-mode block decipher algorithm (corresponds to CIPHER) |
| SIGN | Selected signature algorithm |
| VERIFY | The selected signature verification algorithm (corresponds to SIGN) |
| SASGEN | The selected SAS generation algorithm |
| &x1xZ; | Alice's private Diffie-Hellman keys - each value corresponds to one of Z different DH groups |
| &e1eZ; | 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) |
| &He1HeZ; | The list of hash commitments that Alice sends to Bob (hashes of &e1eZ;) |
| *&signKeysA; | All the private keys that Alice is able to use to create signatures |
| *&signsB; | The set of signatures of &formB; (one for each of Bob's private keys) |
| *&pubKeysA; | All of Alice's public keys that Bob has access to |
* Offline negotiation only
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. The differences between this protocol and Online ESession-R Negotiation are highlighted.
ALICE BOB
&NsubA; = random()
for g,p ∈ options
x = random()
e = &gsupx; mod p
&formA; = {&e1eZ;, options, &NsubA;}
&formA;
--------->
chosen = {p,g,HASH,CIPHER,SIGN...} = choose(options)
e = choose(&e1eZ;, p)
&NsubB; = random()
&CsubA; = random()
&CBeCAx2n1;
y = random()
d = &gsupy; mod p
&formB; = {&CsubA;, chosen, d, &NsubA;, &NsubB;}
assert 1 < e < p-1
K = HASH(&esupy; mod p)
&KCsubA; = HMAC(HASH, K, "Initiator Cipher Key")
&KCsubB; = HMAC(HASH, K, "Responder Cipher Key")
&KMsubA; = HMAC(HASH, K, "Initiator MAC Key")
&KMsubB; = HMAC(HASH, K, "Responder MAC Key")
&KSsubA; = HMAC(HASH, K, "Initiator SIGMA Key")
&KSsubB; = HMAC(HASH, K, "Responder SIGMA Key")
&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})
&signB; = SIGN(&signKeyB;, &macB;)
&IDB; = CIPHER(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
&MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
&formB;
<---------
&IDB;, &MsubB;
assert chosen ∈ options
x = choose(&x1xZ;, p)
e = &gsupx; mod p
&CBeCAx2n1;
assert 1 < d < p-1
K = HASH(&dsupx; mod p)
&KCsubA; = HMAC(HASH, K, "Initiator Cipher Key")
&KCsubB; = HMAC(HASH, K, "Responder Cipher Key")
&KMsubA; = HMAC(HASH, K, "Initiator MAC Key")
&KMsubB; = HMAC(HASH, K, "Responder MAC Key")
&KSsubA; = HMAC(HASH, K, "Initiator SIGMA Key")
&KSsubB; = HMAC(HASH, K, "Responder SIGMA Key")
assert &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
{&pubKeyB;, &signB;} = DECIPHER(&KCsubB;, &CsubB;, &IDB;)
&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})
VERIFY(&signB;, &pubKeyB;, &macB;)
&macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;})
&signA; = SIGN(&signKeyA;, &macA;)
&IDA; = CIPHER(&KCsubA;, &CsubA;, {&pubKeyA;, &signA;})
&MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;)
&IDA;
--------->
&MsubA;, &NsubB;
assert &MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;)
{&pubKeyA;, &signA;} = DECIPHER(&KCsubA;, &CsubA;, &IDA;)
&macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;})
VERIFY(&signA;, &pubKeyA;, &macA;)
This protocol is similar to the Online ESession-I Negotiation above, except that Bob's identity is protected from active attacks (by by delaying communicating his identity to Alice until he has authenticated her). The optional use of SAS, retained secrets and other secrets means the protocol may be used without any public keys. The differences between this protocol and Online ESession-I Negotiation are highlighted.
ALICE BOB
&NsubA; = random()
for g,p ∈ options
x = random()
e = &gsupx; mod p
He = SHA256(e)
&formA; = {&He1HeZ;, options, &NsubA;, &isPKsubA;}
&formA;
------------>
chosen = {p,g,HASH,CIPHER,SIGN,SASGEN...} = choose(options)
He = choose(&He1HeZ;, p)
&NsubB; = random()
&CsubA; = random()
&CBeCAx2n1;
y = random()
d = &gsupy; mod p
&formB; = {&CsubA;, chosen, d, &NsubA;, &NsubB;, &isPKsubB;}
&formB;
<------------
assert chosen ∈ options
x = choose(&x1xZ;, p)
e = choose(&e1eZ;, p)
&CBeCAx2n1;
assert 1 < d < p-1
K = HASH(&dsupx; mod p)
&KCsubA; = HMAC(HASH, K, "Initiator Cipher Key")
&KMsubA; = HMAC(HASH, K, "Initiator MAC Key")
&KSsubA; = HMAC(HASH, K, "Initiator SIGMA Key")
SAS = SASGEN(e, d)
&RSH1ARSHZA; = HMAC(HASH, &NsubA;, &RS1ARSZA;)
&formA2; = {&RSH1ARSHZA;, e, &NsubB;}
if &isPKsubB; equals false then:
&macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &formA;, &formA2;})
&IDA; = CIPHER(&KCsubA;, &CsubA;, &macA;)
else:
&macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;, &formA2;})
&signA; = SIGN(&signKeyA;, &macA;)
&IDA; = CIPHER(&KCsubA;, &CsubA;, {&pubKeyA;, &signA;})
&MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;)
&IDA;, &MsubA;
------------>
&formA2;
assert He = SHA256(e)
SAS = SASGEN(e, d)
SAS
<===========>
assert 1 < e < p-1
K = HASH(&esupy; mod p)
&KCsubA; = HMAC(HASH, K, "Initiator Cipher Key")
&KMsubA; = HMAC(HASH, K, "Initiator MAC Key")
&KSsubA; = HMAC(HASH, K, "Initiator SIGMA Key")
assert &MsubA; = HMAC(HASH, &KMsubA;, &CsubA;, &IDA;)
if &isPKsubB; equals false then:
&macA; = DECIPHER(&KCsubA;, &CsubA;, &IDA;)
assert &macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &formA;, &formA2;})
else:
{&pubKeyA;, &signA;} = DECIPHER(&KCsubA;, &CsubA;, &IDA;)
&macA; = HMAC(HASH, &KSsubA;, {&NsubB;, &NsubA;, e, &pubKeyA;, &formA;, &formA2;})
VERIFY(&signA;, &pubKeyA;, &macA;)
SRS = choose(&RS1BRSZB;, &RSH1ARSHZA;, &NsubA;)
K = HASH(K | SRS | OSS)
&KCsubA; = HMAC(HASH, K, "Initiator Cipher Key")
&KCsubB; = HMAC(HASH, K, "Responder Cipher Key")
&KMsubA; = HMAC(HASH, K, "Initiator MAC Key")
&KMsubB; = HMAC(HASH, K, "Responder MAC Key")
&KSsubB; = HMAC(HASH, K, "Responder SIGMA Key")
if SRS equals false then:
SRS = random()
SRSH = HMAC(HASH, SRS, "Shared Retained Secret")
retain(HMAC(HASH, K, "New Retained Secret"))
&formB2; = {&NsubA;, SRSH}
if &isPKsubA; equals false then:
&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &formB;, &formB2;})
&IDB; = CIPHER(&KCsubB;, &CsubB;, &macB;)
else:
&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;, &formB2;})
&signB; = SIGN(&signKeyB;, &macB;)
&IDB; = CIPHER(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
&MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
&IDB;, &MsubB;
<------------
&formB2;
SRS = choose(&RS1ARSZA;, SRSH)
K = HASH(K | SRS | OSS)
&KCsubA; = HMAC(HASH, K, "Initiator Cipher Key")
&KCsubB; = HMAC(HASH, K, "Responder Cipher Key")
&KMsubA; = HMAC(HASH, K, "Initiator MAC Key")
&KMsubB; = HMAC(HASH, K, "Responder MAC Key")
&KSsubB; = HMAC(HASH, K, "Responder SIGMA Key")
retain(HMAC(HASH, K, "New Retained Secret"))
assert &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
if &isPKsubA; equals false then:
&macB; = DECIPHER(&KCsubB;, &CsubB;, &IDB;)
assert &macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &formB;, &formB2;})
else:
{&pubKeyB;, &signB;} = DECIPHER(&KCsubB;, &CsubB;, &IDB;)
&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;, &formB2;})
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 at all.
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
&NsubA; = random()
for g,p ∈ options
x = random()
e = &gsupx; mod p
&formA; = {&e1eZ;, options, &NsubA;}
&signsA; = multi_sign(&signKeysA;, &formA;)
retain(&NsubA;, &x1xZ;, expireTime)
&formA;
-------->
&signsA;
retain(&formA;, &signsA;)
---------------------------------------------------------------------------------------------------------
retrieve(&formA;, &signsA;)
&formA;
-------->
&signsA;
verify_one(&signsA;, &pubKeysA;, &formA;)
chosen = {p,g,HASH,CIPHER,SIGN...} = choose(options)
e = choose(&e1eZ;, p)
&CsubA; = random()
y = random()
d = &gsupy; mod p
&CBeCAx2n1;
&NsubB; = random()
&formB; = {&CsubA;, chosen, d, &NsubA;, &NsubB;}
assert 1 < e < p-1
K = HASH(&esupy; mod p)
&KCsubA; = HMAC(HASH, K, "Initiator Cipher Key")
&KCsubB; = HMAC(HASH, K, "Responder Cipher Key")
&KMsubA; = HMAC(HASH, K, "Initiator MAC Key")
&KMsubB; = HMAC(HASH, K, "Responder MAC Key")
&KSsubA; = HMAC(HASH, K, "Initiator SIGMA Key")
&KSsubB; = HMAC(HASH, K, "Responder SIGMA Key")
&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})
&signB; = SIGN(&signKeyB;, &macB;)
&IDB; = CIPHER(&KCsubB;, &CsubB;, {&pubKeyB;, &signB;})
&MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
&formB;
<--------
&IDB;, &MsubB;
retain(&formB;,&IDB;,&MsubB;)
---------------------------------------------------------------------------------------------------------
retrieve(&formB;,&IDB;,&MsubB;)
&formB;
<--------
&IDB;, &MsubB;
retrieve(&NsubA;, &x1xZ;, expireTime)
assert now < expireTime
assert chosen ∈ options
x = choose(&x1xZ;, p)
e = &gsupx; mod p
&CBeCAx2n1;
assert 1 < d < p-1
K = HASH(&dsupx; mod p)
&KCsubA; = HMAC(HASH, K, "Initiator Cipher Key")
&KCsubB; = HMAC(HASH, K, "Responder Cipher Key")
&KMsubA; = HMAC(HASH, K, "Initiator MAC Key")
&KMsubB; = HMAC(HASH, K, "Responder MAC Key")
&KSsubA; = HMAC(HASH, K, "Initiator SIGMA Key")
&KSsubB; = HMAC(HASH, K, "Responder SIGMA Key")
assert &MsubB; = HMAC(HASH, &KMsubB;, &CsubB;, &IDB;)
{&pubKeyB;, &signB;} = DECIPHER(&KCsubB;, &CsubB;, &IDB;)
&macB; = HMAC(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})
VERIFY(&signB;, &pubKeyB;, &macB;)
Note: &KMsubB; is necessary only to allow Bob to terminate the ESession if he comes online before Alice terminates it. The calculation of &KCsubB; and &KSsubB; is not strictly necessary.
The security considerations are described in Encrypted Session Negotiation and Offline Encrypted Sessions.
This document requires no interaction with &IANA;.
This document requires no interaction with the ®ISTRAR;.
The author would like to thank Ian Goldberg for the time he spent reviewing this protocol and for his invaluable suggestions and comments.