Vulnslist

Workaround for CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, and CVE-2017-13081 Limiting the maximum number of Extensible Authentication Protocol (EAP) over LAN (EAPoL) key retries to 0 has been determined to be a valid workaround for these vulnerabilities. Setting the EAPoL retries value to 0 means one message will be sent, there will be no retransmissions sent, and if the EAPoL timeout is exceeded the client will be removed.

This workaround can be configured at the global level or at the individual wireless LAN (WLAN) level. Please note that the option to configure this workaround at the WLAN level is only available on Cisco WLC releases 7.6 and later. Previous releases only allow configuration at the global (all WLANs) level.

In order to configure this workaround at the global level (for all WLANs), use the following command in the WLC CLI:
config advanced eap eapol-key-retries 0

The command show advanced eap can be used to verify the configuration change is now active on the device (in bold on the following example output):

(wlc-hostname)> show advanced eap
EAP-Identity-Request Timeout (seconds)........... 30 EAP-Identity-Request Max Retries................. 2 EAP Key-Index for Dynamic WEP.................... 0 EAP Max-Login Ignore Identity Response........... enable EAP-Request Timeout (seconds).................... 30 EAP-Request Max Retries.......................... 2 EAPOL-Key Timeout (milliseconds)................. 1000 EAPOL-Key Max Retries............................ 0 EAP-Broadcast Key Interval....................... 120

In order to configure this workaround for a specific WLAN, the following two commands should be entered in the WLC CLI:
config wlan security eap-params enable WLAN-NUMBER
config wlan security eap-params eapol-key-retries 0 WLAN-NUMBER
Both commands must be entered and WLAN-NUMBER should be replaced with the actual WLAN number. In the following example, the workaround is being implemented on WLAN number 24:
config wlan security eap-params enable 24
config wlan security eap-params eapol-key-retries 0 24

The command show wlan WLAN-NUMBER (where WLAN-NUMBER is replaced with the appropriate WLAN number) can be used then to verify the configuration change is now active on the device (in bold on the following example output):
(wlc-hostname)> show wlan 24
WLAN Identifier.................................. X Profile Name..................................... ftpsk Network Name (SSID).............................. ftpsk . . . Tkip MIC Countermeasure Hold-down Timer....... 60 Eap-params.................................... Enabled EAP-Identity-Request Timeout (seconds)..... 30 EAP-Identity-Request Max Retries........... 2 EAP-Request Timeout (seconds).............. 30 EAP-Request Max Retries.................... 2 EAPOL-Key Timeout (milliseconds)........... 1000 EAPOL-Key Max Retries...................... 0

Note: Implementing the previous workaround may have a negative impact on normal wireless client association to the access point in the following scenarios:

Clients that are slow or may drop initial processing of EAPoL message number 1 (M1). This is seen on some embedded/CPU-limited clients, which may receive the M1 and not be ready to process it after the 802.1x authentication phase.
Environments with RF (Radio Frequency) interference or a WAN connection between the access point (AP) and the WLC, which may result in packet drops at some point on transmission towards clients.
In either scenario the outcome would be an EAPoL exchange failure and the wireless client will lose its authentication, requiring it to restart the association/authentication processes.
Workaround for CVE-2017-13082 For customers who are concerned about CVE-2017-13082 (Accepting a Retransmitted FT Reassociation Request and Reinstalling the Pairwise Key While Processing It), the workaround is as follows:

If no interactive applications such as Voice over IP (VoIP) or video are being used on the network, you can disable 11r support on the access point.
If VoIP applications are in use but the supplicants support CCKM (for example, Cisco Wireless Phones), you can disable 11r support and reconfigure the clients to use CCKM (Cisco Centralized Key Management), which should provide a similar roaming experience.
Note: Disabling 11r support may have negative performance and availability impact on the network. Customers should verify that disabling 11r would not negatively impact their environment before performing such configuration change on their infrastructure devices.

No workarounds have been identified for CVE-2017-13086, CVE-2017-13087, or CVE-2017-13088. Any future workarounds that address these vulnerabilities will be documented in the respective Cisco bugs, which are accessible through the Cisco Bug Search Tool https://bst.cloudapps.cisco.com/bugsearch/bug/BUGID .