[anonsec] 3401 and highjacking

[Nicolas Williams]

On Thu, Feb 16, 2006 at 01:12:35PM -0500, Stephen Kent wrote:
> Nico,
> 
> I appreciate your analysis of the issues associated with the problems 
> we are discussing, but I disagree with several of your assertions and 
> conclusions.
> 
> Network dynamics are more a fact of life today than they were in the 
> past, which makes use of IP addresses less attractive as identifiers. 
> Yet, at layer 3, on a per-packet basis, we have only addresses as 
> end-point IDs, especially for intermediate systems like routers and 
> firewalls. So,if we choose to enforce access controls at layer three, 
> we have to be very careful in how we deal with identifiers, to ensure 
> that we don't make mistakes resulting from cross-layer ambiguities. 
> What we have done in IPsec and in other protocols is to allow for 
> higher layer IDs to be used in lieu of addresses (e.g., to 
> accommodate the dynamics you cite), but then to bind these IDs to 
> addresses to enable efficient, per-packet access control policy 
> enforcement for some time interval. An inevitable side effect of this 
> is the potential to have a mismatch between a higher level ID and the 
> address, based on unsynchronized management practices between the 
> layers, e.g., address reassignment.

In other words: we're in agreement on the significance of wildcard
matching in PAD entries.  Cool.

> You suggested that network security is being pushed up the stack. In 
> some regards that is true, and in others it is not. User 
> authentication at the application layer is nothing new; it has been a 
> staple of host security since the days of multi-programming, time 
> sharing, etc. Is it a network security issue? We have examples of how 
> to make it more of a network security issue and reduce security, 
> e.g., the Unix rhost file model. If we use certs to authenticate 
> users does that make this a network security mechanism? I think not. 
> On the other hand use of SSL/TLS is certainly an example of moving 
> security up the stack (from layer 3 to layer 5). For some set of 
> contexts, an SSL solution may be more appropriate than an IPsec 
> solution. But, this WG decided to focus on IPsec, and so such 
> discussions are out of scope here.

Hmm, no, pushing session protection down the stack is in scope,
indirectly at least.

> There are multiple motivations for imposing security controls at 
> layer 3. Performance may be important in some instances, as you 
> suggest, but more often the motivations have to do with assurance and 
> management. Lower layer controls can be more secure that higher later 
> controls, given the unfortunate state of OS and application security. 
> Lower layer controls can be imposed (cleanly) at points other than 
> end systems, which simplifies management and also may improve 
> assurance. None of this says that application layer security is 
> redundant. However, it also does not suggest that trying to split 
> security services between layer 3 and layer 7, as some BTNS use cases 
> require, will necessarily work well.

If channel binding to IPsec channels were not feasible I'd not spend one
more ounce of energy on BTNS.  Are you saying that they are not?  Please
expand.

> When this WG was chartered I noted that there were multiple 
> constituencies, each with different goals, all of which hoped to use 
> the same or similar mechanisms to achieve these disparate goals. What 
> we are seeing here may be an example of that.

This past week on this thread we've been discussing a weakness in the
RFC4301 model.  This somehow led me to explain, for the nth time, my use
case for BTNS.  Now that you're on the record as acknowledging (above)
that use of wildcards in PAD entries represents a significant trade-off
maybe we can move on and discuss other things :)

Nico
--