On 21/11/2018 11:59, Jouni Malinen wrote: > On Tue, Nov 20, 2018 at 03:54:05PM +0100, Arnout Vandecappelle wrote: >> On 20/11/2018 00:23, Jouni Malinen wrote: >>> http://patchwork.ozlabs.org/patch/978101/ >>> easymesh: add backhaul BSS support for WPS M8 > >>> - 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 >> >> Actually that's not true: the MAC address attribute in M8's credentials is the >> BSSID, not the enrollee MAC address. At least, that's how I understand it. > > The WSC tech spec is not as clear on this detail as it could be for the > Registrar side functionality, but this attribute is supposed to contain > the Enrollee's MAC Address. It is documented as having "Member device's > MAC address" in the table that defined the Credential attributes. > Section 7.2.2 (Validation of Configuration Data) is much clearer on > that, though, with "the Enrollee shall verify that the MAC Address > attribute inside each Credential attribute ... matches with its own MAC > Address. If an address mismatch is found, the ConfigData shall not be > used and the protocol run shall be terminated with an error." You're right, sorry, I was confusing the M8 used in WPS with the M2 used in IEEE 1905.1 AP Autoconfiguration. Totally different thing. > In other words, a compliant Enrollee implementation would reject that > Credential if it contained the BSSID (or well, any BSSID.. there may be > more than one BSS in the ESS). I don't really see how this requirement > could be met cleanly with a hardcoded external file. > > >> What is clearly also missing is documentation of how it should all work. I >> think there should be a README-MULTI-AP somewhere that explains it all. Here is >> a start. Marianna, Wouter, Daniel, Jouni, please comment on it. Jouni, please >> let me know if this clarifies sufficiently how the multi-ap support is supposed >> to be used. > > Thanks for the description. It would be useful to have such > documentation available somewhere (whether part of > hostapd/wpa_supplicant or the Multi-AP Agent). I will rework the four patches and include this text in README-MULTI-AP. You can delegate them to me (user arnout) on patchwork if you like. > >> The AP side of the backhaul link is called a "backhaul SSID". Such an SSID must >> be handled specially by hostapd, because it must add an additional information >> element in each (Re-)Association Response, but only to stations that have >> identified themselves as backhaul stations ([3], section 5.2, paragraph 5-6). >> This is important because it is possible to use the same BSS and SSID for >> fronthaul and backhaul at the same time. The additional information element must >> only be used for frames sent to a backhaul STA, not to a normal STA. Also, >> frames sent to a backhaul STA must use 4-address mode, while frames sent to a >> normal STA must use 3-address mode. > > That use of the same SSID/ESS does not sounds particularly secure unless > those backhaul links use a different passphrase/PSK or some other > protected mean of identifying the backhaul STAs.. The information > element added into (Re)Association Request frame is not protected, so > anyone with access to this same BSS could claim to be part of the > backhaul if that is the only thing protecting this. Don't get me started on the security aspects of Multi-AP R1... Basically, unless all APs in the network take drastic measures (e.g. isolation with ebtables), any device in the network can pretend to be an Multi-AP agent (or even Multi-AP controller...) and get the backhaul credentials. Regards, Arnout > >> WPS requires more special handling. WPS must only be advertised on fronthaul >> SSIDs, not on backhaul SSIDs, so WPS should not be enabled on the backhaul SSID >> in hostapd.conf. The WPS configuration purely works on the fronthaul SSID. When >> a WPS M1 message has an additional subelement that indicates a request for a >> multi-AP backhaul link, hostapd must not respond with the normal fronthaul SSID >> credentials; instead, it responds with the (potentially different) backhaul SSID >> credentials. [Insert here how to configure this.] In addition to supplying the >> backhaul SSID credentials, hostapd will also add an additional information >> element to confirm that this is for a multi-AP backhaul link. >> >> When wpa_supplicant initiates WPS, it can add the multi-AP backhaul subelement >> in the M1 message. [Insert here how to configure wpa_supplicant to add the IE in >> WPS.] If it then receives the M8 response with the multi-AP backhaul subelement, >> it must treat the received credentials as a backhaul link, i.e. it must add the >> additional information element in (Re-)Association Request frames and it must >> 4-address mode. [Insert here how wpa_supplicant saves the information.] If it >> doesn't receive the multi-AP backhaul subelement in the WPS M8 response, it >> treats the link as a normal link, without additional information elements. > > This is the part that is relatively clear in the patches I've seen so > far. The part that is not, is the upper layer use of functionality, > i.e., those [Insert something] comments and the exact sequence on how > the operations might be completed (e.g., the question I had about > dynamically added netdev/vif for backhaul STA). > _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
