[anonsec] 3401 and highjacking

[kent at bbn.com (Stephen Kent)]

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. 
IPsec tries to offer roughly the same set of services for native 
host, BITS, BITW, and SG implementations. That's why we need to not 
assume channel binding is a solution for the full range of IPsec 
contexts. The BTNS contexts that are the primary focus for you are 
ones that can take advantage of native host implementations, and 
that's fine. But since the scope of IPsec is much broader, we ought 
not assume that we can rely on channel binding in general for Ipsec.

>...
>
>I don't recall any such proposals.  The argument that I've made is
>"these problems existed in the IPsec architecture to begin with, but
>they are most significant when BTNS is in the picture..." followed by
>"channel binding helps a lot" :)

OK.

>
>>  My perspective is that the current PAD/SPD model works for IPsec,
>>  when one looks at the rest of the mechanisms used in IPsec
>>  deployments.
>
>I'm not sure that it does for sufficiently large and dynamic networks; I
>have no experience deploying and managing IPsec in such environments, so
>it's hard for me to say this authoritatively, but it does seem like a
>logical conclusion.

well, the folks who have experience deploying IPsec today don't seem 
to regard the problems we've explored as significant, as evidenced by 
a lack of feedback in the IPsec WG as we developed 4301. (These folks 
DID provide feedback that caused other changes to the architecture 
and that motivated the features set of IKE v2, so they were not 
silent.) But, you may argue that the current environment for 
deployment is not as dynamic as what you envision, and thus this is 
not a good basis for evaluating the adequacy of the current model. 
However, the mobile IP folks have been developing solutions based on 
4301, in their context, which is very dynamic, so I may disagree with 
your conclusion.

>
>>  The challenge for the WG is to add BTNS functionality to the existing
>>  IPsec architecture, without undermining the existing IPsec access
>>  control model. It is not to change the architecture for authenticated
>>  IPsec as a side effect of accommodating BTNS functionality.
>
>Not only.  We should want BTNS not to undermine the existing IPsec
>architecture (I believe it does not, conceptually, nor concretely in my
>latest I-D), but also ensure that BTNS has certain desirable properties.
>
>BTNS as described in draft-btns-btns-00 is not good enough for my
>purposes, nor does it meet the original requirement of protection
>against MITM attacks after an initial exchange.  But add draft-btns-
>connection-latching-00, channel bindings and/or leap-of-faith (ugh) and
>then it is good enough for some/most[/all?] of the stated purposes.

I was not suggesting that any specific draft on the table has the 
problems I allude to above. I was making a general statement about 
how the WG ought to proceed when viewing any proposals.

Steve