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

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

All,

I wanted to give a more detailed explanation for the IEEE 802.11i
Considerations requirement. This note describes how CAPWAP can be
updated to satisfy this requirement

I would like to use this to highlight the proposal being put forward. 

>From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations

   Protocol Requirement:

   The CAPWAP protocol MUST determine the exact structure of the

   centralized WLAN architecture in which authentication needs to be

   supported, i.e., the location of major authentication components.

   This may be achieved during WTP initialization where major

   capabilities are distinguished.

   The protocol MUST allow for the exchange of key information when

   authenticator and encryption roles are located in distinct entities.

Following the requirement, CAPWAP needs;

1. to incorporate authentication & encryption locations in 

   capabilities exchange

2. to exchange key information when authentication and crypt are

   located in different network entities

Basic case:

AC does both IEEE 802.11i authentication and cryptography. For 4-way

exchange, AC tracks the KeyRSC, which it then uses for Message-3,

i.e., AC calculates KeyMIC and updates EAPoL frame.

                                                  - 802.11i
Authentication 

                                                  - 802.11i Crypto 

                                                     (KeyRSC maintained
here)

   +----------+                 +-----+                     +------+

   | Terminal |                 | WTP |                     |  AC  |

   +----------+                 +-----+                     +------+

        |                          |                            |

        |                    802.1x Authentication              |

        |<=====================================================>|

        |                          |                            |

       PMK                         |                           PMK

        |                          |                            |

      Generate                     |                        Generate

       SNonce                      |                         ANonce

        |                          |                            |

        |                          |                            |

        |                      Message-1                        |

        |<-------------------------|<---------------------------|

        |       EAPoL Packet       |        CAPWAP Packet       |

      Receive                      |                            |

       ANonce                      |                            |

      Generate                     |                            |

       PTK                         |                            |

        |                          |                            |

        |                      Message-2                        |

        |------------------------->|--------------------------->|

        |       EAPoL Packet       |        CAPWAP Packet       |

        |                          |                        Receive

        |                          |                        SNonce

        |                          |                            |

        |                          |                       Generate

        |                          |                          PTK

        |                          |                          GTK

        |                      Message-3                        |

        |<-------------------------|<---------------------------|

        |       EAPoL Packet       |   CAPWAP Packet            |

        |                          |      |                     |  

        |                          |      | +-----------------------+

        |                          |       \|- EAPoL Frame          |

      Receive                      |        +-----------------------+

       GTK                         |                            |

        |                          |                            |

        |                          |                            |

        |                      Message-4                        |

        |------------------------->|--------------------------->|

        |       EAPoL Packet       |         CAPWAP Packet      |

        |                          |                            |

 

Case specified by RFC 4564:

The 802.11i Considerations requirement considers the case where 802.11i

authentication is at AC and 802.11i crypto is at WTP. So now, the WTP

maintains the KeyRSC while the AC requires this information to generate

the EAPoL frame for Message-3 of the 4-way handshake. 

The diagram below shows this;

                            - 802.11i Crypto           

                         (KeyRSC maintained here)      - 802.11i
Authentication

   +----------+                 +-----+                     +------+

   | Terminal |                 | WTP |                     |  AC  |

   +----------+                 +-----+                     +------+

        |                          |                            |

        |                    802.1x Authentication              |

        |<=====================================================>|

        |                          |                            |

       PMK                         |                           PMK

        |                          |                            |

      Generate                     |                        Generate

       SNonce                      |                         ANonce

        |                          |                            |

In this case, the EAPoL frame generated by the AC will not be based on

the prevailing value of the KeyRSC, as this counter is maintained by 

the WTP. 

This problem is currently not solved in the CAPWAP specifications. 

Proposal:

The proposal is to include a CAPWAP Key Configuration message that can

transport the EAPoL frame between AC and WTP before being sent to the 

client (terminal). 

Key Configuration is a control message sent by the AC to the WTP. The 

message contains Message-3 of the 4-way handshake - including the 

EAPoL-frame. However, the EAPoL frame has its KeyMIC field unassigned as

the AC cannot accurately calculate this.

So on receiving the Key Configuration - containing EAPoL frame with

unassigned KeyMIC field, the WTP retrieves the value of the KeyRSC it

maintains and computes the corresponding KeyMIC. 

The EAPoL frame is then updated and Message-3 of the 4-way handshake is

reconstructed before being sent over the wireless link to the client. 

The diagram below illustrates this;

                            - 802.11i Crypto           

                         (KeyRSC maintained here)      - 802.11i
