wpa_supplicant: FT: No PMKR1Name in FT 4-way handshake message 3/4

[Andreas Steinmetz]

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 at domdv.de