IEEE 802.11r KDF uses key length in the derivation and as such, the PTK
length must be specified correctly. The previous version was deriving
using 512-bit PTK regardless of the negotiated cipher suite; this works
for TKIP, but not for CCMP. Update the code to use proper PTK length
based on the pairwise cipher.
This fixed PTK derivation for both IEEE 802.11r and IEEE 802.11w (when
using AKMP that specifies SHA-256-based key derivation). The fixed
version does not interoperate with the previous versions. [Bug 307]
dot11RSNAConfigGroupUpdateTimeOut and
dot11RSNAConfigPairwiseUpdateTimeOut MIB variables were only used in
draft versions of IEEE 802.11i, so rename these in order not to use
confusing name here.
Replaced EAPOL-Key timeout to use following timeouts (in
milliseconds): 100,1000,1000,1000 (this was 1000,1000,1000,0). There
is no point in sending out the final EAPOL-Key frame which would be
immediately followed by disconnection. After the change to allow
response to any pending EAPOL-Key frame, it is fine to send the first
retransmission quickly to avoid long wait in cases where Supplicant
did not receive the first frame for any reason. The new sequence will
still provide 3.1 seconds of time to get any response frame, so this
does not reduce the previous time.
Accept response to any pending request, not just the last one. This
gives the Supplicant more time to reply since hostapd will now allow up
to three seconds for the reply to the first EAPOL-Key frame transmission
(and two seconds for the first retry and one second for the last) while
the previous version invalidated any old request immediately when
sending a retransmitted frame.
If the Supplicant replies to more than one request, only the first reply
to arrive at the Authenticator will be processed. As far as the
Supplicant is concerned, this behavior does not differ from the previous
one except for being less likely to cause unneeded retransmissions of
EAPOL-Key frames.
This can help in cases where power saving is used when the group key is
rekeyed or when there is excessive traffic on the channel that can delay
(or drop) EAPOL-Key frames.
We need to cancel the group key update for a STA if a reauthentication
request is received while the STA is in pending group key update. When
canceling the update, we will also need to make sure that the PTK Group Key
state machine ends up in the correct state (IDLE) to allow future updates
in case of WPA2.
