Network Working Group                                          R. Barnes                                     P. Saint-Andre
Internet-Draft                                          BBN Technologies                                                 M. Miller
Intended status: Standards Track                             J. Lindberg                     Cisco Systems, Inc.
Expires: September October 17, 2013                                 April 15, 2011                                       Google
                                                          March 14, 2011 2013

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

Abstract

   The current authentication process Associations (DNA) in XMPP requires the XMPP server
   for a domain to present a certificate that contains that domain's
   name. Extensible Messaging and Presence
                            Protocol (XMPP)
                         draft-ietf-xmpp-dna-02

Abstract

   This requirement causes several problems document improves the security of the Extensible Messaging and
   Presence Protocol (XMPP) in scenarios where
   XMPP services have been delegated from one domain to another,
   especially when one two ways.  First, it specifies how
   "prooftypes" can establish a strong association between a domain provides XMPP services for many domains.
   This document describes name
   and an extension to the XMPP authentication
   process that allows domains XML stream.  Second, it describes how 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 delegate a
   source domain to be interpreted as described a derived domain, which is especially important in RFC 2119 [RFC2119].
   virtual hosting environments.

Status of this This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   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."

   This Internet-Draft will expire on September 15, 2011. October 17, 2013.

Copyright Notice

   Copyright (c) 2011 2013 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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Overview  Flow Chart  . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Connection Model . .   3
   4.  A Simple Scenario . . . . . . . . . . . . . . . . . . . . . .  8   5
   5.  Channel Establishment and  One-Way Authentication  . . . . . . . . . . .  9 . . . . . . . .   6
   6.  Authorizing XMPP Stanzas  Piggybacking  . . . . . . . . . . . . . . . . . . . 13 . . . . .   7
     6.1.  Assertion . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  Supposition . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Backward Compatibility  Alternative Prooftypes  . . . . . . . . . . . . . . . . . . .  10
     7.1.  DANE  . . . . . . . . . 15
   8.  Operational Considerations . . . . . . . . . . . . . . . . .  10
     7.2.  POSH  . 16 . . . . . . . . . . . . . . . . . . . . . . . . .  10
   8.  Secure Delegation and Multi-Tenancy . . . . . . . . . . . . .  11
   9.  IANA Considerations  Prooftype Model . . . . . . . . . . . . . . . . . . . . . . 16 .  12
   10. Security Considerations . . . . . . . . . . . . . . . . . . . 16  12
   11. Acknowledgements . . IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16  12
   12. Normative References  . . . . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . .  12
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     12.2.  Informative References . . 17

1.  Introduction

   When connecting two XMPP services to provide inter-domain
   communication, it is important for a service . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The need to be able establish a strong association between a domain name and
   an XML stream arises in both client-to-server and server-to-server
   communication using the Extensible Messaging and Presence Protocol
   (XMPP), because XMPP servers are typically identified by DNS domain
   names.  However, a client or peer server needs to determine verify the identity
   of a peer service to prevent traffic spoofing.  The
   Jabber communities first approach server to identity which it connects.  To date, such verification was the
   Server Dialback protocol.  When has
   been established based on information obtained from the Jabber protocols were formalized
   by Domain Name
   System (DNS), the XMPP working group of Public Key Infrastructure (PKI), or similar
   sources.  This document (1) generalizes the IETF 2002-04, support for strong
   identity verification using TLS + SASL was added.

   Server Dialback [XEP-0220] model currently in use so
   that additional prooftypes can be defined, (2) provides weak identity verification and
   makes it more difficult to spoof hostnames of servers XMPP network.
   However, it does not provide authentication between servers and is
   not a security mechanism.  It is susceptible basis for
   modernizing some prooftypes to reflect progress in underlying
   technologies such as DNS poisoning attacks
   (unless DNSSEC is used) Security [RFC4033], and cannot protect against attackers capable
   of hijacking (3) describes the IP address
   flow of operations for establishing a remote service.

   TLS + SASL provides strong identity verification but requires a
   obtaining a digital certificate by a trusted CA (or domain name association.

   Furthermore, the XMPP
   Intermediate Certification Authority) and using it in process for resolving the domain name of an XMPP
   service,
   service into the IP address at which may an XML stream will be hosted by negotiated
   (defined in [RFC6120]) can involve delegation of a 3rd party.  This solution does not
   allow for multiplexing traffic for multiple source domain pairs over
   (say, example.com) to a
   connection, possibly requiring derived domain (say, hosting.example.net).
   If such delegation is not done in a large number of connections between
   two hosting providers.

   Server Dialback can secure manner, then the domain
   name association cannot be used with TLS.  When STARTTLS negotiation
   succeeds with a peer service but the 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 originating server that wish to use TLS for encryption, but
   only can present a self signed certificate.

   In practice, many XMPP server deployments rely on Server Dialback and
   either do not support XMPP 1.0 or do not offer negotiation of TLS +
   SASL.

   This goal of authenticated.  Therefore, this document is to describe secure authentication using
   a hosting provide TLS certificate from a trusted CA, combined with a
   dialback mechanism providing
   provides guidelines for defining secure delegation based on DNS record
   delgation verified using DNSSEC. methods.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this

   This document are to be interpreted as described in RFC
   2119 [RFC2119].

   We will refer to four different types of domains in this document:

   o  Sender domain: The domain that initially sends out an XMPP message

   o  Target domain: The ultimate destination of an inherits XMPP message

   o  Originating domain: The originating domain of a particular server-
      to-server connection

   o  Receiving domain: terminology from [RFC6120] and
   [XEP-0220], DNS terminology from [RFC1034], [RFC1035], [RFC2782] and
   [RFC4033], and security terminology from [RFC4949] and [RFC5280].
   The receiving domain of a particular server-to-
      server connection

   In outsourcing scenarios, the sending terms "source domain", "derived domain", "reference identity",
   and receiving domains "presented identity" are
   outsourced to the originating and receiving domains, respectively.

