<remark><p>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</p></remark>
<p><em>Note: The protocols developed according to the cryptographic design described in this document are described in &xep0116;, &xep0217;, &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.</em></p>
<p>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.</p>
<p>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 <cite>RFC 3920</cite>. 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.</p>
<p>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 detailed requirements for encrypted sessions are defined in &xep0210;.</p>
<p>The conceptual model for the approach specified in this document 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.</p>
<p>Note: In order to gain a thorough understanding of this document, it is recommended that the <cite>Off-the-Record Communication</cite> paper and the &zrtp; Internet-Draft are read first.</p>
<p>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.</p>
<p>Authenticated key-exchange is the most challenging part of the design of any secure communication protocol. The ESessions key exchange essentially translates the σ<note>Like <cite>RFC 2409</cite>, this protocol uses <em>variant (ii)</em>, as described in Secion 5.4 of the <cite>SIGMA</cite> paper.</note> key-exchange protocol into the syntax of XMPP. The SIGMA approach to Diffie-Hellman Key Agreement (see &rfc2631;) underpins several standard key-exchange protocols including the Internet Key Exchange (IKE) protocol versions 1 and 2 (see &rfc2409; and &rfc4306;).</p>
<p>Note: Although this section provides an overview of SIGMA, it is strongly recommended that the <cite>SIGMA</cite> paper is read first in order to gain a thorough understanding of this document.</p>
<p>The 3-message SIGMA-I-based key exchange protects the identity of the <em>initiator</em> against active attacks. This SHOULD NOT be used to establish client to client sessions since the <em>responder's</em> 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.</p>
<p>The two 4-message SIGMA-R-based key exchanges with hash commitment defend the <em>responder's</em> identity against active attacks and facilitate detection of a Man in the Middle attack. They SHOULD be used to establish client to client sessions.</p>
<p>Note: The block cipher function, <em>cipher</em>, uses CTR mode.</p>
<p>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 <cite>SIGMA</cite>.</p>
<p>The diagram below demonstrates the skeleton of the Diffie-Hellman key exchange that employs out-of-band Short Authentication String (SAS) verification. 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.</p>
<p>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.</p>
<section2topic='SIGMA-R with SAS Overview'anchor='foundations-skeleton-r'>
<p>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 <em>optional</em> out-of-band SAS authentication.</p>
<p>The diagram below describes exactly the same SIGMA-I key exchange protocol as the <linkurl='#foundations-skeleton-i'>SIGMA-I Overview</link> above. It provides much more detail, without specifying any ESession-specific details. The differences between it and the <linkurl='#foundations-core-r'>SIGMA-R with SAS Key Exchange</link> are highlighted.</p>
<section2topic='SIGMA-R with SAS Key Exchange'anchor='foundations-core-r'>
<p>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).</p>
<p>Furthermore, if retained secrets associated with a client/user combination are employed <em>consistently</em> 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). <note>This combination of techniques underpins the <cite>ZRTP</cite> key agreement protocol.</note></p>
<p>Public keys are optional in the diagram below. It describes the same SIGMA-R with SAS key exchange protocol as the <linkurl='#foundations-skeleton-r'>SIGMA-R Overview</link>. It provides much more detail including the use of retained secrets and other secrets. The use of public keys is negotiated in the first two messages. Note: These <em>optional</em> security enhancements are especially important when the protocol is being used without public keys.</p>
<p>The diagram does not specify any ESession-specific details. The differences between it and the <linkurl='#foundations-core-i'>SIGMA-I Key Exchange</link> are highlighted.</p>
<p>This section provides an overview of the full ESession key-exchange protocol from a cryptographic point of view. This protocol is based on the <em>full fledge</em> protocol, as described in Appendix B of the <cite>SIGMA</cite> paper. It also uses <em>variant (ii)</em>, as described in Secion 5.4 of the same paper.</p>
<p>The table below describes the parameters that are not found in the <linkurl='#foundations-parameters'>Parameter Descriptions</link> tables above.</p>
<td>Includes a set of possible values for each and every ESession parameter (see the ESession Request sub-section in <cite>Encrypted Session Negotiation</cite>), including sets of possible values for p, g, HASH, CIPHER, SIGN</td>
<td>Alice's private Diffie-Hellman keys - each value corresponds to one of Z different DH groups</td>
</tr>
<tr>
<td>&e1eZ;</td>
<td>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)</td>
<p>Alice uses this protocol when Bob is Online. In addition to the key exchange described in the <linkurl='#foundations-core-i'>SIGMA-I Key Exchange</link> 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 <linkurl='#design-online-r'>Online ESession-R Negotiation</link> are highlighted.</p>
<!--The first two forms below negotiate policy, swap Diffie-Hellman public values and the ancillary data necessary for the exchange and authentication. The second message also authenticates the responder. The third message authenticates the initiator and exchanges the final Diffie-Hellman public value.-->
<p>This protocol is similar to the <linkurl='#design-online-i'>Online ESession-I Negotiation</link> 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 <linkurl='#design-online-i'>Online ESession-I Negotiation</link> are highlighted.</p>
<p>Bob uses this protocol to send stanzas to Alice when she is Offline. Note: Since the full <cite>SIGMA</cite> protocol cannot be used if Alice is offline, her identity is not protected at all.</p>
<p>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.</p>
<p>The differences between this offline protocol and the <linkurl='#design-online-i'>Online ESession-I Negotiation</link> protocol above are highlighted in the diagram below.</p>
<p>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.</p>
<p>The author would like to thank: Ian Goldberg for the time he spent reviewing an early version of this protocol and for his invaluable suggestions and comments; and Hugo Krawczyk for his general advice and encouragment. The author of this document is entirely responsable for any errors it contains.</p>
