Re: [STDS-802-11-TGM] [STDS-802-11] KRACK paper actions

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

In the context of the response to the KRACK vulnerability, it might be

worth reviewing the following elements of the KRACK paper (my emphasis),

https://papers.mathyvanhoef.com/ccs2017.pdf , if this has not already

been done:

After discussion with Mathy, the author of the KRACK paper, here is what

I think the disposition of the various issues could be (in general I

echo him since he's the security expert!):

First, the

entity implementing the data-confidentiality protocol should check

whether an already-in-use key is being installed. If so, it should

not reset associated nonces and replay counters. This prevents our

attacks, at least if an adversary cannot temporarily trick an

implementation into installing a different (old) key before reinstalling

the current one.

https://mentor.ieee.org/802.11/dcn/17/11-17-1602-03-000m-nonce-reuse-prevention.docx

basically addresses this.

In particular, when using this countermeasure it is

essential that the replay counter of received group key handshake

messages only increases.

This is already mandated clearly enough in the standard. Mathy points at

12.7.7.2 in 802.11-2016: "On reception of message 1, the Supplicant:

a) Verifies that the Key Replay Counter field value has not yet been seen

before, i.e., its value is strictly larger than that in any other EAPOL-Key

frame received thus far during this session."

Otherwise, an adversary can use an old

group message 1 to make a victim temporarily install an old

(different) key, to subsequently reinstall the current group key using a

more recent group message 1.

Mathy has identified an edge case where the adversary can first install

a new group key (e.g. using a WNM-Sleep Exit frame), and then reinstall

an old group key (e.g. using an EAPOL-Key group message). Jouni concurs,

as I understand it.

This edge case should be explicitly addressed in the standard. Mathy

suggests wording like: "Additionally, stations must track the last configured

GTK/IGTK value separately from EAPOL-Key frames and WNM-Sleep Mode

frames to cover a corner case where these two different mechanisms may

get used when the GTK/IGTK has changed and tracking a single value is

not sufficient to detect a possible key reinstallation". (We might want

to make the wording more generic, so that we won't have spec rot

when a third way to set (I)GTKs gets introduced.)

A second solution is to assure that a particular key is only in-

stalled once into the entity implementing the data-confidentiality

protocol during a handshake execution. For example, the generated

session key in a 4-way handshake should only be installed once.

When the client receives a retransmitted message 3, it should reply,

but not reinstall the session key. This can be accomplished by adding

a boolean variable to the state machine of Figure 3. It is initialized to

false, and set to true when generating a fresh PTK in PTK-START. If

the boolean is true when entering PTK-DONE, the PTK is installed

and the boolean is set to false. If the boolean is false when entering

PTK-DONE, installation of the PTK is skipped

Mathy thinks it would be extra protection, but not necessary. Only

with the group key scenario is extra care needed (as far as he knows).

When GCMP is used, the impact is catastrophic. First, it is

possible to replay and decrypt packets. Additionally, it is possible to

recover the authentication key [43], which in GCMP is used to

protect both communication directions (recall Section 2.4). Therefore,

unlike with TKIP, an adversary can forge packets in both directions.

Given that GCMP is expected to be adopted at a high rate in the next

few years under the WiGig name [58], this is a worrying situation

[…]

with GCMP the authentication key can be recovered in case of nonce

recuse, while this is not so for CCMP. More generally, a nonce

misuse-resistant encryption scheme should be used, examples being

AES-SIV, GCM-SIV, or HS1-SIV [16].

Mathy points out TLS 1.3 is also still using GCM. What makes the situation

worse in 802.11 though is that the same authentication key is used in both

communication directions. He's not sure if it's worth it to deprecate

GCM currently, though.

when attacking the 4-way

handshake in Section 3.3, we observed that the 802.11 standard is

ambiguous as to which replay counter values should be accepted. A

more precise or formal specification would avoid any such potential

incorrect interpretations.

[…]

However, a careful inspection of the 802.11 standard reveals that

the authenticator may accept any replay counter that was used in

the 4-way handshake, not only the latest one [1, §12.7.6.5]:

“On reception of message 4, the Authenticator verifies

that the Key Replay Counter field value is one that it

used on this 4-way handshake.”

In practice, we found that several APs indeed accept an older replay

counter. More precisely, some APs accept replay counters that were

used in a message to the client, but were not yet used in a reply

from the client (see column 2 in Table 2 on page 8). These APs

will accept the older unencrypted message 4, which has the replay

counter r+1 in Figure 4. As a result, these AP will install the PTK,

and will start sending encrypted unicast data frames to the client.

Mathy suggests that something like the following would make it clearer:

"On reception of message 4, the Authenticator verifies that the Key

Replay Counter field value is one that it used on this 4-way handshake

and is strictly larger than that in any other EAPOL-Key frame received

thus far during this session."

the model of the 4-way handshake used in formal proofs did not fully

reflect reality. This is because it did not define when the negotiated

session key should be installed. As a result, there was no guarantee

that a session key is installed just once.

Mathy doesn't think this has implications for the wording of the standard.

The 802.11 standard says that a retransmitted message 4 must be sent in plaintext in

the initial 4-way handshake [1, §12.7.6.5], but nearly all clients send it using encryption

Mathy thinks this is not security-critical.

Thanks,

Mark

Mark RISON, Standards Architect, WLAN English/Esperanto/Français

Samsung Cambridge Solution Centre Tel: +44 1223 434600

Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601

ROYAUME UNI WWW: http://www.samsung.com/uk

From: Dorothy Stanley [mailto:dstanley1389@xxxxxxxxx]
Sent: 6 November 2017 10:13
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11] Revised TGmd agenda posted - Note proposed motions this week re: removal of Phased Coexistence Operation and Strictly Ordered Service Class

--- This message came from the IEEE 802.11 Working Group Reflector ---

All,

A revised TGmd agenda is available, see https://mentor.ieee.org/802.11/dcn/17/11-17-1556-01-000m-november-2017-tgmd-agenda.pptx .

Please note: proposed Wednesday PM1 motions, see https://mentor.ieee.org/802.11/dcn/17/11-17-0989-05-000m-resolutions-for-obsolete-and-repace-comments-d0-1.docx, for

–CID 60 PCO Phased co-existence operation

–CID 66 Strictly Ordered Service Class

Thanks,

Dorothy

----------------------
Dorothy Stanley
Hewlett Packard Enterprise

dorothy.stanley@xxxxxxx
dstanley1389@xxxxxxxxx
+1 630-363-1389

_______________________________________________________________________________

If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.

Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the LEAVE button.

If there is no LEAVE button here, try http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________

IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.