3.  Protocol Overview

   Consider a scenario used as defined in which the domain sender.tld has outsourced
   XMPP services to originating.tld, and target.tld has outsourced to
   receiving.tld. "CertID"
   specification [RFC6125].  The particular hosts providing services are
   xmpp1.originating.tld terms "permissive federation",
   "verified federation", and xmpp1.receiving.tld.  Users
   romeo@sender.tld and juliet@target.tld maintain client-to-server
   connections 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 server-to-server connection to Provider B's
   server.  Since they "encrypted federation" are both acting on behalf of other domains,
   however, each side will have to verify that derived from
   [XEP-0238], although we substitute the other is authorized
   to act in term "authenticated
   federation" for the term "trusted federation" from that role. document.

3.  Flow Chart

   The first step is to provision records that can be used to verify
   these delegations.  In order for XMPP to work, when following flow chart illustrates the hosting
   relationships are set up, sender.tld protocol flow for
   establishing domain name associations between Server A and target.tld have to provision
   SRV records pointing to their providers' servers.  To make this
   delegation secure, they sign these records using DNSSEC [RFC4033].
   On the XMPP servers themselves, Server B,
   as described in the originating and receiving domains
   provision certificates that can be used to authenticate the names
   xmpp1.originating.tld and xmpp1.receiving.tld.

   When Romeo wants to send a stanza to Juliet, he will first send it to
   his server, xmpp1.originating.tld.  Seeing that the 'to' domain of
   the 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 to do; the server simply connects
   to the remote domain using normal XMPP procedures.  If there is a
   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 TLS connection is established, 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 created, it can immediately carry stanzas
   directly between the two servers.  In order to send messages to and
   from other domains, the 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 originating server uses STARTTLS to set up a TLS connection.  In
   the ClientHello message initiating the connection, the
   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 originating server.  The originating server presents a
   certificate for its own name, xmpp1.originating.tld.

   At this point, the server xmpp1.originating.tld knows that
   xmpp1.receiving.tld is authorized to represent either
   xmpp1.receiving.tld (via the certificate) or target.tld (via DNSSEC).
   The other server, xmpp1.receiving.tld knows only that the other
   server repressents xmpp1.originating.tld.

   Once the 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 authorized to represent sender.tld, it has
   to check, using an abbreviated form of dialback.  Just as the
   Provider A server did earlier for target.tld, the Provider B server
   looks up the SRV records for _xmpp-server._tcp.sender.tld and any
   associated DNSSEC records.  If there are no DNSSEC records or the
   signature is not valid, then the server rejects the request to send
   stanzas from that domain.  If the record is DNSSEC-signed, then the
   server checks that the server name in the SRV record is one remaining sections of the
   names authenticated for the remote side.
   R: <db:result type='invalid' from='sender.tld' to='target.tld' />

   On the other hand, if the DNSSEC signature is valid, then the server
   can accept the 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 for other stanzas and other domains.  If either server
   finds another domain that is delegated to the other server, it can
   send a <db:result> requesting permission to send stanzas for that
   domain, and the other server will grant or deny permission after
   checking the delegation.

   The following figure summarizes the overal process:
   Originating                   DNS                     Receiving
     Server                    Server                     Server
   -----------               ---------                   --------
       |                          |                          | document.

                       |  Lookup _xmpp-server
                       |
           (Section 4: A Simple Scenario)
                       |
                       |
                DNS SRV record for      |                          |
       |  target.tld to find      |                          |
       |  delegation of service   |                          |
       |  to Receiving Server.    |                          |
       |  Verify zone signature   |                          |
       | -----------------------> |                          |
       |                          |                          |
       |  'Receiving Server'      |                          |
       | <----------------------- |                          |
       |                          |                          |
       | RESOLUTION ETC.
                       |
   +-------------STREAM HEADERS--------------------+
   |                                               |
   |  A: <stream from='originating.tld' to='receiving.tld'> |
       | --------------------------------------------------> from='a.example' to='b.example'>  |
   |                                               |
   |  B: <stream from='receiving.tld' to='originating.tld'> |
       | <-------------------------------------------------- |
       |                                                     | from='b.example' to='a.example'>  |  <features><starttls></features>
   |                                               | <--------------------------------------------------
   +-----------------------------------------------+
                       |
   +-------------TLS NEGOTIATION-------------------+
   |                                               |
   |  <starttls/>                                        |
       | --------------------------------------------------> |
       |                                                     |
       |  <proceed/>                                         |   B: Server Certificate                       | <--------------------------------------------------
   |  [B: Certificate Request]                     |
   |  [A: Client Certificate]                      |
   |                                               | <====================== TLS ======================>
   +-----------------------------------------------+
                       |
       (A establishes DNA for b.example!)
                       |
   +-------------AUTHENTICATION--------------------+
   |                   |                           |
   |  <stream from='originating.tld' to='receiving.tld'>          {client certificate?} ----+          |
   | -------------------------------------------------->                   |                |          |
   |  <stream from='receiving.tld' to='originating.tld'>                   | yes         no | <--------------------------------------------------          |
   |                   v                |          |  <features><bidi></features>
   |             SASL EXTERNAL          | <--------------------------------------------------          |
   |             (mutual auth!)         |          |  <db:result from='sender.tld' to='target.tld'/>
   +------------------------------------|----------+
                                        |
                       +----------------+
                       | --------------------------------------------------> B needs to auth A
                       |
           (Section 5: One-Way Authentication)
                       |
                       |
                DNS RESOLUTION ETC.
                       | ...
   +-------------STREAM HEADERS--------------------+
   |

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  B: <stream from='b.example' to='a.example'>  | Delegated Domain Names
   |
   +------------+---------------------+------------------------+                                               | XXX
   | xmpp1.provider.com  A: <stream from='a.example' to='b.example'>  | capulet.example
   |                                               | YYY
   +-----------------------------------------------+
                       | xmpp2.provider.com
   +-------------TLS NEGOTIATION-------------------+
   | capulet.example                                               |
   | AAA   A: Server Certificate                       | 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
   +-----------------------------------------------+
                       |
       (B establishes DNA for the single XMPP stream that it carries.

   +------------------+-----------------+---------------+ a.example!)
                       | Local
                       | Remote
         (Section 6.1: Piggybacking Assertion)
                       | Connections
                       |
   +------------------+-----------------+---------------+
   +----------DIALBACK IDENTITY ASSERTION----------+
   | montague.example                                               | capulet.example
   | XXX, YYY  B: <db:result from='c.example'               |
   | laurence.example                to='a.example'/>               | capulet.example
   | AAA                                               |
   +-----------------------------------------------+
                       | laurence.example
   +-----------DNA DANCE AS ABOVE------------------+
   | paris.example                                               | YYY, AAA
   |
   +------------------+-----------------+---------------+
   The binding table acts as a routing table for outgoing stanzas and a
   filter for incoming stanzas.  When    DNS RESOLUTION, STREAM HEADERS,            |
   |    TLS NEGOTIATION, AUTHENTICATION            |
   |                                               |
   +-----------------------------------------------+
                       |
   +----------DIALBACK IDENTITY VERIFICATION-------+
   |                                               |
   |  A: <db:result from='a.example'               |
   |                to='c.example'                 |
   |                type='valid'/>                 |
   |                                               |
   +-----------------------------------------------+
                       |
                       |
         (Section 6.2: Piggybacking Supposition)
                       |
                       |
   +-----------SUBSEQUENT CONNECTION---------------+
   |                                               |
   |  B: <stream from='c.example'                  |
   |             to='chatrooms.a.example'>         |
   |                                               |
   |  A: <stream from='chatrooms.a.example'        |
   |             to='c.example'>                   |
   |                                               |
   +-----------------------------------------------+
                       |
   +-----------DNA DANCE AS ABOVE------------------+
   |                                               |
   |    DNS RESOLUTION, STREAM HEADERS,            |
   |    TLS NEGOTIATION, AUTHENTICATION            |
   |                                               |
   +-----------------------------------------------+
                       |
   +-----------DIALBACK OPTIMIZATION---------------+
   |                                               |
   |  B: <db:result from='c.example'               |
   |                to='chatrooms.a.example'/>     |
   |                                               |
   |  B: <db:result from='chatrooms.a.example'     |
   |                to='c.example'                 |
   |                type='valid'/>                 |
   |                                               |
   +-----------------------------------------------+

