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

[hahnt@us.ibm.com]

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