<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 accepts a server-to-server connection from an initiating server, it does not process traffic over the connection 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, it has effectively prevented most instances of address spoofing on the XMPP network since its development in the year 2000.</abstract>
<remark><p>Corrected several small errors and added sentence about the undesirability of the stream features child element, per list discussion.</p></remark>
<remark><p>Per list discussion, reverted the stream features versioning that was added to version 0.10, thus reverting to the format used in versions 0.5 through 0.9 of the spec; corrected several errors in the examples.</p></remark>
<remark><p>Modified stream features to incorporate versioning, thus removing the need for an <errors/> child element; clarified a few points in the text.</p></remark>
<remark><p>To reduce the possibility of confusion, harmonized the protocol sections so that they show only the first dialback negotiation from Initiating Server to Receiving Server.</p></remark>
<remark><p>Per list discussion, restored requirement for Receiving Server to close the stream if the dialback key is invalid, since application of dialback to multiple domain pairs will use dialback packets of type error, not type invalid.</p></remark>
<remark><p>Removed stream feature for advertising mere protocol support, using it only for advertising support for enhanced error handling.</p></remark>
<remark><p>Updated to reflect RFC 6120; mandated support for stream feature in XMPP 1.0 implementations; removed requirement for the Receiving Server to close the stream if the dialback key is invalid, since the stream might be used for multiple domain pairs.</p></remark>
<p>When Jabber technologies were first developed in 1998, they were conceived of as a client-server system similar to email, wherein a client would connect to a server in order to communicate with other clients. Similarly, servers would connect with peer servers to provide inter-domain communication (often called "federation"). In a system that allows federation, it is important for a server to be able to determine the identity of a peer server; accepting a connection from any peer without determining its identity would result in the use of merely asserted identities and a completely uncontrolled approach to federation, which on the open Internet would rapidly devolve into chaos. Clearly such a state of affairs would be unsustainable for a network protocol aiming for widespread deployment.</p>
<p>Such potential chaos was the state of affairs on the Jabber network during the earliest releases of the original &jabberd; server codebase (up through the 1.0 release in May 2000). Therefore the Jabber developer community designed a protocol called "Server Dialback" for identity verification based on the Domain Name System (DNS), built support for that protocol into the jabberd 1.2 server (released in October 2000), and mandated support for that protocol on the emerging Jabber server network.</p>
<p>The basic idea behind Server Dialback is that a receiving server does not accept XMPP traffic from a sending server until it has (a) "called back" the authoritative server for the domain asserted by the sending server and (b) verified that the sending server is truly authorized to generate XMPP traffic for that domain.</p>
<p>When the early Jabber protocols were formalized by the XMPP Working Group of the &IETF; in 2002-2004, support for strong identity verification was added (see &rfc3920;). That support takes the form of Transport Layer Security (TLS) for encryption of server-to-server XML streams and the Simple Authentication and Security Layer (SASL) for authentication of such streams, typically using digital certificates issued by trusted root certification authorities (CAs). However, the Server Dialback protocol is still in wide use, and probably will be for the foreseeable future given the perceived difficulty of obtaining digital certificates issued by common CAs. In addition, the slow but steady deployment of the DNS security extensions (DNSSEC) &rfc4033; can provide a stronger basis for using Server Dialback, as explored in &dna-dns;. Therefore it is important to maintain accurate documentation of the Server Dialback protocol.</p>
<p>Server Dialback is a method for identity verification: if the dialback negotiation succeeds, the receiving server for an XML stream can associate a pair of domain names with the stream (on the concept of a domain name association, see &dna-framework;); those two domain names are the sender domain asserted by the initiating server and the domain name at the receiving server that the initiating server has indicated it wishes to communicate with.</p>
<p>The verification accomplished in Server Dialback depends on the Domain Name System (DNS) and the use of keys based on a shared secret known to all XMPP servers within a given administrative domain. It is a proof-of-possession protocol in the sense of &rfc4949; which asserts that the initiating server and the authoritative server are associated with each other. The relative strength or weakness of the verificaiton depends in part on the strength or weakness of the process for resolving the domain names of the authoritative server; in particular, if DNSSEC is not used then Server Dialback results in weak identity verification, whereas if DNSSEC is used then Server Dialback can result in fairly strong identity verification.</p>
<p>Since October 2000, the use of Server Dialback (even absent DNSSEC) has made it more difficult to spoof the hostnames of servers (and therefore the addresses of sent messages) on the XMPP network.</p>
<p>Server Dialback is unidirectional, and results in weak verification for one XML stream in one direction. Because mutual authentication is not achieved directly by this protocol, Server Dialback needs to be completed in each direction in order to enable bidirectional communication between two domains.</p>
<p>Dialback does not verify that the IP address returned by a DNS lookup of the originating domain is the same as the source IP address of the inbound TCP connection. While this might often be true, not performing this check enables large deployments to separate inbound and outbound message routing.</p>
<di><dt>Authoritative Server</dt><dd>The machine that is discovered by means of a DNS lookup for the Sender Domain; for simple deployments this will be the Initiating Server, but it could be a separate machine in the Initiating Server's network (where "network" is defined by knowledge of a shared secret for verification of dialback keys).</dd></di>
<di><dt>Domain Pair</dt><dd>The combination of the Sender Domain and Target Domain.</dd></di>
<di><dt>Initiating Server</dt><dd>The machine that wants to send a message from an entity at the Sender Domain to an entity at the Target Domain (and thus the machine that is attempting to establish a domain name association between the Target Domain and the XML stream from the Initiating Server to the Receiving Server). Note well that in older documentation of the Server Dialback protocol, this was called the Originating Server.</dd></di>
<di><dt>Receiving Server</dt><dd>The machine to which the Initiating Server has opened a connection for the purpose of sending a message from the Sender Domain to the Target Domain (and thus the machine that is trying to verify that the Initiating Server represents the Sender Domain).</dd></di>
<di><dt>Sender Domain</dt><dd>The domain name asserted by the Initiating Server as the domainpart of the XMPP 'from' address of stanzas that will flow over the XML stream from the Initiating Server to the Receiving Server.</dd></di>
<di><dt>Target Domain</dt><dd>The domain name specified by the Initiating Server as the domainpart of the XMPP 'to' address of stanzas that will flow over the XML stream from the Initiating Server to the Receiving Server.</dd></di>
<li><p>The Initiating Server generates a dialback key and sends that value over its XML stream with the Receiving Server. (If the Initiating Server does not yet have an XML stream to the Receiving Server, it will first need to perform a DNS lookup on the Target Domain and thus discover the Receiving Server, open a TCP connection to the discovered IP address and port, and establish an XML stream with the Receiving Server.)</p></li>
<li><p>Instead of immediately accepting XML stanzas on the connection from the Initiating Server, the Receiving Server sends the same dialback key over its XML stream with the Authoritative Server for verification. (If the Receiving Server does not yet have an XML stream to the Authoritative Server, it will first need to perform a DNS lookup on the Sender Domain and thus discover the Authoritative Server, open a TCP connection to the discovered IP address and port, and establish an XML stream with the Authoritative Server).</p></li>
<li><p>The Authoritative Server informs the Receiving Server whether the key is valid or invalid.</p></li>
<li><p>The Receiving Server informs the Initiating Server whether its identity has been verified or not.</p></li>
<p>After Step 4, the Initiating Server is authorized to send stanzas from the Sender Domain to the Target Domain as communicated in the 'to' and 'from' attributes of the dialback negotiation. In addition to identity verification of the Sender Domain, this also ensures that the Receiving Server is accepting stanzas only for the Target Domain.</p>
<li>The server hosting "capulet.lit" is acting as the Initiating Server in sections 2.1.1 and 2.2.1 and as the Receiving Server in sections 2.1.2 and 2.2.2. A DNS SRV lookup on "capulet.lit" resolves to "orchard.capulet.lit".</li>
<li>The server hosting "montague.lit" is acting as Receiving Server in sections 2.1.1 and 2.2.2 and as Authoritative Server in sections 2.1.2 and 2.2.2. A DNS SRV lookup on "montague.lit" resolves to the machine "home.montague.lit"</li>
<li>The stream ID of the response stream header sent from "capulet.lit" to "montague.lit" is "D60000229F".</li>
<li>The stream ID of the response stream header sent from "montague.lit" to "capulet.lit" is "417GAF25".</li>
<li>The shared secret within the "capulet.lit" domain is "s3cr3tf0rd14lb4ck".</li>
<li>The shared secret within the "montague.lit" domain is "d14lb4ck43v3r".</li>
<li><p>To understand the protocol flow of each dialback negotiation, read Section 2.1.1 and Section 2.2.1 (aspects of the dialback negotiation from capulet.lit as Initiating Server to montague.lit as Receiving Server), then Section 2.1.2 and 2.2.2 (aspects of the dialback negotiation from montague.lit as Initiating Server to capulet.lit as Receiving Server).</p></li>
<li><p>To implement the code for either an outbound connection or an inbound connection, read Section 2.1 (outbound) or Section 2.2 (outbound). Note that both parts can be implemented, tested, and used separately.</p></li>
</ol>
<p>The following figure gives an overview of where each example is embedded in the process and illustrates the changing roles of each server.</p>
<p>Note: All XML elements qualified by the Server Dialback namespace MUST be prefixed with the namespace prefix for the 'jabber:server:dialback' namespace as advertised on the stream header originally sent by the entity sending the element. <note>RFC 3920 stipulated that "an implementation SHOULD generate only the 'db:' prefix for such elements and MAY accept only the 'db:' prefix." This restriction was included for the sake of backward compatibility with the jabberd 1.x codebase and is no longer necessary.</note></p>
<p>On an outbound connection there are two different tasks:</p>
<ol>
<li>Request authorization to send stanzas from a Sender Domain to a Target Domain, i.e., act as an Initiating Server in relation to a Receiving Server; this is is described under Section 2.1.1.</li>
<li>Generate verification requests about the validity of dialback keys, i.e., act as a Receiving Server in relation to an Authoritative Server; this is described under Section 2.1.2.</li>
</ol>
<section3topic="Initiating Server Generates Outbound Request for Authorization by Receiving Server">
<p>This subsection describes the interaction between the server hosting capulet.lit (acting as an Initiating Server) and the server hosting montague.lit (acting as a Receiving Server), from the outbound perspective of the Initiating Server.</p>
<p>When the Initiating Server has stanzas to send from the Sender Domain to the Target Domain, does not have a verified connection, or is currently attempting to get a verified connection for this domain pair, it sends a new dialback key to the Receiving Server.</p>
<p>To do so, either it can reuse an existing XML stream or it needs to establish a new connection. To establish a new connection, the Initiating Server performs a DNS lookup on the Target Domain, thus finding the IP address and port for server-to-server communication at an authoritative machine for the Target Domain (here the "home.montague.lit").</p>
<p>After the XML stream is established from the Initiating Server to the Receiving Server, the Initiating Server sends a dialback key to the Receiving Server. This is done by creating a <db:result/> element whose XML character data is the dialback key; the element MUST possess a 'from' attribute whose value is the Sender Domain and MUST possess a 'to' attribute whose value is the Target Domain.</p>
<examplecaption="Initiating Server Sends Dialback Key (Step 1)"><