Subject: protocol: closing SASL upon Unbind

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 06 Dec 2004 22:59:49 +0100

protocol-28 section 4.3 (Unbind Operation) says:

> (...) close the LDAP session as follows:
>
>   - cease exchanges at the LDAP message layer,
>   - close the SASL layer (if installed),

No.  To do that, one simply closes the connection.  As I noted earlier,
[SASL] does not define the operation of closing a SASL layer, it only
defines replacing it with another layer.
I suggest

    - cease exchanges at the the SASL layer (if installed),

>   - close the TLS layer (if installed), and
>   - close the transport connection.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 06 Dec 2004 14:20:18 -0800

>defines replacing it with another layer.

The SASL mechanism itself may provide a layer closure facility
and, if so, it should be used.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 6 Dec 2004 23:31:38 +0100

> and, if so, it should be used.

If so, [SASL] should be modified to mention such a facility: The
application shouldn't need to know that the particilar SASL layer it is
using has such a facility; the SASL implementation itself should provide
a "close the current layer" function.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 6 Dec 2004 23:44:32 +0100

> a "close the current layer" function.

Sorry, I meant "close the current layer if necessary", or "attempt to
close the current layer", or something like that.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 06 Dec 2004 15:06:57 -0800

At 02:31 PM 12/6/2004, Hallvard B Furuseth wrote:
>If so, [SASL] should be modified to mention such a facility:

[SASL] leaves most of the details of layers to mechanisms,
and, in general, doesn't preclude layers from providing closure
facilities.  If the SASL base specification needs to mention
something here, then I suggest you raise a concern on the
SASL mailing list.

>The application shouldn't need to know that the particilar SASL layer it is

Well, if by SASL implementation, you mean some library providing
some SASL services to a program, then likely, yes, that API
should likely include a close function.   That's a good topic
for those designing SASL APIs.  In Cyrus SASL, IIRC, the
function is named sasl_dispose().

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 06 Dec 2004 15:17:56 -0800

>close the current layer", or something like that.

If a peer attempts to gracefully close the current layer and fails,
wouldn't the peer then ungracefully close the current layer.

Do we really need to say anything more than "close the SASL layer"?

Or maybe we should say:
        cease exchanges at the LDAP message layer,
        tear down the SASL layer,
        tear down the TLS layer, and
        tear down the transport connection.

Note here that as SASL layer also refers to associations
established through the SASL services, so tear down applies
regardless of whether a SASL data security layer was installed
or not.

We can than say something like:
        Where the installed data security and transport services
        provide for graceful closure, the implementation SHOULD
        attempt graceful closure before resorting to ungraceful
        closure.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 06 Dec 2004 15:50:03 -0800

>regardless of whether a SASL data security layer was installed

But as SASL (or TLS) may not be used, I revise my suggestion to:
        cease exchanges at the LDAP message layer,
        tear down the SASL layer (if any),
        tear down the TLS layer (if any), and
        tear down the transport connection.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 7 Dec 2004 17:01:28 +0100

Kurt D. Zeilenga writes:
> facilities.

But it doesn't mandate it either, or even define the concept.  A
requirement to close the SASL layer is in essence a requirement to
make use of a private extension to SASL.

(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
destruction/finalization during garbage collection.)

> If the SASL base specification needs to mention

Will do.

SASL also doesn't say in which order SASL and TLS layers must be
removed.  Is there any reason LDAP needs to specify this?  If there is,
I suspect the same applies to other protocols, and that the order
belongs in the SASL protocol profile.

Anyway, unless the above is indeed needed, or we will wait for this to
be discussed on the SASL list, I suggest to be a bit more vague:

  cease exchanges at the LDAP message layer, tear down any SASL and TLS
  layers as appropriate, and tear down the transport connection.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 07 Dec 2004 08:12:57 -0800

At 08:01 AM 12/7/2004, Hallvard B Furuseth wrote:
>removed.  Is there any reason LDAP needs to specify this? 

LDAP specifies that SASL is layered above TLS.  During graceful
closure, one shouldn't teardown a lower layer until the above
layers have been torn down.

>  layers as appropriate, and tear down the transport connection.

I prefer to "and then" conjunctions between each (as I suggested) as
this indicates that the implementation should do a graceful top-down
closure.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 7 Dec 2004 17:43:37 +0100

> layers have been torn down.

Well, it seems like the obvious thing to do if SASL did define graceful
closure of a layer.  OTOH, LDAP can install a TLS and a and SASL layer
in any order, and supports removing TLS and keeping the connection
(including SASL).  And if one has a SASL implementation where removing
the layer is tied to closing the connection, removing TLS in the middle
of that may be nontrivial.

So - if someone removes the TLS layer before the SASL layer, what is the
actual problem with this?  Both client and server knows that Unbind has
been sent, so I don't see any security problem, at least.

> this indicates that the implementation should do a graceful top-down

