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

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Thu, 28 Sep 2006 14:21:09 -0700

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: [email-masked]
<mailto:[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 
	> > > >
	> > > > 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

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

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

---

From: "Michael Montemurro" <[email-masked]>
Date: Thu, 28 Sep 2006 19:40:55 -0400

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

On 9/28/06, Bob O'Hara (boohara) <[email-masked]> wrote:
> 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
> > 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
> > The problem with what Bechet and Saranavan are asking is that either of
> > 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
> > 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.
> >
> > communication between WTP and AC, at least one new CAPWAP packet for
> > acknowledged, or two new CAPWAP packets, if it is acknowledged.  This is
> > 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
> > 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
> > 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
> > 2) As suggested by Behcet: AC communicate a correct KeyRSC to WTP
> >
> > 3) As suggested by Saravanana: Some exchange mechanism between WTP and
> > AC
> >
> > 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
> > 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
> > > > From: Cheng Hong [mailto: [email-masked]]
> > > > If I understand your description below correct, you are proposing a
> > > > Saravanan) by mandating the behavior of the AC to always set the
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > > > understand why the exchange that Saranavan is requesting is not
> > > > > necessary.  In fact, there are several systems from several
> > > > > initial sequence counter value for the pairwise key, since it has
> > > > > The same is not true of the group key, i.e., after the WTP begins
> > > > > However, as you will see from the tutorial below, it is not
> > > > necessary
> > > > > 1. A value for the KeyRSC in the EAPOL-key frame is necessary to
> > > > > calculate the KeyMIC.
> > > > >
> > > > > 3. The client STA will use the value of KeyRSC received in the
> > > > > 4. The client STA will also set its group key RSC to the value
> > > > > 5. The value in the client STA's RSC will be compared against the
> > > > > sequence number in subsequent received frames to identify replay
> > > > > and meets all other validity and authenticity requirements,
> > > > the client
> > > > > STA updates its RSC value to the sequence number in the received
> > > > > validate its MIC.  This is a potential attack against the STA
> > > > > 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
> > > > > performs the 4-way handshake.  The WTP sniffs the 4-way handshake
> > > > > generate the KeyRSC and include it in the AddMobile message
> > > > as Behcet
> > > > > suggests.
> > > > >
> > > > > --
> > > > > > 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
> > > > > > 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
> > > > > >
> > > > > > 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
> > > > > > 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
> > > > > > In the case of CAPWAP, the 4-way handshake is between the AC
> > > > > > The problem arises, when the authenticator is at the AC and
> > > > > the crypto
> > > > > > not know the value of the KeyRSC. The KeyRSC is maintained
> > > > > by the WTP.
> > > > > >
> > > > > > the 4-way handshake be sent from AC to WTP. This will allow
> > > > > the 4-way
> > > > > > From: Margaret Wasserman [mailto:[email-masked]]
> > > > > >> The issue here is about how 802.11i exchanges are done when
> > > > > > On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:
> > > > > >> AC, while the data packet crypto elements in the WTP. This
> > > > > feature is
> > > > > > necessary?  it will not be helpful to my understanding to
> > > > > re-send your
> > > > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >