<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 XMPP stanzas over the connection until it has verified the initiating server's identity. Additionally, the protocol is used to negotitate whether the receiving server is accepting stanzas for the target domain. Although Server Dialback does not provide strong authentication and is subject to DNS poisoning attacks, it has effectively prevented most address spoofing on the XMPP network since its development in the year 2000.</abstract>
<remark><p>Updated the Security Considerations to describe the 'Unsolicited Dialback Attack' and added recommendations to avoid this attack.</p></remark>
<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. 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. The protocol also ensures that the receiving server is accepting stanzas for the target 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;, since updated by &rfc6120;). 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. In addition, the slow but steady deployment of the DNS security extensions (DNSSEC) &rfc4033; can provide a stronger basis for using Server Dialback.</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; 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>Traditionally, the verification accomplished in Server Dialback has depended 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 verification 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 verification for one XML stream in one direction. Because traditionally Server-to-Server connections are used unidirectionally, Server Dialback needs to be completed in each direction in order to enable bidirectional communication between two domains (unless &xep0288; is used).</p>
<p>Furthermore, because a separate TCP connection is mandated for each domain pair, the use of server dialback results in significant scalability challenges for large XMPP service providers that host many domains (see &dna-framework; for a possible solution).</p>
<p>Finally, dialback signalling can be used without basing the identity verification on checking of the dialback key provided by the Initiating Server. As one example, if Transport Layer Security (TLS) is used then the Receiving Server can attempt to verify the certificate presented by the Initiating Server, either according to the PKIX-based rules specified in &xep0178;, <cite>RFC 6120</cite>, and &rfc6125; or by checking that the public key or certificate of the Initiating Server matches a public key or certificate obtained via &posh;. However, this technique of using dialback signalling without verifying the dialback key (sometimes called "dialback without dialing back" since the Receiving Server does not contact the Authoritative Server) is not described in this document.</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 (a) the Target Domain and (b) 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>
<p>Server Dialback is used when a stanza that is to be sent from a Sender Domain must be routed to a Target Domain and there is not yet an established connection between the domains. The basic flow of events in Server Dialback consists of the following four steps:</p>
<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>
<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 for the Target Domain.</p>
<li>The server hosting "capulet.example" 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.example" resolves to "orchard.capulet.example".</li>
<li>The server hosting "montague.example" 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.example" resolves to the machine "home.montague.example"</li>
<li>The stream ID of the response stream header sent from "capulet.example" to "montague.example" is "D60000229F".</li>
<li>The stream ID of the response stream header sent from "montague.example" to "capulet.example" is "417GAF25".</li>
<li>The shared secret within the "capulet.example" domain is "s3cr3tf0rd14lb4ck".</li>
<li>The shared secret within the "montague.example" domain is "d14lb4ck43v3r".</li>
<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.</note></p>
<li><p>To understand the overall protocol flow of each dialback negotiation, read Section 2.1.1 and Section 2.2.1 (aspects of the dialback negotiation from capulet.example as Initiating Server to montague.example as Receiving Server), then Section 2.1.2 and 2.2.2 (aspects of the dialback negotiation from montague.example as Initiating Server to capulet.example 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 (inbound). Note that both parts can be implemented, tested, and used separately.</p></li>
<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.example (acting as an Initiating Server) and the server hosting montague.example (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, is currently not 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 that is "home.montague.example").</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)"><