Network Working Group C. Ye Internet-Draft C. Wan Expires: June 4, 2007 Huawei Technologies Dec. 2006 Problem statement of key distribution for 802.11r using CAPWAP protocol draft-ye-capwap-fbsskey-distribution-ps-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 4, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract CAPWAP specifies a communication exchange mechanism between Wireless Termination Points (WTPs) and a centralized Access Controller (AC) to assist in better coordination and control across the entire ESS network. However it does not specify how to distribute keys used in 802.11r. This document focuses on the requirement for 802.11r key distribution using CAPWAP protocol. Ye & Wan Expires June 4, 2007 [Page 1] Internet-Draft fbsskey distribution ps Dec. 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scenarios Analysis . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Key distribution considerations . . . . . . . . . . . . . . . 8 4.1. PMK-R1 distribution considerations . . . . . . . . . . . . 8 4.2. PTK distribution considerations . . . . . . . . . . . . . 9 5. CAPWAP considerations . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Ye & Wan Expires June 4, 2007 [Page 2] Internet-Draft fbsskey distribution ps Dec. 2006 1. Introduction The Centralized WLAN Architecture is an emerging architecture family in the WLAN market[RFC4118]. It defines two new entities called Wireless Termination Point (WTP) and Access Controller (AC). WTP is a network entity that contains an RF antenna and 802.11 PHY to transmit and receive station traffic for the IEEE 802.11 WLAN access networks, while AC is a network entity in the Centralized WLAN Architecture, where it provides WTPs access to the centralized hierarchical network infrastructure in the data plane, control plane, management plane, or a combination therein. There are three main alternative scenarios, Local MAC, Split MAC and Remote MAC, in the Centralized WLAN Architecture. In Local MAC, the majority or entire set of 802.11 MAC functions are implemented at the WTP, including most of the 802.11[IEEE802.11i]management frame processing. In split MAC, the WTP only implements the delay sensitive MAC services for IEEE 802.11 and the AC processes all the remaining management and data frames tunneled by the WTP. In Remote MAC, the entire set of 802.11 MAC functions are implemented at the AC and the WTP only terminates the 802.11 PHY functions. To enhance STA's handover security and decrease handover delay, the IEEE 802.11r standard [IEEE802.11r]defines fast BSS transition mechanism as the extensions to IEEE STD 802.11 for Wireless Local Area Networks. Fast BSS transition mechanism can apply to STA transitions between ACs within the same ESS. When a STA firstly (re)associates to a mobility domain, 802.11r standard uses an initial exchange "Fast BSS Transition Initial Mobility Domain Association". Subsequent reassociations to other APs within the same Mobility Domain may use Fast BSS transition mechanisms. The IEEE 802.11r standard also introduces FT key hierarchy architecture including three level key, PMK-R0, PMK-R1 and PTK to secure Fast BSS transition, Figure 1 shows the hierarchy architecture. PMK-R0 which is the first level of the FT key hierarchy is derived as a function of the MSK or PSK and stored by the Supplicant and the R1KH. This key is mutually derived by a STA and the R0KH. Generally, there is only a single PMK-R0 derived between the STA and the Mobility Domain. PMK-R1 which is the second level of the key hierarchy is mutually derived by a STA and R0KH. PTK which is the third level of the key hierarchy is mutually derived by a STA and R1KH. From network side, R0KH delivers PMK-R0 and PMK-R1 and holds PMK-R0 as well. R1KH delivers PTK and also holds PMK-R1. PTK-KH only holds PTK. After delivering PMK-R1, R0KH pushes it to R1KH when a STA (re)associates to a mobility domain; While PTK, which is used to protect (re)association signaling of Fast BSS transition, is pushed from R1KH to PTK-KH after four-way handshake or authentication of FBSS. Ye & Wan Expires June 4, 2007 [Page 3] Internet-Draft fbsskey distribution ps Dec. 2006 +--------------------------+ | R0KH | | derives and holds PMK-R0 | | derives PMK-R1 | +--------------------------+ / \ / \ / \ / \ +----------------+ +----------------+ | R1KH | | R1KH | | stores PMK-R1 | | stores PMK-R1 | | derives PTK | | derives PTK | +----------------+ +----------------+ | | | | v v +---------------+ +---------------+ | PTK-KH | | PTK-KH | | stores PTK | | stores PTK | +---------------+ +---------------+ Figure 1 Architecture of FT key hierarchy CAPWAP protocol[capwap]describes an interoperable protocol which enables an Access Controller (AC) to manage a collection of Wireless Termination Points (WTPs), where AC and WTP control and data plane communication is via a CAPWAP protocol transport mechanism. When 802.11r key distribution is between a WTP and an AC, CAPWAP protocol should be used for the distribution. This document focuses on key distribution issue of 802.11r and discusses problems of key distribution for 802.11r using CAPWAP protocol between a WTP and an AC. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119. [STANDARDS] Wireless Termination Point (WTP): The physical or network entity that contains an RF antenna and 802.11 PHY to transmit and receive station traffic for the IEEE 802.11 WLAN access networks. Ye & Wan Expires June 4, 2007 [Page 4] Internet-Draft fbsskey distribution ps Dec. 2006 Access Controller (AC): The network entity in the Centralized WLAN Architecture that provides WTPs access to the centralized hierarchical network infrastructure in the data plane, control plane, management plane, or a combination therein. Station (STA): A device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). Pairwise Master Key R0 (PMK-R0): The key at the first level of the Fast BSS Transition (FT) key hierarchy; the PMK-R0 key is known to only the STA and the R0 key holder and is used to derive PMK-R1 keys. Pairwise Master Key R1 (PMK-R1): The key at the second level of the FT key hierarchy; the PMKR1 key is known to both the STA and the R1 key holder and is used to derive PTKs. Pairwise transient key (PTK): A concatenation of session keys derived from the pairwise master key (PMK) or from the PMK-R1 value. Its components include a key confirmation key (KCK), a key encryption key (KEK), and one or more temporal keys that are used to protect information exchanged over the link. The derivation includes various binding and liveliness values such as Authenticator Address (AA), Supplicant address (SPA), Authenticator nonce (ANonce), and Supplicant nonce (SNonce). Pairwise Master Key R0 Key Holder (R0KH): The component that derives the PMK-R1s and is authorized to distribute them to the PMK-R1 key holders. Pairwise Master Key R1 Key Holder (R1KH): The component that holds the PMK-R1, and derives the PTKs. PTK key holder (PTK-KH): Ye & Wan Expires June 4, 2007 [Page 5] Internet-Draft fbsskey distribution ps Dec. 2006 The component that holds the PTK. 3. Scenarios Analysis In this section, we state problems of key distribution of 802.11r. Four scenarios are listed below according to different location of key holders in the WTP or the AC. 3.1. Scenario A The figure 2 shows a scenario that all key holders (R0KH, R1KH and PTK-KH) locate in the same physical entity AC. +----------+ +----------+ +----------+ | STA |---------| WTP |------------| AC | +----------+ | | | | +----------+ | R0KH | | R1KH | | PTK-KH | +----------+ Figure 2 Scenario A In this scenario, as all key holders locate in the same physical entity AC, 802.11traffic encryption terminates at the entity. PMK-R0 and PMK-R1 are generated by R0KH after a successful IEEE 802.1X Authentication and also stored in the AC. Four-way handshake or authentication of FBSS, which is performed between a STA and AC results to generate a PTK and the PTK is also stored in the AC. This scenario is likely to appear in remote MAC model, where the WTP acts only as a pass-through between the STA and the AC and the AC provides network monitoring, management and control, an entire set of 802.11 AP services, security features, resource management, channel selection features, and guarantees Quality of Service to the STAs. 3.2. Scenario B Figure 3 shows PTK-KH locates in the WTP, while R0KH and R1KH locate in the AC. Ye & Wan Expires June 4, 2007 [Page 6] Internet-Draft fbsskey distribution ps Dec. 2006 +----------+ +----------+ +----------+ | STA |---------| WTP |------------| AC | +----------+ | | | | | PTK-KH | | | +----------+ | R0KH | | R1KH | +----------+ Figure 3 Scenario B In this scenario, as R0KH and R1KH locate in the AC, PMK-R0 and PMK-R1 which are generated by R0KH are respectively stored by R0KH and R1KH in the AC after a successful IEEE 802.1X Authentication. After 4-way handshake or authentication of FBSS, R1KH generates a PTK. As the PTK generated by R1KH must be held by PTK-KH, while PTK-KH locates in the WTP, it needs to be delivered from the AC to the WTP. This scenario is likely to occur in local MAC model and split MAC model. 3.3. Scenario C The figure 4 shows R0KH locates in the AC, while both R1KH and PMK-KH locates in the WTP. +----------+ +----------+ +----------+ | STA |---------| WTP |------------| AC | +----------+ | | | | | R1KH | | | | PTK-KH | | R1KH | +----------+ +----------+ Figure 4 Scenario C In this scenario, both PMK-R0 and PMK-R1 are generated by R0KH in the AC after a successful IEEE 802.1X Authentication. Before R1KH generates a PTK, it must get the PMK-R1 from R0KH. However, as the generator and holder of PMK-R1 locate in different physical entities, PMK-R1 must be distributed from the AC to the WTP. 3.4. Scenario D Scenario D is a scenario that R1KH, R0KH and PTK-KH locate in a WTP. The scenario is likely to appear in an Autonomous Architecture instead of part of the Centralized Architecture. Ye & Wan Expires June 4, 2007 [Page 7] Internet-Draft fbsskey distribution ps Dec. 2006 4. Key distribution considerations As described from above, the WTP and the AC are respectively separated in any MAC model of the Centralized WLAN Architecture (e.g. Local MAC, Split MAC or Remote MAC), while R0KH, R1KH and PTK-KH may locate in a WTP or AC according to 802.11r. If a physical entity of key generator differs from the physical entity of its holder, there exists key distribution between the generator and the holder. Two key distributions are involved in the above scenarios, for example, there are PMK-R1 distribution in scenario C and PTK distribution in scenario B for their generator and holder locating in different physical entities. 4.1. PMK-R1 distribution considerations To secure PMK-R1 distribution using CAPWAP protocol, a pre- established SA (PSA) must be established between the WTP and the AC. Generally, PMK-R1 is also derived when STA associates firstly a domain. PMK-R1 generation and distribution may include the following steps: 1) 802.1 X EAP Authentication is performed between STA and AC. 2) AC receives MSK from AAA server. And generates PMK-R0 and PMK-R1. 3) PMK-R0 is delivered from the AC to WTP using CAPWAP protocol. 4) PTK is generated after 4-way handshake to protect association signaling. 5) AC authorizes WTP for STA's association. The following properties should be involved in the distribution according to 802.11r requirement. 1) Authentication of entities involved in key distribution. 2) Confidentiality of the key distribution. 3) Authorization of the status of a PMK-R1 holder. 4) Validation of the authorization. 5) Receipt of the key is acknowledged. Ye & Wan Expires June 4, 2007 [Page 8] Internet-Draft fbsskey distribution ps Dec. 2006 6) Correctness of the authorization attributes assigned to the STA. Sometimes, to decrease handover delay, PMK-R1 may be distributed to several WTPs which are the current WTP Neighbors [FAMFH]. So beside these above properties required by 802.11r, the following issues should also be considered for PMK-R1 distribution: 1) If a STA initiates PMK-R1 distribution for several WTPs, which are the STA's Neighbors, it may communicate with the AC via a current WTP. So exchange security should be considered between the current WTP and the Neighbors WTP. 2) Neighbor WTPs must be able to authenticate that PMK-R1 is from a legal STA. 4.2. PTK distribution considerations Typically, after 4-way handshake or authentication of FBSS between the WTP and the AC, the AC sends the PTK, which is used to protect association signaling, to the WTP. Steps of PTK generation and distribution are listed below: 1) After 802.1 X EAP Authentication, AC delivers PMK-R0 from MSK or PSK and PMK-R1. 2) PTK is generated and distributed to the WTP using CAPWAP protocol after 4-way handshake to protect association signaling. 3) AC authorizes WTP for STA's association. To secure PTK distribution, a pre-established SA (PSA) must be established between the WTP and the AC. Some additional issues should be considered. They are listed below: 1) The AC must be able to authenticate the WTP. 2) The PTK must confidentially be distributed to the WTP. 3) The WTP must get authorization to accept the PTK. 4) The WTP must authenticate the PTK. 5. CAPWAP considerations As CAPWAP hasn't specially been designed for 802.11r, CAPWAP as an exchange protocol, which runs over DTLS[DTLS] between a WTP and an AC Ye & Wan Expires June 4, 2007 [Page 9] Internet-Draft fbsskey distribution ps Dec. 2006 must be extended to support the key distribution. All key distribution packages must use control messages. However, since there is not message type for key distribution, additional message type must be added in CAPWAP protocol. PMK-R0 messgae types which are used for PMK-R0 distribtuion. PTK message types which are used for PTK distribution. Before the lifetime of PMK-R1 and PTK is expired, the lifetime must be updated. So two timers, R1lifetime and PTKlifetime should be considered. R1lifetime that is used for PMK-R1. PTKlifetime that is used for PTK. The two timers may launch key distribution by using CAPWAP protocol before their lifetimes are expired. When key distribution is initiated by a STA, (e.g. when a STA moves from a WTP to the another one, the STA will launch key distribution between the WTP and AC. ), two timers should be set to zero. The case that Key context information may be transmitted from the current WTP to a new WTP via the AC if there is "over-the-DS" is also considered for key distribtuion. 6. Security Considerations This document aims to provide a problem statement of keys distribution of 802.11r using CAPWAP. When generator of PMK-R1 and its holder locate in different physical entities, security of two keys distribution must be considered. 7. IANA Consideration This document does not require any actions by IANA. 8. References 8.1. Normative References [DTLS] Escorla, E. and N. Modadugu, "Datagram Transport LayerSecurity, RFC4347", April 2006. Ye & Wan Expires June 4, 2007 [Page 10] Internet-Draft fbsskey distribution ps Dec. 2006 [FAMFH] Bargh, M., Hulsebosch,, R., Eertink, E., Prasad, A., Wang, H., and P. Schoo, "Fast Authentication Methods for Handovers between IEEE 802.11 Wireless LANs", Oct. 2004. [IEEE802.11i] "IEEE Std 802.11i-2004: 802.11 Medium Access Control (MAC) Security enhancements", July 2004. [IEEE802.11r] "IEEE Std 802.11r/D3: 802.11 Fast BSS Transition", Sep. 2006. [capwap] Montemurro, M. and D. Stanley, "CAPWAP Base Protocol Specification", Oct 2006, . 8.2. Informative References [RFC4118] Yang, L., Calhoun, P., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", June 2005. [STANDARDS] "Key words for use in RFCs to Indicate Requirement Levels", Oct 1997, . Ye & Wan Expires June 4, 2007 [Page 11] Internet-Draft fbsskey distribution ps Dec. 2006 Authors' Addresses Chengping Ye Huawei Technologies Site A,Floor 10,HuiHong Mansion,No.91 BaiXia Rd. Nanjing, China 210009 Phone: +86-25-84565458 Email: yechengping@huawei.com Changsheng Wan Huawei Technologies Site A,Floor 10,HuiHong Mansion,No.91 BaiXia Rd. Nanjing, China 210009 Phone: +86-25-84565457 Email: wanchangsheng@ustc.edu Ye & Wan Expires June 4, 2007 [Page 12] Internet-Draft fbsskey distribution ps Dec. 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ye & Wan Expires June 4, 2007 [Page 13]