Subject: [ldapext] concerns re: draft-behera-ldap-password-policy-07.txt

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 20 Mar 2004 11:43:48 -0800

I just finished a quick read of this proposal, and have
a number of concerns.

I think this premise put forth by this document that retry
lockouts mechanism will significantly mitigate against
dictionary attacks is somewhat flawed.  This lockout is
particularly weak in defending dictionary attacks (and
prone to DoS attack) as it is based solely on a per-user
retry count.  Such counters target the user, and not
necessarily the attacker.  An attacker can easily avoid
such a retry (regardless of whether notice is given or not)
and, if notice is given, the notice can clearly benefit the
attacker.  It's my belief that such lockouts are more likely
to be used in mounting a denial of service attack (upon
the user, the directory service (including replication),
upon the support staff/infrastructure) then they will ever
be used to effectively stop/slow dictionary attacks.

I think it better for any authentication failure to result
in a constant message (same code, diag text, etc.) regardless
of the reason for failure.  And, as attackers may be able
to discern the nature of failure by how much time it takes
for the server to respond, to take the same amount of time
(by delaying response for fast failures) in responding to
failed authentication attempts.  Also, inserting delay
in to hinder dictionary attacks could also be useful.
However, I note, inserting any delay implies the server has
to maintain the connections/operations for longer periods
of time, and that, in itself, could open the server to an
DoS attack.

I am also concerned by this I-D use of controls attached
to bind requests and responses.  These controls are only
usable (in a secure fashion) when adequate data security
services are in place.  Aside from this meaning that
implementations supporting these controls MUST be capable
of protecting them with TLS (though deployers can protect
them by other means if they choose), this means that
implementations MUST be capable of using TLS with DIGEST-MD5.
That's problematic requirement as it leads to multiple
security layers.  Aside from being redundant in some cases,
supporting multiple security layers can be quite difficult.

Now the argument I suspect will be voiced is that this
policy mechanism is more intended for use with simple bind's
password mechanism.  But given that DIGEST-MD5 is LDAP's
mandatory-to-implement mechanism, I think it appropriate for
any standard track LDAP password policy mechanism should be
specially designed with it in mind.

I also noticed that the document doesn't distinguish between
the "directory (server) administrator", the "(password)
policy administrator", and the "password administrator".  The
document says that anyone who can administrate passwords is
considered a directory administrator.  While a directory
administrator can generally administrate passwords, it is
follow that everyone who can administrate passwords is a
directory administrator.  (For instance, my manager can reset
my directory password, but he's not the directory administrator.)

And I think the security considerations section needs to be
flushed out more.  For instance, it doesn't discuss that
these controls may expose additional information, some of
which might be useful to an attacker.  Also, it seems an
attacker could have lots of fun adding, deleting, and
modifying these controls.

Kurt 

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext