The authentication and resource binding process between an ordinary XMPP client and an ordinary XMPP server goes through lots of XMPP messages. A lot of XMPP messages ping-pong between the server and the client. This situation increases the login duration as expected.

We will deeply look at the messaging sequence during authentication and we will analyse that if we already knew some predefined values before the authentication whether we can eliminate some of inessential messages or not.

The figure below shows the ordinary authentication and resource binding message sequence diagram between the client and the server:

Let's examine these messages deeply:

1. stream - IP

<stream:stream to="0.0.0.0" xmlns="jabber:client" 
               xmlns:stream="http://etherx.jabber.org/streams" version="1.0">

First of all the client sends the stream message to the server for initiating the XMPP streaming. This is the first message which opens the stream between the client and the server.

2. stream features message - 1

<?xml version='1.0' encoding='utf-8'?>
<stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" 
               from="testtims.turkcell.com.tr" id="d4e01436"
xml:lang="en" version="1.0">
  <stream:features>
    <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls>
    <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
      <mechanism>PLAIN</mechanism>
    </mechanisms>
    <auth xmlns="http://jabber.org/features/iq-auth" />
    <register xmlns="http://jabber.org/features/iq-register" />
  </stream:features>
</stream:stream>

After opening the stream, the server returns its inital features to the client with the message above. The message says that the server supports tls, plain authentication mechanism, authentication and also registration features for non-authenticated clients.

3. start tls

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

After receiving the server features, the client negotiates for secure transportation with the server.

4. proceed tls

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

The server returns tls proceed message to the client which includes that the client can continue streaming securely.

5. stream - server

<stream:stream to="xmppserver" xmlns="jabber:client" 
               xmlns:stream="http://etherx.jabber.org/streams" version="1.0">

After receiving the proceed message, this time the client starts a secure stream with the server.

6. stream feature message - 2

<?xml version='1.0' encoding='utf-8'?>
<stream:stream xmlns:stream="http://etherx.jabber.org/streams" 
               xmlns="jabber:client" from="testtims.turkcell.com.tr" id="d4e01436"
xml:lang="en" version="1.0">
  <stream:features>
    <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
      <mechanism>PLAIN</mechanism>
    </mechanisms>
    <auth xmlns="http://jabber.org/features/iq-auth" />
    <register xmlns="http://jabber.org/features/iq-register" />
  </stream:features>
</stream:stream>

The server returns its features again to the client after starting TLS.

7. auth

<auth mechanism="PLAIN" 
   xmlns="urn:ietf:params:xml:ns:xmpp-sasl">dfaXNlcjE4MDAxAHVzZXIxODAwMQAxMjM0NTY=
</auth>

At last, the client sends its password to the server for authentication. 

8. success  

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

If the password is correct then the server authenticates the client and returns the success messsage to the client.

9. stream server

<stream:stream to="xmppserver" xmlns="jabber:client" 
               xmlns:stream="http://etherx.jabber.org/streams" version="1.0">

After receiveng the successful authentication message, the client wants the server features for authenticated clients.

10. stream features message - 3

<?xml version='1.0' encoding='utf-8'?>
<stream:stream xmlns:stream="http://etherx.jabber.org/streams" 
               xmlns="jabber:client" from="testtims.turkcell.com.tr" id="d4e01436"
xml:lang="en" version="1.0">
  <stream:features>
    <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind" />
    <session xmlns="urn:ietf:params:xml:ns:xmpp-session" />
  </stream:features>
</stream:stream>

Server informs the client that it can bind a resource or start the session.

11. resource bind

<iq id="q5kug-0" type="set">
  <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
  <resource>3694075081760</resource>
  </bind>
</iq>

After receiving the server features for authenticated clients, resource is sent for binding by the client.

12. bind success

<iq type="result" id="q5kug-0" to="xmppserver/d4e01436">
  <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
  <jid>user@xmppserver/3694075081760</jid>
  </bind>
</iq>

The client receives the bind result message from the server.

13. session start

<iq id="q5kug-1" type="set">
  <session xmlns="urn:ietf:params:xml:ns:xmpp-session"/>
</iq>

At the end of the sequence the client sends the session start message to the server and the streaming begins :)

Now we can examine which messages can be eliminated if we knew some predefined configuration before authentication.

a. starttls

If we know that we will always start tls between the client and the server, then the 3th and the 4th messages become inessential. The server and the client automatically starts the TLS because they already knew that.

b. stream feature message - 2

In the client side, let's assume we initally know the server supports auth, register and plain authentication mechanism. Then no need to send the 5th message from the client side to the server. The 5th and the 6th messages are eliminated.

c. stream feature message - 3

Let's also assume that the client knows the features of the server for the authenticated clients, which are bind and session in our case, then there is no need to to ask the features to the server.

If a new message type, which includes authentication plain text and also the resource to be bound, is introduced between the client and the server then the server may handle both process in the same time. This new message with a new namespace which will be handled by the server can be introduced as:

<message id="dLsP8-0">
  <auth xmlns="xmpp:auth">
    <xmlval>
      <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="PLAIN">dXNasdlcjEwMDE4AHVzZXIxMDAxOAAxMjM0NTY=</auth>
    </xmlval>
    <resource>resource</resource>
  </auth>
</message>

As seen the message includes both the password and the resource. If the authentication and binding is successful then the server may return the bind result IQ to the client:

<iq type="result" id="q5kug-0" to="xmppserver/d4e01436">
  <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
  <jid>user@xmppserver/3694075081760</jid>
  </bind>
</iq>

While returning the it knows that the session message will be sent by the client then it may take the session action without receiving the session message from the client and then the client session message is eliminated too.

If we summarize the new messaging sequence:

1. stream 

<stream:stream to="xmppserver" xmlns="jabber:client" 
               xmlns:stream="http://etherx.jabber.org/streams" version="1.0">

2. stream features message - 1

<?xml version='1.0' encoding='utf-8'?>
<stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="testtims.turkcell.com.tr" id="d4e01436"
xml:lang="en" version="1.0">
  <stream:features>
    <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls>
    <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
      <mechanism>PLAIN</mechanism>
    </mechanisms>
    <auth xmlns="http://jabber.org/features/iq-auth" />
    <register xmlns="http://jabber.org/features/iq-register" />
  </stream:features>
</stream:stream>

3. auth & bind

<message id="dLsP8-0">
  <auth xmlns="xmpp:auth">
    <xmlval>
      <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="PLAIN">dXNasdlcjEwMDE4AHVzZXIxMDAxOAAxMjM0NTY=</auth>
    </xmlval>
    <resource>resource</resource>
  </auth>
</message>

4. bind success

<iq type="result" id="q5kug-0" to="xmppserver/d4e01436">
  <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
  <jid>user@xmppserver/3694075081760</jid>
  </bind>
</iq>

The new sequence diagram for authentication and resource binding process is shown below:

As seen above, if we initailly know the server features as a client then only 4 messages are enough for successful authentication. This new sequence dramatically decreases the login duration as expected. The only thing to be introduced by the XMPP server is to handle the new authentication&binding message.