Re: [STDS-802-11-TGM] WNM-Sleep and GTK
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
If the STA doesn't delete the key, when the STA wakes up an attacker
could send very old group addressed frames to that STA. These are not
replays from the STA's point of view, but they may contain data that is
significantly outdated. Yes, all group addressed frames are subject to
some delays under e.g. normal power save rules, but here we're
introducing the possibility that the frames could be hours old (or more?
what's the limit on WNM-Sleep duration again?)
"It is not clear why this is necessary or even advisable."
Necessary? Perhaps not, but it seems advisable to me. Is there any
compelling argument for why it the key shouldn't be deleted?
---
Henry Ptasinski
henry@xxxxxxxxxx
On 11/30/2012 09:55 AM, Robert Stacey wrote:
--- This message came from the IEEE 802.11 Task Group M Technical
Reflector ---
Hello Jouni,
I have a comment in REVmc (CID 329) to remove the requirement that a
non-AP STA delete the GTKSA on entering WMN-Sleep (see below).
Concern was expressed that not deleting the key creates a security
vulnerability. I don't see a vulnerability on the receive side: if the
STA uses an old key (after missing an GTK update) it simply won't be
successfully decrypting group addressed frames. As far as I know the STA
does not use the key to encrypt frames.
Can you comment on this?
Regards,
-Robert
CID Page Clause Resn Status Comment Proposed Change Resolution
Owning Ad-hoc Ad-hoc Status Ad-hoc Notes
329 1005.00 10.2.1.18.2 J "The non-AP STA shall delete the GTKSA if
the response
indicates success." It is not clear why this is necessary or even
advisable. A STA in WNM-Sleep mode does not participate in group key
updates. Fine. But why should it delete the GTKSA? If the current key
expires and a new one is distributed the STA may not get the update, but
that is no reason to prevent it using one that was in effect when it
entered WNM-Sleep mode. Besides, the group key may have a lifetime far
longer than the STA's WNM-Sleep. Delete the following two sentences:
"The non-AP STA shall delete the GTKSA if the response indicates
success. If RSN is used with management frame protection, the non-AP STA
shall delete the IGTKSA if the response indicates success." REJECTED
(MAC: 2012-10-09 18:35:46Z): The non-AP STA deletes the GTK to remove
any possibility of using the expired key. MAC Discuss MAC: 2012-11-14
17:12:09Z - Update. Robert would like to discuss this further. Moving
back to "Discuss" status.
Comment-MAH: Need a security expert's opinion. I am guessing that it
potentially decreases the entropy of the GTK if the sleeping STA
continues to use it, after the key has changed (which the STA didn't
realize).
MAC: 2012-10-05 14:21:37Z - Propose decline. The non-AP STA deletes the
GTK to remove any possibility of using the expired key. Dorothy to
confirm with Jouni.
_______________________________________________________________________________
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.
SELF SERVICE OPTION: Point your Browser to -
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then
amend your subscription on the form provided. If you require removal
from the reflector press the LEAVE button.
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.
SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and
then amend your subscription on the form provided. If you require removal from the reflector
press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________