Subject: A minor problem with SCRAM-HMAC-SHA-1-PLUS mechanism name

From: Alexey Melnikov <[email-masked]>
Date: Fri, 27 Mar 2009 21:02:13 -0700

If I can still count, it is 21 US-ASCII character long. But SASL allows 
at most 20 (as per RFC 4422).

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 01 Apr 2009 23:52:02 -0400

> at most 20 (as per RFC 4422).

Hrm.  Well, we can't s/-PLUS/+/, as plus is not allowed.

For starters, I think we should not algorithmically modify mechanism names; 
instead, any GSS-API mechanism (including SCRAM) that wishes to define 
friendly SASL mechanism names should define two such names, for the "PLUS" 
and "non-PLUS" cases.  This makes it easier to express the requirement that 
these names be registered in the SASL mechanism name registry and not 
conflict with the names of any existing (or future) SASL mechanisms.

Secondly, I'd propose including the "plus" bit before the algorithm:

GS2B-oidoidoidoidoid (basic)
GS2P-oidoidoidoidoid (plus)

SCRAM_B-HMAC-SHA-1   (basic)
SCRAM_P-HMAC-SHA-1   (plus)
SCRAM_P-HMAC-SHA-256 (plus)

Thirdly, if we are in a pinch, we can abbreviate, like s/SHA-1/SHA1/ or 
removing or abbreviating the "HMAC" component, which is mostly redundant.

Finally...  What in the world were jgm et al thinking, limiting mechanism 
names to 20 characters and a relatively small symbol set?  Now there are 
only 3.12E+39 possible SASL mechanism names; what ever will we do?

-- Jeff

---

From: Dave Cridland <[email-masked]>
Date: Thu, 02 Apr 2009 10:58:47 +0100

On Thu Apr  2 04:52:02 2009, Jeffrey Hutzelman wrote:
> Finally...  What in the world were jgm et al thinking, limiting  
> mechanism names to 20 characters and a relatively small symbol set?  
>  Now there are only 3.12E+39 possible SASL mechanism names; what  
> ever will we do?

There's also the pressing problem of internationalized SASL mechanism  
names.

Oh, wait, what day is it?

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Apr 2009 11:09:25 -0500

> conflict with the names of any existing (or future) SASL mechanisms.

OTOH, having a common affix for "server supports channel binding" makes
it easier to implement a common mechanism selection function in a
client-side SASL framework.

Yes, it wouldn't be hard for such a framework to ask each mechanism
plugin what names it has and which indicate "server supports channel
binding"...

> SCRAM_P-HMAC-SHA-256 (plus)

Chris believes that mechanism names will leak into configuration UIs,
and that therefore it's important that the -PLUS affix be meaningful to
humans.  I think we can leave the affix as an implementation detail
(e.g., the user configured "SCRAM" but the client and server will
understand that SCRAM-PLUS is also allowed unless the user specifically
disallowed channel binding).

> removing or abbreviating the "HMAC" component, which is mostly redundant.

Chris proposed that we just call it "SCRAM1" -- we don't need the
algorithm names in the mechanism name.  I agree with that.  That way the
-PLUS suffix becomes a non-issue for SCRAM (it's already a non-issue for
GS2 -- see the latest GS2 I-D).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 2 Apr 2009 11:02:48 -0500

> Oh, wait, what day is it?

A day too late :)

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 02 Apr 2009 12:33:06 -0400

> Chris believes that mechanism names will leak into configuration UIs,

...

> algorithm names in the mechanism name.  I agree with that.

These positions seem to be inconsistent.  If the mechanism names are going 
to leak into the UI, then I think we owe it to users to use a name that is 
actually descriptive of the mechanism.  I'd much rather have "SCRAM-SHA-1" 
and "SCRAM-SHA-256" and "SCRAM-SHA-3" than "SCRAM1", "SCRAM2", and 
"SCRAM3"; the latter are fairly useless.

I can accept the argument that the -PLUS needs to be meaningful to humans, 
though I suspect the right answer here is that those mechanisms should be 
hidden in configuration UI's -- the UI should treat SCRAM and SCRAM-PLUS as 
if they were the same mechanism, and choose between them appropriately. 
But if we use an affix like -PLUS, we're effectively limiting GSS-API 
mechanisms (and potentially, any mechanism with autonegotiated optional CB 
support) to a 15-character base name.  The GS2 spec should make this clear.

> see the latest GS2 I-D)

I tried, but I couldn't figure out which one it is. :-(