From 5a9b58ee2b2bf15ed3cbb26d6ed4ce6a1940c9b6 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 22 Jun 2012 12:13:46 -0600 Subject: [PATCH] 0.13rc1 --- xep-0220.xml | 238 +++++++++++++++++++++++++++++++++++---------------- 1 file changed, 163 insertions(+), 75 deletions(-) diff --git a/xep-0220.xml b/xep-0220.xml index 534785b1..50369070 100644 --- a/xep-0220.xml +++ b/xep-0220.xml @@ -11,6 +11,7 @@ &LEGALNOTICE; 0220 Experimental + Standards Track Standards Council @@ -27,6 +28,21 @@ Hancke fippo@psyced.org + + 0.13rc1 + ph + work in progress, last updated 2012-06-22 + +
    +
  • Changed hostnames to something more memorable.
    • +
  • Added note about using certificates for "dialback-without-dial-back".
    • +
  • Added note about not forwarding invalid.
    • +
  • Added another figure for the examples, reordered examples accordingly.
    • +
  • Notes about verify-only connections.
    • +
  • Added note about bouncing stanzas with an <internal-server-error/> stanza error in section 2.1.1
    • +
+ + 0.12 2011-09-19 @@ -175,7 +191,7 @@
  • The Receiving Server informs the Originating Server whether its identity has been verified or not.

    • 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.

    -

    We can represent this flow of events graphically as follows.

    +

    We can represent the flow of events graphically as follows.

    This section describes the protocol in detail.

    Assumptions used in the examples:

      -
    • The Sender Domain is "sender.tld". A DNS lookup on this domain resolves to the machine "authority.sender.tld".
      • -
    • The Target Domain is "target.tld". A DNS lookup on this domain resolves to the machine "receiver.target.tld".
      • -
    • The stream ID of the stream from the Originating Server (some IP address) to the Receiving Server (receiver.target.tld) is "D60000229F".
      • -
    • The shared secret of the Sender Domain (sender.tld) is "s3cr3tf0rd14lb4ck".
      • +
    • The Sender Domain is "capulet.lit". A DNS lookup on this domain resolves to the machine "authority.capulet.lit".
      • +
    • The Target Domain is "montague.lit". A DNS lookup on this domain resolves to the machine "receiver.montague.lit".
      • +
    • The stream ID of the stream from the Originating Server (some IP address) to the Receiving Server (receiver.montague.lit) is "D60000229F".
      • +
    • The stream ID of the stream from the Receiving Server (receiver.montague.lit) to the Authoritative Server (authority.capulet.lit) is "417GAF25".
      • +
    • The shared secret of the Sender Domain (capulet.lit) is "s3cr3tf0rd14lb4ck".
      • +
    • The shared secret of the Target Domain (montague.lit) is "d14lb4ck43v3r".

    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. 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.

    -

    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.

    +

    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.

    + | + | | + | (stream id D60000229F) | capulet.lit + | send dialback key | (Authoritative Server) + | -------(STEP 1)--------> | ----------- + | Example 1 / 9 | | + | | [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)-------- | | + | Example 2,3,4/10,11,12 | | + | | | + | ---- stanzas from -----> | | + | capulet.lit | | + | to montague.lit | | + | (Originating Server) (Receiving Server) + | --------- ---------- + | | | + | | [may reuse connection] | + | | (stream id 417GAF25) | + | | | + | | | montague.lit + | | send dialback key | (Authoritative Server) + | | -------(STEP 1)--------> | ----------- + | | | | + | [may reuse connection] | | [may open TCP connection | + | | | and establish stream] | + | | | -------(STEP 2)---------> | + | | | Example 5 / 13 | + | | | | + | | | send verify response | + | | | <------(STEP 3)---------- | + | | | Example 6,7,8/14,15,16 | + | | | | + | | report dialback result | | + | | <------(STEP 4)--------- | | + | | | | + | | <--- stanzas from -------| | + | | montague.lit to | | + | | capulet.lit | | + ]]> @@ -234,8 +314,8 @@ Originating Receiving

    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.

    + from='capulet.lit' + to='montague.lit'> 1e701f120f66824b57303384e83b51feba858024fd2221d39f7acc52dcf767a9 ]]> @@ -243,7 +323,7 @@ send: key = HMAC-SHA256( SHA256('s3cr3tf0rd14lb4ck'), - { 'target.tld', ' ', 'sender.tld', ' ', 'D60000229F' } + { 'montague.lit', ' ', 'capulet.lit', ' ', 'D60000229F' } ) = 1e701f120f66824b57303384e83b51feba858024fd2221d39f7acc52dcf767a9     @@ -255,24 +335,25 @@ key = HMAC-SHA256(

    The result is either valid...

    ]]>

    ... or invalid ...

    ]]> -

    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.

    -

    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 RFC 6120.

    +

    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. FIXME: note about enabling session managment or doing compression!

    +

    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 but instead return them to the respective senders at the Sender Domain with a &internalserver; stanza error.

    +

    Note that, since the Receiving Server will most likely close the stream and the underlying TCP connection the Originating Server should not attempt to send further stanzas for other domain pairs who have already been authorized.

    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 Dialback with Error Handling. 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.

    @@ -283,42 +364,42 @@ 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.sender.tld").

    +

    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").

    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.

    +

    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.

    - 1e701f120f66824b57303384e83b51feba858024fd2221d39f7acc52dcf767a9 + from='capulet.lit' + id='417GAF25' + to='montague.lit'> + fed84f34d39682fd80bd04e01894f98c4149cf9df47575b134eeb6d2c7fe9fee ]]>

    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.

    Here again, the result is either valid...

    ]]>

    ... or invalid ...

    ]]>

    In addition to the values "valid" and "invalid", the 'type' attribute can also have a value of "error"; see Dialback with Error Handling for a detailed explanation.

    @@ -327,6 +408,7 @@ recv:

    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.

    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.

    +

    Note that when receiving an verification result of type 'invalid', the Receiving Server MAY choose not to relay this result to the Originating Server. Instead, it might send a dialback error such as <forbidden/> to the Originating Server. Compared to sending an result of type invalid, this behaviour 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.

    @@ -338,19 +420,19 @@ recv: 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).

    + from='capulet.lit' + to='montague.lit'> 1e701f120f66824b57303384e83b51feba858024fd2221d39f7acc52dcf767a9     ]]>     -

    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.

    -

    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.

    +

    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.

    +

    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. For example, if TLS is used the Receiving Server can attempt to validate the certificate according to the rules specified in &xep0178; and &rfc6125; and send a dialback result without performing the actual dial-back (this technique is called "dialback without dial-back" or D-W-D).

    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.

    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 Section 2.4.2, 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.

    @@ -362,37 +444,38 @@ send: Therefore, here again the result is either valid...

    ]]>

    ... or invalid ...

    ]]>

    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).

    -

    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).

    +

    This subsection describes the interaction between the Receiving Server and the Authoritative Server, from the perspective of the Authoritative Server (i.e., this section is the mirror image of Section 2.1.2).

    - 1e701f120f66824b57303384e83b51feba858024fd2221d39f7acc52dcf767a9 + from='capulet.lit' + id='417GAF25' + to='montague.lit'> + fed84f34d39682fd80bd04e01894f98c4149cf9df47575b134eeb6d2c7fe9fee ]]>

    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.

    @@ -402,26 +485,26 @@ send: 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:

    key = HMAC-SHA256( - SHA256('s3cr3tf0rd14lb4ck'), - { 'target.tld', ' ', 'sender.tld', ' ', 'D60000229F' } + SHA256('d14lb4ck43v3r'), + { 'capulet.lit', ' ', 'montague.lit', ' ', '417GAF25' } ) - = 1e701f120f66824b57303384e83b51feba858024fd2221d39f7acc52dcf767a9 + = fed84f34d39682fd80bd04e01894f98c4149cf9df47575b134eeb6d2c7fe9fee

    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".

    Therefore, here again the result is either valid...

    ]]>

    ... or invalid ...

    ]]>

    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).

    @@ -441,8 +524,8 @@ send: + from='montague.lit' + to='capulet.lit'> ]]>

    Although this method of advertising protocol support has been superseded by the use of stream features as originally defined in RFC 3920, the server dialback protocol predates the existence of stream features and therefore the namespace declaration method is still used in this instance.

     @@ -469,7 +552,7 @@ send: Condition Description - When Occurs + Occurs in ¬found; @@ -494,39 +577,44 @@ send: &policy; 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. - Step 3 + Step 3 or 4 ¬authorized; 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. Step 3 + + &forbidden; + The Receiving Server received an 'invalid' response when attempting to verify the dialback key with the Authoritative 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 "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.

    -

    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;.)

    - +

    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.

    +

    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.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.

    +

    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.

     -

    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".

    +

    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:

    - -

    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".

    +

    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".

    +

    &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 and SASL. If SASL is used for server-to-server authentication, Server Dialback SHOULD NOT be used since it is unnecessary.

    +

    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.

     @@ -553,7 +641,7 @@ receiver.target.tld. 86400 IN A 10.44.0.4 -

    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.

    +

    Thanks to Richard Barnes, 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.