4.  A Simple Scenario

   To illustrate the server wishes to send a
   stanza, it looks in problem, consider the binding table simplified order of events
   (see [RFC6120] for a row that has the 'from'
   domain as the local domain details) in establishing an XML stream between
   Server A (a.example) and Server B (b.example):

   1.  Server A resolves the 'to' DNS domain as the remote domain.
   If there is such name b.example.

   2.  Server A opens a in the binding table, then the server MUST
   transmit the on the first connection in the TCP connection list.  Thus,
   in to the above example, resolved IP address.

   3.  Server A sends an initial stream header to Server B, asserting
       that it is a.example:

       <stream:stream from='a.example' to='b.example'>

   4.  Server B sends a stanza from montague.example response stream header to
   capulet.example would be routed on channel XXX.

   In the same way, when Server A, asserting
       that it is b.example:

       <stream:stream from='b.example' to='a.example'>

   5.  The servers attempt TLS negotiation, during which Server B
       (acting as a server receives TLS server) presents a stanza over PKIX certificate proving that
       it is b.example and Server A (acting as a connection
   from TLS client) presents a remote server,
       PKIX certificate proving that it looks up is a.example.

   6.  Server A checks the PKIX certificate that Server B provided and
       Server B checks the relevant entry in PKIX certificate that Server A provided; if
       these proofs are consistent with the binding
   table, this time using XMPP profile of the 'to' matching
       rules from [RFC6125], each server accepts that there is a strong
       domain as name association between its stream to the local domain other party and
       the
   'from' DNS domain as name of the remote domain.  If other party.

   Several simplifying assumptions underlie the server finds happy scenario just
   outlined:

   o  Server A presents a binding
   table entry and the connection over PKIX certificate during TLS negotiation, which
      enables the stanza arrived is
   listed in the entry, then it accepts the stanza.  Otherwise, it MUST
   discard the stanza parties to complete mutual authentication.

   o  There are no additional domains associated with Server A and return a stanza error <invalid-connection/>.
   In the above example,
      Server B (say, a stanza from capulet.example to
   escalus.example would be accepted subdomain chatrooms.a.example on connections AAA and BBB, but no
   others.

   When Server A or a connection is opened (and at some points thereafter), entries
      second domain c.example on Server B).

   o  The server administrators are able to obtain PKIX certificates in
      the name table first place.

   o  The server administrators are established running their own XMPP servers,
      rather than using the processes hosting services.

   Let's consider each of these "wrinkles" in Section
   Section turn.