Authentication

   +----------+                 +-----+                     +------+

   | Terminal |                 | WTP |                     |  AC  |

   +----------+                 +-----+                     +------+

        |                          |                            |

        |                    802.1x Authentication              |

        |<=====================================================>|

        |                          |                            |

       PMK                         |                           PMK

        |                          |                            |

      Generate                     |                        Generate

       SNonce                      |                         ANonce

        |                          |                            |

        |                          |                            |

        |                      Message 1                        |

        |<-------------------------|<---------------------------|

        |       EAPoL Packet       |        CAPWAP Packet       |

      Receive                      |                            |

       ANonce                      |                            |

      Generate                     |                            |

       PTK                         |                            |

        |                          |                            |

        |                      Message 2                        |

        |------------------------->|--------------------------->|

        |       EAPoL Packet       |        CAPWAP Packet       |

        |                          |                        Receive

        |                          |                        SNonce

        |                          |                            |

        |                          |                       Generate

        |                          |                          PTK

        |                          |                          GTK

        |                          |          Message 3         |

        |                          |<===========================|

        |                          |        CAPWAP Packet       |

        |                          |      (Key Configuration)   |

        |                          |      | +-----------------------+

        |                          |       \|- GTK-Flag             |

        |                 -Retrieve KeyRSC  |- Encryption-Data(PTK) |

        |                 -Update KeyMIC    |- Encryption-Data(GTK) |

        |                 -Reconstruct      |- EAP-Frame            |

        |                     Message-3     +-----------------------+

        |                          |                            |

        |<-------------------------|                            |

        |       EAPoL Packet       |                            |

     Receive                       |                            |

      GTK                          |                            | 

        |                      Message 4                        |

        |------------------------->|--------------------------->|

        |       EAPoL Packet       |        CAPWAP Packet       |

        |                          |                            |

This proposal very simply solves the problem while directly addressing 

the requirement for IEEE 802.11i Considerations.

Cheers,

Saravanan

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 15 Sep 2006 10:35:53 -0700

The "protocol" performs the function of 802.1X/802.11i without any
issues in both the SplitMAC and LocalMAC operation. 

Are you stating this is required because RFC4564 states that flexibility
is required, or because there is an actual need for this feature?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Saravanan Govindan [mailto:[email-masked]] 
> Sent: Friday, September 15, 2006 9:00 AM
> To: Pat Calhoun (pacalhou); [email-masked]
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i 
> Considerations
> 
> I want to emphasize that this is not an "additional" feature 
> - it is a mandatory requirement from RFC 4564. The protocol 
> currently does not meet the requirement.
> 
> Saravanan
> 
> 
> 
> ----Original Message Follows----
> From: "Pat Calhoun (pacalhou)" <[email-masked]>
> To: "Saravanan Govindan" 
> <[email-masked]>,<[email-masked]>
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i 
> Considerations
> Date: Fri, 15 Sep 2006 08:01:32 -0700
> 
> I understand the proposal, but stand firm on my belief that 
> this additional mode of operation is unnecessary. While it is 
> possible to implement, as everything is in a protocol, I 
> believe the WG needs to focus on fixing the protocol in the 
> areas where it is broken, as opposed to adding more optional 
> modes that really do not change the outcome of the functions.
> 
> Perhaps what would be more useful is not to describe the 
> method, but the reason why this is being proposed. I still 
> fail to understand why you believe this mode of operation is 
> necessary.
> 
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> 
> 
> 
> 
> ________________________________
> 
> 	From: Saravanan Govindan
> [mailto:[email-masked]]
> 	Sent: Friday, September 15, 2006 2:03 AM
> 	To: [email-masked]
> 	Subject: [Capwap] Issue 43 - Explanation for 802.11i 
> Considerations
> 
> 
> 
> 	All,
> 
> 
> 	I wanted to give a more detailed explanation for the 
> IEEE 802.11i Considerations requirement. This note describes 
> how CAPWAP can be updated to satisfy this requirement
> 
> 
> 
> 	                                                  - 
> 802.11i Authentication
> 	                                                  - 
> 802.11i Crypto
> (KeyRSC maintained here)
> 	        |                          |
> |
> 	        |                    802.1x Authentication
> |
> 	        |                          |
> |
> 	       PMK                         |
> PMK
> 	        |                          |
> |
> 	      Generate                     |
> Generate
> 	       SNonce                      |
> ANonce
> 	        |                          |
> |
> 	        |                          |
> |
> 	        |                      Message-1
> |
> 	      Receive                      |
> |
> 	       ANonce                      |
> |
> 	      Generate                     |
> |
> 	       PTK                         |
> |
> 	        |                          |
> |
> 	        |                      Message-2
> |
> 	        |                          |
> Receive
> 	        |                          |
> SNonce
> 	        |                          |
> |
> 	        |                          |
> Generate
> 	        |                          |
> PTK
> 	        |                          |
> GTK
> 	        |                      Message-3
> |
> |
> +-----------------------+
> 
> 	        |                          |       \|- EAPoL Frame
> |
> 
> 	      Receive                      |
> 	       GTK                         |
> |
> 	        |                          |
> |
> 	        |                          |
> |
> 	        |                      Message-4
> |
> 	        |                          |
> |
> 	        |                          |
> |
> 	        |                    802.1x Authentication
> |
> 	        |                          |
> |
> 	       PMK                         |
> PMK
> 	        |                          |
> |
> 	      Generate                     |
> Generate
> 	       SNonce                      |
> ANonce
> 	        |                          |
> |
> 	        |                          |
> |
> 	        |                    802.1x Authentication
> |
> 	        |                          |
> |
> 	       PMK                         |
> PMK
> 	        |                          |
> |
> 	      Generate                     |
> Generate
> 	       SNonce                      |
> ANonce
> 	        |                          |
> |
> 	        |                          |
> |
> 	        |                      Message 1
> |
> 	      Receive                      |
> |
> 	       ANonce                      |
> |
> 	      Generate                     |
> |
> 	       PTK                         |
> |
> 	        |                          |
> |
> 	        |                      Message 2
> |
> 	        |                          |
> Receive
> 	        |                          |
> SNonce
> 	        |                          |
> |
> 	        |                          |
> Generate
> 	        |                          |
> PTK
> 	        |                          |
> GTK
> 	        |                          |          Message 3
> |
> 	        |                          |        CAPWAP Packet
> |
> 	        |                          |      (Key Configuration)
> |
> +-----------------------+
> 
> 	        |                          |       \|- GTK-Flag
> |
> 
> 	        |                 -Retrieve KeyRSC  |-
> Encryption-Data(PTK) |
> 
> 	        |                 -Update KeyMIC    |-
> Encryption-Data(GTK) |
> 
> 	        |                          |
> |
> 	        |       EAPoL Packet       |
> |
> 	     Receive                       |
> |
> 	      GTK                          |
> |
> 	        |                      Message 4
> |
> 	        |                          |
> |
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 15 Sep 2006 11:43:55 -0700

