mirror of https://github.com/moparisthebest/xeps
XEP-0220 v1.2 - approved by Council on 2014-07-30
This commit is contained in:
Matthew A. Miller
parent
55ea1f0022
commit
be375e2b0c
50
xep-0220.xml
50
xep-0220.xml
|
|
@ -27,8 +27,8 @@
|
|||
&stpeter;
|
||||
&fippo;
|
||||
<revision>
|
||||
<version>1.1rc2</version>
|
||||
<date>2014-06-18</date>
|
||||
<version>1.1</version>
|
||||
<date>2014-08-05</date>
|
||||
<initials>ph/psa</initials>
|
||||
<remark>
|
||||
<ul>
|
||||
|
|
@ -278,7 +278,7 @@ Initiating Receiving
|
|||
<p>The following figure gives an overview of where each example is embedded in the process and illustrates the changing roles of each server.</p>
|
||||
<code><![CDATA[
|
||||
orchard.capulet. home.montague.
|
||||
example example
|
||||
example example
|
||||
(as Initiating) (as Receiving
|
||||
Server) Server)
|
||||
---------------- -------------
|
||||
|
|
@ -295,7 +295,7 @@ example example
|
|||
| (ID D60000229F) |
|
||||
| |
|
||||
| send | capulet.example
|
||||
| dialback key | (as Authoritative
|
||||
| dialback key | (as Authoritative
|
||||
| -----(STEP 1)----> | Server)
|
||||
| Ex 1 / 9 | -----------------
|
||||
| | [if necessary, |
|
||||
|
|
@ -330,14 +330,14 @@ example example
|
|||
| montague.example capulet.example
|
||||
| (as Initiating (as Receiving
|
||||
| Server) Server)
|
||||
| --------- ----------
|
||||
| | |
|
||||
| --------- ----------
|
||||
| | |
|
||||
| | [may reuse |
|
||||
| | connection or |
|
||||
| | open new stream] |
|
||||
| | -----------------> |
|
||||
| | (ID 417GAF25) |
|
||||
| | | montague.example
|
||||
| | connection or |
|
||||
| | open new stream] |
|
||||
| | -----------------> |
|
||||
| | (ID 417GAF25) |
|
||||
| | | montague.example
|
||||
| | send | (as Authoritative
|
||||
| | dialback key | Server)
|
||||
| | -----(STEP 1)----> | -----------
|
||||
|
|
@ -389,8 +389,8 @@ send: <db:result
|
|||
]]></example>
|
||||
<p>The key sent is generated as described in &xep0185;:</p>
|
||||
<code>
|
||||
key = HMAC-SHA256(
|
||||
SHA256('s3cr3tf0rd14lb4ck'),
|
||||
key = HMAC-SHA256(
|
||||
SHA256('s3cr3tf0rd14lb4ck'),
|
||||
{ 'montague.example', ' ', 'capulet.example', ' ', 'D60000229F' }
|
||||
)
|
||||
= b4835385f37fe2895af6c196b59097b16862406db80559900d96bf6fa7d23df3
|
||||
|
|
@ -426,7 +426,7 @@ recv: <db:result
|
|||
<error type='cancel'>
|
||||
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</error>
|
||||
</db:result>
|
||||
</db:result>
|
||||
]]></example>
|
||||
</section3>
|
||||
|
||||
|
|
@ -508,7 +508,7 @@ send: <db:result
|
|||
<error type='cancel'>
|
||||
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</error>
|
||||
</db:result>
|
||||
</db:result>
|
||||
]]></example>
|
||||
<p>After the validity of the dialback request has been established (for example, by the Authoritative Server), the Receiving Server can safely accept stanzas from the Initiating Server for the verified domain pair.</p>
|
||||
<p>In addition, the Receiving Server SHALL notify the Initiating Server of the result and thus signal its willingness to accept stanzas from the Initiating Server for the verified domain pair. 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" (or "error", as shown above).</p>
|
||||
|
|
@ -519,14 +519,14 @@ send: <db:result
|
|||
to='capulet.example'
|
||||
type='valid'/>
|
||||
]]></example>
|
||||
<p>... or invalid (this is the same as Example 3)...</p>
|
||||
<p>... or invalid (this is the same as Example 3)...</p>
|
||||
<example caption="Receiving Server Sends Invalid Verification Result to Initiating Server (Step 4)"><![CDATA[
|
||||
send: <db:result
|
||||
from='montague.example'
|
||||
to='capulet.example'
|
||||
type='invalid'/>
|
||||
]]></example>
|
||||
<p>If the result is "invalid", the Initiating Server is either attempting to spoof the Sender Domain, or misconfigured. The Receiving Server MUST NOT accept stanzas from the Initiating Server for the Sender Domain and ought to log the attempt. If no other valid domain pairs exist for this connection (ie, if this is the first attempt), the Receiving Server SHOULD send a result with type "invalid" and MUST close the XML stream. If there exist other valid domain pairs for this connection, the Initiating Server might merely have a misconfiguration for the Sender Domain. In this case, the Receiving Server MAY return an error condition of <forbidden/> as described under Section 2.5 of this document.</p>
|
||||
<p>If the result is "invalid", the Initiating Server is either attempting to spoof the Sender Domain or is misconfigured. The Receiving Server MUST NOT accept stanzas from the Initiating Server for the Sender Domain and ought to log the attempt. If no other valid domain pairs exist for this connection (i.e., if this is the first attempt), the Receiving Server SHOULD send a result with type "invalid" and MUST close the XML stream. If there exist other valid domain pairs for this connection, the Initiating Server might merely have a misconfiguration for the Sender Domain. In this case, the Receiving Server MAY (instead of closing the connection) return an error condition of <forbidden/> as described under Section 2.5 of this document.</p>
|
||||
</section3>
|
||||
|
||||
<section3 topic="Authoritative Server Handles Inbound Verification Request from Receiving Server">
|
||||
|
|
@ -544,17 +544,17 @@ recv: <db:verify
|
|||
send: <db:verify
|
||||
from='montague.example'
|
||||
id='417GAF25'
|
||||
to='capulet.example'
|
||||
to='capulet.example'
|
||||
type='error'>
|
||||
<error type='cancel'>
|
||||
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</error>
|
||||
</db:verify>
|
||||
</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('d14lb4ck43v3r'),
|
||||
key = HMAC-SHA256(
|
||||
SHA256('d14lb4ck43v3r'),
|
||||
{ 'capulet.example', ' ', 'montague.example', ' ', '417GAF25' }
|
||||
)
|
||||
= 225cc5aa6a071133249d25fef42ae516fc7a86c523aa1c6980a7f73e784c972d
|
||||
|
|
@ -573,7 +573,7 @@ send: <db:verify
|
|||
send: <db:verify
|
||||
from='montague.example'
|
||||
id='417GAF25'
|
||||
to='capulet.example'
|
||||
to='capulet.example'
|
||||
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>
|
||||
|
|
@ -589,7 +589,7 @@ send: <db:verify
|
|||
<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 With Dialback Namespace Declaration"><![CDATA[
|
||||
<stream:stream
|
||||
<stream:stream
|
||||
xmlns='jabber:server'
|
||||
xmlns:db='jabber:server:dialback'
|
||||
xmlns:stream='http://etherx.jabber.org/streams'
|
||||
|
|
@ -674,7 +674,7 @@ send: <db:verify
|
|||
|
||||
<!--
|
||||
<section2 topic="Reverification" anchor='reverify'>
|
||||
<p>Server-to-server streams can exist for long periods of time. An Initiating Server MAY reverify the key periodically over the life of the stream (i.e., by sending a new <db:verify/> packet as in Step 3 of the dialback negotiation), but MUST NOT attempt to re-verify the domain pair on this TCP connection.</p>
|
||||
<p>Server-to-server streams can exist for long periods of time. An Initiating Server MAY reverify the key periodically over the life of the stream (i.e., by sending a new <db:verify/> packet as in Step 3 of the dialback negotiation), but MUST NOT attempt to re-verify the domain pair on this TCP connection.</p>
|
||||
-->
|
||||
|
||||
<section2 topic="Multiplexing" anchor='multiplex'>
|
||||
|
|
@ -711,7 +711,7 @@ home.montague.example. 86400 IN A 10.44.0.
|
|||
</section1>
|
||||
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
|
|
|
|||
Loading…
Reference in New Issue