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

Are we talking about different things?

User A: server secret (mech SCRAM: (hash MD5:  (salt s, ...))
User B: server secret (mech SCRAM: (hash SHA1: (salt t, ...))

The client sends auth(SCRAM, user A, <supports: MD5,SHA1,DES>)
and receives server challenge (MD5, nonce, salt s, etc).

vs:

User A: server secret (mech SCRAM-HMAC-MD5:  (salt s, iter 128, etc)).
User B: server secret (mech SCRAM-HMAC-SHA1: (salt t, iter 160, etc)).

The server announces support for SCRAM-HMAC-MD5 and SCRAM-HMAC-SHA1, but
the client doesn't know which is stored for that user, the admin doesn't
want it or him to need to know either beyond "SCRAM", and the server
response to one SASL mechanism doesn't tell which other mechansism to
try instead for that user.

So "negotiating" the hash function must consist of trying each mechanism
both client and server supports until one of them works.  Which also
interferes with "allowed failed login attempts" policy.

Or one could implement some other way to ask the server which mechanism
to use for that server, which loses the advantage of using SASL in the
first place.

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

Yes...

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

Yes.  And if accounts using old and new style hashes can coexist, we
don't need to tell everyone to re-enroll at the same time.  Instad we
can relay on password expiry policy which ought to be in place anyway.

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

Yes, that's what I said.  It helps if both variants are SCRAM, but not
otherwise.

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

Too bad.  Then my objection is stronger than I hoped...  Not sure
how strong though.  I haven't implemented SASL myself, so I don't know
about the complexity issues people are talking about.

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

In this case, how?  If you mean it discloses the existence of a user, so
does trying to auth as that user with a particular SCRAM mechanism.
Unless the server sends a challenge which looks like the user exists
whether he does or not - which again can be done in both cases.

-- 
Hallvard