[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: SSL/GSSAPI for OpenLDAP




shltch@osfmail.isc.rit.edu wrote:
> 
> I wanted to inquire about the state of SSL/GSSAPI support in
> OpenLDAP-devel.  I am about to port SSL and GSSAPI changes from our old
> UMich source to the new OpenLDAP source.  I wanted to let everyone know
> about my intentions, so as to not step on anyone's toes and to coordinate
> with anyone else who is doing this same thing.  I also wanted to make sure
> I implemented these functions in a consistent way with the rest of the
> OpenLDAP team.

I am (was?) about to retake this.  But my focus is on SASL and direct SSL
only comes as a necessary kludge.  I had no plans to get GSSAPI into the
picture.  I am not very familiar with GSSAPI, I just read a few specs in
the past.  I don't have an implementation of GSSAPI, so it was a little
bit outside my interests.

So let's talk.  I think this list is the most appropriate place.

As far as direct SSL/TLS is concerned, it is relatively straightforward to
do and I have preliminary code from Bart Hartgers to do it (your patch had
another implementation).  A really useful setup requires the ability to
define certificate policies and checking them before doing work on the
connection depending on validity (from our point of view) of certificates
and security strength achieved (quality of authentication and
confidentiality strength).  I like the concepts in Apache mod_ssl for this.
Same goes for permissions.  It should be possible to change the applicable
ACLs depending on the security level achieved.

But direct SSL/TLS is just a compatibility kludge, since the standard way
to achieve security on LDAP V3 is through SASL.  There is an Internet Draft
that proposes how to switch to TLS on an LDAP connection with the help of
an extended operation StartTLS and the SASL EXTERNAL mechanism.

Add to this that we are in the process of having loadable modules and I think
this is an ideal application area for that.  So additional SASL mechanisms
should be installed by "registration" of the relevant routines and the library
should be modified to add hooks in the appropriate places so that the correct
methods are invoked on the connection depending on the SASL mechanism in use.

> My first question is, should I just implement the entire thing as I see
> fit, then send it as one big diff file, or should I pose implementation
> questions to the group as I go along?  My biggest concern is making sure I
> implement SSL and GSSAPI in a helpful and consistent way.

Try to find a balance.  Both extremes are bad.  Maybe tell us a little bit of
your current approach or even upload your current patch (I only have the copy
in ftp://ftp.rage.net/pub/LDAP/ldap-3.3+ssl081-2.patch but it seems many
different things are merged in there.  This way I can see where you need the
hooks and start implementing them.  Then you could proceed independently.

BTW, it seems we need loadable modules for the clients too, so we should
think about how to get them there.  Backends modules are irrelevant to the
clients, while security modules are needed by both.  It would be nice if we
could reuse modules between clients and servers, but if we define the modules
in the main slapd.conf file (that many clients are reading), we need to have
a method to specify which are server-sepecific.

Julio