[Standards] [Fwd: I-D Action:draft-melnikov-digest-to-historic-00.txt]

Dave Cridland dave at cridland.net
Tue Sep 11 13:24:13 UTC 2007


On Tue Sep 11 11:55:35 2007, Jonathan Chayce Dickinson wrote:
> Interesting because most clients used Digest-MD5, so what do we use  
> now?
> Cram-MD5? Or is there some other newfangled method out there?
> 
> 
DIGEST-MD5 is still more secure than CRAM-MD5, and this won't change  
because of that draft. :-)

Some background - since I work with both Alexey and Kurt, one of the  
chairs of the working group that issued this, as well as being in the  
SASL WG in Prague where this was decided.

One upon a time, there was a mechanism called CRAM-MD5, which was  
thought up as a simple challenge response mechanism. But, it's got a  
number of weaknesses, the most important two being that its use of  
MD5 is weak, and it more or less stores the password in the clear on  
the server.

So, a number of replacement mechanisms were proposed. HTTP,  
meanwhile, had developed Digest auth, and looking to unify HTTP auth  
and SASL, Chris Newman abandoned his own mechanism, and instead  
devoted much energy to getting a variant of Digest as a SASL  
mechanism - which became DIGEST-MD5.

However, DIGEST-MD5 has a considerable amount of problems - these are  
documented in the draft. Eventually, the SASL WG decided to abandon  
its attempts to fix it, since it was exceedingly difficult to bring  
it up to date, and some problems were simply beyond fixing.

Seeing this coming, a number of people decided to address the niche  
by designing a new password based mechanism which had approximately  
the same properties, but was more secure. These were:

HEXA (By Alexey and myself).
SCRAM-MD5 - a reissue and revamp of Chris Newman's original  
mechanism, by Abhijit Menon-Sen (Who, if he reads this, will no doubt  
correct my spelling). (Actually, it's SCRAM-*, now, as it's sprouted  
hash agility).
YAP-* - a mechanism family intended to replace PLAIN in some  
circumstances for RTT-sensitive applications, and also replace  
CRAM-MD5 entirely.

In Prague, all three were presented and discussed at length, and we  
decided to fold in the good bits of HEXA into SCRAM-MD5 and proceed  
with SCRAM and YAP, ditching DIGEST-MD5 (and saving Alexey and me  
lots of typing). SCRAM was designed a decade ago, and has actually  
seen some limited deployment. I'd heartily recommend examining it  
closely. Alexey and I hadn't actually read it when we designed HEXA  
(in a pub, on the back of a beermat), although the two come out  
looking very similar - both use "The Powerful XOR Encryption  
Algorithm", as I like to call it.

So the short answer is: Carry on using DIGEST-MD5 until a replacement  
comes out, watch SCRAM-* as a functional replacement, watch YAP-* as  
a functional replacement for CRAM and PLAIN. If you're clear on the  
patent situation - I'm not - then you may wish to look at SRP, which  
seems more secure than any of these.

Some references for those willing to try the bleeding edge:

http://tools.ietf.org/html/draft-cridland-sasl-hexa-00
http://tools.ietf.org/id/draft-newman-auth-scram-04.txt
http://tools.ietf.org/wg/sasl/draft-zeilenga-sasl-yap-01.txt

The last two are actively worked on, and I'm sure the authors would  
be interested in comments. The first is just included for  
completeness.

Hope this helps.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list