DPP push button timeouts/sesson-overlap interaction

[James Haggerty]

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.