Re: GNU SASL Summer of Code

[Simon Josefsson]

Francis Brosnan Blazquez <address@hidden> writes:

> 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! 

Hi Francis!

Actually, GS2 is just the framework that permit a replacement for
CRAM/DIGEST-MD5, my specific proposal for the replacement is not
finished nor submitted yet, but I'm working on it:

http://josefsson.org/gss-hmac/

> 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?

For CRAM-MD5, it is more difficult to do this, because you need to
store two intermediate hash states:

        MD5((tanstaaftanstaaf XOR opad),
            MD5((tanstaaftanstaaf XOR ipad),
            <address@hidden>))

The password here is 'tanstaaftanstaaf'.  GNU SASL doesn't support
this, and it is some work to do it because you'll need to export the
MD5 hash state, which we don't have crypto APIs for right now.

For DIGEST-MD5, it is easier to support this, because you can store
the entire hash output:

      A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
           ":", nonce-value, ":", cnonce-value, ":", authzid-value }

You'll store the H(...) value on disk.  GNU SASL doesn't support this
now, but making this work is easy, you'll have the create a new
"property" and have digest-md5/server.c use it instead of this code:

      /* Compute secret.  TODO: Add callback to retrieve hashed
         secret. */
      {
        const char *c;
        char *tmp, *tmp2;

        c = gsasl_property_get (sctx, GSASL_PASSWORD);
        if (!c)
          return GSASL_NO_PASSWORD;

        if (asprintf (&tmp, "%s:%s:%s", state->response.username,
                      state->response.realm ?
                      state->response.realm : "", c) < 0)
          return GSASL_MALLOC_ERROR;

        rc = gsasl_md5 (tmp, strlen (tmp), &tmp2);
        free (tmp);
        if (rc != GSASL_OK)
          return rc;
        memcpy (state->secret, tmp2, DIGEST_MD5_LENGTH);
        free (tmp2);
      }

So rather than asking for the password property, it would ask for a
(say) GSASL_HASHED_PASSWORD_DIGEST_MD5 property.

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

Yes.

>> 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!

Thanks for your support, Francis!

/Simon