Subject: [anonsec] Milestone to be filled: Decision on whether SPD/PAD extensions are needed

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Fri, 29 Apr 2005 16:16:29 +0300

Folks,

According to our charter we should soon make a decision
whether SPD and/or PAD extensions are likely to be needed
in order to implement the purported BTNS functionality
(which of course, is still to be defined).  The purpose
of this decision is to make sure that we don't initiate
unnecessary work, and on the other hand, if the work is
indeed needed, make sure that we do initiate the work.

Now, based on my fresh reading of rfc2401bis, to me it
seems that most of what we will technically need are already
there in the form of "name" selectors.  What may be missing
is linking back inbound SAs to names, a question which I
(partially) asked in the other mail, cross-posted and
directed to the IPsec WG ML.

However, there seems to be also some problematic
normative text, especially the last paragraph of
Section 4.4.3.4:

>    Note that because the PAD is checked before searching for an SPD
>    entry, this safeguard protects an initiator against spoofing 
> attacks.
>    For example, assume that IKE A receives an outbound packet destined
>    for IP address X, a host served by a security gateway. RFC 2401 and
>    2401bis do not specify how A determines the address of the IKE peer
>    serving X. However, any peer contacted by A as the presumed
>    representative for X must be registered in the PAD in order to allow
>    the IKE exchange to be authenticated. Moreover, when the
>    authenticated peer asserts that it represents X in its traffic
>    selector exchange, the PAD will be consulted to determine if the 
> peer
>    in question is authorized to represent X. Thus the PAD provides a
>    binding of address ranges (or name sub-spaces) to peers, to counter
>    such attacks.

Now, if I understand the situation correctly, in BTNS
we want to support a situation where peer need not be
authorised to represent X.  On the other hand, we want to
make sure that at the given configuration nobody else (i.e.
no other PAD/SPD entry) can claim authority over X.

Other than that, it looks to me that we may need to have

  a) ordering rules for correlated PAD/SPD entries, stating that
     specific BTNS entries MUST be after non-BTNS entries

and

  b) specification of a "generic" or "opportunistic" BTNS
     entry for SPD/PAD

Opinions?  Especially, what am I missing or misunderstanding?

--Pekka

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 29 Apr 2005 08:33:31 -0500

I wrote an I-D a while back that I just haven't published -- I'll
publish it today, as a personal submission.  It deals with BTNS in BITS
mode only, not native mode -- I thought it best to start small.

It does involve some such PAD extensions, as you'll see, though only to
specify for which addresses BTNS is OK.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 29 Apr 2005 12:07:26 -0500

> specify for which addresses BTNS is OK.

Until the I-D appears in the I-D repository you can find a copy here:

http://blogs.sun.com/roller/resources/nico/williams-unauth-ike.txt

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 29 Apr 2005 13:12:08 -0700

> no other PAD/SPD entry) can claim authority over X.

I'm not clear on that; BTNS means you're not authorized to represent X;
it also means that whatever you say you're representing (e.g., X) is
irrelevant, IMO.

If we restrict BTNS as above, it means that once a host uses
conventional authorization, _that host_ can't use BTNS for other
associations (e.g., other ports).

Unless, of course, X includes the full policy, in which case this just
means that policies don't collide, which is understood (and assumed, I
would hope).

> _______________________________________________