SV: [RFC] PMF: Allow Key ID in big endian format to workaround faulty APs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>From: Jouni Malinen <j@xxxxx>
>Sent: Feb 15, 2019 11:10
>> 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.

...
>> 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?

Good point. Only limited checks done. For example that AP can handle encrypted
deauth frames.

> 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?

I've only been able to get hold of one of these AP models. It's a home router
with limited feature set. No fast bss transition support for example. So was not
able have the AP send any frames that should be encrypted with IGTK and can't
really answer if the IGTK was valid or not.

Looking at that ieee standard I don't think it's obvious which frames should
be encrypted with IGTK. If you know of any common frame types I can check.
Must admit I've mostly looked at PMF as a way to prevent deauth attacks.

> And maybe more importantly, that the particular IGTK is not a predictable
> value where this type of workaround would result in a security vulnerability.

Hard to tell just by looking at the IGTK received. But yeah good point.

> If the AP does not implement PMF correctly, the best workaround would
> likely be to not try to use PMF with that AP.

Right. Maybe this should rather be implemented outside of wpa_supplicant. Like
disabling PMF for the specific network if PMF fails.

> Do you have such a broken AP available for testing different types of
> workarounds for this issue?

I have access to only one that I unfortunately cannot share information about. But I
can get hold of vendor OUI from a couple APs and probably determine brand/model
for a few of them.

> 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.

Understood. I'll try to gather necessary information.

Thanks for feedback!

/Mikael
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux