Subject: Should CGA parameters be a separate header instead of being integrated with AH

From: Pekka Nikander <[email-masked]>
Date: Sun, 15 Jun 2003 12:20:23 +0300

Based our (so far limited) implementation experience, I am
starting to think that perhaps the CGA public key and
parameters should be included in a separate option instead
of being integrated into the AH header.  In this note I will
first briefly explain the current situation, reason for the
suggested situation based on our experienc, and finally my
proposal for a new design.

1. Current design
=================

In draft-ietf-send-ipsec-01.txt, the IPsec AH header is
defined to include the following structure:

   - standard AH headers (Next header, length, SPI, replay counter)
   - timestamp
   - Key Information
   - signature

The Key Information field is defined, using ASN.1, to contain
cgaParameters, including the CGA key, and signerInfo, which
may contain a different key than the CGA key.

2. Why should this be changed
=============================

While implementing the current proposal, we seem to end up
including the CGA information in at least two separate kernel
data structures.  Firstly, we need the have the CGA parameters
field available for CGA address generation.  CGA address generation
is performed, in turn, either when the first link local address
is generated, or when a host is using autoconfiguration and
receives a new routing prefix in an RA.

Secondly, we need to have the CGA parameters field available
when protecting packets with AH.  The reason for this is that the
CGA parameters is included the AH header; otherwise they are not
needed.

Sharing the CGA parameters between AH and address generation
is not exactly trivial.  Typically, address generation is
handled by ND code, controlled with ifconfig(8), and the API
between ifconfig and the ND code is based on ioctl(SIOC[CG]IF).
On the other hand, AH is part of IPsec, controled with setkey(8),
and the API between the user level and kernel is based on PF_KEY.

Thus, if we try to inject the CGA parameters data just once to
the kernel, we get an ugly dependency between two otherwise fairly
independent pieces of code.  Alternatively, we have to pass the
exactly same data twice to the kernel, and typically even with
different user level utilities.

Now, if we separated CGA processing completely from AH processing,
AH should not know about CGA at all.  When sending outbound packets,
the ND stack would include a CGA header, and the IPsec processing
would included it as a part of the IP packet, making sure that
it is located before the AH header (just like HbH options or
Routing Header is).  On the input side, a separate piece of code
(trigged by the next header field) would process the CGA header,
drop the packet if the CGA verification fails, and cache the key
otherwise.  AH would then be able to fetch the key from the cache.

In addition to making the implementation cleaner, the new design
would have another benefit:  It would make CGA independent of AH,
making it possible to use it also with e.g. ESP or HIP.

3. Proposal for a new design
============================

I propose that we move the cga parameters from the AH header to
a separate header, which MUST precede the AH header:

   *------------------------------------------------*
   | IPv6   | CGA    | AH     | ICMPv6 | ND message |
   | Header | Header | Header | Header |            |
   *------------------------------------------------*

The CGA header would include
   - cgaParameters, including
     - auxParameters, just as today
     - publicKey, just as today

The AH header would then include just a hash of the public
key, i.e., a key name.

Furthermore, I would propose that ASN.1 is not used, since
having a full ASN.1 DER parser in kernel code just causes
bloat.  Instead, I propose the following formats for the
new CGA header and revised AH header.

---------------------------------------------------------------------

X. CGA Extension Header format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Next Header   |  Hdr Ext Len  | RES | PAD |CC |  Algorithm    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                            Modifier                           |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                          Public key                           .
    .                      (variable length)                        .
    | 
 
                                                                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Next Header          8-bit selector.  Identifies the type of header
                         immediately following the CGA header.

    Hdr Ext Len          8-bit unsigned integer.  Length of the CGA
                         header in 8-octet units, not including the
                         first 8 octets.

    RESERVED             Reserved for future use.  MUST be set zero
                         by the sender and SHOULD be ignored by the
                         receiver.

    CC                   Collision Count.  As defined in [CGA].

    PAD                  Padding length (in octets).

    Algorithm            Public key algorithm, as defined in Section 3.2
                         in [RFC2535].  All conforming implementations
                         MUST support RSA/MD5.

    Modifier             CGA modifier.  As defined in [CGA].

    Public key           Public key in [RFC2535] format.  For RSA, see
                         [RFC2537].  Padded with zeros, if necessary,
                         so that the header length becomes integral with
                         8-octet units.  The number of padding octets
                         (if any) is indicated by the PAD field.

    Notes:

    - the extension header DOES NOT include the routing prefix, since
      it is implicitly available in the source address.

