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

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 18 Feb 2000 11:02:24 -0800

At 10:16 AM 2/18/00 -0700, Jim Sermersheim wrote:
>>The intent is that an authentication process which uses X, Y, and
>>Z schemes should use all values of scheme X, Y, and Z.
>
>So let's say a client performs a simple authentication and sends a clear text password to the server. Are you saying that if the server's authentication process uses X, Y, and Z schemes, it should hash the password with X, then challenge the result against all values of the X scheme, then apply this same process to the password using Y, and Z?

Yes.

>If so, what has to match for authentication to happen? I could imagine: 1) all values must match, 2) one value of each scheme has to match, 3) one value of any scheme has to match.

3.

>>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.
>
>Bummer. This opens up security holes and makes the application of password policy difficult and bulky. I know userPassword allows multiple values, but I've never understood why. I'd like to understand what the reasons are before following the pattern.

I believe the use or not of multiple passwords for one identity
is a matter of policy not storage.  The storage should allow
for either policy to be implemented.  It's my intent for this
draft to be policy neutral.

>>>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).
>
>Then I think the draft needs something in the implementation section that talks about this. It should reflect the notion that if a client changes one value of the authPassword attribute, and not all values, it will likely screw things up--depending on the server implementation.

I'll have to chew on this a bit.  I will, however, try to
make a note stating the clients interacting directly with this
attribute should aware of how servers make use of the attribute
and that this may be policy driven.

>In other words, with this draft, I see an opportunity to make the use of passwords more interoperable. I would like to see a good deal of implementation details in the draft that move us toward that end.

The intent of the authpassword draft is to provide a
storage mechanism to promote interoperbility
between servers and management clients.  The storage
is designed to be independent of use (and policy).

The intent of the passwd-exop draft is to provide a
update mechanism to promote interoperability between
user clients and servers.  This update may be policy
driven.  The mechanism is designed to independent of
storage.

>>>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).
>
>Can you provide a reference to the passwd-exop draft in this draft?

I'll provide a reference to the passwd-exop draft in a manner
which does not depend this specification upon passwd-exop
(again, passwd-exop is only one of many possible mechanisms).
[In the end, I hope we can pick one update mechanism.  I'm
hoping to implement a couple of alternatives to gain
operational experience with each].

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 18 Feb 2000 20:07:06 -0800

>draft to be policy neutral.

Note that enforcement of password change policy often
requires knowledge of the current and new passwords.  As
updates via normal LDAP operations upon authPassword use
hashed values, it is not possible for the server to
enforce any content based password change policy.

Servers which support such policies will need to disable
update via normal LDAP commands and provide separate
update mechanisms which provide the necessary content
(the user's current and/or new password).  passwd-exop
provides such a mechanism.

I add a comment regarding this to the draft.

Kurt