Capwap Mailing List: Re: CAPWAP for 802.11r

[Dorothy Stanley (dstanley1389]

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 <behcetsarikaya [at] yahoo.com> wrote:

Comments inline.

----- Original Message ----
From: Charles Clancy <clancy [at] cs.umd.edu>
To: Pat Calhoun (pacalhou) <pcalhoun [at] cisco.com>
Cc: Behcet Sarikaya < sarikaya [at] ieee.org>; capwap <capwap [at] frascone.com>
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.  <>  tcc [at] umd.edu  <>   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
> authentication of the management frame.
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
>> -----Original Message-----
>> From: Charles Clancy [mailto: clancy [at] cs.umd.edu]
>> Sent: Thursday, October 19, 2006 12:27 PM
>> To: Behcet Sarikaya
>> Cc: capwap
>> Subject: Re: [Capwap] CAPWAP for 802.11r
>>
>> 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.
>>
>> --
>> t. charles clancy, ph.d.  |  tcc [at] umd.edu  |   www.cs.umd.edu/~clancy
>>
>> _________________________________________________________________
>> 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

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

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