Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7712.
Expired & archived
Authors Jonas Lindberg , Richard Barnes
Last updated 2011-03-14 (Latest revision 2010-01-14)
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7712 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-xmpp-dna-01
Network Working Group                                       A. Mayrhofer
Request for Comments: 4725                                       enum.at
Category: Informational                                     B. Hoeneisen
                                                                  Switch
                                                           November 2006

                      ENUM Validation Architecture

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

   An ENUM domain name is tightly coupled with the underlying E.164
   number.  The process of verifying whether or not the Registrant of an
   ENUM domain name is identical to the Assignee of the corresponding
   E.164 number is commonly called "validation".  This document
   describes validation requirements and a high-level architecture for
   an ENUM validation infrastructure.

Mayrhofer & Hoeneisen        Informational                      [Page 1]
RFC 4725              ENUM Validation Architecture         November 2006

Table of Contents

   1. Introduction ....................................................3
   2. Requirements ....................................................3
   3. ENUM Provisioning Model and Roles ...............................4
      3.1. Number Assignment Entity (NAE) .............................5
      3.2. Assignee ...................................................7
      3.3. Registrant .................................................7
      3.4. Validation Entity (VE) .....................................7
      3.5. Registry ...................................................8
      3.6. Registrar ..................................................8
      3.7. Domain Name System Service Provider (DNS-SP) ...............8
      3.8. Application Service Provider (ASP) .........................8
   4. Validation Process Assumptions ..................................9
      4.1. Workflow ...................................................9
      4.2. Trust Relations ...........................................10
      4.3. Data Flow and Format ......................................11
   5. Example Scenarios ..............................................11
      5.1. E.164 Number Assignment along with ENUM Registration ......11
      5.2. Fully Disjoint Roles ......................................13
   6. Security Considerations ........................................14
      6.1. Fraud Prevention ..........................................14
      6.2. Assignee Data .............................................14
   7. Acknowledgements ...............................................15
   8. References .....................................................15
      8.1. Normative References ......................................15
      8.2. Informative References ....................................15

Mayrhofer & Hoeneisen        Informational                      [Page 2]
RFC 4725              ENUM Validation Architecture         November 2006

1.  Introduction

   E.164 Number Mapping (ENUM) [1] uses the Domain Name System (DNS) [4]
   to refer from E.164 numbers [2] to Uniform Resource Identifiers
   (URIs) [3].  E.164 numbers are mapped to domain names through means
   described further in RFC 3761 [1].

   "Ordinary" domain names are usually allocated on a first-come-first-
   served basis, where the associated registration data is the complete
   source of ownership.  However, ENUM domain names are linked to E.164
   numbers, and thus intrinsically tied to the status and the "Assignee"
   (defined in Section 3.2) of the corresponding E.164 number.

2.  Requirements

   Preserving integrity between ENUM and E.164 is one of the main
   concerns in ENUM implementations, and often one of the reasons why
   "trials" precede commercial implementations.

   To maintain this relationship between E.164 numbers and ENUM domain
   names, registration processes must ensure that the following
   requirements are fulfilled during the entire lifetime of an ENUM
   delegation:

   o  The ENUM domain name corresponds either to an assigned E.164
      number or to a respective E.164 number that is assigned during the
      registration process itself.

   o  The corresponding E.164 number is within a number range approved
      to be used with ENUM.

   o  The registration of the ENUM domain name is authorized by the
      Assignee of the corresponding E.164 number; i.e., the entity
      requesting the registration of an ENUM domain name is either the
      Assignee of the corresponding E.164 number itself or an entity
      authorized to request registration on behalf of said Assignee.

   o  The "Registrant" (see Section 3.3) of the ENUM domain is identical
      to the Assignee of the corresponding E.164 number.

   The process of verifying the above requirements during registration
   is commonly called "initial validation".  In addition to this one-
   time validation process, provisions must be made that ENUM domain
   name delegations are revoked when the above requirements are no
   longer met.  In other words, it must be ensured that the state of the
   ENUM domain name tracks any change in state and ownership of the

Mayrhofer & Hoeneisen        Informational                      [Page 3]
RFC 4725              ENUM Validation Architecture         November 2006

   corresponding E.164 number.  The regular process of checking that the
   above requirements are still satisfied is commonly called "recurring
   validation" or "revalidation".

   The above requirements are usually part of the local registration
   policy issued by the authorities in charge of ENUM administration.

