XEP-0220: Server Dialback

NOTICE: This document is currently within Last Call or under consideration by the XMPP Council for advancement to the next stage in the XSF standards process.

1. Introduction
    1.1. Why Dialback?
    1.2. Federation Models
    1.3. What Dialback Accomplishes
    1.4. When Dialback Is Used
    1.5. How Dialback Works
2. Protocol
    2.1. Stream Setup Between Originating Server and Receiving Server
       2.1.1. Originating Server Resolves Receiving Server
       2.1.2. Originating Server Opens TCP Connection
       2.1.3. Originating Server Sends Initial Stream Header
       2.1.4. Receiving Server Processes Initial Stream Header
         2.1.4.1. Success Case
         2.1.4.2. Error Cases
       2.1.5. Originating Server Processes Response Stream Header
         2.1.5.1. Success Case
         2.1.5.2. Error Cases
    2.2. Generation and Exchange of Dialback Key
       2.2.1. Originating Server Generates Dialback Key
       2.2.2. Originating Server Sends Dialback Key
       2.2.3. Receiving Server Processes Dialback Key
         2.2.3.1. Success Case
         2.2.3.2. Error Cases
    2.3. Stream Setup Between Receiving Server and Authoritative Server
       2.3.1. Receiving Server Resolves Authoritative Server
       2.3.2. Receiving Server Opens TCP Connection
       2.3.3. Receiving Server Sends Initial Stream Header
       2.3.4. Authoritative Server Processes Initial Stream Header
         2.3.4.1. Success Case
         2.3.4.2. Error Cases
       2.3.5. Receiving Server Processes Response Stream Header
         2.3.5.1. Success Case
         2.3.5.2. Error Cases
    2.4. Exchange of Verification Request
       2.4.1. Receiving Server Sends Verification Request
       2.4.2. Authoritative Server Processes Verification Request
         2.4.2.1. Success Case
         2.4.2.2. Error Cases
    2.5. Validation of Dialback Key and Exchange of Validation Result
       2.5.1. Authoritative Server Determines Validity of Dialback Key
       2.5.2. Authoritative Server Sends Validation Result
       2.5.3. Receiving Server Processes Validation Result
         2.5.3.1. Success Case
         2.5.3.2. Error Cases
    2.6. Communication and Handling of Verification Result
       2.6.1. Receiving Server Communicates Verification Result
       2.6.2. Receiving Server Handles Verification Result
         2.6.2.1. Invalid Connection
         2.6.2.2. Valid Connection
3. Reuse of Negotiated Connections ("Piggybacking")
4. Security Considerations
5. IANA Considerations
6. XMPP Registrar Considerations
    6.1. Protocol Namespaces
    6.2. Stream Features
7. XML Schema
    7.1. Dialback
    7.2. Stream Feature

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

1. Introduction

1.1 Why Dialback?

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.

Unfortunately, that was the state of affairs on the Jabber network during the earliest releases of the original jabberd [1] server codebase (up through the 1.0 release in May 2000). Therefore the open-source developer community designed a protocol ("Server Dialback") for weak 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.

When the core Jabber protocols were formalized by the XMPP Working Group of the Internet Engineering Task Force (IETF) [2] in 2002-2004, support for strong identity verification was added. 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, using digital certificates issued by trusted root certificate authorities (CAs). Documentation of TLS and SASL within XMPP is provided in XMPP Core [3]. However, the Server Dialback protocol is still in wide use, and probably will be for the foreseeable future given the difficulty (real or perceived) of obtaining digital certificates issued by common CAs. (The XMPP Standards Foundation (XSF) [4] has worked to make certificates easier to obtain by running the XMPP Intermediate Certification Authority [5].)

Therefore it is important to maintain accurate documentation of the Server Dialback protocol. Such documentation was originally provided in RFC 3920 [6]. Although that documentation was removed from rfc3920bis [7], it is still provided in this specification for the sake of interoperability.

1.2 Federation Models

There are at least four levels of server-to-server federation in Jabber/XMPP networks:

Permissive Federation -- a server accepts a connection from any other peer on the network, even without verifiying the identity of the peer based on DNS lookups. The lack of peer verification or authentication means that domains can be spoofed.
Verified Federation -- a server accepts a connection from a peer only after the identity of the peer has been weakly verified based on information obtained via the Domain Name System (DNS). However, the connection is not encrypted or authenticated. The use of identity verification effectively prevents domain spoofing, but federation requires proper DNS setup and is still subject to DNS poisoning attacks.
Encrypted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) as defined for XMPP in RFC 3920 and the peer presents a digital certificate. However, the certificate can be self-signed, in which case mutual authentication is typically not possible. Therefore, after STARTTLS negotiation the parties proceed to weakly verify identity based on DNS information as under Verified Federation. This combination results in an encrypted connection with weak identity verification.
Trusted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) and the peer presents a digital certificate issued by a trusted root certificate authority (CA). The list of trusted root CAs is determined by local service policy, as is the level of trust accorded to various types of certificates (e.g., Class 1, Class 2, or Class 3). The use of trusted domain certificates effectively prevents DNS poisoning attacks and results in mutual authentication.

This specification documents the technology that enabled the Jabber server network to advance beyond Permissive Federation to Verified Federation. Combined with the use of TLS, Server Dialback can also result in Encrypted Federation. However, Trusted Federation is not possible with Server Dialback.

Note: For detailed examples showing the protocol flows and outcomes of dialback negotiation for a wide variety of federation scenarios, refer to XMPP Protocol Flows for Inter-Domain Federation [8].

1.3 What Dialback Accomplishes

Server Dialback is a method for weak identify verification. Such verification 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 trust domain (e.g., the trust domain associated with a given second-level DNS domain such as "example.com" and all of its subdomains).

