Server dialback, formerly documented in &rfc3920; but now canonically documented in this specification, is a weak identify verification method that is made possible by the existence of the Domain Name System (DNS), since one server can (normally) discover the authoritative server for a given domain. Dialback is a native XMPP method that occurs over XML streams, with the result that it is more difficult to spoof XMPP server domains and XML stanzas sent over XML streams between servers.

Server dialback is not a security mechanism, and results only in weak verification of server identities. Domains requiring robust security SHOULD use TLS and SASL. If SASL is used for server-to-server authentication, dialback SHOULD NOT be used since it is unnecessary. However, depending on local policies, a service may wish to use dialback to provide weak identity verification in cases where SASL negotiation would not result in strong authentication (e.g., because the certificate presented by the peer service during TLS negotiation is self-signed and thus provides even weaker identity verification than DNS).

Server dialback is uni-directional, and results in weak identity verification for one stream in one direction. Because server dialback is not an authentication mechanism, mutual authentication is not possible via dialback. Therefore, server dialback MUST be completed in each direction in order to enable bi-directional communications between two domains.

The method for generating and verifying the keys used in server dialback MUST take into account the hostnames being used, the stream ID generated by the receiving server, and a secret known by the authoritative server's network; see Dialback Key Generation.

Any error that occurs during dialback negotiation MUST be considered a stream error, resulting in termination of the stream and of the underlying TCP connection. The possible error conditions are specified in the protocol description below.

The following terminology applies:

• ORIGINATING SERVER -- the server that is attempting to establish a connection between two domains.
• RECEIVING SERVER -- the server that is trying to authenticate that the Originating Server represents the domain which it claims to be.
• AUTHORITATIVE SERVER -- the server that answers to the DNS hostname asserted by the Originating Server; for basic environments this will be the Originating Server, but it could be a separate machine in the Originating Server's network (where "network" is defined by knowledge of a shared secret for verification of dialback keys).

The following is a brief summary of the order of events in dialback:

1. The Originating Server establishes an XML stream with the Receiving Server.
2. The Originating Server sends a 'key' value over the connection to the Receiving Server.
3. The Receiving Server establishes an XML stream with the Authoritative Server.
4. The Receiving Server sends the same 'key' value to the Authoritative Server for verification.
5. The Authoritative Server replies that key is valid or invalid.
6. The Receiving Server informs the Originating Server whether it is authenticated or not.

We can represent this flow of events graphically as follows.

This section describes the detailed protocol interaction between the Originating Server, the Receiving Server, and the Authoritative Server.

This section uses the following domain names, IP addresses, stream IDs, and shared secret in the examples:

• The Originating Server is "example.org" (there is no IP address associated with this domain since it is merely asserted by the Originating Server).
• The Receiving Server is "xmpp.example.com" and its IP address is "192.0.2.0".
• The Authoritative Server is "example.org" and its IP address is "192.0.2.1".
• The stream ID of the stream from the Originating Server to the Receiving Server is "D60000229F".
• The shared secret known by the Authoritative Server's network is "s3cr3tf0rd14lb4ck".

To assist the reader, the following conventions are used to clarify the flow of packets:

• "O2R:" -- packets sent from the Originating Server to the Receiving Server.
• "R2O:" -- packets sent from the Receiving Server to the Originating Server.
• "R2A:" -- packets sent from the Receiving Server to the Authoritative Server.
• "A2R:" -- packets sent from the Authoritative Server to the Receiving Server.

Note: A dialback namespace declaration is REQUIRED for all elements used in server dialback. The name of the dialback namespace MUST be 'jabber:server:dialback'. All elements qualified by this namespace MUST be prefixed. An implementation SHOULD generate only the 'db:' prefix for such elements and MAY accept only the 'db:' prefix.

The flow of events is as follows.

After the Receiving Server has validated the connection from the Originating Server, the Originating Server may wish to reuse that connection for validation of additional domains. This feature is called PIGGYBACKING. Support for piggybacking is OPTIONAL.

