%ents; ]>
Server Dialback This specification defines the server dialback protocol, which is used between XMPP servers to provide identity verification. Server dialback uses the Domain Name System (DNS) as the basis for verifying identity; the basic approach is that when a receiving server receives a server-to-server connection requesting from an originating server, it does not accept the request until it has verified a key with an authoritative server for the domain asserted by the originating server. Although server dialback does not provide strong authentication or trusted federation and although it is subject to DNS poisoning attacks, since its development in the year 2000 it has effectively prevented most instances of address spoofing on the XMPP network. &LEGALNOTICE; 0220 Experimental Standards Track Standards Council XMPP Core dialback &stpeter; &jer; 0.2 2007-12-26 psa

Separated sections into subsections, as has been done for xmppbis Internet-Drafts; explained and illustrated failure cases more completely; added motivating text about different federation models; added explanatory text about scenarios in which server dialback is used and not used.

0.1 2007-07-11 psa

Initial published version.

0.0.1 2007-06-22 psa

Content moved from rfc3920bis.

The client-server model used by Jabber/XMPP technologies makes it desirable to enable communication among servers. Such server-to-server or inter-domain communication is often called "federation". There are three main models for federation:

Model Definition Comments Status
Promiscuous Accept a connection from any peer, even without verification or authentication of the peer's identity Lack of peer verification or authentication means that domains can be spoofed Promiscuous federation has not been allowed on the Jabber network since the release of the jabberd 1.2 server in October 2000
Verified Accept a connection only after the peer's identity has been verified via DNS-based mechanisms, specifically server dialback The use of identity verification effectively prevents domain spoofing, but federation requires proper DNS setup and is still subject to DNS poisoning attacks Verified federation has been standard practice on the Jabber network since October 2000
Trusted Accept a connection only if the peer presents a certificate issued by a certification authority (CA) that is a trusted root according to the accepting domain (or, less commonly, if the peers have previously exchanged keys out of band) The use of trusted domain certificates effectively prevents DNS poisoning attacks but makes federation more difficult since typically such certificates are not easy to obtain Trusted federation has been possible since the definition of XMPP 1.0 (including TLS and SASL) in 2004 but is not yet common on the Jabber network because certificates are not widely available; typically, deployed Jabber services accept a mix of verified and trusted federation

This document defines server dialback, a native Jabber protocol for peer identity verification that results in verified (but not trusted) federation between Jabber/XMPP servers.

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:

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.

| | | Authoritative | send dialback key | Server | ----------------------> | ------------- | | | | establish stream | | ----------------------> | | | | send verify request | | ----------------------> | | | | send verify response | | <---------------------- | | | report dialback result | | <---------------------- | | | ]]>

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:

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

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.

The Originating Server (asserted to be "example.org") performs a DNS lookup for the Receiving Server (in accordance with the procedure described in RFC 3920) and establishes a TCP connection to the Receiving Server at the IP address and port discovered during the DNS lookup (here assumed to be "192.0.2.0" and "5269"). Alternatively, the Originating Server MAY reuse an existing TCP connnection to the Receiving Server here rather than opening a new TCP connection (see Piggybacking).

The Originating Server then sends a stream header to the Receiving Server:

]]>

Note: The inclusion of the xmlns:db namespace declaration with the name shown indicates to the Receiving Server that the Originating Server supports server dialback. If any of the namespace names provided by the Originating Server is incorrect, then the Receiving Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'to' address provided by the Originating Server does not match a hostname serviced by the Receiving Server, then the Receiving Server MUST generate a <host-unknown/> stream error condition and terminate both the XML stream and the underlying TCP connection.

The Receiving Server SHOULD send a stream header back to the Originating Server over the same TCP connection, including a unique ID for this interaction:

]]>

Note: The Receiving Server SHOULD reply but MAY silently terminate the XML stream and underlying TCP connection depending on local security policies; however, if the Receiving Server desires to proceed, it MUST send a stream header back to the Originating Server. If any of the namespace names provided by the Receiving Server is incorrect, then the Originating Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'to' address provided by the Receiving Server does not match a hostname serviced by the Originating Server, then the Originating Server MUST generate a <host-unknown/> stream error condition and terminate both the XML stream and the underlying TCP connection.

The Receiving Server SHOULD also send stream features to the Originating Server, including the dialback feature:

]]>

The Originating Server MUST then send a dialback key to the Receiving Server:

37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643 ]]>

If the value of the 'to' address provided by the Originating Server does not match a hostname serviced by the Receiving Server, then the Receiving Server MUST generate a <host-unknown/> stream error condition and terminate both the XML stream and the underlying TCP connection. The key generated by the Originating Server MUST be verifiable only by servers in the Authoritative Server's network, based on information known only to those servers. Any verifiable method MAY be used to generate the key; however, the method specified under Dialback Key Generation is RECOMMENDED. The key is not examined by the Receiving Server, since the key is validated by the Authoritative Server.

