Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 4 Oct 2006 08:20:10 -0700 (PDT)

Hi Dorothy,

----- Original Message ----
From: Dorothy Stanley <[email-masked]>
To: Bob O'Hara (boohara) <[email-masked]>
Cc: Saravanan Govindan <[email-masked]>; Cheng Hong <[email-masked]>; [email-masked]
Sent: Tuesday, October 3, 2006 5:09:55 PM
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Bob, all,

Comments inline.

Thanks,

Dorothy

On 9/29/06, Bob O'Hara (boohara) <[email-masked]> wrote:
 
Again, your proposal does not eliminate any attack mechanism and does not add any functionality to the protocol, only cost and complexity.  A replayed frame will be discarded by the MAC, using the normal duplicate frame detection mechanisms.  See section 8.3.3.3.2 of 802.11i (where the frame sequence number is part of the additional authenticated data) and section 9.2.9 of 802.11-1999 for the description of these functions.  And PLEASE read 802.11 and 802.11i before again asserting that this proposal is necessary.

In Section 8.3.3.3.2, the AAD construction for CCMP  includes the frame sequence control field – and the sequence number, 
bits 4-15 of the frame equence control field - is masked to 0 in the AAD; so that only the fragment number is protected.
The TKIP MIC protects neither the fragment number nor the sequence number of  the 802.11 frame sequence control field, as the TKIP MIC
is MSDU based.

In 9.2.9, Duplicate detection and recovery, the text indicates that a STA may omit 
broadcast/multicast frame data from its duplicate detection cache; if bc/mc data is not included, then normal
duplicate frame detection will not apply.
 As I said several emails ago, the ONLY effect of using zero as the value for the KeyRSC is that the 802.11 chipset in the STA (client) will have to receive the frame, attempt to decrypt it, and validate the MIC.  This must be done for EVERY frame received, whether it is a replayed frame or not.  This set of functions is performed in the 802.11 STA chipset and does not consume any additional resources of the STA.  So, the attack, if it can even be characterized as an attack, is no more effective at DOSing the STA than sending it any other frame.

The MIC calculation, and encrpt/decrypt is typically performed in hardware in the chipset for CCMP.
However, the TKIP MIC calculation is typically performed in the driver, in software.

If a STA does not have the proper RSC value, there is a "window of vulnerability" before it receives
the correct value, during
which the STA can receive and process replayed  bc/mc frames. The magnitude of the DOS aspect of this
depends on the STA crypto implementation - hw/ccmp - virtually no impact or sw/tkip-some small impact.
The larger issue is that the replay protection mechanism guarrantees provided by 802.11i are lost.
--snip
==>
Are you favoring a solution Charles sketched, i.e. WTP sends keyRSC value during authentication/reassociation of each new STA so that AC can use the correct (or close to correct) value in Message 3 of 4-way handshake and Message 1 of group key handshake?
Can you clarify this?

Thanks
Behcet

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Dorothy Stanley" <[email-masked]>
Date: Thu, 5 Oct 2006 08:57:49 -0700

Hi Behcet,

Comment inline below.

Dorothy

On 10/4/06, Behcet Sarikaya <[email-masked]> wrote:
> From: Dorothy Stanley < [email-masked]>
> Cc: Saravanan Govindan < [email-masked]>; Cheng Hong
> < [email-masked]>; [email-masked]
> On 9/29/06, Bob O'Hara (boohara) < [email-masked]> wrote:
> >
> >
> > Again, your proposal does not eliminate any attack mechanism and does
> > not add any functionality to the protocol, only cost and complexity.  A
> > replayed frame will be discarded by the MAC, using the normal duplicate
> > frame detection mechanisms.  See section 8.3.3.3.2 of 802.11i (where the
> > frame sequence number is part of the additional authenticated data) and
> > section 9.2.9 of 802.11-1999 for the description of these functions.
> > And PLEASE read 802.11 and 802.11i before again asserting that this
> > proposal is necessary.
> >
>
> In Section 8.3.3.3.2, the AAD construction for CCMP  includes the frame
> sequence control field – and the sequence number,
> bits 4-15 of the frame equence control field - is masked to 0 in the AAD;
> so that only the fragment number is protected.
>
> The TKIP MIC protects neither the fragment number nor the sequence number
> of  the 802.11 frame sequence control field, as the TKIP MIC
> is MSDU based.
>
>  As I said several emails ago, the ONLY effect of using zero as the value
> for the KeyRSC is that the 802.11 chipset in the STA (client) will have to
> receive the frame, attempt to decrypt it, and validate the MIC.  This must
> be done for EVERY frame received, whether it is a replayed frame or not.
> This set of functions is performed in the 802.11 STA chipset and does not
> consume any additional resources of the STA.  So, the attack, if it can even
> be characterized as an attack, is no more effective at DOSing the STA than
> sending it any other frame.
>
> Are you favoring a solution Charles sketched, i.e. WTP sends keyRSC value
> during authentication/reassociation of each new STA so that AC can use the
> correct (or close to correct) value in Message 3 of 4-way handshake and
> Message 1 of group key handshake?
>
> Can you clarify this?
>
It seems that there are three categories of solutions being discussed:
(a) Those that remove the possibility of replayed frames - ideal, but
alternatives on the table are viewed as too complex and introduce time
constraints.
(b) Those that reduce the number of previously sent bc/mc frames that can be
replayed - less than ideal, but less complex.
(c) Those that allow any previously sent bc/mc frame with a given GTK to be
replayed.

If asked to select between (b) and (c), I would favor a (b) category
solution over a (c) category solution.

 Thanks