[anonsec] 3401 and highjacking

[kent at bbn.com (Stephen Kent)]

At 6:00 PM -0600 2/21/06, Nicolas Williams wrote:
>On Tue, Feb 21, 2006 at 06:24:05PM -0500, Stephen Kent wrote:
>>  Nico,
>>
>>  > > however, it is fair to say that I worry that the attempt to use layer
>>  >> 7 authentication in conjunction with layer 3 confidentiality,
>>  >> integrity and access control may a continuing source of problems for
>>  >> us.
>>  >
>>  >Hmm, no, the problems we've been discussing in this thread do not arise
>>  >from trying to mix authentication at higher layers with session
>>  >protection at lower layers.  In fact, channel binding is an answer to
>>  >those problems :)
>>
>>  Maybe for end systems, but probably not for intermediate systems.
>
>BTNS for SG use is out of scope, as I recall...

I really don't recall, and I'm too lazy to check the charter right 
now :-).  But IF one were to suggest changes to IPsec that are 
designed to address problems other than those induced by BTNS 
functionality, THEN such changes must be considered in the context of 
all IPsec deployment options as defined in 4301, i.e., native host, 
BITW, BITS, and SG.

>
>...but even if it is in scope, connection latching[*] (though there is
>no ULP connection to speak of) can still work, as can channel binding.
>
>[*]  See draft-btns-connection-latching-00, when it appears in the I-D
>      directory.
>
>Think of having a layer 7 protocol for authenticating to the SG and the
>SG enabling packet forwarding only once the client is authenticated;
>conversely the tunnel (and latch) are to be torn down only when the
>client agrees or a sufficiently long inactivity timer expires.  The
>latch and inactivity timer prevent theft of a client's packet flows (the
>attack that Michael described a few days ago).

This almost sounds like a MIDCOM-style solution. I think this would 
be a very big change to the current IPsec architecture, probably out 
of scope for this WG.

Steve