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

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

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