XMPP Presentation 160108105545 PDF

XMPP – Extensible Messaging
and Presence Protocol

http://www.javaproficiency.com/
XMPP
The base protocol used for XMPP is RFC 2779 (Instant
Messaging /Presence Protocol Requirements).
There are 2 drafts namely XMPP Core and XMPP Instant
Messaging currently on XMPP.
Presence and Instant Messaging

• Presence – Presence is a means for finding, retrieving, and
subscribing to changes in the presence information (e.g. "online" or
"offline") of other users.
• Instant Messaging – It is a means for sending small,
simple messages that are delivered immediately to online users.
2
Requirements of RFC 2779
1. Scalability
2. Access Control
3. Message Encryption & Authentication
4. Presence Lookup & Notification
5. Presence Caching & Replication
6. Reliability
7. Performance
3
XMPP Core Overview
• XMPP is an open protocol for streaming XML elements in

order to exchange messages and presence information in close to
real time.
• XMPP has been implemented via a typical client-server

architecture, wherein a client utilizing XMPP accesses a server
over a TCP socket.
4
Addressing Scheme
JID – Jabber Identifier.

format: [node@]domain[/resource]
E.g. <room@service>
(where "room" is the name of the chat room and "service" is
the hostname of the multi-user chat service)
<room@service/nick>
(where "nick" is the occupant's room nickname)
<domain/resource>
(could be a server-side script or service )
5
• Domain Identifier –
– Only Required identifier of JID.

– Represents the n/w gateway or primary server to
which entities connect.
– Not always a server, can be service that is addressed
as a sub domain of a server.
• Node Identifier –
– optional secondary identifier.

– represents a client or a chat room associated with a
multi-user chat service etc.
– is called a "bare JID" and is of the form
<node@domain>.
6
• Resource Identifier –
– optional tertiary identifier.
– represents a specific session, connection (e.g., a device
or location), or object (e.g., a participant in a multi-user
chat room).
– typically defined by a client implementation.
7
XML Streams and Stanzas
 XML Streams
 container for the exchange of XML elements between
any two entities over a network.
 The start and end of the XML stream is denoted by
<stream> tag and </ stream> tag.
 An XML stream is unidirectional.
 XML Stanza
 is a discrete semantic unit of structured information.
 is at a depth=1 of the XML stream.
8
XML Stanzas
• Message Stanza
– include single messages, <stream>
– Types of messages are chat, error, group chat, <presence>
headline, normal. <show/>
– Child elements are <subject/> and <body/>. </presence>
<message
<message to='foo'>
to='[email protected]'
from='[email protected]/balcony' <body/>
xml:lang='en'> </message>
<subject>I implore you!</subject> <iq to='bar'>
<subject xml:lang=‘en'> <query/>
</subject>
</iq>
<body>Where are you, Romeo?</body>
<body xml:lang=‘en'> </stream>
</body>
</message>
9
•Presence Stanza
– to express an entity's current availability status.
– Types of Presence are unavailable, subscribe etc.
– Child elements are <show/>, <status/>, <priority/>.
<presence>
<show>dnd</show>
</presence>
•IQ Stanza
– is a request-response mechanism
– Types of IQ are get(request roaster), set(add item on roaster), result, error.
– Client requests current roster from server:
<iq type='get' id='roster_1'>
<query xmlns='jabber:iq:roster'/>
</iq>
10
::
A Basic Session:
C: <?xml version='1.0'?>
<stream:stream
to='shakespeare.lit'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
S: <?xml version='1.0'?>
<stream:stream
from='shakespeare.lit'
id='id_123456789'
xmlns:stream='http://etherx.jabber.org/streams‘
version='1.0'>
….authentication ...
C: <message from='[email protected]'
xml:lang='en'>
C: <body>Hi Romeo</body>
C: </message>
S: <message from='[email protected]'
xml:lang='en'>
S: <body>Hi Juliet.</body>
S: </message>
C: </stream:stream> 11
S: </stream:stream>
Stream Encryption & Authentication
XMPP includes a method for securing the stream from tampering and
eavesdropping. This channel encryption method makes use of the
Transport Layer Security (TLS) protocol, along with a "STARTTLS“.
Example
Step 1: Client initiates stream to server:
<stream:stream
to='capulet.com'
version='1.0'>
Step 2: Server responds by sending a stream tag to client:
<stream:stream
id='12345678'
from='capulet.com'
version='1.0'>
12
Step 3: Server sends the STARTTLS extension to client along with
authentication mechanisms and any other stream features:
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms> </stream:features>
Step 4: Client sends the STARTTLS command to server:
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
Step 5: Server informs client to proceed:
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
Step 6: Client and server attempt to complete TLS negotiation over the
existing TCP connection.
Step 7: If TLS negotiation is successful, client initiates a new stream to
server: <stream:stream
to='capulet.com'
version='1.0'> 13
Step 8: Server responds by sending a stream header to client along with
any remaining negotiable stream features:
<stream:stream
from='capulet.com'
id='12345678'
version='1.0'>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>
Step 9: Client selects an authentication mechanism:
<auth
xmlns='urn:ietf:params:xml:ns:xmpp-sasl‘
mechanism='DIGEST-MD5'/>
Step 10: Server sends a base64-encoded challenge to client: The decoded challenge
is:
nonce="gx0P01RRVoOfJVrIJ6aNkFlinh9nM/Up9dazVTFTq1c=",\
realm="capulet.com",qop="auth,auth-int,auth-conf",\
cipher="rc4-40,rc4-56,rc4,des,3des",maxbuf=2048,\
charset=utf-8,algorithm=md5-sess 14
Step 11: Client responds to the challenge: The decoded response is:
username="juliet",realm="capulet.com",\ authzid="[email protected]/balcony",\
nonce="gx0P01RRVoOfJVrIJ6aNkFlinh9nM/Up9dazVTFTq1c=",\
cnonce="bdi7U/Duhd97ffXpS9mNhhK3ciY0FGO9xuqIlapBK4o=",\
nc=00000001,qop=auth-conf,cipher="rc4",maxbuf=2048,\
digest-uri="xmpp/capulet.com",\ response=8e0ac6010833b1224fcc4742afbdb352
Step 12: Server informs client of successful authentication:
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 13: Client initiates a new stream to server and the rest of the message
passing happens.
15
Order of Layers
The order of layers in which protocols MUST be stacked is as follows:

1. TCP
2. TLS
3. SASL
4. XMPP
The rationale for this order is that TCP is the base connection layer used
by all of the protocols. Stacked on top of TCP is TLS and is often provided at the
operating system layer, SASL is often provided at the application layer, and
XMPP is the application itself.
16
Summary of XMPP- IM
• Establishing a Session
• Exchanging Messages
• Exchanging Presence Information
• Managing One's Roster
17

XMPP Presentation 160108105545 PDF

Uploaded by

Copyright:

Available Formats

XMPP Presentation 160108105545 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

XMPP Presentation 160108105545 PDF

Uploaded by

Copyright:

Available Formats

XMPP – Extensible Messaging

and Presence Protocol

Presence and Instant Messaging

• XMPP is an open protocol for streaming XML elements in

• XMPP has been implemented via a typical client-server

JID – Jabber Identifier.

– Only Required identifier of JID.

– optional secondary identifier.

The order of layers in which protocols MUST be stacked is as follows:

You might also like