1

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?

dutsnekcirf
  • 79
  • 1
  • 3
  • 14
  • I'm aware of a [possible workaround](https://bugzilla.redhat.com/show_bug.cgi?id=1571754) on RHEL 7, but there is nothing for RHEL 6 (and likely never will be). – Michael Hampton Jan 04 '19 at 00:28
  • Could implementing EAP-TLS instead of EAP-MD5 work? Or could I upgrade to FreeRadius version 3 and implement radsec? – dutsnekcirf Jan 04 '19 at 02: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 06 '19 at 02:44
  • @ArranCudbard-Bell It would actually be easy to detect if the server is running in FIPS mode. "cat /proc/sys/crypto/fips_enabled" would return a 1 if it's enabled or 0 if it's not. How could I force it to use the internal md5 functions based on the output of that command? – dutsnekcirf Jan 06 '19 at 21:32
  • 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 07 '19 at 01:31
  • @ArranCudbard-Bell From a fresh install of rhel 6.8 with fips=1 defined on the grub kernel statement install freeradius using "yum install freeradius". I get version 2.2.6. Once installed add a test user in /etc/raddb/users. Attempt to start the server with radiusd -X. It fails and I get the following errors: "rlm_eap_tls: Couldn't set ephemeral RSA Key" "rlm_eap: Fail to initialize type tls" "/etc/raddb/eap.conf[17]: Instantiation failed for module "eap"" "/etc/raddb/sites-enabled/default[310]: Failed to find "eap" in the "modules" section." "/etc/raddb/sites-enabled/default[252]: Errors.. – dutsnekcirf Jan 07 '19 at 02:59
  • "/etc/raddb/sites-enabled/default[252]: Errors parsing authentication section." I've run the /etc/raddb/certs/bootstrap script as well just to be safe. From what I understand the server should start fresh. As soon as I remove fips=1 from the grub kernel statement the server starts without errors. – dutsnekcirf Jan 07 '19 at 03:03
  • @ArranCudbard-Bell So...I just went through the exact same steps as I outlined above except I instead installed a fresh copy of CentOS 6.9 minimal, set fips=1 on the grub kernel statement, ran yum update and installed freeradius. This time the server started without errors. I then ran radtest and received an Accept-Accept packet. So this tells me that I have something unique with my RHEL 6.9 VM that is preventing me from loading the modules. More troubleshooting is needed with that particular VM. – dutsnekcirf Jan 07 '19 at 03:35
  • @ArranCudbard-Bell Another update. On my RHEL 6.9 VM, I just edited the eap.conf file and commented out all the lines from 90 - 700. Basically left only the md5 module and then started the server and it started successfully. I then ran radtest and received an Accept-Accept. So the problem lies with a specific module. I'm guessing something with TLS given the error messages I was receiving before. – dutsnekcirf Jan 07 '19 at 04:18
  • 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 07 '19 at 08:02
  • I modified the code in the master branch to support runtime selection of md4 functions based on the availability of OpenSSL and whether it's running in FIPS mode. I'll apply the same fix to md5 and sha1. https://github.com/FreeRADIUS/freeradius-server/commit/337ec8f6f56a3a91220613746c63fe47a37b7700 – Arran Cudbard-Bell Jan 08 '19 at 00:13
  • @ArranCudbard-Bell I'd like to mark this question as resolved. I believe you've answered the question with the fact that it is indeed possible to run freeradius on a fips enabled rhel server by virtue of the fact that freeradius implements its own versions of MD5. I'd like to give you credit for answering the question but I guess you have to actually post it as an answer and not simply a comment. If you could post that then I'll mark it as the answer right away. – dutsnekcirf Jan 14 '19 at 04:07

1 Answers1

1

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

Arran Cudbard-Bell
  • 1,514
  • 1
  • 9
  • 18