1

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-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?

John Lawrence Aspden
  • 17,124
  • 11
  • 67
  • 110

4 Answers4

2

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
Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
  • 1
    Thanks, that sounds deeply plausible. It's actually the opposite of what I thought was the obvious answer ("yes"). I wonder if it's actually specified anywhere? – John Lawrence Aspden Oct 11 '11 at 09:57
  • For AES-GCM ESP, the ESP IV is not exactly the same as the GCM's IV (or "nonce"). So what you pass as "IV" into the GCM algorithm should actually be "SA salt contatenated with ESP IV". Only the ESP IV is regenerated for each packet, salt is constant for SA. – salicideblock Jan 25 '17 at 16:05
1

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

user1967795
  • 11
  • 1
1

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.

Community
  • 1
  • 1
salicideblock
  • 388
  • 3
  • 8
0

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.

Community
  • 1
  • 1
John Lawrence Aspden
  • 17,124
  • 11
  • 67
  • 110
  • Actually, no: The initialization vector is a **separate input** to the GMAC (or GCM) mode, not a part of the *additional authenticated data*. So it somehow is authenticated (as changing the initialization vector will give different results), but it is not part of the AAD input. – Paŭlo Ebermann Oct 11 '11 at 14:31
  • Paulo, thanks for your trouble, I'm a bit new to this and appreciate the help. Figure 4 in rfc 4543 looks to me like it's telling me to put the iv in the AAD. I'm figuring that AES-GCM still needs an IV even if it's not encrypting, so it seems that in the GMAC case it's going in twice. Which looks like a security horror to me, but then IANAC. Am I reading it wrong? – John Lawrence Aspden Oct 11 '11 at 16:46
  • Huh. Figure 4 is misleading in this respect, I think. Figure 3, on the other hand, clearly shows that the IV is not included in the AAD. – Paŭlo Ebermann Oct 11 '11 at 17:48
  • One of them is misleading, certainly. Figure 3 seems not to include the IV at all. But section 7 seems to vote with figure 4. – John Lawrence Aspden Oct 11 '11 at 18:09
  • Okay, I now have to say I'm not sure anymore. There is [an erratum about section 7](http://www.rfc-editor.org/errata_search.php?eid=62), which also seems to indicate that figure 4 is right. Try it out and see which version interoperates with other implementations? – Paŭlo Ebermann Oct 11 '11 at 19:50