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

[Kurt@OpenLDAP.org]

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

Kurt

At 10:18 PM 8/19/2004, donn@u.washington.edu wrote:
>On Thursday, August 19, 2004, at 12:43 PM, Howard Chu wrote:
>>> Full_Name: Donn Cave
>>> Version: HEAD (Aug 17)
>>> OS: n/a
>>> URL: http://staff.washington.edu/donn/donn-cave-040817.ext
>>> Submission from: (NULL) (128.95.135.150)
>>>
>>>
>>> Allow simple bind with no password, bind DN == SSL certificate DN.
>
>> I had a patch for this 'way back in OpenLDAP 2.0 but I abandoned it. 
>> There is no standard specification (e.g. RFC) for this behavior, and 
>> we really need to have that before a feature like this can be 
>> incorporated. Why can't you just use SASL/EXTERNAL? Alternatively, you 
>> can publish an RFC defining exactly how this feature should be (a) 
>> advertised by servers to clients and (b) used.
>
>Yes, you mentioned that code when this came up in March
>http://www.openldap.org/lists/openldap-devel/200403/msg00138.html
>after Kurt mentioned the idea,
>http://www.openldap.org/lists/openldap-devel/200403/msg00135.html
>
>The reason I did it was of course to avoid the requirement for SASL.
>We have environments here where SASL EXTERNAL support is missing,
>and can't easily be added.  The worst case is naturally some version
>of Microsoft Windows;  I don't know the details, but it was going to
>be some kind of show-stopper.
>
>The proximate cause for the patch submission was the August 6 San Diego
>conference, where I think the proceedings will show that Kurt included
>something like this on the wish list for contributions.  Maybe I
>misinterpreted.  I can afford to keep carrying it as a local patch,
>that's no problem.
>
>I actually implemented it slightly differently for my site, by the way.
>Same code, but it takes a magic password "X509", and accepts bind DN
>"CN=EXTERNAL" as an alternative to the certificate DN.  It may turn
>out to be a non-trivial problem for our application people to extract
>the certificate DN, so the latter feature may be more important than
>I was thinking.
>
>        Donn Cave, donn@u.washington.edu