Network Working Group L. Xue Internet-Draft Huawei Intended status: Informational B. Gao Expires: January 13, 2014 China Telecom July 12, 2013 RADIUS Extensions for Key Management in WLAN network draft-xue-radext-key-management-01 Abstract It is a general case in operators networks that Authenticator is deployed on Service Gateway (SGW) to avoid overload on the Access Controller (AC). In this scenario, the encryption/decryption node can't obtain Pairwise Master Key (PMK) information during Extensible Authentication Protocol (EAP) procedure, it is not sufficent to achieve traffic encryption/decryption requirement in Wireless Local Area Network (WLAN) network. This document analyzes the requirement and issue for key management that has arisen so far during authentication process in WLAN network. Meanwhile, the control messages for key management are defined. 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 January 13, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Xue & Gao Expires January 13, 2014 [Page 1] Internet-Draft key management via radius July 2013 (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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 5. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 6 5.1. PMK Announcement Messages . . . . . . . . . . . . . . . . 6 6. Authentication Procedure . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The Wireless Local Area Network (WLAN) is becoming very popular, which is used in many industries (the financial, medical, and manufacturing, etc). It features low cost and flexible network, and high speed wireless data access with open spectrum. Besides, the WLAN technology is now used by more and more service operators to supplement cellular (2G/3G/LTE) network. Based on the WLAN security requirements mentioned in [IEEE-802.11i], keying material used for encryption and integrity algorithms MUST be obtained in the uniform authentication procedure. During the Extensible Authentication Protocol (EAP) [RFC3748] procedure between Station (STA) and Authenticator Server (AS), Pairwise Master Key (PMK) will be generated as a side effect. Moreover, AS distributes PMK to the Authenticator defined in[RFC3748]. Then, the PMK and 4-way handshake [IEEE-802.11i]are used to derive, bind and verify the Pairwise Transient Key (PTK), which is a collection of operational keys for secure between STA and encryption/ decryption node. Also,Group Transient Key (GTK) can be derived, and is used to secure multicast/ broadcast traffic between STA and encryption/decryption node. However, in practice, it is a general case in operators networks that Authenticator is deployed on Service Gateway (SGW) to avoid overload Xue & Gao Expires January 13, 2014 [Page 2] Internet-Draft key management via radius July 2013 on the Access Controller (AC). In this scenario, the encryption/ decryption node can't obtain PMK information during EAP procedure, it is not sufficient to achieve traffic encryption/decryption requirement in WLAN network. This document analyzes the requirement and issue for key management that has arisen so far during authentication process in WLAN network. Meanwhile, the control messages for key management are defined. The specification described in this document is applicable if authenticator function is not collocated with the encryption/ decryption function in WLAN. It is recommended for WLAN network deployment as informational. 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 following terminologies. 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. This definition has the same meaning used in [RFC4118]. 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, as defined in [RFC4118] Authentication Server(AS) An entity that provides an authentication service to an authenticator. This service determines, from the credentials provided by the Supplicant, whether the Supplicant is authorized to access the services provided by the system in which the authenticator resides. AS is generally located on the backend AAA server. Authenticator Xue & Gao Expires January 13, 2014 [Page 3] Internet-Draft key management via radius July 2013 An entity that facilitates authentication of other entities attached to the same LAN. The term authenticator is also used in [RFC3748], and has the same meaning in this document. Service Gateway (SGW) A device in operator access network, who can charge the subscriber authentication. It maybe BRAS (Broadband Remote Access Server) or BNG (Broadband Network Gateway). Supplicant Supplicant is kind of device in authentication. A device at one end of a point-to-point LAN segment seeks to be authenticated by an Authenticator. It is the same as the Peer defined in [RFC3748]. The supplicant is station (STA) in WLAN network. 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 supplicant, 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 supplicant, which is derived from the 4-way handshake[IEEE-802.11i]. 4. Problem Statement In practice, ACs are deployed on the centralized center in existing operator networks. In order to avoid the traffic overload on AC, WTPs forward the wireless frames directly to SGW deployed in the network. The AC does not have the intelligence to aggregate all the wireless frames. An illustration of the WLAN centralized architecture is shown as follows. Xue & Gao Expires January 13, 2014 [Page 4] Internet-Draft key management via radius July 2013 +------+ | | | AC | | | +--+---+ | | | +------+ +------+ +--+---+ /-------\ | | | | | | | | | STA | /-/ | WTP +--------------+ SGW +----+ Service | | | | | | | | | +------+ +------+ +------+ \-------/ Figure 1 WLAN Centralized Architecture In EAP framework, SGW could act as the Authenticator instead of AC because of several reasons. First of all, a powerful AC that aggregates the Authenticator function is not a appreciated choice for some operators.There are large numbers of AC devices in the operators existing network. The AS will overload the communication with large numbers of AC devices if ACs acts as the Authenticator. On the other hand, SGW MUST support the RADIUS Relay function when AC acts as the Authenticator in EAP framework. In this scenario, both SGW and AC should be responsible for authentication procedure. For operators, it is cost in large-scale upgraded deployment. Consequently,it is a popular scenario for operator to deploy the EAP Authenticator on SGW. Unfortunately, the Authenticator SGW is the only node which can obtain the derived PMK,except of STA and AS. But AC is supposed to deliver the PMK to the WTP to guarantee the security requirement, and there is not standard interface for SGW sending the PMK to the WTP or the AC. The authentication procedure when SGW acting as Authenticator is shown as following figure. In this document, the mechanism is specified to inform the PMK to ecryption/decryption node, which is the WTP or AC. Authenticator Supplicant Authenticator Server +-------+ +----+ +----+ +-------+ +-------+ | | | | | | | | | | | STA | | WTP| | AC | | SGW | | AAA | | | | | | | | | | | +-------+ +----+ +----+ +---+---+ +-------+ | Xue & Gao Expires January 13, 2014 [Page 5] Internet-Draft key management via radius July 2013 | | | |802.1x/EAP-Requesr Identity | | |<------------------------------+ | |802.1x/EAP-Response Identity | | | (EAP type specific) | | |------------------------------>| RADIUS Access | | | Request/Identity | | +------------------------->| | EAP type specific | | mutual authentication | |<------------------------------o------------------------->| | | | | | Radius Accept(with PMK) | | |<-------------------------+ | 802.1x/EAP-Success | | |<------------------------------+ | | | | Figure 2 Authentication Procedure When SGW Deployed as Authenticator 5. Protocol overview Based on the analysis above, it is recommended that control messages used for PMK announcement from SGW to WTP/AC should be defined when SGW acts the EAP Authenticator. If AC is the encryption/decryption node, the SGW sends the PMK to AC via these control messages. If WTP is the encryption/decryption node, the SGW sends the PMK to AC as well, then AC sends the obtained PMK to WTP via protocol defined in [RFC4564]. However, the SGW can send the PMK to WTP directly, which conforms to the mechine defined in this document. As we know, RADIUS attributes are comprised of variable length Type- Length-Vaule 3 tuples. New attribute values can be added without disturbing existing implementation of the protocol. This document describes the RADIUS extension to support the PMK announcement between SGW and WTP/AC. Specially, new RADIUS messages, including Key-of-Announcement(KoA) message, KoA-ACK/NAK message, are defined. 5.1. PMK Announcement Messages There are three messages defined for PMK announcement, shown in following figures. Authenticator +---------+ +---------+ | | | | Xue & Gao Expires January 13, 2014 [Page 6] Internet-Draft key management via radius July 2013 | | | | | WTP/AC | | SGW | | | | | +---------+ +---------+ | | | KoA Message | |<--------------------------------------| | | | | | | | KoA ACK/NAK Message | |-------------------------------------> | | | | | | | | | Figure 3 PMK Announcement Messages o During the authentication procedure, when SGW obtains the PMK from AS, the SGW initiates the KoA message and send it to the AC. o If AC is able to obtain the PMK successfully, AC responds the KoA ACK message to SGW. Otherwise, AC responds the KoA NAK message to SGW. The format for PMK announcement messages is shown as follows. 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 4 PMK Announcement Message Format Code Xue & Gao Expires January 13, 2014 [Page 7] Internet-Draft key management via radius July 2013 The Code field is one octet, and identifies the type of RADIUS packet. Packets with an invalid Code field MUST be discarded silently. o KoA: TBD o KoA-ACK: TBD o KoA-NAK (optional): TBD Identifier The Identifier field is one octet. It is used to identifier a pair of KoA and KoA-ACK/NAK message. This value is set by SGW in this specification when SGW sends the KoA message to AC. The Identifier field must be changed by SGW whenever a valid reply has been received for a previous KoA message. Authenticator The same as defined in [RFC3576]. In addition, the following attributes should be included in PMK Announcement messages. o Calling-Station-Id. This attribution is used to carry the STA identifier, for example MAC address. It can be used to bind the PMK for a special STA. The call-station-id attribute may be included within KoA, KoA-ACK/NAK messages. The values are shown below. Type 31 as defined in [RFC5176]. Length 8 Value The Value field is 6 octets, containing the STA MAC address. o Keying-Material, shown as follows. This attribute is used by SGW to transport PMK to AC. The Keying-material attribute may be included within KoA-ACK/NAK messages. The format is shown in following figure. Xue & Gao Expires January 13, 2014 [Page 8] Internet-Draft key management via radius July 2013 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 5 Keying-Material Attribute Format Type TBD Length 34 Value The Value field is 32 octets, containing the PMK information. o KoA-Feedback, shown as follows. It is responsible to provide the feedback when AC receives the KoA message from SGW. The KoA- Feedback attribute may include within KoA-ACK/NAK messages. 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 6 KoA-Feedback Atrribute Format Type TBD Length 4 Value Xue & Gao Expires January 13, 2014 [Page 9] Internet-Draft key management via radius July 2013 The Value field is 2 octets, containing the feedback from the AC when received the KoA message. In this version, several values are defined. o 0 Succeed o 1-8 Reject, can be used in KoA-NAK to indicate the fail reasons. 6. Authentication Procedure Based on the control message defined in this document, the recommended procedure is shown as follows. Authenticator Supplicant Authenticator Server +-------+ +----+ +-------+ +-------+ | | | | | | | | | STA | | AC | | SGW | | AAA | | | | | | | | | +-------+ +-+--+ +---+---+ +-------+ | | | | | | |802.1x/EAP-Requesr Identity | | ~~~~ |<------------------------------+ | ^ |802.1x/EAP-Response Identity | | | | (EAP type specific) | | | |---------------+-------------->| RADIUS Access | | | | Request/Identity | | | +------------------------->| 1 | |EAP type specific | | mutual authentication | |<------------------------------o------------------------->| | | | | | | | | | Radius Accept(with PMK) | v | | |<-------------------------+ | 802.1x/EAP-Success | | ~~~~ |<------------------------------+ | | | | | | | 2 KoA | | | |<==============+ | | | | | | |3 KoA ACK/NAK | | | +==============>| | | | | | Figure 7 Authentication Procedure Xue & Gao Expires January 13, 2014 [Page 10] Internet-Draft key management via radius July 2013 1 Mutual authentication procedure as general defined in [RFC3748][IEEE-802.1X]. 2 After EAP authentication completes, the SGW acting as Authenticator initiates and transmits the KoA packet to AC via KoA message. It is desirable to provide keying information needed based on [IEEE-802.11i]. 3 AC should interpret the KoA message and obtain the PMK included in Keying-material attribute as an indication that the AS has successfully authenticated the STA. If AC is able to get the PMK successfully, AC responds the KoA ACK message to SGW. Otherwise, AC responds the KoA NAK message to SGW. Additionally, the derived PMK can be used with 4-Way Handshake to derive, bind, and verify PTK or GTK, which is out of the scope. 7. IANA Considerations TBD 8. Security Considerations The security must be guaranteed between the SGW and the WTP/AC for key announcement. If there is security requirements, IPsec tunnel or MD5 encryption/decryption algorithm between SGW and WTP/AC are needed. 9. Normative References [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. [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. Xue & Gao Expires January 13, 2014 [Page 11] Internet-Draft key management via radius July 2013 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005. [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. Authors' Addresses 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 Bo Gao China Telecom No. 1835, South Pudong Road Shanghai 200122 China Email: gaobo@sttri.com.cn Xue & Gao Expires January 13, 2014 [Page 12]