As an aside, issue 43 was closed. Issue 199 was opened some time ago and
was being used to track this issue.

Pat Calhoun

> From: Pat Calhoun (pacalhou) 
> Sent: Friday, September 15, 2006 10:36 AM
> To: Saravanan Govindan; [email-masked]
> The "protocol" performs the function of 802.1X/802.11i 
> without any issues in both the SplitMAC and LocalMAC operation. 
> 
> Are you stating this is required because RFC4564 states that 
> flexibility is required, or because there is an actual need 
> for this feature?
> 
> Pat Calhoun
> > I understand the proposal, but stand firm on my belief that this 
> > additional mode of operation is unnecessary. While it is 
> possible to 
> > implement, as everything is in a protocol, I believe the WG 
> needs to 
> > focus on fixing the protocol in the areas where it is broken, as 
> > opposed to adding more optional modes that really do not change the 
> > outcome of the functions.
> > 
> method, but 
> > the reason why this is being proposed. I still fail to 
> understand why 
> > you believe this mode of operation is necessary.
> > 
> > 
> > Pat Calhoun
> > |<===========================|
> > 
> > 	        |                          |        CAPWAP Packet
> > |
> > 
> > 	        |                          |      (Key Configuration)
> > |
> > 
> > 	        |                          |      |

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sun, 17 Sep 2006 21:06:30 -0700

My thoughts is that the protocol, as defined today, can provide complete
support for 802.11i in both Local and Split MAC. So while we may have
agreed on a requirement, my objective is to try to keep the protocol as
simple as possible. I do not see making this change as necessary,
because there is nothing the protocol is unable to do today.
Furthermore, I do not see making this change as necessary, because it
would introduce additional optional features in the protocol - and
consequently increase complexity.

So I disagree with your comment of not confusing between need and stated
requirement. When we agreed on requirements, I'm not sure we all
understood how they could be interpreted. I believe we have a very
flexible approach today.

so my thought is that if we believe we need to interpret the requirement
in the way you have, this requirement is not required. If we interpret
the requirement the way I have (see above), then we have already.

Pat Calhoun

> From: Saravanan Govindan [mailto:[email-masked]] 
> Sent: Sunday, September 17, 2006 7:24 PM
> Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i 
> Considerations
> 
> 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. 
> 
> The proposal is a way to realize this requirement. 
> 
> Let's not confuse between actual need and stated 
> requirements. We achieved consensus on the mandatory 
> requirement because there is indeed a need for it. 
> 
> Given that this topic has been discussed for a while, I would 
> really like to understand your concerns. What are your 
> thoughts on realizing this requirement? 
> 
> Saravanan
> 
> 
> 
> 
> 
> 
> From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
> Sent: Saturday, September 16, 2006 1:36 AM

