On Mon, Mar 16, 2020 at 11:54:41PM +0100, Alexander Wetzel wrote: > First: FT0 and FILS0 seem to to exactly what you want. I'm just not sure if > you are ok with how these modes "pin" Extended Key Id support with the > initial handshakes (FT or FILS) and make sure the rekeys are then using > something different later. I'm not I completely understood that pinning the support part, but I'll take a closer look at the details in the updated patch. > I would also have simple told the STA to signal support for Extended Key ID > and only check the KeyID in EAPOL#3: If there is a keyID use that. If not > use zero. But the standard forces us to check the RSN (chapter 12.7.6.4): > If the Extended Key ID for Individually Addressed Frames subfield of the RSN > Capabilities field is 1 for both the Authenticator and Supplicant then prior > to sending message 4, STA_P uses the MLME-SETKEYS.request primitive to > configure the IEEE 802.11 MAC to receive individually > addressed MPDUs protected by the STK with the assigned Key ID. > Simply acting on the KeyID would therefore violate the standard. That design is broken and should be ignored. Extended Capabilities element is not protected and the bits in in should certainly not override the protected exchange of Key ID KDE in EAPOL-Key msg 3/4. IMHO, it is perfectly fine and correct to not comply with that statement. This full text is pretty descriptive instead of using clearly normative language.. Anyway, I'll try to get this fixed in REVmd to use the presence of Key ID KDE as the rule for the station side and also add an explicit requirement for the AP to include Key ID KDE in msg 3/4 whenever using Extended Key ID (i.e., also require it to be there for Key ID 0 case). I did not see such an explicit requirement in the standard. > Yes, that would also be a problem... wpa_deny_ptk0_rekey != 0 is resetting > the connection normally way prior to getting the new keyID. > > when we not decide at the initial connection if we are using Extended Key ID > or not we would have to reset the connection much later and not at the first > indication one end plans to rekey. I'm still not completely sure I understand why there would be such a difference.. Station should assume the AP will be using Extended Key ID based on the Extended Capabilities indication from scan results (i.e., known at the time of the initial association). I'll see if I can understand this better when going through the updated patch. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
