Re: [ldapext] Fwd: I-D ACTION:draft-behera-ldap-password-policy-08.txt

[Neil Dunbar <neil.dunbar@hp.com>]

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