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

[Bob O'Hara (boohara) (boohara]

There is no limit placed on 802.11i operation.  Please explain that
statement.  Please READ 802.11i, first, specifically the two subclauses
I cited. 


 -Bob
 
-----Original Message-----
From: Saravanan Govindan [mailto:Saravanan.Govindan [at] sg.panasonic.com] 
Sent: Thursday, September 28, 2006 6:04 AM
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

This seems to suggest that the standard specify parametric values. It
seems to place a limitation on 802.11i operation. 

Saravanan




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