One document matched: draft-ietf-xmpp-dna-11.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1034 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY rfc1035 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY rfc2142 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2142.xml">
<!ENTITY rfc2782 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY rfc3920 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3920.xml">
<!ENTITY rfc4033 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY rfc4120 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4120.xml">
<!ENTITY rfc4422 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4422.xml">
<!ENTITY rfc4949 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY rfc5280 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY rfc5785 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5785.xml">
<!ENTITY rfc6066 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml">
<!ENTITY rfc6091 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6091.xml">
<!ENTITY rfc6120 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6120.xml">
<!ENTITY rfc6125 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6125.xml">
<!ENTITY rfc6698 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY rfc6749 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml">
<!ENTITY rfc7218 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7218.xml">
<!ENTITY rfc7590 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7590.xml">
<!ENTITY xep0045 PUBLIC "" "http://xmpp.org/extensions/refs/reference.XSF.XEP-0045.xml">
<!ENTITY xep0220 PUBLIC "" "http://xmpp.org/extensions/refs/reference.XSF.XEP-0220.xml">
<!ENTITY xep0288 PUBLIC "" "http://xmpp.org/extensions/refs/reference.XSF.XEP-0288.xml">
<!ENTITY xep0344 PUBLIC "" "http://xmpp.org/extensions/refs/reference.XSF.XEP-0344.xml">
<!ENTITY I-D.ietf-dane-srv PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dane-srv.xml">
<!ENTITY I-D.ietf-xmpp-posh PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-xmpp-posh.xml">
]>
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<rfc category="std" docName="draft-ietf-xmpp-dna-11" ipr="trust200902">
<front>
<title abbrev="XMPP DNA">Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>&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>USA</country>
</postal>
<email>mamille2@cisco.com</email>
</address>
</author>
<author initials="P." surname="Hancke" fullname="Philipp Hancke">
<organization>&yet</organization>
<address>
<email>fippo@andyet.com</email>
<uri>https://andyet.com/</uri>
</address>
</author>
<date/>
<area>RAI</area>
<keyword>Internet-Draft</keyword>
<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 host name (e.g., hosting.example.net), which 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 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 (DNA).</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 host name (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 host name using technologies such as DNS SRV records <xref target='RFC2782'/>. A more detailed description of the delegation problem can be found in <xref target='I-D.ietf-xmpp-posh'/>. 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='I-D.ietf-dane-srv'/>, this document uses the terms "service domain name" and "target server host name" 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, which means 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.exmaple) to a server (a.example) is as follows:</t>
<t>
<list style='numbers'>
<t>The client resolves via DNS the service _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'/>
<stream:stream to='a.example'>
</t>
<t>
The server sends a response stream header to the client, asserting that it is a.example:
<vspace blankLines='1'/>
<stream:stream from='a.example'>
</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 apply either the fallback process described in section 6.6.4 of <xref target='RFC6125'/> or prompt the user to accept an unauthenticated connection as described in Section 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 involves 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 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 DANCE 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 DANCE 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 _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'/>
<stream:stream from='a.example' to='b.example'>
</t>
<t>
Server 2 sends a response stream header to Server 1, asserting that it is b.example:
<vspace blankLines='1'/>
<stream:stream from='b.example' to='a.example'>
</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 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, which enables the parties to complete mutual authentication.</t>
<t>There are no additional domains associated with Server 1 and Server 2 (say, a subdomain 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. <!--Since Server 1 is acting as a TLS client the behavior is the same as in the C2S case described in <xref target='c2s-description'/>.--></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 it is a.example using the Server Dialback protocol:
<vspace blankLines='1'/>
<db:result from='a.example' to='b.example' id='...'>some-dialback-key</db:result>
</t>
<t>Server 2 resolves via DNS the service _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'/>
<stream:stream from='b.example' to='a.example'>
</t>
<t>
Server 1 sends a response stream header to Server 2, asserting that it is a.example:
<vspace blankLines='1'/>
<stream:stream from='a.example' to='b.example'>
</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'/>:
<vspace blankLines='1'/>
<db:verify from='b.example' to='a.example' id='...'>some-dialback-key</db:verify>
</t>
<t>
Server 1 responds to this:
<vspace blankLines='1'/>
<db:verify from='a.example' to='b.example' id='...' type='valid/>
<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-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 <db:result/> 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 element functions as Server 2's assertion that it is (also) c.example, and thus 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 _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'/>
<stream:stream from='a.example' to='c.example'>
</t>
<t>
Server 2 sends a response stream header to Server 1, asserting that it is c.example:
<vspace blankLines='1'/>
<stream:stream from='c.example' to='a.example'>
</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'/>:
<vspace blankLines='1'/>
<db:verify from='a.example' to='c.example' id='...'>some-dialback-key</db:verify>
</t>
<t>
Server 2 responds to this:
<vspace blankLines='1'/>
<db:verify from='c.example' to='a.example' id='...' type='valid/>
<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, since 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 subdomain such as a Multi-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 sevice, 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 vua DNS the service _xmpp-server._tcp.rooms.a.example.</t>
<t>Server 2 determines this resolves to an IP address and port that it is already connected to.</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 mailto: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='I-D.ietf-xmpp-posh'/>.)</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='I-D.ietf-dane-srv'/>.</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='I-D.ietf-dane-srv'/>. 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 (since 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 since 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='I-D.ietf-xmpp-posh'/>. 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 (since 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>
<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 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-tenancy has been found to be unwieldy when the provider hosts large numbers of XMPP services on behalf of multiple tenants (see <xref target='I-D.ietf-xmpp-posh'/> for a detailed description). As a result, server-to-server communications to example.com go unencrypted or the communications are TLS-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 use of SRV records with DANE <xref target='I-D.ietf-dane-srv'/> explains how to use DNSSEC for secure delegation with the DANE prooftype, and the POSH specification <xref target='I-D.ietf-xmpp-posh'/> 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 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 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'/>) is 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='I-D.ietf-dane-srv'/>, 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='I-D.ietf-xmpp-posh'/>, 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 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='I-D.ietf-dane-srv'/>, and Section 8 of <xref target='I-D.ietf-xmpp-posh'/>.</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 certification authority 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='I-D.ietf-xmpp-posh'/> establishes a registry for POSH service names to be used in well-known URIs <xref target='RFC5785'/>. This specification registers two such URIs for use in XMPP: "xmpp-client" and "xmpp-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>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-to-server stream in XMPP</t>
<t>Specification: [[ 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>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>
<t>Specification: [[ 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 PKIX prooftypes, the reader is referred to <xref target='I-D.ietf-dane-srv'/> and <xref target='I-D.ietf-xmpp-posh'/>, 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">
<reference anchor='I-D.ietf-dane-srv'>
<front>
<title>Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records</title>
<author initials='T' surname='Finch' fullname='Tony Finch'>
<organization />
</author>
<author initials='M' surname='Miller' fullname='Matthew Miller'>
<organization />
</author>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<date month='April' day='23' year='2015' />
<abstract><t>The DANE specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its TLS certificate. However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain cannot apply the rules from RFC 6698. Therefore this document provides guidelines that enable such protocols to locate and use TLSA records.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dane-srv-14' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-dane-srv-14.txt' />
</reference>
<reference anchor='I-D.ietf-xmpp-posh'>
<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='February' day='23' year='2015' />
<abstract><t>Experience has shown that it is extremely difficult to deploy proper PKIX certificates for TLS in multi-tenanted environments. As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in obvious security implications. This document defines two methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. While these methods developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-xmpp-posh-04' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-xmpp-posh-04.txt' />
</reference>
&rfc1034;
&rfc1035;
&rfc2782;
&rfc4033;
&rfc4422;
&rfc4949;
&rfc5280;
&rfc5785;
&rfc6120;
&rfc6125;
&rfc6698;
&rfc7218;
&xep0220;
</references>
<references title="Informative References">
&rfc2142;
&rfc3920;
&rfc4120;
&rfc6066;
&rfc6091;
&rfc6749;
&rfc7590;
&xep0045;
&xep0288;
&xep0344;
</references>
<section title="Acknowledgements" anchor="acks">
<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>
| PAFTECH AB 2003-2026 | 2026-04-24 01:21:59 |