[PATCH 1/1] hostapd: Avoid EAPOL trigger in reassoc path for AP, in case of 4way HS offload

[Vinayak Yadawad]

Hi Jouni,

>Do you really mean association path and reassociation path here? The
>current implementation in hostapd_new_assoc_sta() should be used both
>when processing an Association Request frame and when processing a
>Reassociation Request frame.
The fix is meant for a case where assoc event is received by the AP
from an already associated STA (without deauth in between).
wpa_auth_sta_associated handles both reassoc and assoc case
differently and the 4way HS offload case is getting skipped for
reassoc case. This change should have been in common path. Let me
check whether I can handle the same in  SM_STATE(WPA_PTK, PTKSTART).

Regards,
Vinayak


On Sat, Aug 10, 2024 at 1:29 PM Jouni Malinen <j at w1.fi> wrote:
>
> On Fri, May 24, 2024 at 12:00:27PM +0530, Vinayak Yadawad wrote:
> > Currently avoiding of EAPOL exchange for AP with 4way HS offload is
> > handled only in new STA assoc path. Current change avoids complete
> > authentication trigger in case of AP reassoc path as well.
>
> Do you really mean association path and reassociation path here? The
> current implementation in hostapd_new_assoc_sta() should be used both
> when processing an Association Request frame and when processing a
> Reassociation Request frame.
>
> > diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c
> > @@ -2708,8 +2717,20 @@ SM_STATE(WPA_PTK, PTKSTART)
> >       SM_ENTRY_MA(WPA_PTK, PTKSTART, wpa_ptk);
> > +
> > +     wpa_auth_get_drv_flags(sm->wpa_auth, &drv_flags, &drv_flags2);
> > +     ap_4way_hs_offload = !!(drv_flags2 & WPA_DRIVER_FLAGS2_4WAY_HANDSHAKE_AP_PSK);
> > +     if (ap_4way_hs_offload) {
> > +             /* 4way HS offloaded to driver no need of EAPOL */
> > +             wpa_printf(MSG_INFO, "Avoid EAPOL in case of 4way HS offload");
> > +             return;
> > +     }
>
> This on the other hand would address other reasons to start 4-way
> handshake than association or reassociation. For example, rekeying of
> the PTK would be such a case. This might be a reasonable thing to do,
> but that commit message makes the intent of this change quite unclear.
>
> --
> Jouni Malinen                                            PGP id EFC895FA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4218 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20240816/e167e998/attachment.p7s>