<remark><p>Initial version (extracted from XEP-0116 version 0.12); clarified Re-Key Exchange section; removed canonicalization requirement; employed HMAC instead of hash; added new sections; changed element name and namespace</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>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 &xep0027;. When the core protocols were formalized within the Internet Standards Process by the IETF's XMPP Working Group in 2003 (see &rfc3920; and &rfc3921;), a different extension was defined using S/MIME-based signing and encryption of CPIM-formatted messages (see &rfc3862;) and PIDF-formatted presence information (see &rfc3863;); this extension is specified in &rfc3923;.</p>
<p>For reasons described in &xep0210;, 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.</p>
<p>This document describes a different session-based approach to the end-to-end encryption of the full content of XMPP stanzas sent between two entities. The protocol assumes that the encrypted session parameters (initial keys, counters and algorithms etc.) have already been agreed, typically through a negotiation protocol such as &xep0116;, &xep0217; or &xep0187;. The session approach when combined with short-lived keys offers many important advantages over the existing "Object Encryption" proposals, including Perfect Forward Secrecy and Identity Protection.</p>
<p>The requirements and the consequent cryptographic design that underpin this protocol and its associated protocols are described in &xep0210; and <cite>Cryptographic Design of Encrypted Sessions</cite>. The specific objectives of this protocol include:</p>
<li><p>Encryption of the full stanza content (except that which is required for stanza routing)</p></li>
<li><p>Minimise the Perfect Forward Secrecy window by enabling light-weight renegotiation of the short-term keys without requiring a full session renegotiation.</p></li>
<li><p>Minimise bandwidth overhead</p></li>
<li><p>No dependence on XML canonicalization</p></li>
<p>This document introduces two characters to help the reader follow the necessary exchanges:</p>
<olstart='1'>
<li>"Alice" is the name of the entity sending the encrypted stanza or initiating a re-key. Within the scope of this document, we stipulate that her fully-qualified JID is: <alice@example.org/pda>.</li>
<li>"Bob" is the name of the entity receiving the encrypted stanza or accepting a re-key. Within the scope of this document, his fully-qualified JID is: <bob@example.com/laptop>.</li>
</ol>
<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 send or receive encrypted stanzas within an encrypted session or initiate a re-key.</p>
<p>Here we assume that Alice and Bob have already established an encrypted session. Either Alice or Bob MAY send encrypted stanzas within the encrypted session or initiate a re-key. The following sections describe the process where Alice sends Bob an encrypted stanza and initiates a re-key.</p>
</section1>
<section1topic="Assumptions"anchor='assume'>
<p>The following sections assume that the parameters in the tables below have already been agreed. For more details refer to an encrypted session negotiation protocol such as <cite>Encrypted Session Negotiation</cite>.</p>
<tablecaption='Encryption Parameters'>
<tr>
<th>Parameter</th>
<th>Description</th>
</tr>
<tr>
<td>&CsubA;, &CsubB;</td>
<td>The initial block cipher counter value for blocks sent by Alice and Bob</td>
</tr>
<tr>
<td>&KCsubA;, &KCsubB;</td>
<td>The initial secret cipher keys that Alice and Bob use to encrypt</td>
</tr>
<tr>
<td>&KMsubA;, &KMsubB;</td>
<td>The initial secret MAC keys that Alice and Bob use to protect the integrity of encrypted data</td>
</tr>
<tr>
<td>HASH</td>
<td>Agreed hash algorithm</td>
</tr>
<tr>
<td>CIPHER, DECIPHER</td>
<td>Agreed CTR-mode block cipher algorithm</td>
</tr>
<tr>
<td>COMPRESS, DECOMPRESS</td>
<td>Agreed compression algorithm</td>
</tr>
</table>
<tablecaption='Re-Key Parameters'>
<tr>
<th>Parameter</th>
<th>Description</th>
</tr>
<tr>
<td>g</td>
<td>Diffie-Hellman generator</td>
</tr>
<tr>
<td>p</td>
<td>Diffie-Hellman prime</td>
</tr>
<tr>
<td>e, d</td>
<td>Alice and Bob's initial public Diffie-Hellman keys</td>
</tr>
<tr>
<td>x, y</td>
<td>*Alice and Bob's initial private Diffie-Hellman keys</td>
</tr>
</table>
<p>* x and y MUST be known only to Alice and Bob respectively, all other parameters MUST be known by both parties</p>
<p>All parameters except the algorithms are multi-precision integers, so implementations will need a Big Integer Math library to perform the necessary modular arithmetic. Note: A simple HMAC function and a cryptographic-strength pseudo-random number generator are also required, but no other cryptographic code is necessary.</p>
<p>Alice MAY use this protocol to encrypt only that part of the <em>content</em> of one-to-one &MESSAGE;, &PRESENCE; and &IQ; stanzas that would normally be ignored by the intermediate servers. She MUST NOT encrypt:</p>
<ul>
<li><p>Stanza wrapper element tags (only stanza content)</p></li>
<li><p><error/> elements <note>RFC 3920 requires that stanzas of type 'error' contain an <error/> child element.</note></p></li>
<li><p><defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> child elements of <error/> elements. <note>RFC 3920 requires that <error/> elements contain a <defined-condition/> child element.</note></p></li>
<li><p>&THREAD; elements <note>Applications typically use &THREAD; elements internally to route stanzas to the process handling a session. The content of thread elements MUST be opaque with no semantic meaning and only exact comparisons MAY be made against it.</note></p></li>
<li><p><amp/> elements (see &xep0079;)</p></li>
<p>A stanza MUST NOT contain more than one <c xmlns='http://www.xmpp.org/extensions/xep-0200.html#ns'/> element, and it MUST be an immediate child of the stanza wrapper element. There is only one exception to those two rules, if the stanza is type 'error' then its <error/> child element MAY also contain a <c xmlns='http://www.xmpp.org/extensions/xep-0200.html#ns'/> element.</p>
<section1topic="Encrypting a Stanza"anchor='encrypt'>
<p>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 <linkurl='#rekey'>Re-Key Exchange</link> stanza), then &CsubA; MUST be incremented by 1 (see below), and only the last two steps (normalization and MAC calculation) should be performed.</p>
<olstart='1'>
<li><p>Serialize the XML content she wishes to send into an array of UTF-8 bytes, m. <note>Although counter mode encryption requires no padding, implementations MAY still disguise the length of m by appending a random number of white-space characters.</note></p></li>
<li>
<p>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. <note>If Bob were to receive a stanza out-of-order, then he would fail to decrypt the stanza and be forced to terminate the encrypted session.</note></p>
<code>m_compressed = COMPRESS(m)</code>
</li>
<li>
<p>Encrypt the data with the agreed algorithm in counter mode, using the encryption key &KCsubA;. Note: &CsubA; MUST be incremented by 1 for each encrypted block or partial block (i.e. &CsubA; = (&CsubA; + 1) mod 2<spanclass='super'>n</span>, 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 then encryption MUST NOT be performed and &CsubA; MUST be incremented by 1 (for replay protection).</p>
<p>If there is encrypted XML content, the XML MUST include the Base64 encoded (even if the block cipher algorithm 'none' was agreed <note>The content is encoded even if no encryption is used to avoid triggering namespace errors when entities parse the XML.</note>, in accordance with Section 4 of &rfc4648;) value of m_final wrapped in a <data/> element.</p>
<p>Only if Alice has received stanzas containing a <key/> element (see <linkurl='#rekey'>Re-Key Exchange</link>) from Bob since she sent her last stanza then the XML MUST include the (positive, non-zero) number of such stanzas she has received (since she sent her last stanza) wrapped in a <new/> element.</p>
<p>The content may also contain one <key/> element (see <linkurl='#rekey'>Re-Key Exchange</link>) and one or more <old/> elements (see <linkurl='#publish'>Publishing Old MAC Values</link>).</p>
<p>Alice MUST normalize the content by removing any whitespace from the serialized content (i.e. remove all character data from <em>between</em> all elements). Note: <c/> elements are so simple that there should <em>never</em> be a need to convert the XML to canonical form.</p>
<p>Process the XML content, concatenated with the value of Alice's block cipher counter &CsubA; <em>before</em> the data was encrypted, through the HMAC algorithm (as defined in Section 2 of &rfc2104;), along with the agreed hash algorithm ("HASH") and the integrity key &KMsubA;.</p>
<section1topic="Sending an Encrypted Stanza"anchor='send'>
<p>Before sending the stanza to Bob, Alice MUST wrap the (unnormalized) content and the Base64 encoded value of a_mac (wrapped in a <mac/> element) inside an <c/> element and insert it into the stanza in place of the original content.</p>
<examplecaption='Message Stanza with Encrypted Content'><