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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
