Re: (ITS#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by hyc＠symas.com
Daniel Pocock wrote:
>
>
> On 06/03/16 20:49, Howard Chu wrote:
>> Daniel Pocock wrote:
>>>
>>>
>>> On 06/03/16 20:00, Howard Chu wrote:
>>>> daniel(a)pocock.pro wrote:
>>>>> Full_Name: Daniel Pocock
>>>>> Version:
>>>>> OS: Debian
>>>>> URL: ftp://ftp.openldap.org/incoming/
>>>>> Submission from: (NULL) (2001:1620:b22::2042)
>>>>>
>>>>>
>>>>> 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]?
>>>>
>>>> The ITS is not for usage questions. You already asked this and were
>>>> answered on the discussion mailing list.
>>>>
>>>> http://www.openldap.org/lists/openldap-technical/201507/msg00073.html
>>>>
>>>> There is nothing here that requires any OpenLDAP development activity.
>>>> It's all already handled by the SASL Digest mechanism, as I already
>>>> noted in the above email.
>>>>
>>>> Closing this ITS.
>>>
>>>
>>> I didn't open this feature request to ask for somebody to implement it,
>>> I'm simply trying to track a number of items that I'm working on myself.
>>> Normally I open a bug/feature request in anything I work on in case
>>> somebody else wants to work on the same thing, it helps avoid
>>> duplication.
>>>
>>> The email thread doesn't fully resolve the issue, it does appear to
>>> require some plugin to be created for the server side, especially if the
>>> LDAP server doesn't keep plain text passwords. Given the fairly generic
>>> nature of the DIGEST algorithm, I also felt that when implemented, this
>>> code should be contributed to the OpenLDAP repository and not hosted
>>> elsewhere.
>>
>> Take the hint: RTF SASL Digest code. All the code you're asking for has
>> already been implemented in Cyrus SASL and is of zero concern to OpenLDAP.
>>
>> The most important skill of a programmer is being able to *read* - not
>> being able to write. Any fool can spew code.
>>
>
> I'm not sure if you've seen my reply to the list, it looks like it got
> stuck in moderation
>
> I understand your point about DIGEST and that may well work for HTTP and
> SIP. TURN, however, uses HMAC-SHA1 and that involves sending a copy of
> the entire message body to the authentication server for use in the
> algorithm:
> https://tools.ietf.org/html/rfc5766#page-51
You continue to fail to read.
Pasting this again
http://www.openldap.org/lists/openldap-technical/201507/msg00073.html
The required parameters cannot be passed in a Simple Bind request. The only
way to be able to pass what you want and have the server authenticate it is to
use a SASL mechanism. For TURN you may need to define your own SASL mechanism.
None of this has anything to do with OpenLDAP.
> CRAM-MD5 from SASL does HMAC but it does not appear to transfer entire
> message bodies in the manner required for TURN.
>
> DIGEST-MD5 and HMAC-SHA1 both use a HA1 value (or a cleartext password)
> as the lowest common denominator but otherwise they are not the same.
>
>> Your mention of smbk5pwd is totally off base as well. The reason the
>> smbk5pwd module was needed was because Samba 3 and the Kerberos5 KDC
>> both stored their secrets in separate and incompatible formats but
>> everyone wanted central coordinated administration for these separate
>> attributes. If you're writing something from scratch there is no reason
>> to use your own separate and incompatible attribute, and thus there is
>> no reason to require any special synchronization or coordination.
>>
>
> The reason I mentioned that is because it was the closest thing I could
> find to the concept of storing multiple password hashes, but I'm not
> locked in to that strategy. If there are cleartext passwords in LDAP
> then they can be used for all of these algorithms. If the administrator
> does not want to store cleartext values, however, then the salted
> password strings used for UNIX logins are not interchangeable with HA1
> hashed values, in that case, isn't it necessary to store and synchronize
> multiple values, hashed with each algorithm?
Once again you're back to software usage questions which is not what the ITS
is for.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 6 months
Re: (ITS#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by daniel＠pocock.pro
On 06/03/16 20:49, Howard Chu wrote:
> Daniel Pocock wrote:
>>
>>
>> On 06/03/16 20:00, Howard Chu wrote:
>>> daniel(a)pocock.pro wrote:
>>>> Full_Name: Daniel Pocock
>>>> Version:
>>>> OS: Debian
>>>> URL: ftp://ftp.openldap.org/incoming/
>>>> Submission from: (NULL) (2001:1620:b22::2042)
>>>>
>>>>
>>>> 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]?
>>>
>>> The ITS is not for usage questions. You already asked this and were
>>> answered on the discussion mailing list.
>>>
>>> http://www.openldap.org/lists/openldap-technical/201507/msg00073.html
>>>
>>> There is nothing here that requires any OpenLDAP development activity.
>>> It's all already handled by the SASL Digest mechanism, as I already
>>> noted in the above email.
>>>
>>> Closing this ITS.
>>
>>
>> I didn't open this feature request to ask for somebody to implement it,
>> I'm simply trying to track a number of items that I'm working on myself.
>> Normally I open a bug/feature request in anything I work on in case
>> somebody else wants to work on the same thing, it helps avoid
>> duplication.
>>
>> The email thread doesn't fully resolve the issue, it does appear to
>> require some plugin to be created for the server side, especially if the
>> LDAP server doesn't keep plain text passwords. Given the fairly generic
>> nature of the DIGEST algorithm, I also felt that when implemented, this
>> code should be contributed to the OpenLDAP repository and not hosted
>> elsewhere.
>
> Take the hint: RTF SASL Digest code. All the code you're asking for has
> already been implemented in Cyrus SASL and is of zero concern to OpenLDAP.
>
> The most important skill of a programmer is being able to *read* - not
> being able to write. Any fool can spew code.
>
I'm not sure if you've seen my reply to the list, it looks like it got
stuck in moderation
I understand your point about DIGEST and that may well work for HTTP and
SIP. TURN, however, uses HMAC-SHA1 and that involves sending a copy of
the entire message body to the authentication server for use in the
algorithm:
https://tools.ietf.org/html/rfc5766#page-51
CRAM-MD5 from SASL does HMAC but it does not appear to transfer entire
message bodies in the manner required for TURN.
DIGEST-MD5 and HMAC-SHA1 both use a HA1 value (or a cleartext password)
as the lowest common denominator but otherwise they are not the same.
> Your mention of smbk5pwd is totally off base as well. The reason the
> smbk5pwd module was needed was because Samba 3 and the Kerberos5 KDC
> both stored their secrets in separate and incompatible formats but
> everyone wanted central coordinated administration for these separate
> attributes. If you're writing something from scratch there is no reason
> to use your own separate and incompatible attribute, and thus there is
> no reason to require any special synchronization or coordination.
>
The reason I mentioned that is because it was the closest thing I could
find to the concept of storing multiple password hashes, but I'm not
locked in to that strategy. If there are cleartext passwords in LDAP
then they can be used for all of these algorithms. If the administrator
does not want to store cleartext values, however, then the salted
password strings used for UNIX logins are not interchangeable with HA1
hashed values, in that case, isn't it necessary to store and synchronize
multiple values, hashed with each algorithm?
Regards,
Daniel
7 years, 6 months
Re: (ITS#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by hyc＠symas.com
Daniel Pocock wrote:
>
>
> On 06/03/16 20:00, Howard Chu wrote:
>> daniel(a)pocock.pro wrote:
>>> Full_Name: Daniel Pocock
>>> Version:
>>> OS: Debian
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (2001:1620:b22::2042)
>>>
>>>
>>> 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]?
>>
>> The ITS is not for usage questions. You already asked this and were
>> answered on the discussion mailing list.
>>
>> http://www.openldap.org/lists/openldap-technical/201507/msg00073.html
>>
>> There is nothing here that requires any OpenLDAP development activity.
>> It's all already handled by the SASL Digest mechanism, as I already
>> noted in the above email.
>>
>> Closing this ITS.
>
>
> I didn't open this feature request to ask for somebody to implement it,
> I'm simply trying to track a number of items that I'm working on myself.
> Normally I open a bug/feature request in anything I work on in case
> somebody else wants to work on the same thing, it helps avoid duplication.
>
> The email thread doesn't fully resolve the issue, it does appear to
> require some plugin to be created for the server side, especially if the
> LDAP server doesn't keep plain text passwords. Given the fairly generic
> nature of the DIGEST algorithm, I also felt that when implemented, this
> code should be contributed to the OpenLDAP repository and not hosted
> elsewhere.
Take the hint: RTF SASL Digest code. All the code you're asking for has
already been implemented in Cyrus SASL and is of zero concern to OpenLDAP.
The most important skill of a programmer is being able to *read* - not being
able to write. Any fool can spew code.
Your mention of smbk5pwd is totally off base as well. The reason the smbk5pwd
module was needed was because Samba 3 and the Kerberos5 KDC both stored their
secrets in separate and incompatible formats but everyone wanted central
coordinated administration for these separate attributes. If you're writing
something from scratch there is no reason to use your own separate and
incompatible attribute, and thus there is no reason to require any special
synchronization or coordination.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 6 months
Re: (ITS#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by daniel＠pocock.pro
On 06/03/16 20:00, Howard Chu wrote:
> daniel(a)pocock.pro wrote:
>> Full_Name: Daniel Pocock
>> Version:
>> OS: Debian
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (2001:1620:b22::2042)
>>
>>
>> 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]?
>
> The ITS is not for usage questions. You already asked this and were
> answered on the discussion mailing list.
>
> http://www.openldap.org/lists/openldap-technical/201507/msg00073.html
>
> There is nothing here that requires any OpenLDAP development activity.
> It's all already handled by the SASL Digest mechanism, as I already
> noted in the above email.
>
> Closing this ITS.
I didn't open this feature request to ask for somebody to implement it,
I'm simply trying to track a number of items that I'm working on myself.
Normally I open a bug/feature request in anything I work on in case
somebody else wants to work on the same thing, it helps avoid duplication.
The email thread doesn't fully resolve the issue, it does appear to
require some plugin to be created for the server side, especially if the
LDAP server doesn't keep plain text passwords. Given the fairly generic
nature of the DIGEST algorithm, I also felt that when implemented, this
code should be contributed to the OpenLDAP repository and not hosted
elsewhere.
Regards,
Daniel
7 years, 6 months
