openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

(ITS#8381) Proposing new mirror for OpenLDAP sources
by dcoutadeur＠linagora.com 07 Mar '16

07 Mar '16

Full_Name: David Coutadeur Version: 2.4.44 OS: Debian 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.103.166.6) Linagora (France) is now hosting a new mirror for OpenLDAP sources. It is available at: http://repository.linagora.org/OpenLDAP/ http://repository.linagora.com/OpenLDAP/ The latter (.com) will not be supported in the long term. Please update MIRRORS file accordingly. Regards, David

1 0

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 07 Mar '16

07 Mar '16

On 06/03/16 23:02, Howard Chu wrote: > 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. I fully agree with that - the HMAC-SHA1 message verification for TURN, like the DIGEST-MD5 code, would be in Cyrus SASL or in the TURN server (LDAP client). The OpenLDAP manual, s15.2.3 about DIGEST-MD5 explains "it needs access to the plaintext password". The DIGEST-MD5 code that uses the password is here: https://cgit.cyrus.foundation/cyrus-sasl/tree/plugins/digestmd5.c#n440 and it takes the plaintext password and transforms it into a HA1 string. Notice that: HA1 = MD5(user:realm:password) This is a repetitive calculation that does not involve the nonce, salt or any other transient value. HA1 is always the same value for any given user/realm/password permutation. Therefore, OpenLDAP could store HA1 values instead of plaintext values. In fact, Apache already does the same thing with a flat file maintained by the htdigest utility: $ htdigest -c /tmp/test.ha1 example.org daniel instead of storing plaintext values in a file. The HA1 values, not being salted, are still sensitive but some sites may prefer to store the HA1 values instead of plaintext values. So section 15.2.3 could actually be changed: "it needs access to the plaintext password or a password that has already been hashed in HA1" An alternative is that the TURN server process could bind to the LDAP server and then query the HA1 attribute for any user or the HA1 values could be periodically extract into a flat file similar to that created by the htdigest utility. I agree that people who have plaintext passwords don't need to store any HA1 attribute, but if somebody does not have plaintext passwords and does not want to have plaintext passwords, it appears that the HA1 hashing needs to be done in OpenLDAP on password changes. This would also appear to require a change to the Cyrus code so that it can accept either the plaintext or HA1 from the LDAP entry and the slapd auxprop plugin would need to be able to return either attribute. > >> 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. >

1 0

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 06 Mar '16

06 Mar '16

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/

1 0

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 06 Mar '16

06 Mar '16

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

1 0

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 06 Mar '16

06 Mar '16

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/

1 0

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 06 Mar '16

06 Mar '16

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

1 0

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 06 Mar '16

06 Mar '16

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 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? > > Discussed on the mailing list already[5] > > 1. http://tools.ietf.org/html/rfc2617#section-3 > 2. https://tools.ietf.org/html/rfc3261#cection-22.4 > 3. https://tools.ietf.org/html/rfc5389#section-15.4 > 4. http://www.openldap.org/doc/admin24/security.html#Password%20Storage > 5. http://www.openldap.org/lists/openldap-technical/201507/msg00039.html > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8380) Feature request: make a plugin like smbk5pwd for the HA1 and HA1b hashes used in DIGEST and HMAC
by daniel＠pocock.pro 06 Mar '16

06 Mar '16

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]? 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? Discussed on the mailing list already[5] 1. http://tools.ietf.org/html/rfc2617#section-3 2. https://tools.ietf.org/html/rfc3261#cection-22.4 3. https://tools.ietf.org/html/rfc5389#section-15.4 4. http://www.openldap.org/doc/admin24/security.html#Password%20Storage 5. http://www.openldap.org/lists/openldap-technical/201507/msg00039.html

1 0

(ITS#8379) URL changes for funded and managed
by mhardin＠symas.com 01 Mar '16

01 Mar '16

Full_Name: Matthew Hardin Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.109.202.222) Thank you for the attribution for the management and hosting of the openldap.org website. We respectfully request the following changes to the URLs for the logos: 1. Please change the link URL for the "Site funded and managed by" logo to: https://symas.com/about-openldap/?utm_source=OpenLDAP&utm_medium=ctr&utm_ca… 2. Please change the link URL for the "Hosting provided by" logo to: http://symas.com/?utm_source=openldap&utm_medium=ctr&utm_campaign=OpenLdapH… Thanks

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 01 Mar '16

01 Mar '16

Oh, and one more observation, the result is intermittent. The starttls connection actually fails as it is supposed to, something like 1/100 attempts. Martin....

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs