Mobile IP WG Stefano M. Faccin INTERNET-DRAFT Franck Le Date: December 2001 Nokia Research Center Expires: June 2002 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 [1] 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 must be authenticated to prevent potential denial of service attacks [2]. The MN and the Home Agent can have a static security association, established at the configuration time, but the case of the Correspondent Node is more complex since it cannot be assumed that the MN and the CN have any pre-established security association. Faccin, Le [Page i] INTERNET-DRAFT Mobile IP November 2001 This document describes a method, based on the Diffie Hellman mechanism [3], to set up a security key between the MN and the CN to authenticate the Binding Update and the Binding Acknowledegement. The mechanism does not require any PKI nor any other infrastructure such as AAA but these mechanisms can optionally be used when present in order to authenticate the Diffie Hellman values. The present procedure enables the MN to establish symmetric keys with other entities without requiring the two involved parties to have any pre-shared data. The mechanism described in this document can also be used to establish the security association between the MN and the mobility agents when a Localized Mobility Management [4] solution is adopted. Faccin, Le [Page ii] INTERNET-DRAFT Mobile IP November 2001 1. Introduction This document includes many improvements compared to the previous version in order to make the protocol more robust against denial of service attacks. Cookies are suggested in order to avoid any memory DOS and computation DOS: The way to use them is very similar to the way described in JFK [5]. Since neither Public keys, nor PKI, nor AAA is required to authenticate the Diffie Hellman values, the protocol may be vulnerable to some man-in-the-middle attacks. Some methods to detect them and reduce the harm are suggested in section 3. Since the Mobile IP WG has not yet decided how to send the binding update authentication data (as destination option or new next header values, etc.), this document focuses on the protocol: it describes the entities behaviour and identifies the parameters that need to be exchanged but does not define the message format yet. 2. Protocol Overview In order to establish a security key and send authenticated binding update and binding acknowledgement messages, the MN and the CN exchange the following information: Notation: "MN->CN" means a message from the MN to the CN and "CN->MN" means the opposite direction. Some messages (e.g. message 2) are sent through the MN's HA since the CN sends this packet to the MN's Home address. Message 1, MN -> CN: Ni, g^i Message 2, CN -> MN (via HA): Ni, Nr, g^r, key_identifier, HMAC{HKr}(Ni, Nr, g^i, g^r) Message 3, MN -> CN : Ni, Nr, g^i, key_identifier, HMAC{HKr}(Ni, Nr, g^i, g^r), Authenticated BU (Ks) Message 4, CN -> MN : Authenticated BA (Ks) The key used to authenticate the binding update and binding acknowledgement is computed as HMAC{g^ir}{Ni, Nr}. Faccin, Le [Page 1] INTERNET-DRAFT Mobile IP November 2001 Message 1: The MN sends a fresh random nonce, Ni, with its exponential, g^i, of a well-known Diffie Hellman group, to the correpondent node. The MN can re-use a g^i value in multiple instances of the protocol with the CN or other CNs for as long as the MN wishes its forward secrecy interval to be. The Nonce Ni allows the MN to reuse the exponential while ensuring that the resulting session key Ks will be different. Message 2: The CN replies with its exponential and an authenticator calculated from a secret, HKr, known to the CN; the authenticator is computed over the two exponentials and nonces. The computation of the authenticator is implementation dependent but it is also recommended that the source IP address, the destination IP address and the home address option are considered in the authenticator computation. The authenticator key is changed at least as often as g^r, thus preventing replays of stale data. The CN's exponential, g^r, may also be reused; again, it is regenerated according to the CN's forward secrecy interval. The nonce Nr prevents two successive session keys from being the same. If the Diffie Hellman Group chosen by the MN is not acceptable to the CN, this latter one instead, replies indicating the groups it accepts. Note that the CN does not need generate any state at this point, but only performs a MAC calculation. Since the CN does not know if the Message 1 is coming from a legitimate MN or a forged message from a denial of service attack, the CN does not perform expensive calculations nor create any state. If the Message 1 is a bogus one, the CN will not have committed any storage resources. This message is sent to the MN's home address. The HA will therefore intercept it and forward it to the MN. Message 3: It includes Ni, Nr, g^i, key_identifier and the authenticator. Thanks to the key_identifier, the CN will be able to know which g^r to consider: the CN may be generating a new g^r between the time it sends the message 2 and receives message 3. Then with the received Ni, Nr, g^i, and eventually the souce, destination and home IP addresses, the CN can re-compute the authenticator, and Faccin, Le [Page 2] INTERNET-DRAFT Mobile IP November 2001 compares it with the received one, thus verifying the authenticity of the returned data: This allows the CN to verify that it is in round-trip communication with a legitimate potential MN. The Message 3 also carries an authenticated BU; and if the authenticator verification passed, then the CN computes the deriving Diffie Hellman session key Ks and verifies the authenticity of the BU. The CN SHOULD keep a copy recently-received Message (3)'s and their corresponding Message (4). Receiving a duplicate (or replayed) Message (3) causes the Responder to simply retransmit the corresponding message (4) without creating new state or invoking the Diffie Hellman computation. This cache of messages coud be reset as soon as g^r or HKr are changed. As outlined in JFK, caching Message (3) and refraining from creating new state for replayed instances of Message (3) serves also another security purpose. If the CN were to create a new state and send a new Message (4), and a new sa' for a replayed Message (3), then an attacker that compromised the MN could replay a recent session with the CN. That is, by replaying Message (3) from a recent exchange between the MN and the CN, the attacker could establish a session with the CN where the session-key is identical to the key of the previous session (which took place when the Initiator was not yet compromised). This could compromise the Forward Security of the MN. There is a risk, however, to keeping this message cached for too long: if the CN's machine is compromised during this period, perfect forward secrecy is compromised. We can tune this by changing the MAC key HKr more frequently. The cache can be reset when a new g^r or HKr is chosen. Message 4: The CN sends a Binding Acknowledgement to the MN, authenticated with Ks. If protection against replay attacks is desired for the binding acknowledgement, the MN can send a random number in message 3; and the CN will echoes back the random number and takes it as an input in the computation of the authentication data for the binding acknowledegment. After such a procedure, the MN and the CN share a session key, Ks, they can directly use in order to authenticate subsequent binding update/ binding acknowledgement. Faccin, Le [Page 3] INTERNET-DRAFT Mobile IP November 2001 3. Man in the middle attacks Unauthenticated Diffie Hellman key agreement is vulnerable to intruder-in-the-middle attack; therefore whenever Public Keys, PKI, or AAA is present, these SHOULD be used to authenticate the Diffie Hellman values. 3.1. Diffie Hellman exchange with a AAA based authentication When present, a AAA infrastructure could be used in order to authenticate the Diffie Hellman exchange as follows: Assumption: * MN and AAAh share a security association (Ki) * CN and its AAAh share a security association (Kj) * 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 Faccin, Le [Page 4] INTERNET-DRAFT Mobile IP November 2001 (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_CN can make sure CN sends that request. * CN's AAAh verifies MAC(Kj): - AAAh_CN retrieves Kj thanks to CN's NAI - And then compute MAC(Kj) taking Kj, and DH(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 Faccin, Le [Page 5] INTERNET-DRAFT Mobile IP November 2001 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. 3.2. Diffie Hellman exchange with a Public keys based authentication If Public keys are available, MN and CN SHOULD use them to sign/authenticate the Diffie Hellman information. 3.3. Man in the middle attack detection methods Otherwise, if neither AAA nor PKI is valid, properties of IP could help detecting man in the middle attacks attempts: if an intruder is between the MN and the CN and tries to fool both entities inserting in the middle after MN has sent a message 1, this man in the middle may most probably not be able to 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 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 may most probably not be able to 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. Faccin, Le [Page 6] INTERNET-DRAFT Mobile IP November 2001 3.4. Security considerations This document is about security and more particularly intends to solve one of the security issues related to Mobile IPv6: the establishment of a secret key between the MN and its CN in order to be able to send the authenticated binding updates. Faccin, Le [Page 7] INTERNET-DRAFT Mobile IP November 2001 4. References [1] "Mobility Support in IPv6", David B. Johnson, Charles Perkins, Internet Engineering Task Force, Internet draft, work in progress, November 2001 [2] "Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6", Allison Mankin, Basavaraj Patil, Dan Harkins, Erik Nordmark, Pekka Nikander, Phil Roberts, Thomas Narten, Internet Engineering Task Force, Internet draft, work in progress, November 2001 [3] "Diffie, W. and Hellman, M., "New Directions in Cryptography", IEEE Transactions on Information Theory, Vol. IT-22, Nov. 1976, pp. 664- 654. [4] "Localized Mobility Management Requirements for IPv6", Carl Williams, Internet Engineering Task Force, Internet draft, work in progress, November 2001 [5] "Just Fast Keying (JFK)", W. Aiello, S.M. Bellovin, M. Blaze, R. Canetti, J. Ioannidis, A.D. Keromytis, O. Reingold Faccin, Le [Page 8] INTERNET-DRAFT Mobile IP November 2001 5. Authors' Addresses Stefano M. Faccin Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894-4994 E-mail: stefano.faccin@nokia.com Franck Le Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 374-1256 E-mail: franck.le@nokia.com Faccin, Le [Page 9] INTERNET-DRAFT Mobile IP November 2001 Table of Contents Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . 1 3. Man in the middle attacks . . . . . . . . . . . . . . . . . . . . 4 3.1. Diffie Hellman exchange with a AAA based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Diffie Hellman exchange with a Public keys based authentication . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Man in the middle attack detection methods . . . . . . . . . 6 3.4. Security considerations . . . . . . . . . . . . . . . . . . 7 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Faccin, Le [Page x]