Capwap Mailing List: Re: Clarification of Issue 43: IEEE 802.11i Considerations

[Bob O'Hara (boohara) (boohara]

I agree with most of what Michael has written below.  His statements of the assumptions in the -02 draft are correct.  His statement that the solution meets the CAPWAP objectives is also correct.

 

I think that separation of 802.1X state machine to perform one part in the AC and another part in the WTP, i.e, authentication in the AC and EAPOL-Key exchange in the WTP, is a very bad idea.  This portion of the exchange between the WTP and the mobile client device is a time critical period.  Adding one or more additional round trip exchanges between the AC and WTP that are not directly conveying packets to the mobile client does not help to minimize this time critical exchange with the client.

 

Therefore, I also agree that splitting the protocol between AC and WTP is a wish and not a requirement. 

 

The KeyRSC issue, where there has been proposed a negotiation or exchange between AC and WTP is also a wish and not a requirement.  A proper understanding of how the PTK and GTK are established between the authenticator and supplicant shows that the KeyRSC does not need to be known by the AC, even if it is maintained by the WTP.  This might even demote the issue to a bad wish, at that.

 -Bob
 

 

---

From: Michael Montemurro [mailto:montemurro.michael [at] gmail.com]
Sent: Thursday, July 20, 2006 9:05 AM
To: Cheng Hong
Cc: Saravanan Govindan; capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations

I believe the existing draft supports IEEE 802.11i in both Split MAC and local MAC modes.

 

The assumption in CAPWAP-02 is that:

1) The IEEE 802.1X Authenticator and the RADIUS client reside on the AC. I don't see any reason why this should be changed for local or split MAC.

2) RSNA Key Management resides on the AC. The PMK is cached on the AC and EAPoL-Key frames are generated by the AC. I don't see this as a problem for either split MAC or local MAC modes.

3) The PTK and GTK are transmitted to the WTP by the AC.

 

I believe the solution meets the CAPWAP objectives. The solution works for both splitMAC or localMAC modes.

 

Saravanan requested that the keyRSC be maintained at the WTP. I think the best approach to address this is to negotiate between the AC and the WTP so that, upon successful IEEE 802.1X authentication, the PMK is passed from the AC to the WTP. The WTP would then transmit EAPoL-Key frames.

 

I believe this is a request that should be added to the wish list.

 

Thanks,

 

Mike

 

 

On 7/20/06, Cheng Hong <Hong.Cheng [at] sg.panasonic.com> wrote:

Obviously, this is a type of "Split" case. Thus, it has to be "mandatory". Or, the understanding of "mandatory" is different?

 

cheers

 

Cheng Hong

 

---

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