|
I agree. In fact, I think the draft needs to describe the "Replication Considerations", but not prescribe behavior.
This leaves room for vendors and deployers to provide competitive solutions, and leaves the password policy draft out of the business of replication policies.
Jim
>>> Ludovic Poitou <ludovic.poitou@Sun.COM> 10/26/04 6:54:15 AM >>> I believe that replication of these attributes should be a choice left to the administrator of the service and not mandated by the LDAP password policy specification. There are cases where replicating these attributes has a cost higher than the benefits. When the Directory Servers are behind a load balancer, applications need a consistent view. But when the service is geographically distributed and the authentications are mainly local to one server (with a possible failover), then keeping the attributes per server is really acceptable. The policy could be understood as "5 consecutive failed attempts on a machine and you're out of this machine" The goal of the policy is too limit the possibilities of a dictionary attack against a simple string based password, and should be balanced against a possible denial of service if all accounts are locked on all servers because someone is trying to authenticate with a known bad password. Ludovic. Neil Dunbar wrote: >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 > > -- Ludovic Poitou Directory Architect. Directory Server Group, Grenoble, France Sun Microsystems Inc. Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext |
_______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext