Re: [STDS-802-11-TGM] WNM-Sleep and GTK
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Thanks Jouni
So... to summarize...
With strict rekeying:
- STAs are vulnerable to attack by other STAs currently associated with the AP
- a STA that doesn't receive GTK updates would also be vulnerable to attack by a STA that triggered an update on leaving the BSS
There is nothing we can do about the former, but to prevent the latter, a STA is required to delete the GTK on entering WNM-Sleep and thus is unable to receive any group-addressed traffic while in WNM-Sleep. This is OK because the STA is expected to establish a good multicast to unicast conversion filter. As a side effect, however, a GTK update is necessary each time a STA leaves WNM-Sleep.
I don't necessarily agree with the tradeoff made here (reduced vulnerability vs always having GTK update on exiting WNM-Sleep), but at least I understand where it came from.
-Robert
On Nov 30, 2012, at 5:30 PM, "Malinen, Jouni" <jouni@xxxxxxxxxxxxxxxx> wrote:
>
>
> On 11/30/12 8:55 AM, "Robert Stacey" <rjstacey@xxxxxxxxx> wrote:
>
>> 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.
>
> It is correct that a properly functioning non-AP STA would not use a GTK
> to encrypt frames. The potential issue here is in the receive side when
> someone else is doing something else than normal behavior.
>
> If a STA maintains an old GTKSA while in WNM-Sleep Mode, there is no
> indication to the STA that the old GTK has been replaced. This is
> undesired especially when strict rekeying is used. Any non-AP STA that is
> associated with an AP can receive the GTKs and as such, has all it takes
> to be able to forge group addressed Data frames to any non-AP STA in the
> BSS. With strict rekeying, this can be limited to the time any STA is
> associated (i.e., GTK will be changed when any STA leaves the BSS). Not
> dropping GTKSA when entering a state where no GTK updates are received
> would extend the time while this type of attack could be performed.
>
> - 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
_______________________________________________________________________________