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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
