Hi Jouni, On 5 February 2017 at 13:03, Jouni Malinen <j@xxxxx> wrote: > On Tue, Jan 31, 2017 at 02:20:34AM +0100, Andrew Zaborowski wrote: >> I couldn't firgure out what sm->Pair is exactly but with FT it's going >> to be false, unlike after an EAPOL 4-Way handshake and the install bit >> will be true in effect. Is there any reason the install bit isn't >> just hardcoded to 0, as defined by 11.6.2 and illustrated by the >> message sequences in 11.6.7? > > sm->Pair is actually supposed to be hardcoded to TRUE and it is just > because of the FT protocol (and FILS authentication) case having a > mechanism to skip proper state machine initialization which resulted in > this not getting set.. The !Pair case is somewhat of a theoretical one > here currently, but based on the standard, this should be used for RSN > IBSS in one direction. > > I'll do following to fix the Install bit in group key handshake during > an association started with FT protocol or FILS authentication: > > diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c > index 66b2d50..0bd901f 100644 > --- a/src/ap/wpa_auth.c > +++ b/src/ap/wpa_auth.c > @@ -615,6 +615,7 @@ int wpa_auth_sta_associated(struct wpa_authenticator *wpa_auth, > "start 4-way handshake"); > /* Go to PTKINITDONE state to allow GTK rekeying */ > sm->wpa_ptk_state = WPA_PTK_PTKINITDONE; > + sm->Pair = TRUE; > return 0; > } > #endif /* CONFIG_IEEE80211R_AP */ > @@ -625,6 +626,7 @@ int wpa_auth_sta_associated(struct wpa_authenticator *wpa_auth, > "FILS authentication already completed - do not start 4-way handshake"); > /* Go to PTKINITDONE state to allow GTK rekeying */ > sm->wpa_ptk_state = WPA_PTK_PTKINITDONE; > + sm->Pair = TRUE; > return 0; > } > #endif /* CONFIG_FILS */ Looks good, thanks. > > >> Similarly it seems the nonce should just be 0 since it's neither >> ANonce or SNonce, and Key Length should be hardcoded to 0 in >> __wpa_send_eapol. Patch for illustration. > > The standard looks a bit ambiguous on the Key Nonce field.. The example > group handshake figure and the Authenticator state machine figures > describe the Send EAPOL operation as using GNonce as the nonce value > while the subclauses listing the field values for EAPOL-Key messages > show 0. The hostapd implementation followed the Authenticator state > machine description. That said, there is no use for GNonce on the > Supplicant side, so I'll clear it to zero with this: > > @@ -3102,7 +3106,7 @@ SM_STATE(WPA_PTK_GROUP, REKEYNEGOTIATING) > (wpa_mic_len(sm->wpa_key_mgmt) ? WPA_KEY_INFO_MIC : 0) | > WPA_KEY_INFO_ACK | > (!sm->Pair ? WPA_KEY_INFO_INSTALL : 0), > - rsc, gsm->GNonce, kde, kde_len, gsm->GN, 1); > + rsc, NULL, kde, kde_len, gsm->GN, 1); > > os_free(kde_buf); > } Thanks, indeed GNonce is shown in that diagram. In that case I guess they're equally correct but I'd pick 0. > > > The Key Length field has a bit more complex story.. P802.11i/D3.0 > defines that field as having value 16 for EAPOL-Key group message 1/2. > That behavior needs to be maintained for WPA interoperability. That > said, it looks like it would be fine to clear this to 0 for WPA2 (RSN) > cases and hopefully that does not cause any new interop issues.. I'm > planning on doing this to address that: After looking through the spec again it looks like either value would be good here too. While 802.11-2012 11.6.2 says "length in octets of the pairwise temporal key to configure", and so this doesn't apply to the GTK, it doesn't list 0 as a special backup value or anything similar. 11.6.7.2 shows 0 but the "Key Length" fields in FTE GTK / IGTK subelements are the length of the unwrapped / unpadded GTK / IGTK. Best regards _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
