Re: SSL certificate auth without SASL (ITS#3286)

[donn@u.washington.edu]

On Friday, August 20, 2004, at 01:25 AM, Kurt D. Zeilenga wrote:
> I have (and continue) to suggest that -lldap include
> native support for select SASL mechanisms (namely,
> EXTERNAL).  That way, without Cyrus SASL, one would
> still have support for these select SASL mechanisms.
> (So, I think, you misinterpret my statements).
>
> I do not think we should RE-define DN w/o Password to
> be some new semantic.  That would only cause interop
> problems with implementations relying on the currently
> defined semantic (unauthenticated Bind).

I see.  Well, I'm sure you know of some case where this
non-Cyrus SASL would be useful, but it sure isn't a
solution for anything here.  Where we're at all likely
to install a current OpenLDAP client that might have this
native SASL, we actually have no problem with Cyrus SASL
anyway.

I haven't really explored the interop issue, but it's
basically the reason our local version uses a magic
password instead of no password - together with the
likely mismatch between the certificate and simple
bind DN space, it seemed pretty unlikely to get mixed
up with any current use.  The present w/o password
implementation would just be more obvious.

> I note that if one is dealing with legacy clients
> which don't support SASL, they likely also don't
> support TLS with client certificates.  (And arguably
> could be viewed as not support LDAPv3, as
> SASL/DIGEST-MD5 is THE mandatory-to-implement
> authentication mechanism).  Anyways, as you noted
> your problem involved 'application programmers',
> I suggest they either don't know how to use the
> SDK (as most include SASL support) or made a
> poor choice of SDK (if it doesn't include basic*
> SASL support).
>
> * the SDK need not support EXTERNAL itself.  It
> is sufficient to have the SDK construct the
> LDAP Bind PDU with application-provided SASL
> mechanism data (e.g., ldap_sasl_bind(3)).

If you're interested in more details about the problem
they were dealing with, I can get that from them.  All
I remember is that in some relatively old Windows platform,
maybe some version of W2K, the "crypto layer" didn't support
EXTERNAL, as later ones do.  I personally find that the
SASL in MacOS X 10.2's OpenLDAP doesn't support EXTERNAL.
If there are workarounds for this, that doesn't surprise
me a lot, since it's there isn't much to it (I mean, SASL
EXTERNAL is sort of vacuous), but all I had to do was not
require SASL and this whole class of problems went away.

	Donn Cave, donn@u.washington.edu