[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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.