Subject: protocol: session termination

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 11 Feb 2005 19:03:26 +0100

I'm sorry about dropping these threads - I seem to be suffering from
"standardization fatigue":-) I just haven't been able to sit down and
look at this.  So I'm sending a few comments before dashing off on a
week's holiday, and I guess I'm not promising to follow any detailed
resulting discussion anyway...  This is definitely a 'feel free to
ignore it'-kind of posting.

While comparing protocol-30 with -20, I noticed:

- Servers can or must use graceful closure instead of abrupt in some
  cases.  That doesn't seem to be reflected in the Changes appendix.

- A new paragraph:

> 6. Security Considerations
>
>   In the event that a protocol peer senses an attack which in its
>   nature could cause damage due to further communication at any layer
>   in the LDAP session, the protocol peer should abruptly terminate the
>   LDAP session as described in Section 5.3.

While this is good by itself, I think an at least as common scenario is
that it senses something which _might_ an attack, but might be something
else - e.g. a client error - which it would be useful for the client to
know about.  E.g. a revoked client certificate, or probably some of the
reasons for inventing the dreaded "invalidated associations".

I wonder if that's why I wanted Notice of Disconnection followed by
abrupt closure while Kurt did not, if Kurt was thinking more of events
that are clearly attacks.

When it's maybe not an attack, I think the server should inform the
client of why it's terminating the session.  After all, the purpose of
the Notice is to "assist clients in distinguishing between an
exceptional server condition and a transient network failure".  And when
it maybe is an attack, the session should be terminated abruptly rather
than gracefully (since graceful closure might surrender the connection
gracefully to an attacker so that he could continue the session.  Did
that discussion go astray?)

Or I suppose it could be an attack of a kind which might not be able to
prevent the server from informing the client of this.  Then it would
certainly be useful to inform the client of the attack.

Someone also spoke of Notice of Disconnection as part of the closure.  I
can see that from that point of view it can be un-nice to have it in the
middle of an abrupt closure, at least.
I always always thought of it as an alert sent before the closure, not
as a part of it.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 11 Feb 2005 13:24:16 -0800

>ignore it'-kind of posting.

(See my note regarding progression of this I-D in my response
to your "protocol: closing SASL upon Unbind" thread.)

The server may initiate closure the LDAP session at any time.
This closure may do so graceful or aburpt.  Graceful termination
implies that the server teardowns each layer in an orderly manner,
starting by sending a notice of disconnect at the LDAP
message layer.  Aburpt termination implies that the server
immediately ceases communications with the client at all layers
within the LDAP session.  This is appropriate where it would
be precarious to continue further communications.

>reasons for inventing the dreaded "invalidated associations".

In this scenario, the server should initiate gracefully close
the LDAP session by sending a Notice of Disconnect indicating
the reason for that closure, the proceed with tearing down the
LDAP session in an orderly manner.

But the quoted text is talking about the scenario where the
server feels it is precarious to communicate further with the
client within the LDAP session (or layer thereof).  In this
case, the server is to cease transmission at all layers of
the LDAP session and close the underlying connection.

>that are clearly attacks.

I wonder why you think abrupt closure of the LDAP session would
involve transfer of an LDAP PDU.

>client of why it's terminating the session.

If the server can safely do so, it should.  The text, I believe,
simply indicates that a server where further communication would
be precarious, the server may abruptly terminate those communications.

>After all, the purpose of
>exceptional server condition and a transient network failure". 
>And when it maybe is an attack, the session should be terminated abruptly rather

Aiding an attacker is also not the purpose of the notice.  If
sending a notice and/or gracefully teardown installed layers would
aide an attacker, the server should abruptly close the underlying
connection.  (And, I note, if sending a TCP RSET would aide
the attacker, the server may choose to terminate the session
by other means (ICMP) or simply cease ALL communications.

>certainly be useful to inform the client of the attack.

As noted above, abrupt closure is for when it would be
precarious to communicate the reason for disconnect (or
to otherwise communicate).

>I always always thought of it as an alert sent before the closure, not

I think it somewhat pointless to argue whether or not the notice
is part of the closure or not.

Instead, consider the following in termination of the LDAP session.

If further communication would be precarious, then the implementation
(client or server) should cease communications.  Period.  

If further communication would not be precarious, then the
implementation (client or server) should teardown the LDAP session
in a graceful manner, starting by sending an appropriate LDAP message
(Unbind for clients, Notice of Disconnect for servers) and then by
tearing down any installed security layer (taking advantage of
truncation attack detection in the layer), then by closing the
underlying connection.