Justin Karneges wrote:
On Tuesday 25 March 2008 2:16 pm, Peter Saint-Andre wrote:
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'
mechanism='DIGEST-MD5'>=</auth>
challenge + response etc.
S: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<not-authorized/>
</failure>
C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='PLAIN'/>
The one trouble with this approach that I've discovered is that you can't
easily reprompt for a password. Suppose you have a client that doesn't save
a password, and prompts on demand. What should it do if DIGEST-MD5 returns
not-authorized?
The client should try a reasonable number of retries with the same SASL
mechanism.
The user could have just made a typo,
Indeed.
but instead we'll try
some other mechanism?
The client needs to retry the same mechanism several times, then
fallback to the next one, etc.
But this is a bit of oversimplification. There is one complication: some
mechanisms require password to be asked directly from the user (e.g.
DIGEST-MD5, CRAM-MD5, PLAIN), but others typically require the user to
specify the password before launching the application (e.g. to obtain
Kerberos ticket for GSSAPI). In the latter case there is no need to
retry: either the client has a valid Kerberos ticket or it doesn't.
However SASL APIs don't necessarily have a way of telling applications
about differences between the two types of mechanisms described above.
Weird. And we probably shouldn't prompt for the
fallback mechanisms.
I guess the unfortunate solution is something like this:
1) Try SASL mechs in some order.
2) If one asks for a password, prompt, cache, and use a password.
3) If another mech asks for a password, use the cached password.
If another mechanism asks for a password, it means that authentication
using the previous mechanism failed.
So the client might as well ask for the password again.
4) If all mechs fail, only then clear the password cache and start over.
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).
Also, if using a SASL library, probably the best approach to ensuring the
proper selection order is to remove the offending mechanism from the list and
retry again using the reduced list. Repeat until out of mechanisms.
Yes.
