Subject: SCRAM-HMAC-<<hash>> vs GS2-<<whatever>>

From: Dave Cridland <[email-masked]>
Date: Wed, 18 Feb 2009 14:06:37 +0000

I'm not subscribed to the list, please copy me in on replies.

As someone who's spent a considerable time lately working with client  
developers of both MUAs and more recently XMPP, I'd like to describe  
what happens in those communities, particularly for XMPP.

XMPP's MTI SASL mechanism is currently DIGEST-MD5. This has to  
change. Operators and developers alike want a mechanism that doesn't  
store passwords in plaintext and doesn't send them in the clear  
either. SCRAM fits the bill very nicely, and is also relatively  
simple to code. Most client developers, especially, write their SASL  
mechanisms themselves - no libraries used - so a mechanism which is  
relatively straightforward to code in a number of common languages is  
important to us.

The GS2-<<whatever>> variant isn't much harder - although I suspect  
it is marginally more complex after reviewing them both. However, I  
feel strongly that although from a technical perspective there's  
little difference, the naming and use of GS2 will have a significant  
impact on deployment. In particular:

1) The simple fact it's using GSSAPI is enough to put many people off.

2) The name, by not being recognisable, would, I suspect, tend to  
mean that client developers don't notice the deployment, and won't  
follow up to see what the mechanism is. A SCRAM-HMAC-* name would,  
after all, be noticed much more easily in protocol logs, etc.

3) A SCRAM-HMAC-* name allows for new hash support to be obvious, and  
moreover allows for some implementations to switch in new hashes much  
more easily, by simple switching based on the name. GS2-<<whatever>>  
doesn't allow a developer to find out what hashes are supported very  
easily - indeed, the encrypted name means a brute-force attack is  
required.

None of this argues against there being a SCRAM-compatible GSSAPI  
mechanism, of course, but it does argue that a pure-SASL mechanism is  
useful to make available, and in some respects is actually going to  
be more secure, if only due to increased deployment and hash agility  
that's acted upon.

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