Rekey Interval

[Francisca Noggles]

What I infer from this is that the Orbi product does not constantly reset the WPA key. I confess to not understanding much about WPA-PSK. What I sense is that there is some mechanism built into the WPA standard for the access point and device to update the shared key without losing conection which would mean that someone snooping on the WiFi stream would be collecting packets where the key changes every so often and this would make cracking the encryption exponentially more difficult.

Hi, thanks to both of you who replied. I'm debugging a connected device, which has an issue with frequent disconnects on a different router (an ISP provided router). But this same device works well on the Orbi. My thought was the disconnects are occuring when the key is changed. What I see from the Orbi debug menu, and the settings shown by "nvram show" is that all the rekey intervals are 0. This means no key changes. And this lines up with my experience that the device works well with Orbi, but not on the other router that changes the key frequently.

It is not problem for me now as I exchanged USB dongles with PCI card, but before on USB dongles WIFI it was REALLY ANNOYING issue. I would update my wireless config accordingly but if it will be proven to correct this unwated behaviour, maybe it should be retrofitted into turris default configuration.

"If a mobile device chooses to leave the Wi-Fi LAN, it should notify the access point by sending an IEEE 802.11 disassociate message. When it does this, the access point erases the copy of the pairwise keys for the departing mobile device and stops sending it messages. If the device wants to rejoin later, it must go through the whole key establishment phase from scratch. But what about the group key? Even though the device has left the network, it can still receive and decrypt the multicasts that are sent because it still has a valid group key available. This is not acceptable from a security standpoint; if a device leaves the network, it should no longer be allowed any access at all.

Well I understand this point. But now I suspect that I experienced such disconnect with macbook running for couple days and in sleep mode as well as android phone even on PCIE WIFI card. So going to update my wireless network configuration accordingly but even it is not manageable in LuCI not everyone put such effort and knowledge into investigation of this issue like @blbeczech82 hence other blame guess what ? whole device itself. There should be some troubleshooting page in official documentation where this will be mentioned.

May be a pain to get the most recent version of hostapd to work on the turris, but it should be fairly easy to cherry-pick just that commit and backport it. It does depend on a new struct member wpa_group_rekey_set which causes it to be binary-incompatible, so that will need to be worked around somehow.

Can You please add one more thing on GitHub. I don 't have my login on github at hand. If the team decided to leave TKIP for some reason. MacOS also disconnects when someone tries to hack into your network. AFAIK This behavior is not the same in Windows. So despite that I manually change to CCMP. So, when I want to then set up a new password in Forris, I have to go back to LuCI and change from TKIP + CCMP on CCMP.

When using WPA, the keys used to encrypt and authenticate unicast traffic between a wireless client and AP change automatically. This is called rekeying. The rekey interval is 3600 seconds. If your SSID is configured to use WPA2-Enterprise with 802.1X authentication, you will see rekeying events for connected wireless clients appearing in the Meraki Event log every hour. This is normal behavior. Notice the timestamps on the logs below.

When WPA2-Enterprise with 802.1X authentication is used, the Pairwise Master Key (PMK) is derived from the 802.1X process. The PMK is computed by the RADIUS server and returned to the AP. The PMK is used to create temporal keys used for actual frame authentication and encryption. Therefore the wireless client must perform 802.1x authentication at the rekeying interval to derive new temporal keys, unless there is an over-ride setting of session-timeout at the RADIUS server. If there is such a session-timeout, Meraki APs will honor that setting.

When WPA2-PSK (shared network key) is used, the Pairwise Master Key (PMK) is configured as a shared secret on the wireless client and AP. The PMK is used to create temporal keys used for actual frame authentication and encryption. Therefore, WPA rekeying will occur between the wireless client and AP every hour to derive new temporal keys.

Since the release of vSAN 6.5.1, the PowerCLI team has introduced a number of high level vSAN cmdlets (current list HERE) that can be used to automate a variety of tasks. While the existing vSAN cmdlets are quite extensive and continues to get updated with new functionality, it will never be able to cover the rich set of functionality that is provided by vSAN.

