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

From: "Saravanan Govindan" <[email-masked]>
Date: Fri, 22 Sep 2006 17:03:09 +0800

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: Margaret Wasserman <[email-masked]>
Date: Fri, 22 Sep 2006 18:12:08 -0400

Hi All,

I'm trying to get a read on whether this issue needs further  
discussion or not...

Saravanan has made a proposal for change to the specification, and he  
has offered an explanation for the motivation behind this proposal  
(see below).

Pat Calhoun has argued that this level of flexibility is unnecessary  
and that the specification fully supports IEEE 802.11i and meets the  
requirements, as written.

I've seen a few notes in support of Pat's position and I haven't  
noticed anyone else supporting Saravanan's proposal.  If there are  
others who support Saravanan's proposal, please speak up.  Unless we  
see strong support for this proposal, we'll have to conclude that the  
WG does not have consensus to make this change.

Margaret

---

From: sujay <[email-masked]>
Date: Sat, 23 Sep 2006 13:36:41 +0530

Hi Margaret/Pat,

I am not sure which section in the current specs solves the issue
pointed out by Saravanan . (.. my ignorance !)

Could anyone give some pointers?

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: Margaret Wasserman [mailto:[email-masked]] 
Sent: Saturday, September 23, 2006 3:42 AM
To: [email-masked]
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Hi All,

I'm trying to get a read on whether this issue needs further discussion or
not...

Saravanan has made a proposal for change to the specification, and he has
offered an explanation for the motivation behind this proposal (see below).

Pat Calhoun has argued that this level of flexibility is unnecessary and
that the specification fully supports IEEE 802.11i and meets the
requirements, as written.

I've seen a few notes in support of Pat's position and I haven't noticed
anyone else supporting Saravanan's proposal.  If there are others who
support Saravanan's proposal, please speak up.  Unless we see strong support
for this proposal, we'll have to conclude that the WG does not have
consensus to make this change.

Margaret

On Sep 22, 2006, at 5:03 AM, Saravanan Govindan wrote:

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

---

From: "Peter Nilsson J (LI/EAB)" <[email-masked]>
Date: Mon, 25 Sep 2006 14:58:52 +0200

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,

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,

Saravanan, you wrote:

Thanks,
Margaret

---

From: "Nehru Bhandaru" <[email-masked]>
Date: Mon, 25 Sep 2006 08:39:05 -0600

Does this mean WTP has knowledge of (or can compute) the KCK that is
used to integrity protect these messages? Does/Did the protocol have a
way to communicate this to the WTP? If so, does this have any additional
security implications?

- Nehru

-----Original Message-----
From: Peter Nilsson J (LI/EAB) [mailto:[email-masked]] 
Sent: Monday, September 25, 2006 8:59 AM
Cc: [email-masked]
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

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,

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,

Saravanan, you wrote:

Thanks,
Margaret

---

From: "T. Charles Clancy" <[email-masked]>
Date: Mon, 25 Sep 2006 14:36:55 -0400 (EDT)

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