Subject: [Capwap] CAPWAP for 802.11r

From: Behcet Sarikaya <[email-masked]>
Date: Sat, 14 Oct 2006 08:32:56 -0700 (PDT)

Dear all,
  I submitted a draft on CAPWAP Roaming Protocol in 802.11R Domains.
It should be available soon at the following link:

http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-fastbss-00.txt

Regards,

Behcet

_________________________________________________________________
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: Mon, 16 Oct 2006 11:02:43 -0700

Behcet,
 
I believe we've discussed this idea a few times, and I am still unsure
why we believe CAPWAP needs to define anything to support TGr. The
current CAPWAP protocol is sufficient to support the upcoming standard.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Behcet Sarikaya [mailto:[email-masked]] 
	Sent: Saturday, October 14, 2006 8:33 AM
	To: [email-masked]
	Subject: [Capwap] CAPWAP for 802.11r

	Dear all,
	  I submitted a draft on CAPWAP Roaming Protocol in 802.11R
Domains.
	It should be available soon at the following link:

	Regards,
	
	Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 16 Oct 2006 16:40:58 -0700 (PDT)

Pat, 

----- Original Message ----
From: Pat Calhoun (pacalhou) <[email-masked]>
To: Behcet Sarikaya <[email-masked]>; [email-masked]
Sent: Monday, October 16, 2006 1:02:43 PM
Subject: RE: [Capwap] CAPWAP for 802.11r

DIV {
MARGIN:0px;}

Behcet,

I 
believe we've discussed this idea a few times, and I am still unsure why we 
believe CAPWAP needs to define anything to support TGr. The current CAPWAP 
protocol is sufficient to support the upcoming standard.

==>
The basis is there but we need several extensions.
Please read the draft and comment, then we can make a more informed decision, I think.

Pat Calhoun
CTO, Wireless Networking Business 
Unit
Cisco Systems

Regards,

--behcet

  
  From: Behcet Sarikaya 
  [mailto:[email-masked]] 
Sent: Saturday, October 14, 2006 
  8:33 AM
To: [email-masked]
Subject: [Capwap] CAPWAP 
  for 802.11r

  Dear all,
  I submitted a draft on CAPWAP Roaming Protocol in 
  802.11R Domains.
It should be available soon at the following 
  link:

Regards,

Behcet

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 19 Oct 2006 09:31:51 -0700

Behcet,

The architecture laid out in your specification seems to conflict with
the CAPWAP architecture. 

A couple of specific concerns before I get into the meat of the
document:

   > We use [802.11r] key distribution protocol for transfering key
context
   > for Local MAC WTPs.

The latest 802.11r draft does not define a key distribution protocol to
move key context across WTPs (or APs). So I am not sure what we are
refering to.

   > AC next generates PMK-R1 for R1 key holder (R1KH), i.e. the WTP.
AC
   > is now in a position to transfer PMK-R1 context and associated
   > authorization to the WTP.  R1KH and STA perform a 4-way handshake
and
   > generate the session key, PTK.

The CAPWAP protocol does not assume that the PMK is ever transferred
down into the WTP. Furthermore, the protocol assumes the authenticator
resides in the AC - not the WTP. So this statement seems to change the
fundamental architecture of the CAPWAP protocol.

I will have many additional questions once I read the specification
completely, but first want to make sure that we agree on whether the
spec is in scope or not (by answering the above questions).

Pat Calhoun

> -----Original Message-----
> Sent: Wednesday, October 18, 2006 12:43 AM
> To: capwap
> Pat and all,
> The link:
> is now on.
> To: Behcet Sarikaya <[email-masked]>
> Sent: Monday, October 16, 2006 7:01:11 PM
> ok, I will once it becomes available.
>  
> 
> Pat Calhoun
> --------------------------------------------------------------
> ----------
>     *From:* Behcet Sarikaya [mailto:[email-masked]]
>     *Sent:* Monday, October 16, 2006 4:41 PM
>     *To:* Pat Calhoun (pacalhou); [email-masked]
>     *Subject:* Re: [Capwap] CAPWAP for 802.11r
> 
>     Pat,
> 
> 
>     I believe we've discussed this idea a few times, and I am still
>     unsure why we believe CAPWAP needs to define anything to support
>     TGr. The current CAPWAP protocol is sufficient to support the
>     upcoming standard.
> 
>     ==>
>     Please read the draft and comment, then we can make a 
> more informed
>     decision, I think.
> 
> 
>     Pat Calhoun
> --------------------------------------------------------------
> ----------
>         *From:* Behcet Sarikaya [mailto:[email-masked]]
>         *Sent:* Saturday, October 14, 2006 8:33 AM
>         *To:* [email-masked]
>         *Subject:* [Capwap] CAPWAP for 802.11r
> 
>         Dear all,

