Message ID | 20200104221015.90469-17-alexander@wetzel-home.de |
---|---|
State | Changes Requested |
Headers | show |
Series | Seamless PTK rekeys | expand |
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. 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.
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
diff --git a/src/ap/wpa_auth_ie.c b/src/ap/wpa_auth_ie.c index cb01e4d7f..0c9ab9725 100644 --- a/src/ap/wpa_auth_ie.c +++ b/src/ap/wpa_auth_ie.c @@ -573,6 +573,7 @@ int handle_extended_key_id(struct wpa_state_machine *sm, int capabilities) " supports Extended Key ID", MAC2STR(sm->addr)); sm->use_extended_key_id = TRUE; + sm->keyidx_active = 1; } else if (!sm->pairwise_set) { wpa_printf(MSG_DEBUG, "STA " MACSTR " is not supporting Extended Key ID",
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. Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de> --- src/ap/wpa_auth_ie.c | 1 + 1 file changed, 1 insertion(+)