Re: APPLCORE: An architectural question

first, the relevant portion of those notes (about removing the 3WHS,
not specifically about T/TCP)

> First, removing the three-way handshake opens up security holes. The
> issue of sequence number guessing attacks is serious. IPSEC is
> reasonably cheap for 'over the wire' security, but a key question is
> where do you get the IPSEC keys? Unfortunately, multiple RTTs are
> needed to connect with a key manager, and one needs
> loosely-synchronized clocks (to address replay attacks). Other public
> key management systems will be similarly expensive. The best you can
> hope for is to cache key management state. But this doesn't work if
> you talk to a lot of other entities over a short time.
> 
> However, it might be that object security is in fact cheaper than
> transport security (though you still need to watch for replays).

okay, first when we say "opens up security holes", we need to ask
"compared to what?"  Seems like the important point is that a
connection that lacks a 3WHS may be more vulnerable to some kinds of
hijacking attacks than a traditional TCP connection.  I'm by no means
an expert on security and my brain hurts too much today to analyze
this in detail.  But I wonder how much this really hurts us.

For example, in the case of a very short "connection" of one request
and one response packet each, I don't immediately understand the
difference between a connection hijacking attack, and a simple
impersonation of the client or server host.  The danger of using T/TCP
relative to using TCP, it seems, is that we will use some sort of
authentication mechanism which doesn't guarantee integrity for the
whole session, allowing someone else to steal the connection and
impersonate the authenticated party.  But you cannot "hijack" a
connection when the server sends a FIN in response to the first SYN,
and for longer connections it's not difficult to define ways to
prevent connection hijacking - i.e. to make sure you're still talking
to the same host as when you started the connection.  

So I don't think we should consider T/TCP "dead"; but we might need to
tweak it (not unusual for an experimental protocol), or ensure that
other kinds of protection (such as object security) are provided by
any "applcore" protocol that we define.  But we knew we had to do that
anyway, didn't we?

Keith

(real authentication of your peer is of course still very difficult to
do, especially without adding steps.  but we don't always need real
authentication, and in the cases we do, perhaps we can find a way to
piggyback that authentication along with payload - as long as we don't
trust the payload to be authentic until the authenticaiton is
complete.)

Received on Wednesday, 10 February 1999 16:16:28 UTC