Bug 1248484
Summary: | FreeRADIUS 2.2.6 miscalculates MPPE keys with TLS 1.2 | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Nick Lowe <nick.lowe> | |
Component: | freeradius | Assignee: | Nikolai Kondrashov <nikolai.kondrashov> | |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Jaroslav Aster <jaster> | |
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | 6.8 | CC: | dpal, eduroam-uk-support, fabio.pedretti, h.b.furuseth, jaster, jherrman, nikolai.kondrashov, oss, paolo.barbato, pkis, salmy, t.h.amundsen, tore | |
Target Milestone: | rc | Keywords: | ZStream | |
Target Release: | --- | |||
Hardware: | All | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Bug Fix | ||
Doc Text: |
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).
|
Story Points: | --- | |
Clone Of: | ||||
: | 1254176 (view as bug list) | Environment: | ||
Last Closed: | 2016-09-14 13:13:21 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: | ||||
Bug Blocks: | 1254176 |
Description
Nick Lowe
2015-07-30 11:39:59 UTC
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. |