mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-22 07:38:52 -05:00
0.6 RC1 both isPKA and isPKB
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@870 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
parent
d92cee7d7f
commit
06d8724514
20
xep-0188.xml
20
xep-0188.xml
@ -67,6 +67,12 @@
|
|||||||
<supersededby>None</supersededby>
|
<supersededby>None</supersededby>
|
||||||
<shortname>cryptoesession</shortname>
|
<shortname>cryptoesession</shortname>
|
||||||
&ianpaterson;
|
&ianpaterson;
|
||||||
|
<revision>
|
||||||
|
<version>0.6</version>
|
||||||
|
<date>2007-05-30</date>
|
||||||
|
<initials>ip</initials>
|
||||||
|
<remark><p>SIGMA-R negotiates both isPKA and isPKB fields</p></remark>
|
||||||
|
</revision>
|
||||||
<revision>
|
<revision>
|
||||||
<version>0.5</version>
|
<version>0.5</version>
|
||||||
<date>2007-04-20</date>
|
<date>2007-04-20</date>
|
||||||
@ -100,7 +106,7 @@
|
|||||||
</header>
|
</header>
|
||||||
|
|
||||||
<section1 topic='Introduction' anchor='intro'>
|
<section1 topic='Introduction' anchor='intro'>
|
||||||
<p><em>Note: The protocols developed according to the cryptographic design described in this document are described in &xep0116;, &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><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>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>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>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>
|
||||||
@ -393,7 +399,7 @@ K = HASH(&dsupx; mod p)
|
|||||||
<section2 topic='SIGMA-R with SAS Key Exchange' anchor='foundations-core-r'>
|
<section2 topic='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>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>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 <link url='#foundations-skeleton-r'>SIGMA-R Overview</link>. It provides much more detail including the use of retained secrets and other secrets. Note: These <em>optional</em> security enhancements are especially important when the protocol is being used without public keys.</p>
|
<p>Public keys are optional in the diagram below. It describes the same SIGMA-R with SAS key exchange protocol as the <link url='#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 <link url='#foundations-core-i'>SIGMA-I Key Exchange</link> are highlighted.</p>
|
<p>The diagram does not specify any ESession-specific details. The differences between it and the <link url='#foundations-core-i'>SIGMA-I Key Exchange</link> are highlighted.</p>
|
||||||
<pre>
|
<pre>
|
||||||
<strong>ALICE</strong>  <strong>BOB</strong> 
|
<strong>ALICE</strong>  <strong>BOB</strong> 
|
||||||
@ -404,7 +410,7 @@ e = &gsupx; mod p
|
|||||||
<span class='highlight'>He = SHA256(e)
|
<span class='highlight'>He = SHA256(e)
|
||||||
He, &isPKsubA;</span>
|
He, &isPKsubA;</span>
|
||||||
------------>
|
------------>
|
||||||
&NsubA; 
|
<span class='highlight'>&isPKsubB;,</span> &NsubA; 
|
||||||
&NsubB; = <em>random</em>()
|
&NsubB; = <em>random</em>()
|
||||||
&CsubA; = <em>random</em>()
|
&CsubA; = <em>random</em>()
|
||||||
&CBeCAx2n1; 
|
&CBeCAx2n1; 
|
||||||
@ -412,7 +418,7 @@ e = &gsupx; mod p
|
|||||||
d = &gsupy; mod p
|
d = &gsupy; mod p
|
||||||
d, &CsubA;, &NsubB;
|
d, &CsubA;, &NsubB;
|
||||||
<------------
|
<------------
|
||||||
<span class='highlight'>&isPKsubB;</span> 
|
<span class='highlight'>&isPKsubA;, &isPKsubB;</span> 
|
||||||
&CBeCAx2n1; 
|
&CBeCAx2n1; 
|
||||||
<em>assert</em> 1 < d < p-1
|
<em>assert</em> 1 < d < p-1
|
||||||
K = HASH(&dsupx; mod p)
|
K = HASH(&dsupx; mod p)
|
||||||
@ -635,19 +641,19 @@ VERIFY(&signB;, &pubKeyB;, &macB;)</span> 
|
|||||||
x = <em>random</em>()
|
x = <em>random</em>()
|
||||||
e = &gsupx; mod p
|
e = &gsupx; mod p
|
||||||
<span class='highlight'>He = SHA256(e)</span> 
|
<span class='highlight'>He = SHA256(e)</span> 
|
||||||
&formA; = {<span class='highlight'>&He1HeZ;</span>, options, &NsubA;, <span class='highlight'>&isPKsubA;</span>}
|
&formA; = {<span class='highlight'>&He1HeZ;</span>, options, &NsubA;}
|
||||||
|
|
||||||
&formA;
|
&formA;
|
||||||
------------>
|
------------>
|
||||||
|
|
||||||
chosen = {p,g,HASH,CIPHER,SIGN,SASGEN...} = <em>choose</em>(options)
|
chosen = {p,g,HASH,CIPHER,SIGN,SASGEN,<span class='highlight'>&isPKsubA;,&isPKsubB;</span>...} = <em>choose</em>(options)
|
||||||
<span class='highlight'>He</span> = <em>choose</em>(<span class='highlight'>&He1HeZ;</span>, p)
|
<span class='highlight'>He</span> = <em>choose</em>(<span class='highlight'>&He1HeZ;</span>, p)
|
||||||
&NsubB; = <em>random</em>()
|
&NsubB; = <em>random</em>()
|
||||||
&CsubA; = <em>random</em>()
|
&CsubA; = <em>random</em>()
|
||||||
&CBeCAx2n1; 
|
&CBeCAx2n1; 
|
||||||
y = <em>random</em>()
|
y = <em>random</em>()
|
||||||
d = &gsupy; mod p
|
d = &gsupy; mod p
|
||||||
&formB; = {&CsubA;, chosen, d, &NsubA;, &NsubB;, <span class='highlight'>&isPKsubB;</span>}
|
&formB; = {&CsubA;, chosen, d, &NsubA;, &NsubB;}
|
||||||
&formB;
|
&formB;
|
||||||
<------------
|
<------------
|
||||||
<em>assert</em> chosen ∈ options
|
<em>assert</em> chosen ∈ options
|
||||||
|
Loading…
Reference in New Issue
Block a user