Subject: [IPsec] IANA allocations for combined mode ciphers and IKEv1.

From: Tero Kivinen <[email-masked]>
Date: Thu, 31 Mar 2011 17:54:04 +0300

In early 2009 there was discussion in the IPsec list that the RFC4543
was supposed to allocate numbers also for IKEv1, not only for IKEv2.
There was some discussion on the list and then there was errata 1821
was submitted to the RFC4543 which said those numbers should also be
allocated for the IKEv1 IANA registry. At that point we didn't really
realize that ESPv2 which is implied by using IKEv1 does not support
combined mode ciphers.

In the end of 2009 we started to discuss about the IPsec roadmap
document, and then this item came out again. We had open ticket #111
(http://tools.ietf.org/wg/ipsecme/trac/ticket/111) about the issue and
the final wording in the roadmap (now RFC6071) document was:

----------------------------------------------------------------------
5.4.  Combined Mode Algorithms

   IKEv1 and ESP-v2 use separate algorithms to provide encryption and
   integrity protection, and IKEv1 can negotiate different combinations
   of algorithms for different SAs.  In ESP-v3, a new class of
   algorithms was introduced, in which a single algorithm can provide
   both encryption and integrity protection.  [RFC5996] describes how
   IKEv2 can negotiate combined mode algorithms to be used in ESP-v3
   SAs.  [RFC5282] adds that capability to IKEv2, enabling IKEv2 to
   negotiate and use combined mode algorithms for its own traffic.  When
   properly designed, these algorithms can provide increased efficiency
   in both implementation and execution.

   Although ESP-v2 did not originally include combined mode algorithms,
   some IKEv1 implementations have added the capability to negotiate
   combined mode algorithms for use in IPsec SAs; these implementations
   do not include the capability to use combined mode algorithms to
   protect IKE SAs.  IANA numbers for combined mode algorithms have been
   added to the IKEv1 registry.

5.4.1.  RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with
        IPsec Encapsulating Security Payload (ESP) (S, December 2005)
...
   Requirement levels for AES-CCM:

     IKEv1 - N/A
     IKEv2 - optional
     ESP-v2 - N/A
     ESP-v3 - optional [RFC4835]

   NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but
   combined mode algorithms are not a feature of IPsec-v2.  Although
   some IKEv1/IPsec-v2 implementations include this capability (see
   Section 5.4), it is not part of the protocol.

5.4.2.  RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec
        Encapsulating Security Payload (ESP) (S, June 2005)
...
   Requirement levels for AES-GCM:

     IKEv1 - N/A
     IKEv2 - optional
     ESP-v2 - N/A
     ESP-v3 - optional [RFC4835]

   NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but
   combined mode algorithms are not a feature of IPsec-v2.  Although
   some IKEv1/IPsec-v2 implementations include this capability (see
   Section 5.4), it is not part of the protocol.

5.4.3.  RFC 4543, The Use of Galois Message Authentication Code (GMAC)
        in IPsec ESP and AH (S, May 2006)
...
   Requirement levels for AES-GMAC:

     IKEv1 - N/A
     IKEv2 - N/A
     IPsec-v2 - N/A
     IPsec-v3 - optional

   NOTE: The IPsec-v2 IANA registry includes values for AES-GMAC, but
   combined mode algorithms are not a feature of IPsec-v2.  Although
   some IKEv1/IPsec-v2 implementations include this capability (see
   Section 5.4), it is not part of the protocol.
----------------------------------------------------------------------

Listing all those combined ciphers as N/A for IPsec-v2.

As I think the RFC6071 do reflect the concensus of the IPsecME
workgroup, and because of this I think we should fix the IANA
allocations for the combined mode ciphers (this includes AES-CCM
(RFC4835), AES-GCM (RFC4835) and AES-GMAC (RFC4543)) and change them
to be RESERVED and add note that they are not really part of IKEv1
protocol.

This whole issue comes mostly because there is no version number in
the ESP, meaning only way to know whether ESPv2 or ESPv3 is used is by
implying that from whether IKEv1 or IKEv2 was used (which do have
version numbers).

This affects following IANA entries in the isakmp-registry
(http://www.iana.org/assignments/isakmp-registry):

----------------------------------------------------------------------
IPSEC ESP Transform Identifiers
===============================

Transform ID         Value              Reference
------------         -----              ---------
ESP_AES-CCM_8           14              [RFC4309]
ESP_AES-CCM_12          15              [RFC4309]
ESP_AES-CCM_16          16              [RFC4309]
ESP_AES-GCM_8           18              [RFC4106]
ESP_AES-GCM_12          19              [RFC4106]
ESP_AES-GCM_16          20              [RFC4106]
ESP_NULL_AUTH_AES-GMAC  23              [RFC4543][Errata1821]

IPSEC AH Transform Identifiers
==============================

Transform ID       Value        Reference
------------       -----        ---------
AH_AES-128-GMAC       11        [RFC4543][Errata1821]
AH_AES-192-GMAC       12        [RFC4543][Errata1821]
AH_AES-256-GMAC       13        [RFC4543][Errata1821]

IPSEC Security Association Attributes
=====================================

  Authentication Algorithm

    Name                   Value           Reference
    ----                   -----           ---------
    AES-128-GMAC           11              [RFC4543][Errata1821]
    AES-192-GMAC           12              [RFC4543][Errata1821]
    AES-256-GMAC           13              [RFC4543][Errata1821]
----------------------------------------------------------------------

I am not really sure what should be done for the AH transform
identifiers, as I think the AH_AES-*-GMAC can actually be used without
problems in the IPsec-v2 AH, but I am not sure.

We have few options:

1) Leave things as they are as this is only for obsoleted protocol
   that nobody uses...

   Unfortunately there are still people using this obsoleted protocol
   and if the numbers are there in the IANA registry as they are now,
   some implementors might think they can actually implement and then
   they do end up mixed mode version of IPsec-v2 and IPsec-v3.

2) Change all those entries to be "RESERVED (was xxx)" and add note
   saying that they are not really a feature of IPsec-v2 and even when
   there is implementations using them that is not standard way to do
   it. If those algorithms is needed then ESPv3 (and IKEv2, and
   RFC4301 architecture) is needed.

3) Change ESP entries to "RESERVED (was xxx)" and add similar note
   than in 2, but leave AH entries intact.

I think the option 2 is the best, i.e clearly mark them that you
should not do this, but if you see these numbers you do know that it
is some implementation using some wierd mixed IPsec-v2 / v3 feature
set.
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Thu, 31 Mar 2011 11:07:27 -0400

Tero, the existence of RFC 4304 represents an even more direct way in which
ESPv3 and AHv3 have leaked into IKEv1.

I'm inclined to take your option 1, though I would quibble with "nobody
uses." :) Considering both ESN and combined-mode algorithms, it seems that
in practice we have general agreement that it is legitimate for two IKEv1
implementations to mutually agree to use ESPv3 and AHv3 without importing
all of IPsec-v3.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:	Tero Kivinen <[email-masked]>
To:	[email-masked]
Date:	03/31/2011 10:54 AM
Subject:	[IPsec] IANA allocations for combined mode ciphers and IKEv1.
Sent by:	[email-masked]

     IKEv1 - N/A
     IKEv2 - optional
     ESP-v2 - N/A

     IKEv1 - N/A
     IKEv2 - optional
     ESP-v2 - N/A

     IKEv1 - N/A
     IKEv2 - N/A
     IPsec-v2 - N/A
     IPsec-v3 - optional

  Authentication Algorithm

    Name                   Value           Reference
    ----                   -----           ---------

We have few options:

I think the option 2 is the best, i.e clearly mark them that you
should not do this, but if you see these numbers you do know that it
is some implementation using some wierd mixed IPsec-v2 / v3 feature
set.
--
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 31 Mar 2011 18:19:26 +0300

> ESPv3 and AHv3 have leaked into IKEv1.

True. On the other hand that is feature that is explictly negotiated
in the IKEv1, which only enables the one specific feature of the ESPv3
to the IKEv1 and IPsec-v2. If you use that option, I do not expect
that you are allowed to use traffic flow confidentiality even if you
send that option.

And we did make our mind when we decided to have the current wording
on the RFC6071. 

> implementations to mutually agree to use ESPv3 and AHv3 without importing

Which features of IPsec-v3 is imported? Do using any of the features
from the ESPv3 mean that all features of ESPv3 are available. Do we
take any changes from the RFC4301 too?

Perhaps we have 4th option, i.e. just add note saying that this is not
really feature which should be used here as it is only defined for
ESPv3. Or at least mark those ciphers separately which require (and
perhaps imply) ESPv3. But do to that I would really need more text
than what would be useful in the IANA footnote, and having new RFC for
obsolete IKEv1 would be quite useless...
-- 
[email-masked]