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

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Nicolas Williams <Nicolas.Williams@xxxxxxx> 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.)

Yes.

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

Yes, I meant that too.

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

Exactly.

Server implementations could have very similar code for both SCRAM-SHA1
and SCRAM-SHA256 (not sure why I wrote SHA224 up there, nobody is
advocating for HMAC-SHA224, right?) and the shared secret for the user
stored in the database should contain both the SHA-1 and SHA-256
version.  The implementation must make guarantee consistency between the
two fields, never update the sha-1 password without also updating the
sha-256 password.

If this approach would ease Chris' concerns about SHA-2, I think it is a
reasonable compromise.

/Simon