Subject: [ldapext] Re: draft-behera-ldap-password-policy-07.txt

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 16 Mar 2004 01:01:15 -0700

True. For replication purposes, we picked timestamp over integer
counters.
 
I suggest we use change sequence numbers
(http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-csn-00.txt)
instead of timestamps for these.
 
I also noticed that the quoted change below was made to Section 6.1
(bind), but not Section 6.4 (compare), I hope to consolidate these
nearly identical sections soon.
 
Jim

>>> "Howard Chu" <[email-masked]> 3/15/04 6:06:27 PM >>>
> -----Original Message-----
> >Section 4.3.3, 6.1.1
> >A 0 value for generalizedTime is mentioned. This is
> >impossible as 0 is not a valid value.
> >We use 0000010100Z.

> Nice catch. We use 000001010000Z which is another
> representation of the same value.
> I'll change the wording to specific the generalizedTime 1st
> of Jan 0000, 00h00mn and give a representation of the value.

While testing our implementation for OpenLDAP I tripped over a minor
problem - if multiple Bind requests for a user are made in rapid
succession,
there may not be fine enough resolution in the timestamps to
distinguish each
attempt. So, the pwdFailureTime (for failures) or pwdGraceUseTime (for
expired password) attributes will not have an accurate count because
the
server refuses to store duplicate values in an attribute.

It seems that, audit aspects aside, these attributes would be more
useful as
single-valued integer counters instead of a list of timestamps.

-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc 
Symas: Premier OpenSource Development and Support

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

---

From: Ludovic Poitou <[email-masked]>
Date: Tue, 16 Mar 2004 11:58:32 +0100

Using single valued integers is very problematic as there is no 
increment operation (and reset operation), and thus it doesn't work well 
with replication.
We have several customers that want to have a strict measure of the 
failed attempts on a distributed directory.

I am fine with the use of Change Sequence Numbers (or something similar 
may be shorter, as GSER really produces big string representations). It 
may require some specifications on what is a ReplicaID in the case of 
standalone server.

Ludovic.

Jim Sermersheim wrote:

> True. For replication purposes, we picked timestamp over integer counters.
>  
> (http://www.ietf.org/internet-drafts/draft-sermersheim-ldap-csn-00.txt) instead 
> of timestamps for these.
>  
> expired password) attributes will not have an accurate count because the
> _http://www.symas.com <http://www.symas.com/>_ 
> _http://highlandsun.com/hyc_
> [email-masked] <mailto:[email-masked]>_
> _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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 16 Mar 2004 07:28:59 -0800

At 02:58 AM 3/16/2004, Ludovic Poitou wrote:
>Using single valued integers is very problematic as there is no increment operation (and reset operation), and thus it doesn't work well with replication.

Replicating values due to non-user modifications is also
problematic.  It seems to me that an attacker could abuse
distributed directories supporting such?  Also, if this
is a master-provided attribute, it seems you need a
mechanism for shadow servers communicate to the master
that a bind has failed?  Also, doesn't this mean you can
attack all the shadows at will until the master communicates
that the account is locked?

I also note that giving notice that an 'account' is 'locked'
is helpful to an attacker.  Let's them know they need to
move onto another account for a while, or can be used by
the attacker to lock out a particular user, or to DoS
the directory administrator with support calls from locked
out users.

I think we need to consider alternatives to locking the
account to hinder dictionary/exhaustive attack upon user's
password.

Kurt

---

From: Ludovic Poitou <[email-masked]>
Date: Tue, 16 Mar 2004 17:17:28 +0100

Kurt D. Zeilenga wrote:

>distributed directories supporting such? 
>
Correct.

> Also, if this
>that a bind has failed?
Correct.

>  Also, doesn't this mean you can
That is an implementation issue (one can apply the change locally and 
communicate it to the Master).

>the directory administrator with support calls from locked

I agree... Implementation should be free to return or not the control 
giving notice that the 'account' is 'locked'

>account to hinder dictionary/exhaustive attack upon user's
What is the current state of the art with regards to dictionary attack 
protection ? Except keeping answering invalid credentials without 
actually doing anything, I don't have ideas...

Ludovic.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 16 Mar 2004 10:11:24 -0800

At 08:17 AM 3/16/2004, Ludovic Poitou wrote:
>What is the current state of the art with regards to dictionary attack protection ? Except keeping answering invalid credentials without actually doing anything, I don't have ideas... 

I think the current state of concern is that one has to be
very careful in defending dictionary attacks upon the users'
credentials as often the defensive measures open the service
to higher risk attacks, such as DoS attacks, or actually aid
dictionary attackers.

In regards to the latter, it seems this proposal seems to
focus in on attacks to a particular known user's password.
The proposal seems to give away information that would be
useful in attacks on sets of users (including the set of
users previously unknown to the attacker).  In particular,
the proposal aides the attacker in determine which of the
possible users are valid.  Also, the proposal seems to
assume the attack will have an inner loop which varies
the password.  If the inner loop actually varied the
user name, the proposal may be ineffective.

In regards to the former, the mechanism is clearly open to
DoS abuses upon individual users, the service at a particular
server, the (distributed) service in general, and support
centers.  Not only is the mechanism is kind enough to lock
out accounts for the attacker, it kind enough to deal her
when they are locked out (so the attacker can move on to
locking another account).

Anways, I think it would wiser for servers to just return
invalidCredentials when the credentials are invalid (and have
credentials which have significant entropy), possibly
with an exponential delay to slow retries (and a policy that
no one connection can have multiple bind requests outstanding).
However, even insertion of delays can be used by attackers
in denying service.

I think the state of the art lies in Intrusion Detection
Systems.  That is, systems which take information about
events, automagically analyze these for possible intrusion
attempts, and then take immediate action (notify admin, advise
service take some defensive action, etc.) based upon local policy
information, and provide tools for subsequent investigation
and actions.

Of course, the state of art in DoS is to attack IDS systems.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 16 Mar 2004 10:38:46 -0800

At 08:17 AM 3/16/2004, Ludovic Poitou wrote:
>That is an implementation issue (one can apply the change locally and communicate it to the Master). 

Doesn't this go against your' user's desire to have a strict
lock out on N retries policy across the service?   I mean, if
implementations are free to local retries counts, than cannot
those be abused to get retries than the policy allowed?

Ignoring DoS attacks in this area, is there a scaling problem
here?

We have deployments involving large numbers of replicas
where maintain policy state information on a context
wide basis would be prohibitively expensive.

It seems to me that it would be better to define any state
information to be DSA-specific, but with a comment saying
that DSAs may agree to share state information but that
the how to that sharing could be performed is beyond the
scope of this document.

Kurt

---

From: "Howard Chu" <[email-masked]>
Date: Tue, 16 Mar 2004 10:59:17 -0800

> From: Kurt D. Zeilenga [mailto:[email-masked]]

> >That is an implementation issue (one can apply the change
> locally and communicate it to the Master).
>

Another similar case is for a pool of servers behind a DNS round-robin scheme
or a load balancer...

> wide basis would be prohibitively expensive.

There's definitely the potential here for Bind requests on a single server to
tie up resources on all cooperating servers as the policy attributes get
replicated around. In a single-master case it would make more sense for the
read-only replicas to chain the Binds to the master rather than process them
locally, and keep the policy attributes only on the master.

> the how to that sharing could be performed is beyond the

As a sanity check it would be good to have a "Replication/Distribution
Considerations" section (somewhat like the current section 9) that was
Informative (not normative) highlighting some of the pros and cons of various
approaches. It always bugs me to see a document punt with "there are problems
here" without listing the problems...

  -- Howard Chu

---

From: Ludovic Poitou <[email-masked]>
Date: Tue, 16 Mar 2004 20:41:41 +0100

>locally, and keep the policy attributes only on the master.
I agree that it may be very resource consuming, but it mainly depend on 
the rate of authentication request.
However, I think that this is a deployement choice.  We don't want to 
mandate the failure attempts to be replication, but we don't want to 
prevent it either.
The Sun Directory Server password policy currently uses single valued 
integer for the failure count and we are seeing major issues in some 
deployements, and numerous customers requesting a single lockout counter 
(although this is beyond dictionary attack protection).

>here" without listing the problems...

I agree. Will think of how to change section 9.

Ludovic

---

From: Mark Ennis <[email-masked]>
Date: Wed, 17 Mar 2004 11:07:46 +1100

I'd discourage the use of change sequence numbers as they add extraneous 
information, specifically replicaID and changeCount, which is not 
relevant to the problem being addressed.

- Mark.