moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

added disclosure field and Back Doors section 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@186 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Ian Paterson 2006-11-16 20:50:58 +00:00
parent 486b73e571
commit 126232144a
1 changed files with 48 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

63
xep-0116.xml
View File

@ -69,6 +69,12 @@
&ianpaterson;
&stpeter;
&dizzyd;
<revision>
<version>0.13</version>
<date>2006-11-16</date>
<initials>ip</initials>
<remark><p>Added disclosure field and Back Doors section</p></remark>
</revision>
<revision>
<version>0.12</version>
<date>2006-10-05</date>
@ -160,7 +166,7 @@
</section1>
<section1 topic='Discovering Support' anchor='disco'>
<p>Before attempting to engage in an ESession with Bob, Alice SHOULD discover whether he supports this protocol, using either &xep0030; or the presence-based profile of <cite>XEP-0030</cite> specified in &xep0115;.</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>
<example caption='Alice Queries Bob for ESession Support via Disco'><![CDATA[
<iq type='get'
@ -192,7 +198,7 @@
<p>Note: If Alice believes Bob is offline then she SHOULD NOT use this negotiation protocol. However, she MAY use the protocol specified in <cite>Offline Encrypted Sessions</cite> 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>Note: In any case, Alice MUST NOT initiate a new ESession with Bob if she already has one established with him.</p>
<section2 topic="ESession Request" anchor='init-online-request'>
<p>In addition to the "accept", "otr" and "security" fields specified in <cite>Chat Session Negotiation</cite>, Alice MUST send to Bob each of the ESession options (see list below) that she is willing to use, in her order of preference (see <link url='#sec-mandatory'>Mandatory to Implement Technologies</link>). Note: Alice SHOULD NOT include a "reason" field since Aunt Tillie may not be aware the ESession request is <em>not</em> encrypted.</p>
<p>In addition to the "accept", "security", "otr" and "disclosure" fields (see <link url='#sec-backdoor'>Back Doors</link>) specified in <cite>Chat Session Negotiation</cite>, Alice MUST send to Bob each of the ESession options (see list below) that she is willing to use, in her order of preference (see <link url='#sec-mandatory'>Mandatory to Implement Technologies</link>). Note: Alice SHOULD NOT include a "reason" field since Aunt Tillie may not be aware the ESession request is <em>not</em> encrypted.</p>
<ol>
<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 (valid group numbers include 1,2,3,4,5,14,15,16,17 and 18)</p></li>
<li><p>Symmetric block cipher algorithm names</p></li>
@ -212,6 +218,7 @@
<p>Alice MUST send all her calculated values of e to Bob (in the same order as the associated MODP groups are being sent). She MUST also specify randomly generated Base64 encoded (in accordance with Section 3 of &rfc3548;) value of &NsubA; (her ESession ID).</p>
<example caption='Alice Requests an ESession'><![CDATA[
<message from='alice@example.org/pda' to='bob@example.com'>
<thread>ffd7076498744578d10edabfe7f4a866</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x type='form' xmlns='jabber:x:data'>
<field type="hidden" var="FORM_TYPE">
@ -224,6 +231,9 @@
<option><value>false</value></option>
<option><value>true</value></option>
</field>
<field type="list-single" var="disclosure">
<option><value>never</value></option>
</field>
<field type="list-single" var="security">
<option><value>e2e</value></option>
<option><value>c2s</value></option>
@ -264,10 +274,10 @@
<field type="text-single" var="rekey_freq">
<value>1</value>
</field>
<field var="my_nonce">
<value> ** Base64 encoded ESession ID ** </value>
<field type="hidden" var="my_nonce">
<value> ** Alice's Base64 encoded ESession ID ** </value>
</field>
<field var="keys">
<field type="hidden" var="keys">
<value> ** Base64 encoded value of e5 ** </value>
<value> ** Base64 encoded value of e14 ** </value>
<value> ** Base64 encoded value of e2 ** </value>
@ -285,6 +295,7 @@
<message type='error'
from='bob@example.com/laptop'
to='alice@example.org/pda'>
<thread>ffd7076498744578d10edabfe7f4a866</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
...
</feature>
@ -298,6 +309,7 @@
<p>If Bob is unwilling to start an ESession, but he <em>is</em> ready to initiate a one-to-one chat session with Alice (see <cite>Chat Session Negotiation</cite>), and if Alice included an option for the "security" field with the value "none" or "c2s", then Bob SHOULD accept the Chat Session and terminate the ESession negotiation by specifying "none" or "c2s" for the value of the "security" field in his response.</p>
<example caption='Bob Accepts Chat Session'><![CDATA[
<message from='bob@example.com/laptop' to='alice@example.org/pda'>
<thread>ffd7076498744578d10edabfe7f4a866</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x type='submit' xmlns='jabber:x:data'>
<field var="FORM_TYPE">
@ -305,6 +317,7 @@
</field>
<field var="accept"><value>1</value></field>
<field var="otr"><value>true</value></field>
<field var="disclosure"><value>never</value></field>
<field var="security"><value>c2s</value></field>
</x>
</feature>
@ -349,7 +362,7 @@
<ol>
<li><p>Select &pubKeyB;, the public key Alice should use to authenticate his signature with the signature algorithm he selected ("SIGN").</p></li>
<li><p>Set &formB; to the <link url='#sign-normal'>Normalized</link>&#160;<em>content</em> of the reponse data form he will send back to Alice (including his responses for all the fields he received from Alice).</p>
<p>Bob MUST encapsulate the Base64 encoded values of &CsubA; and Alice's &NsubA; in two new 'counter' and 'nonce' fields and add them to &formB;. Note: The 'pk_hash' field specifies whether or not Alice MUST send the fingerprint of her public signature-verification key instead of her full key. Note: The value of the 'rekey_freq' field MUST be less than &twosup32; and greater than or equal to the value specified by Alice. Note: Bob MUST place his Base64 encoded values of &NsubB; and d in the 'my_nonce' and 'keys' fields. Bob MUST NOT return Alice's values of e.</p></li>
<p>Bob MUST encapsulate the Base64 encoded values of &CsubA; and Alice's &NsubA; in two new 'counter' and 'nonce' fields and add them to &formB;. He MUST set the 'pk_hash' field to specify whether or not <em>Alice</em> MUST send the fingerprint of her public signature-verification key instead of her full key. He MUST set the value of the 'rekey_freq' field to be less than &twosup32; and greater than or equal to the value specified by Alice. Bob MUST place his Base64 encoded values of &NsubB; and d in the 'my_nonce' and 'keys' fields. Note: Bob MUST NOT return Alice's values of &NsubA; and e in these fields.</p></li>
<li><p>Concatenate Alice's ESession ID, Bob's ESession ID, d, &pubKeyB; and &formB;, and calculate the HMAC (as defined in Section 2 of &rfc2104;) of the resulting byte string using the selected hash algorithm ("HASH") and the key &KSsubB;.</p>
<code>&macB; = <em>HMAC</em>(HASH, &KSsubB;, {&NsubA;, &NsubB;, d, &pubKeyB;, &formB;})</code></li>
<li><p>Calculate &signB;, the signature of the HMAC result using his private signature key that corresponds to &pubKeyB;</p>
@ -367,6 +380,7 @@
<p>Bob responds to Alice by sending her &formB;.</p>
<example caption='Bob Responds to Alice (4-Message Negotiation)'><![CDATA[
<message from='bob@example.com/laptop' to='alice@example.org/pda'>
<thread>ffd7076498744578d10edabfe7f4a866</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x type='submit' xmlns='jabber:x:data'>
<field var="FORM_TYPE">
@ -374,6 +388,7 @@
</field>
<field var="accept"><value>1</value></field>
<field var="otr"><value>true</value></field>
<field var="disclosure"><value>never</value></field>
<field var="security"><value>e2e</value></field>
<field var="modp"><value>5</value></field>
<field var="crypt_algs"><value>aes256-ctr</value></field>
@ -385,13 +400,13 @@
<field var="ver"><value>1.3</value></field>
<field var="rekey_freq"><value>50</value></field>
<field var="my_nonce">
<value> ** Base64 encoded ESession ID ** </value>
<value> ** Bob's Base64 encoded ESession ID ** </value>
</field>
<field var="keys">
<value> ** Base64 encoded value of d ** </value>
</field>
<field var="nonce">
<value> ** Base64 encoded ESession ID ** </value>
<value> ** Alice's Base64 encoded ESession ID ** </value>
</field>
<field var="counter">
<value> ** Base64 encoded block counter ** </value>
@ -403,6 +418,7 @@
<p>If Bob prefers the RECOMMENDED 3-message ESession negotiation, where Alice's identity is protected from active attacks instead of his own, then he should encapsulate the Base64 encoded values of &IDB; and &MsubB; in data form fields ('identity' and 'mac'), and append the new fields to &formB; before sending it to Alice.</p>
<example caption='Bob Responds to Alice (3-Message Negotiation)'><![CDATA[
<message from='bob@example.com/laptop' to='alice@example.org/pda'>
<thread>ffd7076498744578d10edabfe7f4a866</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x type='submit' xmlns='jabber:x:data'>
<field var="FORM_TYPE">
@ -410,6 +426,7 @@
</field>
<field var="accept"><value>1</value></field>
<field var="otr"><value>true</value></field>
<field var="disclosure"><value>never</value></field>
<field var="security"><value>e2e</value></field>
<field var="modp"><value>5</value></field>
<field var="crypt_algs"><value>aes256-ctr</value></field>
@ -421,13 +438,13 @@
<field var="ver"><value>1.3</value></field>
<field var="rekey_freq"><value>50</value></field>
<field var="my_nonce">
<value> ** Base64 encoded ESession ID ** </value>
<value> ** Bob's Base64 encoded ESession ID ** </value>
</field>
<field var="keys">
<value> ** Base64 encoded value of d ** </value>
</field>
<field var="nonce">
<value> ** Base64 encoded ESession ID ** </value>
<value> ** Alice's Base64 encoded ESession ID ** </value>
</field>
<field var="counter">
<value> ** Base64 encoded block counter ** </value>
@ -484,10 +501,11 @@
<p>Alice MUST send the Base64 encoded values of &NsubB;, &IDA; and &MsubA; to Bob. If Alice has already confirmed Bob's identity (i.e. if Bob included 'identity' and 'mac' fields in his response), then she MAY also send encrypted content (see <link url='#exchange'>Exchanging Stanzas</link>) in the same stanza as the proof of her identity.</p>
<example caption='Alice Sends Bob Her Identity'><![CDATA[
<message from='alice@example.org/pda' to='bob@example.com/laptop'>
<thread>ffd7076498744578d10edabfe7f4a866</thread>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x type='result' xmlns='jabber:x:data'>
<field var="FORM_TYPE"><value>http://jabber.org/protocol/chatneg</value></field>
<field var="nonce"><value> ** Base64 encoded ESession ID ** </value></field>
<field var="nonce"><value> ** Bob's Base64 encoded ESession ID ** </value></field>
<field var="identity"><value> ** Encrypted identity ** </value></field>
<field var="mac"><value> ** Integrity of identity ** </value></field>
</x>
@ -508,10 +526,11 @@
<p>Otherwise, one more step is necessary. Bob MUST send Alice the Base64 encoded values of &NsubA;, &IDB; and &MsubB; that he calculated previously (see <link url='#init-hide'>Hiding Identity</link>). Note: He MAY also send encrypted content (see <link url='#exchange'>Exchanging Stanzas</link>) in the same stanza.</p>
<example caption='Bob Sends Alice His Identity'><![CDATA[
<message from='bob@example.com/laptop' to='alice@example.org/pda'>
<thread>ffd7076498744578d10edabfe7f4a866</thread>
<init xmlns='http://jabber.org/protocol/esession#init'>
<x type='result' xmlns='jabber:x:data'>
<field var="FORM_TYPE"><value>http://jabber.org/protocol/chatneg</value></field>
<field var="nonce"><value> ** Base64 encoded ESession ID ** </value></field>
<field var="nonce"><value> ** Alice's Base64 encoded ESession ID ** </value></field>
<field var="identity"><value> ** Encrypted identity ** </value></field>
<field var="mac"><value> ** Integrity of identity ** </value></field>
</x>
@ -526,11 +545,12 @@
<section1 topic="Exchanging Stanzas" anchor='exchange'>
<section2 topic="Encryptable Content" anchor='exchange-separate'>
<p>Once ESession negotiation is complete, Alice and Bob MUST exchange only encrypted forms of the one-to-one stanza types they agreed upon (e.g., &MESSAGE; and &IQ; stanzas).</p>
<p>Either Alice or Bob MAY send encrypted stanzas. Here we describe the process where Alice sends Bob an encrypted stanza. She MUST only encrypt the XML content that would normally be ignored by the intermediate servers. She MUST NOT encrypt stanza wrapper elements or <cite>Advanced Message Processing</cite> elements.</p>
<p>Either Alice or Bob MAY send encrypted stanzas. Here we describe the process where Alice sends Bob an encrypted stanza. She MUST only encrypt the XML content that would normally be ignored by the intermediate servers. She MUST NOT encrypt stanza wrapper elements (only their content), &THREAD; or <cite>Advanced Message Processing</cite> elements.</p>
<example caption='Unencrypted Stanza'><![CDATA[
<message from='alice@example.org/pda'
to='bob@example.com/laptop'
type='chat'>
<thread>ffd7076498744578d10edabfe7f4a866</thread>
<body>Hello, Bob!</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='error' condition='match-resource' value='exact'/>
@ -574,6 +594,7 @@
<message from='alice@example.org/pda'
to='bob@example.com/laptop'
type='chat'>
<thread>ffd7076498744578d10edabfe7f4a866</thread>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data> ** Base64 encoded m_final ** </data>
<mac> ** Base64 encoded a_mac ** </mac>
@ -626,6 +647,7 @@
<p>Note: There is no need for Alice to provide a signature because the calculation of the MAC includes the new value of e, see <link url='#exchange'>Exchanging Stanzas</link>).</p>
<example caption='Alice Sends Re-Key Stanza'><![CDATA[
<message from='alice@example.org/pda' to='bob@example.com/laptop'>
<thread>ffd7076498744578d10edabfe7f4a866</thread>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data> ** Base64 encoded m_final ** </data>
<key> ** Base64 encoded value of new e ** </key>
@ -645,6 +667,7 @@
<p>The next time Bob sends Alice a stanza he MUST specify the number of rekeys he has received from her since he sent her his last stanza. He does that by setting the 'rekeys' attribute of the &lt;data/&gt; element. Note: The default value of the 'rekeys' attribute is zero.</p>
<example caption="Bob's First Stanza After Receiving a Re-Key"><![CDATA[
<message from='bob@example.com/laptop' to='alice@example.org/pda'>
<thread>ffd7076498744578d10edabfe7f4a866</thread>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data rekeys='1'> ** Base64 encoded m_final ** </data>
<mac> ** Base64 encoded b_mac ** </mac>
@ -658,6 +681,7 @@
<p>Either entity MAY publish old values of &KMsubA; and/or &KMsubB; within any encrypted stanza as long as it knows that all the stanzas that MAY use the old values have been received and validated. Note: A 'man-in-the-middle' could delay the delivery of stanzas indefinitely. So, before Alice publishes &KMsubA; (and &KMsubB;), she MUST wait until she has both sent a re-key to Bob and received a stanza from Bob encrypted with her new key. (She MAY also publish &KMsubB; after she has received a re-key from Bob.)</p>
<example caption='Publishing Expired MAC Keys'><![CDATA[
<message from='alice@example.org/pda' to='bob@example.com/laptop'>
<thread>ffd7076498744578d10edabfe7f4a866</thread>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data> ** Base64 encoded m_final ** </data>
<old> ** Base64 encoded old MAC key ** </old>
@ -674,6 +698,7 @@
<p>Either entity MAY terminate an ESession at any time. Entities MUST terminate all open ESessions before they go offline. To terminate an ESession Alice MUST send an encrypted stanza to Bob including within the encrypted XML of the &lt;data/&gt; element a chat negotiation form with a "terminate" field (as specified in the Termination section of <cite>Chat Session Negotiation</cite>). Note: She MAY publish old values of &KMsubA; and/or &KMsubB; within her termination stanza as long as she is sure all the stanzas that MAY use the old values have been received and validated (see <link url='#rekey-publish'>Publishing Old MAC Values</link>). She MUST then securely destroy all keys associated with the ESession.</p>
<example caption='Alice Terminates an ESession'><![CDATA[
<message from='alice@example.org/pda' to='bob@example.com/laptop'>
<thread>ffd7076498744578d10edabfe7f4a866</thread>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data> ** Base64 encoded encrypted terminate form ** </data>
<old> ** Base64 encoded old MAC key ** </old>
@ -684,6 +709,7 @@
<p>When Bob receives a termination stanza he MUST verify the MAC (to be sure he received all the stanzas Alice sent him during the ESession) and immediately send an encrypted termination acknowledgement form (as specified in the Termination section of <cite>Chat Session Negotiation</cite>) back to Alice. Note: He MAY publish <em>any</em> old values of &KMsubA; or &KMsubB; within the acknowledgement stanza. He MUST then securely destroy all keys associated with the ESession.</p>
<example caption='Bob Acknowledges ESession Termination'><![CDATA[
<message from='bob@example.com/laptop' to='alice@example.org/pda'>
<thread>ffd7076498744578d10edabfe7f4a866</thread>
<encrypted xmlns='http://jabber.org/protocol/esession'>
<data> ** Base64 encoded encrypted acknowledgement form ** </data>
<old> ** Base64 encoded old MAC key ** </old>
@ -771,14 +797,21 @@
<p>Alice and Bob MUST ensure that the value of e or d they provide when negotiating each online ESession is unique. This prevents complete online ESessions being replayed.</p>
</section2>
<section2 topic='Unencrypted ESessions' anchor='sec-unencrypted'>
<p>Organisations with full disclosure policies may require entities to disable encryption to enable the logging of all messages on their server. Unencrypted ESessions meet all the <link url='#reqs-sec'>Security Requirements</link> except for Confidentiality. Unencrypted ESessions enable Alice to to confirm <em>securely</em> with Bob that both client-server connections are secure. i.e. that the value of the 'security' option (as specified in <cite>Chat Session Negotiation</cite>) has not been tampered with.</p>
<p>Organisations with full disclosure policies may require entities to disable encryption (see <link url='#sec-backdoor'>Back Doors</link>) to enable the logging of all messages on their server. Unencrypted ESessions meet all the <link url='#reqs-sec'>Security Requirements</link> except for Confidentiality. Unencrypted ESessions enable Alice to to confirm <em>securely</em> with Bob that both client-server connections are secure. i.e. that the value of the 'security' option (as specified in <cite>Chat Session Negotiation</cite>) has not been tampered with.</p>
</section2>
<section2 topic='Storage' anchor='sec-storage'>
<p>If either entity stores a (re-encrypted) transcript of an ESession for future consultation then the Perfect Forward Secrecy offered by this protocol is lost. If the negotiated value of the 'otr' <cite>Chat Session Negotiation</cite> field is 'true' the entities SHOULD NOT store any part of the ESession content (not even in encrypted form).</p>
<p>If either entity stores a (re-encrypted) transcript of an ESession for future consultation then the Perfect Forward Secrecy offered by this protocol is lost. If the negotiated value of the 'otr' <cite>Chat Session Negotiation</cite> field is 'true' the entities MUST NOT store any part of the ESession content (not even in encrypted form).</p>
</section2>
<section2 topic='Extra Responsabilities of Implementors' anchor='sec-general'>
<p>Cryptography plays only a small part in an entity's security. Even if it implements this protocol perfectly it may still be vulnerable to other attacks. For examples, an implementation might store ESession keys on swap space or save private keys to a file in cleartext! Implementors MUST take very great care when developing applications with secure technologies.</p>
</section2>
<section2 topic="Back Doors" anchor="sec-backdoor">
<p>The authors and the XSF would like to discourage the deliberate inclusion of "back doors" in implementations of this protocol. However, we recognize that some organizations must monitor chats or record chats in decryptable form for legal compliance reasons, or may choose to monitor chats for quality assurance purposes. In these cases it is important to inform the other entity of the disclosure before starting the ESession (if only to maintain public confidence in this protocol).</p>
<p>Both implementations MUST immediately and clearly inform their users if the negotiated value of the 'disclose' field is not 'never'.</p>
<p>Before disclosing any chat, an entity SHOULD either negotiate the value of the 'disclose' field to be 'enabled' or terminate the negotiation unsuccessfully. It MUST NOT negotiate the value of the 'disclose' field to be 'disabled' unless it would be illegal for it to divulge the disclosure to the other entity.</p>
<p>In any case an implementation MUST NOT negotiate the value of the 'disclose' field to be 'never' unless it implements no feature or mechanism (not even a disabled feature or mechanism) that could be used directly or indirectly to divulge to <em>any</em> third-party either the identites of the participants, or the keys, or the content of <em>any</em> ESession (or information that could be used to recover any of those items). If an implementation deliberately fails to observe this last point (or fails to correct an accidental back door) then it is not compliant with this protocol and MUST NOT either claim or imply any compliance with this protocol or any of the other protocols developed by the authors or the XSF. In this case the authors and the XSF reserve all rights regarding the names of the protocols.</p>
<p>The expectation is that this legal requirement will persuade many implementors either to tell the users of their products that a back door exists, or not to implement a back door at all (if, once informed, the market demands that).</p>
</section2>
<section2 topic='Mandatory to Implement Technologies' anchor='sec-mandatory'>
<p>An implementation of ESession MUST support the Diffie-Hellman Key Agreement and HMAC algorithms. Note: The parameter names mentioned below are related to secure shell; see <cite>SSH Transport Layer Encryption Modes</cite> for block cipher algorithm details; see the &ianassh; for other names.</p>
<section3 topic='Block Cipher Algorithms' anchor='sec-mandatory-encryption'>