And I omitted that and changed it from a numbed list to a sentence for
the opposite reason:-) If we are to be more specific, I'd prefer to wait
to see if the SASL WG defines the feature of removing a SASL layer
before closing the connection.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 07 Dec 2004 09:17:36 -0800

>>   layers as appropriate, and tear down the transport connection.

I would be fine with:
     cease exchanges at the LDAP message layer, tear down any SASL
     layer, tear down any TLS layer, and close the transport
     connection.

This has same basic level of vagueness as your suggestion.

My suggest differs slightly for a couple of subtle reasons.
I dislike the phrase "SASL and TLS layers" as unclear whether
this semantically equivalent "SASL layer and TLS layer".  That
is, I rather avoid using variants of use our defined terms.

I removed "as appropriate" as its extraneous and makes the
sentence harder to read.  The "any" makes it reasonable clear
that no tear down work may be needed where SASL is not in
use and/or no SASL security layer is in place.

I prefer "close" over "tear down" for the transport connection
as "close" is the more common terminology here.

At 08:43 AM 12/7/2004, Hallvard B Furuseth wrote:
>closure of a layer.

Though this might be moot now, I note:

The SASL framework does not and likely will not define how to do
graceful closure, however 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.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 07 Dec 2004 17:43:45 -0800

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.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 8 Dec 2004 17:50:49 +0100

Kurt D. Zeilenga writes:
> (...) while I have no

It still looks like a list of actions to take to me, so if it is
supposed to be unordered I'd prefer to swap SASL and TLS so it fits
[SASL] if one does take it to be ordered.  That seems more important
than listing it in the order which looks more graceful.

BTW, just to have stated it publicly: I didn't quite understand your
previous objection to "SASL and TLS layers" without comma, and as
discussed privately I disagree with part of your previous message
anyway, but hopefully that's irrelevant now.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 8 Dec 2004 18:10:41 +0100

> 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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Dec 2004 09:44:33 -0800

At 08:50 AM 12/8/2004, Hallvard B Furuseth wrote:
>It still looks like a list of actions to take to me,

It looks like an unordered list of actions to me.

>so if it is supposed to be unordered I'd prefer to swap SASL and TLS so it fits [SASL] if one does take it to be ordered. 

I don't see how switching the order fits SASL.  If one
were to take it as being ordered, the order (I think) is
generally appropriately for LDAP (as SASL is layered above
TLS).  It would be not wise to tear down TLS before SASL
as tearing down SASL could additional cipher buffer output,
which should rightly be protected by TLS.  Note that
the cipher buffers I refer to could be the result of
yet fully transferred response PDUs present at the time
the Unbind request was received.

The list of actions are presented top-down.  If we were
to switch SASL and TLS, some readers might mistaken think
TLS is layered above SASL.  I prefer to list protocol
layers top-down (or bottom-up).

>That seems more important

My point was that we should avoid variants of defined terms
as there can be ambiguity as to whether the variant was
intended to be used in a fashion consistent with the defined
term, or used in some other fashion.

The defined terms are "SASL layer" and "TLS layer", hence
"SASL layer and TLS layer" should be used instead of
"SASL and TLS layers".

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Dec 2004 10:17:45 -0800

At 09:10 AM 12/8/2004, Hallvard B Furuseth wrote:
>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

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.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 8 Dec 2004 20:56:30 +0100

> it should (but updated per this discussion).

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

> sense as there is no way to re-establish PDU alignment after

There is no way to send anything after abrupt closure.

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

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 Dec 2004 12:32:38 -0800

At 11:56 AM 12/8/2004, Hallvard B Furuseth wrote:
>that addition I don't see a problem with it.

But this section is talking about abrupt closure.  Not only
does it makes little to no sense to send a Notice of Disconnect
before an abrupt closure.

>The connection may be compromised and the Notice may not reach the client,
>but in most cases it probably will.

If the connection is compromised, one should cease sending
additional TLS data (period).

If the event is of a nature were abrupt closure is appropriate,
then the connection should be abruptly closed (no transmission
of any application-level (including PDUs, SASL cipher buffers,
or TLS frames) data.

If the event is of a nature where graceful closure is appropriate,
then the implementation should gracefully close the LDAP session
in an orderly fashion.  This should be initiated by queuing
an Unbind or Notice of Disconnect (depending on which peer is
initiating) for transfer, closing the queue, allowing the
queue to drain, allowing the SASL layer to drain (per the
SASL and the SASL mechanism specifications), allowing TLS layer
to drain (per the TLS and TLS ciphersuite specifications),
and then closing the transport connection (per the transport
protocol specification).  It's noted that graceful closure
of the layers before the PDU layer may involve exchange
of data beyond that necessary to transfer the last LDAP
PDU.  For instance, TCP requires a specific closure exchange.
These should not be skipped during graceful closure.

Kurt