moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-22 01:02:17 -05:00
Code Issues Releases Wiki Activity

0.4

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@507 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-02-09 19:41:21 +00:00
parent a96a7a6eb8
commit 7dac5b459f
1 changed files with 28 additions and 118 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

146
xep-0185.xml
View File

@ -26,6 +26,14 @@
<email>fippo@goodadvice.pages.de</email>
<jid>fippo@goodadvice.pages.de</jid>
</author>
&stpeter;
<revision>
<version>0.4</version>
<initials>psa/ph</initials>
<date>2007-02-09</date>
<remark><p>Modified order of explanation to ease understanding; removed discussion of alternate algorithms, which is better left to a more in-depth security analysis.</p>
</remark>
</revision>
<revision>
<version>0.3</version>
<initials>ph</initials>
@ -55,36 +63,39 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
&RFC3920BISNOTE;
<p><cite>RFC 3920</cite> does not specify in detail how to generate the keys used in the server dialback protocol, and why each of the variables used in key generation is crucial for security. This document is provided for discussion purposes and aims at clarifying the key generation and its validation mechanism and to show common attacks on weak mechanisms. It is not meant to supersede the text in <cite>RFC 3920</cite>; however, the recommendations in this document have been incorporated into <cite>rfc3920bis</cite>.</p>
<p>&rfc3920; does not specify in detail a recommended algorithm for generating the keys used in the server dialback protocol. This document provides such a recommendation as an aid to implementors of XMPP servers. This document is not meant to supersede any text in <cite>RFC 3920</cite>; however, the recommendations in this document have been incorporated into &rfc3920bis;.</p>
</section1>
<section1 topic='Dialback Explained'>
<p>The Originating Server, which generates the dialback key, and the Authoritative Server, which validates the dialback key, may reside on different hosts or be running in separate processes. The method used in key generation and validation should not require interactive communication between Originating Server, Authoritative Server and optionally a third party like a database.</p>
<p>The key is generated based on:</p>
<section1 topic='Recommended Algorithm' anchor='algorithm'>
<p>The process for generating and validating a dialback key SHOULD take into account the following four inputs:</p>
<ul>
<li>the (hostname of) Originating Server,</li>
<li>the (hostname of) Receiving Server,</li>
<li>the Stream ID,</li>
<li>and a secret known by the Authoritative Server's network.</li>
<li>the hostname of the Originating Server</li>
<li>the hostname of the Receiving Server</li>
<li>the Stream ID generated by the Receiving Server</li>
<li>a secret known by the Authoritative Server's network</li>
</ul>
<p>The last item, a shared secret known to Originating Server and Authoritative Server, is used in a Keyed-Hash Message Authentication Code (HMAC) to generate and validate the dialback keys. This key must either be set up in a configuration option for each host or process, or generated as a random string when starting the server.</p>
<p>&nistfips198a; recommends that the length of the key should be at least half the size of the hash function output. To fulfill this requirement, the secret SHOULD be hashed with the hash function prior to usage as a key in HMAC.</p>
<p>The Stream ID and the involved hostnames should be concatenated with a unicode space character (U+0020) for the delimiter.</p>
<p>In particular, the following algorithm is RECOMMENDED:</p>
<code>
key = HMAC-SHA256
(
SHA256(Secret),
{
Receiving Server, ' ',
Originating or Authoritative server, ' ',
Originating Server, ' ',
Stream ID
}
)
</code>
<p>To avoid encoding problems, the digest algorithm output MUST be provided in the hexadecimal representation.</p>
<p>Note the following:</p>
<ol>
<li>The resulting dialback key is a Keyed-Hash Message Authentication Code (see &nistfips198a;) generated using the SHA256 hashing algorithm (see &nistfips180-2;).</li>
<li>The Secret is used as a "key" within the HMAC generation process; because <cite>HMAC</cite> recommends that the length of the HMAC key should be at least half the size of the hash function output, the Secret SHOULD be hashed via SHA256 prior to use in the in HMAC generation process.</li>
<li>The Secret MUST either be set up in a configuration option for each host or process, or generated as a random string when starting the XMPP server. Creation of the Secret MUST NOT require communication between the Originating Server, the Authoritative Server, and optionally a third party (such as a database).</li>
<li>The output of the SHA256 hashing algorithm MUST be provided in the hexadecimal representation; this helps to avoid encoding problems.</li>
<li>The hostname of the Receiving Server, the hostname of the Originating Server, and the Stream ID SHOULD be concatenated with a Unicode space character (U+0020) as the delimiter; this helps to avoid ambiguity in concatenation. <note>For example, the string "example.inform.example.org" could be construed as a concatenation of "example.info" and "rm.example.org" or of "example.in" and "form.example.org".</note></li>
</ol>
</section1>
<section1 topic='Key Generation and Validation'>
<p>This document closely follows the description of the dialback protocol in <cite>RFC 3920</cite>, but omits steps that are not important for the generation and validation of the dialback keys. For ease of comparison the numbering of the steps is the same as in section 8.3 of <cite>RFC 3920</cite>. Any line breaks in the examples are included for the purpose of readability only.</p>
<section1 topic='Example' anchor='example'>
<p>This document closely follows the description of the dialback protocol in <cite>RFC 3920</cite> and <cite>rfc3920bis</cite>, but omits steps that are not important for the generation and validation of the dialback keys. For ease of comparison the numbering of the steps is the same as in section 8.3 of <cite>RFC 3920</cite> and Appendix C.3 of <cite>rfc3920bis</cite>. Any line breaks in the examples are included for the purpose of readability only.</p>
<p>The following data values are used in the examples:</p>
<table caption='Data Used in Examples'>
<tr>
@ -176,109 +187,8 @@ key = HMAC-SHA256(
type='valid'/>
]]></code>
</section1>
<section1 topic='Attacks Against Key Generation Methods'>
<p>This section contains attack scenarios that illustrate why each of the factors used in key generation is important.</p>
<p>An attacker will assume the role of the Originating Server and try to send a dialback key that the Authoritative Server acknowledges as valid. If this is successful, the attacker is allowed to send packets for the hostname of the Authoritative Server.</p>
<p>In each subsection, the example hash method, which uses the (compromised and NOT RECOMMENDED) SHA1 algorithm as described in &rfc3174; for simplicity, ignores one of the variables,</p>
<ul>
<li>Originating Server,</li>
<li>Stream ID,</li>
<li>Receiving Server,</li>
<li>or Secret,</li>
</ul>
<p>and it is shown how an attacker might exploit this behavior to get a valid result from the Authoritative Server.</p>
<section2 topic='Hostname of Originating Server Not Considered'>
<p>This subsection demonstrates what can happen if the key generation method ignores the hostname of the Originating Server, e.g. for the hash function</p>
<code>
key = SHA1({ Secret, Receiving Server, Stream ID })
</code>
<p>The dialback keys generated for the originating domains 'example.org' and 'xmpp.example.com' are the same, which might disclose that the secret used to generate the keys for these domains is equal. An attacker cannot exploit this any further.</p>
<code><![CDATA[
<db:verify
to='example.org'
from='xmpp.example.com'
id='D60000229F'>
22f8a639f5864d851556c566f52683ac3790bd35
</db:verify>
]]></code>
<p>This key is generated using:</p>
<code>
SHA1('s3cr3tf0rd14lb4ckxmpp.example.comD60000229F') =
'22f8a639f5864d851556c566f52683ac3790bd35'
</code>
</section2>
<section2 topic='Stream ID Not Considered'>
<p>This subsection demonstrates a replay attack that is possible if the key generation method ignores the Stream ID, e.g. for the hash function</p>
<code>
key = SHA1({ Secret, Receiving Server, Originating Server })
</code>
<p>If the attacker is able to obtain a single valid dialback key exchanged between the two domains, this key can be used to validate any stream.</p>
<code><![CDATA[
<db:verify
to='example.org'
from='xmpp.example.com'
id='D60000229F'>
7c39e9cbd28b63676c1ae74e9b98ac229c611cfc
</db:verify>
]]></code>
<p>This key is generated using the empty string instead of the id:</p>
<code>
SHA1('s3cr3tf0rd14lb4ckxmpp.example.comexample.org') =
'7c39e9cbd28b63676c1ae74e9b98ac229c611cfc'
</code>
<p>This key is also valid for</p>
<code><![CDATA[
<db:verify
to='example.org'
from='xmpp.example.com'
id='anyidyouwant'>
7c39e9cbd28b63676c1ae74e9b98ac229c611cfc
</db:verify>
]]></code>
</section2>
<section2 topic='Hostname of the Receiving Server Not Considered'>
<p>This subsection demonstrates against a key generation method that ignores the hostname of the receiving server, e.g. for the hash function</p>
<code>
key = SHA1({ Secret, Originating Server, Stream ID })
</code>
<p>The attacker can use a dialback key and stream ID we have sent to a domain under his control.</p>
<code><![CDATA[
<db:verify
to='example.org'
from='xmpp.example.com'
id='D60000229F'>
ffe5f8139d3eee683068de52481ae61a131e7025
</db:verify>
]]></code>
<p>This key is generated using:</p>
<code>
SHA1('s3cr3tf0rd14lb4ckexample.orgD60000229F') =
'ffe5f8139d3eee683068de52481ae61a131e7025'
</code>
</section2>
<section2 topic='Shared Secret Not Considered'>
<p>If the key generation method does not take into account a shared secret in the Authoritative Servers network or if this secret is disclosed and the key generation method is known, an attacker can generate valid dialback keys.</p>
<code>
key = SHA1({ Receiving Server, Originating Server, Stream ID })
</code>
<p>In both cases the attacker is able to generate an arbitrary number of dialback keys.</p>
<code><![CDATA[
<db:verify
to='example.org'
from='xmpp.example.com'
id='D60000229F'>
65d94be830a9cba41edb50b6f6ec72a89754a2a5
</db:verify>
]]></code>
<p>This key is generated using:</p>
<code>
SHA1('xmpp.example.comexample.orgD60000229F') =
'65d94be830a9cba41edb50b6f6ec72a89754a2a5'
</code>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>This document introduces no security considerations or concerns above and beyond those discussed in <cite>RFC 3920</cite>, but describes what might happen if the security considerations are ignored.</p>
<p>This document introduces no security considerations or concerns above and beyond those discussed in <cite>RFC 3920</cite> and <cite>rfc3920bis</cite>.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>