Since October 2000, the use of Server Dialback has made it more difficult to spoof the hostnames of servers (and therefore the addresses of sent messages) on the XMPP network. However, Server Dialback does not provide authentication between servers and is not a security mechanism. Domains requiring high security are advised to use TLS and SASL with certificates issued by trusted roots.

Server Dialback is uni-directional, and results in weak identity verification for one XML 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 communication between two domains.

1.4 When Dialback Is Used

Server Dialback is typically used in two scenarios:

When a peer service does not support XMPP 1.0 as defined in RFC 3920 or, more generally, does not offer negotiation of TLS.
When STARTTLS negotiation succeeds with a peer service but the peer's certificate is not strong enough to result in mutual authentication via SASL (e.g., because the certificate presented by the peer service during TLS negotiation is self-signed and local service policies stipulate that it is preferable to weakly identify the peer service via Server Dialback rather than depend on the self-signed certificate for identity verification).

Both of these scenarios result in an untrusted connection (verified federation in the first scenario and encrypted federation in the second scenario). However, depending on local security policies, a server might accept such an untrusted connection if the use of Server Dialback results in weak identity verification.

Dialback is not used if SASL is used for server-to-server authentication, since SASL provides strong authentication using certificates, pre-established passwords, or other credentials.

A service cannot begin negotiation of Server Dialback unless its peer advertises support for the Server Dialback protocol. As described under Receiving Server Processes Initial Stream Header, a peer advertises support through inclusion of the Server Dialback namespace declaration in its response stream header and (for XMPP 1.0 servers) through inclusion of the Server Dialback stream feature.

1.5 How Dialback Works

The basic idea behind Server Dialback is that a receiving server does not accept XMPP traffic from a sending server until it has "called back" the authoritative server for the domain asserted by the sending server, and verified that the sending server is truly authorized to generate XMPP traffic for that domain.

A helpful analogy might be the following telephone scenario:

A representative from your electric utility company knocks on your front door and says he needs to enter your house.
Rather than letting him in, you ask for his employee ID number and politely close the door for a few moments.
You open the phone book, find the authoritative phone number for the utility company's headquarters, and call them on the phone.
After being transferred to the customer service department, you ask if a rep with that particular ID number is authorized to be visiting your house.
The company tells you that the rep is authorized, so you thank them and hang up.
You then reopen the front door and allow the rep to enter your house.

In Server Dialback, the equivalent of the utility company representative is the ORIGINATING SERVER, i.e., the machine that wants to send a message to an entity at a destination domain and thus is attempting to establish a connection between the two servers. The equivalent of the person at the house is the RECEIVING SERVER, i.e., the machine to which the originating server has opened a connection for the purpose of sending the message and thus is trying to authenticate that the Originating Server represents the domain which it claims to be. And the equivalent of the company headquarters is the AUTHORITATIVE SERVER, i.e., the machine that answers to a DNS lookup for the domain asserted by the originating server (which is not necessarily the machine associated with 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 basic flow of events in Server Dialback is as follows:

The Originating Server performs a DNS lookup on the hostname of the Receiving Server, opens a TCP connection to the discovered IP address and port, and establishes an XML stream with the Receiving Server.
The Originating Server generates a dialback key and sends that value over its XML stream with the Receiving Server.
The Receiving Server does not immediately accept the connection but instead performs a DNS lookup on the hostname of the Authoritative Server, opens a TCP connection to the discovered IP address and port, and establishes an XML stream with the Authoritative Server.
The Receiving Server sends the same dialback key over its XML stream with the Authoritative Server for verification.
The Authoritative Server replies that the key is valid or invalid.
The Receiving Server informs the Originating Server whether its identify has been verified or not.

We can represent this flow of events graphically as follows.

Originating               Receiving
  Server                    Server
-----------               ---------
    |                         |
    |   perform DNS lookup,   |
    |   open TCP connection,  |
    |   and establish stream  |
    | ----------------------> |
    |                         |                   Authoritative
    |   send dialback key     |                       Server
    | ----------------------> |                   -------------
    |                         |                         |
    |                         |   perform DNS lookup,   |
    |                         |   open TCP connection,  |
    |                         |   and establish stream  |
    |                         | ----------------------> |
    |                         |                         |
    |                         |   send verify request   |
    |                         | ----------------------> |
    |                         |                         |
    |                         |   send verify response  |
    |                         | <---------------------- |
    |                         |
    |  report dialback result |
    | <---------------------- |
    |                         |

Note: In Steps 1 and 3, it is not always necessary to open a new TCP connection and establish a new stream; for details, see the section on Reuse of Negotiated Connections ("Piggybacking").

2. Protocol

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

The examples in this section use the following domain names, IP addresses, stream IDs, and shared secret:

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

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

2.1 Stream Setup Between Originating Server and Receiving Server

2.1.1 Originating Server Resolves Receiving Server

Before opening a TCP connection to the Receiving Server, the Originating Server first needs to determine the appropriate IP address and port at which to connect. This is done by resolving the Receiving Server's hostname ("xmpp.example.com") using the Domain Name System. As described in XMPP Core, the Originating Server will first attempt to resolve a TCP service of _xmpp-server for that hostname using DNS SRV records. Here we assume that example.com has the following records in its DNS configuration:

Example 1. DNS SRV Record for Receiving Server

_xmpp-server._tcp.xmpp.example.com. 86400 IN SRV 10 0 5269 x1.example.com
_xmpp-server._tcp.xmpp.example.com. 86400 IN SRV 20 0 9625 x2.example.com

These records show that server-to-server connections for the XMPP service "xmpp.example.com" are serviced by two machines: x1.example.com at port 5269 and x2.example.com at port 9625.

Based on the SRV record weights, the Originating Server would then attempt to resolve one of these machines further. Here the Originating Server resolves x2.example.com, for which a standard A lookup yields an IP address of "192.0.2.2".

Note: As described in XMPP Core, if the Receiving Server does not provide appropriate DNS SRV records then in order to resolve the hostname of the Receiving Server the Originating Server can fall back to normal IPv4/IPv6 address record resolution to determine the IP address and assume a port of 5269 as registered with the IANA.

2.1.2 Originating Server Opens TCP Connection

Once the Originating Server has resolved "xmpp.example.com" to an IP address of 192.0.2.2 and port of 9625, it opens a TCP connection to that IP and port.

Note: Instead of opening a new TCP connection to the Receiving Server, the Originating Server MAY reuse an existing TCP connnection; for details, see the Reuse of Negotiated Connections ("Piggybacking") section of this document.

2.1.3 Originating Server Sends Initial Stream Header

Once the Originating Server has opened a TCP connection to the resolved IP address and port of the Receiving Server, it sends an initial stream header to the Receiving Server as described in XMPP Core.

Example 2. Initial Stream Header

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'>

In addition to the core XMPP rules regarding initial stream headers, the following dialback-related rules apply to the initial stream header:

It MUST include a declaration for the Server Dialback namespace.
The Server Dialback namespace MUST be 'jabber:server:dialback'.
The prefix for the Server Dialback namespace SHOULD be 'db:'.

Until the initial stream has been validated, the Originating Server MUST NOT send any further XML data to the Receiving Server over that stream.

Note: If the Receiving Server receives any XML stanzas from the Originating Server before the initial stream has been validated, the Receiving Server MUST silently drop those stanzas.

2.1.4 Receiving Server Processes Initial Stream Header

When the Receiving Server receives the initial stream header from the Originating Server, it MUST proceed as follows.

2.1.4.1 Success Case

If the Receiving Server can successfully process the initial stream header, it MUST return a response stream header to the Originating Server over the same TCP connection.

Example 3. Response Stream Header

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'>

In addition to the core XMPP rules regarding response stream headers, the following dialback-related rules apply to the response stream header:

If the initial stream header included a Server Dialback namespace declaration and the Receiving Server supports the Server Dialback protocol, the response stream header also MUST include a declaration for the Server Dialback namespace.
If the initial stream header did not include a Server Dialback namespace declaration and the Receiving Server supports the Server Dialback protocol, the response stream header MAY include a Server Dialback namespace declaration.
If the response stream header includes a Server Dialback namespace declaration, the Server Dialback namespace MUST be 'jabber:server:dialback' and the prefix for the Server Dialback namespace SHOULD be 'db:'.

After sending the response stream header, the Receiving Server also sends stream features to the Originating Server. The Receiving Server SHOULD include the dialback feature in its initial stream features advertisement, including an indication of whether Server Dialback negotiation is optional or required.

Example 4. Stream Features

R2O: <stream:features>
       <dialback xmlns='urn:xmpp:features:dialback'>
         <required/>
       </dialback>
     </stream:features>

Note: Typically, Server Dialback negotiation is required for server-to-server communication unless SASL is used for strong authentication.

2.1.4.2 Error Cases

There are several reasons why the Receiving Server's processing of the initial stream header might fail:

The Server Dialback namespace name provided by the Originating Server is incorrect.
The Server Dialback namespace prefix provided by the Originating Server is not supported by the Receiving Server (note: an implementation MAY accept only the 'db:' namespace prefix).
The value of the 'to' address provided by the Originating Server does not match a hostname serviced by the Receiving Server.
The Receiving Server does not accept communication with the hostname of the 'from' address provided by the Originating Server.

These error cases are described more fully in the remainder of this section.

If the Server Dialback namespace name is incorrect, then the Receiving Server SHOULD generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection.

Example 5. Invalid Namespace

R2O: <stream:error>
       <invalid-namespace
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2O: </stream:stream>

If the Server Dialback namespace prefix is not supported by the Receiving Server, then the Receiving Server SHOULD generate a <bad-namespace-prefix/> stream error condition and terminate both the XML stream and the underlying TCP connection.

Example 6. Bad Namespace Prefix

R2O: <stream:error>
       <bad-namespace-prefix
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2O: </stream:stream>

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 SHOULD generate a <host-unknown/> or <host-gone/> stream error condition (as appropriate) and terminate both the XML stream and the underlying TCP connection.

Example 7. Host Unknown

R2O: <stream:error>
       <host-unknown
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2O: </stream:stream>

If the Receiving Server does not allow communication with the hostname of the 'from' address provided by the Originating Server, then the Receiving Server SHOULD generate a <not-authorized/> stream error condition and terminate both the XML stream and the underlying TCP connection.

Example 8. Not Authorized

R2O: <stream:error>
       <not-authorized
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2O: </stream:stream>

Note Well: The foregoing error flows specify that the Receiving Server SHOULD return a stream error. However, depending on local security policies, the Receiving Server MAY silently terminate the XML stream and underlying TCP connection instead of returning a stream error (e.g., to prevent certain denial of service attacks).

2.1.5 Originating Server Processes Response Stream Header

When the Originating Server receives the response stream header from the Receiving Server, it MUST proceed as follows.

2.1.5.1 Success Case

If the response stream header can be successfully processed, the Originating Server MUST generate and send a dialback key as described under Generation and Exchange of Dialback Key.

2.1.5.2 Error Cases

There are several reasons why the Originating Server's processing of the response stream header and stream features might fail:

The Server Dialback namespace name provided by the Receiving Server is incorrect.
The Server Dialback namespace prefix provided by the Receiving Server is not supported by the Originating Server (note: an implementation MAY accept only the 'db:' namespace prefix).
The value of the 'to' address provided by the Receiving Server does not match a hostname serviced by the Originating Server.
The Originating Server does not accept communication with the hostname of the 'from' address provided by the Receiving Server.
The Receiving Server does not advertise support for Server Dialback via a Server Dialback namespace declaration or stream feature.

These error cases are described more fully in the remainder of this section.

If the Server Dialback namespace name is incorrect, then the Originating Server SHOULD generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection.

Example 9. Invalid Namespace

O2R: <stream:error>
       <invalid-namespace
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

O2R: </stream:stream>

If the Server Dialback namespace prefix is not supported by the Originating Server, then the Originating Server SHOULD generate a <bad-namespace-prefix/> stream error condition and terminate both the XML stream and the underlying TCP connection.

Example 10. Bad Namespace Prefix

O2R: <stream:error>
       <bad-namespace-prefix
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

O2R: </stream:stream>

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 SHOULD generate a <host-unknown/> or <host-gone/> stream error condition (as appropriate) and terminate both the XML stream and the underlying TCP connection.

Example 11. Host Unknown

O2R: <stream:error>
       <host-unknown
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

O2R: </stream:stream>

If the Originating Server does not allow communication with the hostname of the 'from' address provided by the Receiving Server, then the Originating Server SHOULD generate a <not-authorized/> stream error condition and terminate both the XML stream and the underlying TCP connection.

Example 12. Not Authorized

O2R: <stream:error>
       <not-authorized
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

O2R: </stream:stream>

Note Well: The foregoing error flows specify that the Originating Server SHOULD return a stream error. However, depending on local security policies, the Originating Server MAY silently terminate the XML stream and underlying TCP connection instead of returning a stream error (e.g., to prevent certain denial of service attacks).

If the Receiving Server does not advertise support for Server Dialback via a Server Dialback namespace declaration or stream feature, then the Originating Server's attempt to negotiate Server Dialback also fails.

Note Well: In all of the foregoing error cases, the Originating Server SHOULD consider the Server Dialback negotiation attempt to have failed in an unrecoverable fashion and therefore it SHOULD return a <remote-server-timeout/> stanza error to the local entity that generated the stanza that triggered the Server Dialback negotiation attempt in the first place (if any).

2.2 Generation and Exchange of Dialback Key

2.2.1 Originating Server Generates Dialback Key

Once the Originating Server has established an XML stream with the Receiving Server, it MUST generate a dialback key for verification by the Authoritative Server.

The method for generating (and verifying) the keys used in Server Dialback MUST take into account the following 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 RFC 4086 [9] 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 HMAC [10]) generated using the SHA256 hashing algorithm (see SHA [11]), as follows.

