xeps/xep-0175.xml

156 lines
6.1 KiB
XML

<?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>
<jig>Standards JIG</jig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<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'>
&BISNOTE;
<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> when that document is written.</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 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 &lt;success/&gt;.</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 &REGISTRAR;.</p>
</section1>
</xep>