From 5d7aac9b4183ced295a7b9fee17cca973db08b6d Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 27 Aug 2013 14:33:56 -0600 Subject: [PATCH] 0.15 --- xep-0220.xml | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/xep-0220.xml b/xep-0220.xml index 0dfedeae..5350d81f 100644 --- a/xep-0220.xml +++ b/xep-0220.xml @@ -11,7 +11,6 @@ &LEGALNOTICE; 0220 Proposed - 2013-05-10 Standards Track Standards @@ -26,9 +25,9 @@ &stpeter; &fippo; - 0.15rc1 + 0.15 psa/ph - 2012-08-26 + 2012-08-27

Addressed Last Call feedback and made editorial improvements.

 @@ -178,7 +177,7 @@

Since October 2000, the use of Server Dialback (even absent DNSSEC) has made it more difficult to spoof the hostnames of servers (and therefore the addresses of sent messages) on the XMPP network.

Server Dialback is unidirectional, and results in verification for one XML stream in one direction. Because traditionally Server-to-Server connections are used unidirectionally, Server Dialback needs to be completed in each direction in order to enable bidirectional communication between two domains (unless &xep0288; is used).

Furthermore, because a separate TCP connection is mandated for each domain pair, the use of server dialback results in significant scalability challenges for large XMPP service providers that host many domains (see &dna-framework; for a possible solution).

-

Finally, dialback signalling can be used without dialback keys if out-of-band methods are used to establish authorization. As one example, if TLS is used then the Receiving Server can attempt to verify the certificate presented by the Initiating Server, either according to the rules specified in &xep0178; and &rfc6125; or by checking that the key of the Initiating Server matches a key obtained via &posh;. This technique of using dialback signalling without dialback keys (sometimes called "dialback without dialing back") is not, however, described in this document.

+

Finally, dialback signalling can be used without basing the identity verification on checking of the dialback key provided by the Initiating Server. As one example, if Transport Layer Security (TLS) is used then the Receiving Server can attempt to verify the certificate presented by the Initiating Server, either according to the PKIX-based rules specified in &xep0178;, RFC 6120, and &rfc6125; or by checking that the public key or certificate of the Initiating Server matches a public key or certificate obtained via &posh;. However, this technique of using dialback signalling without verifying the dialback key (sometimes called "dialback without dialing back" since the Receiving Server does not contact the Authoritative Server) is not described in this document.

@@ -365,7 +364,7 @@ example example send: - 404fe54e60d0259b2b6d9a620e72990ab3e8fe2faca420653da71eb80597e5a4 + b4835385f37fe2895af6c196b59097b16862406db80559900d96bf6fa7d23df3 ]]>

The key sent is generated as described in &xep0185;:

@@ -374,7 +373,7 @@ key = HMAC-SHA256( SHA256('s3cr3tf0rd14lb4ck'), { 'montague.example', ' ', 'capulet.example', ' ', 'D60000229F' } ) - = 404fe54e60d0259b2b6d9a620e72990ab3e8fe2faca420653da71eb80597e5a4 + = b4835385f37fe2895af6c196b59097b16862406db80559900d96bf6fa7d23df3

Note: The Receiving Server MAY use any method to determine the validity of the dialback key and the identity of the Initiating Server. The Initiating Server MUST NOT make any assumptions about how the Receiving Server verifies the key, including even the assumption that the key is actively verified by the Receiving Server through communication with the Authoritative Server.

After sending the dialback key, the Initiating Server waits for the verification result from the Receiving Server. If the Initiating Server wishes to send any stanzas for this domain pair, it MUST queue them for sending after it has received authorization to send stanzas from the Receiving Server, and MUST NOT attempt to send stanzas until it has received such authorization.

@@ -421,7 +420,7 @@ send: - d4afb251ac62eb6fc778dac7ad65c43fdee29c4930ba204d479191566ea99496 + 225cc5aa6a071133249d25fef42ae516fc7a86c523aa1c6980a7f73e784c972d ]]>

After that, the Receiving Server waits for the verification result. While doing so, it can still use the connection to send dialback packets or to send stanzas for domain pairs that have already been validated.

@@ -475,7 +474,7 @@ recv: - 404fe54e60d0259b2b6d9a620e72990ab3e8fe2faca420653da71eb80597e5a4 + b4835385f37fe2895af6c196b59097b16862406db80559900d96bf6fa7d23df3 ]]>

Before the Receiving Server allows the Initiating Server to send stanzas from the Sender Domain (here "capulet.example") to the Target Domain (here "montague.example"), it MUST verify the identity of the Initiating Server. Depending on how the server dialback protocol is used, this can be done by verifying the dialback key or by using some out-of-band method as in the POSH prooftype for XMPP domain name associations. Note that the verification process might fail prematurely, for example, if the Receiving Server's policy states that connections from the Initiating Server or the Sender Domain are not allowed.

@@ -517,7 +516,7 @@ recv: - d4afb251ac62eb6fc778dac7ad65c43fdee29c4930ba204d479191566ea99496 + 225cc5aa6a071133249d25fef42ae516fc7a86c523aa1c6980a7f73e784c972d ]]>

If the Target Domain as given in the 'to' attribute of the element does not match a configured local domain according to the Authoritative Server, 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. (The following example is the same as Example 8.)

@@ -538,7 +537,7 @@ key = HMAC-SHA256( SHA256('d14lb4ck43v3r'), { 'capulet.example', ' ', 'montague.example', ' ', '417GAF25' } ) - = d4afb251ac62eb6fc778dac7ad65c43fdee29c4930ba204d479191566ea99496 + = 225cc5aa6a071133249d25fef42ae516fc7a86c523aa1c6980a7f73e784c972d

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 (this is the same as Example 6)...