[RADIATOR] Apple iOS 9 and OS X El Capitan

[David Zych]

In case anyone else out there is in the same boat...

Last week, we noticed that Apple devices running the beta releases of El 
Capitan and iOS 9 were unable to connect to our WPA2 Enterprise 
networks, which authenticate against Radiator running on Red Hat 
Enterprise Linux 6.6.

TL;DR: check what version of Net::SSLeay your Radiator is using!

According to the station logs from our wireless infrastructure, our test 
iOS 9 client was able to successfully make it all the way through the 
authentication stage of 802.11i (producing a RADIUS Access-Accept which 
was received by the wireless controller); the failure occurred after 
that, during the four-way handshake to construct the PTK.  At this 
point, I reasoned, the RADIUS server is no longer involved in the 
process, which led us to believe that the problem resided elsewhere 
(i.e. with either Apple or our wireless vendor).

Then Radiator 4.15 came out with an important vulnerability fix, and I 
took advantage of its new configuration options to specify:
   EAPTLS_Protocols TLSv1.2, TLSv1.1, TLSv1
   EAPTLS_Ciphers DEFAULT:!EXPORT:!LOW:!RC4
which caused it to emit the following log warnings:
TLS_Protocols value TLSv1.2 not available. Ignoring.
TLS_Protocols value TLSv1.1 not available. Ignoring.

These warnings led me to discover that the RHEL6-provided version of 
perl-Net-SSLeay I had been using was positively ancient:
$ perl -e 'use Net::SSLeay; print $Net::SSLeay::VERSION."\n"'
1.35
so I installed the latest Net::SSLeay 1.70 from cpan and successfully 
got rid of the warnings.

After I deployed these changes to production, we were pleasantly 
astonished to discover that El Capitan and iOS 9 clients were suddenly 
able to connect with no problems!

Subsequent re-testing in my lab environment shows that what made the 
difference was not Radiator 4.15 or my config changes (which only work 
with Radiator 4.15), but Net::SSLeay.

What's even more surprising to me is that even with the older 
Net::SSLeay, the RADIUS server would respond to the TLSv1.2 Client Hello 
with a TLSv1.2 Server Hello (based on my other observations up to this 
point, I would have expected to see the server negotiate TLSv1.0 
instead).  Furthermore, side by side comparisons of the unencrypted 
portions of traffic captures from the RADIUS server show no obvious 
differences in the ensuing conversation depending on which Net::SSLeay 
is installed; both appear to be TLSv1.2 throughout, both select the same 
cipher suite, and even the lengths of the (opaque to my Wireshark) 
Encrypted Application Data in each packet after that match up perfectly. 
It's obvious from the reproducible empirical success vs failure that the 
RADIUS server as a whole must be doing _something_ different in the two 
cases, but for the life of me I can't see what it is... and if something 
went wrong in setting up the TLS tunnel, then I would expect iOS 9 to 
bail out immediately rather than continuing to authenticate over a 
tunnel it didn't like.

The other half-baked hypothesis that occurs to me is that perhaps the 
old Net::SSLeay somehow caused Radiator to end up sending the wrong 
value in MS-MPPE-Recv-Key; if the AP had the wrong PMK, then it wouldn't 
be able to validate the STA's portion of the 4-way handshake.  But how 
would Radiator manage to successfully decode everything else well enough 
to carry out the whole inner authentication, and only have problems with 
that one value?

If anyone more knowledgeable than I has any insights to share, I remain 
ever-curious about what exactly was going wrong earlier, but my main 
goal in posting this is to share the solution that I discovered purely 
by accident (upgrade Net::SSLeay) with anybody else who might be tearing 
their hair out over the same problem.

Happy Friday!
David