[PATCH 05/44] FT: wpa_auth_ft rrb fix data length

[Jouni Malinen]

On Wed, Mar 02, 2016 at 07:10:52PM +0100, M. Braun wrote:
> I'm thinking about choosing one of a1 / b1 / a2 / b2.
> I'd be fine implementing a1 as this provides all I need. But if any of
> over variants is required, that might be feasable as well.
> 
> Structure:
> 
> a) use TLV. This completely breaks backward compatibility.
> 
> b) keep the existing format, add a magic cookie (like DHCP/BOOTP
>    migration) after the existing message and then add TLV.
>    This should keep compatibility for the attributes already in the
>    message struct.

For b, could define new frame_type values (though, this is not really
nice even with the current ones which are not really properly assigned)
or a completely new frame type. The latter could be considered
especially if we were to move from a MAC frame to something on top of IP
to allow routing of AP-to-AP communication.

As far as (a) vs. (b) is concerned, I think I'm willing to drop
backwards compatibility once for this taken into account the origin and
state of the current protocol. That said, if it is straightforward to
leave the current option in place as-is and define a new one
independently, there could be some value in doing so and remove the
current (i.e., the old at the time) version eventuality after couple of
released versions.

> Encryption
> 
> 1) As IPsec-over-UDP with static keys results in something similar to
>    the current encryption, encryption might just be dropped in hostapd.
>    Using IPsec or some other VPN solution is also more flexible with
>    respect to the available key management schemes.

In theory, yes, this would be quite nice. That said, I find it quite
unlikely that people would be setting up anything secure between APs..

> 2) Hostapd is currently missing some MAC. So replace aeswrap with an
>    AES-GCM implementation.

AES-GCM has the complexity of the IV value having to be unique for every
single use with a specific key. In other words, using AES-GCM would come
at the price of having to define a mechanism to derive and manage new
keys and/or unique IV space..

>    Additionally, if the key provided is all-zero, encryption and
>    authentication could be skipped (for example if used with a VPN).
>    This way users that do not need in-hostapd encryption/authentication
>    of the message can skip it and reduce cpu time needed.

I'm not sure I like this and certainly not with "all-zero key" as the
way of configuring this.

If the new mechanism is over an IP connection, it would be somewhat
easier to justify that external VPN configuration needs to be used.
Though, this would also come with the price of having to have IP
addresses for the APs to be configured statically are learned through
some mechanism (I guess this could use DNS as well, if desired).

-- 
Jouni Malinen                                            PGP id EFC895FA