diff mbox

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

Message ID 1479409038.10915.21.camel@domdv.de
State Rejected
Headers show

Commit Message

Andreas Steinmetz Nov. 17, 2016, 6:57 p.m. UTC
[please CC me on replies, I'm not subscribed]

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".

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.

Anyway, wpa_supplicant doesn't seem to use the returned value except
for a paranoia sanity check.

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.

Comments

Jouni Malinen Nov. 19, 2016, 11:13 a.m. UTC | #1
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.
Andreas Steinmetz Nov. 20, 2016, 4:53 p.m. UTC | #2
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.
diff mbox

Patch

--- a/src/rsn_supp/wpa.c	2016-11-17 18:17:47.634394902 +0100
+++ b/src/rsn_supp/wpa.c	2016-11-17 18:18:02.953502135 +0100
@@ -1013,7 +1013,7 @@ 
 	    rsn.num_pmkid != 1 || rsn.pmkid == NULL) {
 		wpa_dbg(sm->ctx->msg_ctx, MSG_DEBUG, "FT: No PMKR1Name in "
 			"FT 4-way handshake message 3/4");
-		return -1;
+		return 0;
 	}
 
 	if (os_memcmp_const(rsn.pmkid, sm->pmk_r1_name, WPA_PMK_NAME_LEN) != 0)