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

From: "Howard Chu" <[email-masked]>
Date: Thu, 4 Mar 2004 09:38:34 -0800

> Date: Thu, 04 Mar 2004 08:12:26 +0100
> From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[email-masked]>

> Howard Chu wrote:
> >
> > From a purist's security perspective, I'd agree that
> invalidCredentials is
> > the correct response. One of the maxims in security is to
> provide the minimal
> > amount of information to an attacker. Thus, one is advised
> to avoid giving
> > responses that differentiate between "account does not
> exist" / "password is
> > incorrect" / "account locked due to too many failed
> attempts" ... Following
> > this argument, I wouldn't even provide any special
> information in the
> > passwordPolicyResponse control.
>
> This would make a password policy a 1st-level support
> nightmare.

Making it optional as I suggested is harmless; your site can enable this
result if you feel the need. Making it mandatory is harmful; I have worked on
a number of US government projects where computer systems are expressly
forbidden from revealing this kind of status. I think your objection is a
moot point if the feature is optional.

> And it's
> security by obscurity which does not really work against
> serious attacks anyway.

No, this is not the same as "security by obscurity." A better illustration
would be to compare it to a silent alarm system in the real world. When the
intruder doesn't know that his intrusion has been detected, he remains on the
scene, giving time for authorities to arrive and catch him in the act. An
attacker that doesn't know the account has been locked is likely to continue
probing it with Bind attempts. If they know for certain it has been disabled,
they will move on. There is real value in not letting the attacker know that
the attack has been detected, because it gives a greater opportunity to trace
the attack.

Not all LDAP servers need to be user-friendly; the protocol should allow for
other possibilities.

  -- 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: "Howard Chu" <[email-masked]>
Date: Thu, 4 Mar 2004 10:01:06 -0800

In general I see the LDAP unwillingToPerform result code used to mean
*unable* to perform - i.e., the requested operation is unimplemented and the
target server can *never* satisfy a request. Of course the LDAP spec doesn't
define it this way, but that appears to me to be the most common usage. (Am I
missing the point somewhere?)

I am uncomfortable with its use in this draft for errors which are unrelated
to the actual capabilities implemented by the server. E.g., 6.2.3 should just
return insufficientAccessRights. Is my concern unnecessary?

  -- Howard Chu

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 05 Mar 2004 10:27:31 +0900

I haven't look at the particular usage, but I think that
specifically calling for the return of unwillingToPerform
is not a good idea.  It, like a number of general result
codes, should be left to the implementor to decide between
(other, busy, ...).  Or, to put it another way, specifications
should not attach narrow semantics to a general purpose
result code.  If something needs to be called out specifically,
it likely better to use a new code.

Kurt