On Fri, Feb 15, 2019 at 03:08:26PM +0000, Kanstrup, Mikael wrote:
> >From: Jouni Malinen <j@xxxxx>
>
> > 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.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
