DPP push button timeouts/sesson-overlap interaction

[James Haggerty]

Following up on my previous email re the likelihood of DPP-PB session
overlaps due to regenerating the bootstrap key, my thought is that
this could be made a lot better if, when one attempted to initiate an
interaction on the AP side, it would fail immediately if an overlap
could be predicted.

Proposed logic: when DPP PB is initiated on the configurator side, if
a DPP PB announcement already exists that's more than 5s but less than
120s old, return failure on dpp pb to the user immediately.

This almost always avoids the situation where you begin a DPP PB on
the configurator which is almost guaranteed to fail. It also means that
if you have initiated the DPP PB on the enrollee side this should still
work, as it will be announcing frequently enough that it will be <5s old.

On Wed, Feb 26, 2025 at 2:00 PM James Haggerty
<james.haggerty at morsemicro.com> wrote:
>
> Hi,
>
> I've been struggling with DPP push button session-overlap
> behaviour. Because a DPP Push button interaction generates a new
> bootstrapping key every time on the wpa_supplicant side, if you had
> a previous failed interaction hostapd will usually break your current
> interaction. So after any failure, you end up in this situation if you
> don't wait long enough:
>
> - DPP failure
> - try again -> session overlap
> - try again -> session overlap etc.
>
> To avoid a session overlap, it seems you have to wait 120s after the
> last DPP-TX on the wpa_supplicant side. Because the supplicant side has a
> 100s timeout, I believe you can't safely initiate a DPP push button for
> up to 100+120=220 seconds after your last one (if the last one didn't
> succeed). This is quite a long interval!
>
> Relevant pieces of code:
>
> 100s timeout in wpa_supplicant:
>
>     os_get_reltime(&now);
>     if (os_reltime_expired(&now, &wpa_s->dpp_pb_time, 100)) {
>         wpa_printf(MSG_DEBUG, "DPP: Push button wait time expired");
>         wpas_dpp_push_button_stop(wpa_s); return;
>     }
>
> 120s timeout on overlap detection in hostapd (if you pass this guard,
> it will detect the overlap):
>
>     if (os_reltime_expired(&now, &tmp->rx_time, 120)) {
>         wpa_hexdump(MSG_DEBUG, "DPP: Push button Enrollee hash
> expired", tmp->hash, SHA256_MAC_LEN);
>         tmp->rx_time.sec = 0;
>         tmp->rx_time.usec = 0; continue;
>     }
>
> Because this was frustrating behaviour from a user perspective (i.e. we
> have lock the button out for almost 4 minutes if something goes wrong!),
> I was looking into the v3 Wi-Fi EasyConnect spec to determine if there
> was any leeway here. I noticed that:
>
> - the spec does not have the 100s wpa_supplicant timeout, but rather a
> number of tighter timeouts. Depending on how you read it, it seems like
> it could stop at either 30s (T1e) or 30+30 (T1e+T2e) if no response was
> received (which is what happens in session overlap, since a response
> frame is never sent back).
>
> - the spec does not have the 120s session overlap timeout, but rather a
> 110s window before the button was pushed (T4)
>
> - the spec does unfortunately say in the mitigations section that the
> bootstrapping key must be regenerated in most situations (even though
> it's normally static): "If Push button bootstrapping is aborted for any
> reason... the Enrollee shall discard the bootstrapping key used with the
> aborted session and generate a new, unique bootstrapping key for
> subsequent Push button bootstrapping session"
>
> Any advice welcome, even if it's just "your spec reading seems right,
> feel free to change the timeout behaviour yourself".
>
> Thanks,
> James.