hostapd, wpa_supplicant and the Multi-AP Specification
======================================================

This document describes how hostapd and wpa_supplicant can be configured to
support the Multi-AP Specification.

Introduction to Multi-AP
------------------------

The Wi-Fi Alliance Multi-AP Specification is the technical specification for
Wi-Fi CERTIFIED EasyMesh(TM) [1], the Wi-Fi Alliance® certification program for
Multi-AP. It defines control protocols between Wi-Fi® access points (APs) to
join them into a network with centralized control and operation. It is targeted
only at routers (repeaters, gateways, ...), not at clients. Clients are not
involved at all in the protocols.

Most of the Multi-AP specification falls outside of the scope of
hostapd/wpa_supplicant. hostapd/wpa_supplicant is only involved for the items
summarized below. The rest of the protocol must be implemented by a separate
daemon, e.g., prplMesh [2]. That daemon also needs to communicate with hostapd,
e.g., to get a list of associated clients, but this can be done using the normal
hostapd interfaces.

hostapd/wpa_supplicant needs to be configured specifically to support:
- the WPS onboarding process;
- configuring backhaul links.

The text below refers to "Multi-AP Specification v1.0" [3].


Fronthaul and backhaul links
----------------------------

In a Multi-AP network, the central controller can configure the BSSs on the
devices that are joined into the network. These are called fronthaul BSSs.
From the point of view of hostapd, there is nothing special about these
fronthaul BSSs.

In addition to fronthaul BSSs, the controller can also configure backhaul
links. A backhaul link is a link between two access point devices, giving
internet access to access point devices that don't have a wired link. The
Multi-AP specification doesn't dictate this, but typically the backhaul link
will be bridged into a LAN together with (one of) the fronthaul BSS(s) and the
wired Ethernet ports.

A backhaul link must be treated specially by hostapd and wpa_supplicant. One
side of the backhaul link is configured through the Multi-AP protocol as the
"backhaul STA", i.e., the client side of the link. A backhaul STA is like any
station and is handled appropriately by wpa_supplicant, but two additional
features are required. It must send an additional information element in each
(Re)Association Request frame ([3], section 5.2, paragraph 4). In addition, it
must use 4-address mode for all frames sent over this link ([3], section 14).
Therefore, wpa_supplicant must be configured explicitly as the backhaul STA
role, by setting 'multi_ap_backhaul_sta=1' in the network configuration block
or when configuring the network profile through the control interface. When
'multi_ap_backhaul_sta=1', wpa_supplicant includes the Multi-AP IE in
(Re)Association Request frame and verifies that it is included in the
(Re)Association Response frame. If it is not, association fails. If it is,
wpa_supplicant sets 4-address mode for this interface through a driver
callback.

