Re: server-initiated connection closure vs. TLS/SASL closure (was: closing SASL upon Unbind)

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

Kurt D. Zeilenga writes:
>At 09:10 AM 12/8/2004, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>> My previous suggestion does not adequately cover the
>>> issue of graceful closure of the LDAP session.  That is,
>>> the reason why a particular order was suggested was that
>>> it was thought to be graceful.  So while I have no
>>> problem with removing the ordering aspect of the current
>>> text, I'd like to indicate that Unbind/Notice of Disconnect
>>> are intended to affect a graceful closure.
>>
>> Actually, this thread started with the text for the Unbind operation,
>> not Notice of Disconnection.
>
> I just noticed that the Notice of Disconnect section does not
> include symmetric text to Unbind.  As previously discussed,
> it should (but updated per this discussion).

Which discussion was that?  It reached the opposite conclusion of mine
just now.

>> [Protocol] states that Notice of
>> Disconnection should use abrupt closure, not graceful, when the TLS
>> layer is removed.  It seems to say the same when the connection is
>> closed for other reasons, but maybe I'm seeing too much in these words.
>
> What I thought it meant was "In this circumstance, a server MAY
> send the client a Notice of Disconnection before closing the
> transport connection AFTER abruptly closing TLS."  This makes no
> sense as there is no way to re-establish PDU alignment after
> an abrupt closure.

There is no way to send anything after abrupt closure.

> If instead it was meant, "In this circumstance, a server MAY
> send the client a Notice of Disconnection before closing the
> transport connection BEFORE abruptly closing TLS", this would
> make little sense as that requires further use of TLS.

It should be 'In the case of server initiating closure,...', but with
that addition I don't see a problem with it.  The connection may be
compromised and the Notice may not reach the client, but in most cases
it probably will.

> I think 4.14.13.2 should simply read.
>    Either the client or server may abruptly remove the
>    TLS layer by abruptly closing the transport connection.
>
>>In any case, this seems to me to be the right choice.  For the server to
>>gracefully remove security layers might mean to gracefully surrender the
>>connection unencrypted to a hijacker.  It's not dangerous if the client
>>has noticed the Notice of Disconnection, but the client is no longer
>>required to do so - and I don't think many clients did when rfc2251 said
>>they should, anyway.
>>
>>The client ought to notice that security layers have disappeared, but
>>apparently we don't trust it to do that.  At least, that's the only
>>reason I can think of for [authmeth] to suggest that the server might
>>want to invalidate the association after TLS closure.  Makes sense at
>>least with the LDAP C API rfc/draft, which makes no provision for
>>discovering this.

-- 
Hallvard