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

From: "Cheng Hong" <[email-masked]>
Date: Thu, 20 Jul 2006 23:39:00 +0800

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:[email-masked]] 
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:[email-masked]] 
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:[email-masked]] 
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:[email-masked]] 
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 <[email-masked]>
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: [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 <
<mailto:[email-masked]>
[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: Thu, 20 Jul 2006 12:04:37 -0400

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 <[email-masked]> wrote:
>  ------------------------------
>  *From:* Pat Calhoun (pacalhou) [mailto:[email-masked]]
> *Sent:* Thursday, July 20, 2006 11:27 PM
> *To:* Saravanan Govindan; Michael Montemurro
> *Cc:* capwap
>
> *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderations
>
>
>
> "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
>  ------------------------------
> *From:* Saravanan Govindan [mailto:[email-masked]]
> *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.11iConsiderations
>
>
>
> 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:[email-masked]]
> *Sent:* Thursday, July 20, 2006 6:30 AM
> *To:* Michael Montemurro; Saravanan Govindan
> *Cc:* capwap
> *Subject:* RE: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderations
>
>
>
> 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
>  ------------------------------
>
> *From:* Michael Montemurro [mailto:[email-masked]]
> *Sent:* Tuesday, July 18, 2006 6:59 PM
> *To:* Saravanan Govindan
> *Cc:* capwap
> *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderations
>
> Saravanan,
>
>
>
> would require additional text as well as an additional negotiation between
> the WTP and the AC.
>
>
>
> 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.
>
>
>
> On 7/6/06, *Saravanan Govindan* <[email-masked]>
> wrote:
>
> Hi Mike,
>
>
>
> Thank you for the note.
>
>
> 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
>
>
>
>
>
>

---

From: Charles Clancy <[email-masked]>
Date: Thu, 20 Jul 2006 19:53:44 -0400

Sending the PMK to the WTP breaks the current security model.  Secure 
handoff between WTPs would require a full 1X reauthentication.  The PMK 
SHOULD NOT be transmitted to the WTP.

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

Michael Montemurro wrote:
> 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.
> 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.
>  
> On 7/20/06, *Cheng Hong* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>         ------------------------------------------------------------------------
>         *From:* Pat Calhoun (pacalhou) [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         ------------------------------------------------------------------------
>         *From:* Saravanan Govindan [mailto:
>         [email-masked]
>         <mailto:[email-masked]>]
>         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: [email-masked]
>         <mailto:[email-masked]>]
>         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
>             ------------------------------------------------------------------------
> 
>             *From:* Michael Montemurro
>             [mailto:[email-masked]
>             <mailto:[email-masked]> ]
>             *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.
> 
>              
> 
>             On 7/6/06, *Saravanan Govindan* <
>             [email-masked]
>             <mailto:[email-masked]>> 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.
> 
>              
> 
>             ------------------------------------------------------------------------
> 
>             *From:* Michael Montemurro [mailto:
>             [email-masked]
>             <mailto:[email-masked]>]
>             *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.
> 
>              
> 
>             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.
> 
>              
> 
>             On 7/3/06, *Saravanan Govindan* <
>             [email-masked]
>             <mailto:[email-masked]>> wrote:
> 
>             Hi Mike,
> 
>              
> 
>             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).
> 
>              
> 
>             ------------------------------------------------------------------------
> 
>             *From:* Michael Montemurro [mailto:
>             [email-masked]
>             <mailto:[email-masked]>]
>             *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
> 
>              
> 
>              
> 
> 
> 
> ------------------------------------------------------------------------
>