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

[Peter Saint-Andre]

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? 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. :)

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Alexey Melnikov]

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)

[Peter Saint-Andre]

On 06/04/2008 7:56 AM, Alexey Melnikov wrote:
> 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".

+1

> However you might want to add "account disabled" error response, because
> it requires different action from the user (e.g. to phone a sysadmin)

Yes I added that in the latest version:

http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-05.html#sasl-errors-account-disabled

Peter

--
Peter Saint-Andre
https://stpeter.im/