One common motivation for such reuse is the existence of additional services associated with the Originating Server but hosted at subdomains of the Originating Server (the use of subdomains helps to ensure proper routing of XML stanzas to the hosted services). For example, the "example.org" XMPP server may host a groupchat service at "chat.example.org". In order to accept XML stanzas from rooms at "chat.example.org" intended for addresses at "xmpp.example.com", the "xmpp.example.com" domain will need to validate the "chat.example.org" domain (just as it already did for the "example.org" domain). Thus the "example.org" server would now initiate a dialback negotiation with "xmpp.example.com" but specify the Originating Server as "chat.example.org".

However, because the "example.org" server already has a validated connection open to the Receiving Server ("xmpp.example.com"), it MAY send a <db:result/> element with the key to be validated for the new Originating Server ("chat.example.org") over the XML stream that has already been negotiated, rather than opening a new TCP connection and XML stream.

The Receiving Server SHOULD accept this <db:result/> element (as it did for the first <db:result/> element) and process it according to the rules already specified. If that process is successful, it would eventually result in sending of a <db:result/> element from the Receiving Server to the Originating Server.

However, if the Receiving Server does not allow reuse of the existing connection, it MUST return an error of the following form to the Originating Server.

As mentioned, the dialback key is generated based on four different pieces of information:

• the hostname of the Originating Server
• the hostname of the Receiving Server
• the Stream ID
• a shared secret known by the Authoritative Server's network

The stream ID is security-critical in server dialback and therefore MUST be both unpredictable and non-repeating (see &rfc4086; for recommendations regarding randomness for security purposes).

It is RECOMMENDED for the dialback key to be the hexadecimal representation of a Keyed-Hash Message Authentication Code (see &nistfips198a;) generated using the SHA256 hashing algorithm (see &nistfips180-2;), as follows.

The shared secret SHOULD either be set up in a configuration option for each host or process within the Authoritative Server's network or generated as a random string when starting each host or process. The secret's length SHOULD be at least 128 bits or 16 characters long.

Consider the following scenario:

• The Originating Server is "example.org"
• The Receiving Server is "xmpp.example.com"
• The Stream ID is "D60000229F"
• The secret is "s3cr3tf0rd14lb4ck"

The resulting dialback key would be:

Support for the server dialback protocol can be indicated in two ways:

1. By inclusion of the server dialback feature in a given set of stream features.
2. By inclusion of the dialback namespace declaration in the stream header.

The former method is preferred, but the latter method is also specified herein for the purpose of backward-compatibility with older "XMPP 0.9" deployments.

The server dialback stream feature is advertised by including in any given set of stream features a <dialback/> element qualified by the 'urn:xmpp:features:dialback' namespace; the <dialback/> element MAY also include an empty <required/> element, indicating that the entity sending the stream features requires dialback to be negotiated for the stream.

As mentioned, support for the server dialback protocol can also be advertised by including the dialback namespace declaration in a stream header.

No matter which method is used, a service SHOULD advertise support for server dialback only at a point in the stream negotiation when it will accept negotiation of server dialback for that stream. For example, if a service wishes to be backward-compatible with older "XMPP 0.9" deployments, it SHOULD include the server dialback namespace declaration in the initial stream header it sends to other servers (so that "XMPP 0.9" servers can proceed with dialback in the absence of TLS and SASL authentication). However, in the midst of stream negotiation with an XMPP 1.0 or higher server, a service SHOULD advertise the dialback stream feature only at a point when negotiation of server dialback is allowed in accordance with local service policies (e.g., after TLS negotiation in the case when a self-signed certificate was presented by the Originating Server and local service policies stipulate that it is preferable to weakly identify the Originating Server via server dialback rather than depend on the self-signed certificate for identity verification).

Server dialback helps protect against domain spoofing, thus making it more difficult to spoof XML stanzas. It is not a mechanism for authenticating, securing, or encrypting streams between servers as is done via SASL and TLS, and results in weak verification of server identities only. Furthermore, it is susceptible to DNS poisoning attacks unless DNSSEC (see &rfc4033;) is used, and even if the DNS information is accurate, dialback cannot protect from attacks where the attacker is capable of hijacking the IP address of the remote domain. Domains requiring robust security SHOULD use TLS and SASL. If SASL is used for server-to-server authentication, dialback SHOULD NOT be used since it is unnecessary.

This document requires no interaction with &IANA;.