12:13 a.m.
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
1:27 a.m.
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
1:32 a.m.
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 )|
1:51 a.m.
Am Mon, 8 Dec 2014 08:13:25 +0000
schrieb "lux-integ" <lux-integ(a)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
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
1:52 a.m.
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.
3:42 a.m.
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.
3:44 a.m.
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.
5:26 a.m.
Michael Ströder wrote:
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.
The SASL SCRAM mechanism works without a plaintext userPassword.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5:38 a.m.
Howard Chu wrote:
Michael Ströder wrote:
> 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.
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.
5:56 a.m.
Michael Ströder wrote:
Howard Chu wrote:
> Michael Ströder wrote:
>> 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.
>
> 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
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6:06 a.m.
Howard Chu wrote:
Michael Ströder wrote:
> Howard Chu wrote:
>> Michael Ströder wrote:
>>> 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.
>>
>> 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.
6:13 a.m.
Michael Ströder wrote:
Howard Chu wrote:
> Michael Ströder wrote:
>> Howard Chu wrote:
>>> Michael Ströder wrote:
>>>> 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.
>>>
>>> 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
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6:55 a.m.
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.
7:44 a.m.
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
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11:05 a.m.
New subject: Using SCRAM-SHA-1 and authPassword
Howard Chu wrote:
Michael Ströder wrote:
> Howard Chu wrote:
>> Michael Ströder wrote:
>>> 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.
>>
>> 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.
12:14 p.m.
New subject: Using SCRAM-SHA-1 and authPassword
Michael Ströder wrote:
Howard Chu wrote:
> Michael Ströder wrote:
>> Howard Chu wrote:
>>> Michael Ströder wrote:
>>>> 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.
>>>
>>> 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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3103
days inactive
3103
days old
openldap-technical@openldap.org
16 comments
4 participants
participants (4)
-
Dieter Klünter -
Howard Chu -
lux-integ -
Michael Ströder