The AP side of the backhaul link is called a "backhaul BSS". Such a BSS must
be handled specially by hostapd, because it must add an additional information
element in each (Re)Association Response frame, 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 (fronthaul, when it's a fronthaul and backhaul BSS) must use
3-address mode.

A BSS is configured in Multi-AP mode in hostapd by setting the 'multi_ap'
configuration option to 1 (backhaul BSS), 2 (fronthaul BSS), or 3
(simultaneous backhaul and fronthaul BSS). If this option is set, hostapd
parses the Multi-AP information element in the Association Request frame. If the
station is a backhaul STA and the BSS is configured as a backhaul BSS,
hostapd sets up 4-address mode. Since there may be multiple stations connected
simultaneously, and each of them has a different RA (receiver address), a VLAN
is created for each backhaul STA and it is automatically added to a bridge.
This is the same behavior as for WDS, and the relevant option ('bridge' or
'wds_bridge') applies here as well.

If 'multi_ap' is 1 (backhaul BSS only), any station that tries to associate
without the Multi-AP information element will be denied.

If 'multi_ap' is 2 (fronthaul BSS only), any station that tries to associate
with the Multi-AP information element will be denied. That is also the only
difference with 'multi_ap' set to 0: in the latter case, the Multi-AP
information element is simply ignored.

In summary, this is the end-to-end behavior for a backhaul BSS (i.e.,
multi_ap_backhaul_sta=1 in wpa_supplicant on STA, and multi_ap=1 or 3 in
hostapd on AP). Note that point 1 means that hostapd must not be configured
with WPS support on the backhaul BSS (multi_ap=1). hostapd does not check for
that.

1. Backhaul BSS beacons do not advertise WPS support (other than that, nothing
   Multi-AP specific).
2. STA sends Authentication frame (nothing Multi-AP specific).
3. AP sends Authentication frame (nothing Multi-AP specific).
4. STA sends Association Request frame with Multi-AP IE.
5. AP sends Association Response frame with Multi-AP IE.
6. STA and AP both use 4-address mode for Data frames.


WPS support
-----------

WPS requires more special handling. WPS must only be advertised on fronthaul
BSSs, not on backhaul BSSs, so WPS should not be enabled on a backhaul-only
BSS in hostapd.conf. The WPS configuration purely works on the fronthaul BSS.
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
BSS credentials; instead, it should respond with the (potentially different)
backhaul BSS credentials.

To support this, hostapd has the 'multi_ap_backhaul_ssid',
'multi_ap_backhaul_wpa_psk' and 'multi_ap_backhaul_wpa_passphrase' options.
When these are set on an BSS with WPS, they are used instead of the normal
credentials when hostapd receives a WPS M1 message with the Multi-AP IE. Only
WPA2-Personal is supported in the Multi-AP specification, so there is no need
to specify authentication or encryption options. For the backhaul credentials,
per-device PSK is not supported.

If the BSS is a simultaneous backhaul and fronthaul BSS, there is no need to
specify the backhaul credentials, since the backhaul and fronthaul credentials
are identical.

To enable the Multi-AP backhaul STA feature when it performs WPS, a new
parameter has been introduced to the WPS_PBC control interface call. When this
"multi_ap=1" option is set, it adds the Multi-AP backhaul subelement to the
Association Request frame and the M1 message. It then configures the new network
profile with 'multi_ap_backhaul_sta=1'. Note that this means that if the AP does
not follow the Multi-AP specification, wpa_supplicant will fail to associate.

In summary, this is the end-to-end behavior for WPS of a backhaul link (i.e.,
multi_ap=1 option is given in the wps_pbc call on the STA side, and multi_ap=2
and multi_ap_backhaul_ssid and either multi_ap_backhaul_wpa_psk or
multi_ap_backhaul_wpa_passphrase are set to the credentials of a backhaul BSS
in hostapd on Registrar AP).

1. Fronthaul BSS Beacon frames advertise WPS support (nothing Multi-AP
   specific).
2. Enrollee sends Authentication frame (nothing Multi-AP specific).
3. AP sends Authentication frame (nothing Multi-AP specific).
4. Enrollee sends Association Request frame with Multi-AP IE.
5. AP sends Association Response frame with Multi-AP IE.
6. Enrollee sends M1 with additional Multi-AP subelement.
7. AP sends M8 with backhaul instead of fronthaul credentials.
8. Enrollee sends Deauthentication frame.


References
----------

[1] https://www.wi-fi.org/discover-wi-fi/wi-fi-easymesh
[2] https://github.com/prplfoundation/prplMesh
[3] https://www.wi-fi.org/file/multi-ap-specification-v10
    (requires registration)

hostapd and Wi-Fi Protected Setup (WPS)
=======================================

This document describes how the WPS implementation in hostapd can be
configured and how an external component on an AP (e.g., web UI) is
used to enable enrollment of client devices.


Introduction to WPS
-------------------

Wi-Fi Protected Setup (WPS) is a mechanism for easy configuration of a
wireless network. It allows automated generation of random keys (WPA
passphrase/PSK) and configuration of an access point and client
devices. WPS includes number of methods for setting up connections
with PIN method and push-button configuration (PBC) being the most
commonly deployed options.

While WPS can enable more home networks to use encryption in the
wireless network, it should be noted that the use of the PIN and
especially PBC mechanisms for authenticating the initial key setup is
not very secure. As such, use of WPS may not be suitable for
environments that require secure network access without chance for
allowing outsiders to gain access during the setup phase.

WPS uses following terms to describe the entities participating in the
network setup:
- access point: the WLAN access point
- Registrar: a device that control a network and can authorize
  addition of new devices); this may be either in the AP ("internal
  Registrar") or in an external device, e.g., a laptop, ("external
  Registrar")
- Enrollee: a device that is being authorized to use the network

It should also be noted that the AP and a client device may change
roles (i.e., AP acts as an Enrollee and client device as a Registrar)
when WPS is used to configure the access point.


More information about WPS is available from Wi-Fi Alliance:
http://www.wi-fi.org/wifi-protected-setup


hostapd implementation
----------------------

hostapd includes an optional WPS component that can be used as an
internal WPS Registrar to manage addition of new WPS enabled clients
to the network. In addition, WPS Enrollee functionality in hostapd can
be used to allow external WPS Registrars to configure the access
point, e.g., for initial network setup. In addition, hostapd can proxy a
WPS registration between a wireless Enrollee and an external Registrar
(e.g., Microsoft Vista or Atheros JumpStart) with UPnP.


hostapd configuration
---------------------

WPS is an optional component that needs to be enabled in hostapd build
configuration (.config). Here is an example configuration that
includes WPS support and uses nl80211 driver interface:

CONFIG_DRIVER_NL80211=y
CONFIG_WPS=y
CONFIG_WPS_UPNP=y

Following parameter can be used to enable support for NFC config method:

CONFIG_WPS_NFC=y


Following section shows an example runtime configuration
(hostapd.conf) that enables WPS:

# Configure the driver and network interface
driver=nl80211
interface=wlan0

# WPA2-Personal configuration for the AP
ssid=wps-test
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
# Default WPA passphrase for legacy (non-WPS) clients
wpa_passphrase=12345678
# Enable random per-device PSK generation for WPS clients
# Please note that the file has to exists for hostapd to start (i.e., create an
# empty file as a starting point).
wpa_psk_file=/etc/hostapd.psk

# Enable control interface for PBC/PIN entry
ctrl_interface=/var/run/hostapd

# Enable internal EAP server for EAP-WSC (part of Wi-Fi Protected Setup)
eap_server=1

# WPS configuration (AP configured, do not allow external WPS Registrars)
wps_state=2
ap_setup_locked=1
# If UUID is not configured, it will be generated based on local MAC address.
uuid=87654321-9abc-def0-1234-56789abc0000
wps_pin_requests=/var/run/hostapd.pin-req
device_name=Wireless AP
manufacturer=Company
model_name=WAP
model_number=123
serial_number=12345
device_type=6-0050F204-1
os_version=01020300
config_methods=label display push_button keypad

# if external Registrars are allowed, UPnP support could be added:
#upnp_iface=br0
#friendly_name=WPS Access Point


External operations
-------------------

WPS requires either a device PIN code (usually, 8-digit number) or a
pushbutton event (for PBC) to allow a new WPS Enrollee to join the
network. hostapd uses the control interface as an input channel for
these events.

The PIN value used in the commands must be processed by an UI to
remove non-digit characters and potentially, to verify the checksum
digit. "hostapd_cli wps_check_pin <PIN>" can be used to do such
processing. It returns FAIL if the PIN is invalid, or FAIL-CHECKSUM if
the checksum digit is incorrect, or the processed PIN (non-digit
characters removed) if the PIN is valid.

When a client device (WPS Enrollee) connects to hostapd (WPS
Registrar) in order to start PIN mode negotiation for WPS, an
identifier (Enrollee UUID) is sent. hostapd will need to be configured
with a device password (PIN) for this Enrollee. This is an operation
that requires user interaction (assuming there are no pre-configured
PINs on the AP for a set of Enrollee).

The PIN request with information about the device is appended to the
wps_pin_requests file (/var/run/hostapd.pin-req in this example). In
addition, hostapd control interface event is sent as a notification of
a new device. The AP could use, e.g., a web UI for showing active
Enrollees to the user and request a PIN for an Enrollee.

The PIN request file has one line for every Enrollee that connected to
the AP, but for which there was no PIN. Following information is
provided for each Enrollee (separated with tabulators):
- timestamp (seconds from 1970-01-01)
- Enrollee UUID
- MAC address
- Device name
- Manufacturer
- Model Name
- Model Number
- Serial Number
- Device category

Example line in the /var/run/hostapd.pin-req file:
1200188391	53b63a98-d29e-4457-a2ed-094d7e6a669c	Intel(R) Centrino(R)	Intel Corporation	Intel(R) Centrino(R)	-	-	1-0050F204-1

Control interface data:
WPS-PIN-NEEDED [UUID-E|MAC Address|Device Name|Manufacturer|Model Name|Model Number|Serial Number|Device Category]
For example:
<2>WPS-PIN-NEEDED [53b63a98-d29e-4457-a2ed-094d7e6a669c|02:12:34:56:78:9a|Device|Manuf|Model|Model Number|Serial Number|1-0050F204-1]

When the user enters a PIN for a pending Enrollee, e.g., on the web
UI), hostapd needs to be notified of the new PIN over the control
interface. This can be done either by using the UNIX domain socket
-based control interface directly (src/common/wpa_ctrl.c provides
helper functions for using the interface) or by calling hostapd_cli.

