diff mbox series

[v6,17/17] hostapd: Extended Key ID stress test

Message ID 20190915200837.196283-18-alexander@wetzel-home.de
State Superseded
Headers show
Series Support seamless PTK rekeys with Extended Key ID | expand

Commit Message

Alexander Wetzel Sept. 15, 2019, 8:08 p.m. UTC 
Change the default keyid to 1 for the first pairwise key when using
Extended Key ID. This is so far only intended to cause compatibility
problems as soon as possible and not delay them till we rekey.

When a broken STA claims to be compatible with Extended Key ID it will
still assume keyid 0 is being used for the first key and never be able
to communicate with our AP supporting Extended Key ID.

Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
---

For now this is has mainly two functions:
1) Guarantees that Extended Key ID can really be used at the initial
   connect. Many potential issues are linked to the usage of keyid 1
   for a unicast key, so make sure this happens as soon as possible.

2) The existing tests will find many of these issues, even when not
   rekeying the connection

I have some plans to extend that later:
By e.g. starting a EAPOL group handshake directly after the connect we
can verify if the keyid 1 transport is really working. When the
handshake times out hostapd could install the same key for keyid 0,
disabling Extended Key ID support and allow the broken STA to still
communicate with the BSS.

This idea is mostly based to the fact that one of my devices (Samsung
Galaxy Tap S3) is setting the "Extended Key ID" capability flag wrong.
The AP therefore (correctly) starts using it. But when the AP rekeys
the PTK is losing the connection. It looks like the device is just
copying the capability bit from the AP RSN. And chances are more devices
have the same bug...

I'm not sure if we really want to deploy such a workaround. It's
probably hard to get rid of and just getting the broken devices fixed
is be the better solution. But till that is done users will wonder why
it's not working, so handling that outside of the standard may be
better.
Of course the workaround would be optional:
I think we could set wpa_extended_key_id to 2 by default and allow the
user to disable the workaround by setting it to 1.

Another option would be to simply drop the patch or use it only creating
binaries for testing. (CONFIG_TESTING_OPTIONS)
After all PTK rekeying is - based on all devices I could get my hands on
- mostly broken. The chance to have an AP and a STA able to rekey really
correctly under load is as of today really bad. (Maybe 20% success rate?)
Therefore it looks like rekey is not used very often and when we start
with keyid 0 and never rekey it will also work for most users.

On the other hand I prefer a clean failure to something working on the
brink of failure: So this patch series tries to make sure it fails as
soon as possible.

 src/ap/wpa_auth_ie.c | 1 +
 1 file changed, 1 insertion(+)
diff mbox series

Patch

diff --git a/src/ap/wpa_auth_ie.c b/src/ap/wpa_auth_ie.c
index 833abe14a..2e3204f5d 100644
--- a/src/ap/wpa_auth_ie.c
+++ b/src/ap/wpa_auth_ie.c
@@ -545,6 +545,7 @@  int handle_extended_key_id(struct wpa_state_machine *sm, int capabilities)
 			return -1;
 		} else if (!sm->use_extended_key_id) {
 			sm->use_extended_key_id = TRUE;
+			sm->keyidx_active = 1;
 		}
 	} else {
 		if (sm->use_extended_key_id && sm->pairwise_set) {