We've been using SecureW2's client with our Freeradius server using EAP-TTLS/PAP authentication. From doing some very preliminary testing with the Windows 8 consumer preview, I've noticed that MS is now including EAP-TTLS support directly in windows. Unfortunately, I haven't had any luck getting this working yet. From looking over the radius logs, everything appears to be authenticating correctly, but then windows sits at "Checking network requirements" for a few minutes before dying. Below are the steps I have taken to configure windows to connect to our network so far. Has anyone else had luck with this yet? 1. Open the "Network and Sharing Center" either through the control panel or by right clicking the network icon in your tray 2. Click "Set up a new connection or network" 3. Click "Manually connect to a wireless network" 4. Enter the network name and choose WPA2-Enterprise for Security Type, then click Next 5. Click "Change connection settings" 6. Go to the security tab and choose "Microsoft EAP-TTLS" from the "Network Authentication Method" dropdown 7. Click "Settings" and uncheck "Enable identity privacy" 8. Click OK twice 9. Click the wifi icon in your tray and choose your secure wireless network 10. You will now be prompted for your username & password Brian Gold System Administrator Bard College at Simon's Rock
On 05/03/12 15:05, Brian Gold wrote:
We've been using SecureW2's client with our Freeradius server using EAP-TTLS/PAP authentication. From doing some very preliminary testing with the Windows 8 consumer preview, I've noticed that MS is now including EAP-TTLS support directly in windows. Unfortunately, I
Ooo, interesting.
haven't had any luck getting this working yet. From looking over the radius logs, everything appears to be authenticating correctly, but then windows sits at "Checking network requirements" for a few minutes before dying. Below are the steps I have taken to configure windows to connect to our network so far. Has anyone else had luck with this yet?
Please send "radiusd -X" output. We have a Win8 preview box here; I'll try to test it.
I've uploaded the radius -X output to http://pastebin.com/Fgr60hXr since it was pretty long.
-----Original Message----- From: freeradius-users-bounces+bgold=simons-rock.edu@lists.freeradius.org [mailto:freeradius-users-bounces+bgold=simons- rock.edu@lists.freeradius.org] On Behalf Of Phil Mayers Sent: Monday, March 05, 2012 10:45 AM To: freeradius-users@lists.freeradius.org Subject: Re: using windows 8's builtin eap-ttls w/ freeradius
On 05/03/12 15:05, Brian Gold wrote:
We've been using SecureW2's client with our Freeradius server using EAP-TTLS/PAP authentication. From doing some very preliminary testing with the Windows 8 consumer preview, I've noticed that MS is now including EAP-TTLS support directly in windows. Unfortunately, I
Ooo, interesting.
haven't had any luck getting this working yet. From looking over the radius logs, everything appears to be authenticating correctly, but then windows sits at "Checking network requirements" for a few minutes before dying. Below are the steps I have taken to configure windows to connect to our network so far. Has anyone else had luck with this yet?
Please send "radiusd -X" output.
We have a Win8 preview box here; I'll try to test it. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
hi, 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. based on the UI it seems that theres 2 groups of people coding the stuff as the PEAP interface has updated options and layout - whereas the TTLS page is based on the old windows XP PEAP pane - from layout/options. its a little hideous. importing of CAs has changed again - since Win7 - the auto detect for cert import now puts it into the wrong place again...but manually choosing the store and choosing Root CAs gets it in the very small list of CAs that Win8 knows... it seems you can choose whatever you want for the anonymous ID in TTLS too - whereas the PEAP anonymous is more conservative. ..and none of this can be done via the new 'metro' interface....yes, its funky and looks pretty but once again, it doesnt show you much detail when you hover over the wireless - signal strength bars, encyption and 802.11n - so what about channel or SNR? couldnt find an obvious 'disconnect' option in the interface either...but it did take me a minute or 2 to find the 'shutdown/reset' option! ;-) alan
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>
On 03/05/2012 06:31 PM, Brian Gold wrote:
I've uploaded the radius -X output to http://pastebin.com/Fgr60hXr since it was pretty long.
Weird; that all looks good to me. I guess the problem must be on the Windows side, but I'm not super familiar with TTLS so am not sure what it might be.
participants (5)
-
Alan Buxey -
alan buxey
-
Brian Gold -
Matthew Newton -
Phil Mayers