Re: [PATCH v2 4/9] ft: add FTE/RSNE building to ft_prepare_handshake

[James Prestwood <prestwoj@gmail.com>]

Hi Denis,

On 12/6/23 08:36, Denis Kenzior wrote:
> Hi James,
>
> On 12/6/23 09:07, James Prestwood wrote:
>> In preparation to remove ft_associate build the FTE/RSNE in
>> ft_prepare_handshake and set into the handshake object directly.
>> ---
>>   src/ft.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>>   1 file changed, 82 insertions(+), 2 deletions(-)
>>
>
> <snip>
>> +    fte = alloca(256);
>> +    ie_build_fast_bss_transition(&ft_info, kck_len, fte);
>> +
>> +    if (!ft_calculate_fte_mic(hs, 5, rsne, fte, NULL, ft_info.mic))
>> +        return false;
>> +
>> +    /* Rebuild the FT IE now with the MIC included */
>> +    ie_build_fast_bss_transition(&ft_info, kck_len, fte);
>> +
>> +    handshake_state_set_fte(hs, fte);
>
> However, this is less clear to me.  Looking at how FILS and FT uses 
> this API, it seems that set_fte is meant for the authenticator FTE 
> element?  So I think rekeying after FT would be broken by this change.

Good question. Rekeys do appear to work as-is but you are right, FILS/FT 
uses set_fte() for the authenticators element, but eapol seems to use 
hs->fte for building message 2/4, as well as checks that the handshakes 
FTE matches what the authenticator sends in 3/4. maybe this is actually 
a bug in eapol? I think the reason everything "works" is because the FTE 
should be the same between both peers.

We may want to refactor and do:

handshake_state_set_authenticator_fte()

handshake_state_set_supplicant_fte()

Thanks,

James

>
>> +
>> +    return true;
>>   }
>>     static bool ft_send_action(struct wiphy_radio_work_item *work)
>
> Regards,
> -Denis