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

From: "Cheng Hong" <[email-masked]>
Date: Mon, 2 Oct 2006 13:36:07 +0800

Hi Bob,
 
Let's get this straight again, hopefully, it is the last time. We have
been deviated from the real technical issue by your non-technical
comments too many times. And, by the way, they are not funny at all :)
 
No one is asking for assistance of protocol design from you or Cisco as
a commercial entity. The question was raised since you claim that your
proposal is workable, and should be adopted by the CAPWAP WG into the
protocol design. Shouldn't any member of this WG demand a bit more
information to justify your assertion? I think as a veteran of
standardization, you should know this better than anyone else ?!
 
If you plainly refuse to provide any information on that, please stop
talking again like "xxx products works fine like this, and there is no
problem", since it is simply not verifiable. 
 
cheers
 
Cheng Hong

  _____  

From: Bob O'Hara (boohara) [mailto:[email-masked]] 
Sent: Saturday, September 30, 2006 12:10 AM
To: Cheng Hong; Dorothy Stanley
Cc: Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);
[email-masked]; Saravanan Govindan
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations

I am afraid that requesting design assistance from a competitor is very
close to violation of U.S anti-trust laws.  I will not describe how
Cisco has designed any of its products and I cannot help you design
yours.
 
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.
 
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.

 -Bob

  _____  

From: Cheng Hong [mailto:[email-masked]] 
Sent: Thursday, September 28, 2006 5:34 PM
To: Bob O'Hara (boohara); Dorothy Stanley
Cc: Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);
[email-masked]; Saravanan Govindan
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Hi Bob,
 
As Dorothy correctly pointed out below, setting the KeyRSC to a value
closer to the current RSC would be better than setting it to a
pre-defined value zero. 
 
It is true that 802.11i and 802.1X do not specify what is the KeyRSC
value to be used, since they are trying to provide us a tool to
correctly synchronize the RSC using the Msg 3. By mandating the KeyRSC
to zero, we are just disabling the tool. It is not wrong, but just
deprives the system a designed function.
 
As for the effectiveness of KeyRSC, setting it to a predefined value of
0 would pose a greater threat. In a simple example, if the RSC is
currently 1000, and we are mandating the KeyRSC to be always zero, the
attacker basically can safely replay the last 1000 packets to the STA
without being detected. If the KeyRSC can be set to a closer value of
the current RSC, say, 900, the number of possible replayed packets can
be reduced to 10 percent, 100 packets. 
 
Therefore, I would say, setting the KeyRSC value to zero does place a
bigger threat. Is that how the cisco products implemented? Maybe you
could share with us some other implementation/testing data to prove
otherwise. Or, you have some other considerations that could defend the
replay attack?
 
cheers
 
Cheng Hong

  _____  

From: Bob O'Hara (boohara) [mailto:[email-masked]] 
Sent: Friday, September 29, 2006 5:21 AM
To: Dorothy Stanley
Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson
J (LI/EAB); [email-masked]
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Dorothy,
 
The problem with this proposal is that it is no more effective than
sending a value of zero for the KeyRSC.  It doesn't eliminate any
potential attacks.  It doesn't add any functionality.  However, it does
add cost and complexity to the protocol.  

 -Bob

  _____  

From: Dorothy Stanley [mailto:[email-masked]] 
Sent: Thursday, September 28, 2006 1:17 PM
To: Bob O'Hara (boohara)
Cc: Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson
J (LI/EAB); [email-masked]
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

All,

Below is the text from 802.11REV-maD8.0 Clause 8.5.2, describing the Key
RSC field.:

"g) Key RSC. This field is 8 octets in length. It contains the receive
sequence counter (RSC) for the
GTK being installed in IEEE 802.11. It is used in Message 3 of the 4-Way
Handshake and
Message 1 of the Group Key Handshake, where it is used to synchronize
the IEEE 802.11 replay
state. It may also be used in the Michael MIC Failure Report frame, to
report the TSC field value of
the frame experiencing a MIC failure. It shall contain 0 in other
messages. The Key RSC field gives
the current message number for the GTK, to allow a STA to identify
replayed MPDUs. If the Key
RSC field value is less than 8 octets in length, the remaining octets
shall be set to 0. The least significant
octet of the TSC or PN should be in the first octet of the Key RSC
field."

The intent of adding this value in message 3 was to immediately minimize
the number of 
replayed frames that a STA would potentially process: "The Key RSC field
gives
the current message number for the GTK, to allow a STA to identify
replayed MPDUs."
Setting the value to 0 in Msg 3 does not provide the current sequence
counter (in most cases
not even close) of the GTK..

Perhaps the WTP could periodically/frequently notify the AC of its
current GTK sequence counter, and the
AC would use the most recently received value in the message 3 sent to
new STAs. The RSC value
would not be  up to date at all times, but would be closer than "0", not
require an "in-the-critical-path
message exchange between the AC and WTP, and still be close to the
intended use of the field.

Dorothy

On 9/28/06, Bob O'Hara (boohara) <[email-masked]> wrote: 

Please understand that 802.11i specifies no behavior in this area for
the 802.1X authenticator.  Our choice to send a group key KeyRSC value
of zero in the EAPOL-key frame requires no change to 802.11i or to
802.1X .  It requires us to state this in the CAPWAP spec, if we want
this behavior to be consistent across all implementations.

The problem with what Bechet and Saranavan are asking is that either of
three different things are required: 
1: the WTP must communicate the group key TSC to the AC every time it is
updated, or
2: the AC must request the current value of the group key TSC for the
KeyRSC before constructing the EAPOL-key frame, or
3: the AC must send the KCK to the AC so  that it can insert the KeyRSC
value and also calculate the correct MIC, inserting that into the proper
EAPOL-key frame.

The first item requires a tremendous amount of additional CAPWAP 
communication between WTP and AC, at least one new CAPWAP packet for
every multicast frame sent by the WTP, if the packet is not
acknowledged, or two new CAPWAP packets, if it is acknowledged.  This is
a very expensive addition to the protocol. 

The second item requires new protocol between the AC and WTP during what
can be a time critical portion of the 802.11 transition (handoff, roam)
from one WTP to another.  It also introduces a race condition that is 
not present in the protocol today.  Once the value for the KeyRSC is
sent from the WTP to the AC, it is possible that the WTP can send
another multicast frame encrypted with the group key.  This puts the
value of the sequence counter out of sync with the value that will be 
shortly communicated to the client in the EAPOL-key frame from the AC.
This will behave exactly the same as if a value of zero is sent in the
EAPOL-key frame.

The third item requires a new architecture split that is not required in

our objectives.  The new split is not splitting the MAC, but splitting
the authenticator.  Placing the KCK in the WTP is also a potential
reduction in the security of the overall WLAN system, since these
devices are normally not in a secured wiring closet, but exposed and 
more easily compromised than the AC.

The simplest to implement, least expensive, and most secure option is to
use the protocol as it is now specified and have the AC send a value of
zero in the KeyRSC field of the EAPOL-key frame. 

-Bob

-----Original Message-----
From: Cheng Hong [mailto:[email-masked]]
Sent: Wednesday, September 27, 2006 6:50 PM
To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; 
Peter Nilsson J (LI/EAB)
Cc: [email-masked]
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Hi Pat and all,

So, based on this, I would say that we have consensus that setting the 
correct KeyRSC is an issue for the CAPWAP protocol design.

So far, we have three option/solutions:

1) As proposed by Bob: Using a static value (0) for the KeyRSC.

2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP 

3) As suggested by Saravanana: Some exchange mechanism between WTP and
AC

