Network Working Group A. Lior Internet-Draft Bridgewater Systems Expires: August 29, 2006 K. Chowdhury Starent Networks February 25, 2006 Mobile IP Key Derivation using EAP draft-lior-mipkeys-eap-00 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 on August 29, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides information on the derivation of Mobility Registration Keys from EAP. Lior & Chowdhury Expires August 29, 2006 [Page 1] Internet-Draft Mobile IP and EAP February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Functional Entities . . . . . . . . . . . . . . . . . . . 5 2.2. Network Access Authentication . . . . . . . . . . . . . . 7 2.3. MIPv4 Mobility Registration . . . . . . . . . . . . . . . 8 2.4. MIPv6 Mobility Registration . . . . . . . . . . . . . . . 10 3. Key Hierarchy and Derivation . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative references . . . . . . . . . . . . . . . . . . . 12 7.2. Informative references . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Lior & Chowdhury Expires August 29, 2006 [Page 2] Internet-Draft Mobile IP and EAP February 2006 1. Introduction Wireless Networks typically require that the mobile subscriber be authenticated before gaining access to the network. Sometimes this authentication involves both user and device authentication. The device authentication is required to ensure that the device the user is using is compatible with the network and as a side benefit is used to track stolen devices. User authentication is performed to authenticate the user to the subscriber account held by the home network. This is the account that will be billed for the services rendered. EAP based authentication [RFC3579] using AAA (RADIUS [RFC2865] or Diameter [RFC3588]) is becoming the preferred method for handling device and/or user authentication. After access to the network is granted to the user and his device, the user attempts to invoke services. Some wireless devices may connect to the network and are not mobile, on the other hand, some wireless devices connect to the network and are highly mobile. This document addresses device that are mobile and tend to roam from network to network. Mobile IP: MIPv4 [RFC3344] or MIPv6 [RFC3775] is used for these devices. By anchoring the IP address for the device, Mobile IP allows the devices to be mobile and maintain uninterrupted network access. Mobile IP procedures require that the device register itself with the Home Agent (HA). The registration process provides a means for the Mobile Node to authentication with each of the Mobility Agents and in Mobile IPv4, for the Mobility Agents to authenticate with each other. The authentication requires the establishment of security association represented by registration keys. The MN-HA key authenticates the Mobile Node with the HA, the MN-FA (Mobile IPv4) authenticates the MN to the FA and the FA-HA (Mobile IPv4) authenticates the FA to the HA. Depending on the situation some of these keys are not required and some are mandatory. There are different ways in which the mobile node and the mobility agents obtain the keys used during the mobile ip procedures. The simplest method is that the keys are pre-provisioned in the mobile and at the agents. This method is very efficient if the roaming domain of the mobile node is kept small. In reality users roam globally and therefore pre-provisioning of mobility keys is not realistic. For MIPv4 provisioning of mobility keys is provided by [RFC3957]. Lior & Chowdhury Expires August 29, 2006 [Page 3] Internet-Draft Mobile IP and EAP February 2006 The procedures of RFC 3957 assume that the mobile node has a security association with a AAA server. Using this security association, known as MN-AAA key, [RFC3957] prescribes how fresh mobility registration keys between the MN and FA and/or between the MN HA can be derived. Derivation of the FA-HA key is possible by having the FA obtain the FA-HA key from the AAA infrastructure by having the FA initiate a AAA transaction when it receives a Mobile IP registration request from the Mobile. The realization of [RFC3957] and AAA is covered by [RFC4004]for Diameter and [I-D.nakhjiri-radius-mip4] for RADIUS. MIPv6 provides two mechanism for establishing a security association between the mobile node and the HA. One method is to user IPSec to protect the Binding Update (BU) between the Mobile and the HA. See [RFC3776]. The other method, protects the BU and the Binding Acknowledgement (BA) using the same strategy as is available for MIPv4. See [RFC4285]. Both of these methods require AAA interactions. For a discussion on the justification for use of [RFC4285] see [I-D.ietf-mip6-whyauthdataoption] 1.1. Problem Statement As shown in the above, Mobile IP key derivation is highly desirable for wireless mobile ip. This key derivation comes at a price of extra AAA interactions which has the effect of delaying the length of time it takes the mobile node to connect to the network. As well, EAP method provide a mechanism to hide the true identity of the mobile node, from all the nodes except the Mobile Node and the Home AAA. The MIP procedures typically require the use of an NAI extension with no provisions for hiding the identity of the user. This document shows how to use the EAP based authentication used for Network Access to derive the Mobility Registration keys and also how to hide the identity of the user during Mobile IP registration. The result allows the mobile to connect and to register for mobility service using two AAA transactions. One transaction for the Network Access and one transaction between the HA and the HAAA. 1.2. Terminology The document uses the RADIUS terms found in: [RFC2865], [RFC2869]; Diameter terms found in: [RFC3588], [RFC4072], [RFC4005]; and EAP terms found in [RFC3579]. The term "attributes" refers to RADIUS attributes and "Attribute Value Pair" or "AVP" refers to Diameter attributes. Lior & Chowdhury Expires August 29, 2006 [Page 4] Internet-Draft Mobile IP and EAP February 2006 The term "NAS" refers to the AAA client which are assumed to be logically co-located with the FA. To ease in dealing with two AAA protocols each using similar names, the document adopts the following terms: AAA client: represents either RADIUS client or Diameter client. AAA server: represents either RADIUS server or Diameter server. AAA proxy: represents either RADIUS proxy or Diameter proxy. AAA-Request: represents either RADIUS Access-Request packet or Diameter-EAP-Request (DER). AAA-Accept: represents either RADIUS Access-Accept packet or Diameter-EAP-Answer(DEA) with Result-Code=Diameter_SUCCESS. AAA-Challange: represents either RADIUS Access-Challenge or a Diameter-EAP-Answer(DEA) with Result- Code=DIAMETER_MULTI_ROUND_AUTH. AAA-Reject: represents either RADIUS Access-Reject packet or Diameter-EAP-Answer(DEA) with Result-Code=Diameter_FAIL. The above terms are used to represent either Diameter or RADIUS operations. Terms specific to RADIUS and Diameter will be used when we need to address specific RADIUS and Diameter When specific reference to Diameter operations. 1.3. Requirements Language In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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]. 2. Operations 2.1. Functional Entities Figure 1. illustrates the functional entities used in the proceeding discussion. Lior & Chowdhury Expires August 29, 2006 [Page 5] Internet-Draft Mobile IP and EAP February 2006 +--------------+ +---------------------+ +------------------+ | +----------+ | | +-----------+ | | +------------+ | | | EAP PEER |<--------->+ EAP AUTH/ +<-+ | | | EAP Server +<+ | | +----+-----+ | | +-----------+ | | | +-----+------+ | | | V | | | | | V | | | +----+-----+ | | +-----------+ | | | +-----+------+ | | | | KH/KG | | | +-+ KH/KG | | | | | KH/KG | | | | +----+-----+ | | | +-----+-----+ | | | +-----+------+ | | | | | | | ^ | | | | | | | | | | | | +----+ | | | | | | | | | | | V | | V | | | | | | | +-----+---+-+ | | +-----+------+ | | | | | | | | AAA Client|<====+======+>| AAA Server +<+ | | | | | | +-----------+ | AAA | +-----+------+ | | | | | | | | | Home Net | | | | | +-------+ | +-------|----------+ | V | | V | | | +----+-----+ | | +-----+-----+ | +----+------+ | | MIPC |<=========>| FA |<====+=======>| HA | | +----------+ | MIP | +-----------+ | MIP +-----------+ | | | | | Mobile Node | | NAS | +--------------+ +---------------------+ Figure 1: Functional Entities The EAP method executes between the EAP PEER and the EAP Authentication Server in the Home Network. The EAP method is transported between the AAA client in the NAS and the AAA Server in the Home Network. The Mobile Node, NAS and Home Netwrok each have a KeyHolder/ KeyGenerators (KH/KG). The KH/KG at the Home Network and the Mobile Node receive the MIP Application Key derived from the EMSK for the session from the EAP Peer and the EAP Server. The KH/KG at the NAS receives the mobility registration keys needed by the FA which are derived from the MIP Application Key. These are transported over AAA in a secure fashion. The MIP Client (MIPC) at the Mobile node gets the mobility registration keys from the KH/KG in the mobile node. The FA gets the keys it needs from the KH/KG located at the NAS. The HA gets the mobility registration keys it needs from the KH/KG via AAA interaction. Note, the AAA does not cache any keys. The keys are cached by the Lior & Chowdhury Expires August 29, 2006 [Page 6] Internet-Draft Mobile IP and EAP February 2006 KH/KG as long as the session for which they were created is active. When the session terminates or when the session reauthenticates the keys are securely erased and replaced by new fresh keys. 2.2. Network Access Authentication During Network Access authentication and authorization procedure the Mobile Node is authenticated by the HAAA using EAP based authentication. The EAP method selected depends on the credentials that are used and must generated an MSK and EMSK. The call flow for Network Access Authentication is shown in figure 2. EAP PEER EAP-AUTH EAP=AUTH Server MN NAS AAA Server | EAP RQ Identity | | |<-----------------| | | | | | EAP RP Identity | | | PseudoIdentity@ | | | realm | Access-Request | |----------------->|-------------------------->| | | Access-Challenge | |<-----------------|<--------------------------| | | Access-Request | |----------------->|-------------------------->| o o o o o o o o o o o o o o o o | | Access-Accept EAP Success| | | [MSK], [MN-FA], [FA-HA] | | EAP Success |<--------------------------| |<-----------------| Figure 2: Network Access Authentication If identity hiding is required then an EAP method that provides identity hiding is used. In this case in order to provide for identity hiding during the Mobility Registration procedures, the Mobile node generates a temporary identity, or a pseudo identity that is used as the outer identity during Network Access Authentication and Authorization. The outer idenity is used as the User-Name attribute or AVP in AAA. The User-Name is used to route the AAA message to the home network. All intermediate nodes (AAA proxies and brokers) will be able to see the pseudoIdentity generated by the Mobile Node and will not abe able to decode the inner identity. Only the Home AAA will be able to decode the inner identity and thus the HAAA associates the pseudo identity with the true identity of the Lior & Chowdhury Expires August 29, 2006 [Page 7] Internet-Draft Mobile IP and EAP February 2006 user. This association will be used during mobile ip registration procedure. Before the responding with an AAA Access-Accept the EAP Authentication Server is requested to generate an Application Master Session Key (AMSK) for the mobility application. The Mobility Application Master Session Key (MIP-AMSK) is generated from the EMSK and is sent to a Key-Holder/Key-Generator. When the AAA replies with the Access-Accept message contain EAP- Success, it requests that the Key Holder/Key Generator generate an MN-FA key and an FA-HA key. These keys are then sent to the NAS in the Access Accept message. The AAA must ensure that the keys are encrypted. The Key Holder/Key Generator in the Home Network maintains these generated keys indexed by the true identity of the user. When the keys arrive at the NAS, the NAS places the keys in the Key Holder/Key Generator indexed by the pseudoIdentity of the user. Thus the keys will be retrievable during mobile ip operations. A similar process occurs in the Mobile Node. During the Network Access Authentication and Authorization procedure the EAP Peer generated the MSK and EMSK. The EAP Peer is requested to derive the MIP-AMSK from the EMSK. The MIP-AMSK is stored in the KeyHolder/ KeyGenerator located in the Mobile Node. When the session terminates the Key Holder/Key Generator will securely erase the keys associated with the session. Similarly when the session re-authenticates the old keys held by the Key Holder/Key Generators will be securely replaced by the new keys. 2.3. MIPv4 Mobility Registration During the MIPv4 Mobility Registration procedure the Mobile Node generates an Mobile IP Registration Request RRQ. See figure 3. The RRQ contains the NAI extension which is set to the pseudo-Identity@realm generated by the mobile node during the Network Access Authentication Procedures. The Mobile node requests that the Key Holder/Key Generator generate the MN-FA and MN-HA keys. The MN-HA is used to create the MN-HA Authentication Extension (AE) and the MN-FA key is used to create the MN-FA AE that are included in the RRQ. Lior & Chowdhury Expires August 29, 2006 [Page 8] Internet-Draft Mobile IP and EAP February 2006 MOBILE NODE NAS HOME NETWORK MIPC KH/KG FA KH/KG HA HAAA KH/KG | | | | | | get() | | | | |------>| | | | |MNHA/ | | | | |MNFA | | | | |<------| | | | | | | | |RRQ MN-FA AE | | | | MN-HA AE | | | | NAI Extension| | | |---------------->| get() | | | | |------>| | | | |MN-FA | | | | |FA-HA | | | | |<------| | | | | RRQ + FA-HA AE | | | |------------------->| | | | | | | | |AAA Access-Request | | | User-Name= NAI Extension | | |---------->| | | | | get() | | | | |-------->| | | | |MN-HA | | | | |FA-HA | | | | |<--------| | | | AAA Access Accept | | | MN-HA FA-HA | | |<----------| | | RRP | | | RRP |<-------------------| |<----------------| Figure 3: MIPv4 Call-flow When the FA receives the RRQ it asks the Key Holder/Key Generator to fetch the MN-FA key and the FA-HA key using the pseudo-identity contained the NAI extenion in the RRQ. The FA uses the MN-FA key to validate the MN-FA AE and uses the FA-HA key to generate the FA-HA AE. The FA forwards the RRQ to the HA. If the HA does not have a mobility association for the pseudoIdentity contained in the Mobile IP Registration Request, it constructs a AAA request, to fetch the MN-HA key and the FA-HA key. The AAA request must contain the Lior & Chowdhury Expires August 29, 2006 [Page 9] Internet-Draft Mobile IP and EAP February 2006 pseudoIdentity@realm as received in the Mobile IP Registration Request. The AAA server receives the request and uses the pseudoIdentity to lookup the true identity of the user. If the lookup fails then this means that the user was never authenticated or that the user has been disconnected. In this case the HAAA responds with an Access-Reject message. If the lookup succeeds the AAA server asks the KeyHolder/ KeyGenerator for the MN-HA key and FA-HA key. The keys are sent back to the HA. The HA uses these keys to validate the MN-HA AE and the FA-HA AE. If the HA receives an Access-Reject from the HAAA, it silently discards the RRQ. If the HA recieves an Access-Accept from the HAAA, the HA uses the MN-HA and FA-HA to validate the MN-HA AE and the FA-HA AE. If the extensions validate the HA responds back with an RRP indicating success. Note that during mobility procedure there are other attributes that are passed between the mobility agents and also between the HA and the HAAA. These attributes are used for further processing or authorization of the mobile IP session. The attributes are discussed in other RFCs. 2.4. MIPv6 Mobility Registration TBD TBD Figure 4: MIPv6 Call flow 3. Key Hierarchy and Derivation As described above, the mobility keys are derived from the EAP method used during Network Access Authentication. The EAP method uses a RootKey that is provisioned in the Mobile Node and is also known in the home network. The RootKey could also be a Certificate. The following diagram shows the key hierarchy. Lior & Chowdhury Expires August 29, 2006 [Page 10] Internet-Draft Mobile IP and EAP February 2006 RootKey | ------------+--------------- EAP Layer | | +-----+------+ | EAP-METHOD | +--+------+--+ | | EMSK MSK | | ---------+-------+---------- | | MIP-AMSK +-------> | +----MN-HA | +----MN-FA | +----FA-HA Figure 5: Key Hierarchy The keys are stored in Key Holder/Key Generation entities at the Mobile Node, and the Home Network and at the NAS. The keys are transported to the NAS using AAA Access-Accept packet as a result of successful authentication and authorization. During mobility procedures the required keys are available at the FA (assuming the FA is collocated with the NAS). The HA uses the AAA protocol to fetch its required keys. The derivation of the keys is given below: The MIP-AMSK is derived from the EMSK using the following formula: MIP-AMSK = HMAC-SHA1(EMSK,"MIP APPLICATION KEY") The mobility keys are derived from the MIP-AMSK using the following formulas: MN-HA = HMAC-SHA1(MIP-AMSK,"MN HA" | HA-IP) MN-FA = HMAC-SHA1(MIP-AMSK,"MN-FA" | FA-IP) FA-HA = HMAC-SHA1(MIP-AMSK,"FA-HA" | HA-IP | NONCE) Lior & Chowdhury Expires August 29, 2006 [Page 11] Internet-Draft Mobile IP and EAP February 2006 4. Security Considerations TBD 5. Conclusions The docuement showed how MIP Key derivation from EAP based Network Access Authentication can be achieved. The advantages can be summarized as follows: o Mobility keys are derived from fresh keys rather then a statically provisioned key (MN-AAA). o Mobility keys are bound to an authenticated session. o Mobility procedures are simplified. No need for [RFC3957]. o The procedures do not require any modification to Mobile IP protocols. AAA protocols may require new attributes. o The reduction of AAA transaction to two transactions, one for Network Access Authentication and one for the HA to obtain the Registration Keys. Finally, it was shown how to provide identity hidding to Mobile IP. 6. Acknowledgement The authors would like to thank ... 7. References 7.1. Normative references [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. [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. Lior & Chowdhury Expires August 29, 2006 [Page 12] Internet-Draft Mobile IP and EAP February 2006 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [RFC3957] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005. [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005. [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005. [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006. [I-D.ietf-mip6-whyauthdataoption] Patil, B. and G. Dommety, "Why Authentication Data suboption is needed for MIP6", draft-ietf-mip6-whyauthdataoption-00 (work in progress), September 2005. [I-D.nakhjiri-radius-mip4] Nakhjiri, M., "RADIUS Mobile IPv4 extensions", draft-nakhjiri-radius-mip4-02 (work in progress), October 2005. Lior & Chowdhury Expires August 29, 2006 [Page 13] Internet-Draft Mobile IP and EAP February 2006 7.2. Informative references Lior & Chowdhury Expires August 29, 2006 [Page 14] Internet-Draft Mobile IP and EAP February 2006 Authors' Addresses Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Ottawa, Ontario K2K 3J1 Canada Phone: +1 613-591-6655 Email: avi@bridgewatersystems.com Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 USA Phone: +1 214 550 1416 Email: kchowdhury@starentnetworks.com Lior & Chowdhury Expires August 29, 2006 [Page 15] Internet-Draft Mobile IP and EAP February 2006 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 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 (2006). 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. Lior & Chowdhury Expires August 29, 2006 [Page 16]