On Mon, Mar 16, 2020 at 11:18:48PM +0100, Alexander Wetzel wrote: > Here the chain of thoughts leading to the decision to not consider Extended > Key ID in combination with FT/FILS as standardized: > > 1) The RSN capabilities of an AP are fixed. The AP can't just drop > capabilities used in a beacon in e.g. a FT or FILS handshake Agreed, but I'm reading this as the AP indicating it supports Extended Key ID for all AKMs, including FT and FILS cases if those are enabled for the BSS. > 2) The STA also should not change the RSN capability in mid-connection. Same here. > 3) Therefore we have the full signaling that Extended Key ID can be used at > the initial connect when we support it, also for FT and FILS. But nothing in > the standard tells us what we shall do when FT/FILS handshakes indicate both > ends are Extended Key ID capable (we just don't have a transport for the > KeyID) I'm reading the standard saying that with FT protocol and FILS authentication Key ID 0 shall be used for the initial association and if RSNE indicated support for Extended Key ID, PTK rekeying (which will through 4-way handshake that has the Key ID) will indeed use Extended Key ID (i.e., the very first 4-way handshake exchange during this association shall include Key ID KDE setting Key ID to 1). > 4) We CAN continue as usual, maybe even flag the connection as Extended Key > ID capable (This is exactly what BASIC+FT0+FILS0 is doing in this patch.) Yes, that should be done based on the negotiated Extended Key ID capability in RSNE. > 5) Assuming the standard is then amended to add the keyID to FT/FILS > handshakes it's then no longer sufficient to check if both ends support > Extended Key ID: We also have to check if there is a KeyID and when not > assume 0 to stay compatible with the "previous" standard. I'm not sure I see any need to amend that design, i.e., it sounds fine to force Key ID 0 to be used for the first TK at the beginning of association. It might make sense to note that somewhere in the standard, but this seems to be sufficient from functionality view point. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
