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

Am 15.03.20 um 23:35 schrieb Jouni Malinen:
> On Sun, Mar 15, 2020 at 08:04:22PM +0100, Alexander Wetzel wrote:
>> Support Extended Key ID in hostapd according to IEEE 802.11-2016.
>>
>> 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 an AP to serve STAs with and without Extended Key
>> ID support in the same BSS.
>>
>> The standard is not covering how to use it with extensions like FILS or
>> FT and hostapd sticks to the save settings by default but allows the
>> user to enable non-standard Extended Key ID support for FT and FILS.
> 
> All that non-standard design needs to be removed or moved to another
> patch (which I'd be unlikely to apply before REVmd changes for that go
> in, but the patch itself would be of use for preparing such REVmd
> changes to the standard).
> 

Ok.

>> diff --git a/src/ap/ap_config.c b/src/ap/ap_config.c
>> @@ -1169,7 +1170,31 @@ static int hostapd_config_check_bss(struct hostapd_bss_config *bss,
> 
>> +#ifdef CONFIG_FILS
>> +	if (full_config && wpa_key_mgmt_fils(bss->wpa_key_mgmt) &&
>> +	    !(bss->extended_key_id & EXT_KEY_ID_FILS)) {
>> +		wpa_printf(MSG_INFO,
>> +			   "Extended Key ID disabled (reason: FILS enabled)");
>> +		bss->extended_key_id = 0;
>> +	}
>> +#endif /* CONFIG_FILS */
>> +
>>   #ifdef CONFIG_IEEE80211R_AP
>> +	if (full_config && wpa_key_mgmt_ft(bss->wpa_key_mgmt) &&
>> +	    !(bss->extended_key_id & EXT_KEY_ID_FT0)) {
>> +		wpa_printf(MSG_INFO,
>> +			   "Extended Key ID disabled (reason: FT enabled)");
>> +		bss->extended_key_id = 0;
>> +	}
> 
> 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.

Alexander