RE: SSL/GSSAPI for OpenLDAP

[<lukeh@xedoc.com.au>]

GSS-API is merely a SASL mechanism, so if the plugin API is well desgined,
then it should be a no-brainer.

Client-side plugins are an interesting issue. We've implemented a GSS-API
client-side plugin for Netscape's client library and have run into a few
problems. First, as far as I can tell, there's no way to pass some
per-session context to the ber_write()/ber_read() hooks, so implementing
privacy protection with multiple GSS-API contexts is harder than it needs to
be. Also, because there doesn't appear to be a way to register a bind
function for a particular SASL mechanism, the client library can't do a SASL
rebind after chasing a referral.

You can look at the code at ftp.padl.com/pub/gsssasl.tar.gz to see how we
have/haven't resolved some of these issues. Please note that this software
is not open source.


-- Luke

> 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

> 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
>