[c-nsp] WiSM "WPA MIC error" shuts the *entire* AP down?
Alan Buxey
A.L.M.Buxey at lboro.ac.uk
Thu Sep 2 16:57:26 EDT 2010
Hi,
> Can someone explain to me how this:
>
> http://www.cisco.com/en/US/products/ps6366/products_qanda_item09186a008082c464.shtml#err2
>
> ...is anything other than a terrible, terrible idea?
>
> Do people disable this in their networks?
but thats the way it works - MIC error causes all TKIP activity to be stopped...
thus the AP stops being an AP - we see this quite a few times a day - the joys of
a broadcast based system - just one single bad client can mess up everyones life.
ISTR that lots of APs behave in this way....at least if they follow standards,
clients are required to disassociate from the AP and rekey (their own key and group key)
when a MIC failure first occurs.
IEEE 802.11i requires any station detecting two MIC failures within 60 seconds to
stop all communication for 60 seconds.
The Mac is nice about this too, eg
kernel[0]: AirPort: Message Integrity Failure detected (G)
kernel[0]: AirPort: MIC Failure -- activate countermeasures
kernel[0]: AirPort: Message Integrity Failure detected (G)
kernel[0]: AirPort: MIC Failure -- activate countermeasures
kernel[0]: AirPort: Link DOWN (out-of-range 0)
kernel[0]: AirPort: Link Active: "eduroam" - 00xxxxxxxxxx - chan 144
- and you get a nice scary message as a user...mmm..
couple this with the issue that if you have mixed mode - ie TKIP and AES
for an SSID, then the AES client has to have a TKIP group key...and
therefore falls into 'get ready to be hacked' territory...oh, and will fall
foul of this issue.
one more really really good reason to drop TKIP and move to WPA2/AES only
alan
More information about the cisco-nsp
mailing list