Re: Outstanding operations after TLS closure/renegotiation

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

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, as the appropriate behavior is
likely dependent on why the TLS alert or ciphersuite change
was initiated (and by whom), what security
associations/services were gained/lost due these events,
and associated policy model and policy information.  That
is, security factors can change and implementations must
be robust in their handling of security factor changes.
But what is robust, well, depends on numerous factors
(most of which are a local matter).

However, I think it appropriate to state a security
consideration.  That consideration should be very general.
Something like:
        Implementators should note that various security
        factors, including authentication and authorization
        information and data security services may change
        during the course of operation processing.  For
        instance, the user's credentials could expire,
        the user's access rights could be revoked,
        the underlying security layer(s) could be replaced,
        or terminated.  Implementations should be robust
        in the handling of changing security factors.
        In some cases, it may be appropriate to continue
        the operation even in light of the security
        factor changes.  For instance, it is likely
        appropriate to continue an Abandon or Unbind
        operation regardless of the change, or when
        the change was upgraded (or maintained) the
        security factor. In other cases, it may be
        appropriate to fail the operation or to
        alter the processing the operation. 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.  In certain cases, it may not
        be desirable to silently complete the
        operation or to silently fail the operation.

This discussion seems most appropriately included in
[AuthMeth].