3.  ENUM Provisioning Model and Roles

   The above requirements lead to the introduction of a new role in the
   provisioning model, an entity performing validation related tasks:
   The Validation Entity (VE).  A typical ENUM provisioning model, on
   which this document is based, is depicted in Figure 1:

                           +----------+
                          .| Registry |- -- -- -- -- -- --
                        .  +----------+                   |
                      .          |
                    .            |                        | Trust
            DNS Delegation       |                          Relation
                .                | Registration           |
              .                  |
            .                    |                        |
   +--------+              +-----------+                +----+
   | DNS-SP |-- -- -- -- --| Registrar |----------------| VE |
   +--------+ Nameservers  +-----------+   Validation   +----+
       :                         |                     /  |
       :                         |                  E.164 Number
       :                         | ENUM             Assignment
       : NAPTR                   | Management     _ Verification
       :                         |             /          |
       :                         |          _
       :                         |      /                 |
    +-----+  ENUM enabled  +------------+ E.164 Number +-----+
    | ASP |- -- -- -- -- --| Assignee = |-- -- -- -- --| NAE |
    +-----+    Service     | Registrant |  Assignment  +-----+
                           +------------+

         Legend:

         ASP:    Application Service Provider
         DNS-SP: Domain Name System Service Provider
         NAE:    Number Assignment Entity
         VE:     Validation Entity

                           Figure 1: ENUM Model

Mayrhofer & Hoeneisen        Informational                      [Page 4]
RFC 4725              ENUM Validation Architecture         November 2006

   These different roles are described further below.  Note that an
   entity can act in more than one of these roles simultaneously; for
   example, the Registrar, the DNS-SP, and the ASP roles could be
   performed by a single company.

3.1.  Number Assignment Entity (NAE)

   A Number Assignment Entity (NAE) assigns E.164 numbers to end-users.
   Often, but not always, the Communication Service Provider (CSP) of
   the end-user (Assignee) acts as NAE.  There are two main variants for
   E.164 number assignments:

   1.  Indirect assignment:

       The National Number Plan Administrator (NNPA) assigns ranges of
       E.164 numbers to CSPs.  Out of these ranges, the CSPs assign
       numbers (or number blocks) to their customers (end-users,
       Assignees).  In this variant, the CSPs perform the role of the
       NAE.

   2.  Direct assignment:

       In certain cases, an NNPA assigns E.164 numbers directly to
       Assignees (end-users), and therefore the NNPA acts as NAE in this
       variant.  Typically, this concerns the assignment of special
       purpose numbers (e.g., premium rate).

Mayrhofer & Hoeneisen        Informational                      [Page 5]
RFC 4725              ENUM Validation Architecture         November 2006

   lt;features><bidi></features>                        |

Barnes & Lindberg      Expires September 15, 2011               [Page 7]
Internet-Draft                     DNA                        March 2011

       | <-------------------------------------------------- |
       |                                                     |
       |  <db:result from='sender.tld' to='target.tld'/>     |
       | --------------------------------------------------> |
       |                                                     |
       | ...                                                 |

4.  Connection Model

   The core challenge for managing inter-server connections is the
   multiplexing of stanzas for multiple domains onto a single transport-
   layer connection.  There are two key pieces of state associated with
   this multiplexing: A list of domain names that have been
   authenticated for use on a connection, and a table binding pairs of
   domains that are authorized for a connection.

   First table that a server maintains is a connection table.  Each
   entry in this table contains a connection and a set of domain names.
   The domain names represent the set of names for which the remote
   server has been authenticated, according to the procedures described
   in Section Section 5.  This set of domain names constrains the set of
   domain pairs that can be bound to this channel; the remote server
   cannot ask to transmit stanzas for an 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 channel binding table.  Each row in the binding table
   contains a "local" domain name, a "remote" domain name, and an
   ordered list of connections.  The identifier for a connection is the
   stream ID for 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      |
   +------------------+-----------------+---------------+

Barnes & Lindberg      Expires September 15, 2011               [Page 8]
Internet-Draft                     DNA                        March 2011

   The binding table acts as a routing table for outgoing stanzas and a
   filter for incoming stanzas.  When the server wishes to send a
   stanza, it looks in the binding table for a row that has the 'from'
   domain as the local domain and the 'to' domain as the remote domain.
   If there is such a in the binding table, then the server MUST
   transmit the on the first connection in the connection list.  Thus,
   in the above example, a stanza from montague.example to
   capulet.example would be routed on channel XXX.

   In the same way, when a server receives a stanza over a connection
   from a remote server, it looks up the relevant entry in the binding
   table, this time using the 'to' domain as the local domain and the
   'from' domain as the remote domain.  If the server finds a binding
   table entry and the connection over which the stanza arrived is
   listed in the entry, then it accepts the stanza.  Otherwise, it MUST
   discard the stanza and return a stanza error <invalid-connection/>.
   In the above example, a stanza from capulet.example to
   escalus.example would be accepted on connections AAA and BBB, but no
   others.

   When a connection is opened (and at some points thereafter), entries
   in the name table are established using the processes in Section
   Section 5.  Once a connection is open, binding table entries are
   added or removed using the processes in Section Section 6.  When a
   connection is closed, both servers MUST delete its entry in the name
   table and remove it from all entries in the binding table.

5.  Channel Establishment and Authentication

   When a server wants to send a stanza and doesn't have an entry in the
   connection table for the destination domain, it sets one up.  The
   first step is to establish a connection to a server for the
   destination domain, and validate that the server is authorized to
   represent the destination domain.

   The originating server MUST take the following steps to establish a
   secure connection to the server for example.com:

   1.  Retrieve SRV records for XMPP services for example.com
       [I-D.ietf-xmpp-3920bis].

   2.  Verify that the SRV records have been signed using DNSSEC
       [RFC4033].  The originating server may either retrieve DNSSEC
       records directly or rely on a validating resolver.  If the SRV
       records are not secured with DNSSEC, then the connection fails.

Barnes & Lindberg      Expires September 15, 2011               [Page 9]
Internet-Draft                     DNA                        March 2011

   3.  If there is already a connection in the connection table that has
       the target of any SRV record in its "server names" list, then
       this process terminates and the server attempts to use that
       connection (See Section Section 6)

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

       *  'from' domain: The originating server's name

       *  'to' domain: The receiving server's name from the SRV record

       *  [[ TODO: Add a stream feature to indicate support for this
          extension ]]

   5.  Upgrade the connection to TLS using STARTTLS, using a cipher
       suite that requires the server to present an X.509 certificate.

   6.  Verify that the certificate is valid and chains to a local trust
       anchor.  If the certificate is invalid, the connection fails.

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

   8.  Verify that the target name in the SRV record is one of the names
       in the certificate.  If the target name is not found in the list
       of names from the certificate, then the connection fails.

   A server receiving such a connection MUST perform the 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 client certificate from the
       remote side.

   3.  Verify that the 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
       server MAY terminate the TCP connection.

   If this process establishes a new connection, then the originating
   server knows that it has established a connection to a server that
   legitimately represents example.com.  It should thus initialize a row
   in the connection table for this connection:

Barnes & Lindberg      Expires September 15, 2011              [Page 10]
Internet-Draft                     DNA                        March 2011

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

   o  Delegated names: example.com

   If the process terminated at Step 3, then the server simply updates
   the connection table entry to add example.com to the list of
   delegated names.  In either case, the row for a connection is removed
   from the connection table when the connection is closed.

   In order for this process to work, the domain owner and the hosting
   provider need to publish information that other XMPP entities can use
   to verify the delegation.  XMPP services are delegated via SRV
   records (see Section 3.2.1 of [I-D.ietf-xmpp-3920bis]), so in order
   for the delegation to be secure, the domain owner MUST sign these
   records with DNSSEC.  In other words, if the delegated domain is
   example.com, then the zone _xmpp-server._tcp.example.com MUST be
   signed.  Each server that acts for a domain MUST be provisioned with
   a certificate that contains the target name used by SRV records.

   The server on the receiving end of the TLS connection MUST request a
   client certificate from the originating server during the TLS
   handshake, and the originating server MUST provide a client
   certificate.  The receiving server can then also initialize an entry
   in its connection table to which delegated names can be added later:

   o  Server names: The list of names from the client certificate (from
      the originating server), if present.  Otherwise, empty.

   o  Delgated names: Empty.

   Once the two servers have established a TLS connection, they MUST set
   up an XMPP stream that will be used for domains that they represent.
   This process follows the normal stream initiation procedure
   [I-D.ietf-xmpp-3920bis], except that the 'to' and 'from' domains MUST
   be set to the names of the servers themselves: The originating server
   sends a <stream> stanza with the 'from' domain set to a name for
   itself that is contained in its client certificate, and the 'to'
   domain set to the server name used in the SRV record for this
   connection.  If stream negotiation fails, then the connection fails.
   If it succeeds, then both sides MUST set the connection identifier in
   the connection table to be the stream ID for the negotiated stream.

   Since server-to-server connections are by default directional, it is
   RECOMMENDED that servers also request the <bidi> stream feature to
   enable bidirectional flows on this connection [XEP-0288].

