Advanced Wireless Access Security Settings

Navigation

Navigate using the tab icons. Hover over an icon to see the name of the tab.

Configure > Network Policies > policy_name > Wireless Networks > SSID_name > Additional Settings > Advanced Access Security Controls > Customize

Advanced Access Security Controls Overview

Select WPA / WPA2 802.1X (Enterprise), WPA / WPA2 PSK (Personal), or Private PSK under the SSID Authentication tab to see the Advanced Settings section. Here you can configure advanced access security controls based on the IEEE 802.11w standard. IEEE 802.11w establishes encryption protocols for APs to authenticate themselves to clients, and helps to secure the WLAN from various types of attacks, such as spoofing. You can configure and manage the encryption keys that are part of this process. To enable and configure the settings, select Customize. You can choose to use the default settings, or modify them if necessary.

Protected Management Frames

The IEEE 802.11w standard establishes a number of protections that APs can use to protect 802.11 managementframes from certain types of exploitation, such as reply attacks and deauthentication attacks. The standard also helps receiving APs verify the data integrity and the origin of the frame.

To support protected management frames, enable the feature. This is only available when you select WPA/WPA2 802.1X (Enterprise), WPA/WPA2 PSK (Personal) as the access security protocol.

Note

The IEEE 802.11w specification defines a way to protect management frames using encryption, but rather than encrypting the entire frame, devices use a MIC (MessageIntegrity Check), which is appended to the management frame. When the receivingstation receives the frame, it checks the MIC to determine whether it is valid or missing. If the MIC is valid,the frame is accepted; if invalid or missing, the frame is discarded. In addition to preventing malicious disconnections by spoofing, 802.11w also protects a number of actionframes that carry information regarding the state of the network, RF environment, and so on. Suchframes include spectrum and radio management frames, QoS, fast BSS transition, and block ACK frames.

Protected management frame.

In the illustration below, a valid network host makes a successful connection with a friendly AP while a rogue wireless client and a rogue AP cannot because the receiving station has determined that the MIC is missing, or is invalid. The MIC effectively prevents MITM (man-in-the-middle) malicious attacks.

Select Mandatory or Optional from the drop-down menu for protection on broadcast or multicast management frames such as beacons and probe requests.

Use 802.11w protection for broadcasts/multicasts: Select to use 802.11w protection on broadcast or multicast management frames such as beacons and probe requests. Select Save if you are done, or continue setting up the features in the Advanced Authentication Options section.

Advanced Authentication Options

In this section you can configure and manage the cryptographic keys used to encrypt Wi-Fi traffic during the four-way handshake authentication process between an AP and clients.

Configure Group Encryption Keys

Manage and set up Group Encryption Keys.

Generate new Group Master Key (GMK) after: Enter the time interval until a new GMK is generated. From the drop-down menu, choose seconds, minutes, hours, or days.

Note

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.

Generate New Group Temporal Key (GTK) after: Enter the time interval until a new GTK is generated. From the drop-down menu, choose seconds, minutes, hours, or days.

Note

The wireless client and Extreme Networks device use a GTK to encrypt to encrypt 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.

GTK Timeout Period: Set the interval that the device waits for client replies during the handshake process. The default value is 4000 milliseconds. 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.

Number of GTK Retries: Set the maximum number of times the device will retry sending GTK messages. By default, a device sends up to three GTK messages. You can change the number of tries to as few as 1 and as many as 10.

Configure Pairwise Transient Keys

Manage and set up Pairwise Transient Keys.

Generate a new Pairwise Transient Key (PTK) after: To enable PTK rekeying, select the check box 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. By default, the check box is cleared and PTK rekeying is disabled because not all wireless clients support it. 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.

PTK timeout period: Set the interval that the device waits for client replies during the four-way handshake in which they derive a PTK (pairwise transient key) for encrypting and decrypting unicast traffic. The default timeout value is 4000 milliseconds. 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.

Number of PTK retries: Set the maximum number of times the device will retry sending PTK messages. By default, a device sends up to three PTK messages. You can change the number of tries to as few as 1 and as many as 10.

