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

[Bob O'Hara (boohara) (boohara]

I am describing an implementation of CAPWAP that would be perfectly
functional and compliant with a WTP providing 802.11 service with
802.11i.  We could include a note to the effect that the group KeyRSC
should be zero in the EAPOL-key frame.  But, this is not new standards
making.  There is no need to change anything in 802.11. 


 -Bob
 
-----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
>