[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
I support use of HMAC. CRAM-MD5 demonstrated it is deployable in apps, there are published test vectors in RFCs for it we can reference, and although the security benefit is not overwhelming IMHO, it has clear benefits due to the attacks on concatenated hashes.
I am not convinced the security value of PBKDF-2 offsets the additional complexity it adds. Remember there is negative security benefit if we use PBKDF-2 and the additional complexity pushes the mechanism over the edge into the "not worth implementing" category. It may be not a lot of complexity, but every bit matters.
I support using the mechanism name for algorithm agility and not having sub-negotiation. This is a tradeoff. The sub-negotiation occurs after the user is identified so it provides significant usability enhancements when it's actually necessary to perform an algorithm migration. However, in retrospect I believe the complexity cost to the mechanism outweighs the benefit. It's more important to get a mechanism we can deploy now and work out the operational details of hash migration later. The additional complexity of sub-negotiation for the hash adds too much risk the mechanism won't deploy. It doesn't matter how usable the hash migration happens to be if the mechanism doesn't deploy.
While I would personally be fine with abandoning MD5 in favor of SHA1 given my code toolkit has both algorithms, I'm concerned about the impact. Everyone's code toolkit includes MD5, but use of SHA1 is quite rare in applications at the moment. Switching away from MD5 will create a deployment barrier. Again, it doesn't matter how much more secure SHA1 is than MD5 if the SHA1-based mechanism doesn't deploy and an MD5-based one might have deployed. I'd like to hear from other SASL implementers before making a firm decision on this one: do you have SHA1 in your code toolkit? If not, how hard would it be to add it and would that be a deployment barrier? 

		- Chris
--On March 17, 2008 17:05:31 +0100 Simon Josefsson <simon@xxxxxxxxxxxxx> wrote: 



While thinking about merging SCRAM with my document, I thought about how
to handle crypto algorithm agility.  To recap what we have today:

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.

2) In draft-josefsson-password-auth the core protocol doesn't care about
which crypto algorithm is used.  It lets the GSS-API OID infer which
crypto parameters are used.  The default and only specified algorithm at
this point is HMAC-SHA-256.  It is possible to specify an HMAC-SHA1, or
OMAC-based, profile by using a new OID, and be consistent with my draft.

My initial reaction when merging my ideas with SCRAM is that it would be
nice to have more complete crypto agility in SCRAM.  In other words,
allow not only the hash be specified but also the entire authentication
algorithm (e.g., HMAC, OMAC), as I did in password-auth.

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.

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.

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.

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?

Am I missing some reason to offer crypto agility in the SASL or GSS-API
mechanism, that gives any value compared to re-using the mechanism
agility already present in SASL and GSS-API?

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.

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.

/Simon