Regarding status code in initial SAE confirm message

[Jouni Malinen]

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