IKEv2 AES-256-GCM and SHA-384, what?

What has this SHA-384 to do with AES-256-GCM? I thought GCM contained integrity checks already, so why is SHA-384 there anyway?

• IKE = Internet Key Exchange, the way to securely negotiate IPsec (Internet Protocol Security) encryption between two VPN (Virtual Private Network) tunnel peers
• AES = Advanced Encryption Standard
• GCM = Galois/Counter Mode
• CBC = Cipher Block Chaining
• SHA = Secure Hash Algorithm

With AES-CBC (= non-GCM) in IKEv2 phase 1, you have to use an authentication (hashing) algorithm that ensures the integrity of the data exchange. Nowadays the common ones are SHA-256, SHA-384 and SHA-512. So, you select the encryption algorithm plus the authentication algorithm. For example: AES-256 + SHA-384.

With AES-GCM there is an authentication algorithm included in the AES-GCM encryption, so you don’t select the authentication algorithm separately. But, AES-GCM needs a hashing function for PRF (Pseudo-Random Function). That’s why you need to select something like SHA-256 or SHA-384 with AES-GCM.

Among security device vendors there seems to be (at least) two ways to deal with this PRF algorithm selection when configuring AES with GCM: some let you select whatever you want, and some force a specific algorithm based on your present configuration details.

For example, Fortinet lets you select it when configuring IKEv2 phase 1 on FortiOS:

• aes128gcm-prfsha1
• aes128gcm-prfsha256
• aes128gcm-prfsha384
• aes128gcm-prfsha512
• aes256gcm-prfsha1
• aes256gcm-prfsha256
• aes256gcm-prfsha384
• aes256gcm-prfsha512
• Reference: https://docs.fortinet.com/document/fortigate/7.4.1/administration-guide/238852/encryption-algorithms#IKEv2

They do indicate the PRF thingy there in the option names, so it tells you that it is not the “normal” IPsec authentication algorithm (like in “aes256-sha384”) but something related to PRF only.

In contrast, Palo Alto Networks selects the PRF hashing for you: if you have GCM and DH (Diffie-Hellman) group (or key exchange method transform identifier) 19 or smaller, PAN-OS selects SHA-256 for PRF, and if you have DH group 20, it uses SHA-384 for PRF. Reference: https://docs.paloaltonetworks.com/network-security/ipsec-vpn/administration/set-up-site-to-site-vpn/define-cryptographic-profiles/define-ike-crypto-profiles. They don’t mention PRF anywhere in the configuration or in the documentation, and the configuration commit fails if you try to use AES-GCM with any other hash selection than “non-auth” (you cannot leave it empty either).

So, when configuring IPsec VPN tunnel with IKEv2 and AES-GCM between FortiGate and PAN-OS firewalls, this is one successful combination for phase 1:

• FortiGate: proposal = aes256gcm-prfsha384, dhgrp = 20
• PAN-OS: encryption = aes-256-gcm, hash = non-auth, dh-group = group20

Feel free to share your own experiences with AES-GCM configuration gotchas maybe for other vendors, or any other comments you feel the readers of this post should be aware of (like any crucial corrections to my possible misunderstandings!).