Re: SAE authentication frames in client mode
On Thu, Sep 20, 2018 at 11:12 AM Jouni Malinen wrote: > 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. Thanks for the information. The standard should indeed be more clear, currently there doesn't seem to be a requirement to follow a specific sequence of frames. > > 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. If the mac80211 retransmissions fail, wpa_supplicant will abort the authentication attempt (seems like sme_auth_timer is fired, and the client deauthenticates from the network). So wpa_supplicant itself will not attempt to send another Confirm frame with a higher Send-Confirm?
Re: SAE authentication frames in client mode
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 MalinenPGP id EFC895FA
Re: SAE authentication frames in client mode
> > 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).
Re: SAE authentication frames in client mode
On Wed, Sep 19, 2018 at 02:36:20PM +0200, Mathy Vanhoef wrote: > It seems that in client mode, the Linux kernel only accepts an > authentication frame after sending one itself. Is this interpretation > correct? For infrastructure station case, yes. > 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. For mesh BSS cases, the SAE Confirm message can be sent out immediately after having processed the Commit message, so the sequence there may end up being different. That's also supported in the Linux implementation, but this flexibility is not extended to the infrastructure case on purpose. -- Jouni MalinenPGP id EFC895FA