Re: SSL/GSSAPI for OpenLDAP

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

bart@etpmod.phys.tue.nl wrote:
> The easiest way would be to supply the client with an interface that it
> can use to install its own security layer.

Yes, I think the client should be able to "register" additional
functionality, preferrable using ldap/ber_set_option.   The client
could also be provided with separate libraries what registered themselves.
Depending upon the implementation, the client might have to a special
call into the auxilary library to initiate this registration.

ie: 
	client calls XXX_init() which is local -lXXX.  XXX_init()
	takes are of all the necessary *_set_option() calls to
	"teach" -lldap/-llber new functionality.

This can also be done with modules... but, from what I gather, client
side modules can be problematic.  However, this is worth exploring.

> I think the next step to take would be to extent the private and
> public LDAP api to include some simple TLS functions, both on the server
> side, and on the client (libldap) side. We need to make
> an abstraction-layer to prevent things from getting too OpenSSL
> specific.

As I noted previously, I would like to keep -llber independent
of underlying stream.  I think it would be wise for it to just have
a couple of hooks and require that hooked functions behave in some
reasonable fashion.   -llber should be flexible (support both blocking
and non-blocking I/O) but push away complex issues (such as multiple I/O
layers).  I think multiple I/O layers (ie: crypto vs wire data availability)
into caller and the hooks the caller provides.

Besides allowing us to provide handlers for a wide variety of I/O streams
(encrypted or not), it would also allow us to provide a consisent error
handling mechanism.

We should provide a number of these I/O handlers in the default libraries
including TCP, UDP, and (if OpenSSL installed) TLS handlers.

> Adding TLS support with OpenSSL seems very simple, just replace read and
> write with SSL_read and SSL_write, supply the name of a file with
> certificates ("TLS identities"), and your communication will be safe.
> Unfortunately, this triggers all kinds of semi-automatic stuff that we
> don't want (asking the user for a password behind our back, for
> instance). It would be very difficult to make something portable from
> supporting this interface.

Depending on the application, this "semi-automatic" stuff may be okay.
For example, for many of the command lines tools, this might be fine
(though passphrase prompting does make use of the tools in scripts
much harder).

Obviously, for many applications, this won't do.

> For our TLS supporting API, I think we should do the managing of
> certificates ourselves, and only use the TLS library for the actual
> encryption and authentication. More to the point, we need to define a
> struct LDAP_X509_CERT and functions to manipulate it. In the end, all
> that a client or server ever needs to see of TLS is this certificate.
> Using our own format prevents too much dependency on a single TLS
> library, and  will also make it more easy to store certificates in the
> LDAP server.

I prefer to leaverage existing open source codes where it makes sense.
The dependency upon OpenSSL does not bother me.   There must be well
defined schema for storing certificates.  If it makes sense to have
an OpenLDAP intermediate format, so be it.  However, I would much
rather have OpenSSL extended to better support the LDAP certificate
schema such that we don't have invent our own internal format.

Kurt