Peter Saint-Andre wrote:
On 03/26/2008 4:48 AM, Maciek Niedzielski wrote:
Alexey Melnikov pisze:
Ralph Meijer wrote:
On Tue, 2008-03-25 at 15:16 -0600, 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.
[..]
If one mechanism fails with <not-authorized/>, why would another one
succeed, exactly?
Because different mechanisms might be using different authentication
databases. For example DIGEST-MD5 and GSSAPI.
Is it usually possible for the server to know that failure was caused by
using wrong method?
"Wrong" in what sense? Any given SASL mechanism might be enabled for one
user and not for another, this is a [server] implementation choice.
So yes, the server typically knows, but for security reasons the server
should not disclose to the client the difference between the client
providing a wrong password (but the user account exists for the
specified SASL mechanism) and the client providing password for a
non-existing account. Section 7.5.7 of
draft-saintandre-rfc3920bis-04.txt already says that.
If yes, maybe it would be worth adding a different
error for this case?
As far as I can see there is not separate error for this case, but I may
be missing something. Perhaps Alexey Melnikov can shed some light on
this for us. :)
I think the server shouldn't disclose the difference between the two
cases I've mentioned above. Which means that no new error response is
needed and that the client has to treat <not-authorized/> as "ask the
user for password again, if asked too many times, then move on to the
next SASL mechanism".
However you might want to add "account disabled" error response, because
it requires different action from the user (e.g. to phone a sysadmin)
