Sorry, forgot to put the Mailing list on CC for the initial mail. So
here again:
Am 06.01.20 um 12:38 schrieb Alexander Wetzel:
Am 06.01.20 um 10:03 schrieb Jouni Malinen:
On Sat, Jan 04, 2020 at 11:10:01PM +0100, Alexander Wetzel wrote:
Rekeying a pairwise key using only keyid 0 (PTK0 rekeys) has many broken
implementations and should be avoided for both security and usability
reasons.
The effects can be triggered by either end of the connection and range
from hardly noticeable disconnects over long connection freezes up to
leaking clear text MPDUs which can be used to calculate the outgoing
PTK.
To avoid the issues replace PTK0 rekeys by default with disconnects and
add the new option "wpa_deny_ptk0_rekey" to let the user control the
behavior.
I don't think it is appropriate to force disconnections by default for
all existing systems. It would seem fine to provide an option to
explicitly request such behavior, but this by-default-behavior looks
like a too drastic approach to take when there are multiple drivers that
have over years added various workarounds to avoid many of the issues
for most common cases.
I'm aware of the issue to be controversial. For me this looks more risky
than the alternative, but I can't rule out I miss something...
Have you some evidence of rekeying to be really working in real-world
scenarios? It can work with carefully selected cards/drivers but in
mixed environments it seems to be asking for trouble.
I've done some tests with abysmal results with HW available to me.
I tried to google issues related to that and did find some - but much
less than expected - candidates ranging from very likely to maybe. Some
were even discussing GTK rekeys when the log evidence made clear that
they had a PTK rekey issue.
I can only explain the missing outcry by the assumption that rekeying is
seldom used and the few users hit by it are using the workarounds for
"strange wifi issues" like disabling HW encryption and/or A-MPDU
aggregation or switching to other HW. Coupled with the normal 1h "dead
time" you need to hit the first problem and that most systems seem to
recovering already with a reconnect that may just be possible...
Set your AP to rekey all 30s and start a download or video streaming and
check what happens with your different devices. (I'm normally testing
close to the AP.)
For me with Windows the "common" case was a disconnect, due to
encrypting the eapol #4 with the new key. I was initially assuming that
these reconnects were by design to recover from whatever went wrong and
was wondering why linux systems did freeze instead. Fixing eapol#4 races
may therefore make the situation worse.
Here list for devices/System which got at least some quick look and what
I found out (this data is roughly two years old):
The only working devices I found are
- ath10k with linux (not tested with Windows)
- Windows Surface Pro 3 running Win 10 (I think many/most/all Marvell
drivers could be ok)
- iPhone (I think it was a iPhone X but may be off one generation)
Known devices/systems not able to rekey the PTK correctly:
- any linux system using ath9k with mac80211 from kernel < 4.20
- HTC 10 smartphone (running Linageos)
- Nexus 5x smartphone (stock)
- Samsung Galaxy S5 smartphone (running Linageos)
- Samsung Galaxy Tab S3 (stock)
- Samsung Series 6 SmartTV
- Dell notebook using some broadcom fullmac NIC (Windows 7)
- AWUS036ACH USB stick (Win10)
So there is at least some evidence that many developers did not consider
the races and the potential consequences of ignoring them has.
There is basically no way that the ath9k driver is not messing up a
rekey with ongoing traffic. It's also so far the only known driver which
can leak the PTK. Especially with TKIP this looks extremely dangerous,
where an attacker can trigger the rekeys at will.
I've not tried it, but generate MIC errors at a busy moment and you will
get MPDUs fully set up for encryption with only the encryption missing.
And that also works for retransmits, so you can get the same MPDU
encrypted and decrypted... Which for my understanding then allows you to
calculate the PTK and decrypt any previously captured MPDUs using the PTK.
Now this is of course nothing more than a driver issue but looking at
the lists I would be very surprised if not at least 50% of common used
devices are broken today and expect rates around 90%. (With most already
reconnecting, mitigating the user impact.)
For me the issue started with these two tickets, when I got frustrated
by the strange wlan freezes and could no longer deny a pattern after
having ignored it for years:
- https://bugzilla.kernel.org/show_bug.cgi?id=92451
- https://dev.archive.openwrt.org/ticket/18966
I was able to pin the issue to PTK rekeying with clear evidence showing
what was going on. But nothing happened and so some years later I
decided to try to fix that myself. A important mile stone was the fix
for mac80211 62872a9b9a10 ("mac80211: Fix PTK rekey freezes and clear
text leak"), which is to my best knowledge the first documentation what
must be considered when replacing a PTK key besides the eapol#4 race -
which is pretty harmless compared to the other races a driver can have.
Keeping the old behavior as default will for sure cause less pain, after
all the problems are as old as WPA and the users must have reached some
kind of arrangement with the situation. But knowing that this can leak
PTKs it looks like the only secure approach is enforce the reconnects.
The reasoning is, that since we do not have a outcry of users with PTK
rekey issues today and most devices are already reconnecting on rekey
there should not be many users which should notice the difference.
But quite some of them may leak PTK keys.
I would of course feel better if more would test PTK rekeying in their
setups or at least get some data how often PTK rekeying is enabled by
default and what are the intervals.
Not changing the default is ok when we are sure that only ath9k with
mac80211 < 4.20 is leaking clear text MPDUs and no other of the broken
devices fell into the same trap. Or - since my understanding of the used
cypto is still lacking - someone can confirm that having an encrypted
MPDU and the same MPDU decrypted (with all the same headers and PN) does
not allow to calculate the PTK.
I small update on that:
After some reading I'm sure the clear text leak is harmless with
"modern" TKIP/CCMP ciphers. The only security relevant issue allowing
attacks on the key seems to be the the PN reuse.
Here the attack, designed for ath9k cards using vulnerable mac80211:
1) Attacker sets up an "repeater" and getting an victim to funnel all
communication with the true AP trough it. (When thew AP is vulnerable
all STAs can be attacked.)
2) The repeater is normally just passing through all frames without
modifications but a small delay (10ms or so, probably needs some tuning)
3) Once the "repeater" detects an PTK rekey (PN numbers reset to zero)
it drops all packets buffered to stop all packets using the PN from the
old key encrypted with the new to reach the other STA. (This prevents
the freeze AND the attacker gets some packets for the new key with PN
numbers the new key may reach)
4) Now the attack needs luck or a way to generate traffic for the
association: The PN for the new key must become a bit higher than for
the first key.
5) Which violates the requirement that PNs must never be reused. (Sounds
like this opens some cryptographic attacks)
6) Which then potentially allows to decrypt or is at least weakening the
encryption of all other MPDUs protected with the same key. (Not sure how
bad it really is but for my understanding it crosses a red line.)
With CCMP the attacker can't control the time for the PTK rekey, so a
mostly idle connection during the rekey will make this a hit and miss.
But if the connection is using TKIP he simply can time a rekey by
generating Michal MIC errors when he wants...
I did find anything how much effort it would be to calculate the PTK
when you have multiple MPDUs using the same PN. (I guess 10 pairs of
duplicate PN MPDUs can be achieved by the attack on each rekey.)
Do you see any holes in the attack scenario?
Alexander
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