Barnes & Lindberg      Expires September 15, 2011              [Page 11]
Internet-Draft                     DNA                        March 2011

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

Barnes & Lindberg      Expires September 15, 2011              [Page 12]
Internet-Draft                     DNA                        March 2011

6.  Authorizing XMPP Stanzas

   Before sending traffic from a Sender Domain to a Target Domain using
   an established connection, the originating server MUST request
   permission to do so, and wait until it has received authorization
   from the remote service.  A service receiving traffic MUST verify
   that the Sender and Target domain pair has been authorized on the
   connection being used.

   An originating server MUST go through the following steps to reqeust
   authorization to send traffic from a Sender Domain to a Target
   Domain:

   1.  Send a <db:result/> [XEP-0220] element with Sender Domain as
       'from' and Target Domain as 'to'.  The server may also include a
       Dialback Key as part of the element's character data, to support
       legacy deployments.

   2.  Wait for remote service to respond with a <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
       originating server SHOULD examine the error cause and take
       appropriate action and MAY retry requesting authorization on the
       same connection in the future.

   3.  If response 'type' was 'valid', the originating server updates
       its binding table to indicate that Sender Domain (Local) and
       Target Domain (Remote) is authorized in the sending direction for
       the connection used.

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

   Upon receiving a <db:result/> stanza, the receiving server MUST take
   following steps:

   1.  Verify that the receiving direction is supported for this
       connection.  If not, fail by disconnecting the stream.  (By
       default, connections are one-way)

   2.  Verify that domain in to-attribute is hosted by the service.  If
       not, fail and respond with an <item-not-found/> error.

   3.  Verify that domain in from-attribute delegates hosting of their
       XMPP to 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,

Barnes & Lindberg      Expires September 15, 2011              [Page 13]
Internet-Draft                     DNA                        March 2011

       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 Delegated Domain Names in the Connection Table, and
       updates the Binding Table indicating that the Sending Domain
       (remote) is allowed to send traffic to Target Domain (local) on
       the connection.

   5.  Respond to remote service with a <db:result/> stanza with 'type'
       set to 'valid'.

   A service may revoke authorization for a domain pair at any time by
   sending a <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 it does not
   consider authorized, then it MUST return a <not-authorized/> error
   and MAY terminate the TCP connection.

Barnes & Lindberg      Expires September 15, 2011              [Page 14]
Internet-Draft                     DNA                        March 2011

   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     |
       |   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 &These two variants of E.164 number assignment are depicted in
   Figure 2:

   +--------------------------------------------+
   | International Telecommunication Union (ITU)|
   +--------------------------------------------+
                        |
              Country codes (e.g., +44)
                        |
                        v
    +-------------------------------------------+
    | National Number Plan Administrator (NNPA) |------------+
    +-------------------------------------------+            |
                        |                                    |
                  Number Ranges                              |
            (e.g., +44 20 7946 xxxx)                         |
                        |                                    |
                        v                                    |
      +--------------------------------------+               |
      | Communication Service Provider (CSP) |               |
      +--------------------------------------+               |
                        |                                    |
                        |                              Single Numbers
              Either Single Numbers              (e.g., +44 909 8790879)
                 or Number Blocks                       (Variant 2)
     (e.g., +44 20 7946 0999, +44 20 7946 07xx)              |
                   (Variant 1)                               |
                        |                                    |
                        v                                    |
                  +----------+                               |
                  | Assignee |<------------------------------+
                  +----------+

                     Figure 2: E.164 Number Assignment

   (Note: Numbers above are "drama" numbers and are shown for
   illustrative purpose only.  Assignment polices for similar "real"
   numbers in country code +44 may differ.)

   As the Assignee (subscriber) data associated with an E.164 number is
   the primary source of number assignment information, the NAE usually
   holds the authoritative information required to confirm the
   assignment.

   A CSP that acts as NAE (indirect assignment) may therefore easily
   assert the E.164 number assignment for its subscribers.  In some
   cases, such CSPs operate database(s) containing service information
   on their subscribers' numbers.  Typically, authorized entities such

