Driver cannot safely Rekeying with 801.1x

The warning message will appear in logread, when I use 2 devices (WiFi clients) with the same username/password authentication with 801.1x (WPA2 Enterprise):

Thu Apr 15 00:18:49 2021 kern.warn kernel: [14772.396669] Rekeying PTK for STA xx:xx:xx:xx:x:x2 but driver can't safely do that.

No anomalies during using the 2 different devices, what I am asking is, what's the best practice of using WPA2 Enterprise? Probably each device should have it's own username/password pair?

Edit: Just found that the warning messages did not only appear when more than 2 devices are connected to the WiFi, it will appear even when only 1 device connected.

Anyone know what does this warning message means? Should I be worried or should I take any measure to avoid it?

Honestly that rekeying does not seem to work at all...

Search for eap_reauth_period, and you see the mess. Normally every hour the key should be exchanged, but to my understanding there are many clients not supporting this, and then the result is, that the client appears still connected but has no connectivity.

The only suggested solution I found from googling is to extend this rekeying intervals, which of course weakens security.

Another option might be an automated scheduled regular disconnect, hoping he client has autoconnect set and connects again immediately. But this is not a comfortable option.

I have extended this interval to 12h in my network.

Tried disabling the following option in /etc/config/wireless

        option wpa_disable_eapol_key_retries '1'

and the warning message seemed disappear.

As I understand, the key reinstallation attacks the option supposed to mitigate, is actually against client. Not sure if this option is a 'must' for wireless settings nowadays.

Ummm...that isn't the default in OpenWrt. It's 5 minutes. You can adjust this to 1 hour (or one day), by setting option wpa_group_rekey '86400'

  • One hour == 3600 seconds
  • One day == 86400 seconds

I had issues with 5 minutes...a lot of other OSes use an hour or a day, so I picked them.

1 Like

yes, you are right, the 3600 I did not find in OpenWrt sources. Interestingly I do not find anything in the openwrt sources except;a=commitdiff;h=4689bc8517d0387b75f3ff42c42444dd403a4847

Is there a way to find this 5 min default ?

1 Like

My bad, I assumed it was easily locate-able:

The re-key option is valid in WPA2 Personal (and other modes) also - nonetheless, the default is noted as 600 seconds (which I stand corrected - the default is 10 minutes).

I worked on that setting too! :wink:

1 Like

Now I am a little bit lost. Looks like I misunderstood wpa_group_rekey and eap_reauth_period. I initially thought, wpa_group_rekey would only apply to WPA2/PERSONAL, but not to WPA2/ENTERPRISE, but it looks like it is used in both, eap_reauth_period is only used for WPA2/ENTERPRISE.
I am just wondering that I do not find any C-code-places where these are used, to hopefully see how they are really used.
I only find, which to my understanding is used by openwrt while parsing the openwrt config files to create the correct hostapd...conf file used to parameterize hostapd. But the source code of hostapd itself I could not find.

Read from that @alexw65500 suggested disable rekeying by:

option eap_reauth_period '0'

with EAP-TLS configured APs, due to not being able to correctly Rekeying could cause more serious safety issues.

It's probably a workaround, but is there an solution to this problem?

BTW, my AP is a D-Link DIR-860L B1 with mt76 wifi drivers, not sure if the driver is able to handle Rekeying correctly, or safe enough though.

Edit: Another confusion is that, what is the difference between WPA group rekey and EAP reauth, does disabling EAP reauth really hurt security with 801.1x?

1 Like

Googled a little bit, and found the meaning of the 2 options as follow:

             Time interval for rekeying GTK (broadcast/multicast encryption
             keys) in seconds.

             EAP reauthentication period in seconds.  To disable
             reauthentication, use "0".

so they are quite different. Set eap_reauth_period to 1 hour actually didn't cause any trouble for now for most of my devices, just not clear if the warning message should be worried enough to be taken care of.

Edit: Just encountered an episode, logread as follow:

