Dialback Key Generation and Validation

%ents; ]>

Dialback Key Generation and Validation This document explains how to generate and validate the keys used in the XMPP server dialback protocol. &LEGALNOTICE; 0185 Experimental Informational Standards JIG Council XMPP Core N/A Philipp Hancke fippo@goodadvice.pages.de fippo@goodadvice.pages.de 0.2 ph 2006-05-10

Clarified and corrected roles of originating and receiving servers; updated recommendation and main example to use HMAC-SHA256 for key generation.

0.1 2006-04-11 psa

Initial version.

0.0.1 2006-03-30 ph

First draft.

&BISNOTE;

RFC 3920 does not specify 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 supercede the text in RFC 3920.

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.

The key is generated based on

the (hostname of) Originating Server,
the (hostname of) Receiving Server,
the Stream ID,
and a secret known by the Authoritative Server's network.

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. &nistfips198a; recommends that the length of the key should be at least half of the size of the hash function output.

The recommended hash for usage in HMAC is SHA-256 described in &nistfips180-2;, hence the secret's length should be at least 128 bits or 16 characters long.


key = HEX( HMAC-SHA256( Secret, { Stream ID, 
           Receiving Server, Originating or Authoritative server } ) )

To avoid problems of encoding, a hexadecimal representation of the digest algorithm output SHOULD be used.

Originating and Authoritative Server	example.com
Receiving Server	example.org
Secret	thesecret
Stream ID	457F9224A0

This document closely follows the description of the dialback protocol in RFC 3920, 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 RFC 3920.

3. Receiving Server sends a stream header back to the Originating Server, including a unique ID for this interaction:

]]>

The Originating Server now generates a dialback key to be sent to the Receiving Server:


key = HMAC-SHA256( secret, { Receiving server, Originating server, Stream ID})
    = HMAC-SHA256( 'thesecret', { 'example.org', 'example.com', '457F9224A0' })
    = HMAC-SHA256( 'thesecret', { 'example.orgexample.com457F9224A0' })
    = 'a85748c59049b700dfa728da3eae5ea93aac1e0fc89713b490e441486653dd8c'

4. The Originating Server sends the generated dialback key to the Receiving Server:


    a85748c59049b700dfa728da3eae5ea93aac1e0fc89713b490e441486653dd8c

    ]]>

8. The Receiving Server sends the Authoritative Server a request for verification of the key:


    a85748c59049b700dfa728da3eae5ea93aac1e0fc89713b490e441486653dd8c

    ]]>

The Authoritative Server calculates the valid key for this verify request, using data supplied in the packet and the secret shared with the Originating Server.


key = HMAC-SHA256( secret, { Receiving Server, Authoritative Server, Stream ID })
    = HMAC-SHA256( 'thesecret', { 'example.org', 'example.com', '457F9224A0' })
    = HMAC-SHA256( 'thesecret', { 'example.orgexample.com457F9224A0' })
    = 'a85748c59049b700dfa728da3eae5ea93aac1e0fc89713b490e441486653dd8c'

9. The Authoritative Server compares this value to the key contained in the verification requests and informs the Originating Server of the result, in our example a success:

]]>

This section contains attack scenarios that illustrate why each of the factors used in key generation is important.

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.

In each subsection, the example hash method, which uses the SHA1 algorithm as described in &rfc3174; for simplicity, ignores one of the variables,

Originating Server,
Stream ID,
Receiving Server,
or Secret,

and it is shown how an attacker might exploit this behavior to get a valid result from the Authoritative Server.

This subsection demonstrates what can happen if the key generation method ignores the hostname of the Originating Server, e.g. for the hash function


key = SHA1({ Secret, Receiving Server, Stream ID })

The dialback keys generated for the originating domains 'example.com' and 'example.net' 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.

 
    807ccee5541ed9332559513797df75c1dd18ae8e

    ]]>

This key is generated using:


SHA1('thesecretexample.org457F9224A0') = 
	    '807ccee5541ed9332559513797df75c1dd18ae8e'

This subsection demonstrates a replay attack that is possible if the key generation method ignores the Stream ID, e.g. for the hash function


key = SHA1({ Secret, Receiving Server, Originating Server })

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.

 
    14cbd71d0f127be89b7004c2242424918d8fad95

    ]]>

This key is generated using the empty string instead of the id:


SHA1('thesecretexample.orgexample.com') = 
	    '14cbd71d0f127be89b7004c2242424918d8fad95'

This key is also valid for


    14cbd71d0f127be89b7004c2242424918d8fad95

    ]]>

This subsection demonstrates against a key generation method that ignores the hostname of the receiving server, e.g. for the hash function


key = SHA1({ Secret, Originating Server, Stream ID })

The attacker can use a dialback key and stream ID we have sent a domain under his control.

 
    c04ca426a81b3fa04bd4a9df2e24482372b4b874

    ]]>

This key is generated using:


SHA1('thesecretexample.com457F9224A0') = 
	    'c04ca426a81b3fa04bd4a9df2e24482372b4b874'

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.


key = SHA1({ Receiving Server, Originating Server, Stream ID })

In both cases the attacker is able to generate an arbitrary number of dialback keys.

 
    30e59d3ee62926a29f012822769e58e67571d750

    ]]>

This key is generated using:


SHA1('example.orgexample.com457F9224A0') = 
	    '30e59d3ee62926a29f012822769e58e67571d750'

This document introduces no security considerations or concerns above and beyond those discussed in RFC3920, but describes what might happen if the security considerations are ignored.

This document requires no interaction with &IANA;.

This document requires no interaction with the ®ISTRAR;.