---

From: "Saravanan Govindan" <[email-masked]>
Date: Mon, 18 Sep 2006 16:08:17 +0800

Pat,

The requirement goes beyond distinguishing local / split MAC support. It
is explicit in the need to support authenticator and cyrpto elements
located at AC and WTP, respectively. 

I find it difficult to interpret it in another way. 

I do not think it is right to arbitrarily dismiss a compulsory
requirement. 

The fundamental goal of RFC4564 was to put forth key requirements that
the protocol has to satisfy. It is a "MUST" - I do not see why we are
having this extensive discussion. 

Saravanan

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Monday, September 18, 2006 12:07 PM
To: Saravanan Govindan; [email-masked]
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Pat Calhoun

---

From: Behcet Sarikaya <[email-masked]>
Date: Sun, 24 Sep 2006 14:18:43 -0700 (PDT)

I would vote for Option 3:
802.11i requires Key RSC value to be set to starting sequence number that the Authenticator’s STA will use in MPDUs protected by GTK.
The fix would be to add Key RSC field (8 octets)
in IEEE 802.11 Mobile Session Key message element 
and add some behaviour like AC sends the value (key RSC) it used during 4-way
handshake together with the key.
--behcet

----- Original Message ----
From: T. Charles Clancy <[email-masked]>
To: T Sridhar <[email-masked]>
Cc: Margaret Wasserman <[email-masked]>; [email-masked]
Sent: Saturday, September 23, 2006 12:15:30 PM
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

I think all the discussions about the requirements and taxonomy, etc, 
overcomplicate the matter.  It's a simple technical point in the protocol.

First of all, this applies to the scenario where split-mac is being used, 
and the WTP is performing the packet encryption/decryption.

Saravanan's point:  In order to perform the 4-way handshake, the AC needs 
to know the KeyRSC.  In the aforementioned scenario, the KeyRSC resides at 
the WTP.  This has nothing to do with optional features; as-is the 
protocol just plain won't work.

It seems to me that the WG has a couple options:

1. Decide that Saravanan's point is technically incorrect, and not inline
    with 802.11i.
2. Decide that we don't want to support split-mac with the WTP doing the
    packet crypto.
3. Fix the protocol by having some message to sync the KeyRSC values.

Without rereading 802.11i, I think Saravanan has a point, and we should 
fix the protocol.  Of course, Cisco has working code that somehow operates 
in this scenario.  Perhaps Pat and Bob could fill us in on how the KeyRSC 
is handled in existing systems?  Perhaps different KeyRSC values are used, 
and the client supplicants just don't notice?

Unfortunately for the next few weeks my Internet connection is through an 
extremely slow WiFi network (motivation to finish CAPWAP) that would 
probably implode upon itself if I tried to download the 11i spec (oh the 
irony).  Without that as a reference, I can't speak with very much 
authority.

--
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

---

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

It should be rejected because the CAPWAP protocol, as defined, is
capable of supporting the 802.11i protocol as is. It is capable of
providing crypto both at the WTP, as well as in the AC. Both Split and
Local MAC are implemented.

Pat Calhoun

> From: T Sridhar [mailto:[email-masked]] 
> Sent: Friday, September 22, 2006 3:18 PM
> To: Margaret Wasserman; [email-masked]
> Hi,
> It would be good to get a summary of the reasons why this proposal
> 
> should be accepted or rejected. Currently we have a number of email
> 
> threads on this topic but a summary would be great. Saravanan/Pat -
> 
> could you folks help?
> 
> 
> 
> Thanks,
> 
> Sridhar
> 
> 
> 
> 
> 
> From: Margaret Wasserman [mailto:[email-masked]] 
> 
> Sent: Friday, September 22, 2006 3:12 PM
> 
> To: [email-masked]
> 
> 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:
> 
> 
> 
> > 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
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> > From: Margaret Wasserman [mailto:[email-masked]]
> 
> > Sent: Thursday, September 21, 2006 8:26 PM
> 
> > To: Saravanan Govindan
> 
> > Cc: Pat Calhoun (pacalhou); [email-masked]
> 
> > 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,
> 
> >>
> 
> >> 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
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> 
> 
> Legal Disclaimer:
> The information contained in this message may be privileged 
> and confidential. It is intended to be read only by the 
> individual or entity to whom it is addressed or by their 
> designee. If the reader of this message is not the intended 
> recipient, you are on notice that any distribution of this 
> message, in any form, is strictly prohibited. If you have 
> received this message in error, please immediately notify the 
> sender and delete or destroy any copy of this message
>

---

From: "Cheng Hong" <[email-masked]>
Date: Mon, 25 Sep 2006 09:56:58 +0800

