<abstract>This document specifies a minimal subset of the Encrypted Session Negotiation protocol sufficent for negotiating an end-to-end encrypted session.</abstract>
<remark><p>Initial published version; modified namespaces to reflect XMPP Registrar procedures regarding URN issuance.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2007-05-30</date>
<initials>ip</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>&xep0116; is a fully-fledged protocol that supports multiple different end-to-end encryption functionalities and scenarios. The protocol is as simple as possible given its feature set. However, the work involved to implement it may be reduced by removing support for several of the optional features, including alternative algorithms, 3-message exchange, public keys, repudiation and key re-exchange.</p>
<p>The minimal subset of the protocol defined in this document is designed to be relatively simple to implement while offering full compatibility with implementations of the fully-fledged protocol. The existence of this subset enables developers to produce working code before they have finished implementing the full protocol.</p>
<p>The requirements and the consequent cryptographic design that underpin this protocol are described in &xep0210; and &xep0188;. The basic concept is that of an encrypted session which acts as a secure tunnel between two endpoints. The protocol specified in &xep0155; and in this document is used to negotiate the encryption keys and establish the tunnel. Thereafter the content of each one-to-one XML stanza exchanged between the endpoints during the session will be encrypted and transmitted within a "wrapper" stanza using &xep0200;.</p>
<p>The cut-down protocol described here is a 4-message key exchange (see <linkurl='http://www.xmpp.org/extensions/xep-0188.html#design-online-r'>useful summary of 4-message negotiation</link>) with short-authentication-string (SAS), hash commitment and optional retained secrets. It avoids using public keys - thus protecting the identity of <em>both</em> participants against active attacks from third parties.</p>
<p>Note: This protocol requires that both entities are online. An entity MAY use the protocol specified in &xep0187; if it believes the other entity is offline.</p>
<p>This document introduces two characters to help the reader follow the necessary exchanges:</p>
<olstart='1'>
<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>
</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 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 disco#info request sent from Alice to Bob might look as follows:</p>
<examplecaption='Alice Queries Bob for ESession Support via Disco'><