Re: CRAM-SHA1 support

[Simon Josefsson]

Lothar May <address@hidden> writes:

> Hi Simon,
>
> thank you for your prompt reply!
>
> 2009/8/28 Simon Josefsson <address@hidden>:
> [...]
>> The SASL WG has just completed a last call on SCRAM-SHA1 which is the
>> (long-awaited) replacement of both CRAM-MD5 and DIGEST-MD5.  I need to
>> find time to implement it in GNU SASL.  If anyone wants to help with the
>> implementation, that would be excellent.
>>
>> I'm aware that there are some libraries that support CRAM-SHA1, but it
>> is not standardized.  It would be easier to implement than CRAM-MD5.
>> However, because it is not standardized, and has some poor security
>> properties as well (SCRAM solves them, that's why it took so long to
>> complete) I'm not sure it is a good idea to support it.  Thoughts?
>>
>
> Do you mean this one:
> http://tools.ietf.org/html/draft-ietf-sasl-scram-05 ?

Yes.

> I've had a look at this also, and I like it, but it is quite complex.

Yes more complex than CRAM-MD5 indeed, but hopefully not entirely as
complex and ugly as DIGEST-MD5.

> I could not find any implementation of it. I've read completely
> through it, even before having a look at gsasl, and considered
> implementing it using gcrypt. There are several points I don't quite
> understand, above all this part:
>
>       AuthMessage     := client-first-message-bare + "," +
>                          server-first-message + "," +
>                          client-final-message-without-proof
>
> These messages are defined, but I don't understand their definitions:
>
>      client-final-message-without-proof =
>                        channel-binding "," nonce [","
>                        extensions]
>      channel-binding = "c=" base64
>                        ;; base64 encoding of cbind-input
>
> What is "cbind-input"? I don't quite get it, this is probably because
> I didn't yet read http://tools.ietf.org/html/rfc5056 about channel
> binding. It's kind of complex.

Yes, it is covered by RFC 5056 and in particular the 'tls-unique'
binding in this document:

http://tools.ietf.org/html/draft-altman-tls-channel-bindings-06

So the cbind-input data is the TLS finished message.

> Same for this:
>
>      client-first-message-bare =
>                        [reserved-mext ","]
>                        username "," nonce ["," extensions]
>
>      reserved-mext  = "m=" 1*(value-char)
>                        ;; Reserved for signalling mandatory extensions.
>                        ;; The exact syntax will be defined in
>                        ;; the future.
>
> There is an optional argument at the beginning. So the username
> "m=..." is not valid? Or do you have to count how many commas there
> are? This seems very strange. I have more questions like this, which
> tells me that I'm probably not the right one to implement this... :-/

The fields are comma-separated, and ',' needs to be escaped inside the
value-char's, check the definition of 'value-safe-char'.

If you have time to co-operate on an implementation, and are willing to
sign over copyright of your work to the FSF, we could collaborate on
doing the SCRAM implementation.  I have some preliminary code for it,
but have too little time to work on this right now. :-(

/Simon