Hide Forgot
Previously, when using Extensible Authentication Protection (EAP) to authenticate clients that use the TLS 1.2 protocol, such as systems with iOS 9, OS X El Capitan (OS X 11), wpa_supplicant 2.4 and, when configured, Windows 7 and later, a usable association to a WPA2-Enterprise/802.1X SSID could not be established and the connection thus failed. This update ensures that Microsoft Point-to-Point Encryption (MPPE) keys are calculated correctly when TLS 1.2 is used, which prevents the described problem from occurring. The Master Session Key (MSK) is derived from the MS-MPPE-Recv-Key (MasterReceiveKey) and MS-MPPE-Send-Key (MasterSendKey).
Description of problem: 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 in conjunction with a TLS 1.2 capable version of OpenSSL. This occurs because FreeRADIUS miscalculates the MPPE keys meaning that client auth cannot complete when an EAP client negotiates with TLS 1.2. The issue is patched here: https://github.com/FreeRADIUS/freeradius-server/commit/bdff82cdc5bbd6e9079be4b11f0adc27fa994416 iOS 9 and OS X El Capitan, currently in beta, are examples of clients that use TLS 1.2 by default for EAP purposes. Users find that they cannot associate to networks that use WPA2-Enterprise. When these ship, this will have a significant impact as affected clients are not be able to connect. This is of particular concern and importance to the eduroam community. This bug was resolved with FreeRADIUS 2.2.7 and 3.0.8 I suggest that you consider upgrading the FreeRADIUS 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.) Failing that, the patch linked above should be merged. The FreeRADIUS package was updated to 2.2.6 recently: https://rhn.redhat.com/errata/RHSA-2015-1287.html wpa_supplicant 2.4, where TLS 1.2 is enabled by default for TLS-based EAP, is also affected. 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 - it must be configured. See the second More Information section of: https://support.microsoft.com/en-us/kb/2977292 Version-Release number of selected component (if applicable): 2.2.6 How reproducible: Always Actual results: Clients that offer to use TLS 1.2 should cannot connect to a WPA2-Enterprise network that is backed by FreeRADIUS. Expected results: Clients that offer to use TLS 1.2 should be able to connect to a WPA2-Enterprise network that is backed by FreeRADIUS.
as national roaming operator (NRO) of eduroam in the UK and a RedHat subscription owner (we use this OS on the UK national proxies) I would like to ask for this issue to be resolved as soon as possible - with a fixed 2.2.8 FreeRADIUS package being available as soon as possible - or our clients that are running Redhat and FreeRADIUS 2.2.6 are going to be rather unstuck when IOS 9 and OSX El Capitan are released int he very near future. These clients are unlikely to be those that can compile their own version (indeed, such users are probably already running 2.2.8 or eyeing up a 3.0.9 upgrade this summer). it will be the less technically capable who will have hundreds/thousands of end users unable to authenticate onto their 802.1X WPA2-Enterprise Wifi network (eduroam) many thanks alan
Just to make this clear as there appears to be confusion behind the scenes. RHSA-2015:1287-3 introduced this bug as it rebased the FreeRADIUS package to 2.2.6 https://rhn.redhat.com/errata/RHSA-2015-1287.html FreeRADIUS 2.2.5 and earlier are not affected as those releases only support TLS 1.0 FreeRADIUS 2.2.6 introduced support for TLS 1.2 but did so incorrectly. FreeRADIUS 2.2.7 corrected this critical bug. You should therefore consider rebasing again to 2.2.8. The 2.2.x branch is now EOL for all but security fixes. Only one additional patch has made it to the tree, which you may wish to include if you decide to do this: https://github.com/FreeRADIUS/freeradius-server/commits/v2.x.x
Thank you for the report, Nick. We've started the work on backporting the fix.
The fix is done by upstream, backporting.
Doc Text isn't correct. Windows 7 and 8 and 8.1 only use TLS 1.2 for EAP purposes when explicitly configured to do so and after the required security hotfix from Windows Update is applied. It isn't enabled by default. When enabled, failure occurs. OS X El Capital (OS X 11) and iOS 9 use TLS 1.2 by default and fails. wpa_supplicant 2.4 uses TLS 1.2 by default and fails. wpa_supplicant is used by Android clients so this behaviour will make it in to circulation on widely deployed clients.
The other thing that is probably worth mentioning, although strictly out of scope, is that the 3.x version of FreeRADIUS in RHEL 7.1 does not support TLS 1.2 as it predates the 2.x version in RHEL 6.7
The public release date for iOS 9 is likely to be in mid-September. Please can a patch for this be available by then?
Any news on this critical issue ?
I have been told that Apple have deferred using TLS 1.2 for EAP from iOS 9 to a later release due to the current breaking compatibility impact seen with FreeRADIUS deployments, of particular concern is this very issue that is outstanding with broken RHEL 6.7 and therefore broken CentOS 6.7 packages. Disappointingly, fixed binaries have not been made available in a timely manner. It is therefore a sensible course of action for Apple to have taken due to the inaction seen here to avoid the support burden that would result at the present time. The forthcoming Android release is currently negotiating with TLS 1.2 for EAP due to it moving to wpa_supplicant 2.4 so this is still a pressing concern.
Well this is a good news, may be Apple as also deferred TLS 1.2 default also in 10.11 ? Have redhat engineers reading this thread any update ?
We've implemented the fix and the fixed packages will be available in the next RHEL6.7.z release (see Bug 1254176) and RHEL6.8 (this bug). Customers can request pre-release packages as a support exception.
The other related bug still says 6.8 after it was cloned although reading through it, it's obviously instead about 6.7 ;) The salient point here is that the fix ought to be available to all customers who are supported on 6.7, irrespective of the level of support that's paid for. Some common sense direction and being commercially reasonable IMO should come in to play due to the breaking nature of this bug on existing deployments. That just hasn't happened... Also expecting EUS customers, at the present time, to... 1) Hit the issue. 2) Spend the time to triage and understand it correctly, this being unlikely in many cases due to a level of expertise/interest/time being required. 3) Know to open a support case to get a pre-release package as an exception. ... isn't, surely, remotely realistic or indeed reasonable?
*discretion not direction Anyway, the important point now is that this has been deferred so it won't bite later today, when iOS 9 becomes available, and in the forthcoming few days.
The fix for this bug has been delivered in RHEL 6.7.z and this component has not been updated in RHEL 6.8. RHEL 6.8 contains the fix from RHEL 6.7.z. Therefore, this bug has been closed as CURRENTRELEASE.