--On Tuesday, March 18, 2008 06:01:10 PM +0100 Hallvard B Furuseth <h.b.furuseth@xxxxxxxxxxx> wrote:
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 usersSCRAM-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.
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.
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 mechanisms.
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 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, 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.
-- Jeff