[Exim] CRAM-MD5 fudging

Top Page
Delete this message
Reply to this message
Author: John Jetmore
Date:  
To: exim-users
Subject: [Exim] CRAM-MD5 fudging
I finally convinced my boss that it would be the most convenient to use
radius to serve our smtp-auth customers since we have such a complex user
base and radius was already configured to do this for us. Now I have a
problem. I can see how easy it would be to proxy off plaintext (PLAIN,
LOGIN) requests, but I'm stuck on CRAM-MD5. For a while I thought it was
sufficiently similar to CHAP authentication that I could use it, but that
appears not to be the case.

Now I'm wondering about a slightly different direction. Our radius
software is wonderfully configurable (my boss gets the same gleam in his
eye talking about it that I get over exim), so I feel that if I can get
the data to the radius server in any format that is suitable to radius, I
can handle it.

So here's my current idea:

MUA requests CRAM-MD5
MTA presents challenge
MUA presents proper response:
    BASE64("user " . MD5((secr XOR opad) . MD5(secr XOR ipad) . chal))
MTA sends radius request to RAD with original challenge string as the
    username and the MUA's response as password.
RAD server now has access to:
    original challenge
    user (decoded from MUA's response)
    digest (decoded from MUA's response)
    - this should be enough to recreate the digest
RAD sends ACK or NAK to MTA
MTA sends ACK or NAK to MUA


The custom radius code is obviously beyond the scope of this email, but I
feel sufficiently confident that it could be done to write this email (to
paraphrase one of the ghostbusters: "since I started messing with this
radius server I've seen it's capable of doing shit that would turn you
white").

So now the only real problem is getting access to the challenge string to
send to the radius server. I think I could reproduce this entire
transaction using the plaintext authenticator: the challenge would be the
prompt, like Username: is in LOGIN and server_condition could use
${radius to make the request. The only thing missing is the challenge
string itself. The only interesting thing is it needs to be consistant
inside AUTH attempts, but rebuilt between AUTH attempts.

I'm thinking of modifying the code to allow this to work (basically to
create a $auth_cram_challenge variable and make it have the attributes I
described above). Here are my questions:

1) am I nuts (have I missed some fundamental reason this won't work)
2) is there anything that needs to be tweaked above?
3) if I implement this variable cleanly, is there a chance of it being
adopted into the main source tree so I don't have to maintain a branch?
4) is there a better name for this variable?

Thanks for your time.
--John