Subject: Re: Outstanding operations after TLS closure/renegotiation

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 6 Mar 2005 19:02:21 +0100

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 08 Mar 2005 00:27:18 -0600

At 12:02 PM 3/6/2005, Hallvard B Furuseth wrote:
>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

Drop "or Unbind" then.

>Missing "to NOT include password..." I presume.

Or, s/include/exclude/

>However, I think that
>important than that of passwords.

Well, I don't think the text suggests any such thing.

>At best the server could re-apply

Which could cause either of the behavior described.

>I disagree with that one, see above.

I may have meant "may be desirable".

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 08 Mar 2005 15:16:47 +0100

Kurt D. Zeilenga writes:
>> 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.
>

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.

> to inappropriately reuse message IDs).

OK.

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

> outstanding operations.  Nothing in RFC 2830 required the

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

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

>>>         password values or, minimally, to [exclude] password values
>>>         in the response.
>>
>> However, I think that

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.

> 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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 8 Mar 2005 16:27:49 +0100

> closure), we'd still have to say something about in which cases it must

Sorry, I forgot we were talking about ciphersuite renegotiation and not
closure here, and old vs new clients too.  So old clients not expecting
to need timeouts would break anyway.

New clients -- I've just been trying to think of a clean way to write a
client which makes use of a response with may or may not arrive.  In
some cases one could of course just wait for a while and then exit with
an error message.  But if one wants to try anything more complex, the
code quickly gets ugly.  In particular handling error responses from the
operations, which might e.g. have been attempted in the opposite order
from how they were sent.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 8 Mar 2005 17:01:00 +0100

Maybe this will be my last reply to myself...

I wrote:
> code quickly gets ugly.

...like reestablishing TLS and retrying the operation (with a new
message ID) after a while:

> In particular handling error responses from the

-- 
Hallvard