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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.Org>]

At 10:01 AM 12/23/99 -0500, Mark C Smith wrote:
>Some comments on your draft:

Much appreciated!

>1) I would be more careful about the use of the term "encryption."

I concur.

>A one-way hash is not encryption in my view.

I will reword section 4.4.

>Do you intend to support encrypted, reversible storage schemes as well?

authPassword is intended to be used with non-reversible storage
schemes AND to be flexible.

>2) Why did you not include a crypt scheme?

Two reasons:
 1) traditional crypt(3) (DES based) passwords are easily attacked
 2) enhanced crypt(3) (? based) passwords are platform specific

The only rational in favor of including them was to support migration
from UNIX based authentication to LDAP based authentication systems.
I would much rather see migrate_unix.pl take the particular pw_passwd
encoding used on a give box and map this into appropriate authPassword
schemes (then to support platform specific schemes).

For those directory managers who want tight integration, a number
of vendors are offering ties to existing external password stores.
For example, OpenLDAP 1.x support "{UNIX}kdz" (the server fetches
the kdz entry from /etc/password (or replacement) and use that
value for the comparison.   We intend to define an authPassword
scheme to support continued use of such external password stores.
I hope that this can be done is a generally useful way (non-platform
specific).

>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

I definitely did consider just reusing the {SCHEME}HASHED-VALUED
syntax offered by RFC 2307.  I choose to use a different syntax
to resolve some nagging issues with the syntax.  In particular,
I wanted to add support:
	additional schema-specific information in a general way
	combine non-salted and salt variants ({MD5} vs {SMD5})

I weighted the expense of s/userPassword/authPassword/ change
against the expense of a new authPassword syntax.  I realized that
the expense was about the same, change is change.

On the other hand (for those who thing the change is significantly
more expensive), I would argue that we should not penalize those
vendors who did not abuse userPassword and desire to implement
authPassword by requiring some signficant change to all those who
want to support authPassword.

In addition, I plan on submitting additional drafts (or extend
this draft) such to support server side generation of hashed values
of new passwords without abusing "user" (non-operational) nature
of this attribute.

>3) The heading for section 4.3 is "supportedAuthSchemes" but the text
>defines an attribute type called supportedAuthPasswordSchemes.

Thanks.

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

I originally modeled authPasswordObject after simpleSecurityObject.
However, I later changed authPasswordObject to be a simple mix in class.
I concur that for this use that MAY would be more appropriate.

If specific objectclasses were needed to imply specific uses of
authPassword, these may be defined as well.

>5) Why is MD5 a MUST and SHA1 a SHOULD for servers that support LDAP
>simple bind?

I wanted to MUST one and only one scheme for use with simple bind.
I choose MD5 as it provided a reasonable level of protection from
brute force attack AND implementations are available which are
highly portable and in the public domain.  Though SHA1 offers
better protection against brute force attack, I could not find
a implementation which as both highly portable and in the public
domain.  (If you know of such, send me a URL).

>6) In the security considerations, we should describe in more detail how
>servers and clients should protect these values.

Servers and clients should protect these values as if they were
plain text passwords.  The "more details of how", I believe, is
implementation specific.

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

As with any attribute, authPassword is subject to access controls.

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

I specifically wanted to divorce password storage from password use.
A server may use a subset of the values to support a particular
authentication process.  A server may use values from multiple sources
to support an authentication process.