Hi Aman, (I'm copying freeradius-users to feedback to the thread, but as it's not really a FR issue I'm happy for you to take this off-list if you want any more details/testing). On Mon, Mar 05, 2012 at 08:19:15PM +0000, Alan Buxey wrote:
right. interesting. I've just been looking into Windows 8 and I found that if I chose a non-EAP method with TTLS (eg PAP or MSCHAP) then it didnt work. but if I chose an EAP method with TTLS - eg EAP-MSCHAPv2 then it worked fine. so more needs to be looked at there.
We've been digging into this a bit more and testing the TTLS support with Windows 8. Really nice to see more options than just PEAP at last :-) There seems to be a bug in the Windows 8 TTLS ACK, which means that EAP-TTLS/MS-CHAPv2 doesn't work (EAP-TTLS/MSCHAP and EAP-TTLS/EAP-MSCHAP-V2 are OK). Having received an Access-Accept from the inner tunnel (after the mschap module succeeded), FreeRADIUS sends an Access-Challenge back to the NAS. See src/modules/rlm_eap/types/rlm_eap_ttls/ttls.c:675. The end device should respond to the challenge with a TTLS ACK. RFC 5281 s9.2.3 says: "An Acknowledgement packet is an EAP-TTLS packet with no additional data beyond the Flags octet, and with the L, M, and S bits of the Flags octet set to 0. (Note, however, that the V field MUST still be set to the appropriate version number.)" (this is correctly handled in FR src/modules/rlm_eap/libeap/eap_tls.c:375) The EAP-Message in the resulting Access-Request from Win8 is: EAP-Message = 0x020b000a158000000000 Which is Response / id 11 / length 10 / type TTLS, then: flags 0x80 ('length included') followed by a length of 00000000. Note the RFC says that no additional data beyond Flags, and L/M/S all set to 0 - here, L is set to 1, so it's not a correctly formed ACK (albeit looking like one with Length set to 0), so FR bombs out with: [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS TLS Length 0 [ttls] Length Included [ttls] eaptls_verify returned 11 [ttls] SSL_read Error [ttls] Error in fragmentation logic [ttls] eaptls_process returned 4 [eap] Handler failed in EAP/ttls [eap] Failed in EAP select ++[eap] returns invalid Failed to authenticate the user. eapol_test with EAP-TTLS/MSCHAP-v2 works fine, and sends the TTLS ACK back as: EAP-Message = 0x020800061500 which is fine - flags all 0, no TTLS length supplied. Windows 8 with EAP-TTLS/MSCHAP is also fine, as there is no Access-Challenge sent; it's a direct Access-Accept with EAP-Message 0x030a0004 (Success). As Alan noted, EAP-TTLS/EAP-MSCHAP-V2 also seems fine. Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>