Re: [ldapext] draft-stroeder-hashed-userpassword-values-01

Michael Ströder wrote:
> Howard Chu wrote:
>> Andrew Findlay wrote:
>>> On Wed, Mar 13, 2013 at 11:39:28PM +0100, Michael Ströder wrote:
>>>
>>>>> I see this document is marked as being intended to be published as
>>>>> Informational, but it reads more like it's trying to be a standard.
>>>>
>>>> I tried to add some wording to avoid that misunderstanding in the next
>>>> revision of this draft:
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-stroeder-hashed-userpassword-values-01.txt
>>>>
>>>
>>> Still -01 ?
>>>
>>> You are explicitly excluding details of '{crypt}'. I think this is a
>>> mistake, especially in an informational document. {crypt} is
>>> extremely useful in transition scenarios, so people need to know about
>>> it.
>>
>> Who benefits from this document? What interoperability problems does it solve?
>
> Anybody who has to generate or compare such userPassword values.
>
>> Hashed userPassword values are strictly a server-internal implementation
>> detail, clients never need to know about them.
>
> Not true.
>
> 1. E.g. think of bulk sync processes where it's quite usual that you convert
> password hashes within the LDAP client - in some cases even salted.

If you can convert from one hash to another, the hash is broken.

> 2. Furthermore if a server does not support RFC 3062 and/or server-side
> hashing but supports this hashed values when performing password checking you
> also have to do client-side generation. This gets rare with recent server
> releases of various vendors but it's not something to completely ignore.

A server that can effectively read/use values but cannot write/create them in 
the first place has to be considered defective. Fine, don't ignore it, but 
footnote it. It doesn't deserve to be treated as in any way normal.

> 3. In some cases it's more appropriate that a LDAP client writes several
> attributes in a *single* LDAP write operation instead of using a add/modify
> with a subsequent Password Modify ext. op. E.g. when subschema has 'MUST
> userPassword' for an object class used.

Perhaps so. But this requires the client (or admin running the client) to 
already know what schemes the target server supports. So again, it's 
server-specific knowledge and isn't required for interoperability between 
heterogeneous implementations. Taking the opposite approach - there is no way 
for a server to advertise what mechanisms it supports, so an uninformed 
client/admin cannot possibly do this correctly anyway.

And on that note - no, I don't believe the server should advertise what its 
supported mechanisms are. Again, it's purely an internal matter, and there's 
no reason to give an arbitrary 3rd party a head start on cracking attempts.

Without advance knowledge, obtained out of band, none of these scenarios are 
feasible. The advance knowledge is always specific to a particular server 
deployment.

Finally, an objectclass that defines "MUST userPassword" also has to be 
considered broken. (Reminds me of groupOfNames / MUST member.)

>> The syntax specification is defective in at least 2 ways:
>>    1) it only allows a form "hashandsalt" which actually precludes any unsalted
>> hash mechanisms.
>
> Not true. The unsalted variant has simply a zero-length salt. For -02 I've
> added some text to clarify this.
>
>>    2) it only allows "b64-hashandsalt" which precludes any mechanisms that
>> don't use base64 format for their values. E.g. Unix crypt and Windows LANMAN
>> hash formats use their own binary-to-printable encoding, not base64.
>
> Well, at first I simply wanted to ignore this completely.
> But after Andrews request I've already changed it for upcoming -02 like this:
>
>      userpasswordvalue  = cleartext-password / prefix hashed-password

I think you should replace "hashed-password" with "scheme-specific data" and 
stop there. Provide examples for MD5/SHA/SHA-2 if you like, but emphasize that 
these are just informal examples. There's no reason someone can't come along 
and use an unconstrained octet string after the scheme, if they really want to.

>      prefix       = "{" scheme "}"
>      scheme = %x30-39 / %x41-5A / %x61-7a / %x2D-2F / %x5F
>           ;0-9, A-Z, a-z, "-", ".", "/", or "_"
>
>      hashed-password = b64-hashandsalt / crypt3-result
>
>      b64-hashandsalt = <base64 of hashandsalt>
>
>      hashandsalt = password-hash salt
>
>      password-hash = <digest of cleartext-password salt>
>
>      cleartext-password = %x00-FF
>
>      salt = %x00-FF
>
>      crypt3-result = <generated by Unix function crypt(3)>
>
> Please review this. Comments about clarity welcome.
>
> Ciao, Michael.
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/