Jeremie Miller The Jabber.org Project

jeremie@jabber.org

David Waite Jabber.com

dwaite@jabber.com

01/25/2001

This below needs to be cleaned up, checked, and reformatted yet... The xmlns:db actually indicates to server B that server A supports dialback at all. 2. Server B sends a stream header back to Server A over Conn 1: 3. Server A sends a dialback key to Server B over Conn 1: 98AF014EDC0... Note that this key is not even examined by Server B; it does not keep information on Server A between sessions. 4. Server B now establishes a connection back to Server A, getting the Authorative Server A (Conn 2) 5. Server B sends Authorative Server A a stream header on Conn 2: 6. Authorative Server A sends Server B a stream header on Conn 2: Note the presence of the id attribute: this will be explained further down. 7. Server B sends Authorative Server A a packet on Conn 2 indicating it wants wants Authorative Server A to verify a key: 98AF014EDC0... Passed here are the server names, the original identifier from Server B's stream header to Server A in step 2, and the key Server A gave Server B in step 3. Based on this information and shared secret information within the 'Server A' network, the key is verified. The key generation technique used by the jabber.org 1.2 and 1.4 server uses a SHA1-hashed concatenation of a subset of this information, but the key is private to the servers making up the Server A network: any verifiable method can be used to generate the key. 8. Authorative Server A sends a packet back to Server B over Conn 2 indicating whether the key was valid or invalid: or 9. Server B informs Server A of the result over Conn 1: At this point the connection has either been validated via a type='valid', or reported as invalid. Once the connection is validated, data can be sent over Conn 1 and read by Server B; before that, packets are dropped. There is a small caveat which makes the above considerably harder to follow. When Server B and Authorative Server A are talking, Server B has the option of not only sending the db:verify request over, but sending a db:result over with its own key. After this, Authorative Server A would establish a connection with Authorative Server B to conduct the dialback again, this time in reverse (so that Server B can conduct server to server communication with Server A). The reason that Server B needs to do this is that s2s requires two sockets between servers. Remember again that the networks can be complicated server farms - there could be one authorative jabber server for handling s2s traffic, and this would need to be the one that Server B communicates with, not the Server A which established the connection ]]>