Am 16.03.20 um 22:25 schrieb Jouni Malinen:
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?
I assume you wanted to refer to EXT_KEY_ID_FILS0 here? (EXT_KEY_ID_FILS
is just a helper macro)
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
2) The STA also should not change the RSN capability in mid-connection.
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)
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.)
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 therefore decided to be careful and disable Extended Key ID outright
when it's possible to have Extended Key ID RSN signaling outside of the
covered EAPOL handshake.
By blocking Extended Key ID to be used with FT and FILS would still
allow the standard and make the KeyID mandatory in some way and not
force the decision now.
Alexander
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
