[PATCH 00/92] Add NAN PASN pairing support

[Otcheretianski, Andrei]

> Thanks, I applied all the non-hwsim-test patches with cleanup.
> 
> I would like to get a fix to get rid of the blocking os_sleep() call as noted in an
> earlier message. In addition to the issues mentioned then, it should also be
> understood that peer devices might use different implementation and that
> might not have this type of an extra delay.
> 
> If the protocol has a case where a key is configured at a time when the peer
> might already be sending a frame encrypted with that key, it might be
> necessary to add a workaround that is capable of postponing decryption of a
> frame from a peer while the key is being configured and then complete
> decryption in software (e.g., in mac80211/driver). This is obviously undesired
> extra complexity, but this area should be understood and documented more
> clearly.

Thanks again for a very quick response and review.
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.
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."
- 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.
I personally tend to the second approach which should be ok especially with the kernel fix to reduce the key installation time.

Andrei

> 
> --
> Jouni Malinen                                            PGP id EFC895FA