Internet Draft Madjid Nakhjiri draft-nakhjiri-pmip-key-00.txt Narayanan Venkitaraman Category: Internet draft Motorola Labs Expires: June 2006 January 2005 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 (2005). 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. Nakhjiri et. al. Expires - June 2006 [Page 1] Care is taken so that the solution is aligned as closely as possible to the guidelines provided by the EAP Keying framework [EAP-KEY]. 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....................................2 3. Overview.......................................................5 4. Security considerations........................................8 5. References.....................................................8 6. Appendix A Use of PMIP-AMSK as PMN-AAA key.....................8 Acknowledgments...................................................9 Author's Addresses................................................9 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 and response messages between the mobile node and a Home Agent. The HA then proxies for the mobile node and tunnels the packets to the present location of the mobile node. These messages must be authenticated using key shared by the mobile node and its home agent. In many cases a network may have to rely on a proxy (called the proxy mobile node) to generate the registration requests and process the registration responses. This is especially needed for nodes that do not have a mobile IP stack but require mobility services from the network. 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. 2. Terminology and Assumptions Mobile Node (MN) (peer) Nakhjiri et. al. Expires - June 2006 [Page 2] The entity that includes EAP peer functionality as described by [EAP3748] and keying frameworks [EAP-KEY], 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]. The handover keying architecture assumes the EAP server is a backend entity that provides an authentication service to a pass-through authenticator as defined in [EAP3748]. Home AAA server Nakhjiri et. al. Expires -June 2006 [Page 3] The entity that is in charge of overall access control which provides authentication, authorization and accounting services to network edge devices. This document considers the AAA server (not the EAP server) to be the main point of trust and authorization in any administrative domain, but the AAA server relies on EAP server for EAP-method authentications. Also, this document does not distinguish between the AAA server function and the storage databases that may hold information related to keying and AAA functions and refer to the server implementing AAA protocols and functions as well as storage as ‘‘AAA server’’. The implication is that, any compromise of the database at the AAA server is understood to possibly have security implications on the administrative domain. It is assumed that the Home AAA server (AAAH) and the EAP server are co-located within the same physical device and possibly interact through internal mechanisms. EAP pass-through Authenticator According to [EAP3748], authenticator is the end of the link initiating EAP authentication. In this document, to add specificity, we define the term authenticator to refer to the entity acting as a "pass-through" during EAP authentication between a peer and a backend EAP server. The pass-through authenticator does not understand the content of the data field within EAP Request and Response messages, but can match requests with responses and can understand EAP success and failure messages. The authenticator may not necessarily be the entity that terminates the link between the peer and the access network. 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. It is assumed that the EAP pass-through authenticator and the AAA client are collocated. 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 AMSK received from AAA server and possibly performs further key derivations and distribution functions for access nodes. It is yet to be determined from the EAP Nakhjiri et. al. Expires - June 2006 [Page 4] keying requirement specification in EAP WG whether either a AAA server or a AAA client can cache the keys after key transport. This may mean both central (next to AAA server) and local (next to AAA client) key holders may exist in the architecture. How the key holder receives the key (from which entity) is to be determined. In the EAP keying architecture, it is the pass-through authenticator that acts as a key holder (receiving the key through AAA protocol). In the Proxy Mobile IP application, it is the PMN that is the key holder for PMIP-key, while the authenticator can be considered as the entity that is the PMIP-AMSK holder. 3. Overview The objective is to establish a shared key between the PMN and HA so that they are able exchange authenticated MIP registration messages. The basic idea is to enable the AAA server derive a PMIP AMSK and transport the key to the PMN via the authenticator in conjunction with the EAP access network authentication. 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 AMSK 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 The operation is as follows . 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. Nakhjiri et. al. Expires - June 2006 [Page 5] . 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: 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. . The AAA server has now access to the PMIP-AMSK. There are two methods for use of PMIP-AMSK to arrive at PMIP-key (PMN-HA key). 1. The PMIP-Key can be created from the PMIP-AMSK through a straightforward derivation (PMIP-key=PMIP-AMSK or truncate(PMIP-AMSK) or PRF(PMIP-AMSK, other information)). The PMIP-Key can then be distributed to the PMN through the authenticator and to the HA upon request. In this document we endorse the first alternative due to its simplicity and closer match to the security needs of the environment for Proxy Mobile IP is being used for. So this alternative is explained in details shortly. 2. The PMIP-AMSK can be used to derive a so called PMN-AAA key to be sent to the PMN. The PMN-AAA could then be used for further interaction between the PMN and the AAA server to bootstrap the actual PMIP-key. We will cover a short description of this method in an appendix. . 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 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 Nakhjiri et. al. Expires- June 2006 [Page 6] 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 passes it to the Proxy Mobile Node (PMN). . The PMN function obtains the PMIP-key and related information from the authenticator function using implementation specific communication link between PMN and authenticator. Note that it is possible for the PMN and the authenticator to be physically collocated to avoid compromise of the PMIP AMSK due to additional transfers. . 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. RFC3957 will still 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. Nakhjiri et. al. Expires - June 2006 [Page 7] 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. 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. [EAPKEY8] 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. [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: Nakhjiri et. al. Expires - June 2006 [Page 8] . 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. Acknowledgments 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 Nakhjiri et. al. Expires - June 2006 [Page 9] 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 (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 10]