Re: [exim] cyrus sasl authentication problems

On 2008-01-10 at 21:01 -0500, Ross Boylan wrote:
> The other thing that seems odd is that I see no exchange of the user
> name (on either the client or server side). Are the password and
> username all wrapped into one in the challenge-response? If not, then
> that's the immediate cause of the problem. I do specify -au to swak.

They are both in the CRAM-MD5 base64 data, yes.

RFC 2195, "IMAP/POP AUTHorize Extension for Simple Challenge/Response"
defines CRAM-MD5.

If you run the script I posted in a separate window to a telnet into
exim's SMTP service, "EHLO ...", "AUTH CRAM-MD5", then when the server
supplies a base64 challenge, cut&paste that into the script; the script
will then prompt for a usercode and password and then give you the
response to cut&paste back into the SMTP session.

In essence, once you undo the Base64 encoding, CRAM-MD5 is the server
issuing a blob; the client performs HMAC-MD5 hashing using that
challenge as the key and the password as the data to be hashed; the
client then supplies the usercode, a space and the hash result. This is
just wrapped in base64 making the usercode less visible. It also means
you can't have whitespace in your usercode with CRAM-MD5. Ironic
really, since DIGEST-MD5 blocks colons, that the only password-based
widespread standard authentication protocol which supports "anything
except a NUL character" in usercodes is, uhm, PLAIN.

The challenge is supposed to be some random digits, a timestamp and the
server hostname. Eg, Exim with its built-in CRAM-MD5 just gave me:
334 PDc5OTMuMTIwMDAyMDQ4MkBzbXRwLnNwb2RodWlzLm9yZz4=
where the base64 decodes to:
<7993.1200020482@???>
Similarly, Cyrus IMAP (which uses cyrus-sasl) offers
"<3822671788.8838420@???>" encoded.

The benefit of CRAM-MD5 is that the server doesn't need to store the
password cleartext, it _can_ store an intermediate result of the
relevant hashing operations and then "finish it off" with the challenge
data, so server compromise doesn't risk leaking passwords. In reality,
sasldb is storing the cleartext passwords so that they can be used with
other authentication mechanisms and it's easier to switch authentication
algorithms.