---------------------------------------------------------------------

7.1.2 Integrity Check Value Format

[Note that AHbis has renamed the Authentication Data field into
  Integrity Check Value.]

    The format of the ICV field in AH depends on the chosen transform.
    For the AH_RSA_Sig transform, the format is as follows:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                          Timestamp                            +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                                                               +
      |                        Key Information                        |
      +                                                               +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .              Digital Signature (remaining bytes)              .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The meaning of the fields is described below:

    Timestamp

       This 64 bit unsigned integer field contains a timestamp used for
       replay protection (the Sequence Number field in AH is not used for
       AH_RSA_Sig).  The use of this field is discussed in Section 7.1.4.

    Key Information

       A 160-bit long SHA-1 hash of the public key.

    Digital Signature

       This variable length field contains the signature made using the
       sender's private key, over the the whole packet as defined by the
       usual AH rules [3].  The signature is made using the RSA algorithm
       and MUST be encoded as private key encryption in PKCS #1 format
       [17].

       The length of this field is determined by the PKCS #1 encoding.

---------------------------------------------------------------------

--------------------------------------------------------------------
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: Pekka Nikander <[email-masked]>
Date: Sun, 15 Jun 2003 13:40:05 +0300

Thinking a little bit more about the proposed change of
separating CGA from AH, I realized that the change would
create an "implicit" KMP.  That is, when the new CGA
layer checks a CGA header and caches the public key,
it effectively creates a new IPsec SA that can be selected
based on the fixed SPI and source address.

Now, AHbis states the following:

    2.4  Security Parameters Index (SPI)

    ... For a unicast
    SA, the SPI can be used by itself to specify an SA, or it may be used
    in conjunction with the IPsec protocol type (in this case AH).

    If an IPsec implementation supports multicast, then it MUST support
    multicast SAs using the following algorithm for mapping inbound IPsec
    datagrams to SAs. ...  Each entry in the
    Security Association Database (SAD) [KA98a] must indicate whether the
    SA lookup makes use of the source and destination IP addresses, in
    addition to the SPI. ...  Nominally, this indication can be
    represented by two bits, one associated with the source IP address
    and the other for the destination IP address. A "1" value for each
    bit indicates the need to match against the corresponding address
    field as part of the SA lookup process. ... (There is no current
    requirement to support SA mapping based
    on the source address but not the destination address, thus one of
    the possible four values is not meaningful.)...

Now, if we employ this new conceptual algorithm from AHbis, and
use it also for unicast traffic, and allow the case where the
source address is meaningful but the destination is not, in the
SA selection, we get the desired behaviour.

Comments?  BTW, AHbis WC LC closes tomorrow (Monday).

--Pekka

---

From: Jari Arkko <[email-masked]>
Date: Sun, 15 Jun 2003 18:31:05 +0300

> and the API between the user level and kernel is based on PF_KEY.

I agree that this can be troublesome. However, while I agree
with you that this could be an issue, I'm not sure I agree with
the proposed solution.

As you know but the rest of the list may not know, I have doubts
about the use of AH vs. "application layer" security in ND options.
If you think the IPsec - ND coordination is troublesome, I would
suggest that we go for ND options instead, with roughly the
same format and functionality as we now have in the Authentication
Data field.

