AP: Extend EAPOL-Key msg 1/4 retry workaround for changing SNonce
If the 4-way handshake ends up having to retransmit the EAPOL-Key message 1/4 due to a timeout on waiting for the response, it is possible for the Supplicant to change SNonce between the first and second EAPOL-Key message 2/4. This is not really desirable due to extra complexities it causes on the Authenticator side, but some deployed stations are doing this. This message sequence looks like this: AP->STA: EAPOL-Key 1/4 (replay counter 1, ANonce) AP->STA: EAPOL-Key 1/4 (replay counter 2, ANonce) STA->AP: EAPOL-Key 2/4 (replay counter 1, SNonce 1) AP->STA: EAPOL-Key 3/4 (replay counter 3, ANonce) STA->AP: EAPOL-Key 2/4 (replay counter 2, SNonce 2) followed by either: STA->AP: EAPOL-Key 4/4 (replay counter 3 using PTK from SNonce 1) or: AP->STA: EAPOL-Key 3/4 (replay counter 4, ANonce) STA->AP: EAPOL-Key 4/4 (replay counter 4, using PTK from SNonce 2) Previously, Authenticator implementation was able to handle the cases where SNonce 1 and SNonce 2 were identifical (i.e., Supplicant did not update SNonce which is the wpa_supplicant behavior) and where PTK derived using SNonce 2 was used in EAPOL-Key 4/4. However, the case of using PTK from SNonce 1 was rejected ("WPA: received EAPOL-Key 4/4 Pairwise with unexpected replay counter" since EAPOL-Key 3/4 TX and following second EAPOL-Key 2/4 invalidated the Replay Counter that was used previously with the first SNonce). This commit extends the AP/Authenticator workaround to keep both SNonce values in memory if two EAPOL-Key 2/4 messages are received with different SNonce values. The following EAPOL-Key 4/4 message is then accepted whether the MIC has been calculated with the latest SNonce (the previously existing behavior) or with the earlier SNonce (the new extension). This makes 4-way handshake more robust with stations that update SNonce for each transmitted EAPOL-Key 2/4 message in cases where EAPOL-Key message 1/4 needs to be retransmitted. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>master
parent
db099951cb
commit
f23c5b17e1
Loading…
Reference in New Issue