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. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator