Am Samstag, den 19.11.2016, 13:13 +0200 schrieb Jouni Malinen: > 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. > Well, looking again it seems I got that wrong, e.g. from https://mrncciew.com/2014/09/07/cwsp-802-11r-over-the-air-ft/ (last picture), which references not association but transition. My bad. > > > > 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. > Opened a ticket at the manufacturer. Thanks for your clarification. -- Andreas Steinmetz SPAMmers use robotrap@xxxxxxxx _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
