On Thursday 24 October 2002 04:33 am, Philip Hazel wrote:
> On Wed, 23 Oct 2002, Eric Renfro wrote:
> > > The first CRAM-MD5 AUTH works for the first user that attempts it.
> > > After that, the same user, or any other user can't AUTH and succeed,
> > > with CRAM-MD5. Waiting ~10 minutes and trying again, and it begins
> > > working, once.
> > >
> > > Seems like a cache problem?
> >
> > I did a debug on this problem, and it's showing here:
> >
> > Process 17668 is handling incoming connection from [192.168.1.10]
> ^^^^^
>
> > That's the first successfull lookup.
> >
> > Process 17696 is handling incoming connection from [192.168.1.10]
> ^^^^^
> A new process.... and authentication fails.
>
> Exim does not cache lookup information between processes. I can't see
> how this can be anything to do with Exim - though sometimes complex
> things do occur that surprise me.
Well, it was working seemlessly with LDAP. It's /not/ working seemlessly with
PostgreSQL..
> Certainly there's nothing like a 10 minute kind of timeout thing. (You
> aren't re-starting your daemon every 10 minutes, are you? If you are,
> that _would_ be significant.)
No, I started to restart the testing exim server somewhat like that, but then,
stopped, and tested how long apart it would be before it would work.
I'd even upgraded from exim 4.05 to 4.10 to solve this, to no avail. The MUA
I'm using, and have always been using, through LDAP CRAM, and PGSQL CRAM, is
KDE's KMail.
> > Pay attention to the received, and the digest being completely different.
> >
> > challenge = <17696.1035403810@???>
> > received = 5cb4301be6c19a10bc555491921cf89e
> > digest = 6ba2869e37c4d041dafb41c538de1407
>
> Indeed. The fact that it output that info, however, shows that it ran
> through the CRAM-MD5 code.
>
> Given that you know the correct password, you could compute which digest
> is actually correct. In principle, it could either be the one received
> or the one computed.
>
> You have to take the MD5 digest of the password concatenated with the
> challenge string, with some padding. From the comments in the code:
>
> The CRAM-MD5 algorithm is described in RFC 2195. It computes
>
> MD5((secret XOR opad), MD5((secret XOR ipad), challenge))
>
> where secret is padded out to 64 characters (after being reduced to an MD5
> digest if longer than 64) and ipad and opad are 64-byte strings of 0x36 and
> 0x5c respectively, and comma means concatenation.
>
> I realize that this is a non-trivial exercise!
Yes, as Steve mentioned in this thread, I've tried that, and they don't even
come close to a match...
Not in any of the cases, success or failure.
--
Eric Renfro
Myrddin Computers & Designs - CEO/President
Sales: sales@???
Fax: (775) 243-4535
