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

[Jouni Malinen]

On Wed, Feb 24, 2016 at 12:53:11PM +0100, michael-dev at fami-braun.de wrote:
> The FT RRB hostapd packets have a length field.
> For PULL frames, it counts the bytes starting with nonce and up to the last
> before pad. For RESP frames, it counts the bytes starting with nonce and up
> to the last before pad except for 2 bytes. For PUSH frames, it counts the
> bytes starting with nonce and up to including pad.

Those missing 2 bytes and including pad are bugs from the change that
added the 2 octet pairwise field. data_length was supposed to be length
of the encrypted plaintext before padding.

> AES encryption is not affected, as rounding hides the differences.
> The packets data_length field is not used, so the differences have no
> effect there.

This change would still "break" the previously used message format by
fixing the data_length field. I was thinking of not applying this, but I
guess this could be final accepted change to the AP-to-AP protocol to
since it actually fixes the data_length values to be what they were
supposed to be after the pairwise 2 octet field was added. Since the
receiving processing does not use the data_length field in hostapd (and
I'm not aware of any other implementation using the message format),
this change could be accepted.

> As rounding is done with AES encryption, including pad does not make sense.
> Not including the last field before pad does not make sense to me either.

Agreed.

> So this patch changes the constants to match the bytes used, thus excluding
> pad.
> To validate the changes, look at remainder modulo 8 of the sum of the size
> constants and the padding sizes.

I think this message format has come to the end of its useful life. It
was a quick prototype implementation to allow some AP-to-AP
communication to be experimented with. It is clearly not extensible and
the last attempt to extend it (that pairwise field six years ago)
already failed.

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.

-- 
Jouni Malinen                                            PGP id EFC895FA