---

From: Behcet Sarikaya <[email-masked]>
Date: Sun, 22 Oct 2006 09:56:45 -0700 (PDT)

Some general comments first. CAPWAP is a protocol for managing Split/Local MAC WTPs. Support for roaming STAs is a small part of CAPWAP which could be considered orthogonal. Roaming text is geared towards Split MAC WTPs. Some people argued that 802.11i cannot be supported in CAPWAP because there is at least one value, i.e. KeyRSC should be set by WTP.

The same goes for 802.11r. There could be tendency to use CAPWAP only for management and use 802.11r for roaming especially when WTPs are 802.11r enabled.

However, in draft-sarikaya-capwap-fastbss-00.txt we argue that CAPWAP could be harmonized with this new technology called 802.11r. We came up with a solution and we expect to receive constructive comments for improvement.

----- Original Message ----
From: Charles Clancy <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: capwap <[email-masked]>
Sent: Friday, October 20, 2006 9:21:00 AM
Subject: Re: [Capwap] CAPWAP for 802.11r

Behcet,

11R D3 8.5A.6 (attached for those interested) defines the basic 
properties and summarizes the exchanges, but I don't see any packet 
formats, transport mechanism, link security mechanism, or method for 
establishing a trust relationship between the MDC and possible KHs.

==> 802.11r has all those. My proposal is AC to be the MDC and PMK R0 KH and Local MAC
WTPs PMK R1 KHs. I suggest that you read D3 and we can have a face to face discussion in San Diego.

In CAPWAP, there's no AAA context to transfer, because the AAA context 
always resides at the AC.  Using the existing mechanism for key 
distribution (via Add Mobile messages) is sufficient for transporting 
PTKs to the WTPs.
==>In draft-sarikaya-capwap-fastbss-00, we have that for SplitMAC operation.

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

Behcet Sarikaya wrote:
> Hi Pat and Charles,
>  
> Section 8.5A.6 in 802.11r D3 describes the key distribution protocol. It 
> is true that earlier versions like D2.2 did not have it.
> So my Local MAC scenarios were based on this protocol.
>   The key distribution protocol makes it unnecessary to use the context 
> transfer ahead of time and it is quite nice to generate and transfer the 
> key in a just-in-time manner. I thought it was good and used it in CAPWAPRP.
> 
  Regards,

Behcet

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 26 Oct 2006 03:47:54 -0700

I agree, but that doesn't mean that we should be dillatory and not fix
something in the protocol that is known to be broken in supporting an
upcoming ammendment. This is not the case with 802.11r, but just wanted
to provide my interpretation of the process..

Pat Calhoun

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Thursday, October 26, 2006 1:02 AM
	To: Behcet Sarikaya
	Cc: capwap
	Subject: Re: [Capwap] CAPWAP for 802.11r

	All,
	
	I believe that we previously agreed that the
	initial CAPWAP specification(s) will support 802.11 capabilities
through
	those defined in  802.11-REVma, expected to be approved in Dec
06, and that
	unapproved amendments including .11k, .11r, .11n etc would be
dealt with
	in a future version. 
	
	Thus  802.11r support in CAPWAP, the discussion of which is very
interesting,
	is not in scope for the current CAPWAP specifications under
development.
	
	Thanks,
	
	Dorothy

	On 10/25/06, Behcet Sarikaya <[email-masked]> wrote: 

		Comments inline.

		----- Original Message ----
		From: Charles Clancy <[email-masked]>
		To: Pat Calhoun (pacalhou) <[email-masked]>
		Cc: Behcet Sarikaya < [email-masked]
<mailto:[email-masked]> >; capwap <[email-masked]>
		Sent: Monday, October 23, 2006 11:00:38 AM
		Subject: Re: [Capwap] CAPWAP for 802.11r

		Unless PMK-R1s are preemptively distributed to WTPs to
which a STA might
		roam (neighbor graphs, anyone?), you'll still have the
WTP-AC latency for 
		the WTP to request a PMK-R1 from the AC (R0KH).  This
would be about equal
		to the latency of having the AC validating Association
Request packets.
		
		==>PMK-R1 is sent during Authenticate req/resp exchange,
so no effect on ReassReq/Resp latency.
		
		Does 11r let you proactively distribute PMK-R1s?  I