Example 13. HMAC

HMAC-SHA256
( 
  SHA256(secret), 
  {Receiving Server, ' ', Originating Server, ' ', Stream ID} 
)

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:

Example 14. A Key

HMAC-SHA256
( 
  SHA256(secret), 
  {Receiving Server, ' ', Originating Server, ' ', Stream ID} 
)

that is,

HMAC-SHA256
(SHA256('s3cr3tf0rd14lb4ck'),
{'xmpp.example.net',' ','example.org',' ','D60000229F'})

that is,

HMAC-SHA256
('a7136eb1f46c9ef18c5e78c36ca257067c69b3d518285f0b18a96c33beae9acc',
{'xmpp.example.com chat.example.org D60000229F'})

that is,

37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643

2.2.2 Originating Server Sends Dialback Key

Once the Originating Server has processed the response stream header from the Receiving Server and has generated a dialback key for verification by the Receiving Server, it MUST then send that 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 hostname of the Originating Server and MUST possess a 'to' attribute whose value is the hostname of the Receiving Server.

Note: All XML elements qualified by the Server Dialback namespace MUST be prefixed with the namespace prefix advertised on the stream header originally sent by the entity sending the element.

Example 15. Originating Server Sends Dialback Key

O2R: <db:result
         from='example.org'
         to='xmpp.example.com'>
       37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643
     </db:result>

2.2.3 Receiving Server Processes Dialback Key

When the Receiving Server receives the dialback key, it MUST proceed as follows.

2.2.3.1 Success Case

If the dialback key can be successfully processed, the Receiving Server MUST attempt to open a connection to the Authoritative Server and then ask the Authoritative Server to validate the key provided by the Originating Server, as described in under Stream Setup Between Receiving Server and Authoritative Server.

Note: The dialback key is not examined by the Receiving Server, since the key is validated by the Authoritative Server.

2.2.3.2 Error Cases

There are several reasons why the Receiving Server's processing of the dialback key might fail:

The Server Dialback namespace prefix provided by the Originating Server is not supported by the Receiving Server (note: an implementation MAY accept only the 'db:' namespace prefix).
The value of the 'to' address provided by the Originating Server does not match a hostname serviced by the Receiving Server.
The Receiving Server does not accept communication with the hostname of the 'from' address provided by the Originating Server.

These error cases are described more fully in the remainder of this section.

Example 16. Bad Namespace Prefix

R2O: <stream:error>
       <bad-namespace-prefix
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2O: </stream:stream>

Example 17. Host Unknown

R2O: <stream:error>
       <host-unknown
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2O: </stream:stream>

Example 18. Not Authorized

R2O: <stream:error>
       <not-authorized
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2O: </stream:stream>

2.3 Stream Setup Between Receiving Server and Authoritative Server

2.3.1 Receiving Server Resolves Authoritative Server

Before opening a TCP connection to the Authoritative Server, the Receiving Server first needs to determine the appropriate IP address and port at which to connect. This is done by resolving the Authoritative Server's hostname ("example.org") using the Domain Name System. As described in XMPP Core, the Receiving Server will first attempt to resolve a TCP service of _xmpp-server for that hostname using DNS SRV records. Here we assume that example.org has the following records in its DNS configuration:

Example 19. DNS SRV Record for Authoritative Server

_xmpp-server._tcp.example.org. 86400 IN SRV 10 0 5269 foo.example.org

These records show that server-to-server connections for the XMPP service "example.org" are serviced by the physical machine foo.example.org at port 5269.

The Receiving Server would then resolve that machine to an IP address, in this case "192.0.2.23".

Note: As described in XMPP Core, if the Authoritative Server does not provide appropriate DNS SRV records then in order to resolve the hostname of the Authoritative Server the Receiving Server can fall back to normal IPv4/IPv6 address record resolution to determine the IP address and assume a port of 5269 as registered with the IANA.

