Skip to main content
Cisco Meraki Documentation

PMKID Vulnerability FAQ - WPA/WPA2-PSK and 802.11r

Overview

On August 4th, 2018,  a new method to exploit a known vulnerability was announced for wireless networks that use WPA/WPA2-PSK (pre-shared key). The vulnerability allows attackers to obtain the PSK being used for the particular SSID. The vulnerability affects most wireless vendors using roaming technologies - including Cisco Meraki. For an overview of how Meraki helped its customers, please refer to our blog. For any additional information, please refer to this FAQ page.

 

SSIDs using PSK have traditionally not been considered as secure since the PSK used for different clients is the same and dictionary attacks can be used to crack passwords easily.  PSK is also prone to social engineering attacks. It is recommended that customers check their networks to ensure that fast roaming technologies are disabled.

 

As part of the attack, an attacker can target the reassociation process to obtain the unique primary key ID used for the specific client. The primary key ID is derived from primary key (a function of PSK) and name, AP MAC and client MAC. Since primary key is derived from PSK and other details can be easily obtained, an attacker can obtain the key. This attack uses a dictionary attack to determine the PSK being used and hence, it is highly recommended to use strong passwords that are not susceptible to guessing attempts.

 

FAQ

What is targeted to execute this attack?

The attacker targets the management frames used during roaming to obtain the PMKID used for each client. PMKID is cached on APs for enhanced roaming.

 

What is PMKID and why is it used?

PMKID is the unique key identifier used by the AP to keep track of the PMK being used for the client. PMKID is a derivative of AP MAC, Client MAC, PMK and PMK Name

 

What is PMK caching? Why is it important?

PMK caching is used to establish smooth roaming for time sensitive applications. Using PMKID caching the clients do not have to go through the entire authentication cycle and cuts down on the time needed for the client to authenticate to the new AP. This is especially important on WPA/WPA2 - Enterprise networks that have authentication times of almost 1 second depending on authentication type being used.

 

Which authentication methods use PMK caching and when are they used?

Almost all fast roaming technologies use PMK caching. Meraki uses PMK caching for the following:

  1. 802.11r - Client is roaming to a new AP

  2. OKC - Client is roaming to a new AP

  3. PMK Caching - Client is roaming back to an AP it was previously associated to

 

Are all roaming technologies affected on Meraki APs?

No, only using WPA/WPA2-PSK with 802.11r will make networks vulnerable when using Meraki APs.

 

Which WPA authentication methods are vulnerable?

Only WPA/WPA2-PSK is vulnerable. It does not matter if WPA or WPA2 is being used as the attack is against key management thereby making the ciphers irrelevant. SSIDs using WPA/WPA2-Enterprise are not vulnerable as PMK is derived dynamically by the RADIUS server instead of being a function of PSK.

 

Is PMKID caching needed for WPA/WPA2-PSK?

No, although, PMKID caching reduces the time needed to authenticate even with a PSK SSID, the reduction in time is not significant and has no real advantages. The number of frames for authentication goes down from 4 to 2 if PMK caching is used. Using PMKID caching WPA/WPA2-Enterprise results in significant reduction in authentication time.

 

Is WPA/WPA2-PSK no longer safe?

While the base attack used is a dictionary attack, and has been around since WPA was announced, this vulnerability makes it easier for the attacker to gather information for the dictionary attack.

 

How can I protect my networks from this vulnerability?

It is recommended to disable 802.11r on WPA/WPA2-PSK networks. Affected customers can leverage the tool available under Notifications > KRACK & PMKID Vulnerability Impact to disable 802.11r on networks that are affected by this vulnerability.

 

Are MX-W products affected?

No. MX-W products do not support the configuration option that is vulnerable.

  • Was this article helpful?