Use this task to configure and manage the cryptographic keys used to encrypt Wi-Fi
traffic during the four-way handshake authentication process between an AP and
clients, manage and set up Pairwise Transient Keys.
-
For Generate new
Group Master Key (GMK) after, enter the time interval until a
new GMK is generated.
The GMK is a large random number that an Extreme Networks device chooses. From
the GMK, the device derives a GTK (Group Temporal Key), which it then sends to
all associated clients within EPOL-key messages. The Extreme Networks device and
clients use the GTK to encrypt and decrypt broadcast or multicast traffic
transmitted between themselves.
-
For Generate New Group Temporal Key (GTK) after, enter
the time interval until a new GTK is generated.
The wireless client and Extreme Networks device use a GTK to encrypt to and
decrypt broadcast and multicast traffic transmitted between themselves. A GTK is
a temporal key that an Extreme Networks device derives from a GMK (Group Master
Key) by performing a cryptographic hash on the concatenation of the GMK, a
nonce, and the MAC address of the Extreme Networks device. The Extreme Networks
device then sends the GTK to all associated clients within EAPOL-Key
messages.
-
For GTK Timeout Period, set the interval that the device
waits for client replies during the handshake process.
To accommodate clients that have shorter or longer timeout values, you can
change this to a value from 100 (the standard timeout value) to a maximum of
8000 milliseconds.
-
For Number of GTK Retries, set the maximum number of
times the device will retry sending GTK messages.
-
Select Generate a new Pairwise Transient Key (PTK) after
to enable PTK rekeying, and enter a value between 10 and 50,000,000 seconds
(~231 days).
If you enable PTK rekeying, an interval between 2 and 10 minutes (120 and
600 seconds) is the best practice recommendation, which is short enough to
thwart the known TKIP exploit. Enable this option only if you know that the
clients using the SSID support it. (In addition to configuring PTK rekeying
on devices, it might also need to be enabled on the clients.)
Note
There is a flaw in TKIP that allows an attacker to decrypt unicast packets
sent from an access point to a wireless client, and then send the
client-forged packets, possibly with the purpose of poisoning ARP or DNS
caches. If it is not possible to transition to AES-CCMP—which is not
susceptible to this attack—you can mitigate attacks against TKIP-encrypted
data by setting the PTK (pairwise transient key) to rekey at short
intervals.
-
For PTK timeout period, set the interval that the device
waits for client replies during the four-way handshake in which they derive a
PTK for encrypting and decrypting unicast traffic.
To accommodate clients that have shorter or longer timeout values, you can
change the value from 100 milliseconds (the standard timeout value) to a maximum
of 8000 milliseconds.
-
For Number of PTK retries, set the maximum number of
times the device will retry sending PTK messages.
-
For Replay window, set a window size within which the
device accepts replies to previously sent messages during four-way handshakes.
0 indicates that the device does not accept any messages other than a reply to
the last message that it sent. You might want to accept replies to previously
sent messages if there are clients that reply more slowly than the device
retries sending it messages.
-
Select Local TKIP Countermeasure (available when the
encryption method is Auto-TKIP or CCMP (AES) or TKIP) to enable or disable the
deauthentication of all clients when the local device detects message integrity
check failures during TKIP operations.
Even if just one key fails an integrity check, the discovery of such a failure
suggests that other keys in current use might also be compromised. The cautious
security stance is to deauthenticate all clients and stop using all existing
keys immediately. When clients reauthenticate, they use newly generated pairwise
and group primary and temporal keys. If this feature is disabled, the device
continues to use its existing keys and maintain currently connected clients
after detecting MIC failures.
-
Select Remote TKIP Countermeasure (available when the
encryption method is Auto-TKIP or CCMP (AES) or TKIP) to deauthenticate all
previously authenticated clients when a client reports MIC failures during TKIP
operations.
The distinction between the local and remote countermeasure options is where
the discovery of the failure occurs: local = the device discovered it, remote =
the client discovered—and reported—it.
-
Deselect Refresh GTK when client disassociates from the
SSID to refresh the GTK whenever a client disassociates from the
SSID.