Among the three, the first option seems the easiest. However, it
requires a mandated Authenticator behavior(in this case AC) that is not 
mandated by 802.11. Therefore, we have to specify that (e.g. as proposed
by Bob: "We could include a note to the effect that the group KeyRSC
should be zero in the EAPOL-key frame.") either in CAPWAP or 802.11,
because otherwise there is no interoperability. For example, AC provided
by another vendor does not have to set KeyRSC to 0 to be compliant with
CAPWAP and 802.11i.

Another implication is that we don't really understand the impact of 
mandating a static KeyRSC value. Although Bob provided an excellent
analysis, I still have some doubts about the profoundness of the impact.
If the KeyRSC value is as described of no use, why would it appear in
the EAPOL frames in the first place? By mandating it to static value,
what have we lost? Maybe some liaison letter to 802.1 or 802.11 could
provide us a better understanding of the issue.

For the last two options, I think they are both within CAPWAP's scope. 
Further analysis could help us to decide which one  is better (or
someone could propose other solutions).

cheers

Cheng Hong

> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto: [email-masked]]
> Sent: Thursday, September 28, 2006 1:39 AM
> To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy;
> Peter Nilsson J (LI/EAB)
> Cc: [email-masked]
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> Considerations
>
> Bob's point is 802.11i works this way today. The AP (or in 
> this case AC) can set the RSC to whatever value it wishes.
> Bob used zero (0) as an example. Implementations could use
> any other value, which would require some form of
> communication to the WTP, as suggested by Behcet. 
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
> > -----Original Message-----
> > From: Cheng Hong [mailto:  <mailto:[email-masked]>
[email-masked]]
> > Sent: Tuesday, September 26, 2006 6:03 PM
> > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson
> J (LI/EAB)
> > Cc: [email-masked]
> > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > Considerations
> >
> > Hi Bob,
> >
> > If I understand your description below correct, you are proposing a 
> > solution (to the problem pointed out by
> > Saravanan) by mandating the behavior of the AC to always set the
> > KeyRSC in the 4-way handshake to zero.
> >
> > This is not a defined behavior according to the current 
> > 802.11 standard.
> > Are you suggesting that we CAPWAP WG should specifically
> mandate that
> > in our CAPWAP protocol spec, e.g. something like "a CAPWAP
> compatible
> > AC MUST set KeyRSC to zero"? Otherwise, the problem still exists,
> > since not all AC implementation have to follow what you described.
> >
> > Or, are you planning to take this issue to TGm for 802.11 standard
> > revision? (since based on your description, there is essentially no
> > use of the KeyRSC).
> >
> > cheers
> >
> > Cheng Hong
> >
> > 
> >
> >
> > > -----Original Message-----
> > > From: Bob O'Hara (boohara) [mailto:[email-masked]]
> > > Sent: Wednesday, September 27, 2006 2:32 AM 
> > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB)
> > > Cc: [email-masked]
> > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i 
> > > Considerations
> > >
> > > Charles, Peter,
> > >
> > > Below is an expansion of a snippet from a thread on this
> > topic that I
> > > sent to the list on July 25, 2006.  I think this will be 
> helpful to
> > > understand why the exchange that Saranavan is requesting is not
> > > necessary.  In fact, there are several systems from several
> > > manufacturers in the field using precursor protocols to 
> CAPWAP that
> > > are Wi-Fi certified for WPA2/802.11i operation using the
> > protocol as
> > > it is described below.
> > >
> > > BTW, this whole discussion is about the KeyRSC for the 
> > group key, not
> > > the pairwise key.  This is so because the WTP and AC both
> know the
> > > initial sequence counter value for the pairwise key, since it has
> > > never been used to send a frame.   802.11i requires the
> first frame
> > > sent on a key to use the sequence counter value of 1.  See
> > 8.3.2.6 c)
> > > and
> > > 8.3.3.4.3 c) in 802.11i for this requirement.
> > >
> > > The same is not true of the group key, i.e., after the WTP begins
> > > operation, the AC will not know the value of the sequence
> > counter for 
> > > the group key when it needs to complete the EAPOL-key
> > handshake with a
> > > newly associated STA.
> > > However, as you will see from the tutorial below, it is not
> > necessary
> > > for the AC and WTP to exchange any information about the
> group key
> > > KeyRSC for the protocol to operate as it is intended.
> > >
> > > 1. A value for the KeyRSC in the EAPOL-key frame is necessary to 
> > > calculate the KeyMIC.
> > >
> > > 2. This value does not need to bear any specific
> > relationship to the
> > > RSC value maintained by the WTP.  A value of zero in the 
> EAPOL-key
> > > frame for the group key will always work.
> > >
> > > 3. The client STA will use the value of KeyRSC received in the
> > > EAPOL-key frame to validate frame using the KeyMIC. 
> > >
> > > 4. The client STA will also set its group key RSC to the value
> > > received in KeyRSC, say, zero.
> > >
> > > 5. The value in the client STA's RSC will be compared against the 
> > > sequence number in subsequent received frames to identify replay
> > > attacks.  Any frame received with a sequence counter value
> > within the
> > > replay window will be checked to have a valid MIC.  If the 
> > MIC is not
> > > valid, the frame is dropped.
> > >
> > > 6. For any frame that is determined not to be a replay
> attack frame
> > > and meets all other validity and authenticity requirements, 
> > the client
> > > STA updates its RSC value to the sequence number in the received
> > > frame, if the value is greater than its current RSC value.
> > Only the
> > > AP can meet these criteria as the source of a frame 
> received by the
> > > STA.
> > >
> > > 7. Please see item 6, immediately above, for the reason
> that the AC
> > > and WTP do not need to coordinate and exchange the RSC. 
> > >
> > >
> > > The only possible attack mode is for the attacker to send
> frames to
> > > the client STA between the time of the EAPOL-key frame and
> > the first 
> > > frame encrypted with the group key.
> > > During this time, the client will receive the frame and
> proceed to
> > > validate its MIC.  This is a potential attack against the STA 
> > > resources.  But, the MIC validation is done in the STA's
> > > 802.11 chip and consumes no more resources than receiving
> any other
> > > frame.  Thus, the attack does not actually consume any STA 
> > resources
> > > beyond those of receiving a frame.
> > >
> > > This attack is not unique to the use of the value zero for
> > the KeyRSC,
> > > either.  The same attack is available to an attacker at any other 
> > > time, as well.  It is no more nor less effective at either time.
> > >
> > > For these reasons, the protocol is not in need of any changes to
> > > address the issue raised by Saranavan. 
> > >
> > >  -Bob
> > > -----Original Message-----
> > > From: T. Charles Clancy [mailto:[email-masked]]
> > > Sent: Monday, September 25, 2006 11:37 AM 
> > > To: Peter Nilsson J (LI/EAB)
> > > Cc: [email-masked]
> > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations 
> > >
> > > This is a very interesting solution.  The AC selects the
> KeyRSC and
> > > performs the 4-way handshake.  The WTP sniffs the 4-way handshake
> > > traffic and grabs the KeyRSC value and uses it to 
> > initialize its own
> > > counter.
> > >
> > > Pat/Bob: Is this how the Cisco implementation works?  I
> > have to agree
> > > with Saravanan that I've yet to see a technical 
> description of how
> > > Cisco implements it.
> > >
> > > IMHO, this is somewhat hackish, and it would be cleaner to
> > have the AC
> > > generate the KeyRSC and include it in the AddMobile message 
> > as Behcet
> > > suggests.
> > >
> > > --
> > > t. charles clancy, ph.d.  |  [email-masked]  |
> www.cs.umd.edu/~clancy
> > >
> > > On Mon, 25 Sep 2006, Peter Nilsson J (LI/EAB) wrote:
> > >
> > > > I think Saravanan has a point. We did a prototype
> > impelementation of 
> > > the
> > > > protocol a year ago when it was still called LWAPP. The way
> > > we solved
> > > > this issue then was to let the WTP sniff on all CAPWAP data
> > > messages 
> > > > from the AC and when message 3 of the 4-way handshake or
> > > message 1 of
> > > > the groupkey handshake was sent the WTP inserted the correct RSC
> > > before 
> > > > sending it off to the supplicant. To avoid the sniffing on
> > > all CAPWAP
> > > > data messages we would need a mechanism with in CAPWAP to
> > > handle these 
> > > > two messages.
> > > >
> > > > Peter Nilsson
> > > >
> > > > -----Original Message-----
> > > > From: Saravanan Govindan
> > > [mailto:[email-masked]]
> > > > Sent: den 22 september 2006 11:03
> > > > To: Margaret Wasserman
> > > > Cc: [email-masked]
> > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > > >
> > > > Hi Margaret,
> > > >
> > > > Thank you for reviewing the discussion on this issue.
> > > >
> > > > The issue here is the working of IEEE 802.11i when the 802.11i
> > > > authenticator element is at the AC and the 802.11i crypto
> > element is
> > > at
> > > > the WTP. Particularly, it is for the 4-way handshake between 
> > > > authenticator and supplicant.
> > > >
> > > > Now, the 4-way handshake requires knowing the value of
> > > KeyRSC sequence
> > > > counter. The KeyRSC helps both authenticator and supplicant 
> > > keep track
> > > > of their exchanges. It serves to protect against threats by
> > > tracking
> > > > sequential frames. The KeyRSC is maintained at the at the
> > point of
> > > > encryption, i.e. just before transmission over the
> > wireless channel.
> > > >
> > > > In the case of CAPWAP, the 4-way handshake is between the AC 
> > > > (authenticator) and the wireless station (supplicant).
> > > >
> > > > The problem arises, when the authenticator is at the AC and
> > > the crypto
> > > > element (together with KeyRSC) is at the WTP. This is a 
> > > fairly common
> > > > design. Now in this case, the AC starts the 4-way
> handshake but it
> > > does
> > > > not know the value of the KeyRSC. The KeyRSC is maintained 
> > > by the WTP.
> > > >
> > > > Based on this, the current CAPWAP specification does not
> > allow for a
> > > way
> > > > to conduct the 4-way handshake with the correct KeyRSC. 
> > > >
> > > > The functionality I would like to see is a way for the
> > authenticator
> > > > (AC) to use the correct prevailing value of KeyRSC
> > > (maintained by the 
> > > > WTP) in its 4-way handshake.
> > > >
> > > > One way to introduce this functionality in to CAPWAP is
> > to have part
> > > of
> > > > the 4-way handshake be sent from AC to WTP. This will allow 
> > > the 4-way
> > > > handshake to use the correct value of the KeyRSC before
> > > being sent to
> > > > the wireless station.
> > > >
> > > > I hope this helps clarify my view on the issue. 
> > > >
> > > > Cheers,
> > > >
> > > > Saravanan
> > > >
> > > >
> > > >
> > > >
> > > > 
> > > >
> > > > -----Original Message-----
> > > > From: Margaret Wasserman [mailto:[email-masked]]
> > > > Sent: Thursday, September 21, 2006 8:26 PM 
> > > > To: Saravanan Govindan
> > > > Cc: Pat Calhoun (pacalhou); [email-masked]
> > > > Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
> > > Considerations
> > > >
> > > >
> > > >
> > > > Hi again,
> > > >
> > > > Okay, I am even more confused than I thought I was... 
> > > >
> > > > Saravanan, you wrote:
> > > >
> > > > On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote:
> > > >
> > > >> Pat, 
> > > >>
> > > >> The issue here is about how 802.11i exchanges are done when
> > > >> authenticator is at the AC and crypto elements are at
> > the WTP. This 
> > > is
> > > >> the requirement.
> > > >
> > > > And, in response, Pat Calhoun wrote:
> > > >
> > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote: 
> > > >> The current specification allows the authenticator to
> > > reside in the
> > > >> AC, while the data packet crypto elements in the WTP. This
> > > feature is 
> > > >> already in the specification.
> > > >
> > > > Pat's message matches my reading of the specification.
> > > >
> > > > So, Saravanan, what functionality are you asking for 
> that is not
> > > > already supported by the specification?  And why do you
> > think it is
> > > > necessary?  it will not be helpful to my understanding to
> > > re-send your 
> > > > proposal or to cite the requirements document...  Please
> > summarize
> > > > what functionality you think is missing from the current
> > > specification
> > > > and why you think that functionality is necessary to 
> support IEEE
> > > > 802.11i or any important use case.
> > > >
> > > > At some point, the chairs may need to make a consensus
> > call on this
> > > > issue, and I'd like to understand your view and make sure 
> > > that it has
> > > > been clearly communicated to the WG before we ask the WG to
> > > decide on
> > > > this issue.
> > > >
> > > > Thanks, 
> > > > Margaret
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> _________________________________________________________________ 
> > > > To unsubscribe or modify your subscription options,
> please visit:
> > > > http://lists.frascone.com/mailman/listinfo/capwap
<http://lists.frascone.com/mailman/listinfo/capwap> 
> > > >
> > > > Archives: http://lists.frascone.com/pipermail/capwap
> > > >
> _________________________________________________________________ 
> > > > To unsubscribe or modify your subscription options,
> please visit:
> > > > http://lists.frascone.com/mailman/listinfo/capwap
<http://lists.frascone.com/mailman/listinfo/capwap> 
> > > >
> > > > Archives: http://lists.frascone.com/pipermail/capwap
> > > >
> > > _________________________________________________________________ 
> > > To unsubscribe or modify your subscription options, please visit:
> > > http://lists.frascone.com/mailman/listinfo/capwap
> > > 
> > > Archives: http://lists.frascone.com/pipermail/capwap
> > > _________________________________________________________________
> > > To unsubscribe or modify your subscription options, please visit: 
> > > http://lists.frascone.com/mailman/listinfo/capwap
> > >
> > > Archives: http://lists.frascone.com/pipermail/capwap
> > >
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit: 
> > http://lists.frascone.com/mailman/listinfo/capwap
> >
> > Archives: http://lists.frascone.com/pipermail/capwap
<http://lists.frascone.com/pipermail/capwap> 
> >
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________ 
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

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

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

