One document matched: draft-ietf-xmpp-dna-10.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 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 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-uta-xmpp PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-uta-xmpp.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-10" 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 relation to such associations, 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'/>. If such delegation is not done in a secure manner, then the domain name association cannot be verified.</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 from='user@a.example' to='a.example'> |
| |
| S: <stream from='a.example' to='user@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 from='user@a.example' 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' to='user@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 trusted by 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 <xref target='I-D.ietf-uta-xmpp'/>.</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. The Server Dialback protocol is defined in <xref target='XEP-0220'/>. See <xref target='XEP-0344'/> for considerations when using it together with TLS and DNSSEC. Also, <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 chart illustrates the protocol flow for establishing domain name associations between Server A (the initiating entity) and Server B (the receiving entity), as described in the remaining sections of this document.</t>
<figure>
<artwork><![CDATA[
|
(A Simple S2S Scenario)
|
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)
|
+-------------AUTHENTICATION--------------------+
| | |
| {valid client certificate?} --+ |
| | | |
| | yes no | |
| v | |
| SASL EXTERNAL | |
| (mutual auth!) | |
| (B establishes DNA for a.example) | |
+-------------------------------------|---------+
|
+-----------------+
| 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> |
| |
+-----------------------------------------------+
|
(Section 4.3: No Mutual PKIX authentication)
|
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)
|
|
(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'/> |
| |
+-----------------------------------------------+
|
|
(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 A (a.example) and Server B (b.example):</t>
<t>
<list style='numbers'>
<t>Server A resolves via DNS the service _xmpp-server._tcp.b.example.</t>
<t>Server A opens a TCP connection to the resolved IP address.</t>
<t>
Server A sends an initial stream header to Server B, asserting that it is a.example:
<vspace blankLines='1'/>
<stream:stream from='a.example' to='b.example'>
</t>
<t>
Server B sends a response stream header to Server A, 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 B (acting as a TLS server) presents a PKIX certificate proving that it is b.example and Server A (acting as a TLS client) presents a PKIX certificate proving that it is a.example.</t>
<t>Server A checks the PKIX certificate that Server B provided and Server B checks the PKIX certificate that Server A provided; if these proofs are consistent with the XMPP profile of the matching rules from <xref target='RFC6125'/> and is 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.</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 B during TLS negotiation is trusted by Server A and matches the expected identity.</t>
<t>The PKIX certificate presented by Server A during TLS negotiation is trusted by Server B, which enables the parties to complete mutual authentication.</t>
<t>There are no additional domains associated with Server A and Server B (say, a subdomain rooms.a.example on Server A or a second domain c.example on Server B).</t>
<t>The server administrators are able to obtain PKIX certificates issued by a widely-accepted certificate 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 A is acting as a S2S client the behaviour is 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 A during TLS negotiation is not trusted by Server B, Server B is unable to mutually authenticate Server A. Therefore, Server B needs to verify the asserted identity of Server A by other means.</t>
<t>
<list style='numbers'>
<t>
Server A 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 B resolves via DNS the service _xmpp-server._tcp.a.example.</t>
<t>Server B opens a TCP connection to the resolved IP address.</t>
<t>
Server B sends an initial stream header to Server A, asserting that it is b.example:
<vspace blankLines='1'/>
<stream:stream from='b.example' to='a.example'>
</t>
<t>
Server A sends a response stream header to Server B, 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 A (acting as a TLS server) presents a PKIX certificate proving that it is a.example.</t>
<t>Server B checks the PKIX certificate that Server A provided. This might be the same certificate presented by Server A as a client certificate in the initial connection. See <xref target='XEP-0344'/> for further discussion about skipping the subsequent steps.</t>
<t>
Server B 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 A responds to this:
<vspace blankLines='1'/>
<db:verify from='a.example' to='b.example' id='...' type='valid/>
<vspace blankLines='1'/>
allowing Server B to establish the domain name association.
</t>
</list>
</t>
</section>
<section title="Piggybacking" anchor="s2s-piggybacking">
<section title="Assertion" anchor="s2s-piggybacking-assertion">
<t>Consider the common scenario in which Server B hosts not only b.example but also a second domain c.example (often called a "multi-tenanted" environment). If a user of Server B associated with c.example wishes to communicate with a 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 a new TCP connection and negotiate new XML streams for the domain pair of c.example and a.example, that too is wasteful (especially if Server B hosts a large number of domains). Server B 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, first specified in (the now obsolete) <xref target='RFC3920'/> and since moved to <xref target='XEP-0220'/>. Here, Server B 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 B'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 A needs to obtain some kind of proof that Server B really is also c.example. If the certificate presented by Server B is also valid for c.example then no further action is necessary. However, if not then Server A needs to do a bit more work. Specifically, Server A can pursue the same strategy it used before:</t>
<t>
<list style='numbers'>
<t>Server A resolves via DNS the service _xmpp-server._tcp.c.example.</t>
<t>Server A opens a TCP connection to the resolved IP address (which might be the same IP address as for b.example).</t>
<t>
Server A sends an initial stream header to Server B, asserting that it is a.example:
<vspace blankLines='1'/>
<stream:stream from='a.example' to='c.example'>
</t>
<t>
Server B sends a response stream header to Server A, 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 B (acting as a TLS server) presents a PKIX certificate proving that it is c.example.</t>
<t>
At this point, Server A 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 B responds to this:
<vspace blankLines='1'/>
<db:verify from='c.example' to='a.example' id='...' type='valid/>
<vspace blankLines='1'/>
allowing Server A to establish the domain name association.
</t>
</list>
</t>
<t>Now that Server A accepts the domain name association, it informs Server B 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 A 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 A provides XMPP services not only for a.example but also for a subdomain such as a groupchat service (e.g., Multi-User Chat <xref target='XEP-0045'/>) at rooms.a.example. If a user from c.example at Server B wishes to join a room on the groupchat sevice, Server B needs to send XMPP stanzas from the domain c.example to the domain rooms.a.example rather than a.example. First, Server B 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 B resolves vua DNS the service _xmpp-server._tcp.rooms.a.example.</t>
<t>Server B determines this resolves to an IP address and port that it is already connected to.</t>
<t>Server B determines that the PKIX certificate for that active connection would also be valid for the rooms.a.example domain and that Server A has announced support for dialback errors.</t>
</list>
</t>
<t>Server B sends a dialback key to Server A 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 A then informs Server B 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 PKI prooftype specified in <xref target='RFC6120'/>: that is, the server's proof consists of a PKIX certificate that is checked according to the XMPP profile <xref target='RFC6120'/> 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>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 can be 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 the 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 can be 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 materials are 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._tcp.json" for client-to-server connections</t>
<t>"/.well-known/posh._xmpp-server._tcp.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 signalling 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="IANA Considerations" anchor="iana">
<t>The POSH specification <xref target='I-D.ietf-xmpp-posh'/> provides guidelines for registering the well-known URIs <xref target='RFC5785'/> of protocols that make use of POSH. This specification registers two such URIs, for which the completed registration templates follow.</t>
<section title="Well-Known URI for xmpp-client Service" anchor="iana-client">
<t>This specification registers "posh._xmpp-client._tcp.json" in the Well-Known URI Registry as defined by <xref target='RFC5785'/>.</t>
<t>URI suffix: posh._xmpp-client._tcp.json</t>
<t>Change controller: IETF</t>
<t>Specification document(s): [[ this document ]]</t>
</section>
<section title="Well-Known URI for xmpp-server Service" anchor="iana-server">
<t>This specification registers "posh._xmpp-server._tcp.json" in the Well-Known URI Registry as defined by <xref target='RFC5785'/>.</t>
<t>URI suffix: posh._xmpp-server._tcp.json</t>
<t>Change controller: IETF</t>
<t>Specification document(s): [[ 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">
&I-D.ietf-dane-srv;
&I-D.ietf-xmpp-posh;
&rfc1034;
&rfc1035;
&rfc2782;
&rfc4033;
&rfc4949;
&rfc5280;
&rfc5785;
&rfc6120;
&rfc6125;
&rfc6698;
&rfc7218;
&xep0220;
</references>
<references title="Informative References">
&I-D.ietf-uta-xmpp;
&rfc2142;
&rfc3920;
&rfc4120;
&rfc6066;
&rfc6091;
&rfc6749;
&xep0045;
&xep0288;
&xep0344;
</references>
<section title="Acknowledgements" anchor="acks">
<t>Thanks to Richard Barnes, Stephen Farrell, and Jonas Lindberg for contributing to earlier versions of this document.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:21:41 |