Hello openldap-technical,
I'm wondering what the OpenLDAP-technical World thinks about LDAP authentication secrets. A couple observations and questions:
1. RFC 4519 allows userPassword to be multi-valued and it gives some rationale which is logical, but it also seems to lack imagination. There seem to be more possibilities for abuse by defining attributeType this way than legitimate use cases. Is there any way to force userPassword to be single-valued? Has anyone attempted this? 2. Assuming you decide to ditch passwords, and use TLS EXTERNAL, you still have the problem of storing the key, and the risk that if the key is stolen, than someone other than you can authenticate as you. Of course store it on storage with permissions and ownership of files set correctly. That goes without being said, but storage is not always perfectly secure or private, so let's not trust it completely. Short lifetimes would be one mitigation. And CRLs of course. What else do people do? 3. Is there anyway to have ldap* commands read the key in from an environment variable or call to gpg/secrets store /etc? Funky alias / bash-wrapper yeah but I'm looking for something less clunky.
many thanks,
Chris Paul | Rex Consulting | https://www.rexconsulting.net
On 3/12/22 00:02, Christopher Paul wrote:
- RFC 4519 allows userPassword to be multi-valued and it gives some rationale which is logical, but it also seems to lack imagination. There seem to be more possibilities for abuse by defining attributeType this way than legitimate use cases. Is there any way to force userPassword to be single-valued? Has anyone attempted this?
You cannot modify the standard schema. But you can use overlay slapo-constraint to limit the number of userPassword values to 1.
- Assuming you decide to ditch passwords, and use TLS EXTERNAL, you still have the problem of storing the key, and the risk that if the key is stolen, than someone other than you can authenticate as you.
You're speaking about TLS client certs? In theory you could use libldap linked to OpenSSL with PKCS#11 support. But even if you manage to get it working, the client setup is complicated and the usual client software will not easily work with that.
- Is there anyway to have ldap* commands read the key in from an environment variable or call to gpg/secrets store /etc? Funky alias / bash-wrapper yeah but I'm looking for something less clunky.
Which users use the LDAP client? systemd has a directive LoadCredential= which might also somewhat help.
But all that depends on your specific use-case.
Ciao, Michael.
On 3/11/22 5:01 PM, Michael Ströder wrote:
You cannot modify the standard schema. But you can use overlay slapo-constraint to limit the number of userPassword values to 1.
Thanks. This is useful, Michael.
You're speaking about TLS client certs? In theory you could use libldap linked to OpenSSL with PKCS#11 support. But even if you manage to get it working, the client setup is complicated and the usual client software will not easily work with that.
Yeah, TLS client certs. I like complicated, so I may try, but for users of course, something simpler is better.
Which users use the LDAP client? systemd has a directive LoadCredential= which might also somewhat help.
Ah... this is a new thing to me Thanks again, Michael. I'm going to look into it. I notice it's somewhat recent and that RedHat and variants do not yet support it.
Christopher Paul wrote:
Hello openldap-technical,
I'm wondering what the OpenLDAP-technical World thinks about LDAP authentication secrets. A couple observations and questions:
- RFC 4519 allows userPassword to be multi-valued and it gives some rationale which is logical, but it also seems to lack imagination. There seem to be more possibilities for abuse by defining attributeType this way than legitimate use cases. Is there any way to force userPassword to be single-valued? Has anyone attempted this?
The LDAP Password Policy spec requires userPassword to store only 1 value.
- Assuming you decide to ditch passwords, and use TLS EXTERNAL, you still have the problem of storing the key, and the risk that if the key is stolen, than someone other than you can authenticate as you. Of course store it on storage with permissions and ownership of files set correctly. That goes without being said, but storage is not always perfectly secure or private, so let's not trust it completely. Short lifetimes would be one mitigation. And CRLs of course. What else do people do?
You can generate short lifetime certs easily enough but keys tend to still be long lived. Likewise in Kerberos where tickets are short lifetime, but you still use a longlived password to get the initial TGT.
You can use the autoCA overlay in OpenLDAP to streamline certificate generation for all of your users and set them to arbitrarily long or short lifetimes. No matter what security mechanism you develop, the key management problem remains unchanged.
- Is there anyway to have ldap* commands read the key in from an environment variable or call to gpg/secrets store /etc? Funky alias / bash-wrapper yeah but I'm looking for something less clunky.
The OpenLDAP software doesn't even touch any strong secrets - they're all managed by the relevant TLS / Kerberos / whatever library, so this question should be directed to those packages.
On 3/12/22 4:26 AM, Howard Chu wrote:
The LDAP Password Policy spec requires userPassword to store only 1 value.
But simple auth will still work for all of them if someone manually adds others right?
You can generate short lifetime certs easily enough but keys tend to still be long lived. Likewise in Kerberos where tickets are short lifetime, but you still use a longlived password to get the initial TGT.
You can use the autoCA overlay in OpenLDAP to streamline certificate generation for all of your users and set them to arbitrarily long or short lifetimes. No matter what security mechanism you develop, the key management problem remains unchanged.
But if you're swapping out the cert, you can optionally re-key at the same time, so I think we add to the list of TLS client best practice: re-key when you re-cert. Right? There are no great costs to re-keying, unless I am missing something.
- Is there anyway to have ldap* commands read the key in from an environment variable or call to gpg/secrets store /etc? Funky alias / bash-wrapper yeah but I'm looking for something less clunky.
The OpenLDAP software doesn't even touch any strong secrets - they're all managed by the relevant TLS / Kerberos / whatever library, so this question should be directed to those packages.
Thanks for the redirect, Howard. I will ask.
Christopher Paul wrote:
On 3/12/22 4:26 AM, Howard Chu wrote:
The LDAP Password Policy spec requires userPassword to store only 1 value.
But simple auth will still work for all of them if someone manually adds others right?
Yes, if you're able to add others they will all be checked on a Bind attempt.
You can generate short lifetime certs easily enough but keys tend to still be long lived. Likewise in Kerberos where tickets are short lifetime, but you still use a longlived password to get the initial TGT.
You can use the autoCA overlay in OpenLDAP to streamline certificate generation for all of your users and set them to arbitrarily long or short lifetimes. No matter what security mechanism you develop, the key management problem remains unchanged.
But if you're swapping out the cert, you can optionally re-key at the same time, so I think we add to the list of TLS client best practice: re-key when you re-cert. Right? There are no great costs to re-keying, unless I am missing something.
Generating key pairs tends to be the most compute-intensive part of any of this, so usually sites try to do it only once per user. Though that may be more of a consideration for RSA and not as significant for ECC based pubkey schemes.
On 3/12/22 18:52, Howard Chu wrote:
Christopher Paul wrote:
But if you're swapping out the cert, you can optionally re-key at the same time, so I think we add to the list of TLS client best practice: re-key when you re-cert. Right? There are no great costs to re-keying, unless I am missing something. >
Generating key pairs tends to be the most compute-intensive part of any of this, so usually sites try to do it only once per user. Though that may be more of a consideration for RSA and not as significant for ECC based pubkey schemes.
It's not a big deal to re-key each time you issue a short-term cert. I'm doing this for SSH in EKCA all the time even with RSA-4096.
Generally using TLS client certs in a secure way is not well supported in most clients. Or does libldap today support asking for a client key passphrase?
Ciao, Michael.
Michael Ströder wrote:
Generally using TLS client certs in a secure way is not well supported in most clients. Or does libldap today support asking for a client key passphrase?
As already stated, OpenLDAP has nothing to do with any of the key material. The OpenSSL library already prompts for key passphrase when needed, we have nothing to do with that.
On 3/12/22 21:24, Howard Chu wrote:
Michael Ströder wrote:
Generally using TLS client certs in a secure way is not well supported in most clients. Or does libldap today support asking for a client key passphrase? >
As already stated, OpenLDAP has nothing to do with any of the key material. The OpenSSL library already prompts for key passphrase when needed, we have nothing to do with that.
Some LDAP clients using libldap are not command-line programs.
Ciao, Michael.
openldap-technical@openldap.org
-
Christopher Paul -
Howard Chu -
Michael Ströder