On Mon, Mar 16, 2020 at 09:30:32PM +0100, Alexander Wetzel wrote: > Am 15.03.20 um 23:35 schrieb Jouni Malinen: > > Can you please clarify why those parts are needed? Why would the AP not > > be able to enable Extended Key ID support for non-FILS/FT cases even if > > FILS and FT are enabled in the configuration? The AP is free to select > > which KeyID to deliver and for FT/FILS it would simply use KeyID 0 while > > the cases going through 4-way handshake would alternate between 0 and 1. > > The standard is not telling how to handle it, Extended Key ID is only > defined for EAPOL handshakes. When we enable it in those handshakes we have > more or less decided that the standard compliant way is to always use keyID > 0 here. We then have decided that what "BASIC+FT0+FILS0" here must be the > standard compliant way. Maybe I'm misunderstanding EXT_KEY_ID_FILS or EXT_KEY_ID_FT0 here, but I don't understand why anything related to FILS or FT would end up disabling Extended Key ID for non-FT non-FILS cases. Isn't that what setting bss->extended_key_id to 0 would do? Why would that be needed if the network enables PSK or SAE in addition to FILS and FT? While thinking about this a bit more, I'm not even sure why FT and FILS cases would not be sufficiently defined. Isn't the missing piece only for the part of being able to explicitly state which KeyID is used for the first TK? In other words, this works just fine as long as we always start with KeyID 0. PTK rekeying uses 4-way handshake in all these cases, so the very first time when KeyID 1 has to be indicated is when doing that.. I'm obviously assuming here the default I want to see anyway, i.e., starting with KeyID 0. The special test case for starting with KeyID 1 would then be available only if when the association does not use FT protocol or FILS authentication. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
