using windows 8's builtin eap-ttls... Windows 8 bug

[Matthew Newton]

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 at 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 at le.ac.uk>