2.3.2 Receiving Server Opens TCP Connection

Once the Receiving Server has resolved "example.org" to an IP address of 192.0.2.23 and port of 5269, it opens a TCP connection to that IP and port.

Note: Instead of opening a new TCP connection to the Authoritative Server, the Receiving Server MAY reuse an existing TCP connnection; for details, see the Reuse of Negotiated Connections ("Piggybacking") section of this document.

2.3.3 Receiving Server Sends Initial Stream Header

Once the Receiving Server has opened a TCP connection to the resolved IP address and port of the Authoritative Server, it sends an initial stream header to the Authoritative Server as described in XMPP Core.

Example 20. Initial Stream Header

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'>

In addition to the core XMPP rules regarding initial stream headers, the following dialback-related rules apply to the initial stream header:

It MUST include a declaration for the Server Dialback namespace.
The Server Dialback namespace MUST be 'jabber:server:dialback'.
The prefix for the Server Dialback namespace SHOULD be 'db:'.

Note: An implementation MAY accept only the 'db:' namespace prefix.

2.3.4 Authoritative Server Processes Initial Stream Header

When the Authoritative Server receives the initial stream header from the Receiving Server, it MUST proceed as follows.

2.3.4.1 Success Case

If the Authoritative Server can successfully process the initial stream header, it MUST return a response stream header to the Receiving Server over the same TCP connection.

Example 21. Response Stream Header

A2R: <stream:stream
         xmlns='jabber:server'
         xmlns:db='jabber:server:dialback'
         xmlns:stream='http://etherx.jabber.org/streams'
         from='example.org'
         id='D60000229F'
         to='xmpp.example.com'
         version='1.0'>

In addition to the core XMPP rules regarding response stream headers, the following dialback-related rules apply to the response stream header:

If the initial stream header included a Server Dialback namespace declaration and the Authoritative Server supports the Server Dialback protocol, the response stream header also MUST include a declaration for the Server Dialback namespace.
If the initial stream header did not include a Server Dialback namespace declaration and the Authoritative Server supports the Server Dialback protocol, the response stream header MAY include a Server Dialback namespace declaration.
If the response stream header includes a Server Dialback namespace declaration, the Server Dialback namespace MUST be 'jabber:server:dialback' and the prefix for the Server Dialback namespace SHOULD be 'db:'.

After sending the response stream header, the Authoritative Server also sends stream features to the Receiving Server. The Authoritative Server SHOULD include the dialback feature in its initial stream features advertisement, including an indication of whether Server Dialback negotiation is optional or required.

Example 22. Stream Features

A2R: <stream:features>
       <dialback xmlns='urn:xmpp:features:dialback'>
         <optional/>
       </dialback>
     </stream:features>

2.3.4.2 Error Cases

There are several reasons why the Authoritative Server's processing of the initial stream header might fail:

The Server Dialback namespace name provided by the Receiving Server is incorrect.
The Server Dialback namespace prefix provided by the Receiving Server is not supported by the Authoritative Server (note: an implementation MAY accept only the 'db:' namespace prefix).
The value of the 'to' address provided by the Receiving Server does not match a hostname serviced by the Authoritative Server.
The Authoritative Server does not accept communication with the hostname of the 'from' address provided by the Receiving Server.

These error cases are described more fully in the remainder of this section.

Note Well: If

If the Server Dialback namespace name is incorrect, then the Authoritative Server SHOULD generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection.

Example 23. Invalid Namespace

A2R: <stream:error>
       <invalid-namespace
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

A2R: </stream:stream>

If the Server Dialback namespace prefix is not supported by the Authoritative Server, then the Authoritative Server SHOULD generate a <bad-namespace-prefix/> stream error condition and terminate both the XML stream and the underlying TCP connection.

Example 24. Bad Namespace Prefix

A2R: <stream:error>
       <bad-namespace-prefix
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

A2R: </stream:stream>

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 SHOULD generate a <host-unknown/> or <host-gone/> stream error condition (as appropriate) and terminate both the XML stream and the underlying TCP connection.

Example 25. Host Unknown

A2R: <stream:error>
       <host-unknown
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

A2R: </stream:stream>

If the Authoritative Server does not allow communication with the hostname of the 'from' address provided by the Receiving Server, then the Authoritative Server SHOULD generate a <not-authorized/> stream error condition and terminate both the XML stream and the underlying TCP connection.

Example 26. Not Authorized

A2R: <stream:error>
       <not-authorized
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

A2R: </stream:stream>

Note Well: The foregoing error flows specify that the Authoritative Server SHOULD return a stream error. However, depending on local security policies, the Authoritative Server MAY silently terminate the XML stream and underlying TCP connection instead of returning a stream error (e.g., to prevent certain denial of service attacks).

2.3.5 Receiving Server Processes Response Stream Header

When the Receiving Server receives the response stream header from the Authoritative Server, it MUST proceed as follows.

2.3.5.1 Success Case

If the response stream header can be successfully processed, the Receiving Server MUST send the dialback key it received from the Originating Server as described under Exchange of Verification Request between Receiving Server and Authoritative Server.

2.3.5.2 Error Cases

There are several reasons why the Receiving Server's processing of the response stream header and stream features might fail:

The Server Dialback namespace name provided by the Authoritative Server is incorrect.
The Server Dialback namespace prefix provided by the Authoritative Server is not supported by the Receiving Server (note: an implementation MAY accept only the 'db:' namespace prefix).
The value of the 'to' address provided by the Authoritative Server does not match a hostname serviced by the Receiving Server.
The Receiving Server does not accept communication with the hostname of the 'from' address provided by the Authoritative Server.
The Authoritative Server does not advertise support for Server Dialback via a Server Dialback namespace declaration or stream feature.

