Re: Clarification of Issue 43: IEEE 802.11i Considerations
From: Bob O'Hara (boohara) (booharacisco.com)
Date: Sun, 4 Jun 2006 10:45:02 -0700 (PDT)
Mike,
 
I assume you mean the approved 802.11i-2004 amendment, not the latest draft.  If anyone needs a copy of this document, it is available for free download (registration required) from the following URL:
 
http://standards.ieee.org/getieee802
 
 -Bob
 
 


From: Michael Montemurro [mailto:montemurro.michael [at] gmail.com]
Sent: Saturday, June 03, 2006 11:05 AM
To: Saravanan Govindan
Cc: capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations

Saravanan,
 
I took a look again at the latest draft for IEEE 802.11i, and as I understand it, the GTK 1 message needs the sequence number of the
last transmitted broadcast frame.
 
In the split MAC case, the AC should know the sequence number because it would set it. In the local MAC case, the AC would have to
query the WTP for the sequence number.
 
So, I believe what you require is a mechanism for the AC to query the WTP for the sequence number in the local MAC case. Is that correct?
 
The keyMIC should not be an issue because in either the local MAC or the split MAC case, the AC would have all the information it needs.
The only requirement would be for the AC to hold onto the KEK for the STA to calculate the MIC for the EAPoL frame.
 
Would that be correct?
 
Cheers,
 
Mike
 
On 5/26/06, Saravanan Govindan < Saravanan.Govindan [at] sg.panasonic.com> wrote:
Hi,
 



This is a copy-and-paste from previous email.
 



 
In cases where IEEE 802.11i encryption/decryption is located in a WTP and IEEE 
802.11i authenticator is located in an AC, there is a mismatch in tracking 



KeyRSC values (draft-ietf-capwap-objectives-04.txt) Section 5.1.10. The CAPWAP 
protocol must allow the 4-way and Group-key exchanges to use accurate values 
of KeyRSC and KeyMIC in all cases. 
 


 
My recommendation:



 
Introduce new Key Configuration & Key Configuration Response messages as part 
of Message Types. Key Configuration message will be used to exchange 3rd message (for 4-way exchange & with unassigned KeyMIC and KeyRSC fields) and 1st message (for group-key exchange & with unassigned KeyMIC and KeyRSC fields). 
 
 



 
I was looking for these 2 messages in the new draft. However, I am open to other ways of accomplishing the objective. 
 
Cheers,




Saravanan
 
 

 

 


From: Michael Montemurro [mailto: montemurro.michael [at] gmail.com]
Sent: Friday, May 26, 2006 8:30 AM
To: Pat Calhoun (pacalhou)
Cc: Saravanan Govindan; capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations

 

The only text that I could identify that was missing here was information on how the GTK was handled.

 

If there is more information or clarification, please let me know.

 

Cheers,


Mike
 

On 5/23/06, Pat Calhoun (pacalhou) < pcalhoun [at] cisco.com> wrote:

I have re-opened issue 43, but it would be useful if you could provide a
high level example (outline) of what you would like to see.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems



> -----Original Message-----
> From: Saravanan Govindan [mailto: Saravanan.Govindan [at] sg.panasonic.com ]
> Sent: Tuesday, May 23, 2006 12:24 AM
> To: capwap
> Subject: [Capwap] Clarification of Issue 43: IEEE 802.11i
> Considerations
>
> All,
>
> I believe this issue 43 - also a Mandatory Objective - is
> still open. My suggestion is to update the 802.11 binding
> section to reflect steps local-MAC and split-MAC cases.
>
> Saravanan
>
> _________________________________________________________________
> 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

 


Results generated by Tiger Technologies using MHonArc.