On Wed, 8 Aug 2001, David Wright wrote:
>
> First off, thanks to you, Lawrence, and the many others who helped
> clarify why OpenLDAP 2.0.x + pam_ldap + cyrus-imaps-2.0.x won't play
> together out-of-the-box. For those just tuning in to this thread, it's
> because the SASL routines are (1) used both by cyrus-imapd and OpenLDAP
> and (2) not re-entrant, so memory gets deallocated by one while the
> other is still trying to use it. Poof -- core dump.
>
> CMU people, please don't take the following personally; your work is
> impressive and appreciated. But some things about it are less than
> useful off the CMU campus, and I think SASL is one of them. My reasoning
> is simple:
>
> A non-re-entrant security layer is contradiction in terms. Security
> layers are designed to be ubiquitous -- if SASL works out as planned,
> every application involved in authentication will link to it. Problems
> like these would be a dime a dozen (which is one reason SASL will not
> become ubiquitous).
SASL is not a security layer the same way PAM is. PAM is just a library.
A network connection (if any) is made only for AAA purpose, and PAM
handles ONLY the client side. Conversely, SASL (see RFC2222) allows
you to extend existing network protocols, adding authentication and
authorization to them. The SASL *library* handles BOTH client and
server side, allowing you to write secure applications with little
knowledge of the security protocols involved. While of course it should
be reentrant, it is understandable that some problems occur when an
application violates the basic client-server model, and creates (via an
external library) a second SASL client instance in the middle of the
execution of the first one (SASL hides the security protocol state
machine away from the programmer).
> I think for most applications PAM is a much better alternative. It is
> inherently simpler. It can support ticket systems by using Kerberos. It
> can support access restrictions based on time-of-day, IP-address, and
> such, which (correct me if I'm wrong) SASL cannot. If is far more widely
> used and easily understood.
Of course. Whenever an application wants to do some (client-side) AAA
PAM is a good framework. But you don't implement a network server with
PAM. BTW, it follows that it makes perfect sense for the *server* side
of SASL to use PAM (as it does) for AAA.
> Of course, one can always claim that SASL doesn't hurt anything, since
> it can call PAM. But my experience has proven the falacy of the doctrine
> of harmless layers. It turns out to be even more difficult than planned
> for me to avoid the re-entrancy problem, because the LDAP encyption of
> OpenLDAP 2.0.x gets broken when compiled --without-cyrus-sasl, and
> OpenLDAP 1.x doesn't have any encryption, and I need my LDAP
> communications encrypted (which is why the sasl-ldap patch also isn't an
> option).
Implementation details. PAM doesn't offer a *network* security layer,
so it can't simply replace SASL.
> Which leads me to repeat my earilier question: how hard would it be to
> replace SASL with PAM, thus producing, IMHO, a more useful imap server
> for sites other than CMU. Basically this comes down to the question: how
> many calls to SASL library APIs are there in cyrus-imapd? 10? 100? 1000?
> If it's less than 100 I'd give it a try myself.
You need to re-implement all the client-server authentication dialog.
And be sure to interoperate with different clients. With SASL, I can
hope to talk to RFC2222-aware clients, at least.
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...
I'm not a big SASL fan myself. Were I to replace SASL *now*, I'd limit
network security to SSL/TLS (instead of them being just a external
method), with either plaintext password (over encrypted channel) or
X.509 client certs, ala HTTP. But in the end SASL lets me do that anyway,
and I guess that in the future, when IPSec/IPv6 are widely deployed,
we'll just ask the network layer to provide enough security, with no
need for another security layer on top of it.
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.
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ [EMAIL PROTECTED]
