IEEE 802.11ai - 2016 is missing any instructions how Extended Key ID
shall be handled combination with it. But there seem to be only two ways:
1) FILS can only use keyid 0 and the STAs only decide on rekey if they
can use Extended Key ID.
2) FILS also checks is Extended Key ID can be used by both STAs and if
so adds the KeyID KDE in addition to the GTK/IGTK KDEs.
Since the later seems to be a closer to the intent of 802.11ai and there
are no other implementations for Extended Key ID we could be incompatible
to this patch implements 2) for now.
Signed-off-by: Alexander Wetzel <alexander@xxxxxxxxxxxxxx>
---
Now this is a very free interpretation how to handle Extended Key ID in
combination with FILS. Technically it's the same issue as we have for
FT, so I'm using the same (arguable) solution here:
We bypass the 4-way handshake and Extended Key ID is therefore mostly
irrelevant. Neither FILS nor FT make any concession for Extended Key ID
but have a mechanism to get the GTK ID. Which of course can also pass
over the (unicast) KeyID required for Extended Key ID support...
Now the new patch series is rigorously sticking to the key install mode
used at the initial connect: When either the AP or the STA tries to use
anything else than for the connect we kill the connection. By also
adding the KeyID to the KDEs these checks work basically out of the box
and the Extended Key ID flag in the RSN capabilities serves a purpose.
Alternatively we could relax the checks and accept, that we either still
set the Extended Key ID bit in RSN but just assume the keyid is always
zero for FT and FILS or even drop the bit in the RSN capabilities and
relax the sanity checks for FILS and FT.
Since any not Extended Key ID capable STA won't care either way and
there are zero implementations for Extended Key ID we have to stay
compatible with I decided to first try what I consider the cleanest way.
Therefore Unicast KeyIDs have been added to the frames transporting also
the GTK ID. Based on the feedback we either keep or change it.
src/ap/wpa_auth.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c
index 0213e97c2..10c58c26c 100644
--- a/src/ap/wpa_auth.c
+++ b/src/ap/wpa_auth.c
@@ -2692,6 +2692,15 @@ static struct wpabuf * fils_prepare_plainbuf(struct wpa_state_machine *sm,
wpabuf_put_u8(plain, WLAN_EID_EXT_KEY_DELIVERY);
wpa_auth_get_seqnum(sm->wpa_auth, NULL, gsm->GN,
wpabuf_put(plain, WPA_KEY_RSC_LEN));
+
+ hdr[1] = 0;
+ if (sm->use_extended_key_id) {
+ hdr[0] = sm->keyidx_active & 0x01;
+ tmp = wpabuf_put(plain, 0);
+ tmp2 = wpa_add_kde(tmp, RSN_KEY_DATA_KEYID, hdr, 2, NULL, 0);
+ wpabuf_put(plain, tmp2 - tmp);
+ }
+
/* GTK KDE */
gtk = gsm->GTK[gsm->GN - 1];
gtk_len = gsm->GTK_len;
@@ -2708,7 +2717,6 @@ static struct wpabuf * fils_prepare_plainbuf(struct wpa_state_machine *sm,
gtk = dummy_gtk;
}
hdr[0] = gsm->GN & 0x03;
- hdr[1] = 0;
tmp = wpabuf_put(plain, 0);
tmp2 = wpa_add_kde(tmp, RSN_KEY_DATA_GROUPKEY, hdr, 2,
gtk, gtk_len);
@@ -2754,6 +2762,7 @@ int fils_set_tk(struct wpa_state_machine *sm)
wpa_printf(MSG_DEBUG, "FILS: No valid PTK available to set TK");
return -1;
}
+
if (sm->tk_already_set) {
wpa_printf(MSG_DEBUG, "FILS: TK already set to the driver");
return -1;
@@ -2763,7 +2772,7 @@ int fils_set_tk(struct wpa_state_machine *sm)
klen = wpa_cipher_key_len(sm->pairwise);
wpa_printf(MSG_DEBUG, "FILS: Configure TK to the driver");
- if (wpa_auth_set_key(sm->wpa_auth, 0, alg, sm->addr, 0,
+ if (wpa_auth_set_key(sm->wpa_auth, 0, alg, sm->addr, sm->keyidx_active,
sm->PTK.tk, klen, KEY_TYPE_PAIRWISE)) {
wpa_printf(MSG_DEBUG, "FILS: Failed to set TK to the driver");
return -1;
--
2.22.0
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