Mayrhofer & Hoeneisen        Informational                      [Page 6]
RFC 4725              ENUM Validation Architecture         November 2006

   as other CSPs are allowed to access these databases, in real-time,
   under contract for the limited purposes of billing and validation (no
   marketing, data mining, or otherwise).  These databases could be re-
   used for ENUM validation purposes.

   Number portability transactions may lead to situations where the CSP
   that originally acted as NAE no longer has authoritative assignment
   information about ported numbers.  Whether the old and/or the new CSP
   act(s) as NAE for ported numbers depends on local policy.

   However, it is unlikely that all CSPs acting as NAEs will participate
   in ENUM validation.

3.2.  Assignee

   The person or organization to whom a NAE assigns an E.164 number is
   called Assignee of this number.  For the scope of this document, the
   terms Assignee, subscriber, and number-holder are used equivalently.

   The Assignee has the "right to use" on the assigned E.164 number.

3.3.  Registrant

   The ENUM Registrant is the end-user, the person or organization who
   is the "holder" of the ENUM domain name.

   The Registrant usually has control over his ENUM domain name(s) and
   its DNS zone content.

3.4.  Validation Entity (VE)

   The Validation Entity (VE) verifies whether or not the Registrant of
   an ENUM domain name is identical to the Assignee of the corresponding
   E.164 number.

   Often it also verifies that the entity requesting the registration of
   an ENUM domain name is either the Assignee of the corresponding E.164
   number itself or an entity authorized to request registration on
   behalf of said Assignee.

   This role may be performed by several parties and is not necessarily
   limited to a single entity.

   The actual validation methods applied may vary depending on, e.g.,
   the particular party, available data sources, Assignee's choice, and
   regulatory requirements.  Validation methods are out of scope of this
   document.

Mayrhofer & Hoeneisen        Informational                      [Page 7]
RFC 4725              ENUM Validation Architecture         November 2006

3.5.  Registry

   The ENUM Registry operates the master database of ENUM domain
   delegations and runs the authoritative nameservers for the relevant
   zone under e164.arpa.  There must always be a single authoritative
   ENUM Registry for a specific zone.

3.6.  Registrar

   An ENUM Registrar performs ENUM domain delegations on behalf of a
   Registrant by interacting with the Registry, typically through a
   protocol like Extensible Provisioning Protocol (EPP) [5].  This role
   is similar to the one that Registrars fulfill in the "ordinary"
   domain name registration world.

   The Registrar may well not be the same entity as the CSP of the
   Registrant.  Therefore, a Registrar may lack authoritative number-
   assignment information.  If the Registrar and the CSP are the same
   entity (or has a source of authoritative data), the Registrar could
   perform the role of the VE itself.

   In any case, a Registrar has to ensure a proper validation through a
   VE prior to the registration of an ENUM domain name.

3.7.  Domain Name System Service Provider (DNS-SP)

   The Domain Name System Service Provider (DNS-SP) operates the
   nameservers for the ENUM DNS zones, which contain the ENUM Naming
   Authority Pointer (NAPTR) Resource Record (RR) entries [1].

   In most cases, the Registry delegates the ENUM DNS zones to the
   nameservers at the DNS-SP.

   The DNS-SP is usually not involved in the validation process.

3.8.  Application Service Provider (ASP)

   The Application Service Provider (ASP) operates a service for the
   Registrant.  This service could be an IP telephony service, whereby
   the service provider populates the ENUM zone for its customers so
   that others can discover that customer's URI.

   Usually, the ASP is not involved in the validation process.

