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