Am 06.01.20 um 10:39 schrieb Jouni Malinen:
On Sat, Jan 04, 2020 at 11:10:15PM +0100, Alexander Wetzel wrote:
Change the default keyid to 1 for the first pairwise key when using
Extended Key ID. This shifts potential problems to the initial connect.
Without that broken STAs accidentally claiming to be compatible with
Extended Key ID would work at the initial connect and only fail when the
connection is rekeyed.
While this sounds like a nice idea, I'm afraid this will guarantee
interoperability issues with deployed stations and as such, cannot
really be done by default. Maybe change the wpa_extended_key_id config
parameter to have three values: 0=disabled, 1=enabled with Key ID 0 used
first, 2=enabled with Key ID 1 used first.
Well, I can of course add that, too. But how can there be
interoperability issues today? Chances are my AP here is the only one
able to trigger the issue at the moment. (If Johannes, Luca or one of
their colleagues are not already having one also in the meantime, too...:-)
And what better time to define some rules as long as we are the only
players on the field?
I see the compatibility with us in the responsibility of the new
implementations to cope with something well within the standard. Or at
least point it out when we got something wrong, so we can find a
solution together.
The AP tells the client which KeyID it wants to use out of [0, 1] and
the supplicant configures it as told.
The main issue with deployed stations is that there are number of known
implementations that copy RSN Capabilities values from the AP's RSNE to
Association Request frame and by doing so, negotiate various things they
do not actually support.
Sure, but that's only applicable when we:
a) keep Extended Key ID enabled on the AP by default
b) and are willing to accept that the STAs then working are breaking
when/if we rekey. Which for the user will be like: "Oh heck, why is my
WLAN not working again? It works when I reboot the router and then after
some time just fails." (Some of the good PTK0 rekey candidates issues I
found are already saying that. They do not even try a reconnect instead
of rebooting the AP after discovering that)
When you want to disable Extended Key ID support on the AP by default I
still would prefer Extended Key ID to failing at the initial connect
compared to "maybe some random time later"
But to repeat and enhance a similar statement from another mail today:
Tell me what you want me to change and I'll do it. Will now probably
take some days at least (vacation is ending, so less time to code and
some of the chances will require some QA testing till I'm ready to
release them again.)
So far plan is:
- Split out PTK0 rekey. Even when you still want me to change the
default to not reconnect this will is trivial and will basically only
update the documentation.
- Second patch set will introducing a parameter struct for set_key(),
add the key_flag to that and NOT drop set_tx, drivers can still
use it.
- Third patch set for Extended Key ID support with whatever default we
agree here now after I tried to defend my initial selection. With both
FT and FILS not using the proposed solution here but make it
dependent on non-default settings for wpa_extended_key_id.
Which keyID the AP use at the initial connect still to be confirmed,
but I really would like to use id 1 as default at least for the
tests. I found quite some broken test cases and some real problems
with my implementation after changing the default keyid and would like
to prevent adding bugs with new features.
I think I'll just release the first patch set and wait till/what of it
gets merged and then send the next series. After all the v9 of the
series is - besides one wrong key_type for a deletion and the wrong
patch which slipped into the "drop set_tx" patch - what we need for the
discussion and even tests if someone want to do so.
Thanks for all the feedback so far,
Alexander
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