don't see any
		references in D3... all I see is the reactive
distribution protocol. 
		==>I think it is possible but the key distribution
protocol is more advantageous because you do not distribute keys to WTPs
that may never need to use such a key.

		My understanding is that one of the reasons 11r is
faster is because keys
		can be *reactively* transfered directly between APs
without having to go
		through the AAA server.  Unfortunately our main security
association is 
		with the AC, not the WTP, and inter-WTP communications
is bad, so
		everything will have to go through the AC.
		
		==>No inter-WTP communications in CAPWAPRP. 

		-- 
		t. charles clancy, ph.d.  <>  [email-masked]  <>
www.cs.umd.edu/~clancy <http://www.cs.umd.edu/%7Eclancy> 
		
		On Mon, October 23, 2006 10:28 am, Pat Calhoun
\(pacalhou\) wrote:
		> I agree with Charles - but I do believe there is a
single issue. In the
		> case of local MAC, the IEEE 802.11 binding states that
the WTP processes
		> the Association Request and then forwards it to the
AC. The AC can
		> override the decision made by the WTP by sending a
negative result
		> Association Response.
		>
		> When 802.11r, the local MAC WTP will not have the
cryptographic keys
		> necessary to validate the Association Request, so it
would *have* to
		> defer to the AC. The question is whether this is
acceptable as it does 
		> change the timing of the Association round trip. One
alternative is to
		> push the PMK-R1 keys to the WTP to allow the WTP to
perform its own
		> authentication of the management frame.
		>
		> Pat Calhoun 
		>> From: Charles Clancy [mailto: [email-masked]
<mailto:[email-masked]> ]
		>> Sent: Thursday, October 19, 2006 12:27 PM
		>> To: Behcet Sarikaya
		>> Cc: capwap
		>> > My proposal is to use the key distribution protocol
of
		>> 802.11r which
		>> > securely transports the keys.
		>> > Also no need for the context transfer which was
what I had in mind. 
		>>
		>> My point is that we don't need to distribute PMK-R1
keys
		>> since all authenticator functionality will reside at
the AC
		>> regardless of the MAC splitting, so we therefore
