Re: [PATCH 4/8] AP: Support Extended Key ID

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