[anonsec] 3401 and highjacking

[Nicolas Williams]

On Thu, Feb 16, 2006 at 07:16:44PM -0500, Stephen Kent wrote:
> Nico,
> 
> I'm afraid your interpretation of my comments diverges from my intent 
> in several places.  I'll try to clarify, using some different words 
> this time, and responding directly to your comments.
> 
> #1: do we agree on the "significance" of wildcard matching in the PAD?

I read the following to mean more or less "yes."

[text not quoted.]

> My point here is that the type of problems we're discussing are not 
> really specific to the use of wildcards, and probably not specific to 
> the PAD design.

They are specific to configurations that try to avoid tying specific IDs
to specific IP addresses.  Such configurations will typically use
wildcard matching, I assume.

> Because BTNS wants to create SAs for entities who possess no 
> authentication credentials, we cannot use the same set of criteria to 
> reject SAs that use addresses that collide with other SAs, as 
> suggested above. This exacerbates what I think is a relatively minor 
> issue. I'd call this a BTNS-generated problem.

Whereas I focus on the "exacerbates" part above.  If we disagree then
it's a matter of degree.

> #2 Did I say that pushing session protection down the stack is out of scope?
> 
> No. I explained why I disagreed with your comment that performance 
> was the motivation for pushing some security measures lower in the 
> stack, while other factors pushed security measures higher in the 
> stack.

Was I not clear that this was *my* (as opposed to *the*) motivation?

>        I also said that one could use SSL to address some (though not 
> all) of the use cases that were put forth as motivations for BTNS, 
> but that is out of scope for this WG, based on its current charter.

You wrote "[b]ut, this WG decided to focus on IPsec, and so such
discussions are out of scope here."  I took this to mean that you meant
that talking about splitting security between layers is out of scope.

Perhaps I read too much into that.

> #3. Did I say that channel binding to IPsec SAs is infeasible.
> 
> Whether use of IPsec for channel binding is "feasible" is what the 
> output of this WG will determine. I suggested that when one tries to 
> split security service offerings between layers, one may create new 
> problems, problems that may not arise if one avoids crossing layer 
> boundaries in this fashion. Demonstrating the feasibility of using 
> IPsec for channel binding is the responsibility of those who propose 
> such uses.

Agreed.  I thought perhaps you might have some comments specifically
about the feasibility of channel bindings that you might share with us.

> What we have discussed in the thread that was restarted from last 
> year, was that under some circumstances, certain choices of PAD and 
> SPD entries might be problematic, in principle. Michael also noted 
> that we tend to not see this happening, due to various details of SG 
> implementations. So, what might be a minor weakness of the 4301 
> model, in principle, may be a more serious problem for BTNS. I 
> consider this a challenge for BTNS; I do not think it is a rationale 
> to make significant changes to IPsec, to accommodate BTNS.

I do agree that BTNS makes that "minor" weakness in the RFC4301 model
worse (and have said so now several times).  I don't agree that that
weakness is so minor.  Given a sufficiently large, sufficiently dynamic
network using IPsec (but not BTNS) that weakness approaches the same
severity as in the BTNS case.  In so far as when not using BTNS one does
have a choice (strongly tie IDs and IP addresses or don't), this
weakness is minor, but only if said choice is realistic, which, I
suspect, it is not for sufficiently large&dynamic networks.

Again, I read this to mean that we're mostly in agreement.