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

Am 16.03.20 um 22:37 schrieb Jouni Malinen:
> On Mon, Mar 16, 2020 at 10:07:26PM +0100, Alexander Wetzel wrote:
>> First, you see BASIC+FT0+FILS0 as standardized? (See previous mail)
> 
> I don't understand what "FT0" and "FILS0" really mean.. If that means
> never using KeyID 1 with FT protocol or FILS authentication when going
> through PTK rekeying, no, I don't think I would say so. If those mean
> that the very first KeyID for an association has to be 0, I guess I'd
> agree. So in the simplest default case: KeyID 0 is always assigned first
> regardless of which authentication mechanism is used and PTK rekeying
> through 4-way handshake can then switch between KeyID 1 and 0 since that
> same design is used with all cases.
> 
>> 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.
> 
> I'm not sure I fully follow the terminology of "PTK0 rekey" and what
> would you describe here.. I'd expect station/supplicant to follow
> whatever the AP tells it for the KeyID. If there is no explicit
> indication of KeyID for the initial TK at the beginning of association,
> 0 have to be assumed to be used. Whenever going through PTK rekeying
> (4-way handshake), if there is an explicit indication of Key ID (i.e.,
> Key ID KDE), that provides the Key ID to use; otherwise, 0 is assumed.
> 

First: FT0 and FILS0 seem to to exactly what you want. I'm just not sure 
if you are ok with how these modes "pin" Extended Key Id support with 
the initial handshakes (FT or FILS) and make sure the rekeys are then 
using something different later.

I would also have simple told the STA to signal support for Extended Key 
ID and only check the KeyID in EAPOL#3: If there is a keyID use that. If 
not use zero. But the standard forces us to check the RSN (chapter 
12.7.6.4):
If the Extended Key ID for Individually Addressed Frames subfield of the 
RSN Capabilities field is 1 for both the Authenticator and Supplicant 
then prior to sending message 4, STA_P uses the MLME-SETKEYS.request 
primitive to configure the IEEE 802.11 MAC to receive individually
addressed MPDUs protected by the STK with the assigned Key ID.
Simply acting on the KeyID would therefore violate the standard.

> Or are you just talking about the wpa_deny_ptk0_rekey != 0 cases?
> Wouldn't that be obvious at the time of the first rekey? If both the
> initial TK and the second TK from that first rekey use Key ID 0, the AP
> is not using Extended Key ID.
> 

Yes, that would also be a problem... wpa_deny_ptk0_rekey != 0 is 
resetting the connection normally way prior to getting the new keyID.

when we not decide at the initial connection if we are using Extended 
Key ID or not we would have to reset the connection much later and not 
at the first indication one end plans to rekey.

>> 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?
> 
> Ah, yes.. We'll have to consider the implication for AP mode. I guess it
> could be justifiable to do that with the shared global parameter as
> well. A specific network profile for AP mode is explicitly selected
> anyway, so there would be no significant limitation from requiring the
> global parameter value to be set for cases where different setting for
> use of Extended Key ID is needed. I'd probably also drop the special
> case of starting with Key ID 1, i.e., simply have ext_key_id=0/1 as the
> wpa_supplicant global parameter while hostapd would use ext_key_id=0/1/2
> to allow start-with-KeyID-1 testing (with PSK/SAE; not with FT/FILS per
> discussion on what the standard actually describes).
> 

Honestly I'm thinking of dropping the "start-with-keyid-1" outright now. 
Just using it for testcases is probably not worth it.

Alexander