[PATCH 00/92] Add NAN PASN pairing support

[Jouni Malinen]

On Mon, Apr 27, 2026 at 08:00:18AM +0000, Otcheretianski, Andrei wrote:
> I totally agree with your comment regarding this sleep and we had a lot of internal discussions how it should be addressed.
> This sleep is a temporary workaround - I should have properly documented it. Actually,  it was originally in a separate "bugfix" patch with a proper explanation, but eventually I squashed it with the original commit.
> Anyway, the issue arises since the NAN specification defines (based on Figure 48) that NIK exchange should be started by the initiator. This is a bit awkward, as the initiator is sending the last PASN message.

This sounds like the exact same issue that shows up with EPPKE..

> In the current PASN implementation the responder installs the keys only after processing the last message and since installing the keys in the kernel calls synchronize_net() (which probably is not really needed for NAN case) it takes quite a lot of time and it misses the follow up message with NIK.
> Here are two possible approaches to address it (though none of this looks perfect):
>  - It is in theory possible to install the keys on the responder side immediately after processing the 1st PASN message (and roll it back if PASN fails). This however, results in installing keys without any verification of the peer and contradicts IEEE80211 PASN spec which states that the keys should be installed after processing the third message:
> 	"[..]For the third PASN frame, if the MIC validation fails, the AP shall discard the frame and terminate the
> 	processing of the frame with no further effect. If other validation fails, or base AKMP processing indicates an
> 	error, the AP shall terminate the PASN authentication. If the validation was successful, the AP installs the
> 	temporal key derived using MLME-SETKEYS.request primitive to install the new key."

This approach is what is already being done for EPPKE, i.e., hostapd
installs the TK before sending PASN/EPPKE Auth 2 so that the key is
available for decrypting the Association Request frame that follows
immediately after PASN/EPPKE Auth 3 from the STA.

Yes, this is quite inconvenient from the view point of having to
configure a key that is not validated, i.e., this needs to be done
carefully to avoid having that key being used for anything else than the
Association Request frame before PASN validation has been completed.

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

> - Another approach is to retry NIK follow-up exchange if no follow-up is received in response. This however doesn't solve compatibility with other devices that won't implement this retry mechanism.

This might work for some cases, but it is not really addressing the real
issue in the protocol design. 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.
Both of these options have significant inconveniences, though, but I
don't see what else could be done to make this work with any other
implementation that is compliant with the specification and does not
delay or retry.

-- 
Jouni Malinen                                            PGP id EFC895FA