On Wed, Feb 24, 2016 at 12:53:11PM +0100, michael-dev@xxxxxxxxxxxxx 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
