moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-22 07:38:52 -05:00
Code Issues Releases Wiki Activity

0.15

Browse Source
This commit is contained in:
Peter Saint-Andre 2013-08-27 14:33:56 -06:00
parent be578b4522
commit 5d7aac9b41
1 changed files with 9 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
xep-0220.xml
View File

@ -11,7 +11,6 @@
&LEGALNOTICE; &LEGALNOTICE;
<number>0220</number> <number>0220</number>
<status>Proposed</status> <status>Proposed</status>
<interim/>
<lastcall>2013-05-10</lastcall> <lastcall>2013-05-10</lastcall>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
@ -26,9 +25,9 @@
&stpeter; &stpeter;
&fippo; &fippo;
<revision> <revision>
<version>0.15rc1</version> <version>0.15</version>
<initials>psa/ph</initials> <initials>psa/ph</initials>
<date>2012-08-26</date> <date>2012-08-27</date>
<remark><p>Addressed Last Call feedback and made editorial improvements.</p></remark> <remark><p>Addressed Last Call feedback and made editorial improvements.</p></remark>
</revision> </revision>
<revision> <revision>
@ -178,7 +177,7 @@
<p>Since October 2000, the use of Server Dialback (even absent DNSSEC) has made it more difficult to spoof the hostnames of servers (and therefore the addresses of sent messages) on the XMPP network.</p> <p>Since October 2000, the use of Server Dialback (even absent DNSSEC) has made it more difficult to spoof the hostnames of servers (and therefore the addresses of sent messages) on the XMPP network.</p>
<p>Server Dialback is unidirectional, and results in verification for one XML stream in one direction. Because traditionally Server-to-Server connections are used unidirectionally, Server Dialback needs to be completed in each direction in order to enable bidirectional communication between two domains (unless &xep0288; is used).</p> <p>Server Dialback is unidirectional, and results in verification for one XML stream in one direction. Because traditionally Server-to-Server connections are used unidirectionally, Server Dialback needs to be completed in each direction in order to enable bidirectional communication between two domains (unless &xep0288; is used).</p>
<p>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).</p> <p>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).</p>
<p>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.</p> <p>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;, <cite>RFC 6120</cite>, 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.</p>
</section2> </section2>
<section2 topic="Terminology" anchor="intro-terms"> <section2 topic="Terminology" anchor="intro-terms">
@ -365,7 +364,7 @@ example example
send: <db:result send: <db:result
from='capulet.example' from='capulet.example'
to='montague.example'> to='montague.example'>
404fe54e60d0259b2b6d9a620e72990ab3e8fe2faca420653da71eb80597e5a4 b4835385f37fe2895af6c196b59097b16862406db80559900d96bf6fa7d23df3
</db:result> </db:result>
]]></example> ]]></example>
<p>The key sent is generated as described in &xep0185;:</p> <p>The key sent is generated as described in &xep0185;:</p>
@ -374,7 +373,7 @@ key = HMAC-SHA256(
SHA256('s3cr3tf0rd14lb4ck'), SHA256('s3cr3tf0rd14lb4ck'),
{ 'montague.example', ' ', 'capulet.example', ' ', 'D60000229F' } { 'montague.example', ' ', 'capulet.example', ' ', 'D60000229F' }
) )
= 404fe54e60d0259b2b6d9a620e72990ab3e8fe2faca420653da71eb80597e5a4 = b4835385f37fe2895af6c196b59097b16862406db80559900d96bf6fa7d23df3
</code> </code>
<p>Note: The Receiving Server MAY use any method to determine the validity of the dialback key and the identity of the Initiating Server. The Initiating Server MUST NOT make any assumptions about how the Receiving Server verifies the key, including even the assumption that the key is actively verified by the Receiving Server through communication with the Authoritative Server.</p> <p>Note: The Receiving Server MAY use any method to determine the validity of the dialback key and the identity of the Initiating Server. The Initiating Server MUST NOT make any assumptions about how the Receiving Server verifies the key, including even the assumption that the key is actively verified by the Receiving Server through communication with the Authoritative Server.</p>
<p>After sending the dialback key, the Initiating Server waits for the verification result from the Receiving Server. If the Initiating Server wishes to send any stanzas for this domain pair, it MUST queue them for sending after it has received authorization to send stanzas from the Receiving Server, and MUST NOT attempt to send stanzas until it has received such authorization.</p> <p>After sending the dialback key, the Initiating Server waits for the verification result from the Receiving Server. If the Initiating Server wishes to send any stanzas for this domain pair, it MUST queue them for sending after it has received authorization to send stanzas from the Receiving Server, and MUST NOT attempt to send stanzas until it has received such authorization.</p>
@ -421,7 +420,7 @@ send: <db:verify
from='capulet.example' from='capulet.example'
id='417GAF25' id='417GAF25'
to='montague.example'> to='montague.example'>
d4afb251ac62eb6fc778dac7ad65c43fdee29c4930ba204d479191566ea99496 225cc5aa6a071133249d25fef42ae516fc7a86c523aa1c6980a7f73e784c972d
</db:verify> </db:verify>
]]></example> ]]></example>
<p>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.</p> <p>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.</p>
@ -475,7 +474,7 @@ recv: <db:verify
recv: <db:result recv: <db:result
from='capulet.example' from='capulet.example'
to='montague.example'> to='montague.example'>
404fe54e60d0259b2b6d9a620e72990ab3e8fe2faca420653da71eb80597e5a4 b4835385f37fe2895af6c196b59097b16862406db80559900d96bf6fa7d23df3
</db:result> </db:result>
]]></example> ]]></example>
<p>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.</p> <p>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.</p>
@ -517,7 +516,7 @@ recv: <db:verify
from='capulet.example' from='capulet.example'
id='417GAF25' id='417GAF25'
to='montague.example'> to='montague.example'>
d4afb251ac62eb6fc778dac7ad65c43fdee29c4930ba204d479191566ea99496 225cc5aa6a071133249d25fef42ae516fc7a86c523aa1c6980a7f73e784c972d
</db:verify> </db:verify>
]]></example> ]]></example>
<p>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 <cite>RFC 6120</cite>), since the stream might already be used for sending XML stanzas for other domain pairs. (The following example is the same as Example 8.)</p> <p>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 <cite>RFC 6120</cite>), since the stream might already be used for sending XML stanzas for other domain pairs. (The following example is the same as Example 8.)</p>
@ -538,7 +537,7 @@ key = HMAC-SHA256(
SHA256('d14lb4ck43v3r'), SHA256('d14lb4ck43v3r'),
{ 'capulet.example', ' ', 'montague.example', ' ', '417GAF25' } { 'capulet.example', ' ', 'montague.example', ' ', '417GAF25' }
) )
= d4afb251ac62eb6fc778dac7ad65c43fdee29c4930ba204d479191566ea99496 = 225cc5aa6a071133249d25fef42ae516fc7a86c523aa1c6980a7f73e784c972d
</code> </code>
<p>The Authoritative Server then notifies the Receiving Server whether the key is valid. This is done by creating a &lt;db:verify/&gt; 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>The Authoritative Server then notifies the Receiving Server whether the key is valid. This is done by creating a &lt;db:verify/&gt; 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 (this is the same as Example 6)...</p> <p>Therefore, here again the result is either valid (this is the same as Example 6)...</p>