Subject: IANA Hash Function Textual Names vs. SCRAM mechanism names

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 27 Jan 2009 19:31:25 +0100

Now that I'm looking at SCRAM again (draft-newman-auth-scram-07.txt):

> 4. SCRAM mechanism names
>
>    A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the
>    uppercased name of the underlying hashed function taken from the
>    IANA "Hash Function Textual Names" registry.

Thus SCRAM can only use hash functions with case-insensitive names
of max 9 of the characters [-_0-9A-Z].  See RFC 4422 section 3.1.

Is there anything to prevent "LongCaseSensitiveName/paramName(value)"
from being registered as a hash function?  I don't see anything in RFC
3279 or <http://www.iana.org/assignments/hash-function-text-names/>.
   
Should we obsolete RFC 3279 for one which requires somewhat friendlier
names?

Or do we defer any worry until it happens, and register aliases for new
SCRAM-unfriendly names if they arrive?  We'd need to keep that option
open anyway: I expect a 9-character limit on IANA hash function names
could be too restrictive, in particular if someone invents and registers
hash function family names.

-- 
Hallvard

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 27 Jan 2009 14:10:58 -0500

> Should we obsolete RFC 3279 for one which requires somewhat friendlier

Well, we certainly shouldn't obsolete RFC3279, which doesn't create that 
registry or specify its rules, but does specify names and OID's for a 
number of hash functions in wide use today.  Besides, it's not ours.

We also shouldn't obsolete RFC4572, which does create the registry and set 
its rules, but is mostly about specifying SDP over TLS.  Besides, it also 
is not ours.

In practice, I don't think we need to worry about it.  New names can be 
added to that registry only by standards-track RFC's which update or 
replace RFC3279, which is a pretty narrow category requiring fairly wide 
review.  I don't expect anyone will ever try to define a hash function name 
which is deliberately long, invalid, or ambiguous.

Note, BTW, that there is no such thing as a "case-insensitive name"; only 
case-insensitive treatment of names.  Regardless of what case might be used 
in registering a hash function name, we can still use it in a SASL 
mechanism name, unless/until there are two hash functions whose registered 
names differ only in case, which I somehow doubt would pass the review 
required for standards-track RFC's.

-- Jeff

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 27 Jan 2009 20:47:29 +0100

> its rules, but is mostly about specifying SDP over TLS.  Besides, it also 

Argh, I took the RFC name from the wrong browser window...  Anyway, I
didn't mean "we" would do it as in SASL taking it over, more like
someone doing whatever was required.  However,

> In practice, I don't think we need to worry about it.
>
> New names can be 

Fine by me.  As long as _someone_ who knows SASL keeps track.

> case-insensitive treatment of names.

Right, that was sloppy.

> Regardless of what case might be used in registering a hash function
> name, we can still use it in a SASL mechanism name, unless/until there
> are two hash functions whose registered names differ only in case,
> which I somehow doubt would pass the review required for
> standards-track RFC's.

Hopefully so.  I guess it's GS2 which has me worried.  It'd never have
occurred to me to worry that a SASL mechanism name might someday be
named something unreadable like "GS2-DT4PIK22T6APV2PY" either.
A similar idea but base64 instead of base32 and SASL would be in
trouble.  Or lowercase(base64()), since I too would expect required
case-sensitive treatment to raise loud protests.

-- 
Hallvard

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 27 Jan 2009 15:17:17 -0500

> case-sensitive treatment to raise loud protests.

Well, GS2 is a SASL mechanism family, and so was designed specifically with 
the requirements of SASL in mind.  Compare to RFC4462, which defines a 
family of GSS-API-based SSH key exchange algorithms using a similar 
technique, but based on the requirements of SSH.

-- Jeff

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Jan 2009 21:08:27 +0000

>of max 9 of the characters [-_0-9A-Z].  See RFC 4422 section 3.1.
Yes, I've raised this issue myself.

>Should we obsolete RFC 3279 for one which requires somewhat friendlier
I agree with Jeff that we shouldn't obsolete this RFC. But we can try to 
put extra restrictions on the registry.

>Or do we defer any worry until it happens,
>
That too.

>and register aliases for new

Jeffrey Hutzelman wrote:
 [...]

> In practice, I don't think we need to worry about it.  New names can 
> be added to that registry only by standards-track RFC's which update 
> or replace RFC3279, which is a pretty narrow category requiring fairly 
> wide review.  I don't expect anyone will ever try to define a hash 
> function name which is deliberately long, invalid, or ambiguous.

Agreed.

> Note, BTW, that there is no such thing as a "case-insensitive name"; 
> only case-insensitive treatment of names.  Regardless of what case 
> might be used in registering a hash function name, we can still use it 
> in a SASL mechanism name, unless/until there are two hash functions 
> whose registered names differ only in case, which I somehow doubt 
> would pass the review required for standards-track RFC's.