Example command to add a PIN (12345670) for an Enrollee:

hostapd_cli wps_pin 53b63a98-d29e-4457-a2ed-094d7e6a669c 12345670

If the UUID-E is not available (e.g., Enrollee waits for the Registrar
to be selected before connecting), wildcard UUID may be used to allow
the PIN to be used once with any UUID:

hostapd_cli wps_pin any 12345670

To reduce likelihood of PIN being used with other devices or of
forgetting an active PIN available for potential attackers, expiration
time in seconds can be set for the new PIN (value 0 indicates no
expiration):

hostapd_cli wps_pin any 12345670 300

If the MAC address of the enrollee is known, it should be configured
to allow the AP to advertise list of authorized enrollees:

hostapd_cli wps_pin 53b63a98-d29e-4457-a2ed-094d7e6a669c \
	12345670 300 00:11:22:33:44:55


After this, the Enrollee can connect to the AP again and complete WPS
negotiation. At that point, a new, random WPA PSK is generated for the
client device and the client can then use that key to connect to the
AP to access the network.


If the AP includes a pushbutton, WPS PBC mode can be used. It is
enabled by pushing a button on both the AP and the client at about the
same time (2 minute window). hostapd needs to be notified about the AP
button pushed event over the control interface, e.g., by calling
hostapd_cli:

