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

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

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

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

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.

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.
>
>Relevant texts from [protocol]:
>
>> 4.1.1. Message Envelope 
>> 
>>    If the server receives a PDU from the client in which the LDAPMessage 
>>    SEQUENCE tag cannot be recognized, the messageID cannot be parsed, 
>>    the tag of the protocolOp is not recognized as a request, or the 
>>    encoding structures or lengths of data fields are found to be 
>>    incorrect, then the server SHOULD return the Notice of Disconnection 
>>    described in Section 4.4.1, with the resultCode set to protocolError, 
>>    and MUST immediately close the transport connection.  
>>     
>>    In other cases where the client or server cannot parse a PDU, it 
>>    SHOULD abruptly close the transport connection where further 
>>    communication (including providing notice) would be 
>>    pernicious. Otherwise, server implementations MUST return an 
>>    appropriate response to the request, with the resultCode set to 
>>    protocolError. 
>
>> 4.4.1. Notice of Disconnection 
>> 
>>    Upon transmission of the Notice of Disconnection, the server MUST 
>>    cease transmission of messages to the client, and MUST close the 
>>    transport connection. 
>
>> 4.14.3.2. Abrupt Removal 
>>  
>>    Either the client or server MAY abruptly remove the TLS layer by 
>>    closing the transport connection. In this circumstance, a server MAY 
>>    send the client a Notice of Disconnection before closing the 
>>    transport connection.  
>
>-- 
>Hallvard