I'm working on a pros-cons analysis and a drafty draft for this
approach, and will post it to the list as soon as possible.

> new CGA header and revised AH header.

Agree with this, though I don't currently see this as a major
problem.

--Jari

---

From: Julien Laganier <[email-masked]>
Date: Sun, 15 Jun 2003 22:17:21 +0200

> same format and functionality as we now have in the Authentication

I like the idea of having a CGA-based KMP interfaced with IPsec that can then 
be used by other protocols than ND (e.g. HIP, CGA-based Opportunistic 
Encryption). As Pekka said, the modifications needed in AH are minimals and 
allows to have an IPsec based SEND. Thus, because the provided mechanisms 
(CGA based-KMP) can probably be reused, if this can avoid us to reinvent the 
wheel yet another time in another situation, IMHO it's worth trying it.

> Agree with this, though I don't currently see this as a major

Being capable of implementing SEND within a low memory fingerprint IPv6 stack 
maybe of considerable interest in the future, so it makes sense to me not to 
require that each SEND-enabled node implement a full ASN.1 parser.

--julien

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Jun 2003 15:19:22 +0300

Pekka, I wanted to ask a clarification... you

> and the API between the user level and kernel is based on PF_KEY.

...

> different user level utilities.

...

> making it possible to use it also with e.g. ESP or HIP.

It is quite easy for me to understand how this works nicely
in the receiving end. But was your original intent to get rid
of passing the data twice to the kernel? The part that I don't
understand is that if the new extension header would be
generally useful, it would have to be outside the ND module,
right? So how do we avoid setting the CGA parameters both to
ND (where the address generation takes place) and to the
new extension header code (which should attach the used CGA
parameters to the packet)? Or is the intent that the ND
module creates the CGA header as well? But then ND would
have to sit in two places in the stack path, before and
after IPsec. Is this what is intended?

--Jari

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 16 Jun 2003 16:16:44 +0300

> It is quite easy for me to understand how this works nicely in the 
> receiving end. But was your original intent to get rid of passing the
> data twice to the kernel? .... Or is the intent that the ND module 
> creates the CGA header as well?

Yes.

> But then ND would have to sit in two places in the stack path, before
> and after IPsec. Is this what is intended?

No.  IPsec will split and splice the packet anyway, since even
in the typical case the packet arrives as a complete packet
to IPsec, which then injects AH or ESP.  Thus, the ND layer can
include the CGA extension header, and IPsec will just neatly
place AH on the right place, between the CGA header and the
ND payload.

--Pekka

---

From: Markku Savela <[email-masked]>
Date: Mon, 16 Jun 2003 16:20:18 +0300

> place AH on the right place, between the CGA header and the

But, then IPSEC needs to "know" the CGA header. Currently, IPSEC knows
about some extension headers (Dest. Opt, Hop By Hop, RTH), and when it
bumps into "unknown", it will splice it's headers before that. (e.g.,
unmodified IPSEC code will put it's headers in front of your proposed
CGA header).

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 16 Jun 2003 16:29:03 +0300

> unmodified IPSEC code will put it's headers in front of your proposed

Yes.  That is a set of two line changes.  Trivial to implement.
In KAME the changes would go to ip6_output.c:ip6_output, plus
the necessary .h files.  Most of those changes you have to do
anyway if you add a new extension header, only about one or two
would be IPsec specific.

--Pekka

---

From: Jonathan Wood <[email-masked]>
Date: Tue, 17 Jun 2003 23:25:03 -0700

On Sunday, June 15, 2003, at 02:20 AM, Pekka Nikander wrote:
> data structures.

I haven't found this to be an implementation issue for me (working
on Linux), so from an implementation standpoint I don't really care.
However...

> making it possible to use it also with e.g. ESP or HIP.

I think this is a pretty compelling argument. I support this proposal.

j

---

From: Greg Daley <[email-masked]>
Date: Wed, 18 Jun 2003 16:27:21 +1000

