Subject: Re: [IPsec] IPsec maintenance/extensions WG?

From: Joy Latten <[email-masked]>
Date: Tue, 22 Apr 2008 12:21:22 -0500

>At the same time, there has been interest in standardizing small
>improvements and extensions that were not included in the IKEv2
>base specifications (just search for drafts containing "-ikev2-" 
>or "-ipsec-"). Some of those extensions could benefit from wider
>participation that having a working group would bring.
>
>To actually form a WG, we would need to agree on the initial
>charter scope, and have enough people to work on all the items
>we decide to take on. 
>
>My current thinking is that the WG charter should describe a small
>number of specific work items and reasonable timelines for
>completing them, as opposed to including everything related to
>IPsec and planning to have the WG around forever.
>
>To get some discussion started, please send your opinions on 
>whether having a WG would be a good idea, your thoughts on what 
>the charter should look like, and what you'd consider to be the 
>most important work items.
>

I think it is a great idea! 

I have been involved in government certifications 
involving IPsec, in particular LSPP in which we used IPsec
for MAC on network communications, often called "labeled ipsec".
I am in the process of writing internet drafts to extend 
IKEv1 and IKEv2 to include generic security labels.
I would like very much to add this as a work item. 

This may be a moot topic, if so please ignore, but are there any
plans to improve/extend pfkey for ikev2? Just wondering. :-)

Thank you!

regards,
Joy Latten
IBM Linux Technology Center 
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Chinh Nguyen <[email-masked]>
Date: Tue, 22 Apr 2008 15:54:42 -0400

> plans to improve/extend pfkey for ikev2? Just wondering. :-)

There are certainly a number of pfkey issues. For example, linux & bsd 
have slightly different implementation of pfkey. Now, this is a impl. 
issue not a standards issue but it highlights the fact that people are 
wishing to extend pfkey. These extensions typically never made it past 
draft, and have since expired.

A second one is that if you were to attempt to convert an "IKEv2" child 
SA to pfkey format, you will find that there are no IANA numbers 
assigned to the ipsec side for ENCR_NULL_AUTH_AES_GMAC and 
AUTH_AES_[128|192|256]_GMAC 
(http://www.iana.org/assignments/ikev2-parameters). This assumes that 
pfkey is using the values from 
http://www.iana.org/assignments/isakmp-registry, which is true for linux.

Chinh
--
http://www.certicom.com

---

From: Dan McDonald <[email-masked]>
Date: Tue, 22 Apr 2008 16:15:33 -0400

> > plans to improve/extend pfkey for ikev2? Just wondering. :-)

There's been prodding by some to produce PF_KEYv3.  I've had no cycles, but I
do have interest in helping produce a 430x-happy PF_KEYv3.

> draft, and have since expired.

Yes - and the BSD and Linux extensions (based on the KAME/WIDE work) are very
VERY different than, say, the ones produced in what is now OpenSolaris.  When
we opened up OpenSolaris, I blogged about it here:

	http://blogs.sun.com/danmcd/entry/pf_key_in_solaris_or

Part of that divergence is my fault - when I co-wrote 2367, I was fighting
internal IPsec battles at Sun (old-timers on this list know EXACTLY what I'm
talking about).  I didn't consider the needs of an actual KMd writer, and I
was resistant to anything that to my mind would favor IKEv1 vs. another
future KM protocol.  I'd like to think anyone could build JFK, IKEv2, or
anything else on top of PF_KEY, as that was the point of PF_KEY in the first
place.  2367 as published had several weaknesses, which various extension
efforts fixed in their own way.

> http://www.iana.org/assignments/isakmp-registry, which is true for linux.

And what's worse --> IKEv2/430x uses slightly different values than
IKEv1/240x for algorithms like the SHA-2 family.  Check this out:

From http://www.iana.org/assignments/ikev2-parameters  -- we have:

     For Transform Type 3 (Integrity Algorithm), 
     defined Transform IDs are:
     Number    Name                                Reference
     ------    ---------------------------------   ---------
          0    NONE                                [RFC4306]
          1    AUTH_HMAC_MD5_96                    [RFC2403]
          2    AUTH_HMAC_SHA1_96                   [RFC2404]
          3    AUTH_DES_MAC                        [RFC4306]
          4    AUTH_KPDK_MD5                       [RFC1826]
          5    AUTH_AES_XCBC_96                    [RFC3566]
          6    AUTH_HMAC_MD5_128                   [RFC4595]
          7    AUTH_HMAC_SHA1_160                  [RFC4595]
          8    AUTH_AES_CMAC_96                    [RFC4494]
          9    AUTH_AES_128_GMAC                   [RFC4543]
         10    AUTH_AES_192_GMAC                   [RFC4543]
         11    AUTH_AES_256_GMAC                   [RFC4543]
         12    AUTH_HMAC_SHA2_256_128              [RFC4868]
         13    AUTH_HMAC_SHA2_384_192              [RFC4868]
         14    AUTH_HMAC_SHA2_512_256              [RFC4868]

But from RFC 4868 we have:

   For IKE Phase 2 negotiations, IANA has assigned the following
   authentication algorithm identifiers:

   HMAC-SHA2-256:  5

   HMAC-SHA2-384:  6

   HMAC-SHA2-512:  7

So it's DIFFERENT between IKEv1 and IKEv2, and we really would like to keep
PF_KEY independent, yet optimized.  This used to be simple, now it's quite
hard.  OpenSolaris uses 5-7 for SHA2 in PF_KEY, but when we switch to a fully
430x-happy IPsec, we need to consider what to do.

There are two distinct PF_KEY lists too,  the original one --
[email-masked] (Bcc:ing the keeper of that list), and one on vpnc.org.

I think PF_KEY falls outside this or any followup IETF group -- after all the
IETF isn't supposed to do APIs last time I checked.  OTOH, there's plenty of
fertile ground for feedback into PF_KEYv3.  As I'm learning the hard way how
much two implementations have diverged (I'm bringing up racoon2 on
OpenSolaris) - I believe there's an opportunity to get it right.  I just hope
it doesn't get bloated beyond usability.

Dan

---

From: "balaji raghavan" <[email-masked]>
Date: Wed, 23 Apr 2008 09:42:49 +0200

To flog the dead(?) horse once more ... :)

The effects of ESP(v3) and AH updates( RFC 4302 and RFC 4303) , for
example ESN and TFC enhancements on Pfkey have to be also considered
.. Though RFC 4718 does clarify the effects of these enhancements on
IKEv2 operation it does leave out pfkey related matters.

Although i do agree that the pfkey API specification does fall out of
the scope of IETF,  for the sake of interop doesn't it atleast warrant
mention in the WG forum ?

-Regards
Balaji