---

From: "Saravanan Govindan" <[email-masked]>
Date: Mon, 2 Oct 2006 14:53:01 +0800

Hi Mike,

Regarding Section 11.3, I think the GTK update procedure has to reflect
the KeyRSC step. I will send text shortly for the WG's consideration.

Cheers,

Saravanan

 

________________________________

From: Michael Montemurro [mailto:[email-masked]] 
Sent: Friday, September 29, 2006 7:41 AM
To: Bob O'Hara (boohara)
Cc: [email-masked]; Cheng Hong
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Bob and all interested parties,

In the last round of edits, I updated Section 11.3 to describe the GTK
update procedure. I thought that it lines up pretty well with what's in
IEEE 802.11i (and implementations of IEEE 802.11i that I am aware of).

Could someone make recommendations on how you think this section should
be updated?

Thanks,

Mike

Dorothy,

 -Bob

________________________________

 

All,

Dorothy

On 9/28/06, Bob O'Hara (boohara) <[email-masked] > wrote: 

-Bob

-----Original Message-----
From: Cheng Hong [mailto:[email-masked] ]
Sent: Wednesday, September 27, 2006 6:50 PM
To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; 
Peter Nilsson J (LI/EAB)
Cc: [email-masked]

Hi Pat and all,

cheers

Cheng Hong

> > From: Cheng Hong [mailto: [email-masked]
<mailto:[email-masked]> ]
> > > From: Bob O'Hara (boohara) [mailto: [email-masked]
<mailto:[email-masked]> ]
> > 8.3.2.6 <http://8.3.2.6/>  c)
> > > and
> > > From: T. Charles Clancy [mailto: [email-masked]
<mailto:[email-masked]> ]
> > > [mailto: [email-masked]
<mailto:[email-masked]> ]
> > > > From: Margaret Wasserman [mailto: [email-masked]
<mailto:[email-masked]> ]

---

From: "Cheng Hong" <[email-masked]>
Date: Tue, 3 Oct 2006 09:49:15 +0800

Dear all,

Some comments below:

cheers

Cheng Hong

> Bob>> I don't believe that this increases the risk of replay attack.
> The risk of attack is related to the presence of an attacker 
> and the time between the 4-way handshake and the next 
> multicast frame transmitted by the AP.  As long as the 
> possibility exists that the KeyRSC does not match the actual 
> TSC, this attack is feasible.

As already discussed in previous emails, unless the KeyRSC follows the
exact RSC value, there could be possible replay attacks. However,
setting the KeyRSC to a static value does make things worse, since it
opens the possibility for the attacker to replay any previous frames.
Repeat the same example: Setting KeyRSC to 0 allows 1000 frames to be
replayed, and setting KeyRSC to a value close to 1000, say 900, will
reduce the possible replay frames to 100. 

The risk is not measured with the "time between the 4-way handshake and
the next multicast frame transmitted by the AP". By looking at the sheer
number of possible replayed frames, the risk is increased by setting
KeyRSC to a static value 0.

> Bob>> It should be noted that "replay" of encrypted/MICed multicast
> frames is inherent in the design of an 802.11 WLAN that has 
> more than one AP in it.  Because the load and availability of 
> transmit opportunities varies with time, location, and 
> channel, it is likely that the STA will encounter a situation 
> where it has received one or more multicast frames from one 
> AP that it will receive again from a second AP that it has 
> just roamed to.  The multicast frames at the second AP have 
> been delayed due to that AP having fewer opportunities to 
> transmit, resulting in longer queuing delays for the first 
> transmission of those multicast frames. 

As already pointed out in several emails, the RSC is maintained per
GTKSA. So, if the different APs are using different GTK, different RSCs
will be used. Not issue exists, since the frames from different APs are
checked against different TSC space (suppose TKIP is used as stated in
clause 8.3.2.6).  

Even in the case that all the APs are sharing the same GTK, the
procedure defined in clause 8.3.2.6 will be carried out at STA.
Duplicated frames will be dropped. There is no place showing the
"replay" is "inherent in the design of an 802.11 WLAN that has more than
one AP in it". 

