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
