XEP-0220: Server Dialback

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.

Document Information

Author Information

Peter Saint-Andre

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

Jeremie Miller

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

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://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).

Discussion Venue

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.

Conformance Terms

The following 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".

1. Introduction
2. Terminology
3. Order of Events
4. Protocol
    4.1. Stream Setup Between Originating Server and Receiving Server
    4.2. Dialback Key
    4.3. Stream Setup Between Receiving Server and Authoritative Server
    4.4. Verification Request
    4.5. Result
5. Reuse of Negotiated Connections
6. Dialback Key Generation
7. Advertisement
8. Security Considerations
9. IANA Considerations
10. XMPP Registrar Considerations
    10.1. Protocol Namespaces
    10.2. Stream Features
11. XML Schema
    11.1. Dialback
    11.2. Stream Feature
Notes
Revision History

1. Introduction

Server dialback, formerly documented in RFC 3920 [1] but now canonically documented in this specification, is a weak identify verification method that is made possible by the existence of the Domain Name System (DNS), since one server can (normally) discover the authoritative server for a given domain. Dialback is a native XMPP method that occurs over XML streams, with the result that it is more difficult to spoof XMPP server domains and XML stanzas sent over XML streams between servers.

Server dialback is not a security mechanism, and results only in weak verification of server identities. Domains requiring robust security SHOULD use TLS and SASL. If SASL is used for server-to-server authentication, dialback SHOULD NOT be used since it is unnecessary. However, depending on local policies, a service may wish to use dialback to provide weak identity verification in cases where SASL negotiation would not result in strong authentication (e.g., because the certificate presented by the peer service during TLS negotiation is self-signed and thus provides even weaker identity verification than DNS).

Server dialback is uni-directional, and results in weak identity verification for one stream in one direction. Because server dialback is not an authentication mechanism, mutual authentication is not possible via dialback. Therefore, server dialback MUST be completed in each direction in order to enable bi-directional communications between two domains.

The method for generating and verifying the keys used in server dialback MUST take into account the hostnames being used, the stream ID generated by the receiving server, and a secret known by the authoritative server's network; see Dialback Key Generation.

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

2. Terminology

3. Order of Events

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

4. Protocol

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

This section uses the following domain names, IP addresses, stream IDs, and shared secret in the examples:

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

Note: A dialback namespace declaration is REQUIRED for all elements used in server dialback. The name of the dialback namespace MUST be 'jabber:server:dialback'. All elements qualified by this namespace MUST be prefixed. An implementation SHOULD generate only the 'db:' prefix for such elements and MAY accept only the 'db:' prefix.

4.1 Stream Setup Between Originating Server and Receiving Server

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

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

Example 1. 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'>

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

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

Example 2. 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'>

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

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

Example 3. Stream Features

R2O: <stream:features>
       <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
       <dialback xmlns='urn:xmpp:features:dialback'/>
     </stream:features>

4.2 Dialback Key

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

Example 4. Dialback Key

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

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

4.3 Stream Setup Between Receiving Server and Authoritative Server

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

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

Example 5. 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'>

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

The Authoritative Server sends the Receiving Server a stream header:

Example 6. Stream Header

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

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

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

Example 7. Stream Header

A2R: <stream:features>
       <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
       <dialback xmlns='urn:xmpp:features:dialback'/>
     </stream:features>

4.4 Verification Request

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

Example 8. Stream Header

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

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

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

Example 9. Key is Valid

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

Or:

Example 10. Key is Invalid

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

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

4.5 Result

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

Example 11. Result

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

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

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

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

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

5. Reuse of Negotiated Connections

After the Receiving Server has validated the connection from the Originating Server, the Originating Server may wish to reuse that connection for validation of additional domains. This feature is called PIGGYBACKING. Support for piggybacking is OPTIONAL.

One common motivation for such reuse is the existence of additional services associated with the Originating Server but hosted at subdomains of the Originating Server (the use of subdomains helps to ensure proper routing of XML stanzas to the hosted services). For example, the "example.org" XMPP server may host a groupchat service at "chat.example.org". In order to accept XML stanzas from rooms at "chat.example.org" intended for addresses at "xmpp.example.com", the "xmpp.example.com" domain will need to validate the "chat.example.org" domain (just as it already did for the "example.org" domain). Thus the "example.org" server would now initiate a dialback negotiation with "xmpp.example.com" but specify the Originating Server as "chat.example.org".

However, because the "example.org" server already has a validated connection open to the Receiving Server ("xmpp.example.com"), it MAY send a <db:result/> element with the key to be validated for the new Originating Server ("chat.example.org") over the XML stream that has already been negotiated, rather than opening a new TCP connection and XML stream.

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>

6. Dialback Key Generation

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

The stream ID is security-critical in server dialback and therefore MUST be both unpredictable and non-repeating (see RFC 4086 [2] 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 [3]) generated using the SHA256 hashing algorithm (see SHA [4]), as follows.

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.

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

7. Advertisement

The former method is preferred, but the latter method is also specified herein for the purpose of backward-compatibility with older "XMPP 0.9" deployments.

The server dialback stream feature is advertised by including in any given set of stream features a <dialback/> element qualified by the 'urn:xmpp:features:dialback' namespace; the <dialback/> element MAY also include an empty <required/> element, indicating that the entity sending the stream features requires dialback to be negotiated for the stream.

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

As mentioned, support for the server dialback protocol can also be advertised by including the dialback namespace declaration in a stream header.

<stream:stream
    xmlns='jabber:server'
    xmlns:db='jabber:server:dialback'
    xmlns:stream='http://etherx.jabber.org/streams'
    from='example.com'
    to='example.net'>

No matter which method is used, a service SHOULD advertise support for server dialback only at a point in the stream negotiation when it will accept negotiation of server dialback for that stream. For example, if a service wishes to be backward-compatible with older "XMPP 0.9" deployments, it SHOULD include the server dialback namespace declaration in the initial stream header it sends to other servers (so that "XMPP 0.9" servers can proceed with dialback in the absence of TLS and SASL authentication). However, in the midst of stream negotiation with an XMPP 1.0 or higher server, a service SHOULD advertise the dialback stream feature only at a point when negotiation of server dialback is allowed in accordance with local service policies (e.g., after TLS negotiation in the case when a self-signed certificate was presented by the Originating Server and local service policies stipulate that it is preferable to weakly identify the Originating Server via server dialback rather than depend on the self-signed certificate for identity verification).

8. 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 [5]) is used, and even if the DNS information is accurate, dialback cannot protect from attacks where the attacker is capable of hijacking the IP address of the remote domain. Domains requiring robust security SHOULD use TLS and SASL. If SASL is used for server-to-server authentication, dialback SHOULD NOT be used since it is unnecessary.

9. IANA Considerations

10. XMPP Registrar Considerations

10.1 Protocol Namespaces

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

10.2 Stream Features

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

11. XML Schema

11.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='error'/>
                <xs:enumeration value='invalid'/>
                <xs:enumeration value='valid'/>
              </xs:restriction>
            </xs:simpleType>
          </xs:attribute>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

</xs:schema>

11.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:sequence>
        <xs:element name='required'
                    minOccurs='0'
                    maxOccurs='1'
                    type='empty'/>
      </xs:sequence>
    </xs:complexType>

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

</xs:schema>

Notes

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

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

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

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

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

6. 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/>.

7. 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://www.xmpp.org/registrar/>.