On 31/12/15 09:41, Emmanuel Grumbach wrote:
On Thu, Dec 31, 2015 at 10:12 AM, voncken <cedric.voncken@xxxxxxxxx> wrote:
Hi,
I'm not a WPA expert and security expert,
Could you explain why the patch sent by Alexander Wetzel break the security properties of this code?
The Alexander's patch is in attachment.
Thanks for your help.
It simply disables the replay attack detection :)
You could receive the same (encrypted) packet twice and not throw away
the second one.
The author of the patch never said that this patch is a "fix", it is
rather a debug step to understand what happens.
PTK rekeying is a problem from the spec point of view. In Intel, we
did inquiries and in the end we understood that what we should really
do whenever we get to a situation where we need to rekey the PTK is to
disconnect and reconnect. Only weird configuration allow to change the
PTK more frequently than after X packet (don't remember what X is bu
something like 2^32 which is big enough to hold the connection for
days...).
IIRC, Intel devices don't have problems in Tx while we rekey because
we give the key material along with the packet itself, so that we
can't get to a situation where we have old PN and new key. The Atheros
devices separate the key material and the Tx packet (which is a
perfectly valid design decision), but this introduce the possibility
to use the old PN with a new key meaning that the recipient could
decrypt the packet after the new key has been installed, but it would
also update the PN to be high and discard all the next packets that
will come with a new (low) PN.
So essentially, this is a bug in the TX'ing side. Fixing it requires
to hit the performance which is not something people are willing to
do, when the bug is really in the spec.
That's what I remember, but I may be wrong.
We've encountered exactly this problem in a mix of devices where one
applies key material faster than the other. (ath9k and aquilla)
As a workaround we check on the STA if we are authorized when
updating/checking CCMP. (see attached patches)
Not sure what the performance impact of that is.
Is this something which might be interesting to upstream?
-----Message d'origine-----
De : linux-wireless-owner@xxxxxxxxxxxxxxx [mailto:linux-wireless-
owner@xxxxxxxxxxxxxxx] De la part de voncken
Envoyé : mardi 29 décembre 2015 16:24
À : 'Emmanuel Grumbach'
Cc : 'linux-wireless'; 'Johannes Berg'
Objet : RE: Mac80211 : Wpa rekeying issue
> -----Message d'origine-----
De : Emmanuel Grumbach [mailto:egrumbach@xxxxxxxxx] Envoyé : mardi 29
décembre 2015 15:20 À : Cedric VONCKEN Cc : linux-wireless Objet : Re:
Mac80211 : Wpa rekeying issue
On Tue, Dec 29, 2015 at 3:01 PM, Cedric VONCKEN
<cedric.voncken@xxxxxxxxx>
wrote:
Hi,
My test plateform is:
2 equipements
Both equipment used compat version 2015-07-21 from openwrt.
Both equipment used security WPA2
The equipment #1 is an AP.
The Group rekey interval is set to 3601s
The Pair rekey interval set to 50s (I reduced this value to
show the issue often)
The Master rekey interval is set to 86400 s.
The equipment #2 is a sta+wds
I used a 5GHz channel to have a free channel (without other AP) I
connected a computer on each equipment.
To reproduce the issue:
I ran iperf udp@50Mbps from computer connected to the AP to
the computer connected to the sta. After several WPA2 rekeying,
iperf server side didn't received any frame.
I investigated in the driver. All packets are dropped in sta side,
because the function ieee80211_crypto_ccmp_decrypt return
Rx_DROP_UNUSABLE. This function return this code because the test
if(memcmp(pn,key->u.ccmp.rx_pn[queue],IEEE8021_CCMP_PN_LEN) <=0)
return true.
Have you any idea to fix this issue?
I don't remember exactly what we had, but you may look at
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/137742
Thanks for the link, I think I'm in the same situation.
How can I fix this issue?
Because the patch sent by Alexander Wetzel was rejected by Johannes (for
security reason), and if I disable the hw crypto I will have performance
issue.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless"
in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info
at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Matthias May
Software Engineer
Neratec Solutions AG
Postfach 83, CH-8608 Bubikon, Switzerland
Direct: +41 55 253 2074
Office: +41 55 253 2000
Fax: +41 55 253 2070
email: matthias.may@xxxxxxxxxxx
Web: www.neratec.com
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index feb547d..c2adb0d 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -522,7 +522,9 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx,
queue = rx->security_idx;
if (memcmp(pn, key->u.ccmp.rx_pn[queue],
- IEEE80211_CCMP_PN_LEN) <= 0) {
+ IEEE80211_CCMP_PN_LEN) <= 0 &&
+ !(rx->sta && !test_sta_flag(rx->sta,
+ WLAN_STA_AUTHORIZED))) {
key->u.ccmp.replays++;
return RX_DROP_UNUSABLE;
}
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index e115175..dc9c084 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -538,7 +538,13 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx,
return RX_DROP_UNUSABLE;
}
- memcpy(key->u.ccmp.rx_pn[queue], pn, IEEE80211_CCMP_PN_LEN);
+ /* If we are a station update the ccmp counter only when we are
+ * authorised. For all other modes always update. */
+ if (!rx->sta ||
+ (rx->sta && test_sta_flag(rx->sta, WLAN_STA_AUTHORIZED)) ) {
+ memcpy(key->u.ccmp.rx_pn[queue],
+ pn, IEEE80211_CCMP_PN_LEN);
+ }
}
/* Remove CCMP header and MIC */
