[Standards-JIG] proto-JEP: Best Practices for Implementation of SASL ANONYMOUS

Peter Saint-Andre stpeter at jabber.org
Thu Feb 9 17:31:31 UTC 2006

Hash: SHA1

Ralph Meijer wrote:
> On Tue, Jan 24, 2006 at 11:42:10PM -0600, JEP Editor wrote:
>> The JEP Editor has received a proposal for a new JEP.
>> Title: Best Practices for Implementation of SASL ANONYMOUS
>> Abstract: This document specifies best practices for implementation of the SASL ANONYMOUS mechanism in the context of client authentication with an XMPP server.
>> URL: http://www.jabber.org/jeps/inbox/sasl-anonymous.html
>> The Jabber Council will decide within 7 days (or at its next meeting) whether to accept this proposal as an official JEP.
> Although we didn't yet accept this proposal as a JEP, I want to comment
> on several aspects in the proposal.
> First off, I would like to ask people dealing with SASL mechanism
> specifications to remember this about the examples:
> In almost all examples, the used profile is IMAP (RFC 2060). This
> profile is different from ours in that IMAP has no way to have the
> command which initiates an authentication protocol exchange contains a
> so-called 'initial client response'. Thus an extra round trip is needed
> with the initial client response sent in response to an empty server
> challenge. The same goes for additional data sent along with the
> indication of a successful completion of the exchange as I outlined
> earlier [1] for the DIGEST-MD5 mechanism.
> In the XMPP SASL Profile, we *can* send this data along in one go, and
> should. Implementations like cyrus sasl have a flag you can set to do
> this properly.
> So, the proper exchange for this ANONYMOUS mechanism would be:
> C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='ANONYMOUS'/>
> S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
> or, in case of the optional trace information:
> C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='ANONYMOUS'>
>     c2lyaGM=
>    </auth>
> S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>

I've fixed the document accordingly.

> Also note that the ANONYMOUS mechanism specification never talks about
> using the trace information for relaying a request for a certain
> username. As I read it, this information is just used for tracing and
> there is some prose about how you should use this in RFC 2245. Maybe
> in-band registration (JEP-0077) is a better approach for requesting
> usernames.

We need to look more closely at the "trace" data. Currently it can be
either an email address or "an opaque string which does not contain the
'@' (U+0040) character and can be interpreted by the system
administrator of the client's domain." There is also a trace profile of
stringprep and we'd need to see how that might interact with the
Nodeprep profile we use in XMPP. So for now I've left that out of the JEP.

> This proposal links to draft-ietf-sasl-anon-05, but that has expired
> last november. I don't know about the status of the IETF SASL WG, but at
> least we should change this reference to RFC 2245 which
> draft-ietf-sasl-anon-05 aims to replace eventually. RFC 2245 is a
> Proposed Standard, while the draft has the status of 'expired'.

draft-ietf-sasl-anon-05 has been approved by the IESG and is in the RFC
Editor's Queue:



So it is just waiting for an RFC number and official publication.


- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060209/c1827a8d/attachment.bin>

More information about the Standards mailing list