On 29/07/2023 12:32 am, Howard Chu wrote:
Regardless. A session is either authenticated, meaning it has an identity
associated to it, or it is anonymous, meaning
it has no identity associated to it. You can't have both at once.
I am not suggestion any change to or diversion from RFC4513, and what
I'm suggestion is in no way mutually exclusive with that specification
and the authentication and authorization states it defines.
What I'm proposing is a mechanism to strengthen the security of what
LDAP offers natively by use of an external mechanism. slapd already
offers several external mechanisms to this end - domain names, IP
addresses, IPC socket names etc. Use of the TLS client certificate would
be stronger and more flexible than the DNS or IP address mechanisms
offered. It's use as an alternative to these should be obvious. The only
apparent "problem" is that the semantics of certificate names overlaps
with slapd's own use of these names. But there is no conflict here. Both
uses of the certificate name use it exactly as it was intended - to
identify the client.
My proposal will not spell the end of the "bind" operation, it is part
of the LDAP specification and always will be. It will continue to be
essential to proxy authentication, and will continue to be used for
regular authentication because that is how clients are written and will
continue to written for compatibility reasons.
Let me restate the fundamental problem...
Currently there is no reliable way to force someone using a particular
client certificate to bind as the identity on the certificate. If one
client is compromised, that client's connection could be used to launch
a dictionary attack on the credentials of all other clients. This
arrangement was a necessary compromise for the LDAP authors because they
could not assume a way of externally identifying clients existed. They
most certainly did not intend this compromise to force LDAP implementers
to ignore external knowledge of a client's identity.
By deliberately hiding external knowledge of a clients identity, slapd
is attempting to drag all uses down to the same compromised security
implicit in a non-TLS world. THIS IS THE WRONG RESPONSE. Instead, slapd
should offer it's users the full benefit of TLS, and instead encourage
all it's uses to deploy TLS with client certificates. Pull people up to
a stronger security setting, rather than push them down to the lowest
common denominator.
Sean.
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
