Subject: Some architectural thoughts about AH in SEND

From: Pekka Nikander <[email-masked]>
Date: Sun, 15 Jun 2003 18:08:05 +0300

Continuing my thinking in the proposal about separating
CGA from AH, partly basing on Ran's comments from our
discussion at the SAAG ML.

Let me consider a situation where we have a public
key based AH with the following properties:

   - there is a separate SA for each public key
   - at the receiver end, the correct SA is selected
     based on a fixed SPI and a source address
   - other than that, the SAs are pretty standard,
     i.e. have lifetime etc.

In effect, we would have an AH mode that can use
AHbis SPD entries, with the difference that the
SA selection is based on the source address (and SPI).
However, SA selection based on SPI and source address
is already *almost* supported in AHbis; the modifications
would be minimal and perhaps we can justify them within
the remaining AHbis WC LC time.

Let us further suppose that we have a public key based
KMP that basically associates an IP address with a
public key, effectively creating a separate AH SA
for each IP address.  The SA would have the properties
outlined above, and selected based on the source address.

There could be two versions of such KMP:

   - a CGA based version "inline" version, creating an
     SA after as a part of the process of verifying
     a CGA extension header

   - a certificate based version, where a host creates an SA
     after receiving and verifying a chain of certificates,
     rooted on a trusted party and ending in an association
     between an IP addressa and a public key.

The basic difference between the two methods are in
the authorization implied by the SAs.  In the CGA case the
only assurance we have is that it is computationally hard
to create another public key that maps to the IP address.
In the certificate case the assurance flows from the
trusted party, and depends on its certification policy.

Returning to SEND, in the CGA case we would have a
three stage process for processing incoming packets:

   - create an AH SA based on the CGA extension header
   - verify the signature in the AH header, using the
     newly created SA
   - process the ND payload, with assurance that the
     source IP address is associated with a public key,
     and the public key was used in signing the packet,
     and it is unlikely that there exists currently
     another node in the link that uses a different
     public key but wants to use the same IP address

I believe that this is functionally equivalent to the
current method, but I haven't checked the details.

In the certificate case, the process would be distributed
over time, into two steps:

   - initially, the node sends a query for certificates,
     receives some, and creates the AH SA based on the
     certificates,
   - later on, the node receives a packet, and verifies
     the signature in the AH header, using the SA
     created ealier
   - process the ND payload, with assurance the is based
     on the contents of the certificates, and recorded
     in the SA.

If it is undesirable to record authorization information
into the SA, it is even possible to record the router
capabilities and other certificate based information
into a separate ND level data structure, indexed by
the source IP address and valid if and only if the
packet has been properly authenticated earlier on.

I think that this design could cleanly separate the
various aspects of CGA, certificates, header integrity
and data origin authentication, and ND based authorization.
It even allows further capabilities, such as caching
CGA based SAs, querying for CGA/cert based SAs, etc.
We could also use a separate SPI for CGA and certificate
based authentication, if needed.

Thoughts?

--Pekka Nikander

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Mon, 16 Jun 2003 15:30:06 -0700

I like the idea of using a separate CGA header, though we need to make
sure it works well on Linux. I particularly like the idea of having
two SPIs, one for CGA and another for trusted roots. They always

>      on the contents of the certificates, and recorded

I think the sequence goes something like this:

    - node receives a NS containing an AH header with an unverified IP
address.
    - In the IPsec code, call out to obtain the certificates.
        . Certificate chain found? Return it.
        . No certificate chain found? Use DCS/DCA to find and return.
    - Create IPsec SA based on destination address
        (note we can't use the source address here because the SA can
         have a different chain depending on the chain returned).
    - Process AH header using SA.
    - Process ND payload if AH verifies packet.

I believe the second step is unavoidable for any IPsec SPI that uses
public key and certificates, and is not specific to SEND, but how the
certificates are retrieved if they are not available will differ. In
this case, it is the DCS/DCA, so the SPI becomes specific to SEND.

            jak

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 17 Jun 2003 10:05:37 +0300

> struck me as being separate. However, I have a comment:
...
>     - node receives a NS containing an AH header with an unverified IP

Right.  However, if we use the source address based SA selection,
already the SPD code will notice that there is no SA for the
particular <SPI, source IP address> pair.  The SPD code will
kick the issue up to the user level via PF_KEY.

>         . No certificate chain found? Use DCS/DCA to find and return.

This can be done all at the user level, as a result to the
PF_KEY ACQUIRE generated by the SPD code in the kernel.

The user level code can process the certificates, and once it
finds or is is able to acquire a proper chain, it installs
the new SA with PF_KEY ADD.

>          have a different chain depending on the chain returned).

Hmm.  Why can't we use the source address?  That particular SA
is only at the receiving end, i.e. the SA *instance* is a local
issue.

>     - Process AH header using SA.

Yes.

>     - Process ND payload if AH verifies packet.

There is slightly complication here.  The ND code must also be
aware about the prefixes that the particular node is permitted
to announce.  Fortunately we can use the now-verified source
address as an index, and either query for the permissions from
the user level, or have them cached in the kernel, as a side
result of the previously performed SA creation.

> this case, it is the DCS/DCA, so the SPI becomes specific to SEND.

Agreed.

--Pekka

---

From: Markku Savela <[email-masked]>
Date: Tue, 17 Jun 2003 10:40:05 +0300

> From: Pekka Nikander <[email-masked]>
> > 

Umm.. this is not exactly the way I thought IPSEC works. If incoming
packet requires an SA that does not exist, packet is dropped like a
hot potato. No PFKEY negotiation! I think there would be a DOS
potential, if any incoming random SPI would cause negotiation attempt!
[Although, I may be wrong too, but that's the way the IPSEC version I
know, works]

Only outgoing traffic can initiate key / SA negotiation.

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 17 Jun 2003 11:00:05 +0300

> Only outgoing traffic can initiate key / SA negotiation.

Oops.  Mea culpa.  You are right, of course.  However, the
change to call PF_KEY would be trivial, at least in KAME.
I have to think about the DoS aspects.

--Pekka

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 17 Jun 2003 12:06:21 -0400

> I have to think about the DoS aspects.

similar things are needed under some schemes for detecting lost IPsec
state.

Rate limiting (on both ends of the PF_KEY channel) would be a large
part of any DoS solution.

					- Bill

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Jun 2003 09:41:34 -0700

> is only at the receiving end, i.e. the SA *instance* is a local

Sounds like we can. 

            jak