Subject: RE: [ldapext] draft-behera-ldap-password-policy - bind behavior w hen pwd must be changed

From: "Volpers, Helmut" <[email-masked]>
Date: Wed, 19 Nov 2003 16:32:09 +0100

Hi,

I agree with John. The draft should distinguish between clients which
provides the password policy request control and clients which don't support
this.

other comments inline.

> -----Original Message-----
> From: Dejan Muhamedagic [mailto:[email-masked]] 
> Sent: Wednesday, November 19, 2003 4:00 PM
> To: John McMeeking
> Cc: [email-masked]
> Subject: Re: [ldapext] draft-behera-ldap-password-policy - 
> bind behavior when pwd must be changed
> 
> 
> John,
> 
> On Wed, Nov 19, 2003 at 08:13:42AM -0600, John McMeeking wrote:
> > 
> [snip]
> >
> > What I feel is lacking in the draft is the distinction between a 
> > client that provides the password policy request control 
> and a client 
> > that does not.
> > - If no password policy control is present, a bind with a reset 
> > password should fail
> > - If a password policy is present, a bind with a reset 
> password should 
> > succeed with a reponse control returned as is currently 
> stated in the 
> > draft.
> 
> How can LDAP server tell if the client supports password 
> policy or not?  All it knows is that they want to bind.
> 
> I agree that the security policy should be enforced at the 
> server and not at the client, but in this case we have no 
> means to do that without "breaking" clients which don't know 
> how to read the policy.

the LDAPserver can publish the control in the ROOT by supported controls.
the Ldapclient should not read the Password policy.

Helmut

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

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

---

From: "Andrew Sciberras" <[email-masked]>
Date: Thu, 20 Nov 2003 09:22:53 +1100

Hi,

>From: [email-masked] [mailto:[email-masked]]On Behalf Of
Volpers, Helmut
>Sent: Thursday, 20 November 2003 2:32
>
>Hi,
>

Generally I agree with this point. I think it is sensible, as a security
precaution, to fail binds if the directory cannot be certain that the client
would understand the scope in which it is allowing the bind to proceed.
Compare operations should fail aswell.

In principal, I think that any client that cannot handle a password policy
response control should not be interacting with a password policy enabled
directory.
If the client is unable to interpret the contents of the control, they've
got a lot more than the changeAfterReset dilemma to worry about. Each of the
errors and warnings
	* timeBeforeExpiration,
	* graceLoginsRemaining,
	* passwordExpired,
	* acocuntLocked,
	* changeAfterReset,
	* passwordModNotAllowed,
	* mustSupplyOldPassword,
	* invalidPasswordSyntax,
	* passwordTooShort,
	* passwordTooYoung,
	* passwordInHistory
provide vital information as to why the directory is not ( or will not in
the future) be behaving according to the "normal" LDAP protocol rules.
It is simply pointless enforcing a password policy and having unaware
clients interacting with the system.

My overall view is that the server must fail binds and compares if pwdReset
is true and it does not think that the client could handle a response
control. (Still not sure about the search operation. Any suggestions ???).
It must handle binds and compares normally if the client has indicated that
they are able to handle a response control.
This requires a few changes to be made:
* Clear statement that clients MUST provide a request control if they want
the password policy to apply normally
* Clear statement that the server will be basing its opinion on whether a
client supports the password policy on whether the client has provided a
request control.
* Mandating that the server must return a response control (in an erroneous
or warning situation) when the client has sent one

Cheers,
Andrew Sciberras.

P.S.
Please let me know if a new version of this draft is due to be made, I have
some other suggestions that I'd like to make. Thanks.

---

From: Ludovic Poitou <[email-masked]>
Date: Thu, 20 Nov 2003 10:42:34 +0100

Andrew,

I've started editing the new version of the ID. Feel free to post your 
suggestions.
One of the comments that was made to me about the draft is about error 
results returned in the control. The question was whether we should 
create new LDAP Result codes or keep these in the Password Policy 
control. I think that most of them can be considered as sub-results of 
typical LDAP results. But the recent discussion let me believe that some 
errors could be new LDAP Result code and not returned in the Control. 
Still needs full analysis though.

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: Michael Ströder <[email-masked]>
Date: Thu, 20 Nov 2003 19:51:39 +0100

> response control should not be interacting with a password policy enabled

The majority of LDAP clients cannot handle a password  policy response 
control and judging from my personal experience I wouldn't bet that this 
will change any time soon.

> the future) be behaving according to the "normal" LDAP protocol rules.

BindRequest should fail. That's it. Fine-grained error handling at the
client would be nice but won't be possible with the majority of LDAP
clients.

The server should provide an appropriate informational message in
LDAPResult.errorMessage though since most LDAP clients display or log this
message text. Yes, this is not perfect for client-side error handling but
it's common practice which somewhat helps in most situations.

> the password policy to apply normally

Are you saying here that the password policy should not be in effect if the
client does not provide a request control? Maybe I did get you wrong?

> client supports the password policy on whether the client has provided a

+1

> or warning situation) when the client has sent one

+1

Ciao, Michael.

---

From: "Andrew Sciberras" <[email-masked]>
Date: Fri, 21 Nov 2003 09:43:04 +1100

>Michael Ströder wrote:
>
>BindRequest should fail. That's it.

I really believe that the compare should fail as well.
The description for the 'Compare Operation':
"The compare operation MAY be used to compare a password. This might
 be performed when a client wishes to verify that user's supplied
 password is correct. An example of this is an LDAP HTTP
 authentication redirector. It may be desirable to use this rather
 than performing a bind operation in order to reduce possible
 overhead involved in performing a bind."

Surely this is the exact scenario for which we are having this
discussion; a client using the directory to authenticate someone's
password to grant them access to another service.

>client does not provide a request control? Maybe I did get you wrong?

I think my words just came out a little wrong.
I'm just saying that if a client does support the password policy control,
then they MUST provide it. Otherwise the directory may make some incorrect
assumptions about the client, which will lead to the password policy
not being enforced normally. Eg. Bind failing due to pwdReset, instead of
succeeding.

Andrew Sciberras.

---

From: Michael Ströder <[email-masked]>
Date: Fri, 21 Nov 2003 20:27:05 +0100

> I really believe that the compare should fail as well.

Yes! Simply forgot that. Thanks for the reminder.

> not being enforced normally. Eg. Bind failing due to pwdReset, instead of

IMO "SHOULD provide it" and a short note will be sufficient here to make 
implementors aware of the issues.

If a LDAP client, which in principle supports password policy control, wants 
to behave really dumb for some good reason it should be allowed to do so 
even if it does not look reasonable to us now. It then simply behaves like 
any other dumb LDAP client out there.

Ciao, Michael.

---

From: "Andrew Sciberras" <[email-masked]>
Date: Mon, 24 Nov 2003 10:37:41 +1100

>any other dumb LDAP client out there.

Agreed. That all sounds pretty cool to me.

Andrew Sciberras.