These error cases are described more fully in the remainder of this section.

Example 27. Invalid Namespace

R2A: <stream:error>
       <invalid-namespace
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2A: </stream:stream>

Example 28. Bad Namespace Prefix

R2A: <stream:error>
       <bad-namespace-prefix
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2A: </stream:stream>

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 SHOULD generate a <host-unknown/> or <host-gone/> stream error condition (as appropriate) and terminate both the XML stream and the underlying TCP connection.

Example 29. Host Unknown

R2A: <stream:error>
       <host-unknown
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2A: </stream:stream>

If the Receiving Server does not allow communication with the hostname of the 'from' address provided by the Authoritative Server, then the Receiving Server SHOULD generate a <not-authorized/> stream error condition and terminate both the XML stream and the underlying TCP connection.

Example 30. Not Authorized

R2A: <stream:error>
       <not-authorized
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2A: </stream:stream>

If the Authoritative Server does not advertise support for Server Dialback via a Server Dialback namespace declaration or stream feature, then the Receiving Server's attempt to request verification of the Originating Server's dialback key also fails.

Note: In all of the foregoing error cases, the Receiving Server SHOULD consider the Server Dialback negotiation attempt to have failed in an unrecoverable fashion and therefore it SHOULD return a <remote-connection-failed/> stream error to the Originating Server.

Example 31. Remote Server Timeout

R2O: <stream:error>
       <remote-server-timeout
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2O: </stream:stream>

2.4 Exchange of Verification Request

2.4.1 Receiving Server Sends Verification Request

Once the Receiving Server has established an XML stream with the Authoritative Server, it MUST send to the Authoritative Server the dialback key it received from the Originating Server. This is done by creating a <db:verify/> element whose XML character data is the dialback key; the element MUST possess a 'from' attribute whose value is the hostname of the Receiving Server, MUST possess a 'to' attribute whose value is the hostname of the Originating Server, and MUST possess an 'id' attribute whose value is the stream identifier from the Receiving Server's response stream header to the Originating Server.

Note: All XML elements qualified by the Server Dialback namespace MUST be prefixed with the namespace prefix advertised on the stream header originally sent by the entity sending the element.

Example 32. Receiving Server Sends Verification Request

R2A: <db:verify
         from='xmpp.example.com'
         id='D60000229F'
         to='example.org'>
       37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643
     </db:verify>

2.4.2 Authoritative Server Processes Verification Request

2.4.2.1 Success Case

If the verification request can be successfully processed, the Authoritative Server MUST validate the dialback key it received from the Receiving Server as described under Validation of Dialback Key by Authoritative Server.

2.4.2.2 Error Cases

There are several reasons why the Authoritative Server's processing of the verification request might fail:

The value of the 'to' address provided by the Receiving Server does not match a hostname serviced by the Authoritative Server's network.
The value of the 'from' address provided by the Receiving Server does not match the hostname sent by the Receiving Server in the 'from' address of the initial stream header it sent to the Authoritative Server.

These error cases are described more fully in the remainder of this section.

If the value of the 'to' address provided by the Receiving Server does not match a hostname serviced by the Authoritative Server's network, then the Authoritative Server MUST generate a <host-unknown/> or <host-gone/> stream error condition (as appropriate) and terminate both the XML stream and the underlying TCP connection.

Example 33. Host Unknown

A2R: <stream:error>
       <host-unknown
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

A2R: </stream:stream>

If the value of the 'from' address provided by the Receiving Server does not match the hostname sent by the Receiving Server in the 'from' address of the initial stream header it sent to the Authoritative Server, then the Authoritative Server MUST generate an <invalid-from/> stream error condition and terminate both the XML stream and the underlying TCP connection.

Example 34. Invalid From

A2R: <stream:error>
       <invalid-from
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

A2R: </stream:stream>

Example 35. Remote Server Timeout

R2O: <stream:error>
       <remote-server-timeout
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2O: </stream:stream>

2.5 Validation of Dialback Key and Exchange of Validation Result

2.5.1 Authoritative Server Determines Validity of Dialback Key

If the Authoritative Server can successfully process the verification request, it MUST determine whether the key is valid or invalid.

The key shall be considered valid if the Authoritative Server determines that the key matches the output it would have produced using its key generation algorithm with the inputs specified in the XML attributes of the verification request along with its shared secret.

The key shall be considered invalid if the Authoritative Server determines that the key does not match the output it would have produced using its key generation algorithm with the inputs specified in the XML attributes of the verification request along with its shared secret.

2.5.2 Authoritative Server Sends Validation Result

Once the Authoritative Server determines whether the key is valid or invalid, it MUST inform the Receiving Server of its determination. This is done by creating a <db:verify/> element whose XML character data is the dialback key; the element MUST possess a 'from' attribute whose value is the hostname of the Originating Server, MUST possess a 'to' attribute whose value is the hostname of the Receiving Server, MUST possess an 'id' attribute whose value is the stream identifier from the Receiving Server's response stream header to the Originating Server as communicated in the verification request, and MUST possess a 'type' attribute whose value is either "valid" or "invalid".

Example 36. Key is Valid

A2R: <db:verify
         from='example.org'
         id='D60000229F'
         to='xmpp.example.com'
         type='valid'>
       37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643
     </db:verify>

Or:

Example 37. Key is Invalid

A2R: <db:verify
         from='example.org'
         id='D60000229F'
         to='xmpp.example.com'
         type='invalid'>
       37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643
     </db:verify>

2.5.3 Receiving Server Processes Validation Result

2.5.3.1 Success Case

If the validation result can be successfully processed, the Receiving Server MUST inform the Originating Server of the Server Dialback results described under Communication of Result from Receiving Server to Originating Server. The Receiving Server then SHOULD also terminate the XML stream and the underlying TCP connection between the Receiving Server and the Authoritative Server.

2.5.3.2 Error Cases

There are several reasons why the Receiving Server's processing of the validation result might fail:

