[anonsec] 3401 and highjacking

[kent at bbn.com (Stephen Kent)]

At 8:10 PM -0600 2/16/06, Nicolas Williams wrote:
>...
>>  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.

I see your point.  I was focusing on use of wild cards as indices 
into the PAD or SPD, but you are correctly noting that the issues we 
are discussing arise even when wild cards are NOT used as indices. 
Anyway, I think the messages from Michael and Mohan note that these 
sorts of issues are adequately addressed, in the current IPsec 
environment, through the use of various ancillary mechanisms, some of 
which are needed to deal with mobility, NAT traversal, etc.

>  > 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.

yes, it may just be 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?

no, you were not clear, but I understand now.

>
>>         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.

yes, I think so.

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.

>  > #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.

nope, not for now.

>  > 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.

We do agree on a number of points. What worries me is that the 
possibility that one might look at the issues we have discussed and 
use that to justify changing existing features of IPsec in order to 
accommodate BTNS functionality. The form of the argument would be 
"... the PAD and SPD model don't accommodate some scenarios where 
address reuse by peers is a near term possibility, so let's change 
them in a way that also addresses problems associated with BTNS ..."

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.

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.

Steve