Greetings,
I have been searching webpages for guidance on using a smartcard ( also know as an HSM ) for storing passwords for an ldap database on a linux system.
This would include for instance how would the userPassword (attrribute) be specified - i.e. how to specify the userPassword to read the PIN/SO- PIN/PUK{whatever} of the HSM/smart-card etc etc ??
Any guidance would be much appreciated.
Yours sincerely luxInteg
Am Mon, 8 Dec 2014 08:13:25 +0000 schrieb "lux-integ" lux-integ@btconnect.com:
Greetings,
I have been searching webpages for guidance on using a smartcard ( also know as an HSM ) for storing passwords for an ldap database on a linux system.
This would include for instance how would the userPassword (attrribute) be specified - i.e. how to specify the userPassword to read the PIN/SO- PIN/PUK{whatever} of the HSM/smart-card etc etc ??
Any guidance would be much appreciated.
RFC-4513 describes LDAP Authentication Methods. I don't know much about HSM/smartcards, but if the provided key is a X.509 certificate, than it would be simple. RFC-4422 describes SASL, if your smatcard provider is complying with this RFC, than it could be realised.
-Dieter
On Monday 08 December 2014 09:51:47 Dieter Klünter wrote:
RFC-4513 describes LDAP Authentication Methods. I don't know much about HSM/smartcards, but if the provided key is a X.509 certificate, than it would be simple
yes I will consider x509 certificates placed within the smart-card
lux-integ wrote:
On Monday 08 December 2014 09:51:47 Dieter Klünter wrote:
RFC-4513 describes LDAP Authentication Methods. I don't know much about HSM/smartcards, but if the provided key is a X.509 certificate, than it would be simple
yes I will consider x509 certificates placed within the smart-card
Then using smartcards is mostly a client issue with the client being able to send SASL/EXTERNAL at least. On the server you probably want to define a authz-regexp mapping (besides correctly configuring the trust anchor for the client certs).
As said: If you use libldap you could use PKCS#11 provider module with OpenSSL's pkcs11 engine of libnss.
If you're using other LDAP client APIs you have to dive into what they provide.
Ciao, Michael.
lux-integ wrote:
I have been searching webpages for guidance on using a smartcard ( also know as an HSM ) for storing passwords for an ldap database on a linux system.
This would include for instance how would the userPassword (attrribute) be specified - i.e. how to specify the userPassword to read the PIN/SO- PIN/PUK{whatever} of the HSM/smart-card etc etc ??
It's not entirely clear what you want to achieve.
Which risks do you want to address?
1. For rootpw in configuration you should simply avoid setting it.
2. For protecting TLS client and server certificates' private keys you could e.g. use PKCS#11 modules with OpenSSL (pkcs11 engine) or libnss. Never did that myself though and it will be slow for most smartcard hardware. And it will be quite some work to implement a robust setup.
3. When using LDAP simple bind the client sends the password in clear and slapd hashes it and compares it to hashed 'userPassword' value(s).
4. In case of SASL mechanisms which require 'userPassword' value(s) in clear you would have to implement a reversible encryption password storage schema in an OpenLDAP overlay and adapt some other layer/components to correctly use it.
=> much more details needed
Ciao, Michael.
On Monday 08 December 2014 09:52:11 Michael Ströder wrote:
In case of SASL mechanisms which require 'userPassword' value(s) in clear you would have to implement a reversible encryption password storage schema in an OpenLDAP overlay and adapt some other layer/components to correctly use it
very ineresting has anyhing like this been attempted ?
links to any such attempts would me much appreciated ( if only to see how much work is involved )|
lux-integ wrote:
On Monday 08 December 2014 09:52:11 Michael Ströder wrote:
In case of SASL mechanisms which require 'userPassword' value(s) in clear you would have to implement a reversible encryption password storage schema in an OpenLDAP overlay and adapt some other layer/components to correctly use it
very ineresting has anyhing like this been attempted ?
In a project a collegue implemented a closed source overlay with RSA private key stored on disk.
For open source examples of overlays implementing different password storage methods see directory contrib/slapd-modules/passwd/ in OpenLDAP's source distribution.
Ciao, Michael.
Michael Ströder wrote:
- In case of SASL mechanisms which require 'userPassword' value(s) in clear
you would have to implement a reversible encryption password storage schema in an OpenLDAP overlay and adapt some other layer/components to correctly use it.
The SASL SCRAM mechanism works without a plaintext userPassword.
Howard Chu wrote:
Michael Ströder wrote:
- In case of SASL mechanisms which require 'userPassword' value(s) in clear
you would have to implement a reversible encryption password storage schema in an OpenLDAP overlay and adapt some other layer/components to correctly use it.
The SASL SCRAM mechanism works without a plaintext userPassword.
Yes, but AFAIK not the current cyrus-sasl implementation. Not to speak of lack of support by client implementations...
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
- In case of SASL mechanisms which require 'userPassword' value(s) in clear
you would have to implement a reversible encryption password storage schema in an OpenLDAP overlay and adapt some other layer/components to correctly use it.
The SASL SCRAM mechanism works without a plaintext userPassword.
Yes, but AFAIK not the current cyrus-sasl implementation.
Hm, Cyrus-SASL 2.1.26 with SCRAM was released in 2012.
Not to speak of lack of support by client implementations...
Any client that uses the Cyrus-SASL libraries should have support without any extra effort. They may need tweaks to support channel binding, but the basic authentication mech works.
Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
- In case of SASL mechanisms which require 'userPassword' value(s) in clear
you would have to implement a reversible encryption password storage schema in an OpenLDAP overlay and adapt some other layer/components to correctly use it.
The SASL SCRAM mechanism works without a plaintext userPassword.
Yes, but AFAIK not the current cyrus-sasl implementation.
Hm, Cyrus-SASL 2.1.26 with SCRAM was released in 2012.
Not to speak of lack of support by client implementations...
Any client that uses the Cyrus-SASL libraries should have support without any extra effort.
Hmm, some extra effort is needed in clients, especially when they have a UI or complex configuration. At a minimum you have to register a new SASL mech as being a password-based mech.
You might have guessed: I've added SCRAM support to web2ldap right after SCRAM support appeared in cyrus-sasl release.
They may need tweaks to support channel binding, but the basic authentication mech works.
Yes, but how many clients provide the input form or configuration for choosing SCRAM?
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
- In case of SASL mechanisms which require 'userPassword' value(s) in clear
you would have to implement a reversible encryption password storage schema in an OpenLDAP overlay and adapt some other layer/components to correctly use it.
The SASL SCRAM mechanism works without a plaintext userPassword.
Yes, but AFAIK not the current cyrus-sasl implementation.
Hm, Cyrus-SASL 2.1.26 with SCRAM was released in 2012.
Not to speak of lack of support by client implementations...
Any client that uses the Cyrus-SASL libraries should have support without any extra effort.
Hmm, some extra effort is needed in clients, especially when they have a UI or complex configuration. At a minimum you have to register a new SASL mech as being a password-based mech.
You might have guessed: I've added SCRAM support to web2ldap right after SCRAM support appeared in cyrus-sasl release.
They may need tweaks to support channel binding, but the basic authentication mech works.
Yes, but how many clients provide the input form or configuration for choosing SCRAM?
Given that Cyrus-SASL has a listmechs() API, I don't see why a client would ever have a hardcoded list of supported mechanisms. But OK, that's a topic for another time and place.
Howard Chu wrote:
Given that Cyrus-SASL has a listmechs() API, I don't see why a client would ever have a hardcoded list of supported mechanisms.
Please re-read in my posting: "At a minimum you have to register a new SASL mech as being a password-based mech."
Be assured that I really know what I'm talking about: An interactive UI needs some extra effort.
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
Given that Cyrus-SASL has a listmechs() API, I don't see why a client would ever have a hardcoded list of supported mechanisms.
Please re-read in my posting: "At a minimum you have to register a new SASL mech as being a password-based mech."
The SASL library provides its own prompts as well. ldap_sasl_interactive_bind works without knowing anything about the mechanism in advance.
Be assured that I really know what I'm talking about: An interactive UI needs some extra effort.
You aren't the first or only person to have wrapped a GUI around a SASL authentication.
https://git.gnome.org/browse/ekiga/tree/plugins/ldap/ldap-book.cpp
If your application requires updates every time a new loadable plugin is released for one of its underlying libraries, you're just making things harder on yourself.
Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
- In case of SASL mechanisms which require 'userPassword' value(s) in clear
you would have to implement a reversible encryption password storage schema in an OpenLDAP overlay and adapt some other layer/components to correctly use it.
The SASL SCRAM mechanism works without a plaintext userPassword.
Yes, but AFAIK not the current cyrus-sasl implementation.
Hm, Cyrus-SASL 2.1.26 with SCRAM was released in 2012.
Digging into cyrus-sasl's git repo I find a commit which indicates that it's possible to store pre-hashed SCRAM secrets in authPassword. Is that supported by OpenLDAP?
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
- In case of SASL mechanisms which require 'userPassword' value(s) in clear
you would have to implement a reversible encryption password storage schema in an OpenLDAP overlay and adapt some other layer/components to correctly use it.
The SASL SCRAM mechanism works without a plaintext userPassword.
Yes, but AFAIK not the current cyrus-sasl implementation.
Hm, Cyrus-SASL 2.1.26 with SCRAM was released in 2012.
Digging into cyrus-sasl's git repo I find a commit which indicates that it's possible to store pre-hashed SCRAM secrets in authPassword. Is that supported by OpenLDAP?
Not currently. The last time we discussed it, Kurt mentioned that the authPassword spec was a dead end and no one had implemented it.
openldap-technical@openldap.org
-
Dieter Klünter -
Howard Chu -
lux-integ -
Michael Ströder