Re: [PATCH 5/8] STA: Support Extended Key ID

Am 15.03.20 um 23:26 schrieb Jouni Malinen:
> On Sun, Mar 15, 2020 at 08:04:23PM +0100, Alexander Wetzel wrote:
>> Support Extended Key ID in wpa_supplicant according to
>> IEEE 802.11-2016 for infrastructure (AP) associations.
>>
>> Extended Key ID allows to rekey pairwise keys without the otherwise
>> unavoidable MPDU losses on a busy link. The standard is fully backward
>> compatible, allowing STAs to also connect to APs not supporting it.
>>
>> The standard is not covering how to use it with extensions like FILS or
>> FT and wpa_supplicant sticks to the save settings by default but allows
>> the user to enable non-standard Extended Key ID support for FT and FILS.
>>
>> BASIC Extended Key ID support does nothing not clearly covered by the
>> standard and force it to be off for compatibility when needed.
>> FT0, FILS0 and FILS_CUSTOM are not standardized extensions to also allow
>> Extended Key ID support to be used with FT and/or FILS.
>>
>> FT0, FILS0 and FILS_CUSTOM are not standardized extensions allowing to
>> use Extended Key ID also with FT and/or FILS.
>> FILS0 and FILS_CUSTOM are both detecting when the AP is using the other
>> mode and switch over to it.
> 
> I'd like to get a version of this that includes only the fully
> standardized parts, i.e., use of Extended Key ID when going through
> 4-way handshake.
> 
First, you see BASIC+FT0+FILS0 as standardized? (See previous mail)

The only question is then if we can "mark" the connections to be using 
Extended Key ID at the FT or FILS connect or shall wait till we rekey.
Since both handshakes have RSN and therefore the Extended Key ID 
Capability Bit the initial connect seems to be the logical point.

Alternatively we can make the check that the AP is not stopping using 
Extended Key ID less strict and allow e.g. PTK0 rekey for at least the 
first EAPOL rekey. Even when the RSN Capapilities at the initial connect 
told us it should be Extended Key ID.

> As far as wpa_supplicant configuration for this is concerned, is there
> real need for provide per-network profile configuration? I'm thinking of
> simply adding a global ext_key_id parameter with 0/1 values that applies
> to all cases. This would default to 0 (disabled) for now and then could
> be changed to 1 once there has been some interoperability testing of the
> functionality between vendors.
> 

wpa_supplicant can also be configured to start an AP. The network 
setting is passed through to the AP. Using a global setting for that 
will prevent to configure it for the AP at all. It either would be stuck 
to a hard coded value or to the global config setting. Shall I go for that?

Alexander