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