rfc7712.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc1034 SYSTEM "reference.RFC.1034.xml">
  <!ENTITY rfc1035 SYSTEM "reference.RFC.1035.xml">
  <!ENTITY rfc2142 SYSTEM "reference.RFC.2142.xml">
  <!ENTITY rfc2782 SYSTEM "reference.RFC.2782.xml">
  <!ENTITY rfc3920 SYSTEM "reference.RFC.3920.xml">
  <!ENTITY rfc4033 SYSTEM "reference.RFC.4033.xml">
  <!ENTITY rfc4120 SYSTEM "reference.RFC.4120.xml">
  <!ENTITY rfc4422 SYSTEM "reference.RFC.4422.xml">
  <!ENTITY rfc4949 SYSTEM "reference.RFC.4949.xml">
  <!ENTITY rfc5280 SYSTEM "reference.RFC.5280.xml">
  <!ENTITY rfc5785 SYSTEM "reference.RFC.5785.xml">
  <!ENTITY rfc6066 SYSTEM "reference.RFC.6066.xml">
  <!ENTITY rfc6091 SYSTEM "reference.RFC.6091.xml">
  <!ENTITY rfc6120 SYSTEM "reference.RFC.6120.xml">
  <!ENTITY rfc6125 SYSTEM "reference.RFC.6125.xml">
  <!ENTITY rfc6698 SYSTEM "reference.RFC.6698.xml">
  <!ENTITY rfc6749 SYSTEM "reference.RFC.6749.xml">
  <!ENTITY rfc7218 SYSTEM "reference.RFC.7218.xml">
  <!ENTITY rfc7590 SYSTEM "reference.RFC.7590.xml">
  <!ENTITY rfc7673 SYSTEM "reference.RFC.7673.xml">
]>

<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>

