XEP-xxxx: Domain Name Assertions

An application-level approach to asserting and proving the delegated ownership of a domain name for server-to-server XMPP federation.
Joe Hildebrand
© 1999 – 2020 XMPP Standards Foundation. SEE LEGAL NOTICES.


WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.
Standards Track
0.0.1 (2009-07-27)
Document Lifecycle
  1. Experimental
  2. Proposed
  3. Draft
  4. Final

1. Introduction

As large hosting providers begin providing XMPP services for multiple domains, several issues with previous mechanisms for server-to-server federation have become apparent.

A large number of sockets are currently required between hosting providers. Although servers MAY attempt to piggyback whenever possible, the possibility exists that 2*N*M sockets will be created (where N is the number of domains on one hosting provider, and M is the number of domains on another hosting provider). The goal would be that the number of sockets was dependent on load or deployment considerations.

In order to enable or require encryption, the hosting provider needs to create a separate socket for each hostname pair and have access to a X.509 certificate that is signed by a widely-trusted CA and includes both the public and private keys. Customers of hosting providers might be uncomfortable with the level of trust this requires.

This document describes an approach known as Domain Name Assertions (DNA) that allows providers to effectively host XMPP services on behalf of other companies, and might be expanded later to support other protocols.

2. Glossary

Hosted domain
An XMPP domain whose network services are delegated to a third party.
Hosting provider
A business entity that provides services for one or more domains that it does not directly and fully control.
Self-hosted domain
A domain whose owner acts as its hosting provider.
A ceremony that acts as proof of the intent of the owner of a hosted domain to cede control to a hosting provider for a given protocol.
Widely-trusted CA
For open communities, a Certificate Authority whose certificate that is trusted by multiple web browsers by default. For closed communities, a Certificate Authority that is trusted by all members of that community.
Sender Domain
The domain associated with the "from" address on a stanza to be sent across a federation boundary.
Target Domain
The domain associated with the "to" address on a stanza to be sent across a federation boundary.
Originating Server
The machine that wants to send a message from an entity at the Sender Domain to an entity at the Target Domain and thus is attempting to establish a connection between the two servers.
Receiving Server
The machine to which the Originating Server has opened a connection for the purpose of sending a message from the Sender Domain to the Target Domain.
Asserting Entity
A system element (such as a server) asserting a given domain name as an identity.
Validating Entity
A system element (such as a client or server) that checks a given identity asserted by an asserting entity.
Asserted Domain
A domain name asserted by either side of a conversation. Validating entities MAY require assertions to be backed up with proof.
A secure mechanism through which a validating entity can ascertain that an asserting entity has authority for the asserted domain, either directly or indirectly (by delegation).

3. Requirements

  1. A hosting provider MUST be able to service domains for which it cannot obtain certificates signed by a widely-trusted CA.
  2. All server-to-server (except for initial handshakes) MUST be encrypted in a manner not subject to man-in-the-middle attacks.
  3. The number of socket connections between hosting providers MUST NOT be a function of the number of domains hosted by either provider.
  4. Connections MUST be usable in either direction, if allowed by policy and deployment considerations.
  5. The owners of the hosted domain MUST NOT be required to give out private keying material associated with any certificate they own that has been signed by a widely-trusted CA.
  6. The owners of the hosted domain MUST be allowed to choose the frequency with which they wish to perform the delegation ceremony.
  7. The owners of the hosted domain MUST be allowed to revoke their delegation at any time.
  8. Multiple mechanisms for proving delegation MUST be possible.
  9. It MUST be possible for new assertions to be added to a stream at any point after the stream is fully established, but before the stream is closed

4. Generic Use Cases

The DNA mechanism can be used for multiple different protocols. In particular, client-to-server XMPP and server-to-server XMPP are discussed herein, but the general approach could be used for non-XMPP protocols such as SMTP. As such, the protocol syntax offered here is normative for XMPP, but merely illustrative for other protocols, which will need their own protocol bindings.

The following domain names are used in the examples:

