[Date Prev][Date Next]
Re: SSL certificate auth without SASL (ITS#3286)
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
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, firstname.lastname@example.org