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

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Tue, 25 Jul 2006 08:01:48 -0700

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:[email-masked]] 
Sent: Monday, July 24, 2006 6:30 PM
To: Bob O'Hara (boohara); [email-masked]
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:[email-masked]] 
Sent: Tuesday, July 25, 2006 12:00 AM
To: [email-masked]
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:[email-masked]] 
Sent: Monday, July 24, 2006 8:50 AM
To: Bob O'Hara (boohara); [email-masked]
Cc: [email-masked]
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)" <[email-masked]>
To: "capwap" <[email-masked]>
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:[email-masked]]
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:[email-masked]]
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:[email-masked]]
	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:[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 <
[email-masked]
<mailto:[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

_________________________________________________________________
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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Saravanan Govindan" <[email-masked]>
Date: Tue, 25 Jul 2006 23:33:10 +0800

Bob,

We seem to be going in circles. I do not see any solid reference to the 
current CAPWAP specifications on how requirement 5.1.10 is addressed for the 
case that it presents. This is the only mystery.

And reference to any non-CAPWAP system is moot. We are here to standardize 
the CAPWAP protocol.

So I ask again, please explain how the requirement is currently met - or 
let's discuss how it can be incorporated in to the specifications.

Saravanan

----Original Message Follows----
From: "Bob O'Hara (boohara)" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations
Date: Tue, 25 Jul 2006 08:01:48 -0700

Saranavan,

  -Bob

-----Original Message-----
From: Saravanan Govindan [mailto:[email-masked]]
Sent: Monday, July 24, 2006 6:30 PM
To: Bob O'Hara (boohara); [email-masked]
Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i
Considerations

Saravanan

-----Original Message-----
From: Bob O'Hara (boohara) [mailto:[email-masked]]
Sent: Tuesday, July 25, 2006 12:00 AM
To: [email-masked]
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i
Considerations

<tutorial mode>

  -Bob

-----Original Message-----
From: Saravanan Govindan [mailto:[email-masked]]
Sent: Monday, July 24, 2006 8:50 AM
To: Bob O'Hara (boohara); [email-masked]
Cc: [email-masked]
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i
Considerations

Saravanan

----Original Message Follows----
From: "Bob O'Hara (boohara)" <[email-masked]>
To: "capwap" <[email-masked]>
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i
Considerations

   -Bob

Saravanan

Pat Calhoun

	From: Saravanan Govindan

	Saravanan

	Pat Calhoun

		From: Saravanan Govindan

		Saravanan

		Pat Calhoun

			From: Michael Montemurro

			Saravanan,

			Cheers,

			Mike

			Hi Mike,

			Thank you for the note.

			Cheers,

			Saravanan

			Saravanan,

			This would then require:

			Hi Mike,

			Cheers,

			Saravanan

			Saravanan,

			Cheers,

			Mike

_________________________________________________________________
Find just what you are after with the more precise, more powerful new MSN 
Search. http://search.msn.com.sg/ Try it now.