On Tue, 2024-06-18 at 13:56 +0000, Sperling, Tobias wrote:
> > > >
> I guess you were on the right track. For now we disabled the control_port via
> driver option in the supplicant conf, because the wpa_s logs were pointing to
> that and now the 4/4 frame of the 4-way handshake is encrypted as expected.
OK.
> Looking to the supplicant the problematic code is in the following function.
> When WPA_DRIVER_FLAGS_CONTROL_PORT is set, during rekeying at the time
> of frame 4/4 the (new) PTK is not yet installed and therefore, leading to the
> frame being unencrypted. The additional check for PTK being installed is probably
> to prevent some race conditions. At least that's what I think after reading the
> commit messages of when control port was introduced.
>
> int wpa_ether_send(struct wpa_supplicant *wpa_s, const u8 *dest,
> u16 proto, const u8 *buf, size_t len)
> {
> [...]
> if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_CONTROL_PORT) {
> int encrypt = wpa_s->wpa &&
> wpa_sm_has_ptk_installed(wpa_s->wpa);
>
> return wpa_drv_tx_control_port(wpa_s, dest, proto, buf, len,
> !encrypt);
> }
>
> if (wpa_s->l2) {
> return l2_packet_send(wpa_s->l2, dest, proto, buf, len);
> }
>
> return -1;
> }
I don't know, you should take all this to the hostap list then.
> Currently I don't really get the relation of PTK of the 4-way handshake and the
> PEAP session key of the TLS handshake. Latter encryption should be applied
> independently of the PTK being installed or not or am I wrong? Searching in
> the IEEE802.11 standard didn't help me to find an answer to that question.
The PEAP session is completely transparent to wifi as a transort - as
far as the kernel stack is concerned, the TLS handshake packets are just
data to either be encrypted with the TK (PTK) or not (depending on the
flag), but the inner encryption is totally up to the higher layer.
> So I'd assume there's a bug in the wpa_supplicant or what's your impression?
Sounds like.
> Or is disabling of control_port already considered as a proper solution?
No.
johannes
