On Thu, Feb 14, 2019 at 01:46:53PM +0100, Mikael Kanstrup wrote: > A few APs out on the market have got the byte order of IGTK key > index wrong making PMF enabled connections fail to connect. The faulty > APs request STAs to configure IGTK with key ID value 1024 or 1280. > Looking more closely into the values requested, 4 and 5 in 16-bit > network byte order/big endian byte order happens to correspond to > 1024 and 1280 respectively in wireless little endian byte order. As > connect attempts using out of spec values will anyway fail detect > and workaround the problem by reading the incorrect values in big > endian format. Do you have reason to believe that the particular APs with this behavior have PMF working otherwise? For example, is the IGTK provided by those APs with this swapped KeyID actually the correct IGTK and if the AP were to transmit a group-addressed robust management frame, that would be correctly protected using this IGTK? And maybe more importantly, that the particular IGTK is not a predictable value where this type of workaround would result in a security vulnerability. If the AP does not implement PMF correctly, the best workaround would likely be to not try to use PMF with that AP. Allowing the association to go through can result in false sense of security and some upper layer operations getting unexpected behavior if the station device assume there is protection for all the robust management frames while that is not really the case. Do you have such a broken AP available for testing different types of workarounds for this issue? My main issue with this item has been that I have no such AP, so I cannot really fully evaluate the impact of various possible workarounds for this. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
