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

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

Jeffrey Hutzelman writes:
><h.b.furuseth@xxxxxxxxxxx> wrote:
>>Nicolas Williams writes:
>>>On Tue, Mar 18, 2008 at 03:31:03PM +0100, Hallvard B Furuseth wrote:
>>>> 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, (...)
>
> 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.

I think security requires that it can return one list of mechanisms
which will work and one with mechanisms which might work.  (Both subsets
of those reachable without mechanism-negotiation, as you say below.)

Otherwise the mechanism-negotiation mechanism could reveal information
which would not be revealed by the chosen mechanism.  (E.g. over an
unencrypted connection, with a mechanism which encrypts the exchange.)

The "might work" list would consist of all supported mechanisms which
would disclose information the admin(?) thinks should be hidden if they
were sent in the "will work" list, or something like that.
(If the user does not exist, the "will work" list could still contain a
suggested mechanism - where authentication would successfully fail:-)

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

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

Except it seems much harder to do it than for an attacker to analyze it.
But my point here was just that I don't see the difference between SCRAM
and a mechanism-negotiation mechanism in this regard.  Unless i
misunderstood what Nico was talking about.

-- 
Hallvard