[PATCH V2 0/9] nl80211: add support for PTK/GTK handshake offload

[Arend van Spriel]

On 6/9/2017 11:08 AM, Johannes Berg wrote:
> Hi Arend,
> 
> Sorry about the delay.

No problem.

>>> Then you have to support NEW_KEY (AP case) and then using NEW_KEY
>>> to
>>> detect whether or not a wpa_s configuration option to not use
>>> offloaded
>>> 4-way-HS can be used will not work correctly.
>>>
>>> I don't really see that this is a sensible configuration, but I
>>> could
>>> imagine it existing if somebody "bolted on" AP functionality for a
>>> client-side chipset or something like that.
> 
>> So I want to get back to this as to assure we have the same
>> understanding. First off, the proposed offloads are STA-only.
> 
> Right. But we at least also want to have them for AP mode, which
> answers your below question.
> 
>> So if a
>> driver supports STA and AP mode and the 4-way-HS offload, we could
>> already have the case you describe here. So not really a "bolted on"
>> scenario I would say.
> 
> But if you say you don't have it in AP mode, or you didn't even think
> about it in AP mode yet, then I think you're right and the "bolted on"
> part doesn't really apply (*).

yup.

> However, this does mean that checking for NEW_KEY support _isn't_
> sufficient to understand whether or not the device also supports doing
> the 4-way-HS in the host, because the device might _not_ support that
> in client mode, yet implement NEW_KEY for AP mode, right?

Indeed. I did not state it explicitly, but that is also my understanding 
so not going to do that.

> In any case - I don't think this changes much my opinion. I think that
> newer wpa_s should always use the offload where available, and if
> there's a debug option to turn that off, and that debug option causes
> failures because the driver rejects the NEW_KEY command, rather than
> causing an up-front configuration failure because wpa_s knows that the
> NEW_KEY wouldn't be supported, then I don't think for a debug option
> that makes a big difference. For something that higher layers might
> need to set, it would make a difference - but that's not at stake here.

Not trying to change your opinion ;-). Just getting it all clear. As a 
matter of fact I already have my wpa_s use the offload without any 
debug/config option. As brcmfmac can use override to disable firmware 
features I also do not need such in wpa_s.

> (*) my line of thinking was that if you have the necessary state
> machine for client in the firmware, then it's not a huge step to also
> have it for AP, since you have the crypto primitives for it

Agree. However, in our firmware they are two modules that can be 
compiled in, ie. idsup and idauth.

Regards,
Arend