[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 2/17/00 10:30:01 PM >>>
>>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.

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

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

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

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.

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

Jim