Mobile IP WG Franck Le INTERNET-DRAFT Stefano M. Faccin Date: 23 February 2001 Expires: 23 August 2001 Nokia Research Center Key distribution mechanisms for Mobile IPv6 Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract Mobile IP and many of its extensions such as Mobile IPv6 Regional Registration [1] or Hierarchical MIPv6 Mobility Management [2] require strong authentication between the mobile node and different agents (Home Agent, Gateway Mobility Agent [1], Mobility Anchor Point [2]) which are either located in the Home or Visited Domain. The mobile node may share a security association with its home AAA server for entity authentication to allow him to roam in different other domains. The idea described in this draft is that such security association can be used to create derivative security associations between the mobile node and other entities in the visited or home Le, Faccin [Page i] INTERNET-DRAFT Mobile IP 23 February 2001 domain. The keys thus established between the nodes can not only be used for authentication as required by Mobile IP and many of its extensions but additionally for confidentiality (e.g. over the access link between the mobile node and the access router) or other security services if required. This document specifies mechanisms and extensions to the Mobile IP to distribute security information to the mobile node. Le, Faccin [Page ii] INTERNET-DRAFT Mobile IP 23 February 2001 1. Introduction Mobile IP and many of its extensions such as Mobile IPv6 Regional Registration [1] or Hierarchical MIPv6 Mobility Management [2] require strong authentication between the mobile node and different agents (Home Agent, Gateway Mobility Agent [1], Mobility Anchor Point [2])which are either located in the Home or Visited Domain. The mobile node may share a security association with its home AAA server for entity authentication to allow him to roam in different other domains: the idea is that when the mobile node enters a new visited domain, the serving system may want to authenticate the user to make sure he is a valid one before giving him access to its network resources, and the security association between the mobile node and the home domain is used to support such authentication. The security association between the mobile node and the home domain security association can also be used to create derivative security associations between the mobile node and other entities in the visited or home domain (e.g. AAA in visited domain). The derivative security associations thus established between the nodes can not only be used for authentication as required by Mobile IP and many of its extensions but additionally used for confidentiality (e.g. over the access link between the mobile node and the access router) or other security services if required. This document specifies mechanisms and extensions to the Mobile IP to distribute security information to the mobile node. Two methods are described in this document to support key distribution. The first method described is based on random numbers and the second one is based on the Diffie Hellman mechanism. This document actually introduces the concept and future revisions will include more implementation details. 2. Definitions Perfect forward Secrecy: A protocol is said to have perfect forward secrecy if compromise of long-term keys does not compromise past session keys. Le, Faccin [Page 1] INTERNET-DRAFT Mobile IP 23 February 2001 3. Background and Motivation Different key distribution schemes have already been introduced such as the ones described in "AAA Keys for Mobile IP" [3], or "Registration keys for Route Optimization" [4]. All such proposal suggest to distribute the key to the mobile node over the access link by encrypting it either using a long term security association between the mobile node and the AAA-H or using Public keys. When considering radio links, sending the keys encrypted with a long term security association over the air interface causes a weak link in the security chain: the wireless link is weak since everyone can eavesdropp and the risk to have the long term key compromised is high. In fact, even if the keys are distributed by encrypting them, traditionally such key distribution mechanisms have been avoided in order to increase the system security. In addition, in such mechanism, once the long term key is compromised, the network can not distribute new keys to the MN. For that reason, security keys in cellular networks (e.g. GSM, UMTS, IS-41) are never distributed over the air. For the same reasons, in the present key distribution mechanisms used today such as Internet Key Exchange [5], keys are not distributed encrypted using a long term key: nonces, hash, Diffie Hellman values can be encrypted but the keys are not distributed, even encrypted. Moreover, mechanisms proposed in [3], [4] do not provide Perfect Forward Secrecy. As for the utilization of Public Keys as suggested in the current proposals, in addition to the high risk to have the Public Keys compromised by using them over the access link, and the lack of Perfect Forward Secrecy, in order for public keys solutions to be widely and efficiently deployed in commercial systems such as cellular networks, a well established PKI needs to exist. Moreover, many issues still need to be solved for the adoption of public keys in wireless networks: first of all, the limitated availability of the radio resources must be taken into account thus raising problems such as the procedure and the frequency for certificate revocation, and the certificate length itself. In addition, public keys based algorithms are also more time consuming, thus creating delay issues, and are more CPU demanding: low end mobile nodes may not be able to support the requirements of public key algorithms. Diffie Hellman based key distribution is a viable alternative to establish the security associations between the mobile node and entities in the visited or home domains. Internet Key Exchange is Le, Faccin [Page 2] INTERNET-DRAFT Mobile IP 23 February 2001 based on Diffie Hellman mechanism but IKE may not be appropriate for a wireless network: it requires too many messages to be exchanged over the access link and we need to consider that radio resources are a very limited and expensive resource. Although IKE may not be the best solution for a cellular environment, a simpler and lighter key distribution based on Diffie Hellman will enable to re-apply the work of the IPsec Working Group to the Diffie Hellman mechanism. Furthermore key distribution based on Diffie Hellman can provide Perfect Forward Secrecy. In summary, this document proposes to add two other key distribution mechanism to the mechanisms that already exist: a method based on random numbers and one based on the Diffie Hellman mechanism. 4. Key distribution based on random numbers 4.1. Background In current cellular networks, key distribution is based on random number. The Mobile Station and the Home Network share a long term key and have knowledge of a common authentication and key generation algorithm (e.g. CAVE in IS 41). Either the Home Network or the visited network generates the random number, depending on the specific cellular system considered. In the latter case, the visited domain informs the Home network of the value of the random number using inter domain security (e.g. thanks to a security association established through a roaming agreement). The random number is then sent to the Mobile station and using the long-term key and the common authentication and key generation algorithm, the MS derives the session keys. The Home Domain, having the same long-term key and authentication and key generation algorithms can also compute the same keys. It can then forwad them, protected using the inter domain security assocation, to the visited domain if the keys need to be shared between the mobile station and the visited domain. In such a mechanism, over the access link, only the random number and the response to the authentication need to be sent. Even if they are eavesdropped this does not compromise the security since the eavesdropper does not know the long term key and cannot compute the session keys. This mechanism does not require to send the long term key over the access link, thus reducing the risk of having it compromised. Le, Faccin [Page 3] INTERNET-DRAFT Mobile IP 23 February 2001 4.2. Basic procedure In the AAA framework, the Local Challenge [6] broadcasted by the visited domain in Router advertisments messages can be used as the random number to derive the session keys. The following procedure describes how key distribution takes place. Router +.......................+ Host . UCP CP . AAAL AAAH | LC . | | . | | |<--------------------| | . | | |AAA Req: LC,RPI,ID,CR| | . | | |-------------------->| | . | | | . | HR (LC, CR) | . | | | . |- - - - - - - - |- - - - - - - - >| | | . | | . AHR(LC, CR) | . | | . |- - - >| | . | | . AHA (K1,..., Kn; | . | | . R1,...,Rn) | HA (K1,..., Kn; R1,...,Rn) |< - - -| | . |<- - - - - - - -| -.- - - - - - - | | | . | Update config | . | | | . |--------------->| . | | | . | | . | | | . | | . | | | . | | . | | |AAA Rep: stat,RPI, R1,...,Rn | . | | |<--------------------| | . | | | . | | . | | +.......................+ LC = Local AAA Challenge RPI = Replay Protection Indicator used between host and AAAH CR = AAA Credential ID = Client Identifier UCP = Uncontrolled part CP = Controlled part AHR = AAA Host Request (using an AAA protocol) AHA = AAA Host Answer (using an AAA protocol) K1, ..., Kn = Session Keys R1, ..., Rn = Random values The Local challenge is then transmitted to the Home domain in the AHR message, protected using inter AAA servers security. Thanks to the Le, Faccin [Page 4] INTERNET-DRAFT Mobile IP 23 February 2001 Client Identifier (e.g. the user's NAI) AAA-H retrieves the user specific long-term key and using the shared authentication and key generation algorithm, AAA-H derives the session keys K1-Kn. The session keys are provided to the appropriate entities that will adopt them. Examples of session keys are the key used by the mobile node and the Home Agent for authenticating binding updates and Binding acknowledgement messages, and possible key shared by the mobile node and mobility agents. If this agent is in the Home network, AAA-H forwards the value of the session keys using intra domain security. Otherwise, if the agent is in the visited domain, AAA-H transmits the session keys in a AHA message protected using inter AAA servers security, and the AAA-L forwards the session keys to the corresponding agents using visited domain intra domain security. 4.3. Enhanced procedure In the previous case, the messages exchanged with the mobile node during the key distribution procedure are in clear text. The mechanism can be enhanced to provide confidentiality and authentication of the first messages as described in the follow: Le, Faccin [Page 5] INTERNET-DRAFT Mobile IP 23 February 2001 Router +.......................+ Host . UCP CP . AAAL AAAH | LC . | | . | | |<--------------------| | . | | |AAA Req*: LC,RPI,ID,CR| | . | | |-------------------->| | . | | | . | AHR (LC, CR) | . | | | . |- - - - - - - - |- - - - - - - - >| | | . | | . AHR(LC, CR) | . | | . |- - - >| | . | | . AHA (K, RAND_K) | . | AHA (K, RAND_K) |< - - -| | . |<- - - - - - - -| -.- - - - - - - | | | . | Update config | . | | | . |--------------->| . | | | . | | . | | | . | | . | | | . | | . | | |AAA Rep*: stat,RPI,KR, RAND_K | . | | |<--------------------| | . | | | . | | . | | +.......................+ Note: (*) indicates that the message is ciphered and integrity protected as described below. The mobile node takes the Local Challenge and using the long term key and a key derivation algorithm it shares with its Home domain, it derives a Temporal Ciphering Key and an Temporal Integrity Key. The mobile node then creates the AAA Req message and encapsulates the Binding Update message; it also uses the previously computed keys to encrypt and integrity protect the message but leaving the Client Identifier in Clear text. The Visited domain forwards this message to the AAA-H for user authentication, including the value of the Local Challenge. The AAA-H retrieves the user specific long term key thanks to the Client ID, and using the Local Challenge, derives the Temporal Ciphering Key and Temporal Integrity Key to decrypt the message. AAA- H then verifies the authenticity of the user based on the AAA credentials and generates a random number RAND_K. Based on this value, using the user specific long term key and the common authentication and key generation algorithm it shares with the MN, it derives a key K. Le, Faccin [Page 6] INTERNET-DRAFT Mobile IP 23 February 2001 AAA-H then forwards K to AAA-L using inter AAA servers security and uses the Temporal Ciphering Key and the Temporal Intergrity Key to secure the message to the MN carrying RAND_K. As indicated in the basic procedure, the AAA-H may distribute K to some entity, e.g. the Home Agent. When receiving the reply, the MN uses the Temporal Ciphering Key and Temporal Integrity Key to decrypt the message and using RAND_K, derive the session key to be used. The advantage of this mechanism is that it gives more control to the Home network since AAA-H generates the random number RAND_K used for the computation of the session keys and, in addition, provides more security since the messages exchanged with the mobile node during the key distribution procedure can be protected using the Temporal Ciphering Key and Temporal Intergrity Key. Finally RAND_K is also encrypted when sent to the MN. 5. Key distribution based on Diffie Hellman mechanism 5.1. Background In the key distribution solutions proposed in the previous section, the AAA-H acts as a Key Distribution Center, generating the session keys and thus having knowledge of the keys used. In a key distribution based on the Diffie Hellman mechanism, only the MN and the appropriate entities (i.e. the entities that will be using the keys for securing communications) have knowledge of the keys. Restricting the knowledge of the security key only to the entities that will actually use the keys is particularly useful in the following cases: - when Home Agent is assigned in Visited Domain; - for the security asociation to be used over the access link between the MN and the access router; - for the security association to be set up between the MN and the mobility agents in the visited domain (when an extension such as [1] or [2] is deployed). In such cases the visited domain and the MN may not want the home domain to know the value of the session keys. In addition, as mentioned above, the current proposals for Mobile IP key distribution does not provide Perfect Forward Secrecy whereas a Le, Faccin [Page 7] INTERNET-DRAFT Mobile IP 23 February 2001 key distribution mechanism based on Diffie Hellman can provide that security service. 5.2. Diffie Hellman mechanism As defined in [7], Diffie Hellman allows two nodes to derive a shared secret key for use in secret-key cryptography as follows: Each node generates a random, secret value which it keeps private. Each node computes a public value, derived mathematically from the random, secret value, and sends this public value to the other node. Each node mathematically combines the public value received from the other node with its own random, secret value. Due to the mathematical properties involved in the derivation of the public and secret values, the two nodes end up with the same exact combined values at the end of the procedure, which they can use as a shared secret key. In this exchange, the secret portions are not disclosed to anyone and therefore only these two nodes can compute the combined value. Diffie-Hellman has a major vulnerability, though. Although it allows two nodes to establish a shared, secret key in a secure fashion, it does not allow a node to figure out with what other node it is establishing that specific secret key: an intruder on the path between two nodes could fool them into each establishing a key with the intruder instead of each other (man in the middle attack). To prevent this kind of man-in-the-middle attack and defeat such vulnerability, the Diffie Hellman Public value must be authenticated. 5.3. Procedure As indicated above, in order to use the Diffie Hellman mechanism, the Diffie Hellman public values must be authenticated. In the Mobile IP/AAA framework, the security association between the Mobile node and its home network (AAA-H) and the security association between the AAA-L and AAA-H can provide that authentication. If the mobile node wants to set up a securiy association with an agent (e.g. home agent), the mobile node first sends its public Diffie Hellman value DH_MN using the long term security association it shares with its AAA-H to authenticate it. If the agent with whom the MN wants to set up a security association is in the visited domain, AAA-V retieves the agent's Diffie Hellman public value using Le, Faccin [Page 8] INTERNET-DRAFT Mobile IP 23 February 2001 intra domain security and sends such value (authenticated with the security association it shares with the AAA-H) to the home network of the MN together with the message from the MN. AAA-H authenticates the Diffie Hellman Public values of the agent and the MN, and then sends the MN's Diffie Hellman Public Value to the AAA-L using the security association it shares with AAA-L and encapsulates the Agent's Diffie Hellman Public Value to the MN using the security association it shares with the MN to authenticate it. In this way, AAA-H is used to authenticate the Diffie Hellman public values but since it does not have knowledge of the secret values, it can not derive the secret. AAA-H is used as a certificate authority thus allowing an easy transition when Public Key Infrastructure will be deployed. 6. Possible optimizations thanks to the Temporary Shared Key As described in [8], the Temporary Shared Key function encompasses the processes by which the authentication center (AAA-H) and the serving system (AAA-L) manage the sharing of authentication reponsibilities for a visiting MN. Initially, the MN and its Home network (AAA-H) share a long term security association. When TSK is used, the Home network provides the serving system (AAA-L) with a user specific temporary Shared Key that that is shared between the serving system and the MN. The temporary Shared Key refresh, set up and other related procedures are described in [8]. TSK Sharing gives the serving system significant load control over the authentication and key distribution of a visiting MN: the key refresh and new key distribution procedure can be based on this temporary shared Key stored in the AAA-L thus saving round trips with the Home network. Thanks to the TSK sharing function, the AAA-L can refresh and set up new keys for security associations between the MN and agents in the visited domain without involving the MN's home network. This reduces time delay and load over the network. This optimization can be applied both for the key distribution method based on random numbers and for the key distribution method based on the Diffie Hellman mechanism. In the first case, the serving system must have the common authentication and key generation algorithm and instead of using the long term key with the random number to compute Le, Faccin [Page 9] INTERNET-DRAFT Mobile IP 23 February 2001 the session keys, the MN and the AAA-L use the temporary Shared Key and the random number as the inputs to the common authentication and key generation algorithm. In the second case, the MN uses the temporary Shared Key to authenticate its Diffie Hellman public value. The AAA-L does not need to invoke the AAA-H to verify the identity of the node sending the public value. These are possible optimizations to the key distribution mechanisms but whether the TSK function is used depend on policies of the Home and Visited networks. 7. Security Considerations The focus of this document is to provide the appropriate level of security for Mobile IP entities (mobile node,home agent, mobility agent) to operate Mobile IP Binding Update, binding acknowledgement. The security associations resulting from use of the suggested mechanisms can also offer other security services between the mobile node and entities in the visited domain. 8. Intellectual Property Considerations Nokia Corporation and/or its affiliates hereby declare that they are in conformity with Section 10 of RFC 2026. Nokia's contributions may contain one or more patents or patent applications. To the extent Nokia's contribution is adopted to the specification, Nokia undertakes to license patents technically necessary to implement the specification on fair, reasonable and nondiscriminatory terms based on reciprocity. Le, Faccin [Page 10] INTERNET-DRAFT Mobile IP 23 February 2001 9. References [1] Jari T. Malinen and Charles E. Perkins. Mobile IPv6 Regional Registrations. Internet Draft, Internet Engineering Task Force, December 2000. [2] Hesham Soliman, Claude Castelluccia, Karim El-Malki, and Ludovic Bellier. Hierarchical MIPv6 mobility management. Internet Draft, Internet Engineering Task Force, September, 2000. [3] Charles E. Perkins and Pat R. Calhoun. AAA Registration Keys for Mobile IP. Internet Draft, Internet Engineering Task Force, January 2001. [4] Charles E. Perkins, David B. Johnson, Carnegie Mellon University and N. Asokan. Registration Keys for Route Optimization. Internet Draft, Internet Engineering Task Force, July 2000. [5] D. Harkins and D. Carrel Internet Key Exchange. Request for Comments 2409, Internet Engineering Task Force, November 1998. [6] N. Asokan, Patrik Flykt, Charles E. Perkins and Thomas Eklund AAA for IPv6 Network Access. Internet Draft, Internet Engineering Task Force, January 2000. [7] Diffie, W. and Hellman, M., "New Directions in Cryptography", IEEE Transactions on Information Theory, Vol. IT-22, Nov. 1976, pp. 664- 654. IP [8] 10 Franck Le and Stefano M. Faccin. Temporary Shared Key Function for secure delegation of security to the local network. Internet Draft, Internet Engineering Task Force, February 2001. Le, Faccin [Page 11] INTERNET-DRAFT Mobile IP 23 February 2001 10. Authors' Addresses Franck Le Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 374-1256 E-mail: franck.le@nokia.com stefano M. Faccin Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894-4994 E-mail: stefano.faccin@nokia.com Le, Faccin [Page 12] INTERNET-DRAFT Mobile IP 23 February 2001 Table of Contents Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3. Background and Motivation . . . . . . . . . . . . . . . . . . . . 2 4. Key distribution based on random numbers . . . . . . . . . . . . 3 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.2. Basic procedure . . . . . . . . . . . . . . . . . . . . . . 4 4.3. Enhanced procedure . . . . . . . . . . . . . . . . . . . . . 5 5. Key distribution based on Diffie Hellman mechanism . . . . . . . 7 5.1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Diffie Hellman mechanism . . . . . . . . . . . . . . . . . . 8 5.3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Possible optimizations thanks to the Temporary Shared Key . . . . 9 7. Security considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Intellectual Property Considerations . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Le, Faccin [Page iii]