Mayrhofer & Hoeneisen        Informational                      [Page 8]
RFC 4725              ENUM Validation Architecture         November 2006

4.  Validation Process Assumptions

4.1.  Workflow

   The prototypical initial validation workflow using the above roles
   and definitions consists of the following steps:

   1.  A potential Registrant approaches a Registrar, and orders an ENUM
       domain name.

   2.  The Registrar chooses a cooperating Validation Entity, and
       requests an initial validation for the ENUM domain name ordered.

   3.  The Validation Entity performs the actual validation, which could
       require interaction with the Assignee/Registrant.

   4.  The Validation Entity indicates the result of the initial
       validation to the Registrar.

   5.  If the validation process was successful, the Registrar
       provisions the ENUM domain name with the Registry.  Depending on
       the local Registry policy, validation-related information may be
       provided to the Registry along with this registration.

   In most cases, local policy mandates expiration dates to be imposed
   on successful validations.  If the ENUM delegation is to be kept
   beyond this expiration date, recurring validation has to be
   performed.  A typical revalidation workflow involves the following
   steps:

   1.  In good time before the current validation expires, the Registrar
       requests the Validation Entity to revalidate the domain name in
       question.

   2.  The Validation Entity verifies if the delegation requirements are
       still met.  It may use information acquired during the initial
       validation or associated to the registration data.

   3.  The Validation Entity indicates the result of the recurring
       validation to the Registrar.

   4.  In case the revalidation has been successful, the domain
       delegation may persist.  Local Registry policy may require
       updating domain name registration data, especially in case the
       Registry keeps validation-related expiry information.

Mayrhofer & Hoeneisen        Informational                      [Page 9]
RFC 4725              ENUM Validation Architecture         November 2006

   5.  In case the revalidation has failed, the ENUM domain delegation
       must be suspended, either by explicit interaction with the
       Registry or -- if the Registry keeps validation-related
       information -- automatically when the current validation expires.
       Local policy may grant a grace period on the expiration date.

   This workflow ensures the integrity between the E.164 and ENUM
   namespaces.  ENUM domain delegations that fail to meet the validation
   requirements are suspended from the DNS.

4.2.  Trust Relations

   The above validation workflow implies the following trust relations:

   o  The Registry trusts the Validation Entities to enforce the local
      validation policy.

   o  The Registrars trust the Validation Entities to properly perform
      validation based on the Registrar's request.

   o  Depending on the amount of validation data provided to the
      Registry additional trust relations may be necessary.  Three cases
      can be differentiated:

      *  The Registry receives no validation-related data: The Registry
         needs to trust the Registrar that validation has been
         performed, and the result was positive.  In addition, the
         Registry needs to trust the Registrar that it will properly
         remove delegations for which revalidation fails.

      *  The Registry receives validation-related data including expiry
         date, but there are no means of checking its authenticity: The
         Registry needs to trust the Registrar that the validation data
         provided is authentic.

      *  The Registry receives validation-related data including expiry
         date and means to verify its authenticity (e.g., a
         cryptographic signature issued by the VE): No additional trust
         relations are necessary.

Mayrhofer & Hoeneisen        Informational                     [Page 10]
RFC 4725              ENUM Validation Architecture         November 2006

4.3.  Data Flow and Format

   The validation process requires the following regular data flows
   (Note: data flows not directly related to validation are out of scope
   of this document):

   o  Registrars communicate with Validation Entities to initiate,
      modify, or cancel validation requests.  Validation Entities act
      upon validation requests and provide validation results to
      Registrars.  Since Registrars could potentially communicate with
      several Validation Entities, and Validation Entities could provide
      services to several Registrars (worst case: full mesh), a
      standardized protocol and data format should be used in this data
      flow.

   o  If the local Registry policy mandates that validation-related
      information is to be stored along with delegation records, a
      validation-related data flow between Registry and Registrar is
      required.  Since the registration itself already requires
      communication between those entities, validation-related
      information in a standardized data format should be embedded into
      the existing Registry-Registrar protocol data flow.

   o  Validation Entities may need to communicate with Assignees to
      perform validation.  A Validation Entity may choose to perform all
      communication with the Assignee via the requesting Registrar
      rather than contacting the Assignee by itself.  Since the actual
      communication form and process are expected to greatly vary, it
      does not make sense to specify any data formats or processes for
      this purpose.

