Subject: Removing the SASL layer before the TLS layer

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 07 Dec 2004 23:43:47 +0100

The LDAPbis group is discussing to specify that terminating the session
would do something like:
    cease exchanges at the LDAP message layer,
    tear down the SASL layer (if any),
    tear down the TLS layer (if any), and
    close the transport connection.
LDAP specifies that TLS is layered between the transport connection and
any SASL layer, so it certainly looks reasonable to do it in this order.

Kurt tells me that
  a mechanism can define as part of its data security layer a graceful
  closure facility.  This can even be associated with another "kind of
  security services", which the SASL I-D explicitly states mechanisms
  may offer.
He also states that if SASL a mechanism provides a layer closure
facility, it should be used (by LDAP when terminating the session).

However, as far as I can tell rfc2222bis prohibits this:

   3.3 Security layers

   If use of a security layer is negotiated by the authentication
   protocol exchange, the security layer is applied to all subsequent
   data sent over the connection (until another security layer is
   negotiated ( see also section 6.3) or underlying connection is
   closed).

I had taken this to mean that the two interfaces which SASL provides to
remove the layer is to close the connection and to replace the layer.  I
can see no "call the mechanism's graceful closure facility if it exists"
interface, so for a protocol to require this seems to me to require the
use of a private extension to SASL.  That does not seem proper.
Though a protocol implementation may choose to do so, of course.

(A C implementation of SASL as currently specified will provide a
finalization function whether or not the spec says so, since there must
be some call to reclaim memory.  OTOH, this is not so for a garbage
collecting language, unless it includes the misfeature of doing
finalization during garbage collection.)

Also, to my reading, even if a mechanism provides a "graceful closure"
facility which leaves the connection intact, doing anything on the
connection (such as graceful TLS closure) between removing the layer
and closing the connection violates the text from 3.3 above.

Three solutions I see (in addition to possible clarifications of 3.3)
are:

* Provide a "close the SASL layer if the mechanism supports it"
  interface - possibly with the caveats that
  - it MUST NOT be used other than when closing the connection - though
    possibly before doing graceful TLS closure,
  - protocol peers MUST NOT accept other activity on the connection
    afterward.

* Allow the protocol profile to specify that if TLS is active, then when
  the connection is closed in an orderly manner the SASL layer is
  removed before - or after - the TLS layer if possible.
  "If possible" because the mechanism may not support it, or because
  only one protocol peer can invoke SASL layer removal and the
  connection closure is initiated by the wrong protocol peer.

* No change; a protocol should not specify that the SASL layer is
  removed before the TLS layer.

-- 
Hallvard