Technical Tip: Explaining AES-GCM, 'None' Integrity, and PRF selection for IKEv2 IPsec tunnels on the FortiGate

[pjang]

Description	This article discusses AES-GCM encryption on the FortiGate in reference to IKE/IPsec tunnels. More specifically, this article discusses how AEAD algorithms ('Authenticated encryption with associated data', like AES-GCM) require a 'None' Integrity algorithm option to be used, and how FortiGate implements this compared to other vendors.
Scope	FortiGate, IPsec
Solution	The FortiGate has supported the usage of AEAD algorithms like AES-GCM for IKEv2 phase 1 since FortiOS 6.0.1 and 6.2.0 (per Change #471326), with phase 2 proposals supporting AEAD ciphers even earlier than this. Fortinet implements this feature as defined by RFC 5852 (for AES-GCM) and RFC 7634 (for ChaCha-Poly), IKEv1 does not have a standard for supporting AEAD ciphers, and so the FortiGate does not allow for these ciphers to be used with IKEv1. AEAD ciphers combine encryption and integrity together, and so there is no need to specify separate algorithms for each (and for IKEv2, the proposal must not propose any integrity transforms when using AEAD encryption ciphers). In these cases, the proposal would use AES-GCM (or ChaCha-Poly) as the 'Encryption' algorithm, whereas the 'Integrity' Algorithm is either not set OR may be set as 'None'. For the FortiGate specifically, setting an AEAD algorithm in the Encryption proposal for an IKEv2 phase 1 configuration will automatically (and silently) set the Integrity/Authentication algorithm to 'None', which conforms with the RFC. However, this implementation can be different from other vendors, which can lead to some confusion when forming cross-vendor IKEv2 tunnels: Palo Alto's PAN-OS requires administrators to specifically select the 'non-auth' Authentication setting when using AES-GCM for encryption, otherwise the configuration commit will fail if any other Authentication setting is chosen (see also: Palo Alto PAN-OS - Define IKE Crypto Profiles). By comparison, strongSwan explicitly states that 'no separate integrity algorithm must be proposed' when using AEAD algorithms in the IKEv2 proposal, and so there is no need to specify an integrity algorithm (not even 'None', see also: strongSwan - IKEv2 Cipher Suites). In addition to Authentication and Integrity algorithms, IKEv2 also makes use of a Pseudo-Random Function (PRF) to derive keying material, as well as Diffie-Hellman (DH) Groups for key exchange. When using non-AEAD ciphers (such as AES-CBC), IKEv2 will automatically use the proposed Integrity algorithms for PRF purposes, whereas AEAD ciphers require a PRF hashing algorithm to be specifically defined. On older FortiOS versions (such as 7.2.12), the GUI distinguishes between the cases of Encryption-Authentication (non-AEAD ciphers) and Encryption-PRF (AEAD ciphers). However, later FortiOS versions (such as v7.6.4) only label this as Encryption-Authentication, which can add to the confusion, considering that PRF is separate (but uses similar algorithms to) Integrity/Authentication: IPsec Phase 1 Proposal example (7.2.12) IPsec Phase 1 Proposal (7.6.4) Key Takeaways: When configuring IKEv2 IPsec tunnels in-general, remember that an Encryption algorithm, an Integrity/Authentication algorithm, a PRF algorithm, and DH Groups must always be set. However, on the FortiGate (and with other vendors), these settings may not always be completely visible or explicitly configured. Use the following as a reference when configuring non-AEAD vs. AEAD ciphers on the FortiGate: Non-AEAD ciphers (such as AES-CBC): Encryption - set by administrator (AES128, AES256, etc.). Integrity/Authentication - set by administrator (SHA256, SHA384, etc.). PRF - Not directly set by administrator (automatically inherits same algorithm from Integrity/Authentication). DH Groups - set by administrator (DH Group 20, 14, 5, etc.) AEAD ciphers (such as AES-GCM or ChaCha-Poly): Encryption - set by administrator (AES128GCM, AES256GCM, etc.). Integrity/Authentication - Not directly set by administrator (automatically/silently set to None/NULL per RFC). PRF - set by administrator (PRFSHA256, PRFSHA384, etc.). DH Groups - set by administrator (DH Group 20, 14, 5, etc.)