Mobile IP Working Group Charles E. Perkins INTERNET DRAFT Nokia Research Center 27 February 2000 David B. Johnson Carnegie Mellon University Registration Keys for Route Optimization draft-ietf-mobileip-regkey-01.txt Status of This Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. 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 Route optimization defines extensions to Mobile IP Registration Requests that allow datagrams in flight when a mobile node moves, and datagrams sent based on an out-of-date cached binding, to be forwarded directly to the mobile node's new binding. These extensions for smooth handoff require a registration key to be established between the mobile node and foreign agent. This document defines additional extensions to the registration requests to allow for the establishment of single-use registration keys between a mobile node and foreign agent. Perkins and Johnson Expires 27 August 2000 [Page i] Internet Draft Registration Keys 27 February 2000 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Terminology 1 3. Establishing Registration Keys 2 3.1. The Home Agent as a KDC . . . . . . . . . . . . . . . . . 4 3.2. Using the Foreign Agent as a KDC . . . . . . . . . . . . 5 4. Registration Key Request Extension Subtypes 5 4.1. Registration Key Request Subtype . . . . . . . . . . . . 7 4.2. Foreign Agent Registration Key Request Subtype . . . . . 7 4.3. Mobile Node Request Via Public Key Subtype . . . . . . . 8 4.4. Foreign Agent Public Key Request Subtype . . . . . . . . 8 4.5. Diffie-Hellman Registration Key Request Subtype . . . . . 8 4.6. Diffie-Hellman Elliptic Curve Registration Key Request . 9 5. Generalized MN-FA Key Reply Subtypes 10 5.1. Registration Key Reply from Home Agent Subtype . . . . . 11 5.2. Mobile Node Public Key Reply Subtype . . . . . . . . . . 11 5.3. Foreign Agent Public Key Reply Subtype . . . . . . . . . 12 5.4. Diffie-Hellman Key Reply Subtype . . . . . . . . . . . . 12 6. Mobile Node Key Requests 13 7. Miscellaneous Home Agent Operations 14 7.1. Receiving Registration Key Requests . . . . . . . . . . . 14 7.2. Diffie-Hellman Considerations . . . . . . . . . . . . . . 15 7.3. Home Agent Supplying Registration Keys . . . . . . . . . 16 8. Miscellaneous Foreign Agent Operations 17 8.1. Foreign Agent Handling Key Requests . . . . . . . . . . . 17 8.2. Advertising Digestified Diffie-Hellman Computations . . . 19 9. Security Considerations 19 References 20 A. Using Diffie-Hellman with the Foreign Agent 21 B. Diffie-Hellman Key Exchange in the Field of Integers mod p 23 Perkins and Johnson Expires 27 August 2000 [Page ii] Internet Draft Registration Keys 27 February 2000 C. Diffie-Hellman Key Exchange in Elliptic Curve Groups 23 Addresses 26 1. Introduction The Binding Update is a Route Optimization [12] message that changes the routing of IP datagrams to the mobile node. It can be authenticated using mechanisms similar to those specified for the base Mobile IP protocol [11]. The authentication relies on a mobility security association established in advance between the sender and receiver of such messages. The Binding Update message can be used to accomplish a smooth handoff for a mobile node moving from a previous foreign agent to a new foreign agent. Such smooth handoffs rely on the Previous Foreign Agent Notification extension [12], which requires the transmission of a Binding Update to the previous foreign agent created by the mobile node after it moves. However, when a mobile node registers with a foreign agent, typically it does not share a security association with the foreign agent. In order for the foreign agent to process future Binding Updates that it may receive from the mobile node, it needs to establish such a security association. This document is a specification for some useful methods for establishing the necessary mobility security association between the mobile node and its new foreign agent. 2. Terminology This document makes use of many terms defined in RFC 2002 [11] to describe the base Mobile IP protocol, as well as terms defined in the specification for Route Optimization [12]. In addition, the following terms are used: Binding cache A cache of mobility bindings of mobile nodes, maintained by a node for use in tunneling datagrams to those mobile nodes. Field Element an element of one of the fields used to define the Diffie-Hellman key exchange extensions. This usage must be carefully distinguished from the use of the word "field" to denote a designated part of the data for a protocol unit. Perkins and Johnson Expires 27 August 2000 [Page 1] Internet Draft Registration Keys 27 February 2000 Registration Key A secret key shared between a mobile node and a foreign agent, that may optionally be established during registration with that foreign agent. When later moving and registering a new care-of address elsewhere, the mobile node uses the registration key shared with its previous foreign agent to send it an authenticated Binding Update to this foreign agent. The registration key forms the basis for the mobility security association needed between the mobile node and the foreign agent. Registration Lifetime The registration lifetime is the time duration for which a binding is valid. The term remaining registration lifetime means the amount of time remaining for which a registration lifetime is still valid, at some time after the registration was approved by the home agent. Triangle Routing A situation in which a correspondent node's packets to a Mobile Node follow a path which is longer than the optimal path because the packets must be forwarded to the Mobile Node via a Home Agent. In formulas requiring exponentiation, the `^' character is used. 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 [1]. 3. Establishing Registration Keys Foreign agents may become cheap and widely available, as Mobile IP becomes fully deployed. Mobile nodes will likely find it difficult to manage long-term security relationships with so many foreign agents. To securely perform the operations needed for smooth handoffs from one foreign agent to the next, however, any careful foreign agent should require assurance that it is getting authentic handoff information, and not arranging to forward in-flight datagrams to a bogus destination. The messages described in this document are used with the Mobile IP Registration Request and Registration Reply messages to create (sufficient) trust between mobile node and foreign agent when none exists beforehand, while allowing the use of fully trustworthy security associations between foreign agents and mobile nodes whenever they do exist. Perkins and Johnson Expires 27 August 2000 [Page 2] Internet Draft Registration Keys 27 February 2000 Note that the mobile node may often be unable to verify the identity of the foreign agent. It must then act only on the presumption that the foreign agent is performing its duties by correct adherence to protocol. The exact identity of the foreign agent is not crucial to the process of establishing a registration key. Only an agreement to follow protocol can be expected or enforced. If the mobile node has a way to obtain a certified public key for the foreign agent, then the identity may be established in a firmer fashion, but the needed public key infrastructure seems to be at least five years distant. Therefore, the methods in this document enable a mobile node to create a registration key with an anonymous foreign agent (i.e., one whose identity we cannot establish) during the registration process. There are several proposed methods for establishing a registration key, discussed in order of declining preference. Other methods of establishing keys may become available in the future. 1. If the foreign agent and mobile node share a security association, it can be used to secure the Previous Foreign Agent Notification without need to establish a registration key. 2. If the home agent and foreign agent share a security association, the home agent can choose the new registration key. 3. If the mobile node can transfer key information between foreign agents that trust each other, it can use the same key as it had used with its previous foreign agent [2]. 4. If the foreign agent has a public key, it can again use the home agent to supply a registration key. 5. If the mobile node includes its public key in its Registration Request, the foreign agent can choose the new registration key. 6. The mobile node and its foreign agent can execute a Diffie-Hellman key exchange protocol [5], using the method for elliptic curves [7, 9], or using the more familiar method involving exponentiations. Once the registration key is established, the smooth handoff method can be used [12]. The following sections give a brief overview of the above enumerated methods for establishing the registration key. If a request for key establishment cannot be accommodated by the foreign agent and/or the home agent, then the mobile node's key request must go unfulfilled. This does not mean that the Registration Request itself fails, so the same status code will be returned by the home agent to the mobile node. The mobile node has to be able to handle the case in which it has requested a key but the Registration Reply arrives without any key reply extension. Perkins and Johnson Expires 27 August 2000 [Page 3] Internet Draft Registration Keys 27 February 2000 This could happen even when the foreign agent has advertised its willingness to offer smooth handoffs, and the mobile node has supplied all the necessary parameters. The effect will likely be a less than smooth handover. 3.1. The Home Agent as a KDC Crucial to methods (2) and (4) listed above is that the home agent and mobile node already are known to share a mobility security association, which can be used to encode the registration key for delivery to the mobile node. Thus, if the home agent can securely deliver the key to the foreign agent, it can be used as a Key Distribution Center (KDC) for the mobile node and its new foreign agent. The mobile node requests this by including a Registration Key Request extension in its Registration Request message. When the home agent chooses the registration key, it returns the key in two different extensions to the Registration Reply. One extension has the encrypted key for the foreign agent, and the other extension has the same key encrypted differently for the mobile node. For the registration key to be established using this method, the home agent must be able to securely transmit an encrypted copy of the registration key to the foreign agent. This is straightforward if the foreign agent already has a mobility security association with the home agent. If mobile nodes from some home network often visit a foreign agent, then the effort of creating such a mobility security association between that foreign agent and the home agent serving their home network may be worthwhile. If the home agent does not have such a mobility security association, but the foreign agent has a public key available, it can still ask the home agent to use it to pick a registration key. This is preferable than asking the mobile node to pick a good registration key, because doing so may depend upon using resources not available to all mobile nodes; simply selecting pseudo-random numbers is by itself a significant computational burden. Moreover, allowing the home agent to pick the key fits well into the existing registration procedures. On the other hand, it is conceivable that a mobile node could do with less than perfect pseudo-random numbers as long as the registration key were to be used in the restricted fashion envisioned for smooth handoffs. Note that MD5 can be used here for the purpose of transmitting registration keys, secure against eavesdroppers. The expression expr1 == MD5(secret | regrep | secret) XOR (key) Perkins and Johnson Expires 27 August 2000 [Page 4] Internet Draft Registration Keys 27 February 2000 (where regrep is the Registration Reply message payload up to but not including the encoded key data, and XOR is exclusive-or) can be included within the appropriate Registration Reply extension. This encodes the key in a way which allows recovery only by the recipient. It is secure against replay because of the Identification within the Registration Reply message. The recipient recovers the key by computing expr2 == MD5(secret | regrep | secret) which then yields (key == expr1 XOR expr2). Use of MD5 avoids entanglements with the legal issues surrounding the export of encryption technology, and reducing the computational power needed to secure the password against eavesdroppers. 3.2. Using the Foreign Agent as a KDC When the foreign agent and mobile node share a mobility security association, there is no need to pick a registration key. The mobile node can secure its Binding Update to the foreign agent whenever it needs to, by using the existing security association. This is the most desirable case. Otherwise, if available, the mobile node can include its public key (such as RSA [14]) in its Registration Request to the foreign agent, using a Mobile Node Public Key Request extension (see section 4.3). The foreign agent chooses the new registration key and includes a copy of it encrypted with the mobile node's public key, using a Foreign-Mobile Public Key Reply extension (see section 5.3). This is sent to the home agent for inclusion with the Registration Reply. 4. Registration Key Request Extension Subtypes A Generalized MN-FA Key Request extension has been specified [13]. This generalized extension contains the SPI that the mobile node wishes to use with the registration key. Thus, it is guaranteed that the SPI will not collide with another existing Mobility Security Association already in place for the mobile node. To simplify the discussion for protocol operations involving a particular subtype, the generalized extension with a particular subtype will typically be denoted as a specific extension, instead of a generalized extension with a specific subtype. So, for instance, there will be discussion using the terminology "Registration Key Request extension", which should be interpreted to mean "Generalized Key Request extension with subtype 1". Note that a key requested by any subtype of this Generalized Registration Key Request extension Perkins and Johnson Expires 27 August 2000 [Page 5] Internet Draft Registration Keys 27 February 2000 is, by definition, for use between the mobile node and the foreign agent handling its Mobile IP Registration Request. The foreign agent stores the SPI from the registration key request extension sent by the mobile node as part of its pending registration request information. The SPI will be needed if the registration key reply extension is returned in the Registration Reply message from the home agent. In this document, the following subtypes of the Generalized MN-FA Key extension are defined: 1. Registration Key Request subtype (see section 4.1) 2. Foreign Agent Registration Key Request subtype (see section 4.2) 3. Mobile Node Request Via Public Key subtype (see section 4.3) 4. Foreign Agent Public Key Request subtype (see section 4.4) 5. Diffie-Hellman Registration Key Request subtype (see section 4.5) 6. Diffie-Hellman Elliptic Curve Registration Key Request extension (see section 4.6) Handling for these subtypes is specified in this section. These may be used by mobile nodes or foreign agents to request the establishment of a registration key. For each subtype, the MN-FA Key Request Subtype Data of the Generalized Key Request extension has to be specified. In this section, the MN-FA Key Request Subtype Data will generally be referred as "the subtype data". See sections 6, 7.3, and 8 for appropriate algorithms which allow each node to use the extensions that most closely fit its configured requirements. There are two Diffie-Hellman Key Request subtypes that may be included by a foreign agent in a Registration Request message sent to a home agent, if the other possible key establishment methods are not available. For either subtype, the foreign agent should then select a good pseudo-random registration key. The foreign agent initiates the Diffie-Hellman key exchange algorithm (as described in Appendix A), and includes a Diffie-Hellman Registration Key Request extension in the Registration Request message sent to the home agent to initiate the key exchange. The home agent will then complete the key exchange and include the computed value in the Diffie-Hellman Registration Key Reply extension in the Registration Reply sent to the mobile node, where that extension can be authenticated as part of the reply message. Perkins and Johnson Expires 27 August 2000 [Page 6] Internet Draft Registration Keys 27 February 2000 The two Diffie-Hellman key request subtypes differ in the creation and processing of the Computed Value which appears in the subtype data. Note that I am not certain that the name "Diffie-Hellman" applies to key exchanges using elliptic curve groups. 4.1. Registration Key Request Subtype The Registration Key Request subtype may be included in a Registration Request to ask the foreign agent to supply a key by any means it has available. The foreign agent may have a public key, or it might have a security association with the home agent. Otherwise, the foreign agent will attempt to employ a Diffie-Hellman key exchange. If the foreign agent has advertised a Challenge value, and also sets the `S' bit in its Agent Advertisements, then the mobile node MUST include that Challenge value in its registration request [3]. Furthermore, in this case, the Challenge value represents a digested form of the next value that would be used, if needed, by the foreign agent in its next key exchange with a home agent. Thus, if the foreign agent sets the `S' bit but does NOT include a Challenge value, the mobile node cannot be certain that the foreign agent is taking steps to protect against the man-in-the-middle attack that can sometimes be mounted against Diffie-Hellman key exchanges. While this is normally not an issue for registration keys, some mobile nodes MAY be configured to avoid using the Registration Key Request extension when the foreign agent does not advertise the Challenge value. For this extension, the subtype data is empty. 4.2. Foreign Agent Registration Key Request Subtype If the foreign agent receives a Registration Key Request from a mobile node, and it has a security association with the home agent, it may select a registration key and append the Foreign Agent Registration Key Request extension to the Registration Request after the mobile-home authentication extension. For this extension, the SPI in the Generalized Key Request extension refers to the SPI of the security association between the home agent and the foreign agent. For this extension, the subtype data is the key selected by the foreign agent and encoded according to the FA-HA security association. Perkins and Johnson Expires 27 August 2000 [Page 7] Internet Draft Registration Keys 27 February 2000 4.3. Mobile Node Request Via Public Key Subtype If the mobile node has a public key, it can ask its prospective foreign agent to choose a registration key, and to use the mobile node's public key to encode the chosen registration key. No eavesdropper will be able to decode the registration key, even if the encoded key is broadcast to all entities with access to the network medium used by the mobile node. The foreign agent then includes the encoded registration key in a Mobile Node Public Key Reply extension (see section 5.2) to the Registration Request as it goes to the home agent. Then, the home agent can authenticate the selected encoded registration key as part of the Registration Reply message. For the Mobile Node Request Via Public Key subtype, the subtype data contains the mobile node's public key. 4.4. Foreign Agent Public Key Request Subtype If the foreign agent has a public key, it can ask the mobile node's home agent to choose a registration key, and then to use the foreign agent's public key to encode the chosen registration key. As before, no eavesdropper will be able to decode the registration key, even if the encoded key is broadcast to all entities with access to the network medium used by the home agent and the foreign agent. The home agent then includes the encoded registration key in a Foreign Agent Public Key Reply extension (see section 5.3) to the Registration Reply. For the Foreign Agent Public Key subtype, the subtype data contains the foreign agent's public key. 4.5. Diffie-Hellman Registration Key Request Subtype The foreign agent may send the Diffie-Hellman Registration Key Request extension to initiate key exchange by use of the exponentiation algorithm in the field of integers mod p, as described in Appendix A. To initiate the key exchange the foreign agent chooses a large random number, N. If g is the value of the generator and p is the value of the prime, the computed value in the extension is g^N mod p. See appendix B for details on the algorithm. The foreign agent then appends the extension to the Registration Request message, containing the values for the prime and generator, along with the computed value (F) from its own private random number N. The home agent will then choose its own private random number M and creates its own computed value (H). The foreign agent will complete the key exchange by extracting the home agent's computed Perkins and Johnson Expires 27 August 2000 [Page 8] Internet Draft Registration Keys 27 February 2000 value H from the Diffie-Hellman Registration Key Reply extension in the registration request. The format of the subtype data contained in this extension is illustrated below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prime ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Generator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Computed Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prime One of the two public numbers involved in the Diffie-Hellman key exchange algorithm. The prime should be a large prime number. Generator The other public number involved in the Diffie-Hellman key exchange algorithm. If p is the value of the prime used for this Diffie-Hellman exchange, the generator should be less than p, and should be a primitive root [14] of p. Computed Value The public computed value from the foreign agent for this Diffie-Hellman exchange. The values indicated for the prime, generator, and computed value are all the same length, which must be a integral number of bytes. 4.6. Diffie-Hellman Elliptic Curve Registration Key Request All foreign agents that support smooth handovers SHOULD support the Diffie-Hellman Elliptic Curve Registration Key Request. To initiate the key exchange the foreign agent chooses a large random number, N. If the generating point is (X,Y), then the computed value is N*(X,Y), where the integer multiplication is accomplished by adding the point to itself N times. The algorithm for adding points in the elliptic curve group is given in section C. The default value for the generating point (X,Y) is (24,13). Note that for any point (X,Y) in the elliptic curve group, both X and Y are elements of the underlying field, which in the default case specified below will be the Galois Field GF[2^185]. Perkins and Johnson Expires 27 August 2000 [Page 9] Internet Draft Registration Keys 27 February 2000 The foreign agent then inserts the extension in the Registration Request message, containing the values for the prime and generator, along with the computed value (F) from its own private random number N. The home agent will then choose its own private random number and creates its own computed value (H). The foreign agent will complete the key exchange by extracting the home agent's computed value H from the Diffie-Hellman Registration Key Reply extension in the registration request. The format of the subtype data contained in this extension is illustrated below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Y0 | First Coordinate of (V,W) = N*(X,Y) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Y0 Either 02 or 03, depending upon the least significant bit of the computed value N*(X,Y) First Coordinate of (V,W) = N*(X,Y) If the chosen random number is N, and the chosen generator is (X,Y), and if (V,W) = N*(X,Y), then this value is V. See section C for details about the computation of N*(X,Y), its compressed representation as illustrated above, and recovery of N*(X,Y) given this compressed representation. 5. Generalized MN-FA Key Reply Subtypes Key reply extensions in this document are subtypes of the Generalized MN-FA Key Reply extension [13]. The following subtypes are defined: 1. Registration Key Reply from Home Agent 2. Mobile Node Public Key Reply 3. Foreign Agent Public Key Reply 4. Diffie-Hellman Key Reply For each subtype, the format of the MN-FA Key Reply Subtype Data has to be separately defined according to the particular method required to set up the security association. In this section, the term "subtype data" refers to the MN-FA Key Reply Subtype Data of the Generalized MN-FA Key Reply extension. Perkins and Johnson Expires 27 August 2000 [Page 10] Internet Draft Registration Keys 27 February 2000 For the subtypes specified in this document, the Registration Key supplied in the subtype data comes as a result of a request which was sent using a subtype of the Generalized MN-FA Key Request Extension. The SPI to be used when employing the security association defined by the registration key is supplied in the original request. The keys obtained by the mobile node from the Key Reply extension subtypes defined in this document are expected to remain valid for as long as the mobile node continuously uses the same care-of address. The purpose of the registration key is to facilitate smooth handoffs, as well as secure subsequent registrations. Since it would typically take a huge number of encryptions with the same registration key for an attacker to gain enough information to compromise the key, such intended uses are unlikely to make the registration key insecure. Similarly, the mobile node is unlikely to use the same registration key for enough registrations to make the single smooth handover insecure. Thus, the registration key does not need to have any particular lifetime unless it is used for purposes of data hiding in addition to registration and smooth handover. 5.1. Registration Key Reply from Home Agent Subtype The home agent uses the Registration Key Reply from Home Agent extension in Registration Reply messages to securely deliver a registration key to the mobile node. For this extension, the subtype data is the registration key encoded using the SPI in the Registration Reply. The method used is specified in section 3.1, where the registration reply payload used in the encoding includes all the data up to and including the SPI field in the Generalized Key Reply extension for which this is a subtype. This key reply extension is authenticated along with the rest of the Registration Reply message, and thus no additional authenticator is included in the extension. The home agent SHOULD also include another key reply extension which delivers the same key to the mobile node's new foreign agent. 5.2. Mobile Node Public Key Reply Subtype When the mobile node sends a Mobile Node Public Key Request to its prospective foreign agent, the foreign agent can immediately select a registration key. The foreign agent encodes this registration key into the Mobile Node Public Key Reply extension to the Registration Request. The foreign agent also stores the key and the SPI from the Mobile Node Public Key Request for future reference as a potential security association with the mobile node. The home agent subsequently transcribes this extension without change into the Perkins and Johnson Expires 27 August 2000 [Page 11] Internet Draft Registration Keys 27 February 2000 Registration Reply message. Thus, the mobile node is protected against common man-in-the-middle attacks. The subtype data for this subtype is the Registration Key encoded by using the mobile node's public key. 5.3. Foreign Agent Public Key Reply Subtype This extension is sent in response to a Foreign Agent Public Key Request extension. The home agent selects a registration key and encodes it twice into two separate key reply extensions of the Registration Reply message. The Foreign Agent Public Key Reply extension contains the registration key encoded with the public key of the foreign agent. The foreign agent also stores the SPI from the registration key request extension sent by the mobile node, for future reference as a potential security association with the mobile node if the registration is successful. The subtype data for this extension is the Registration Key encoded by using the foreign agent's public key. 5.4. Diffie-Hellman Key Reply Subtype The Diffie-Hellman Registration Key Reply extension should be included in a Registration Request message sent by a home agent to the foreign agent, when the following conditions are met: - the mobile node has included a Registration Key Request extension in its registration request message, - the foreign agent has no public key or security association with the home agent or mobile node, and - the foreign agent has included one of the Diffie-Hellman Registration Key Request extensions in its Registration Request message to the home agent (see sections 4.5 and 4.6). The home agent uses the same reply extension subtype (namely, the Diffie-Hellman Key Reply subtype), in response to either of the Diffie-Hellman key exchange request messages. The subtype data for the Diffie-Hellman Registration Key Reply extension, is just the Computed Value resulting from the requested Diffie-Hellman computation. Perkins and Johnson Expires 27 August 2000 [Page 12] Internet Draft Registration Keys 27 February 2000 6. Mobile Node Key Requests If the mobile node receives an Agent Advertisement from a foreign agent with the `S' bit set, the mobile node may attempt a smooth handoff with its previous foreign agent, as well as asking its new foreign agent to aid in supplying a registration key for the new registration. The following code fragment illustrates a good algorithm for the mobile node to use during registration, to allow flexibility in the selection of the new registration key. Any particular mobile node may be configured to use one, none, or any subset of the key establishment procedures specified in this document. The Mobile Node executes the following algorithm upon new FA registration. This algorithm is intended to reduce complexity at the mobile node. But, the Home Agent MAY require that the mobile node use Public Key if required by the policy of the home domain administration, instead of relying on other means for generating keys. Perkins and Johnson Expires 27 August 2000 [Page 13] Internet Draft Registration Keys 27 February 2000 If (Challenge advertised) { Add challenge data to Registration Request /* If NewFA uses Elliptic, challenge is MD5 (N*(X,Y)) */ } If (NewFA advertises 'S') { if (have registration key with previous FA) { /* append Previous Foreign Agent Notification (PFAN) */ If (received opaque-data) { /* See [2] */ append opaque-data extension after PFAN; } } if (have security association with current FA) { ; /* Don't need to create a registration key */ } else if (HA expects Public Key) { Add public key extension; /* FA will choose key */ } else if (opaque-data || SA with NewFA) { create MN-FA extension; } else { Send Registration Key Extension; /* Let them do it */ } } In this way, the mobile node can get a registration key whenever one can be produced by any mechanism specified in this document. 7. Miscellaneous Home Agent Operations 7.1. Receiving Registration Key Requests When the home agent receives a Registration Request message, an extension requesting a registration key (Section 4) may be present in the message. Then the home agent is expected to provide a registration key to the mobile node and its foreign agent, as described in Section 3. When needed, the home agent employs a good algorithm for producing random keys [6] and encrypts the result separately for use by the foreign agent and by the mobile node. The chosen key is encoded under the mobility security association shared between the home agent and the mobile node as described in section 3.1. The regrep data used as part of the encoding includes all the preceding Registration Reply data up to and including the Length field of the Generalized MN-FA Reply extension for which the Registration Key Reply is the subtype. The encrypted key is the placed as the Subtype Data of the Registration Key Reply from Home Agent extension (section 5.1) in the Registration Reply message. Perkins and Johnson Expires 27 August 2000 [Page 14] Internet Draft Registration Keys 27 February 2000 The same key may also be encrypted under the mobility security association shared between the home agent and the foreign agent, and the encoding placed in a registration key reply extension in the Registration Reply message. When the home agent transmits the Registration Reply message containing reply extensions to the foreign agent, the message has the overall structure as follows: ------------------------------------------------------------- |IP|UDP| Reg-Reply| MN Key| FA Key| MN-HA Auth.| HA-FA Auth.| ------------------------------------------------------------- The HA-FA authentication extension is only included if the home agent and foreign agent share a mobility security association. If the home agent cannot satisfy a request to select a registration key, but the other Mobile IP registration requirements are fulfilled, it MAY still approve the registration reply. In this case, the home agent returns a Registration Reply message Code indicating success, but does not include any key reply extension. 7.2. Diffie-Hellman Considerations If the home agent receives one of the Diffie-Hellman key request extensions, (see sections 4.5 and 4.6), then it has to pick a good random number [6] and use it to complete the key exchange algorithm. Suppose the home agent picks the random number Z. Then the home agent applies the group operation Z times on the data received from the foreign agent, which amounts to either exponentiation to the Zth power, or else (in the elliptic case) to multiplication by Z of the incoming solution point. The result of this operation gives the registration key, which is then encoded in a Registration Key Reply from Home Agent extension and sent to the mobile node. In order to deliver the registration key to the foreign agent, the home agent takes the same number Z and applies it to the generator (or, in the elliptic case, the generating point). The result of that operation is placed in a Diffie-Hellman Key Reply extension and sent to the foreign agent so that the foreign agent can compute the registration key. When a home agent receives one of the Diffie-Hellman Key Request subtypes along with a Challenge extension, the Challenge Value MUST be checked against the computed value selected by the foreign agent. The rule by which the computed value is to be checked is described in section 8.2. Perkins and Johnson Expires 27 August 2000 [Page 15] Internet Draft Registration Keys 27 February 2000 7.3. Home Agent Supplying Registration Keys When the home agent receives a Registration Request message with registration key extensions, it usually performs one of two operations: - select and encode a registration key for both the mobile node and the foreign agent, or - transcribe the registration key already selected by the foreign agent into the appropriate extension to the Registration Reply message. Both operations ensure that the mobile node and home agent are dealing with the same foreign agent. Whenever the home agent inserts one of the following key reply extensions in the Registration Reply, 1. Registration Key Reply from Home Agent 2. Mobile Node Public Key Reply 3. Foreign Agent Public Key Reply each key reply extension MUST precede the MN-HA Authentication Extension. The Diffie-Hellman Key Reply, on the other hand, is consumed by the foreign agent, and SHOULD be located after the MN-HA Authentication Extension whenever the Challenge value is supplied with the Registration Request message. The Challenge value is typically sufficient to protect against man-in-the-middle attacks. When building the Registration Reply, the home agent should follow an algorithm such as the one illustrated below, which is useful for the registration key establishment methods currently specified. The underlying theme of the algorithm is that the home agent just does as it is told. Perkins and Johnson Expires 27 August 2000 [Page 16] Internet Draft Registration Keys 27 February 2000 if (Foreign Agent Reg. Key Request) { /* HA-FA assn_exists */ /* Pick a key, encode for FA */ /* append MN Key Reply to Registration Reply */ /* append FA key reply to Registration Reply */ } If (MN public key) { /* Transcribe the encoded key */ /* append MN Key Reply to Registration Reply */ } If (FA public key) { /* Pick a key, encode for FA */ /* append MN Key Reply to Registration Reply */ /* append FA Public Key Reply to Registration Reply */ } If (elliptic) { /* Pick multiplier `Z', do the D-H algorithm */ } else { /* do nothing */ } /* append mobile-home authentication extension at end */ /* Encode the key for the MN if necessary, use existing SPI */ /* New registration key will then be invoked by SPI from */ /* key request extension. */ 8. Miscellaneous Foreign Agent Operations This section details various operational considerations important for foreign agents wishing to support smooth handoff, including algorithms for establishment of registration keys. 8.1. Foreign Agent Handling Key Requests The foreign agent, when it receives a request from a mobile node for a registration key, is faced with a variety of possible actions. The action selected by the foreign agent depends on the resources it has available. The foreign agent typically attempts to reduce as much as possible the computational burden placed on the mobile node, but relies on the security association with sufficient cryptographic strength to encode the registration key. Furthermore, if the foreign agent performs the key selection, it still supplies the encoded key in an extension to the Registration Request message, so that the home agent will authenticate its choice of registration key to the mobile node. This strategy reduces the opportunity for interlopers to mount man-in-the-middle attacks. Perkins and Johnson Expires 27 August 2000 [Page 17] Internet Draft Registration Keys 27 February 2000 The following code fragment, executed when the foreign agent receives a key request of some variety, exhibits an algorithm which may be useful for implementors of foreign agents. The algorithm is supposed to be used when a foreign agent gets a Registration Request with one of the key request extensions included. The foreign agent uses the elliptic curve Diffie-Hellman key exchange as a last resort, with implicit well-known parameters (X-coordinate, Y-coordinate, Extension-Field), picking multiplier `N'. If (opaque-data) { /* extract key/replay protection */ /* check against replays */ /* drop registration unless opaque-data passes check */ } if (Previous Foreign Agent Notification (PFAN)) { /* Formulate Binding Update */ /* Send with Smooth Handoff Authentication Extension */ } If (MN-FA authentication extension) { /* Verify before proceeding */ } If (Registration Key Extension) { /* Set up registration key */ if (have mobile node's public key) { /* pick a good key */ /* append MN Public Key Reply to Reg. Request */ } If (opaque-data valid) { /* Use old extension */ } if (have security association with HA) { /* Append FA key request to Registration Request */ } If (FA public key) { /* Send it; HA will pick key */ } else { /* pick elliptic point multiplier `N' */ /* append result to the Registration Key Request */ } } Perkins and Johnson Expires 27 August 2000 [Page 18] Internet Draft Registration Keys 27 February 2000 8.2. Advertising Digestified Diffie-Hellman Computations When a foreign agent advertises the `S' bit, it is expected to support Diffie-Hellman key exchange with the home agent for those cases when the mobile node asks for a registration key, but no other means are available for producing registration keys. In order to protect against man-in-the-middle attacks, the home agent and the mobile node need some way to make sure that they are dealing with the same foreign agent. This can be accomplished by digestifying the Diffie-Hellman computed values, and advertising the digest as a Challenge Value for the mobile node. The digest is produced by using MD5 on the computed value, with no other data prepended or appended. In order to reduce bandwidth requirements for this advertisement, the foreign agent MAY truncate the MD5 digest to as few as the initial 4 bytes. Since all of the bits of the MD5 digest are considered equally random, applying further operations (such as XOR) might even reduce the resulting cryptographic strength. 9. Security Considerations Whenever a key is exchanged by use of the Diffie-Hellman algorithm, the process is susceptible to the "man-in-the-middle" attack, as detailed in Appendix A. This attack is not known to produce further difficulty, and susceptibility is already inherent in the operation of the base Mobile IP specification [11]. Attention to this detail is warranted during any future changes to the Route Optimization protocol. Ways to reduce the risk should be incorporated into future revisions of this document. Already, the risk of such an attack against the registration key distribution mechanisms specified in this document are greatly reduced by the authentication of the Registration Reply by the home agent. The calculation of the authentication data described in Section 3.1 is specified to be the same as in the base Mobile IP document for ease of implementation. There is a better method available (HMAC), specified in RFC 2104 [8]. If the base Mobile IP specification is updated to use HMAC, then this route optimization specification should also be updated similarly. Registration keys should typically NOT be used as master keys for producing other derived keys, because of the man-in-the-middle attack associated with unidentifiable foreign agents. Perkins and Johnson Expires 27 August 2000 [Page 19] Internet Draft Registration Keys 27 February 2000 References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [2] P. Calhoun, Haseeb Akhtar, Emad Qaddoura, and N. Asokan. Minimal Latency Secure Hand-off. draft-calhoun-mobileip-min-lat-handoff-01.txt, February 2000. (work in progress). [3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent Challenge/Response Extension. draft-ietf-mobileip-challenge-08.txt, January 2000. (work in progress). [4] CDPD consortium. Cellular Digital Packet Data Specification. P.O. Box 809320, Chicago, Illinois, July 1993. [5] W. Diffie and M. Hellman. New Directions in Cryptography. IEEE Transactions on Information Theory, 22:644--654, November 1976. [6] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness Recommendations for Security. Request for Comments (Informational) 1750, Internet Engineering Task Force, December 1994. [7] N. Koblitz. Elliptic Curve Cryptosystems. Mathematics of Computation, 48(177):203--209, 1987. [8] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments (Informational) 2104, Internet Engineering Task Force, February 1997. [9] V. S. Miller. Use of Elliptic Curves in Cryptography. In Advances in Cryptology -- CRYPTO '85 Proceedings, pages 417--426, Berlin, 1986. Springer-Verlag. [10] H. Orman. The OAKLEY Key Determination Protocol. Request for Comments (Informational) 2412, Internet Engineering Task Force, November 1998. [11] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 2002, Internet Engineering Task Force, October 1996. Perkins and Johnson Expires 27 August 2000 [Page 20] Internet Draft Registration Keys 27 February 2000 [12] C. Perkins and D. Johnson. Route Optimization in Mobile IP. Internet Draft, Internet Engineering Task Force, February 1999. Work in progress. [13] Charles E. Perkins and Pat R. Calhoun. Generalized Key Distribution Extensions for Mobile IP. draft-ietf-mobileip-gen-key-00.txt, February 2000. (work in progress). [14] Bruce Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C. John Wiley, New York, NY, USA, 1994. [15] Richard Schroeppel, Hilarie Orman, and Sean OMalley. Fast Key Exchange with Elliptic Curve Systems. In Advances in Cryptology -- CRYPTO '95 Proceedings. Springer-Verlag, 1995. A. Using Diffie-Hellman with the Foreign Agent Diffie-Hellman public key cryptosystems allows two parties to establish a shared secret key, such that the shared secret key cannot be determined by other parties overhearing the messages exchanged during the algorithm. It is used in other well-known protocols that require a key exchange, such as the Cellular Digital Packet Data (CDPD) system [4]. These systems work because they are employed where the ``discrete logarithm'' problem is currently intractable. The discrete logarithm problem can be stated as follows: given g and g*N (where `*' means repeating the group operation between g and itself N times), find the value of N. The two group operations of most interest are: 1. multiplication, in the modular field of integers mod p 2. addition, in the group of solution points to particular elliptic curves For a multiplicative group, repeating the group operation by an element on itself N times amounts to (integer) exponentiation by N. For an additive group, repeating the group operation N times amounts to an integer multiplication operation on that group element. In the elliptic curve group, the elements are not integers, but instead ordered pairs (X,Y) which represent solutions to the elliptic curve. The first groups have the advantage of being easy to understand. The second groups, proposed later than the first, have the advantage of being much faster computationally. Perkins and Johnson Expires 27 August 2000 [Page 21] Internet Draft Registration Keys 27 February 2000 For the purposes of the explanation in this appendix, suppose that the first party in the key exchange is the foreign agent, and the second party is the home agent. This would be the situation whenever these key exchanges are used to generate Registration Keys using the methods specified in this document. In both cases, the result depends on the fact that the group operation in the relevant groups is commutative, so that M*(N*g) == N*(M*g). When the group operation is multiplication, this is more conventionally written as (g^M)^N = (g^N)^M. This technique is known to suffer from a man-in-the-middle attack. In other words, a malicious agent could pretend to the foreign agent to be the home agent, and pretend to the home agent to be the foreign agent, and participate as an unwanted third member in the key exchange. Armed with knowledge of the registration key, the malicious agent could at a later time disrupt the smooth handoff, or initiate the handoff prematurely. The man-in-the-middle attack is no worse than a malicious agent pretending to be a foreign agent in any other circumstance; that is, it is no worse than already exists with the base Mobile IP specification [11]. In the key distribution mechanisms specified in this document, the man-in-the-middle attack is prevented in most circumstances because each registration key is effectively authenticated by the home agent. Moreover, the mobile node and/or the foreign agent are presumably in direct contact, so that such an attack is detectable if either of the nodes notices the reception of duplicate packets, and corrective action taken. Establishing a registration key using Diffie-Hellman is computationally more expensive than most methods described in Section 3. The use of Diffie-Hellman described here, though, is designed to allow the Diffie-Hellman computations to be overlapped with other activities. The foreign agent may choose (or be manually configured with) the prime and generator values (or, the generating point and Galois field values) at any time, or may use the same values for a number of registrations. The home agent may also choose its private random number and calculate its computed value at any time. For example, after completing one registration, the foreign agent may choose the private random number for its next registration and begin the computation of its new computed value based on this random number, such that it has completed this computation before it is needed in a registration from another mobile node. Even more simply, the foreign agent may use the same private random number and computed value for any number of registrations. Perkins and Johnson Expires 27 August 2000 [Page 22] Internet Draft Registration Keys 27 February 2000 B. Diffie-Hellman Key Exchange in the Field of Integers mod p Briefly, the Diffie-Hellman algorithm involves the use of two large public numbers, a prime number (p) and a generator (g). The prime number and the generator must be known by both parties involved in the algorithm, but do not have to be secret; these values may be the same or different for each execution of the algorithm and are not used once the algorithm completes. Each party chooses a private random number, produces a computed value based on this random number, the prime and the generator, and sends the computed value in a registration message extension to the other party. The foreign agent creates the computed value f = g^N mod p, where N is its private random number, p is the prime which is sent as part of the transaction, and g is the generator. The home agent then creates another computed value h = g^y mod p, where M is its own private random number, and p and g are the same as for the foreign agent. Each party then computes the (same) shared secret key using its own private random number, the computed value received from the other party, and the prime and generator values. Since f^M = (g^N)^M = C = (g^M)^N = f^N, the foreign agent and the home agent can compute a shared value C that is not detectable by other network nodes. The shared secret is the number C mod p, where p is the same prime number as before. Knowing the computed values mod p does not enable passive listeners to determine the private values, so the algorithm allows the two parties to agree on an otherwise undetectable secret. If Diffie-Hellman were substantially less computationally expensive, it could likely serve the needs of many mobile nodes. But, the algorithm itself uses exponentiations or strange additions involving numbers with hundreds of digits. That may take a long time for some mobile nodes to do, time which would come at the expense of interactivity or convenient operation of user application programs. For this reason, Diffie-Hellman is considered the least desirable alternative for establishing registration keys. Since it requires no other configuration, it is nevertheless required in all implementations of foreign agents that advertise support for smooth handoffs. C. Diffie-Hellman Key Exchange in Elliptic Curve Groups In order to multiply a generating point (X,Y) by a large number N, it is necessary to add the point to itself N times. However, addition in elliptic curve groups is not simple componentwise addition; (X,Y) + (A,B) is NOT EQUAL to (X+A,Y+B). Instead, in order for the group addition to yield only points that are solutions to the elliptic curve, a special formula for group addition must be used. Perkins and Johnson Expires 27 August 2000 [Page 23] Internet Draft Registration Keys 27 February 2000 Suppose, then, that one is given two points (X1, Y1) and (X2, Y2) in the elliptic curve group of all solutions to the equation y^2 + x*y = x^3 + a*x^2 + b. The function Plus (X1, Y1, X2, Y2) is defined as follows. - if X1 = X2 and Y1 = Y2, then Plus (X1, Y1, X2, Y2) = Double (X1, Y1), where Double (X, Y) is as defined below. - otherwise, if X1 = X2 but Y1 != Y2, then Plus (X1, Y1, X2, Y2) = (0,0) - otherwise, Plus (X1, Y1, X2, Y2) = (V, W), where i. V = L^2 + L + X1 + X2 + a ii. W = L*(X1 + V) + V + Y1, and iii. L = (Y1 + Y2)/(X1 + X2) The function Double (X, Y) is defined as follows: - if X = 0, then Double (X, Y) = (0,0) - otherwise, Double (X, Y) = (V, W), where i. V = L^2 + L + a, ii. W = X^2 + (L + 1) * X, and iii. L = X + Y/X The above formulas are given in a publication by Richard Schroeppel, Hilarie Orman, and Sean O'Malley [15]. Note that there are many computational shortcuts available. The referenced publication is a good start; one should also consult [14]. The following elliptic curve characteristics are used by default, and until a method is specified for offering non-default values. This information is taken from appendix E.4 of RFC 2412 [10], and is reproduced here only for completeness. The elliptic curve is based on the Galois field GF[2^185] with 2^185 field elements. The irreducible polynomial for the field is u^185 + u^69 + 1. The equation for the elliptic curve is Y^2 + X Y = X^3 + A X + B. Perkins and Johnson Expires 27 August 2000 [Page 24] Internet Draft Registration Keys 27 February 2000 X, Y, A, B are elements of the field. For the curve specified, A = 0 and B = u^12 + u^11 + u^10 + u^9 + u^7 + u^6 + u^5 + u^3 + 1. B is represented in binary as the bit string 1111011101001; in decimal this is 7913, and in hex 1EE9. The generator is a point (X,Y) on the curve (satisfying the curve equation, mod 2 and modulo the field polynomial); X = u^4 + u^3 and Y = u^3 + u^2 + 1. For this extension, the subtype data is a standard representation using a point compression technique (not defined in RFC 2412) for the computed value of (V,W) = N*(X,Y), specified as follows. Let (V,W) be a point of the elliptic curve group defined as above. Let OCTETS be the representation of V as bits right-justified into an integer number of octets. For instance, if V = 24(decimal), OCTETS = 18 shown as two hexadecimal digits. If V = 317(decimal), OCTETS = 013D shown as four hexadecimal digits. The number of hexadecimal digits needed to represent OCTETS will always be an even number since every byte of the representation takes two hexadecimal digits to represent. Then, define W0 to be zero (0) if V == 0; otherwise define W0 to be the rightmost bit of the field element W/V. If W0 == 0, then the subtype data will be 02 || OCTETS; otherwise the subtype data will be 03 || OCTETS. Here, "||" means concatenation. To recover (V,W) from this standard representation, proceed as follows. If V == 0, then W = B^(2^184), where B = 7913 from the defining elliptic curve. W is the square root of B. Otherwise, compute the field element W = V + a + B/(V^2) = V + 7913/(V^2). Find Z such that Z^2 + Z = W. Let Z0 be the rightmost bit of Z. If the received computed value has prefix 02, let W0 be 0; otherwise if the received computed value has prefix 02, let W0 be 1. If W0 != Z0, then let Z = Z + 1. Then, W = Z*V. Perkins and Johnson Expires 27 August 2000 [Page 25] Internet Draft Registration Keys 27 February 2000 Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola M/S M8-540 6000 Connection Drive 1501 West Shure Drive Irving, TX 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com Fax : +1 972-894-5349 Questions about this memo can also be directed to the authors: Charles E. Perkins David B. Johnson Communications Systems Lab Computer Science Department Nokia Research Center 5000 Forbes Avenue 313 Fairchild Drive Pittsburgh, PA 15213-3891 Mountain View, California 94043 Carnegie Mellon University USA USA Phone: +1-650 625-2986 Phone: +1-412-268-7399 EMail: charliep@iprg.nokia.com E-mail: dbj@cs.cmu.edu Fax: +1 650 625-2502 Fax: +1-412-268-5576 Perkins and Johnson Expires 27 August 2000 [Page 26]