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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sun, 24 Sep 2006 18:16:13 -0700

Saravanan,

We've been down this path already, and I believe Bob O'Hara tried to set
you in the right direction. Your assessment is incorrect and 802.11i
works fine w/ the current spec.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Saravanan Govindan [mailto:[email-masked]] 
> Sent: Friday, September 22, 2006 2:03 AM
> To: Margaret Wasserman
> Cc: Pat Calhoun (pacalhou); [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

---

From: sujay <[email-masked]>
Date: Mon, 25 Sep 2006 10:50:39 +0530

Hi Pat,

Perhaps the current specs has no provision for maintaining the KeyRSC
required for  Multicast and Broadcast messages in the AC, in case the WTP is
doing the
en/de-cryption. Hence in the 3rd message of the 4 way handshake , I do not
see how the AC
could possibly send the KeyRSC values to the Mobile Station w/o some
assumptions on the 
Mobile station (supplicant) side ??

I concur with Charles in his analysis.

Regds,
Sujay G
My Location;
http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h
&hl=en

This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it! 
-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Monday, September 25, 2006 6:46 AM
To: Saravanan Govindan; Margaret Wasserman
Cc: [email-masked]
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Saravanan,

We've been down this path already, and I believe Bob O'Hara tried to set you
in the right direction. Your assessment is incorrect and 802.11i works fine
w/ the current spec.

Pat Calhoun

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