Retansmitted associate requests with OWE

[James Prestwood]

Hi Jouni,

On Fri, 2022-04-01 at 12:47 +0300, Jouni Malinen wrote:
> 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.

Ok, I do remember seeing those SAE changes. Thanks for helping clarify
the actual problem. And I agree, the way SAE/OWE work over auth and
associate doesn't jive well with how the kernel retransmits these
frames. Userspace just needs total control.

One problem that I see is with fullmac cards where we cannot send Assoc
directly. We use CMD_CONNECT exclusively with OWE since it works for
both soft/fullmac cards. But I'm guessing this isn't going to be
possible to fix for CMD_CONNECT.

> > 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#).

Ok, I'll take a look at the SAE changes and see if I can come up with
something similar.

> 
> > 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.
>