Re: comments on draft-behera-ldap-password-policy-02.txt

[Ludovic Poitou <ludovic.poitou@france.Sun.COM>]

hahnt@us.ibm.com wrote:

> Greetings,
>
> I have a few comments on the I-D:
>
> Section 2.1, second paragraph: "password for a directory administrator
> never expires, the account is never locked, etc."
> I think that if a particular implementation wants to allow this, then it
> can choose to do so.  I do not think it should be singled out as part of
> the specification.  In a secure environment, the directory administrator(s)
> should be held to strict requirements like everyone else.  All efforts
> should be made to disallow a "single, allow-allowing identity" from
> existing.

I agree and will change the wording.
But I think that at least the Directory Manager (or root if you prefer) should
not have a password policy that could lock him outside the directory.


>
> Section 4.2.5, first paragraph: "otherwise the server must returned an
> error" - returned should be return.

>
> Also, case "1" and case "2" look to me to be identical.

They're not, when the new password is hashed. Case "1" will succeed (trust the
client for having checked the syntax before submitting a new hashed password),
case "2" will fail (refuse a hashed password since syntax cannot be checked).

>
> Also, it would be nice if the "pwCheckSyntax" identified the password
> attriubutes that it applied to by name.

I don't understand this remark. The whole policy definition apply to the same
password attribute.

>
>
> Section 4.2.13, second paragraph: "If this attribute is not preset, ... the
> failure counter will never be purged."
> I expected that the failure counter would always be purged after a
> successful authentication?

I agree this is not clear. What about :
"This attribute holds the number of seconds after which the password failures
are purged from the failure counter even though no successful authentication
occured.
If this attribute is not present,... the failure counter is only reset by a
succesfull authentication."

> How does one indicate that password failures
> should not be counted?

The pwdMaxFailure is used to indicate that password failures should not be
counted (not present or value set to 0).

>
>
> Section 4.3:
> Is there any alternative to this use of attribute descriptions/options?
> Many implementations don't have full support for attribute
> descriptions/options yet.

The alternative would be to specify the password attribute name in each value.
Something like "pwdChangedTime: {userPassword}20000103121520Z"
I don't really like this because it cost more to search for the correct value.
Especially for the attributes that can hold several timestamps.


>
>
> Section 4.3.3, first paragraph: "The password must expire in the ...",
> should "must" be "will"?

Yes, corrected.

>
>
> Section 4.3.4, first paragraph: "time stamps" should be "timestamps"
>

Thanks.

>
> Section 6.4, step 2, part B "checks for password expiration".
> Will compareTrue still be returned after expiration?  This was not clear.

I don't think so.
If compare is used for authentication purpose, the result should only be
compareTrue or compareFalse, and the appropriate control set.
I need to discuss this with the other authors of this document.


>

>
> Also, "bindResponse" should be changed to "compareResponse" throughout this
> section of the text (all the way to the start of Section 7).
>

Done.

>
> Section 7.1, first paragraph:
> "For every bind response received" should be "for every bind response or
> compare response received", and likewise throughout the rest of the
> section, compare response should be factored in.

I'd rather add a compare section since compare should return compareTrue or
compareFalse, or an error.

>
>
> Section 8:
> As an alternative, why not apply the auxiliary class to an entry in the
> tree and define its "scope" to be the subtree below that entry (until
> another policy is encountered, or the subtree leaves the server instance).

That's a possibility.
I think that because the password policy definition is more of an
administrative entry than a "user" entry, it should not be returned during
regular searches. Subentry allows that without having to set specific ACIs.

>
> Also, "When the server need to find the" , "need" should be "needs"
>

Corrected.

>
> Section 9, last paragraph:
> I interpreted this paragraph to mean that the operational attributes should
> be modified/tracked by each replica itself, not replicated/kept in sync
> across the replicas.  If that is so, I'm not sure that this should be
> specified here - some implementations might find a way to keep them in sync
> to cut down on the total number of possible attempts (counting all replicas
> of the information).

I think the "should" express a recommandation not an obligation. But I agree
some implementation (or some deployement) might find usefull to keep all
attributes in sync.


>
>
> Section 10, last paragraph:
> It would be nice to see an expanded discussion of auditing.  Might this be
> the topic of a new I-D?
>

Good point, need to think about this...

Thanks for reviewing the draft.

Ludovic.

>
> Regards,
> Tim Hahn
>
> Internet: hahnt@us.ibm.com
> Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
> phone: 607.752.6388     tie-line: 8/852.6388
> fax: 607.752.3681

--
Ludovic Poitou
Sun Microsystems Inc.
iPlanet E-Commerce Solutions - Directory Group - Grenoble - France