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

[Ludovic Poitou <ludovic.poitou@Sun.COM>]

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