<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE xep SYSTEM 'xep.dtd' [ <!ENTITY % ents SYSTEM 'xep.ent'> %ents; ]> <?xml-stylesheet type='text/xsl' href='xep.xsl'?> <xep> <header> <title>Best Practices for Use of SASL ANONYMOUS</title> <abstract>This document specifies best practices for use of the SASL ANONYMOUS mechanism in the context of client authentication with an XMPP server.</abstract> &LEGALNOTICE; <number>0175</number> <status>Active</status> <type>Informational</type> <sig>Standards</sig> <approver>Council</approver> <dependencies> <spec>XMPP Core</spec> </dependencies> <supersedes/> <supersededby/> <shortname>N/A</shortname> &stpeter; <revision> <version>1.1</version> <date>2007-11-07</date> <initials>psa</initials> <remark><p>Recommended that node identifier be a UUID; recommended that trace data not be included.</p></remark> </revision> <revision> <version>1.0</version> <date>2006-09-20</date> <initials>psa</initials> <remark><p>Per a vote of the Jabber Council, advanced status to Active.</p></remark> </revision> <revision> <version>0.1</version> <date>2006-02-09</date> <initials>psa</initials> <remark><p>Initial version; modified flow to remove unecessary challenge.</p></remark> </revision> <revision> <version>0.0.1</version> <date>2006-01-24</date> <initials>psa</initials> <remark><p>First draft.</p></remark> </revision> </header> <section1 topic='Introduction' anchor='intro'> &RFC3920BISNOTE; <p><cite>RFC 3920</cite> allows the use of any SASL mechanism (see &rfc4422;) in XMPP authentication, including the SASL ANONYMOUS mechanism (see &rfc4505;). This document specifies a recommended protocol flow for such use.</p> <p>Note: This document is provided for discussion purposes in order to clarify the usage of SASL ANONYMOUS in XMPP systems. It is not meant to supersede the text in <cite>RFC 3920</cite>, <cite>RFC 4422</cite>, or <cite>RFC 4505</cite>. However, the recommendations in this document may be folded into <cite>rfc3920bis</cite>.</p> </section1> <section1 topic='Recommendation' anchor='rec'> <p><cite>RFC 3920</cite> specifies that after an XMPP client authenticates with an XMPP server, it must bind a resource to the XML stream so that XML stanzas can be routed to the client. In essence there are three resource binding scenarios:</p> <ol> <li>The client specifies a desired resource identifier and the server accepts it.</li> <li>The client specifies a desired resource identifier but the server does not accept it, instead overruling the client and assigning a resource identifier.</li> <li>The client asks the server to assign a resource identifier and the server does so.</li> </ol> <p>No matter which scenario is enacted, at the end of the process the server informs the client of its full JID (&FULLJID;). In particular, it might be helpful for an XMPP server to assign a full JID to the client (i.e., not just the resource identifier) if it authenticates with SASL ANONYMOUS, and to ensure that the "bare JID" portion (&BAREJID;) is unique in the context of the domain served by the server.</p> <p>The method for ensuring the uniqueness of the node identifier is a matter of implementation. It is RECOMMENDED for the node identifier to be a UUID as specified in &rfc4122;.</p> <p>Although <cite>RFC 4505</cite> allows the initiating entity (client) to provide so-called "trace data" when authenticating via SASL ANONYMOUS, it is NOT RECOMMENDED to include trace data as the XML character data of the <auth/> element (instead, the <auth/> element SHOULD be empty). However, if trace data is included, the server MUST NOT use it for any purpose other than tracing (e.g., in server logs).</p> </section1> <section1 topic='Protocol Flow' anchor='flow'> <p>The RECOMMENDED protocol flow following TLS negotiation (refer to <cite>RFC 3920</cite>) is as follows:</p> <ol> <li> <p>Client initiates stream to server.</p> <example caption="Stream initiation"><![CDATA[ <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' to='example.com' version='1.0'> ]]></example> </li> <li> <p>Server replies with stream header.</p> <example caption="Stream header reply"><![CDATA[ <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' id='c2s_234' from='example.com' version='1.0'> ]]></example> </li> <li> <p>Server advertises stream features.</p> <example caption="Stream features advertisement"><![CDATA[ <stream:features> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>DIGEST-MD5<mechanism> <mechanism>ANONYMOUS<mechanism> </mechanisms> </stream:features> ]]></example> </li> <li> <p>Client requests SASL ANONYMOUS mechanism.</p> <example caption="Requesting SASL ANONYMOUS"><![CDATA[ <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='ANONYMOUS'/> ]]></example> </li> <li> <p>Server sends <success/>.</p> <example caption="Sending success"><![CDATA[ <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> ]]></example> </li> <li> <p>Client opens new stream.</p> <example caption="Initiating a new stream"><![CDATA[ <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' to='example.com' version='1.0'> ]]></example> </li> <li> <p>Server tells client that resource binding is required.</p> <example caption="Stream header reply with features"><![CDATA[ <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' id='c2s_345' from='example.com' version='1.0'> <stream:features> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> </stream:features> ]]></example> </li> <li> <p>Client requests that server create a resource for it.</p> <example caption="Requesting resource creation"><![CDATA[ <iq type='set' id='bind_1'> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> </iq> ]]></example> </li> <li> <p>Server replies with full JID.</p> <example caption="Server informs client of full JID"><![CDATA[ <iq type='result' id='bind_1'> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'> <jid>somenode@example.com/someresource</jid> </bind> </iq> ]]></example> </li> </ol> </section1> <section1 topic='Security Considerations' anchor='security'> <p>This document introduces no security considerations or concerns above and beyond those discussed in <cite>RFC 3920</cite>.</p> </section1> <section1 topic='IANA Considerations' anchor='iana'> <p>This document requires no interaction with &IANA;.</p> </section1> <section1 topic='XMPP Registrar Considerations' anchor='registrar'> <p>This document requires no interaction with the ®ISTRAR;.</p> </section1> </xep>