hostapd_cli wps_pbc

At this point, the client has two minutes to complete WPS negotiation
which will generate a new WPA PSK in the same way as the PIN method
described above.


When an external Registrar is used, the AP can act as an Enrollee and
use its AP PIN. A static AP PIN (e.g., one one a label in the AP
device) can be configured in hostapd.conf (ap_pin parameter). A more
secure option is to use hostapd_cli wps_ap_pin command to enable the
AP PIN only based on user action (and even better security by using a
random AP PIN for each session, i.e., by using "wps_ap_pin random"
command with a timeout value). Following commands are available for
managing the dynamic AP PIN operations:

hostapd_cli wps_ap_pin disable
- disable AP PIN (i.e., do not allow external Registrars to use it to
  learn the current AP settings or to reconfigure the AP)

hostapd_cli wps_ap_pin random [timeout]
- generate a random AP PIN and enable it
- if the optional timeout parameter is given, the AP PIN will be enabled
  for the specified number of seconds

hostapd_cli wps_ap_pin get
- fetch the current AP PIN

hostapd_cli wps_ap_pin set <PIN> [timeout]
- set the AP PIN and enable it
- if the optional timeout parameter is given, the AP PIN will be enabled
  for the specified number of seconds

hostapd_cli get_config
- display the current configuration

hostapd_cli wps_config <new SSID> <auth> <encr> <new key>
examples:
  hostapd_cli wps_config testing WPA2PSK CCMP 12345678
  hostapd_cli wps_config "no security" OPEN NONE ""

<auth> must be one of the following: OPEN WPAPSK WPA2PSK
<encr> must be one of the following: NONE WEP TKIP CCMP


Credential generation and configuration changes
-----------------------------------------------

