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

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

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