The latest wpa_supplicant package for Fedora 28 includes compile-time support for PMF (Protected Management Frames). This is a good thing, as it protects against a set of WiFi replay attacks. However, a small number of users reported WiFi connectivity problems after an upgrade to Fedora 28. If you read this post, you can learn how to troubleshoot that connection, and possibly feel less frustrated.
Disabling PMF can be a viable workaround. But it’s possible to understand more deeply where the failure is happening. Ideally, you can find a software fix for those issues, and still keep the advantage of improved security.
How does PMF work?
PMF protects WiFi connections against replay attacks on Robust Management Frames. For example, it prevents a rogue access point sending spoofed Deauth frames from disconnecting a “victim” node. The protection consists of a MIC (Message Integrity Check), computed by a PMF-capable transmitter and written on each outgoing Robust Management Frame (e.g. a Deauth frame). A PMF-capable receiver is then allowed to discard those frames, if the MIC verification fails.
The key used to generate / verify MICs, named IGTK (Integrity Group Temporary Key), is shared among the group of nodes belonging to the network. Access points regularly update the IGTK using EAPOL packets, same as with the GTK (Group Temporary Key) to encrypt the content of broadcast frames. Similarly, clients and Access Points negotiate the cipher used to generate and verify MICs using the RSN (Robust Security Network) element of EAPOL packets, as happens with the cipher used to encrypt broadcast frames.
Trying it on Fedora
Since version 1.10, NetworkManager exposes the 802-11-wireless-security.pmf property to configure PMF. Within the kernel, support for PMF relies on the underlying wireless chipset capabilities, and on the driver implementation. Users can query Linux to see if their wireless adapter supports at least one of the algorithms used for MIC generation/verification. With iw, you can check if at least CMAC or GMAC is available:
$ iw phy0 info | grep -A9 'Supported Ciphers' Supported Ciphers: ... * CMAC (00-0f-ac:6) * GMAC-128 (00-0f-ac:11) * GMAC-256 (00-0f-ac:12)
Until wpa_supplicant had compile-time support for PMF, kernel drivers were never instructed to generate or verify the MIC on Robust Management Frames. Everything behaved just as if PMF were disabled in the NetworkManager configuration. Starting from version 2.6-15.fc28, though, wpa_supplicant tries to install the IGTK in the driver as soon as it connects to a PMF-capable access point.
good or bad news?
Some drivers just don’t support any of the cipher suites required to validate or generate MICs. In this case, an attempt to connect to the Access Point fails if PMF is negotiated. Reading the client log, the following error messages appear:
wpa_supplicant: wlp2s0: WPA: Failed to configure IGTK to the driver kernel: wlp2s0: deauthenticating from by local choice (Reason: 1=UNSPECIFIED) wpa_supplicant: wlp2s0: RSN: Failed to configure IGTK
This usually happens when Linux was unable to find the cipher suite that wpa_supplicant negotiated with the access point. If the connection was successful before upgrading to Fedora 28, there’s good news: you can recover by disabling PMF. The following command fixed most of the reported issues:
$ nmcli connection modify wifi-sec.pmf disable; nmcli connection up
The bad news is this wireless NIC does not support PMF. At least, it does not support the cipher suite required by the access point.
Now that a workaround is known, here are some ways the overall PMF experience can improve:
- Patch userspace agents (NetworkManager or wpa_supplicant, or both) to check the NIC capabilities, and match better with the access point configuration. This wouldn’t solve all the issues above, as there might still be access points requiring a cipher not available on the client. But in this case, wpa_supplicant would refuse to attempt the connection, in accordance to the current standard. Moreover, it would also report a more meaningful message in the log, thus helping the user to fix settings in the access point. At least it’s better than attempting the connection and terminating it with an error on reception of EAPOL 3 / 4.
- Fix wireless drivers not implementing PMF correctly, as we did recently on the mt7601u. Linux is usually able to seamlessly implement in software those cipher suites that can’t run in hardware. Therefore, unless the chipset has a limitation in its hardware or firmware, PMF should be available on the majority of wireless adapters.
Special thanks for the material in this article go to Beniamino Galvani, Lorenzo Bianconi, Francesco Giudici, and all Bugzilla reporters.
Image courtesy of russellstreet, via Flickr (CC BY-SA 2.0).
Thanks for the great article!
How do you do “Reading the client log”? Is it using systemctl?
The rest of the examples are very helpful because the command used is also shown.
Paul W. Frields
@Jorge: Generally you can read system logs with the journalctl command. This one will help cut down the output for something you’re looking for in today’s logs:
Is there anyway to check if PMF is supported on the AP or my client is using PMF for the connection?
I have a Intel Corporation Wireless 3165 and it shows
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP-128 (00-0f-ac:4)
* CMAC (00-0f-ac:6)
Available Antennas: TX 0 RX 0
Supported interface modes:
Not sure if I’m using PMF for improved security?
@Mr Casa: that NIC theoretically supports PMF since it can do CMAC. Understanding if your Access Point also supports MFP is more tricky: theoretically, you can do it with d-bus inspecting the values of the latest scan. In practice, it’s easier (for me 🙂 ) to attempt the connection with verbose logging enabled in wpa_supplicant:
# ip link set dev wlp4s0 down
# ip link set dev wlp4s0 up
# journalctl -u wpa_supplicant --system --since today | grep 'MGMT group cipher'
if PMF is being used, you should find something a message like
Does this mean using pmf is safer than others? wont leak any info?