Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations

From: "Saravanan Govindan" <[email-masked]>
Date: Thu, 6 Jul 2006 17:57:33 +0800

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

---

From: "Michael Montemurro" <[email-masked]>
Date: Tue, 18 Jul 2006 21:58:38 -0400

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 <[email-masked]> wrote:
> EAPoL frames generated at the AC alone – not at the WTP.
>
>
>
> 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.
>
>
>
>  ------------------------------
>
> *From:* Michael Montemurro [mailto:[email-masked]]
> *Sent:* Tuesday, July 04, 2006 9:47 PM
> *To:* Saravanan Govindan
> *Cc:* capwap
>
> *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderations
>
>
>
> Saravanan,
>
>
>
> 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.
>
> On 7/3/06, *Saravanan Govindan* <[email-masked]>
> wrote:
>
> Hi Mike,
>
>
>
> 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.
>
>
>
> 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).
>
>
>
>  ------------------------------
>
> *From:* Michael Montemurro [mailto: [email-masked]]
> *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.11iConsiderations
>
>
>
> Saravanan,
>
>
>
> 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
>
>
>