Internet Draft Madjid Nakhjiri draft-nakhjiri-pmip-key-01.txt Narayanan Venkitaraman Category: Internet draft Motorola Labs Expires: June 2006 January 2006 EAP based Proxy Mobile IP key bootstrapping for WiMAX 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 in June 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document intends to provide a first pass example of how the EAP keying framework may be used for bootstrapping keys between two agents performing a network service such as Proxy Mobile IP function. Care is taken so that the solution is aligned as closely as possible to the guidelines provided by the EAP Keying framework [EAPKEY]. Nakhjiri et. al. Expires - June 2006 [Page 1] Conventions used in this document 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 RFC-2119. Table of Contents 1. Introduction...................................................2 2. Terminology and Assumptions....................................3 3. Overview.......................................................4 4. Security considerations........................................8 5. References.....................................................8 6. Appendix A Use of PMIP-AMSK as PMN-AAA key.....................9 Acknowledgments..................................................10 Author's Addresses...............................................10 1. Introduction Mobile IP [X] specifies a protocol for a node to receive packets destined to its home IP address even when the node is not present in its home network. It specifies registration request (RRQ) and response (RRP) messages between the mobile node and a Home Agent. The HA then receives packets on behalf of the mobile node and tunnels the packets to the present location of the mobile node. The RRQ and RRP messages must be authenticated using key shared by the mobile node and its home agent. In some cases, such as cases where nodes connecting to the network do not have a Mobile IP stack but require mobility services, the network may have to rely on a proxy (called the Proxy Mobile Node, PMN) to generate the registration requests and process the registration responses on behalf of the node. To ensure Mobile IP compatible behavior, the control packets from the PMN must be sent via the current subnet of the mobile node. So the MIP control packets generated by the PMN are tunneled via an assistant function that resides in the current subnet of the mobile node (located say in a foreign agent or an access point). Thus the PMN (and the PMN-HA key) can reside in a single/secure location even as the mobile nodes moves from one subnet to another This document describes a scheme by which a proxy mobile node can obtain the keys to generate registration requests and validate the response from the Home agent. Nakhjiri et. al. Expires - June 2006 [Page 2] 2. Terminology and Assumptions Mobile Node (MN) (peer) The entity that includes EAP peer functionality as described by [EAP3748] and keying frameworks [EAPKEY], with the exception that mobile node may not have a direct link to the EAP pass-through authenticator. In this document we may use the terms MN and EAP peer interchangeably. MN is the entity whose records are kept at the AAA server and is authorized for various network services. Proxy Mobile Node (PMN): An entity in that generates RRQs on behalf of a mobile node and processes the RRPs. PMN is also the entity that is final key holder for the PMIP Key. Proxy MIP key (PMIP key): A key that is shared between the Proxy Mobile Node (PMN) and the home agent and is used to generate the Mobile-Home-Authentication extension to be included in Mobile IP registration requests (RRQ) and/or responses (RRP). MN-AAA key The MN-AAA key is the basis for the creation of all the keys that are created dynamically between MN and its mobility agents. MN-AAA key is used for calculation of the authenticator field inside an MN-AAA-Authentication extension [RFC3012bis04] included in a Mobile IP registration request for the home agent and verified by the home AAA server. The details of Mobile IPv4 key bootstrapping are covered in [RFC3957] and [RADIUS-MIP]. Note that this key is different from a possible PMN-AAA key, that may be established between PMN and the AAA server (if needed). Home agent (HA) A Mobile IP Home Agent that is responsible for generating and keeping a binding between mobile node home address and its care of address. EAP server EAP server is the entity that engages in EAP method exchange and terminates the EAP authentication method with peer as defined in [EAP3748]. EAP server is capable of generating and exporting relevant EAP keys as defined in [EAP-KEY]. Nakhjiri et. al. Expires - June 2006 [Page 3] Home AAA server HAAA server is the entity that is the main point of trust and authorization (AAA) in the administrative domain, and maintains peer information and possibly keying information. The AAA server relies on EAP server for execution of EAP-method authentications. EAP pass-through Authenticator The pass-through authenticator is the entity between a peer and a backend EAP server that is passing through EAP Request and Response messages ([RFC3748]) without understanding their data content. It can understand EAP success and failure messages. The authenticator may not necessarily be the terminating point for the physical access link to the peer. AAA client The first AAA entity (from mobile node side), that engages in AAA protocol conversation with the AAA infrastructure leading to the home AAA server. This entity is also responsible for encapsulating EAP messaging inside AAA protocol messages (RADIUS, [RFC3579] or Diameter). The logical AAA client is not responsible for understanding EAP messaging, however, it is the physical entity that receives any transported master keys produced as part EAP keying process, if the transport is performed through AAA protocols. According to current EAP keying documentation AAA layer entities are to delete the transported keys and this may mean a logical AAA client will not have an authority to act as a key holder. Key holder This entity is the one that holds the master key received from AAA server and possibly performs further key derivations and distribution functions for access nodes. In WiMAX architecture, the authenticator function is split between a key holder that receives the master keys from the AAA server and key receiver that also performs EAP relay function. In this document we assume the key holder is part of authenticator that receives the PMIP-key (also the AAA client) and use authenticator and key holder definitions interchangeably. 3. Overview The objective for a PMIP keying solution is to establish a shared key between the PMN and HA so that they are able exchange authenticated MIP registration messages. Nakhjiri et. al. Expires - June 2006 [Page 4] Our basic idea is to enable the AAA server derive a PMIP key and transport the key to the PMN in conjunction with the EAP access network authentication. So that the PMN can generate authenticated Mobile IP registration requests (RRQ) towards the HA by using the PMIP key as message authentication key. When a HA receives its first registration request corresponding to a mobile node from the PMN, the HA can obtain the corresponding key from the AAA. Note that this requires the AAA server to cache the PMIP key or related keying material and later retrieve the key for delivery to HA upon request. The following diagram provides a summary of the entities in the system, the flow of PMIP keying material to the PMN and the Home Agent and the data path from the Home agent to the MN via a optional foreign Agent. EAP/AAA Authenticator< =====================> AAA/EAP PMN <-----------AAA client ^^ <-----------------------Server PMIP-key || AAA (PMIP-key) | || | ||EAP | || | || | VV V MN<-+--+-+-+-++-+-+-+-+-Home Agent ==== EAP signaling ---- PMIP Key Path -+-+- Data Path Figure 1: Interactions between various entities in PMIP keying The operation is as follows (shown in Figure 2) . During network entry the mobile node (MN) performs an EAP authentication with the EAP server collocated with home AAA server via the pass-through authenticator. . After successful EAP authentication, the home AAA server after examining the MN service policies and/or possibly receiving specific requests (through initial AAA requests) for Proxy Mobile IP service, authorizes the MN for Proxy Mobile IP service. Upon this authorization, the AAA server (acting as AAA layer in EAP framework) requests a specific AMSK for proxy Mobile IP application from the EAP layer. The EAP layer at AAA server based on the request from the AAA layer calculates the PMIP-AMSK from the EMSK as follows: Nakhjiri et. al. Expires - June 2006 [Page 5] PMIP AMSK = PRF (EMSK, MN_ID |Authenticator_ID| "PMIP Application Key"| Key length) . Note that Home Agent ID is not used in the key binding to allow flexibility towards alternative dynamic home agent assignments. Peer aPMN Authenticator HA EAP/ AAA ---- --- ------------- --- ---------- | | | EAP authentication | |< --------------------------------------------- >| | | | PMIP-key transport | | | PMIP-key |< ----------------------| | |< --------------| | | | | RRQ+Auth | | | | |-------------------------- >| Req for key| | | | |---------- >| | | | | Key tx | | | | RRP+Auth |< ----------| | | < -------------------------| | | | | | | Figure 2: PMIP key bootstrapping using EAP and AAA mechanisms. . The AAA server has now access to the PMIP-AMSK and can either use the PMIP-AMSK to generate the PMIP-key (PMN-HA key) or send the PMIP-AMSK to the authenticator/ AAA client to do so instead. The latter alternative however may cause problems if the EAP Keying framework [EAPKEY] requires the AAA entities to delete all transported keys (including AMSKs) after transport, as the AAA server later needs to supply this to HA later upon request. Therefore, we recommend the AAA server to calculate the PMIP-key from the PMIP-AMSK locally as one of the following alternatives: PMIP-key=Truncate(PMIP-AMSK, required PMIP-key length) PMIP-key=PRF(PMIP-AMSK, other information) . When the AAA server calculates the PMIP-key from the PMIP AMSK, the PMIP-key is then sent securely to the AAA client using appropriate AAA protocol mechanisms (RADIUS attributes or Diameter AVP) following or around the same time as when an EAP success is being sent to the EAP peer through the EAP pass-through authenticator. Typically the pass-through authenticator is collocated with the AAA Nakhjiri et. al. Expires - June 2006 [Page 6] client, so the EAP success and the PMIP-Key may be sent through the same AAA message, assuming proper and secure key wrapping mechanisms are provided for that message. At any rate the AAA client function will pass the PMIP-key to the authenticator for storage. . In WiMAX operation it is expected that the AAA server may also needs to also provide proper authorization information for the 802.16e access link, mobile node network operation (e.g. an assigned Home Address information, HoA and other entities, such the Proxy Mobile Node for performing Proxy Mobile IP service, including necessary authorizations for the PMN (e.g. IP address for a Home Agent, HA, if available), as well as other necessary information such as key lifetimes, and possible SPI information. This information is sent through the AAA protocol to the AAA client function to the final destination. The life time for PMIP-key and related PMIP authorization must never exceed the life time of the EAP session. . The authenticator co-located with the AAA client will access the PMIP-Key and other related information and passes the key to the Proxy Mobile Node (PMN) function. It is possible for the PMN and the authenticator to be physically collocated to avoid compromise of the PMIP key due to additional transfers. It is possible that the PMN function is in another entity physically separate (such as inside a base station or foreign agent) from the authenticator, in which case, care must be taken in transferring the PMIP-key to the PMN. . When the PMN generates a registration request (RRQ) it uses the PMIP key to create the Mobile-Home Authentication Extension (MHAE) to authenticate the registration request to the HA. . When a HA receives a registration request, if it does not have the SPI/keys corresponding to the security association with the PMN, it queries the AAA server via an AAA Request message. . The AAA server validates the request and sends the PMIP key (PMN-HA key) corresponding to the requesting HA in a AAA Response message. . After receiving the PMIP key, the HA validates the MHAE in RRQ, and processes the RRQ and generates a registration response with a valid authentication extension using the same PMN-HA key. Nakhjiri et. al. Expires - June 2006 [Page 7] Note: An alternative method for generation of PMIP-key has been suggested as follows: Instead of generating the PMIP-key from PMIP-AMSK directly, it has been suggested to use the PMIP-AMSK to derive a so called PMN-AAA key that can be used to bootstrap the PMIP-key through direct interactions between the PMN (rather than the mobile node) and AAA server at a later time using [RFC3957]. We will cover a short description of this method in an appendix. 4. Security considerations The PMN may be co-located with the authenticator itself or may reside separately. In any case the PMIP or PMIP-AAA key must be securely provided from the authenticator function to the PMN function. The protocol between the PMN and the authenticator is beyond the scope of this document. It should be noted that, peer mobility may result in need of handover between the physical entities the PMN is associated with. In such cases, to avoid the security issues with compromise of PMIP-key and to avoid the need for new interactions with the backend server, the initial PMN, so called PMN anchor will hold on to the PMIP-key and will perform any needed PMIP security functions in interacting with other Mobile IP entities. 5.References [MIPv4] C. Perkins, IP Mobility Support, IETF, RFC 3344, August 2002. [3012bis04] C. Perkins, P. Calhoun, Mobile IP Challenge/Response Extensions, draft-ietf-mip4-rfc3012bis-04.txt., June 2005. [RFC3957] C. Perkins, P. Calhoun, AAA Registration Keys for Mobile IP, IETF, RFC 3957, March 2005. [KEYWRAP], G. Zorn, Et. Al., RADIUS Attributes for Key Delivery, draft-zorn-radius-keywrap-08.txt. [EAPKEY] B. Aboba, Et. Al., Extensible Authentication Protocol (EAP) Key Management Framework, Internet Draft, IETF, draft-ietf-eap- keying-08 (work in progress), October 2005. [EAP3748], B. Aboba, Et. Al., Extensible Authentication Protocol (EAP)’’, RFC 3748, IETF, June 2004. Nakhjiri et. al. Expires - June 2006 [Page 8] [RADIUS-MIP], M. Nakhjiri, Et. Al., RADIUS Mobile IP extensions, Internet Draft, IETF, draft-nakhjiri-radius-mip4-02.txt, October 2005. [RADEAP3579], B. Aboba, P. Calhoun, RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP), RFC 3579, IETF, September 2003. 6. Appendix A Use of PMIP-AMSK as PMN-AAA key This section describes an second alternative to bootstrapping the Proxy Mobile IP keys using the PMIP-AMSK derived from EAP authentication as PMN-AAA key. According to this proposal the PMN-AAA key is used instead of the MN-AAA key in the process defined in [RFC3957] and [RADIUS-MIP] to bootstrap PMN-HA key through the AAA server. In this method: . The AAA server after receiving the PMIP-AMSK from the EAP layer (following EAP authentication) calculates a PMN-AAA key from the PMIP-AMSK through a straightforward method (PMN-AAA key=PRF( PMIP- AMSK, other PMIP info)) and sends a copy of PMN-AAA and sends another copy to the authenticator through the AAA client. . The authenticator passes the PMN-AAA key to the PMN for further PMIP key bootstrapping with the AAA server. . When the PMN needs to send a registration request to the HA, since the PMN does not have access to the PMN-HA key, it indicates the need for PMN-HA key by including an MN-AAA Authentication extension in the RRQ submitted to HA, where the PMN-AAA key is used for calculation of the authenticator field within the extension. When the HA receives an RRQ with MN-AAA AE, it needs to refer to the AAA server for retrieval of a PMN-HA key. It should be noted that this method would require the AAA server to have access to a copy (generate and/or store) of the PMN-AAA key for verification of MN- AAA Authentication extension, when the AAA server receives the RRQ submitted by the HA later on. . Upon verification of the MN-AAA AE and access to MN profile, the AAA calculates a PMIP-nonce (PMN-HA nonce) and a corresponding PMIP-key (PMN-HA key), using the PMN-AAA key and procedures defined in [RFC3957], and sends the nonce to the PMN in the clear and the encrypted PMIP-key to the HA. The authors believe that due to the transitive security associations provided between the AAA server and PMN (through AAA server-AAA client/ authenticator SA and authenticator-PMN SA), the nonce creation is unnecessarily complex. Furthermore, RFC3957 will still Nakhjiri et. al. Expires - June 2006 [Page 9] require the HA to query AAA server for retrieval of the PMIP key and furthermore, it requires distribution of nonces to the PMN even though the PMN may be a trusted by the authenticator. Acknowledgments Authors would like to acknowledge Anand Bedekar and Avi Lior for the discussions leading to creation of this draft. Author's Addresses Madjid Nakhjiri Motorola Labs Contact Email: Madjid.Nakhjiri@motorola.com Narayanan Venkitaraman Motorola Labs Contact Email : Narayanan.Venkitaraman@motorola.com 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 Nakhjiri et. al. Expires- June 2006 [Page 10] 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 (2005). 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. This Internet-Draft will expire on June, 2006. Nakhjiri et. al. Expires - - June 2006 [Page 11]