> Sent: Tuesday, October 03, 2006 12:37 AM
> To: Charles Clancy; Margaret Wasserman
> Cc: [email-masked]
> Charles, 
> Please see my comments below.
> 
>  -Bob
>  
> From: Charles Clancy [mailto:[email-masked]]
> Sent: Saturday, September 30, 2006 4:11 PM
> To: Margaret Wasserman
> Cc: [email-masked]
> I've reread the thread and reread the relevent portions of 
> 11i.  I think my statements before were partially inaccurate. 
>  The security and overhead ramifications are not insignificant.
> 
> We can:
> 
> 1. Set the KeyRSC to a static value.  This increases the risk 
> of replay attacks of multicast/broadcast packets encrypted 
> with the group key between the time the client authenticates 
> and when the first legitimate group key-encrypted packet is 
> transmitted.
> 
> Bob>> I don't believe that this increases the risk of replay attack.
> The risk of attack is related to the presence of an attacker 
> and the time between the 4-way handshake and the next 
> multicast frame transmitted by the AP.  As long as the 
> possibility exists that the KeyRSC does not match the actual 
> TSC, this attack is feasible.
> 
> Bob>> It should be noted that "replay" of encrypted/MICed multicast
> frames is inherent in the design of an 802.11 WLAN that has 
> more than one AP in it.  Because the load and availability of 
> transmit opportunities varies with time, location, and 
> channel, it is likely that the STA will encounter a situation 
> where it has received one or more multicast frames from one 
> AP that it will receive again from a second AP that it has 
> just roamed to.  The multicast frames at the second AP have 
> been delayed due to that AP having fewer opportunities to 
> transmit, resulting in longer queuing delays for the first 
> transmission of those multicast frames. 
> 
> 2. Periodically transmit the KeyRSC from the WTP to the AC.  
> This would allow for fewer packets to be replayed, but would 
> not completely prevent replay attacks.  Probabalistically, it 
> would weaken their effectiveness.
> 
> The added price is more protocol overhead.
> 
> 3. Have the WTP request the GTK prior to initiating the 4-way 
> handshake.
> 
> This would eliminate replay attacks, but add one round trip 
> to the authentication process.  This could possibly be 
> optimized by having the WTP detect EAPOL message 1 being sent 
> to the STA, and immediately transmit it to the AC before it 
> needs it for EAPOL message 3.
> 
> Bob>> The WTP already has the GTK, if it has any STAs 
> associated.  There
> is no need for it to request it from the AC.  I am not sure 
> what this would accomplish.
> 
> Transporting the KCK to the WTP breaks the security model, 
> and should not be considered a viable option.
> 
> Bob>> Agreed.
> 
> None of the approaches affect the STA operation, or require 
> any changes to 802.11.
> 
> Bob>> Agreed.
> 
> Here's a question: what happens if the newly authenticated 
> STA tries to transmit a GTK-encrypted packet using RSC=0?  
> Would it get dropped?  Is this a problem, particularly for 
> protocols such as DHCP?
> 
> Bob>> The STA cannot transmit on the GTK, this is not allowed 
> by 802.11.
> Any frame sent to a multicast destination in 802.11 by an 
> associated STA must be sent directly to the AP, encrypted on 
> the PTK, where it is then decrypted and forwarded (both to 
> the wire and to the BSS encrypted on the GTK) as a multicast 
> frame.  Only the frame from the AP will be encrypted on the 
> GTK.  All STAs are required to drop any frames addressed to 
> them that are not sent from the AP, when associated to an AP. 
>  This is done prior to checking MIC or decrypting the frame.
> 
> --
> t. charles clancy, ph.d.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy
> 
> On Sat, September 30, 2006 12:00 pm, Margaret Wasserman wrote:
> >
> >
> > Could one of you explain to me what the implications would 
> be of the 
> > AC always using an RSC value of 0 to compute the MIC in 
> message 3 of 
> > the 4-way handshake?
> >
> > Would this reduce/eliminate the value of the RSC as a security 
> > mechanism?  Does it imply something about how the WTP needs 
> to behave?  
> > Something about how the supplicant needs to behave?
> >
> > Thanks,
> > Margaret
> >
> >
> > On Sep 29, 2006, at 4:43 PM, Pat Calhoun (pacalhou) wrote:
> >
> >> To be fair, one option requires that message 3 be created, and 
> >> encrypted, in the WTP. This implies that encryption and
> authentication
> >> keys required to formulate message 3 be sent to the WTP.
> >>
> >> Seems to me simpler to include text that either states the 
> value of 
> >> zero is always used (simplest), or some configurable value 
> be sent to 
> >> the WTP (simpler).
> >>
> >> Pat Calhoun
> >> CTO, Wireless Networking Business Unit Cisco Systems
> >>
> >>
> >>
> >>> Sent: Friday, September 29, 2006 12:07 PM
> >>> To: Cheng Hong
> >>> Cc: Bob O'Hara (boohara); Dorothy Stanley; Pat Calhoun
> >>> (pacalhou); Peter Nilsson J (LI/EAB); [email-masked];
> >>> Saravanan Govindan
> >>> I'm glad to see we're finally arguing about the right issue.
> >>> As discussed, the Cisco solution to the problem is "set 
> it to zero".
> >>> Certainly sniffing the value works as well.  From a security
> >>> standpoint either is just fine.
> >>>
> >>> We do have an interoperability issue, however, if a Cisco WTP
> >>> were used with an AC that's randomly generating a KeyRSC and
> >>> expecting the WTP to sniff it.  So, I think some text is
> >>> necessary to address the issue.
> >>>
> >>> What remains are two entrenched opinions about protocol
> >>> flexibility vs simplicity, neither of which would
> >>> significantly tilt the flexibility vs simplicity balance in
> >>> either of direction.  Let's flip a coin and move on to more
> >>> important issues.
> >>>
> >>> --
> >>> On Fri, 29 Sep 2006, Cheng Hong wrote:
> >>>
> >>>> Hi Bob,
> >>>>

---

From: "Cheng Hong" <[email-masked]>
Date: Tue, 3 Oct 2006 10:19:19 +0800

Now to address technical portion of your comment:

[[Cheng Hong]] The mechanism defined in 802.11i detects the replay frame
if the frame contains a sequence number out of order. However, if the
KeyRSC has been set to 0, it means the initial RSC at the STA is forced
to be 0 when it joins the BSS. This makes the STA to take any received
frame as a valid frame since the sequence is in order. So, if the
attacker replay frames with sequence in order, the STA has no way to
detect that, until a frame of higher sequence order is received
(supposedly by the actual AP instead of another attacker).

[[Cheng Hong]]  As commented above, the risk of setting the KeyRSC to 0
is to allow those replay frames to pass 802.11 chipset replay check
procedures, and left the detection of the replay to higher layer, and it
obviously poses higher DOS threats to the STA. Setting KeyRSC to a value
closer to RSC will allow the replay being detected earlier, and reduces
the possible DOS attack frames.

 -Bob

  _____  

Hi Bob,

 

cheers
 
Cheng Hong

  _____  

Dorothy,

 -Bob

  _____  

All,

Dorothy

-Bob

-----Original Message-----
From: Cheng Hong [mailto:[email-masked]]
Sent: Wednesday, September 27, 2006 6:50 PM
To: Pat Calhoun (pacalhou); Bob O'Hara (boohara); T. Charles Clancy; 
Peter Nilsson J (LI/EAB)
Cc: [email-masked]

Hi Pat and all,

cheers

Cheng Hong

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Tue, 3 Oct 2006 08:54:02 -0700

Charles said:
If the consensus is to use RSC=0, then I think a disclaimer statement
should be added to the security considerations section about the replay
possibility in multicast protocols.  Overall this is probably
sufficient.

Bob>> I agree.

 -Bob

---

From: "Dorothy Stanley" <[email-masked]>
Date: Tue, 3 Oct 2006 15:09:55 -0700

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.

>  -Bob
>
>
>
>  ------------------------------
> *From:* Cheng Hong [mailto:[email-masked]]
> *Sent:* Thursday, September 28, 2006 5:34 PM
> *To:* Bob O'Hara (boohara); Dorothy Stanley
> *Cc:* Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);
> *Subject:* RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations
>
>  Hi Bob,
>
> closer to the current RSC would be better than setting it to a pre-defined
> value zero.
>
> It is true that 802.11i and 802.1X do not specify what is the KeyRSC value
> to be used, since they are trying to provide us a tool to correctly
> synchronize the RSC using the Msg 3. By mandating the KeyRSC to zero, we are
> just disabling the tool. It is not wrong, but just deprives the system a
> designed function.
>
> As for the effectiveness of KeyRSC, setting it to a predefined value of 0
> would pose a greater threat. In a simple example, if the RSC is currently
> 1000, and we are mandating the KeyRSC to be always zero, the attacker
> basically can safely replay the last 1000 packets to the STA without being
> detected. If the KeyRSC can be set to a closer value of the current RSC,
> say, 900, the number of possible replayed packets can be reduced to 10
> percent, 100 packets.
>
> bigger threat. Is that how the cisco products implemented? Maybe you could
> share with us some other implementation/testing data to prove otherwise. Or,
> you have some other considerations that could defend the replay attack?
>
> cheers
>
> Cheng Hong
>
>
>  ------------------------------
> *From:* Bob O'Hara (boohara) [mailto:[email-masked]]
> *Sent:* Friday, September 29, 2006 5:21 AM
> *To:* Dorothy Stanley
> *Cc:* Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson
> *Subject:* RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations
>
>  Dorothy,
>
> sending a value of zero for the KeyRSC.  It doesn't eliminate any potential
> attacks.  It doesn't add any functionality.  However, it does add cost and
> complexity to the protocol.
>
>  -Bob
>
>
>
>  ------------------------------
> *From:* Dorothy Stanley [mailto:[email-masked]]
> *Sent:* Thursday, September 28, 2006 1:17 PM
> *To:* Bob O'Hara (boohara)
> *Cc:* Cheng Hong; Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson
> *Subject:* Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations
>
> All,
>
> Message 1 of the Group Key Handshake, where it is used to synchronize the
> IEEE 802.11 replay
> octet of the TSC or PN should be in the first octet of the Key RSC field."
>
> Perhaps the WTP could periodically/frequently notify the AC of its current
> GTK sequence counter, and the
> AC would use the most recently received value in the message 3 sent to new
> STAs. The RSC value
> > > > From: Cheng Hong [mailto: [email-masked]]
> > > www.cs.umd.edu/~clancy <http://www.cs.umd.edu/%7Eclancy>
> > > > >

