SAE authentication frames in client mode

SAE authentication frames in client mode

[Mathy Vanhoef]

Hello,

It seems that in client mode, the Linux kernel only accepts an
authentication frame after sending one itself. Is this interpretation
correct?

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?

Cheers,
Mathy

Re: SAE authentication frames in client mode

[Jouni Malinen]

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 Malinen                                            PGP id EFC895FA

Re: SAE authentication frames in client mode

[Mathy Vanhoef]

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

[Jouni Malinen]

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

Re: SAE authentication frames in client mode

[Mathy Vanhoef]

On Thu, Sep 20, 2018 at 11:12 AM Jouni Malinen <j@w1.fi> 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?