5.  Once a connection  One-Way Authentication

   If Server A does not present its PKIX certificate during TLS
   negotiation (perhaps because it wishes to verify the identity of
   Server B before presenting its own credentials), Server B is open, binding table entries are
   added or removed using unable
   to mutually authenticate Server A.  Therefore, Server B needs to
   negotiate and authenticate a stream to Server A, just as Server A has
   done:

   1.  Server B resolves the processes in Section Section 6.  When DNS domain name a.example.

   2.  Server B opens a TCP connection is closed, both servers MUST delete its entry in to the name
   table and remove resolved IP address.

   3.  Server B sends an initial stream header to Server A, asserting
       that it from all entries in the binding table.

5.  Channel Establishment and Authentication

   When is b.example:

       <stream:stream from='b.example' to='a.example'>

   4.  Server A sends a server wants response stream header to send Server B, asserting
       that it is a.example:

       <stream:stream from='a.example' to='b.example'>

   5.  The servers attempt TLS negotiation, during which Server A
       (acting as a stanza and doesn't have an entry in the
   connection table for TLS server) presents a PKIX certificate proving that
       it is a.example.

   6.  Server B checks the destination domain, PKIX certificate that Server A provided; if
       it sets one up.  The
   first step is to establish consistent with the XMPP profile of the matching rules from
       [RFC6125], Server B accepts that there is a connection strong domain name
       association between its stream to a server for the
   destination domain, Server A and validate that the server DNS domain
       name a.example.

   Unfortunately, now the servers are using two TCP connections instead
   of one, which is authorized somewhat wasteful.  However, there are ways to
   represent tie
   the destination domain.

   The originating server MUST take authentication achieved on the following steps to establish a
   secure second TCP connection to the server for example.com:

   1.  Retrieve SRV records for XMPP services first
   TCP connection; see [XEP-0288] for example.com
       [I-D.ietf-xmpp-3920bis].

   2.  Verify that further discussion.

