IKEv2 IPsec proposal AES-GCM-256 encryption requires NULL for the Integrity algorithm

Jose Borquez · ‎06-13-2016

Can someone please explain why the asa documentation requires when using AES-GCM for a site-to-site IPsec VPN that the integrity hash selected must be NULL? Thank you in advanced for any explanation.

Jose

Karsten Iwen · ‎06-13-2016

GCM is an authenticated encryption. That means that all what was done previously with the HMAC, is directly done while encrypting the packet. An additional HMAC is not needed any more.

Jerome BERTHIER · ‎07-19-2022

Hello Jose

Please take a look on this documentation :

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_ike2vpn/configuration/xe-16-8/sec-flex-vpn-xe-16-8-book/sec-cfg-ikev2-flex.pdf

It explains AES-GCM Support :
"An authenticated encryption algorithm provides a combined functionality of encryption and integrity. Such
algorithms are called combined mode algorithms. The Support of AES-GCM as an IKEv2 Cipher on IOS
feature provides the use of authenticated encryption algorithms for encrypted messages in IKEv2 protocol by
adding the Advanced Encryption Standard in Galois/Counter Mode (AES-GCM). AES-GCM supports the
key size of 128- and 256-bits—AES-GCM-128 and AES-GCM-256.
If AES-GCM is the only encryption algorithm, integrity algorithms cannot be added to the proposal."

Regards

MHM Cisco World · ‎07-19-2022

I think it Bug

https://bst.cisco.com/bugsearch/bug/CSCuy93295

will · ‎08-15-2023

im researching this now as GCM is "supposedly" more secure than CBC. But im confused since IKE is a P1 negotiations, coming before Ipsec (P2). so how can i ensure my far side is really who they should be with no form of password or authentication key exchange? I set up a tunnel between to devices. the far side gets swapped by someone who knows the IP's but not the key. After he puts that in P1 with GCM comes up without the password being entered on the far side replaced device???

seems counterintuitive here, and im sure im missing something, but what is it??

tvotna · ‎08-16-2023

These are two different stories. IKE PSK/cert authentication is still required in order to bring IKE SA up if AES-GCM is used during IKE negotiation as an encryption algorithm. Also, AES-GCM combines encryption and authentication, but still this has nothing to do with IKE authentication.

Jerome BERTHIER · ‎09-04-2023

Hello

You talk about very different things.

First, GCM and CBC are two different mathematic models for implementing AES. And GCM is not only an encryption algorithm but also deals with integrity.

So, when choosing GCM, you do not need to select an integrity algorithm for IPSEC proposal (as it won't apply).

It has nothing to do with authentication !

Authentication is managed during phase 1 with IKE. Depending on using IKEv1 or IKEv2 (recommended), you will be able to use different sets of algorithms.

But it always the same, you need :

- an IKE policy that will deal with securing key exchange and cipher negocations during phase 1

- an ESP policy that will deal with encryption and intergrity (based on details negociated on phase 1)

IKE policy then ESP transform set have their own parameters (integrity, ciphers) that can be similar or not.

So, in your case, nobondy will replace the remoter end if you use authentication in phase 1.