> > If that is the case, this would conflict with the SAE handshake as > > defined in the 802.11-2016 standard. That's because when the AP > > receives a Commit frame, the AP is allowed to send both a Commit and > > Confirm frame (see 12.4.8.6.3). So according to the standard, the > > client must accept a SAE Confirm authentication frame, even if it > > hasn't yet transmitted its own Confirm frame. So this appears to be a > > bug. Thoughts? > > While the SAE authentication exchange itself has such flexibility in the > sequence of Commit/Confirm messages, there is a constraint in IEEE > 802.11 on how the Authentication frames are exchanged in an > infrastructure BSS between a non-AP STA and an AP. For SAE, this is > explicitly requiring the exchange proceed in the sequence shown in > Figure 4-29 (Example using SAE authentication), i.e., with the Commit > messages exchanged first and the first Confirm message coming from STA > to AP and the exchange concluded with the Confirm message from AP to > STA. This matches the Linux kernel implementation.
That figure only appears to be an example. It doesn't say an exchange must ("shall") follow that order. So I don't see where the standard puts a constraint on how the authentication frames are exchanged. A related observation is that retransmissions of the Confirm message are done by the kernel? Unfortunately this means the Send-Confirm field is not being incremented (as per 12.4.8.6.5). In practice we indeed see that this field is not being incremented for retransmitted Confirm frames (when using wpa_supplicant). This means that if the first Confirm frame sent by the AP is lost, the handshake will fail, since the AP will not accept retransmissions with the same Send-Confirm counter (and hence won't retransmit its own Confirm frame).