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

[Bob O'Hara (boohara) (boohara]

Charles, 

Please see my comments below.

 -Bob
 
-----Original Message-----
From: Charles Clancy [mailto:clancy [at] cs.umd.edu] 
Sent: Saturday, September 30, 2006 4:11 PM
To: Margaret Wasserman
Cc: capwap [at] frascone.com
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

I've reread the thread and reread the relevent portions of 11i.  I think
my statements before were partially inaccurate.  The security and
overhead
ramifications are not insignificant.

We can:

1. Set the KeyRSC to a static value.  This increases the risk of replay
attacks of multicast/broadcast packets encrypted with the group key
between the time the client authenticates and when the first legitimate
group key-encrypted packet is transmitted.

Bob>> I don't believe that this increases the risk of replay attack.
The risk of attack is related to the presence of an attacker and the
time between the 4-way handshake and the next multicast frame
transmitted by the AP.  As long as the possibility exists that the
KeyRSC does not match the actual TSC, this attack is feasible.

Bob>> It should be noted that "replay" of encrypted/MICed multicast
frames is inherent in the design of an 802.11 WLAN that has more than
one AP in it.  Because the load and availability of transmit
opportunities varies with time, location, and channel, it is likely that
the STA will encounter a situation where it has received one or more
multicast frames from one AP that it will receive again from a second AP
that it has just roamed to.  The multicast frames at the second AP have
been delayed due to that AP having fewer opportunities to transmit,
resulting in longer queuing delays for the first transmission of those
multicast frames. 

2. Periodically transmit the KeyRSC from the WTP to the AC.  This would
allow for fewer packets to be replayed, but would not completely prevent
replay attacks.  Probabalistically, it would weaken their effectiveness.

The added price is more protocol overhead.

3. Have the WTP request the GTK prior to initiating the 4-way handshake.

This would eliminate replay attacks, but add one round trip to the
authentication process.  This could possibly be optimized by having the
WTP detect EAPOL message 1 being sent to the STA, and immediately
transmit
it to the AC before it needs it for EAPOL message 3.

Bob>> The WTP already has the GTK, if it has any STAs associated.  There
is no need for it to request it from the AC.  I am not sure what this
would accomplish.

Transporting the KCK to the WTP breaks the security model, and should
not
be considered a viable option.

Bob>> Agreed.

None of the approaches affect the STA operation, or require any changes
to
802.11.

Bob>> Agreed.

Here's a question: what happens if the newly authenticated STA tries to
transmit a GTK-encrypted packet using RSC=0?  Would it get dropped?  Is
this a problem, particularly for protocols such as DHCP?

Bob>> The STA cannot transmit on the GTK, this is not allowed by 802.11.
Any frame sent to a multicast destination in 802.11 by an associated STA
must be sent directly to the AP, encrypted on the PTK, where it is then
decrypted and forwarded (both to the wire and to the BSS encrypted on
the GTK) as a multicast frame.  Only the frame from the AP will be
encrypted on the GTK.  All STAs are required to drop any frames
addressed to them that are not sent from the AP, when associated to an
AP.  This is done prior to checking MIC or decrypting the frame.

-- 
t. charles clancy, ph.d.  <>  tcc [at] umd.edu  <>  www.cs.umd.edu/~clancy

On Sat, September 30, 2006 12:00 pm, Margaret Wasserman wrote:
>
>
> Could one of you explain to me what the implications would be of the
> AC always using an RSC value of 0 to compute the MIC in message 3 of
> the 4-way handshake?
>
> Would this reduce/eliminate the value of the RSC as a security
> mechanism?  Does it imply something about how the WTP needs to
> behave?  Something about how the supplicant needs to behave?
>
> Thanks,
> Margaret
>
>
> On Sep 29, 2006, at 4:43 PM, Pat Calhoun (pacalhou) wrote:
>
>> To be fair, one option requires that message 3 be created, and
>> encrypted, in the WTP. This implies that encryption and
authentication
>> keys required to formulate message 3 be sent to the WTP.
>>
>> Seems to me simpler to include text that either states the value of
>> zero
>> is always used (simplest), or some configurable value be sent to
>> the WTP
>> (simpler).
>>
>> Pat Calhoun
>> CTO, Wireless Networking Business Unit
>> Cisco Systems
>>
>>
>>
>>> -----Original Message-----
>>> From: T. Charles Clancy [mailto:clancy [at] cs.umd.edu]
>>> Sent: Friday, September 29, 2006 12:07 PM
>>> To: Cheng Hong
>>> Cc: Bob O'Hara (boohara); Dorothy Stanley; Pat Calhoun
>>> (pacalhou); Peter Nilsson J (LI/EAB); capwap [at] frascone.com;
>>> Saravanan Govindan
>>> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i
>>> Considerations
>>>
>>> All,
>>>
>>> I'm glad to see we're finally arguing about the right issue.
>>> As discussed, the Cisco solution to the problem is "set it to zero".
>>> Certainly sniffing the value works as well.  From a security
>>> standpoint either is just fine.
>>>
>>> We do have an interoperability issue, however, if a Cisco WTP
>>> were used with an AC that's randomly generating a KeyRSC and
>>> expecting the WTP to sniff it.  So, I think some text is
>>> necessary to address the issue.
>>>
>>> What remains are two entrenched opinions about protocol
>>> flexibility vs simplicity, neither of which would
>>> significantly tilt the flexibility vs simplicity balance in
>>> either of direction.  Let's flip a coin and move on to more
>>> important issues.
>>>
>>> --
>>> t. charles clancy, ph.d.  |  tcc [at] umd.edu  |  www.cs.umd.edu/~clancy
>>>
>>> On Fri, 29 Sep 2006, Cheng Hong wrote:
>>>
>>>> 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:boohara [at] cisco.com]
>>>> 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); capwap [at] frascone.com
>>>> 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:dstanley1389 [at] gmail.com]
>>>> 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); capwap [at] frascone.com
>>>> 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) <boohara [at] cisco.com> 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:Hong.Cheng [at] sg.panasonic.com]
>>>> 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: capwap [at] frascone.com
>>>> 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: pcalhoun [at] cisco.com]
>>>>> Sent: Thursday, September 28, 2006 1:39 AM
>>>>> To: Cheng Hong; 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
>>>>>
>>>>> 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:  <mailto:Hong.Cheng [at] sg.panasonic.com>
>>>> 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
>>>> <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
>>>> <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
>>>> <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