By default, hostapd generates credentials for Enrollees and processing
AP configuration updates internally. However, it is possible to
control these operations from external programs, if desired.

The internal credential generation can be disabled with
skip_cred_build=1 option in the configuration. extra_cred option will
then need to be used to provide pre-configured Credential attribute(s)
for hostapd to use. The exact data from this binary file will be sent,
i.e., it will have to include valid WPS attributes. extra_cred can
also be used to add additional networks if the Registrar is used to
configure credentials for multiple networks.

Processing of received configuration updates can be disabled with
wps_cred_processing=1 option. When this is used, an external program
is responsible for creating hostapd configuration files and processing
configuration updates based on messages received from hostapd over
control interface. This will also include the initial configuration on
first successful registration if the AP is initially set in
unconfigured state.

Following control interface messages are sent out for external programs:

WPS-REG-SUCCESS <Enrollee MAC address <UUID-E>
For example:
<2>WPS-REG-SUCCESS 02:66:a0:ee:17:27 2b7093f1-d6fb-5108-adbb-bea66bb87333

This can be used to trigger change from unconfigured to configured
state (random configuration based on the first successful WPS
registration). In addition, this can be used to update AP UI about the
status of WPS registration progress.


WPS-NEW-AP-SETTINGS <hexdump of AP Setup attributes>
For example:
<2>WPS-NEW-AP-SETTINGS 10260001011045000c6a6b6d2d7770732d74657374100300020020100f00020008102700403065346230343536633236366665306433396164313535346131663462663731323433376163666462376633393965353466316631623032306164343438623510200006024231cede15101e000844

This can be used to update the externally stored AP configuration and
then update hostapd configuration (followed by restarting of hostapd).


WPS with NFC
------------

WPS can be used with NFC-based configuration method. An NFC tag
containing a password token from the Enrollee can be used to
authenticate the connection instead of the PIN. In addition, an NFC tag
with a configuration token can be used to transfer AP settings without
going through the WPS protocol.

When the AP acts as an Enrollee, a local NFC tag with a password token
can be used by touching the NFC interface of an external Registrar. The
wps_nfc_token command is used to manage use of the NFC password token
from the AP. "wps_nfc_token enable" enables the use of the AP's NFC
password token (in place of AP PIN) and "wps_nfc_token disable" disables
the NFC password token.

The NFC password token that is either pre-configured in the
configuration file (wps_nfc_dev_pw_id, wps_nfc_dh_pubkey,
wps_nfc_dh_privkey, wps_nfc_dev_pw) or generated dynamically with
"wps_nfc_token <WPS|NDEF>" command. The nfc_pw_token tool from
wpa_supplicant can be used to generate NFC password tokens during
manufacturing (each AP needs to have its own random keys).

The "wps_nfc_config_token <WPS/NDEF>" command can be used to build an
NFC configuration token. The output value from this command is a hexdump
of the current AP configuration (WPS parameter requests this to include
only the WPS attributes; NDEF parameter requests additional NDEF
encapsulation to be included). This data needs to be written to an NFC
tag with an external program. Once written, the NFC configuration token
can be used to touch an NFC interface on a station to provision the
credentials needed to access the network.

When the NFC device on the AP reads an NFC tag with a MIME media type
"application/vnd.wfa.wsc", the NDEF message payload (with or without
NDEF encapsulation) can be delivered to hostapd using the
following hostapd_cli command:

wps_nfc_tag_read <hexdump of payload>

If the NFC tag contains a password token, the token is added to the
internal Registrar. This allows station Enrollee from which the password
token was received to run through WPS protocol to provision the
credential.

"nfc_get_handover_sel <NDEF> <WPS>" command can be used to build the
contents of a Handover Select Message for connection handover when this
does not depend on the contents of the Handover Request Message. The
first argument selects the format of the output data and the second
argument selects which type of connection handover is requested (WPS =
Wi-Fi handover as specified in WSC 2.0).

"nfc_report_handover <INIT/RESP> WPS <carrier from handover request>
<carrier from handover select>" is used to report completed NFC
connection handover. The first parameter indicates whether the local
device initiated or responded to the connection handover and the carrier
records are the selected carrier from the handover request and select
messages as a hexdump.