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

[Michael Ströder <[e-mail]>]

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.

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.

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.

> 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

    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.