RE: Protocol: control specifications.

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:02 PM 3/9/2004, Hallvard B Furuseth wrote:
>Ramsay, Ron writes:
>> I can see no point in discussions of how a server should handle
>> incorrect criticality.
>
>Whether there is any point in discussing it anymore I don't know.

It does seem we're beating a dead horse.

>I do wish someone knew what some X.500 servers do about wrong
>criticality.

I am pretty sure they behave in a manner consistent with most
LDAP servers.   That is, criticality is irrelevant to a server
making use of the extension information.  However, those
implementing DAP are welcomed to comment here.

But then, again, I don't think it matters all that much.  We
should be more concerned by what LDAP implementatoins are doing,
and how to revise the LDAP specification such that new
implementations are able to interoperate with existing as
well as other new implementations then attempting to re-engineer
LDAP to what we think was intended (or what we think it should
have been).

>> I don't see either as acceptable server behaviour.
>
>And I don't see why servers should be forbidden to catch this particular
>client error.

They aren't forbidden per say, but prohibited from checking unless the
control specification states a specific requirement (against the guidance
against overloading criticality) for that they implement such a check.

Because that can lead to interoperability problems.  That is, while
you intend this to catch errors during development, it might have the
effect of producing non-conforming clients (because they follow a
server which doesn't provide the diagnostic, or provide s a bogus
diagnostic).

It also will lead to cases where an otherwise conforming client and
otherwise conforming server fail to interoperate simply because the
fail to agree to the proper value of criticality.  Such disagreements
should not be fatal to interoperability.

Also, having the server verify criticality limits the kinds of extensions
which can be made to LDAP.  That is, it makes it harder to extend
controls to support new operations, makes it harder to extend operations
extended by controls with new controls, etc..

In the same vein, consider issues regarding changes to the set of appropriate
messages which a control can be attached to.  Should a server verify that
a control whose specification said "MUST be attached only to a search request"
treat attachment of the control to a non-search request as a protocol error?
Shouldn't it be allowed for a new extended operation to say that this old
control can not be attached to the new operation?

What if the appropriate criticality for this new operation was different?
Would it be appropriate to new extended operation to say "old control MUST be
critical" even though the specification for that old control said it MUST
always be non-critical?

And what happens when a new security consideration arises that suggests
that a control, whose previous specification said be non-critical, should
not be critical in a some cases.  A sender verification requirement would
disallow simply changing the guidance provided to the client developer
(or user), but force the introduction of a replacement control.

That is, have criticality be "in the eye of the client" allows a great
deal of revision and extension flexibility.

>There are plenty of client errors that servers may, but
>need not, catch.  I think it's an important client error to catch, since
>it can be so damaging.

It can be damaging to unnecessarily catch errors that don't matter.
That is, the "be liberal in what you accept" principle is quite sound.

>As important as rejecting cleartext password binds done without TLS.

Bad example.  Use of cleartext passwords without TLS is not a protocol
error.

>After all, rejecting the bind doesn't protect the password, that has already been sent in the clear.  But it encourages the client to be fixed.

Some argue that such checks encourage complaints to be made to the
server developer not the client developer.  Some vendors don't think
its there place to police other vendors.

Kurt