6.  Piggybacking

6.1.  Assertion

   Consider the SRV records have been signed using DNSSEC
       [RFC4033].  The originating server may either retrieve DNSSEC
       records directly or rely on common scenario in which Server B hosts not only
   b.example but also a validating resolver. second domain c.example.  If the SRV
       records are not secured a user of Server B
   associated with c.example wishes to communicate with DNSSEC, then the connection fails.

   3.  If there is already a connection in friend at
   a.example, Server B needs to send XMPP stanzas from the domain
   c.example rather than b.example.  Although Server B could open an new
   TCP connection table that has and negotiate new XML streams for the target domain pair of any SRV record in its "server names" list, then
       this process terminates
   c.example and the server attempts to use a.example, that
       connection (See Section Section 6)

   4.  If there too is no existing wasteful.  Server B already has
   a connection to a.example, so how can it assert that matches, establish it would like to
   add a TCP
       connection new domain pair 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: existing connection?

   The receiving server's name from the SRV record

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

   5.  Upgrade doing so is the connection Server Dialback protocol,
   first specified in [RFC3920] and since moved to TLS using STARTTLS, using [XEP-0220].  Here,
   Server B can send a cipher
       suite that requires <db:result/> element for the server to present an X.509 certificate.

   6.  Verify new domain pair over
   the existing stream.

    <db:result from='c.example' to='a.example'>
      some-dialback-key
    </db:result>

   This element functions as Server B's assertion that the certificate it is valid (also)
   c.example, and chains to a local trust
       anchor.  If the certificate thus is invalid, functionally equivalent to the connection fails.

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

   8.  Verify an initial stream header as previously described.

   In response to this assertion, Server A needs to obtain some kind of
   proof that the target name in the SRV record Server B really is one of the names
       in also c.example.  It can do the certificate.  If same
   thing that it did before:

   1.  Server A resolves the target DNS domain name is not found in the list
       of names from the certificate, then the connection fails. c.example.

   2.  Server A server receiving such opens a connection MUST perform the following
   steps:

   1.  Accept the TCP connection from to the remote side and accept resolved IP address (which
       might be the same IP address as for b.example).

   3.  Server A sends an initial stream negotiation using server names.

   2.  In the header to Server B, asserting
       that it is a.example:

       <stream:stream from='a.example' to='c.example'>

   4.  Server B sends a response stream header to Server A, asserting
       that it is c.example:

       <stream:stream from='c.example' to='a.example'>

   5.  The servers attempt TLS negotiation, require during which Server B
       (acting as a client TLS server) presents a PKIX certificate from the
       remote side.

   3.  Verify proving that
       it is c.example.

   6.  Server A checks the remote server name in the stream matches the
       client certificate [I-D.saintandre-tls-server-id-check].  If the PKIX certificate does not match, the TLS negotiation fails, and the
       server MAY terminate that Server B provided; if
       it is consistent with the TCP connection.

   If this process establishes a new connection, then XMPP profile of the originating
   server knows matching rules from
       [RFC6125], Server A accepts that it has established there is a connection strong domain name
       association between its stream to a server that
   legitimately represents example.com.  It should thus initialize a row
   in the connection table for this connection:

   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 B and the connection table entry to add example.com to DNS domain
       name c.example.

   Now that Server A accepts the list domain name association, it informs
   Server B of
   delegated names.  In either case, that fact:

    <db:result from='a.example' to='c.example' type='valid'/>

   The parties can then terminate the row second connection, since it was
   used only for Server A to associate a connection is removed
   from the connection table when stream over the connection is closed.

   In order for this process to work, same IP:port
   combination with the domain owner and name c.example (dialback key links the hosting
   provider need to publish information that other XMPP entities can use
   original stream to verify the delegation.  XMPP services are delegated via SRV
   records (see Section 3.2.1 of [I-D.ietf-xmpp-3920bis]), so new association).