<rfc category="std" number="7712" ipr="trust200902" submissionType="IETF" consensus="yes">

  <front>
    <title abbrev="XMPP DNA">Domain Name Associations (DNA) in&nbsp;the&nbsp;Extensible&nbsp;Messaging&nbsp;and&nbsp;Presence&nbsp;Protocol (XMPP)</title>

    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization>&amp;yet</organization>
      <address>
        <email>peter@andyet.com</email>
        <uri>https://andyet.com/</uri>
      </address>
    </author>

    <author initials="M." surname="Miller" fullname="Matthew Miller">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>1899 Wynkoop Street, Suite 600</street>
          <city>Denver</city>
          <region>CO</region>
          <code>80202</code>
          <country>United States</country>
        </postal>
        <email>mamille2@cisco.com</email>
      </address>
    </author>

    <author initials="P." surname="Hancke" fullname="Philipp Hancke">
      <organization>&amp;yet</organization>
      <address>
        <email>fippo@andyet.com</email>
        <uri>https://andyet.com/</uri>
      </address>
    </author>

    <date month="November" year="2015"/>

    <keyword>XMPP</keyword>
    <keyword>Extensible Messaging and Presence Protocol</keyword>
    <keyword>Jabber</keyword>
    <keyword>federation</keyword>
    <keyword>delegation</keyword>
    <keyword>security</keyword>

    <abstract>
      <t>This document improves the security of the Extensible Messaging and
      Presence Protocol (XMPP) in two ways.  First, it specifies how to
      establish a strong association between a domain name and an XML stream,
      using the concept of "prooftypes".  Second, it describes how to securely
      delegate a service domain name (e.g., example.com) to a target server
      hostname (e.g., hosting.example.net); this is especially important in
      multi-tenanted environments where the same target server hosts a large
      number of domains.</t>

    </abstract>
  </front>

  <middle>

    <section title="Introduction" anchor="intro">
      <t>In systems that use the Extensible Messaging and Presence Protocol
      (XMPP) <xref target='RFC6120'/>, it is important to establish a strong
      association between the DNS domain name of an XMPP service (e.g.,
      example.com) and the XML stream that a client or peer server initiates
      with that service. In other words, the client or peer server needs to
      verify the identity of the server to which it connects. Additionally,
      servers need to verify incoming connections from other servers.</t>

      <t>To date, such verification has been established based on information
      obtained from the Domain Name System (DNS), the Public Key
      Infrastructure (PKI), or similar sources.  In particular, XMPP as
      defined in <xref target='RFC6120'/> assumed that Domain Name
      Associations (DNA) are to be proved using the "PKIX prooftype";
      that is, the server's proof consists of a PKIX certificate that is
      checked according to the XMPP profile of the matching rules from
      <xref target='RFC6125'/> (and the overall validation rules from
      <xref target='RFC5280'/>), the client's verification material is
      obtained out of band in the form of a trusted root, and secure DNS
      is not necessary.</t>

      <t>By extending the concept of a domain name association within XMPP,
      this document does the following:</t>

      <t>
        <list style='numbers'>
          <t>Generalizes the model currently in use so that additional
          prooftypes can be defined if needed.</t>

          <t>Provides a basis for modernizing some prooftypes to reflect
          progress in underlying technologies such as DNS Security <xref
          target="RFC4033"/>.</t>

          <t>Describes the flow of operations for establishing a domain name
          association.</t>

        </list>
      </t>
      <t>This document also provides guidelines for secure delegation of a
      service domain name (e.g., example.com) to a target server hostname
      (e.g., hosting.example.net).  The need for secure delegation arises
      because the process for resolving the domain name of an XMPP service
      into the IP address at which an XML stream will be negotiated (see <xref
      target='RFC6120'/>) can involve delegation of a service domain name to a
      target server hostname using technologies such as DNS SRV records <xref
      target='RFC2782'/>.  A more detailed description of the delegation
      problem can be found in <xref target='RFC7711'/>.  The domain
      name association can be verified only if the delegation is done in a
      secure manner.</t>

    </section>

    <section title="Terminology" anchor="terms">
      <t>This document inherits XMPP terminology from <xref target="RFC6120"/>
      and <xref target="XEP-0220"/>; DNS terminology from <xref
      target="RFC1034"/>, <xref target="RFC1035"/>, <xref target="RFC2782"/>,
      and <xref target="RFC4033"/>; and security terminology from <xref
      target="RFC4949"/> and <xref target="RFC5280"/>.  The terms "reference
      identity" and "presented identity" are used as defined in the "CertID"
      specification <xref target="RFC6125"/>.  For the sake of consistency
      with <xref target='RFC7673'/>, this document uses the terms
      "service domain name" and "target server hostname" to refer to the same
      entities identified by the terms "source domain" and "derived domain"
      from <xref target='RFC6125'/>.</t>

    </section>

    <section title="Client-to-Server (C2S) DNA" anchor="c2s">

      <t>The client-to-server case is much simpler than the server-to-server
      case because the client does not assert a domain name; this means
      that verification happens in only one direction.  Therefore, we
      describe this case first to help the reader understand
      domain name associations in XMPP.</t>


      <section title="C2S Flow" anchor="c2s-flow">
        <t>The following flow chart illustrates the protocol flow for
        establishing a domain name association for an XML stream from a client
        (C) to a server (S) using the standard PKIX prooftype specified in
        <xref target="RFC6120"/>.</t>

        <figure>
          <artwork><![CDATA[
                        |
                DNS RESOLUTION ETC.
                        |
+-----------------STREAM HEADERS---------------------+
|                                                    |
|  C: <stream to='a.example'>                        |
|                                                    |
|  S: <stream from='a.example'>                      |
|                                                    |
+----------------------------------------------------+
                        |
+-----------------TLS NEGOTIATION--------------------+
|                                                    |
|  S: Server Certificate                             |
|                                                    |
+----------------------------------------------------+
                        |
          (client checks certificate and 
           establishes DNA for a.example)
          ]]></artwork>
        </figure>
      </section>
      
      <section title="C2S Description" anchor="c2s-description">
        <t>The simplified order of events (see <xref target='RFC6120'/> for
        details) in establishing an XML stream from a client (user@a.example)
        to a server (a.example) is as follows:</t>

        <t>
          <list style='numbers'>
            <t>The client resolves via DNS the service
            <vspace/>
            _xmpp-client._tcp.a.example.</t>
            <t>The client opens a TCP connection to the resolved IP
            address.</t>

            <t>
              The client sends an initial stream header to the server:
              <vspace blankLines='1'/>
              &lt;stream:stream to='a.example'&gt;
            </t>
            <t>
              The server sends a response stream header to the client,
              asserting that it is a.example:

              <vspace blankLines='1'/>
              &lt;stream:stream from='a.example'&gt;
            </t>
            <t>The parties attempt TLS negotiation, during which the XMPP
            server (acting as a TLS server) presents a PKIX certificate
            proving that it is a.example.</t>

            <t>The client checks the PKIX certificate that the server
            provided; if the proof is consistent with the XMPP profile of the
            matching rules from <xref target='RFC6125'/> and the certificate
            is otherwise valid according to <xref target='RFC5280'/>, the
            client accepts that there is a strong domain name association
            between its stream to the target server and the DNS domain name of
            the XMPP service.</t>

          </list>
        </t>
        <t>The certificate that the server presents might not be acceptable to
        the client. As one example, the server might be hosting multiple
        domains and secure delegation as described in <xref
        target='delegation'/> is necessary. As another example, the server
        might present a self-signed certificate, which requires the client to
        either (1)&nbsp;apply the fallback process described in
        Section&nbsp;6.6.4 of <xref target='RFC6125'/> or (2)&nbsp;prompt
        the user to accept an unauthenticated connection as described in
        Section&nbsp;3.4 of <xref target='RFC7590'/>.</t>

      </section>
    </section>

    <section title="Server-to-Server (S2S) DNA" anchor="s2s">
      <t>The server-to-server case is significantly more complex than the
      client-to-server case, and it involves the checking of
      domain name associations in both directions along with other
      "wrinkles" described in the following sections.  In some parts of
      the flow, server-to-server communications use the Server Dialback
      protocol first specified in (the now obsolete) <xref target='RFC3920'/>
      and since moved to <xref target='XEP-0220'/>.  See "Impact of TLS
      and DNSSEC on Dialback" <xref target='XEP-0344'/> for considerations
      when using it together with TLS and DNSSEC. Also, "Bidirectional
      Server-to-Server Connections" <xref target='XEP-0288'/> provides a
      way to use the server-to-server connections for bidirectional
      exchange of XML stanzas, which reduces the complexity of some of
      the processes involved.</t>


      <section title="S2S Flow" anchor="s2s-flow">
        <t>The following flow charts illustrate the protocol flow for
        establishing domain name associations between Server 1 (the initiating
        entity) and Server 2 (the receiving entity), as described in the
        remaining sections of this document.</t>

        <t>A simple S2S scenario would be as follows:</t>

        <figure>
          <artwork><![CDATA[
                    |
             DNS RESOLUTION ETC.
                    |
+-------------STREAM HEADERS--------------------+
|                                               |
|  A: <stream from='a.example' to='b.example'>  |
|                                               |
|  B: <stream from='b.example' to='a.example'>  |
|                                               |
+-----------------------------------------------+
                    |
+-------------TLS NEGOTIATION-------------------+
|                                               |
|  B: Server Certificate                        |
|  B: Certificate Request                       |
|  A: Client Certificate                        |
|                                               |
+-----------------------------------------------+
                    |
    (A establishes DNA for b.example)
                    |
          ]]></artwork>
        </figure>
        <t>After the domain name association has been established in one
        direction, it is possible to perform mutual authentication using
        the Simple Authentication and Security Layer (SASL) <xref
        target='RFC4422'/> and thus establish domain name associations in
        both directions.</t>

        <figure>
          <artwork><![CDATA[
                    |
+-------------AUTHENTICATION--------------------+
|                   |                           |
|       {valid client certificate?} --+         |
|                   |                 |         |
|                   | yes         no  |         |
|                   v                 |         |
|             SASL EXTERNAL           |         |
|             (mutual auth)           |         |
|   (B establishes DNA for a.example) |         |
+-------------------------------------|---------+
                                      |
          ]]></artwork>
        </figure>

        <t>However, if mutual authentication cannot be completed using SASL,
        the receiving server needs to establish a domain name association in
        another way.  This scenario is described in <xref
        target='s2s-notsimple'/>.</t>

        <figure>
          <artwork><![CDATA[
                                      |
                    +-----------------+
                    |
        (Section 4.3: No Mutual PKIX Authentication)
                    |
                    | B needs to establish DNA
                    | for this stream from a.example, 
                    | so A asserts its identity
                    |
+----------DIALBACK IDENTITY ASSERTION----------+
|                                               |
|  A: <db:result from='a.example'               |
|                to='b.example'>                |
|       some-dialback-key                       |
|     </db:result>                              |
|                                               |
+-----------------------------------------------+
                    |
             DNS RESOLUTION ETC.
                    |
+-------------STREAM HEADERS--------------------+
|                                               |
|  B: <stream from='b.example' to='a.example'>  |
|                                               |
|  A: <stream from='a.example' to='b.example'>  |
|                                               |
+-----------------------------------------------+
                    |
+-------------TLS NEGOTIATION-------------------+
|                                               |
|  A: Server Certificate                        |
|                                               |
+-----------------------------------------------+
                    |
+----------DIALBACK IDENTITY VERIFICATION-------+
|                                               |
|  B: <db:verify from='b.example'               |
|                to='a.example'                 |
|                id='...'>                      |
|       some-dialback-key                       |
|     </db:verify>                              |
|                                               |
|  A: <db:verify from='a.example'               |
|                to='b.example'                 |
|                type='valid'                   |
|                id='...'>                      |
|                                               |
+-----------------------------------------------+
                    |
    (B establishes DNA for a.example)
                    |
          ]]></artwork>
        </figure>
        <t>If one of the servers hosts additional service names (e.g., Server
        2 might host c.example in addition to b.example and Server 1 might
        host rooms.a.example in addition to a.example), then the servers can
        use Server Dialback "piggybacking" to establish additional domain name
        associations for the stream, as described in <xref
        target='s2s-piggybacking'/>.</t>

        <t>There are two varieties of piggybacking.  The first is here called
        "assertion".</t>

        <figure>
          <artwork><![CDATA[
                    |
      (Section 4.4.1: Piggybacking Assertion)
                    |
+----------DIALBACK IDENTITY ASSERTION----------+
|                                               |
|  B: <db:result from='c.example'               |
|                to='a.example'/>               |
|                                               |
+-----------------------------------------------+
                    |
+-------DNA ESTABLISHMENT AS ABOVE--------------+
|                                               |
|    DNS RESOLUTION, STREAM HEADERS,            |
|    TLS NEGOTIATION, AUTHENTICATION            |
|                                               |
+-----------------------------------------------+
                    |
+----------DIALBACK IDENTITY VERIFICATION-------+
|                                               |
|  A: <db:result from='a.example'               |
|                to='c.example'                 |
|                type='valid'/>                 |
|                                               |
+-----------------------------------------------+
                    |
          ]]></artwork>
        </figure>

        <t>The second variety of piggybacking is here called "supposition".</t>

        <figure>
          <artwork><![CDATA[
                    |
      (Section 4.4.2: Piggybacking Supposition)
                    |
+-----------SUBSEQUENT CONNECTION---------------+
|                                               |
|  B: <stream from='c.example'                  |
|             to='rooms.a.example'>             |
|                                               |
|  A: <stream from='rooms.a.example'            |
|             to='c.example'>                   |
|                                               |
+-----------------------------------------------+
                    |
+-------DNA ESTABLISHMENT AS ABOVE--------------+
|                                               |
|    DNS RESOLUTION, STREAM HEADERS,            |
|    TLS NEGOTIATION, AUTHENTICATION            |
|                                               |
+-----------------------------------------------+
                    |
+-----------DIALBACK OPTIMIZATION---------------+
|                                               |
|  B: <db:result from='c.example'               |
|                to='rooms.a.example'/>         |
|                                               |
|  B: <db:result from='rooms.a.example'         |
|                to='c.example'                 |
|                type='valid'/>                 |
|                                               |
+-----------------------------------------------+
          ]]></artwork>
        </figure>

      </section>

      <section title="A Simple S2S Scenario" anchor="s2s-simple">
        <t>To illustrate the problem, consider the simplified order of events
        (see <xref target='RFC6120'/> for details) in establishing an XML
        stream between Server 1 (a.example) and Server 2 (b.example):</t>

        <t>
          <list style='numbers'>
            <t>Server 1 resolves via DNS the service
            <vspace/>
            _xmpp-server._tcp.b.example.</t>

            <t>Server 1 opens a TCP connection to the resolved IP address.</t>
            <t>
              Server 1 sends an initial stream header to Server 2, asserting
              that it is a.example:

              <vspace blankLines='1'/>
              &lt;stream:stream from='a.example' to='b.example'&gt;
            </t>
            <t>
              Server 2 sends a response stream header to Server 1, asserting
              that it is b.example:

              <vspace blankLines='1'/>
              &lt;stream:stream from='b.example' to='a.example'&gt;
            </t>
            <t>The servers attempt TLS negotiation, during which Server 2
            (acting as a TLS server) presents a PKIX certificate proving that
            it is b.example and Server 1 (acting as a TLS client) presents a
            PKIX certificate proving that it is a.example.</t>

            <t>Server 1 checks the PKIX certificate that Server 2 provided,
            and Server 2 checks the PKIX certificate that Server 1 provided;
            if these proofs are consistent with the XMPP profile of the
            matching rules from <xref target='RFC6125'/> and are otherwise
            valid according to <xref target='RFC5280'/>, each server accepts
            that there is a strong domain name association between its
            stream to the other party and the DNS domain name of the other
            party (i.e., mutual authentication is achieved).</t>

          </list>
        </t>
        <t>Several simplifying assumptions underlie the "happy path" scenario
        just outlined:</t>

        <t>
          <list style='symbols'>
            <t>The PKIX certificate presented by Server 2 during TLS
            negotiation is acceptable to Server 1 and matches the expected
            identity.</t>

            <t>The PKIX certificate presented by Server 1 during TLS
            negotiation is acceptable to Server 2; this enables the parties
            to complete mutual authentication.</t>

            <t>There are no additional domains associated with Server 1 and
            Server 2 (say, a sub&nbhy;domain rooms.a.example on Server 1
            or a second domain c.example on Server 2).</t>

            <t>The server administrators are able to obtain PKIX certificates
            issued by a widely accepted Certification Authority (CA) in the
            first place.</t>

            <t>The server administrators are running their own XMPP servers,
            rather than using hosting services.</t>

          </list>
        </t>
        <t>Let's consider each of these "wrinkles" in turn.
