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

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

Nicolas Williams writes:
> Incidentally, for a mechanism like SCRAM deploying a new hash
> implies re-enrolling all users

SCRAM-HMAC-MD5 implies it if that's what you mean.  SCRAM with
negotiated hash does not, it allows a mixture of new-hash and old-hash
accounts.  With a site policy to delete X days old passwords, the old
hash gets phased out as a side effect and most users won't even notice.

That's a problem with SASL deployment in general though.  When the day
comes for a site to replace SCRAM-HMAC-MD5, it might be in favor of a
non-SCRAM mechanism.  Then it doesn't matter whether or not SCRAM
supports hash algorithm negotiation.

It might make sense to instead define a "wrapper" auth mechanism: The
client sends (user, supported mechanisms), receives a challenge with the
desired mechanism name for that user, and then proceeds with that
mechanism.  Costs one round-trip extra and likely complicates the
security considerations.

> (alternatively: the enrolment site keeps all passwords in the clear;
> ugh).

Not that bad.  The enrolment site keeps public-key encrypted passwords
and locks the private key down in dark dungeon.  Though I imagine the
practical side can still be a pain, e.g. to keep the dungeon dark enough
and be able to formally claim that it is.

-- 
Hallvard