Bug 1248484 - FreeRADIUS 2.2.6 miscalculates MPPE keys with TLS 1.2
Summary: FreeRADIUS 2.2.6 miscalculates MPPE keys with TLS 1.2
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: freeradius   
(Show other bugs)
Version: 6.8
Hardware: All
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Nikolai Kondrashov
QA Contact: Jaroslav Aster
URL:
Whiteboard:
Keywords: ZStream
Depends On:
Blocks: 1254176
TreeView+ depends on / blocked
 
Reported: 2015-07-30 11:39 UTC by Nick Lowe
Modified: 2016-09-14 13:13 UTC (History)
13 users (show)

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: ---


Attachments (Terms of Use)

Description Nick Lowe 2015-07-30 11:39:59 UTC
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.

Comment 2 eduroam UK support 2015-08-10 14:34:18 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

Comment 3 Nick Lowe 2015-08-10 19:03:17 UTC
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

Comment 6 Nikolai Kondrashov 2015-08-13 09:23:11 UTC
Thank you for the report, Nick. We've started the work on backporting the fix.

Comment 9 Nikolai Kondrashov 2015-08-17 10:56:22 UTC
The fix is done by upstream, backporting.

Comment 13 Nick Lowe 2015-08-24 09:46:40 UTC
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.

Comment 14 Nick Lowe 2015-08-24 10:06:05 UTC
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

Comment 15 Nick Lowe 2015-08-27 13:41:04 UTC
The public release date for iOS 9 is likely to be in mid-September. Please can a patch for this be available by then?

Comment 23 paolob 2015-09-16 13:07:37 UTC
Any news on this critical issue ?

Comment 24 Nick Lowe 2015-09-16 13:17:44 UTC
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.

Comment 25 paolob 2015-09-16 13:30:38 UTC
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 ?

Comment 26 Nikolai Kondrashov 2015-09-16 13:55:09 UTC
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.

Comment 27 Nick Lowe 2015-09-16 14:12:42 UTC
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?

Comment 28 Nick Lowe 2015-09-16 14:26:33 UTC
*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.

Comment 29 Marcel Kolaja 2016-09-14 13:13:21 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.