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

[Hallvard Breien Furuseth <[e-mail]>]

I'm not convinced that this much detail is useful, but anyway:

You can document existing practice and recommend what implementations'
practice ought to be, but should say that the implementation's doc is
authoritative.  What implementations have you surveyed for that
existing practice?

If we generate 'userPassword's which this document says is OK but the
implementation does not support, then Bind can break in interesting
ways.  So users MUST NOT trust this document if the implementation
differs, which they must read the implementation doc to discover.

E.g. some implementation might have a scheme {SSHA} with a different
syntax like <hash "$" salt>.  Or:

>   Implementations MUST be prepared of handling field salt of arbitrary
>   length.

Who wants megabyte-sized salts?  It seems reasonable for the
implementation to set some arbitrary limit.  Both for convenience
and because you could do a DoS attack by setting a huge salt and
repeatedly Bind, forcing the server to hash a large value often.

================

Unix crypt(3):

This is a function, not a library.  Drop the 3 since non-Unix people
will wonder why we're passing 3 to the function.

The definition should boil down to "whatever crypt() returns on this
host", which is no more yucky than the notes above other schemes:-)
Perhaps less so since there's no point in giving a syntax, crypt()
should be used to both generate the hash and verify a password.

Please and add a reference to the quite general definition in the
Single Unix Specification at <http://www.unix.org/online.html>
functions/crypt.html.  It's free, but you must register to read it.

================

An EXAMPLES section with the same value and hash in different schemes
would be useful - including Linux {crypt}$1$ (salted MD5) and {SMD5}.

================

>>    Any value which do not adhere to this syntax MAY be treated as
>>    clear-text password (...)
>
> I know that this sounds kinda problematic but what is the actual risk?

Umm... The reason we use hashes at all is that if someone knows the
attribute value, he can't just type it in and Bind with it.

Please add the {CLEARTEXT} scheme from OpenLDAP for this purpose.
RECOMMEND that servers are configured to not recognize userPassword
values without a scheme.  And maybe that this config is the default.

================

>> 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'.

Yes it does.  The sentence
   "userPassword values MUST be represented by following syntax:"
claims to cover everything you could ever stuff into 'userPassword',
and thus that anything using different userPassword syntax is invalid.
That is wrong for schemes like {CRYPT} with different syntax, and
for servers which treat "{scheme}foo" as a cleartext password.

Instead you can say:
- Generally, syntax "{" scheme "}" scheme-parameters / cleartext pw
  like someone said.  Leave scheme-parameters unspecified.
- [The following listed schemes] share [the following more specific
  scheme-parameters definition].

Note that scheme-parameters need not involve a hashing or a password.
In OpenLDAP, {CLEARTEXT} does not hash.  I think {SASL} need not
encode the password either, just tell SASL where to find auth info.

================

The draft can RECOMMEND that clients avoid needing to know anything
about password formats by using the Password Modify operation (RFC
3062) when feasible.

Provided the server will then hash the password if it is stored in
userPassword, anyway.  Which it hopefully will.  But RFC 3062 says
nothing about hashing in that case.  Should it be updated to do so?

Use cases at our site for generating {scheme}hash:
- Importing user info including userPassword from the SQL user
  database - which does not keep the cleartext passwords.
- Multiple passwords in one entry, typically during the transition
  when changing the password for an LDAP service DN.

MUST userPassword in an object class may be broken, but RFC 1274
defines simpleSecurityObject (AUXILIARY MUST userPassword) anyway.
For use with classes like 'account' which lack userPassword.  Might
be about time to define simpleSecurityObject2 using 'MAY' instead.

-- 
Hallvard