Following the webcast on the WPA/WPA2 Break today, a listened pointed out that there are still a lot of clients that will normally generate Michael MIC failures on a TKIP network reportedly including some Intel Centrino drivers and Cisco 7920 phones.

Reading the Cisco 7920 firmware 3.1 release notes, I was able to confirm this behavior:

    "The Cisco Unified Wireless IP Phone 7920 may transmit a message integrity check (MIC) error to the access point when using TKIP. If the access point receives two MIC errors within 60 seconds, then the access point enters Countermeasure mode in which all associated TKIP clients are de-authenticated for the duration of the Countermeasure Holdoff time."

Really Cisco?  Effectively, this says that there is a  bug in the TKIP implementation on this phone that they can't figure out how to fix.

What do you do when you can't fix a bug?  Workaround!  Here is what they recommend:

    "You can reduce the Holdoff time for TKIP Countermeasure mode to less than 60 seconds (the default value) on the access point.  Use this command on your access point configuration:

        interface dot11radio 0

        countermeasure tkip hold-time seconds

where seconds is the holdoff time. Suggested values are from 0 to 3. "

Now, I hate to be a stick-in-the-mud, but disabling Michael countermeasures ("countermeasure tkip hold-time 0") will cause the AP to silently accept all MIC failures without complaint.  In the perspective of the new TKIP attack, this allows an adversary the freedom to decrypt entire packets at will, without the 1-byte-per-minute limitation from well-behaving TKIP implementations.

Bottom line, your network is more vulnerable with Cisco 7920 phones than without.  If you keep the default countermeasure timer to 60 seconds, you will DoS all users from the AP whenever this bug is triggered more than once per minute.  If you decide to disable countermeasures altogether, you open yourself up to an even more aggressive TKIP attack which effectively puts security back to that of a WEP network.

I don't know how this is acceptable from a respected engineering team like Cisco.  If it were me, I'd demand a real bugfix, or a refund.

-Josh