Retansmitted associate requests with OWE

[Jouni Malinen]

On Tue, Mar 29, 2022 at 03:23:18PM -0700, James Prestwood wrote:
> I have observed some behavior related to OWE where hostapd and the
> station cannot connect if the associate request ACK is never received
> by the station:
> 
> 1. Station sends Association request
> 2. Hostapd receives this, derives its side of the keys and replies
> 3. Station never receives an ACK from the association request, kernel
> retransmits.

Just to be clear here.. What you describe here is not the link layer
retransmission of the frame which happens when the ACK frame is not
received, but a transmission of a completely new Association Request
frame. Those are two very different things, i.e., the former would have
been dropped as a duplicate frame while the latter results in this
issue. IMHO, the main issue is indeed here, i.e., the kernel should not
have sent a new Association Request frame (a different sequence number,
not the link layer retransmission done by the hardware/firmware) in this
type of a case where there is potentially changing keying material in
the frame. We have had similar issues with mac80211 and SAE
authentication and the best way to avoid these is to prevent mac80211
from doing those retries on its own.

> 4. Hostapd receives the retransmit, treats it as a new association and
> re-derives the keys.

This "retransmit" is the second Association Request frame, i.e., not
just a link layer retransmission of the first one due to missing ACK
frame. This is supposed to be processed as a new association and yes, in
the case of OWE, it would indeed result in going through DH processing
again.

> 5. Station gets hostapd's first Association response via CMD_CONNECT,
> unknown what ever happened to the second association response, likely
> dropped by the kernel since it already sent CMD_CONNECT to userspace.

This would be fixed by removing that mac80211 retry-with-new-frame
behavior for OWE.

> 6. Now the STA derives its keys based on hostapd's first association
> response, and hostapd derived its keys based on its second. This
> results in the 4-way failing.

While obviously undesired, this is the expected behavior in this type of
a sequence..

> I can think of only two possible ways to fix this:
> 
> a) Have the kernel tell userspace of the retransmit, and of a new
> association response (an additional CMD_CONNECT event?). This assumes
> the second response actually made it and wasn't lost. This would end up
> being quite a burden on both the kernel and userspace to handle this
> case. Better would be...

I don't think I would call this a fix, but more like a way of hiding the
real issue (that mac80211-generated retransmit). While this is really a
two completely distinct association attempts and as such, would need two
CONNECT events, this looks quite strange from the view point of
having only a single CONNECT command going to the kernel. Furthermore,
there would be a race condition on finding out when the "correct"
CONNECT event is received.

> b) Have hostapd treat additional association requests as retransmits.
> For OWE specifically you can all but guarantee it was a retransmit if
> the DH IE is identical.

This is not a fix either, but a workaround for badly behaving stations.
It might be justifiable to do this anyway, though, if there is a
significant number of deployed station devices that support OWE with
this incorrect behavior.

But the real fix is:

c) Stop mac80211 from sending OWE (Re)Association Request frame retries
with new frames (different seq#).

> I can't seem to find anything in 802.11 about retransmitting management
> frames, so hostapd isn't doing anything wrong as far as the spec is
> concerned... But I think the behavior could be improved by treating
> identical associate requests as retransmits.

This is not IEEE 802.11 retransmission (those link level retries which
maintain the same seq#) but two distinct association attempts as far as
the standard is concerned. That should not be done and instead, the
retries should depend on the real link layer retries that have a clearly
defined duplicate detection mechanism that prevent this type of issues.
If the station wants to try to associate again, it can certainly do so
even if it were pretty pointless in this case, but the current Linux
kernel interface does not handle it correctly. Such two attempts of
association should result in two reports of the result to the user
space.

-- 
Jouni Malinen                                            PGP id EFC895FA