The domain name being asserted.

4.1 Assertions

The asserting entity asserts a domain name through the use of an assert element. Assertions MUST contain a "from" attribute naming the domain name that is being asserted.

Example 1. Assertion
<assert xmlns='urn:xmpp:dna:0' from='asserted.tld'/>

4.2 Validation

When the validating entity has been satisified that the asserting entity is authoritative for the domain name asserted, it MUST send a <valid/> element. At this point, the asserting entity can send stanzas to the validating entity containing "from" addresses in the asserted and validated domain.

Validating entities SHOULD respond to a domain name assertion without asking for further proof when the domain name asserted is represented in the certificate offered by the asserting entity according to the rules set out in rfc3920bis [1].

Validating entities MAY respond to a domain name assertion without asking for further proof when the domain name asserted is known to be associated with the asserting entity through some other secure means such as DNSSEC (RFC 4033 [2]), caching, or local knowledge. In the DNSSEC case, the server hostname in the SRV record used to connect SHOULD be looked for in the certificate offered by the asserting entity, according to the rules set out in rfc3920bis.

Example 2. Valid
<valid xmlns='urn:xmpp:dna:0' to='asserted.tld'/>

4.3 Invalidation

When the validating entity does not accept proof offered by the asserting entity, or it no longer trusts the proof (for example due to the proof timing out or being revoked), it sends the asserting entity an <invalid/> element. The asserting entity MUST NOT send any stanzas to the validating entity containing "from" addresses in the invalidated domain without performing another validation.

Invalid responses MAY be given in direct response to an assertion if the validating entity has reason to believe that no proof is possible. Examples that would cause this response include a blocking list or a negative cache.

Example 3. Invalid proof
<invalid xmlns='urn:xmpp:dna:0' to='asserted.tld'/>

4.4 Requesting proof with a challenge

If an assertion cannot be validated immediately, the validating entity MAY ask for further proof. In the "prove-it" request, at least one form of proof that will be acceptable MUST be disclosed to the asserting entity.

A proof type MUST be a valid URI. A registry of proof types will be created. Standard proof types will begin with "urn:xmpp:dna:proof:". Custom proofs SHOULD be signaled with a type attribute value containing a full URI under the control of the defining party. Proof types MUST be compared for equality using the rules for URIs (see RFC 3986 [3]).

Some proof types MAY require information or nonces from the validating entity. If so, the specification for that proof type MUST specify extensions to the proof element in a new namespace.

In some protocols, a challenge MAY be sent without an assertion, if the validating entity has reason to believe that the entity with which it is talking is authoritative for a given domain (for example, through a DNS lookup).

Example 4. Prove your assertion, one of these ways
<challenge xmlns='urn:xmpp:dna:0' to='asserted.tld'>
  <proof type='urn:xmpp:dna:proof:attribute-cert'/>
  <proof type='http://example.com/proof/custom'/>

4.5 No proof possible

If the validating entity requires proof, but will not accept proof by a means that the asserting entity has available for the asserted domain, the asserting entity MUST respond with an <impossible/> element. The validating entity MUST NOT send a <valid/> or <invalid/> element in response, and MUST NOT accept stanzas from the asserted domain on this connection unless some other assertion works in the future.

The <impossible/> element MAY be sent after full validation, if the asserting entity would like to retract the assertion.

Example 5. Impossible response
<impossible xmlns='urn:xmpp:dna:0' from='asserted.tld'/>

4.6 Proving a challenge

If an asserting entity thinks it can prove a given assertion when challenged, it sends that proof in a <proof/> element. The REQUIRED 'type' attribute specifies the chosen proof type, and the REQUIRED 'from' attribute specifies the domain being proved. Each proof type MUST specify the format of the contents of the proof element. Suggestions for formats include base64-encoded binary as character data or structured XML in a new namespace.

Example 6. Proof
<proof xmlns='urn:xmpp:dna:0' from='asserted.tld' type='urn:xmpp:dna:proof:attribute-cert'>
(ascii-armored attribute certificate)