6.2.  Supposition

   Piggybacking can also occur 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 direction.  Consider the zone _xmpp-server._tcp.example.com MUST be
   signed.  Each server that acts
   common scenario in which Server A provides XMPP services not only for
   a.example but also for a domain MUST be provisioned with subdomain such as a certificate that contains the target name used by SRV records.

   The server groupchat service at
   chatrooms.a.example (see [XEP-0045]).  If a user from c.example at
   Server B wishes to join a room on the receiving end of the TLS connection MUST request a
   client certificate groupchat sevice, Server B
   needs to send XMPP stanzas from the originating server during domain c.example to the TLS
   handshake, domain
   chatrooms.a.example rather than a.example.  Therefore, Server B needs
   to negotiate and authenticate a stream to chatrooms.a.example:

   1.  Server B resolves the originating server MUST provide DNS domain name chatrooms.a.example.

   2.  Server B opens a client
   certificate.  The receiving server can then also initialize an entry
   in its TCP connection table to which delegated names can be added later:

   o the resolved IP address.

   3.  Server B sends an initial stream header to Server A acting as
       chatrooms.a.example, asserting that it is b.example:

       <stream:stream from='b.example' to='chatrooms.a.example'>

   4.  Server A sends a response stream header to Server names: B, asserting
       that it is chatrooms.a.example:

       <stream:stream from='chatrooms.a.example' to='b.example'>

   5.  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 attempt TLS negotiation, during which Server A
       (acting as a TLS connection, they MUST set
   up an XMPP stream that will be used for domains server) presents a PKIX certificate proving that they represent.
   This process follows
       it is chatrooms.a.example.

   6.  Server B checks the normal stream initiation procedure
   [I-D.ietf-xmpp-3920bis], except PKIX certificate that Server A provided; if
       it is consistent with the 'to' and 'from' domains MUST
   be set to the names XMPP profile of the servers themselves: The originating server
   sends matching rules from
       [RFC6125], Server B accepts that there is a <stream> stanza with the 'from' strong domain set to a name for
   itself that is contained in
       association between its client certificate, stream to Server A and the 'to' DNS 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 chatrooms.a.example.

   As before, the stream ID for the negotiated stream.

   Since server-to-server parties now have two TCP connections are by default directional, it is
   RECOMMENDED open.  So that servers also request
   they can close the <bidi> stream feature now-redundant connection, Server B sends a
   dialback key to
   enable bidirectional flows on this connection [XEP-0288].

   Originating                   DNS                     Receiving Server A over the new connection.

    <db:result from='c.example' to='chatrooms.a.example'>
      some-dialback-key
    </db:result>

   Server A then informs 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 Sender Domain to a Target Domain using
   an established connection, B that it accepts the originating server MUST request
   permission to do so, and wait until domain name
   association:

    <db:result from='chatrooms.a.example' to='c.example' type='valid'/>

   Server B can now close the connection over which it has received authorization
   from tested the remote service.  A service receiving traffic MUST verify domain
   name association for chatrooms.a.example.

7.  Alternative Prooftypes

   The foregoing protocol flows assumed that the Sender and Target domain pair has been authorized on name associations
   were proved using the
   connection being used.

   An originating server MUST go through standard PKI prooftype specified in [RFC6120]:
   that is, 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 server's proof consists 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 PKIX certificate that is either 'valid' or 'invalid'.  In case
   checked according to a profile of 'invalid', the
       originating server SHOULD examine the error cause and take
       appropriate action and MAY retry requesting authorization on matching rules from [RFC6125],
   the
       same connection client's verification material is obtained out of band in the future.

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

   4.  Originating not necessary.

   However, sometimes XMPP server proceeds with sending traffic from Sender
       Domain administrators are unable or unwilling
   to Target Domain.

   Upon receiving a <db:result/> stanza, obtain valid PKIX certificates for their servers (e.g., the receiving server MUST
   administrator of im.cs.podunk.example can't receive certification
   authority verification messages sent to
   mailto:hostmaster@podunk.example, or hosting.example.net does not
   want to take
   following steps:

   1.  Verify that on the receiving direction is supported for this
       connection.  If not, fail by disconnecting liability of holding the stream.  (By
       default, connections certificate and private
   key for example.com).  In these circumstances, prooftypes other than
   PKIX are one-way)

   2.  Verify desirable.  Two alternatives have been defined so far: DANE
   and POSH.

