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

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Mon, Mar 17, 2008 at 05:05:31PM +0100, Simon Josefsson wrote:
> While thinking about merging SCRAM with my document, I thought about how
> to handle crypto algorithm agility.  To recap what we have today:

Funny you should ask.  Sam and I, while discussing how to represent
SCRAM+GS2 in ABNF, both agreed that the hash function used by SCRAM
should be part of its OID.

We also agreed that SCRAM should use PBKDF-2 instead of that Hi()
function (PBKDF-2 does nto add much complexity).

I need to finish writing up the text to go with that ABNF...

> 1) SCRAM hard code use of HMAC.  It only specify MD5 today.  It has
> extensibility to allow for other hashes (the "h=md5" variable), but
> replacing HMAC is not possible.

I've seen no reason to think that the HMAC construction is insecure or
will be any time soon such that simply using a stronger hash function
won't suffice.

Sure, it could happen, but then, if the hash can be negotiated via
standard SASL mechanism negotiation, then so should the MAC.

> Over the weekend I had a chance to reflect on this.  I have changed my
> mind and now believe that it would be nicer to avoid having to specify
> and describe crypto negotiation in the mechanism.

That's exactly the right thing to do.

> The primary reason is that both SASL and GSS-API are flexible protocols
> in themselves and can negotiate between mechanisms of different
> strengths.  There is no strong need for SASL mechanisms or GSS-API
> mechanisms to have crypto agility, as far as I can tell.
> 
> Further, the complexity in DIGEST-MD5 compared to CRAM-MD5 stems
> (partially) from having to negotiate various things.  The more we can
> avoid having to negotiate, the simpler the wire protocol becomes.  The
> specification becomes less complex as well.  The crypto negotiation is
> not different from character set or security layer negotiations in this
> aspect.

I agree, fully.

> If we hard code the crypto mechanism, and the underlying crypto is
> broken, we would need to publish a new document that is a search-replace
> s/HMAC-MD5/XMAC-SHA3/ or whatever.  It would have a new SASL mechanism
> name and a new GSS-API object identifier.  This can be simpler than
> specifying a "profile" or "extension" of the base protocol, which needs
> to handle backwards compatibility issues and upgrade to a new algorithm.
> 
> This approach also allows the framework (i.e., SASL and GSS-API) to be
> able to quantify the strength of the mechanism better.

And it avoids multi-layer negotiation issues.  It makes the list of
mechanisms longer.  And so it may make things seem more complicated.

In particular putting algos into the mech name/OID may leak into user
visible UIs in ways that may not seem helpful.

E.g., imagine that we did this for the krb5 GSS mech, and so for
RPCSEC_GSS, so then when sharing via NFS one would would have a larger
choice of RPCSEC_GSS triples to select from -- "share -o
sec=krb5-aes256-i,..." instead of "share -o sec=krb5i ...", say.

At first glance that's annoying, but on the other hand, it gives the
administrator (and user) better control over what algorithms are used.
That may be a good thing.  And we can always have a special alias in the
UI that refers to the set of mechanisms based on SCRAM/krb5/... but
without regard to algorithms.

> Thus my suggestion is to hard code the crypto algorithm in SCRAMng,
> following the simplicity of CRAM-MD5.
> 
> What do others think about this proposal?

Yes please.

> As for the mechanism to use, I would prefer HMAC-SHA1 or HMAC-SHA256
> over HMAC-MD5.  I think there are some arguments for moving away from
> HMAC, and use things like OMAC, but I don't think this mechanism is the
> best place to experiment with that.

Absolutely.  No more MD5 anywhere.

> I want to stress that I think the choice of a particular algorithm is
> less important than the larger design approach question outline in this
> email, though.

More agreement.

Nico
--