[PATCH 00/92] Add NAN PASN pairing support

[Johannes Berg]

On Mon, 2026-04-27 at 19:50 +0300, Jouni Malinen wrote:
> On Mon, Apr 27, 2026 at 12:22:18PM +0200, Johannes Berg wrote:
> > On Mon, 2026-04-27 at 12:30 +0300, Jouni Malinen wrote:
> > > IMHO, the key will either need to be
> > > configured earlier (with all the extra checks to avoid misuse) or there
> > > needs to be a fallback mechanism that can decrypt a received frame that
> > > was not decrypted because the key was not quite yet configured for it.
> > 
> > I don't think such a fallback mechanism can really be done. We have up
> > to four different layers involved: HW/FW, driver, mac80211 and then
> > wpa_supplicant, with different implementations (from different vendors)
> > splitting MIC check and replay check differently, e.g. iwlwifi will
> > usually do MIC validation in HW/FW and replay check in the driver (due
> > to multi-queue).
> > 
> > Synchronising state across these layers for maintaining correct replay
> > counters when HW crypto cannot be used doesn't really seem plausible.
> 
> Understood that this would be really inconvenient and that other
> approach (early key configuration) would likely be significantly
> simpler. This could be as simple as having wpa_supplicant configure the
> key before sending out PASN Auth 2 for NAN cases and then discarding all
> encrypted frames that are received from that peer device before a valid
> PASN Auth 3 has been received.

I guess we might even want to do such a thing in mac80211 - we should be
able to rely on _order_ of RX, but not timing of RX. You were referring
earlier to changes for EPPKE:

> IEEE P802.11bi will likely be changed to describe this. Something
> similar might be doable with Wi-Fi Aware.

While I don't know (yet) what 802.11bi might do in this area, perhaps
the same approach would be usable for NAN here.

> If there is a timeout on being able to
> validate the key, the key would be additionally removed from the driver.

I'm not sure that's explicitly needed, it would seem you'd want to
remove the station entry in this case as well? And then I think we
really could start relying on "keys are removed when stations are
removed" in new code that really only works with modern driver
infrastructure anyway.

johannes