On Thu, Nov 17, 2016 at 07:57:18PM +0100, Andreas Steinmetz wrote: > Trying to associate with wpa_supplicant 2.6 to a Lancom AP/WLC > combination in 802.11r eap mode fails with the message "FT: No > PMKR1Name in FT 4-way handshake message 3/4". That AP implementation sounds broken if it does not use properly constructed RSNE in the EAPOL-Key message 3/4. IEEE Std 802.11-2012, 12.4.2 mandates this behavior: "Message 3: the R1KH shall include the PMKR1Name in the PMKID field of the RSNE. The PMKR1Name shall be as calculated by the R1KH according to the procedures of 11.6.1.7.4 and shall be the same as the PMKR1Name in Message 2; all other fields of the RSNE shall be identical to the RSNE present in the Beacon or Probe Response frames." It would be interesting to see a more detailed debug log or capture file showing this behavior. > Googling around it seems that including the PMK-R1-Name in said message > seems to be optional, though I can't seem to find any proper documents. I'm not sure what that claim is based on, but it is not correct. This is clearly mandated to be present in the message. > Anyway, wpa_supplicant doesn't seem to use the returned value except > for a paranoia sanity check. This validation is part of the FT security implementation, not a "paranoia sanity check". IEEE P802.11REVmc/D8.0 describes the rules quite clearly: "The Supplicant also: a) Verifies the RSNE. If this message 3 is part of a fast BSS transition initial mobility domain association or an association started through the FT protocol, the Supplicant verifies that the PMKR1Name in the PMKID field of the RSNE is identical to the value it sent in message 2 and verifies that all other fields of the RSNE are identical to the fields in the RSNE present in the Beacon or Probe Response frames and verifies that the FTE and MDE are the same as in the (Re)Association Response frame." > The attached patch simply changes the behaviour when PMK-R1-Name is not > included in the message from error to warning and wpa_supplicant > completes association/authentication. One could use that if one does not care about security.. More appropriate way of fixing this would be to fix the AP to be compliant with the IEEE 802.11 standard. It is not acceptable to delete mandatory validation steps from a security exchange. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
