Subject: [ldapext] password policy response control question

From: John McMeeking <[email-masked]>
Date: Sun, 7 May 2006 21:26:20 -0500

What response should the server send
if there are no password policy warnings or errors to report?

I've heard several answers proposed
on my team, along with arguments for and against:

1.  Do not send a password policy
response control.

2.  Send a response control with
no value.

3.  Send a response control where
the value consists of an empty sequence.

The draft says that responses are sent
"when appropriate", and there is a general rule that protocols
shouldn't be unnecessarily "chatty".  Not sending a response
fits both those criteria, but some have argued that not sending this control
should be interpreted as meaning the server does not support the control
(perhaps the control is not supported with a particular naming context)
.  Control values are optional for LDAP controls in general.  The
draft doesn't say the response MUST be sent with a control value; neither
does it state any condition under which the server would send a response
control without a warning or error.

The converse of the question might be:
What should a client expect as normal responses?

John  McMeeking

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

---

From: Howard Chu <[email-masked]>
Date: Sun, 07 May 2006 19:48:24 -0700

John McMeeking wrote:
> 
> What response should the server send if there are no password policy 
> warnings or errors to report?
> 
> I've heard several answers proposed on my team, along with arguments for 
> and against:
> 
> 1.  Do not send a password policy response control.
> 2.  Send a response control with no value.
> 3.  Send a response control where the value consists of an empty sequence.

The OpenLDAP implementation does (3). If I were writing a client, I'm 
not sure I'd care. For an unsupported control, you would get a specific 
error already. So, absent that error, I would assume all's well.

> The draft says that responses are sent "when appropriate", and there is 
> a general rule that protocols shouldn't be unnecessarily "chatty".  Not 
> sending a response fits both those criteria, but some have argued that 
> not sending this control should be interpreted as meaning the server 
> does not support the control (perhaps the control is not supported with 
> a particular naming context) .  Control values are optional for LDAP 
> controls in general.  The draft doesn't say the response MUST be sent 
> with a control value; neither does it state any condition under which 
> the server would send a response control without a warning or error.
> 
> The converse of the question might be:  What should a client expect as 
> normal responses?
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/

---

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 8 May 2006 12:53:26 +1000

Hi John,
 
The question of whether to send a response ("when appropriate") has come
up before and has not been resolved. I'd like to put a stake in the
ground and say that a response should always be sent if the control is
understood (that is, if the server supports the control).
 
Further, I'd like to suggest that, in the case where there is no data to
be sent, the value be absent.
 
Ron

________________________________

From: John McMeeking [mailto:[email-masked]] 
Sent: Monday, 8 May 2006 12:26 PM
To: [email-masked]
Subject: [ldapext] password policy response control question

1.  Do not send a password policy response control. 
2.  Send a response control with no value. 
3.  Send a response control where the value consists of an empty
sequence. 

John  McMeeking

---

From: "Pierangelo Masarati" <[email-masked]>
Date: Mon, 8 May 2006 10:17:00 +0200 (CEST)

> understood (that is, if the server supports the control).

Ron,

the fact that the control is understood is guaranteed by the fact that the
DSA didn't reject the request with unavailableCriticalExtension; it would
be acceptable for the control response to be absent if not needed.  This
is true, of course for critical controls.  I'd favor this case.

> be sent, the value be absent.

this should be the behavior when the control is not critical.

p.

Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    [email-masked]
------------------------------------------

---

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 8 May 2006 18:43:11 +1000

Hmmm. I didn't think the control was required to be marked 'critical'
but, if it is, then you are correct that the control will have been
recognised if the request was performed. (Your remark "when the control
is not critical" makes me believe that you don't understand the use of
the criticality flag. For example, you cannot respond with
"unavailableCriticalExtension" if the control is not marked critical.)

I don't see how whether a response control is sent is related to whether
the control is critical. Originally, the idea was that whether the
control was marked critical or not, processing should be the same. This
may have changed recently with Kurt's remarks on the behaviour of
modules in OpenLDAP and also with reference to distributed operations.

Therefore, it is simply a preference whether a control on the request is
matched with one on the response. I am in favour of this always being
the case. Two of the most troublesome operations in LDAP are Abandon and
Unbind, simply because they are not confirmed operations. Please let's
have this control 'confirmed'.

Also, I don't believe it is required to be marked 'critical', so a
response control will set the client at ease.

Ron

-----Original Message-----
From: Pierangelo Masarati [mailto:[email-masked]] 
Sent: Monday, 8 May 2006 6:17 PM
To: Ramsay, Ron
Cc: John McMeeking; [email-masked]
Subject: RE: [ldapext] password policy response control question

> Hi John,
>
> The question of whether to send a response ("when appropriate") has 
> come up before and has not been resolved. I'd like to put a stake in 
> the ground and say that a response should always be sent if the 
> control is understood (that is, if the server supports the control).

Ron,

the fact that the control is understood is guaranteed by the fact that
the DSA didn't reject the request with unavailableCriticalExtension; it
would be acceptable for the control response to be absent if not needed.
This is true, of course for critical controls.  I'd favor this case.

> Further, I'd like to suggest that, in the case where there is no data 
> to be sent, the value be absent.

p.

Ing. Pierangelo Masarati

SysNet s.n.c.

---

From: Howard Chu <[email-masked]>
Date: Mon, 08 May 2006 02:43:34 -0700

