Hide Forgot
The freeradius packages have been upgraded to upstream version 2.2.6, which provides a number of bug fixes and enhancements over the previous version, including: * The number of dictionaries have been updated. * This update implements several Extensible Authentication Protocol (EAP) improvements. * A number of new expansions have been added, including: %{randstr:...}, %{hex:...}, %{sha1:...}, %{base64:...}, %{tobase64:...}, and %{base64tohex:...}. * Hexadecimal numbers (0x...) are now supported in %{expr:...} expansions. * This update adds operator support to the rlm_python module. * The Dynamic Host Configuration Protocol (DHCP) and DHCP relay code have been finalized. * This update adds the rlm_cache module to cache arbitrary attributes.
FreeRADIUS 2.2.4 was released containing a couple of bugfixes and two minor feature improvements. Configuration compatibility is not affected. We should rebase to save on fix backporting and to reduce customer confusion. The original release announcement follows. ---:<--- Version 2.2.4 has been released The changes from 2.2.3 are minor. Feature improvements * A "panic_action" can be set to have the server dump a gdb log on SEGV or other fatal error. * allow radmin command "set module status <module> <code>" which can be used to forcibly enable/disable modules. Bug Fixes * If the server fails to bind() after fork(), that is now reported to the parent, which exits with an error. * Session / delay times in MySQL are unsigned int. & Use --tag=CC for libtool. Closes #497. Because libtool is too stupid to notice that compiling means compilation. * Fix bug when copying attributes for vendors > 32767 * Fix behaviour on FreeBSD where sending packets from an interface bound to an IP address would fail when the server was built with udpfromto. * Don't fail config check if were listening on an IP which is also a home server. Some deployments have valid reasons to loop packets back to another virtual server. * Use correct port when DHCP relaying. * Set source IP address for DHCP packets from DHCP-Server-IP-Address, or DHCP-DHCP-Server-Identifier, if we're unable to otherwise determine the source IP. --->:---
This should be updated to 2.2.5 (which is the latest stable for 2.x). Also, this should be assigned to Nikolay Kondrashov, since he's the new maintainer for the package :-)
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, 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://rhn.redhat.com/errata/RHSA-2015-1287.html
There is a high impact bug that will increasingly impact TLS-based EAP users in FreeRADIUS 2.2.6 and 3.0.7, such as 802.1X deployments, when FreeRADIUS is used with a TLS 1.2 capable version of OpenSSL. This occurs because FreeRADIUS miscalculates the MPPE key meaning that client auth cannot complete when a client negotiates with TLS 1.2. See: https://github.com/FreeRADIUS/freeradius-server/commit/bdff82cdc5bbd6e9079be4b11f0adc27fa994416 iOS 9, currently in beta, is an example of a client that uses TLS 1.2 by default for EAP purposes. Users find that they cannot associate to networks that use WPA2-Enterprise. This bug was resolved with FreeRADIUS 2.2.7 and 3.0.8 I suggest that you consider upgrading this package to 2.2.8. There is a small set of changes between 2.2.6 and 2.2.8. (The 2.2.x branch is now EOL for all but security fixes.)
*MPPE keys.
Thank you for a heads-up, Nick! I'll see what we can do.
No problem! :) This also affects OS X EL Capitan and the latest version of wpa_supplicant where TLS 1.2 is enabled by default for TLS-based EAP. The supplicant in Windows 7 and newer support TLS 1.2 for the TLS-based EAP types offered such as EAP-PEAP if the machine is fully patched via Windows Update. TLS 1.1 and 1.2 are however, for the moment. disabled by default. See the second More Information section of: https://support.microsoft.com/en-us/kb/2977292
I've opened: https://bugzilla.redhat.com/show_bug.cgi?id=1248484