Re: protocol: closing SASL upon Unbind

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

At 10:19 AM 2/11/2005, Hallvard B Furuseth wrote:
>Sorry about the delay.
>
>Jim Sermersheim writes:
>> For my education, what about this is slightly wrong?
>>
>>>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 1/24/05 12:22:03 PM
>>
>> Ouch. I lost those threads completely, while trying to unravel some
>> SASL stuff. IIRC; after Kurt's last (private) explanation I think
>> this text will be slightly wrong whatever we do, unless we leave the
>> details underspecified as in earlier drafts. Or unless the SASL spec
>> is modified. So I guess this text is as good as any.
>
>I still think - but still need to look at this

I note that I (as chair) recommend this I-D (as I indicated I would
last week).  That said, I see no problem with continuing this
discussion.

Below are my personal thoughts (e.g., chair hat off).


First off, I think you are reading far too much into the text:
   In these cases each protocol
   peer gracefully terminates the LDAP session by ceasing exchanges at
   the LDAP message layer, tearing down any SASL layer, tearing down any
   TLS layer, and closing the transport connection.

This text does not detail what might be necessary to tear
down any SASL or TLS layer, only that they should be torn
down.  It is up to SASL and TLS specifications to specify how
to tear down these.

Please note that TLS provides truncation attack detection.  Also
note that future SASL mechanisms might provide truncation attack
detection.

Also note that no extension of [SASL] is required for a mechanism
to offer truncation attack detection.  [SASL] specifically says
mechanism may offer a wide range of services in security
layers and [SASL] says nothing about what cipher buffers
a mechanism might require to provide those services.

Just as [Protocol] leaves it to [TCP] to detail how to tear
down TCP, [Protocol] should leave details of how to tear down
TLS and SASL layers to TLS and SASL specifications.

>- that the only ways
>[SASL] provide to remove a SASL layer is "closing the connection" and
>"replacing the layer". 

[SASL] leaves details of layers to mechanisms.  A mechanism
is free to require additional cipher buffer exchange before
uninstalling (or to uninstall) the layer.  In particular, this
may be needed to provide a truncation attack detection service.
[SASL] does preclude mechanisms from providing such services.
In fact, [SASL] specifically states that mechanisms may provide
a wide range of services in layers.

>If a SASL implementation provides "removing the
>layer" as a separate operation, that's a SASL extension.

No extension of SASL is required for a mechanism to offer
truncation detection services (or re-keying, or whatever)
as SASL relies on mechanism specifications to detail what
cipher buffers are necessary to accomplish any application
protocol exchange and/or service provided by the mechanism.

>If LDAP - or a
>SASL mechanism - requires support for first removing the layer, then
>doing something else on the connection, and then closing it, then it
>depends on an extension to [SASL].  LDAP does not refer to the definition of this extension.

No extension is necessary.

>OTOH, Kurt listed privately quite a number of horrors with doing things
>the other way around: First removing the TLS layer, then the SASL layer.
>For example, note the problems we had with TLS layer removal - we had to
>invalidate the connection afterwards.  SASL above TLS has the same
>problem.  In particular if closing the SASL layer involves messages in
>both directions, which I believe Kurt said was possible.

A SASL mechanism is free to specify what SASL cipher buffers are
necessary to gracefully shutdown the layer, just as it free to
specify what cipher buffers are necessary to initiate a layer.

>Which reminds me: Something - either [SASL] or [Protocol] or [Authmeth]
>- needs a warning about security problems with removing security layers
>in the wrong order.  Since LDAP explicitly allows them to be added in
>any order, maybe a warning in an LDAP document is a good thing.
>Otherwise someone might feel the natural way to remove the layers is in
>the reverse order of how they were added.

I suggest you offer specific text for discussion.


>>Jim Sermersheim writes:
>>> Unless there are further issues with this, I will replace the current
>>> instructions for Unbind with Kurts suggested text here.
>>>
>>> >>> "Kurt D. Zeilenga" < Kurt@OpenLDAP.org > 12/7/04 6:43:45 PM >>>
>>> 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.
>>>
>>> Hence, I suggest:
>>>
>>> The client, upon transmission of the UnbindRequest, and
>>> the server, upon receipt of the UnbindRequest are to
>>> gracefully close the LDAP session by ceasing exchange
>>> at the LDAP message layer, tearing down any SASL layer,
>>> tearing down any TLS layer, and closing the transport
>>> connection.
>>>
>>> I note that while the 4 actions the implementation might need
>>> to take are stated in the order which the implementation likely
>>> would need to affect graceful closure of the LDAP session,
>>> the text does not actually prescribe a particular order, nor
>>> does it imply that any exchange within the SASL and/or TLS
>>> layer would been necessary.
>
>-- 
>Hallvard