Re: Outstanding operations after TLS closure/renegotiation

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

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.  Also I imagine some
current clients can reuse message IDs after TLS closure, since they can
deduce that they won't receive responses with those message IDs.  That
is counter to RFC 2251 section 4.1.1.1, and RFC 2830 (LDAP with TLS)
says nothing about it, but section 4.1.1.1 has problems anyway.  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.

>         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.  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.  At best the server could re-apply
the access controls as for anonymous connections or something.

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

> 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