Dear all,

I think Charles provided a very good summary of the issue below. 

The issue should be clarified in two steps:

First of all, (without debating on whether the scenario is optional or
not), could Pat or Bob provide a technical explanation on how the
scenario pointed out by Saravanan is supported by the current CAPWAP
specification? (since Pat and Bob have been claiming that "So we already
support both modes of operation already.") I don't think something like
"our products do not do it that way" is adequate for that. The WG should
build a consensus on this point first, i.e. if this is TECHNICALLY a
non-issue. This is option 1 in Charles's email. 

After that, in case the CAPWAP specification as for now cannot support
the scenario, the WG could look into how to fix the problem: either to
dismiss the scenario (option 2 in Charles's email), or to add some
mechanism to cope with the scenario (option 3 in Charles's). For both of
the options, I see a need to modify the current specification, i.e. for
option 2, a statement should be included to specifically dismiss the
scenario. 

Personally, I would think option 3 is the choice, since the scenario
does pose a problem for the current specification. Of course, I would
leave the technical analysis to our experts in 802.11.

cheers

Cheng Hong

> From: T. Charles Clancy [mailto:[email-masked]] 
> Sent: Sunday, September 24, 2006 1:16 AM
> To: T Sridhar
> Cc: Margaret Wasserman; [email-masked]
> I think all the discussions about the requirements and 
> taxonomy, etc, overcomplicate the matter.  It's a simple 
> technical point in the protocol.
> 
> First of all, this applies to the scenario where split-mac is 
> being used, and the WTP is performing the packet 
> encryption/decryption.
> 
> Saravanan's point:  In order to perform the 4-way handshake, 
> the AC needs to know the KeyRSC.  In the aforementioned 
> scenario, the KeyRSC resides at the WTP.  This has nothing to 
> do with optional features; as-is the protocol just plain won't work.
> 
> Without rereading 802.11i, I think Saravanan has a point, and 
> we should fix the protocol.  Of course, Cisco has working 
> code that somehow operates in this scenario.  Perhaps Pat and 
> Bob could fill us in on how the KeyRSC is handled in existing 
> systems?  Perhaps different KeyRSC values are used, and the 
> client supplicants just don't notice?
> 
> Unfortunately for the next few weeks my Internet connection 
> is through an extremely slow WiFi network (motivation to 
> finish CAPWAP) that would probably implode upon itself if I 
> tried to download the 11i spec (oh the irony).  Without that 
> as a reference, I can't speak with very much authority.
> 
> --

---

From: "Saravanan Govindan" <[email-masked]>
Date: Tue, 26 Sep 2006 00:24:07 +0800

Hi Sridhar,

To summarize, the current CAPWAP specifications will not allow the 4-way
handshake to be correctly operated in the case where authenticator is at
the AC and cyrpto element is at the WTP - the KeyRSC is maintained at
the point of the crypto element. 

The reason is that the 4-way handshake requires KeyRSC information that
is unavailable to the AC since the KeyRSC is maintained by the WTP. 

I hope this helps summarize the issue.

Cheers,

Saravanan

-----Original Message-----
From: T Sridhar [mailto:[email-masked]] 
Sent: Saturday, September 23, 2006 6:18 AM
To: Margaret Wasserman; [email-masked]
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Hi,

could you folks help?

Thanks,

Sridhar

-----Original Message-----

To: [email-masked]

Hi All,

discussion or not...

Saravanan has made a proposal for change to the specification, and he  

(see below).

see strong support for this proposal, we'll have to conclude that the  

Margaret

> Now, the 4-way handshake requires knowing the value of KeyRSC sequence

> counter. The KeyRSC helps both authenticator and supplicant keep track

> 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

> not know the value of the KeyRSC. The KeyRSC is maintained by the WTP.

> (AC) to use the correct prevailing value of KeyRSC (maintained by the

> 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

> 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

Legal Disclaimer:

The information contained in this message may be privileged and
confidential. It is intended to be read only by the individual or entity
to whom it is addressed or by their designee. If the reader of this
message is not the intended recipient, you are on notice that any
distribution of this message, in any form, is strictly prohibited. If
you have received this message in error, please immediately notify the
sender and delete or destroy any copy of this message

---

From: "Saravanan Govindan" <[email-masked]>
Date: Tue, 26 Sep 2006 00:41:19 +0800

Hi Margaret,

You provide a very thorough summary of the issue!

I am pasting only a portion of your note here;
 
> Saravanan, could you provides some technical information that  
> supports your position that the KeyRSC will reside on the WTP when  
> the encryption end-point is on the WTP?

As a sequence counter, the KeyRSC is used to track frames over the
wireless channel. Fundamentally, the KeyRSC is updated only when a frame
is exchanged over the channel. So in the CAPWAP architecture; 

AC <-> WTP <-> Wireless

The WTP "neighbours" the wireless channel. So it is the WTP that will
maintain the KeyRSC. 

Cheers,

Saravanan

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Saturday, September 23, 2006 9:36 PM
To: T Sridhar
Cc: [email-masked]
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Hi All,

[Pat and Saravanan, I have asked some questions of each of you  
below.  In particular, please note the request for more information  
at the end of the main message, before the beginning of the  
references section.]

At T. Sridhar's request, I'll attempt to summarize the discussion on  
this issue to date.
.
.
.
.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 25 Sep 2006 09:39:31 -0700 (PDT)

Are you saying that the RSC value can not be set by AC? I fail to understand it because the user (STA) is new under this WTP anyways.

--behcet

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

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,

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. 

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. 

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:

On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote:

> authenticator is at the AC and crypto elements are at the WTP. This is
> the requirement.

Thanks,
Margaret

---

From: "Saravanan Govindan" <[email-masked]>
Date: Tue, 26 Sep 2006 00:48:39 +0800

Pat,

I have asked both Bob and yourself to clarify how the current
specifications allow 802.11i to operate in the case under consideration.
Sujay has made another note on this. 

We are still waiting to get substantive explanation on how the protocol
currently does this. 

Saravanan

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Monday, September 25, 2006 9:16 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

> Sent: Friday, September 22, 2006 2:03 AM
> To: Margaret Wasserman
> 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.
> 
> 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. 
>

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Tue, 26 Sep 2006 11:31:59 -0700

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:[email-masked]] 
Sent: Monday, September 25, 2006 11:37 AM
To: Peter Nilsson J (LI/EAB)
Cc: [email-masked]
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.

Considerations
does
Considerations

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 26 Sep 2006 13:45:18 -0700 (PDT)

So, Bob, communicating the key RSC value to WTP would not hurt, would it?
Or something to this effect, like AC initializing to zero of the group key KeyRSC of all WTPs?

Regards,

--behcet

----- Original Message ----
From: Bob O'Hara (boohara) <[email-masked]>
To: T. Charles Clancy <[email-masked]>; Peter Nilsson J (LI/EAB) <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, September 26, 2006 1:31:59 PM
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Charles, Peter,

-Bob 
-----Original Message-----
From: T. Charles Clancy [mailto:[email-masked]] 
Sent: Monday, September 25, 2006 11:37 AM
To: Peter Nilsson J (LI/EAB)
Cc: [email-masked]
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Considerations
does
Considerations

---

From: "Cheng Hong" <[email-masked]>
Date: Wed, 27 Sep 2006 09:03:04 +0800

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

> From: Bob O'Hara (boohara) [mailto:[email-masked]] 
> Sent: Wednesday, September 27, 2006 2:32 AM
> To: T. Charles Clancy; Peter Nilsson J (LI/EAB)
> Cc: [email-masked]
> 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
> 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 
> 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 
> 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
> 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.
> 
> --
> >> 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: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 27 Sep 2006 08:45:48 -0700

We could send the communicated value to the WTP via the means we
currently communicate the Pairwise RSC value.

Pat Calhoun

	From: Behcet Sarikaya [mailto:[email-masked]] 
	Sent: Tuesday, September 26, 2006 1:45 PM
	To: Bob O'Hara (boohara)
	Cc: [email-masked]
	Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
Considerations

	So, Bob, communicating the key RSC value to WTP would not hurt,
would it?
	Or something to this effect, like AC initializing to zero of the
group key KeyRSC of all WTPs?
	 
	Regards,
	 
	--behcet

	----- Original Message ----
	From: Bob O'Hara (boohara) <[email-masked]>
	To: T. Charles Clancy <[email-masked]>; Peter Nilsson J
(LI/EAB) <[email-masked]>
	Cc: [email-masked]
	Sent: Tuesday, September 26, 2006 1:31:59 PM
	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.

	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:[email-masked]] 
	Sent: Monday, September 25, 2006 11:37 AM
	To: Peter Nilsson J (LI/EAB)
	Cc: [email-masked]
	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.  |  [email-masked]  |
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
	> the groupkey handshake was sent the WTP inserted the correct
RSC
	before
	Considerations
	> authenticator element is at the AC and the 802.11i crypto
element is
	at
	> Now, the 4-way handshake requires knowing the value of KeyRSC
sequence
keep track
the crypto
	does
	> Based on this, the current CAPWAP specification does not allow
for a
	way
	> One way to introduce this functionality in to CAPWAP is to
have part
	of
the 4-way
	Considerations
	>> authenticator is at the AC and crypto elements are at the
WTP. This
	is
	> necessary?  it will not be helpful to my understanding to
re-send
decide on
	
_________________________________________________________________
	To unsubscribe or modify your subscription options, please
visit:
	http://lists.frascone.com/mailman/listinfo/capwap

_________________________________________________________________
	To unsubscribe or modify your subscription options, please
visit:
	http://lists.frascone.com/mailman/listinfo/capwap

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Wed, 27 Sep 2006 13:27:28 -0700

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:[email-masked]] 
Sent: Tuesday, September 26, 2006 6:03 PM
To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson J (LI/EAB)
Cc: [email-masked]
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Hi Bob,

cheers

Cheng Hong

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 27 Sep 2006 10:38:32 -0700

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

> 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. 
> 
> 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
> 
> 
>  
> 
> topic that I 
> > 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.
> > 
> > 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
> > newly associated STA.
> necessary 
> > for the AC and WTP to exchange any information about the group key 
> > KeyRSC for the protocol to operate as it is intended.
> > 
> > 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.
> > 
> > EAPOL-key frame to validate frame using the KeyMIC.
> > 
> > received in KeyRSC, say, zero.
> > 
> > 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
> 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.
> > 
> > address the issue raised by Saranavan.
> > 
> >  -Bob
> > traffic and grabs the KeyRSC value and uses it to 
> initialize its own 
> > counter.
> > 
> > with Saravanan that I've yet to see a technical description of how 
> > Cisco implements it.
> > 
> have the AC 
> allow for a
> > > One way to introduce this functionality in to CAPWAP is 
> to have part
> > of
> > >> authenticator is at the AC and crypto elements are at 
> the WTP. This
> > is
> > >> the requirement.
> > >

---

From: "Cheng Hong" <[email-masked]>
Date: Thu, 28 Sep 2006 09:50:20 +0800

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

> Sent: Thursday, September 28, 2006 1:39 AM
> To: Cheng Hong; Bob O'Hara (boohara); T. Charles Clancy; 
> Peter Nilsson J (LI/EAB)
> Cc: [email-masked]
> 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
> > 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.
> > 
> 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.
> > 
> > revision? (since based on your description, there is essentially no 
> > use of the KeyRSC).
> > 
> > cheers
> > 
> > Cheng Hong
> > 
> > 
> >  
> > 
> frames to 
> proceed to 
> KeyRSC and

---

From: "Saravanan Govindan" <[email-masked]>
Date: Thu, 28 Sep 2006 21:03:42 +0800

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:[email-masked]] 
Sent: Wednesday, September 27, 2006 2:32 AM
To: T. Charles Clancy; Peter Nilsson J (LI/EAB)
Cc: [email-masked]
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Charles, Peter,

 -Bob 
