Re: Outstanding operations after TLS closure/renegotiation

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt D. Zeilenga writes:
>At 12:02 PM 3/6/2005, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>> I am not sure it reasonable to prescribe a particular
>>> behavior in these cases, (...)
>>
>> Whether or not to send a response if the connection is kept open
>> needs to be prescribed, and should not be changed for LDAPv3.  Which
>> means I must withdraw my suggestion to "correct" that for
>> renegotiation.  Otherwise an old client which expects a reponse after
>> renegotiation will hang if the server does not send the response.
>
> But a server was not obligated, IMO, to complete the operation
> and hence never required to return a response.  The
> server is free to suspend the operation until (explicitly or
> implicitly abandoned).  Obviously, clients which hang on a
> response can hang indefinitely.

Technically true if you mean "in practice suspend forever", but by that
logic a client ought to wrap every LDAP call in a local timeout.  That
does not seem reasonable to me.  Or if clients are not supposed to need
that for every call but only in some situations (like after TLS
closure), we'd still have to say something about in which cases it must
expect such behaviour.

>> Also I imagine some
>> current clients can reuse message IDs after TLS closure,
>
> Given the behavior of commonly used LDAP client libraries
> (and the recommendations of RFC 2251 regarding message id
> generation), I seriously doubt that any such clients exist
> (with the possible except of test clients specifically designed
> to inappropriately reuse message IDs).

OK.

>> since they can
>> deduce that they won't receive responses with those message IDs.
>
> Noting that the client violated an absolute imperative:
>    Before closing a TLS connection, the client MUST either wait
>    for any outstanding LDAP operations to complete, or
>    explicitly abandon them [LDAPv3].

The client can't obey that if the server initiated TLS closure.
And the server is not required to wait for a time when there are
no known outstanding operations before it initiates TLS closure.

> it shouldn't be surprised if the connection is abruptly closed.
> It shouldn't however assume the server is going to abandon
> outstanding operations.  Nothing in RFC 2830 required the
> server to do so.

Except requests sent by the client but not yet received by the server
at the time the client receives a server-initiated TLS closure:

RFC 2830 4.1.  Graceful Closure

   After the initiator of a close has sent a closure alert, it MUST
   discard any TLS messages until it has received an alert from the
   other party.  It will cease to send TLS Record Protocol PDUs, and

But you are right, the [Protocol] text

   After the TLS layer has been removed, the server MUST NOT send
   responses to any request message received before the TLS closure
   alert.

is new, and as far as I can tell it is contrary to RFC 2830.  Unless
I'm missing something, if a client has received a search response to a
request, it can expect to receive further responses and the final
response according to RFC 2830.

A change of that seems bad too to me; maybe the best option is to
require the server to terminate the session rather than to just do TLS
closure if there are outstanding operations.

[Skipping parts where my answer is "ok"]

>>>         For instance, if confidential protections were removed,
>>>         it would appropriate to either fail a request to return
>>>         password values or, minimally, to [exclude] password values
>>>         in the response.
>>
>> However, I think that
>> is too weak.  I do not think we should suggest that the server at its
>> own initiative should judge other attributes' confidentiality to be less
>> important than that of passwords.
>
> Well, I don't think the text suggests any such thing.

I was thinking of situations like:

- The mechanism to exclude passwords is access controls,

- or sensitive info is protected by only being able to "self", and the
  rest of the protection is implemented by protecting the Bind
  operation.  E.g. one can only Bind using TLS, but then one loses TLS
  after a search and the server sends the responses unencrypted.  Which
  can also be solved by invalidating the association and re-applying the
  access controls, of course.  Yet access control can be hard to get
  right, so such a restrictive behaviour should be be the default.

>>At best the server could re-apply
>>the access controls as for anonymous connections or something.
>
> Which could cause either of the behavior described.

I'm not quite sure how, but given that I just proved that suggestion
wrong myself I seem to be getting lost anyway:-)

-- 
Hallvard