The value of the 'id' attribute does not match that provided by the Receiving Server in the verification request.
The value of the 'from' address does not match the hostname represented by the Originating Server in the 'from' address of the initial stream header it sent to the Receiving Server.
The value of the 'to' address does not match a hostname serviced by the Receiving Server.

These error cases are described more fully in the remainder of this section.

If the value of the 'id' attribute does not match that provided by the Receiving Server in the verification request, then the Receiving Server MUST generate an <invalid-id/> stream error condition and terminate both the XML stream and the underlying TCP connection between it and the Authoritative Server.

Example 38. Invalid ID

R2A: <stream:error>
       <invalid-id
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2A: </stream:stream>

The value of the 'from' address does not match the hostname represented by the Originating Server in the 'from' address of the initial stream header it sent to the Receiving Server, then the Receiving Server MUST generate an <invalid-from/> stream error condition and terminate both the XML stream and the underlying TCP connection.

Example 39. Invalid From

R2A: <stream:error>
       <invalid-from
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2A: </stream:stream>

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/> or <host-gone/> stream error condition (as appropriate) and terminate both the XML stream and the underlying TCP connection.

Example 40. Host Unknown

R2A: <stream:error>
       <host-unknown
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2A: </stream:stream>

Example 41. Remote Server Timeout

R2O: <stream:error>
       <remote-server-timeout
           xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     </stream:error>

R2O: </stream:stream>

2.6 Communication and Handling of Verification Result

2.6.1 Receiving Server Communicates Verification Result

Once the Receiving Server successfully processes the validation result it received from the Authoritative Server, it informs the Originating Server of the result. 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 hostname of the Receiving Server, MUST possess a 'to' attribute whose value is the hostname of the Originating Server, MUST possess an 'id' attribute whose value is the stream identifier from the Receiving Server's response stream header to the Originating Server, and MUST possess a 'type' attribute whose value is either "valid" or "invalid".

Example 42. Receiving Server Sends Verification Result

R2O: <db:result
         from='xmpp.example.com'
         to='example.org'
         type='valid'>
       37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643
     </db:result>

2.6.2 Receiving Server Handles Verification Result

2.6.2.1 Invalid Connection

If the Authoritative Server reported the dialback key as invalid, then the Receiving Server MUST terminate both the XML stream and the underlying TCP connection between itself and the Originating Server.

2.6.2.2 Valid Connection

If the Authoritative Server reported the dialback key as valid, the Receiving Server has verified the identity of the Originating Server. As a result, the Receiving Server can now accept XML stanzas from the Originating Server over the validated connection (i.e., over the "initial stream" from the Originating Server to the Receiving Server). However, in accordance with XMPP Core, the Receiving Server MUST follow the rules specified therein 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.

Note Well: If the Receiving Server receives any XML stanzas from the Originating Server before the initial stream has been validated, the Receiving Server MUST silently drop those stanzas.

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 can send XML stanzas to the Originating Server, the Receiving Server MUST now also initiate a dialback negotiation with the Originating Server (i.e., assume the role of an originating server in a new dialback negotiation).

3. Reuse of Negotiated Connections ("Piggybacking")

After the Receiving Server has validated a connection from the Originating Server, the Originating Server might 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 might 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.

O2R: <db:result
         from='chat.example.org'
         to='xmpp.example.com'>
       88a96894060d5f4258c37cd51b772e5a483430d8203f71d3782cac72a0866458
     </db:result>

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.

R2O: <db:result
         from='xmpp.example.com'
         to='chat.example.org'
         type='valid'>
       88a96894060d5f4258c37cd51b772e5a483430d8203f71d3782cac72a0866458
     </db:result>

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.

R2O: <db:result
         from='xmpp.example.com'
         to='chat.example.org'
         type='error'>
       88a96894060d5f4258c37cd51b772e5a483430d8203f71d3782cac72a0866458
     </db:result>

Note: a <db:result/> element of type "error" MUST NOT be considered a stream error and therefore MUST NOT result in termination of the stream and the underlying TCP connection, which presumably is being used for sending XML stanzas from the Originating Server to the Receiving Server.

4. Security Considerations

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 RFC 4033 [12]) is used. Even if the DNS information is accurate, Server Dialback cannot protect against 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, Server Dialback SHOULD NOT be used since it is unnecessary.

5. IANA Considerations

6. XMPP Registrar Considerations

6.1 Protocol Namespaces

