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

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? 
Hashed userPassword values are strictly a server-internal implementation 
detail, clients never need to know about them.

The syntax specification is defective in at least 2 ways:
   1) it only allows a form "hashandsalt" which actually precludes any 
unsalted hash mechanisms.
   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.

> What platform-specific variants do you know of?
> The really important one is the old Unix-crypt 13-char salted hash.
>
> Could you perhaps say something like:
>
> {crypt} introduces a password-hash string that is generated and
> checked by the crypt(3) library. This could be the traditional
> 13-character 'Unix crypt' or some other variant such as the stronger
> '$1$' and $6$' schemes used by recent versions of Linux.
>
> Andrew
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/