DOS attack on WPA 802.11?

[Niels Ferguson]

We've gone through all the main argument here, and I think it is clear we
don't agree. I started writing a detailed reply to your last message, but
most of it was just argueing that we need authentication on 802.11 packets.
TGi had a limited brief: improve the security for 802.11, and that includes
providing authentication. 

Many of your arguments depend on properties of other parts of the system. A
few forged packets won't cause too much danger. We can DF the transmitter,
and then do something about it. We can catch Bob when he collects the
money. We can detect the attack and let the humans respond to it. We can
implement alternative countermeasures in the form of a filter. 

You can't assume that any of these are true. We can't tell our customers
something like: "Here is the security upgrade for your existing hardware,
but you need to buy DF equipment, staff your wireless network security
office 24*7, re-design all your applications such that a few forged packets
do not do too much harm, buy new APs with enough memory to implement the
new filter functions, and establish a world-wide police system to arrest
Bob at any bank in the world when he tries to collect the money." 

Our job is to secure 802.11, nothing more, but certainly nothing less. That
means that we have to provide authentication for all packets. The only
sensible measure of how well we do that is how much effort it takes an
attacker to forge a single message. 

I will therefore restrict myself to the issue of securing 802.11, and not
go into any of the other aspects of the system.

[...]
>Tell me if I understand this attack correctly. Bob intercepts a 

The 2^-29 probability comes from carefully choosing a particular difference
pattern in the message. For certain carefully chosen difference patterns
the MIC value does not change. Alternatively, you can use carefully chosen
difference patterns in the message and a related chosen difference in the
MIC value. The probability here is taken over all possible Michael keys.

[...]
>The logic behind your countermeasure is that forgery attempts are 
>very easy to detect and by shutting down for a minute after 2 forgery 
>attempts within one second, Bob needs an average of half a million 
>minutes to get his packet through, or about one year. And that's an 
>acceptable risk.

Yes. That seems more work for Bob than breaking into the office and tapping
directly into the Ethernet cables, which is the original security goal of WEP.


[...]
>There are three important differences between the Michael 
>countermeasure DOS attack and the packet canceling attack you 
>described earlier. First, the Michael attack is much easier to 
>program, hence more likely to happen. Second, since it is new and 
>specific to the touted WPA, it will be especially attractive to 
>hackers, while at the same time more damaging to WPA's reputation.

We all know it only takes one smart programmer to program it, and then the
attack becomes just a tool. My DOS attack is also a super-slick one. You
can think up many other ones that are much simpler to program, like
disturbing the beacon or sending false beacons. 

Besides, I don't understand where you want to go with this argument. You
argue for a configuration switch to switch of the countermeasures. The
basic forgery attack still exists, so now the attacker can do the DOS
attack and get the countermeasures switched off. Are you saying that
Michael without countermeasures is secure enough?

>Third, the countermeasure attack is inherently very hard to detect 
>while I believe there are defenses against the packet cancelling 
>attack that force the attacker to make lots of transmissions. As I 
>mentioned, TCP/IP packets can be encapsulated in a layer above 
>802.11. Also two stations on the same wireless network that also had 
>a wired link could collude to force the attacker into transmitting 
>more.  These aren't great defenses, but they could be developed 
>fairly quickly if packet cancelling attacks became a problem.

Not if you cancel the ARP packets for new stations. And the attacker would
detect these collusing stations and ignore their packets anyway. And I can
think of several more DOS attacks against 802.11, but I don't have the time
now to work out the details.


>Then why not have two levels of strength, one what is now proposed 
>and the second with a stronger MIC, perhaps Michael with more rounds 
>as you suggest, and let the user choose?  And why not insist that 
>802.11a use the stronger mode? Because it is just coming out, 802.11a 
>has no installed base and there is less crud on its 5 GHz band. It is 
>also much faster so it will require more powerful processors anyway 
>and any forgery attack will take much less time.
>
>I sense a shift in argument here from "We had to retrofit existing 
>systems and did the best we could," which I can buy for 802.11b but 
>not in the 802.11a case, to "We don't care about DOS attacks, so we 
>won't increase hardware cost a dime to defeat them."

That is exactly what TGi is doing. There are two levels of strength, the
quick-fix for existing hardware which uses Michael, and a new security
protocol that uses AES as the cryptographic basis. The AES-based work isn't
finished yet, I gather. I agree that all new hardware should use the
AES-based security system, but it has to be finalised before people can
implement it.


>The two extremes in designing a software system are having a bunch of 
>security options,initially turned off, that the user is supposed to 
>select correctly and having no options at all on the assumption that 
>all the tradeoffs were figured out correctly. In my opinion, both 
>extremes are unwise.

I've worked in cryptographic security for over a decade now, and I've yet
to see a security option that helped making the systems more secure.
Security is only as good as the weakest link. Any option that creates a
weak link creates a security hole. If you have even a single hole, you
might as well not bother with the cryptography at all. If I had things my
way there wouldn't even be the option of switching the cryptography
protocol off.


Anyway, we seem to be mostly going around in circles, and this is quickly
losing its interest for me. I think I've given all the relevant arguments
from my side. We had exactly the same discussions within TGi, and after
much discussion TGi chose what it considered to be the best route. I don't
think this is the forum to re-do TGI's work. 


Cheers!

Niels

P.S. I'm not on this mailing list, so I can only respond to email that is
sent directly to me.



==============================================================
Niels Ferguson, niels at ferguson.net, phone: +31 20 463 0977
PGP: 3EC2 3304 9B6E 27D9  72E7 E545 C1E0 5D7E

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com