LDAPS (LDAP over SSL) client authentication

[John Kristian <kristian@netscape.com>]

To anyone implementing certificate-based client authentication in
LDAPS (LDAP over SSL), or LDAP over TLS:

I implemented this, in Netscape Directory Server.  Some design choices
weren't obvious (to me).  I'd be happy to tell you what the Netscape
software does, and why.  I aim to make Netscape's software compatible
with yours.  I urge you to make compatible choices in your
implementation, or (if you don't) let me know what you're doing, so
I can help change Netscape's software to be compatible with yours.

Some facts about Netscape's implementation that spring to mind:

By default, the LDAPS server lets the client choose whether to
authenticate via SSL.  The server transmits a 'Certificate Request'
during SSL session creation.  The client may send a 'Client Certificate'
or a 'no certificate' alert; either is acceptable to the server.
Optionally, the server can be configured to either:

- not send a 'Certificate Request' (in which case SSL forbids the
  client to send a certificate).  This has been used to work around
  LDAPS clients that crash when they receive a 'Certificate Request'
  (those clients are erroneous, IMHO).  Or

- require a 'Client Certificate' (the server rejects the SSL session,
  unless the client sends one).

SSL client authentication interacts with subsequent LDAP Bind requests
(sent over the SSL session).  An LDAPS client can authenticate via SSL
by sending a 'Client Certificate' during SSL session negotiation, and
then sending either:

- no Bind request (the server assumes LDAPv3), or

- an LDAPv3 SASL Bind request with mechanism "EXTERNAL" and
  zero-length name and credentials, or

- an LDAPv2 simple Bind request with zero-length name and password.

In any of these 3 cases, the client's authorization identity is
derived from the SSL 'Client Certificate'.  That is, the certificate
is the client's effective authorization credentials.

An LDAPv3 simple Bind request or an LDAPv2 simple Bind with a
non-zero-length name or password causes the server to ignore the SSL
'Client Certificate'; the subsequent authorization identity is either
anonymous or the name given in the Bind request.  A client may resume
the SSL identity again, by sending one of the Bind requests described
above.

----------------
John Kristian <kristian@netscape.com>
Software Developer
Netscape Communications