Network Working Group                                        J. Lindberg                                          R. Barnes
Internet-Draft                                                    Google                                          BBN Technologies
Intended status: Standards Track                              S. Farrell                             J. Lindberg
Expires: July 18, 2010                                   NewBay Software
                                                        January September 15, 2011                                       Google
                                                          March 14, 2010 2011

                         Domain Name Assertions
                         draft-ietf-xmpp-dna-00
                         draft-ietf-xmpp-dna-01

Abstract

   An application-level approach to asserting and proving

   The current authentication process in XMPP requires the delegated
   ownership of XMPP server
   for a domain name to present a certificate that contains that domain's
   name.  This requirement causes several problems in scenarios where
   XMPP services have been delegated from one domain to another,
   especially when one domain provides XMPP services for XMPP. many domains.
   This document describes an extension to the XMPP authentication
   process that allows domains to be securely delegated, simplifying
   authorization in delegation scenarios.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 18, 2010. September 15, 2011.

Copyright Notice

   Copyright (c) 2010 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Glossary . .  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Requirements . . .
   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Generic Use Cases  . . . . .
   4.  Connection Model . . . . . . . . . . . . . . . . .  5
     5.1.  Assertions . . . . . .  8
   5.  Channel Establishment and Authentication . . . . . . . . . . .  9
   6.  Authorizing XMPP Stanzas . . . . . . .  5
     5.2.  Validation . . . . . . . . . . . . 13
   7.  Backward Compatibility . . . . . . . . . . . .  5
     5.3.  Invalidation . . . . . . . . 15
   8.  Operational Considerations . . . . . . . . . . . . . . .  5
     5.4.  Requesting proof with a challenge . . . 16
   9.  IANA Considerations  . . . . . . . . .  6
     5.5.  No proof possible . . . . . . . . . . . . 16
   10. Security Considerations  . . . . . . . .  6
     5.6.  Proving a challenge . . . . . . . . . . . 16
   11. Acknowledgements . . . . . . . .  7
   6.  Attribute Certificate Proof . . . . . . . . . . . . . . . 16
   12. Normative References . .  7
     6.1.  Attribute Certificate Issuer Profile . . . . . . . . . . .  8
     6.2.  Attribute Certificate Profile . . . . . . . . 17
   Authors' Addresses . . . . . .  8
     6.3.  Access Identity Values . . . . . . . . . . . . . . . . . .  8
       6.3.1.  XMPP . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.4.  Attribute Certificate Signature Algorithms . . . . . . . .  9
     6.5.  Proof Encoding . . . . . . . . . . . . . . . . . . . . . .  9
   7.  DNA for XMPP Federation  . . . . . . . . . . . . . . . . . . .  9
     7.1.  DNS SRV lookups  . . . . . . . . . . . . . . . . . . . . . 10
     7.2.  Certificates during Start-TLS  . . . . . . . . . . . . . . 10
     7.3.  Discovering Support  . . . . . . . . . . . . . . . . . . . 11
     7.4.  Turning on DNA . . . . . . . . . . . . . . . . . . . . . . 11
     7.5.  Asserting new domains  . . . . . . . . . . . . . . . . . . 12
     7.6.  Proactive challenges . . . . . . . . . . . . . . . . . . . 12
     7.7.  Proactive validation . . . . . . . . . . . . . . . . . . . 12
     7.8.  Reusing streams  . . . . . . . . . . . . . . . . . . . . . 13
     7.9.  Implementation notes . . . . . . . . . . . . . . . . . . . 13
   8.  DNA for XMPP client connections  . . . . . . . . . . . . . . . 13
     8.1.  Announcing Support . . . . . . . . . . . . . . . . . . . . 14
     8.2.  Client challenges for proof  . . . . . . . . . . . . . . . 14
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     9.1.  XML Namespace Name for DNA . . . . . . . . . . . . . . . . 14
     9.2.  URN space for standard DNA Proof Types . . . . . . . . . . 14
     9.3.  DNA Proof Registry . . . . . . . . . . . . . . . . . . . . 15
     9.4.  Object Identifiers . . . . . . . . . . . . . . . . . . . . 15
   10. Internationalization Considerations  . . . . . . . . . . . . . 15
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   12. Normative References . . . . . . . . . . . . . . . . . . . . . 15
   Appendix A.  RELAX NG XML Schema . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17

1.  Introduction

   As large hosting providers begin providing 17

1.  Introduction

   When connecting two XMPP services to provide inter-domain
   communication, it is important for multiple
   domains, several issues with previous mechanisms a service to be able to determine
   the identity of a peer service to prevent traffic spoofing.  The
   Jabber communities first approach to identity verification was the
   Server Dialback protocol.  When the Jabber protocols were formalized
   by the XMPP working group of the IETF 2002-04, support for server-to-server
   federation have become apparent.

   A large number strong
   identity verification using TLS + SASL was added.

   Server Dialback [XEP-0220] provides weak identity verification and
   makes it more difficult to spoof hostnames of sockets are currently required servers XMPP network.
   However, it does not provide authentication between hosting
   providers.  Although servers may attempt and is
   not a security mechanism.  It is susceptible to piggyback whenever
   possible, the possibility exists that 2*N*M sockets will be created
   (where N DNS poisoning attacks
   (unless DNSSEC is the number of domains on one hosting provider, used) and M is
   the number cannot protect against attackers capable
   of domains on another hosting provider).  The goal would
   be that hijacking the number IP address of sockets was dependent on load or deployment
   considerations.

   In order to enable or require encryption, the hosting provider must
   create a separate socket for each hostname pair and have access to remote service.

   TLS + SASL provides strong identity verification but requires a
   X.509
   obtaining a digital certificate that is signed by a widely-trusted trusted CA and includes
   both (or the public XMPP
   Intermediate Certification Authority) and private keys.  Customers using it in the XMPP
   service, which may be hosted by a 3rd party.  This solution does not
   allow for multiplexing traffic for multiple domain pairs over a
   connection, possibly requiring a large number of connections between
   two hosting providers
   might providers.

   Server Dialback can be uncomfortable used with TLS.  When STARTTLS negotiation
   succeeds with a peer service but the level of trust this requires.

   This document lays out peer's certificate cannot be
   used to establish the peer's identity, the remote domain may use on
   Server Dialback for (weak) identity verification.  One use case can
   be an approach known as Domain Name Assertions
   (DNA) originating server that allows providers wish to effectively host use TLS for encryption, but
   only can present a self signed certificate.

   In practice, many XMPP services server deployments rely on
   behalf of other companies, Server Dialback and might be expanded later to
   either do not support
   other protocols.

