Modified order of explanation to ease understanding; removed discussion of alternate algorithms, which is better left to a more in-depth security analysis.
+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.
+&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 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 process for generating and validating a dialback key SHOULD take into account the following four inputs:
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 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.
+In particular, the following algorithm is RECOMMENDED:
key = HMAC-SHA256
(
SHA256(Secret),
{
Receiving Server, ' ',
- Originating or Authoritative server, ' ',
+ Originating Server, ' ',
Stream ID
}
)
- To avoid encoding problems, the digest algorithm output MUST be provided in the hexadecimal representation.
+Note the following:
+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.
+This document closely follows the description of the dialback protocol in RFC 3920 and rfc3920bis, 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 and Appendix C.3 of rfc3920bis. Any line breaks in the examples are included for the purpose of readability only.
The following data values are used in the examples: