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

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

 



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

_______________________________________________
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