[RADIATOR] Apple iOS 9 and OS X El Capitan (radiator Digest, Vol 74, Issue 10)

[David Zych]

On 07/26/2015 04:06 AM, Heikki Vatiainen wrote:
> On 07/25/2015 04:28 PM, Nick Lowe wrote:
> 
>> Well, just as a point of related interest, FreeRADIUS had an issue
>> where the MPPE key was incorrectly calculated for TLS 1.2:
>>
>> https://github.com/FreeRADIUS/freeradius-server/commit/bdff82cdc5bbd6e9079be4b11f0adc27fa994416
>>
>> FreeRADIUS 2.2.6 and 3.0.7 don't work with iOS 9 unless TLS 1.2 is
>> disabled server side.
> 
> Thanks for the pointer. Was this discovered with iOS 9 or are there
> other devices too that support TLSv1.2 with EAP? We don't have iOS 9
> betas available, so it would be useful to know if there are other
> clients we could try.
> 
> We have used recent eapol_test versions since they now provide the
> options to specify the TLS version and cipher suites. If the MPPE key
> attributes do not match the values the client expects, it will complain.
> No complaints were seen, but we did not try very old Net::SSLeay
> versions either, so the problem might be visible there, as David's
> findings hint.

Thanks, Nick and Heikki!

Prompted by these hints, I did a bit more testing using a newly compiled eapol_test (from wpa_supplicant-2.4) against Radiator running with the old vs new Net::SSLeay, and confirmed that there was definitely badness specifically related to TLSv1.2.

eapol_version=1
network={
  eap=TTLS
  phase1=""
  phase2="auth=MSCHAPV2"
  identity="XXX"
  password="XXX"
}

With new Net::SSLeay, success.

With old Net::SSLeay and disabling client TLSv1.2 (phase1="tls_disable_tlsv1_2=1"), success.

With old Net::SSLeay and allowing client TLSv1.2 (phase1=""), failure.  This eapol_test trial produces an Access-Reject at the outer handler:

Tue Jul 28 18:44:27 2015 144673: DEBUG: Handling with Radius::AuthFILE: wireless-eapOuter
Tue Jul 28 18:44:27 2015 144783: DEBUG: Handling with EAP: code 2, 7, 163, 21
Tue Jul 28 18:44:27 2015 144857: DEBUG: Response type 21
Tue Jul 28 18:44:27 2015 145082: DEBUG: EAP result: 1, Incorrect MSCHAPV2 challenge sent by client
Tue Jul 28 18:44:27 2015 145166: DEBUG: AuthBy FILE result: REJECT, Incorrect MSCHAPV2 challenge sent by client

With old Net::SSLeay, TLSv1.2, and using PAP instead of EAP-MSCHAPv2 for the inner authentication (phase1="", phase2="auth=PAP"): Access-Accept with PMK mismatch!

Received RADIUS message
RADIUS message: code=2 (Access-Accept) identifier=7 length=189
...
EAPOL: Successfully fetched key (len=32)
PMK from EAPOL - hexdump(len=32): [XXX BYTES XXX]
WARNING: PMK mismatch
PMK from AS - hexdump(len=32): [XXX DIFFERENT BYTES XXX]
No EAP-Key-Name received from server
EAP: deinitialize previously used EAP method (21, TTLS) at EAP deinit
ENGINE: engine deinit
MPPE keys OK: 0  mismatch: 1
FAILURE

This still doesn't _exactly_ match my iOS 9 test case, because it appears that iOS 9 was doing EAP-MSCHAPv2 (not PAP) inside EAP-TTLS and getting an Accept, *but* it proves the concept that with old Net::SSLeay it's possible to make it through RADIUS authentication, get an Accept, and still end up with the wrong PMK... so I'm satisfied.

Moral of story, part 2: I should run eapol_test more often.  :)

Thanks,
David

P.S.  Heikki, a suggestion: it's certainly not Radiator's responsibility to save me from being dumb, but it occurs to me that adding a runtime check which emits a warning if you're using a Net::SSLeay that's older than the minimum one required by the release notes (manually disable-able with DisabledRuntimeChecks, of course) might be a friendly way to help other people quickly diagnose this sort of issue.