5.  Example Scenarios

5.1.  E.164 Number Assignment along with ENUM Registration

   In this simple scenario, we assume that the roles of the Registrar,
   the VE, and the NAE are performed by the same entity, e.g., an
   Internet Telephony Service Provider (ITSP).  This ITSP is a CSP that
   was assigned number ranges by the NNPA.  Out of these ranges he
   assigns numbers to his customers (Assignees) to provide those with
   communication services.  The ITSP chooses to assign an E.164 number
   together with the corresponding ENUM domain name.  Therefore, it can
   perform the validation simply by reference to its subscriber
   database.

Mayrhofer & Hoeneisen        Informational                     [Page 11]
RFC 4725              ENUM Validation Architecture         November 2006

   Figure 3 shows the external interactions needed for the ENUM domain
   name provisioning process:

                   +----------+
                   | Registry |
                   +----------+
                        ^
                        |
                        |(3)
                        |
                +--------------------------------------+
                |                                      |
                |                    ITSP              |
                |  +-----------+              +----+   |
                |  | Registrar |              | VE |   |
                |  +-----------+      (2)     +----+   |
                |                                      |
                +--------------------------+           |
                        ^                  |           |
                        |                  |           |
                        |(1)               |           |
                        |                  |           |
                        |                  |           |
                  +------------+   (4)     |  +-----+  |
                  | Assignee = |<----------|  | NAE |  |
                  | Registrant |           |  +-----+  |
                  -------------            |           |
                                           +-----------+

                     Legend:

                     ITSP: Internet Telephony Service Provider
                     NAE:  Number Assignment Entity
                     VE:   Validation Entity

      Figure 3: E.164 Number Assignment along with ENUM Registration

   (1)  The ITSP receives an order for ENUM services.
   (2)  The ITSP assigns a free E.164 number and performs the validation
        at the same time.
   (3)  The ITSP sends an ENUM registration request to the Registry,
        which might contain additional information about the validation
        applied.
   (4)  The ITSP sends a confirmation about the E.164 number assignment
        and the ENUM registration to its customer, who is now Assignee
        and Registrant.

   This scenario is quite close to "ordinary" domain name registrations.

Mayrhofer & Hoeneisen        Informational                     [Page 12]
RFC 4725              ENUM Validation Architecture         November 2006

5.2.  Fully Disjoint Roles

   In this more complex scenario, we assume that all roles of the ENUM
   provisioning model are performed by different entities.  In contrast
   with the previous example (in Section 5.1), we assume that the ENUM
   domain name to be registered is based on an already assigned E.164
   number and the NAE in question provides the VE with access to the
   subscriber database.  We further assume that there is a requirement
   for the VE to verify the intention of the Assignee.  The validation
   process therefore involves also contacting the Assignee.

   Figure 4 shows the interactions needed for the ENUM domain name
   provisioning process:

                    +----------+
                    | Registry |
                    +----------+
                         ^
                         |
                         |(9)
                         |
                         |
                         |             (3)
                    +-----------+ ---------->+----+
                    | Registrar |<---------- | VE |
                    +-----------+   (8)    > +----+
                         ^                / /  ^  |
                         |               / /   |  |
                         |           (7)/ /    |  |
                         |(2)          / /     |  |
                         |            / /   (5)|  |
                         |           / /       |  |
                         |          / /        |  |
                         |         / /(6)      |  |
                         |        / /          |  |(4)
                         |       / /           |  |
                         |      / /            |  |
                   +------------+<             |  v
                   | Assignee = |            +-----+
                   | Registrant |<---------- | NAE |
                   +------------+    (1)     +-----+

                     Legend:

                     NAE:  Number Assignment Entity
                     VE:   Validation Entity

                      Figure 4: Fully Disjoint Roles

