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

Ralph Meijer jabber.org at ralphm.ik.nu
Wed Jan 25 09:29:25 UTC 2006

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'>
S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>

No challenges!

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

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'.

It would be nice to be able to use a future version of the draft,
however, since it allows full utf-8 instead of just US-ASCII. I believe
Peter knows some people in the SASL WG, so it might be helpful to invoke
those contacts.

[1] http://mail.jabber.org/pipermail/xmppwg/2005-November/002347.html



More information about the Standards mailing list