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. > _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
