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

From: [email-masked]
Date: Mon, 7 Aug 2000 11:09:47 -0400

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.

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.
Also, it would be nice if the "pwCheckSyntax" identified the password
attriubutes that it applied to by name.

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?  How does one indicate that password failures
should not be counted?

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.

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

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

Section 6.4, step 2, part B "checks for password expiration".
Will compareTrue still be returned after expiration?  This was not clear.
Also, "bindResponse" should be changed to "compareResponse" throughout this
section of the text (all the way to the start of Section 7).

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.

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).
Also, "When the server need to find the" , "need" should be "needs"

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

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?

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

---

From: Ludovic Poitou <[email-masked]>
Date: Tue, 22 Aug 2000 14:28:30 +0200

> should be made to disallow a "single, allow-allowing identity" from

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.

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

> attriubutes that it applied to by name.

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

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

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

Yes, corrected.

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

Thanks.

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

> section of the text (all the way to the start of Section 7).

Done.

> section, compare response should be factored in.

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

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

> to cut down on the total number of possible attempts (counting all replicas

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.

> It would be nice to see an expanded discussion of auditing.  Might this be

Good point, need to think about this...

Thanks for reviewing the draft.

Ludovic.

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