This document explains how to generate and validate dialback keys
WARNING: This Informational JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the best practice or protocol profile described herein is encouraged in exploratory implementations, although production systems should not deploy implementations of this protocol until it advances to a status of Draft.
Status: Experimental
Type: Informational
Number: 0185
Version: 0.1
Last Updated: 2006-04-11
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: Not yet assigned
Wiki Page: <http://wiki.jabber.org/index.php/Dialback Key Generation and Validation (JEP-0185)>
Email:
fippo@goodadvice.pages.de
JID:
fippo@goodadvice.pages.de
This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/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-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software 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 JEP 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 keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
RFC 3920 [1] does not specify how to generate the keys used in the 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 Authorative 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, Authorative Server and optionally a third party like a database.
Based on
RFC 3920 leaves it to the implementation how the key is generated.
The last item, a shared secret known to Originating Server and Authorative Server is static and can be set up in a configuration option for each host or process. If there is no configured secret, a random one MUST be generated when starting the server.
To protect this secret's confidentiality, a hash algorithm SHOULD be used in the key generation method. The choice which algorithm to use is left to the implementation, but usage of the SHA1 algorithm described in RFC 3174 [2] is recommended.
The input to the hash algorithm is a string concatenation of all factors mentioned above. The order in which those are concatenated or any character separators inserted during concatenation is up to the implementation. To avoid problems of encoding, a hexadecimal representation of the digest algorithm output SHOULD be used.
The examples in this document will use the SHA1 algorithm and separate the factors by a colon, similar to RFC 2831 [3]:
key = HEX( H({ ID, ":", hostname of Receiving Server, ":",
hostname of Originating or Authorative server, ":", secret} ) )
The secret used in the examples is "thesecret"
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:
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
to='example.com'
from='example.org'
id='457F9224A0'>
The Originating Server now generates a dialback key to be sent to the Receiving Server:
key = SHA1({ ID, ':', receiving server, ':', originating server, ':', secret })
= SHA1({ '457F9224A0', ':', 'example.com', ':',
'example.org', ':', 'thesecret' })
= SHA1('457F9224A0:example.com:example.org:thesecret')
= 'f19f09ad8a0d7c4778eff54ee5727c2d660ceeb2'
4. The Originating Server sends the generated dialback key to the Receiving Server:
<db:result
to='example.com'
from='example.org'>
f19f09ad8a0d7c4778eff54ee5727c2d660ceeb2
</db:result>
8. The Receiving Server sends the Authorative Server a request for verification of the key:
<db:verify
to='example.org'
from='example.com'
id='457F9224A0'>
f19f09ad8a0d7c4778eff54ee5727c2d660ceeb2
</db:verify>
The Authorative Server calculates the valid key for this verify request, using data supplied in the packet and the secret shared with the Originating Server.
key = SHA1({ ID, ':', Receiving Server, ':', Authorative Server, ':', secret })
= SHA1({ '457F9224A0', ':', 'example.com', ':',
'example.org', ':', 'thesecret' })
= SHA1('457F9224A0:example.com:example.org:thesecret')
= 'f19f09ad8a0d7c4778eff54ee5727c2d660ceeb2'
9. The Authorative 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
from='example.org'
to='example.com'
id='457F9224A0'
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 Authorative Server acknowlegdes as valid. If this is successful, the attacker is allowed to send packets for the hostname of the Authorative Server.
In each subsection, the example hash method ignores one of the variables,
by using an empty string instead, and it is shown how an attacker might exploit this behavior to get a valid result from the Authorative 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({ ID, ':', hostname of receiving server, ':', empty string, ':', secret })
The dialback keys generated for the originating domains 'example.org' and 'example.net' are the same, which might disclose that the secret used to generate the keys for these domains is equal. An attacker can not exploit this any further.
<db:verify
to='example.org'
from='example.com'
id='4a4a6813131'>
d46bd18b327a65b609eda23419310719597a7838
</db:verify>
This key is generated using the empty string instead of the originating domain name:
SHA1('4a4a6813131:example.com::thesecret') =
'd46bd18b327a65b609eda23419310719597a7838'
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({ empty string, ':', hostname of receiving server, ':',
hostname of originating server, ':', secret })
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.org'
from='example.com'
id='434afab75131f'>
f9864ed156570ee8b505fad8d5d17374d513371b
</db:verify>
This key is generated using the empty string instead of the id:
SHA1(':example.com:example.org:thesecret') =
'f9864ed156570ee8b505fad8d5d17374d513371b'
This key is also valid for
<db:verify
to='example.org'
from='example.com'
id='anyidyouwant'>
f9864ed156570ee8b505fad8d5d17374d513371b
</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({ ID, ':', empty string, ':',
hostname of originating server, ':', secret })
The attacker can use a dialback key and stream ID we have sent a domain under his control.
<db:verify
to='example.org'
from='example.com'
id='abag32325bg1'>
67cdeb22c9300b52a9ec466f7878adc2d318fd8a
</db:verify>
This key is generated using the empty string instead of the receiving domain:
SHA1('abag32325bg1::example.org:thesecret') =
'67cdeb22c9300b52a9ec466f7878adc2d318fd8a'
If the key generation method does not take into account a shared secret in the Authorative Servers network or if this secret is disclosed and the key generation method is known, an attacker can generate valid dialback keys.
key = SHA1({ ID, ':', hostname of receiving server, ':',
hostname of originating server, ':', empty string})In both cases the attacker is able to generate an arbitrary number of dialback keys.
<db:verify
to='example.org'
from='example.com'
id='aqtqrq13'>
1f44ba7a2eca0e7f9908e18d239ed5c2ad9fe9c1
</db:verify>
This key is generated for the empty string instead of the secret:
SHA1('aqtqrq13:example.com:example.org:') =
'1f44ba7a2eca0e7f9908e18d239ed5c2ad9fe9c1'
This JEP 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 JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [4].
This JEP requires no interaction with the Jabber Registrar [5].
1. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.
2. RFC 3174: US Secure Hash Algorithm 1 (SHA1) <http://www.ietf.org/rfc/rfc3174.txt>.
3. RFC 2831: Using Digest Authentication as a SASL Mechanism <http://www.ietf.org/rfc/rfc2831.txt>.
4. 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/>.
5. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
Initial JEP version.
(psa)First draft.
(ph)END