---

From: "Cheng Hong" <[email-masked]>
Date: Wed, 4 Oct 2006 09:42:03 +0800

Dear all,

We have been dragged into the discussion of the virtue of KeyRSC value
(which should have been done in IEEE802.1 & 11i - a liaison to ask those
experts why the KeyRSC is incorporated into their protocol in the first
place), and the real problem about the CAPWAP protocol design has been
put aside. 

So, is the conclusion now about demanding all CAPWAP compliant AC to
always set KeyRSC to zero? (This is about the interoperability of the
CAPWAP devices.) Is this the consensus of the WG? 

Will the disclaimer clearly state that by setting KeyRSC to zero the
replay mechanism provided by 802.11i will be turned off and possible
replay possibility has been increased?

cheers

Cheng Hong

> Sent: Tuesday, October 03, 2006 8:05 PM
> To: Charles Clancy
> Cc: [email-masked]
> Hi Charles,
> <chair hat=off>
> > should be added to the security considerations section about the 
> > replay possibility in multicast protocols.  Overall this is 
> probably 
> > sufficient.
> 
> This does seem like the simplest approach.  So, if there is 
> no objection from our security advisors (you and Scott 
> Kelly), then I'm for it.
> 
> </chair>
> 
> Margaret
>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 5 Oct 2006 16:15:40 -0400 (EDT)

Following up once again - after careful review, I still agree with Charles, and here's some suggested text for the security considerations:

13.5.  IEEE 802.11 Security

    When used with an IEEE 802.11 infrastructure with WEP encryption, the
   CAPWAP protocol does not add any new vulnerabilities.  Derived
   session keys between the STA and WTP can be compromised, resulting in
   many well-documented attacks.  Implementors SHOULD discourage the use
   of WEP and encourage use of technically sound cryptographic solutions
   such as those in an IEEE 802.11 RSN.

   When used with IEEE 802.11 RSN security, the CAPWAP protocol
   may introduce new vulnerabilities, depending on whether the link security
  (packet encryption and integrity verification) is provided by the WTP or the AC. 
   When the link security function is provided by the AC, no new security 
   concerns are introduced. 

   However, when the WTP provides link security, a new vulnerability will
   exist when the following conditions are true:

	o the client is not the first to associate to the WTP/ESSID
        (i.e. other clients are associated), and a GTK already exists

        o traffic has been broadcast under the existing GTK

   Under these circumstances, the receive sequence counter (KeyRSC) 
   associated with the GTK is non-zero, but because the AC anchors the
   4-way handshake with the client, the exact value of the KeyRSC is not
   known when the AC constructs the message containing the GTK.
   The client will update its Key RSC value to the current valid KeyRSC
   upon receipt of a valid multicast/broadcast message, but prior to this, 
   previous multicast/broadcast traffic which was secured with the existing 
   GTK may be replayed, and the client will accept this traffic as valid.

   Typically, busy networks will produce numerous multicast or broadcast
   frames per second, so the window of opportunity with respect to such
   replay is expected to be very small. In most conditions, it is expected that 
   replayed frames could be detected (and logged) by the WTP. 

   The only way to completely close this window is to provide the 
   exact KeyRSC value in message 3 of the 4-way handshake; any
   other approach simply narrows the window to varying degrees. Given
   the low relative threat level this presents, the additional complexity
   introduced by providing the exact KeyRSC value is not warranted. That 
   is, this specification provides for a calculated risk in this regard.

Margaret Wasserman wrote:
>> replay
> This does seem like the simplest approach.  So, if there is no  
> objection from our security advisors
> (you and Scott Kelly), then I'm for it.
> 
> </chair>
> 
> Margaret
> 
______

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 6 Oct 2006 15:36:39 -0700

I agree with Margaret

Pat Calhoun

> Sent: Friday, October 06, 2006 6:39 AM
> To: Scott G Kelly
> Cc: capwap; Cheng Hong
> While I am not against leaving things open to more optimal 
> implementations, I do think that we need to add some text to 
> the protocol portion of the document (as well as the security
> considerations) to explain how this is handled.  How about something
> like:
> 
> The AC SHOULD use an RSC of 0 when computing message-3 of the 
> 4-way 802.11i handshake, unless the AC has knowledge of a 
> more optimal RSC value to use.  Mechanisms for determining a 
> more optimal RSC value are outside the scope of this specification.
> 
> I do not think that we should simply say nothing and hope 
> that implementors figure this out.
> 
> Margaret
> 
> ---
> 
> On Oct 6, 2006, at 9:28 AM, Scott G Kelly wrote:
> 
> > Hi Cheng,
> >
> > I think we have to make the security disclaimer no matter what, as 
> > there is a small window of opportunity unless you precisely 
> > synchronize the KeyRSC (which I think most agree is more 
> complex than 
> > the resulting exposure warrants).
> >
> > As for setting the value, we could be rigid and require it 
> to be set 
> > to zero, or we could be a little less precise, and leave some 
> > discretion here. The only requirement for interoperability 
> is that the 
> > WTP
> > *accept*
> > any value, regardless of what its current KeyRSC value is (which is 
> > also true if we require "0"). Of course, if the AC sends the wrong 
> > value (i.e. a value greater than the actual KeyRSC), this will be a 
> > problem for the STA, and I think all would agree that this 
> particular 
> > implementation is broken.
> >
> > On the other hand, strictly requiring the AC to send zero 
> precludes a 
> > vendor of a "compliant" implementation from implementing some 
> > heuristic or workaround which narrows the window. Frankly, I'm not 
> > certain that any such workaround exists (short of some yet to be 
> > defined WTP/AC exchange), but I guess the question is, should we 
> > firmly slam this door shut, or should we specify only the necessary 
> > and sufficient text for interoperability?
> >
> > I think leaving the value unspecified might be a better approach.
> >
> > Scott
> >
> > Cheng Hong wrote:
> >> Hi Charles and all,
> >>
> >> To specify a "default" value means specifying it to "zero".  
> >> Otherwise,
> >> it would not work. Say, the "default" value is set to 100, but the 
> >> actual sequence number used could be 50 at the moment. It 
> means the 
> >> STA is not able to receive the Broadcast/Multicast packets for the 
> >> next 50 seqeunce count.
> >>
> >> So, I think we need some clarification on what is the 
> decision here. 
> >> Is the decision now:
> >> - No change to the protocol design except some security 
> disclaimers.
> >> And, specify a default value (0) to be used by the AC always.
> >>
> >> Or, We also allow:
> >> - The WTP and AC can choose to implement info exchange methods (a 
> >> simple element to be specified in the draft). However, if some AC 
> >> choose not to support such mechanism, it will have to set 
> the KeyRSC 
> >> to zero. And a security disclaimer to state what is the effect of 
> >> setting the KeyRSC to zero.
> >>
> >> cheers
> >>
> >> Cheng Hong
> >>
> >>
> >>
> >>
> >>> Sent: Friday, October 06, 2006 9:24 AM
> >>> To: Dorothy Stanley
> >>> Cc: capwap
> >>> We'd definitely need to specify a value for keyRSC in the 
> >>> appropriate section.  That would be in addition to the changes to 
> >>> the security considerations.  Without specifying a 
> default value, we 
> >>> could have interoperability issues between WTPs and ACs.
> >>>
> >>> --
> >>> Dorothy Stanley wrote:
> >>>> Behcet,
> >>>> My understanding of Scott's recommendations is that  
> text be added 
> >>>> into the security considerations section.
> >>>> - no additional CAPWAP protocol exchange between the WTP and AC
> >>>> - no specification of setting the keyRSC value to 0.
> >>>>
> >>>> Without some specification in the protocol, how can the 
> WTP provide 
> >>>> the KeyRSC info to the AC in a way that the AC is sure to
> >>> understand?
> >>>> The most we can say
> >>>> with respect to the standard is that an AC implementation
> >>> is free to
> >>>> comes up with its own algorithm to set the keyRSC value.
> >>>>
> >>>> Dorothy
> >>>>
> >>>> On 10/5/06, *Behcet Sarikaya* <[email-masked] 
> >>>> <mailto:[email-masked]>> wrote:
> >>>>
> >>>>     I agree with this and suggest adding Peter's fix as a
> >>> possibility.
> >>>>     As far as interoperability is concerned, value 0 is
> >>> interoperable
> >>>>     but not correct. If we allow implementations to snif in
> >>> and modify
> >>>>     then any value should be acceptable which may be a 
> concern for
> >>>>     interoperability?
> >>>>
> >>>>     ----- Original Message ----
> >>>>     From: Scott G. Kelly < [email-masked]
> >>>>     <mailto:[email-masked]>>
> >>>>     To: capwap <[email-masked] <mailto:[email-masked]>>
> >>>>     Sent: Thursday, October 5, 2006 3:15:40 PM
> >>>>     Following up once again - after careful review, I still
> >>> agree with
> >>>>     Charles, and here's some suggested text for the
> >>> security considerations:
> >>>>        of WEP and encourage use of technically sound 
> cryptographic
> >>>>     solutions
> >>>>        may introduce new vulnerabilities, depending on
> >>> whether the link
> >>>>     security
> >>>>       (packet encryption and integrity verification) is
> >>> provided by the
> >>>>     WTP or the AC.
> >>>>        When the link security function is provided by the AC, no 
> >>>> new
> >>>>     security
> >>>>        concerns are introduced.
> >>>>
> >>>>        However, when the WTP provides link security, a new
> >>> vulnerability
> >>>>     will
> >>>>             (i.e. other clients are associated), and a 
> GTK already 
> >>>> exists
> >>>>
> >>>>        upon receipt of a valid multicast/broadcast message,
> >>> but prior to
> >>>>     this,
> >>>>        previous multicast/broadcast traffic which was
> >>> secured with the
> >>>>     existing
> >>>>        GTK may be replayed, and the client will accept this
> >>> traffic as
> >>>>     valid.
> >>>>
> >>>>        replay is expected to be very small. In most
> >>> conditions, it is
> >>>>     expected that
> >>>>        the low relative threat level this presents, the 
> additional
> >>>>     complexity
> >>>>        introduced by providing the exact KeyRSC value is
> >>> not warranted.
> >>>>     That
> >>>>     ==>
> >>>>     However, WTP implementations MAY provide the exact 
> KeyRSC value
> >>>>     before forwarding message 3 of the 4-way handshake.
> >>>>
> >>>>     --behcet
> >>>>
> >>>>
> --------------------------------------------------------------------
> >>> --
> >>>> --
> >>>>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 6 Oct 2006 20:25:35 -0400 (EDT)