-----Original Message-----
From: T. Charles Clancy [mailto:[email-masked]] 
Sent: Monday, September 25, 2006 11:37 AM
To: Peter Nilsson J (LI/EAB)
Cc: [email-masked]
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Considerations
does
Considerations

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Thu, 28 Sep 2006 10:35:59 -0700

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:[email-masked]] 
Sent: Thursday, September 28, 2006 6:04 AM
To: Bob O'Hara (boohara); T. Charles Clancy; Peter Nilsson J (LI/EAB)
Cc: [email-masked]
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Saravanan

-----Original Message-----
From: Bob O'Hara (boohara) [mailto:[email-masked]] 
Sent: Wednesday, September 27, 2006 2:32 AM
To: T. Charles Clancy; Peter Nilsson J (LI/EAB)
Cc: [email-masked]
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Charles, Peter,

 -Bob 
-----Original Message-----
From: T. Charles Clancy [mailto:[email-masked]] 
Sent: Monday, September 25, 2006 11:37 AM
To: Peter Nilsson J (LI/EAB)
Cc: [email-masked]
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Considerations
does
Considerations

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Thu, 28 Sep 2006 11:13:49 -0700

Michael,
 
This is entirely unnecessary, as 802.11i requires the TSC (KeyRSC) to be
initialized to a fixed value, i.e., the first frame encrypted with the
new key MUST use the value of 1 for the sequence counter.

 -Bob

From: Michael Montemurro [mailto:[email-masked]] 
Sent: Wednesday, September 27, 2006 4:45 PM
To: Bob O'Hara (boohara)
Cc: Behcet Sarikaya; [email-masked]
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Actually, in CAPWAP-02, the keyRSC is sent to the WTP on the group key
update.
 
But as yet, we have left the Oxford English Dictionary out. :-)
 
Cheers,
 
Mike

On 9/27/06, Bob O'Hara (boohara) <[email-masked]> wrote: 

	Bechet, 
	 
	no, it would not hurt.  <sarcasm>But it is completely
unnecessary, as is sending a copy of the Oxford English Dictionary to
the WTP.  but, we could do that, too.</sarcasm> 

	 -Bob

	
	 
	Regards,
	 
	--behcet

	----- Original Message ----
	From: Bob O'Hara (boohara) < [email-masked]
<mailto:[email-masked]> >
	To: T. Charles Clancy <[email-masked]>; Peter Nilsson J
(LI/EAB) < [email-masked]
<mailto:[email-masked]> >
	
	Cc: [email-masked]

	Charles, Peter,

	key to use the sequence counter value of 1.  See 8.3.2.6
<http://8.3.2.6/>  c) and

	

	

	

	-Bob 
	-----Original Message-----
	From: T. Charles Clancy [mailto:[email-masked]] 
	Sent: Monday, September 25, 2006 11:37 AM
	To: Peter Nilsson J (LI/EAB) 
	Cc: [email-masked]
	Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i
