Subject: [kitten] Enctype agility in SCRAM?

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Jun 2011 22:51:08 +0200

How is the enctype algorithm agility supposed to work in SCRAM?

Recall that the SCRAM GSS-API mechanism hard codes the use of
"aes128-cts-hmac-sha1-96" for per-message tokens and GSS_Pseudo_random.

Let's say someone breaks "aes128-cts-hmac-sha1-96", or we for some
reason just wants to use something else.  How would this be done?  I'm
thinking we would need to specify both a new SASL name and a new GSS-API
OID for the new mechanism, but unfortunately, this won't be backwards
compatible with existing native-SASL implementations of SCRAM.  Is there
some alternative?  If we only change the OID, how would
GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname work?

/Simon

---

From: Nico Williams <[email-masked]>
Date: Tue, 14 Jun 2011 17:04:28 -0500

> "aes128-cts-hmac-sha1-96" for per-message tokens and GSS_Pseudo_random.

It also uses HMAC-SHA-1 for the security context tokens.

If you want a different suite of algorithms then you must assign a new
OID (and SASL mech name, if you don't want the hash-of-OID name) to
SCRAM with that suite.  We explicitly made this choice.

> GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname work?

Adding suite negotiation in the mechanism wouldn't change the fact
that to add a new suite is not enough: you must also deploy it widely
if you want that suite to be used.

And suite negotiation in the mechanism is a form of two-layer
negotiation, with all attendant issues.  It is important that we avoid
it as much as possible (I know, we didn't avoid this in the case of
Kerberos, but there we had decades of having done it one way, so we
stuck to it).

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 15 Jun 2011 11:26:48 +0200

> SCRAM with that suite.  We explicitly made this choice.

Ok thanks, that resolves my question.  I think there would be
significant operational problems making this change, but I can't think
of any better solution.  Part of the problem is that there is no benefit
for native-SASL implementers to support the new mech, they will be
identical on the SASL-wire.

/Simon