Hi Margaret,

Comments inline below...

-----Original Message-----
>From: Margaret Wasserman <[email-masked]>
>Sent: Oct 6, 2006 9:39 AM
>To: Scott G Kelly <[email-masked]>
>Cc: Cheng Hong <[email-masked]>, capwap <[email-masked]>
>implementations, I do think that we need to add some text to the  
>protocol portion of the document (as well as the security  
>The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way  
>802.11i handshake, unless the AC has knowledge of a more optimal RSC  
>value to use.  Mechanisms for determining a more optimal RSC value  
>are outside the scope of this specification.
>
>I do not think that we should simply say nothing and hope that  
>implementors figure this out.
>
>Margaret

After thinking long and hard about this, I can't bring myself to agree with the suggested text. Quite frankly, I think always using an RSC value of 0 is a lazy hack, and given that we've acknowledged we are introducing a vulnerability here (however slight), telling implementors they SHOULD do this just doesn't sit right with me. 

An enlightened implementation could almost certainly do better than always setting this to zero, and explicitly recommending that people nail this window open just rubs me the wrong way. At least, let's hold off on this decision until we've clearly defined what statistics we expect to be available. Seems like if we're going to tell implementors what they SHOULD do, we SHOULD give them sound, well considered advice.

Scott

---

From: "Cheng Hong" <[email-masked]>
Date: Mon, 9 Oct 2006 13:21:16 +0800

Hi Scott,

Some comments below:

> After thinking long and hard about this, I can't bring myself 
> to agree with the suggested text. Quite frankly, I think 
> always using an RSC value of 0 is a lazy hack, and given that 
> we've acknowledged we are introducing a vulnerability here 
> (however slight), telling implementors they SHOULD do this 
> just doesn't sit right with me. 
> 
> An enlightened implementation could almost certainly do 
> better than always setting this to zero, and explicitly 
> recommending that people nail this window open just rubs me 
> the wrong way. At least, let's hold off on this decision 
> until we've clearly defined what statistics we expect to be 
> available. Seems like if we're going to tell implementors 
> what they SHOULD do, we SHOULD give them sound, well 
> considered advice.

I absolutely agree with you on this point. 

What I was trying to state in my previous emails was:
- I would against setting a static value for the KeyRSC as a solution to
this issue. 
- However if the WG decided to go for a static value, the draft should
clearly point out that NOT all static value could work (value other than
zero may be a problem for interoperability).
- And the draft needs to clearly point out what is the danger of setting
a static KeyRSC value in the security consideration section.
- Also, the draft should not prohibit other implementation for sync the
KeyRSC value between WTP and AC (the CAPWAP standard should not dictate
such implementation incompatible). 

If there is a alternative solution than setting a static KeyRSC value to
narrow the window, I would vote for it.

cheers

Cheng Hong

> From: Scott G. Kelly [mailto:[email-masked]] 
> Sent: Saturday, October 07, 2006 8:26 AM
> To: Margaret Wasserman
> Cc: capwap
> >value to use.  Mechanisms for determining a more optimal RSC 
> value are 
> >outside the scope of this specification.
> >
> After thinking long and hard about this, I can't bring myself 
> to agree with the suggested text. Quite frankly, I think 
> always using an RSC value of 0 is a lazy hack, and given that 
> we've acknowledged we are introducing a vulnerability here 
> (however slight), telling implementors they SHOULD do this 
> just doesn't sit right with me. 
> 
> An enlightened implementation could almost certainly do 
> better than always setting this to zero, and explicitly 
> recommending that people nail this window open just rubs me 
> the wrong way. At least, let's hold off on this decision 
> until we've clearly defined what statistics we expect to be 
> available. Seems like if we're going to tell implementors 
> what they SHOULD do, we SHOULD give them sound, well 
> considered advice.
> 
> Scott
>

---

From: "Cheng Hong" <[email-masked]>
Date: Mon, 9 Oct 2006 14:20:01 +0800

Hi Charles,

> appears.  For example, the WTP would need to communicate it's 
> ability to be queried for the KeyRSC to the AC during initialization.

Yes. It would require AC to know if WTP supports the sync of KeyRSC
value. If WTP doesn't, AC could choose to set a static value for KeyRSC.

The capability exchange has already been in the CAPWAP protocol for
initialize the connection between AC and WTP. This probably is just
another bit to be defined.

cheers

Cheng Hong

> Sent: Friday, October 06, 2006 8:33 PM
> To: Cheng Hong
> Cc: Dorothy Stanley; capwap
> You're suggesting the disclaimer and "static initialization value" 
> (perhaps more accurate term than a "default value") would be 
> mandatory to implement, and there would also be an optional 
> information exchange to synchronize the KeyRSC to something 
> else.  That certainly sounds like a good compromise, but I 
> suspect a little more complicated to implement than it first 
> appears.  For example, the WTP would need to communicate it's 
> ability to be queried for the KeyRSC to the AC during initialization.
> 
> --
> t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy
> 
> Cheng Hong wrote:
> > Hi Charles and all,
> > 
> > actual sequence number used could be 50 at the moment. It means the 
> > - No change to the protocol design except some security disclaimers.
> appropriate 
> >> section.  That would be in addition to the changes to the security 
> >> considerations.  Without specifying a default value, we could have 
> >> interoperability issues between WTPs and ACs.
> >>
> >> --
> >> t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy
> >>
> >> Dorothy Stanley wrote:
> >>> Behcet,
> >>>
> >>> My understanding of Scott's recommendations is that  text 
> be added 
> >>>     then any value should be acceptable which may be a concern for
> >>>     interoperability?
> >>>
> >>>        When the link security function is provided by the 
> AC, no new
> >>>     security
> >>>        concerns are introduced.
> >>>
> ---------------------------------------------------------------------
> >> -
> >>> --
> >>>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 9 Oct 2006 18:01:37 -0400 (EDT)

Hi Saravanan,

Saravanan Govindan wrote:

>Hi Scott,
>
>I am not sure the suggestion below affects any security model. As long as 
>there is an established security framework between the AC and WTP, the 
>suggested approach remains transparent.

When you consider the 'security model', you have to consider all assumptions that went into the cryptographic protocol design.  Also, you need to carefully consider whether our particular deployment scenarios introduce the need for additional interpretation, since the deployment model 802.11 security has been designed around does not include splitting AP functions in two, with a potentially hostile hop in between. That is what we are doing with CAPWAP. 

I won't waste time here trying to speculate (or argue) about what clauses might have been worded differently had the 802.11i group been considering CAPWAP-like scenarios. Instead, let me point out just one consequence of passing the KCK to the WTP: the WTP could undetectably modify the content of message 3 of the 4-way handshake.   This is bad.

Without spending a lot of time thinking about why this might be a problem, we can immediately see that the WTP would be in a position to modify (downgrade) the security capabilities info it sends out, and then modify the IE in message 3 of the 4-way to match.

Why would a WTP want to do this? I'm not sure, but we have to keep in mind that we are talking about interoperability here, so the WTP does not necessarily come from the same place as the AC. But the real point is that according to the security model upon which RSN security is based, _this simply should not be possible_ And I should add, I turned this up after only a cursory analysis - there may be other more significant issues.

Arguably, the same could be said for the KeyRSC=0 problem, so we are in the difficult position of having to weigh these two against one another in choosing a solution. 

Having spent more than a few hours mulling this over, I think we are safest if we choose a solution that minimizes protocol complexity and exposure simultaneously. 

Now, recalling the following for the KeyRSC=0 problem:

- the STA's briefly inaccurate view of the RSC (and it's resulting susceptibility to mcast/bcast replays) will be corrected upon receipt of the first valid mcast/bcast message from the WTP