2.  Acknowledgements

   The original version of this specification was written by Joe
   Hildebrand and Sean Turner.

3.  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 1.0 or
      more domains that it does do not directly and fully control.
   Self-hosted domain  A domain whose owner acts as its hosting
      provider.
   Delegation  A ceremony that acts as proof of the intent offer negotiation of the owner TLS +
   SASL.

   This goal of a hosted domain to cede control this document is to describe secure authentication using
   a hosting provider for a
      given protocol.
   Widely-trusted CA  For open communities, a Certificate Authority
      whose provide TLS certificate that is trusted by multiple web browsers by
      default.  For closed communities, from a Certificate Authority that is trusted by all members of that community.

   Sender Domain  The domain associated CA, combined with the 'from' address on a
      stanza to be sent across a federation boundary.
   Target Domain  The domain associated with the 'to' address
   dialback mechanism providing secure delegation based on a
      stanza DNS record
   delgation verified using DNSSEC.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be sent across a federation boundary.
   Originating Server  The machine that wants interpreted as described in RFC
   2119 [RFC2119].

   We will refer to send a message from an
      entity at the four different types of domains in this document:

   o  Sender Domain to domain: The domain that initially sends out an entity at the XMPP message

   o  Target Domain and
      thus is attempting to establish domain: The ultimate destination of an XMPP message

   o  Originating domain: The originating domain of a particular server-
      to-server connection between the two
      servers.

   o  Receiving Server domain: The machine to which the Originating Server has
      opened receiving domain of a particular server-to-
      server connection for

   In outsourcing scenarios, the purpose of sending a message from the
      Sender Domain and receiving domains are
   outsourced 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 originating and receiving domains, respectively.

3.  Protocol Overview

   Consider a
      conversation. validating entities may require assertions to be
      backed up with proof.
   Proof  A secure mechanism through scenario in which a validating entity can
      ascertain that an asserting entity has authority for the asserted
      domain, either directly or indirectly (by delegation).

