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/
