Bug 1872689
| Summary: | Radius Authentication does not work in FIPS mode | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Sergey Orlov <sorlov> |
| Component: | krb5 | Assignee: | Robbie Harwood <rharwood> |
| Status: | CLOSED ERRATA | QA Contact: | Filip Dvorak <fdvorak> |
| Severity: | unspecified | Docs Contact: | Josip Vilicic <jvilicic> |
| Priority: | unspecified | ||
| Version: | 8.3 | CC: | abokovoy, dpal, fdvorak, jvilicic, pcech, rcritten, rharwood, tscherf |
| Target Milestone: | rc | ||
| Target Release: | 8.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | krb5-1.18.2-6.el8 | Doc Type: | No Doc Update |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-05-18 14:42:18 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1884741 | ||
| Bug Blocks: | 1894575, 1958979 | ||
|
Description
Sergey Orlov
2020-08-26 12:53:34 UTC
Could you run radiusd with the -X flag? $ sudo systemctl edit --full radiusd.service (add -X flag to radiusd) This should give you additional debug output in the radiusd logs. As it is, there's no indication that kerberos is even hitting radiusd. After adding -X flag: "systemctl restart radiusd" does not return, can be exited with Ctrl-C, radiusd is running: # ps aux | grep radiusd radiusd 12914 0.0 0.6 166816 12648 ? Ss 15:55 0:00 /usr/sbin/radiusd -d /etc/raddb -X I see nothing new in /var/log/radius/radius.log Wed Aug 26 15:57:03 2020 : Info: Debugger not attached Wed Aug 26 15:57:03 2020 : Warning: Please use tls_min_version and tls_max_version instead of disable_tlsv1 Wed Aug 26 15:57:03 2020 : Warning: Please use tls_min_version and tls_max_version instead of disable_tlsv1_2 Wed Aug 26 15:57:03 2020 : Warning: tls: Ignoring user-selected DH parameters in FIPS mode. Using defaults. Wed Aug 26 15:57:03 2020 : Info: Loaded virtual server <default> Wed Aug 26 15:57:03 2020 : Warning: Ignoring "sql" (see raddb/mods-available/README.rst) Wed Aug 26 15:57:03 2020 : Warning: Ignoring "ldap" (see raddb/mods-available/README.rst) Wed Aug 26 15:57:03 2020 : Info: Loaded virtual server default Wed Aug 26 15:57:03 2020 : Info: # Skipping contents of 'if' as it is always 'false' -- /etc/raddb/sites-enabled/inner-tunnel:336 Wed Aug 26 15:57:03 2020 : Info: Loaded virtual server inner-tunnel I have also tried to add -xx instead of -X - stil nothing is written to log file during kinit attempt: Well, yuck. I guess, I'd ask if there's any useful journalctl output and a packet capture if not... Otherwise, a reproducer VM and I can grab those and take a look. Hi, krb5 maint here. First, my sympathies to everyone involved for the lack of logging here. The RADIUS bits that ipa-otpd uses are from libkrad, which, being a library, doesn't log anywhere. Second, I don't believe this is a supported use case in FIPS mode. My understanding is that we don't support running anything other than IPA on an IPA server. Furthermore, RADIUS uses cryptographic MD5 for user-password stuff; this means we can't let it leave the machine. Because krad can't tell where the packets are being sent, it blocks packet construction entirely in FIPS mode. This limitation is intentional and known. Did this ever work? My feeling is that it can't have, given the above. Robbie, Could you please explain your comment in more details? In #7 you say that RADIUS authentication is "usable with FreeIPA" when both servers are on the same machine. I do not have a good knowledge of how IPA works with RADIUS so I do not fully understand why it should not work given the fact that RADIUS and IPA servers are installed on the same machine. Sergey, let me explain it. https://www.freeipa.org/page/V4/OTP#High-Level_Architecture_and_Workflow explains a high level architecture. In short, when Kerberos client uses OTP pre-authentication mechanism, KDC will talk to its own 'RADIUS' end-point which is by default a UNIX domain socket. The other end of this socket is listened by systemd which triggers ipa-otpd run if something comes in to that socket. ipa-otpd will perform a lookup in IPA LDAP of the details of the user trying to authenticate. If this user has been allowed to authenticate with OTP, ipa-otpd will do an LDAP bind using the user's DN and the password+otp value passed in by KDC through the UNIX domain socket. If user entry has associated RADIUS proxy configuration, ipa-otpd instead will use the proxy information to connect to the RADIUS proxy. To do so, ipa-otpd uses the same library that KDC uses to talk to RADIUS (libkrad). libkrad library code was tightened in FIPS mode to only allow to communicate over UNIX domain socket because RADIUS communication protocol uses crypto primitives incompatible with FIPS requirements. However, RADIUS proxy definition in FreeIPA cannot specify UNIX domain socket as a target for the proxy. It means, even a localhost connection to RADIUS server would be done using TCP/IP protocol. This connection will be rejected by libkrad in FIPS mode. To solve this problem we could add an infrastructure to allow specifying RADIUS proxy in FreeIPA by UNIX domain socket in addition to using a server name and its port. In FIPS mode, then libkrad would allow to connect to that UNIX domain socket. This is currently not implemented. Alexander, Thank you for your explanation, now it is clear to me. Alex, I agree that this it is not a bug but a documentation issue. Should we close it now or should we wait for documentation to be updated? Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: krb5 security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:1593 |