4.  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 network traffic (except for initial handshakes) MUST be
       encrypted in a manner not subject domain sender.tld has outsourced
   XMPP services to man-in-the-middle attacks.
   3. originating.tld, and target.tld has outsourced to
   receiving.tld.  The number of socket particular hosts providing services are
   xmpp1.originating.tld and xmpp1.receiving.tld.  Users
   romeo@sender.tld and juliet@target.tld maintain client-to-server
   connections between hosting providers MUST
       NOT be to these servers.
   romeo@sender.tld -- xmpp1.originating.tld
                               .
                               .
                       xmpp1.receiving.tld -- juliet@target.tld

   When Romeo wants to send a message to Juliet, Provider A's server
   will have to establish a function server-to-server connection to Provider B's
   server.  Since they are both acting on behalf of other domains,
   however, each side will have to verify that the number of domains hosted by either
       provider.
   4.  Connections MUST be usable other is authorized
   to act in either direction, if allowed by
       policy and deployment considerations.
   5. that role.

   The owners of the hosted domain MUST NOT first step is to provision records that can be required used to give out
       private keying material associated with any certificate verify
   these delegations.  In order for XMPP to work, when the hosting
   relationships are set up, sender.tld and target.tld have to provision
   SRV records pointing to their providers' servers.  To make this
   delegation secure, they own
       that has been signed by a widely-trusted CA.
   6.  The owners of sign these records using DNSSEC [RFC4033].
   On the hosted domain MUST XMPP servers themselves, the originating and receiving domains
   provision certificates that can be allowed used to choose authenticate the
       frequency with which they wish names
   xmpp1.originating.tld and xmpp1.receiving.tld.

   When Romeo wants to perform send a stanza to Juliet, he will first send it to
   his server, xmpp1.originating.tld.  Seeing that the delegation
       ceremony.
   7.  The owners 'to' domain 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 stanza is target.tld, the server will retrieve the SRV records
   for _xmpp-server._tcp.target.tld, plus any associated DNSSEC records

   [RFC4034].
   _xmpp-server._tcp.target.tld. 400 IN SRV
               20 0 5269 xmpp1.receiving.tld

   _xmpp-server._tcp.target.tld. 400 IN RRSIG
               SRV 5 3 400 20030322173103 (
                 20030220173103 2642 _tcp.target.tld.
                 oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
                 PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
                 B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
                 GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
                 J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

   If there are no DNSSEC records, or if the DNSSEC records do not
   validate, then there is nothing new assertions to be added do; the server simply connects
   to the remote domain using normal XMPP procedures.  If there is a stream at
       any point after
   valid DNSSEC signature on the SRV record, then the server knows that
   he can allow the remote server to authenticate as either target.tld
   or xmpp1.receiving.tld.

   Once the stream TLS connection is fully established, but before the two sides negotiate a
   single bidirectional stream to run over it, using their own names:
   I: <?xml version='1.0'?>
      <stream:stream
          from='xmpp1.originating.tld'
          to='xmpp1.receiving.tld'
          version='1.0'
          xml:lang='en'
          xmlns='jabber:server'
          xmlns:stream='http://etherx.jabber.org/streams'>

   R: <?xml version='1.0'?>
      <stream:stream
          from='xmpp1.receiving.tld'
          id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
          to='xmpp1.originating.tld'
          version='1.0'
          xml:lang='en'
          xmlns='jabber:server'
          xmlns:stream='http://etherx.jabber.org/streams'>

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

   When this stream is closed

5.  Generic Use Cases

   The DNA mechanism created, it can be used for multiple different protocols. immediately carry stanzas
   directly between the two servers.  In
   particular, client-to-server XMPP order to send messages to and server-to-server XMPP are
   discussed herein, but the general approach could be used for non-XMPP
   protocols such as SMTP or IMAP.  As such, the protocol syntax offered
   here is normative for XMPP, but merely illustrative for
   from other
   protocols, which will need their own protocol bindings.

   The following domain names are used in domains, the examples in this section:
   asserted.tld  The domain name being asserted.

5.1.  Assertions servers have to authenticate and request
   permission.  So to send Romeo's stanza to Juliet,
   xmpp1.originating.tld requests permission to send from sender.tld to
   target.tld.

   The asserting entity asserts a domain name through the use of an
   "assert" element.  Assertions MUST contain originating server uses STARTTLS to set up a "from" attribute naming TLS connection.  In
   the domain name that is being asserted.
   <assert xmlns='urn:ietf:params:xml:ns:dna' from='asserted.tld'/>

5.2.  Validation

   When ClientHello message initiating the validating entity has been satisified that connection, the asserting
   entity is authoritative
   xmpp1.originating.tld includes a Server Name Indication extension set
   to xmpp1.receiving.tld [RFC4366].  The remote server
   xmpp1.receiving.tld responds to this request with a certificate for
   its own name, xmpp1.receiving.tld and requests a client certificate
   from the domain name asserted, it MUST send originating server.  The originating server presents a
   "valid" element.
   certificate for its own name, xmpp1.originating.tld.

   At this point, the asserting entity MAY send
   stanzas server xmpp1.originating.tld knows that
   xmpp1.receiving.tld is authorized to represent either
   xmpp1.receiving.tld (via the validating entity containing from addresses in certificate) or target.tld (via DNSSEC).
   The other server, xmpp1.receiving.tld knows only that the
   asserted and validated domain.

   Validating entities SHOULD respond to a domain name assertion without
   asking for further proof when other
   server repressents xmpp1.originating.tld.

   Once the domain name asserted two servers have authenticated their own names over TLS,
   they can request permission to send stanzas:
   I: <db:result from='sender.tld' to='target.tld' />

   Since xmpp1.receiving.tld doesn't yet know whether
   xmpp1.originating.tld is represented
   in authorized to represent sender.tld, it has
   to check, using an abbreviated form of dialback.  Just as the certificate offered by
   Provider A server did earlier for target.tld, the asserting entity according to Provider B server
   looks up the
   rules set out in [rfc3920bis].

   Validating entities MAY respond to a domain name assertion without
   asking SRV records for further proof when _xmpp-server._tcp.sender.tld and any
   associated DNSSEC records.  If there are no DNSSEC records or the domain name asserted
   signature is known not valid, then the server rejects the request to be
   associated with send
   stanzas from that domain.  If the asserting entity through some other secure means
   such as DNSSEC, caching, or local knowledge.  In record is DNSSEC-signed, then the DNSSEC case,
   server checks that the server hostname name in the SRV record used to connect SHOULD be looked is one of the
   names authenticated for in the certificate offered by remote side.
   R: <db:result type='invalid' from='sender.tld' to='target.tld' />

   On the asserting entity, according to other hand, if the rules set out in [rfc3920bis].
   <valid xmlns='urn:ietf:params:xml:ns:dna' to='asserted.tld'/>

5.3.  Invalidation

   When DNSSEC signature is valid, then the validating entity does not server
   can accept proof offered by the
   asserting entity, or request to send stanzas, and the two servers can
   exchange stanzas for those domains.
   R: <db:result type='valid' from'sender.tld' to='target.tld' />

   I: <!-- stanza -->

   Now that the two servers have established this connection, they can
   re-used it no longer trusts for other stanzas and other domains.  If either server
   finds another domain that is delegated to the proof (for example due other server, it can
   send a <db:result> requesting permission to send stanzas for that
   domain, and the proof timing out other server will grant or being revoked), it sends deny permission after
   checking the asserting
   entity an "invalid" element. delegation.

   The following figure summarizes the overal process:
   Originating                   DNS                     Receiving
     Server                    Server                     Server
   -----------               ---------                   --------
       |                          |                          |
       |  Lookup _xmpp-server     |                          |
       |  DNS SRV record for      |                          |
       |  target.tld to find      |                          |
       |  delegation of service   |                          |
       |  to Receiving Server.    |                          |
       |  Verify zone signature   |                          |
       | -----------------------> |                          |
       |                          |                          |
       |  'Receiving Server'      |                          |
       | <----------------------- |                          |
       |                          |                          |
       |                                                     |
       |                                                     |
       |  <stream from='originating.tld' to='receiving.tld'> |
       | --------------------------------------------------> |
       |                                                     |
       |  <stream from='receiving.tld' to='originating.tld'> |
       | <-------------------------------------------------- |
       |                                                     |
       |  <features><starttls></features>                    |
       | <-------------------------------------------------- |
       |                                                     |
       |  <starttls/>                                        |
       | --------------------------------------------------> |
       |                                                     |
       |  <proceed/>                                         |
       | <-------------------------------------------------- |
       |                                                     |
       |                                                     |
       | <====================== TLS ======================> |
       |                                                     |
       |                                                     |
       |  <stream from='originating.tld' to='receiving.tld'> |
       | --------------------------------------------------> |
       |                                                     |
       |  <stream from='receiving.tld' to='originating.tld'> |
       | <-------------------------------------------------- |
       |                                                     |
       |  <features><bidi></features>                        |
       | <-------------------------------------------------- |
       |                                                     |
       |  <db:result from='sender.tld' to='target.tld'/>     |
       | --------------------------------------------------> |
       |                                                     |
       | ...                                                 |

4.  Connection Model

   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.
   <invalid xmlns='urn:ietf:params:xml:ns:dna' to='asserted.tld'/>

5.4.  Requesting proof with a core challenge

   If an assertion cannot be validated immediately, the validating
   entity may ask for further proof.  Inside managing inter-server connections is the "challenge" element, at
   least one form
   multiplexing of proof that will be acceptable MUST be given to the
   asserting entity.  If an acceptable proof format is not available stanzas for
   the asserted domain, the validating entity MUST return an invalid
   response proactively.

   A "proof" element designates multiple domains onto a type of proof that would be acceptable
   to the verifying entity.  The "type" attribute single transport-
   layer connection.  There are two key pieces of the "proof" element
   MUST be a valid URI. state associated with
   this multiplexing: A registry list of proof types will be created with
   the IANA (see Section 9).  Standard proof types will begin with
   "urn:ietf:params:dna:proof:".  Custom proofs should be signaled with domain names that have been
   authenticated for use on a "type" attribute value containing connection, and a full URI under the control table binding pairs of
   the defining party.  Proof types MUST be compared for equality using
   the rules for comparing URIs.

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

   In some protocols, are authorized for a challenge MAY be sent without an assertion, if
   the validating entity has reason to believe connection.

   First table that the entity with
   which it is talking a server maintains is authoritative for a given domain.
   <challenge xmlns='urn:ietf:params:xml:ns:dna' to='asserted.tld'>
     <proof xmlns='urn:ietf:params:dna:proof:attribute-cert'/>
     < type='http://example.com/proof/custom'/>
   </challenge>

5.5.  No proof possible

   If the validating entity requires proof, but will not accept proof by connection table.  Each
   entry in this table contains a means that connection and a set of domain names.
   The domain names represent the asserting entity has available set of names for which the asserted
   domain, remote
   server has been authenticated, according to the asserting entity MUST respond with an "impossible"
   element.  The validating entity MUST NOT send a "valid" or "invalid"
   element procedures described
   in response, and MUST NOT accept stanzas from the asserted Section Section 5.  This set of domain on this connection unless some other assertion works in the
   future.

   The "impossible" element MAY be sent after full validation, if names constrains the
   asserting entity would like set of
   domain pairs that can be bound to retract this channel; the assertion.
   <impossible xmlns='urn:ietf:params:xml:ns:dna' from='asserted.tld'/>

5.6.  Proving a challenge

   If remote server
   cannot ask to transmit stanzas for an asserting entity thinks it can prove unauthenticated domain name.

   +------------+---------------------+------------------------+
   | Connection | Server Domain Names | Delegated Domain Names |
   +------------+---------------------+------------------------+
   | XXX        | xmpp1.provider.com  | capulet.example        |
   | YYY        | xmpp2.provider.com  | capulet.example        |
   | AAA        | paris.example       | paris.example          |
   +------------+---------------------+------------------------+

   To determine how to handle incoming and outgoing stanzas, each server
   maintains a given assertion when
   challenged, it sends that proof channel binding table.  Each row in a "proof" element.  The REQUIRED
   "type" attribute specifies the chosen proof type, and the REQUIRED
   "from" attribute specifies the binding table
   contains a "local" domain being proved.  Each proof type
   MUST specify the format of the contents name, a "remote" domain name, and an
   ordered list of connections.  The identifier for a connection is the "proof" element.
   Suggestions
   stream ID for formats include Base64-encoded binary the single XMPP stream that it carries.

   +------------------+-----------------+---------------+
   | Local            | Remote          | Connections   |
   +------------------+-----------------+---------------+
   | montague.example | capulet.example | XXX, YYY      |
   | laurence.example | capulet.example | AAA           |
   | laurence.example | paris.example   | YYY, AAA      |
   +------------------+-----------------+---------------+
   The binding table acts as character
   data or structured XML in a new namespace.
   <proof xmlns='urn:ietf:params:xml:ns:dna'
          from='asserted.tld'
          type='urn:ietf:params:dna:proof:attribute-cert'>
     (Base64-encoded attribute certificate)
   </proof>

6.  Attribute Certificate Proof

   When an asserting entity has been delegated responsibility routing table for
   hosting outgoing stanzas and a given domain, an Attribute Certificate MUST be used to
   prove
   filter for incoming stanzas.  When the delegation.  The proof type URI associated with attribute
   certificates SHALL be 'urn:ietf:params:dna:proof:attribute-cert'
   (EDITOR'S NOTE: We will work with IANA server wishes to come up with send a good URN.
   This is just
   stanza, it looks in the binding table for a placeholder.)

   The certificate row that signed has the attribute certificate MUST have been
   acceptable 'from'
   domain as proof of ownership of a given the local domain for and the protocol
   in question, according to 'to' domain as the rules remote domain.
   If there is such a in [rfc3920bis].  Validating
   entities SHOULD try prepending the asserted domain with "www." and
   re-checking for name matches before rejecting binding table, then the signing
   certificate, server MUST
   transmit the on the first connection in order the connection list.  Thus,
   in the above example, a stanza from montague.example to allow for easier deployments using existing
   web certificates as proof.

   Each protocol that is delegated will
   capulet.example would be assigned its own OID to
   identify a service and whether routed on channel XXX.

   In the entity can act as same way, when a server or
   client.  These values will be included in the Access Identifier
   attribute, receives a stanza over a connection
   from [I-D.ietf-pkix-3281update].  This document defines a remote server, it looks up the OIDs for XMPP.  Other documents may specify additional OIDs.

   The remaining paragraphs relevant entry in the binding
   table, this section profile time using the attribute
   certificate issuers public key certificate 'to' domain as the local domain and the attribute
   certificate.

6.1.  Attribute Certificate Issuer Profile

   The following is
   'from' domain as the remote domain.  If the server finds a profile of binding
   table entry and the attribute certificate issuer's
   public key certificate, connection over which the stanza arrived is as per [I-D.ietf-pkix-3281update]:
   o  The issuer's certificate MUST conform to [RFC5280].
   o  The issuer's certificate MUST have a keyUsage extension with
   listed in the
      digitalSignature bit set.
   o  The issuer's certificate entry, then it accepts the stanza.  Otherwise, it MUST NOT have a basicConstraints
      extension with
   discard the cA BOOLEAN set to TRUE. stanza and return a stanza error <invalid-connection/>.
   In addition to the [I-D.ietf-pkix-3281update] requirements, the
   subject name MUST above example, a stanza from capulet.example to
   escalus.example would be non-NULL accepted on connections AAA and BBB, but no
   others.

   When a connection is opened (and at some points thereafter), entries
   in the attribute certificate issuer's
   public key certificate.

6.2.  Attribute Certificate Profile

   The attribute certificate issued MUST conform to
   [I-D.ietf-pkix-3281update].  There name table are options in that profile and
   the following profiles those options:
   o  The holder field MUST be the baseCertificateID.
   o  The attributes field MUST include established using the Access Identity attribute,
      as specified processes in Section 4.4.2 of [I-D.ietf-pkix-3281update].  Both
      the service and ident fields' GeneralName choice MUST be
      registeredID.  The service and ident fields MUST be as defined in
   Section 5.3.  Other attributes MAY be included.
   o  The extensions field MUST include 5.  Once a connection is open, binding table entries are
   added or removed using the non-critical noRevAvail
      extension, as defined processes in Section 4.3.6 of
      [I-D.ietf-pkix-3281update], to indicate that no revocation
      information Section 6.  When a
   connection is available from the attribute certificate issuer.
   o  The extensions field MAY include:
      *  The authorityKeyIdentifier extension if the issuer has more
         than one key pair.
      *  The issuerAltName extension if the issuer's certificate
         includes the subjectAltName extension.  If included
         issuerAltName closed, both servers MUST be marked non-critical.

6.3.  Access Identity Values

   The following paragraphs define delete its entry in the service name
   table and ident values for remove it from all entries in the
   delegated protocols.  Currently, only values for XMPP are defined.  A
   later version of this document or another document may specify
   additional values for other protocols.

6.3.1.  XMPP binding table.

5.  Channel Establishment and Authentication

   When XMPP is delegated the following procedures MUST be followed.

   The service field MUST be id-xmpp.  The following object identifier
   identifies that the AC holder supports XMPP:
   id-xmpp OBJECT IDENTIFIER ::= { TBD }

   The ident field MUST be either id-xmpp-client or id-xmpp-server.
   Both id-xmpp-client a server wants to send a stanza and id-xmpp-server MAY appear doesn't have an entry in the same
   attribute certificate.  Note that
   connection table for the Access Identity attribute will
   be multi-valued when both id-xmpp-client and id-xmpp-server are
   present. destination domain, it sets one up.  The following object identifier identifies
   first step is to establish a connection to a server for the AC holder as
   destination domain, and validate that the XMPP
   client:
   id-xmpp-client OBJECT IDENTIFIER ::= { id-xmpp 0 } server is authorized to
   represent the destination domain.

   The following object identifier identifies originating server MUST take the AC holder as following steps to establish a
   secure connection to the server for example.com:

   1.  Retrieve SRV records for XMPP
   server:
   id-xmpp-server OBJECT IDENTIFIER ::= { id-xmpp 1 }

6.4.  Attribute Certificate Signature Algorithms

   The issuer MUST support signing attribute certificate with services for example.com
       [I-D.ietf-xmpp-3920bis].

   2.  Verify that the PKCS
   #1 version 1.5 signature algorithm with SHA-256, as specified in
   [RFC4055].

6.5.  Proof Encoding SRV records have been signed using DNSSEC
       [RFC4033].  The attribute certificate, originating server may either retrieve DNSSEC
       records directly or rely on a validating resolver.  If the issuer's certificate, and all of SRV
       records are not secured with DNSSEC, then the
   CA certificates connection fails.

   3.  If there is already a connection in the trust chain connection table that has
       the target of any SRV record in its "server names" list, then
       this process terminates and the signing certificate back server attempts to
   the trust anchor are encoded as a "certs-only" SMIME message, as per
   [I-D.ietf-smime-3851bis] (i.e, use that
       connection (See Section Section 6)

   4.  If there is no existing connection that matches, establish a degenerate SignedData TCP
       connection to any of the servers listed in an SRV record and
       negotiate an XMPP stream with no
   content just certificates). the following parameters:

       *  'from' domain: The resulting message is then Base64
   encoded, as per Section 6.8 of [RFC2045]. originating server's name

       *  'to' domain: The end result is then
   transmitted as receiving server's name from the character data of SRV record

       *  [[ TODO: Add a "proof" element.

7.  DNA stream feature to indicate support for XMPP Federation

   Two XMPP servers, each of which hosts multiple domains that they do
   not directly control, desire this
          extension ]]

   5.  Upgrade the connection to connect in order TLS using STARTTLS, using a cipher
       suite that requires the server to exchange traffic
   for at least two of those domains (one on either side).

   The following domain names are used in present an X.509 certificate.

   6.  Verify that the examples:
   target.tld  The domain portion of certificate is valid and chains to a local trust
       anchor.  If the JID in certificate is invalid, the to address connection fails.

   7.  Construct a list of all names that the
      stanza certificate presents
       [I-D.saintandre-tls-server-id-check].

   8.  Verify that caused this connection to be initiated.
   othertarget.tld  The domain portion of the JID target name in the to address SRV record is one of a
      stanza being sent across a stream that was originally started to
      talk to target.tld.

   targetprovider.tld  The hosting provider for target.tld.
   server.targetprovider.tld  A server with XMPP federation services at the target's hosting provider.
   originator.tld  The domain portion of names
       in the certificate.  If the JID target name is not found in the from address list
       of names from the certificate, then the stanza that caused this connection to be initiated.
   originatingprovider.tld  The hosting provider for target.tld.
   server.originatingprovider.tld fails.

   A server with XMPP federation
      services at receiving such a connection MUST perform the originator's hosting provider.

7.1.  DNS SRV lookups following
   steps:

   1.  Accept the TCP connection from the remote side and accept the
       stream negotiation using server names.

   2.  In the TLS negotiation, require a delegated hosting scenario, DNS SRV records are REQUIRED, since
   otherwise client certificate from the hosting provider will never be contacted for
       remote side.

   3.  Verify that the target
   domain.  As specified by [rfc3920bis] remote server name in the stream matches the
       client certificate [I-D.saintandre-tls-server-id-check].  If the
       certificate does not match, the TLS negotiation fails, and the originating
       server looks up MAY terminate the target domain to find a list of receiving servers. TCP connection.

   If this process establishes a new connection, then the originating
   server already knows that it has established a connection to a server that
   legitimately represents example.com.  It should thus initialize a row
   in the IP address
   represented by one of these servers (perhaps because it is
   communicating with another domain hosted by connection table for this provider), it MAY
   reuse that stream (see Stream Reuse). connection:

   o  Server names: The list of names in the server's certificate

   o  Delegated names: example.com

   If the originating process terminated at Step 3, then the server does
   not have a simply updates
   the connection it wants table entry to reuse, it performs the SRV
   algorithm add example.com to select an SRV record and makes the list of
   delegated names.  In either case, the row for a TCP connection to is removed
   from the
   server and port specified by connection table when the selected SRV record.

   Unless assured by a mechanism such as DNSSEC, connection is closed.

   In order for this process to work, the originating server
   MUST NOT trust domain owner and the hosting
   provider need to publish information received from that other XMPP entities can use
   to verify the DNS delegation.  XMPP services are delegated via SRV as proof
   that
   records (see Section 3.2.1 of [I-D.ietf-xmpp-3920bis]), so in order
   for the delegation to be secure, the target domain has been owner MUST sign these
   records with DNSSEC.  In other words, if the delegated to domain is
   example.com, then the receiving server.
   % dig +short -t SRV _xmpp-server._tcp.target.tld
   0 1 5269 server.targetprovider.tld

7.2.  Certificates during Start-TLS

   The first step during stream negotiation zone _xmpp-server._tcp.example.com MUST be Start-TLS.  The
   receiving
   signed.  Each server that acts for a domain MUST offer be provisioned with
   a certificate signed that contains the target name used by a widely-trusted
   CA. SRV records.

   The receiving server on the receiving end of the TLS connection MUST require request a
   client certificate.  The certificate offered by from the originating server MUST be signed be a
   widely-trusted CA.  Both sides MUST check during the certificate offered to
   it for validity (e.g. time period, signatures, TLS
   handshake, and trust anchor), but
   MUST NOT disconnect when the certificate received does not contain originating server MUST provide a
   name matching its expectations. client
   certificate.  The receiving server can then also initialize an entry
   in its connection table to which delegated names on these certificates SHOULD can be associated with added later:

   o  Server names: The list of names from the
   relevant hosting provider, and need not be related to client certificate (from
      the domains
   being hosted.  If originating server), if present.  Otherwise, empty.

   o  Delgated names: Empty.

   Once the certificates two servers have the name of the server
   offered in the SRV record, it MAY established a TLS connection, they MUST set
   up an XMPP stream that will be possible to use DNSSEC used for proof
   in the future.
   CN=server.targetprovider.tld
   CN=server.originatingprovider.tld

7.3.  Discovering Support

   To and from addresses are REQUIRED in the stream:stream tag.  These
   represent domains that they represent.
   This process follows the first domain pair associated with this stream, normal stream initiation procedure
   [I-D.ietf-xmpp-3920bis], except that the 'to' and are 'from' domains MUST
   be set to the domain names from of the servers themselves: The originating server
   sends a <stream> stanza that caused this connection with the 'from' domain set to be
   established.

   To announce its support a name for DNA, the receiving server asserts its
   identity
   itself that is contained in its client certificate, and the stream features following TLS negotiation.
   <stream:features>
     <assert xmlns='urn:ietf:params:xml:ns:dna' from='target.tld'/>
   </stream:features>

7.4.  Turning on DNA

   If 'to'
   domain set to the originating server supports DNA, it looks for an assertion name used in the SRV record for this
   connection.  If stream features. negotiation fails, then the connection fails.
   If it finds none, it MAY fall back on another
   means of verifying succeeds, then both sides MUST set the identiy of connection identifier in
   the target server, if allowed by
   local policy.

   Originating servers that support DNA talking connection table to target servers that
   declare support be the stream ID for DNA MUST NOT send protocol other than DNA
   negotations until they are able to validate the assertion offered negotiated stream.

   Since server-to-server connections are by default directional, it is
   RECOMMENDED that servers also request the target server in the <bidi> stream features.  The first validation
   proves feature to the originating server that it is talking
   enable bidirectional flows on this connection [XEP-0288].

   Originating                   DNS                     Receiving
     Server                    Server                     Server
   -----------               ---------                   --------
       |                          |                          |
       |  Lookup _xmpp-server     |                          |
       |  DNS SRV record for      |                          |
       |  target.tld to find      |                          |
       |  delegation of service   |                          |
       |  to Receiving Server.    |                          |
       |  Verify zone signature   |                          |
       | -----------------------> |                          |
       |                          |                          |
       |  'Receiving Server'      |                          |
       | <----------------------- |                          |
       |                          |                          |
       |                                                     |
       |                                                     |
       |  <stream from='originating.tld' to='receiving.tld'> |
       | --------------------------------------------------> |
       |                                                     |
       |  <stream from='receiving.tld' to='originating.tld'> |
       | <-------------------------------------------------- |
       |                                                     |
       |  <features><starttls></features>                    |
       | <-------------------------------------------------- |
       |                                                     |
       |  <starttls/>                                        |
       | --------------------------------------------------> |
       |                                                     |
       |  <proceed/>                                         |
       | <-------------------------------------------------- |
       |                                                     |
       |                                                     |
       | <====================== TLS ======================> |
       |                                                     |
       |                                                     |
       |  <stream from='originating.tld' to='receiving.tld'> |
       | --------------------------------------------------> |
       |                                                     |
       |  <stream from='receiving.tld' to='originating.tld'> |
       | <-------------------------------------------------- |
       |                                                     |
       |  <features><bidi></features>                        |
       | <-------------------------------------------------- |

6.  Authorizing XMPP Stanzas

   Before sending traffic from a server
   authoritative for the target domain, so that it is safe Sender Domain to use this
   domain in "to" addresses on this stream.

   Once a Target Domain using
   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 established connection, the originating server does not require more proof (due MUST request
   permission to a
   certificate match or DNSSEC-verified delegation), it may send a
   "valid" element without requesting proof first, as in all DNA
   interactions.
   <challenge xmlns='urn:ietf:params:xml:ns:dna' to='target.tld'>
     <proof type='urn:ietf:params:dna:proof:attribute-cert'/>
   </challenge>

   <proof xmlns='urn:ietf:params:xml:ns:dna'
          from='target.tld'
          type='urn:ietf:params:dna:proof:attribute-cert'>
     (Base64-encoded attribute certificate)
   </proof>
   <valid xmlns='urn:ietf:params:xml:ns:dna' to='target.tld'/>

7.5.  Asserting new domains

   Before either side sends stanzas on a given stream, do so, and wait until it has received authorization
   from the remote service.  A service receiving traffic MUST ensure verify
   that the other side will accept those stanzas by asserting the domain
   in the "from" attribute of those stanzas, Sender and waiting for a "valid"
   response before sending Target domain pair has been authorized on the stanzas in question.

   The
   connection being used.

   An originating server MUST therefore send its own assertion after
   accepting go through the target domain's assertion.
   <assert xmlns='urn:ietf:params:xml:ns:dna' from='originator.tld'/>

7.6.  Proactive challenges

   Before either side sends stanzas on following steps to reqeust
   authorization to send traffic from a given stream, it MUST ensure
   that the other side is authoriative 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 Sender Domain to a
   challenge even though the other side has not sent an assertion for
   that domain yet.
   <challenge xmlns='urn:ietf:params:xml:ns:dna' to='othertarget.tld'>
     <proof type='urn:ietf:params:dna:proof:attribute-cert'/>
   </challenge>

7.7.  Proactive validation

   When two hosting providers connect, they may have previous knowledge
   (perhaps from Target
   Domain:

   1.  Send a cache) of which domains they will trust on the new
   connection.  If so, either side MAY send as many "valid" elements <db:result/> [XEP-0220] element with Sender Domain as
   desired, even though the other side has not sent assertions for those
   domain.
       'from' and Target Domain as 'to'.  The server receiving these proactive validations MUST NOT change its
   self-image (which domains it thinks it is authoritative for), but
   SHOULD NOT send assertions for these domains on this stream.  If the
   server receiving may also include a proactive validation is no long authoritative
       Dialback Key as part of the element's character data, to support
       legacy deployments.

   2.  Wait for remote service to respond with a given domain, it MUST send an "impossible" element, at which point <db:result> with Target
       Domain as 'from', Sender Domain as 'to' and 'type' attribute that
       is either 'valid' or 'invalid'.  In case of 'invalid', the sender MUST remove
       originating server SHOULD examine the receiver from any cache error cause and not send any
   stanzas take
       appropriate action and MAY retry requesting authorization on this stream to the given domain.

   Any cache of DNA information SHOULD be associated with
       same connection in the
   certificate offerred by future.

   3.  If response 'type' was 'valid', the relevant server, and SHOULD be checked
   for revocation if possible, according originating server updates
       its binding table to local policy.
   <valid xmlns='urn:ietf:params:xml:ns:dna' to='target1.tld'/>
   <valid xmlns='urn:ietf:params:xml:ns:dna' to='target2.tld'/>
   <valid xmlns='urn:ietf:params:xml:ns:dna' to='target3.tld'/>

7.8.  Reusing streams

   DNA streams are bi-directional, indicate that Sender Domain (Local) and may have an aribtrary number of
   domains validated in either direction, at any point
       Target Domain (Remote) is authorized in the lifetime
   of sending direction for
       the stream.  Before connection used.

   4.  Originating server proceeds with sending traffic from Sender
       Domain to Target Domain.

   Upon receiving a stanza on a given stream, <db:result/> stanza, the sender receiving server MUST ensure take
   following steps:

   1.  Verify that "valid" elements have been exchanged according to the above rules receiving direction is supported for both this
       connection.  If not, fail by disconnecting the "to" and "from" address, and stream.  (By
       default, connections are one-way)

   2.  Verify that no
   "invalid" or "impossible" element has revoked an assertion.

   An "impossible" or "invalid" element SHOULD NOT cause domain in to-attribute is hosted by the rest service.  If
       not, fail and respond with an <item-not-found/> error.

   3.  Verify that domain in from-attribute delegates hosting of the
   stream their
       XMPP to become invalidated in either directions.  When these
   elements are seen, they SHOULD merely change the remote Server Domain Name by looking up SRV and
       verifying that the zone is signed.  If not, fail with a <not-
       authorized/> error.  Note: a service MAY accept a less secure
       delegation mechanism such a SRV records in a non signed zone,
       subject to local policy.

   4.  Once secure delegation from Sending Domain to remote Server
       Domain name has been verified, service adds Sending Domain to
       list of domains that
   are valid on that stream.  If no domains are valid on Delegated Domain Names in the stream, Connection Table, and
       updates the
   stream MAY be closed immediately, or MAY be left open if desired.  If
   left open, Binding Table indicating that the stream MUST NOT be used for stanza Sending Domain
       (remote) is allowed to send traffic until
   domains are asserted as needed for the desired domains.

   Domains that are marked as "invalid" or "impossible" SHOULD NOT be
   retried to Target Domain (local) on
       the same stream unless new information has become
   available, in order connection.

   5.  Respond to prevent assertion storms.

7.9.  Implementation notes

   If the first server-to-server validation exchange fails, the parties
   MAY keep the connection open (perhaps remote service with a <db:result/> stanza with 'type'
       set to 'valid'.

   A service may revoke authorization for a shorter than is usual) in
   case another domain pair would need at any time by
   sending a connection between these
   servers.

   Ensure <db:result> with 'type' set to invalid.  Once authorization
   has been revoked, the remote side MUST re-aquire authorization before
   sending any futher traffic for the domain pair.

   If a server receives a stanza for a to/from pair that only it does not
   consider authorized, then it MUST return a <not-authorized/> error
   and MAY terminate the TCP connection.

   Originating               Receiving                     DNS
     Server                    Server                     Server
   -----------               ---------                   --------
       |                          |                          |
       |  <db:result              |                          |
       |     from='sender.tld'    |                          |
       |     to='target.tld'/>    |                          |
       | -----------------------> |                          |
       |                          |  Lookup _xmpp-server     |
       |                          |  DNS SRV record for      |
       |                          |  sender.tld to verify    |
       |                          |  signed delegation of    |
       |                          |  delegation of service   |
       |                          |  to Originating Server   |
       |                          | -----------------------> |
       |                          |                          |
       |                          |  Result                  |
       |                          | <----------------------- |
       |                          |
       |  <db:result              |
       |    from='target.tld'     |
       |    to='sender.tld'       |
       |    type='valid'/>        |
       | <----------------------- |
       |                          |
       |  (Traffic authorized     |
       |   from sender.tld to     |
       |   target.tld, in one challenge     |
       |   direction.)            |
       |                          |
       |  <message                |
       |    from='r@sender.tld'   |
       |    to='j@target.tld'>    |
       |    <body>hi</body>       |
       |  </message>              |
       | -----------------------> |

7.  Backward Compatibility

   Using Server Domain Names as to/from attributes in <stream> stanzas
   is outstanding on a given connection
   for a given domain.  Ensure incompatible with XMPP services that only one assertion or one proof is
   outstanding on do not support this protocol,
   because it was previously assumed that when receiving a given connection for a given domain.

8.  DNA for XMPP client connections

   Hosting providers have a similar problem for client to server
   connections.  Clients need to ensure that they are talking
   the stream to attibute will contains an
   authoritative server for the XMPP domain they intend to log in to.
   Typically, this is done hosted by examining the certificate offered by
   receiving service.  It is RECOMMENDED that if the
   server during TLS negotiation, according to connection fails,
   the rules in
   [rfc3920bis].  However, hosting providers will typically not have
   access to service tries again using the Remote Domain as stream to-
   attribute.

   Presenting a valid certificate for the target domain and its
   associated private key.  DNA can be used for the hosting provider to
   prove that hosting Server Domain Name is incompatible
   with XMPP services have been delegated to it.

8.1.  Announcing Support

   To announce its that do not support for DNA, this protocol, because those
   will expect the server asserts its identity Remote Domain in the stream features following TLS negotiation.  The server MUST offer certificate.  It is RECOMMENDED
   that if the identity of authorization fails, the domain specified in service tries again presenting
   the client's stream header
   "to" attribute.
   <stream:features>
     <assert xmlns='urn:ietf:params:xml:ns:dna' from='target.tld'/>
   </stream:features>

8.2.  Client challenges certificate 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 Remote Domain.  A service may also choose to
   fall back on the offered certificate, it does not disconnect immediately.
   Instead, if the server offers an assertion, it can use the name from
   that assertion a weaker identification mechanism such as Server
   Dialback, subject to ask the server local policy.

8.  Operational Considerations

   [[ What names to put in certs for proof servers in a cluster, i.e., all of delegation.

   Subsequent protocol follows the generic use cases above, with the
   exception that alternate or additional domain
   them. ]]

   [[ Do TLS clients support multiple 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 in certs? ]]

   [[ How DNSSEC validation is done can vary depending on deployment
   scenario. ]]

   [[ Since SNI is used to signal support for this extension,
   recommended not to serve end users on the stream.
   <challenge xmlns='urn:ietf:params:xml:ns:dna' to='asserted.tld'>
     <proof type='urn:ietf:params:dna:proof:attribute-cert'/>
   </challenge> same domain as hosting
   services. ]]

   [[ Load balancing thoughts, since each connection will handle a lot
   more traffic? ]]

9.  IANA Considerations

9.1.

   [[ Register XML Namespace Name schema for DNA

   A URN sub-namespace for Domain Name Assertion (DNA) negotiation data
   in the Extensible Messaging assertions, if necessary ]]

   [[ Define invalid-connection error element ]]

10.  Security Considerations

   [[ This document simplifies authentication and Presence Protocol (XMPP) is defined
   as follows.  (This namespace name adheres to the format defined authorization of XMPP
   servers in .)

   URI:  urn:ietf:params:xml:ns:dna
   Specification:  XXXX
   Description:  This is the XML namespace name certain scenarios.  When used together with DNSSEC-
   protected delegations, it does not introduce any new security risks.
   ]]

   [[ If a provider chooses to omit DNSSEC checks or ]]

11.  Acknowledgements

   Thanks to Joe Hildebrand and Sean Turner for Domain Name
      Assertion (DNA) negotiation data in prompting the Extensible Messaging original
   work on this problem, and
      Presence Protocol (XMPP) as defined by XXXX.
   Registrant Contact:  IETF, XMPP Working Group, <xmppwg@xmpp.org>

9.2.  URN space for standard DNA Proof Types

   A URN sub-namespace for DNA is defined as follows.  (This namespace
   name adheres to the format defined in .)
   URI:  urn:ietf:params:dna:proof
   Specification:  XXXX
   Description:  This is the sub-namespace Stephen Farrell for standardized Domain Name
      Assertion (DNA) proof types as defined by XXXX.
   Registrant Contact:  IETF, XMPP Working Group, <xmppwg@xmpp.org>

9.3.  DNA Proof Registry

   The URNs inside urn:ietf:params:dna:proof

9.4.  Object Identifiers

   The following OIDs are defined in Section 5.3 his work on initial
   versions of this document:
   o  id-xmpp
   o  id-xmpp-client
   o  id-xmpp-server

10.  Internationalization Considerations

   The domains offered MUST conform to all of the rules for "Domain
   Identitifiers", as specified in &rfc3920bis;, including (but not
   limited to) the rules for syntax, cannonicalization and comparison.