The Receiving Server performs a DNS lookup for the Authoritative Server (in accordance with the procedure described in RFC 3920) and establishes a TCP connection to the Authoritative Server at the IP address and port discovered during the DNS lookup (here assumed to be "192.0.2.1" and "5269"). If the Receiving Server cannot connect to the Authoritive Server, it MUST return a <remote-connection-failed/> stream error to the Originating Server and terminate both the XML stream and the underlying TCP connection.

The Receiving Server sends a stream header to the Authoritative Server:

]]>

Note: If the namespace name is incorrect, then the Authoritative Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'to' address provided by the Receiving Server does not match a hostname serviced by the Authoritative Server, then the Authoritative Server MUST generate a <host-unknown/> stream error condition and terminate both the XML stream and the underlying TCP connection.

The Authoritative Server sends the Receiving Server a stream header:

]]>

Note: If any of the namespace names provided by the Authoritative Server is incorrect, then the Receiving Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection between it and the Authoritative Server. If the value of the 'to' address provided by the Authoritative Server does not match a hostname serviced by the Receiving Server, then the Receiving Server MUST generate a <host-unknown/> stream error condition and terminate both the XML stream and the underlying TCP connection. If a stream error occurs between the Receiving Server and the Authoritative Server, then the Receiving Server MUST not only terminate the XML stream and the underlying TCP connection between it and the Authoritative Server but also terminate the XML stream and the underlying TCP connection between it and the Originating Server, generating a <remote-connection-failed/> stream error for the latter stream.

The Authoritative Server SHOULD also send stream features to the Receiving Server, including the dialback feature:

]]>

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

37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643 ]]>

Note: Passed here are the hostnames of the Receiving Server ('from') and the Originating Server ('to'), the original identifier from the Receiving Server's stream header to the Originating Server in Step 3, and the key that the Originating Server sent to the Receiving Server in Step 5. Based on this information, as well as shared secret information within the Authoritative Server's network, the Authoritative Server determines whether the key is valid or invalid. If the value of the 'to' address does not match a hostname serviced by the Authoritative Server, then the Authoritative Server MUST generate a <host-unknown/> stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'from' address does not match the hostname sent by the Receiving Server in the 'from' address of the stream header it sent to the Authoritative Server in Step 7, then the Authoritative Server MUST generate an <invalid-from/> stream error condition and terminate both the XML stream and the underlying TCP connection.

The Authoritative Server determines whether the key was valid or invalid and informs the Receiving Server of its determination, where the <db:verify/> element SHOULD include the key sent by the Receiving Server:

37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643 ]]>

Or:

37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643 ]]>

Note: If the ID does not match that provided by the Receiving Server in Step 3, then the Receiving Server MUST generate an <invalid-id/> stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'to' address does not match a hostname serviced by the Receiving Server, then the Receiving Server MUST generate a <host-unknown/> stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'from' address does not match the hostname represented by the Originating Server in the 'from' address of the stream header it sent to the Receiving Server in Step 2, then the Receiving Server MUST generate an <invalid-from/> stream error condition and terminate both the XML stream and the underlying TCP connection. After receiving the verification from the Authoritative Server, the Receiving Server SHOULD terminate the stream between them and the underlying TCP connection.

The Receiving Server informs the Originating Server of the result, where the <db:result/> element SHOULD include the key sent by the Originating Server:

37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643 ]]>

Note: At this point, the connection from the Originating Server to the Receiving Server has either been validated or reported as invalid. If the connection is invalid, then the Receiving Server MUST terminate both the XML stream and the underlying TCP connection between itself and the Originating Server. If the connection is valid, the Receiving Server has verified the identity of the Originating Server; as a result, the Originating Server may now send XML stanzas to the Receiving Server over the validated connection (i.e., over the "initial stream" from the Originating Server to the Receiving Server).

Until the initial stream has been validated, the Originating Server MUST NOT send any further XML data to the Receiving Server. If it receives any XML stanzas from the Originating Server before the initial stream has been validated, the Receiving Server MUST silently drop them.

After successful dialback negotiation, the Receiving Server MUST follow the rules specified in RFC 3920 regarding inclusion and checking of 'from' and 'to' attributes on all XML stanzas it receives from the Originating Server. These checks help to prevent address spoofing.

As mentioned, server dialback results in weak identity verification in one direction only (in the foregoing text, verification of the Originating Server by the Receiving Server). In order to proceed with bi-directional communication so that the Receiving Server may sent XML stanzas to the Originating Server, the Receiving Server MUST now also initiate a dialback negotiation with the Originating Server (this happens on a different TCP connection).

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.

88a96894060d5f4258c37cd51b772e5a483430d8203f71d3782cac72a0866458 ]]>

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.

88a96894060d5f4258c37cd51b772e5a483430d8203f71d3782cac72a0866458 ]]>

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.

88a96894060d5f4258c37cd51b772e5a483430d8203f71d3782cac72a0866458 ]]>

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

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 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;.

The ®ISTRAR; includes 'jabber:server:dialback' in its registry of protocol namespaces (see &NAMESPACES;).

The XMPP Registrar includes 'urn:xmpp:features:dialback' in its registry of stream features (see &STREAMFEATURES;).

]]> ]]>