Re: Comments on draft-zeilenga-ldap-authpasswd-01.txt

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

At 06:43 PM 2/17/00 -0700, Jim Sermersheim wrote:
>First a minor consistency issue:
>Section 3 says "The attribute may be used by LDAP servers to implement simple bind and  SASL ..."
>Section 7 says "This document describes how authentication information to support simple password authentication ...

The intent is to allow the attribute to be used to support password
based authentication, whether simple bind, SASL, or whatever.
I'll attempt to clarify in next draft.

>
>Then I've got some questions regarding implementation details.
>
>The wording of the first sentence of Section 6 is a bit confusing: "Servers MAY restrict schemes used to support a particular authentication process but SHOULD use all values of those schemes."  What does "use all values of those schemes" mean?  I'm guessing that it should read "use all values of those schemes which are supported", but I'm not sure. It would also help to qualify the word use.

The intent is that an authentication process which uses X, Y, and
Z schemes should use all values of scheme X, Y, and Z.

I'll try to clarify this as well.

>The authPassword attribute is defined as multi-valued. Then there is an indication of what makes up the set of values: "The values of this abbribute[SIC] are derived from the user's password per the indicated scheme".
The implication (based on the singularity of the word password) is that though this attribute may hold many values, each value is a different representation (different hash) of a _single_ password. If this is the case, I'm reading a lot into the draft that isn't there yet. If it's not the case, and the intent is that this attribute can hold an arbitrary number of different passwords, there are security holes that need to be talked about in the Security Considerations section.

I intended was the later, user's password(s), I'll add some
clarification and a security consideration.  It's my intent
is that this attribute be used instead of userPassword,
userPassword allows multiple values.

>How is the attribute populated? It's a user attribute which leads me to believe that the client is responsible to populate/update it.

Yes.  The attribute type implies no special behavior.  It's
my intention that mechanisms would be introduced (in other
drafts) to provide additional behavior.

>If so, the client would (should) have to populate/re-populate each value in the attribute, right?

Yes... or use a separated defined mechanism.   Note, it is
intended that password change be initiated by a client
acting on behalf of the user (or the directory admin).

>It seems like this could be achieved in a much more secure
and consistent way if there was a server side mechanism for creating and updating values of this attribute.

I personally favor use of an extended operation to provide
clients with consistent behavior irregardless of the
storage used for passwords.  I've introduced such in
my passwd-exop draft, it may be used with userPassword,
authPassword, and/or external password storage.  Security,
of course, is based on a number of factors.  I generally
recommend the clear separation of private/secret and public
data.  I prefer (when using password based authentication)
external password storage like that provided by independent
SASL service providors).