11.  Security Considerations

   TBD. draft.

12.  Normative References

   [rfc3920bis]

   [I-D.ietf-xmpp-3920bis]
              Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-02 draft-ietf-xmpp-3920bis-22 (work
              in progress), September 2009.

   [I-D.ietf-pkix-3281update]
              Housley, R., Farrell, S., December 2010.

   [I-D.saintandre-tls-server-id-check]
              Saint-Andre, P. and S. Turner, "An Internet
              Attribute Certificate Profile for Authorization",
              draft-ietf-pkix-3281update-05 (work in progress),
              April 2009.

   [I-D.ietf-smime-3851bis]
              Ramsdell, B. J. Hodges, "Representation and S. Turner, "Secure/Multipurpose
              Verification of Domain-Based Application Service Identity
              within Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", draft-ietf-smime-3851bis-11 Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", draft-saintandre-tls-server-id-check-14
              (work in progress), May 2009.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC4055]  Schaad, J., Kaliski, B., and R. Housley, "Additional
              Algorithms and Identifiers for RSA Cryptography January 2011.

   [RFC2119]  Bradner, S., "Key words for use in
              the Internet X.509 Public Key Infrastructure Certificate RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Certificate Revocation List (CRL) Profile", Requirements",
              RFC 4055,
              June 4033, March 2005.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley,

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and Certificate Revocation List
              (CRL) Profile", T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 5280, May 2008.

