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 protected] [mailto:[email protected]] *On
>     Behalf Of *Scott C Moonen
>     *Sent:* Thursday, August 13, 2009 2:09 PM
>     *To:* [email protected]
>     *Subject:* [IPsec] AES-GCM IV length
> 
> 
>     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. 
> 
> 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).
> 
>     Does anyone have any observations or comments on this?  Is it
>     correct that existing ESP AES_GCM implementations are using 128-bit
>     IVs? 
> 
> If they are, they are not following RFC 4106...
> 
>      
> 
>     Thanks,
> 
> 
>     Scott Moonen ([email protected])
>     z/OS Communications Server TCP/IP Development
>     http://scott.andstuff.org/
>     http://www.linkedin.com/in/smoonen

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

Reply via email to