moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

need to start dialback negotiation in different direction

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3301 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Philipp Hancke 2009-07-02 15:51:15 +00:00
parent 2cf9922161
commit 254c00ec1c
1 changed files with 3 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
xep-0220.xml
View File

@ -92,7 +92,7 @@
</section2>
<section2 topic="What Dialback Accomplishes" anchor="intro-what">
<p>Server Dialback is a method for weak identify verification. Such verification depends on the Domain Name System (DNS) and the use of keys based on a shared secret known to all XMPP servers within a given trust domain.</p>
<p>Server Dialback is a method for weak identity verification. Such verification depends on the Domain Name System (DNS) and the use of keys based on a shared secret known to all XMPP servers within a given trust domain.</p>
<p>Since October 2000, the use of Server Dialback has made it more difficult to spoof the hostnames of servers (and therefore the addresses of sent messages) on the XMPP network. However, Server Dialback does not provide authentication between servers and is not a security mechanism. Domains requiring high security are advised to use TLS and SASL with certificates issued by trusted roots.</p>
<p>Server Dialback is uni-directional, and results in weak identity verification for one XML stream in one direction. Because Server Dialback is not an authentication mechanism, mutual authentication is not possible via dialback. Therefore, Server Dialback must be completed in each direction in order to enable bi-directional communication between two domains.</p>
<p>Dialback does not verify that the IP address returned by a DNS lookup of the originating domain is the same as the source IP address of the incoming TCP connection. While this might often be true, not performing this check enables large deployments to separate incoming and outgoing message routing.</p>
@ -124,7 +124,7 @@
<li>The Originating Server generates a dialback key and sends that value over its XML stream with the Receiving Server. (If the Originating Server does not yet have an XML stream to the Receiving Server, it will first need to perform a DNS lookup on the Target Domain and thus discover the Receiving Server, open a TCP connection to the discovered IP address and port, and establish an XML stream with the Receiving Server.)</li>
<li>Instead of immediately accepting XML stanzas on the connectiom from the Originating Server, the Receiving Server sends the same dialback key over its XML stream with the Authoritative Server for verification. (If the Receiving Server does not yet have an XML stream to the Authoritative Server, it will first need to perform a DNS lookup on the Sender Domain and thus discover the Authoritative Server, open a TCP connection to the discovered IP address and port, and establish an XML stream with the Authoritative Server.)</li>
<li>The Authoritative Server informs the Receiving Server whether the key is valid or invalid.</li>
<li>The Receiving Server informs the Originating Server whether its identify has been verified or not.</li>
<li>The Receiving Server informs the Originating Server whether its identity has been verified or not.</li>
</ol>
<p>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.</p>
<p>We can represent this flow of events graphically as follows.</p>
@ -320,6 +320,7 @@ send: <db:result
type='invalid'/>
]]></example>
<p>If the type is 'invalid', the Originating Server is attempting to spoof the Sender Domain. The Receiving Server MUST terminate the XML stream and the underlying TCP connection and SHOULD log the attempt.</p>
<p>As mentioned, Server Dialback results in weak identity verification of the Sender Domain by the Target Domain. In order to proceed with bi-directional communication so that the Target Domain can send XML stanzas to the Sender Domain, the Receiving Server MUST now also 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).</p>
</section3>
<section3 topic="Verify Request and Response">