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

[Johannes Berg <johannes@sipsolutions.net>]

Hi,

> What I would like and what we need is: data encryption stays in
> software (FIPS-compliant), WiFi connectivity works, and we accept
> that some management frame protection is not fully FIPS-validated.

Fair.

> > Well, it does work without MFP, so fundamentally the firmware can pass
> > data without having keys?
> 
> That is what I would expect, but in v1 I only re-enabled MFP_CAPABLE
> without passing any keys to firmware and got connection but no data
> traffic. Looking at the code, mac80211 SW crypto plumbing works
> correctly when drv_set_key() does not install keys in hardware,
> and the TX path sets IWL_TX_FLAGS_ENCRYPT_DIS for pre-encrypted
> frames. So the host side should handle it. My suspicion is that
> firmware changes its behavior when MFP is negotiated, expecting
> keys to be installed, and drops encrypted data frames it cannot
> decrypt instead of forwarding them to the host. The SEC_ENC_ERR
> messages I saw in v1 were likely from management frames, not data.
> Any guidance on this would help me take the right approach for v3.

I don't _think_ it does that. It does behave a bit differently for MFP,
but that's wrt. management frames.

Fundamentally, in this case the driver (even mac80211) shouldn't install
(data) keys to hardware.

> > That's not the point - the point is that there are different
> > dependencies and you didn't think about _why_ something is disabled.
> > Not all of this is all related to MFP.
> 
> Fair point. These dependencies were not documented in the original
> disabling commits, so I treated everything as a single block to
> revert. Could you clarify which features depend on MFP, which on
> HW crypto, and which on other reasons? That would help me get
> the separation right.

I'd need to sit down and (re-)derive that, but I don't recall it being
particularly tricky - just boils down to the various dependencies
between features.

> Spelled out: data encryption (PTK/GTK) must stay in software
> (FIPS-compliant). We accept that firmware-autonomous management
> frames (like AddBA) are not FIPS-protected. We accept reduced
> uplink throughput from missing TX aggregation. We do not need
> big A-MSDUs or WoWLAN. The goal is a working WPA3-SAE connection
> with FIPS-compliant data path.

Presumably that would mean IGTK/BIGTK can be offloaded and remain
working, but TK/GTK can't be known to the firmware since it's not FIPS
certified.

I mean, you _could_ push this further and keep almost all features: you
still give PTK/GTK to firmware but don't use the offload mechanisms for
data frames; though presumably then you'd not consider the result "good
enough" since then a non-certified component (the firmware/hardware)
holds the keys...?

> Also, is the general approach of an opt-in boot parameter
> (fips_exception) to keep the default behavior unchanged
> acceptable, or would you prefer a different mechanism?

I have no opinion on that, I guess the crypto folks should chime in
about that. Having something very obvious makes sense to me, vs. having
it at wifi or even driver level.

johannes