mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-22 15:48:52 -05:00
e23c2c97aa
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1349 4b5297f7-1745-476d-ba37-a9c6900126ab
166 lines
7.0 KiB
XML
166 lines
7.0 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>
|
|
<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>
|