Technical Tip: FortiGate FIPS-CC mode no longer supports standard RADIUS, use RADSEC instead (Expected Behavior for FortiOS v7.2 and later)

First, regarding the FIPS 140-2/140-3 transition for FortiOS, refer to the following KB article: Technical Tip: Key considerations when upgrading FIPS FortiGates from FIPS 140-2 (v7.0 and earlier) to FIPS 140-3 (v7.2, v7.4, and later).

One of the newest limitations imposed in FIPS 140-3 has been the removal of MD5, MD4, and DES as accepted cryptographic algorithms. There have also been additional limitations that prevent unprotected plaintext authentication.

This has a significant impact on the RADIUS authentication protocol, as it prevents the usage of CHAP, MSCHAP, and MSCHAPv2 (since these schemes use the aforementioned weak crypto), as well as PAP (when used with unprotected standard RADIUS) when operating in FIPS-CC mode. As such, it is no longer possible to configure standard unprotected RADIUS authentication when FIPS mode is enabled on FortiOS v7.2 and later.

However, the FIPS standards do allow encrypted RADIUS authentication to be utilized, and so the FIPS Certified/CVE-Patched branches of FortiOS v7.2 and v7.4 support the configuration of RADSEC (aka RADIUS over TLS) with PAP as the inner authentication protocol (allowed now since it is protected by TLS; CHAP/MSCHAP/MSCHAPv2 remain disallowed). In fact, when configuring RADIUS on a FIPS-enabled FortiGate, it will automatically default to using RADSEC/RADIUS-over-TLS (which uses TCP/2083 for communication, rather than UDP/1812) with no option to revert to standard RADIUS.

Important: The General Availability (GA) version of FortiOS v7.4 also implements support for RADSEC (see: Add RADSEC client support), but FortiOS v7.2 GA does not support RADSEC. This means that for FortiOS v7.2, only the FIPS Certified/CVE-Patched builds will support RADIUS authentication when FIPS mode is enabled.

Recommendations for users upgrading from earlier FIPS Certified/CVE-Patched FortiOS versions:

In this particular case, check the production FortiGates to see if they are configured for RADIUS-based authentication, then validate if that authentication is still required (or if it can be removed or replaced with an alternative like LDAP or SAML).

If RADIUS authentication is still required, then the next step is to update the associated RADIUS server to enable RADSEC support with PAP as the inner authentication method. Alternatively, consider adding a RADSEC proxy as a bridge between the FortiGate and the existing RADIUS server (if the server does not support RADSEC).

Finally, validate that the FortiGate can generally reach the RADSEC server over the network (e.g., with telnet over TCP/2083), then upgrade the FortiGate when ready.

Additional notes regarding IPsec/IKEv2 and User Authentication:

• As a reminder, IKEv2 requires the usage of EAP to handle authentication (as opposed to XAUTH with IKEv1). For an in-depth explanation of how IKEv2 EAP authentication works on the FortiGate, refer to Technical Tip: FortiOS IKEv2 EAP user authentication operation.
• For most forms of authentication (LDAP, local users, SAML, etc., but not RADIUS), the FortiGate supports either EAP-MSCHAPv2 or EAP-TTLS authentication with FortiClient, with the FortiGate acting as the EAP authenticator/terminator.
  • SAML authentication occurs separately from IKE/IPsec at first. Then, after authentication is completed, the results are utilized within IKEv2's EAP authentication scheme. See the article linked above for more information.
  • RADIUS-based authentication for IKEv2 is also supported (provided that RADSEC/RADIUS-over-TLS is utilized), though in that case the EAP authentication is between FortiClient and the RADIUS server directly (EAP communication passes through the FortiGate and is negotiated between the client and RADIUS server directly).
• Important Note 1: since MSCHAPv2 is disallowed in FIPS 140-3, EAP-TTLS/PAP must be enabled on FortiClient for IKEv2-based VPN tunnels connecting to FIPS-enabled FortiGates.
  • See also: Technical Tip: How to enable EAP-TTLS for IPsec IKEv2 tunnels in VPN-only (unlicensed) FortiClient.
• Important Note ##2 the RADIUS Message-Authenticator attribute is also disallowed by FIPS 140-3 (since it uses MD5 hashing). On FIPS Certified/CVE-Patched firmware this is not a concern as the attribute has been removed from IKEv2's EAP-based authentication, but for GA firmware with FIPS mode enabled it is still present and can result in IKEv2 dial-up tunnels failing to establish correctly ('Invalid Message-Authenticator' will be present in eap_proxy debugs).
  
  • To resolve this, use FIPS Certified/CVE-Patched firmware for environments that require FIPS mode to be enabled, as GA firmware is not guaranteed to be fully FIPS-compliant.

Related articles:

• Technical Tip: FortiOS FIPS Resource List
• Technical Tip: Key considerations when upgrading FIPS FortiGates from FIPS 140-2 (v7.0 and earlier) to FIPS 140-3 (v7.2, v7.4, and later)
• Technical Tip: Upgrading FortiOS Firmware when FIPS-CC is enabled