The password in User-Password AVP is padded to a multiple of 16 bytes
on EAP-TTLS/PAP. But when the password length is zero, no padding is
added. It doesn't cause connectivity issue. In fact, I could connect
with hostapd RADIUS server with zero length password.
I think it's better for obfuscation to pad the 16 bytes data when the
password length is zero with this patch.
In addition, start ordering header file includes to be in more
consistent order: system header files, src/utils, src/*, same
directory as the *.c file.
Changed peer to derive the full key (both MS-MPPE-Recv-Key and
MS-MPPE-Send-Key for total of 32 octets) to match with server
implementation.
Swapped the order of MPPE keys in MSK derivation since server
MS-MPPE-Recv-Key | MS-MPPE-Send-Key matches with the order specified for
EAP-TLS MSK derivation. This means that PEAPv0 cryptobinding is now
using EAP-MSCHAPv2 MSK as-is for ISK while EAP-FAST will need to swap
the order of the MPPE keys to get ISK in a way that interoperates with
Cisco EAP-FAST implementation.
The previous version was deriving unnecessarily large amount of output data
for the implicit challenge. With the TLS PRF, this was not causing any
problems because the output length is not explicitly bound into the
derivation. Anyway, it is better to use the correct output length should
the PRF be ever changed to a one that uses the output length to change the
beginning of the output data.
Need to process EAP AVP after the non-EAP Phase 2 method. In addition,
EAP-TTLS/MSCHAPv2 needs special code for handling the starting of TNC after
extra roundtrip of MSCHAPv2 success message.
