Subject: Re: [IPsec] [ipsecme] #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3?

From: "Frankel, Sheila E." <[email-masked]>
Date: Tue, 27 Oct 2009 11:39:17 -0400

#111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3?

Proposed changes to Roadmap doc:

1) Add text to section 5.4 (Combined Mode Algorithms)

Current text:
   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. [RFC4306] 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.

Additional text:
   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. Since combined mode algorithms are not a feature of IPsec-v2, 
   these IKEv1 implementations are used in conjunction with IPsec-v3.  IANA
   numbers for combined mode algorithms have been added to the IKEv1 registry.

2) Change IKEv2 and IPsec-v2 requirement levels

	Requirements levels for AES-GMAC:
		old IKEv2 - optional
		new IKEv2 - optional (integrity-protection algorithm)
			    N/A (combined mode algorithm with NULL encryption)
		old IPsec-v2 - undefined (no IANA #)
		new IPsec-v2:
		    AH-v2 - optional (integrity-protection alg)
		    ESP-v2 - N/A (combined mode algorithm with NULL encryption)

3) Move RFC 4543 to section on combined mode algorithms, since it has 2 versions: classic integ prot and also combined mode

________________________________________
From: ipsecme issue tracker [[email-masked]]
Sent: Friday, October 16, 2009 8:10 PM
To: [email-masked]; Frankel, Sheila E.
Subject: [ipsecme] #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3?

#111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3?
-----------------------------------+----------------------------------------
 Reporter:  paul.hoffman@…         |       Owner:  sheila.frankel@…
     Type:  defect                 |      Status:  new
 Priority:  normal                 |   Milestone:
Component:  roadmap                |    Severity:  -
 Keywords:                         |
-----------------------------------+----------------------------------------
 Section 5.4 says:
    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. [RFC4306] 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.
 What about IKEv1? Can you use IKEv1 to negotiate a combined algorithm for
 IPsec-v3?

--
Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/111>
ipsecme <http://tools.ietf.org/ipsecme/>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 28 Oct 2009 13:58:36 +0200

> 1) Add text to section 5.4 (Combined Mode Algorithms)
...
>    numbers for combined mode algorithms have been added to the IKEv1 registry.

That text seems ok.

> 			    N/A (combined mode algorithm with NULL encryption)

IKEv2 SA cannot be used with NULL encryption, so using AES-GMAC
requires some other encryption algorithm when used in IKEv2. AES-GMAC
requires IV and some other encryption algorithm used with it also
requires IV, which means we require two IVs or they require sharing
the IV, which might not be possible as there IV generation rules (and
lengths) might be different.

I do not think it is possible to use AES-GMAC at all to protect IKEv2
traffic, and also it does not make any sense to use AES-GMAC as it
says that it is to be used when no confidentiality is desired, and as
in IKEv2 that is required then AES-GCM should be used instead.

>From RFC5282:
----------------------------------------------------------------------
3.  The Use of AES-GMAC in ESP
...
         If confidentiality is desired, then
   GCM ESP [RFC4106] SHOULD be used instead.
----------------------------------------------------------------------

So I think the correct change is

		       IKEv2 - N/A (IKEv2 requires encryption). 
-- 
[email-masked]