Daniel Pocock wrote: > > > On 06/03/16 20:49, Howard Chu wrote: >> Daniel Pocock wrote: >>> >>> >>> On 06/03/16 20:00, Howard Chu wrote: >>>> [email protected] 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/
