EAP-TLV: Earlier failure - force failed Phase 2

[Adam Jacobs]

ajacobs at jeremiah:~$ openssl version
OpenSSL 1.0.2d 9 Jul 2015



I'll create a temporary user account and reproduce the error, and then blow it away, so I can safely demonstrate the error and send you all the private details.




Adam

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

On Mon, Jan 04, 2016 at 07:29:02PM -0800, Adam Jacobs wrote:
> Okay, here's some better logging showing the failure.  I reproduced this by starting wpa_supplicant manually, with the same flags as DBUS uses plus -dd.  It does appear the problem is cryptobinding-related.

Thanks!

> Also, the failure seems to happen pretty consistently after around 30 minutes.

It looks like the AP has been configured to perform EAP reauthentication
after that time, i.e., the trigger for this is in the reauthenticating
initiated by the AP here:

> 1451963729.285691: wlan0: RX EAPOL from 3c:0e:23:8e:48:3f
> 1451963729.285880: EAP: EAP entering state RECEIVED
> 1451963729.285907: EAP: Received EAP-Request id=1 method=1 vendor=0 vendorMethod=0
> 1451963729.285923: EAP: EAP entering state IDENTITY

The initial EAP authentication for the connection was not included in
this log, so I cannot check what happened there, but I'd assume it did
use TLS v1.2 and cryptobinding successfully and the issue is only in the
case of using cryptobinding during the reauthentication sequence and
more specifically, when using TLS session resumption for fast
reauthentication with TLS v1.2 and cryptobinding enabled.

It looks like the OpenSSL build used here is somehow lacking debug
information and since wpa_supplicant is not exposing private
password/key related material without -K on the command line, I cannot
check what exactly happens here. Anyway, it is obvious that the failure
is in the authentication server and wpa_supplicant coming up with a
different Compound_MAC value in this TLS v1.2 + TLS session resumption
case.

Would it be possible for you to produce a debug log that a test account
for which you could expose the password in the wpa_supplicant debug log?
It's fine to send such a log directly to me instead of the public
mailing list. I would like to see both the initial authentication and
the failing reauthentication with -ddKt on wpa_supplicant command line.
That -K there will expose all the private material like keys and
passwords, so obviously this should not be done in a production system
with a real user account that was either used with the same password in
the past or will be used in the future.

Could you please also confirm that you are using the OpenSSL version
from the distribution (I think Ubuntu 15.10 uses OpenSSL 1.0.2d)? There
has been issues in TLS v1.2 key derivation with some OpenSSL versions,
e.g., the one included in Ubuntu 14.04 is broken in this area and could
cause something like this.. OpenSSL 1.0.2d on the other hand does not
have known issues with this.

It would also be helpful if you would be able to generate a
wpa_supplicant debug log with TLS v1.2 disabled.

Unfortunately, the current Microsoft [MS-PEAP] specification seems to
have a step missing from key derivation for this exact issue area. I'm
not completely sure where I got the earlier description (either an older
version of that spec or some IETF draft for PEAPv2, I guesS), but
anyway, if that worked with TLS v1.0, it sounds like there is something
going wrong with TLS v1.2 which is the main new change here based on
your description on the issue showing up after the upgrade.

--
Jouni Malinen                                            PGP id EFC895FA