DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Coding
  3. JavaScript
  4. A New Approach for Authentication and Resource Binding for XMPP

A New Approach for Authentication and Resource Binding for XMPP

The authentication and resource binding process between an ordinary XMPP client and an ordinary XMPP server goes through lots of XMPP messages.

Ayberk Cansever user avatar by
Ayberk Cansever
·
Jul. 09, 15 · Tutorial
Like (1)
Save
Tweet
Share
1.78K Views

Join the DZone community and get the full member experience.

Join For Free

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:

image title

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:

image title

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.

authentication Binding (linguistics) XMPP Stream (computing) Session (web analytics)

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How Observability Is Redefining Developer Roles
  • A Complete Guide to AngularJS Testing
  • Spring Cloud: How To Deal With Microservice Configuration (Part 1)
  • Type Variance in Java and Kotlin

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: