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.