Network Working Group L. Xue Internet-Draft D. Zhang Intended status: Informational Huawei Expires: August 14, 2014 B. Gao China Telecom February 10, 2014 RADIUS Extensions for Key Management in WLAN network draft-xue-radext-key-management-02 Abstract When a mobile device (referred to as Station (STA) in this work) tries to connect to a Wireless Local Area Network (WLAN), it needs to first perform mutual authentication with the EAP server of the network. As a result of successful authentication, a Pairwise Master Key (PMK) will be generated, and distributed to the STA and the Authenticator of the network by the EAP server respectively. The PMK is used for securing the subsequent communications between the STA and the Wireless Termination Point (WTP) it attaches to. In practice, the authenticator may not be deployed on the WTP. In this case, an approach is required to help the WTP to obtain the PMK. This work tries to discuss the issues related with this topic and proposes a RADIUS extension to address the problem. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on August 14, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Xue, et al. Expires August 14, 2014 [Page 1] Internet-Draft key management via radius February 2014 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. EAP in WLAN . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Motivation Scenario . . . . . . . . . . . . . . . . . . . . . 5 6. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 7 6.1. RADIUS Commands for PMK Transportation . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction WLAN is now widely used by service operators as a complement of the cellular (2G/3G/LTE) networks, and Extensible Authentication Protocol (EAP)[RFC3748] is regarded as a widely preferred solution for STA authentication in WLAN. When a STA tries to connect to the WLAN, it needs to mutually authenticate with the EAP server of the network first. According to the security requirements specified in [IEEE-802.11i], a successful EAP authentication procedure must result in a Pairwise Master Key (PMK) for the communication between the STA and the EAP server. In addition, the EAP server also distribute the PMK to the Authenticator. In practice, the encryption/decryption operations on the STA traffics are carried out either on the WTP or the associated Access Controller (AC) [RFC5416], and so they need to get the PMK to perform this job. In some deployment scenarios, the Authenticator may be deployed on a Gateway (GW) node rather than on the WTP or the AC. In this case, a solution needs to be provided in order to forward keys to the WTP/AC. Xue, et al. Expires August 14, 2014 [Page 2] Internet-Draft key management via radius February 2014 This document proposes a solution which extends RADIUS so as to enable an Authenticator to transfer PMKs to the associated WTPs or ACs. 2. Requirements Language 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 [RFC2119]. 3. Terminology This document uses the same terminologies as found in [RFC5415]and [RFC5247]. Some of the terms defined in the document have been repeated in this section for the convenience of the reader, along with additional terminologies that are used by this document. Access Controller (AC) The network entity that provides WTP access to the network infrastructure in the data plane, control plane, management plane, or a combination therein. Authenticator The entity initiating EAP authentication. Backend Authentication Server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. This terminology is also used in [IEEE-802.1X] EAP Server The entity that terminates the EAP authentication method with the supplicant. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server. In this work, the latter case is considered. Gateway (GW) A device in operator access network, who can charge the subscriber authentication and IP address management. Xue, et al. Expires August 14, 2014 [Page 3] Internet-Draft key management via radius February 2014 Station (STA) A device that contains an interface to a wireless medium. User equipment (UE) with (U)SIM is one type of STA. In authentication procedure, STA is the Supplicant. Pairwise Master Key (PMK) PMK is a fresh symmetric key controlling STA's and the encryption/ decryption node (WTP or AC) access to 802.11 channel during the session. Pairwise Transient Key (PTK) PTK is used to encrypt/decrypt unicast traffic for STA which is derived from the 4-way handshake [IEEE-802.11i]. Group Temporal Key (GTK) GTK is used to encrypt/decrypt multicast/broadcast traffic for STA, which is derived from the 4-way handshake[IEEE-802.11i]. Wireless Termination Point (WTP) The physical or logical network entity that contains an RF antenna and wireless physical layer (PHY) to transmit and receive station traffic for wireless access networks. 4. EAP in WLAN In WLAN, EAP [RFC3748] messages are normally transported over RADIUS [RFC2865][RFC2866][RFC3579]. An example of end-to-end EAP authentication in a WLAN is illustrated in Figure 1. Xue, et al. Expires August 14, 2014 [Page 4] Internet-Draft key management via radius February 2014 Supplicant (STA) Authenticator EAP Server +-------+ +-------+ +-------+ | | | | | | | | | | | | | | | | | | +-------+ +-------+ +-------+ | | | |EAP-Request Identity | | |<-------------------------+ | |EAP-Response Identity | | | | | |------------------------->| | | | RADIUS Access Request | | +------------------------->| | EAP type specific | | mutual authentication | |<-------------------------o------------------------->| | | | | |RADIUS Access Accept(with PMK) | |<-------------------------+ | EAP-Success | | |<-------------------------+ | | | | Figure 1. EAP Operation In the EAP authentication framework, there are three entities: o Supplicant: The end of the link that responds to the Authenticator. In this work, a supplicant is actually a STA. o Authenticator: An entity that facilitates authentication of other entities attached to the same LAN. In a WLAN, an Authenticator could be deployed on WTP, AC or GW according to the operator's requirements. o EAP Server : An entity provides an authentication service to an authenticator. In this work, it is assumed that an EAP server is deployed on a backend device (e.g., AAA server). 5. Motivation Scenario The architecture of a typical WLAN deployment [BBF-WT-321] is shown in Figure 2 . Xue, et al. Expires August 14, 2014 [Page 5] Internet-Draft key management via radius February 2014 +--------+ +--------+ | AAA | | DHCP | +---\----+ +----/---+ \ / \ / /----\ +----+ +--------+ +--------+ +-+--+---+ / \ |STA +----+ WTP +-----+ AC +-----+ GW +-------| IP MAN | +----+ +--------+ +--------+ +--------+ \ / \----/ Figure 2 WLAN architecture As illustrated in this diagram: o AC and GW are deployed separately. o AC is responsible for AP management as [RFC5415]. o GW is responsible to provide IP address management and traffic management ( e.g., QoS, Charging, Remark, etc) for each STA attached to it. When a STA attempts to access the WLAN, GW will assign an IPv4 address to the STA after the STA has been authenticated. In addition, based on the privileges associated with a STA, GW can decide whether to forward (maybe certain types of) STA traffics not. Assuming a STA is attached to the WLAN. After a successful EAP session, the GW needs to obtain sufficient information about the STA (including authentication and authorization results) to provide IP address management and traffic management. There are two candidate solutions to achieve this. The first solution is to deploy the Authenticator on the AC. In this case the GW can act as a RADIUS PROXY during EAP procedure to get the STA information, as shown in figure 3. In this solution, both the GW and the AC MUST be involved with the EAP authentication procedure, and the STA related information needs to be redundantly maintained on both the GW and the AC. In addition, this solution will make ACs more complex. Especially, in the scenarios where there are large amount of WTPs, ACs MUST be deployed close to the WTPs because of normally a AC is only able to manage a limited number of WTPs. As a result, there will be a large amount of ACs in the network, which could be costly for operators and could introduce enormous management costs on both EAP servers and ACs. Moreover, the encryption of the communication between EAP server and ACs may damage the effectiveness of this solution. Xue, et al. Expires August 14, 2014 [Page 6] Internet-Draft key management via radius February 2014 The second solution is to deploy the Authenticator on the GW. This solution can largely avoid this issues occurred in the first solution. ACs do not have to support EAP procedures, and the number of GWs could be much less than the number of ACs in a WLAN. However, in the second solution, the GW needs to find a way to forward the PMK to the AC,which is the objective of this work. Authenticator EAP Server +-------+ +----+ +----+ +-------+ +-------+ | | | | | | | | | | | STA | |WTP | | AC | | GW | | EAP | | | | | | | | | | Server| +-------+ +----+ +----+ +-------+ +-------+ | | | | |EAP-Request Identity | | | <---------------------+ | | |EAP-Response Identity| | | |-------------------->| | | | | RADIUS Access Request | | +----------->------------------------->| | | | | | | RADIUS Access Challenge | | |<----------<--------------------------| | EAP Exchange | | | |<------------------->| | | | | RADIUS|Access Request | | +----------->------------------------->| | | | | | | RADIUS Access Accept | | |<----------<--------------------------| | EAP Success | | | |<--------------------+ | | | | | | | DHCP Exchange | | |<--------------------+---------->| | | | | Accounting | | | +----------------------> | Figure 3 GW acts as RADIUS PROXY 6. Protocol overview As introduced above, the encryption/decryption operations could be performed on either AC or WTP. If the AC is the encryption/ decryption node, the Authenticator then needs to send the PMK to AC. If the WTP is the encryption/decryption node, the Authenticator can Xue, et al. Expires August 14, 2014 [Page 7] Internet-Draft key management via radius February 2014 also send the PMK to AC, and AC then forwards the PMK to WTP via protocol defined in [RFC4564]. Therefore, this work specifies three RADIUS commands and a set of attributes for PMK transportation from Authenticator(GW) to AC, i.e., Key-of-Announcement (KoA), KoA-ACK and KoA-NAK. The PMK transportation is trigged when the Authenticator receives a RADIUS Accept message in EAP session which indicates the authentication success. 6.1. RADIUS Commands for PMK Transportation Authenticator +---------+ +---------+ | | | | | | | | | AC | | GW | | | | | +---------+ +---------+ | | | KoA Message | |<--------------------------------------| | | | | | | | KoA ACK/NAK Message | |-------------------------------------> | | | | | | | | | Figure 4 RADIUS Commands for PMK Transportation As illustrated in the above figure, during the authentication procedure between a STA and a EAP server, the GW acts as an Authenticator. The GW constructs a KoA message and forwards the message to the AC when it obtains the PMK carried in the RADIUS Accept message from EAP server. The AC responds with a KoA-ACK message after successfully accept the PMK. Otherwise, the AC responds with a KoA-NAK. The commands use the format of Change-of-Authorization Messages (CoA) [RFC5176], presented as follows Xue, et al. Expires August 14, 2014 [Page 8] Internet-Draft key management via radius February 2014 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- Figure 5 Packet Format Code The Code field is one octet, and identifies the type of RADIUS packet. Three new RADIUS codes are defined. o 100 - Key-of-Announcement o 101 - KoA-ACK o 102 - KoA-NAK Identifier This field is one octet, and aids in matching requests and replies. This value is set by GW in this specification when GW sends the KoA message to the AC. It is used to identifier a pair of KoA and KoA- ACK/NAK message. The Identifier field must be changed by GW whenever a valid reply has been received for a previous request. Authenticator The same as defined in [RFC5176]. The following attributes should be included in KoA, KoA-ACK and KoA- NAK messages. o Calling-Station-Id. This attribution is used to take the STA identifier, for example MAC address. It can be used to bind the PMK to a special STA. This attribute may include within KoA, KoA- ACK and KoA-NAK messages. The values are shown below. Type Xue, et al. Expires August 14, 2014 [Page 9] Internet-Draft key management via radius February 2014 31 as defined in [RFC5176]. Length 8 Value The Value field is 6 octets, containing the STA MAC address. o Keying-Material. This attribute is used by GW to transport the PMK to the AC. This attribute may include within KoA, KoA-ACK and KoA-NAK messages. The format and the values are shown below. 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 Keying-Material Attribute Format Type The type could be an unassigned type right now. In this specification, type 17 is recommended. Length 34 Value The Value field is 32 octets, containing the PMK information. o KoA-Feedback. It is responsible to provide the feedback when AC receives the KoA command from GW. This attribute may include within KoA-ACK/NAK messages. The format is shown below. Xue, et al. Expires August 14, 2014 [Page 10] Internet-Draft key management via radius February 2014 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 KoA-Feedback Attribute Format Type The type could be an unassigned type right now. In this specification, type 21 is recommended. Considering the compatibility, the type 18 can also be used referenced in[RFC2865]. Length 4 Value The Value field is 2 octets, containing the feedback from the AC when received the KoA message. It could be reasons for PMK transportation fails. 7. IANA Considerations TBD 8. Security Considerations TBD 9. Normative References [BBF-WT-321] "Public Wi-Fi Access in Multi-service Broadband Networks", January 2014. [IEEE-802.11i] "Institute of Electrical and Electronics Engineers, "Unapproved Draft Supplement to Standard for Telecommunications and Information Exchange Between Systems-LAN/MAN Specific Requirements -Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security" "", September 2004. Xue, et al. Expires August 14, 2014 [Page 11] Internet-Draft key management via radius February 2014 [IEEE-802.1X] "Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control"", September 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4564, July 2006. [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008. [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008. [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009. [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, March 2009. Authors' Addresses Xue, et al. Expires August 14, 2014 [Page 12] Internet-Draft key management via radius February 2014 Li Xue Huawei No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, Beijing, HaiDian District 100095 China Email: xueli@huawei.com Dacheng Zhang Huawei Beijing China Email: zhangdacheng@huawei.com Bo Gao China Telecom No. 1835, South Pudong Road Shanghai 200122 China Email: gaobo@sttri.com.cn Xue, et al. Expires August 14, 2014 [Page 13]