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/
