Hi All,
This is loosely related to issue 10065 https://bugs.openldap.org/show_bug.cgi?id=10065, but can be read independently.
I have devised a work-around to slapd's inability to check client names on Client certificates and am in the process of removing a proxy (haproxy) I had in front of my slapd server. I have however come across an annoying compromise and I'm offering here a suggestion on how to remove it.
In particular, with the proxy, I could write rules targeting particular clients that worked, even before their initial "bind" operation by using the "sockname=" pattern in the access control rules. This does not seem possible when slapd talks directly to the clients. before the initial "bind" operation, only the IP address is available to tell clients apart, which are not very reliable. IP addresses are easily spoofed.
It would be much better to use the client certificate to match against the particular client. Currently the client ID on the certificate is passed to the SASL layer with the sasl_setprop(...,SASL_AUTH_EXTERNAL,...) call. There it remains until the client performs a "bind" using the SASL EXTERNAL mechanism. At this point, the EXTERNAL client ID is used to derive a distinguished name by filtering it through the "olcAuthzRegexp". It should be noted that LDAP v3 does not require the client to perform such a bind operation.
My Proposal is to expose the EXTERNAL identity to the ACL rules in a similar way to how the "real" prefix exposes the authentication identity - by creating an "external" prefix.
As such, the matching rules
externalanonymous externalusers externalself externaldn externaldnattr
Could be used to restrict access to clients, even before or without a bind operation.
To maintain naming consistency, The name passed to SASL could have the "olcAuthzRegexp" mapping applied before the ACL rule is applied. In this case, the "external" identity would be the same as the unprefixed identity, after a bind using SASL EXTERNAL mechanism had occured.
This arrangement would have several advantages including:
*) only exposing the userPassword to the particular client that needs it. *) enforcing client/IP address associations in a rigorous manner. *) general ACL rules for operations that do not need a "bind" operation. *) restricting SIMPLE binds to particular clients.
Any Thoughts ?
On Thu, Jul 27, 2023 at 03:17:41PM +1000, Sean Gallagher wrote:
Hi All,
I have devised a work-around to slapd's inability to check client names on Client certificates and am in the process of removing a proxy (haproxy) I had in front of my slapd server. I have however come across an annoying compromise and I'm offering here a suggestion on how to remove it.
In particular, with the proxy, I could write rules targeting particular clients that worked, even before their initial "bind" operation by using the "sockname=" pattern in the access control rules. This does not seem possible when slapd talks directly to the clients. before the initial "bind" operation, only the IP address is available to tell clients apart, which are not very reliable. IP addresses are easily spoofed.
It would be much better to use the client certificate to match against the particular client. Currently the client ID on the certificate is passed to the SASL layer with the sasl_setprop(...,SASL_AUTH_EXTERNAL,...) call. There it remains until the client performs a "bind" using the SASL EXTERNAL mechanism. At this point, the EXTERNAL client ID is used to derive a distinguished name by filtering it through the "olcAuthzRegexp". It should be noted that LDAP v3 does not require the client to perform such a bind operation.
Hi Sean, I'm not sure what you're trying to achieve here. Why do you want to distinguish different kinds of anonymous clients? The usual answer to this is to have ACLs that prevent them from doing anything except a Bind, during/after which they have (a proposed) identity that is part of ACL processing.
If you need to distinguish different "anonymous" clients from each other and give some additional access, you might have to define your own dynacl module that lets you define arbitrary logic, pretty sure even inspecting the connection/TLS session state.
Regards,
On 27/07/2023 5:57 pm, Ondřej Kuzník wrote:
I'm not sure what you're trying to achieve here. Why do you want to distinguish different kinds of anonymous clients?
My clients are very asymmetric. Each has a particular job to do, and a particular set of operations to perform on the database. I was trying to restrict access for each client, to just what was needed for it to perform it's task. Then if one client is compromised, damage can be (more) contained.
As it stands, before a bind, all (IP) clients look the same (Apart from the IP address) - and so all clients need "auth" access to all other clients credentials. If any client is granted some pre-bind rights, all clients get those same rights. One compromised client makes all clients vulnerable. This is not necessary. slapd _knows_ the identity of each client, it's just a matter of exposing it to the ACL rules. It's not even without precedent, the sasl_ssf is exposed to the ACL rules before a bind, why not other properties of the sasl state?
Anyway, this is just a "nice to have" idea, the real-life effect this would have on security is pretty minimal. It's just frustrating when I have to weaken access controls to do things the "right" way..
On Thu, Jul 27, 2023 at 10:32:08PM +1000, Sean Gallagher wrote:
My clients are very asymmetric. Each has a particular job to do, and a particular set of operations to perform on the database. I was trying to restrict access for each client, to just what was needed for it to perform it's task. Then if one client is compromised, damage can be (more) contained.
As it stands, before a bind, all (IP) clients look the same (Apart from the IP address) - and so all clients need "auth" access to all other clients credentials. If any client is granted some pre-bind rights, all clients get those same rights. One compromised client makes all clients vulnerable. This is not necessary. slapd _knows_ the identity of each client, it's just a matter of exposing it to the ACL rules. It's not even without precedent, the sasl_ssf is exposed to the ACL rules before a bind, why not other properties of the sasl state?
Anyway, this is just a "nice to have" idea, the real-life effect this would have on security is pretty minimal. It's just frustrating when I have to weaken access controls to do things the "right" way..
For now, your best bet would be a dynacl module. Or you can implement your proposed functionality yourself and see if we can get it merged.
Regards,
Ondřej Kuzník wrote:
On Thu, Jul 27, 2023 at 10:32:08PM +1000, Sean Gallagher wrote:
My clients are very asymmetric. Each has a particular job to do, and a particular set of operations to perform on the database. I was trying to restrict access for each client, to just what was needed for it to perform it's task. Then if one client is compromised, damage can be (more) contained.
As it stands, before a bind, all (IP) clients look the same (Apart from the IP address) - and so all clients need "auth" access to all other clients credentials. If any client is granted some pre-bind rights, all clients get those same rights. One compromised client makes all clients vulnerable. This is not necessary. slapd _knows_ the identity of each client, it's just a matter of exposing it to the ACL rules. It's not even without precedent, the sasl_ssf is exposed to the ACL rules before a bind, why not other properties of the sasl state?
Anyway, this is just a "nice to have" idea, the real-life effect this would have on security is pretty minimal. It's just frustrating when I have to weaken access controls to do things the "right" way..
For now, your best bet would be a dynacl module. Or you can implement your proposed functionality yourself and see if we can get it merged.
No. This is fallacious.
Sean Gallagher wrote:
On 27/07/2023 5:57 pm, Ondřej Kuzník wrote:
I'm not sure what you're trying to achieve here. Why do you want to distinguish different kinds of anonymous clients?
My clients are very asymmetric. Each has a particular job to do, and a particular set of operations to perform on the database. I was trying to restrict access for each client, to just what was needed for it to perform it's task. Then if one client is compromised, damage can be (more) contained.
As it stands, before a bind, all (IP) clients look the same (Apart from the IP address) - and so all clients need "auth" access to all other clients credentials.
That is all false. No auth privileges are needed to perform a SASL EXTERNAL Bind.
If any client is granted some pre-bind rights, all clients get those same rights. One compromised client makes all clients vulnerable. This is not necessary.
The exact same is true with what you've proposed.
slapd _knows_ the identity of each client, it's just a matter of exposing it to the ACL rules. It's not even without precedent, the sasl_ssf is exposed to the ACL rules before a bind, why not other properties of the sasl state?
Anyway, this is just a "nice to have" idea, the real-life effect this would have on security is pretty minimal. It's just frustrating when I have to weaken access controls to do things the "right" way..
All you're doing is inventing a new authentication mechanism instead of using one that already exists.
--On Thursday, July 27, 2023 5:23 PM +0100 Howard Chu hyc@symas.com wrote:
Sean Gallagher wrote:
On 27/07/2023 5:57 pm, Ondřej Kuzník wrote:
I'm not sure what you're trying to achieve here. Why do you want to distinguish different kinds of anonymous clients?
My clients are very asymmetric. Each has a particular job to do, and a particular set of operations to perform on the database. I was trying to restrict access for each client, to just what was needed for it to perform it's task. Then if one client is compromised, damage can be (more) contained.
As it stands, before a bind, all (IP) clients look the same (Apart from the IP address) - and so all clients need "auth" access to all other clients credentials.
That is all false. No auth privileges are needed to perform a SASL EXTERNAL Bind.
That is not necessarily true. If you do a direct mapping, correct. If you have an ldap URI that does an internal lookup as part of validating the external bind, then auth is necessary on those attributes. This is noted explicitly in the man page.
--Quanah
Quanah Gibson-Mount wrote:
--On Thursday, July 27, 2023 5:23 PM +0100 Howard Chu hyc@symas.com wrote:
Sean Gallagher wrote:
On 27/07/2023 5:57 pm, Ondřej Kuzník wrote:
I'm not sure what you're trying to achieve here. Why do you want to distinguish different kinds of anonymous clients?
My clients are very asymmetric. Each has a particular job to do, and a particular set of operations to perform on the database. I was trying to restrict access for each client, to just what was needed for it to perform it's task. Then if one client is compromised, damage can be (more) contained.
As it stands, before a bind, all (IP) clients look the same (Apart from the IP address) - and so all clients need "auth" access to all other clients credentials.
That is all false. No auth privileges are needed to perform a SASL EXTERNAL Bind.
That is not necessarily true. If you do a direct mapping, correct. If you have an ldap URI that does an internal lookup as part of validating the external bind, then auth is necessary on those attributes. This is noted explicitly in the man page.
Wrong. In a SASL EXTERNAL Bind there are no failure conditions, the entire point is that the presence of the session means it was already validated. Failure to map the SASL authc identity doesn't invalidate it, it just means the original identity is used as-is. Regardless, the Bind succeeds unconditionally.
On 28/07/2023 1:23 am, Howard Chu wrote:
That is all false. No auth privileges are needed to perform a SASL EXTERNAL Bind.
Not all clients use the EXTERNAL bind to authenticate. I'm also thinking about clients that don't bind at all.
The exact same is true with what you've proposed.
Compare: access to dn="ou=people,o=Example Corp" attr="userPassword" by externalself auth access to dn="ou=people,o=Example Corp" attr="userPassword" by anonymous auth
clearly not exactly the same
I see a parallel here with the evolution of shadow passwords on unix systems. Before shadow passwords came along, all uses of the unix box could see hashes of all the other user's passwords. People realized this was a bad idea pretty early on and so shadow passwords were invented. What I'm proposing is more like shadow passwords. The status-quo is more like the original system.
All you're doing is inventing a new authentication mechanism instead of using one that already exists.
I think "improving on one that already exists" is closer to the truth. In any case you give me too much credit. I didn't invent TLS, I just want to see it reach it's potential.
But it is true, with what I'm proposing, many clients would not need to bind at all. I say good! save a round trip time on the transaction.
All this really misses the point though. This is really about building walls around each client and preventing them from interacting except in the limited sense deemed necessary by design. This is a basic tenet computer security and one worth pursuing.
Sean Gallagher wrote:
On 28/07/2023 1:23 am, Howard Chu wrote:
That is all false. No auth privileges are needed to perform a SASL EXTERNAL Bind.
Not all clients use the EXTERNAL bind to authenticate. I'm also thinking about clients that don't bind at all.
Clients that don't Bind are, by definition, anonymous.
The exact same is true with what you've proposed.
Compare: access to dn="ou=people,o=Example Corp" attr="userPassword" by externalself auth access to dn="ou=people,o=Example Corp" attr="userPassword" by anonymous auth
clearly not exactly the same
Clearly pointless, because an external bind doesn't need access to userPassword at all.
I see a parallel here with the evolution of shadow passwords on unix systems. Before shadow passwords came along, all uses of the unix box could see hashes of all the other user's passwords. People realized this was a bad idea pretty early on and so shadow passwords were invented. What I'm proposing is more like shadow passwords. The status-quo is more like the original system.
The analogy fails because "auth" access doesn't allow a user to see the values of what access was granted to, while anyone could read the contents of the passwd file. Granting auth access only allows clients to perform Simple Bind ops.
All you're doing is inventing a new authentication mechanism instead of using one that already exists.
I think "improving on one that already exists" is closer to the truth. In any case you give me too much credit. I didn't invent TLS, I just want to see it reach it's potential.
But it is true, with what I'm proposing, many clients would not need to bind at all. I say good! save a round trip time on the transaction.
All this really misses the point though. This is really about building walls around each client and preventing them from interacting except in the limited sense deemed necessary by design. This is a basic tenet computer security and one worth pursuing.
You are asking to associate an identity to a session. That is what "authenticating" is. In LDAP a Bind request is used for authentication.
You're asking for LDAP to perform some new, previously undefined operation to do exactly what a SASL EXTERNAL Bind does.
On 28/07/2023 12:35 pm, Howard Chu wrote:
Clients that don't Bind are, by definition, anonymous.
Yes, that is the term used in the RFCs, but the RFCs do not say what anonymous sessions can and cannot do. This is up to the system administrator. It is not unreasonable to base those permissions on who by or how the connection was established.
Compare: access to dn="ou=people,o=Example Corp" attr="userPassword" by externalself auth access to dn="ou=people,o=Example Corp" attr="userPassword" by anonymous auth
clearly not exactly the same
Clearly pointless, because an external bind doesn't need access to userPassword at all.
Think SIMPLE bind over an ldaps channel. Just because the EXTERNAL identity is there, does not force a client to use it.
The analogy fails because "auth" access doesn't allow a user to see the values of what access was granted to, while anyone could read the contents of the passwd file. Granting auth access only allows clients to perform Simple Bind ops.
Not a perfect analogy, but still helpful.
You are asking to associate an identity to a session. That is what "authenticating" is. In LDAP a Bind request is used for authentication.
You're asking for LDAP to perform some new, previously undefined operation to do exactly what a SASL EXTERNAL Bind does.
This is not a new or undefined operation, this is as old as computers themselves. I control who my clients are by who I allow to connect to my system. Signing a certificate for a client is the modern day equivalent of "plugging it in". The fact that LDAP has an explicit bind operation does not invalidate this fundamental rule of computer networks.
Sean Gallagher wrote:
On 28/07/2023 12:35 pm, Howard Chu wrote:
Clients that don't Bind are, by definition, anonymous.
Yes, that is the term used in the RFCs, but the RFCs do not say what anonymous sessions can and cannot do. This is up to the system administrator. It is not unreasonable to base those permissions on who by or how the connection was established.
Compare: access to dn="ou=people,o=Example Corp" attr="userPassword" by externalself auth access to dn="ou=people,o=Example Corp" attr="userPassword" by anonymous auth
clearly not exactly the same
Clearly pointless, because an external bind doesn't need access to userPassword at all.
Think SIMPLE bind over an ldaps channel. Just because the EXTERNAL identity is there, does not force a client to use it.
The analogy fails because "auth" access doesn't allow a user to see the values of what access was granted to, while anyone could read the contents of the passwd file. Granting auth access only allows clients to perform Simple Bind ops.
Not a perfect analogy, but still helpful.
You are asking to associate an identity to a session. That is what "authenticating" is. In LDAP a Bind request is used for authentication.
You're asking for LDAP to perform some new, previously undefined operation to do exactly what a SASL EXTERNAL Bind does.
This is not a new or undefined operation, this is as old as computers themselves. I control who my clients are by who I allow to connect to my system. Signing a certificate for a client is the modern day equivalent of "plugging it in". The fact that LDAP has an explicit bind operation does not invalidate this fundamental rule of computer networks.
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. If you want an identity to be associated to the session, you perform a Bind operation. End of story.
On 7/28/2023 7: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. If you want an identity to be associated to the session, you perform a Bind operation. End of story.
A TLS session that requires a client certificate is authenticated, whether or not there's a bind operation. The question is whether the ACL subsystem can make use of that existing authentication - whether the TLS-level authenticated identity is automatically made available at the LDAP layer.
Jordan Brown wrote:
On 7/28/2023 7: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. If you want an identity to be associated to the session, you perform a Bind operation. End of story.
A TLS session that requires a client certificate is authenticated, whether or not there's a bind operation. The question is whether the ACL subsystem can make use of that existing authentication - whether the TLS-level authenticated identity is automatically made available at the LDAP layer.
Repeating myself because you don't seem to read carefully:
If you want an identity to be associated to the session, you perform a Bind operation.
On 7/30/2023 6:15 AM, Howard Chu wrote:
If you want an identity to be associated to the session, you perform a Bind operation.
A TLS session with a client certificate is authenticated, whether or not you do a bind. Slapd ignores that authentication information unless you do a bind with SASL/EXTERNAL.
On Mon, Jul 31, 2023 at 03:54:14AM +0000, Jordan Brown wrote:
On 7/30/2023 6:15 AM, Howard Chu wrote:
If you want an identity to be associated to the session, you perform a Bind operation.
A TLS session with a client certificate is authenticated, whether or not you do a bind. Slapd ignores that authentication information unless you do a bind with SASL/EXTERNAL.
A TLS session might be authenticated, but RFC4513 is fairly clear on Bind being used to derive the authenticated identity of an LDAP session, in the case of TLS:
"If a client that has provided a suitable certificate subsequently performs a Bind operation using the SASL EXTERNAL authentication mechanism (Section 5.2.3), information in the certificate may be used by the server to identify and authenticate the client."
Similar with authorization identity.
It later proceeds to state that the authorization state (not identity!) can take into account other factors and is a local matter. This is where ACLs operate and what Sean's proposing to be extended.
My answer is that it's wrong to force the ACL subsystem to interact with the connection's TLS/local socket/... contexts where a perfectly good way to do this exists (a Bind request). If you want to add it, a dynacl module is the way, I would personally be open to then merging such a dynacl module into contrib/ but am not volunteering to writing it.
Regards,
On 31/07/2023 7:02 pm, Ondřej Kuzník wrote:
My answer is that it's wrong to force the ACL subsystem to interact with the connection's TLS/local socket/... contexts where a perfectly good way to do this exists (a Bind request). If you want to add it, a dynacl module is the way, I would personally be open to then merging such a dynacl module into contrib/ but am not volunteering to writing it.
I agree with most of that. The ACLs should not be muddied by all the externalities. What I would really like to see is something like connection classes, where all the externalities (including any information from the client certificate) can be used to classify a connection, and then, that classification used to determine what rights the connection should be given. I think that kind of structure would lead to more understandable and more maintainable rulesets in general. But that's not how slapd works.
I disagree that bind is "perfectly good"
Jordan Brown wrote:
On 7/30/2023 6:15 AM, Howard Chu wrote:
If you want an identity to be associated to the session, you perform a Bind operation.
A TLS session with a client certificate is authenticated, whether or not you do a bind. Slapd ignores that authentication information unless you do a bind with SASL/EXTERNAL.
The LDAP specification says that a session is anonymous unless a Bind is performed.
The fact that the TLS session is already authenticated is irrelevant. Transport layer and Application layer are separate and independent. If a client wants to be authenticated on the LDAP layer it must request it.
You can take this argument to the IETF if you like, but the answer will be the same.
On 7/31/2023 9:10 AM, Howard Chu wrote:
The fact that the TLS session is already authenticated is irrelevant. Transport layer and Application layer are separate and independent. If a client wants to be authenticated on the LDAP layer it must request it.
Does the RFC explicitly authorize controlling access based on the client's IP address? Does slapd allow controlling access based on the client's IP address?
On 1/08/2023 3:46 am, Jordan Brown wrote:
On 7/31/2023 9:10 AM, Howard Chu wrote:
The fact that the TLS session is already authenticated is irrelevant. Transport layer and Application layer are separate and independent. If a client wants to be authenticated on the LDAP layer it must request it.
Does the RFC explicitly authorize controlling access based on the client's IP address? Does slapd allow controlling access based on the client's IP address?
Howard is being very literal in his reading of the LDAP RFCs. The RFCs define several authentication and authorization states and specific operations required to change those states. Until those specific LDAP actions occur, the states no not change. Specifically, the client's TLS layer authenticating with the server's TLS layer does not change the LDAP authentication state.
The point is that what those LDAP states MEAN is a matter of local policy.
1) If a system admin wants to give "anonymous" sessions the power to create and destroy entire databases, there is nothing in the RFC's or slapd to stop them.
2) Less dramatically, if the system admin wants to use IP addresses to determine access to database entries and ignore the authentication state defined by the LDAP RFCs, that is also allowed by the RFCs and by slapd.
3) Finally, if the system admin wants to use the TLS layer authentication state to subtly modify access rights, that is also allowed by the RFCs, BUT NOT BY SLAPD.
I find slapd's incapacity in the third case to be a bizarre inconsistency.
Sean.
On Tue, Aug 01, 2023 at 09:09:43AM +1000, Sean Gallagher wrote:
- Finally, if the system admin wants to use the TLS layer authentication
state to subtly modify access rights, that is also allowed by the RFCs, BUT NOT BY SLAPD.
I find slapd's incapacity in the third case to be a bizarre inconsistency.
The ACL subsystem is extensible well beyond this and I find it bizarre that you keep ignoring that.
On Tue, 1 Aug 2023 at 04:35, Ondřej Kuzník ondra@mistotebe.net wrote:
On Tue, Aug 01, 2023 at 09:09:43AM +1000, Sean Gallagher wrote:
- Finally, if the system admin wants to use the TLS layer authentication
state to subtly modify access rights, that is also allowed by the RFCs, BUT NOT BY SLAPD.
I find slapd's incapacity in the third case to be a bizarre inconsistency.
The ACL subsystem is extensible well beyond this and I find it bizarre that you keep ignoring that.
I created a dynacl a while back that does what I think Sean is looking for: use the SASL_AUTH_EXTERNAL property to allow auth access to userPassword. My original use case was to get rid of an IP whitelist and instead use TLS client auth to control what clients can perform a simple bind, but it can be used for pretty much any access you'd like.
I've attached a simplified version of that dynacl that does away with instance-specific checks.
On 2/08/2023 12:34 am, David Hawes wrote:
I created a dynacl a while back that does what I think Sean is looking for: use the SASL_AUTH_EXTERNAL property to allow auth access to userPassword. My original use case was to get rid of an IP whitelist and instead use TLS client auth to control what clients can perform a simple bind, but it can be used for pretty much any access you'd like.
I've attached a simplified version of that dynacl that does away with instance-specific checks.
OMG. You may have just saved me months of work. Getting up that learning curve would definitely not be straightforward.
Thank you.
Would there be any problem releasing this code under whatever open-source license OpenLDAP is using - Supposing I did write something and submit it back to project?
On 2/08/2023 12:34 am, David Hawes wrote:
On Tue, 1 Aug 2023 at 04:35, Ondřej Kuzník ondra@mistotebe.net wrote:
On Tue, Aug 01, 2023 at 09:09:43AM +1000, Sean Gallagher wrote:
- Finally, if the system admin wants to use the TLS layer authentication
state to subtly modify access rights, that is also allowed by the RFCs, BUT NOT BY SLAPD.
I find slapd's incapacity in the third case to be a bizarre inconsistency.
The ACL subsystem is extensible well beyond this and I find it bizarre that you keep ignoring that.
I created a dynacl a while back that does what I think Sean is looking for: use the SASL_AUTH_EXTERNAL property to allow auth access to userPassword. My original use case was to get rid of an IP whitelist and instead use TLS client auth to control what clients can perform a simple bind, but it can be used for pretty much any access you'd like.
I've attached a simplified version of that dynacl that does away with instance-specific checks.
On Tue, 1 Aug 2023 at 20:05, Sean Gallagher sean@teletech.com.au wrote:
Would there be any problem releasing this code under whatever open-source license OpenLDAP is using - Supposing I did write something and submit it back to project?
I wouldn't have any problem with that. I'd have to re-read https://openldap.org/devel/contributing.html to make the right statement.
Sean Gallagher wrote:
On 1/08/2023 3:46 am, Jordan Brown wrote:
On 7/31/2023 9:10 AM, Howard Chu wrote:
The fact that the TLS session is already authenticated is irrelevant. Transport layer and Application layer are separate and independent. If a client wants to be authenticated on the LDAP layer it must request it.
Does the RFC explicitly authorize controlling access based on the client's IP address? Does slapd allow controlling access based on the client's IP address?
Howard is being very literal in his reading of the LDAP RFCs.
RFCs are not poems, they aren't meant to be loosely interpreted.
I've wasted enough time explaining things here. As always, in an all-volunteer open source project, if you want something changed, go change it yourself. Quit trying to browbeat other people into listening to your selfish demands.
On 2/08/2023 2:27 am, Howard Chu wrote:
Sean Gallagher wrote:
On 1/08/2023 3:46 am, Jordan Brown wrote:
On 7/31/2023 9:10 AM, Howard Chu wrote:
The fact that the TLS session is already authenticated is irrelevant. Transport layer and Application layer are separate and independent. If a client wants to be authenticated on the LDAP layer it must request it.
Does the RFC explicitly authorize controlling access based on the client's IP address? Does slapd allow controlling access based on the client's IP address?
Howard is being very literal in his reading of the LDAP RFCs.
RFCs are not poems, they aren't meant to be loosely interpreted.
Sorry Howard, what I said was in defense of Jordan and not intended as an attack on you. I understand and agree with your position, that the ultimate authority is the specification and anything that happens must be consistent with the specification.
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.
openldap-technical@openldap.org
-
David Hawes -
Howard Chu -
Jordan Brown -
Ondřej Kuzník -
Quanah Gibson-Mount -
Sean Gallagher