Technical Tip: IPsec Phase1 and Phase2 encryption strength requirements when FortiGate is in FIPS-CC mode
| Description | This article discusses some expected restrictions specific to FIPS mode on the FortiGate when selecting encryption algorithms for the Phase1 and Phase2 settings of IPsec VPN tunnels.
Quick Note: FortiGates running 7.4-based firmware (both GA and FIPS certified/CVE-Patched) with FIPS mode enabled can no longer use AES128 for IPsec proposals; see the note at the bottom of the Solution section. |
| Scope | FortiGate, FIPS-CC. |
| Solution | As a quick point of reference, FIPS mode on the FortiGate is subject to compliance regulations from both FIPS 140-2/140-3 as well as Common Criteria (CC) as part of the overall certification process. For Common Criteria in particular, the FortiGate undergoes certification for NDcPP (Network Device Collaborative Protection Profile) and EAL4+ (Evaluation Assurance Level 4 Augmented).
Within NDcPP (specifically the PP-Module for Virtual Private Network (VPN) Gateways, previously known as NDcPP Extended Package for VPN Gateways) there is a restriction labelled FCS_IPSEC_EXT.1.12 which states that the product under evaluation must ensure that the negotiated strength of the symmetric encryption algorithm used for IKEv1 Phase 1 (or IKEv2's IKE_SA equivalent) must be greater than or equal to the strength of the symmetric encryption negotiated for IKEv1 Phase 2 (or IKEv2's CHILD_SA equivalent).
In practical terms, this means that when FIPS mode is enabled on the FortiGate, the weakest option within an IPsec tunnel's Phase 1 proposal will set the upper-limit for what may be set in the Phase 2 proposal settings. For example, consider an IKEv2 VPN tunnel with the following encryption/authentication options in the Phase 1 proposal:
In the above Phase 1 proposal, AES128 is considered weaker than AES256, and so Phase 2 is limited to AES128 or weaker (though no weaker options exist in FIPS mode). When attempting to configure proposals for the VPN tunnel's associated Phase 2, administrators will find that it is not possible to set AES256 at all as an encryption option:
FortiGate # show vpn ipsec phase1-interface example_vpn | grep proposal set proposal aes128-sha256 aes256-sha256
FortiGate # config vpn ipsec phase2-interface FortiGate (phase2-interface) # edit example_vpn FortiGate (example_vpn) # show | grep phase1name set phase1name "example_vpn"
FortiGate (example_vpn) # set proposal ? aes128-sha1 aes128-sha1 aes128-sha256 aes128-sha256 aes128-sha384 aes128-sha384 aes128-sha512 aes128-sha512 aes128gcm aes128gcm
As noted above, this is expected behavior based on NDcPP regulations. To 'solve' the issue and ensure consistency, administrators should avoid mixing encryption algorithms of different strengths within the Phase 1/Phase 2 proposal. In the above example, this could be done by removing the Phase 1 proposal for AES128-SHA256 and using a single option of AES256-SHA256 for both Phase 1 and Phase 2.
Note: The FortiOS CLI/GUI has been somewhat inconsistent with enforcing these restrictions, and in some cases, it has been possible for administrators to configure the FortiGate in a way that would break these rules. Review configurations carefully to ensure that Phase 1 proposals are always equal to or greater in encryption strength than Phase 2 proposals.
Additionally, take note that as of Change #967449 in FortiOS v7.4.4 GA and later (which the FIPS v7.4 certified firmware is based upon), AES128 has been removed as an available option for IPsec tunnels on the FortiGate when FIPS mode is enabled. This leaves AES256 (CBC and GCM) as the only available FIPS-compliant options for FortiOS v7.4 in FIPS mode, even though AES128 is still considered to be technically compliant with FIPS 140-3 and NDcPP v3.0e.
Related documents: Technical Tip: FortiOS FIPS Resource List PP-Module for Virtual Private Network (VPN) Gateways Version 1.3 FortiOS 6.4 FIPS 140-2 and NDcPP Common Criteria Technote (see Page 23) |