Re: [STDS-802-11-TGM] WNM-Sleep and GTK

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

On Fri, Nov 30, 2012 at 1:31 PM, Robert Stacey <rjstacey@xxxxxxxxx> wrote:

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Hi Matt,

Regarding implementation complexity, I don't think it is an issue. At a minimum, the AP needs to know which STAs it has distributed a particular key to when it changes the key. It would need to send a series of GTK updates and would need to track the STAs still needing the update. Maintaining the same information over longer periods of time is not beyond reason. A simple heuristic would be to have a flag in the data structure maintained for associated STAs. When the GTK is changed the flag is cleared for all associated STAs and a series of updates sent. STAs in WNM-Sleep are skipped. When a STA in WNM-Sleep exits sleep, the AP checks its state - if flag clear it sends a GTK update. APs that don't want to maintain that state (as an implementation option) could always send an update to STAs exiting sleep, it would just be less efficient.

However, you raise a good point which has to do with backward compatibility. Since we have a published standard that requires a STA to delete the GTK on entering WNM-Sleep we would need some capability indication to determine STA behavior after the change I have proposed. This does not appear to be worth the effort.

So I concede. Until we have a compelling reason to change the standard we should retain the statement.

Dorothy (or Mark) could we retain the REJECTED resolution, but update the reason to "The proposed change would create a new class of devices that are incompatible with the previously published standard (devices that did not delete their GTKSA, while devices conforming to the previous revision did)"? Or something to that effect.

-Robert

On Nov 30, 2012, at 12:41 PM, "Smith, Matt (QCA)" <smithm@xxxxxxxxxxxxxxxx> wrote:

> 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
_______________________________________________________________________________

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.