[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Fwd: I-D ACTION:draft-behera-ldap-password-policy-08.txt
On Mon, 2004-10-25 at 16:54 -0600, Jim Sermersheim wrote:
> This update addresses some but not all concerns received to date. I
> have 68 remaining mails left to get through.
Couple of things:
pwdExpirationWarned is now undefined, but is still referenced in section
8.2.7 and section 11.
Section 11:
The pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime
and pwdGraceUseTime attributes MUST be replicated to writable
replicas, making the password policy global for all servers.
When the user entry is replicated to a read-only replica, these
attributes SHOULD NOT be replicated.
I'm not sure that this is a tenable position. I understand the
difficulties (in effect, we're talking about making every server an LDAP
master for just these operational attributes), but this seems to
severely weaken the strength of the password policy. If a security
officer approves a policy which states "5 guesses then you're out", I
don't think he'll be thinking "Ah, but since there are 30 servers,
that's really 150 guesses and you're out".
I'm not sure how to express it properly, but I think I'd prefer
something along the lines of
A change to pwdFailureTime, pwdAccountLockedTime or
pwdGraceUseTime occuring as the side-effect of a bind or compare
operation SHOULD be propagated to a writeable server at the
earliest opportunity after the local state has been updated. The
pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime
attributes MUST be replicated to all replicas. If the
replication update would produce no change to the state of the
target entry, then the update MAY be ignored. Changes to
pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime which
occur as part of a downstream replication MUST NOT be propagated
to a writeable server.
I think you need local state update, before you notify any master server
of the change. To fail to do so would introduce a security flaw if you
could DoS the update service (ie, the password would never get locked
since the update to lock it would never happen). With the mechanism
above I think you can say that *in the worst case* you'd end up with an
NxM password guessing field. Whereas in the existing setup, the best
case is also the same as the worst case.
Cheers,
Neil
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext