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:

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!).

Updated: December 14, 2023 — 08:04

Leave a Reply