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

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