[PATCH] rsn_supp: Don't encrypt EAPOL-Key 4/4.

Andreas Hartmann andihartmann
Sat Sep 1 06:18:08 PDT 2012


Jouni Malinen schrieb:
> On Mon, Feb 13, 2012 at 11:39:26AM +0100, Nicolas Cavallari wrote:
>>> What were those other data frames? If this is during the initial 4-way
>>> handshake, the port (PAE) should be unauthorized and other data frames
>>> apart from EAPOL frames should be blocked.
>>
>> Only the specific port corresponding to that particular authenticator is
>> blocked. Other ports from other authenticators may be open. This is not
>> the case for Andreas, as he is in Infrastructure mode. But for me it is,
>> in IBSS mode...
> 
> Sure, though even in that case, the non-EAPOL Data frames that get
> through should be for other destinations. I'm not sure I've fully
> understood this specific part of the issue, though.
> 
>>> As far as rekeying is concerned, this gets quite a bit more
>>> complex (until the newly defined non-zero key index PTK gets into use).
>>
>> Which standard is this ? I might want to implement this for my
>> private IBSS network.
> 
> It was added in P802.11-REVmb/D3.0 and will be included in the IEEE Std
> 802.11-2012 that should get published in a couple of months (it is
> included in the latest draft: P802.11-REVmb/D12).
> 
> These 802.11 submissions may be helpful in understanding the changes:
> 
> https://mentor.ieee.org/802.11/dcn/10/11-10-0313-01-000m-rekeying-protocol-fix.ppt
> https://mentor.ieee.org/802.11/dcn/10/11-10-0314-00-000m-rekeying-protocol-fix-text.doc

May I kindly ask if these protocol changes have already been implemented
in wpa_supplicant / hostapd? The actual situation is really annoying :-(.


Thanks,
kind regards,
Andreas Hartmann




More information about the Hostap mailing list