EAP-TLV: Earlier failure - force failed Phase 2

[Adam Jacobs]

Thanks for your reply!


When I'm back in the office on Monday I'll gather the more verbose logs demonstrating the failure.  I can also try re-enabling TLS1.2 and turning off cryptobinding (my RADIUS servers do allow clients that don't do cryptobinding) to see if that helps.


BTW, I've been trying to understand cryptobinding.  I get that it is supposed to prevent MITM attacks, but doesn't TLS already take care of that?  What's the added benefit of cryptobinding/what do I lose by turning it off?


Also I can run test builds in my environment against my servers, if/when we reach that point.



Thanks!

Adam


________________________________________
From: Jouni Malinen [j at w1.fi]
Sent: Friday, January 01, 2016 06:28
To: Adam Jacobs
Cc: hostap at lists.infradead.org
Subject: Re: EAP-TLV: Earlier failure - force failed Phase 2

On Thu, Dec 31, 2015 at 03:36:22PM -0800, Adam Jacobs wrote:
> Dec 17 07:18:20 jeremiah wpa_supplicant[1146]: wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
> Dec 17 07:18:20 jeremiah wpa_supplicant[1146]: EAP-MSCHAPV2: Authentication succeeded
> Dec 17 07:18:20 jeremiah wpa_supplicant[1146]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed
> Dec 17 07:18:20 jeremiah wpa_supplicant[1146]: EAP-TLV: Earlier failure - force failed Phase 2

It looks like Phase 2 (EAP-MSCHAPv2 username/password validation)
succeeded, but something went wrong with the following PEAP steps.
Adding some more wpa_supplicant debug verbosity (e.g., -d on the command
line) would help clarify what exactly happened here.

> It seems to happen more-or-less randomly; I'm not doing anything in particular when the connection drops.  I'd say an average session lasts about 30 minutes or so, before it dies and I need to restart.
>
> Disabling TLS1.2 in wpa_supplicant seems to solve the problem, but that's a workaround, not a fix.
>
> Any ideas?  In particular, "EAP-TLV: Earlier failure - force failed Phase 2" seems to be where the trouble starts.  Anyone know what that means?

My first guess would be that this ended up using PEAPv0 cryptobinding
and there was an interop issue of some short that caused the server and
wpa_supplicant derive different value. That may very well be dependent
on TLS v1.2 being used.

Unfortunately, I do not have a Windows 2012 RADIUS server to test this
easily myself. If you can produce more detailed debug logs from
wpa_supplicant, that would be useful information to have for figuring
out what exactly might be causing this.

As a workaround, it might be possible to add phase1="crypto_binding=0"
to disable use of PEAP cryptobinding (if the server allows this). That
said, I'd rather get the real issue figured out and fixed.

--
Jouni Malinen                                            PGP id EFC895FA