Hi all,
There are a few protocols that use a HA1[1] password hash, such as HTTP DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than DIGEST)
Is there a standard LDAP attribute name for storing a HA1 value or should it be stored in a regular userPassword attribute as described in the manual[4]?
I came across smbk5pwd for keeping SMB password attributes in sync. Is there a similar facility for keeping HA1 passwords in sync when a user changes the password or how could a developer go about adding that, would the smbk5pwd source be a useful model?
Regards,
Daniel
1. http://tools.ietf.org/html/rfc2617#section-3 2. https://tools.ietf.org/html/rfc3261#section-22.4 3. https://tools.ietf.org/html/rfc5389#section-15.4 4. http://www.openldap.org/doc/admin24/security.html#Password%20Storage
Daniel Pocock wrote:
There are a few protocols that use a HA1[1] password hash, such as HTTP DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than DIGEST)
Is there a standard LDAP attribute name for storing a HA1 value or should it be stored in a regular userPassword attribute as described in the manual[4]?
Do you want to use the LDAP server only as dumb password store or do you also want to use this attribute for LDAP bind operation?
Ciao, Michael.
On 13/07/15 11:03, Michael Ströder wrote:
Daniel Pocock wrote:
There are a few protocols that use a HA1[1] password hash, such as HTTP DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than DIGEST)
Is there a standard LDAP attribute name for storing a HA1 value or should it be stored in a regular userPassword attribute as described in the manual[4]?
Do you want to use the LDAP server only as dumb password store or do you also want to use this attribute for LDAP bind operation?
Good question
For the DIGEST and HMAC algorithms, the most interesting possibility would be for OpenLDAP to perform validation:
1. HTTP server (or SIP proxy or whatever) creates a challenge header and sends it to the end user 2. User responds with an authorization token 3. HTTP server gives a copy of the challenge and the response to the OpenLDAP server 4. OpenLDAP gives a validation true/false response
In this case, clients can't read the HA1 from LDAP
Could that be done with a bind? Does it have any performance impact doing a bind or is there a more lightweight way to achieve this?
There is already a similar solution for RADIUS, rlm_digest http://freeradius.org/radiusd/man/rlm_digest.txt
On 13/07/15 11:37, Daniel Pocock wrote:
On 13/07/15 11:03, Michael Ströder wrote:
Daniel Pocock wrote:
There are a few protocols that use a HA1[1] password hash, such as HTTP DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than DIGEST)
Is there a standard LDAP attribute name for storing a HA1 value or should it be stored in a regular userPassword attribute as described in the manual[4]?
Do you want to use the LDAP server only as dumb password store or do you also want to use this attribute for LDAP bind operation?
Good question
For the DIGEST and HMAC algorithms, the most interesting possibility would be for OpenLDAP to perform validation:
- HTTP server (or SIP proxy or whatever) creates a challenge header and
sends it to the end user 2. User responds with an authorization token 3. HTTP server gives a copy of the challenge and the response to the OpenLDAP server 4. OpenLDAP gives a validation true/false response
In this case, clients can't read the HA1 from LDAP
Could that be done with a bind? Does it have any performance impact doing a bind or is there a more lightweight way to achieve this?
There is already a similar solution for RADIUS, rlm_digest http://freeradius.org/radiusd/man/rlm_digest.txt
I'm just wondering if anybody can give any more feedback about this issue before I look at coding anything for it?
Daniel Pocock wrote:
On 13/07/15 11:37, Daniel Pocock wrote:
On 13/07/15 11:03, Michael Ströder wrote:
Daniel Pocock wrote:
There are a few protocols that use a HA1[1] password hash, such as HTTP DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than DIGEST)
Is there a standard LDAP attribute name for storing a HA1 value or should it be stored in a regular userPassword attribute as described in the manual[4]?
Do you want to use the LDAP server only as dumb password store or do you also want to use this attribute for LDAP bind operation?
Good question
For the DIGEST and HMAC algorithms, the most interesting possibility would be for OpenLDAP to perform validation:
- HTTP server (or SIP proxy or whatever) creates a challenge header and
sends it to the end user 2. User responds with an authorization token 3. HTTP server gives a copy of the challenge and the response to the OpenLDAP server 4. OpenLDAP gives a validation true/false response
In this case, clients can't read the HA1 from LDAP
Could that be done with a bind? Does it have any performance impact doing a bind or is there a more lightweight way to achieve this?
You can't pass all the necessary parameters (nonce, challenge, uri, etc.) to the LDAP server using a Simple Bind request. But e.g. HTTP DIGEST is the same as the SASL DIGEST-MD5 mechanism. You could pass thru the parameters from an LDAP SASL Bind request, with the HTTP (or whatever) server just acting as a MITM. Note that in that case, the LDAP server's SASL library generates the challenge, the HTTP server must parse it and pass it on to the client.
There's no particular performance impact for Bind itself; whatever crypto the underlying mechanism uses will have its own cost of course.
There is already a similar solution for RADIUS, rlm_digest http://freeradius.org/radiusd/man/rlm_digest.txt
I'm just wondering if anybody can give any more feedback about this issue before I look at coding anything for it?
(re-sent due to mailing list issue)
On 16/07/15 13:09, Howard Chu wrote:
Daniel Pocock wrote:
On 13/07/15 11:37, Daniel Pocock wrote:
On 13/07/15 11:03, Michael Ströder wrote:
Daniel Pocock wrote:
There are a few protocols that use a HA1[1] password hash, such as HTTP DIGEST[1], SIP DIGEST[2] and TURN[3] (which uses HMAC rather than DIGEST)
Is there a standard LDAP attribute name for storing a HA1 value or should it be stored in a regular userPassword attribute as described in the manual[4]?
Do you want to use the LDAP server only as dumb password store or do you also want to use this attribute for LDAP bind operation?
Good question
For the DIGEST and HMAC algorithms, the most interesting possibility would be for OpenLDAP to perform validation:
- HTTP server (or SIP proxy or whatever) creates a challenge header and
sends it to the end user 2. User responds with an authorization token 3. HTTP server gives a copy of the challenge and the response to the OpenLDAP server 4. OpenLDAP gives a validation true/false response
In this case, clients can't read the HA1 from LDAP
Could that be done with a bind? Does it have any performance impact doing a bind or is there a more lightweight way to achieve this?
You can't pass all the necessary parameters (nonce, challenge, uri, etc.) to the LDAP server using a Simple Bind request. But e.g. HTTP DIGEST is the same as the SASL DIGEST-MD5 mechanism. You could pass thru the parameters from an LDAP SASL Bind request, with the HTTP (or whatever) server just acting as a MITM. Note that in that case, the LDAP server's SASL library generates the challenge, the HTTP server must parse it and pass it on to the client.
There's no particular performance impact for Bind itself; whatever crypto the underlying mechanism uses will have its own cost of course.
There is already a similar solution for RADIUS, rlm_digest http://freeradius.org/radiusd/man/rlm_digest.txt
I'm just wondering if anybody can give any more feedback about this issue before I look at coding anything for it?
Thanks for the feedback on this issue.
What you describe using SASL may work for HTTP and SIP because they both use DIGEST. SIP DIGEST is very similar to HTTP DIGEST.
TURN (RFC 5766), however, uses HMAC. It still uses the same HA1 hashed version of the secret as an input to the algorithm.
If the OpenLDAP server stores plaintext passwords, the HA1 value can be created on the fly for DIGEST or HMAC challenge/response.
If the OpenLDAP server doesn't store plaintext passwords, then the HA1 values need to be stored in attributes and those attributes need to be updated whenever the user does a password change.
Regards,
Daniel
openldap-technical@openldap.org
-
Daniel Pocock -
Howard Chu -
Michael Ströder