This section describes the protocol in detail.
Assumptions used in the examples:
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.
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. To illustrate this, the examples show two dialback negotiations, one happening in each direction. The following figure gives an overview of where each example is embedded in the process.
+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. To illustrate this, the examples show two dialback negotiations, one happening in each direction. The following figure gives an overview of where each example is embedded in the process and illustrates the changing roles of each server.
| -----------
| | | |
- | [may reuse connection] | | [may open TCP connection |
- | | | and establish stream] |
- | | | -------(STEP 2)---------> |
+ | | | [may open TCP connection |
+ | [may reuse connection] | | and establish stream] |
+ | [------(STEP 2)------->] | | -------(STEP 2)---------> |
| | | Example 5 / 13 |
| | | |
| | | send verify response |
@@ -299,13 +301,12 @@ capulet.lit montague.lit
| | report dialback result | |
| | <------(STEP 4)--------- | |
| | | |
- | | <--- stanzas from -------| |
+ | | ---- stanzas from -----> | |
| | montague.lit to | |
| | capulet.lit | |
]]>
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.
The key sent is generated as described in &xep0185;:
@@ -325,7 +326,7 @@ key = HMAC-SHA256( SHA256('s3cr3tf0rd14lb4ck'), { 'montague.lit', ' ', 'capulet.lit', ' ', 'D60000229F' } ) - = 1e701f120f66824b57303384e83b51feba858024fd2221d39f7acc52dcf767a9 + = 404fe54e60d0259b2b6d9a620e72990ab3e8fe2faca420653da71eb80597e5a4Note: 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.
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.
@@ -364,7 +365,7 @@ recv:This subsection describes the interaction between the Receiving Server and the Authoritative Server, from the perspective of the Receiving Server.
-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.capulet.lit").
+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 "orchard.capulet.lit").
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.
Note: An implementation MAY open a separate connection to the Authoritative Server for the sole purpose of doing key verification. Such an implementation SHOULD close the connection immediately after receiving the verification result. Not using TLS or any other stream features may reduce the number of round trips in that case.
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.
@@ -422,7 +423,7 @@ recv:This key MUST be verified before the Originating Server is authorized to send stanzas from the Sender Domain ('capulet.lit'). 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.
@@ -456,7 +457,6 @@ send: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 RFC 6120).
-FIXME: dave wants an implementation note here?
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).
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 RFC 6120), since the stream might already be used for sending XML stanzas for other domain pairs.
@@ -488,7 +488,7 @@ key = HMAC-SHA256( SHA256('d14lb4ck43v3r'), { 'capulet.lit', ' ', 'montague.lit', ' ', '417GAF25' } ) - = fed84f34d39682fd80bd04e01894f98c4149cf9df47575b134eeb6d2c7fe9fee + = d4afb251ac62eb6fc778dac7ad65c43fdee29c4930ba204d479191566ea99496The 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".
Therefore, here again the result is either valid...
@@ -546,8 +546,8 @@ send:RFC 3920 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".
-This usage of the 'error' value for the 'type' attribute is not fully backward compatible with RFC 3920. 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.
-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.
+This usage of the 'error' value for the 'type' attribute is not fully backward compatible with RFC 3920. 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 the Originating Server MUST return queued stanzas 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.
+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:
| Condition | @@ -589,32 +589,39 @@ send:Step 4 | |
|---|---|---|
| ¬acceptable; | +The Receiving Server was unable to establish the asserted identity of the Originating Server. | +Step 4 | +
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 "montague.lit" and the "capulet.lit" XMPP servers might host &xep0045; services at "chat.montague.lit" and "chat.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.
+A single XML stream between Originating 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.
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.
-In order to accept XML stanzas from rooms at "chat.capulet.lit" intended for addresses at "montague.lit", the "montague.lit" domain will need to validate the "chat.capulet.lit" domain (just as it already did for the "capulet.lit" domain). Thus the Originating Server would now initiate a dialback negotiation with "montague.lit" but specify the Sender Domain as "chat.capulet.lit". Specifying different Sender Domains is called "SENDER PIGGYBACKING" and MAY be used without further negotation.
+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 Originating Server would now initiate a dialback negotiation with "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.
Likewise, to send stanzas to rooms at "chat.montague.lit" from addresses at "capulet.lit", the Originating Server would initiate dialback negotiation with "chat.montague.lit" on the same connection that might already be used to send stanzas from "capulet.lit" to "montague.lit", specifying the Target Domain as "chat.montague.lit". Specifying different target domains is called "TARGET PIGGYBACKING".
-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 Dialback with Error Handling. 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:
+Likewise, to send stanzas to rooms at "chat.montague.lit" from addresses at "capulet.lit", the Originating Server would initiate dialback negotiation with "chat.montague.lit" on the same connection that might already be used to send stanzas from "capulet.lit" to "montague.lit", specifying the Target Domain as "chat.montague.lit". Specifying different target domains is called "TARGET MULTIPLEXING".
+The Originating Server SHOULD NOT use Target Multiplexing unless the Receiving Server has signalled support for dialback error handling via <stream:features/> as described under Dialback with Error Handling. 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:
Because DNS lookups for both "montague.lit" and "chat.montague.lit" 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".
+Because DNS SRV lookups for both "montague.lit" and "chat.montague.lit" point to the same target ("receiver.montague.lit") and port (5269) or in absence of SRV records 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".
&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.
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 with strong identity verification.
+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. 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.
+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, as is done via TLS and SASL.
+Domains requiring more robust security SHOULD use TLS and SASL with strong identity verification.