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

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Tue, Mar 18, 2008 at 03:31:03PM +0100, Hallvard B Furuseth wrote:
> 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.

I don't agree.  SASL apps typically know how to negotiate SASL
mechanisms, so as long as the negotiation happens *somewhere* then you
can migrate.

My point was not about negotiation of hashes, but about what it means
from a user provisioning perspective.

One day your servers all have SCRAM HMAC-MD5 verifiers for your users'
names and passwords.  The next you want to move to SCRAM HMAC-SHA-224,
but you don't have any of those verifiers.  How do you complete the
migration, operationally?

Answers: somehow the users have to either re-enroll (kinda like changing
their passwords) or they have to somehow convey their new verifiers to
the servers.

So one thing we'll need is a flag from the server to the client saying
"you need to re-enroll" and/or "your password is expired."

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

Putting the hash negotiation inside SCRAM doesn't help you with that.

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

One problem with what you suggest is that I think you'll find the
community to be averse to creating more multi-level negotiation schemes.
We've learned from SPNEGO -- we've learned that we don't like it :(
Another problem is that it throws the possibility of privacy protection
for client names out the window (assuming we had PKIX-based mechanisms
that could provide such privacy protection); this is a much lesser
problem.

If there's any negotiation that really must be solved in a new way it
would have to be the "{mechanism, federation/island of trust}" problem.

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

Right.  I'm sure some operators will reject this option, so we need a
way to deal with that (see above).