Tue Apr 20 21:32:23 2021 hostapd: wlan1-1: STA xx:xx:xx:xx:xx:xx WPA: group key handshake completed (RSN)
Tue Apr 20 21:32:31 2021 daemon.notice hostapd: wlan1-1: CTRL-EVENT-EAP-STARTED xx:xx:xx:xx:xx:xx
Tue Apr 20 21:32:31 2021 daemon.notice hostapd: wlan1-1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
Tue Apr 20 21:32:34 2021 daemon.notice hostapd: wlan1-1: CTRL-EVENT-EAP-RETRANSMIT xx:xx:xx:xx:xx:xx
Tue Apr 20 21:32:40 2021 daemon.notice hostapd: wlan1-1: CTRL-EVENT-EAP-RETRANSMIT xx:xx:xx:xx:xx:xx
Tue Apr 20 21:32:52 2021 daemon.notice hostapd: wlan1-1: CTRL-EVENT-EAP-RETRANSMIT xx:xx:xx:xx:xx:xx
Tue Apr 20 21:33:12 2021 daemon.notice hostapd: wlan1-1: CTRL-EVENT-EAP-RETRANSMIT xx:xx:xx:xx:xx:xx
Tue Apr 20 21:33:32 2021 daemon.notice hostapd: wlan1-1: CTRL-EVENT-EAP-RETRANSMIT xx:xx:xx:xx:xx:xx
Tue Apr 20 21:33:32 2021 daemon.notice hostapd: wlan1-1: CTRL-EVENT-EAP-SUCCESS2 xx:xx:xx:xx:xx:xx
Tue Apr 20 21:33:32 2021 hostapd: wlan1-1: STA xx:xx:xx:xx:xx:xx IEEE 802.1X: authenticated - EAP type: 13 (TLS)
Tue Apr 20 21:33:33 2021 hostapd: wlan1-1: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Tue Apr 20 21:33:33 2021 kern.warn kernel: [97334.020607] Rekeying PTK for STA xx:xx:xx:xx:xx:xx but driver can't safely do that.

It seems there were several CTRL-EVENT-EAP-RETRANSMIT before the warning message, when the iPhone was not being used.

As long as you never encounter disconnects or connection loss at that mark it's nothing to worry (much) about. This warning just means that the driver of your card has not confirmed that it is able to handle PTK rekey (Unicast) correctly. It still may handle that fine, though.

It depends what your security requirements are. With EAP you can give each user a unique key and even users with access can't decrypt frames intended for other users. But you can also set up a guest WLAN with a shared password changing in frequent intervals or so... Many use it just to have one user allowing access to both the OS and the WLAN. Which still allows a user to connect multiple devices with his single account.

As for the default setting of eap_reauth_period:
That is a default in hostapd and it's e.g documented in the "official" hostapd.conf.
But do not set that to 1 or other any small number: An "normal" eap rekey is (comparable) slow and when the link is in use you always lose packets. Doing that every second will cause a horrible impact. (Not tested it, but I would expect that the download speed drop to a few kB/s regardless how modern your router/cards are.) Doing that in larger networks will also DDOS your Radius server(s)...
Even using 60 is probably slowing down the download already quite a bit, especially for fast connections.

wpa_group_rekey only affects broadcast traffic the AP sends out. Even when that breaks when rekeying the GTK key chances are good you won't even notice it.

Here a quick interpretation what I think of your log, too:

  1. 21:32:23 the GTK key was replaced (successful)
  2. 21:32:31 - 21:33:32 Looks to me like a normal EAP communication where for some reason the client is no responding for quite some time. That should basically only be a Client <-> Radius server communication the AP is passing through without caring what they are talking about.
  3. 21:33:32 the Radius handshake finally completes successful and all the following lines are to be expected by a normal PTK install when you rekey with a driver not confirming it supports that.

So it looks like for some reasons the client was not responding to the EAP handshake for one minute but finally did...
Now if that was just bad connectivity or something else can't be deduced from the log.

But it's not an indication that PTK or GTK rekeying itself is not working for you: GTK is not needed for the communication and the PTK was still the old one for those packets.

Lastly PTK rekeying is nearly always only time based. They happen regardless if you are using a device or not and only depend on how old the current PTK key is. There are exceptions, but when you are not using TKIP the client itself has to ask for it for some reason. (Which is possible but rare.)

GTK rekeying can happen when a station drops from the network, depending on your settings.
Other than that it's also a time based issue.

1 Like

I also have this, but only with one device (mobile phone, Mi8 lite [platina]) which hourly drops off my WPA2-EAP RADIUS authed WiFi network. I also see the RETRANSMIT lines in the logread output.

I've already tried setting "wpa_disable_eapol_key_retries" from 1 to 0 but it didn't solve the problem. According to

I'll now try to work around the problem by setting:

option eap_reauth_period '0'

Update: Seems to work since I set it and solves my problem.