don't need a 
		>> new key distribution protocol at all.
		>>
		>> Here's how I envision an 11r handoff:
		>>
		>> STA            WTP1           WTP2              AC
		>> --------------------------------------------------
		>>
		>> Initial authentication (as CAPWAP does now):
		>>
		>> <--- assoc ----->
		>> <-------------- open authentication -------------> 
		>> <----------------- 1X/EAP authentication -------->
		>>                (derives PMK-R0, PMK-R1)
		>> <--------------- four-way handshake ------------->
		>>                    (derives PTK)
		>>                 <---------- add mobile (PTK) -----
		>>
		>> fast handoff:
		>>
		>>                (AC and STA derive new PMK-R1')
		>> <------- FT / reassoc (PMK Name, MIC, etc) ------>
		>>                   (derives new PTK')
		>>                               <- add mobile (PTK')
		>>                 <---------- delete mobile --------
		>>
		>>
		>> > Can you spare your ideas why that would not work in
CAPWAP?
		>>
		>> I'm not sure to what you're referring.  Using the
		>> yet-to-be-defined 11r key distribution protocol
duplicates
		>> the add-mobile CAPWAP architecture for distributing
keying 
		>> material.  Additionally, it violates the security
restriction
		>> that keys from the PMK-level in the keying hierarchy
MUST
		>> remain at the authenticator, which is the AC.
		>>
		>> > You're saying we only need the split MAC scenarios
that I 
		>> have in the
		>> > draft.
		>>
		>> I'm saying that CAPWAP can support 11r without any
protocol
		>> changes.  The only changes I can envision being
necessary are
		>> perhaps capabilities flags indicating support for
11r, so ACs 
		>> and WTPs know that each other supports 11r.  All the
11r
		>> protocol processing would be implemented at the AC.
The WTP
		>> would just have to know about the additional 802.11
messages,
		>> and know they should be forwarded to the AC.  WTPs
and ACs
		>> would also have to support AES-CMAC, which is defined
in 11r. 
		>>
		>> --
		>> t. charles clancy, ph.d.  |  [email-masked]  |
www.cs.umd.edu/~clancy <http://www.cs.umd.edu/%7Eclancy> 

_________________________________________________________________
		To unsubscribe or modify your subscription options,
please visit:
		http://lists.frascone.com/mailman/listinfo/capwap

	
_________________________________________________________________
		To unsubscribe or modify your subscription options,
please visit:
		http://lists.frascone.com/mailman/listinfo/capwap

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 26 Oct 2006 14:05:26 -0700 (PDT)

I agree with Pat.
We (CAPWAP ML) should be open for discussion on how something very relevant like 802.11r could be integrated with CAPWAP 802.11 binding.

--behcet

----- Original Message ----
From: Pat Calhoun (pacalhou) <[email-masked]>
To: Dorothy Stanley <[email-masked]>; Behcet Sarikaya <[email-masked]>
Cc: capwap <[email-masked]>
Sent: Thursday, October 26, 2006 5:47:54 AM
Subject: Re: [Capwap] CAPWAP for 802.11r

I agree, but that doesn't mean that we should be dillatory and not fix something in the protocol that is known to be broken in supporting an upcoming ammendment. This is not the case with 802.11r, but just wanted to provide my interpretation of the process..
 
Pat Calhoun

All,

I believe that we previously agreed that the
initial CAPWAP specification(s) will support 802.11 capabilities through
those defined in  802.11-REVma, expected to be approved in Dec 06, and that
unapproved amendments including .11k, .11r, .11n etc would be dealt with
in a future version. 

Thus  802.11r support in CAPWAP, the discussion of which is very interesting,
is not in scope for the current CAPWAP specifications under development.

Thanks,

Dorothy

----- Original Message ----
From: Charles Clancy <[email-masked]>
To: Pat Calhoun (pacalhou) <[email-masked]>
Cc: Behcet Sarikaya < [email-masked]>; capwap <[email-masked]>
Sent: Monday, October 23, 2006 11:00:38 AM
Subject: Re: [Capwap] CAPWAP for 802.11r

Unless PMK-R1s are preemptively distributed to WTPs to which a STA might
roam (neighbor graphs, anyone?), you'll still have the WTP-AC latency for 
the WTP to request a PMK-R1 from the AC (R0KH).  This would be about equal
to the latency of having the AC validating Association Request packets.

==>PMK-R1 is sent during Authenticate req/resp exchange, so no effect on ReassReq/Resp latency.

Does 11r let you proactively distribute PMK-R1s?  I don't see any
references in D3... all I see is the reactive distribution protocol. 
==>I think it is possible but the key distribution protocol is more advantageous because you do not distribute keys to WTPs that may never need to use such a key.

My understanding is that one of the reasons 11r is faster is because keys
can be *reactively* transfered directly between APs without having to go
through the AAA server.  Unfortunately our main security association is 
with the AC, not the WTP, and inter-WTP communications is bad, so
everything will have to go through the AC.

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

On Mon, October 23, 2006 10:28 am, Pat Calhoun \(pacalhou\) wrote:
> I agree with Charles - but I do believe there is a single issue. In the
> case of local MAC, the IEEE 802.11 binding states that the WTP processes
> the Association Request and then forwards it to the AC. The AC can
> override the decision made by the WTP by sending a negative result
> Association Response.
>
> When 802.11r, the local MAC WTP will not have the cryptographic keys
> necessary to validate the Association Request, so it would *have* to
> defer to the AC. The question is whether this is acceptable as it does 
> change the timing of the Association round trip. One alternative is to
> push the PMK-R1 keys to the WTP to allow the WTP to perform its own
>> From: Charles Clancy [mailto: [email-masked]]
>> > My proposal is to use the key distribution protocol of
>> 802.11r which
>> > Also no need for the context transfer which was what I had in mind. 
>>
>> My point is that we don't need to distribute PMK-R1 keys
>> since all authenticator functionality will reside at the AC
>> regardless of the MAC splitting, so we therefore don't need a 
>> > Can you spare your ideas why that would not work in CAPWAP?
>>
>> yet-to-be-defined 11r key distribution protocol duplicates
>> the add-mobile CAPWAP architecture for distributing keying 
>> material.  Additionally, it violates the security restriction
>> that keys from the PMK-level in the keying hierarchy MUST
>> > You're saying we only need the split MAC scenarios that I 
>> have in the
>> > draft.
>>
>> I'm saying that CAPWAP can support 11r without any protocol
>> changes.  The only changes I can envision being necessary are
>> perhaps capabilities flags indicating support for 11r, so ACs 
>> and WTPs know that each other supports 11r.  All the 11r
>> protocol processing would be implemented at the AC.  The WTP
>> would just have to know about the additional 802.11 messages,
>> and know they should be forwarded to the AC.  WTPs and ACs
>> would also have to support AES-CMAC, which is defined in 11r. 
>>
>> --