Mailing List Archive

WiSM "WPA MIC error" shuts the *entire* AP down?
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?
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: WiSM "WPA MIC error" shuts the *entire* AP down? [ In reply to ]
On 02/09/10 11:51, Phil Mayers wrote:
> 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?

I've since done a bit more reading, and apparently this behaviour
(shutting down the radio) is mandated by WPA1 and the solution is to
move to WPA2. It seems bizarre - shut down the entire radio - but there
we go.

Thanks to those who replied off-list.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: WiSM "WPA MIC error" shuts the *entire* AP down? [ In reply to ]
On 02/09/2010 13:59, Phil Mayers wrote:
> I've since done a bit more reading, and apparently this behaviour
> (shutting down the radio) is mandated by WPA1 and the solution is to
> move to WPA2. It seems bizarre - shut down the entire radio - but there
> we go.

It's hobson's choice, isn't it:

a. keep the service up, pretty much guaranteeing that your network will be
compromised

b. take the service down, but ensure that the network is not compromised

Nick
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: WiSM "WPA MIC error" shuts the *entire* AP down? [ In reply to ]
On 02/09/10 14:16, Nick Hilliard wrote:
> On 02/09/2010 13:59, Phil Mayers wrote:
>> I've since done a bit more reading, and apparently this behaviour
>> (shutting down the radio) is mandated by WPA1 and the solution is to
>> move to WPA2. It seems bizarre - shut down the entire radio - but there
>> we go.
>
> It's hobson's choice, isn't it:
>
> a. keep the service up, pretty much guaranteeing that your network will be
> compromised

If invalid MICs are only generated by malicious clients then it might be
an appropriate response, but they're not - as some time spent on google
will show, there are buggy clients/hardware that leak a trickle of
invalid MICs, but are not malicious.

In magic pixie land "fix the clients" is probably the solution, but out
here in the real world... ;o)

>
> b. take the service down, but ensure that the network is not compromised

If, as is claimed, WPA1 is the problem, I don't understand why there isn't:

c. disable all WPA1 clients for 60 seconds

...which would at least attempt to maintain some level of service.
Shutting down the entire radio interface for 60 seconds seems like a
sledgehammer to crack a nut - and a very, very easy DoS to boot.

Bah. Wireless sucks...
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: WiSM "WPA MIC error" shuts the *entire* AP down? [ In reply to ]
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
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/