Replay window: Set a window size within which the device accepts replies to previously sent messages during four-way handshakes. The default value of 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. You can change this to accept replies to up to the previous 10 messages sent.

Additional Settings

Configure additional features in this section. After you enable the features, or use the default settings, select Save.

Force the user to reauthenticate after: Enter an interval after which a user in an ongoing RADIUS session must reauthenticate. The reauth interval is not set by default for an SSID. To set it, select the check box, and enter a number between 600 seconds (10 minutes) and 86,400 seconds (24 hours).

If you set a reauth interval at the SSID level and the AP RADIUS authenticator (that is, the AP with which a user is associated) receives a Session-Timeout attribute from the RADIUS authentication server indicating a different reauth interval, the AP applies the interval it receives from the RADIUS authentication server. The AP authenticator only applies the SSID-level reauth interval when it does not receive a Session-Timeout attribute.

Note

If reauthentication and PTK rekeying occur at the same time, the AP will disconnect the client. This can eventually occur even if they have different values.

Local TKIP Countermeasure: (Available when the encryption method is Auto-TKIP or CCMP (AES) or TKIP.) Enabled by default. Select the check box 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 master 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.

Remote TKIP Countermeasure: (Available when the encryption method is Auto-TKIP or CCMP (AES) or TKIP.) Select the check box 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.)

Refresh GTK when client disassociates from the SSID: Clear the check box to refresh the GTK whenever a client disassociates from the SSID. Select the check box to set GTK rekeying to occur only when the rekey period elapses, regardless of whether any clients disassociate. By default, the check box is selected.

ConfigureWPA / WPA2 802.1X (Enterprise) Only

The following features are only available when WPA / WPA2 802.1X (Enterprise) is selected.

Enable Preauthentication (accelerates roaming): Disabled by default. Select the check box to enable APs hosting this SSID to support preauthentication. (To preauthenticate itself on other APs, the station sends IEEE 802.1X EAPOL-Start messages in frames using EtherType 88-C7 through the AP with which it is currently associated to the other APs. When you enable preauthentication support, the APs recognize these messages and forward them over their wired or wireless backhaul links to each other.) To disable preauthentication support, clear the check box.

Preauthentication is a means of accelerating roaming when using WPA2 with 802.1X authentication. After a client forms an association and completes the full IEEE 802.1X authentication process with an AP, it can then preauthenticate itself with other APs. The client and these APs store a PMK (pairwise master key) for use when the client roams and associates with another AP. Because the client and the APs already have PMKs, they can then reduce the full IEEE 802.1X authentication process to just the four-way handshake used to derive PTKs (pairwise transient keys). This reduces the roaming time to about 1/10th of a second, as opposed to the more than one second required to perform the complete procedure.

Note

Preauthentication is only an option when the SSID uses WPA2-EAP(802.1X) or Auto-(WPA or WPA2)-EAP(802.1X) as the key management method.

Enable Proactive PMK-ID response (uses cached PMKs to supports fast roaming with certain clients):

(Disabled by default.) When you enable the proactive PMK ID response option, the AP tries to use a cached PMK even if the client sends an empty PMK ID list. If the list is empty and the AP has a cached PMK for the client, it proceeds to the four-way handshake using its cached PMK. The client might accept the PMK and continue with the four-way handshake, bypassing the 802.1X authentication process; the client might ignore the PMK ID from the AP and insist on performing 802.1X authentication all over again; or the client might not be able to support receiving an unsolicited PMK and the entire process might come to a halt. Consequently, your decision to enable this feature or not depends on the types of clients that will be using your WLAN.

The contents of the PMK ID list vary depending on the vendor. The table below shows what some popular wireless clients send and how they respond when the AP sends them a PMK ID they did not request:

To support other wireless clients, enable or disable this feature as appropriate based on how they respond to unsolicited PMK IDs that access points send them.

Note

Disabling the proactive PMK ID response does not disable support for fast roaming. It only stops APs from proactively including cached PMK IDs in their responses to clients that do not include them in their reassociation requests.

When you have completed your changes, select Save.