Subject: [anonsec] what kind of phase 2 SAs are we negotiating?

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Wed, 1 Jun 2005 15:34:36 +0300

>> On Fri, May 27, 2005 at 12:59:12PM +0300, Pekka Nikander wrote:
>>> Given that we are likely to move to an environment where
>>> the IP addresses are likely to be quite ephemeral, IMHO
>>> there is strong architectural reasons to annotate the
>>> incoming IPsec-protected IP packets with the SA, and even
>>> have back-pointers from the SA to the relevant SPD and PAD
>>> entries.

> On Fri, May 27, 2005 at 10:22:46AM -0500, Nicolas Williams wrote:
>> I agree, but this won't make the two-nodes-behind-the-same-NAT problem
>> that Michael brings up go away as the PAD entry on the server, in that
>> case, is for the NAT address, not for the address behind the NAT, so
>> we'd have to fix the PAD to be NAT aware.  Sigh.

Hmm.  I don't see any immediate reason why an already existing
PAD entry couldn't be "NAT aware" already, but maybe I am missing
something here (and see also below).  That is, if you index the
PAD entries by the identity, i.e., the public key or self signed
cert in the BTNS case, couldn't there easily be several PAD entries
with child SAs that have overlapping IP address (ranges)?  Sure,
there might be practical difficulties in creating and maintaining
the corresponding SPD entries for outgoing child SA traffic,
especially in the case of BIT* implementations.  Especially, packets
that are sent to a new port at the remote IP address are likely
to go to a wrong host or nowhere at all, but that is nothing new
with NATs.  That would happen even if you did not use IPsec.

On May 27, 2005, at 18:29, Nicolas Williams wrote:
> And note that there is a compatibility/authorization problem here.
>
> Suppose I have an application that uses KAME's IP_POLICY socket option
> and assumes that the IP addresses of connected sockets with that option
> set have been strongly authenticated and so it does authorization 
> checks
> based on IP addresses?

I would argue that such an application would be fundamentally flawed.
If it did use socket options to gain authentication/authorisation
information, it should not automatically assume that other sockets
bound to the same IP address *necessarily* share the same authorisation
information.  Even if there was no NATs, there may be per-port SPD 
entries
making the assumption wrong.  Hence, I would be tended to claim that
such an application would not conform to the IPsec architecture,
but maybe I'm wrong here.

> I don't know of any such applications, but, do none such exist?

Neither do I know any such applications...

--Pekka

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 1 Jun 2005 10:59:28 -0500

On Wed, Jun 01, 2005 at 03:34:36PM +0300, Pekka Nikander wrote:
> with child SAs that have overlapping IP address (ranges)?  [...]

Ah, yes, non-IP address IDs are allowed as indexes.

> I would argue that such an application would be fundamentally flawed.

So would I.  The question is though, do such applications exist and did
they every have a hope of being reasonably secure modulo policy
configuration?

If the answer is yes to both parts of that question then we have to
consider backwards compatibility, though we can probably handle that as
a security consideration, something like "don't turn this on if you know
it would break an application with flawed assumptions about IPsec."

> but maybe I'm wrong here.

I agree, but such an application could be relying on local policy
configuration to ensure the behaviour that the application expects.

> Neither do I know any such applications...

Good.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 13 Jun 2005 17:46:49 -0400

>with NATs.  That would happen even if you did not use IPsec.

In 2401bis, PAD entries are "indexed" by IKE ID. if we use raw keys 
as IKE IDs, then that fits the current model as well. certs do not 
seem to be appropriate as an IKE ID form, as they are complex objects 
with a lot of elements. the PAD specifies how to match an IKE ID 
against a cert if certs are used. one can easily use the public key 
from a cert as ID and carry a cert if one believes that this 
represents a useful way to transfer additional info.

If we use keys as IKE IDs only for BTNS, that offers the opportunity 
to separate the PAD into authenticated entries vs. unauthenticated 
entries. The advantage is that one might adopt a simple policy of 
never accepting an assertion about an address for a child SA for an 
unauthenticated entry, if ANY authenticated entry already has the 
same address as its ID, or that has an address range for child SAs 
that covers the address in question. That would make it relatively 
easy to avoid undermining the existing access controls that rely on 
the PAD to keep different peers from asserting that they represent 
the one another's address spaces.

In the current PAD design, multiple PAD entries would have 
overlapping address ranges (for child SAs) only if the local admin 
(e.g., a user) configured them that way. Such configuration would 
reflect the local admin's belief that the different peers 
legitimately represented the same or overlapping address blocks.

Steve

---

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Wed, 15 Jun 2005 19:16:01 +0200

> represents a useful way to transfer additional info.

I like the idea of using public keys as identities a lot.
In fact, I've had this preference for quite a long time. :-)

> the one another's address spaces.

This looks like a good starting point for me.  However, I'd
appreciate if we could also study how to go further, and create
an ability to dynamically build PAD and SPD entries based on
"experience".  That is, when using BTNS for the first time with
a given peer key, the system may have the ability to store the
key and prefer that key to keys with no prior experience when
opening a connection for the next time.  That is not a simple
problem, I know, but I also believe that such approach may have
long term architectural value.  Basically, it may pave way towards
an architecture where we are using keys instead of IP addresses
as the primary security-meaningful low-level identifiers.
(With low-level I mean IP layer and possibly other layers
that are clearly "below" the application logic.)

> legitimately represented the same or overlapping address blocks.

Agreed.

--Pekka

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 15 Jun 2005 17:43:43 -0400

Pekka,

>...

yes, but in this case we're explicitly dealing with unauthenticated 
peers, so it makes more sense than in some other cases :-)

>that are clearly "below" the application logic.)

I understand your interest in the expanded functionality this would 
provide, since it is supportive of HIP. But HIP is not the focus of 
this WG, so a rationale of why this functionality is required to meet 
BTNS requirements is needed.

Steve