Network Working Group L. Xue Internet-Draft Huawei Intended status: Informational February 18, 2013 Expires: August 22, 2013 RADIUS Extensions for Key Management in WLAN network draft-xue-radext-key-management-00 Abstract In order to guarantee the security and integration of the subscriber in WLAN network, Pairwise Master Key (PMK) will be generated as an access authorization token during the mutual authentication procedure between station (STA) and authenticator server (AS). Then, the PMK and 4-way handshake are used between STA and Authenticator to derive, bind and verify the Pairwise Transient Key (PTK), which is a collection of operational keys for security. Also,Group Transient Key (GTK) can be derived, and is used to secure multicast/broadcast traffic. In the authentication architecture, only STA and AS can manufacture PMK, moreover, AS can only distribute PMK to Authenticator.However, if the authenticator function is not collocated with the encryption/decryption function, it is difficult to achieve traffic encryption/decryption in WLAN network.The purpose of this document is to analyze the requirement and issue for key management that have arisen so far during STA 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 August 22, 2013. Copyright Notice Xue Expires August 22, 2013 [Page 1] Internet-Draft key management via radius February 2013 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 (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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4.1. 802.1x/EAP Operation . . . . . . . . . . . . . . . . . . . 5 4.2. Possibility of Authentication Entities in WLAN . . . . . . 7 4.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 9 5. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 10 5.1. PMK Announcement Messages . . . . . . . . . . . . . . . . 11 6. Authentication Procedure . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Normative References . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Xue Expires August 22, 2013 [Page 2] Internet-Draft key management via radius February 2013 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. In order to enhance the user experience, the perception-free authentication for WLAN network is preferred. Additionally, for operators, it is the trend to do unified authentication together with 2G/3G/LTE network, especially for user equipment with (U)SIM. EAP[RFC3748] based authentication methods are widely deployed in WLAN network. EAP is end-to-end transport for authentication framework between Supplicant and Authentication Server (AS). 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. Fortunately, 802.11i implements a key derivation/management regime. During the mutual authentication procedure between STA and AS, Pairwise Master Key (PMK) will be generated as a side effect. The PMK,which is a fresh symmetric key. 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. In the authentication architecture, only STA and AS can manufacture PMK, moreover, AS distributes PMK to to Authenticator.However, if the authenticator function is not collocated with the encryption/ decryption function, it is difficult to achieve traffic encryption/ decryption in WLAN network.For example, the authenticator is deployed on Gateway (GW) node, whereas, the encryption/decryption node always WTP or AC.The purpose of this document is to analyze the requirement and issue for key management that have 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. Xue Expires August 22, 2013 [Page 3] Internet-Draft key management via radius February 2013 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 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. Gateway (GW) 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 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 Xue Expires August 22, 2013 [Page 4] Internet-Draft key management via radius February 2013 defined in [RFC3748]. The supplicant is station (STA) in WLAN network. It can be user equipment (UE) device. We can also call the supplicant as subscriber. 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 deployed as 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 4.1. 802.1x/EAP Operation As a generic authentication framework, EAP[RFC3748] can be used combined with some payload protocols. In WLAN network, EAP is carried over authentication protocol such as RADIUS [RFC2865][RFC2866][RFC3579]. An example for end-to-end EAP procedure in context of WLAN is shown as following figure 1. Xue Expires August 22, 2013 [Page 5] Internet-Draft key management via radius February 2013 Authenticator Supplicant Authenticator Server +-------+ +-------+ +-------+ | | | | | | | | | | | | | | | | | | +-------+ +-------+ +-------+ | | | |802.1x/EAP-Request 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 1 802.1x/EAP Operation In the 802.1x/EAP authentication framework, there are three entities acting as follows. o Supplicant: The end of the link that responds to the authenticator, as well same meaning as the peer mentioned in [RFC3748] . In this document, STA is one type of supplicant, it could be User equipment (UE) with (U)SIM ,etc. o Authenticator: An entity that facilitates authentication of other entities attached to the same LAN, defined in[RFC3748]. In the existing WLAN, whichever WTP, AC or Service Gateway could be deployed as Authenticator based on operator's requirement. o Authenticator Server: 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 mentioned in [IEEE-802.1X], the Xue Expires August 22, 2013 [Page 6] Internet-Draft key management via radius February 2013 Authentication Server function can be co-located with an Authenticator, or it can be accessed remotely via a network to which an Authenticator has access. In this document, we assume the Authenticator server isn't co-located with the Authenticator. Always, AAA server is the Authenticator Server. Actually, there are several possibilities of entities deployment in WLAN, especially the Authenticator. Also sometimes the authenticator is a standalone device which doesn't support encryption/decryption function. In the next sub-section, the possibilities of entities deployment in typically WLAN are described . 4.2. Possibility of Authentication Entities in WLAN Based on the WTP type in WLAN, which is an intelligent device or a little more than radio-for-wire media converter, some industry analyses have oversimplified the WLAN architecture into two categories. They are WTP autonomous management architecture and WTP centralized management architecture. The previous type of WTP is also called as "FAT AP". The FAT AP is a standalone device responsible for all WLAN functionality, such as encryption/ decryption, authentication, etc. Instead, the other type of WTP is always defined as FIT AP. The FIT AP is a radio-for-wire media converter. The WTPs will be managed by Access Controller (AC). In the autonomous architecture, each of the WTPs is managed by itself independently, as shown in Figure 2. In this case, the authentication entities is deployed as: o Supplicant: STA o Authenticator: WTP, also providing encryption/decryption function. o AS: AAA server as general. +------+ +------+ +------+ /-------\ | | | | | PE/ | | | | STA | /-/ | WTP +-------------+ GW +----+ Service | | | | | | | | | +------+ +------+ +------+ \-------/ Figure 2 Autonomous Architecture Comparatively, in the centralized management architecture, WTPs have less functions and added Access Controller (AC) is responsible for configuration, control and management of WTPs. The 802.11 function Xue Expires August 22, 2013 [Page 7] Internet-Draft key management via radius February 2013 splits between WTP and the Access Controller (AC) in this architecture.Figure 3 shows an example of a centralized management network. In this case, the authentication entities is deployed as: o Supplicant: STA o Authenticator: WTP/AC/GW, but only WTP/AC can provide encryption/ decryption function. o AS: AAA server as general. +------+ | | | AC | | | +--+---+ | | | +------+ +------+ +--+---+ /-------\ | | | | | PE/ | | | | STA | /-/ | WTP +--------------+ GW +----+ Service | | | | | | | | | +------+ +------+ +------+ \-------/ Figure 3 Centralized Architecture As described in previous section, only authenticator can obtain the PMK during the authentication. Meanwhile 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. In the centralized architecture, if the authenticator function is deployed on GW node, not collocated with the encryption/decryption function, it is difficult to achieve traffic encryption/decryption in WLAN network. Actually, it is a general case in existing network because AC isn't intelligent enough to aggregate all the WLAN critical functions in one. Consequently, It is a popular scenario to split the authentication function from AC to GW, which is the existing authentication gateway for other service, such as PPP, etc. This enables a better environment that diminishes the software and Xue Expires August 22, 2013 [Page 8] Internet-Draft key management via radius February 2013 hardware upgrade for operator. In this scenario, the issues for key management arises. For the following discussion, the problem statement is introduced for key management during STA's authentication process in centralized architecture. 4.3. Problem Statement Pairwise Master Key (PMK) will be generated as an access authorization token during the mutual authentication procedure between STA and AS to guarantee the security requirement in WLAN. Then, PTK and GTK will be generated via PMK and 4-way handshake[IEEE-802.11i]. PTK/GTK is used to secure STA's unicast/ (broadcast/multicast) traffic between STA and ecryption/decryption node, which could be WTP or AC. Unfortunately, in exiting authentication procedure, authenticator is the only node which can obtain the derived PMK,except of STA and AS. In addition, authenticator is not always deployed collocated on ecryption/decryption node. That is to say, WTP/AC cannot implement STA's traffic encryption/decryption because of lacking the PMK information. In this case, mechanism is needed to inform the PMK to ecryption/decryption node, WTP or AC in WLAN. In practice, this case is likely to happen in WLAN. Sometimes, AC in the existing network, kind of enterprise device, isn't the high intelligent devices to aggregate all the WLAN critical intelligent function in one. For operator, it is costly in large-scale ungraded deployment. As result, authentication is always deployed on GW node instead of AC. Fortunately, the GW node is the potential node for authentication in real network for other subscriber such as PPP, etc. It is good at Authenticator function. This enables a better environment that diminishes the software and hardware upgrade risks . Based on the above analysis, because of lack the initial fresh symmetric key for encryption/decryption, it is challenge for WTP/AC to control the 802.11 channel with STA, as shown in figure 4. The problem must be resolved. Xue Expires August 22, 2013 [Page 9] Internet-Draft key management via radius February 2013 Authenticator Supplicant Authenticator Server +-------+ +----+ +----+ +-------+ +-------+ | | | | | | | | | | | STA | | WTP| | AC | | GW | | AAA | | | | | | | | | | | +-------+ +----+ +----+ +---+---+ +-------+ | | | | |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 4 Authentication procedure when GW deployed as Authenticator 5. Protocol overview Based on the analysis above, it is recommended that control messages used for PMK transported from GW to WTP/AC in order to support encryption requirement between STA and WTP/AC when GW is the Authenticator. If AC is the encryption/decryption node, the GW can send the PMK to AC via these control messages. If WTP is the encryption/decryption node, the GW can use send the PMK to AC as well, then AC sends the obtained PMK to AP via protocol defined in [RFC4564]. The control messages between GW and AC is defined in this version. The purpose of this section is to provide control procedure and packet definition for key management in centralized architecture. Moreover, the control messages must fix the issues without creating incompatibilities with deployed implementation. As we know, RADIUS attributes are comprised of variable length Type- Xue Expires August 22, 2013 [Page 10] Internet-Draft key management via radius February 2013 Length-Vaule 3 tuples. New attribute values can be added without disturbing existing implementation of the protocol. RADIUS packet is one option.This document describes the RADIUS attributes supporting the key transmit between GW (Authenticator) and WTP/AC. Specially, RADIUS commands (Key-of-Announcement, KoA-ACK/NAK) are defined in order to enable PMK to be send from Authenticator (GW) to AC. These extended commends trigged by the RADIUS Accept message during authentication procedure.New RADIUS attributes for PMK announcement are described. The PMK announcement packets contain PMK derived by AS during the authentication procedure. Typically, this is used to achieve PMK announcement from GW to AC. Based on the exchanged keying material, the traffic security and integration requirement between STA and WTP/AC can be fixed. The PMK Announcement packets are defined as below. 5.1. PMK Announcement Messages Authenticator +---------+ +---------+ | | | | | | | | | WTP/AC | | GW | | | | | +---------+ +---------+ | | | KoA Message | |<--------------------------------------| | | | | | | | KoA ACK/NAK Message | |-------------------------------------> | | | | | | | | | Figure 5 PMK Announcement Messages During the authentication procedure, when GW obtains the PMK key via RADIUS Accept Message from AS, the GW initiates the KoA message and send to AC. The AC responds the KoA message with KoA-ACK if the AC is able to successfully get the PMK for the subscriber, or KoA-NAK if the PMK announcement fail. Xue Expires August 22, 2013 [Page 11] Internet-Draft key management via radius February 2013 The packet format is the general RADIUS. Fortunately, Change-of- Authorization Messages (CoA) have defined in [RFC3576], which is have similar mechanisms. The PMK messages is similar as, [RFC3576] , which is shown as follows The packet format 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 6 PMK Announcement Message Format Code The Code field is one octet, and identifies the type of RADIUS packet. RADIUS codes for this document are assigned as follows. Packets with an invalid Code field must be silently discarded. o 100 - Key-of-Announcement o 101 - KoA-ACK o 102 - KoA-NAK (optional) Identifier The Identifier 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 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 [RFC3576]. The following attributes should be included in PMK Announcement messages. Xue Expires August 22, 2013 [Page 12] Internet-Draft key management via radius February 2013 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. 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 GW to transport PMK to AC. The Keying-material attribute may be included within KoA-ACK/NAK messages. The format is 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 7 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. Xue Expires August 22, 2013 [Page 13] Internet-Draft key management via radius February 2013 o KoA-Feedback, shown as follows. It is responsible to provide the feedback when AC receives the KoA command from GW. The KoA- Feedback attribute may include within KoA-ACK/NAK messages. The format is 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 KoA-Feedback Atrribute 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 here defined in [RFC2865]. Length 4 Value The Value field is 2 octets, containing the feedback from the AC when received the KoA message.In this version, only two value is defined. o 0 Succeed o 1 Reject, can be used as KoA-NAK . 6. Authentication Procedure Based on the control message definition, the recommended procedure is shown as follows if the AC is the encryption/decryption node. Xue Expires August 22, 2013 [Page 14] Internet-Draft key management via radius February 2013 Please view in a fixed-width font such as Courier. Authenticator Supplicant Authenticator Server +-------+ +----+ +-------+ +-------+ | | | | | | | | | MH | | AC | | GW | | 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 9 Authentication Procedure 1 Mutual authentication procedure as general defined in [RFC3748][IEEE-802.1X]. 2 After EAP authentication completes, the GW works as Authenticator initiates and transmits the KoA packet to AC. It is desirable to provide keying information needed based on [IEEE-802.11i].To accomplish this, the KoA message contains the attributes to provide the PMK to AC. 3 AC should interpret the receipt of the Keying-material attribute Xue Expires August 22, 2013 [Page 15] Internet-Draft key management via radius February 2013 within the KoA message as an indication that the server has successfully authenticated the STA. Additionally, the derived PMK during authentication can be used with 4-Way Handshake to derive, bind, and verify PTK or GTK. The 4-way handshake procedure is defined in IEEE, which is out of the scope. 7. IANA Considerations TBD 8. Security Considerations Right now, the AS is only trusted to transport PMK to the Authenticator which was established with the supplicant. So if the Authenticator need to announce the PMK to the third parities, except the supplicant, the security must be guaranteed between the GW and the AC for key announcement. It can be achieved by IPsec tunnel or MD5 encryption/decryption algorithm. 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. [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. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Xue Expires August 22, 2013 [Page 16] Internet-Draft key management via radius February 2013 Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. [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. [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, 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. [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. Author's Address 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 Xue Expires August 22, 2013 [Page 17]