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].
...
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
