| Message ID | 20191215093438.10120-1-ilan.peer@intel.com |
|---|---|
| Headers | show |
| Series | Support for Pre association Security Negotiation (PASN) | expand |
On Sun, Dec 15, 2019 at 11:33:58AM +0200, Ilan Peer wrote: > The following series of patches is an implementation of the > Pre Association Security Negotiation (PASN) as defined in > Draft 802.11az_D1.5. In short, PASN is a mechanism to establish > security association and allow Management Frame Protection (MFP) > prior to association. Does that D1.5-based implementation match what is there in D2.0? I don't really like using temporary task group drafts Dx.y where y is not 0 for implementation taken into account such a version has not been approved even for an internal working group review. > To support the PASN authentication flows while associated, the 3-way > authentication handshake is performed from the wpa_supplicant, > without the low level kernel driver being aware of the authentication > exchange, using the send_mlme() API which was extended to also allow > support for a wait option. In addition, some changes are introduced in > nl80211 driver to allow sending/receiving authentication frames. > To support processing of authentication frames in user space, > the following change in mac80211 is also required: > > - https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/commit/?id=2020ea4a16e35b28d50a77d883e2396995583f81 What's the plan with that mac80211 change? I don't see it in mac80211-next.git. I don't want to apply the hostap.git changes without the upstream kernel having the needed functionality in place. > Since the PASN authentication relies on support for wrapped data and > element fragmentation/defragmentation, the patch set includes changes > that introduce support for the missing parts. Such helper parts might be fine for inclusion in hostap.git, but I don't want to go through 40 patches to try to figure out what is ready to be applied and what is not. > e.g., information element Ids etc. are missing, the implementation uses > internally set values, that should be updated once the specification > is complete. I do not like to apply functionality that uses arbitrary identifiers and may conflict with other definitions. If all of these are within CONFIG_PASN blocks and clearly documented as such, that might be doable, but since not all the kernel components are in place either, it might make more sense to wait for the P802.11az work to get a bit more complete before applying some of the changes. The hwsim test cases would also need to cleanly address cases where either the driver/kernel does not support PASN or hostapd/wpa_supplicant is built without PASN support (i.e., they need to SKIP, not FAIL). I'm dropping this 40-patch series from my queue based on those comments. I'd recommend sending the changes in smaller sets (say, at most about 10 or so patches at a time) and to start with clear interface updates or generic functionality that is not specific to only PASN or that is clearly stable enough in P802.11ax to implement now (and does not depend on identifier values that have not yet been formally assigned). This should not depend on missing upstream kernel functionality either.
Hi Jouni, > On Sun, Dec 15, 2019 at 11:33:58AM +0200, Ilan Peer wrote: > > The following series of patches is an implementation of the Pre > > Association Security Negotiation (PASN) as defined in Draft > > 802.11az_D1.5. In short, PASN is a mechanism to establish security > > association and allow Management Frame Protection (MFP) prior to > > association. > > Does that D1.5-based implementation match what is there in D2.0? I don't > really like using temporary task group drafts Dx.y where y is not 0 for > implementation taken into account such a version has not been approved > even for an internal working group review. > AFAICT, there are no changes related to implemented functionality between version D1.5 and between version D2.0, but as I would need to submit the series again, I'll double check it. > > > > - > > https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwi > > fi.git/commit/?id=2020ea4a16e35b28d50a77d883e2396995583f81 > > What's the plan with that mac80211 change? I don't see it in mac80211- > next.git. I don't want to apply the hostap.git changes without the upstream > kernel having the needed functionality in place. > This indeed required a revised implementation to better handle versions of wpa_supplicant that always register to all types of authentication frames (as handled in the first patch in the series). A revised version of this patch would probably be sent to the mailing list by Luca sometime soon. If needed I can sent it (but as this patch set is dropped, this is probably not urgent). > > Since the PASN authentication relies on support for wrapped data and > > element fragmentation/defragmentation, the patch set includes changes > > that introduce support for the missing parts. > > Such helper parts might be fine for inclusion in hostap.git, but I don't want to > go through 40 patches to try to figure out what is ready to be applied and > what is not. Sure. > > e.g., information element Ids etc. are missing, the implementation > > uses internally set values, that should be updated once the > > specification is complete. > > I do not like to apply functionality that uses arbitrary identifiers and may > conflict with other definitions. If all of these are within CONFIG_PASN blocks > and clearly documented as such, that might be doable, but since not all the All such changes are documented, but I'll add the CONFIG_PASN. > kernel components are in place either, it might make more sense to wait for > the P802.11az work to get a bit more complete before applying some of the > changes. > > The hwsim test cases would also need to cleanly address cases where either > the driver/kernel does not support PASN or hostapd/wpa_supplicant is built > without PASN support (i.e., they need to SKIP, not FAIL). Will do for wpa_supplicant/hostapd. I'll need to figure out how to handle it in the kernel, as the kernel did not require any changes other than the one mentioned above. > > I'm dropping this 40-patch series from my queue based on those comments. > I'd recommend sending the changes in smaller sets (say, at most about 10 or > so patches at a time) and to start with clear interface updates or generic > functionality that is not specific to only PASN or that is clearly stable enough > in P802.11ax to implement now (and does not depend on identifier values > that have not yet been formally assigned). This should not depend on > missing upstream kernel functionality either. > Sounds like a good plan 😊 FWIW, I understand that this submission was not idle, but I just wanted to push this out so it would be available for others for use. Thanks! Ilan.