</t>

      </section>

      <section title="No Mutual PKIX Authentication" anchor="s2s-notsimple">
        <t>If the PKIX certificate presented by Server 1 during TLS
        negotiation is not acceptable to Server 2, Server 2 is unable to
        mutually authenticate Server 1. Therefore, Server 2 needs to verify
        the asserted identity of Server 1 by other means.</t>

        <t>
          <list style='numbers'>
            <t>
              Server 1 asserts that it is a.example using the Server Dialback
              protocol:

              <figure><artwork><![CDATA[
    <db:result from='a.example' to='b.example'>
               some-dialback-key</db:result>
]]></artwork></figure>

            </t>
            <t>Server 2 resolves via DNS the service
            <vspace/>
            _xmpp-server._tcp.a.example.</t>

            <t>Server 2 opens a TCP connection to the resolved IP address.</t>
            <t>
              Server 2 sends an initial stream header to Server 1, asserting
              that it is b.example:

              <vspace blankLines='1'/>
              &lt;stream:stream from='b.example' to='a.example'&gt;
            </t>
            <t>
              Server 1 sends a response stream header to Server 2, asserting
              that it is a.example:

              <vspace blankLines='1'/>
              &lt;stream:stream from='a.example' to='b.example'&gt;
            </t>
            <t>The servers attempt TLS negotiation, during which Server 1
            (acting as a TLS server) presents a PKIX certificate.</t>

            <t>Server 2 checks the PKIX certificate that Server 1 provided
            (this might be the same certificate presented by Server 1 as a
            client certificate in the initial connection).  However, Server 2
            does not accept this certificate as proving that Server 1 is
            authorized as a.example and therefore uses another method (here,
            the Server Dialback protocol) to establish the domain name
            association.</t>

            <t>
              Server 2 proceeds with Server Dialback in order to establish the
              domain name association. In order to do this, it sends a request
              for verification as described in <xref target='XEP-0220'/>:

              <figure><artwork><![CDATA[
    <db:verify from='b.example' to='a.example'
               id='...'>some-dialback-key</db:verify>
]]></artwork></figure>

            </t>
            <t>
              Server 1 responds to this:
              <vspace blankLines='1'/>
              &lt;db:verify from='a.example' to='b.example' id='...'
              type='valid/&gt;

              <vspace blankLines='1'/>
              allowing Server 2 to establish the domain name association.
            </t>
          </list>
        </t>
        <t>In some situations (e.g., if the Authoritative Server in Server
        Dialback presents the same certificate as the Originating Server), it
        is the practice of some XMPP server implementations to skip steps 8
        and 9. These situations are discussed in "Impact of TLS and DNSSEC on
        Dialback" <xref target='XEP-0344'/>.</t>

      </section>

      <section title="Piggybacking" anchor="s2s-piggybacking">
        <section title="Assertion" anchor="s2s-piggybacking-assertion">
          <t>Consider the common scenario in which Server 2 hosts not only
          b.example but also a second domain c.example (often called a
          "multi&nbhy;tenanted" environment).  If a user of Server 2 associated
          with c.example wishes to communicate with a friend at a.example,
          Server 2 needs to send XMPP stanzas from the domain c.example rather
          than b.example.  Although Server 2 could open a new TCP connection
          and negotiate new XML streams for the domain pair of c.example and
          a.example, that is wasteful (especially if Server 2 hosts a large
          number of domains).  Server 2 already has a connection to a.example,
          so how can it assert that it would like to add a new domain pair to
          the existing connection?</t>

          <t>The traditional method for doing so is the Server Dialback
          protocol <xref target='XEP-0220'/>.  Here, Server 2 can send a
          &lt;db:result/&gt; element for the new domain pair over the existing
          stream.</t>

          <figure>
            <artwork><![CDATA[
    <db:result from='c.example' to='a.example'>
      some-dialback-key
    </db:result>
            ]]></artwork>
          </figure>
          <t>This &lt;db:result/&gt; element functions as Server 2's
          assertion that it is (also) c.example (thus, the element is
          functionally equivalent to the 'from' address of an initial
          stream header as previously described).</t>

          <t>In response to this assertion, Server 1 needs to obtain some kind
          of proof that Server 2 really is also c.example. If the certificate
          presented by Server 2 is also valid for c.example, then no further
          action is necessary.  However, if not, then Server 1 needs to do a
          bit more work.  Specifically, Server 1 can pursue the same strategy
          it used before:</t>

          <t>
            <list style='numbers'>
              <t>Server 1 resolves via DNS the service
              <vspace/>
              _xmpp-server._tcp.c.example.</t>

              <t>Server 1 opens a TCP connection to the resolved IP address
              (which might be the same IP address as for b.example).</t>

              <t>
                Server 1 sends an initial stream header to Server 2, asserting
                that it is a.example:

                <vspace blankLines='1'/>
                &lt;stream:stream from='a.example' to='c.example'&gt;
              </t>
              <t>
                Server 2 sends a response stream header to Server 1, asserting
                that it is c.example:

                <vspace blankLines='1'/>
                &lt;stream:stream from='c.example' to='a.example'&gt;
              </t>
              <t>The servers attempt TLS negotiation, during which Server 2
              (acting as a TLS server) presents a PKIX certificate proving
              that it is c.example.</t>

              <t>
                At this point, Server 1 needs to establish that, despite
                different certificates, c.example is associated with the
                origin of the request. This is done using Server Dialback
                <xref target='XEP-0220'/>:

                <figure><artwork><![CDATA[
    <db:verify from='a.example' to='c.example'
               id='...'>some-dialback-key</db:verify>
]]></artwork></figure>

              </t>
              <t>
                Server 2 responds to this:
                <vspace blankLines='1'/>
                &lt;db:verify from='c.example' to='a.example' id='...'
                type='valid/&gt;

                <vspace blankLines='1'/>
                allowing Server 1 to establish the domain name association.
              </t>
            </list>
          </t>
          <t>Now that Server 1 accepts the domain name association, it informs
          Server 2 of that fact:</t>

          <figure>
            <artwork><![CDATA[
    <db:result from='a.example' to='c.example' type='valid'/>
            ]]></artwork>
          </figure>
          <t>The parties can then terminate the second connection, because it
          was used only for Server 1 to associate a stream with the domain
          name c.example (the dialback key links the original stream to the
          new association).</t>

        </section>
        <section title="Supposition" anchor="s2s-piggybacking-supposition">
          <t>Piggybacking can also occur in the other direction.  Consider the
          common scenario in which Server 1 provides XMPP services not only
          for a.example but also for a sub&nbhy;domain such as a
          Multi&nbhy;User Chat <xref target='XEP-0045'/> service at
          rooms.a.example.  If a user from c.example at Server 2 wishes to
          join a room on the groupchat service, Server 2 needs to send
          XMPP stanzas from the domain c.example to the domain
          rooms.a.example rather than a.example.</t>

          <t>First, Server 2 needs to determine whether it can
          piggyback the domain rooms.a.example on the connection to
          a.example:</t>

          <t>
            <list style='numbers'>
              <t>Server 2 resolves via DNS the service
              <vspace/>
              _xmpp-server._tcp.rooms.a.example.</t>

              <t>Server 2 determines that this resolves to an IP address
              and port to which it is already connected.</t>

              <t>Server 2 determines that the PKIX certificate for that active
              connection would also be valid for the rooms.a.example domain
              and that Server 1 has announced support for dialback errors.</t>

            </list>
          </t>
          <t>Server 2 sends a dialback key to Server 1 over the existing
          connection:</t>

          <figure>
            <artwork><![CDATA[
    <db:result from='c.example' to='rooms.a.example'>
      some-dialback-key
    </db:result>
            ]]></artwork>
          </figure>
          <t>Server 1 then informs Server 2 that it accepts the domain name
          association:</t>

          <figure>
            <artwork><![CDATA[
    <db:result from='rooms.a.example' to='c.example' type='valid'/>
            ]]></artwork>
          </figure>
        </section>
      </section>
    </section>

    <section title="Alternative Prooftypes" anchor="alternatives">
      <t>The foregoing protocol flows assumed that domain name associations
      were proved using the PKIX prooftype.  However, sometimes XMPP server
      administrators are unable or unwilling to obtain valid PKIX certificates
      for all of the domains they host at their servers.  For example:</t>

      <t>
        <list style='symbols'>
          <t>In order to issue a PKIX certificate, a CA might try to send
          email messages to authoritative mailbox names <xref
          target='RFC2142'/>, but the administrator of a subsidiary service
          such as im.cs.podunk.example cannot receive email sent to
          hostmaster@podunk.example.</t>

          <t>A hosting provider such as hosting.example.net might not want to
          take on the liability of holding the certificate and private key for
          a tenant such as example.com (or the tenant might not want the
          hosting provider to hold its certificate and private key).</t>

          <t>Even if PKIX certificates for each tenant can be obtained, the
          management of so many certificates can introduce a large
          administrative load.</t>

        </list>
      </t>
      <t>(Additional discussion can be found in <xref
      target='RFC7711'/>.)</t>

      <t>In these circumstances, prooftypes other than PKIX are desirable or
      necessary.  As described below, two alternatives have been defined so
      far: DNS-Based Authentication of Named Entities (DANE) and PKIX over
      Secure HTTP (POSH).</t>

      <section title="DANE" anchor="alternatives-dane">
        <t>The DANE prooftype is defined as follows:</t>
        <t>
          <list style='numbers'>
            <t>The server's proof consists of either a service certificate or
            domain-issued certificate (TLSA usage PKIX-EE or DANE-EE; see
            <xref target='RFC6698'/> and <xref target='RFC7218'/>).</t>

            <t>The proof is checked by verifying an exact match or a hash of
            either the SubjectPublicKeyInfo or the full certificate.</t>

            <t>The client's verification material is obtained via secure DNS
            <xref target="RFC4033"/> as described in <xref
            target='RFC7673'/>.</t>

            <t>Secure DNS is necessary in order to effectively establish an
            alternative chain of trust from the service certificate or
            domain-issued certificate to the DNS root.</t>

          </list>
        </t>
        <t>The DANE prooftype makes use of DNS-Based Authentication of Named
        Entities <xref target='RFC6698'/>, specifically the use of DANE with
        DNS SRV records <xref target='RFC7673'/>.  For XMPP
        purposes, the following rules apply:</t>

        <t>
          <list style='symbols'>
            <t>If there is no SRV resource record, pursue the fallback methods
            described in <xref target='RFC6120'/>.</t>

            <t>Use the 'to' address of the initial stream header to determine
            the domain name of the TLS client's reference identifier (because
            the use of the Server Name Indication extension (TLS SNI) <xref
            target='RFC6066'/> is purely discretionary in XMPP, as mentioned
            in <xref target='RFC6120'/>).</t>

          </list>
        </t>
      </section>
      <section title="POSH" anchor="alternatives-posh">
        <t>The POSH prooftype is defined as follows:</t>
        <t>
          <list style='numbers'>
            <t>The server's proof consists of a PKIX certificate.</t>
            <t>The proof is checked according to the rules from <xref
            target='RFC6120'/> and <xref target='RFC6125'/>.</t>

            <t>The client's verification material is obtained by retrieving a
            hash of the PKIX certificate over HTTPS at a well-known URI <xref
            target='RFC5785'/>.</t>

            <t>Secure DNS is not necessary, because the HTTPS retrieval
            mechanism relies on the chain of trust from the public key
            infrastructure.
            </t>

          </list>
        </t>
        <t>POSH is defined in <xref target='RFC7711'/>.  For XMPP purposes,
        the following rules apply:</t>

        <t>
          <list style='symbols'>
            <t>If no verification material is found via POSH, pursue the
            fallback methods described in <xref target='RFC6120'/>.</t>

            <t>Use the 'to' address of the initial stream header to determine
            the domain name of the TLS client's reference identifier
            (because the use of TLS SNI <xref target='RFC6066'/> is purely
            discretionary in XMPP, as mentioned in
            <xref target='RFC6120'/>).</t>

          </list>
        </t>
        <t>The well-known URIs <xref target='RFC5785'/> to be used for POSH
        are:</t>

        <t>
          <list style='symbols'>
            <t>"/.well-known/posh/xmpp-client.json" for client-to-server
            connections</t>

            <t>"/.well-known/posh/xmpp-server.json" for server-to-server
            connections</t>

          </list>
        </t>
      </section>
    </section>

    <section title="Secure Delegation and Multi-Tenancy" anchor="delegation">
      <t>One common method for deploying XMPP services is multi-tenancy: e.g.,
      XMPP services for the service domain name example.com are actually
      hosted at the target server hosting.example.net.  Such an arrangement is
      relatively convenient in XMPP given the use of DNS SRV records <xref
      target='RFC2782'/>, such as the following delegation from example.com to
      hosting.example.net:</t>

      <figure>
        <artwork><![CDATA[
_xmpp-server._tcp.example.com. 0 IN SRV 0 0 5269 hosting.example.net
        ]]></artwork>
      </figure>
      <t>Secure connections with multi-tenancy can work using the PKIX
      prooftype on a small scale if the provider itself wishes to host several
      domains (e.g., related domains such as jabber-de.example and
      jabber-ch.example).  However, in practice the security of
      multi&nbhy;tenancy has been found to be unwieldy when the provider
      hosts large numbers of XMPP services on behalf of multiple tenants
      (see <xref target='RFC7711'/> for a detailed description).  There
      are two possible results: either (1)&nbsp;server-to-server
      communications to example.com are unencrypted or (2)&nbsp;the
      communications are TLS&nbhy;encrypted but the certificates are not
      checked (which is functionally equivalent to a 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 to accept or "pin" certificates for hosting.example.net instead
      of example.com.  The fundamental problem here is that if DNSSEC is not
      used, then the act of delegation via DNS SRV records is inherently
      insecure.</t>

      <t>The specification for the use of SRV records with DANE <xref
      target='RFC7673'/> explains how to use DNSSEC for secure
      delegation with the DANE prooftype, and the POSH specification <xref
      target='RFC7711'/> explains how to use HTTPS redirects for
      secure delegation with the POSH prooftype.</t>

    </section>

    <section title="Prooftype Model" anchor="model">
      <t>In general, a Domain Name Association (DNA) prooftype conforms to the
      following definition:</t>

      <t><list style="hanging">
      <t hangText="prooftype:">A mechanism for proving an association
      between a domain 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 or not the mechanism depends on secure DNS.</t>
      </list></t>    

      <t>The PKIX, DANE, and POSH prooftypes adhere to this model. (Some
      prooftypes depend on, or are enhanced by, secure DNS <xref
      target="RFC4033"/> and thus also need to describe how they ensure secure
      delegation.)</t>

      <t>Other prooftypes are possible; examples might include TLS with
      Pretty Good Privacy (PGP) keys <xref target='RFC6091'/>,
      a token mechanism such as Kerberos <xref target='RFC4120'/> or
      OAuth <xref target='RFC6749'/>, and Server Dialback
      keys <xref target='XEP-0220'/>.</t>

      <t>Although the PKIX prooftype reuses the syntax of the XMPP Server
      Dialback protocol <xref target='XEP-0220'/> for signaling between
      servers, this framework document does not define how the generation
      and validation of Server Dialback keys (also specified in <xref
      target='XEP-0220'/>) constitute a DNA prooftype. However, nothing in
      this document prevents the continued use of Server Dialback for
      signaling, and a future specification (or an updated version of <xref
      target='XEP-0220'/>) might define a DNA prooftype for Server Dialback
      keys in a way that is consistent with this framework.</t>

    </section>

    <section title="Guidance for Server Operators" anchor="ops">
      <t>This document introduces the concept of a prooftype in order to
      explain and generalize the approach to establishing a strong association
      between the DNS domain name of an XMPP service and the XML stream that a
      client or peer server initiates with that service.</t>

      <t>The operations and management implications of DNA prooftypes will
      depend on the particular prooftypes that an operator supports.  For
      example:</t>

      <t>
        <list style='symbols'>
          <t>To support the PKIX prooftype <xref target='RFC6120'/>, an
          operator needs to obtain certificates for the XMPP server from a
          Certification Authority (CA).  However, DNS Security is not
          required.</t>

          <t>To support the DANE prooftype <xref target='RFC7673'/>,
          an operator can generate its own certificates for the XMPP server or
          obtain them from a CA.   In addition, DNS Security is required.</t>

          <t>To support the POSH prooftype <xref
          target='RFC7711'/>, an operator can generate its own
          certificates for the XMPP server or obtain them from a CA, but in
          addition needs to deploy the web server for POSH files with
          certificates obtained from a CA.  However, DNS Security is not
          required.</t>

        </list>
      </t>
      <t>Considerations for the use of the foregoing prooftypes are
      explained in the relevant specifications.  See in particular
      Section 13.7 of <xref target='RFC6120'/>,
      Section 6 of <xref target='RFC7673'/>, and
      Section 7 of <xref target='RFC7711'/>.</t>

      <t>Naturally, these operations and management considerations are
      additive: if an operator wishes to use multiple prooftypes, the
      complexity of deployment increases (e.g., the operator might want to
      obtain a PKIX certificate from a CA for use in the PKIX prooftype
      and generate its own certificate for use in the DANE prooftype).
      This is an unavoidable aspect of supporting as many prooftypes as
      needed in order to ensure that domain name associations can be
      established in the largest possible percentage of cases.</t>

    </section>

    <section title="IANA Considerations" anchor="iana">
      <t>The POSH specification <xref target='RFC7711'/>
      establishes the "POSH Service Names" registry for use in well-known
      URIs <xref target='RFC5785'/>.  This specification registers two such
      service names for use in XMPP: "xmpp-client" and "xmpp&nbhy;server".
      The completed registration templates follow.</t>

      <section title="POSH Service Name for xmpp-client Service" anchor="iana-client">
        <t>Service name: xmpp-client</t>
        <t>Change controller: IETF</t>

        <t><list style="hanging">
        <t hangText="Definition and usage:">Specifies the location of a
        POSH file containing verification material or a reference thereto
        that enables a client to verify the identity of a server for a
        client&nbhy;to-server stream in XMPP</t>
        </list></t>

        <t>Specification: RFC 7712 (this document)</t>
      </section>
      <section title="POSH Service Name for xmpp-server Service" anchor="iana-server">
        <t>Service name: xmpp-server</t>
        <t>Change controller: IETF</t>

        <t><list style="hanging">
        <t hangText="Definition and usage:">Specifies the location of a
        POSH file containing verification material or a reference thereto
        that enables a server to verify the identity of a peer server for a
        server-to-server stream in XMPP</t>
        </list></t>

        <t>Specification: RFC 7712 (this document)</t>
      </section>
    </section>

    <section title="Security Considerations" anchor="security">
      <t>With regard to the PKIX prooftype, this document supplements but does
      not supersede the security considerations of <xref target='RFC6120'/>
      and <xref target='RFC6125'/>.</t>

      <t>With regard to the DANE and POSH prooftypes, the reader is referred
      to <xref target='RFC7673'/> and <xref target='RFC7711'/>,
      respectively.</t>

      <t>Any future prooftypes need to thoroughly describe how they conform to
      the prooftype model specified in <xref target='model'/> of this
      document.</t>

    </section>

  </middle>

  <back>

    <references title="Normative References">

<!-- draft-ietf-xmpp-posh (RFC 7711) -->
<reference anchor='RFC7711' target="http://www.rfc-editor.org/info/rfc7711">
<front>
<title>PKIX over Secure HTTP (POSH)</title>
<author initials='M' surname='Miller' fullname='Matthew Miller'>
    <organization />
</author>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
    <organization />
</author>
<date month='November' year='2015' />
</front>
<seriesInfo name='RFC' value='7711' />
<seriesInfo name='DOI' value='10.17487/RFC7711'/>
</reference>

      &rfc1034;
      &rfc1035;
      &rfc2782;
      &rfc4033;
      &rfc4422;
      &rfc4949;
      &rfc5280;
      &rfc5785;
      &rfc6120;
      &rfc6125;
      &rfc6698;
      &rfc7218;

<!-- draft-ietf-dane-srv (published; RFC 7673) -->
      &rfc7673;

<reference anchor="XEP-0220" target="http://xmpp.org/extensions/xep-0220.html">
  <front>
    <title>Server Dialback</title>
    <author initials="J." surname="Miller" fullname="Jeremie Miller">
      <organization/>
    </author>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization/>
    </author>
    <author initials="P." surname="Hancke" fullname="Philipp Hancke">
      <organization/>
    </author>
    <date month="August" year="2014"/>
  </front>
  <seriesInfo name="XSF XEP" value="0220"/>
</reference>

    </references>

    <references title="Informative References">
      &rfc2142;
      &rfc3920;
      &rfc4120;
      &rfc6066;
      &rfc6091;
      &rfc6749;
      &rfc7590;

<reference anchor="XEP-0045" target="http://xmpp.org/extensions/xep-0045.html">
  <front>
    <title>Multi-User Chat</title>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization/>
    </author>
    <date month="February" year="2012"/>
  </front>
  <seriesInfo name="XSF XEP" value="0045"/>
</reference>

<reference anchor="XEP-0288" target="http://xmpp.org/extensions/xep-0288.html">
  <front>
    <title>Bidirectional Server-to-Server Connections</title>
    <author initials="P." surname="Hancke" fullname="Philipp Hancke">
      <organization/>
    </author>
    <author initials="D." surname="Cridland" fullname="Dave Cridland">
      <organization/>
    </author>
    <date month="September" year="2013"/>
  </front>
  <seriesInfo name="XSF XEP" value="0288"/>
</reference>

<reference anchor="XEP-0344" target="http://xmpp.org/extensions/xep-0344.html">
  <front>
    <title>Impact of TLS and DNSSEC on Dialback</title>
    <author initials="P." surname="Hancke" fullname="Philipp Hancke">
      <organization/>
    </author>
    <author initials="D." surname="Cridland" fullname="Dave Cridland">
      <organization/>
    </author>
    <date month="March" year="2015"/>
  </front>
  <seriesInfo name="XSF XEP" value="0344"/>
</reference>

    </references>

    <section title="Acknowledgements" anchor="acks" numbered="no">
      <t>Richard Barnes, Stephen Farrell, and Jonas Lindberg contributed as
      co-authors to earlier draft versions of this document.</t>

      <t>Derek Atkins, Mahesh Jethanandani, and Dan Romascanu reviewed the
      document on behalf of the Security Directorate, the Operations and
      Management Directorate, and the General Area Review Team,
      respectively.</t>

      <t>During IESG review, Stephen Farrell and Barry Leiba provided helpful
      input that led to improvements in the specification.</t>

      <t>Thanks to Dave Cridland as document shepherd, Joe Hildebrand as
      working group chair, and Ben Campbell as area director.</t>

      <t>Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
      employing him during his work on earlier draft versions of this
      document.</t>

    </section>

  </back>

</rfc>