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

[Howard Chu <[e-mail]>]

Michael Ströder wrote:
> Howard Chu wrote:
>> Michael Ströder wrote:
>>> Howard Chu wrote:
>>>> 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.
>
> Conversion in this context means converting string representations of (salted)
> hashes. Obviously the algorithm and order of password and salt has to be the same.
>
>>> 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.
>
> We all know that clients have to use some a priori knowledge - most times
> called protocol. ;-)
>
> Another use-cases is dealing with data migration to server product of another
> vendor.

In which case the Admin must look up the documentation of the other vendor's 
product. It is not the IETF's job to serve as a clearinghouse for all 
vendor-specific implementation details, nor is it practical in the long run.

> => So I consider this draft to be useful.
>
>> Finally, an objectclass that defines "MUST userPassword" also has to be
>> considered broken. (Reminds me of groupOfNames / MUST member.)
>
> That's simply your personal opinion not a strong objecting argument.

You're obviously missing the bigger picture then. I shouldn't need to remind 
you of all the trouble that "MUST member" has caused. In this case, deleting a 
userPassword is a straightforward way of disabling authentication for an 
account. If your schema prevents this mechanism your schema is broken. That's 
not an opinion, that's fact.

>>>       userpasswordvalue  = cleartext-password / prefix hashed-password
>>
>> I think you should replace "hashed-password" with "scheme-specific data" and
>> stop there.
>
> That's a conclusion of your opinion. But I want to describe the *order* of
> password and salt used by any server I saw using the scheme.

You can describe those things separately, but this is as far as you should go 
with a formal syntax. Otherwise you will get sucked into the rathole of 
defining special cases for every currently known encoding, and you've already 
stated that you want to avoid that. So no, it's a logical conclusion from 
*your* opinion, not mine.

>> Provide examples for MD5/SHA/SHA-2 if you like, but emphasize that
>> these are just informal examples.
>
> The whole I-D has target "informational".
>
>> There's no reason someone can't come along
>> and use an unconstrained octet string after the scheme, if they really want to.
>
> Yes. But this would just be another scheme to be defined somewhere else.
> This draft does not claim to cover everything you could ever stuff into
> 'userPassword'.

But defining a formal syntax as you're doing *does* exactly that. Which is why 
I'm telling you you're making a mistake.

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