Additional comments: ldap password policy draft

["Kurt D. Zeilenga" <kurt@boolean.net>]

>   11. Password Guessing limit
>      During the bind operation, the server should check for password
>      guessing limit.  If password guessing limit policy is on and the
>      password guessing limit is reached, the server should send
>      bindResponse back to the client with resultCode:
>      LDAP_CONSTRAINT_VIOLATION, and an error message to indicate the
>      password failure limit is reached.

As I noted previously, constraintViolation is not an appropriate
resultCode to be provided in a bindResponse.  I suggest returning
invalidCredentials.  Rational: reaching the password guessing
limit can be viewed as temporarily invalidating the credentials.

>   12.2 Bind Operations
>   12.2.1 During bind operations
>
>      The server should check if the user account is locked or, if the
>      password guessing limit policy is on and the guessing limit is
>      reached. If so, the server should send bindResponse back to the
>      client with resultCode: LDAP_CONSTRAINT_VIOLATION, and an error
>      message to indicate the password failure limit is reached.

I suggest returning invalidCredentials.  Rational: reaching the
password failure limit can be viewed as temporarily invalidating
the credentials.

>   12.4.1.  During the modify password operation
>      1. Check if the user is allowed to change password. If not, the
>         server should send to the client the LDAP_UNWILLING_TO_PERFORM
>         result code and an error message to indicate that the user is
>         not allowed to change the password.

Seems like insufficientAccessRights would be more appropriate.
The policy is stating that this user does not have sufficient
rights to change password.

As noted by others, this capability may be better provided
by the access control features of the server.  I concur.

>   12.5 Compare Operation
>
>     The compare operation may be used to compare a userPassword. This
>     might be performed when a client wishes to verify that user's
>     supplied password is correct. An example of this is an LDAP PAM
>     redirector or an LDAP HTTP authentication redirector. It is
>     desirable to use this rather than performing a bind operation in
>     order to reduce possible overhead involved in performing a bind.

That overhead you are avoiding is implementation other policies.
By using compare, you disallow the server from applying such
policies.

>     If a server supports this behavior, it MUST comply with the
>     following. Otherwise the password policy described in this
>     document may be circumvention.

Redirectors can easily circumvented the policy.  And they will...
to improve performance.  A common approach is for the redirector
to cache information to avoid further directory operations.

I see no reason why the server MUST comply.  SHOULD should be sufficient.

>   15. Password Policy and Replication
>      If they?re not replicated, it means that the limits apply on each
>      server and therefore, a user can try to bind N times on each
>      server.

If they are replicated (single-master), the master will reset
counters on the slaves upon each replication.  An attacker
could use abuse this to obtain more than N attempts on each
server.



----
Kurt D. Zeilenga		<kurt@boolean.net>
Net Boolean Incorporated	<http://www.boolean.net/>