<remark><p>Split pubkey field into init_pubkey and resp_pubkey fields; modified namespaces to reflect XMPP Registrar procedures regarding URN issuance.</p></remark>
<remark><p>Added optional public key independence, hash commitment, SAS authentication, retained secrets and other secrets to the 4-message key exchange; defined when 3- and 4-message negotiations should be used; added disclosure field; added Back Doors and Key Associations sections; employed HMAC instead of hash; required public keys to be in W3C xmldsig KeyValue format and signatures to be wrapped in a SignatureValue element; deleted Signature Generation and Verification section in favor of xmldsig; moved exchanging stanzas and rekeying sections to XEP-0200; changed namespace</p></remark>
<remark><p>Added Upgradability requirement; added expires field to offline options; updated in line with latest version of PEP; moved some content to new XEPs (0187, 0188 and 0189)</p></remark>
<remark><p>Modified protocol in line with SIGMA: added Identity Protection requirement, no pre-indication of acceptable keys, send multiple values of e with ESession request, offline options published via SPPS, added LZW compression</p></remark>
</revision>
<revision>
<version>0.8</version>
<date>2005-09-27</date>
<initials>ip</initials>
<remark><p>Added diagramatic synopses; Added match_resource field; replaced req_mac and kid fields with prev_hash; Alice specifies initial counter (doubles as nonce); many other improvements</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2005-08-26</date>
<initials>ip</initials>
<remark><p>Simplified XML normalization; added Synopsis and Efficiency requirement; defined signature formats</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2005-08-12</date>
<initials>ip</initials>
<remark><p>Extended termination procedure; added object encryption/signing requirement and special case; clarified expired MAC publishing; added Flexible Offline Message Retrieval to Open Issues.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2005-08-10</date>
<initials>ip</initials>
<remark><p>Added flexibility requirement; added late signature of initial request; added termination MAC.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2005-08-09</date>
<initials>ip</initials>
<remark><p>Added (offline) replay protection; required offline Created header; compression is NOT RECOMMENDED; added second set of offline options for subscribers; added JIDs to session key generation; unencrypted sessions; added secure option; sign whole data form; HMAC whole <encrypted/> element; added ESession termination; option to distribute public keys within session negotiation; added Integrity requirement; several clarifications</p></remark>
<remark><p>Restored status to Experimental; complete rewrite; new Introduction, Background, Requirements and Security Considerations; new OTR-inspired protocol; XEP-0155-based negotiation; counter mode encryption; more secure hashes; offline sessions; re-keying; mac publishing; preliminary key and options publishing protocol.</p></remark>
<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 proposal describes a different approach to end-to-end encryption for use by entities that communicate using XMPP. The requirements and the consequent cryptographic design that underpin this protocol are described in <cite>Requirements for Encrypted Sessions</cite> and &xep0188;. 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 each one-to-one XML stanza exchanged between the endpoints will be encrypted and then transmitted within a "wrapper" stanza using &xep0200;.</p>
<p>&xep0217; describes a minimal subset of this protocol chosen to enable developers to produce working code before they have finished implementing the optional parts of this protocol.</p>
<li>"Alice" is the name of the initiator of the ESession. 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 other participant in the ESession started by Alice. Within the scope of this document, his fully-qualified JID is: <bob@example.com/laptop>.</li>
<li>"Aunt Tillie" the archetypal typical user (i.e. non-technical, with only very limited knowledge of how to use a computer, and averse to performing any procedures that are not familiar).</li>
<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>Before attempting to engage in an ESession with Bob, Alice MAY discover whether he supports this protocol, using either &xep0030; or the presence-based profile of <cite>XEP-0030</cite> specified in &xep0115;.</p>
<p>The normal course of events is for Alice to authenticate with her server, retrieve her roster (see <cite>RFC 3921</cite>), 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 <cite>XEP-0115</cite>), Alice SHOULD then send a service discovery information ("disco#info") request to each of those contacts (in accordance with <cite>XEP-0030</cite>). Such initial service discovery stanzas MUST NOT be considered part of encrypted communication sessions for the purposes of this document, 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:</p>
<p>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://www.xmpp.org/extensions/xep-0116.html#ns" &NSNOTE;.</p>
<p>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 σ approach to key exchange (see <cite>Cryptographic Design of Encrypted Sessions</cite>).</p>
<p>If Alice believes Bob may be online then she SHOULD use the protocol specified in &xep0155; and in this section to negotiate the ESession options and the keys.</p>
<p>Note: If Alice believes Bob is offline then she SHOULD NOT use this negotiation protocol. However, she MAY use the protocol specified in &xep0187; to establish the ESession options and keys. Alternatively, she MAY send stanzas without encryption - in which case her client MUST make absolutely clear to her that the stanzas will not be protected and give her the option not to send the stanzas.</p>
<p>The 3-message SIGMA-I-based key exchange (see <linkurl='http://www.xmpp.org/extensions/xep-0188.html#design-online-i'>useful summary of 3-message negotiation</link>) 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 4-message SIGMA-R-based key exchange (see <linkurl='http://www.xmpp.org/extensions/xep-0188.html#design-online-r'>useful summary of 4-message negotiation</link>) with hash commitment defends the <em>responder's</em> identity against active attacks and facilitates detection of a Man in the Middle attack. It SHOULD be used to establish client-to-client sessions. The 4-message key exchange also includes the following optional security enhancements:</p>
<li><p>"Secret Retention": If retained secrets 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. Sessions remain secure even if a long-lived private signing key is compromised at some time <em>after</em> the first session.</p></li>
<li><p>"Short-Authentication-String": Alice and Bob can use SAS once to quickly authenticate each other's public keys. Only a very short human-friendly string needs to be verified out-of-band (e.g. by recognizable voice communication).</p>
<p>Alternatively, thanks to its protection against Man-in-the-Middle attacks, SAS can be used to eliminate the need to generate, distribute or authenticate any public keys. Note: When this protocol is being used without public keys Alice and Bob SHOULD employ Secret Retention, then the out-of-band verification only needs to be performed once to verify the absence of a Man in the Middle for all sessions (past, present and future). <note>This combination of techniques underpins the <cite>ZRTP</cite> key agreement protocol.</note></p></li>
<li><p>"Other Secret": Alice and Bob agree a password out-of-band and their clients use it to authenticate each other every time a session is negotiated.</p></li>
<p>In addition to the "accept", "security", "logging" and "disclosure" fields (see <linkurl='#sec-backdoor'>Back Doors</link>) specified in <cite>Stanza Session Negotiation</cite>, Alice MUST send to Bob each of the ESession options (see list below) that she is willing to use (see <linkurl='#sec-mandatory'>Mandatory to Implement Technologies</link>).</p>
<li><p>The list of Modular Exponential (MODP) group numbers (as specified in &rfc2409; or &rfc3526;) that MAY be used for Diffie-Hellman key exchange in a "modp" field (valid group numbers include 1,2,3,4,5,14,15,16,17 and 18) <note>Entities SHOULD offer even the lowest MODP groups since some entities are CPU-constrained, and security experts tend to agree that "longer keys do not protect against the most realistic security threats".</note></p></li>
<li><p>Symmetric block cipher algorithm names in a "crypt_algs" field</p></li>
<li><p>Hash algorithm names in a "hash_algs" field</p></li>
<li><p>Compression algorithm names in a "compress" field</p></li>
<li><p>Short Authentication String generation algorithm names in a "sas_algs" field</p></li>
<li><p>The list of stanza types that MAY be encrypted and decrypted in a "stanzas" field (message, presence, iq)</p></li>
<li><p>The different versions of this protocol that are supported in a "ver" field <note>This version of this document describes version 1.0 of this protocol.</note></p></li>
<li><p>The minimum number of stanzas that MUST be exchanged before an entity MAY initiate a key re-exchange in a "rekey_freq" field (1 - every stanza, 100 - every hundred stanzas). Note: This value MUST be less than &twosup32; (see <linkurl='#sec-rekey'>Re-Keying Limits</link>)</p></li>
<li><p>The methods of identification of the other entity that would be acceptable, and the methods of identification that this entity is prepared to offer ("init_pubkey" and "resp_pubkey" parameters). The values of these two parameters MUST be either 'key' (a public signature-verification key wrapped in a <KeyValue/> element as specified in &w3xmlsig;), or 'hash' (a fingerprint of the public key - the result of processing the <linkurl='#sign-normal'>Normalized</link><KeyValue/> element with the selected hash algorithm, "HASH") <note>If the entity already possesses one of the other entity's public keys then it is RECOMMENDED that the fingerprint is requested from the other entity instead of the public key - since this saves bandwidth.</note>, or 'none' (no authentication via public keys). Note: 'none' MUST NOT be specified with 3-message negotiation.</p></li>
<li><p>Signature algorithm names (unless the values of the "init_pubkey" and "resp_pubkey" parameters are fixed to 'none')</p></li>
<p>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 <em>each</em> 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):</p>
<p>Alice MUST send all her calculated values of 'He' (for 4-message negotiations) or 'e' (for 3-message negotiations) to Bob (in a "dhhashes" field in the same order as the associated MODP groups are being sent) Base64 encoded (in accordance with Section 4 of &rfc4648;). She MUST also specify a randomly generated Base64 encoded value of &NsubA; (her ESession ID in a "my_nonce" field).</p>
<p>The options in each field MUST appear in Alice's order of preference.</p>
<p>The first message of a 3-message negotiation is identical except there MUST be no 'sas_algs' field and a 'dhkeys' field MUST be included instead of the 'dhhashes' field:</p>
<p>If Alice initiated a 3-message negotiation but Bob only supports 4-message negotiations (with Alice) then he SHOULD return a &feature; error specifying the 'dhkeys' field:</p>
<examplecaption='Bob Informs Alice that 3-message Negotiation is Not Supported'><