Re: [STDS-802-11-TGM] WNM-Sleep and GTK
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Robert,
I see your point, but it seems to me that it's increasing the protocol complexity (implementation if not OTA). How does the AP determine whether or not the client exiting WNM-Sleep needs a new key or not (i.e., has deleted its previous key, or not)? Is that part of the protocol? I don't recall, to be honest.
In practice, there are many AP implementations that rotate the GTK based not only on time but also whenever a client leaves the BSS. So, in practice, the periodicity of the GTK rotation is not fixed and likely to happen quite a lot in congested entherprise or hotspot environnments, or even at home as mobile devices come and go from the BSS.
-Matt
On Nov 30, 2012, at 11:14 AM, Robert Stacey <rjstacey@xxxxxxxxx>
wrote:
> --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
>
> I would think all STAs are vulnerable to a replay attack for the lifetime of the key. If the key lifetime is 24 hours and WNM-Sleep is active for minutes to hours, the non-sleeping STAs are more vulnerable (since the are more available to receive group addressed frames.
>
> I would agree with your argument if the sleep period often extended beyond the key expiration time. In practice I think this is unlikely and easily remedied with an update immediately following an exit from sleep.
>
> The argument for not deleting the key is that an update is only required if the key has changed since the STA last received an update. This would reduce the overhead associated with entering and leaving this sleep mode. Also the group key would be distributed less frequently which could only improve security.
>
> -Robert
>
> On Nov 30, 2012, at 9:39 AM, Henry Ptasinski <henry@xxxxxxxxxx> wrote:
>
>> 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
> _______________________________________________________________________________
_______________________________________________________________________________
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
_______________________________________________________________________________