Customize Advanced Access Security Settings

About this task

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.

Procedure

  1. 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.
  2. 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.
  3. 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.
  4. For Number of GTK Retries, set the maximum number of times the device will retry sending GTK messages.
  5. 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

    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.
  6. 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.
  7. For Number of PTK retries, set the maximum number of times the device will retry sending PTK messages.
  8. 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.
  9. 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.
  10. 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.
  11. Deselect Refresh GTK when client disassociates from the SSID to refresh the GTK whenever a client disassociates from the SSID.