| Re: Clarification of Issue 43: IEEE 802.11i Considerations | <– Date –> <– Thread –> |
From: Bob O'Hara (boohara) (boohara cisco.com)
|
|
| Date: Tue, 25 Jul 2006 08:01:54 -0700 (PDT) | |
Saranavan, I am not disputing your assertion that the RSC is maintained by the WTP. But, my attempt to educate you is over. Please read the 802.11i key exchange protocol and understand it. Once that protocol is understood, the mystery as to why the CAPWAP protocol does not need to provide the RSC from the WTP to the AC will be resolved. There are systems that have been in the field for more than three years that use precursor protocols to CAPWAP. These systems have operated perfectly well without this unnecessary exchange between the AC and WTP. They have also been certified for 802.11i/WPA2 operation by the Wi-Fi Alliance. -Bob -----Original Message----- From: Saravanan Govindan [mailto:Saravanan.Govindan [at] sg.panasonic.com] Sent: Monday, July 24, 2006 6:30 PM To: Bob O'Hara (boohara); capwap [at] frascone.com Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The KeyRSC is in fact maintained by the WTP in the case that requirement 5.1.10 addresses. So when the KeyRSC is maintained at the WTP, how does the AC know which value to use to calculate the KeyMIC? Perhaps the next tutorial can provide insight in to the CAPWAP specifications. Saravanan -----Original Message----- From: Bob O'Hara (boohara) [mailto:boohara [at] cisco.com] Sent: Tuesday, July 25, 2006 12:00 AM To: capwap [at] frascone.com Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations <tutorial mode> 1. A value for the KeyRSC 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. 3. The client STA will use the value of KeyRSC received in the EAPOL-key frame to validate the KeyMIC. 4. The client STA will also set its RSC to the value received in KeyRSC. 5. The value in the client STA's RSC will be compared against the sequence number in subsequent received frames to identify replay attacks. 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. 7. Please see item 6, immediately above, for the reason that the AC and WTP do not need to coordinate and exchange the RSC. </tutorial mode> -Bob -----Original Message----- From: Saravanan Govindan [mailto:saravanang [at] hotmail.com] Sent: Monday, July 24, 2006 8:50 AM To: Bob O'Hara (boohara); capwap [at] frascone.com Cc: saravanan.govindan [at] sg.panasonic.com Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations After reading the specs; there is a need to coordinate in this case. Message 3 of 4-way exchange needs KeyRSC to calculate KeyMIC - if KeyRSC is maintained by WTP, then coordination is needed. I have explained in detail why we need the proposed update with regard to Section 5.1.10. If there is concern that the proposal is not needed, please clarify how the current specifications supports 802.11i when authenticator is handled by AC and encryption / KeyRSC is handled at WTP. Saravanan ----Original Message Follows---- From: "Bob O'Hara (boohara)" <boohara [at] cisco.com> To: "capwap" <capwap [at] frascone.com> Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Date: Mon, 24 Jul 2006 08:38:45 -0700 There is no need to coordinate such values between the AC and WTP. Please read 802.11i to understand how the key exchange protocol operates. -Bob ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan [at] sg.panasonic.com] Sent: Sunday, July 23, 2006 8:02 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The current version of the protocol does not support 5.1.10. There is no means of coordinating KeyRSC values maintained by the WTP and EAPoL frame generation by the AC. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com] Sent: Friday, July 21, 2006 11:15 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The protocol today addresses requirement defined in Section 5.1.10 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan [at] sg.panasonic.com] Sent: Thursday, July 20, 2006 10:44 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations The requirement from Section 5.1.10 of RFC 4564 states that the "protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities." The current protocol draft needs to include operations to support key exchange in such designs. And the feature we've been discussing directly addresses this need. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com] Sent: Thursday, July 20, 2006 11:27 PM To: Saravanan Govindan; Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to understand how you've interpreted this feature as being "mandatory". The current spec supports 802.11i, in both modes of operation that we've agreed to, which is Split and Local MAC. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Saravanan Govindan [mailto:Saravanan.Govindan [at] sg.panasonic.com] Sent: Wednesday, July 19, 2006 11:37 PM To: Pat Calhoun (pacalhou); Michael Montemurro Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations I'd like to clarify that this is indeed a "mandatory" objective and needs to be integral to CAPWAP. Based on the exchanges so far, I think support for this feature can be easily incorporated in to the protocol. We know the protocol needs this (from the requirement) and we know how to do it (from the proposals), so let's just do it and move forward. Saravanan ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com] Sent: Thursday, July 20, 2006 6:30 AM To: Michael Montemurro; Saravanan Govindan Cc: capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations My personal feeling is that this should be considered a "nice to have", and therefore show up in the "wish" tracker category. Given all of the work we have ahead of us, I don't believe there is an urgent need to support this mode of operation, as the current protocol achieves our objectives. So waiting for a future version of the protocol would be my suggestion. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: Michael Montemurro [mailto:montemurro.michael [at] gmail.com] Sent: Tuesday, July 18, 2006 6:59 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, I've given some additional thought to your requirements and I believe it would require additional text as well as an additional negotiation between the WTP and the AC. We could separate the RSNA key management functions from the "classical" IEEE 802.1X authenticator functions and allow the WTP and AC negotiate where these functions reside: The IEEE 802.1X authenticator functions would include the PMK derivation. The PMK would be passed to the WTP upon successful completion of the IEEE 802.1X authentication. The RSNA key management functions would include the 4-way handshake and the generation of GTK updates. I think this is a cleaner mechanism to address your requirements. Does this make sense to you? Cheers, Mike On 7/6/06, Saravanan Govindan <Saravanan.Govindan [at] sg.panasonic.com> wrote: Hi Mike, Thank you for the note. I may not have been clear with my previous post. My request is to have EAPoL frames generated at the AC alone - not at the WTP. My request is for designs where EAPoL frames are generated at the AC and in those where the KeyRSC is maintained in the WTP. These designs were highlighted in the Architecture Taxonomy. Specifically, I suggest that a CAPWAP message (it may be Add WLAN or Update WLAN) be able to carry an EAPoL frame from the AC to the WTP. This EAPoL frame (for Message 3 of 4-way handshake or for Message 1 of group key handshake) would have its KeyRSC field unassigned. Then when the WTP receives this message, it fills in the right value of the KeyRSC, updates the EAPoL frame and then transmit it to the wireless station. I hope this clarifies my suggestion. Cheers, Saravanan ________________________________ From: Michael Montemurro [mailto: montemurro.michael [at] gmail.com] Sent: Tuesday, July 04, 2006 9:47 PM To: Saravanan Govindan Cc: capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, So, you would like to request that the WTP generate EAPoL-Key frames for the 4-way handshake and the GTK update? The current draft assumes that all EAPoL-Key frames are generated at the AC. Based on the following assumptions: 1) This feature would be for local-MAC only. 2) The 4-way handshake and the GTK handshake would originate from the same location. This would then require: 1) Negotiation between the WTP and the AC on where the 4-way handshake and GTK updates are generated. 2) A modification to the updateWLAN message element to include the PMK when a STA successfully associates. I've captured this as issue 199. On 7/3/06, Saravanan Govindan < Saravanan.Govindan [at] sg.panasonic.com <mailto:Saravanan.Govindan [at] sg.panasonic.com> > wrote: Hi Mike, I had a chance to review the new draft. With regard to Issue 43, my understanding is that updates were made in Section 11.9.1 (IEEE 802.11 Add WLAN). In particular, the IEEE 802.11 Add WLAN message element now allows the AC to send sequence counter values to the WTP. So now, CAPWAP can support designs where the KeyRSC is maintained by the AC. My initial concern was with supporting designs where the KeyRSC is maintained by the WTP. This is particularly important to manage the 4-Way and Group-key handshakes. With this in mind, I think the protocol still requires support for designs where the KeyRSC is maintained by the WTP. Based on the current draft, this support can be included by adding another field to the IEEE 802.11 Add WLAN message element. This field would contain Message-3 EAPoL frame (for 4-Way handshake) or Message-1 EAPoL frame (for Group-key handshake). These EAPoL frames would have unassigned fields for KeyRSC (since the value is maintained by the WTP). I am also open to any alternatives to support this. Cheers, Saravanan ________________________________ From: Michael Montemurro [mailto: montemurro.michael [at] gmail.com] Sent: Tuesday, June 20, 2006 10:01 PM To: Saravanan Govindan Cc: Bob O'Hara (boohara); capwap Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Saravanan, I've updated section 11.3 to deal with the GTK exchange and the handling of the KeyRSC in draft -02 to address your comments. I also provided a mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN message element as part of the Group Key exchange. We're finalizing the -02 draft this week and you should be able to look at it when we post it later this week. Cheers, Mike _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap _________________________________________________________________ Get MSN Hotmail alerts on your mobile. http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/capwap Archives: http://lists.frascone.com/pipermail/capwap
- Re: Clarification of Issue 43: IEEE 802.11i Considerations, (continued)
-
Re: Clarification of Issue 43: IEEE 802.11i Considerations Bob O'Hara (boohara), July 24 2006
- Re: Clarification of Issue 43: IEEE 802.11i Considerations Saravanan Govindan, July 24 2006
- Re: Clarification of Issue 43: IEEE 802.11i Considerations Bob O'Hara (boohara), July 24 2006
- Re: Clarification of Issue 43: IEEE 802.11i Considerations Saravanan Govindan, July 24 2006
- Re: Clarification of Issue 43: IEEE 802.11i Considerations Bob O'Hara (boohara), July 25 2006
- Re: Clarification of Issue 43: IEEE 802.11i Considerations Saravanan Govindan, July 25 2006
-
Re: Clarification of Issue 43: IEEE 802.11i Considerations Bob O'Hara (boohara), July 24 2006
Results generated by Tiger Technologies using MHonArc.