The sae_password_entry is used in this function only if CONFIG_SAE is
defined, so declare this variable only under the same condition.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
When I was testing dpp_auth_init on an AP with Enrollee on a different
channel from the AP I was getting failures. This happened on hwsim in
UML with time-travel for me. I don't recall seeing this with real
devices, presumably because of lax offchan implementation.
The DPP authentication would succeed. However the station would then try
to get configuration through a GAS request and fail.
The AP reported the following logs (grepped):
> 1614762426.860212: RX_ACTION category 4 action 10 sa 02:00:00:00:01:00 da 02:00:00:00:00:00 len 227 freq 2412
> 1614762426.860212: wlan0: GAS: GAS Initial Request from 02:00:00:00:01:00 (dialog token 239)
> 1614762426.860233: DPP: Wait for Configuration Result
> 1614762426.860234: nl80211: Send Action frame (ifindex=5, freq=2462 MHz wait=0 ms no_cck=0 offchanok=0)
> 1614762428.861186: DPP: Timeout while waiting for Configuration Result
> 1614762428.861186: wlan0: DPP-CONF-FAILED
While the STA reported the following logs (grepped):
> 1614762426.860193: wlan1: DPP-AUTH-SUCCESS init=0
> 1614762426.860195: DPP: Stop listen on 2412 MHz
> 1614762426.860202: wlan1: GAS-QUERY-START addr=02:00:00:00:00:00 dialog_token=239 freq=2412
> 1614762428.861185: GAS: No response received for query to 02:00:00:00:00:00 dialog token 239
> 1614762428.861189: DPP: GAS query did not succeed
> 1614762428.861189: wlan1: DPP-CONF-FAILED
AP would still receive the GAS request on ch1 but would then try to
respond on ch11 while STA was waiting on ch1.
Signed-off-by: Michal Kazior <michal@plume.com>
Just like with WPA-PSK and keyids it may be desired to identify
connecting clients to provide additional network filtering.
This does:
- extend DPP_EVENT_AUTH_SUCCESS to expose public
key hash of the peer so the system can pick it
up and use for identification later
- store public key hash in PMKSA from DPP Network
Intro for later use
- extend sta mib to print out the dpp_pkhash
from PMKSA if present
- extend AP_STA_CONNECTED to include the
dpp_pkhash from PMKSA if present
Signed-off-by: Michal Kazior <michal@plume.com>
This event is generated in a couple of places. It'll be easier to extend
the event with additional metadata if it's generated in a single place.
Signed-off-by: Michal Kazior <michal@plume.com>
Reorder PKEX initiation function to send out the PKEX Exchange Request
frame at the end after all possible error cases have been checked. This
prevents Enrollee from seeing a PKEX frame when the session is about to
fail.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
hostapd_dpp_add_controller() ended up trying to parse the IP address
without nul terminating it. This might work with some C libraries, but
not all. And anyway, this was already supposed to nul terminate the
string since a temporary copy is created of the constant string. Fix
this by adding the missed replacement of the space with nul.
Fixes: bfe3cfc382 ("DPP: Allow Relay connections to Controllers to be added and removed")
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This can be helpful for upper layers to be able to determine whether the
configuration was rejected.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The new DPP-RELAY-NEEDS-CONTROLLER control interface event can be used
to trigger mDNS discovery of a Controller to see if such a connection
can be established automatically at the time an Enrollee is trying to
initiate an operation.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The new control interface commands "DPP_RELAY_ADD_CONTROLLER <IP addr>
<PK hash>" and "DPP_RELAY_REMOVE_CONTROLLER <IP addr>" can now be used
to dynamically add and remove connections to Controllers for the cases
where the connection is initialized through a DPP Public Action frame
(i.e., Controller as the Responder).
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Instead of requiring explicit configuration through
dpp_configurator_connectivity=1, advertise Configurator connectivity
automatically if a Relay is configured with a Controller that can
operate as a Responder.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Accept an incoming TCP connection from a Controller in a Relay that is
configured with dpp_relay_port even if that Controller is not configured
with a dpp_controller parameter. This allows more dynamic Controller
initiated operations, e.g., when using mDNS to discover a Relay.
This type of a dynamic Controller entry will not be used for exchanges
that are initiated by an Enrollee (i.e., based on a DPP Public Action
frame received by the Relay).
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Verify that the peer does not change its bootstrapping key between the
PKEX exchange and the authentication exchange.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
When PKEX was started through the push button mechanism, the own
bootstrapping key was not bound correctly to the Authentication phase
information and that ended up in incorrectly generating a new
bootstrapping key for the Authentication exchange. Fix this by added the
needed own=<id> parameter into the cached parameters when using push
button.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The peer=<id> information about the specific boostrapping key provided
through PKEX was added for Public Action frame cases, but the TCP
variant did not do same. Add the same information there to maintain
knowledge of the specific peer bootstrapping key from PKEX to
Authentication exchange.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
It is possible for a Controller to receive a copy of its own PKEX
Exchange Request in the case where the Controller is initiating a PKEX
exchange through a Relay. The Configurator role in the device would have
a matching PKEX code in that case and the device might reply as a PKEX
responder which would result in going through the exchange with the
Controller device itself. That is clearly not desired, so recognize this
special case by checking whether the Encrypted Key attribute value
matches a pending locally generated one when processing a received PKEX
Exchange Request.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
We are not supposed to reuse these without being explicitly requested to
perform PKEX again. There is not a strong use case for being able to
provision an Enrollee multiple times with PKEX, so this should have no
issues on the Enrollee. For a Configurator, there might be some use
cases that would benefit from being able to use the same code with
multiple Enrollee devices, e.g., for guess access with a laptop and a
smart phone. That case will now require a new DPP_PKEX_ADD command on
the Configurator after each completion of the provisioning exchange.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add a privacy protecting variant of the peer introduction protocol to
allow the station device to hide its Connector from 3rd parties. The new
wpa_supplicant network profile parameter dpp_connector_privacy=1 can be
used to select this alternative mechanism to the peer introduction
protocol added in the initial release of DPP.
It should be noted that the new variant does not work with older DPP APs
(i.e., requires support for release 3). As such, this new variant is
disabled by default.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This allows the DPP Configuration Request Object from an Enrollee to be
extended with 3rd party information. The new dpp_extra_conf_req_name and
dpp_extra_conf_req_value configuration parameters specify the name of
the added JSON node and its contents. For example:
dpp_extra_conf_req_name=org.example
dpp_extra_conf_req_value={"a":1,"b":"test"}
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This extends Relay functionality to allow a Controller to intitiate a
new DPP exchange in addition to the previously supported case where the
exchange was initiated through a DPP Public Action frame.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
While the most likely production use case for DPP push button is to
provision the AP's current configuration, there might be some use cases
for providing different configuration. Add possibility for doing this by
extending the DPP_PUSH_BUTTON command to accept an optional set of
parameters similarly to the other DPP commands for the Configurator.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add support to use a push button -based bootstrap mechanism with DPP.
The new DPP_PUSH_BUTTON control interface command enables this mode on
the AP/hostapd and station/wpa_supplicant. This goes through the
following sequence of events: a suitable peer in active push button mode
is discovered with session overlap detection, PKEX is executed with
bootstrap key hash validation, DPP authentication and configuration
exchanges are performed.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
tcp_addr=from-uri can now be used as a special case for initiating
DPP-over-TCP to the destination indicated in the peer bootstrapping URI.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Allow the Configurator to be configured to use a specific curve for the
netAccessKey so that it can request the Enrollee to generate a new key
during the configuration exchange to allow a compatible Connector to be
generated when the network uses a different curve than the protocol keys
used during the authentication exchange.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Allow PKEX v1-only or v2-only behavior to be specific for the Responder
role. This is mainly for testing purposes.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The TCP code path did not handle the postponed connection attempt on TX
status and the following result message from the Enrollee to the
Configurator. Fix this by adding TCP-versions of these operations to
match the way wpa_supplicant implemented this for the Public Action
frames.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This extends dpp_test functionality to allow DPP Network Introduction
exchanges to use an incorrect value in the Protocol Version attribute.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Use a separate ver=<1|2> parameter to DPP_PKEX_ADD instead of
overloading init=1 with version indication. This allows additional
options for forcing v1-only and v2-only in addition to automatic mode
(start with v2 and fall back to v1, if needed).
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This extends hostapd with the design used in wpa_supplicant for PKEX
initiator retries and automatic version fallback from v2 to v1 (the
latter is enabled only with CONFIG_DPP3=y).
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add support for PKEXv2 core protocol. This defines a new PKEX Exchange
Request message type with protocol negotiation and different rules for
key derivation with PKEXv2 or newer is used.
This does not change existing behavior for PKEX, i.e., the PKEXv1
variant will still be used by default.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Allow the dpp_test parameter to be used to request the Protocol Version
attributed to be omitted from the Peer Discovery Request/Response
message.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Verify that the Protocol Version attribute is used appropriate in Peer
Discovery Request/Response messages in cases where the signed Connector
includes the version information.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Generate Peer Discovery Request/Response messages using the protected
version from the Connector, if present, instead of the currently
supported protocol version which might be higher than the one that got
included into the signed Connector during provisioning earlier.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Stop the DPP Controller instance, if one is started, when the hostapd
interface that was used to start that Controller is removed. This is
needed to remove the control pointers that point to the soon-to-be-freed
hostapd structures. This fixes an issue where a Controller operation
with multiple interfaces could have resulted in references to freed
memory if an interface is removed without explicitly stopping the DPP
Controller.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
When the driver provides a list of supported modes, hostapd ended up
adding channel 6 even if the 2.4 GHz mode was not included. This
resulted in incorrect behavior of trying to transmit on a not supported
channel in case of 5 GHz only radios.
Fix this by adding the channel 6 by default only if the driver does not
provide a list of supported modes. Whenever the supported modes are
available, only add this channel if it is explicitly listed as an
enabled channel.
This is similar to an earlier wpa_supplicant change in commit
8e5739c3ac ("DPP2: Check channel 6 validity before adding it to chirp
channel list").
Signed-off-by: Disha Das <dishad@codeaurora.org>
Get the DPP Relay Controller context from the list of configured
Controllers based on the correct hostapd callback context. This is
needed to pick the correct hostapd interface for sending out the
response over air, e.g., when the same hostapd process controls a 2.4
GHz only and a 5 GHz only interface.
Signed-off-by: Disha Das <dishad@codeaurora.org>
The GAS client processing of the response callback for DPP did not
properly check for GAS query success. This could result in trying to
check the Advertisement Protocol information in failure cases where that
information is not available and that would have resulted in
dereferencing a NULL pointer. Fix this by checking the GAS query result
before processing with processing of the response.
This is similar to the earlier wpa_supplicant fix in commit 931f7ff656
("DPP: Fix GAS client error case handling").
Signed-off-by: Jouni Malinen <j@w1.fi>
It is possible to receive the Configuration Request frame before having
seen TX status for the Authentication Confirm. In that sequence, the
DPP-AUTH-SUCCESS event would not be indicated before processing the
configuration step and that could confuse upper layers that follow the
details of the DPP exchange. As a workaround, indicate DPP-AUTH-SUCCESS
when receiving the Configuration Request since the Enrollee/Responser
has clearly receive the Authentication Confirm even if the TX status for
it has not been received.
This was already done in wpa_supplicant in commit 422e73d623 ("DPP:
Indicate authentication success on ConfReqRX if needed") and matching
changes are now added to hostapd.
Signed-off-by: Jouni Malinen <j@w1.fi>
The waiting_conn_status_result flag was not set which made hostapd
discard the Connection Status Result. Fix this to match the
wpa_supplicant implementation.
Signed-off-by: Jouni Malinen <j@w1.fi>
The Authentication Request frames triggered by the reception of a
Presence Announcement frame were sent to the broadcast address. This is
not correct behavior since the source MAC address of the Presence
Announcement frame was supposed to override the Responder MAC address.
Fix this by using that source MAC address to avoid unnecessary use of
broadcast frames.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Some time ago it was found some drivers are setting their hw/ucode RX
filters restrictively enough to prevent broadcast DPP Action frames from
being received at upper layers in the stack.
A set of patches was introduced to the kernel and
ath9k driver as well as wpa_supplicant, e.g.,
a39e9af90 ("nl80211: DPP listen mode callback")
4d2ec436e ("DPP: Add driver operation for enabling/disabling listen mode")
However, the hostapd code itself was not calling the new multicast
registration. As such the AP side of things wasn't working as expected
in some scenarios. I've found this while trying to get ath9k working as
an AP Responder/Configurator.
The problem wasn't seen on, e.g., mac80211 hwsim driver.
Extend the wpa_supplicant mechanism to work with hostapd as well.
Signed-off-by: Michal Kazior <michal@plume.com>
After sending DPP Auth Response, the Responder might not receive the
Auth Confirm either due to the Initiator not sending it or the reception
of the frame failing for some reason (e.g., Responder having already
left the negotiation channel). If this happens, following initiation
attempts would fail since the consecutive Auth Request would get
discarded since the previous authentication is still in progress.
Terminate DPP authentication on Responder, if no Auth Confirm is
received within one second of successfully sending Auth Response. This
allows the Responder to accept start of a new exchange.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Generate a control interface event upon receipt of DPP Presence
Announcement frames. This allows external programs to instrument hostapd
with bootstrapping information on-demand.
Signed-off-by: Andrew Beltrano <anbeltra@microsoft.com>
When a Presence Announcement frame is received, a check is done to
ensure an ongoing auth is not in progress (!hapd->dpp_auth). A new DPP
auth is then initialized, however, when setting global configurator
params for it, the hapd->dpp_auth pointer is used which was earlier
confirmed as NULL, causing a crash in dpp_set_configurator params when
the pointer is dereferenced.
This only occurs when there are global DPP configurator params to be set
and the peer has no overriding configurator params. If no global DPP
configurator params exist, the call to dpp_set_configurator exits early
and the problem is not observed.
Fix by using the newly init'ed DPP auth structure for setting global
DPP configurator params.
Signed-off-by: Andrew Beltrano <anbeltra@microsoft.com>
Extend DPP authentication session search for the DPP_QR_CODE command to
cover the ongoing exchanges in Controller/Responder. This was previously
done for wpa_supplicant, but not for hostapd, so complete this support
on the hostapd side.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Extend hostapd support for DPP Controller to cover the DPP_CONTROLLER_*
cases that were previously implemented only in wpa_supplicant. This
allows hostapd/AP to be provisioned using DPP over TCP.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
