Sean Gallagher wrote:
On 26/06/2023 7:40 pm, Howard Chu wrote:
That feature is already available using TLSVerifyClient in the slapd config.
Not really. Using the TLSVerifyClient mechanism could be made to work and would be a nice solution but it isn't there yet. To make this this work, you would need to pass to libldap, some type of specification of the names of legitimate clients. Then in the tls_o.c:tlso_verify_cb() function, compare the name on the client cert with the specification and return the pass/fail status back to the TLS layer. Then it would all "just work".
The average user might be surprised to learn that TLSVerifyClient does not currently involve checking the client's name. You would intuitively think that was pretty important.
The point of a certificate-based authentication system is not to have to implement authentication rules for each and every individual user. An LDAP server should only trust certificates issued by a single CA; that CA should only be issuing certs to valid users. Ideally, the LDAP server should be the CA, which is what slapo-autoca is designed for.
An LDAP server is not a web server or a client. There is no reason for it to trust certs from multiple CAs.
Pure nonsense.
Pure hubris.
It's sad when it takes a disaster to affect real change.
Pure ignorance.
The point of a certificate-based authentication system is not to have to implement authentication rules for each and every individual user. An LDAP server should only trust certificates issued by a single CA; that CA should only be issuing certs to valid users. Ideally, the LDAP server should be the CA, which is what slapo-autoca is designed for.
Any peer in a TLS session that does validation seems to have three things to validate: 1. the x.509 subject name matching the name as known or claimed by the peer 2. the signing authority 3. the validity date
Are we saying that the LDAP server should only care about #2?
Christopher Paul wrote:
The point of a certificate-based authentication system is not to have to implement authentication rules for each and every individual user. An LDAP server should only trust certificates issued by a single CA; that CA should only be issuing certs to valid users. Ideally, the LDAP server should be the CA, which is what slapo-autoca is designed for.
Any peer in a TLS session that does validation seems to have three things to validate:
- the x.509 subject name matching the name as known or claimed by the peer
The above applies to clients validating servers. TLS is client-server, not peer-to-peer.
Clients with certs assert their name to servers, and if the server trusts the cert issuer then it accepts the name that the client asserted.
- the signing authority
- the validity date
Are we saying that the LDAP server should only care about #2?
The date is important too of course. And revocation checks too, but they aren't relevant to this conversation.
Clients with certs assert their name to servers, and if the server trusts the cert issuer then it accepts the name that the client asserted.
Yes, precisely. So when you compare that name with that of your known clients, you can be confident you are not being duped.
On 28/06/2023 3:41 am, Howard Chu wrote:
The point of a certificate-based authentication system is not to have to implement authentication rules for each and every individual user.
It needn't be so fine grained. Just restrict the namespace of accepted certs to that which the system integrator has authority over.
that CA should only be issuing certs to valid users. Ideally, the LDAP server should be the CA
That is too opinionated for universal application. I am sure I am not alone in choosing to use a public CA.
TLS gives you *authentication*. It proves that the bearer owns the DN specified in the certificate. There is no list of "approved clients" associated with that authentication check.
The consumer (here, the LDAP server) must then do an *authorization* check, determining whether that DN is allowed to access a particular resource or perform a particular action. This authorization check might involve ACLs, or lists of approved clients, or similar structures.
--On Wednesday, June 28, 2023 10:12 AM +1000 Sean Gallagher sean@teletech.com.au wrote:
On 28/06/2023 3:41 am, Howard Chu wrote:
The point of a certificate-based authentication system is not to have to implement authentication rules for each and every individual user.
It needn't be so fine grained. Just restrict the namespace of accepted certs to that which the system integrator has authority over.
that CA should only be issuing certs to valid users. Ideally, the LDAP server should be the CA
That is too opinionated for universal application. I am sure I am not alone in choosing to use a public CA.
We use a public CA for the TLS sessions, and a private CA for SASL/EXTERNAL. We run our own PKI on the AD side of things too. Using a public CA for client certs seems very odd to me.
--Quanah
On 28/06/2023 12:14 pm, Quanah Gibson-Mount wrote:
We use a public CA for the TLS sessions, and a private CA for SASL/EXTERNAL. We run our own PKI on the AD side of things too. Using a public CA for client certs seems very odd to me.
We also use a mix of Public-Purchased, Public-Free and Private certs. The LDAP clients are a handful of machines with normal machine certs that are public-free certs for various reasons. These are short-dated certs that get updated frequently and automatically. With all that machinery in place, it seems crazy to introduce yet another CA into the mix. Running the proxy is not that big a deal.
I think, as the use of Public-free CA's catches on, and people realize that these certs can be used on private networks, this use case will only grow.
On 6/27/2023 7:14 PM, Quanah Gibson-Mount wrote:
Using a public CA for client certs seems very odd to me.
Depends on your use case. Think of it as a form of federated login. Many sites will let you log in with your Google username and password (or Amazon or Facebook or ...); why not let you log in using your Google-issued certificate?
Greetings.
On 28 Jun 2023, at 3:41, Jordan Brown wrote:
On 6/27/2023 7:14 PM, Quanah Gibson-Mount wrote:
Using a public CA for client certs seems very odd to me.
Depends on your use case. Think of it as a form of federated login.
Indeed. I've done something similar in the past (this was with access to a web service rather than an LDAP server, but the logic is the same).
Some of my users had, and knew how to use, X.509 certs issued by a large computing grid. So I got my server to trust the CA's cert, and listed the DNs allowed access. The grid CA did the legwork of setting up the PKI and checking the users, and I piggybacked on that, feeling rather smart. Unfortunately, not _all_ of the relevant users had those certs, so I still had to set up a local CA, which meant it ended up more trouble than it was in fact worth.
Best wishes,
Norman
--On Wednesday, June 28, 2023 3:41 AM +0000 Jordan Brown openldap@jordan.maileater.net wrote:
On 6/27/2023 7:14 PM, Quanah Gibson-Mount wrote:
Using a public CA for client certs seems very odd to me.
Depends on your use case. Think of it as a form of federated login. Many sites will let you log in with your Google username and password (or Amazon or Facebook or ...); why not let you log in using your Google-issued certificate?
I guess it comes to an issue of trust. I wouldn't trust Amazon, Facebook, or Google issued certificates, and I personally avoid making use of those types of integrations for username/password.
--Quanah
On 6/28/2023 6:59 AM, Quanah Gibson-Mount wrote:
I guess it comes to an issue of trust. I wouldn't trust Amazon, Facebook, or Google issued certificates, and I personally avoid making use of those types of integrations for username/password.
Indeed. A certificate-based scheme would be more trustworthy, because the issuer isn't contacted on every login and so can't track where you've used the certificate. You *would* have to trust that they only issue one certificate for any given DN, or at least that they ensure that they all go to the same authenticated user, or that they revoke ones that have been replaced. But a data aggregator might still be able to connect dots that you might not want connected.
I would *not* trust that the DN represents any particular human, only that it's the same certificate that was used to set up the authentication.
But your level of trust and my level of trust are not immediately important. What's important is that it's not silly to trust such an organization and its certificates.
On 28/06/2023 11:59 pm, Quanah Gibson-Mount wrote:
I guess it comes to an issue of trust. I wouldn't trust Amazon, Facebook, or Google issued certificates, and I personally avoid making use of those types of integrations for username/password.
It's really hard to avoid depending on and putting some trust in third parties in computing. You say I shouldn't trust a public CA but I should trust you (OpenLDAP). The CA and OpenLDAP are both third parties to me. There is no clear winner here, and in fact, denying adopters of your software the option of choosing the CA just looks suspicious. Obviously, by using OpenLDAP, I choose to trust it's authors and by extending this trust to OpenLDAP I gain convenience. There is always a tradeoff - risk versus reward. This is my tradeoff to make, as the risk is mine and not OpenLDAP's.
By choosing to trust a public CA (a not unprecedented or unreasonable thing to do) I gain the convenience of using off-the-shelf software without burdensome installation and management overhead.
If the public CA betrays my trust and issues certificates for my domain to someone else, the system is immediately compromised. That is not OpenLDAP's fault and that risk would be present regardless of whatever trust paradigm OpenLDAP uses. Using the public CA for OpenLDAP authentication does not add to my overall risk and I believe it is a perfectly reasonable thing to do.
I am not suggesting, every user of OpenLDAP should make the same decisions I have done. Just that OpenLDAP should acknowledge the validity of my decisions and consider supporting this use case by offering a mechanism restrict the names on publicly issued client certificates.
openldap-technical@openldap.org
-
Christopher Paul -
Howard Chu -
Jordan Brown -
Norman Gray -
Quanah Gibson-Mount -
Sean Gallagher