On Mon, Nov 04, 2019 at 08:22:42PM +0100, Alexander Wetzel wrote: > I'm looking into extending my Extended Key ID patches to properly enable it > also for OSEN. Unfortunately I'm a bit handicapped here by not having access > to IEEE802.11u and therefore I'm just looking how it's being used in hostapd > and decoded by wireshark. IEEE Std 802.11u-2011 is now part of IEEE Std 802.11-2016. Anyway, those do not really have anything to do with OSEN.. OSEN is defined in the WFA Hotspot 2.0 technical specification. > I find it a big surprise that with OSEN eapol #2 / #3 have no "Osen RSN" > capabilities included at all... RSNE (and since OSEN element follows its definitions for most subfields, likely it as well) can omit subfields that do not differ from default values. As such, the RSN Capabilities subfield is not mandatory to include in general. That said, if the device were to support Extended Key IDs, it would likely be expected to include RSN Capabilities field. > Is it correct that Osen either does not have to include RSN capabilities in > the eapol #2 and #3 or only has to do that optionally? Or is that maybe a > bug in our implementation? Taken into account how inaccurately OSEN is defined, I would not want to expect more or less anything from OSEN implementations beyond being able to connect using CCMP as the pairwise cipher.. Any change in this area has large risk of interoperability issues. > When it's optional, we can of course just make it mandatory for Extended Key > ID and assume it's off when it's missing, problem solved. That's the way the RSN Capabilities subfield works in RSNE and at least in theory, also in OSEN element. > But when it must not be included, how can the AP "see" that a STA can > support Extended Key ID without that? Based on the capture > "ap_hs20_osen_hwsim0.pcapng from the hostapd osen tests I looks like we have > to add the Osen RSN capabilities at least to eapol #2, so the AP knows it > can use it. (Re)Association Request frame is used to negotiate the RSN/OSEN parameters and EAPOL-Key msg 2/4 confirms that the parameters used during that negotiation were indeed valid. > Is there another mechanism to signal Extended Key ID support within OSEN I > did not find so far? Or is the standardized OSEN simply not able to handle > it, regardless that the standard seems to include the "Extended Key ID for > Individually Addressed Frames capability? I'd be quite surprised if you'll ever find someone interested in supporting Extended Key IDs with OSEN. OSEN is used for a short lived association to perform online signup. It does not sound like a very valuable use case to improve rekeying for it. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
