About the Disassociation or Deauthentication Frame
Last Post: March 15, 2011:
what will the AP or STA do when it receives a Disassociation or Deauthentication Frame from the other side during the 4-ways handshake
Since authentication and association are required prior to establishing RSN security, a disassociation/deauthentication during the 4-way handshake exchange would terminate the association or authentication, essentially resetting the connection, putting the client back into the scanning process. I don't have a trace that shows this happening, but the protocol is pretty clear that it would occur this way.
I want to do a experiment to support it:
send a disassociation during the 4-way handshake exchange and check whether the association would terminate.
could you give me some help?:)
Perhaps a custom version of ddwrt. I doubt you'll be able to get the timing right manually - you'll be splitting up several millisecond streams.
Yeah, you'd have to make some significant software changes in a client's firmware to get this to happen, and that is outside my skill set. The 4-way handshake only takes about 10 milliseconds (typically).
I think it isn't necessary to be splitting up several millisecond streams
just listen the fist message of the 4-ways handshake and send the Deauthentication
You could have the AP send the deauth after it sends the first frame of hte 4-way handshake, and then see if the client still sends the second frame of the 4-way handshake. To do this, you'd have to alter the software of the AP.
As wlanman said, you will not be able to manually inject the deauth at the proper time b/c we're talking about milliseconds between frames. It is nearly impossible to manually time the sending of a frame in this way.
Sounds like doable with CommView for WiFi. No hacks, documented features. You watch the packets being received using the TCP/IP interface described on http://www.tamos.com/htmlhelp/commwifi/mirroring.htm, detect the handshake in your application, and immediately fire a deauth packet that you've crafted. Given that your app is listening for data on the loopback address, without any delays, you should be able to have turn-around time of less then 10 ms. Disclaimer: never tested this myself.
Will your injection device adhere to 802.11 contention?
If yes, then no guarantee that the packet will make it in the middle of the exchange.
If no, then it will more than likely just cause a collision, nothing more.
In 4-way handshake,since the STA will calculate the PTK and MIC after receiving the first message.I think the attacker may send the Deauthentication Frame to STA when the PTK and MIC is being calculate.because calculating the PTK and MIC will take a few time,the STA will receive the Deauthentication before PTK and MIC
have been calculated
It's just like the attacking which the attacker replay the first message of the 4-way handshake.
I don't know if there is something wrong about this thought