Re: Protocol: Restricting operations while binding

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

There are a number of reasons why clients should be
prohibited from sending requests while a bind operation
is outstanding.

The client cannot assume the requested protocol version
is supported.

The client cannot assume it will be requested to use
a different method and/or to establish confidential
protections.

The client cannot assume it will not be referred to
another server.

The client cannot assume its credentials (or request
for anonymous will be accepted.

The client cannot assume its bind request will otherwise
be rejected.

A client which makes such assumptions, I think, fundamentally
flawed.

And, if its SASL bind that could result in security layers
being installed (or new layers installed), then you have
the problem where the request was sent under different
protective services than its responses.

I think we really do need to prohibit sending requests
when a bind operation is outstanding.  The question I
am struggling with is how should the server behave if
gets a request while processing a bind operation (such
as injected by an attacker).  While it might be nice
to respond with operationsError, if new layers have been
established prior to this response, the server shouldn't
respond to the request.  So, I think we either need to
just say "don't process, don't respond" or "respond if
you can do so before new layers, otherwise don't respond".
I think I favor the former.

At 08:05 PM 4/16/2004, Jim Sermersheim wrote:
>It was recently mentioned that we should discuss whether a client is allowed to send requests while a bind response is outstanding.  
> 
>The problem that has arisen in the past has been with clients that send operations asynchronously along with a bind. For example:
>
>C                  S
>*----------------------
>bind---------->
>               workerThread(bind)
>search-------->
>               workerThread(search)
><--------------search resp
><--------------bind resp
>
>This is due to the server spawning worker threads for each operation. Sometimes an operation is performed before operations sent prior.
>
>If the client is told to block until the bind response is returned before sending subsequent responses, it can be assured that those operations will be performed using the correct authN.
>
>I believe this goes beyond bind, to any operation that can change the authN or authZ of an association.
>
>I don't think we can get away with a mandate.

I don't think we can get way without a mandate.

>But I think a recommendation would be good.

I can only see using a SHOULD if there was a reasonable
use case, with existing implementations of that use case,
for allowing it.

Kurt