Subject: [IPsec] AES-GCM IV length

From: Scott C Moonen <[email-masked]>
Date: Thu, 13 Aug 2009 14:09:23 -0400

RFC 4106 says:

   The AES-GCM-ESP IV field MUST be eight octets.

NIST publication 800-38D says:

  For IVs, it is recommended that implementations restrict support to
  the length of 96 bits, to promote interoperability, efficiency, and
  simplicity of design.

There are no errata for RFC 4106, so I assume that ESP with 
ENCR-AES_GCM_nn uses an 8-byte IV.  Unfortunately, this goes against the 
NIST recommendation and also prevents the use of the RBG-based IV 
construction method outlined in the NIST document (which requires a 
minimum IV length of 96 bits).

Does anyone have any observations or comments on this?  Is it correct that 
existing ESP AES_GCM implementations are using 128-bit IVs?

Thanks,

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

---

From: "Scott Fluhrer" <[email-masked]>
Date: Thu, 13 Aug 2009 14:35:19 -0400

_____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Scott C Moonen
Sent: Thursday, August 13, 2009 2:09 PM
To: [email-masked]
Subject: [IPsec] AES-GCM IV length

RFC 4106 says: 

See section 4 of RFC 4106: there's also a 4 octet 'salt' which is negotiated
(and fixed for a particular SA); the nonce (IV) that is passed to the
underlying GCM primitive is made of the of the 4 octet salt concatenated
with the 8 byte IV from the packet.  This concatenated nonce is 96 bits in
length, matching the above guideline...

There are no errata for RFC 4106, so I assume that ESP with ENCR-AES_GCM_nn
uses an 8-byte IV.  Unfortunately, this goes against the NIST recommendation
and also prevents the use of the RBG-based IV construction method outlined
in the NIST document (which requires a minimum IV length of 96 bits). 

If they are, they are not following RFC 4106...

Thanks, 

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
 <http://scott.andstuff.org/> http://scott.andstuff.org/
 <http://www.linkedin.com/in/smoonen> http://www.linkedin.com/in/smoonen

---

From: Andreas Steffen <[email-masked]>
Date: Thu, 13 Aug 2009 20:46:41 +0200

Yes, this is correct: 4 octets of salt are derived the IKEv2 SKEYSEED,
so they don't have to be transmitted and 8 octets is the size of the
actual IV prepended to the encrypted ESP payload. Together with the
4 octet counter a 128 bit block input is formed for the AES block
cipher using the 128 bit output as a stream cipher.

Regards

Andreas

Scott Fluhrer wrote:
>  
> 
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Scott C Moonen
>     *Sent:* Thursday, August 13, 2009 2:09 PM
>     *To:* [email-masked]
>     *Subject:* [IPsec] AES-GCM IV length
> 
> 
>     RFC 4106 says:
> 
> See section 4 of RFC 4106: there's also a 4 octet 'salt' which is
> negotiated (and fixed for a particular SA); the nonce (IV) that is
> passed to the underlying GCM primitive is made of the of the 4 octet
> salt concatenated with the 8 byte IV from the packet.  This concatenated
> nonce is 96 bits in length, matching the above guideline...
> 
>      
> 
>     ENCR-AES_GCM_nn uses an 8-byte IV.  Unfortunately, this goes against
>     the NIST recommendation and also prevents the use of the RBG-based
>     IV construction method outlined in the NIST document (which requires
>     a minimum IV length of 96 bits).
> 
>     Does anyone have any observations or comments on this?  Is it
>     correct that existing ESP AES_GCM implementations are using 128-bit
>     IVs? 
> 

======================================================================
Andreas Steffen                         [email-masked]
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==