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

[M. Braun]

Am 28.02.2016 um 10:57 schrieb Jouni Malinen:
> I don't think there is much point in trying to extend this any further
> without a complete redesign. As such, I think I'm likely to apply this
> patch to document the earlier breakage, but not any of the following
> patches that extend these structs. Instead, we should design a new
> extensible format (e.g., TLVs that can be added to the message and
> length fields that are actually used by the recipient to find the
> validation data instead of using hardcoded offset in the build). In
> addition, AES key wrap is not really ideal for this purpose either, so
> that could be replaced as well.
> 

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.

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.

2) Hostapd is currently missing some MAC. So replace aeswrap with an
   AES-GCM implementation.
   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.

Regards,
M. Braun