Re: SAE authentication frames in client mode

[Jouni Malinen <j@w1.fi>]

On Thu, Sep 20, 2018 at 12:55:10AM +0200, Mathy Vanhoef wrote:
> 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.

I know this figure is not a normative requirement, but it is a
convenient location to point to for showing that specific sequence. I
did discuss this in the IEEE 802.11 working group when working on the
SAE implementation for infrastructure BSS case and the conclusion from
that discussion was that it is better to follow the common sequence of
STA->AP->STA round trips for the Authentication frames and have the STA
be the one taking care of retransmissions, if needed. I thought we ended
up clarifying that in the standard text somewhere as well, but that was
years ago and I do not remember how exactly this got documented. It is
possible that there would be benefit from adding a more explicit
requirement in REVmd. In any case, this sequence is the one that is
being implemented and enforced for implementations of WPA3.

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

For mac80111-based drivers, there is indeed retransmission cases in the
kernel implementation for authentication and association frames. SAE is
not the only case where those are somewhat pointless; similar issue
applies at least for FILS authentication where the timeout is too short
and the retry incorrect anyway. I have some local patches in mac80211
for testing purposes, but I have not yet found time to clean those up
for contribution.

For SAE, wpa_supplicant should really try to send out another Confirm if
no response from the AP is received. The mac80211 retries could be
removed as useless both for SAE and FILS. For now, the recovery from
this by starting authentication exchange from scratch which is likely
sufficient for covering robustness needs with all the link layer retries
making it sufficiently unlikely for the Authentication frames to be lost
completely.

-- 
Jouni Malinen                                            PGP id EFC895FA