On Fri, 2019-02-01 at 09:46 -0800, James Prestwood wrote: > On Fri, 2019-02-01 at 13:12 +0200, Jouni Malinen wrote: > > On Thu, Jan 31, 2019 at 02:00:51PM -0800, James Prestwood wrote: > > > I am running hostapd using SAE for authentication. I am purposly > > > setting sae_groups=20, but having my supplicant try group 19 > > > (which > > > should result in both sides negotiating a group they both > > > support). > > > As > > > far as I understand it, hostapd would be in the "nothing" state > > > and > > > I > > > am sending over a commit. I am seeing hostapd send back over a > > > rejected > > > authentication with UNSUPPORTED_FINITE_CYCLIC_GROUP, but no group > > > number is included, just status and auth transaction. > > > > That follows the IEEE Std 802.11-2016, Table 9-36 (Presence of > > fields > > and elements in Authentication frames) rules. The Finite Cyclic > > Group > > is > > present if the Status Code field is zero or 76. > > UNSUPPORTED_FINITE_CYCLIC_GROUP is 77. > > > > > According to the 802.11 spec this is what should happen: > > > > > > (12.4.8.6.3 Protocol instance behavior - Nothing state) > > > > > > "Upon receipt of a Com event, the protocol instance shall check > > > the > > > Status of the Authentication frame. If the Status code is not > > > SUCCESS , > > > the frame shall be silently discarded and a Del event shall be > > > sent > > > to > > > the parent process. Otherwise, the frame shall be processed by > > > first > > > checking the finite cyclic group field to see if the requested > > > group is > > > supported. If not, BadGrp shall be set and the protocol instance > > > shall > > > construct and transmit a an Authentication frame with Status code > > > UNSUPPORTED_FINITE_CYCLIC_GROUP indicating rejection with the > > > finite > > > cyclic group field set to the rejected group, and shall send the > > > parent > > > process a Del event." > > > > > > Specifically I am concerned with "... finite cyclic group field > > > set > > > to > > > the rejected group ...". > > > > > > So after reading the spec it appears this behavior is not correct > > > on > > > hostapd's part, it should be sending the group number in the > > > authenticate response (at least that is how I read it). > > > > It looks like the standard is ambiguous here. That sentence here is > > somewhat vague with the "with the finite cyclic group field set to > > the > > rejected group" after another with statement, but even if that were > > to > > be interpreted as "with Status Code field set to > > UNSUPPORTED_FINITE_CYCLIC_GROUP indicating rejection and with the > > Finite > > Cyclic Group field set to the rejected group", this behavior would > > be > > constrained by the Table 9-36 description of which fields are > > actually > > present in the frame. > > Overall, I agree its ambiguous and contradictory. But I would not > agree > that section 12.4.8.6.3 is vague. It seems very clear to me how it > wants the frame to be constructed. > > Thanks for pointing out the table, this now makes sense why hostapd > does not include the group. Although I am kinda thinking Table 9-36 > has > a typo (where 76 should be 77) for a few reasons: > > 1. Section 12.4.8.6.3 specifically mentions including the group for > code 77 and no where else does it mention including the group for > code > 76 besides that table. The state machine sections are very explicit > and > clear with every other detail, seems weird to leave this out. > > 2. Since you are rejecting with an unsupported group it really seems > logical to include the group that you are rejecting. (although just > because something is logical it doesnt mean the spec does it that way > :)). > > I guess it comes down to which part of the spec you want to deems as > 'correct'. I would argue the section 12.4 that defines the SAE > protocol > should be taken as correct vs an entry in a table. > > Thanks, > James Upon further review of the spec I found yet another blurb that would seem to point to including the group number when the status is UNSUPPORTED_FINITE_CYCLIC_GROUP. >From before, Section 12.4.8.6.3: "... the protocol instance shall construct and transmit a an Authentication frame with Status code UNSUPPORTED_FINITE_CYCLIC_GROUP indicating rejection with the finite cyclic group field set to the rejected group..." And in Section 12.4.8.6.4: "If the Status code is UNSUPPORTED_FINITE_CYCLIC_GROUP, the protocol instance shall check the finite cyclic group field being rejected. If the rejected group does not match the last offered group the protocol instance shall silently discard the message and set the t0 retransmission) timer." So now we have 2 places that contradict Table 9-36. In addition, Section 12.4.8.6.4 is quite clear that "the protocol instance shall check the finite cyclic group field being rejected", which I don't see wpa_supplicant doing (and how could it? hostapd doesn't include the group). So this, at the very least, shows wpa_supplicant is violating the spec by not checking the group. And if this is true, hostapd is in violation as well by not including the group. Obviously this needs to get straitened out in the spec since there is an obvious contradiction with Table 9-36, which doesn't happen overnight. But in terms of hostapd/wpa_s, I believe this should be enough to make an intelligent decision on how to proceed. Thanks, James > > > > > I guess that's one more item for the REVmd maintenance effort to > > address.. > > > > > _______________________________________________ > Hostap mailing list > Hostap@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/hostap _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
