Re: Questions about adding additional connections to a session

["Julian Satran" <Julian_Satran@il.ibm.com>]

Bill,

You want to work both without a security
envelope and to resist an active attack...
If you keep letting in in your hypothetical
attacker time after time then you certainly  have a pretty weak security.
This type of attacks are not uncommon
on servers with a limited number of threads and the can be stopped by blocking
the intruder through some other means (IP address filtering etc.).  
And regardless of when you declare a
connection in session and count it in the limit - this type of attack will
consume some resources if it reaches your system.

Julo

Bill Studenmund <wrstuden@wasabisystems.com> Sent by: owner-ips@ece.cmu.edu 16/11/02 02:55

To:        <ips@ece.cmu.edu>         cc:                 Subject:        Questions about adding additional connections to a session

I was wondering when exactly an additional connection
becomes part of a
session? When it is IN_LOGIN, or LOGGED_IN?

This question is coming from the angle of seeing if an attacker could
disrupt a session by trying to log in additional connections. I'm also
assuming it's an attacker that does NOT have the security secrets; an
attacker with the secrets will look legitemate.

If the connection is added at LOGGED_IN, then there is nothing malicious
an attacker can do. However, that doesn't seem to be how the spec is
writen, and it means special-casing additional-connection logins. 'cause
we have state Q2, which corresponds to the first connection of the session
being in IN_LOGIN. It also breaks the clenliness of connections always
being in their session, and of using itt to always find a task, including
login, in a session.

The flip side is that if the extra connection is added at IN_LOGIN, then
an attacker can impact an operational session. Note: I understand well
that since I'm talking about an attacker without valid security
credentials, this impact is bounded; at some point the target will reject
the login.

At the bare minimum, assuming we enforce a limit on the number of
connections, the rogue connection will count. Thus there will be a window
in which the real initiator can't add new connections. Since it's real
easy to keep fake connections going, this could be a long-term attack.

The other thing I could see is that if the connection is part of the
session, then, unless care is taken, its itt is visable to the session.
Thus the real initiator can't start a task with that itt. While it's
feasable to shield the itt, you have to take care to do it.

Thoughts?

Take care,

Bill