Re: GNU SASL Summer of Code

[Francis Brosnan Blazquez]

Hi Simon!

> Hi Francis!  DIGEST-MD5 have some problems:
> 
> * Implementation complexity.  The security layers
>   (encryption/integrity) doesn't interop well, and have security
>   issues.
> 
> * Security concerns.  It is built on MD5 and a non-standard MAC mode.
> 
> Anyway, there were long discussions about this at the last IETF, the
> summary is http://article.gmane.org/gmane.ietf.sasl/2818 which says:
> 
>   Given problems with DIGEST-MD5 in terms of interoperability and
>   implementability, there appears to be consensus to move DIGEST-MD5
>   (in the form of RFC 2831) to Historic.
> 
> However, in practice, there is no alternative yet, although there were
> presentations on three different password-based mechanisms at the
> meeting.  They all used HMAC with SHA-256, or similar, which is much
> better than CRAM/DIGEST-MD5 and they all looked quite easy to
> implement (similar to CRAM-MD5 complexity).  I'm working a on a fourth
> proposal myself (written as a GSS-API mechanism).

Sure! I've been following your proposal at the draf list [1] but I
didn't know the intention to be a replacement for CRAM/DIGEST-MD5. Nice
job Simon! 

Currently we are working on a general BEEP application server, which,
among other things, will include already implemented tools to manage
users, etc for the SASL layer.

Until today, the intention was to support PLAIN, CRAM-MD5 and DIGEST-MD5
as default mechanism. However, as you know, CRAM-MD5 and DIGEST-MD5
server side callbacks requires the application to return the clear text
passwords (which is a problem if you pretend to store passwords already
hashed).

My intention was to take a look into the gsasl code to make possible for
CRAM/DIGEST-MD5 to return already hashed password to the gsasl engine.
It this possible Simon or there are protocol problems that can be
solved?

Would your new SASL proposal allow authentication without requiring to
provide clear text passwords?

> To me, this makes it clear that DIGEST-MD5 isn't the future, and it
> doesn't make sense to spend any more time working on improving it for
> GSASL.

Thanks for the info and the work you are doing Simon!

> /Simon

[1] http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-07.txt
-- 
Francis Brosnan Blazquez <address@hidden>
Advanced Software Production Line, S.L.