Mobile IP WG Franck Le INTERNET-DRAFT Stefano M. Faccin Date: April 2001 Expires: October 2001 Nokia Research Center Dynamic Diffie Hellman based Key Distribution 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 requires several security associations: the Mobile Node must share a security association with its Home agent and its Correspondent Nodes to send the binding Update; these messages need to be authenticated to prevent some kind of denial of service attacks. When some Mobile IP extensions such as [HMPIv6] or [RegRegv6] are deployed, the MN also has to set up a security association with the Mobility Agents. The MN and the Home Agent can have a static security association, established at the configuration time, but establishing the security association between the Mobile Node and the Home Agent becomes more Le, Faccin [Page i] INTERNET-DRAFT Mobile IP April 2001 difficult when dynamic Home Agent assignment is allowed. In the case of Correspondent Nodes, the situation is even more complex since it cannot be assumed that the MN and the CN have any pre-established security association. This document describes a Diffie Hellman based key distribution which can also rely on the AAA framework for authentication of the key exchange. Whereas there are well known issues with the availability of a large scale PKI, the AAA infrastructure will be most probably largely deployed for roaming scenarios. In fact, it is in the interest of the visited domain to first make sure that the user accessing the resources is authorized (even if the service is given for free), and second to make sure that money can be collected for roaming users. As an alternative solution applicable in case the AAA servers cannot be used, the document proposes a Diffie Hellman key distribution mechanism relying on the presence of Home Agent. The present procedure enables the MN to securely establish symmetric keys with other entities without requiring the two involved parties to have any pre-shared data. Le, Faccin [Page ii] INTERNET-DRAFT Mobile IP April 2001 1. Introduction Mobile IP requires several security associations: the Mobile Node must share a security association with its Home agent and its Correspondent Nodes to send the binding Update; these messages need to be authenticated to prevent some kind of denial of service attacks. When some Mobile IP extensions such as [HMPIv6] or [RegRegv6] are deployed, the MN also has to set up a security association with the Mobility Agents. The MN and the Home Agent can have a static security association, established at the configuration time, but establishing the security association between the Mobile Node and the Home Agent becomes more difficult when dynamic Home Agent assignment is allowed. In the case of Correspondent Nodes, the situation is even more complex since it cannot be assumed that the MN and the CN have any pre-established security association. This document describes a Diffie Hellman based key distribution which can also rely on the AAA framework for authentication of the key exchange. Whereas there are well known issues with the availability of a large scale PKI, the AAA infrastructure will be most probably largely deployed for roaming scenarios. In fact, it is in the interest of the visited domain to first make sure that the user accessing the resources is authorized (even if the service is given for free), and second to make sure that money can be collected for roaming users. As an alternative solution applicable in case the AAA servers cannot be used, the document proposes a Diffie Hellman key distribution mechanism relying on the presence of Home Agent. The present procedure enables the MN to securely establish symmetric keys with other entities without requiring the two involved parties to have any pre-shared data. 2. Diffie Hellman Background As defined in [DifHel76], Diffie-Hellman allows two nodes to derive a shared secret key for use in secret-key cryptography as follows: 1. Each node generates a random, secret value which it keeps private; 2. Each node computes a public value, derived mathematically from the random, secret value, and sends this public value to the Le, Faccin [Page 1] INTERNET-DRAFT Mobile IP April 2001 other node; 3. 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 in step 3 which they can use as a shared secret key. Diffie-Hellman mechanism has a major property: the secret portions are not disclosed to anyone and, therefore, only these two nodes can compute the combined value. But Diffie Hellman has vulnerability: it does not allow a node to figure out with whom it is establishing the secret key: an intruder on the path between the two nodes can fool them into each establishing a key with the intruder instead of with each other. To prevent that attack, the Diffie Hellman public values must be authenticated: The AAA servers can thus be used to link the node entity to its Diffie Hellman public value. 2.1. Diffie Hellman Key Agreement Protocol (Basic version) This section describes in more details the data that need to be exchanged between the two nodes and their process to end up with the shared key: Assumption: * An appropriate prime p and generator g such as (2 Node2 : g^x mod p (1) Node1 <--------- Node2 : g^y mod p (2) Protocol actions: Perform the following steps each time a shared key is required. 1. Node1 chooses a random secret x, 1 g^x ----> E ----> g^x' ----> B A <---- g^y' <---- E <---- g^y <---- B A and B have private keys x and y, respectively. E creates keys x' and y'. E intercepts A's exponential and replaces it by g^x'; and intercepts B's exponential, replacing it with g^y'. a forms session Key K_A=g^(xy'), while forms session key K_B=g^(x'y). E is able to compute both these keys. When A subsequently sends a message to B encrypted under K_A, E deciphers it, re-enciphers under K_B, and forwards it to B. Similarly E deciphers messages encrypted by B (for A) under K_B and re-enciphers them under K_A. A and B belive they communicate securely while E reads all traffic. 3. A Diffie Hellman based key distribution relying on AAA servers As explained above, man-in-the-middle attacks can be performed on Diffie Hellman based key exchange. To prevent it, the Public Diffie Hellman values need to be authenticated: AAA servers can be used in that purpose and the protocol overview is as follows. Assumption: * MN and AAAh share a security association (Ki) * CN and its AAAh share a security association (Kj) Le, Faccin [Page 3] INTERNET-DRAFT Mobile IP April 2001 * AAAh of MN and AAAh of CN share a security association (K1) Notation: * DH(xxx) Diffie Hellman information related to xxx * MAC (Kx) Authentication data computed using the security key Kx (Ki) (Ki) (K1) (K1) (Kj) (Kj) MN AAAh_MN AAAh_CN CN -- ------- ------- -- | DH(MN), MAC(Ki) | | | |------------------+----------------------+---------------->| | | | | | | | DH(CN), MAC(Kj) | | | DH(CN), MAC(K1) |<----------------| | |<---------------------| DH(MN), MAC(Ki) | | | DH(MN), MAC(Ki) | | | | | | | | | | | | DH(CN), MAC(Ki) | | | |--------------------->| | | | DH(MN), MAC(K1) | DH(CN), MAC(Ki) | | | |---------------->| | | | DH(MN), MAC(K1) | | | | | | DH(CN), MAC(Ki) | | | |<-----------------+----------------------+-----------------| | | | | * MN sends its Diffie Hellman information DH(MN) to the entity with which it wants to establish a security association (e.g the CN to whom it wants to send a Binding Update). This information is authenticated thanks to a hash function and using the security association between the MN and its AAAh (Ki): MAC(Ki) * When receiving this information, to get it authenticated, the CN sends it, thanks to the MN NAI, to the MN AAAh via its AAAh. It also adds its Diffie Hellman information to get it certified and to send it to the MN; this data is authenticated by Kj so AAAh can make sure CN sends that request. * CN's AAAh verifies MAC(Kj): Le, Faccin [Page 4] INTERNET-DRAFT Mobile IP April 2001 - AAAh retrieves Kj thanks to CN's NAI - And then compute MAC(Kj) taking Kj, and MN(CN) as inputs to an authentication algorithm shared between the CN and its AAAh. If the authentication succeeded, CN's AAAh computes MAC(K1) * MN's AAAh, upon receipt of DH(CN), MAC(K1) and DH(MN), MAC(Ki): - verifies MAC(K1) and if valid, computes DH(CN), MAC(Ki): this information will be sent by the CN to the MN and since the MN trusts its Home network (Ki), it can trust that DH(CN) is the Diffie Hellman information of CN - verifies MAC(Ki) and if valid, computes DH(MN), MAC(K1) * Then CN's AAAh: - forwards DH(CN), MAC(Ki) to CN - verfies MAC(K1) and if valid, computes DH(MN), MAC(Kj) * The CN verfies DH(MN), MAC(Kj) and if valid, since it trusts its AAAh, it knows DH(MN) corresponds to Diffie Hellman information of the MN. CN then sends its certified Diffie Hellman information to MN: DH(CN), MAC(Ki) MN and CN have thus exchanged their Diffie Hellman information in an authenticated manner and can now derive the shared session key. 4. A Diffie Hellman based key distribution without AAA servers The following solution applies to the case where AAA servers cannot be adopted, e.g. when the CN does not have any security association established with a AAA server. 4.1. Protocol Overview Le, Faccin [Page 5] INTERNET-DRAFT Mobile IP April 2001 1. DH(MN) ----------------------------> MN ---------------------------- CN \ 4. BU // \ ------------------------> // \ // \ // \ //2. DH(CN) \ // \ // 3. DH(CN) // \ // \ // --- HA --- / --- <--- 1. The MN first sends its Diffie Hellman information to the CN. 2. The CN sends its Diffie Hellman information the MN's Home address and computes the session key 3. The Home agent encapsulates the packet to the MN 4. The MN receives the Diffie Hellman information of the CN and thus can compute the session key and sends an authenticated Binding Update 4.2. Properties The CN relies on the Home Agent to sends its Diffie Hellman information to the MN. Since the CN does initially not have any binding for the MN in its binding cache, the CN was anyway sending packet for the MN to the HA and thus the route optimization establishment does not add more vulnerability to the routing functions. 4.3. Man in the middle attack detection Unauthenticated Diffie Hellman key agreement is vulnerable to intruder-in-the-middle attack; but thanks to the property of IP, if a man in the middle is between the MN and the CN and tries to fool both entities as previously described, since the man in the middle can not stop the original packet from the MN, the MN will receive two different Diffie Hellman values for the CN, and thus be aware that an Le, Faccin [Page 6] INTERNET-DRAFT Mobile IP April 2001 intruder is trying to lead some attacks. It can so take the appropriate actions and e.g. send a warning message to the CN. In the cases that two nodes (node A and node B) are communicating and an intruder wants to lead a man in the middle attack by acting as if being node A, pretending to be a mobile IPv6 node and trying to set up a shared secret with node B to later send an authenticated binding update; the node B will send its Public Diffie Hellman value to node A while A is not expecting this. since the intruder can not stop this packet due to the IP's properties, Node A can thus be aware that an intruder is trying to lead a man in the middle attack and warn node B by sending a message and taking the appropriate actions. In both cases, we therefore have ways to detect man in the middle attacks. 5. New Diffie Hellman Groups As explained in the Basic Verion of the Diffie Hellman key agreement, the prime and the generator are assumed to be published. The Internet Key Exchange [IKE] RFC already defines many groups and thus, the node1 and the node2 only need to exchange their public Diffie Hellman values (g^x mod p and g^y mod p). Actually, the nodes could also create their own group that will be used for the secret key establishment and will be deleted when the session key lifetime expires. The initiating node will in such cases includes all the required information in the first message. As an example, the node1 could: - pick an appropriate prime p and generator g; - selects a random integer x such that 1