5. Attribute Certificate Proof

This section is preliminary.

When an asserting entity has been delegated responsibility for hosting a given domain, an Attribute Certificate (as specified in RFC 3281 [4]) can be used to prove the delegation. The proof type URI associated with attribute certificates SHALL be 'urn:xmpp:dna:proof:attribute-cert' (EDITOR'S NOTE: let's come up with a new, good URN prefix for these. If we move this to an I-D, it should be an IETF URN.)

Each protocol that is delegated will be assigned its own OID for an attribute type. (EDITOR's NOTE: fill in OIDs for xmpp-server and xmpp-client delegation). The values associated with a given attribute are a list of references to hosting provider certificates, one of which MUST have been offered by the asserting entity and accepted by the validating entity (except for name) during the TLS certificate exchange. (EDITOR's NOTE: normative language required for the form of certificate references).

The certificate that signed the attribute certificate MUST have been acceptable as proof of ownership of a given domain for the protocol in question, according to the rules in rfc3920bis. Validating entities SHOULD try prepending the asserted domain with "www." and re-checking for name matches before rejecting the signing certificate, in order to allow for easier deployments using existing web certificates as proof.

The attribute certificate is encoded as PKCS12 (see http://www.rsa.com/rsalabs/node.asp?id=2138), including the signing certificate and all of the CA certificates in the trust chain of the signing certificate, back to a trust anchor. The certificate is then ascii-armored according to (?), and transmitted as the character data of a proof element.

6. DNA for XMPP Federation

Two XMPP servers, each of which hosts multiple domains that they do not directly control, desire to connect in order to exchange traffic for at least two of those domains, one on either side (we call this a "dimain pair").

The following domain names are used in the examples:

The domain portion of the JID in the "to" address of the stanza that caused this connection to be initiated.
The domain portion of the JID in the "to" address of a stanza being sent across a stream that was originally started to talk to target.tld.
The hosting provider for target.tld.
A server with XMPP federation services at the target's hosting provider.
The domain portion of the JID in the "from" address of the stanza that caused this connection to be initiated.
The hosting provider for target.tld.
A server with XMPP federation services at the originator's hosting provider.

6.1 DNS SRV lookups

In a delegated hosting scenario, DNS SRV records are REQUIRED, since otherwise the hosting provider will never be contacted for the target domain. As specified by RFC 3920 [5] the originating server looks up the target domain to find a list of receiving servers. If the originating server already has a connection to the IP address represented by one of these servers (perhaps because it is communicating with another domain hosted by this provider), it MAY reuse that stream (see Stream Reuse). If the originating server does not have a connection it wants to reuse, it performs the SRV algorithm to select an SRV record and makes a TCP connection to the server and port specified by the selected SRV record.

Unless assured by a mechanism such as DNSSEC, the originating server MUST NOT trust the information received from the DNS SRV as proof that the target domain has been delegated to the receiving server.

Example 7. SRV lookup for target domain
% dig +short -t SRV _xmpp-server._tcp.target.tld
0 1 5269 server.targetprovider.tld

6.2 Certificates during Start-TLS

The first step during stream negotiation MUST be Start-TLS. The receiving server MUST offer a certificate signed by a widely-trusted CA. The receiving server MUST require a client certificate. The certificate offered by the originating server MUST be signed be a widely-trusted CA. Each side MUST check the certificate offered to it for validity (e.g. time period, signatures, and trust anchor), but MUST NOT disconnect when the certificate received does not contain a name matching its expectations.

The names on these certificates SHOULD be associated with the relevant hosting provider, and need not be related to the domains being hosted. If the certificates have the name of the server offered in the SRV record, it MAY be possible to use DNSSEC for proof in the future.

Example 8. Server certificate
Example 9. Client certificate

6.3 Discovering Support

The "to" and "from" addresses are REQUIRED on the stream:stream tag. These represent the first domain pair associated with this stream, and are the domain names from the stanza that caused this connection to be established.

To announce its support for DNA, the receiving server asserts its identity in the stream features following TLS negotiation.

Example 10. Domain name assertion in stream features
  <assert xmlns='urn:xmpp:dna:0' from='target.tld'/>

6.4 Turning on DNA

If the originating server supports DNA, it looks for an assertion in the stream features. If it finds none, it MAY fall back on another means of verifying the identity of the target server, if allowed by local policy.

Originating servers that support DNA talking to target servers that declare support for DNA MUST NOT send protocol other than DNA negotations until they are able to validate the assertion offered by the target server in the stream features. The first validation proves to the originating server that it is talking to a server authoritative for the target domain, so that it is safe to use this domain in "to" addresses on this stream.

Once an originating server completes this first validation it signals that it is willing and able to participate in bi-directional XMPP federation traffic, as long as all of the domains required have been asserted and validated at least once on this stream.

If the originating server does not require more proof (due to a certificate match or DNSSEC-verified delegation), it MAY send a valid element without requesting proof first, as in all DNA interactions.

Example 11. Originating server asks for proof, if required
<challenge xmlns='urn:xmpp:dna:0' to='target.tld'>
  <proof type='urn:xmpp:dna:proof:attribute-cert'/>
Example 12. Target server provides proof
<proof xmlns='urn:xmpp:dna:0' from='target.tld' type='urn:xmpp:dna:proof:attribute-cert'>
(ascii-armored attribute certificate)
Example 13. Originating server accepts proof, turns on DNA
<valid xmlns='urn:xmpp:dna:0' to='target.tld'/>

6.5 Asserting new domains

Before either side sends stanzas on a given stream, it MUST ensure that the other side will accept those stanzas by asserting the domain in the "from" attribute of those stanzas, and waiting for a <valid/> response before sending the stanzas in question.

The originating server MUST therefore send its own assertion after accepting the target domain's assertion.

Example 14.
<assert xmlns='urn:xmpp:dna:0' from='originator.tld'/>

6.6 Proactive challenges

Before either side sends stanzas on a given stream, it MUST ensure that the other side is authoritative for the domain in the "to" attribute on those stanzas. If the sender has already accepted an assertion on this stream, and that assertion has not been revoked with an <impossible/> element, no action is required. Otherwise, the sender can proactively request proof for that domain by sending a challenge even though the other side has not sent an assertion for that domain yet.

Example 15. Proactive challenge
<challenge xmlns='urn:xmpp:dna:0' to='othertarget.tld'>
  <proof type='urn:xmpp:dna:proof:attribute-cert'/>

6.7 Proactive validation

When two hosting providers connect, they might have previous knowledge (perhaps from a cache) of which domains they will trust on the new connection. If so, either side MAY send as many <valid/> elements as desired, even though the other side has not sent assertions for those domains.

The server receiving these proactive validations MUST NOT change its self-image (i.e., the list of domains for which it is authoritative), but SHOULD NOT send assertions for these domains on this stream. If the server receiving a proactive validation is no long authoritative for a given domain, it MUST send an <impossible/> element, at which point the sender MUST remove the receiver from any cache and not send any stanzas on this stream to the given domain.

Any cache of DNA information SHOULD be associated with the certificate offerred by the relevant server, and SHOULD be checked for revocation if possible, according to local policy.

Example 16. Proactive validations
<valid xmlns='urn:xmpp:dna:0' to='target1.tld'/>
<valid xmlns='urn:xmpp:dna:0' to='target2.tld'/>
<valid xmlns='urn:xmpp:dna:0' to='target3.tld'/>

6.8 Reusing streams

DNA streams are bi-directional, and might have an arbitrary number of domains validated in either direction, at any point in the lifetime of the stream. Before sending a stanza on a given stream, the sender MUST ensure that <valid/> elements have been exchanged according to the above rules for both the "to" and "from" address, and that no <invalid/> or <impossible/> element has revoked an assertion.

An <impossible/> or <invalid/> element SHOULD NOT cause the rest of the stream to become invalidated in either directions. When these elements are seen, they SHOULD merely change the list of domains that are valid on that stream. If no domains are valid on the stream, the stream MAY be closed immediately, or MAY be left open if desired. If left open, the stream MUST NOT be used for stanza traffic until domains are asserted as needed for the desired domains.

Domains that are marked as <invalid/> or <impossible/> SHOULD NOT be retried on the same stream unless new information has become available, in order to prevent assertion storms.

6.9 Implementation notes

If the first server-to-server validation exchange fails, the parties MAY keep the connection open (perhaps for a shorter period than is usual) in case another domain pair would need a connection between these servers.

The parties SHOULD ensure that only one challenge is outstanding on a given connection for a given domain, and that only one assertion or one proof is outstanding on a given connection for a given domain.

7. DNA for XMPP client connections

Hosting providers have a similar problem for client-to-server connections. Clients need to ensure that they are talking to an authoritative server for the domain they intend to log in to. Typically, this is done by examining the certificate offered by the server during TLS negotiation, according to the rules in rfc3920bis. However, hosting providers will typically not have access to a valid certificate for the target domain and its associated private key. DNA can be used for the hosting provider to prove that hosting services have been delegated to it.

7.1 Announcing Support

To announce its support for DNA, the server asserts its identity in the stream features following TLS negotiation. The server MUST offer the identity of the domain specified in the client's stream header "to" attribute.

Example 17. Server assertion
  <assert xmlns='urn:xmpp:dna:0' from='target.tld'/>

7.2 Client challenges for proof

To utilize the server's DNA assertion, the client performs Start-TLS per rfc3920bis, however, if the client does not find a name match on the offered certificate, it does not disconnect immediately. Instead, if the server offers an assertion, it can use the name from that assertion to ask the server for proof of delegation.

Subsequent protocol follows the generic use cases above, with the exception that alternate or additional domain names MUST NOT be asserted. If the server returns an <impossible/> element, the server MUST terminate the stream. If the client sends an <invalid/> element, the client MUST terminate the stream.

Example 18. Client challenges for proof
<challenge xmlns='urn:xmpp:dna:0' to='asserted.tld'>
  <proof type='urn:xmpp:dna:proof:attribute-cert'/>

8. Internationalization Considerations

The domains offered are International Domain Names, as specified in rfc3920bis.

9. Security Considerations

For the urn:xmpp:dna:proof:attribute-cert proof type, the trust path for an assertion flows from two different trust anchors, one that proves the identity of the hosting provider, and another that proves the identity of the delegating party.

All proof types SHALL have a mechanism to limit the period of availability.

All proof types SHALL include a mechanism for revocation.

10. XMPP Registrar Considerations

A new registry of proof types will be required, which might be maintained by the XMPP Registrar [6] or by the Internet Assigned Numbers Authority (IANA) [7]. These proof types have URI syntax.

11. XML Schema

To follow.


Appendix A: Document Information

XMPP Standards Foundation
Standards Track
Last Updated
Approving Body
XMPP Council
RFC 3920, RFC 3281
XEP-0220, XEP-0238
Superseded By
Short Name

This document in other formats: XML  PDF

Appendix B: Author Information

Joe Hildebrand


This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).


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. ##

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 from, out of, or in connection with the Specification or the implementation, deployment, or other use of 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 can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) 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.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Given that this XMPP Extension Protocol normatively references IETF technologies, discussion on the <xsf-ietf@xmpp.org> list might also be appropriate.

Errata can be sent to <editor@xmpp.org>.

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. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-ietf-saintandre-rfc3920bis>.

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

3. RFC 3986: Uniform Resource Identifiers (URI): Generic Syntax <http://tools.ietf.org/html/rfc3986>.

4. RFC 3281: An Internet Attribute Certificate Profile for Authorization <http://tools.ietf.org/html/rfc3281>.

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

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

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

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

  1. Version 0.0.1 (2009-07-27)

    First draft.