I'm attempting to install a FreeRADIUS server on a RHEL 6.9 VM. This VM is operating in FIPS mode. I'm running into the problem described in a Red Hat bug report found here.

According to that bug report from March of 2015 the RADIUS protocol requires MD5 support. FreeRADIUS (and RADIUS) can therefore not be supported in FIPS mode.

I'm hoping that in the 3 years that have transpired since that bug report there's been a fix or workaround that I can implement to get around this issue. Unfortunately, I'm restricted to running in FIPS mode per DISA STIG requirements. Is anyone aware of a way to get FreeRADIUS to work on a machine that's operating in FIPS mode?

  • I'm aware of a possible workaround on RHEL 7, but there is nothing for RHEL 6 (and likely never will be). – Michael Hampton Jan 4 '19 at 0:28
  • Could implementing EAP-TLS instead of EAP-MD5 work? Or could I upgrade to FreeRadius version 3 and implement radsec? – dutsnekcirf Jan 4 '19 at 2:14
  • 1
    We have our own implementations of MD5 and hmac_md5. If you have a way of detecting if the server is running in FIPS mode we can just switch to the internal functions. – Arran Cudbard-Bell Jan 6 '19 at 2:44
  • 1
    actually... not even sure that's required. Could you tell me exactly where FreeRADIUS is failing? Is it in one of the signing functions? – Arran Cudbard-Bell Jan 7 '19 at 1:31
  • 1
    Sounds like the internal functions are already being used if you're getting Access-Accepts. It's a compile time option, so it's feasible RedHat built the FreeRADIUS packages with the internal MD5 functions. – Arran Cudbard-Bell Jan 7 '19 at 8:02

It seems as though the FreeRADIUS packages being used are being built with the internal MD5 functions enabled, and as such, they're not reliant on OpenSSL's MD5 implementation. This means in this instance, FreeRADIUS will work with OpenSSL in FIPS mode.

For FreeRADIUS 4 (the next major version), I've implemented runtime checking to swap in internal functions if OpenSSL is in FIPS mode, and to use the OpenSSL functions if it is not in FIPS mode.

There are two reasons we want to use the OpenSSL functions over the internal ones when we can:

  • They've had much more public scrutiny. They've likely been proven correct at some point.
  • They take advantage of any hardware acceleration provided by the CPU or crypto acceleration cards.

As you've posted in the comments, certain other algorithms used by TLS may be unavailable. It should be possible to work around any disabled algorithms, by setting an explicit cipher list in the EAP module configuration and in the relevant RADSEC TLS section (TLS config parsing is common code).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.