OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: CRAM-MD5 SASL2 ignores smtpd.conf?

From: Andreas Winkelmann (mlawinkelmann.de)
Date: Sun Jun 04 2006 - 03:02:58 CDT


Am Sunday 04 June 2006 09:28 schrieb Brian A. Seklecki:

> > saslauthd does not support Shared-Secret Mechanisms (CRAM-MD5,
> > DIGEST-MD5).
>
> Yea I figured it was something architectural. I figured it was silently
> failing, and an informational warning about a mismatched config is
> probably not expected by default, however there doesn't seem to be any
> debugging information available about the parsing of config files for
> "applications"
>
> > The Library knows that and uses "pwcheck_method: auxprop" instead. Call
> > it a fallback.
>
> So there's no way for CRAM-MD5 / DIGEST-MD5 to work in combination with
> PAM/passwd/shadow mechanism?

No, and there are several reasons for that.

The Protocol from saslauthd. saslauthd is designed, to check a Password. The
Protocol is easy. The Library asks saslauthd "Is Password xxx for User yyy
with realm zzz and Service-Name smtp correct?" And saslauthd answers with Yes
or No. There is no way to fetch a Password or whatever from saslauthd. But
the Shared-Secret Mechanisms must be able to get the Password from the
Backend.

Almost the same with PAM. PAM is not able to give the Password to the
Application. It only checks the given Password.

And last but not least, the Shared-Secret Mechanisms needs a unencrypted
Password, and that is where passwd/shadow will fail.

It's not only saslauthd which does not support the Shred-Secret Mechs, but
it's the main reason, I think.

> They require a DB? I could swear I just
> read CRAM-MD5 doesn't have a cleartext password storage requirement. I
> thought that was only CHAP-like exchanges.

Yes, in theory you're right. CRAM-MD5 needs not the Cleartext-Password, but a
special prepared Hash which can be stored and used for the Authentication.
This does not mean an encrypted Password from passwd/shadow. Cyrus-SASL does
not support this prepared hash, so if you use Cyrus-SASL, Passwords for
Shared-Secret Mechs must be cleartext. Maybe this would make Cyrus-SASL more
complicated, than it is already.

--
        Andreas