On Wed, 8 Aug 2001, Devdas Bhagat wrote:
> On Wed, 08 Aug 2001, Marco Colombo spewed into the ether:
> <snip>
> > And BTW, why don't you remove SASL from OpenLDAP, instead? You're just
> > asking CMU people to remove SASL from their Cyrus IMAPD so that
> > OpenLDAP 2 can use it to implement the encrypted connection (to the
> > LDAP server) you need. Ask the OpenLDAP people to replace the SASL
> > library they use with PAM...
> Ok, I have rather simple requirements.
> I need to store AAA details for multiple users and services in a single
> place. Since many applications directly support getting user data from
> LDAP, I'll go along with that. now both cyrus and OpenLDAP use SASL.
> What I would like to do is get cyrus to use OpenLDAP, like all my other
> applications. I would prefer not to have to do this through PAM, snice
> it involves running running a process as root. SASL supports my
> requirements of having encrypted passwords.
> However, cyrus does not make it easy for me to use ldap directly. I
> need to use an external process to do this. Also, even if I choose to
> use an external process, cyrus makes it pretty hard.
> I don't think that the complaints are about cyrus SASL, or SASL
> support in cyrus. They are about the implementation of SASL support in
> cyrus, which assumes that sasldb will be used, and usernames will
> reside on the same machine as cyrus.
This is a completely different issue. David Wright is proposing to
*remove* SASL from Cyrus IMAPd in favor of a PAM-only solution, and
I was answering to him. I don't want SASL to be removed from IMAPd,
because that's the right place to use SASL. Despite of PAM not being
a replacement for SASL, of course. I think that OpenLDAP requirement
for a modular, configurable network security layer (SASL itself) is
weaker than the IMAPd one. So IFF you need to remove SASL from one
of the two, OpenLDAP is a better candidate.
You're asking for the opposite: to remove PAM from SASL (for LDAP auth,
of course) and implement a direct SASL -> LDAP solution. As I said,
a complete different issue.
> <snip>
> > Anyway, SASL is a very good ad interim solution. Just try to write
> > a SASL application to understand how useful it can be to you.
> Just one point. My SASL database does *NOT* reside on the same machine
> as cyrus-imap. I see no reason to expose user data directly to the
> internet. This is a big flaw in SASL from my POV, it is not a server
> (It was never supposed to be one, so I would consider this a design
> flaw, at most).
SASL provides support for many machs. Some of them require cleartext
passwords to be available to the server. Where those mechs get the
passwords from is a mere implementation detail from the SASL engine
standpoint. sasldb is one easy way for mechs to get the passwords.
Someone please correct me if I'm wrong, but SASL focuses on providing
generic authentication hooks for client/server applications, allowing
them to support different authentication models / protocols in a
transparent and easy-to-manage way. Mechs themeselves focus on protocol
properties (thus, PLAIN is weak, CRAM-MD5 better, DIGEST-MD5 offers
channel encryption, IIRC, TLS (crypto & auth) is an option as EXTERNAL
mech...). Finally, mechs need to get their "passwords" (can be auth
tokens, certs, ...) - or they just need to validate them. Strictly
speaking, it's not SASL job, it's up to the mechs. The mechs provided
with the SASL library may be naive, compared to your needs, but
I wouldn't call that a design flaw in SASL.
> Does this make some sense? Essentially, I'm trying to store user data
> at a single point. This includes passwords. Now I have services running
> on other machines, which need to access this data. LDAP provides a
> convenient API for this, SASL doesn't. Consider LDAP as a means of
> accessing SASL on a remote machine. Now can we please get good support
> for multiple authentication methods into imapd?
LDAP API doesn't offer anything of what the SASL API does, and of
course the converse is also true. So you can't compare the two, as the
provide *completely* different services to the application. Otherwise
please explain me why OpenLDAP itself uses SASL.
SASL already offers "good support for multiple authentication methods".
So good that even the OpenLDAP developers (as many others) chose to use
it to fulfill thier "multiple authentication methods" needs.
>
> Devdas Bhagat
> --
> Bowie's Theorem:
> If an experiment works, you must be using the wrong equipment.
>
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ [EMAIL PROTECTED]