Appendix A.  RELAX NG XML Schema

   default namespace = "urn:ietf:params:xml:ns:dna"

   # Intent: Internationalized Domain Name (simplisitic view)
   domain = xsd:string { pattern = "(\p{L}|\p{N})(\p{L}|\p{N}|\p{M}|-)*"
   "(\.(\p{L}|\p{N})(\p{L}|\p{N}|\p{M}|-)*)*"}

   assert = element assert {
     attribute from { domain }
   }

   valid = element valid {
     attribute to { domain }
   }

   invalid = element valid {
     attribute to { domain }
   }

   proof = element proof {
    attribute type { xsd:anyURI },
    attribute from { domain }?,
    text?
   }

   challenge = element challenge {
     proof+
   }

   start = assert | valid | invalid | proof | challenge 4366, April 2006.

   [XEP-0220]
              Miller, J., Saint-Andre, P., and P. Hancke, "Server
              Dialback", XSF XEP 0220, March 2010.

   [XEP-0288]
              Hancke, P. and D. Cridland, "Bidirectional Server-to-
              Server Connections", XSF XEP 0288, October 2010.

Authors' Addresses

   Richard L. Barnes
   BBN Technologies

   Email: rbarnes@bbn.com

   Jonas Lindberg
   Google

   Email: jonasl@google.com

   Stephen Farrell
   NewBay Software

   Email: sfarrell@newbay.com