Am 06.01.20 um 10:44 schrieb Jouni Malinen:
On Mon, Jan 06, 2020 at 10:28:21AM +0100, Johannes Berg wrote:
On Mon, 2020-01-06 at 11:26 +0200, Jouni Malinen wrote:
The standard may claim to be fully backwards compatible, but that does
not mean there would be guarantee of no regressions or interop issues if
this were enabled.. I'd consider getting this in first with default
being the functionality being disabled. Once there is some more trust in
this actually working and not causing problems (e.g., an independent
implementation to test against), the default could be changed in the
future.
You'll never find out if you don't enable it though? :)
Sure, but I do not want to force that testing to unsuspecting end users
when they update an unrelated device and something does not work
anymore..
But are you thinking that clients might get confused by a new extended
capability bit getting set? That's something that happens all the time.
Or clients might erroneously set the extended capability bit for
extended PTK IDs?
My main concern is that latter one since there are known deployed
stations that copy RSN Capabilities from AP to Association Request frame
without understanding what they enable. In addition, I'd like to
minimize risk on different interpretation on how CCMP/GCMP handling of
different Key ID gets indicated and used in practice. That's supposed to
be straightforward, but I've seen way too many interop issues in the
past due to vendors managing to interpret the standard in very strange
ways and/or implementing things incorrectly.
The chance of using Extended Key ID is today basically zero when you are
not out to test it. And I would assume whoever is making the next
implementation is testing it against this one and reaching out when
disagreeing with some decision.
To use it today you would have to use an AP and a client both using a
mac80211 card supporting ONLY SW crypto or - hopefully in the near
future - any iwlwifi card.
I do not expect the situation to change radically in the next years.
(After all it has taken more than 8 years and a frustated PTK rekey user
to start playing developer to get the first implementation after
Extended Key ID had been standardized.:-)
I have it running on my home router and with my very limited test set I
already found that the Samsung Galaxy Tab S3 (using stock rom) sets the
Extended Key ID cabability flag when the AP set it - looks like a copy -
but is still not able to handle Extended Key ID. (The tablet really
sucks at PTK rekeying regadless with or without Extended Key ID, so you
hardly see a difference when you rekey all 30s.)
I was thinking about opening a ticket, but I could not figure out how...
(And I do not like my chances getting that through to someone actually
able to understand and care about that.)
If I would work at e.g. Cisco and planning to sell a new AP able to use
Extended Key ID I would for sure disable it by default. But for hostapd
the idea was to enabling it now by default. So there are hopefully some
Extended Key ID capable clients (iwlwifi with linux?) in most test
setups soon and able to highlight the issue.
Changing the default later seems is only postponing the issue and making
it worse when more drivers start implementing it.
Keeping it disabled on hostapd by default but enable it in
wpa_supplicant may be a middle way for now, but I do not see how we can
change the default later either.
Keeping it disabled everywhere seems to be the worst possible solution.
I have the impression that there can't be 10 persons world-wide who care
about PTK rekeys while thousands are unknowingly using the insecure PTK0
rekey.
Chances are nobody will enable it and we'll be stuck with the PTK0 rekey
forever and only special setups who care about it enable it.
Honestly I would like to propose to make Extended Key ID mandatory in
(one of) the next version of IEEE802.11. But I'm doing that here as a
hobby and do not see how I can make such an suggestions without being a
member and the backing of other. (But I did not spend much time figuring
out how that is handled. There are so far more interesting things to
work on:-)
Alexander
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
