Re: (ITS#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC

[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@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/