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

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Fri, 29 Sep 2006 09:09:54 -0700

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:
[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: Fri, 29 Sep 2006 12:50:17 -0400

I still do not see what the problem is with section 11.3 of CAPWAP2. I
follows consistently with what is in IEEE 802.11. If someone does not have
suggested text changes, I recommend that we close this issue.

Cheers,

Mike

On 9/29/06, Bob O'Hara (boohara) <[email-masked]> wrote:
> 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.
>
> 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);
> *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
> 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
> 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
>
> > 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
> > 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.
> >
> > 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
> > 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]
> > So, based on this, I would say that we have consensus that setting the
> > correct KeyRSC is an issue for the CAPWAP protocol design.
> >
> > 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
> > 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: Pat Calhoun (pacalhou) [mailto: [email-masked]]
> > > To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy;
> > > Peter Nilsson J (LI/EAB)
> > > Cc: [email-masked]
> > > 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
> > > > From: Cheng Hong [mailto: [email-masked]]
> > > > To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson
> > > J (LI/EAB)
> > > > Cc: [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
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > > > 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
> > > > > 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.
> > > > >
> > > > > RSC value maintained by the WTP.  A value of zero in the
> > > EAPOL-key
> > > > > 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
> > > > > 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
> > > > > 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
> > > > > 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
> > > > > 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
> > > > > This is a very interesting solution.  The AC selects the
> > > KeyRSC and
> > > > > performs the 4-way handshake.  The WTP sniffs the 4-way handshake
> > > > > Pat/Bob: Is this how the Cisco implementation works?  I
> > > > have to agree
> > > > > 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.
> > > > >
> > > > > --
> > > > > 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
> > > > > >
> > > > > > 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
> > > > > > 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
> > > > > > 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.
> > > > > >
> > > > > > From: Margaret Wasserman [mailto:[email-masked]]
> > > > > > 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.
> > > > > >
> > > > > > 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
> > > > > > 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
> > > > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >