On Wed, Sep 08, 2021 at 12:56:17PM -0700, James Prestwood wrote: > On Wed, 2021-09-08 at 19:44 +0000, RAGHAVENDRA SADARAMACHANDRA > (rsadaram) wrote: > > Reg - " If hostapd receives a confirm with non-success status code > > it treats that as the peer rejecting" =====> Peer rejecting of which > > frame? In client and AP case, client is the one which first sends SAE > > confirm. Here there is no previous confirm message for the client to > > reject. Spec mentioned about rejection of previous SAE confirm > > message. > > Ah ok I see where you're coming from now. I think this would be more a > question to the spec writers than anything... but yes I agree the spec > does not line out what to do in this case. In the pre-SAE world, the Authentication frames between the AP and the station were always in a specific order where the first frame was sent by the station and the second frame by the AP, and the third (if one was used like in Shared Key authentication) by the station, and the fourth by the AP. SAE changed things since it was really defined for the mesh case instead of infrastructure BSS, i.e., there was no clear AP like entity and the stations were indeed equal (the 'E' in SAE) and either end could have started the authentication exchange. Mixing this together with infrastructure BSS expectations for Authentication frames has unfortunately resulted in bit of a mess.. Regarding the claim about "client is the one which first sends SAE confirm", I would note that it would be one reasonable interpretation of how SAE could be used in infrastructure BSS. However, it is not the only one.. There is another view where the AP could be expected to be sending out the SAE Confirm message immediately after having sent out the SAE Commit message. In such a case, it would be possible for the SAE Confirm message from the AP to go out before the station has transmitted its own SAE Confirm message. hostapd can actually be configured to do this with sae_confirm_immediate parameter. Whether a station does any processing of the SAE Confirm message from the AP before sending its own SAE Confirm message is another question. I'd expect most implementations to parse the SAE Commit message from the AP and the station to then build its own SAE Confirm message before checking what other frames might have been received from the AP. In such a model, I don't really see any point in the station ever sending out the first SAE Confirm message with Status Code value other than 0 (SUCCESS), i.e., if the station is not happy with whatever happened in SAE Commit messages, it would stop before sending out the SAE Confirm message. The standard could certainly be made clearer for number of SAE in infrastructure BSS cases. IMHO, it would have been better not to use Authentication Transaction Sequence Number field to distinguish between SAE Commit and Confirm in infrastructure BSS cases, but anyway, that was practically enforced long ago with the publication of IEEE 802.11s. > Personally I would expect to reject the peers connection all together > like hostapd does. In infrastructure BSS, I don't see how the AP would be able to proceed with SAE authentication if the station were to send out SAE Confirm with nonzero Status Code, so rejecting the connection seems to be appropriate thing to do here regardless of what reason the station might have had for sending out the frame in the first place. > Also, I wouldn't expect an initial confirm message with a non-success > status code to actually contain a confirm hash. The only context that > makes sense is if the peer is rejecting the connection entirely. A station sending out an Authentication frame with a nonzero Status Code to an AP in an infrastructure BSS does not really make much, if any, sense to me, i.e., I would expect the station simply to stop the exchange rather than trying to tell the AP that it is explicitly rejecting something. If one were to care what the standard has to say about this case, the Confirm field is present in the SAE Confirm message for all other cases except for the Status Code being REJECTED_WITH_SUGGESTED_BSS_TRANSITION (which is only sent be the AP..). -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
