Subject: Re: [Capwap] CAPWAP for 802.11r

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 18 Oct 2006 20:03:30 -0700 (PDT)

Hi Charles,

----- Original Message ----
From: Charles Clancy <[email-masked]>
To: [email-masked]
Cc: capwap <[email-masked]>
Sent: Wednesday, October 18, 2006 8:49:29 PM
Subject: Re: [Capwap] CAPWAP for 802.11r

Behcet,

CAPWAP has not yet defined how 11r FT and reassociation packets are 
tunneled for Local and Split MAC.  
==> Correct. 
Your assumption is that in Local MAC 
they would be processed at the WTP.  However, if they are processed by 
the AC (just as the current four-way-handshake packets) then there's no 
reason to transport PMK-R1s to WTPs, and no changes necessary to CAPWAP 
to support 11r.  In fact, transportation of PMK-R1s to the WTPs would 
break the current CAPWAP security model. 
==>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.
==> Can you spare your ideas why that would not work in CAPWAP?
 In CAPWAP we only have one 
authenticator; therefore PMK-* MUST reside at the AC.
==> You're saying we only need the split MAC scenarios that I have in the draft.

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

==>
The purpose of the draft is to attempt to initiate work on extending CAPWAP 802.11 binding for FT.
I think it will be good to discuss this and get ideas?

Thanks,

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: "Charles Clancy" <[email-masked]>
Date: Thu, 19 Oct 2006 15:27:28 -0400 (EDT)

Behcet,

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