moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

0.13rc5

Browse Source
This commit is contained in:
Peter Saint-Andre 2012-08-08 11:49:03 -06:00
parent 13c0f4d6ea
commit a6d2b3aee3
1 changed files with 24 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
xep-0220.xml
View File

@ -29,9 +29,9 @@
<jid>fippo@psyced.org</jid>
</author>
<revision>
<version>0.13rc4</version>
<version>0.13rc5</version>
<initials>ph/psa</initials>
<date>2012-07-26</date>
<date>2012-08-12</date>
<remark>
<ul>
<li>Allowed same SRV target in multiplexing business</li>
@ -166,8 +166,8 @@
<section2 topic="What Dialback Accomplishes" anchor="intro-what">
<p>Server Dialback is a method for identity verification: if the dialback negotiation succeeds, the receiving server for an XML stream can associate a pair of domain names with the stream; those two domain names are the sender domain asserted by the initiating server and the domain name at the receiving server that the initiating server has indicated it wishes to communicate with.</p>
<p>The verification accomplished in Server Dialback depends on the Domain Name System (DNS) and the use of keys based on a shared secret known to all XMPP servers within a given administrative domain. It is a proof-of-possession protocol in the sense of &rfc4949; which asserts that the initiating server and the authoritative server are associated with each other. The relative strength or weakness of the verification depends in part on the strength or weakness of the process for resolving the domain names of the authoritative server; in particular, if DNSSEC is not used then Server Dialback results in weak identity verification, whereas if DNSSEC is used then Server Dialback can result in fairly strong identity verification.</p>
<p>Since October 2000, the use of Server Dialback (even absent DNSSEC) has made it difficult to spoof the hostnames of servers (and therefore the addresses of sent messages) on the XMPP network.</p>
<p>Server Dialback is unidirectional, and results in weak verification for one XML stream in one direction. Because traditionally Server-to-Server connections are used unidirectionally, Server Dialback needs to be completed in each direction in order to enable bidirectional communication between two domains (unless &xep0288; is used).</p>
<p>Since October 2000, the use of Server Dialback (even absent DNSSEC) has made it more difficult to spoof the hostnames of servers (and therefore the addresses of sent messages) on the XMPP network.</p>
<p>Server Dialback is unidirectional, and results in verification for one XML stream in one direction. Because traditionally Server-to-Server connections are used unidirectionally, Server Dialback needs to be completed in each direction in order to enable bidirectional communication between two domains (unless &xep0288; is used).</p>
</section2>
<section2 topic="Terminology" anchor="intro-terms">
@ -183,7 +183,7 @@
</section2>
<section2 topic="How Dialback Works" anchor="intro-howitworks">
<p>Server Dialback is used when a stanza is to be sent from a Sender Domain must be routed to a Target Domain and there is not yet an established connection between the domains. The basic flow of events in Server Dialback consists of the following four steps:</p>
<p>Server Dialback is used when a stanza that is to be sent from a Sender Domain must be routed to a Target Domain and there is not yet an established connection between the domains. The basic flow of events in Server Dialback consists of the following four steps:</p>
<ol start='1'>
<li><p>The Initiating Server generates a dialback key and sends that value over its XML stream with the Receiving Server. (If the Initiating Server does not yet have an XML stream to the Receiving Server, it will first need to perform a DNS lookup on the Target Domain and thus discover the Receiving Server, open a TCP connection to the discovered IP address and port, and establish an XML stream with the Receiving Server.)</p></li>
<li><p>Instead of immediately accepting XML stanzas on the connection from the Initiating Server, the Receiving Server sends the same dialback key over its XML stream with the Authoritative Server for verification. (If the Receiving Server does not yet have an XML stream to the Authoritative Server, it will first need to perform a DNS lookup on the Sender Domain and thus discover the Authoritative Server, open a TCP connection to the discovered IP address and port, and establish an XML stream with the Authoritative Server).</p></li>
@ -244,9 +244,9 @@ Initiating Receiving
<li><p>To understand the overall protocol flow of each dialback negotiation, read Section 2.1.1 and Section 2.2.1 (aspects of the dialback negotiation from capulet.lit as Initiating Server to montague.lit as Receiving Server), then Section 2.1.2 and 2.2.2 (aspects of the dialback negotiation from montague.lit as Initiating Server to capulet.lit as Receiving Server).</p></li>
<li><p>To implement the code for either an outbound connection or an inbound connection, read Section 2.1 (outbound) or Section 2.2 (outbound). Note that both parts can be implemented, tested, and used separately.</p></li>
</ol>
<p>The following figure gives an overview of where each example is embedded in the process and illustrates the changing roles of each server. FIXME: orchard.capulet.lit and home.montague.lit in headers?</p>
<p>The following figure gives an overview of where each example is embedded in the process and illustrates the changing roles of each server.</p>
<code><![CDATA[
capulet.lit montague.lit
orchard.capulet.lit home.montague.lit
(as Initiating) (as Receiving
Server) Server)
----------- ---------
@ -361,8 +361,8 @@ key = HMAC-SHA256(
= 404fe54e60d0259b2b6d9a620e72990ab3e8fe2faca420653da71eb80597e5a4
</code>
<p>Note: The Receiving Server MAY use any method to determine the validity of the dialback key and the identity of the Initiating Server. The Initiating Server MUST NOT make any assumptions about how the Receiving Server verifies the key. This includes the assumption that the key is even verified by the Receiving Server through communication with the Authoritative Server.</p>
<p>After sending the dialback key, the Initiating Server waits for the verification result from the Receiving Server. If the Initiating Server wishes to send any stanzas for this domain pair, it MUST queue them for sending after it has received authorization to send stanzas from the Receiving Server, and MUST NOT attempt to send stanzas until it has received such authorization. FIXME: change wording, allow re-verify after certain time, not too often? The Initiating Server MUST NOT attempt to re-verify the domain pair on this TCP connection.</p>
<p>Note: While waiting for the verification result, the Initiating Server SHOULD continue to send stanzas for any domain pair that has already been verified on that connection. It MAY send out additional dialback keys for different domain pairs and issue dialback verification requests as described under Section 2.1.2. To avoid denial of service attacks (&rfc4732;) or deadlock situations, the Initiating Server MAY impose a timeout on dialback operations, i.e. it should consider dialback operations to be failed when there is no response for a certain amount of time.</p>
<p>After sending the dialback key, the Initiating Server waits for the verification result from the Receiving Server. If the Initiating Server wishes to send any stanzas for this domain pair, it MUST queue them for sending after it has received authorization to send stanzas from the Receiving Server, and MUST NOT attempt to send stanzas until it has received such authorization.</p>
<p>Note: While waiting for the verification result, the Initiating Server SHOULD continue to send stanzas for any domain pair that has already been verified on that connection. It MAY send out additional dialback keys for different domain pairs and issue dialback verification requests as described under Section 2.1.2. To avoid denial of service attacks (&rfc4732;) or deadlock situations, the Initiating Server MAY impose a timeout on dialback operations, i.e. it should consider dialback operations to be failed when there is no response after a certain amount of time.</p>
<p>If the stream or the underlying TCP connection is closed by the Receiving Server while the Initiating Server is waiting for the verification result, the Initiating Server shall behave as it does when receiving a dialback error as described below.</p>
<p>After the Receiving Server has verified the request, the Initiating Server receives the verification result in the form of a &lt;db:result/&gt; element, where the 'from' attribute MUST be the Target Domain, the 'to' attribute MUST be the Sender Domain, and the 'type' attribute MUST have a value of "valid" or "invalid" (for the value of "error", see below).</p>
<p>Thus the result is either valid...</p>
@ -381,7 +381,7 @@ recv: <db:result
]]></example>
<p>Note: There are no examples for Step 2 and Step 3 in this section of the document; see the examples under Sections 2.1.2 and 2.2.2.</p>
<p>If the value of the 'type' attribute is "valid", then the connection between the domain pair is considered verified and the Initiating Server can send any outbound stanzas it has queued up for routing to the Receiving Server for the domain pair (i.e., from the Sender Domain to the Target Domain). Naturally, the Initiating Server can also enable or negotiate other stream features at this point, such as &xep0138; and &xep0198;.</p>
<p>If the value of the 'type' attribute is "invalid", then the Receiving Server is reporting that Initiating Server's identity (as valid for the Sender Domain) was verified as bogus by the Authoritative Server. In this case, the Initiating Server MUST NOT attempt to send any outbound stanzas it has queued up for routing to the Receiving Server for the domain pair but instead MUST return such stanzas to the respective senders at the Sender Domain with an &internalserver; stanza error. Since the Receiving Server will most likely close the stream and the underlying TCP connection if that occurs (see Section 2.2.1), the Initiating Server SHOULD NOT attempt to send further stanzas for other domain pairs that have already been authorized.</p>
<p>If the value of the 'type' attribute is "invalid", then the Receiving Server is reporting that Initiating Server's identity (as valid for the Sender Domain) was deemed bogus by the Authoritative Server. In this case, the Initiating Server MUST NOT attempt to send any outbound stanzas it has queued up for routing to the Receiving Server for the domain pair but instead MUST return such stanzas to the respective senders at the Sender Domain with an &internalserver; stanza error. Since the Receiving Server will most likely close the stream and the underlying TCP connection if that occurs (see Section 2.2.1), the Initiating Server SHOULD NOT attempt to send further stanzas for other domain pairs that have already been authorized.</p>
<p>If the value of the 'type' attribute is "error", this indicates a problem which is not related to the validity of the dialback key provided. The error conditions are explained in detail under <link url='#advertisement-errors'>Dialback with Error Handling</link>. Such an error is non-fatal for the XML stream, but the Initiating Server MUST return any queued stanzas to the respective senders at the Sender Domain with a &timeout; stanza error.</p>
<example caption="Initiating Server Receives Dialback Error from Receiving Server (Step 4)"><![CDATA[
recv: <db:result
@ -441,7 +441,7 @@ recv: <db:verify
]]></example>
<p>Note: If the underlying TCP connection is closed by the remote side while there are pending verification requests, those requests SHOULD be considered failed and therefore be treated like an error response.</p>
<p>After receiving the validation result from the Authoritative Server, the Receiving Server determines the inbound connection that the dialback key was originally received on. This connection is uniquely identified by the combination of the 'from', 'to', and 'id' attributes. If no inbound connection is found that matches this combination, the verification result SHOULD be dropped silently. If an inbound connection is found, the Receiving Server uses it to communicate the verification result to the Initiating Server. A positive result indicates the readiness of the Receiving Server to accept stanzas from the Initiating Server for this domain pair.</p>
<p>When receiving a verification result of type "invalid", the Receiving Server MAY choose not to relay this result to the Initiating Server. Instead, it might send a dialback error such as &lt;forbidden/&gt; to the Initiating Server. Compared to sending a result of type "invalid", this behavior will not result in the loss of the whole stream and any previously domain pairs previously negotiated, while at the same time not accepting stanzas from the spoofed domain. Even when not forwarding the "invalid" result, the incident should be logged.</p>
<p>When receiving a verification result of type "invalid", the Receiving Server MAY choose not to relay this result to the Initiating Server. Instead, it might send a dialback error such as &lt;forbidden/&gt; to the Initiating Server. Compared to sending a result of type "invalid", this behavior will not result in the loss of the whole stream and any previously domain pairs previously negotiated, while at the same time not accepting stanzas from the spoofed domain. Even when not forwarding the "invalid" result, the incident ought to be logged.</p>
</section3>
</section2>
@ -463,7 +463,7 @@ recv: <db:result
</db:result>
]]></example>
<p>This key MUST be verified before the Initiating Server is authorized to send stanzas from the Sender Domain ("capulet.lit") to the Target Domain ("montague.lit"). Note that the verification process might fail prematurely, for example, if the Receiving Server's policy states that connections from the Initiating Server or the Sender Domain are not allowed.</p>
<p>The traditional method for verifying that the Initiating Server is authorized to send stanzas from the Sender Domain is for the Receiving Server to "dial back" the Authoritative Server for the Sender Domain and ask it to validate the dialback key which is contained in the XML character data of the request. However, other methods can be used for verifying the identity of the Initiating Server. For example, if TLS is used the the Receiving Server can attempt to verify the certificate (according to the rules specified in &xep0178; and &rfc6125; and then send a dialback result without performing the actual dial-back to the Authoritative Server. This technique is sometimes called "dialback without dial-back".</p>
<p>The traditional method for verifying that the Initiating Server is authorized to send stanzas from the Sender Domain is for the Receiving Server to "dial back" the Authoritative Server for the Sender Domain and ask it to validate the dialback key which is contained in the XML character data of the request. However, other methods can be used for verifying the identity of the Initiating Server. For example, if TLS is used the the Receiving Server can attempt to verify the certificate (typically according to the rules specified in &xep0178; and &rfc6125;) and then send a dialback result without performing the actual dial-back to the Authoritative Server. This technique is sometimes called "dialback without dial-back".</p>
<p>Note: The Receiving Server MUST continue to accept and process stanzas for already verified domain pairs, and MUST continue to process both &lt;db:result/&gt; and &lt;db:verify/&gt; elements.</p>
<p>If the Target Domain as given in the 'to' attribute of the element is not a configured domain of the Receiving Server, this results in a dialback error. This error, which is explained further under <link url='#advertisement-errors'>Section 2.4.2</link>, is not a stream error and therefore MUST NOT result in closing of the stream as described in Section 4.4 of <cite>RFC 6120</cite>, since the stream might already be used to exchange XML stanzas for other domain pairs.</p>
<example caption="Receiving Server Sends Dialback Error to Initiating Server (Step 4)"><![CDATA[
@ -492,7 +492,7 @@ send: <db:result
to='capulet.lit'
type='invalid'/>
]]></example>
<p>If the type is "invalid", the Initiating Server is attempting to spoof the Sender Domain. The Receiving Server MUST NOT accept stanzas from the Initiating Server for the Sender Domain, SHOULD log the attempt, and MUST close the XML stream.</p>
<p>If the type is "invalid", the Initiating Server is attempting to spoof the Sender Domain. The Receiving Server MUST NOT accept stanzas from the Initiating Server for the Sender Domain, ought to log the attempt, and MUST close the XML stream.</p>
</section3>
<section3 topic="Authoritative Server Handles Inbound Verification Request from Receiving Server">
@ -547,7 +547,7 @@ send: <db:verify
</section2>
<section2 topic="Directionality" anchor='directionality'>
<p>The result of the protocol exchanges shown in the foregoing two sections is that the server hosting montague.lit has verified the identity of the server hosting capulet.lit and vice versa. Since XMPP Server-to-Server connections are unidirectional (unless <cite>XEP-0288</cite> is used), Dialback has been completed in each direction before XML stanzas could be exchanged over the two TCP connections between the servers.</p>
<p>The result of the protocol exchanges shown in the foregoing two sections is that the server hosting montague.lit has verified the identity of the server hosting capulet.lit and vice versa. Since XMPP Server-to-Server connections are unidirectional (unless <cite>XEP-0288</cite> is used), dialback needs to be completed in each direction before XML stanzas can be exchanged over the two TCP connections between the servers.</p>
</section2>
<section2 topic="Advertisement" anchor='advertisement'>
@ -583,7 +583,7 @@ send: <db:verify
<!-- credits: Matthias in http://mail.jabber.org/pipermail/standards/2007-June/015662.html -->
<p><cite>RFC 3920</cite> introduced stream errors for any errors related to dialback. However, this turned out to be overly aggressive, particularly if the XML stream was used to multiplex stanzas for more than one domain pair (since closing the stream would result in throwing away accumulated dialback state for a potentially large number of domain pairs). Therefore this specification introduces a third value for the 'type' attribute: "error".</p>
<p>This usage of the 'error' value for the 'type' attribute is not fully backward compatible with <cite>RFC 3920</cite>. However, the server that generates the error SHOULD still attempt to send the dialback error instead of terminating the stream, as the worst thing that can happen is that the remote server terminates the stream if it does not understand the error or if it eventually times out the connection. Dialback errors are to be considered non-fatal for the XML stream, but the Initiating Server MUST return queued stanzas to the respective senders with a &timeout; stanza error. If an error is encountered in Step 3 of the dialback negotiation, the Receiving Server MUST send a &lt;remote-server-not-found/&gt; error to the Initiating Server.</p>
<p>FIXME When the &lt;db:verify/&gt; or &lt;db:result/&gt; element is of type "error", the element MUST contain an &lt;error/&gt; element qualified by the Server Dialback namespace, which MUST in turn contain an XML element qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace (i.e., a stanza error condition), in accordance with the following table.</p>
<p>When the &lt;db:verify/&gt; or &lt;db:result/&gt; element is of type "error", the element MUST contain an &lt;error/&gt; element (implicitly qualified by the 'jabber:server' namespace), which MUST in turn contain an XML element qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace (i.e., a stanza error condition), in accordance with the following table.</p>
<table caption='Dialback error conditions'>
<tr>
<th>Condition</th>
@ -592,7 +592,7 @@ send: <db:verify
</tr>
<tr>
<td>&notfound;</td>
<td>The domain given in the 'to' attribute of the request is not hosted on the Receiving Server. The domain is used in the 'from' attribute nonetheless with the purpose of identifying the original request.</td>
<td>The domain given in the 'to' attribute of the request is not hosted on the Receiving Server. Nonetheless, the domain is used in the 'from' attribute of the error packet, for the purpose of identifying the original request.</td>
<td>Step 3 or 4</td>
</tr>
<tr>
@ -633,9 +633,15 @@ send: <db:verify
</table>
</section2>
<!--
<section2 topic="Reverification" anchor='reverify'>
<p>Server-to-server streams can exist for long periods of time. An Initiating Server MAY reverify the key periodically over the life of the stream (i.e., by sending a new &lt;db:verify/&gt; packet as in Step 3 of the dialback negotiation), but MUST NOT attempt to re-verify the domain pair on this TCP connection.</p>
-->
<section2 topic="Multiplexing" anchor='multiplex'>
<p>A single XML stream between Initiating Server and Receiving Server can be used to multiplex stanzas for more than one domain pair. We call this usage "multiplexing" (historically it has also been known as "piggybacking"). One common motivation for multiplexing is virtual hosting, under which many domains are hosted on the same server. Another common motivation for such reuse is the existence of additional services associated with the Sender Domain but hosted at "subdomains" thereof. For example, both the "montague.lit" and the "capulet.lit" XMPP servers might host &xep0045; services at "chat.montague.lit" and "rooms.capulet.lit" respectively. Without multiplexing, many server-to-server connections would be necessary to exchange stanzas between those domains. With more domains, the number of connections might exceed the maximum number of connections allowed from a single IP address as explained in &xep0205;. Multiplexing reduces the number of connections to two.</p>
<p>Note: Because dialback operates on domain pairs, a total of eight dialback negotiations is necessary for a bidirectional exchange of stanzas between two sending domains and two target domains.</p>
<section3 topic="Multiplexing Sender Domains" anchor="sendermultiplex">
<p>In order to accept XML stanzas from rooms at "rooms.capulet.lit" intended for addresses at "montague.lit", the "montague.lit" domain will need to validate the "rooms.capulet.lit" domain (just as it already did for the "capulet.lit" domain). Thus the server hosting both capulet.lit and rooms.capulet.lit would now initiate a dialback negotiation with the server hosting montague.lit but specify the Sender Domain as "rooms.capulet.lit". Specifying different Sender Domains is called "sender multiplexing" and MAY be used without further negotation.</p>
</section3>
@ -648,7 +654,7 @@ _xmpp-server._tcp.montague.lit. 86400 IN SRV 10 0 5269 home.montague.lit
_xmpp-server._tcp.chat.montague.lit. 86400 IN SRV 10 0 5269 home.montague.lit
home.montague.lit. 86400 IN A 10.44.0.4
]]></example>
<p>Because DNS SRV lookups for both "montague.lit" and "chat.montague.lit" point to the same target ("home.montague.lit") or IP address and port (5269), or in absence of SRV records they resolve to the same IP address (10.44.0.4) and port (5269), "capulet.lit" MAY initiate a dialback negotation from "capulet.lit" to "chat.montague.lit" over the same XML stream that is already used to send stanzas from "capulet.lit" to "montague.lit".</p>
<p>Because DNS SRV lookups for both "montague.lit" and "chat.montague.lit" point to the same target ("home.montague.lit") and port (5269), or eventually resolve to the same IP address (10.44.0.4) and port (5269), "capulet.lit" MAY initiate a dialback negotation from "capulet.lit" to "chat.montague.lit" over the same XML stream that is already used to send stanzas from "capulet.lit" to "montague.lit".</p>
<p>&xep0288; extends those rules since any domain that has been used as a source domain can be used as a target domain without further negotiation.</p>
</section3>
</section2>
@ -656,7 +662,7 @@ home.montague.lit. 86400 IN A 10.44.0.4
<section1 topic='Security Considerations' anchor='security'>
<p>Server Dialback helps protect against domain spoofing, thus making it more difficult to spoof XML stanzas. Absent the use of DNS security (DNSSEC, &rfc4033;), Server Dialback does not provide a mechanism for authenticating a stream, as is done via TLS and SASL, and results in weak verification of server identities only. Furthermore, if DNSSEC is not used then it is susceptible to DNS poisoning attacks.</p>
<p>If DNSSEC is used, Server Dialback provides stream authentication only (i.e., a strong association between a domain name and an XML stream). However, Server Dialback by itself does not provide confidentiality, data integrity, or stream encryption. Some existing implementations are known to support dialback over TLS. Server Dialback is typically carried out the same way as without TLS then, gaining from channel encryption.</p>
<p>If DNSSEC is used, Server Dialback provides stream authentication only (i.e., a strong association between a domain name and an XML stream). However, Server Dialback by itself does not provide confidentiality, data integrity, or stream encryption. Some existing implementations are known to support dialback over TLS. Server Dialback is typically carried out the same way as without TLS, but gains from the use of channel encryption.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>