Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?

From: Alexey Melnikov <[email-masked]>
Date: Sun, 06 Jul 2008 15:29:22 +0100

Hallvard B Furuseth wrote:

>Jeffrey Hutzelman writes:
>  
>
>>On Mon, 31 Mar 2008, Hallvard B Furuseth wrote:
>>    
>>
>>>I think security requires that it can return one list of mechanisms
>>>which will work and one with mechanisms which might work.  (Both subsets
>>>of those reachable without mechanism-negotiation, as you say below.)
>>>(...)
>>>      
>>>
>>I haven't fully paged this discussion back in yet, but...
>>    
>>
>:-)
>  
>
Replying to this message after guarantying that everybody paged out this 
conversion :-).

>>I don't think you actually want to distinguish between two lists,
>>because doing so provides no utility.  I agree that it should be OK to
>>offer mechanisms that won't actually work for this user.  Doing so
>>increases the chance that the client will choose one of those, causing
>>authentication to fail when it could have succeeded, but that's
>>unlikely in practice because often the client has been configured to
>>expect a particular mechanism.
>>    
>>
>But the reason I suggested a mechanism-negotiation mechanism in the
>first place was situations where different users have different
>such as when the site is upgrading from an old mechanism.
>
>If nothing else, a "will work" list can reduce the amount of user
>interaction:  The client can use that right ahead, but ask the user
>for help if there are only "might work" mechanisms.
>
>Alternatively the client could try several "might work" mechanisms in
>succession, but as I mentioned that can interfere with policy about
>max allowed failed logins.
>
A server enforcing this policy would have to distinguish between "lack 
of secret for this user and this mechanism" and "the supplied secret is 
incorrect".
If the server implementation doesn't do that, it is broken.

>Or for that matter different mechanisms
>can need different information from the user - and thus again more user
>interaction than necessary.
>  
>
A properly written client only need to ask for a password once, if the 
server can report back lack of secret.
But yes, this can be quite annoying for users otherwise.

As a side note: I think we really need to spend some time telling client 
implementors how to implement retries/fallback during SASL negotiation.

>The "might work" list might offer no utility when there is a "will work"
>mechanism, if so a single list with a "will work"-flag is enough.
>  
>