Is PMF with development branch working?

[Karthik Krishnamoorthy]

Hi Jouni,

I believe to have found the issue:

The issue seems to be in src/ap/wpa_auth_ie.c:

int wpa_write_rsn_ie(struct wpa_auth_config *conf, u8 *buf, size_t len,
                     const u8 *pmkid)
{

....
....

#ifdef CONFIG_IEEE80211W
if (conf->ieee80211w != NO_MGMT_FRAME_PROTECTION &&
    conf->group_mgmt_cipher != WPA_CIPHER_AES_128_CMAC) {
if (2 + 4 > buf + len - pos)
return -1;
if (pmkid == NULL) {
/* PMKID Count */
WPA_PUT_LE16(pos, 0);
pos += 2;
}

/* Management Group Cipher Suite */
switch (conf->group_mgmt_cipher) {
case WPA_CIPHER_AES_128_CMAC:
RSN_SELECTOR_PUT(pos, RSN_CIPHER_SUITE_AES_128_CMAC);
break;
case WPA_CIPHER_BIP_GMAC_128:
RSN_SELECTOR_PUT(pos, RSN_CIPHER_SUITE_BIP_GMAC_128);
break;
case WPA_CIPHER_BIP_GMAC_256:
RSN_SELECTOR_PUT(pos, RSN_CIPHER_SUITE_BIP_GMAC_256);
break;
case WPA_CIPHER_BIP_CMAC_256:
RSN_SELECTOR_PUT(pos, RSN_CIPHER_SUITE_BIP_CMAC_256);
break;
default:
wpa_printf(MSG_DEBUG,
   "Invalid group management cipher (0x%x)",
   conf->group_mgmt_cipher);
return -1;
}
pos += RSN_SELECTOR_LEN;
}
#endif /* CONFIG_IEEE80211W */

.....
.....

}

Here the condition check :
if (conf->ieee80211w != NO_MGMT_FRAME_PROTECTION &&
    conf->group_mgmt_cipher != WPA_CIPHER_AES_128_CMAC) {

will be missed since the default group_mgmt_cipher will be WPA_CIPHER_AES_128_CMAC.

Whereas the condition check in hostapd-2.1 is :

if (conf->ieee80211w != NO_MGMT_FRAME_PROTECTION)

So here the value is set correctly.

If I remove this check (conf->group_mgmt_cipher != WPA_CIPHER_AES_128_CMAC) it works properly.

Regards,
Karthik.

-----Original Message-----
From: Jouni Malinen [mailto:j at w1.fi]
Sent: Thursday, 3 May 2018 7:22 PM
To: Karthik Krishnamoorthy <kkrishnamoorthy at quantenna.com>
Cc: hostap at lists.infradead.org
Subject: Re: Is PMF with development branch working?


External Email


On Thu, May 03, 2018 at 08:37:08AM +0000, Karthik Krishnamoorthy wrote:
> I am working on the development branch for hostapd.
>
> I started testing PMF mode , with ieee80211w=1.
>
> From testing what I see is the client fails to associate.
>
> On sniffer analysis , I found that Message 3 from AP is not proper.

Can you please share a sniffer capture file showing this, the hostapd.conf file used in the test, and debug log from hostapd (ideally, using some dummy passphrase/password and -ddK on the command like to expose all key material)?

Which client did you use in the test? And what do you mean with "fails to associate"? 4-way handshake is started only after the association has been completed, so if you get to Message 3 of the 4-way handshake, the client has already associated..

> Especially the WPA key data length is 88 bytes.
>
> Whereas when I compare this with hostapd 2.1 version , the WPA key data length is 96 bytes.
>
> There is 8 byte mismatch in the M3 message from AP between hostapd version 2.1 and latest development branch version.

The length of the Key Data field depends on the contents of the RSN element and group cipher, so both of those lengths can be valid.

> Clients associate with hostapd 2.1 version, so I believe that is a correct length.

There is no specific "correct length". For example, a commonly used RSNE of 22 octets (ending with the RSN Capabilities subfield), CCMP as the group ciphers, and BIP as the group management cipher ends up having
22+24+30=76 octets of IEs/KDEs in the plaintext version. That gets
padded with 4 octets to 80 octets to make this a multiple of 8. And AES Key Wrap adds 8 octets to the length, so the total encrypted length of the Key Data field becomes 88 octets.

> Anyone seen this behaviour or is this fixed already? Do I need to sync to latest code?

I'm not aware of any issues in the PMF implementation between version
2.1 and the current snapshot.

--
Jouni Malinen                                            PGP id EFC895FA


This email, including its contents and any attachment(s), may contain confidential information of Quantenna Communications, Inc. and is solely for the intended recipient(s). If you may have received this in error, please contact the sender and permanently delete this email, its contents and any attachment(s).