| Message ID | 20200104221015.90469-14-alexander@wetzel-home.de |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Seamless PTK rekeys | expand |
On Sat, Jan 04, 2020 at 11:10:12PM +0100, Alexander Wetzel wrote: > IEEE 802.11ai-2016 is missing any instructions how to handle FILS in > combination with Extended Key ID. There are two obvious ways: > > 1) FILS connections can only use keyid 0 and the STAs decide on rekey > if they can use Extended Key ID or not. > > 2) FILS also checks if Extended Key ID can be used by both STAs and > adds the KeyID KDE - when it's used - to the FILS handshake. > > The latter seems to be closer to the intent of 802.11ai and since there > are no other implementations for Extended Key ID we could become > incompatible to this patch implements option 2) for now. This should be brought up for discussion in the currently ongoing IEEE 802.11 TGmd maintenance effort that will be updating IEEE Std 802.11-2016 and bringing in the IEEE Std 802.11i-2016 amendment into the same document. For the time being, I'd likely go with option of not using Extended Key ID at all with FILS if there is any risk of not coming up with an interpretation of the standard that everyone would agree with.
Am 06.01.20 um 10:35 schrieb Jouni Malinen: > On Sat, Jan 04, 2020 at 11:10:12PM +0100, Alexander Wetzel wrote: >> IEEE 802.11ai-2016 is missing any instructions how to handle FILS in >> combination with Extended Key ID. There are two obvious ways: >> >> 1) FILS connections can only use keyid 0 and the STAs decide on rekey >> if they can use Extended Key ID or not. >> >> 2) FILS also checks if Extended Key ID can be used by both STAs and >> adds the KeyID KDE - when it's used - to the FILS handshake. >> >> The latter seems to be closer to the intent of 802.11ai and since there >> are no other implementations for Extended Key ID we could become >> incompatible to this patch implements option 2) for now. > > This should be brought up for discussion in the currently ongoing IEEE > 802.11 TGmd maintenance effort that will be updating IEEE Std > 802.11-2016 and bringing in the IEEE Std 802.11i-2016 amendment into the > same document. For the time being, I'd likely go with option of not > using Extended Key ID at all with FILS if there is any risk of not > coming up with an interpretation of the standard that everyone would > agree with. > As mentioned I do not have the means to influence the standard as an outsider. But I totally agree. I can only enable it with wpa_extended_key_id set to 2 or higher. Since FT has a similar problem I'll do the same there, too. (It's mentioned in the older - really long - patch comments.) Or do you prefer to simply drop the patches? Alexander
diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c index c8ef366eb..23cd4df1b 100644 --- a/src/ap/wpa_auth.c +++ b/src/ap/wpa_auth.c @@ -2707,6 +2707,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; @@ -2723,7 +2732,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); @@ -2778,7 +2786,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_FLAG_PAIRWISE_RX_TX)) { wpa_printf(MSG_DEBUG, "FILS: Failed to set TK to the driver"); return -1; diff --git a/src/ap/wpa_auth_ft.c b/src/ap/wpa_auth_ft.c index 462876195..9c5e6dfc7 100644 --- a/src/ap/wpa_auth_ft.c +++ b/src/ap/wpa_auth_ft.c @@ -2660,7 +2660,7 @@ void wpa_ft_install_ptk(struct wpa_state_machine *sm) * again after association to get the PTK configured, but that could be * optimized by adding the STA entry earlier. */ - 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_FLAG_PAIRWISE_RX_TX)) return; @@ -2787,8 +2787,7 @@ static int wpa_ft_set_key_mgmt(struct wpa_state_machine *sm, return -1; } sm->pairwise = wpa_pick_pairwise_cipher(ciphers, 0); - - return 0; + return handle_extended_key_id(sm, parse->capabilities); }
IEEE 802.11ai-2016 is missing any instructions how to handle FILS in combination with Extended Key ID. There are two obvious ways: 1) FILS connections can only use keyid 0 and the STAs decide on rekey if they can use Extended Key ID or not. 2) FILS also checks if Extended Key ID can be used by both STAs and adds the KeyID KDE - when it's used - to the FILS handshake. The latter seems to be closer to the intent of 802.11ai and since there are no other implementations for Extended Key ID we could become incompatible to this patch implements option 2) for now. Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de> --- src/ap/wpa_auth.c | 12 ++++++++++-- src/ap/wpa_auth_ft.c | 5 ++--- 2 files changed, 12 insertions(+), 5 deletions(-)