Re: I-D ACTION:draft-zeilenga-ldap-authpasswd-00.txt

[Ludovic Poitou <ludovic.poitou@france.Sun.COM>]

Mark C Smith wrote:

> Internet-Drafts@ietf.org wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> >         Title           : LDAP Authentication Password Attribute
> >         Author(s)       : K. Zeilenga
> >         Filename        : draft-zeilenga-ldap-authpasswd-00.txt
> >         Pages           : 7
> >         Date            : 21-Dec-99
> >
> > This document describes schema for storing authentication passwords in
> > a LDAP [RFC2251] directory.  The document provides schema definitions
> > for authPassword and related schema definitions.  The authPassword is
> > meant to used instead of clear text password storage mechanisms such
> > as userPassword [RFC2256].  The attribute may be used to store SASL
> > [RFC2222] authentication passwords in entries of a directory.
>
> Kurt, I am glad you took the initiative to produce this document.  I
> would note that IMHO the extended use of userPassword that was pioneered
> by Netscape and others was a good thing because it allowed off the shelf
> LDAP client applications -- even ones that set passwords -- to work in
> the face of one-way hashed password values.  But formalizing this is a
> good idea.
>
> Some comments on your draft:
>
> 1) I would be more careful about the use of the term "encryption."  A
> one-way hash is not encryption in my view.  Do you intend to support
> encrypted, reversible storage schemes as well?  I see no reason not to,
> although obviously there may be key distribution issues and so on for a
> given scheme.
>
> 2) Why did you not include a crypt scheme?
>
> 3) For transition purposes (for those who have deployed with one-way
> hashed userPassword values), it would be nice to use the same format
> with the new authPassword, i.e., {SCHEME}HASHED-VALUED

Yes. And it would be nice to use the same identifiers (SHA instead of SHA1).


>
>
> 3) The heading for section 4.3 is "supportedAuthSchemes" but the text
> defines an attribute type called supportedAuthPasswordSchemes.
>
> 4) In section 4.5 you define an authPasswordObject auxiliary class which
> includes authPassword as a required attribute.  I feel strongly that the
> attribute should be optional as this simplifies client and server
> interactions when adding or deleting authPassword values.
>
> 5) Why is MD5 a MUST and SHA1 a SHOULD for servers that support LDAP
> simple bind?
>
> 6) In the security considerations, we should describe in more detail how
> servers and clients should protect these values.  For example, for
> auditing purposes and to enforce password policies, it is common to
> disallow compare operations and required that all password tests come
> through bind operations.
>
> 7) I assume if more than one authPassword value is present, a password
> presented by a client is tried against all of the values.  This should
> be clarified.

Would it be possible to have the same password hashed with different schemes ?
If so, how to deal with passwords modifications and deletion should be clarified.

Ludovic.

>
>
> --
> Mark Smith
> iPlanet Directory Architect / Sun-Netscape Alliance
> My words are my own, not my employer's.   Got LDAP?

--
Ludovic Poitou
Sun Microsystems Inc.
Sun-Netscape Alliance - Directory Group - Grenoble - France