| Message ID | 20190214124653.24793-1-mikael.kanstrup@sony.com |
|---|---|
| State | RFC |
| Headers | show |
| Series | [RFC] PMF: Allow Key ID in big endian format to workaround faulty APs | expand |
On Thu, Feb 14, 2019 at 01:46:53PM +0100, Mikael Kanstrup wrote: > A few APs out on the market have got the byte order of IGTK key > index wrong making PMF enabled connections fail to connect. The faulty > APs request STAs to configure IGTK with key ID value 1024 or 1280. > Looking more closely into the values requested, 4 and 5 in 16-bit > network byte order/big endian byte order happens to correspond to > 1024 and 1280 respectively in wireless little endian byte order. As > connect attempts using out of spec values will anyway fail detect > and workaround the problem by reading the incorrect values in big > endian format. Do you have reason to believe that the particular APs with this behavior have PMF working otherwise? For example, is the IGTK provided by those APs with this swapped KeyID actually the correct IGTK and if the AP were to transmit a group-addressed robust management frame, that would be correctly protected using this IGTK? And maybe more importantly, that the particular IGTK is not a predictable value where this type of workaround would result in a security vulnerability. If the AP does not implement PMF correctly, the best workaround would likely be to not try to use PMF with that AP. Allowing the association to go through can result in false sense of security and some upper layer operations getting unexpected behavior if the station device assume there is protection for all the robust management frames while that is not really the case. Do you have such a broken AP available for testing different types of workarounds for this issue? My main issue with this item has been that I have no such AP, so I cannot really fully evaluate the impact of various possible workarounds for this.
>From: Jouni Malinen <j@w1.fi> >Sent: Feb 15, 2019 11:10 >> A few APs out on the market have got the byte order of IGTK key >> index wrong making PMF enabled connections fail to connect. The faulty >> APs request STAs to configure IGTK with key ID value 1024 or 1280. ... >> and workaround the problem by reading the incorrect values in big >> endian format. > Do you have reason to believe that the particular APs with this behavior > have PMF working otherwise? Good point. Only limited checks done. For example that AP can handle encrypted deauth frames. > is the IGTK provided by those APs with this swapped KeyID actually the > correct IGTK and if the AP were to transmit a group-addressed robust > management frame, that would be correctly protected using this IGTK? I've only been able to get hold of one of these AP models. It's a home router with limited feature set. No fast bss transition support for example. So was not able have the AP send any frames that should be encrypted with IGTK and can't really answer if the IGTK was valid or not. Looking at that ieee standard I don't think it's obvious which frames should be encrypted with IGTK. If you know of any common frame types I can check. Must admit I've mostly looked at PMF as a way to prevent deauth attacks. > And maybe more importantly, that the particular IGTK is not a predictable > value where this type of workaround would result in a security vulnerability. Hard to tell just by looking at the IGTK received. But yeah good point. > If the AP does not implement PMF correctly, the best workaround would > likely be to not try to use PMF with that AP. Right. Maybe this should rather be implemented outside of wpa_supplicant. Like disabling PMF for the specific network if PMF fails. > Do you have such a broken AP available for testing different types of > workarounds for this issue? I have access to only one that I unfortunately cannot share information about. But I can get hold of vendor OUI from a couple APs and probably determine brand/model for a few of them. > My main issue with this item has been that I have no such AP, so I cannot > really fully evaluate the impact of various possible workarounds for this. Understood. I'll try to gather necessary information. Thanks for feedback! /Mikael
On Fri, Feb 15, 2019 at 03:08:26PM +0000, Kanstrup, Mikael wrote: > >From: Jouni Malinen <j@w1.fi> > > > Do you have reason to believe that the particular APs with this behavior > > have PMF working otherwise? > > Good point. Only limited checks done. For example that AP can handle encrypted > deauth frames. OK, so at least it is trying to do PMF and maybe is even successful at that with unicast frames. > > is the IGTK provided by those APs with this swapped KeyID actually the > > correct IGTK and if the AP were to transmit a group-addressed robust > > management frame, that would be correctly protected using this IGTK? > > I've only been able to get hold of one of these AP models. It's a home router > with limited feature set. No fast bss transition support for example. So was not > able have the AP send any frames that should be encrypted with IGTK and can't > really answer if the IGTK was valid or not. > > Looking at that ieee standard I don't think it's obvious which frames should > be encrypted with IGTK. If you know of any common frame types I can check. > Must admit I've mostly looked at PMF as a way to prevent deauth attacks. BIP/IGTK does not actually encrypt anything; it adds integrity protection with an extra information element (MME) at the end of the frame. There are not many frames that this would apply to in practice, though, and it is possible that there are APs that do not send even a single group-addressed robust management frame. These frames are: broadcast Deauthentication/Disassociation frame and broadcast/multicast Robust Action frames. The former might be sent, e.g., when shutting down the AP. There are not any currently defined example in use for the latter. > > And maybe more importantly, that the particular IGTK is not a predictable > > value where this type of workaround would result in a security vulnerability. > > Hard to tell just by looking at the IGTK received. But yeah good point. One option here would be to modify wpa_supplicant_install_igtk() to ignore wpa_sm_set_key() failure if keyidx is 0x0400 or 0x0500. In other words, do not configure IGTK at all if the AP is using unexpected KeyID and the local driver does not support that value instead of trying to guess that the AP really meant keyidx 4 or 5. Would just need to confirm that the local driver is rejecting any group-addressed robust management frame if there is no key configured for the keyidx. The main benefit here would be in the local driver not getting that IGTK value enabled if there is a risk of it being predictable value that an attacker could use to inject frames. This change would look something like following: diff --git a/src/rsn_supp/wpa.c b/src/rsn_supp/wpa.c index 86593ab..4a82c86 100644 --- a/src/rsn_supp/wpa.c +++ b/src/rsn_supp/wpa.c @@ -1052,7 +1052,12 @@ static int wpa_supplicant_install_igtk(struct wpa_sm *sm, igtk->igtk, len) < 0) { wpa_msg(sm->ctx->msg_ctx, MSG_WARNING, "WPA: Failed to configure IGTK to the driver"); - return -1; + /* Work around issues with APs that are know to use incorrect + * byte order for the KeyID field. Leave the IGTK unconfigured + * while allowing unicast PMF to be used. + */ + if (keyidx != 0x0400 && keyidx != 0x0500) + return -1; } if (wnm_sleep) { > > If the AP does not implement PMF correctly, the best workaround would > > likely be to not try to use PMF with that AP. > > Right. Maybe this should rather be implemented outside of wpa_supplicant. Like > disabling PMF for the specific network if PMF fails. Well, wpa_supplicant could do this automatically if PMF is locally configured to be optional and try to connect again. However, if it is clear the particular APs actually do implement PMF correctly for unicast frames, it may make more sense to simply ignore all BIP/IGTK cases.
diff --git a/src/rsn_supp/wpa.c b/src/rsn_supp/wpa.c index 86593ab78..32b9b9326 100644 --- a/src/rsn_supp/wpa.c +++ b/src/rsn_supp/wpa.c @@ -1024,6 +1024,12 @@ static int wpa_supplicant_install_igtk(struct wpa_sm *sm, { size_t len = wpa_cipher_key_len(sm->mgmt_group_cipher); u16 keyidx = WPA_GET_LE16(igtk->keyid); + if (keyidx == 1024 || keyidx == 1280) { + /* Workaround incorrectly behaving APs that send Key ID in big endian format */ + wpa_printf(MSG_INFO, "PMF: Workaround - Allow Key ID in big endian format(%d)", + keyidx); + keyidx = WPA_GET_BE16(igtk->keyid); + } /* Detect possible key reinstallation */ if ((sm->igtk.igtk_len == len &&