- that on "normal" networks we can expect more than a few of these per second (so the exposure is typically sub-second)

- that an attempt to replay old frames could likely be detected

- that the attacker would either be blindly replaying (outsider attack) and just *hoping* something goes wrong

- or that the attacker is an insider who knows the GTK (and could therefore manufacture whatever packets he desires *within* the legal window anyway

it seems to me that the window of exposre here is very small indeed. Definitely not worth potentially breaking the RSN security model over.

I think that if the WTP, as part of its normal statistics messaging, transmitted per ESSID bcast/mcast counts to the AC, this represents a nice compromise. No new messages, no out of the ordinary processing,  and the AC knows which GTK the stats go with, so it can narrow the window of exposure according to how current its stats are vs the xmit rate with the GTK.

Scott

---

From: "Scott Kelly" <[email-masked]>
Date: Fri, 13 Oct 2006 11:10:03 -0700

Hi All,

Charles and I have been discussing the keyrsc issue, and we're in
agreement on an opinion of the overall security implications. 

To summarize briefly, there are small exposures in either case which are
both pretty trivial. The small replay exposure is probably the more
acceptable of the two, given the complexity level of the proposed 'fix'.
The added complexity of passing the KCK to the WTP together with the
slight associated exposure tips the scale slightly more toward the "just
choose a keyrsc value that will work (zero or a better one if you know
it)" solution.

If you want the background considerations, a more detailed discussion
follows. Otherwise, there you have it.

------------------------------------------------------------------------
----
1. Setting KeyRSC = 0

In the current CAPWAP protocol, the 4-way handshake occurs between the
AC and the STA, and once this is complete, the AC pushes the 802.11
cryptographic key material (the PTK) to the WTP. In cases where a GTK
(the group transient key, which is used to cryptographically protect
broadcast/multicast traffic) is already active for the ESSID the STA is
associating to, the GTK is identified in message 3 of the 4-way
handshake, along with the current receive sequence counter (KeyRSC) for
messages protected under that key. Since the WTP maintains the active
KeyRSC, the AC currently has no way to know precisely what the correct
value is at the point at which message 3 is constructed. To work around
this, LWAPP designers chose to have the AC simply set this value to 0.

This decision does not affect the WTP, who maintains this counter; it
only affects the STA. Hence, there is no interoperability implication to
this behavior. The STA, upon receiving the first valid
broadcast/multicast message from the WTP, will update its RSC to the
correct value, and will be synchronized with the WTP's value from then
on.

The security consequences of this approach are as follows:

- the period beginning when the STA installs the GTK and KeyRSC and
ending when the STA receives the first valid bcast/mcast message from
the WTP represents a window of opportuntity for an attacker

- the window has two dimensions: the time it remains open, and the
relative width, which is measured in terms of the difference between the
current valid KeyRSC value and 0 (i.e. the magnitude of the current
KeyRSC)

- so long as this window remains open, an adversary could replay
previous valid bcast/mcast messages, and so long as those messages are
replayed in monotonically increasing order with respect to the RSC
value, the STA would accept these messages as valid. The higher the
current KeyRSC, the more messages an adversary could potentially replay,
assuming no valid bcast/mcast messages were sent by the WTP (i.e. the
window remained open).

1.1 Mitigating Circumstances

- typical wireless networks with a small population of users will see
multiple broadcasts per second, so this window will normally be open for
a very short (sub-second) interval.

- an unauthenticated (outsider) adversary would be restricted to blindly
playing back mcast/bcast traffic; while the adverary could make some
inferences with respect to the encrypted traffic type based on traffic
analysis techniques, the adversary could not be certain of what message
content he was replaying.

- an authenticated adversary would be capable of selectively playing
back mcast/bcast messages whose content is known, but that same
adversary could generate the same (or similar) messages in real-time
even after the STA's KeyRSC is updated. That is, there is little benefit
in replaying existing messages rather than simply constructing new ones.

- if there are mcast/bcast message streams suitable for launching an
attack, in order to know that such an attack is present in the recorded
stream, the attacker would with high probablility need to be an insider
- in which case replay capability is not a necessary condition for
launching the attack.

1.2 Conclusions

Setting the KeyRSC to 0 opens a small window of opportunity during which
previously transmitted mcast/bcast traffic could be replayed. While this
could have operational implications (e.g. the STA might instantiate
stale ARP entries, receive stale NetBIOS packets to which it may
respond, or receive other invalid information that somehow
'contaminates' its view of the network), we believe the impact would be
both detectable and quite small in a reasonably robust STA. 

Also, the primary threat introduced pertains to an outsider blindly
playing back recorded data, as an insider would have knowledge of the
group key, and so rather than wasting time collecting packets off the
air and attempting to replay them within a window of opportunity of
indefinite size, the adversary would be better advised to simply
generate the spurious packets. That is, an insider adversary has better
tools at his disposal than this window of opportunity provides.

While it is certainly prudent to narrow the window as much as is
practicable, this must be weighed carefully against the complexity of
the solution vs the minimal threat level this represents. 

2. WTP puts current KeyRSC into message 3

One proposed solution the problem of the AC not knowing the current
KeyRSC entails having the WTP insert the correct value in message 3 of
the 4-way handshake. This requires the WTP to know the Key Confirmation
Key (KCK) in order to compute the MIC on the message. Currently, this
value is only known to the AC and STA.

The security considerations for this approach are as follows:

- currently, the WTP has no knowledge of the KCK; having this value
would provide the WTP with the ability to modify the RSN Information
Element (IE) containing the supported cryptographic algorithms
advertised by the AC during the association process. This IE is included
in this message explicitly because the MIC computation provides a secure
mechanism for validating the value used during association against this
authenticated value. That mechanism would now be open to subversion, and
in particular, the WTP would have the ability to downgrade the
cryptographic algorithms the AC is advertising without the ACs
knowledge.

2.1 Mitigating Circumstances

- an evil WTP would also have access to the PTK once the 4-way handshake
completes. Almost anything that could be accomplished via a downgrade
attack could also be accomplished by passing off the PTK to a
collaborator.

- the downgraded RSN IE's used during association could be detected
using sniffers

- that fact that STAs are associating with downgraded capabilities could
be detected via log inspection

2.2 Conclusions

The minimal exposure introduced by communicating the KCK to the WTP does
not represent a signficant threat due to the fact that the WTP also
possesses the PTK. This implies that appropriate measures are already in
place to ensure the trustworthiness of the WTP. While one could dream up
scenarios in which a collaborating evil STA took advantage of the
downgraded cryptographic algorithms to somehow attack an unsuspecting
STA, there are plenty of ways in which the evil WTP could communicate
the PTK to the evil STA, so possession of the KCK adds little
adversarial capability.

3. Recommendations

Security analysis is often very subtle, and there is certainly some art
involved. This appears to be one of those difficult cases in which some
art will be required. Both approaches to this problem entail
vulnerabilities. The question is, do these represent real-world threats
from a practical standpoint? 

In terms of the small window of opportunity opened by setting KeyRSC=0,
it is difficult to imagine how this could be leveraged by an outsider
adversary, especially given that the window size will be sub-second on
typical networks. And it's even more of a stretch to imagine an insider
(who has access to the GTK and the ability to send legitimate
bcast/mcast frames) choosing this avenue for an attack. 

Odds seem very much in our favor that nothing bad will happen if we
leave this small window open, and after reviewing this briefly, Russ
Housley agrees.

In terms of the potential downgrade vulnerability introduced by giving
the KCK to a subverted WTP, it seems clear that there most likely would
be bigger worries there. It's not totally impossible to cook up an
attack scenario, but there are almost certainly simpler avenues of
attack.

Still, on a practical level, pushing the KCK to the WTP adds complexity.
The KCK would have to be delivered to the WTP somehow (and in an
acknowledged CAPWAP control message, while the 4-way handshake is
carried in the data channel). This would add latency to the association
process (already a problem as it is, and this would only make it worse).

Both approaches have what appear to be minor security implications, yet
neither approach invites any obvious attack. It is entirely possible
that there is no practical way to exploit the weaknesses exposed in
either case, but it is also at least slightly possible that some subtle
set of circumstances might lead to an exploit in one case or the other -
we simply cannot be certain.

Taking these things into consideration, it seems like a good operational
compromise to assume the limited risk associated with the minimally open
replay window, while providing appropriate security recommendations to
try to narrow it if it is possible to do so with minimal added
complexity.
--------------------------------

Let us know if you have any further questions on this.

Scott

---

From: "Cheng Hong" <[email-masked]>
Date: Fri, 20 Oct 2006 10:32:35 +0800

Hi Scott and all,

That is an excellent summary of the issue. Would suggest including the
whole analysis into the Security Consideration of the CAPWAP spec
regardless which final approach the group decides to take (since this
issue is specific to/introduced by CAPWAP architecture).

cheers

Cheng Hong

> From: Scott Kelly [mailto:[email-masked]] 
> Sent: Saturday, October 14, 2006 2:10 AM
> To: [email-masked]
> Charles and I have been discussing the keyrsc issue, and 
> we're in agreement on an opinion of the overall security 
> implications. 
> 
> To summarize briefly, there are small exposures in either 
> case which are both pretty trivial. The small replay exposure 
> is probably the more acceptable of the two, given the 
> complexity level of the proposed 'fix'.
> The added complexity of passing the KCK to the WTP together 
> with the slight associated exposure tips the scale slightly 
> more toward the "just choose a keyrsc value that will work 
> (zero or a better one if you know it)" solution.
> 
> If you want the background considerations, a more detailed 
> discussion follows. Otherwise, there you have it.
> 
> In the current CAPWAP protocol, the 4-way handshake occurs 
> between the AC and the STA, and once this is complete, the AC 
> pushes the 802.11 cryptographic key material (the PTK) to the 
> WTP. In cases where a GTK (the group transient key, which is 
> used to cryptographically protect broadcast/multicast 
> traffic) is already active for the ESSID the STA is 
> associating to, the GTK is identified in message 3 of the 
> 4-way handshake, along with the current receive sequence 
> counter (KeyRSC) for messages protected under that key. Since 
> the WTP maintains the active KeyRSC, the AC currently has no 
> way to know precisely what the correct value is at the point 
> at which message 3 is constructed. To work around this, LWAPP 
> designers chose to have the AC simply set this value to 0.
> 
> This decision does not affect the WTP, who maintains this 
> counter; it only affects the STA. Hence, there is no 
> interoperability implication to this behavior. The STA, upon 
> receiving the first valid broadcast/multicast message from 
> the WTP, will update its RSC to the correct value, and will 
> be synchronized with the WTP's value from then on.
> 
> - the period beginning when the STA installs the GTK and 
> KeyRSC and ending when the STA receives the first valid 
> bcast/mcast message from the WTP represents a window of 
> opportuntity for an attacker
> 
> - the window has two dimensions: the time it remains open, 
> and the relative width, which is measured in terms of the 
> difference between the current valid KeyRSC value and 0 (i.e. 
> the magnitude of the current
> KeyRSC)
> 
> - so long as this window remains open, an adversary could 
> replay previous valid bcast/mcast messages, and so long as 
> those messages are replayed in monotonically increasing order 
> with respect to the RSC value, the STA would accept these 
> messages as valid. The higher the current KeyRSC, the more 
> messages an adversary could potentially replay, assuming no 
> valid bcast/mcast messages were sent by the WTP (i.e. the 
> window remained open).
> 
> - typical wireless networks with a small population of users 
> will see multiple broadcasts per second, so this window will 
> normally be open for a very short (sub-second) interval.
> 
> - an unauthenticated (outsider) adversary would be restricted 
> to blindly playing back mcast/bcast traffic; while the 
> adverary could make some inferences with respect to the 
> encrypted traffic type based on traffic analysis techniques, 
> the adversary could not be certain of what message content he 
> was replaying.
> 
> - an authenticated adversary would be capable of selectively 
> playing back mcast/bcast messages whose content is known, but 
> that same adversary could generate the same (or similar) 
> messages in real-time even after the STA's KeyRSC is updated. 
> That is, there is little benefit in replaying existing 
> messages rather than simply constructing new ones.
> 
> - if there are mcast/bcast message streams suitable for 
> launching an attack, in order to know that such an attack is 
> present in the recorded stream, the attacker would with high 
> probablility need to be an insider
> - in which case replay capability is not a necessary 
> condition for launching the attack.
> 
> 1.2 Conclusions
> 
> Setting the KeyRSC to 0 opens a small window of opportunity 
> during which previously transmitted mcast/bcast traffic could 
> be replayed. While this could have operational implications 
> (e.g. the STA might instantiate stale ARP entries, receive 
> stale NetBIOS packets to which it may respond, or receive 
> other invalid information that somehow 'contaminates' its 
> view of the network), we believe the impact would be both 
> detectable and quite small in a reasonably robust STA. 
> 
> Also, the primary threat introduced pertains to an outsider 
> blindly playing back recorded data, as an insider would have 
> knowledge of the group key, and so rather than wasting time 
> collecting packets off the air and attempting to replay them 
> within a window of opportunity of indefinite size, the 
> adversary would be better advised to simply generate the 
> spurious packets. That is, an insider adversary has better 
> While it is certainly prudent to narrow the window as much as 
> is practicable, this must be weighed carefully against the 
> complexity of the solution vs the minimal threat level this 
> represents. 
> 
> 
> One proposed solution the problem of the AC not knowing the 
> current KeyRSC entails having the WTP insert the correct 
> value in message 3 of the 4-way handshake. This requires the 
> WTP to know the Key Confirmation Key (KCK) in order to 
> compute the MIC on the message. Currently, this value is only 
> known to the AC and STA.
> 
> - currently, the WTP has no knowledge of the KCK; having this 
> value would provide the WTP with the ability to modify the 
> RSN Information Element (IE) containing the supported 
> cryptographic algorithms advertised by the AC during the 
> association process. This IE is included in this message 
> explicitly because the MIC computation provides a secure 
> mechanism for validating the value used during association 
> against this authenticated value. That mechanism would now be 
> open to subversion, and in particular, the WTP would have the 
> ability to downgrade the cryptographic algorithms the AC is 
> advertising without the ACs knowledge.
> 
> - an evil WTP would also have access to the PTK once the 
> 4-way handshake completes. Almost anything that could be 
> accomplished via a downgrade attack could also be 
> accomplished by passing off the PTK to a collaborator.
> 
> - the downgraded RSN IE's used during association could be 
> detected using sniffers
> 
> - that fact that STAs are associating with downgraded 
> capabilities could be detected via log inspection
> 
> 2.2 Conclusions
> 
> The minimal exposure introduced by communicating the KCK to 
> the WTP does not represent a signficant threat due to the 
> fact that the WTP also possesses the PTK. This implies that 
> appropriate measures are already in place to ensure the 
> trustworthiness of the WTP. While one could dream up 
> scenarios in which a collaborating evil STA took advantage of 
> the downgraded cryptographic algorithms to somehow attack an 
> unsuspecting STA, there are plenty of ways in which the evil 
> WTP could communicate the PTK to the evil STA, so possession 
> of the KCK adds little adversarial capability.
> 
> 
> 3. Recommendations
> 
> Security analysis is often very subtle, and there is 
> certainly some art involved. This appears to be one of those 
> difficult cases in which some art will be required. Both 
> approaches to this problem entail vulnerabilities. The 
> question is, do these represent real-world threats from a 
> practical standpoint? 
> 
> In terms of the small window of opportunity opened by setting 
> KeyRSC=0, it is difficult to imagine how this could be 
> leveraged by an outsider adversary, especially given that the 
> window size will be sub-second on typical networks. And it's 
> even more of a stretch to imagine an insider (who has access 
> to the GTK and the ability to send legitimate bcast/mcast 
> frames) choosing this avenue for an attack. 
> 
> Odds seem very much in our favor that nothing bad will happen 
> if we leave this small window open, and after reviewing this 
> briefly, Russ Housley agrees.
> 
> In terms of the potential downgrade vulnerability introduced 
> by giving the KCK to a subverted WTP, it seems clear that 
> there most likely would be bigger worries there. It's not 
> totally impossible to cook up an attack scenario, but there 
> are almost certainly simpler avenues of attack.
> 
> The KCK would have to be delivered to the WTP somehow (and in 
> an acknowledged CAPWAP control message, while the 4-way 
> handshake is carried in the data channel). This would add 
> latency to the association process (already a problem as it 
> is, and this would only make it worse).
> 
> Both approaches have what appear to be minor security 
> implications, yet neither approach invites any obvious 
> attack. It is entirely possible that there is no practical 
> way to exploit the weaknesses exposed in either case, but it 
> is also at least slightly possible that some subtle set of 
> circumstances might lead to an exploit in one case or the 
> other - we simply cannot be certain.
> 
> Taking these things into consideration, it seems like a good 
> operational compromise to assume the limited risk associated 
> with the minimally open replay window, while providing 
> appropriate security recommendations to try to narrow it if 
> it is possible to do so with minimal added complexity.