[Standards] rfc3920bis: SASL "fallback" on auth failure

Peter Saint-Andre stpeter at stpeter.im
Tue Mar 25 21:16:14 UTC 2008

Evan Schoenberg of the Adium project pinged offlist regarding the proper
behavior for a client to follow if SASL authentication fails using one
mechanism but other mechanisms are available. I think a flow like the
following makes sense (I ran this by Alexey Melnikov and he concurred).

C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'

challenge + response etc.

S: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>

C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'

Alexey pointed out that we probably need to specify some text like this:

   SASL mechanisms MUST be tried in the order of their strength as
   perceived by the client (assuming the client has this information).
   For example, if the server advertises "PLAIN DIGEST-MD5 GSSAPI" or
   "DIGEST-MD5 GSSAPI PLAIN", the client should try GSSAPI first, then
   DIGEST-MD5, then PLAIN. The client should also be able to disallow
   some mechanisms (e.g. PLAIN).


Peter Saint-Andre

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

More information about the Standards mailing list