I agree with most of the points here, and it aligns with our rationale 
in writing the OpenLDAP implementation. Also my reading of section 6.2 
of the draft:

6.2  Response Control

    If the client has sent a passwordPolicyRequest control, the server
    (when solicited by the inclusion of the request control) sends this
    control with the following operation responses: bindResponse,
    modifyResponse, addResponse, compareResponse and possibly
    extendedResponse, to inform of various conditions, and MAY be sent
    with other operations (in the case of the changeAfterReset error).

I interpret "the server ... sends this control" as "the server SHALL 
send this control..." But that's a separate question (whether the 
response control is sent at all) from the original query (whether the 
control value should be present in the response control).

Still, the use of the control by the client is purely for informative 
purposes; the policies will take effect on the server regardless. As 
such, if the client really really wants to know that an operation 
succeeded in full conformance with the policy, then the client should 
set criticality TRUE in the request.

---

From: "Pierangelo Masarati" <[email-masked]>
Date: Mon, 8 May 2006 12:03:04 +0200 (CEST)

> Hmmm. I didn't think the control was required to be marked 'critical'

from <draft-behera-ldap-password-policy-09>

   The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality may
   be TRUE or FALSE.  There is no controlValue.

> "unavailableCriticalExtension" if the control is not marked critical.)

I believe I understand it.  That's why I agree that if no criticality was
set in the request, a control response with no value should be sent to
clarify that the DSA understood the control.

> the control is critical.

If the control response does not add to the knowledge of the client, it's
a waste of resources.  I believe this is the case if the control
criticality is set but the control response would be empty.  The draft
correctly does not require an empty control response to be returned.

> Originally, the idea was that whether the
> control was marked critical or not, processing should be the same.

If the control is recognized, yes.  If it's not, processing changes quite
a bit.

> This

No, it's not.  My suggestion is about not wasting resources.  I don't mind
too much about badly written clients (things like: since I sent the
control request, there must be a control response, so I don't even check
it's there are nonsense).  In "modern" LDAP client writing, developers
should never assume anything but correctness and, when possible,
efficiency.  I think a response that doesn't add to what the client
already knows is inefficient.

Another point is: this control is about security; I don't like risking
that a security related control is ignored just because I'm too lazy to
mark the request as critical.  If I send the request I'd first make sure
the server supports it, and then requite it to process my request
accordingly.

p.

Ing. Pierangelo Masarati

SysNet s.n.c.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 08 May 2006 11:11:34 -0700

At 07:26 PM 5/7/2006, John McMeeking wrote:

>What response should the server send if there are no password policy warnings or errors to report? 
>
>I've heard several answers proposed on my team, along with arguments for and against: 
>

IIRC, 2) would violate the control specification. The control value
is a BER-encoded instance of a SEQUENCE with some optional fields.
One could change the specification to state that, in lieu of
sending an empty sequence, no control value MUST/SHOULD/MAY be
provided.  However, doing so
1) can complicate implementations and
2) (in the SHOULD/MAY case) can lead to interoperability problems.

>The draft says that responses are sent "when appropriate", and there is a general rule that protocols shouldn't be unnecessarily "chatty".

The "chatty" rule is not applicable here.  A protocol is not
unnecessary chatty simply because the rules used to encode
a value is not minimally compact.

I note that there is value in the protocol being simple.
Having multiple encoding rules for the same or different
abstract values of the same type is unnecessarily complex.

>Not sending a response fits both those criteria, but some have argued that not sending this control should be interpreted as meaning the server does not support the control (perhaps the control is not supported with a particular naming context) .  Control values are optional for LDAP controls in general.  The draft doesn't say the response MUST be sent with a control value; neither does it state any condition under which the server would send a response control without a warning or error. 
>
>The converse of the question might be:  What should a client expect as normal responses? 
>
>
>John  McMeeking

---

From: Pete Rowley <[email-masked]>
Date: Mon, 08 May 2006 16:03:31 -0700

> clarify that the DSA understood the control.
If the client needs to know that there support for the control, doing so 
by altering the flow of the protocol is not the way to do it, 
particularly when the change in flow is unrelated to the mechanism that 
caused it.  The client should examine the root DSE entry for supported 
controls, and should be able to expect the same behavior whether it 
marks the control critical or not. Marking a control non-critical 
implies a level of indifference as to whether its function is understood 
and performed and I fail to see the need to inform those who are 
indifferent.

-- 
Pete

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 08 May 2006 16:19:51 -0700

A control can be recognized by the server and hence
published in supportedControl but current unavailable.
I also note that supportedControl may be visible to
the client.  But I think this is a bit of digression.

IMO, If a request control has an associated response control,
that response control should be returned whenever the
request control is made use of in processing the operation.
No exceptions.  Having a request control that sometimes has,
sometimes hasn't a response control is bad.

Kurt

At 04:03 PM 5/8/2006, Pete Rowley wrote:
>If the client needs to know that there support for the control, doing so by altering the flow of the protocol is not the way to do it, particularly when the change in flow is unrelated to the mechanism that caused it.  The client should examine the root DSE entry for supported controls, and should be able to expect the same behavior whether it marks the control critical or not. Marking a control non-critical implies a level of indifference as to whether its function is understood and performed and I fail to see the need to inform those who are indifferent.
>
>-- 
>Pete
>
>
>
>