wpa keyhandshake question / bug
Tue Apr 19 11:10:11 PDT 2005
I am investigating a wpa bug together with hostapd (tested mit madwifi
but should also apply to others) and serveral types of clients
(windows, prism, madwifi). On reauthentication (WPA, EAP-TLS) clients
lose connection from time to time, especially when there is traffic
between client and ap. I narrowed down the problem into one direction,
and I now want to get some feedback here to hopefully solve it soon.
I will refer to the 802.11i-2004 standard to describe my problem.
On page 89 step 4 of the 4-way handshake is described. When the
Authenticator received message 4 it checks some things and then goes to
PTKINITDONE and sets new key to the driver. After this a group key
handshake should occur.
This does not always work for me. In my scenario the message 4 under
some circumstance does not reach the authenticator. One possibility is
it is lost on air. Another harmfull possibilty is that the message 4 is
already encrypted with the new sta key and is dropped by the MAC layer
as crypto error (linux queuing issue maybe, that means the message 4 is
stuck in linux queue while the .set_key function allready activated the
new key in the driver). In first case a retransmit on mac layer
That is the point where I am very confused. Does wpa_supplicant
recognize that the message 4 did not arrived at the ap and will
retransmit the packet? And whats with the driver interface? If the
.set_key function is done (directly after sending message 4) all
packets from this time on would be encrypted with the new key and
dropped from the ap because the 4-way is not done.
Hmm I want to solve this issue, but am also thinking about a workaround.
It maybe would be an idea to check failing packets against the old key,
but that would mean that the driver has to be modified what is not
always possible (windows, broadcom, ndis). Another idea is to simply
disable the ptk derivation on reauth, as it is stated on page 76 that
this should only occur once per session (but nonce has to be
Thanks for reading and much regards,
p.s.: I just noticed the comment 2 on on page 75, please also have a
look on this!
More information about the Hostap