For functionality that is not available in the high level vSAN cmdlets, user can still perform the task using PowerCLI, but they will need to directly access the underlying API, in this case the vSAN Management API.

Note: This concept also applies to other high level PowerCLI cmdlets, if you are unable to locate the functionality, then most likely you will need to interrogate the API using PowerCLI.

In the case of retrieving the vSAN Data-in-transit encryption rekey interval, which is not available in the high level Get-VsanClusterConfiguration cmdlet, we can easily retrieve it with the following PowerCLI snippet:

The DataInTransitEncryptionConfig property contains two fields: enabled and rekeyInterval, the latter being what we are interested in. If you have enabled data-in-transit encryption, the rekey interval is defined in minutes with the default being 1440 (24hrs) and the minimum value is 30 (30 minutes) with maximum of 10080 (7 days).

William is Senior Staff Solution Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. He focuses on Cloud Native, Automation, Integration and Operation for both VMware vSphere Foundation (VVF) & VMware Cloud Foundation (VCF) across Private, Hybrid and Public Cloud

I have a Netcomm NB6Plus4W wireless modem and I'm using WPA2-PSK. For WPA2-PSK, the default option for "WPA Group Rekey Interval" is "0". Surely this value has to be something non-zero? Wireless seems to be working, as I assume is wireless security! So what does this "0" mean and do I need to change it?

I think a rekey value of zero actually prevents the AP from changing keys at all. This is bad because it reduces the security. It would prevent drop outs from wireless cards that aren't properly implementing TKIP / AES though...

I'm having a bit of a problem with my modem. I'm still experimenting but it seems that sometimes when I turn on my pc and modem in the morning, my pc is not able to access the web via wireless. Its sort of strange as my wireless card software says I'm connected at 54mbps but I can't get any web pages to come up on my web browser (there is no data flow). If I then turn the modem off and then on, this seems to cure the problem. I initially thought it may have to do with the group rekey option but I have tried both 0 and 3600. Does anyone know why this might be happening?

If you turn on both modem and pc at start up, I would suggest you try leaving the modem running and turn on just the pc. See if that helps.
Otherwise the issue is probably drivers for the wireless card not correctly handling the type of security you have setup. Either try another card or another sort of security. WPA -TKIP is fine for the moment at least unless the new cracking method gains momentum. AES tends to work poorly on older cards. WPA2 can also have issues depending on OS and wireless management utility you use.

We want to change the rekey value to 8 hours to see if this will fix our issues.
In the IPsec policies section, I can change the rekey interval but I cannot choose in the IPsec (remote access) settings which policy will be used. Will the default IPsec policy be used? Or must I configure these settings at another level?

The keys negotiated for IKE SAs and IPsec SAs should only be used for a limitedamount of time. Additionally IPsec SA keys should only encrypt a limited amountof data. This means that each SA should expire after a specific lifetime or aftera specific data or packet volume. To avoid interruptions, a replacement SA needsto be negotiated before that happens. This is called rekeying.

In comparison to IKEv1 which only supports reauthentication (see below), IKEv2provides proper inline rekeying of IKE SAs by use of CREATE_CHILD_SA exchanges.This means that new keys may be established without any interruption of theexisting IKE and IPsec SAs.

This is the default behavior of the IKE daemon whenreauthenticating an IKEv2 SA. It means that all IKE_SAs and CHILD SAs aretorn down before recreating them. This will cause some interruptions duringwhich no IPsec SAs are installed. If trap policies are used it could alsotrigger unnecessary acquires and hence duplicate IPsec SAs during that downtime.To prevent plaintext traffic from leaving the host appropriate firewall rulesor drop policies may be used.

This method first creates duplicates of the IKE SAs and all CHILD SAsoverlapping with the existing ones and then deletes the old ones.This avoids interruptions but requires that both peers can handle overlappingSAs (e.g. in regards to virtual IPs, duplicate policies or updown scripts).It is supported for IKEv2 since version 5.3.0 but is disabled by defaultand may be enabled by explicitly setting

c80f0f1006