Controller Based WLANs

 View Only
last person joined: one year ago 

APs, Controllers, VIA

Why has a “Received TKIP Micheal MIC Failure Report” error message been received from the clients? 

Jul 03, 2014 02:28 PM

Product and Software: This article applies to all Aruba controllers and ArubaOS versions.

 

TKIP failures usually occur when the four-way handshake is not complete. Usually the error logs on the AP should give you information about which stage of TKIP has failed.

 

MIC failures can be due to lot of interference and noise in the network or even due to multipath and the bit getting corrupted.

 

A TKIP MIC failure is when the Michael hash on the received frame does not properly validate. When TKIP was designed, a hashing algorithm was needed to protect the integrity of transmitted packets. Traditional hashing algorithms such as SHA1 and MD5 could not be used as they were CPU-intensive (remember that this has to be done for EACH packet received and transmitted). Neils Ferguson wrote the Michael hashing algorithm to answer the need for a hashing mechanism that provides a reasonable level of security, and is very fast, working within the constraints of legacy hardware designed to only accommodate WEP.

 

Michael does have several faults, where the security of the algorithm is less than the actual hash size (64-bits), making it possible to brute-force the MIC in only 2^29 operations. To mitigate this attack, the IEEE 802.11i working group added something called TKIP Countermeasures, where if the AP receives two packets with invalid Michael hashes within 60 seconds, it must disconnect all users and not accept any traffic for 60 seconds.

 

This error is reported if there is a broken driver, or if the driver's algorithm for calculating TKIP MICs is flawed, or if they are not calculating the MIC over the correct portions of a frame (which changed with IEEE 802.11e/QoS).

Statistics
0 Favorited
1 Views
0 Files
0 Shares
0 Downloads

Related Entries and Links

No Related Resource entered.