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

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

Nicolas Williams writes:
>On Tue, Mar 18, 2008 at 08:41:46PM +0100, Hallvard B Furuseth wrote:
>>Simon Josefsson writes:
>>> Can we get away with specifying both SCRAM-SHA1 and SCRAM-SHA224 and say
>>> that servers MUST support both and clients MAY support either?
>
> I think you can say that the server MUST implement both and the client
> MUST implement at least one.  (I think that's what you meant.)
>
>> I don't see what good that does.  The server MUST support both, likely
>> only one password hash is _stored_ in it.  A client which only supports
>> the other can't authenticate.
>
> Right, we'd have to say that the server must also store both sets of
> verifiers and credentials.

No thanks.  "The server implementation SHALL NOT allow a user's
SCRAM-SHA224 or SCRAM-SHA1 credentials to be stored, deleted or replaced
without also updating the other one".  I don't want that bit of code in
the server.  Nor do I want to define it as a user error to only store
one of the values, if the server silently accepts it.

One could define a combined (sha1, sha224) server secret so it can be
administered and e.g. stored in an LDAP attribute as a single value.
Also fairly ugly.

>> You can say that clients MUST support both and servers MAY support
>> either.
>
> That too, but I think Simon is arguing that SHA-* are probably available
> on all server platforms, but not necessarily on all clients, so by
> giving the client a choice we may improve deployability without making
> it too hard to drop one of these hash functions later.

Tradeoff between deployability and interoperability, then.  I prefer
Simon's suggestion over mine or yours.  No opinion of whether that's
better than requireing a single mech.

But come to think of it, which spec are we talking about now?  A
mechanism "SCRAM" spec with a hash function parameter, like before?  Or
a SASL implementation in general?  For the latter my objections are moot
because server admins have enough options to create interoperability
anway.

-- 
Hallvard