<abstract>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.</abstract>
<remark><p>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.</p></remark>
<p>The client-server architecture 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". This document defines server dialback, a native Jabber protocol for federation with weak identity verification between Jabber/XMPP servers.</p>
<p>Server dialback, which was formerly documented in &rfc3920; but now is 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.</p>
<p>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).</p>
<p>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.</p>
<p>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 <linkurl='#generation'>Dialback Key Generation</link>.</p>
<p>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.</p>
</section1>
<section1topic="Terminology"anchor="terms">
<p>The following terminology applies:</p>
<ul>
<li>ORIGINATING SERVER -- the server that is attempting to establish a connection between two domains.</li>
<li>RECEIVING SERVER -- the server that is trying to authenticate that the Originating Server represents the domain which it claims to be.</li>
<li>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).</li>
</ul>
</section1>
<section1topic="Order of Events"anchor="order">
<p>The following is a brief summary of the order of events in dialback:</p>
<ol>
<li>The Originating Server establishes an XML stream with the Receiving Server.</li>
<li>The Originating Server sends a 'key' value over the connection to the Receiving Server.</li>
<li>The Receiving Server establishes an XML stream with the Authoritative Server.</li>
<li>The Receiving Server sends the same 'key' value to the Authoritative Server for verification.</li>
<li>The Authoritative Server replies that key is valid or invalid.</li>
<li>The Receiving Server informs the Originating Server whether it is authenticated or not.</li>
</ol>
<p>We can represent this flow of events graphically as follows.</p>
<code><![CDATA[
Originating Receiving
Server Server
----------- ---------
| |
| establish stream |
| ----------------------> |
| | Authoritative
| send dialback key | Server
| ----------------------> | -------------
| | |
| establish stream |
| ----------------------> |
| |
| send verify request |
| ----------------------> |
| |
| send verify response |
| <----------------------|
|
| report dialback result |
| <----------------------|
| |
]]></code>
</section1>
<section1topic="Protocol"anchor="protocol">
<p>This section describes the detailed protocol interaction between the Originating Server, the Receiving Server, and the Authoritative Server.</p>
<p>This section uses the following domain names, IP addresses, stream IDs, and shared secret in the examples:</p>
<ul>
<li>The Originating Server is "example.org" (there is no IP address associated with this domain since it is merely asserted by the Originating Server).</li>
<li>The Receiving Server is "xmpp.example.com" and its IP address is "192.0.2.0".</li>
<li>The Authoritative Server is "example.org" and its IP address is "192.0.2.1".</li>
<li>The stream ID of the stream from the Originating Server to the Receiving Server is "D60000229F".</li>
<li>The shared secret known by the Authoritative Server's network is "s3cr3tf0rd14lb4ck".</li>
</ul>
<p>To assist the reader, the following conventions are used to clarify the flow of packets:</p>
<ul>
<li>"O2R:" -- packets sent from the Originating Server to the Receiving Server.</li>
<li>"R2O:" -- packets sent from the Receiving Server to the Originating Server.</li>
<li>"R2A:" -- packets sent from the Receiving Server to the Authoritative Server.</li>
<li>"A2R:" -- packets sent from the Authoritative Server to the Receiving Server.</li>
</ul>
<p>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.</p>
<p>The flow of events is as follows.</p>
<section2topic='Stream Setup Between Originating Server and Receiving Server'anchor='proto-setup-o2r'>
<p>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 <linkurl='piggybacking'>Piggybacking</link>).</p>
<p>The Originating Server then sends a stream header to the Receiving Server:</p>
<examplecaption="Stream Header"><![CDATA[
O2R: <stream:stream
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.org'
to='xmpp.example.com'
version='1.0'>
]]></example>
<p>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.</p>
<p>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:</p>
<examplecaption="Stream Header"><![CDATA[
R2O: <stream:stream
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams'
from='xmpp.example.com'
id='D60000229F'
to='example.org'
version='1.0'>
]]></example>
<p>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.</p>
<p>The Receiving Server SHOULD also send stream features to the Originating Server, including the dialback feature:</p>
<p>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 <linkurl='#generation'>Dialback Key Generation</link> is RECOMMENDED. The key is not examined by the Receiving Server, since the key is validated by the Authoritative Server.</p>
</section2>
<section2topic='Stream Setup Between Receiving Server and Authoritative Server'anchor='proto-setup-r2a'>
<p>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.</p>
<p>The Receiving Server sends a stream header to the Authoritative Server:</p>
<examplecaption="Stream Header"><![CDATA[
R2A: <stream:stream
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams'
from='xmpp.example.com'
to='example.org'
version='1.0'>
]]></example>
<p>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.</p>
<p>The Authoritative Server sends the Receiving Server a stream header:</p>
<examplecaption="Stream Header"><![CDATA[
A2R: <stream:stream
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.org'
id='F92200006D'
to='xmpp.example.com'
version='1.0'>
]]></example>
<p>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.</p>
<p>The Authoritative Server SHOULD also send stream features to the Receiving Server, including the dialback feature:</p>
<p>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.</p>
<p>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:</p>
<p>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.</p>
</section2>
<section2topic='Result'anchor='proto-result'>
<p>The Receiving Server informs the Originating Server of the result, where the <db:result/> element SHOULD include the key sent by the Originating Server:</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>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).</p>
</section2>
</section1>
<section1topic="Reuse of Negotiated Connections"anchor="dialback-reuse">
<p>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.</p>
<p>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".</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<examplecaption="Piggybacking Not Supported"><![CDATA[
<p>As mentioned, the dialback key is generated based on four different pieces of information:</p>
<ul>
<li>the hostname of the Originating Server</li>
<li>the hostname of the Receiving Server</li>
<li>the Stream ID</li>
<li>a shared secret known by the Authoritative Server's network</li>
</ul>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>Consider the following scenario:</p>
<ul>
<li>The Originating Server is "example.org"</li>
<li>The Receiving Server is "xmpp.example.com"</li>
<p>The former method is preferred, but the latter method is also specified herein for the purpose of backwards-compatibility with older "XMPP 0.9" deployments.</p>
<p>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.</p>
<examplecaption="Stream Features"><![CDATA[
<stream:features>
<dialbackxmlns='urn:xmpp:features:dialback'>
<required/>
</dialback>
</stream:features>
]]></example>
<p>As mentioned, support for the server dialback protocol can also be advertised by including the dialback namespace declaration in a stream header.</p>
<p>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 backwards-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).</p>
<p>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.</p>
