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

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 15 Feb 2000 18:14:13 -0800

At 04:28 PM 2/15/00 -0800, Bob Joslin wrote:
>I noticed you omitted the reply on the suggestion for changing the name of
>the attribute to hashPassword?  I assume you disagree with the suggestion?

I overlooked this suggestion.  See my comments below.

>4.1. authPasswordSyntax
>
>    ( authPasswordSyntaxOID
>      DESC 'authentication password syntax' )
>
>  Values of this syntax are encoded according to the following BNF:
>
>    authPasswordValue = scheme "$" [ info ] "$" hashedValue
>    scheme = <an IA5 string of letters, numbers, and "-", "_", and "/">
>    info = <a base64 encoded value>
>    hashedValue = <a base64 encoded value>
>
>  where scheme describes the hash mechanism, info is a scheme specific,
>  and hashedValue is the hashed value.  The info field is often a salt.
>
>If the authPasswordSyntax requires a hashedValue, why not change the name
>of the attribute to "hashPassword" instead of "authPassword?"

I intended to reword the section to not use the term "hash" but
to say the value stored a scheme specific.  The intent is for
this attribute to be capable of support a wide variety of
storage schemes used to support authentication via user passwords.

>I would think "hashPassword" would be a more descriptive name.

The primary usage of the attribute type is to support password
authentication mechanisms, hence the name "authPassword."

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 18 Feb 2000 10:16:30 -0700

>>> "Kurt D. Zeilenga" <[email-masked]> 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