Hi Johnathan,

> on Linux), so from an implementation standpoint I don't really care.

Sorry if this sounds dumb, but what do you mean
not a problem?

Not a problem to implement.

or:

Not a problem, there's no IPR/GPL clash that I can see.

I think that especially in the case of Linux, the
second issue is not so clear (or clearly not so good).

Greg

---

From: Jonathan Wood <[email-masked]>
Date: Wed, 18 Jun 2003 09:07:52 -0700

> second issue is not so clear (or clearly not so good).

Ah, apologies for the ambiguity - I meant "Not a problem to
implement." I agree that there is potential for trouble on
the latter point you mention.

j

---

From: Julien Laganier <[email-masked]>
Date: Wed, 18 Jun 2003 22:14:04 +0200

Pekka,

Sorry for responding late to this message, but a detail related to your 
proposal come to my mind. More below...

Pekka Nikander wrote:
> (...)
> AH should not know about CGA at all.  

Here you state that CGA processing could be _completely separated_ from AH 
processing, so by 'reflexion' I guess that the CGA header processing would 
not use informations contained in the AH header (please correct me if I 
misunderstood) => CGA should not known about AH at all.

> When sending outbound packets,
> otherwise.

So the CGA layer cache the key before verifying the signature included in the 
AH header.

> AH would then be able to fetch the key from the cache.

And here (in the AH layer) occurs the signature verification.

I suspect that caching (at least) 1024 bits of a Public Key for each received 
CGA-header without verifying signatures (embedded in AH) may be subject to 
DoS attacks on the memory resources containing the PK cache.

On the other hand, you can validate the CGA header by verifying the signature 
embedded in the AH header before populating the new PK in the cache... in 
this case I guess I completely your proposal.

Thanks,
--
Julien Laganier
SUN Microsystems Laboratories

---

From: Julien Laganier <[email-masked]>
Date: Wed, 18 Jun 2003 22:48:43 +0200

Folks,

Following what I was thinking...

> misunderstood) => CGA should not known about AH at all.

Thus not allowing the CGA layer to validate the PK against the RSA signature 
(only against the source IPv6 CGA).

A solution to this problem may be to have the CGA header being signed as well, 
with the corresponding PK.

Thanks,

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 19 Jun 2003 11:05:50 +0300

Julien Laganier wrote:
> Here you state that CGA processing could be _completely separated_
> from AH processing, so by 'reflexion' I guess that the CGA header
> processing would not use informations contained in the AH header
> (please correct me if I misunderstood) => CGA should not known about
> AH at all.

Correct.

> Thus not allowing the CGA layer to validate the PK against the RSA
> signature (only against the source IPv6 CGA).

Correct.  That would have the additional benefit that the CGA payload
could carry any "stuff" that creates a security assocation.  Not just
a public key, but e.g. a hash chain for hash chain based integrity
protection.

> A solution to this problem may be to have the CGA header being signed
> as well, with the corresponding PK.

That would only duplicate functionality and increase packet size.

> I suspect that caching (at least) 1024 bits of a Public Key for each
> received CGA-header without verifying signatures (embedded in AH) may
> be subject to DoS attacks on the memory resources containing the PK
> cache.

Well, that depends on how long you cache the data.  As I have tried
to state, my suggestion is to cache the data only for the duration
of handling the very packet.  Once the packet has been processed,
the SA is deleted.   AFAIK, this does not change the IPsec conceptual
model.  IPsec already now has the ability to define an SA lifetime
in terms of amount of data processed.  Thus, in this case, it is
conceptually possible to define that the SA must be deprecated once
it has processed exactly as much data as there is in the packet.

In implementation terms, the SA can be represented as meta-data
associated with the packet.  That makes fate-sharing between
the SA and the packet very easy.  However, what it does is that
it preserves the IPsec architecture:  you first create an SA
using a KMP, and then you use the SA at the IPsec "layer".

--Pekka Nikander