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, <http:// www.ietf.org/
internet-drafts/
draft-ietf-capwap-protocol-specification-03.txt>.
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,
<ftp://ftp.isi.edu/in-notes/rfc2119.txt>.
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]