> > 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).
