[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
--On Tuesday, March 18, 2008 06:01:10 PM +0100 Hallvard B Furuseth
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
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).
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.
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
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.
Nico is right, and not. A mechanism-negotiating mechanism is generally a
bad idea, except when it is the _only_ mechanism an application is allowed
to use. An application which does its own mechanism negotiation (as all
SASL applications do) generally should not use mechanism-negotiation
However, there are some exceptions. I don't see a problem with using a
mechanism-negotiation mechanism such as you describe, provided that the set
of mechanisms offered by the negotiation MUST be exactly the subset of the
original offering which could work for the current user. The theory here
is that there are no mechanisms which are reachable only via the
negotiation mechanism (as would be the case with, for example, GS2+SPNEGO)
_and_ any mechanism in the original set which is not offered in the
second-level negotiation wouldn't have worked anyway.
Similarly, I think providing hash negotiation within SCRAM rather than
making the hash part of the mechanism name is not as bad as it sounds.
This is similar to selecting a Kerberos mechanism and then having to agree
on an enctype(*). The client knows what algorithms it supports, and is
capable of supporting any of them for any user. The server knows for which
algorithms it has a secret for this user. If there is no overlap, then
authentication with that mechanism isn't going to work, and doing
negotiation at the next layer up isn't going to help.
In practice, I suspect that the vast majority of SASL application clients
require the user to specify the mechanism to be used, and the question is
only "can the server support the mechanism the user selected?". If we ever
want that to change, for example to support migration from DIGEST-MD5 to
SCRAM or from SCRAM to some other password-based mechanism, the negotiation
mechanism you describe might not be a bad idea.
(*) It's not actually identical, because in Kerberos this actually happens
when a service ticket is issued by the KDC, which knows which enctypes a
server supports. In addition, a Kerberos application server's set of
supported enctypes is not ever client-dependent (though the question of
whether there is an overlap may be). This means that for Kerberos, a
clever client can try obtaining a service ticket _before_ mechanism
negotiation, and not trying the mechanism if it couldn't get a ticket.
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
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, of course, you do this:
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.
Which seems to me like an entirely reasonable approach for people who are
concerned about that issue.