Server-to-Server Examples

The following examples show the data flow for a server negotiating an XML stream with a peer server, exchanging XML stanzas, and closing the negotiated stream. The initiating server ("Server1") is

im.example.com; the receiving server ("Server2") is example.net and it requires use of TLS; im.example.com presents a certificate and authenticates via the SASL EXTERNAL mechanism. It is assumed that before sending the initial stream header, Server1 has already resolved an SRV record of _xmpp-server._tcp.example.net and has opened a TCP connection to the advertised port at the resolved IP address. Note how Server1 declares the content namespace "jabber:

server" as the default namespace and uses prefixes for stream-related elements, whereas Server2 uses prefix-free canonicalization.

9.2.1. TLS

Step 1: Server1 initiates stream to Server2:

S1: <stream:stream

from=’im.example.com’

to=’example.net’

version=’1.0’

xmlns=’jabber:server’

xmlns:stream=’http://etherx.jabber.org/streams’>

Step 2: Server2 responds by sending a response stream header to Server1:

S2: <stream

from=’example.net’

id=’hTiXkW+ih9k2SqdGkk/AZi0OJ/Q=’

to=’im.example.com’

version=’1.0’

xmlns=’http://etherx.jabber.org/streams’>

Step 3: Server2 sends stream features to Server1 (only the STARTTLS extension at this point, which is mandatory-to-negotiate):

S2: <features xmlns=’http://etherx.jabber.org/streams’>

<starttls xmlns=’urn:ietf:params:xml:ns:xmpp-tls’>

<required/>

</starttls>

</features>

Step 4: Server1 sends the STARTTLS command to Server2:

S1: <starttls xmlns=’urn:ietf:params:xml:ns:xmpp-tls’/>

Step 5: Server2 informs Server1 that it is allowed to proceed:

S2: <proceed xmlns=’urn:ietf:params:xml:ns:xmpp-tls’/>

Step 5 (alt): Server2 informs Server1 that STARTTLS negotiation has failed, closes the stream, and terminates the TCP connection (thus, the stream negotiation process ends unsuccessfully and the parties do not move on to the next step):

S2: <failure xmlns=’urn:ietf:params:xml:ns:xmpp-tls’/>

</stream>

Step 6: Server1 and Server2 attempt to complete TLS negotiation via TCP (see [TLS] for details).

Step 7: If TLS negotiation is successful, Server1 initiates a new stream to Server2 over the TLS-protected TCP connection:

S1: <stream:stream

from=’im.example.com’

to=’example.net’

version=’1.0’

xmlns=’jabber:server’

xmlns:stream=’http://etherx.jabber.org/streams’>

Step 7 (alt): If TLS negotiation is unsuccessful, Server2 closes the TCP connection (thus, the stream negotiation process ends

unsuccessfully and the parties do not move on to the next step).

9.2.2. SASL

Step 8: Server2 sends a response stream header to Server1 along with available stream features (including a preference for the SASL

EXTERNAL mechanism):

S2: <stream

from=’example.net’

id=’RChdjlgj/TIBcbT9Keu31zDihH4=’

to=’im.example.com’

version=’1.0’

xmlns=’http://etherx.jabber.org/streams’>

S2: <features xmlns=’http://etherx.jabber.org/streams’>

<mechanisms xmlns=’urn:ietf:params:xml:ns:xmpp-sasl’>

<mechanism>EXTERNAL</mechanism>

</mechanisms>

</features>

Step 9: Server1 selects the EXTERNAL mechanism (including an empty response of "="):

S1: <auth xmlns=’urn:ietf:params:xml:ns:xmpp-sasl’

mechanism=’EXTERNAL’>=</auth>

Step 10: Server2 returns success:

S2: <success xmlns=’urn:ietf:params:xml:ns:xmpp-sasl’/>

Step 10 (alt): Server2 informs Server1 of failed authentication (thus, the stream negotiation process ends unsuccessfully and the parties do not move on to the next step):

S2: <failure xmlns=’urn:ietf:params:xml:ns:xmpp-sasl’>

<not-authorized/>

</failure>

</stream>

Step 11: Server1 initiates a new stream to Server2:

S1: <stream:stream

from=’im.example.com’

to=’example.net’

version=’1.0’

xmlns=’jabber:server’

xmlns:stream=’http://etherx.jabber.org/streams’>

Step 12: Server2 responds by sending a stream header to Server1 along with any additional features (or, in this case, an empty features element):

S2: <stream

from=’example.net’

id=’MbbV2FeojySpUIP6J91qaa+TWHM=’

to=’im.example.com’

version=’1.0’

xmlns=’http://etherx.jabber.org/streams’>

S2: <features xmlns=’http://etherx.jabber.org/streams’/>

9.2.3. Stanza Exchange

Now Server1 is allowed to send XML stanzas to Server2 over the

negotiated stream from im.example.com to example.net; here we assume that the transferred stanzas are those shown earlier for server communication, albeit over a server-to-server stream qualified by the ’jabber:server’ namespace.

Server1 sends XML stanza to Server2:

S1: <message from=’juliet@im.example.com/balcony’

id=’ju2ba41c’

to=’romeo@example.net’

type=’chat’

xml:lang=’en’>

<body>Art thou not Romeo, and a Montague?</body>

</message>

9.2.4. Close

Desiring to send no further messages, Server1 closes its stream to Server2 but waits for incoming data from Server2. (In practice, the stream would most likely remain open for some time, since Server1 and Server2 do not immediately know if the stream will be needed for further communication.)

S1: </stream:stream>

Consistent with the recommended stream closing handshake, Server2 closes the stream as well:

S2: </stream>

Server1 now sends a TLS close_notify alert, receives a responding close_notify alert from Server2, and then terminates the underlying TCP connection.