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

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 25 Oct 2004 16:54:23 -0600

This update addresses some but not all concerns received to date. I have
68 remaining mails left to get through.
 
Jim

>>> <[email-masked]> 10/25/04 1:58:46 PM >>>
A New Internet-Draft is available from the on-line Internet-Drafts
directories.

Title: Password Policy for LDAP Directories
Author(s): P. Behera, et al.
Filename: draft-behera-ldap-password-policy-08.txt
Pages: 38
Date: 2004-10-25

Password policy as described in this document is a set of rules that
controls how passwords are used and administered in LDAP
directories. In order to improve the security of LDAP directories
and make it difficult for password cracking programs to break into
directories, it is desirable to enforce a set of rules on password
usage. These rules are made to ensure that users change their
passwords periodically, passwords meet construction requirements,
the re-use of old password is restricted, and users are locked out
after a certain number of failed attempts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce

to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-behera-ldap-password-policy-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 

Internet-Drafts can also be obtained by e-mail.

Send a message to:
[email-masked] .
In the body type:
"FILE /internet-drafts/draft-behera-ldap-password-policy-08.txt".

NOTE:The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

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

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

---

From: Ludovic Poitou <[email-masked]>
Date: Tue, 26 Oct 2004 14:54:15 +0200

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.

-- 
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 14:17:42 +0100

> machine and you're out of this machine"

I see what you're saying - but what you're then doing is placing the
semantics of an Information Security policy into the hands of the LDAP
operations/design teams. I'm not sure too many InfoSec people would like
that notion. In other words, if the LDAP ops team deploy another 20
servers, they're not going to ask their security teams to validate that
installation - they're just going to do it. But that would have the
effect of adding a boatload of extra guessing capability into the
password protection mechanisms. If the rest of the passwords constraints
aren't up to that, then you might well be compromising baseline
security.

I suppose you could always redirect binds from read-only replicas
towards a writeable replica. That way you're guaranteed to maintain
consistency across the domain. Similarly, I suppose you could use
network segmentation to restrict the LDAP servers that you can bind to
from a particular part of the network.

I still think the draft should comment on the issues arising from
replication, since it's far from obvious what needs to be done in all
cases.

Cheers,

Neil