This document provides a recommended method for generating and validating the keys used in the XMPP server dialback protocol.
NOTICE: This document is currently within Last Call or under consideration by the XMPP Council for advancement to the next stage in the XSF standards process.
Series: XEP
Number: 0185
Publisher: XMPP Standards Foundation
Status:
Proposed
Type:
Informational
Version: 0.3
Last Updated: 2006-11-01
Approving Body: XMPP Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: N/A
Wiki Page: <http://wiki.jabber.org/index.php/Dialback Key Generation and Validation (XEP-0185)>
Email:
fippo@goodadvice.pages.de
JID:
fippo@goodadvice.pages.de
This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy <http://www.xmpp.org/extensions/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
Note: This document describes a protocol or best practice that is intended for incorporation into the specification that will supersede RFC 3920 [1] within the Internet Standards Process, i.e., rfc3920bis [2]. This document is provided only for the purpose of open community discussion of the potential modification and will be obsoleted as soon as the relevant RFC is published.
RFC 3920 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 RFC 3920; however, the recommendations in this document have been incorporated into rfc3920bis.
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 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.
The Keyed-Hash Message Authentication Code (HMAC) [3] 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.
The Stream ID and the involved hostnames should be concatenated with a unicode space character (U+0020) for the delimiter.
key = HEX( HMAC-SHA256( SHA256(Secret), { Receiving Server, ' ',
Originating or Authoritative server, ' ', Stream ID } ) )
To avoid problems of encoding, a hexadecimal representation of the digest algorithm output SHOULD be used.
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. Any line breaks in the examples are included for the purpose of readability only.
The following data values are used in the examples:
Table 1: Data Used in Examples
| Originating and Authoritative Server | example.com |
| Receiving Server | example.net |
| Secret | s3cr3tf0rd14lb4ck |
| Stream ID | D60000229F |
3. Receiving Server sends a stream header back to the Originating Server, including a unique ID for this interaction:
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
to='example.com'
from='example.net'
id='D60000229F'>
The Originating Server now generates a dialback key to be sent to the Receiving Server:
key = HMAC-SHA256(
SHA256(secret),
{ Receiving server, ' ', Originating server, ' ', Stream ID}
)
= HMAC-SHA256(
SHA256('s3cr3tf0rd14lb4ck'),
{ 'example.net', ' ', 'example.com', ' ', 'D60000229F' }
)
= HMAC-SHA256(
'a7136eb1f46c9ef18c5e78c36ca257067c69b3d518285f0b18a96c33beae9acc',
'example.net example.com D60000229F'
)
= '008c689ff366b50c63d69a3e2d2c0e0e1f8404b0118eb688a0102c87cb691bdc'
4. The Originating Server sends the generated dialback key to the Receiving Server:
<db:result
to='example.net'
from='example.com'>
008c689ff366b50c63d69a3e2d2c0e0e1f8404b0118eb688a0102c87cb691bdc
</db:result>
8. The Receiving Server sends the Authoritative Server a request for verification of the key:
<db:verify
to='example.com'
from='example.net'
id='D60000229F'>
008c689ff366b50c63d69a3e2d2c0e0e1f8404b0118eb688a0102c87cb691bdc
</db:verify>
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(
SHA256('s3cr3tf0rd14lb4ck'),
{ 'example.net', ' ', 'example.com', ' ', 'D60000229F' }
)
= HMAC-SHA256(
'a7136eb1f46c9ef18c5e78c36ca257067c69b3d518285f0b18a96c33beae9acc',
'example.net example.com D60000229F'
)
= '008c689ff366b50c63d69a3e2d2c0e0e1f8404b0118eb688a0102c87cb691bdc'
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:
<db:verify
to='example.net'
from='example.com'
id='D60000229F'
type='valid'/>
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 (compromised and NOT RECOMMENDED) SHA1 algorithm as described in RFC 3174 [4] for simplicity, ignores one of the variables,
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.
<db:verify
to='example.com'
from='example.net'
id='D60000229F'>
dba68f5de5b1766d55e70109f42842695bdeb6e4
</db:verify>
This key is generated using:
SHA1('s3cr3tf0rd14lb4ckexample.netD60000229F') =
'dba68f5de5b1766d55e70109f42842695bdeb6e4'
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.
<db:verify
to='example.com'
from='example.net'
id='D60000229F'>
48337750828778765f5e2abbce14a6c5680f2fff
</db:verify>
This key is generated using the empty string instead of the id:
SHA1('s3cr3tf0rd14lb4ckexample.netexample.com') =
'48337750828778765f5e2abbce14a6c5680f2fff'
This key is also valid for
<db:verify
to='example.com'
from='example.net'
id='anyidyouwant'>
48337750828778765f5e2abbce14a6c5680f2fff
</db:verify>
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 to a domain under his control.
<db:verify
to='example.com'
from='example.net'
id='D60000229F'>
eb6c42adee0ced8782175f98a56e4c00b2503602
</db:verify>
This key is generated using:
SHA1('s3cr3tf0rd14lb4ckexample.comD60000229F') =
'eb6c42adee0ced8782175f98a56e4c00b2503602'
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.
<db:verify
to='example.com'
from='example.net'
id='D60000229F'>
c08b18d349a9c4d6aaca2dc3baa772bb7749e3b8
</db:verify>
This key is generated using:
SHA1('example.netexample.comD60000229F') =
'c08b18d349a9c4d6aaca2dc3baa772bb7749e3b8'
This document introduces no security considerations or concerns above and beyond those discussed in RFC 3920, but describes what might happen if the security considerations are ignored.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [5].
This document requires no interaction with the XMPP Registrar [6].
Thanks to Ian Paterson and Matthias Wimmer for their feedback.
1. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.
2. rfc3921bis: proposed revisions to Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/internet-drafts/draft-saintandre-rfc3920bis-00.txt>. (work in progress)
3. The Keyed-Hash Message Authentication Code (HMAC): Federal Information Processing Standards Publication 198 <http://csrc.nist.gov/publications/fips/fips198/fips-198a.pdf>.
4. RFC 3174: US Secure Hash Algorithm 1 (SHA1) <http://www.ietf.org/rfc/rfc3174.txt>.
5. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
6. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://www.xmpp.org/registrar/>.
Recommended hashing the secret to satisfy length requirement; hostnames and Stream ID should be separated by spaces to avoid ambiguity; updated example to match rfc3920bis.
(ph)Clarified and corrected roles of originating and receiving servers; updated recommendation and main example to use HMAC-SHA256 for key generation.
(ph)Initial version.
(psa)First draft.
(ph)END