Subject: Re: [Capwap] CAPWAP for 802.11r

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 19 Oct 2006 17:02:45 -0700 (PDT)

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 

----- Original Message ----
From: Pat Calhoun (pacalhou) <[email-masked]>
To: [email-masked]; capwap <[email-masked]>
Sent: Thursday, October 19, 2006 11:31:51 AM
Subject: Re: [Capwap] CAPWAP for 802.11r

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
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Behcet Sarikaya [mailto:[email-masked]] 
> Sent: Wednesday, October 18, 2006 12:43 AM
> To: capwap
> Subject: [Capwap] CAPWAP for 802.11r
> 
> Pat and all,
> 
> The link:
> http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-fast
> bss-00.txt
> is now on.
> 
> Regards,
> 
> --behcet
> 
> ----- Original Message ----
> From: Pat Calhoun (pacalhou) <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>
> Sent: Monday, October 16, 2006 7:01:11 PM
> Subject: RE: [Capwap] CAPWAP for 802.11r
> 
> ok, I will once it becomes available.
>  
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> 
>  
> 
>     
> --------------------------------------------------------------
> ----------
>     *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,
> 
> 
>     ----- 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
> 
>     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:
> 
>         
> http://www.ietf.org/internet-drafts/draft-sarikaya-capwap-fast
> bss-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
> 
_________________________________________________________________
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: Charles Clancy <[email-masked]>
Date: Fri, 20 Oct 2006 10:21:00 -0400

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.

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.

-- 
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.
>   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
> 
> ------------------------------------------------------------------------
> 
8.5A.6 PMK-R1 distribution within a mobility domain

The following procedures are used to distribute PMK-R1s.

The STA first derives PMK-R0 keys for use in fast BSS transitions (via
the FT Initial Association procedures defined in clause 8A.2)
utilizing information from the target AP as defined in 8.5A.4. When
the IEEE 802.1X AKM is used to establish keys, the PMK-R0 Key Holder
derives the PMK-R0 key utilizing the MSK acquired through EAP based
authentication.

The PMK-R0 shall be stored in a component called the PMK-R0 Key
Holder. Each PMK-R0 Key Holder is responsible for deriving a PMK-R1
key for key for each PMK-R1 Key Holder in the mobility domain. The
PMK-R1 shall be stored in a component called the PMK-R1 Key
Holder. PMK-R1 keys are distributed to PMK-R1 Key Holders by the
PMK-R0 Key Holder using a secure three party protocol described
herein.

The Mobility Domain Controller (MDC) shall mutually authenticate and
authorize all members of the mobility domain that can be Key
Holders. Using the MDC all Key Holders can establish security
associations with each other. The identities they use during the
authentication process shall be their NAS-Id which is identical to the
information included in the NASID IE in all beacons and probe
responses.

The Key Distribution Protocol has the following properties
- Authentication of entities involved in key distribution
- Confidentiality of the key distribution
- Authorization of the status of a PMK-R1 holder
- Validation of the authorization
- Receipt of the key is acknowledged
- Correctness of the authorization attributes assigned to the STA

The Key Distribution Protocol is initiated by the STA by including an
R1DIST Information element along with other Fast BSS Transition
Information Elements in either Authentication or Action frames. The
token of this element shall be the AES-KeyWrap of a sixteen (16) octet
random number chosen by the STA, called Ns, concatenated with the
identity of the target AP as determined by the NASID Information
Element in its beacons and probe responses. The key used to perform
this wrapping shall be "mk" described in section 8.5A.4.

The target AP shall extract the token from the R1DIST Information
Element and send it along with the MAC address of the STA to the R0KH
identified in the FTIE under the protection of the security
association the target AP (a Key Holder) shares with the PMK-R0 Key
Holder. If the target AP does not recognize the R0KH in the FTIE or
does not have a security association with it authentication fails with
status 38 ("the request has not been successful as one or more
parameters have invalid values").

Upon receipt of this message the R0KH looks up the PMK-R0 security
association it shares with the STA based upon the MAC address in the
message. It then unwraps the token using "mk" describe in section
8.5A.4. If the unwrapping fails or the R0KH does not have a PMK-R0
security association for that STA it returns a failure message to the
target AP which then fails the authentication attempt with status
38. The R0KH compares the NAS-Id from the unwrapped token with the
identity the target AP used during when establishing its shared
security association. If the two do not match the R0KH returns a
failure message to the target AP which then fails the authentication
attempt with status 38. The R0KH then chooses a sixteen (16) octet
random number, called Na, and constructs a message back to the target
AP consisting of the STA's MAC address, Ns, Na, the PMK-R1, the PMK-R1
Name, all authorization attributes associated with PMKR0 (e.g. session
lifetime), and a token representing an AES-KeyWrapping of the NAS-Id
of the target AP from the shared security association and Na. The
wrapping shall use "mk" described in section 8.5A.4.

Upon receipt of this message the target AP shall instantiate a PMK-R1
security association and construct either an Authentication response
frame or response action frame depending on the type of request
received originally. This frame will include, along with other Fast
BSS Transition IEs, an RT1DIST IE which shall encapsulate the token it
received from the PMK-R0 Key Holder, and an R1DISTV IE which shall
consist of the digest of SHA-256(Ns|Na).

Upon receipt of this frame the STA shall perform the following
additional validation: it shall unwrap the token in the R1DIST IE and
compare the enclosed NAS-Id with the one it received from the target
AP in a beacon or probe response. If they do not match the STA must
treat this as an authentication failure. If they match the STA
computes the digest of SHA-256(Ns|Na) using Na from the unwrapped
token and compares it to the value in the R1DISTV IE. If they do not
match the STA must treat this as an authentication failure.  If they
match the STA instantiates its own version of a PMK-R1 security
association to share with the target AP and continues with Fast BSS
Transition.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap