Here's a little more explanation of this text from RFC 6071: > 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.
It's more than a decision to not include that capability - IKEv1 exchanges cannot be protected with combined mode algorithms without significant incompatible change to IKEv1, as explained in Section 1 of RFC 5282: Version 1 of the Internet Key Exchange protocol (IKEv1) [RFC2409] is based on the Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408]. The E (Encryption) bit in the ISAKMP header specifies that all payloads following the header are encrypted, but any data integrity verification of those payloads is handled by a separate Hash Payload or Signature Payload (see Sections 3.1, 3.11, and 3.12 of [RFC2408]). This separation of encryption from data integrity protection prevents the use of authenticated encryption with IKEv1, thus limiting initial specifications of AES combined mode usage for IPsec to the Encapsulating Security Payload (ESP) [RFC2406]. OTOH, RFC 4106 (GCM), RFC 4309 (CCM), and RFC 4543 (GMAC) were written in a fashion that allowed their use with ESP (RFC 2406) to be negotiated by IKEv1 (and also for AH in the case of GMAC). I would strongly object to removal of the IANA registry entries that support this usage, although I agree that everyone should be using IKEv2 in preference to IKEv1. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Tero Kivinen > Sent: Wednesday, April 06, 2011 7:44 AM > To: Vinod Sasi > Cc: ipsec@ietf.org; 'Scott Fluhrer (sfluhrer)' > Subject: Re: [IPsec] Queries relating to ESP/AH GCM & GMAC > > Vinod Sasi writes: > > Many thanks for your reply; this is helping me to a great extent. > > In the RFC6071 we do note that those combined mode ciphers are not > feature of the old IPsec-v2 set (i.e IKEv1). I would recommend not to > implement them using IKEv1, as there might be quite a lot of > interoperability issues, especially as the documentation how to use > them in IKEv1 is non-existing and different implementations might use > different interpretation how some document text should be applied in > this context. > > The text in the RFC6071 (IPsec Roadmap) says: > > ---------------------------------------------------------------------- > 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.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. > ---------------------------------------------------------------------- > > So unless this feature is really needed for some internal use case, I > would recommend using IKEv2 instead. > > Do not expect this feature to be interoperable with other IPsec > implementations unless you specifically test it. > > > Few more clarifications from your reply.. > > 1.) RFC 4106 talks about Nonce = IV + Salt (last 4 bytes of > > keying material derived during SA creation). But where do we > > actually use it in the context of ESP & AH? I derive the 8-byte IV, > > feed those 8-bytes as input to the GCM Algorithm, take the cipher > > out & prepend it with the same 8-byte IV before sending it out on > > the wire. > > RFC4303 explains how you use combined mode ciphers in the ESPv3. You > cannot use combined mode ciphers in the RFC2406 implementations. > > > 2.) Between ESP GMAC & AH GMAC. Please confirm my understanding. > > You mean RFC4543? > > > a. Plain_text=Zero for both > > b. AAD constructed accordingly for ESP & AH outlined in RFC 4303 & > > 4302 > > The AAD is constructed as specified in RFC4543 section 3.3 > > > c. 8-byte IV is fed to GMAC algorithm for ESP & AH. > > Yes. > > > d. Before being sent over the wire, for ESP the IV is > > prepended with the actually payload (IP/TCP/UDP). For AH the IV is > > prepended with the ICV tag. > > In the ESP the IV is stored in the IV field of the RFC 4303 section 2. > > In the AH the IV is part of the ICV field of the RFC4302 section 2 and > the construction of the ICV field is specified in the RFC4543 section > 4. > > > e. Both have fixed ICV lengths > > No. RFC4106 has 3 different ICV lengths. RFC4543 has only one. > > > 3.) Between GCM & GMAC algorithm, only difference being for GMAC the > > plain_text=zero. So technically a GCM Algorithm code will act as > > GMAC is my actually payload length provided as input is zero. > > RFC4543 says section 3.5 says: > > ---------------------------------------------------------------------- > 3.5. Differences with AES-GCM-ESP > > In this section, we highlight the differences between this > specification and AES-GCM-ESP [RFC4106]. The essential difference is > that in this document, the AAD consists of the SPI, Sequence Number, > and ESP Payload, and the AES-GCM plaintext is zero-length, while in > AES-GCM-ESP, the AAD consists only of the SPI and Sequence Number, > and the AES-GCM plaintext consists of the ESP Payload. These > differences are illustrated in Figure 4. This figure shows the case > in which the Extended Sequence Number option is not used. When that > option is exercised, the Sequence Number field in the figure would be > replaced with the Extended Sequence Number. > > Importantly, ENCR_NULL_AUTH_AES_GMAC is *not* equivalent to AES-GCM- > ESP with encryption "turned off". However, the ICV computations > performed in both cases are similar because of the structure of the > GHASH function [GCM]. > ... > -- > kivi...@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
