diff mbox series

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

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

Commit Message

Alexander Wetzel Aug. 17, 2019, 9:14 p.m. UTC 
Change the default keyid to 1 for the first key install when using
Extended Key ID. This is so far only a fail-early to highlight
compatibility problems for the hostapd tests and in real environments:

Instead of connection problems after the first rekey the initial connect
will not work.

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

For now this is has mainly two functions:
1) Grantees that Extended Key ID can really be used at the initial
   connect. Many potential issues are linked to keyid 1 for 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 keyid 1 transport to be really working. If that times out
hostapd could install the key also for keyid 0, disabling Extended Key
ID support and allow the broken STA to still connect to the AP.

This is mostly due to the fact that one of my devices (Samsung Galaxy
Tap S3) set the "Extended Key ID" capability flag when connecting to my
patched AP. The AP therefore assumes the device can handle it. But when
the AP switches the PTK to keyid 1 the device loses the connection.
It looks like the device is just copying the capability (bit) from the
AP. Chances are this affects more Samsung devices...

Now 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
may be the better solution. Of course this 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. 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?) Therefore it looks like
rekey is used not 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 725c76056..3207990e5 100644
--- a/src/ap/wpa_auth_ie.c
+++ b/src/ap/wpa_auth_ie.c
@@ -553,6 +553,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) {