wpa_supplicant 2.12-1: WPA2-Enterprise EAP-TLS fails at 4-way handshake, 2.11 works

[Anil Kumar]

Hello,

I am experiencing what appears to be a regression in wpa_supplicant
2.12-1 compared to 2.11-5 on a WPA2-Enterprise / IEEE 802.1X network
using EAP-TLS.

The exact same Wi-Fi hardware, university network, certificates,
configuration, kernel environment, and NetworkManager setup works with
wpa_supplicant 2.11-5 but fails with 2.12-1.

Hardware:
    ASUS Zenbook
    Intel Wi-Fi 6E AX211 160MHz
    PCI device: Intel Meteor Lake PCH CNVi WiFi
    Driver: iwlwifi

Software:
    wpa_supplicant: 2:2.12-1 (failing)
    wpa_supplicant: 2.11-5 (working)
    NetworkManager: 1.58.1-1
    OpenSSL: 3.6.3-1
    Kernel: 7.1.5-arch1-2
    Distribution: Arch Linux

The EAP-TLS authentication itself succeeds. The TLS handshake completes,
the EAP state machine reaches SUCCESS, and the PMK is obtained and used
to derive the PTK/KEK/TK.

The failure occurs afterwards during the WPA 4-way handshake.

The sequence with 2.12 is:

    EAP-TLS authentication
        -> EAP-Success
        -> PMK obtained
        -> PTK/KEK/TK derived
        -> 4-way handshake starts
        -> RX EAPOL-Key 1/4
        -> TX EAPOL-Key 2/4
        -> control-port TX status: ack=1
        -> no EAPOL-Key 3/4 is received
        -> station is deauthenticated

Relevant log:

    WPA: Sending EAPOL-Key 2/4
    WPA: Send EAPOL-Key frame to <AP> ver=2 mic_len=16 key_mgmt=0x1
    WPA: EAPOL-Key MIC using HMAC-SHA1
    WPA: Derived Key MIC - hexdump(len=16): [redacted]
    WPA: TX EAPOL-Key - hexdump(len=125): ...
    nl80211: Send over control port dest=<AP> proto=0x888e len=125 no_encrypt=1
    nl80211: tx_control_port cookie=...
    nl80211: Control port TX status (ack=1)

No EAPOL-Key 3/4 is received after this.

About two seconds later the station is removed/deauthenticated:

    kernel: wlan0: deauthenticated from <AP> (Reason: 3=DEAUTH_LEAVING)
    nl80211: NL80211_CMD_DEL_STATION received
    nl80211: Delete station <AP>
    nl80211: NL80211_CMD_DEAUTHENTICATE received
    wlan0: CTRL-EVENT-DISCONNECTED ... reason=3

I also see:

    nl80211: _cmd_set_pmksa failed: -95 (Operation not supported)

The supplicant nevertheless continues into the 4-way handshake after
this, so I am not certain whether the PMKSA error is related.

I recently noticed upstream commit:

    7c1e798198f34e35a9a1d40c05e0ae34a595cd62

    "wpa_supplicant: Fix PMKSA caching with 802.1X 4-way handshake offload"

The commit specifically concerns driver-based 4-way handshake offload
with IEEE 802.1X and PMK handling. Since my failure occurs immediately
after successful 802.1X authentication and during the 4-way handshake,
I wondered whether this could be related to the same code path.

I am not certain that this commit is the fix for my issue, but the
similarity seemed significant enough to report.

The important reproducible difference is:

    wpa_supplicant 2.11-5 -> works
    wpa_supplicant 2.12-1 -> fails

The configuration and certificates are unchanged between the two
versions.

The failure is therefore specifically reproducible as a 2.11 -> 2.12
version change.

Thank you.