Re: [PATCH v2 0/5] wifi: add opt-in FIPS exception for iwlwifi

[Jose Ignacio Tornos Martinez <jtornosm@redhat.com>]

Hi Johannes,

> A-MSDU size is definitely dependent on PTK since A-MSDU splitting
> requires hardware crypto, and otherwise the RX buffers aren't big
> enough (by default, but it's not worth the complexity, and people won't
> want to do big allocations anyway).

Ok, A-MSDU stays out.

> EHT requires MFP and beacon protection, beacon protection requires
> checking in firmware since firmware reacts to beacon frames.

Understood, so Beacon Protection needs BIGTK offloaded to firmware.
With the approach of IGTK/BIGTK to firmware, this should be
possible, and then EHT can be re-enabled.

> 6 GHz was documented in the code.

Ok, I will check the code comments for that dependency.

> MLO needs EHT and then transitively that was disabled.

Clear, the chain is MLO -> EHT -> MFP + Beacon Protection.

> The biggest question then remains what MFP gaps you create with this. I
> _think_ you might even have to install random keys to the firmware, but
> ... then maybe it wouldn't even pass certain frames to the driver? I'm
> not sure you want to accept a loss of MFP security.

This is the part I am investigating now. Without PTK in firmware,
firmware-autonomous TX management frames (like AddBA) would be
unprotected, that is the accepted trade-off. For RX, the question
is whether firmware forwards protected unicast management frames
to mac80211 for SW decryption or drops them. I am testing this.

About random keys, I think that would cause firmware to attempt
decryption with wrong keys and corrupt or drop the frames, so
probably not a viable path, but needs to be tested.

Regarding MFP security, the intention is not to lose it but to
handle it in software where possible. I think the only gap would be
firmware-autonomous frames that bypass mac80211, but of course I
need to confirm it.

Thank you for your help again

Best regards
Jose Ignacio