Considerations

	
	
	--
	t. charles clancy, ph.d.  |   [email-masked] <mailto:[email-masked]>
|  www.cs.umd.edu/~clancy

impelementation of
	the
RSC
	before
	> From: Saravanan Govindan [mailto:
[email-masked]
<mailto:[email-masked]> ]
	Considerations
element is
	at
sequence
keep track
the crypto
	does
for a 
	way
have part
	of
the 4-way
	Considerations
WTP. This
	is
re-send
decide on

---

From: "Saravanan Govindan" <[email-masked]>
Date: Fri, 29 Sep 2006 08:41:12 +0800

Hi Cheng Hong,

Following from your note, there seem to be too many holes in the
proposal to set a pre-established value to KeyRSC. I suggest we move
forward by considering alternatives to this issue. 

Cheers,

Saravanan

 

  _____  

From: Cheng Hong 
Sent: Friday, September 29, 2006 8:34 AM
To: Bob O'Hara (boohara); Dorothy Stanley
Cc: Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB);
[email-masked]; Saravanan Govindan
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations

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:[email-masked]] 
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); [email-masked]
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:[email-masked]] 
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); [email-masked]
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) <[email-masked]> 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:[email-masked]]
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: [email-masked]

Hi Pat and all,

cheers

Cheng Hong

> From: Pat Calhoun (pacalhou) [mailto: [email-masked]]
> > From: Cheng Hong [mailto: <mailto:[email-masked]>
[email-masked]]

---

From: "Saravanan Govindan" <[email-masked]>
Date: Sat, 30 Sep 2006 09:15:18 +0800

Bringing in the government to deviate from technical discussion is not productive. 

I still do not understand why a protocol standard should specify parameter values. We should consider other options for this.

Saravanan

________________________________________
From: Bob O'Hara (boohara) [mailto:[email-masked]] 
Sent: Saturday, September 30, 2006 12:10 AM
To: Cheng Hong; Dorothy Stanley
Cc: Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); [email-masked]; Saravanan Govindan
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations

I am afraid that requesting design assistance from a competitor is very close to violation of U.S anti-trust laws.  I will not describe how Cisco has designed any of its products and I cannot help you design yours.
 
Again, your proposal does not eliminate any attack mechanism and does not add any functionality to the protocol, only cost and complexity.  A replayed frame will be discarded by the MAC, using the normal duplicate frame detection mechanisms.  See section 8.3.3.3.2 of 802.11i (where the frame sequence number is part of the additional authenticated data) and section 9.2.9 of 802.11-1999 for the description of these functions.  And PLEASE read 802.11 and 802.11i before again asserting that this proposal is necessary.
 
As I said several emails ago, the ONLY effect of using zero as the value for the KeyRSC is that the 802.11 chipset in the STA (client) will have to receive the frame, attempt to decrypt it, and validate the MIC.  This must be done for EVERY frame received, whether it is a replayed frame or not.  This set of functions is performed in the 802.11 STA chipset and does not consume any additional resources of the STA.  So, the attack, if it can even be characterized as an attack, is no more effective at DOSing the STA than sending it any other frame.
 -Bob

________________________________________
From: Cheng Hong [mailto:[email-masked]] 
Sent: Thursday, September 28, 2006 5:34 PM
To: Bob O'Hara (boohara); Dorothy Stanley
Cc: Pat Calhoun (pacalhou); T. Charles Clancy; Peter Nilsson J (LI/EAB); [email-masked]; Saravanan Govindan
Subject: RE: [Capwap] Issue 43 - Explanation for 802.11i Considerations
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:[email-masked]] 
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); [email-masked]
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:[email-masked]] 
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); [email-masked]
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

-Bob

-----Original Message-----
From: Cheng Hong [mailto:[email-masked]]
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: [email-masked]

Hi Pat and all,

cheers

Cheng Hong

> > From: Cheng Hong [mailto: [email-masked]]