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

[mcs@netscape.com (Mark C Smith)]

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

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.

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