7.1.  DANE

   In the DANE prooftype, the server's proof consists of a PKIX
   certificate that domain in to-attribute is hosted by the service.  If
       not, fail and respond with compared as an <item-not-found/> error.

   3.  Verify that domain in from-attribute delegates hosting exact match or a hash of their
       XMPP to either
   the remote Server Domain Name by looking up SRV SubjectPublicKeyInfo or the full certificate, and
       verifying that the zone client's
   verification material is signed.  If not, fail with a <not-
       authorized/> error.  Note: a service MAY accept a less obtained via secure
       delegation mechanism such a DNS.

   The DANE prooftype is based on [I-D.ietf-dane-srv].  For XMPP
   purposes, the following rules apply:

   o  If there is no SRV records resource record, pursue the fallback methods
      described 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 [RFC6120].

   o  Use the 'to' address of the initial stream header to
       list determine the
      domain name of Delegated Domain Names the TLS client's reference identifier (since use of
      the TLS Server Name Indication is purely discretionary in XMPP, as
      mentioned in [RFC6120]).

7.2.  POSH
   In the Connection Table, and
       updates POSH (PKIX Over Secure HTTP) prooftype, the Binding Table indicating server's proof
   consists of a PKIX certificate that the Sending Domain
       (remote) is allowed to send traffic checked according 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 rules
   from [RFC6120] and [RFC6125], the client's verification material is
   obtained by
   sending retrieving the PKIK certificate over HTTPS at a <db:result> with 'type' set to invalid.  Once authorization
   has been revoked, well-
   known URI [RFC5785], and secure DNS is not necessary since the remote side MUST re-aquire authorization before
   sending any futher traffic HTTPS
   retrieval mechanism relies on the chain of trust from the public key
   infrastructure.

   POSH is fully defined in [I-D.miller-xmpp-posh-prooftype].

8.  Secure Delegation and Multi-Tenancy

   One common method for deploying XMPP services is multi-tenancy or
   virtual hosting: e.g., the domain pair.

   If a server receives a stanza XMPP service for a to/from pair that it does not
   consider authorized, then it MUST return a <not-authorized/> error
   and MAY terminate example.com is actually
   hosted at hosting.example.net.  Such an arrangement is relatively
   convenient in XMPP given the TCP connection.

   Originating               Receiving                     DNS
     Server                    Server                     Server
   -----------               ---------                   --------
       |                          |                          |
       |  <db:result              |                          |
       |     from='sender.tld'    |                          |
       |     to='target.tld'/>    |                          |
       | -----------------------> |                          |
       |                          |  Lookup _xmpp-server     |
       |                          | use of 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     |
       | records [RFC2782], such
   as the following pointer from sender.tld example.com 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 <stream> stanzas
   is incompatible with XMPP services that do not support this protocol,
   because it was previously assumed that when receiving hosting.example.net:

   _xmpp-server._tcp.example.com. 0 IN SRV 0 0 5269 hosting.example.net

   Secure connections with multi-tenancy can work using the PKIX
   prooftype on a connection small scale if the stream provider itself wishes to attibute will contains an XMPP domain hosted by host
   several domains (e.g., several related domains such as jabber-
   de.example and jabber-ch.example).  However, in practice the
   receiving service.  It is RECOMMENDED that if security
   of multi-tenancy has been found to be unwieldy when the connection fails, provider
   hosts large numbers of XMPP services on behalf of multiple customers.
   Typically there are two main reasons for this state of affairs: the
   service tries again using provider (say, hosting.example.net) wishes to limit its
   liability and therefore does not wish to hold the Remote Domain as stream to-
   attribute.

   Presenting a certificate and
   private key for the Server Domain Name is incompatible
   with XMPP services that do not support this protocol, because those
   will expect the Remote Domain in customer (say, example.com) and the certificate.  It is RECOMMENDED
   that if customer
   wishes to improve the authorization fails, security of the service tries again presenting
   the and therefore does not
   wish to share its certificate for the Remote Domain.  A and private key with service may also choose to
   fall back on provider.
   As a weaker identification mechanism such as Server
   Dialback, subject result, server-to-server communications to local policy.

