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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

> 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).

-- 
Jouni Malinen                                            PGP id EFC895FA

_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux