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

From: "Saravanan Govindan" <[email-masked]>
Date: Wed, 19 Jul 2006 16:12:11 +0800

Hi Mike,

This is an interesting mechanism. 

I agree that a negotiation will be required to determine where the
functions will occur. This will be inline with the objective. 

My concern, however, is that the mechanism suggests a new architecture
for WTPs. 

I think we can consider the original case - where key management &
"classical" authenticator functions remain at the AC and where the
encryption function is at the WTP. I this case, the update required for
the protocol would be a way to pass AC-generated EAPoL frames (Message 3
of 3-way handshake) to the WTP and then have the WTP update the EAPoL
frames based on the KeyRSC that it manages. 

The total updates required for this would be

i.          The initial negotiation to determine where encryption and
authenticator functions are done

ii.          Corresponding change in key management (4-way handshake) in
the case where encryption and authenticator are in different entities,
i.e. encryption at WTP and authenticator at AC. 

iii.         Text to clarify the negotiation and subsequent operation

I look forward to your thoughts on this.

Cheers,

Saravanan

 

________________________________

From: Michael Montemurro [mailto:[email-masked]] 
Sent: Wednesday, July 19, 2006 9:59 AM
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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 19 Jul 2006 15:30:27 -0700

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

	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. 

		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.

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

		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

---

From: "Saravanan Govindan" <[email-masked]>
Date: Thu, 20 Jul 2006 14:36:47 +0800

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

Pat Calhoun

	Saravanan,

	Cheers,

	Mike

	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. 

	Cheers,

	Saravanan

	 

	Saravanan,

	So, you would like to request that the WTP generate EAPoL-Key
frames for the 4-way handshake and the GTK update?

	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.

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

	Cheers,

	Saravanan

	 

	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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 20 Jul 2006 08:27:19 -0700

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

	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

	 

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

		Cheers,

		Mike

		Hi Mike,

		Thank you for the note. 

		Cheers,

		Saravanan

		 

		Saravanan,

		This would then require:

		Hi Mike,

		Cheers,

		Saravanan

		 

		Saravanan,

		Cheers,

		Mike

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Thu, 20 Jul 2006 09:26:28 -0700

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:[email-masked]] 
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 <[email-masked]> 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:[email-masked]
] 
		
		Sent: Thursday, July 20, 2006 11:27 PM
		To: Saravanan Govindan; Michael Montemurro
		Cc: capwap

		 

	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

		From: Saravanan Govindan [mailto:
[email-masked]
<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

			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.

			Cheers,

			Mike

			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. 

			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. 

			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.

			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.

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

			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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 21 Jul 2006 08:14:53 -0700

The protocol today addresses requirement defined in Section 5.1.10

Pat Calhoun

	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

	 

	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

---

From: "Michael Montemurro" <[email-masked]>
Date: Fri, 21 Jul 2006 11:06:15 -0400

Saravanan,

The current draft meets this requirement: The protocol allows for the PTK
and GTK to be transmitted from the AC to the WTP when encryption is done on
the WTP.

Mike

On 7/21/06, Saravanan Govindan <[email-masked]> wrote:
>
>  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.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: "Sood, Kapil" <[email-masked]>
Date: Sun, 23 Jul 2006 19:14:19 -0700

[Sood, Kapil] Sharing same key at multiple entities is a bad idea.  That
is the reason we have a 2 layer PMK key hierarchy in 11r.  This should
not be legalized.

---

From: "Saravanan Govindan" <[email-masked]>
Date: Mon, 24 Jul 2006 11:02:20 +0800

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

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

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Mon, 24 Jul 2006 08:59:47 -0700

<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

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

_________________________________________________________________
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

---

From: "Saravanan Govindan" <[email-masked]>
Date: Tue, 25 Jul 2006 09:29:39 +0800

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>

 -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