Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

From: "Saravanan Govindan" <[email-masked]>
Date: Mon, 18 Sep 2006 10:24:19 +0800

Pat,

The issue here is about how 802.11i exchanges are done when
authenticator is at the AC and crypto elements are at the WTP. This is
the requirement. 

The proposal is a way to realize this requirement. 

Let's not confuse between actual need and stated requirements. We
achieved consensus on the mandatory requirement because there is indeed
a need for it. 

Given that this topic has been discussed for a while, I would really
like to understand your concerns. What are your thoughts on realizing
this requirement? 

Saravanan

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Saturday, September 16, 2006 1:36 AM
To: Saravanan Govindan; [email-masked]
Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

The "protocol" performs the function of 802.1X/802.11i without any
issues in both the SplitMAC and LocalMAC operation. 

Are you stating this is required because RFC4564 states that flexibility
is required, or because there is an actual need for this feature?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Saravanan Govindan [mailto:[email-masked]] 
> Sent: Friday, September 15, 2006 9:00 AM
> To: Pat Calhoun (pacalhou); [email-masked]
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i 
> Considerations
> 
> I want to emphasize that this is not an "additional" feature 
> - it is a mandatory requirement from RFC 4564. The protocol 
> currently does not meet the requirement.
> 
> Saravanan
> 
> 
> 
> ----Original Message Follows----
> From: "Pat Calhoun (pacalhou)" <[email-masked]>
> To: "Saravanan Govindan" 
> <[email-masked]>,<[email-masked]>
> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i 
> Considerations
> Date: Fri, 15 Sep 2006 08:01:32 -0700
> 
> I understand the proposal, but stand firm on my belief that 
> this additional mode of operation is unnecessary. While it is 
> possible to implement, as everything is in a protocol, I 
> believe the WG needs to focus on fixing the protocol in the 
> areas where it is broken, as opposed to adding more optional 
> modes that really do not change the outcome of the functions.
> 
> Perhaps what would be more useful is not to describe the 
> method, but the reason why this is being proposed. I still 
> fail to understand why you believe this mode of operation is 
> necessary.
> 
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> 
> 
> 
> 
> ________________________________
> 
> 	From: Saravanan Govindan
> [mailto:[email-masked]]
> 	Sent: Friday, September 15, 2006 2:03 AM
> 	To: [email-masked]
> 	Subject: [Capwap] Issue 43 - Explanation for 802.11i 
> Considerations
> 
> 
> 
> 	All,
> 
> 
> 	I wanted to give a more detailed explanation for the 
> IEEE 802.11i Considerations requirement. This note describes 
> how CAPWAP can be updated to satisfy this requirement
> 
> 
> 
> 	I would like to use this to highlight the proposal 
> being put forward.
> 
> 
> 
> 
> 
> 
> 
> 	From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations
> 
> 
> 
> 	   Protocol Requirement:
> 
> 
> 
> 	   The CAPWAP protocol MUST determine the exact structure of the
> 
> 	   centralized WLAN architecture in which 
> authentication needs to be
> 
> 	   supported, i.e., the location of major 
> authentication components.
> 
> 	   This may be achieved during WTP initialization where major
> 
> 	   capabilities are distinguished.
> 
> 
> 
> 	   The protocol MUST allow for the exchange of key 
> information when
> 
> 	   authenticator and encryption roles are located in 
> distinct entities.
> 
> 
> 
> 
> 
> 	Following the requirement, CAPWAP needs;
> 
> 
> 
> 	1. to incorporate authentication & encryption locations in
> 
> 	   capabilities exchange
> 
> 
> 
> 	2. to exchange key information when authentication and crypt are
> 
> 	   located in different network entities
> 
> 
> 
> 
> 
> 	Basic case:
> 
> 
> 
> 	AC does both IEEE 802.11i authentication and 
> cryptography. For 4-way
> 
> 	exchange, AC tracks the KeyRSC, which it then uses for 
> Message-3,
> 
> 	i.e., AC calculates KeyMIC and updates EAPoL frame.
> 
> 
> 
> 
> 
> 	                                                  - 
> 802.11i Authentication
> 
> 	                                                  - 
> 802.11i Crypto
> 
> 	                                                     
> (KeyRSC maintained here)
> 
> 
> 
> 	   +----------+                 +-----+
> +------+
> 
> 	   | Terminal |                 | WTP |                     |
> AC  |
> 
> 	   +----------+                 +-----+
> +------+
> 
> 	        |                          |
> |
> 
> 	        |                    802.1x Authentication
> |
> 
> 
> |<=====================================================>|
> 
> 	        |                          |
> |
> 
> 	       PMK                         |
> PMK
> 
> 	        |                          |
> |
> 
> 	      Generate                     |
> Generate
> 
> 	       SNonce                      |
> ANonce
> 
> 	        |                          |
> |
> 
> 	        |                          |
> |
> 
> 	        |                      Message-1
> |
> 
> 
> |<-------------------------|<---------------------------|
> 
> 	        |       EAPoL Packet       |        CAPWAP Packet
> |
> 
> 	      Receive                      |
> |
> 
> 	       ANonce                      |
> |
> 
> 	      Generate                     |
> |
> 
> 	       PTK                         |
> |
> 
> 	        |                          |
> |
> 
> 	        |                      Message-2
> |
> 
> 
> |------------------------->|--------------------------->|
> 
> 	        |       EAPoL Packet       |        CAPWAP Packet
> |
> 
> 	        |                          |
> Receive
> 
> 	        |                          |
> SNonce
> 
> 	        |                          |
> |
> 
> 	        |                          |
> Generate
> 
> 	        |                          |
> PTK
> 
> 	        |                          |
> GTK
> 
> 	        |                      Message-3
> |
> 
> 
> |<-------------------------|<---------------------------|
> 
> 	        |       EAPoL Packet       |   CAPWAP Packet
> |
> 
> 	        |                          |      |
> |
> 
> 	        |                          |      |
> +-----------------------+
> 
> 	        |                          |       \|- EAPoL Frame
> |
> 
> 	      Receive                      |
> +-----------------------+
> 
> 	       GTK                         |
> |
> 
> 	        |                          |
> |
> 
> 	        |                          |
> |
> 
> 	        |                      Message-4
> |
> 
> 
> |------------------------->|--------------------------->|
> 
> 	        |       EAPoL Packet       |         CAPWAP Packet
> |
> 
> 	        |                          |
> |
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 	Case specified by RFC 4564:
> 
> 
> 
> 	The 802.11i Considerations requirement considers the 
> case where 802.11i
> 
> 	authentication is at AC and 802.11i crypto is at WTP. 
> So now, the WTP
> 
> 	maintains the KeyRSC while the AC requires this 
> information to generate
> 
> 	the EAPoL frame for Message-3 of the 4-way handshake.
> 
> 
> 
> 	The diagram below shows this;
> 
> 
> 
> 	                            - 802.11i Crypto
> 
> 	                         (KeyRSC maintained here)      - 802.11i
> Authentication
> 
> 
> 
> 	   +----------+                 +-----+
> +------+
> 
> 	   | Terminal |                 | WTP |                     |
> AC  |
> 
> 	   +----------+                 +-----+
> +------+
> 
> 	        |                          |
> |
> 
> 	        |                    802.1x Authentication
> |
> 
> 
> |<=====================================================>|
> 
> 	        |                          |
> |
> 
> 	       PMK                         |
> PMK
> 
> 	        |                          |
> |
> 
> 	      Generate                     |
> Generate
> 
> 	       SNonce                      |
> ANonce
> 
> 	        |                          |
> |
> 
> 
> 
> 
> 
> 	In this case, the EAPoL frame generated by the AC will 
> not be based on
> 
> 	the prevailing value of the KeyRSC, as this counter is 
> maintained by
> 
> 	the WTP.
> 
> 
> 
> 	This problem is currently not solved in the CAPWAP 
> specifications.
> 
> 
> 
> 
> 
> 	Proposal:
> 
> 
> 
> 	The proposal is to include a CAPWAP Key Configuration 
> message that can
> 
> 	transport the EAPoL frame between AC and WTP before 
> being sent to the
> 
> 	client (terminal).
> 
> 
> 
> 	Key Configuration is a control message sent by the AC 
> to the WTP. The
> 
> 	message contains Message-3 of the 4-way handshake - 
> including the
> 
> 	EAPoL-frame. However, the EAPoL frame has its KeyMIC 
> field unassigned as
> 
> 	the AC cannot accurately calculate this.
> 
> 
> 
> 	So on receiving the Key Configuration - containing 
> EAPoL frame with
> 
> 	unassigned KeyMIC field, the WTP retrieves the value of 
> the KeyRSC it
> 
> 	maintains and computes the corresponding KeyMIC.
> 
> 
> 
> 	The EAPoL frame is then updated and Message-3 of the 
> 4-way handshake is
> 
> 	reconstructed before being sent over the wireless link 
> to the client.
> 
> 
> 
> 
> 
> 	The diagram below illustrates this;
> 
> 
> 
> 
> 
> 	                            - 802.11i Crypto
> 
> 	                         (KeyRSC maintained here)      - 802.11i
> Authentication
> 
> 
> 
> 	   +----------+                 +-----+
> +------+
> 
> 	   | Terminal |                 | WTP |                     |
> AC  |
> 
> 	   +----------+                 +-----+
> +------+
> 
> 	        |                          |
> |
> 
> 	        |                    802.1x Authentication
> |
> 
> 
> |<=====================================================>|
> 
> 	        |                          |
> |
> 
> 	       PMK                         |
> PMK
> 
> 	        |                          |
> |
> 
> 	      Generate                     |
> Generate
> 
> 	       SNonce                      |
> ANonce
> 
> 	        |                          |
> |
> 
> 	        |                          |
> |
> 
> 	        |                      Message 1
> |
> 
> 
> |<-------------------------|<---------------------------|
> 
> 	        |       EAPoL Packet       |        CAPWAP Packet
> |
> 
> 	      Receive                      |
> |
> 
> 	       ANonce                      |
> |
> 
> 	      Generate                     |
> |
> 
> 	       PTK                         |
> |
> 
> 	        |                          |
> |
> 
> 	        |                      Message 2
> |
> 
> 
> |------------------------->|--------------------------->|
> 
> 	        |       EAPoL Packet       |        CAPWAP Packet
> |
> 
> 	        |                          |
> Receive
> 
> 	        |                          |
> SNonce
> 
> 	        |                          |
> |
> 
> 	        |                          |
> Generate
> 
> 	        |                          |
> PTK
> 
> 	        |                          |
> GTK
> 
> 	        |                          |          Message 3
> |
> 
> 	        |
> |<===========================|
> 
> 	        |                          |        CAPWAP Packet
> |
> 
> 	        |                          |      (Key Configuration)
> |
> 
> 	        |                          |      |
> +-----------------------+
> 
> 	        |                          |       \|- GTK-Flag
> |
> 
> 	        |                 -Retrieve KeyRSC  |-
> Encryption-Data(PTK) |
> 
> 	        |                 -Update KeyMIC    |-
> Encryption-Data(GTK) |
> 
> 	        |                 -Reconstruct      |- EAP-Frame
> |
> 
> 	        |                     Message-3
> +-----------------------+
> 
> 	        |                          |
> |
> 
> 	        |<-------------------------|
> |
> 
> 	        |       EAPoL Packet       |
> |
> 
> 	     Receive                       |
> |
> 
> 	      GTK                          |
> |
> 
> 	        |                      Message 4
> |
> 
> 
> |------------------------->|--------------------------->|
> 
> 	        |       EAPoL Packet       |        CAPWAP Packet
> |
> 
> 	        |                          |
> |
> 
> 
> 
> 
> 
> 
> 
> 	This proposal very simply solves the problem while 
> directly addressing
> 
> 	the requirement for IEEE 802.11i Considerations.
> 
> 
> 
> 
> 
> 	Cheers,
> 
> 
> 
> 	Saravanan
> 
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> 
> _________________________________________________________________
> Get cheap fares online with MSN Travel http://www.msn.com.sg/travel/
> 
_________________________________________________________________
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

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 21 Sep 2006 08:25:37 -0400

Hi again,

Okay, I am even more confused than I thought I was...

Saravanan, you wrote:

> authenticator is at the AC and crypto elements are at the WTP. This is

And, in response, Pat Calhoun wrote:

On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:
> The current specification allows the authenticator to reside in the  
> AC,
> while the data packet crypto elements in the WTP. This feature is
> already in the specification.

Pat's message matches my reading of the specification.

So, Saravanan, what functionality are you asking for that is not  
already supported by the specification?  And why do you think it is  
necessary?  it will not be helpful to my understanding to re-send  
your proposal or to cite the requirements document...  Please  
summarize what functionality you think is missing from the current  
specification and why you think that functionality is necessary to  
support IEEE 802.11i or any important use case.

At some point, the chairs may need to make a consensus call on this  
issue, and I'd like to understand your view and make sure that it has  
been clearly communicated to the WG before we ask the WG to decide on  
this issue.

Thanks,
Margaret