Mobile IP Working Group Charles Perkins INTERNET DRAFT Sun Microsystems 20 November 1997 David B. Johnson Carnegie Mellon University Registration Keys for Route Optimization draft-ietf-mobileip-regkey-00.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@SmallWorks.COM mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Route optimization [6] defines extensions to Mobile IP [7] 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 20 May 1998 [Page i]
Internet Draft Registration Keys 20 November 1997 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 . . . . . . . . . . . . . . . . . 3 3.2. Using the Foreign Agent as a KDC . . . . . . . . . . . . 4 3.3. Using Diffie-Hellman with the Foreign Agent . . . . . . . 5 4. Messages Requesting A Registration Key 7 4.1. Foreign Agent Key Request extension . . . . . . . . . . . 7 4.2. Mobile Node Public Key extension . . . . . . . . . . . . 8 4.3. Foreign Agent Public Key extension . . . . . . . . . . . 8 4.4. Registration Key Request Extension . . . . . . . . . . . 9 5. Extensions to Supply A Registration Key 10 5.1. Home-Mobile Key Reply Extension . . . . . . . . . . . . . 10 5.2. Foreign Agent Key Reply Extension . . . . . . . . . . . . 11 5.3. Mobile Node Public Key Reply Extension . . . . . . . . . 12 5.4. Foreign Agent Public Key Reply Extension . . . . . . . . 13 5.5. Diffie-Hellman Key Reply Extension . . . . . . . . . . . 14 5.6. SPI Extension . . . . . . . . . . . . . . . . . . . . . . 15 6. Mobile Node Key Requests 15 7. Miscellaneous Home Agent Operations 16 7.1. Receiving Registration Key Requests . . . . . . . . . . . 16 7.2. Home Agent Supplying Registration Keys . . . . . . . . . 17 8. Miscellaneous Foreign Agent Operations 17 8.1. Foreign Agent Handling Key Requests . . . . . . . . . . . 17 9. Security Considerations 18 10. Summary 19 References 19 Chairs' Addresses 20 Perkins and Johnson Expires 20 May 1998 [Page ii]
Internet Draft Registration Keys 20 November 1997 1. Introduction All Route Optimization messages that change the routing of IP datagrams to the mobile node are authenticated using the same mechanisms used in the base Mobile IP protocol. The authentication relies on a mobility security association established in advance between the sender and receiver of such messages. However, when a mobile node registers with a foreign agent, typically it does not share a security association with the foreign agent. Nevertheless, in order for the foreign agent to process future binding updates that it may receive from the mobile node, it needs to have such a securiyt assocation. Binding updates provide a mechanism for accomplishing smooth handoffs between a previous foreign agent to a new foreign agent. Such smooth handoffs rely on the Previous Foreign Agent Notification extension [6], which requires the transmission of an authentic binding update to the previous foreign agent created by the mobile node after it moves. 2. Terminology This document uses the following terminology, in addition to that used to describe the base Mobile IP protocol: Binding cache A cache of mobility bindings of mobile nodes, maintained by a node for use in tunneling datagrams to those mobile nodes. Binding update A message indicating a mobile node's current mobility binding, and in particular its care-of address. 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. 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 Perkins and Johnson Expires 20 May 1998 [Page 1]
Internet Draft Registration Keys 20 November 1997 lifetime is still valid, at some time after the registration was approved by the home agent. Security Parameters Index (SPI) An index identifying a security context between a pair of nodes among the contexts available in the Mobility Security Association. SPI values 0 through 255 are reserved and MUST NOT be used in any Mobility Security Association. Triangle Routing A situation in which a Correspondent Host's packets to a Mobile Host follow a path which is longer than the optimal path because the packets must be forwarded to the Mobile Host via a Home Agent. 3. Establishing Registration Keys Foreign agents are expected to be 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. Note that the mobile node can only rarely verify the identity of the foreign agent in any absolute terms. It can only act 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 Perkins and Johnson Expires 20 May 1998 [Page 2]
Internet Draft Registration Keys 20 November 1997 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 foreign agent has a public key, it can again use the home agent to supply a registration key. 4. If the mobile node includes its public key in its Registration Request, the foreign agent can choose the new registration key. 5. The mobile node and its foreign agent can execute a Diffie-Hellman key exchange protocol [2] as part of the registration protocol. Once the registration key is established, the method for performing smooth handoff seems natural. The following sections give a brief overview of the above listed 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 it has no effect on the status code 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. 3.1. The Home Agent as a KDC Crucial to methods (2) and (3) 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 sends it back 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. Perkins and Johnson Expires 20 May 1998 [Page 3]
Internet Draft Registration Keys 20 November 1997 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. 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) (where regrep is the Registration Reply message payload, and XOR is exclusive-or) can be included within the appropriate Registration Reply extension and encodes the key in a way which allows recovery only by the recipient. It is secure against replay because of the identification field within the Registration Reply message. The recipient recovers the key by computing expr2== MD5(secret | regrep | secret) which then yields key = expr1XOR 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. If no such mobility security association exists, 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. Just 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 possible 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. 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 [8]) in its Registration Request to the foreign agent, using a mobile node public key extension. The foreign agent chooses the new registration key and returns a copy of it encrypted with the Perkins and Johnson Expires 20 May 1998 [Page 4]
Internet Draft Registration Keys 20 November 1997 mobile node's public key, using a foreign-mobile registration key reply extension. 3.3. Using Diffie-Hellman with the Foreign Agent The Diffie-Hellman key-exchange algorithm [2] can be used. Diffie-Hellman is a public key cryptosystem that 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 already used, for example, in other protocols that require a key exchange, such as in the Cellular Digital Packet Data (CDPD) system [1]. 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 mobile node, and pretend to the mobile node 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 [7]. In route optimization, the man-in-the-middle attack is prevented in most circumstances because each registration key produced by the techniques in this chapter is effectively authenticated by the home agent. If Diffie-Hellman were not computationally expensive, it could likely serve the needs of many mobile nodes. Diffie-Hellman results are authenticated by the home agent to frustrate man-in-the-middle attacks. 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. But, the algorithm itself uses exponentiations 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. 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 Perkins and Johnson Expires 20 May 1998 [Page 5]
Internet Draft Registration Keys 20 November 1997 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 message to the other party. The computed value is the number g**x mod p, where x is the private random number, p is the prime which is sent as part of the transaction, and g is the generator. 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. The shared secret is the number c**y mod p, where c is the computed value which uses the other party's private number, p is the same as before, and y is the receiver's private number. Since (g**x)**y == (g**y)**x, and since knowing the computed values mod p does not enable passive listeners to determine the private values, the algorithm allows the two parties to agree on an otherwise undetectable secret. To use this algorithm during registration with a foreign agent, the mobile node includes a Registration Key Request extension in its Registration Request message, containing its nonzero values for the prime and generator, along with the computed value from its own private random number. If no other strategy is available, the foreign agent then chooses its own private random number and includes a Diffie-Hellman Registration Key Reply extension in its Registration Reply message to the mobile node; the extension includes the foreign agent's own computed value based on its chosen random number and the supplied prime and generator values from the mobile node. The mobile node and foreign agent each independently form the (same) shared secret key from their own chosen random number, the computed value supplied by the other party, and the prime and generator values. 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 mobile node may choose (or be manually configured with) the prime and generator values at any time, or may use the same two values for a number of registrations. The mobile node may also choose its private random number and calculate its computed value at any time. For example, after completing one registration, the mobile node 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 its next registration. Even more simply, the mobile node may use the same private random number and computed value for any number of registrations. The foreign agent may choose its private random number and begin computation of its computed value based on this number as soon as it receives the mobile node's Registration Request Perkins and Johnson Expires 20 May 1998 [Page 6]
Internet Draft Registration Keys 20 November 1997 message, and need only complete this computation before it sends the matching Registration Reply message for the mobile node's registration. This could be extended to support other similar key exchange algorithms, either by adding a new request and reply extension for each, or by adding a field in the extensions to indicate which algorithm is to be used. Diffie-Hellman currently seems the only obvious choice, though; an implementation is available in the free RSAREF toolkit from RSA Laboratories [5]. 4. Messages Requesting A Registration Key The following extensions may be used by mobile nodes or foreign agents to request the establishment of a registration key. See sections 6,7.2, and 8 for appropriate algorithms which allow each node to tailor the use of these extensions to most closely fit its configured requirements. 113 Foreign Agent Key Request Extension 114 Mobile Node Public Key Extension 115 Foreign Agent Public Key Extension 116 Diffie-Hellman Key Request Extension 4.1. Foreign Agent Key Request extension 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 append the Foreign Agent Key Request extension to the Registration Request after the mobile-home authentication extension. The home agent will use the SPI specified in the key request extension to encode the registration key in the subsequent Registration Reply message. The format of the Foreign Agent Key Request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI ..... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 113 Length 4 Perkins and Johnson Expires 20 May 1998 [Page 7]
Internet Draft Registration Keys 20 November 1997 SPI Security Parameters Index (4 bytes). An opaque identifier. 4.2. Mobile Node Public Key extension 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 it is broadcast to all entities with access to the network medium used by the mobile node. If using the public key, the foreign agent should still include the selected key in the Registration Request before it goes to the home agent. Then, the home agent can authenticate the selected encoded registration key as part of the Registration Reply message. The format of the mobile node public key extension is as 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |MN Public Key .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Mobile Node Public Key, continued ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 114 Length The length (typically larger than 255) of the mobile node's public key 4.3. Foreign Agent Public Key extension The format of the foreign agent public key extension is as 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (continued) |FA Public Key .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Foreign Agent Public Key (continued) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the foreign agent has a public key, it can ask the home agent to choose a registration key, and to use the foreign agent's public key Perkins and Johnson Expires 20 May 1998 [Page 8]
Internet Draft Registration Keys 20 November 1997 to encode the chosen registration key. Then, the home agent can authenticate the selected encoded registration key as part of the Registration Reply message. Type 115 Length 4 plus the length (typically larger than 255) of the foreign agent's public key SPI Security Parameters Index (4 bytes). An opaque identifier. Foreign Agent's Public Key The SPI is provided for the home agent to transcribe into the eventual Foreign Agent Public Key Reply extension to the Registration Reply message. 4.4. Registration Key Request Extension The Registration Key Request extension, illustrated below, may be included in a Registration Request message sent to a foreign agent. If the length of the parameters in the key request extension are all zero, then the mobile node is asking the foreign agent to supply a key by any means it has available except for Diffie-Hellman. If the lengths are nonzero, then the mobile node is enabling the foreign agent to also perform the Diffie-Hellman key exchange algorithm (as described in Section 3.3) if the other possible key establishment methods are not available. The foreign agent should then select a good pseudo-random registration key, and include a Diffie-Hellman Registration Key Reply extension, in the Registration Request message sent to the home agent to complete the key exchange. The home agent will also include same extension in the Registration Reply sent to the mobile node, and then it will be authenticated as part of the reply message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prime ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Prime (continued) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Generator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Computed Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Perkins and Johnson Expires 20 May 1998 [Page 9]
Internet Draft Registration Keys 20 November 1997 Type 116 Length 3 times the length (in bytes) of each of prime, generator, and computed value. The values prime, generator, and computed value must all be the same length, which must be a multiple of 8 bits. Prime One of the two public numbers involved in the Diffie-Hellman key exchange algorithm. The prime should be a large prime number. Generator One of the two public numbers 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 of p. Computed Value The public computed value from the mobile node for this Diffie-Hellman exchange. The mobile node chooses a large random number, x. If g is the value of the generator and p is the value of the prime, the computed value in the extension is g**x mod p. 5. Extensions to Supply A Registration Key The following extensions are used to supply a registration key to a requesting entity, either a foreign agent or a mobile node, and are the counterparts to corresponding extensions used to request registration keys that are described in the last section. 120 Home-Mobile Key Reply Extension 121 Foreign Agent Key Reply Extension 122 Mobile Node Public Key Reply Extension 123 Foreign Agent Public Key Reply Extension 124 Diffie-Hellman Key Reply Extension 125 SPI Extension 5.1. Home-Mobile Key Reply Extension The home-mobile key reply extension may be used in Registration Reply messages to send a registration key from the mobile node's home agent to the mobile node. When used, the home agent is required to also include a key reply extension in the Registration Reply message, which gives a copy of the same key to the mobile node's new foreign agent. The home-mobile key reply extension, illustrated below, is Perkins and Johnson Expires 20 May 1998 [Page 10]
Internet Draft Registration Keys 20 November 1997 authenticated along with the rest of the Registration Reply message, and thus no additional authenticator is included in the extension. The SPI used to encode the registration key may be different than the SPI used to authenticate the Registration Reply message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (continued) | MN Enc. Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Encrypted Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 120 Length 4 plus the length of the encrypted key for the mobile node SPI Security Parameters Index (4 bytes). An opaque identifier. Mobile Node Encrypted Key (variable length) The registration key, chosen by the home agent, encrypted under the mobility security association between the home agent and the mobile node. The same key must be sent, encrypted for the foreign agent in a foreign agent registration key extension in this Registration Reply message. 5.2. Foreign Agent Key Reply Extension 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (continued) | FA Enc. Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Foreign Agent Encrypted Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The home-foreign registration key reply extension may be used in Registration Reply messages to send a registration key from the mobile node's home agent to the mobile node's new foreign agent. When used, the home agent is required to also include a home-mobile Perkins and Johnson Expires 20 May 1998 [Page 11]
Internet Draft Registration Keys 20 November 1997 registration key reply extension in the Registration Reply message, giving a copy of the same key to the mobile node. Type 121 Length 4 plus the length of the encrypted foreign agent's key plus the length of the authenticator SPI Security Parameters Index (4 bytes). An opaque identifier. Foreign Agent Encrypted Key (variable length) The registration key, chosen by the home agent, encrypted under the mobility security association between the home agent and the foreign agent. The key which is sent in this extension must also be sent by the home agent to the mobile node, encoded for the mobile node in a mobile node registration key extension in the same Registration Reply message. Authentication of the key is performed by use of data within a HA-FA Authentication extension to the Registration Reply message which is required when the Foreign Agent Key Reply extension is used. Replay protection is accomplished using the identification field in the Registration Request message, which is also used by the foreign agent to identify the pending registration data. 5.3. Mobile Node Public Key Reply Extension The Mobile Node Public Key Reply message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (continued) | MN Enc. Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Mobile Node's Encoded Key (continued) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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, along with an SPI for future reference. The home agent subsequently transcribes the extension without change into the Perkins and Johnson Expires 20 May 1998 [Page 12]
Internet Draft Registration Keys 20 November 1997 Registration Reply message. This procedure allows the mobile node to be protected against common man-in-the-middle attacks. Type 122 Length The length (in bytes) of the computed value. SPI Security Parameters Index (4 bytes). An opaque identifier. Mobile Node's Encoded Key The foreign agent chooses a suitable key, possibly a pseudo-random number, and encodes it using the mobile node's public key. 5.4. Foreign Agent Public Key Reply Extension In response to a foreign agent public key request extension, the home agent will select a registration key and encode 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 Public Key Reply message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (continued) | FA Enc. Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...Foreign Agent's Encoded Key (continued) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 123 Length 4 plus the length (in bytes) of the Foreign Agent's Encoded Key. SPI Security Parameters Index (4 bytes). An opaque identifier. Foreign Agent's Encoded Key The foreign agent chooses a suitable pseudo-random number, and encodes it using the mobile node's public key. Perkins and Johnson Expires 20 May 1998 [Page 13]
Internet Draft Registration Keys 20 November 1997 The SPI, provided by the foreign agent for transcribing into this extension, is ultimately targeted for use by the mobile node. 5.5. Diffie-Hellman Key Reply Extension The Diffie-Hellman Registration Key Reply extension, illustrated below, should be included in a Registration Request message sent by a foreign agent to the home agent, when the following conditions are met: - mobile node has included a Registration Key Request extension with nonzero prime and generator in its Registration Request message to the foreign agent, and - the foreign agent has no public key or security association with the home agent or mobile node. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (continued) |Computed Val.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Computed Value (continued) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 124 Length 4 plus the length (in bytes) of the computed value. SPI Security Parameters Index (4 bytes). An opaque identifier. Computed Value The foreign agent chooses a large random number, y. If g is the value of the generator and p is the value of the prime, the computed value in the extension is gymod p. The values of the generator and prime, if nonzero, are taken from the Registration Key Request extension from the mobile node's Registration Request message. The foreign agent supplies a new SPI along with the new registration key, so that the new key will be useful in the same way as registration keys created by any other method. Perkins and Johnson Expires 20 May 1998 [Page 14]
Internet Draft Registration Keys 20 November 1997 5.6. SPI Extension The SPI Extension is included in Registration Reply messages when needed to specify the SPI to be associated with the registration key. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI ..... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 125 Length 4 plus the length (in bytes) of the computed value. SPI Security Parameters Index (4 bytes). An opaque identifier. 6. Mobile Node Key Requests If the mobile node detects that its new foreign agent supports smooth handoffs, it may initiate that process 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 the maximum 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 made available as part of the Route Optimization protocol. if (got 'S' bit from advertisement) { if (have registration key with previous FA) { ; /* append Previous Foreign Agent Notification */ } /* Set up registration key */ if (have security association with current FA) { ; /* Don't need to create a registration key */ } else if (have a public key) { ; /* append MN Public Key request */ } else if (want D-H exchange) { /* compute a value for prime p and generator g */ /* use it and append MN Key request */ } Perkins and Johnson Expires 20 May 1998 [Page 15]
Internet Draft Registration Keys 20 November 1997 else /* append MN key request with null computed value, etc */ } In this way, the mobile node can get a registration key whenever one is available 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, requesting the home agent to provide a registration key to the mobile node and its foreign agent, as described in Section 3. In that event, the home agent employs a good algorithm for producing random keys [3] and encrypts the result separately for use by the foreign agent and by the mobile node. The chosen key is encrypted under the mobility security association shared between the home agent and the mobile node, and the encrypted key is placed in a home-mobile registration key reply extension (Section 5.1) in the Registration Reply message. The same key also is encrypted under the mobility security association shared between the home agent and the foreign agent, and the encrypted key is placed in a home-foreign registration key reply extension (Section 5.2) 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| HA-MH Auth.| HA-FA Auth.| ------------------------------------------------------------- The mobile node gets the registration key, typically encoded using an algorithm such as that described in Section 3.1. The encoding of the foreign agent's copy of the key depends on the particular key request made by the foreign agent, and may depend upon the SPI specified along with the encoded key. 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, it MAY still satisfy the registration attempt. In this case, the home agent returns a Registration Reply message indicating success, but does not include any key reply extension. Perkins and Johnson Expires 20 May 1998 [Page 16]
Internet Draft Registration Keys 20 November 1997 7.2. 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. When building the Registration Reply, the home agent should follow an algorithm such as the one illustrated below, to be as useful as possible for the range of registration key establishment scenarios that are possible given the current route optimization protocol. /* Set up registration key */ if (Foreign Agent Key Request) { /* then have security assn. */ /* append MN Key Reply to Registration Reply */ /* append FA key reply to Registration Reply */ } else if ((have foreign agent public key) || (have FA Public Key Reply)) { /* append MN Key Reply to Registration Reply */ /* append FA Public Key Reply to Registration Reply */ } else { /* do nothing */ } /* append mobile-home authentication extension at end */ 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 Perkins and Johnson Expires 20 May 1998 [Page 17]
Internet Draft Registration Keys 20 November 1997 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 the greatest 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 process of registration will also have the effect of authenticating its choice of registration key to the mobile node. This strategy reduces the opportunity for interlopers to mount man-in-the-middle attacks. 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. if (Previous Foreign Agent Notification) { /* build the Binding Update and authentication extension */ } /* Set up registration key */ if (have security association with HA) { /* Append FA key request to Registration Request */ } else if (have a public key) { /* append FA Public Key request to Registration Request */ } else if (have mobile node's public key) { /* pick a good key */ /* append FA Public Key Reply to Registration Request */ } else if (want D-H exchange) { /* start the computation */ /* append the result to the Registration Key Request */ else { /* do nothing */ } 9. Security Considerations Whenever the foreign agent is involved with the production of a registration key by use of the Diffie-Hellman algorithm, the process is susceptible to the "man-in-the-middle" attack, as detailed in Section 3.3. This attack is not known to produce further difficulty, and susceptibility is already inherent in the operation of the base Mobile IP specification [7]. Attention to this detail is warranted Perkins and Johnson Expires 20 May 1998 [Page 18]
Internet Draft Registration Keys 20 November 1997 during any future changes to the Route Optimization protocol, and ways to reduce the risk of direct interest for inclusion into future revisions of this document. 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 [4]. 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. 10. Summary In this document, we have presented the methods for establishing registration keys for use by mobile nodes and foreign agents supporting smooth handoffs. The ways provided for the mobile node and foreign agent to obtain a registration key are as follows: - Use the mobility security association they share if it exists - Use the mobile node's public key if it exists - Use the foreign agent's public key, if it exists, to enable the home agent to create public keys for both entities, or - Use the security association between the foreign agent and home agent, if it exists, to enable the home agent to create the registration keys for both entities, or - Use the Diffie-Hellman key exchange algorithm. References [1] CDPD consortium. Cellular Digital Packet Data Specification. P.O. Box 809320, Chicago, Illinois, July 1993. [2] W. Diffie and M. Hellman. New Directions in Cryptography. IEEE Transactions on Information Theory, 22:644--654, November 1976. [3] Donald E. Eastlake, Stephen D. Crocker, and Jeffrey I. Schiller. Randomness Recommendations for Security. RFC 1750, December 1994. Perkins and Johnson Expires 20 May 1998 [Page 19]
Internet Draft Registration Keys 20 November 1997 [4] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing for Message Authentication. RFC 2104, February 1997. [5] RSA Laboratories. Rsaref: A cryptographic toolkit, version 2.0, 1994. http://www.consensus.com/rsaref/index.html. [6] Charles E. Perkins and David B. Johnson. Route Optimization in Mobile-IP. draft-ietf-mobileip-optim-06.txt, July 1997. (work in progress). [7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. [8] Bruce Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C. John Wiley, New York, NY, USA, 1994. Chairs' Addresses The working group can be contacted via the current chairs: Jim Solomon Erik Nordmark Motorola, Inc. Sun Microsystems, Inc. 1301 E. Algonquin Road 901 San Antonio Road Schaumburg, IL 60196 Palo Alto, California 94303 USA USA Phone: +1-847-576-2753 Phone: +1 650 786-5166 Fax: Fax: +1 650 786-5896 E-mail: solomon@comm.mot.com E-mail: nordmark@sun.com Questions about this document can also be directed to the authors: Charles E. Perkins David B. Johnson Technology Development Group Computer Science Department Mail Stop MPK15-214 Room 2682 Sun Microsystems, Inc. Carnegie Mellon University 901 San Antonio Road 5000 Forbes Avenue Palo Alto, California 94303 Pittsburgh, PA 15213-3891 USA USA Phone: +1-650-786-6464 Phone: +1-412-268-7399 Fax: +1-650-786-6445 Fax: +1-412-268-5576 E-mail: charles.perkins@Sun.COM E-mail: dbj@cs.cmu.edu Perkins and Johnson Expires 20 May 1998 [Page 20]
