Capwap Mailing List: Re: Issue 43 - Explanation for 802.11i Considerations

[Bob O'Hara (boohara) (boohara]

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:dstanley1389 [at] gmail.com]
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); capwap [at] frascone.com
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) <boohara [at] cisco.com> 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:Hong.Cheng [at] sg.panasonic.com]
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: capwap [at] frascone.com
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: pcalhoun [at] cisco.com]
> Sent: Thursday, September 28, 2006 1:39 AM
> To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy;
> Peter Nilsson J (LI/EAB)
> Cc: capwap [at] frascone.com
> 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: Hong.Cheng [at] sg.panasonic.com]
> > Sent: Tuesday, September 26, 2006 6:03 PM
> > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson
> J (LI/EAB)
> > Cc: capwap [at] frascone.com
> > 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:boohara [at] cisco.com]
> > > Sent: Wednesday, September 27, 2006 2:32 AM
> > > To: T. Charles Clancy; Peter Nilsson J (LI/EAB)
> > > Cc: capwap [at] frascone.com
> > > 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:clancy [at] cs.umd.edu]
> > > Sent: Monday, September 25, 2006 11:37 AM
> > > To: Peter Nilsson J (LI/EAB)
> > > Cc: capwap [at] frascone.com
> > > 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.  |  tcc [at] umd.edu  |
> 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:Saravanan.Govindan [at] sg.panasonic.com]
> > > > Sent: den 22 september 2006 11:03
> > > > To: Margaret Wasserman
> > > > Cc: capwap [at] frascone.com
> > > > 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:margaret [at] thingmagic.com]
> > > > Sent: Thursday, September 21, 2006 8:26 PM
> > > > To: Saravanan Govindan
> > > > Cc: Pat Calhoun (pacalhou); capwap [at] frascone.com
> > > > 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
> > > >
> > > > 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
> > >
> > _________________________________________________________________
> > 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