mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-27 19:52:18 -05:00
638 lines
49 KiB
XML
638 lines
49 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Server Dialback</title>
|
|
<abstract>This specification defines the Server Dialback protocol, which is used between XMPP servers to provide identity verification. Server Dialback uses the Domain Name System (DNS) as the basis for verifying identity; the basic approach is that when a receiving server accepts a server-to-server connection from an originating server, it does not process traffic over the connection until it has verified a key with an authoritative server for the domain asserted by the originating server. Although Server Dialback does not provide strong authentication or trusted federation and although it is subject to DNS poisoning attacks, it has effectively prevented most instances of address spoofing on the XMPP network since its development in the year 2000.</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0220</number>
|
|
<status>Experimental</status>
|
|
<type>Standards Track</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>dialback</shortname>
|
|
&jer;
|
|
&stpeter;
|
|
<author>
|
|
<firstname>Philipp</firstname>
|
|
<surname>Hancke</surname>
|
|
<jid>fippo@psyced.org</jid>
|
|
</author>
|
|
<revision>
|
|
<version>0.12</version>
|
|
<date>2011-09-19</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Corrected several small errors and added sentence about the undesirability of the stream features child element, per list discussion.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.11</version>
|
|
<date>2011-07-06</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Per list discussion, reverted the stream features versioning that was added to version 0.10, thus reverting to the format used in versions 0.5 through 0.9 of the spec; corrected several errors in the examples.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.10</version>
|
|
<date>2011-05-16</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Modified stream features to incorporate versioning, thus removing the need for an <errors/> child element; clarified a few points in the text.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.9</version>
|
|
<date>2011-04-25</date>
|
|
<initials>psa</initials>
|
|
<remark><p>To reduce the possibility of confusion, harmonized the protocol sections so that they show only the first dialback negotiation from Originating Server to Receiving Server.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.8</version>
|
|
<date>2011-04-19</date>
|
|
<initials>ph/psa</initials>
|
|
<remark><p>Per list discussion, restored requirement for Receiving Server to close the stream if the dialback key is invalid, since application of dialback to multiple domain pairs will use dialback packets of type error, not type invalid.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.7</version>
|
|
<date>2011-04-14</date>
|
|
<initials>ph/psa</initials>
|
|
<remark><p>Removed stream feature for advertising mere protocol support, using it only for advertising support for enhanced error handling.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.6</version>
|
|
<date>2011-04-13</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Updated to reflect RFC 6120; mandated support for stream feature in XMPP 1.0 implementations; removed requirement for the Receiving Server to close the stream if the dialback key is invalid, since the stream might be used for multiple domain pairs.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.5</version>
|
|
<date>2010-03-18</date>
|
|
<initials>ph</initials>
|
|
<remark><p>Added policy-violation and not-authorized error conditions</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.4</version>
|
|
<date>2009-08-05</date>
|
|
<initials>ph/psa</initials>
|
|
<remark>
|
|
<ul>
|
|
<li>Changed description and order of steps.</li>
|
|
<li>Made clear that dialback consists of two mostly independent subprotocols.</li>
|
|
<li>Further piggybacking clarifications.</li>
|
|
<li>Defined extended usage of dialback errors, obsoleting stream errors.</li>
|
|
<li>Specified extended error conditions.</li>
|
|
<li>Added stream feature details for new-style error behavior.</li>
|
|
<li>Added multiplexing notes.</li>
|
|
<li>Updated schemas.</li>
|
|
</ul>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.3</version>
|
|
<date>2008-10-16</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Completed copy edit; clarified several points in the text; corrected several examples.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.2</version>
|
|
<date>2008-06-18</date>
|
|
<initials>psa</initials>
|
|
<remark>
|
|
<ul>
|
|
<li>Rewrote introduction.</li>
|
|
<li>Provided motivating text about why dialback is used.</li>
|
|
<li>Added text about different federation models.</li>
|
|
<li>More clearly described what dialback accomplishes and what it does not accomplish.</li>
|
|
<li>Added explanatory text about scenarios in which Server Dialback is used and not used.</li>
|
|
<li>Clarified basic description of how dialback works.</li>
|
|
<li>Clarified discovery of dialback support.</li>
|
|
<li>Separated sections into subsections, as has been done for the revisions to RFC 3920 and RFC 3921.</li>
|
|
<li>Described the protocol flows in much greater detail.</li>
|
|
<li>Explained and illustrated failure cases more completely.</li>
|
|
<li>Clarified reuse of negotiated connections, a.k.a. piggybacking.</li>
|
|
</ul>
|
|
</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1</version>
|
|
<date>2007-07-11</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Initial published version.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2007-06-22</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Content moved from the revisions to RFC 3920.</p></remark>
|
|
</revision>
|
|
</header>
|
|
|
|
<section1 topic="Introduction" anchor="intro">
|
|
<section2 topic="Why Dialback?" anchor="intro-why">
|
|
<p>When Jabber technologies were first developed in 1998, they were conceived of as a client-server system similar to email, wherein a client would connect to a server in order to communicate with other clients. Similarly, servers would connect with peer servers to provide inter-domain communication (often called "federation"). In a system that allows federation, it is important for a server to be able to determine the identity of a peer server; accepting a connection from any peer without determining its identity would result in the use of merely asserted identities and a completely uncontrolled approach to federation, which on the open Internet would rapidly devolve into chaos. Clearly such a state of affairs would be unsustainable for a network protocol aiming for widespread deployment.</p>
|
|
<p>Such potential chaos was the state of affairs on the Jabber network during the earliest releases of the original &jabberd; server codebase (up through the 1.0 release in May 2000). Therefore the Jabber developer community designed a protocol ("Server Dialback") for weak identity verification based on the Domain Name System (DNS), built support for that protocol into the jabberd 1.2 server (released in October 2000), and mandated support for that protocol on the emerging Jabber server network.</p>
|
|
<p>When the early Jabber protocols were formalized by the XMPP Working Group of the &IETF; in 2002-2004, support for strong identity verification was added. That support takes the form of Transport Layer Security (TLS) for encryption of server-to-server XML streams and the Simple Authentication and Security Layer (SASL) for authentication of such streams, typically using digital certificates issued by trusted root certificate authorities (CAs). However, the Server Dialback protocol is still in wide use, and probably will be for the foreseeable future given the perceived difficulty of obtaining digital certificates issued by common CAs. Therefore it is important to maintain accurate documentation of the Server Dialback protocol. Such documentation was originally provided in &rfc3920;. Although that documentation was removed from &rfc6120;, it is still provided in this specification for the sake of interoperability.</p>
|
|
</section2>
|
|
|
|
<section2 topic="What Dialback Accomplishes" anchor="intro-what">
|
|
<p>Server Dialback is a method for weak identity verification. Such verification 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.</p>
|
|
<p>Since October 2000, the use of Server Dialback has made it more difficult to spoof the hostnames of servers (and therefore the addresses of sent messages) on the XMPP network. However, Server Dialback does not provide authentication between servers and is not a security mechanism. Domains requiring high security are advised to use TLS and SASL with certificates issued by trusted roots.</p>
|
|
<p>Server Dialback is unidirectional, and results in weak identity verification for one XML stream in one direction. Because Server Dialback is not an authentication mechanism, mutual authentication is not possible via dialback. Therefore, Server Dialback needs to be completed in each direction in order to enable bidirectional communication between two domains.</p>
|
|
<p>Dialback does not verify that the IP address returned by a DNS lookup of the originating domain is the same as the source IP address of the inbound TCP connection. While this might often be true, not performing this check enables large deployments to separate inbound and outbound message routing.</p>
|
|
</section2>
|
|
|
|
<section2 topic="When Dialback Is Used" anchor="intro-when">
|
|
<p>Server Dialback is typically used in two scenarios:</p>
|
|
<ol start='1'>
|
|
<li><p>When a peer service does not support XMPP 1.0 as defined in <cite>RFC 3920</cite> or, more generally, does not offer negotiation of TLS.</p></li>
|
|
<li><p>When STARTTLS negotiation succeeds with a peer service but the peer's certificate cannot be used to establish the peer's identity.</p></li>
|
|
</ol>
|
|
<p>Both of these scenarios result in an untrusted connection. However, depending on local security policies, a server might accept such an untrusted connection if the use of Server Dialback results in weak identity verification.</p>
|
|
</section2>
|
|
|
|
<section2 topic="How Dialback Works" anchor="intro-howitworks">
|
|
<p>The basic idea behind Server Dialback is that a receiving server does not accept XMPP traffic from a sending server until it has (a) "called back" the authoritative server for the domain asserted by the sending server and (b) verified that the sending server is truly authorized to generate XMPP traffic for that domain.</p>
|
|
<p>A helpful analogy might be the following telephone scenario:</p>
|
|
<ol start='1'>
|
|
<li>A worker from your electric utility company knocks on your front door and says he needs to enter your house to check your usage meter.</li>
|
|
<li>Rather than letting him in, you ask for his employee ID number and politely close the door for a few moments.</li>
|
|
<li>You open the phone book, find the authoritative phone number for the utility company's headquarters, and call them on the phone.</li>
|
|
<li>After being transferred to the customer service department, you ask if a worker with that particular ID number is authorized to be visiting your house.</li>
|
|
<li>The company tells you that the worker is authorized, so you thank them and hang up.</li>
|
|
<li>You then reopen the front door and allow the worker to enter your house.</li>
|
|
</ol>
|
|
<p>In Server Dialback, the equivalent of the utility company worker is the ORIGINATING SERVER, i.e., the machine that wants to send a message from an entity at the SENDER DOMAIN to an entity at the TARGET DOMAIN and thus is attempting to establish a connection for the DOMAIN PAIR (combination of Sender Domain and Target Domain). The equivalent of the person at the house is the RECEIVING SERVER, i.e., the machine to which the Originating Server has opened a connection for the purpose of sending a message from the Sender Domain to the Target Domain (and thus the machine that is trying to verify that the Originating Server represents the Sender Domain). And the equivalent of the company headquarters is the AUTHORITATIVE SERVER, i.e., the machine that is discovered from a DNS lookup for the Sender Domain; for simple deployments this will be the Originating Server, but it could be a separate machine in the Originating Server's network (where "network" is defined by knowledge of a shared secret for verification of dialback keys).</p>
|
|
<p>The basic flow of events in Server Dialback consists of the following four steps:</p>
|
|
<ol start='1'>
|
|
<li>The Originating Server generates a dialback key and sends that value over its XML stream with the Receiving Server. (If the Originating 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.)</li>
|
|
<li>Instead of immediately accepting XML stanzas on the connection from the Originating 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).</li>
|
|
<li>The Authoritative Server informs the Receiving Server whether the key is valid or invalid.</li>
|
|
<li>The Receiving Server informs the Originating Server whether its identity has been verified or not.</li>
|
|
</ol>
|
|
<p>After Step 4, the Originating Server is authorized to send stanzas from the Sender Domain to the Target Domain as communicated in the 'to' and 'from' attributes of the dialback negotiation. In addition to a weak identity verification of the Sender Domain, this also ensures that the Receiving Server is accepting stanzas for the Target Domain.</p>
|
|
<p>We can represent this flow of events graphically as follows.</p>
|
|
|
|
<code><![CDATA[
|
|
Originating Receiving
|
|
Server Server
|
|
----------- ---------
|
|
| |
|
|
| [if necessary, |
|
|
| perform DNS lookup |
|
|
| on Target Domain, |
|
|
| open TCP connection, |
|
|
| and establish stream] |
|
|
| -----------------------> |
|
|
| | Authoritative
|
|
| send dialback key | Server
|
|
| -------(STEP 1)--------> | -------------
|
|
| | |
|
|
| | [if necessary, |
|
|
| | perform DNS lookup, |
|
|
| | on Sender Domain, |
|
|
| | open TCP connection, |
|
|
| | and establish stream] |
|
|
| | -----------------------> |
|
|
| | |
|
|
| | send verify request |
|
|
| | -------(STEP 2)--------> |
|
|
| | |
|
|
| | send verify response |
|
|
| | <------(STEP 3)--------- |
|
|
| |
|
|
| report dialback result |
|
|
| <-------(STEP 4)-------- |
|
|
| |
|
|
]]></code>
|
|
</section2>
|
|
</section1>
|
|
|
|
<section1 topic="Protocol" anchor="protocol">
|
|
<p>This section describes the protocol in detail.</p>
|
|
<p>Assumptions used in the examples:</p>
|
|
<ul>
|
|
<li>The Sender Domain is "sender.tld". A DNS lookup on this domain resolves to the machine "authority.sender.tld".</li>
|
|
<li>The Target Domain is "target.tld". A DNS lookup on this domain resolves to the machine "receiver.target.tld".</li>
|
|
<li>The stream ID of the stream from the Originating Server (some IP address) to the Receiving Server (receiver.target.tld) is "D60000229F".</li>
|
|
<li>The shared secret of the Sender Domain (sender.tld) is "s3cr3tf0rd14lb4ck".</li>
|
|
</ul>
|
|
<p>Note: All XML elements qualified by the Server Dialback namespace MUST be prefixed with the namespace prefix for the 'jabber:server:dialback' namespace as advertised on the stream header originally sent by the entity sending the element. <note>RFC 3920 stipulated that "an implementation SHOULD generate only the 'db:' prefix for such elements and MAY accept only the 'db:' prefix." This restriction was included for the sake of backward compatibility with the jabberd 1.x codebase and is no longer necessary.</note></p>
|
|
<p>Section 2.1 describes the protocol from the perspective of an active, outbound connection. Section 2.2 describes the protocol from the perspective of an inbound connection. Note that both parts can be implemented, tested, and used separately.</p>
|
|
|
|
<section2 topic="Outbound Connection">
|
|
|
|
<p>On an outbound connection there are two different tasks that the sending server can perform. The first task is to request authorization to send stanzas from the Sender Domain to the Target Domain, which is described under Section 2.1.1. The second task is to respond to requests on the validity of a given dialback key as described under Section 2.1.2.</p>
|
|
|
|
<section3 topic="Originating Server Generates Outbound Request for Authorization by Receiving Server">
|
|
<p>This subsection describes the interaction between the Originating Server and the Receiving Server, from the perspective of the Originating Server.</p>
|
|
<p>When the Originating Server has stanzas to send from the Sender Domain to the Target Domain, does not have a verified connection, or is currently attempting to get a verified connection for this domain pair, it sends a new dialback key to the Receiving Server.</p>
|
|
<p>This is done by creating a <db:result/> element whose XML character data is the dialback key; the element MUST possess a 'from' attribute whose value is the Sender Domain and MUST possess a 'to' attribute whose value is the Target Domain.</p>
|
|
<example caption="Originating Server Sends Dialback Key (Step 1)"><![CDATA[
|
|
send: <db:result
|
|
from='sender.tld'
|
|
to='target.tld'>
|
|
1e701f120f66824b57303384e83b51feba858024fd2221d39f7acc52dcf767a9
|
|
</db:result>
|
|
]]></example>
|
|
<p>The key sent is generated as described in &xep0185;:</p>
|
|
<code>
|
|
key = HMAC-SHA256(
|
|
SHA256('s3cr3tf0rd14lb4ck'),
|
|
{ 'target.tld', ' ', 'sender.tld', ' ', 'D60000229F' }
|
|
)
|
|
= 1e701f120f66824b57303384e83b51feba858024fd2221d39f7acc52dcf767a9
|
|
</code>
|
|
<p>Note: The Receiving Server MAY use any method to determine the validity of the dialback key and the identity of the Originating Sever. The Originating Server MUST NOT make any assumptions about how the Receiving Server verifies the key. This includes the assumption that the key is ever verified by the Receiving Server.</p>
|
|
<p>After that, the Originating Server waits for the verification result. If the Originating 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. The Originating Server MUST NOT attempt to re-verify the domain pair on this TCP connection.</p>
|
|
<p>Note: While waiting for the verification result, the Originating 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;), the Originating Server MAY impose a timeout on key verification.</p>
|
|
<p>If the stream or the underlying TCP connection is closed by the remote side while waiting for the verification result, this is to be handled similar to receiving an error as described below.</p>
|
|
<p>After the Receiving Server has verified the request, the Originating Server receives the verification result.</p>
|
|
<p>The result is either valid...</p>
|
|
<example caption="Originating Server Receives Valid Verification Result from Receiving Server (Step 4)"><![CDATA[
|
|
recv: <db:result
|
|
from='target.tld'
|
|
to='sender.tld'
|
|
type='valid'/>
|
|
]]></example>
|
|
<p>... or invalid ...</p>
|
|
<example caption="Originating Server Receives Invalid Verification Result from Receiving Server (Step 4)"><![CDATA[
|
|
recv: <db:result
|
|
from='target.tld'
|
|
to='sender.tld'
|
|
type='invalid'/>
|
|
]]></example>
|
|
<p>If the value of the 'type' attribute is "valid", then the connection between the domain pair is considered verified and the Originating Server can send any outbound stanzas it has queued up for routing to the Receiving Server for the domain pair.</p>
|
|
<p>If the value of the 'type' attribute is "invalid", then the Receiving Server is reporting that Originating Server's identity (as valid for the Sender Domain) could not be verified by the Authoritative Server. In this case, the Originating Server MUST NOT attempt to send any outbound stanzas it has queued up for routing to the Receiving Server for the domain pair. In addition, the Receiving Server MUST close the stream as described in Section 4.4 of <cite>RFC 6120</cite>.</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 to be considered non-fatal for the XML stream, but the Originating Server MUST return any queued stanzas to the respective senders at the Sender Domain with a &timeout; stanza error.</p>
|
|
<example caption="Originating Server Receives Dialback Error from Receiving Server (Step 4)"><![CDATA[
|
|
recv: <db:result
|
|
from='target.tld'
|
|
to='sender.tld'
|
|
type='error'>
|
|
<error type='cancel'>
|
|
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
|
</error>
|
|
</db:result>
|
|
]]></example>
|
|
</section3>
|
|
|
|
<section3 topic="Receiving Server Generates Outbound Request for Verification of Originating Server by Authoritative Server">
|
|
<p>This subsection describes the interaction between the Receiving Server and the Authoritative Server, from the perspective of the Receiving Server.</p>
|
|
<p>To determine the validity of a dialback key received from the Originating Server, the Receiving Server needs to establish communications with the Authoritative Server. To do so, either it can reuse an existing XML stream or it needs to establish a new connection. To establish a new connection, the Receiving Server performs a DNS lookup on the Sender Domain, thus finding the IP address and port for server-to-server communication at an authoritative machine for the Sender Domain asserted by the Originating Server (here the machine is "authority.sender.tld").</p>
|
|
<p>After the XML stream is established from the Receiving Server to the Authoritative Server, the Receiving Server sends a verification request. This is done by creating a <db:verify/> element whose XML character data is the dialback key received from the Originating Server; the element MUST possess a 'from' attribute whose value is the Target Domain, MUST possess a 'to' attribute whose value is the Sender Domain as provided in the 'from' attribute of Step 1, and MUST possess an 'id' attribute whose value is the stream identifier of the Receiving Server's response stream header to the Originating Server. The combination of 'from', 'to', and 'id' attributes makes it possible for the Receiving Server to uniquely identify the TCP connection on which it received the original request in Step 1.</p>
|
|
<p>Note: An implementation MAY open a separate connection to the Authoritative Server for the sole purpose of doing key verification.</p>
|
|
<example caption="Receiving Server Sends Verification Request to Authoritative Server (Step 2)"><![CDATA[
|
|
send: <db:verify
|
|
from='target.tld'
|
|
id='D60000229F'
|
|
to='sender.tld'>
|
|
1e701f120f66824b57303384e83b51feba858024fd2221d39f7acc52dcf767a9
|
|
</db:verify>
|
|
]]></example>
|
|
<p>After that, the Receiving Server waits for the verification result. While doing so, it can still use the connection to send any dialback packets or stanzas for domain pairs that have already been validated.</p>
|
|
<p>Here again, the result is either valid...</p>
|
|
<example caption="Receiving Server is Informed by Authoritative Server that Key is Valid (Step 3)"><![CDATA[
|
|
recv: <db:verify
|
|
from='sender.tld'
|
|
id='D60000229F'
|
|
to='target.tld'
|
|
type='valid'>
|
|
</db:verify>
|
|
]]></example>
|
|
<p>... or invalid ...</p>
|
|
<example caption="Receiving Server is Informed by Authoritative Server that Key is Invalid (Step 3)"><![CDATA[
|
|
recv: <db:verify
|
|
from='sender.tld'
|
|
id='D60000229F'
|
|
to='target.tld'
|
|
type='invalid'>
|
|
</db:verify>
|
|
]]></example>
|
|
<p>In addition to the values "valid" and "invalid", the 'type' attribute can also have a value of "error"; see <link url='#advertisement-errors'>Dialback with Error Handling</link> for a detailed explanation.</p>
|
|
<example caption="Receiving Server Receives Dialback Error from Authoritative Server (Step 3)"><![CDATA[
|
|
recv: <db:verify
|
|
from='sender.tld'
|
|
id='D60000229F'
|
|
to='target.tld'
|
|
type='error'>
|
|
<error type='cancel'>
|
|
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
|
</error>
|
|
</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 MAY be dropped silently. If an inbound connection is found, the Receiving Server uses it to communicate the verification result to the Originating Server. A positive result indicates the readiness of the Receiving Server to accept stanzas from the Originating Server for this domain pair.</p>
|
|
</section3>
|
|
</section2>
|
|
|
|
<section2 topic="Inbound Connection">
|
|
|
|
<p>There are two different tasks on an inbound connection. The first task is to authorize inbound connections, which is described under Section 2.2.1. The second task is to answer requests for the validity of a dialback key, which is described under Section 2.2.2.</p>
|
|
|
|
<section3 topic="Receiving Server Handles Inbound Authorization Request from Originating Server">
|
|
<p>This subsection describes the interaction between the Originating Server and the Receiving Server, from the perspective of the Receiving Server (i.e., this section is the mirror image of Section 2.1.1).</p>
|
|
<example caption="Receiving Server Receives Dialback Key from Originating Server (Step 1)"><![CDATA[
|
|
recv: <db:result
|
|
from='sender.tld'
|
|
to='target.tld'>
|
|
1e701f120f66824b57303384e83b51feba858024fd2221d39f7acc52dcf767a9
|
|
</db:result>
|
|
]]></example>
|
|
<p>This key MUST be verified before the Originating Server is authorized to send stanzas from the Sender Domain ('sender.tld'). The verification process might fail prematurely, for example, if the Receiving Server's policy states that connections from the Originating Server or the Sender Domain are not allowed.</p>
|
|
<p>The usual method for verifying that the Originating Server is authorized to send stanzas for the Sender Domain is 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. Other methods can be used for verifying the identity of the Originating Server, but are out of scope for this document.</p>
|
|
<p>Note: The Receiving Server MUST continue to accept and process stanzas for already verified domain pairs, and MUST continue to process both <db:result/> and <db:verify/> 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 for sending XML stanzas for other domain pairs.</p>
|
|
<example caption="Receiving Server Sends Dialback Error to Originating Server (Step 4)"><![CDATA[
|
|
send: <db:result
|
|
from='target.tld'
|
|
to='sender.tld'
|
|
type='error'>
|
|
<error type='cancel'>
|
|
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
|
</error>
|
|
</db:result>
|
|
]]></example>
|
|
<p>After the validity of the key has been established (for example, by the Authoritative Server), the domain pair is to be considered as verified and the Receiving Server MUST accept stanzas from the Originating Server for the verified domain pair.</p>
|
|
<p>In addition, the Originating Server is notified of the result. This is done by creating a <db:result/> element which MUST possess a 'from' attribute whose value is the Target Domain, MUST possess a 'to' attribute whose value is the Sender Domain, and MUST possess a 'type' attribute whose value is either "valid" or "invalid".</p>
|
|
<p>Therefore, here again the result is either valid...</p>
|
|
<example caption="Receiving Server Sends Valid Verification Result to Originating Server (Step 4)"><![CDATA[
|
|
send: <db:result
|
|
from='target.tld'
|
|
to='sender.tld'
|
|
type='valid'/>
|
|
]]></example>
|
|
<p>... or invalid ...</p>
|
|
<example caption="Receiving Server Sends Invalid Verification Result to Originating Server (Step 4)"><![CDATA[
|
|
send: <db:result
|
|
from='target.tld'
|
|
to='sender.tld'
|
|
type='invalid'/>
|
|
]]></example>
|
|
<p>If the type is 'invalid', the Originating Server is attempting to spoof the Sender Domain. The Receiving Server MUST NOT accept stanzas from the Originating Server for the Sender Domain, SHOULD log the attempt, and MUST close the XML stream (as described in Section 4.4 of <cite>RFC 6120</cite>).</p>
|
|
<p>As mentioned, Server Dialback results in weak identity verification of the Sender Domain by the Target Domain. In order to proceed with bidirectional communication so that the Target Domain can send XML stanzas to the Sender Domain, the Receiving Server needs to initiate a dialback negotiation with the Originating Server (i.e., assume the role of an originating server in a new dialback negotiation on a new TCP connection).</p>
|
|
</section3>
|
|
|
|
<section3 topic="Authoritative Server Handles Inbound Verification Request from Receiving Server">
|
|
<p>This subsection describes the interaction between the Receiving Server and the Authoritative Server, from the perspective of the Authoritative Serve (i.e., this section is the mirror image of Section 2.1.2).</p>
|
|
<example caption="Authoritative Server Receives Verification Request from Receiving Server (Step 2)"><![CDATA[
|
|
recv: <db:verify
|
|
from='target.tld'
|
|
id='D60000229F'
|
|
to='sender.tld'>
|
|
1e701f120f66824b57303384e83b51feba858024fd2221d39f7acc52dcf767a9
|
|
</db:verify>
|
|
]]></example>
|
|
<p>If the Target Domain as given in the 'to' attribute of the element does not match a configured local domain, this results in a dialback error. This error, which is explained further under Section 2.4, 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 for sending XML stanzas for other domain pairs.</p>
|
|
<example caption="Authoritative Server Sends Dialback Error to Receiving Server (Step 3)"><![CDATA[
|
|
send: <db:verify
|
|
from='sender.tld'
|
|
id='D60000229F'
|
|
to='target.tld'
|
|
type='error'>
|
|
<error type='cancel'>
|
|
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
|
</error>
|
|
</db:verify>
|
|
]]></example>
|
|
<p>Upon receiving this <db:verify/> element, the Authoritative Server determines the validity of the dialback key provided in the XML character data of the element. This can be achieved for example by comparing the character data with the output of applying the same key generation mechanism that was (presumably) used for the generation of the key, using as input the values of the 'from', 'to', and 'id' attributes contained in the verification request and the secret known only to the Sender Domain:</p>
|
|
<code>
|
|
key = HMAC-SHA256(
|
|
SHA256('s3cr3tf0rd14lb4ck'),
|
|
{ 'target.tld', ' ', 'sender.tld', ' ', 'D60000229F' }
|
|
)
|
|
= 1e701f120f66824b57303384e83b51feba858024fd2221d39f7acc52dcf767a9
|
|
</code>
|
|
<p>The Authoritative Server then notifies the Receiving Server whether the key is valid. This is done by creating a <db:verify/> element which MUST possess 'from' and 'to' attributes whose values are swapped from the request, MUST possess an 'id' attribute whose value is copied from the 'id' value of the request, and MUST possess a 'type' attribute whose value is either "valid" or "invalid".</p>
|
|
<p>Therefore, here again the result is either valid...</p>
|
|
<example caption="Authoritative Server Informs Receiving Server that Key is Valid (Step 3)"><![CDATA[
|
|
send: <db:verify
|
|
from='sender.tld'
|
|
id='D60000229F'
|
|
to='target.tld'
|
|
type='valid'/>
|
|
]]></example>
|
|
<p>... or invalid ...</p>
|
|
<example caption="Authoritative Server Informs Receiving Server that Key is Invalid (Step 3)"><![CDATA[
|
|
send: <db:verify
|
|
from='sender.tld'
|
|
id='D60000229F'
|
|
to='target.tld'
|
|
type='invalid'/>
|
|
]]></example>
|
|
<p>There are several reasons why the key might be invalid (e.g., the Authoritative Server has a different secret key or the Authoritative Server doesn't know anything about the StreamID communicated in the <db:result/> element it received from the Receiving Server).</p>
|
|
</section3>
|
|
</section2>
|
|
|
|
<section2 topic="Directionality" anchor='directionality'>
|
|
<p>The result of the protocol exchanges shown in the foregoing two sections is that the Receiving Server has verified the identity of the Originating Server, so that the Originating Server can send, and the Receiving Server can accept, XML stanzas over the "initial stream" (i.e., the stream from the Originating Server to the Receiving Server). In order to verify the identities of the entities using the "response stream" (i.e., the stream from the Receiving Server to the Originating Server), dialback MUST be completed in the opposite direction as well (i.e., with a reversal of roles so that the Receiving Server is now acting as an originating server and the Originating Server is now acting as a receiving server).</p>
|
|
</section2>
|
|
|
|
<section2 topic="Advertisement" anchor='advertisement'>
|
|
|
|
<section3 topic="Traditional Dialback" anchor='advertisement-traditional'>
|
|
<p>Support for the traditional server dialback protocol (originally specified in <cite>RFC 3920</cite>) is indicated by inclusion of the dialback namespace declaration in the stream header.</p>
|
|
<example caption="Stream Header"><![CDATA[
|
|
<stream:stream
|
|
xmlns='jabber:server'
|
|
xmlns:db='jabber:server:dialback'
|
|
xmlns:stream='http://etherx.jabber.org/streams'
|
|
from='target.tld'
|
|
to='sender.tld'>
|
|
]]></example>
|
|
<p>Although this method of advertising protocol support has been superseded by the use of stream features as originally defined in <cite>RFC 3920</cite>, the server dialback protocol predates the existence of stream features and therefore the namespace declaration method is still used in this instance.</p>
|
|
</section3>
|
|
|
|
<section3 topic="Dialback with Error Handling" anchor='advertisement-errors'>
|
|
<p>If a server supports graceful handling of dialback errors as described under Section 2.4, it MUST advertise that via a stream feature which is a <dialback/> element qualified by the 'urn:xmpp:features:dialback' namespace, including an empty <errors/> element.</p>
|
|
<example caption="Stream Features With <errors/> Element"><![CDATA[
|
|
<stream:features>
|
|
<dialback xmlns='urn:xmpp:features:dialback'>
|
|
<errors/>
|
|
</dialback>
|
|
</stream:features>
|
|
]]></example>
|
|
<p>Note: As a general rule, stream feature elements containing child elements that advertise particular sub-features are not encouraged. The format shown above is used for the sake of backward compatiblity with existing implementations and deployments.</p>
|
|
</section3>
|
|
</section2>
|
|
|
|
<section2 topic="Dialback Error Conditions" anchor='errors'>
|
|
<!-- 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 from 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, with the value "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. Furthermore, a server SHOULD send these errors only to XMPP 1.0 peers that advertise support for dialback errors as described under Section 2.3.2. Dialback errors are to be considered non-fatal for the XML stream, but queued stanzas MUST be returned to the respective senders with a &timeout; stanza error. If an error is encountered in Step 3, the Receiving Server MUST send a <remote-server-not-found/> error to the Originating Server.</p>
|
|
<p>When the <db:verify/> or <db:result/> element is of type "error", the element MUST contain an <error/> element, which is similar to a "stanza error" as specified in &xmppcore;. This specification re-uses the following stanza error conditions.</p>
|
|
<table caption='Dialback error conditions'>
|
|
<tr>
|
|
<th>Condition</th>
|
|
<th>Description</th>
|
|
<th>When Occurs</th>
|
|
</tr>
|
|
<tr>
|
|
<td>¬found;</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>Step 3 or 4</td>
|
|
</tr>
|
|
<tr>
|
|
<td>&remoteconnection;</td>
|
|
<td>The Receiving Server was unable to establish a connection to the Authoritative Server and therefore could not validate the identity of the Originating Server.</td>
|
|
<td>Step 4</td>
|
|
</tr>
|
|
<tr>
|
|
<td>&remoteserver;</td>
|
|
<td>The Receiving Server encountered an ¬found; error condition or a <host-unknown/> stream error when attempting to contact the Authoritative Server.</td>
|
|
<td>Step 4</td>
|
|
</tr>
|
|
<tr>
|
|
<td>&timeout;</td>
|
|
<td>The Receiving Server encountered a problem with the connection to the Authoritative Server, for example if the Authoritative Server unexpectedly closed the stream without verifying the dialback key.</td>
|
|
<td>Step 4</td>
|
|
</tr>
|
|
<tr>
|
|
<td>&policy;</td>
|
|
<td>The Receiving Server enforces a policy which mandates usage of TLS before dialback and the Originating Server did send the dialback request without using TLS.</td>
|
|
<td>Step 3</td>
|
|
</tr>
|
|
<tr>
|
|
<td>¬authorized;</td>
|
|
<td>The Receiving Server enforces a policy which requires a valid x509 certificate containing the identity of the Sender Domain for dialback requests and the Originating Server did not provide a certificate with an identity that matches the Sender Domain.</td>
|
|
<td>Step 3</td>
|
|
</tr>
|
|
</table>
|
|
</section2>
|
|
|
|
<section2 topic="Multiplexing" anchor='multiplex'>
|
|
<p>A single XML stream between Originating Server and Receiving Server can be used to multiplex stanzas for more than one domain pair. This usage is for historical reasons also known as "PIGGYBACKING". One common motivation for this 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 "target.tld" and the "sender.tld" XMPP servers might host &xep0045; services at "chat.target.tld" and "chat.sender.tld" 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. (Work is ongoing to overcome this multiplication of TCP connections and dialback negotiations; see &xmppdna;.)</p>
|
|
|
|
<section3 topic="Multiplexing Sender Domains" anchor="senderpiggyback">
|
|
<p>In order to accept XML stanzas from rooms at "chat.sender.tld" intended for addresses at "target.tld", the "target.tld" domain will need to validate the "chat.sender.tld" domain (just as it already did for the "sender.tld" domain). Thus the Originating Server would now initiate a dialback negotiation with "target.tld" but specify the Sender Domain as "chat.sender.tld". Specifying different Sender Domains is called "SENDER PIGGYBACKING" and MAY be used without further negotation.</p>
|
|
</section3>
|
|
|
|
<section3 topic="Multiplexing Target Domains" anchor="targetpiggyback">
|
|
<p>Likewise, to send stanzas to rooms at "chat.target.tld" from addresses at "sender.tld", the Originating Server would initiate dialback negotiation with "chat.target.tld" on the same connection that might already be used to send stanzas from "sender.tld" to "target.tld", specifying the Target Domain as "chat.target.tld". Specifying different target domains is called "TARGET PIGGYBACKING".</p>
|
|
<p>The Originating Server SHOULD NOT use Target Piggybacking unless the Receiving Server has signalled support for dialback error handling via <stream:features/> as described under <link url='#advertisement-errors'>Dialback with Error Handling</link>. The Originating Server MAY then attempt to multiplex a Sender Domain 'B' on the stream to the Receiving Server that is already used for Sender Domain 'A' if the hostname and port resolution results in the same IP address and port combination. For example:</p>
|
|
<example caption="DNS SRV Record for the sender.tld Zone"><![CDATA[
|
|
_xmpp-server._tcp.target.tld. 86400 IN SRV 10 0 5269 receiver.target.tld
|
|
_xmpp-server._tcp.chat.target.tld. 86400 IN SRV 10 0 5269 receiver.target.tld
|
|
receiver.target.tld. 86400 IN A 10.44.0.4
|
|
]]></example>
|
|
<p>Because DNS lookups for both "target.tld" and "chat.target.tld" resolve to the same IP address (10.44.0.4) and port (5269), "sender.tld" MAY initiate a dialback negotation from "sender.tld" to "chat.target.tld" over the same XML stream that is already used to send stanzas from "sender.tld" to "target.tld".</p>
|
|
</section3>
|
|
</section2>
|
|
</section1>
|
|
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<p>Server Dialback helps protect against domain spoofing, thus making it more difficult to spoof XML stanzas. It is not a mechanism for authenticating, securing, or encrypting streams between servers as is done via SASL and TLS, and results in weak verification of server identities only. Furthermore, it is susceptible to DNS poisoning attacks unless DNSSEC (see &rfc4033;) is used. Even if the DNS information is accurate, Server Dialback cannot protect against attacks where the attacker is capable of hijacking the IP address of the remote domain. Domains requiring robust security SHOULD use TLS and SASL. If SASL is used for server-to-server authentication, Server Dialback SHOULD NOT be used since it is unnecessary.</p>
|
|
</section1>
|
|
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>This document requires no interaction with &IANA;.</p>
|
|
</section1>
|
|
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
|
|
<p>The ®ISTRAR; includes 'jabber:server:dialback' in its registry of protocol namespaces (see &NAMESPACES;).</p>
|
|
</section2>
|
|
<section2 topic='Stream Features' anchor='registrar-stream'>
|
|
<p>The XMPP Registrar shall include 'urn:xmpp:features:dialback' in its registry of stream features (see &STREAMFEATURES;).</p>
|
|
<p>The submission is as follows:</p>
|
|
<code><![CDATA[
|
|
<feature>
|
|
<ns>urn:xmpp:features:dialback</ns>
|
|
<name>dialback</name>
|
|
<element>dialback</element>
|
|
<desc>Support for Server Dialback with dialback errors</desc>
|
|
<doc>XEP-0220</doc>
|
|
</feature>
|
|
]]></code>
|
|
</section2>
|
|
</section1>
|
|
|
|
<section1 topic='Acknowledgments' anchor='ack'>
|
|
<p>Thanks to Dave Cridland, Jack Erwin, Joe Hildebrand, Justin Karneges, Nina Kirchner, Carlo von Loesch, Ralph Meijer, Chris Newton, Rob Norris, Tory Patnoe, Dave Richards, Matthew Wild, and Matthias Wimmer for their comments.</p>
|
|
</section1>
|
|
|
|
<section1 topic='XML Schema' anchor='schema'>
|
|
<section2 topic="Dialback" anchor="schema-dialback">
|
|
<p>Note Well: the 'error' value for the 'type' attribute was added since RFC 3920.</p>
|
|
<code><![CDATA[
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
|
|
|
<xs:schema
|
|
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
|
targetNamespace='jabber:server:dialback'
|
|
xmlns='jabber:server:dialback'
|
|
elementFormDefault='qualified'>
|
|
|
|
<xs:element name='result'>
|
|
<xs:complexType>
|
|
<xs:simpleContent>
|
|
<xs:extension base='xs:NMTOKEN'>
|
|
<xs:attribute name='from' type='xs:string' use='required'/>
|
|
<xs:attribute name='to' type='xs:string' use='required'/>
|
|
<xs:attribute name='type' use='optional'>
|
|
<xs:simpleType>
|
|
<xs:restriction base='xs:NCName'>
|
|
<xs:enumeration value='error'/>
|
|
<xs:enumeration value='invalid'/>
|
|
<xs:enumeration value='valid'/>
|
|
</xs:restriction>
|
|
</xs:simpleType>
|
|
</xs:attribute>
|
|
</xs:extension>
|
|
</xs:simpleContent>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
|
|
<xs:element name='verify'>
|
|
<xs:complexType>
|
|
<xs:simpleContent>
|
|
<xs:extension base='xs:NMTOKEN'>
|
|
<xs:attribute name='from' type='xs:string' use='required'/>
|
|
<xs:attribute name='id' type='xs:NMTOKEN' use='required'/>
|
|
<xs:attribute name='to' type='xs:string' use='required'/>
|
|
<xs:attribute name='type' use='optional'>
|
|
<xs:simpleType>
|
|
<xs:restriction base='xs:NCName'>
|
|
<xs:enumeration value='error'/>
|
|
<xs:enumeration value='invalid'/>
|
|
<xs:enumeration value='valid'/>
|
|
</xs:restriction>
|
|
</xs:simpleType>
|
|
</xs:attribute>
|
|
</xs:extension>
|
|
</xs:simpleContent>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
|
|
</xs:schema>
|
|
]]></code>
|
|
</section2>
|
|
<section2 topic="Stream Feature" anchor="schema-feature">
|
|
<code><![CDATA[
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
|
|
|
<xs:schema
|
|
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
|
targetNamespace='urn:xmpp:features:dialback'
|
|
xmlns='urn:xmpp:features:dialback'
|
|
elementFormDefault='qualified'>
|
|
|
|
<xs:element name='dialback'>
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element name='errors' minOccurs='0' type='empty'/>
|
|
</xs:sequence>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
|
|
</xs:schema>
|
|
]]></code>
|
|
</section2>
|
|
</section1>
|
|
</xep>
|