On 21/11/2018 12:16, Jouni Malinen wrote: > On Tue, Nov 20, 2018 at 11:42:25PM +0000, Marianna Carrera wrote: > >>> http://patchwork.ozlabs.org/patch/978101/ >>> easymesh: add backhaul BSS support for WPS M8 > >>> - should not need wps_cred_processing_easymesh config parameter, i.e., >>> presence of easymesh_backhaul_ap_settings is sufficient to determine >>> whether the feature is enabled >> >> was discussed, we decided to keep the same approach as extra_cred. What about we change it for: >> multiap_backhaul_ap_settings: if unset the feature is disabled, if set it points to an external file (if you agree with below) > > If this design were to be used, yes, that would be the way I would > configure it. However, .. > >>> - cannot use hardcoded external file to build the Credential for >>> backhaul STA since MAC Address attribute depends on the Enrollee's >>> MAC address and changes for each device Hm, I realize now: what was proposed here is the same situation as skip_cred_build=1 and extra_cred=some-file. That couldn't possibly work either then, right? >>> * configure needed SSID/passphrase/etc. parameters instead and allow >>> hostapd to build this Credential dynamically when needed >> >> The one concern I have with creating a config param for each attribute to be added into the Credential TLV is that as far as I understand the WSC spec is very open on what TLV can be carried inside Credential, so we'd have to come up with a very inclusive long list of params, or a short list that may require code update in the future. > > Why would there be changes for this? The WSC tech spec is not going to > be modified much, if at all, anymore, and we are talking about a very > specific provisioning case here: how to provide credentials for the > Multi-AP backhaul STA. This sounds like about as static case of WPS > provisioning as there can be.. > >> What if we have the registrar, when the feature is enabled, to build the 0x100E attribute by concatenating the enrollee's mac address attribute (0x1020) with the binary blob from the external file (so to maintain the flexibility to add any attribute the multi-ap controller would send)? Are there other attributes that cannot be known a priori and stored in the external file? > > This sounds unnecessarily complex to me. I don't see why we would need > to configure more than the SSID and passphrase/PSK of the backhaul BSS > (assuming the same passphrase/PSK is used for each backhaul STA). All > the other attributes within the Credential are either hardcoded or known > to Registrar: > - Network Index: deprecated, hardcoded to 1 > - SSID: from new configuration parameter > - Authentication Type: 0x0020 (WPA2-Personal) > - Encryption Type: 0x0008 (AES) > - Network Key Index: deprecated; not included > - Network Key: from new configuration parameter > - MAC Address: Enrollee's MAC Address > - and that's it; no other attribute is applicable for this use case Table 36 of the WSC specification already enumerates 5 additional optional attributes: EAP Type, EAP Identity, Key Provided Automatically, 802.1X Enabled, Network Key Shareable. In addition, Multi-AP R2 might require an additional credential attribute (as a vendor extension, most likely). Marianna, do you expect that to be the case? Now, even in that situation, we're going to need to patch wpa_supplicant to handle that additional attribute, so we could just as well patch hostapd at the same time to include it. And regardless, you can always use extra_cred to pass additional attributes (they won't be part of the ATTR_CRED then, but they will be encrypted). [snip] >> As far as the high level sequence, what I had in mind when we designed the two patches we submitted is the following (looking at the case where the fronthaul and the backhaul BSS are different BSSes, cause otherwise it's trivial): >> >> 1. A MAP agent that is not yet configured brings up only the station interface. >> --> this is for a configuration software above hostapd to take care of (like PrplMesh) > > Is that "the station interface" referring to a new netdev/vif being > created or would that use an existing main netdev (say, wlan0) of a > radio? Or that does not matter here? The key point I'm trying to > understand here is in whether wpa_supplicant would need to be involved > in creating a new virtual interface here or would that always be assumed > to be outside the scope of wpa_supplicant functionality for this > sequence? There is no difference with normal WPS: the upper layer (e.g. OpenWRT) is responsible for creating the vif if needed (small caveat: AFAIK OpenWRT doesn't currently support WPS for stations). > >> 2. This interface adds a Vendor Specific WFA Element of type MAP in Assoc Requests and M1. >> --> this is covered partially by our http://patchwork.ozlabs.org/patch/999135/ patch, and partially by http://patchwork.ozlabs.org/patch/999588/ >> >> 3. This interface tries to do WSC push button with the fronthaul BSS of an existing agent >> --> backhaul shall not have PBC enabled, so I think no need to restrict this explicitely. >> --> upper layer software like PrplMesh need to ensure that "pressing the button" results in a single fronhaul BSS going into active PBC mode (likely requires user interaction to ensure we know which of the multi frouhaul SSID shall go into pairing mode) >> >> 4. The existing MAP Agent provides in M8 the credentials for the backhaul SSID: wpa_supplicant learns the credentials and associates with the backhaul SSID >> --> this is the standard behavior asaik >> >> 5. The 1905 management layer (e.g., PrplMesh) starts the MultiAP-extended 1905 AP-Autoconfig exchange with the MAP Controller (some other entity in the LAN) >> - This exchange uses M1/M2 messages to provide a full multi-SSID configuration to the agent. >> - The 1905 management layer (e.g., PrplMesh) validates and parses the received configuration and: >> 1/ prepares the external credential file for the backhaul SSID (which can likely be copied as-is from the M2 received in 1905 frame) >> 2/ for each frounhaul BSS: writes the hostapd config (ssid/pwd/enable wps), enables multiap_backhaul_ap_settings feature by setting it to the external credential file path >> 3/ for each backhaul BSS: writes the hostapd config (ssid/pwd/disable wps) >> --> From now on, this new agent should be able to behave as the agent I mentioned in step 4 (assuming we fixed what we discussed above wrt to mac address attribute) >> >> Do you have a different understanding, or would you approach this differenlty? > > 2-4 sounds clear. For 5, I'm not that familiar with the design, but that > sounds reasonable. However, please note comments above about the > viability of using external credential file (i.e., I'd replace that with > preparing hostapd configuration with, say, multiap_backhaul_ssid and > multiap_backhaul_psk parameters for generating backhaul STA WPS > Credential within hostapd). Given the discussion so far, I agree with this. Regards, Arnout _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