The XMPP Registrar [14] includes 'jabber:server:dialback' in its registry of protocol namespaces (see <http://xmpp.org/registrar/namespaces.html>).

6.2 Stream Features

The XMPP Registrar includes 'urn:xmpp:features:dialback' in its registry of stream features (see <http://xmpp.org/registrar/stream-features.html>).

7. XML Schema

7.1 Dialback

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='jabber:server:dialback'
    xmlns='jabber:server:dialback'
    elementFormDefault='qualified'>

  <xs:element name='result'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='xs:NMTOKEN'>
          <xs:attribute name='from' type='xs:string' use='required'/>
          <xs:attribute name='to' type='xs:string' use='required'/>
          <xs:attribute name='type' use='optional'>
            <xs:simpleType>
              <xs:restriction base='xs:NCName'>
                <xs:enumeration value='error'/>
                <xs:enumeration value='invalid'/>
                <xs:enumeration value='valid'/>
              </xs:restriction>
            </xs:simpleType>
          </xs:attribute>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='verify'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='xs:NMTOKEN'>
          <xs:attribute name='from' type='xs:string' use='required'/>
          <xs:attribute name='id' type='xs:NMTOKEN' use='required'/>
          <xs:attribute name='to' type='xs:string' use='required'/>
          <xs:attribute name='type' use='optional'>
            <xs:simpleType>
              <xs:restriction base='xs:NCName'>
                <xs:enumeration value='invalid'/>
                <xs:enumeration value='valid'/>
              </xs:restriction>
            </xs:simpleType>
          </xs:attribute>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

</xs:schema>

7.2 Stream Feature

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:xmpp:features:dialback'
    xmlns='urn:xmpp:features:dialback'
    elementFormDefault='qualified'>

  <xs:element name='dialback'>
    <xs:complexType>
      <xs:choice minOccurs='1' maxOccurs='1'>
        <xs:element name='optional' type='empty'/>
        <xs:element name='required' type='empty'/>
      </xs:choice>
    </xs:complexType>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>

Appendices

Appendix A: Document Information

Appendix B: Author Information

Peter Saint-Andre

JabberID: stpeter@jabber.org
URI: https://stpeter.im/

Jeremie Miller

Email: jer@jabber.org
JabberID: jer@jabber.org

Appendix C: Legal Notices

Copyright

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

1. The jabberd server is the original server implementation of the Jabber/XMPP protocols, first developed by Jeremie Miller, inventor of Jabber. For further information, see <http://jabberd.org/>.

2. The Internet Engineering Task Force is the principal body engaged in the development of new Internet standard specifications, best known for its work on standards such as HTTP and SMTP. For further information, see <http://www.ietf.org/>.

3. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.

4. The XMPP Standards Foundation (XSF) is an independent, non-profit membership organization that develops open extensions to the IETF's Extensible Messaging and Presence Protocol (XMPP). For further information, see <http://xmpp.org/xsf/>.

5. The XMPP Intermediate Certification Authority (ICA) issues free domain certificates to administrators of XMPP-based services. For further information, see <http://xmpp.org/ca/>.

6. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.

7. rfc3920bis: proposed revisions to Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-saintandre-rfc3920bis>. (work in progress)

8. XEP-0238: XMPP Protocol Flows for Inter-Domain Federation <http://xmpp.org/extensions/xep-0238.html>.

9. RFC 4086: Randomness Requirements for Security <http://tools.ietf.org/html/rfc4086>.

10. The Keyed-Hash Message Authentication Code (HMAC): Federal Information Processing Standards Publication 198 <http://csrc.nist.gov/publications/fips/fips198/fips-198a.pdf>.

11. Secure Hash Standard: Federal Information Processing Standards Publication 180-2 <http://csrc.nist.gov/publications/fips/fips180-2/fips186-2withchangenotice.pdf>.

12. RFC 4033: DNS Security Introduction and Requirements <http://tools.ietf.org/html/rfc4033>.

13. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

14. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://xmpp.org/registrar/>.

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 request 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, it has effectively prevented most instances of address spoofing on the XMPP network since its development in the year 2000.
Authors:	Peter Saint-Andre, Jeremie Miller
Copyright:	© 1999 - 2009 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:	Proposed
Type:	Standards Track
Version:	0.3
Last Updated:	2008-10-16

XEP-0220: Server Dialback

Table of Contents

1. Introduction

1.1 Why Dialback?

1.2 Federation Models

1.3 What Dialback Accomplishes

1.4 When Dialback Is Used

1.5 How Dialback Works

2. Protocol

2.1 Stream Setup Between Originating Server and Receiving Server

2.1.1 Originating Server Resolves Receiving Server

2.1.2 Originating Server Opens TCP Connection

2.1.3 Originating Server Sends Initial Stream Header

2.1.4 Receiving Server Processes Initial Stream Header

2.1.4.1 Success Case

2.1.4.2 Error Cases

2.1.5 Originating Server Processes Response Stream Header

2.1.5.1 Success Case

2.1.5.2 Error Cases

2.2 Generation and Exchange of Dialback Key

2.2.1 Originating Server Generates Dialback Key

2.2.2 Originating Server Sends Dialback Key

2.2.3 Receiving Server Processes Dialback Key

2.2.3.1 Success Case

2.2.3.2 Error Cases

2.3 Stream Setup Between Receiving Server and Authoritative Server

2.3.1 Receiving Server Resolves Authoritative Server

2.3.2 Receiving Server Opens TCP Connection

2.3.3 Receiving Server Sends Initial Stream Header

2.3.4 Authoritative Server Processes Initial Stream Header

2.3.4.1 Success Case

2.3.4.2 Error Cases

2.3.5 Receiving Server Processes Response Stream Header

2.3.5.1 Success Case

2.3.5.2 Error Cases

2.4 Exchange of Verification Request

2.4.1 Receiving Server Sends Verification Request

2.4.2 Authoritative Server Processes Verification Request

2.4.2.1 Success Case

2.4.2.2 Error Cases

2.5 Validation of Dialback Key and Exchange of Validation Result

2.5.1 Authoritative Server Determines Validity of Dialback Key

2.5.2 Authoritative Server Sends Validation Result

2.5.3 Receiving Server Processes Validation Result

2.5.3.1 Success Case

2.5.3.2 Error Cases

2.6 Communication and Handling of Verification Result

2.6.1 Receiving Server Communicates Verification Result

2.6.2 Receiving Server Handles Verification Result

2.6.2.1 Invalid Connection

2.6.2.2 Valid Connection

3. Reuse of Negotiated Connections ("Piggybacking")

4. Security Considerations

5. IANA Considerations

6. XMPP Registrar Considerations

6.1 Protocol Namespaces

6.2 Stream Features

7. XML Schema

7.1 Dialback

7.2 Stream Feature

Appendices

Appendix A: Document Information

Appendix B: Author Information

Peter Saint-Andre

Jeremie Miller

Appendix C: Legal Notices

Copyright

Permissions

Disclaimer of Warranty

Limitation of Liability

IPR Conformance

Appendix D: Relation to XMPP

Appendix E: Discussion Venue

Appendix F: Requirements Conformance

Appendix G: Notes

Appendix H: Revision History

Version 0.3 (2008-10-16)

Version 0.2 (2008-06-18)

Version 0.1 (2007-07-11)

Version 0.0.1 (2007-06-22)