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

[Hallvard B Furuseth <h.b.furuseth@xxxxxxxxxxx>]

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...

:-)

> 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.  Or for that matter different mechanisms
can need different information from the user - and thus again more user
interaction than necessary.

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.

> I believe there is a tradeoff between the "security" of not exposing
> information about which mechanisms work for which users and the potential
> interoperability problems caused by advertising mechanisms that won't
> actually work.  It is appropriate for this tradeoff to be a matter of
> policy.

Yes.  I'd just like to inform the client what it can expect beforehand.

> Similarly, there is no problem advertising some set of mechanisms for a
> user that does not actually exist, as a way of hiding information about
> wich users exist.

Well, there is: I still don't know how to do it right.  See my messages
"Hide presence/absence of users in server (HEXA, SCRAM)" of 30 Apr 2007.
But no extra problem compared with mech="SCRAM" with hash negotiation.

> The important properties are these:
>
>>> The theory here
>>> is that there are no mechanisms which are reachable only via the
>>> negotiation mechanism (as would be the case with, for example, GS2+SPNEGO)
>>> _and_ any mechanism in the original set which is not offered in the
>>> second-level negotiation wouldn't have worked anyway.

Yup.

-- 
Hallvard