On Wed, Nov 21, 2018 at 02:39:11PM +0100, Arnout Vandecappelle wrote: > On 21/11/2018 12:16, Jouni Malinen wrote: > >>> - 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? extra_cred does indeed have the same issue and it would be compliant with the WSC v2 technical specification. There is quite a bit more history on this detail, though.. The original WPS release in 2006 did not have the "Validation of Configuration Data" section and no shall statements regarding Enrollee verifying the MAC Address attribute value within Credential. This text was added as part of the version 2 work. extra_cred implementation predates that version 2 work.. wpa_supplicant/hostapd as Enrollee is actually ignoring the MAC address value in Credential by default (just noting incorrect value in debug log) and the strict validation and rejection is enabled only if the build is configured with CONFIG_WPS_STRICT. That said, I do not really want to introduce any new functionality that is clearly non-compliant with the current WSC tech spec. > 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? Those additional items in Table 36 are not really applicable for the Multi-AP backhaul connection since it does not use WPA2-Enterprise (EAP). Or well, Network Key Shareable is actually applicable for the Multi-AP use case, but that could as well get hardcoded to TRUE (i.e., no need to configure it separately) taken into account how the backhaul connection is provisioned between the APs with WPS. I don't think there is much of a point in trying to extend WSC tech spec today taken where WPS went and how any new use case should really be looking at using more secure provisioning mechanism. In other words, I don't really see any issues in (or significant future work from) limiting current Multi-AP implementation to use this minimal configuration (SSID + psk/passphrase) for WPS Credential. > 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). extra_cred should not really be used with any new design. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