8.  Operational Considerations

   [[ What names example.com go
   unencrypted or the communications are TLS-encrypted but the
   certificates are not checked (which is functionally equivalent to put in certs for servers in a cluster, i.e., all of
   them. ]]

   [[ Do TLS
   connection using an anonymous key exchange).  This is also true of
   client-to-server communications, forcing end users to override
   certificate warnings or configure their clients support multiple names in certs? ]]

   [[ How DNSSEC validation to accept
   certificates for hosting.example.net instead of example.com.  The
   fundamental problem here is done can vary depending on deployment
   scenario. ]]

   [[ Since SNI that if DNSSEC is not used then the act
   of delegation via DNS SRV records is inherently insecure.

   [I-D.ietf-dane-srv] explains how to signal support use DNSSEC for this extension,
   recommended not secure delegation
   with the DANE prooftype and [I-D.miller-xmpp-posh-prooftype] explains
   how to serve end users on use HTTPS redirects for secure delegation with the same POSH
   prooftype.

9.  Prooftype Model

   In general, a DNA prooftype conforms to the following definition:

   prooftype:  A mechanism for proving an association between a domain as hosting
   services. ]]

   [[ Load balancing thoughts, since each connection will handle
      name and an XML stream, where the mechanism defines (1) the nature
      of the server's proof, (2) the matching rules for comparing the
      client's verification material against the server's proof, (3) how
      the client obtains its verification material, and (4) whether the
      mechanism depends on secure DNS.

   The PKI, DANE, and POSH prooftypes adhere to this model.  In
   addition, other prooftypes are possible (examples might include PGP
   keys rather than PKIX certificates, or a lot
   more traffic? ]]

9.  IANA Considerations

   [[ Register XML schema token mechanism such as
   Kerberos or OAuth).

   Some prooftypes depend on (or are enhanced by) secure DNS and
   therefore also need to describe how secure delegation occurs for assertions, if necessary ]]

   [[ Define invalid-connection error element ]] that
   prooftype.

10.  Security Considerations

   [[

   This document simplifies authentication and authorization of XMPP
   servers in certain scenarios.  When used together with DNSSEC-
   protected delegations, it supplements but does not introduce any new supersede the security risks.
   ]]

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

11.  Acknowledgements

   Thanks to Joe Hildebrand
   considerations of [RFC6120] and Sean Turner for prompting the original
   work on this problem, [RFC6125].  Relevant security
   considerations can also be found in [I-D.ietf-dane-srv] and to Stephen Farrell
   [I-D.miller-xmpp-posh-prooftype].

11.  IANA Considerations

   This document has no actions for his work on initial
   versions of this draft. the IANA.

12.  References

12.1.  Normative References

   [I-D.ietf-xmpp-3920bis]

   [I-D.ietf-dane-srv]
              Finch, T., "Using DNS-Based Authentication of Named
              Entities (DANE) TLSA records with SRV and MX records.",
              draft-ietf-dane-srv-02 (work in progress), February 2013.

   [I-D.miller-xmpp-posh-prooftype]
              Saint-Andre, P., "Using PKIX over Secure HTTP (POSH) as a
              Prooftype for XMPP Domain Name Associations", draft-
              miller-xmpp-posh-prooftype-03 (work in progress), February
              2013.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, May 2005.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", RFC
              4949, August 2007.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785, April
              2010.

   [RFC6120]  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] RFC 6120, March 2011.

   [RFC6125]  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, 6125, March 2005.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006. 2011.

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

12.2.  Informative References

   [RFC3920]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 3920, October 2004.

   [XEP-0045]
              Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February
              2012.

   [XEP-0238]
              Saint-Andre, P., "XMPP Protocol Flows for Inter-Domain
              Federation", XSF XEP 0238, March 2010. 2008.

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

Authors' Addresses

   Richard L. Barnes
   BBN Technologies

   Peter Saint-Andre
   Cisco Systems, Inc.
   1899 Wynkoop Street, Suite 600
   Denver, CO  80202
   USA

   Email: rbarnes@bbn.com

   Jonas Lindberg
   Google psaintan@cisco.com

   Matthew Miller
   Cisco Systems, Inc.
   1899 Wynkoop Street, Suite 600
   Denver, CO  80202
   USA

   Email: jonasl@google.com mamille2@cisco.com