Re: [Patch v9 05/16] Introduce and add key_flag

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

 



Am 06.01.20 um 10:09 schrieb Jouni Malinen:
On Sat, Jan 04, 2020 at 11:10:04PM +0100, Alexander Wetzel wrote:
Add the new attribute "key_flag" which will in the following patches
replace the boolean "set_tx" with something also able to handle
"Extended Key ID for Individually Addressed Frames" from
IEEE 802.11-2016.
...

Is this dependent on the CAN_REPLACE_PTK0 changes? If yes, I guess I'll
leave this waiting for my comments on those to be addressed. If not, it
would be good to split this patch set into two or more parts since it is
not exactly convenient to get this many patches reviewed in a single set
unless all the changes are trivial or at least straightforward. Maybe it
would be better to split this into three
(NL80211_EXT_FEATURE_CAN_REPLACE_PTK0, set_key() extensions/cleanup, and
Extended Key ID) and get them in one by one set instead of resending all
16 patches if anything needs to change.


I was original hoping to get Extended Key ID merged till PTK0 rekey became ready, so we would not have to discuss the interactions. But then the PTK0 rekey modifications needed very little extra effort and were ready much faster than assumed.

There are some interactions but nothing major. Nevertheless both PTK0 rekeying and Extended Key ID patches would a bit different without the other and for Extended Key ID the v8 version of the series is actual showing what.

The only hard dependency is the new key_flag API for extended Key ID.
Which as a standalone would look like overkill without the new special Extended Key ID cases and just be a small fix to set_tx usage.

PTK0 rekeying is setting up a new callback for the eapol SM to find out from the WPA SM if it can (re-)install a PTK or should abandon the eapol reauthentication immediately. With Extended Key ID only the WPA SM can answer that question. So the PTK0 rekey patches are handling that what seems to be a subotimal way but is later needed.

I can post that as three different series assuming the previous patches have been also applied. This should cut down the resend. (But not V9, which had changes in all areas.)

In fact you can already abort the series after the PTK0 patches (I did verify that is a valid break point) and while not tested much the same should be true for the key_flag API changes.

Is that ok or would you like to have the PTK0 rekey patch as it would be without Extended Key ID on the radar and via versa? and would you then prefer to postpone the additional key_flags only used with Extended key ID to the Extended Key ID series?

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