Re: Outstanding operations after TLS closure/renegotiation

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

At 12:02 PM 3/6/2005, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>At 05:34 AM 2/25/2005, Hallvard B Furuseth wrote:
>>>Protocol-30 4.14.3 (Removal of the TLS Layer) says:
>>>
>>>>   After the TLS layer has been removed, the server MUST NOT send
>>>>   responses to any request message received before the TLS closure
>>>>   alert. Thus, clients wishing to receive responses to messages sent
>>>>   while the TLS layer is intact MUST wait for those message responses
>>>>   before sending the TLS closure alert.
>>>
>>> Didn't we have some text clarifying that the server can either complete
>>> such operations without sending a response, or abandon them?  I don't
>>> see that here.
>>>
>>> How about outstanding operations after TLS ciphersuite renegotiation?
>>> I would think they have the same problem as we'd have with sending
>>> responses after closure.  At least if a poorer cipher is negotiated,
>>> but it would be messy to try to maintain some ranking of which
>>> renegotiations should drop responses and which ones should not.
>>
>> 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.

>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).

>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].

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.

>That is counter to RFC 2251 section 4.1.1.1,

Correct.


>and RFC 2830 (LDAP with TLS)
>says nothing about it, but section 4.1.1.1 has problems anyway.

Well, I think 4.1.1.1 was good enough.  I am not aware of any
client improperly reusing message ids (except test clients
specifically designed to do).  It seems to me that we might
be now overspecifying what should be simple.  Clients simply
should not use a message id if doing do would lead to any
ambiguity as to what request a subsequent response was in
response to.  I would hope that client implementors simply
avoid reusing ids to avoid all possible ambiguity.


>If a
>client does so, a response to an request previous to the TLS closure
>would be taken to be the response to a newer request.
>Even if it did
>not, responses which the client did not expect might pile up in the
>client library's memory.
>
>> However, I think it appropriate to state a security
>> consideration.  That consideration should be very general.
>> Something like:
>
>Mostly good, except:
>
>>         For instance, it is likely appropriate to continue an
>>         Abandon or Unbind operation regardless of the change,
>
>I would not even imply that one might refrain from completing an Unbind.

Drop "or Unbind" then.


>>         For instance, if confidential protections were removed,
>>         it would appropriate to either fail a request to return
>>         password values or, minimally, to include password values
>>         in the response.
>
>Missing "to NOT include password..." I presume.

Or, s/include/exclude/

>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.


>At best the server could re-apply
>the access controls as for anonymous connections or something.

Which could cause either of the behavior described.


>>         In certain cases, it may not be desirable to silently
>>         complete the operation or to silently fail the operation.
>
>I disagree with that one, see above.

I may have meant "may be desirable".

>> This discussion seems most appropriately included in [AuthMeth].
>
>I think which options the server has (such as to send a response or not,
>and to complete the operation or not) is a Protocol issue.  Well,
>discussion of the option to abort the session might go in [Authmeth],
>since [Protocol] already allows it in general.
>
>-- 
>Hallvard