Mayrhofer & Hoeneisen        Informational                     [Page 13]
RFC 4725              ENUM Validation Architecture         November 2006

   (1)  The NAE assigns an E.164 number.  This assignment could have
        been done long before the ENUM domain name registration, e.g.,
        at the time when the Assignee subscribed to a common telephony
        service.
   (2)  The Assignee orders the corresponding ENUM domain name at a
        Registrar of his choice.
   (3)  The Registrar requests validation at an independent VE.
   (4)  The VE contacts the subscriber database of the NAE, to verify
        that the Assignee of the E.164 number corresponds to the
        Registrant of the ENUM domain name.
   (5)  The result of the NAE subscriber database is positive.
   (6)  The VE performs a call-back to the E.164 number to be registered
        as ENUM domain name, makes provisions for authentication, and
        asks the Assignee to confirm his intention.
   (7)  The Assignee confirms and the VE documents this confirmation.
   (8)  The VE returns a positive answer to the Registrar.  The answer
        might contain some additional information about the validation
        process, such as expiration date, validation method applied, and
        so on.
   (9)  Finally, the Registrar sends an ENUM registration request to the
        Registry.  Additional information about the validation process
        might be sent along with the registration request.

6.  Security Considerations

6.1.  Fraud Prevention

   Situations where an entity has control over the ENUM domain of a
   third party's E.164 number impose high fraud potential.  Unauthorized
   control over an ENUM domain of a bank could, for example, be used for
   "man in the middle" attacks on telephone banking applications.  Cases
   of such attacks could discredit ENUM as a whole.

   Implementing high-quality validation processes is therefore crucial
   to any ENUM deployment and should receive high attention.

6.2.  Assignee Data

   When handling Assignee data, privacy and discretion issues must be
   considered.  Implementations transporting assignee data over the
   Internet must use authenticated and encrypted transport protocols.
   Local registration/validation policy and agreements should clearly
   limit usage of Assignee data.

Mayrhofer & Hoeneisen        Informational                     [Page 14]
RFC 4725              ENUM Validation Architecture         November 2006

7.  Acknowledgements

   The authors would like to thank the following persons for their
   valuable suggestions and contributions: Lawrence Conroy, Michael
   Haberler, Ted Hardie, Otmar Lendl, Hala Mowafy, Marcel Parodi, Jon
   Peterson, Penn Pfautz, Patrik Schaefer, and Richard Stastny.

8.  References

8.1.  Normative References

   [1]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
        Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
        Application (ENUM)<stream> stanzas
   is incompatible with XMPP services that do not support this protocol,
   because it was previously assumed that when receiving a connection
   the stream to attibute will contains an XMPP domain hosted by the
   receiving service.  It is RECOMMENDED that if the connection fails,
   the service tries again using the Remote Domain as stream to-
   attribute.

Barnes & Lindberg      Expires September 15, 2011              [Page 15]
Internet-Draft                     DNA                        March 2011

   Presenting a certificate for the Server Domain Name is incompatible
   with XMPP services that do not support this protocol, because those
   will expect the Remote Domain in the certificate.  It is RECOMMENDED
   that if the authorization fails, the service tries again presenting
   the certificate for the Remote Domain.  A service may also choose to
   fall back on a weaker identification mechanism such as Server
   Dialback, subject to local policy.

8.  Operational Considerations

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

   [[ Do TLS clients support multiple names 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 same domain as hosting
   services. ]]

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

9.  IANA Considerations

   [[ Register XML schema for assertions, if necessary ]]

   [[ Define invalid-connection error element ]]

10.  Security Considerations

   [[ This document simplifies authentication and authorization of XMPP
   servers in 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 prompting the original
   work on this problem, and to Stephen Farrell for his work on initial

Barnes & Lindberg      Expires September 15, 2011              [Page 16]
Internet-Draft                     DNA                        March 2011

   versions of this draft.

12.  Normative References

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

   [I-D.saintandre-tls-server-id-check]
              Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet 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), January 2011.

   [RFC2119]  Bradner, S., "Key words for use in 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 Requirements",
              RFC 4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 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.

Barnes & Lindberg      Expires September 15, 2011              [Page 17]
Internet-Draft                     DNA                        March 2011

Authors' Addresses

   Richard L. Barnes
   BBN Technologies

   Email: rbarnes@bbn.com

   Jonas Lindberg
   Google

   Email: jonasl@google.com

Barnes & Lindberg      Expires September 15, 2011              [Page 18]