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

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 26 Oct 2004 08:52:25 -0600

>>> Neil Dunbar <[email-masked]> 10/26/04 3:48:12 AM >>>
>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.

And one other place. I just fixed it in 09
 
Leaving the replication thing for another reply...

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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 26 Oct 2004 08:55:10 -0600

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 <[email-masked]> 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.

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
>
>

-- 
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Neil Dunbar <[email-masked]>
Date: Tue, 26 Oct 2004 16:48:52 +0100

> solutions, and leaves the password policy draft out of the business of

Yup. On consideration, you're right. Protocol descriptions aren't where
security architecture discussions belong. Forget the changed text - it
seems to me that you could have a thoroughly replicated policy and still
fit within the considerations given.

Cheers,

Neil