XMPP Extensible Messaging and Presence Protocol Corso di Applicazioni Telematiche A.A. 2010-11 Prof. Simon Pietro Romano Università degli Studi di Napoli Federico II Facoltà di Ingegneria XMPP: eXtensible Messaging and Presence Protocol • Formerly known as Jabber • Jeremie Miller began the project in 1998 • first release in May 2000 • The project's main product was jabberd • XML-based • Extensible to other features • Open • open standard • open source implementations • open system 2 XMPP: eXtensible Messaging and Presence Protocol • Standardization • IETF XMPP Working Group (2002) • RFC 3920: Core features • RFC 3921: Instant Messaging and Presence 3 RFC 3920: Overview and Architecture • … is a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints… s2s • Architecture XMPP XMPP XMPP XMPP XMPP XMPP XMPP • XMPP servers Client Server Server Client • manage TCP connections • route messages No-XMPP Foreign No-XMPP Foreign • server-to-server (5269) XMPP messagi Messaging Gateway ng Client XMPP Client • XMPP clients network • connect to server (5222) • multiple resources simultaneously • Gateway • translates XMPP into the protocol used by a foreign (non-XMPP) messaging system 4 RFC 3920: Addressing Scheme • All XMPP entities are uniquely addressable • JID (Jabber Identifier) [ node "@" ] domain [ "/" resource ] • domain identifier: FQDN / address-literal • FQDN (Fully Qualified Domain Name) • address-literal: IPv4address / IPv6address • usually represents servers or gateways (REQUIRED) • node identifier • a simple string • usually represents a client (OPTIONAL) • resource identifier • usually represents a specific session, connection or object belonging to the entity associated with a node identifier (OPTIONAL). 5 JID: examples •domain meetecho.com •node@domain [email protected] •node@domain/resource [email protected]/Spark [email protected]/iMeetecho 6 XML example •XML-based communication 7 RFC 3920: XML Stream and Stanzas • XML Stream • container for the exchange of XML Stanzas between any two entities over a network • start <stream> tag with appropriate attributes and namespace • end </stream> tag • the stream enables unidirectional communication • qualified by the default namespace for the stream • jabber:client (client and server ) • jabber:server (server-to-server) 8 Stream example 1. Client initiates stream to server <?xml version='1.0'?> <stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> 2. Server responds by sending a stream tag to client <?xml version='1.0'?> <stream:stream from='example.com' id='someid' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> …encryption, authentication, and resource binding… 9 Encryption: use of TLS • Method for securing the stream • Transport Layer Security (TLS) protocol • "STARTTLS" extension • namespace name – 'urn:ietf:params:xml:ns:xmpp-tls‘ 3. Server sends the STARTTLS extension to client <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> 10 Use of TLS (2) 4. Client sends the STARTTLS command to server <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> 5. Server informs client that it is allowed to proceed <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> 6. Client and server attempt to complete TLS negotiation over the existing TCP connection 7. If TLS negotiation is successful, client initiates a new stream to server 8. Server responds by sending a stream header to client along with any available stream features 9. Client continues with SASL negotiation 11 With encryption 12 Without encryption 13 RFC 3920: XML Stanza • XML Stanza • discrete semantic unit of structured information that is sent over an XML stream • exists at the direct child level of the root <stream> element 14 XMPP stanzas • defined stanzas are: • <message> entity pushes information to another entity • <presence> availaibility information • <iq> info/query request-response mechanism • qualified by the default namespace for the stream • Common Attributes • to, from, type, id, xml:lang <message type='chat' from='[email protected]' to='[email protected]'> <body>Art thou not Romeo, and a Montague?</body> </message> 15 RFC 3921: Instant Messaging and Presence • Describes extensions to and applications of the core features XMPP that provide the basic instant messaging (IM) and presence functionality • Requirements • Exchange messages with other users • Exchange presence information with other users • Manage subscriptions to and from other users • Manage items in a contact list (in XMPP this is called a "roster") • Block communications to or from specific other users 16 RFC 3921: Message Syntax • Possible values of types for Message packets • chat: sent in the context of a one-to-one chat • groupchat: sent in the context of a multi-user chat • Child Elements • <subject/> contains the topic of the message • <body/> the textual content of the message • <thread/> identifier that is used for tracking a conversation thread <message to='[email protected]' from='[email protected]/balcony' type='chat' xml:lang='en'> <subject>The balcony scene!</subject> <subject xml:lang=‘it'>La scena del balcone!</subject> <body>Wherefore art thou, Romeo?</body> <body xml:lang=‘it'>Perché sei tu, Romeo?</body> </message> 17 RFC 3921: Presence Syntax • Possible values of types for Presence packets • subscribe: the sender wishes to subscribe to the recipient's presence • unavailable: signals that the entity is no longer available • probe: request for an entity's current presence • Child Elements • <show/> specifies the particular availability status • away, chat, dnd = "Do Not Disturb“ and xa = "eXtended Away" • <status/> a description of availability status • <priority/> the priority level of the resource [-128, +127] <presence xml:lang='en'> <show>dnd</show> <status>Wooing Juliet</status> <priority>1</priority> </presence> 18 RFC 3921: IQ Syntax • Extended namespace • defines all data contained within the child element • Possible values of types for IQ packets • get • set • result • Use case: retrieving One's Roster on Login • 'jabber:iq:roster' namespace <iq from='[email protected]/balcony' type='get' id='roster_1'> <query xmlns='jabber:iq:roster'/> </iq> <iq to='[email protected]/balcony' type='result' id='roster_1'> <query xmlns='jabber:iq:roster'> <item jid='[email protected]' name='Romeo‘ subscription='both'> <group>Friends</group> </item> </query> </iq> 19 Demo scenario XMPP XMPP Client Client XMPP XMPP XMPP Server Server 20 XEP: XMPP Extension Protocol XEP-0166: Jingle <iq •from=‘[email protected]/Is a pure XMPP signallingcastleprotocol' id='jingle1' •to=‘[email protected]/Designed to interwork withcastleSIP' type='set'> <jingle• Initiating xmlns='andurn managing:xmpp:tmp:jingle'media sessions between two XMPP entitiesaction='session-initiate' initiator=‘[email protected]/castle' • negotiationsid='851ba2'>occurs over the XMPP "channel" <content creator='initiator' name='a-file-offer'> • <mediadescription is exchangedxmlns='urnoutside:xmpp:thetmp:jingle: XMPP usingapps:fileRTP,-transfer UDP…'>. <offer> • How it works<file: File xmlns='http://jabber.org/protocol/si/profile/file transfer - transfer' name='test.txt' size='1022' hash='552da749930852c69ae5d2141d3766b1' date='1969Romeo -07-21T02:56:15Z'>Juliet <desc>This is a test. If this were a real file...</desc> </file> session-initiate </offer> </description> ack <transport xmlns='urn:xmpp:tmp:jingle:transports:bytestreams'/> </content> session-accept </jingle> </iq> ack <iq from=‘[email protected]/castle' MEDIAid=' SESSIONjingle1' to=‘[email protected]/session-terminate castle' type='ack result'/> 21 XEP-0167: Jingle Audio via RTP • This document specifies an application format for negotiating Jingle audio sessions, where the media is exchanged over the Realtime Transport Protocol • Mapping to Session Description Protocol • m=<media> <port> <transport> <fmt list> • In the context of Jingle audio sessions • <media> = audio • <port> is the preferred port • <transport> is whatever profile is negotiated • <fmt list> is the payload-type ID • static payload-type: <payload-type id="13" name="CN"/> m=audio 9999 RTP/AVP 13 • dynamic payload-type <payload-type id='96' name='speex' clockrate='16000' m=audio 9999 RTP/AVP 96 ptime='40'> a=rtpmap:96 speex/16000 <parameter name='vbr' value='on'/> <parameter name='cng' value='on'/> </payload-type> 22 Strengths • Decentralization • anyone can run his own XMPP server • there is no central master server • Open standards • No royalties are required to implement support of these specifications • History • Multiple implementations of the XMPP standards exist for clients, servers, components, and code libraries • Security • XMPP servers may be isolated from the public Jabber network (e.g., on a company intranet) • Flexibility • Custom functionality can be built on top of XMPP 23 Weaknesses • Presence data overhead • With typically over 70% of XMPP inter-server traffic being presence data, and close to 60% of it being redundantly transmitted • No binary data • The way XMPP is encoded as a single long XML document makes it impossible to deliver unmodified binary data • File transfers are therefore arranged to happen using external protocols