should you authenticate the initialization vector in ipsec?

I'm trying to implement IPSEC in the form of ESP in transport mode with using aes in galois/counter mode, according to RFC4106.

I'm supposed to put the initialization vector just before the ciphertext in the transformed packet.

Should it be part of the authenticated (but non开发者_Go百科-encrypted) data? (I'm assuming that you don't encrypt it...)

I can't see where the RFC specifies this. Should it be obvious and if so why?

---

As far as I understand the GCM definition, there is no need to include the initialization vector in the associated data - using different initialization vectors will give both different encryption results as well as different integrity check value anyway.

This is the advantage of using a combined authenticated-encryption mode, you don't have to care about including initialization vectors in the MAC.

So, to encode a packet for ESP with GCM, you do this:

• fetch the key
• generate the IV
• calculate the associated data (from SPI and sequence number)
• get the plaintext
• pass IV, associated data, key, plaintext to the GCM algorithm
• get ciphertext and ICV from the GCM algorithm
• send IV, ciphertext and ICV

---

For AES-GCM-ESP, IV (esp iv of 8bytes) is not part of AAD. AAD is just the ESP header. Note that IV which is passed to AES_GCM is the concatenation of salt(fourbytes) + iv(esp iv of 8bytes). Some hw crypto engines take IV as 16bytes in which case you need to pad the last four bytes to be 0x0.

Check this doc , it is pretty neat http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-revised-spec.pdf

---

No, you shouldn't.

Should it be obvious? Normally yes. Many of the other RFCs for ESP mechanisms include test vectors to dispel this kind of questions. RFC4106 doesn't. This was noticed during discussion but they did not make it to the text: https://www.ietf.org/mail-archive/text/ipsec/2005-08.mail

There is a draft document with test vectors, though: https://datatracker.ietf.org/doc/html/draft-mcgrew-gcm-test-01 . You will notice that the IV (bytes 4-11 of the "nonce", 4956ed... in the first example) are included cleartext in the packet data. They are not included in the "plaintext" nor in the "aad", which is the total of the data authenticated by the GCM cipher.

Consider also that the IV to the GCM cipher itself is a concatenation of the salt and the ESP IV - called "nonce" to avoid ambiguity. The salt is obtained from the key material negotiated during IKE, so it's agreed between both endpoints and constant for the SA lifetime.

---

Apparently both of the obvious answers are right.

According to RFC 4543 which specifies ENCR_NULL_AUTH_AES_GMAC (authentication without encryption), you include the IV.

However the same RFC says that for AES-GCM-ESP (encryption and authentication), you don't.

Armed with this information, it's now clear that that's what RFC 4106 (which actually specifies AES-GCM-ESP) says as well, although that wasn't how I interpreted it at first.