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:
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
lux-integ wrote:
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:
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.
lux-integ wrote:
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:
The SASL SCRAM mechanism works without a plaintext userPassword.
Michael Ströder wrote:
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:
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:
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:
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.
Michael Ströder wrote:
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