idnits 2.17.1 draft-ietf-mobileip-regkey-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([6], [7]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 146: '...es 0 through 255 are reserved and MUST...' RFC 2119 keyword, line 845: '... key, it MAY still satisfy the regis...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1750 (ref. '3') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-06 -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2002 (ref. '7') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 15 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Working Group Charles Perkins 3 INTERNET DRAFT Sun Microsystems 4 20 November 1997 David B. Johnson 5 Carnegie Mellon University 7 Registration Keys for Route Optimization 9 draft-ietf-mobileip-regkey-00.txt 11 Status of This Memo 13 This document is a submission by the Mobile IP Working Group of the 14 Internet Engineering Task Force (IETF). Comments should be submitted 15 to the mobile-ip@SmallWorks.COM mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check 30 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 31 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North 32 Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 33 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 35 Abstract 37 Route optimization [6] defines extensions to Mobile IP [7] 38 registration requests that allow datagrams in flight when a mobile 39 node moves, and datagrams sent based on an out-of-date cached 40 binding, to be forwarded directly to the mobile node's new binding. 41 These extensions for smooth handoff require a registration key to be 42 established between the mobile node and foreign agent. This document 43 defines additional extensions to the registration requests to allow 44 for the establishment of single-use registration keys between a 45 mobile node and foreign agent. 47 Contents 49 Status of This Memo i 51 Abstract i 53 1. Introduction 1 55 2. Terminology 1 57 3. Establishing Registration Keys 2 58 3.1. The Home Agent as a KDC . . . . . . . . . . . . . . . . . 3 59 3.2. Using the Foreign Agent as a KDC . . . . . . . . . . . . 4 60 3.3. Using Diffie-Hellman with the Foreign Agent . . . . . . . 5 62 4. Messages Requesting A Registration Key 7 63 4.1. Foreign Agent Key Request extension . . . . . . . . . . . 7 64 4.2. Mobile Node Public Key extension . . . . . . . . . . . . 8 65 4.3. Foreign Agent Public Key extension . . . . . . . . . . . 8 66 4.4. Registration Key Request Extension . . . . . . . . . . . 9 68 5. Extensions to Supply A Registration Key 10 69 5.1. Home-Mobile Key Reply Extension . . . . . . . . . . . . . 10 70 5.2. Foreign Agent Key Reply Extension . . . . . . . . . . . . 11 71 5.3. Mobile Node Public Key Reply Extension . . . . . . . . . 12 72 5.4. Foreign Agent Public Key Reply Extension . . . . . . . . 13 73 5.5. Diffie-Hellman Key Reply Extension . . . . . . . . . . . 14 74 5.6. SPI Extension . . . . . . . . . . . . . . . . . . . . . . 15 76 6. Mobile Node Key Requests 15 78 7. Miscellaneous Home Agent Operations 16 79 7.1. Receiving Registration Key Requests . . . . . . . . . . . 16 80 7.2. Home Agent Supplying Registration Keys . . . . . . . . . 17 82 8. Miscellaneous Foreign Agent Operations 17 83 8.1. Foreign Agent Handling Key Requests . . . . . . . . . . . 17 85 9. Security Considerations 18 87 10. Summary 19 89 References 19 91 Chairs' Addresses 20 92 1. Introduction 94 All Route Optimization messages that change the routing of IP 95 datagrams to the mobile node are authenticated using the same 96 mechanisms used in the base Mobile IP protocol. The authentication 97 relies on a mobility security association established in advance 98 between the sender and receiver of such messages. However, when a 99 mobile node registers with a foreign agent, typically it does not 100 share a security association with the foreign agent. Nevertheless, 101 in order for the foreign agent to process future binding updates that 102 it may receive from the mobile node, it needs to have such a securiyt 103 assocation. Binding updates provide a mechanism for accomplishing 104 smooth handoffs between a previous foreign agent to a new foreign 105 agent. Such smooth handoffs rely on the Previous Foreign Agent 106 Notification extension [6], which requires the transmission of an 107 authentic binding update to the previous foreign agent created by the 108 mobile node after it moves. 110 2. Terminology 112 This document uses the following terminology, in addition to that 113 used to describe the base Mobile IP protocol: 115 Binding cache 117 A cache of mobility bindings of mobile nodes, maintained by a 118 node for use in tunneling datagrams to those mobile nodes. 120 Binding update 122 A message indicating a mobile node's current mobility binding, 123 and in particular its care-of address. 125 Registration Key 127 A secret key shared between a mobile node and a foreign 128 agent, that may optionally be established during registration 129 with that foreign agent. When later moving and registering 130 a new care-of address elsewhere, the mobile node uses the 131 registration key shared with its previous foreign agent to send 132 it an authenticated Binding Update to this foreign agent. 134 Registration Lifetime 136 The registration lifetime is the time duration for which a 137 binding is valid. The term remaining registration lifetime 138 means the amount of time remaining for which a registration 139 lifetime is still valid, at some time after the registration 140 was approved by the home agent. 142 Security Parameters Index (SPI) 144 An index identifying a security context between a pair of 145 nodes among the contexts available in the Mobility Security 146 Association. SPI values 0 through 255 are reserved and MUST 147 NOT be used in any Mobility Security Association. 149 Triangle Routing 151 A situation in which a Correspondent Host's packets to a Mobile 152 Host follow a path which is longer than the optimal path 153 because the packets must be forwarded to the Mobile Host via a 154 Home Agent. 156 3. Establishing Registration Keys 158 Foreign agents are expected to be cheap and widely available, as 159 Mobile IP becomes fully deployed. Mobile nodes will likely find it 160 difficult to manage long-term security relationships with so many 161 foreign agents. To securely perform the operations needed for smooth 162 handoffs from one foreign agent to the next, however, any careful 163 foreign agent should require assurance that it is getting authentic 164 handoff information, and not arranging to forward in-flight datagrams 165 to a bogus destination. The messages described in this document are 166 used with the Mobile IP Registration Request and Registration Reply 167 messages to create (sufficient) trust between mobile node and foreign 168 agent when none exists beforehand, while allowing the use of fully 169 trustworthy security associations between foreign agents and mobile 170 nodes whenever they do exist. 172 Note that the mobile node can only rarely verify the identity of 173 the foreign agent in any absolute terms. It can only act on the 174 presumption that the foreign agent is performing its duties by 175 correct adherence to protocol. The exact identity of the foreign 176 agent is not crucial to the process of establishing a registration 177 key. Only an agreement to follow protocol can be expected or 178 enforced. If the mobile node has a way to obtain a certified public 179 key for the foreign agent, then the identity may be established in a 180 firmer fashion, but the needed public key infrastructure seems to be 181 at least five years distant. Therefore, the methods in this document 182 enable a mobile node to create a registration key with an anonymous 183 foreign agent (i.e., one whose identity we cannot establish) during 184 the registration process. There are several proposed methods for 185 establishing a registration key, discussed in order of declining 186 preference. Other methods of establishing keys may become available 187 in the future. 189 1. If the foreign agent and mobile node share a security 190 association, it can be used to secure the Previous Foreign Agent 191 Notification without need to establish a registration key. 193 2. If the home agent and foreign agent share a security association, 194 the home agent can choose the new registration key. 196 3. If the foreign agent has a public key, it can again use the home 197 agent to supply a registration key. 199 4. If the mobile node includes its public key in its Registration 200 Request, the foreign agent can choose the new registration key. 202 5. The mobile node and its foreign agent can execute a 203 Diffie-Hellman key exchange protocol [2] as part of the 204 registration protocol. 206 Once the registration key is established, the method for performing 207 smooth handoff seems natural. The following sections give a 208 brief overview of the above listed methods for establishing the 209 registration key. 211 If a request for key establishment cannot be accommodated by 212 the foreign agent and/or the home agent, then the mobile node's 213 key request must go unfulfilled. This does not mean that the 214 Registration Request itself fails, so it has no effect on the status 215 code returned by the home agent to the mobile node. The mobile node 216 has to be able to handle the case in which it has requested a key but 217 the Registration Reply arrives without any key reply extension. 219 3.1. The Home Agent as a KDC 221 Crucial to methods (2) and (3) listed above is that the home agent 222 and mobile node already are known to share a mobility security 223 association, which can be used to encode the registration key for 224 delivery to the mobile node. Thus, if the home agent can securely 225 deliver the key to the foreign agent, it can be used as a Key 226 Distribution Center (KDC) for the mobile node and its new foreign 227 agent. The mobile node requests this by including a Registration 228 Key Request extension in its Registration Request message. When the 229 home agent chooses the registration key, it sends it back in two 230 different extensions to the Registration Reply. One extension has 231 the encrypted key for the foreign agent, and the other extension has 232 the same key encrypted differently for the mobile node. 234 For the registration key to be established using this method, the 235 home agent must be able to securely transmit an encrypted copy of the 236 registration key to the foreign agent. This is straightforward if 237 the foreign agent already has a mobility security association with 238 the home agent. If mobile nodes from some home network often visit a 239 foreign agent, then the effort of creating such a mobility security 240 association between that foreign agent and the home agent serving 241 their home network may be worthwhile. 243 Note that MD5 can be used here for the purpose of transmitting 244 registration keys, secure against eavesdroppers. The expression 245 expr1 = MD5(secret | regrep | secret) XOR (key) 246 (where regrep is the Registration Reply message payload, and XOR is 247 exclusive-or) can be included within the appropriate Registration 248 Reply extension and encodes the key in a way which allows recovery 249 only by the recipient. It is secure against replay because of the 250 identification field within the Registration Reply message. The 251 recipient recovers the key by computing 252 expr2== MD5(secret | regrep | secret) 253 which then yields key = expr1XOR expr2. Use of MD5 avoids 254 entanglements with the legal issues surrounding the export of 255 encryption technology, and reducing the computational power needed to 256 secure the password against eavesdroppers. 258 If no such mobility security association exists, but the foreign 259 agent has a public key available, it can still ask the home agent to 260 use it to pick a registration key. This is preferable than asking 261 the mobile node to pick a good registration key, because doing so 262 may depend upon using resources not available to all mobile nodes. 263 Just selecting pseudo-random numbers is by itself a significant 264 computational burden. Moreover, allowing the home agent to pick the 265 key fits well into the existing registration procedures. On the 266 other hand, it is possible that a mobile node could do with less than 267 perfect pseudo-random numbers as long as the registration key were to 268 be used in the restricted fashion envisioned for smooth handoffs. 270 3.2. Using the Foreign Agent as a KDC 272 When the foreign agent and mobile node share a mobility security 273 association, there is no need to pick a registration key. The mobile 274 node can secure its Binding Update to the foreign agent whenever it 275 needs to, by using the existing security association. This is the 276 most desirable case. 278 Otherwise, if available, the mobile node can include its public key 279 (such as RSA [8]) in its Registration Request to the foreign agent, 280 using a mobile node public key extension. The foreign agent chooses 281 the new registration key and returns a copy of it encrypted with the 282 mobile node's public key, using a foreign-mobile registration key 283 reply extension. 285 3.3. Using Diffie-Hellman with the Foreign Agent 287 The Diffie-Hellman key-exchange algorithm [2] can be used. 288 Diffie-Hellman is a public key cryptosystem that allows two parties 289 to establish a shared secret key, such that the shared secret key 290 cannot be determined by other parties overhearing the messages 291 exchanged during the algorithm. It is already used, for example, in 292 other protocols that require a key exchange, such as in the Cellular 293 Digital Packet Data (CDPD) system [1]. 295 This technique is known to suffer from a man-in-the-middle attack. 296 In other words, a malicious agent could pretend to the foreign agent 297 to be the mobile node, and pretend to the mobile node to be the 298 foreign agent, and participate as an unwanted third member in the 299 key exchange. Armed with knowledge of the registration key, the 300 malicious agent could at a later time disrupt the smooth handoff, or 301 initiate the handoff prematurely. The man-in-the-middle attack is no 302 worse than a malicious agent pretending to be a foreign agent in any 303 other circumstance; that is, it is no worse than already exists with 304 the base Mobile IP specification [7]. In route optimization, the 305 man-in-the-middle attack is prevented in most circumstances because 306 each registration key produced by the techniques in this chapter is 307 effectively authenticated by the home agent. 309 If Diffie-Hellman were not computationally expensive, it could 310 likely serve the needs of many mobile nodes. Diffie-Hellman results 311 are authenticated by the home agent to frustrate man-in-the-middle 312 attacks. Moreover, the mobile node and/or the foreign agent are 313 presumably in direct contact, so that such an attack is detectable if 314 either of the nodes notices the reception of duplicate packets, and 315 corrective action taken. 317 But, the algorithm itself uses exponentiations involving numbers 318 with hundreds of digits. That may take a long time for some mobile 319 nodes to do, time which would come at the expense of interactivity 320 or convenient operation of user application programs. For this 321 reason, Diffie-Hellman is considered the least desirable alternative 322 for establishing registration keys. Since it requires no other 323 configuration, it is nevertheless required in all implementations of 324 foreign agents that advertise support for smooth handoffs. 326 Briefly, the Diffie-Hellman algorithm involves the use of two large 327 public numbers, a prime number (p) and a generator (g). The prime 328 number and the generator must be known by both parties involved 329 in the algorithm, but do not have to be secret; these values may 330 be the same or different for each execution of the algorithm and 331 are not used once the algorithm completes. Each party chooses a 332 private random number, produces a computed value based on this random 333 number, the prime and the generator, and sends the computed value in 334 a message to the other party. The computed value is the number g**x 335 mod p, where x is the private random number, p is the prime which is 336 sent as part of the transaction, and g is the generator. Each party 337 then computes the (same) shared secret key using its own private 338 random number, the computed value received from the other party, and 339 the prime and generator values. The shared secret is the number c**y 340 mod p, where c is the computed value which uses the other party's 341 private number, p is the same as before, and y is the receiver's 342 private number. Since (g**x)**y == (g**y)**x, and since knowing the 343 computed values mod p does not enable passive listeners to determine 344 the private values, the algorithm allows the two parties to agree on 345 an otherwise undetectable secret. 347 To use this algorithm during registration with a foreign agent, the 348 mobile node includes a Registration Key Request extension in its 349 Registration Request message, containing its nonzero values for 350 the prime and generator, along with the computed value from its 351 own private random number. If no other strategy is available, the 352 foreign agent then chooses its own private random number and includes 353 a Diffie-Hellman Registration Key Reply extension in its Registration 354 Reply message to the mobile node; the extension includes the foreign 355 agent's own computed value based on its chosen random number and the 356 supplied prime and generator values from the mobile node. The mobile 357 node and foreign agent each independently form the (same) shared 358 secret key from their own chosen random number, the computed value 359 supplied by the other party, and the prime and generator values. 361 Establishing a registration key using Diffie-Hellman is 362 computationally more expensive than most methods described in 363 Section 3. The use of Diffie-Hellman described here, though, is 364 designed to allow the Diffie-Hellman computations to be overlapped 365 with other activities. The mobile node may choose (or be manually 366 configured with) the prime and generator values at any time, or 367 may use the same two values for a number of registrations. The 368 mobile node may also choose its private random number and calculate 369 its computed value at any time. For example, after completing 370 one registration, the mobile node may choose the private random 371 number for its next registration and begin the computation of 372 its new computed value based on this random number, such that it 373 has completed this computation before it is needed in its next 374 registration. Even more simply, the mobile node may use the 375 same private random number and computed value for any number of 376 registrations. The foreign agent may choose its private random 377 number and begin computation of its computed value based on this 378 number as soon as it receives the mobile node's Registration Request 379 message, and need only complete this computation before it sends 380 the matching Registration Reply message for the mobile node's 381 registration. 383 This could be extended to support other similar key exchange 384 algorithms, either by adding a new request and reply extension for 385 each, or by adding a field in the extensions to indicate which 386 algorithm is to be used. Diffie-Hellman currently seems the only 387 obvious choice, though; an implementation is available in the free 388 RSAREF toolkit from RSA Laboratories [5]. 390 4. Messages Requesting A Registration Key 392 The following extensions may be used by mobile nodes or foreign 393 agents to request the establishment of a registration key. See 394 sections 6,7.2, and 8 for appropriate algorithms which allow each 395 node to tailor the use of these extensions to most closely fit its 396 configured requirements. 398 113 Foreign Agent Key Request Extension 399 114 Mobile Node Public Key Extension 400 115 Foreign Agent Public Key Extension 401 116 Diffie-Hellman Key Request Extension 403 4.1. Foreign Agent Key Request extension 405 If the foreign agent receives a Registration Key Request from 406 a mobile node, and it has a security association with the home 407 agent, it may append the Foreign Agent Key Request extension to 408 the Registration Request after the mobile-home authentication 409 extension. The home agent will use the SPI specified in the key 410 request extension to encode the registration key in the subsequent 411 Registration Reply message. The format of the Foreign Agent Key 412 Request extension is illustrated below. 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type | Length | SPI ..... | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | ... SPI (continued) | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Type 113 424 Length 4 425 SPI Security Parameters Index (4 bytes). An opaque 426 identifier. 428 4.2. Mobile Node Public Key extension 430 If the mobile node has a public key, it can ask its prospective 431 foreign agent to choose a registration key, and to use the mobile 432 node's public key to encode the chosen registration key. No 433 eavesdropper will be able to decode the registration key, even if 434 it is broadcast to all entities with access to the network medium 435 used by the mobile node. If using the public key, the foreign 436 agent should still include the selected key in the Registration 437 Request before it goes to the home agent. Then, the home agent can 438 authenticate the selected encoded registration key as part of the 439 Registration Reply message. The format of the mobile node public key 440 extension is as illustrated below. 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Type | Length |MN Public Key .. 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | ... Mobile Node Public Key, continued ... 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Type 114 452 Length The length (typically larger than 255) of the mobile 453 node's public key 455 4.3. Foreign Agent Public Key extension 457 The format of the foreign agent public key extension is as 458 illustrated below. 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Type | Length | SPI ... | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | ... SPI (continued) |FA Public Key .. 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Foreign Agent Public Key (continued) ... 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 If the foreign agent has a public key, it can ask the home agent to 471 choose a registration key, and to use the foreign agent's public key 472 to encode the chosen registration key. Then, the home agent can 473 authenticate the selected encoded registration key as part of the 474 Registration Reply message. 476 Type 115 478 Length 4 plus the length (typically larger than 255) of the 479 foreign agent's public key 481 SPI Security Parameters Index (4 bytes). An opaque 482 identifier. 484 Foreign Agent's Public Key 486 The SPI is provided for the home agent to transcribe into the 487 eventual Foreign Agent Public Key Reply extension to the Registration 488 Reply message. 490 4.4. Registration Key Request Extension 492 The Registration Key Request extension, illustrated below, may be 493 included in a Registration Request message sent to a foreign agent. 494 If the length of the parameters in the key request extension are all 495 zero, then the mobile node is asking the foreign agent to supply a 496 key by any means it has available except for Diffie-Hellman. 498 If the lengths are nonzero, then the mobile node is enabling the 499 foreign agent to also perform the Diffie-Hellman key exchange 500 algorithm (as described in Section 3.3) if the other possible key 501 establishment methods are not available. The foreign agent should 502 then select a good pseudo-random registration key, and include a 503 Diffie-Hellman Registration Key Reply extension, in the Registration 504 Request message sent to the home agent to complete the key exchange. 505 The home agent will also include same extension in the Registration 506 Reply sent to the mobile node, and then it will be authenticated as 507 part of the reply message. 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Type | Length | Prime ... 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | ... Prime (continued) ... 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Generator ... 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Computed Value ... 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Type 116 522 Length 3 times the length (in bytes) of each of prime, 523 generator, and computed value. The values prime, 524 generator, and computed value must all be the same 525 length, which must be a multiple of 8 bits. 527 Prime One of the two public numbers involved in the 528 Diffie-Hellman key exchange algorithm. The prime should 529 be a large prime number. 531 Generator 532 One of the two public numbers involved in the 533 Diffie-Hellman key exchange algorithm. If p is the value 534 of the prime used for this Diffie-Hellman exchange, 535 the generator should be less than p, and should be a 536 primitive root of p. 538 Computed Value 539 The public computed value from the mobile node for this 540 Diffie-Hellman exchange. The mobile node chooses a large 541 random number, x. If g is the value of the generator and 542 p is the value of the prime, the computed value in the 543 extension is g**x mod p. 545 5. Extensions to Supply A Registration Key 547 The following extensions are used to supply a registration key to 548 a requesting entity, either a foreign agent or a mobile node, and 549 are the counterparts to corresponding extensions used to request 550 registration keys that are described in the last section. 552 120 Home-Mobile Key Reply Extension 553 121 Foreign Agent Key Reply Extension 554 122 Mobile Node Public Key Reply Extension 555 123 Foreign Agent Public Key Reply Extension 556 124 Diffie-Hellman Key Reply Extension 557 125 SPI Extension 559 5.1. Home-Mobile Key Reply Extension 561 The home-mobile key reply extension may be used in Registration Reply 562 messages to send a registration key from the mobile node's home agent 563 to the mobile node. When used, the home agent is required to also 564 include a key reply extension in the Registration Reply message, 565 which gives a copy of the same key to the mobile node's new foreign 566 agent. The home-mobile key reply extension, illustrated below, is 567 authenticated along with the rest of the Registration Reply message, 568 and thus no additional authenticator is included in the extension. 569 The SPI used to encode the registration key may be different than the 570 SPI used to authenticate the Registration Reply message. 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Type | Length | SPI ... | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | ... SPI (continued) | MN Enc. Key ... 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Mobile Node Encrypted Key ... 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Type 120 584 Length 4 plus the length of the encrypted key for the mobile 585 node 587 SPI Security Parameters Index (4 bytes). An opaque 588 identifier. 590 Mobile Node Encrypted Key 591 (variable length) The registration key, chosen by 592 the home agent, encrypted under the mobility security 593 association between the home agent and the mobile node. 594 The same key must be sent, encrypted for the foreign 595 agent in a foreign agent registration key extension in 596 this Registration Reply message. 598 5.2. Foreign Agent Key Reply Extension 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Type | Length | SPI ... | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | ... SPI (continued) | FA Enc. Key ... 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Foreign Agent Encrypted Key ... 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 The home-foreign registration key reply extension may be used in 611 Registration Reply messages to send a registration key from the 612 mobile node's home agent to the mobile node's new foreign agent. 613 When used, the home agent is required to also include a home-mobile 614 registration key reply extension in the Registration Reply message, 615 giving a copy of the same key to the mobile node. 617 Type 121 619 Length 4 plus the length of the encrypted foreign agent's key 620 plus the length of the authenticator 622 SPI Security Parameters Index (4 bytes). An opaque 623 identifier. 625 Foreign Agent Encrypted Key 626 (variable length) The registration key, chosen by 627 the home agent, encrypted under the mobility security 628 association between the home agent and the foreign agent. 630 The key which is sent in this extension must also be sent by the 631 home agent to the mobile node, encoded for the mobile node in a 632 mobile node registration key extension in the same Registration Reply 633 message. 635 Authentication of the key is performed by use of data within a HA-FA 636 Authentication extension to the Registration Reply message which is 637 required when the Foreign Agent Key Reply extension is used. Replay 638 protection is accomplished using the identification field in the 639 Registration Request message, which is also used by the foreign agent 640 to identify the pending registration data. 642 5.3. Mobile Node Public Key Reply Extension 644 The Mobile Node Public Key Reply message is illustrated below. 646 0 1 2 3 647 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 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Type | Length | SPI ... | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | ... SPI (continued) | MN Enc. Key ... 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | ... Mobile Node's Encoded Key (continued) ... 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 When the mobile node sends a Mobile Node Public Key Request to its 657 prospective foreign agent, the foreign agent can immediately select 658 a registration key. The foreign agent encodes this registration key 659 into the Mobile Node Public Key Reply extension to the Registration 660 Request, along with an SPI for future reference. The home agent 661 subsequently transcribes the extension without change into the 662 Registration Reply message. This procedure allows the mobile node to 663 be protected against common man-in-the-middle attacks. 665 Type 122 667 Length The length (in bytes) of the computed value. 669 SPI Security Parameters Index (4 bytes). An opaque 670 identifier. 672 Mobile Node's Encoded Key 673 The foreign agent chooses a suitable key, possibly a 674 pseudo-random number, and encodes it using the mobile 675 node's public key. 677 5.4. Foreign Agent Public Key Reply Extension 679 In response to a foreign agent public key request extension, the home 680 agent will select a registration key and encode it twice into two 681 separate key reply extensions of the Registration Reply message. The 682 Foreign Agent Public Key Reply extension contains the registration 683 key encoded with the public key of the foreign agent. 685 The Foreign Agent Public Key Reply message is illustrated below. 687 0 1 2 3 688 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 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Type | Length | SPI ... | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | ... SPI (continued) | FA Enc. Key ... 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | ...Foreign Agent's Encoded Key (continued) ... 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 Type 123 699 Length 4 plus the length (in bytes) of the Foreign Agent's 700 Encoded Key. 702 SPI Security Parameters Index (4 bytes). An opaque 703 identifier. 705 Foreign Agent's Encoded Key 706 The foreign agent chooses a suitable pseudo-random 707 number, and encodes it using the mobile node's public 708 key. 710 The SPI, provided by the foreign agent for transcribing into this 711 extension, is ultimately targeted for use by the mobile node. 713 5.5. Diffie-Hellman Key Reply Extension 715 The Diffie-Hellman Registration Key Reply extension, illustrated 716 below, should be included in a Registration Request message sent by 717 a foreign agent to the home agent, when the following conditions are 718 met: 720 - mobile node has included a Registration Key Request extension 721 with nonzero prime and generator in its Registration Request 722 message to the foreign agent, and 724 - the foreign agent has no public key or security association with 725 the home agent or mobile node. 727 0 1 2 3 728 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 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Type | Length | SPI ... | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | ... SPI (continued) |Computed Val.... 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | ... Computed Value (continued) ... 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 Type 124 739 Length 4 plus the length (in bytes) of the computed value. 741 SPI Security Parameters Index (4 bytes). An opaque 742 identifier. 744 Computed Value 745 The foreign agent chooses a large random number, y. If g 746 is the value of the generator and p is the value of the 747 prime, the computed value in the extension is gymod p. 748 The values of the generator and prime, if nonzero, are 749 taken from the Registration Key Request extension from 750 the mobile node's Registration Request message. 752 The foreign agent supplies a new SPI along with the new registration 753 key, so that the new key will be useful in the same way as 754 registration keys created by any other method. 756 5.6. SPI Extension 758 The SPI Extension is included in Registration Reply messages when 759 needed to specify the SPI to be associated with the registration key. 761 0 1 2 3 762 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 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Type | Length | SPI ..... | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | ... SPI (continued) | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 Type 125 771 Length 4 plus the length (in bytes) of the computed value. 773 SPI Security Parameters Index (4 bytes). An opaque 774 identifier. 776 6. Mobile Node Key Requests 778 If the mobile node detects that its new foreign agent supports 779 smooth handoffs, it may initiate that process with its previous 780 foreign agent, as well as asking its new foreign agent to aid in 781 supplying a registration key for the new registration. The following 782 code fragment illustrates a good algorithm for the mobile node 783 to use during registration, to allow the maximum flexibility in 784 the selection of the new registration key. Any particular mobile 785 node may be configured to use one, none, or any subset of the 786 key establishment procedures made available as part of the Route 787 Optimization protocol. 789 if (got 'S' bit from advertisement) { 790 if (have registration key with previous FA) { 791 ; /* append Previous Foreign Agent Notification */ 792 } 793 /* Set up registration key */ 794 if (have security association with current FA) { 795 ; /* Don't need to create a registration key */ 796 } 797 else if (have a public key) { 798 ; /* append MN Public Key request */ 799 } 800 else if (want D-H exchange) { 801 /* compute a value for prime p and generator g */ 802 /* use it and append MN Key request */ 803 } 804 else /* append MN key request with null computed value, etc */ 805 } 807 In this way, the mobile node can get a registration key whenever one 808 is available by any mechanism specified in this document. 810 7. Miscellaneous Home Agent Operations 812 7.1. Receiving Registration Key Requests 814 When the home agent receives a Registration Request message, an 815 extension requesting a registration key (Section 4) may be present in 816 the message, requesting the home agent to provide a registration key 817 to the mobile node and its foreign agent, as described in Section 3. 818 In that event, the home agent employs a good algorithm for producing 819 random keys [3] and encrypts the result separately for use by the 820 foreign agent and by the mobile node. The chosen key is encrypted 821 under the mobility security association shared between the home 822 agent and the mobile node, and the encrypted key is placed in a 823 home-mobile registration key reply extension (Section 5.1) in the 824 Registration Reply message. The same key also is encrypted under 825 the mobility security association shared between the home agent and 826 the foreign agent, and the encrypted key is placed in a home-foreign 827 registration key reply extension (Section 5.2) in the Registration 828 Reply message. When the home agent transmits the Registration Reply 829 message containing reply extensions to the foreign agent, the message 830 has the overall structure as follows: 832 ------------------------------------------------------------- 833 |IP|UDP| Reg-Reply| MN Key| FA Key| HA-MH Auth.| HA-FA Auth.| 834 ------------------------------------------------------------- 836 The mobile node gets the registration key, typically encoded using an 837 algorithm such as that described in Section 3.1. The encoding of the 838 foreign agent's copy of the key depends on the particular key request 839 made by the foreign agent, and may depend upon the SPI specified 840 along with the encoded key. The HA-FA authentication extension is 841 only included if the home agent and foreign agent share a mobility 842 security association. 844 If the home agent cannot satisfy a request to select a registration 845 key, it MAY still satisfy the registration attempt. In this case, 846 the home agent returns a Registration Reply message indicating 847 success, but does not include any key reply extension. 849 7.2. Home Agent Supplying Registration Keys 851 When the home agent receives a Registration Request message 852 with registration key extensions, it usually performs one of two 853 operations: 855 - select and encode a registration key for both the mobile node and 856 the foreign agent, or 858 - transcribe the registration key already selected by the foreign 859 agent into the appropriate extension to the Registration Reply 860 message. 862 Both operations ensure that the mobile node and home agent are 863 dealing with the same foreign agent. 865 When building the Registration Reply, the home agent should follow 866 an algorithm such as the one illustrated below, to be as useful as 867 possible for the range of registration key establishment scenarios 868 that are possible given the current route optimization protocol. 870 /* Set up registration key */ 871 if (Foreign Agent Key Request) { /* then have security assn. */ 872 /* append MN Key Reply to Registration Reply */ 873 /* append FA key reply to Registration Reply */ 874 } 875 else if ((have foreign agent public key) || 876 (have FA Public Key Reply)) { 877 /* append MN Key Reply to Registration Reply */ 878 /* append FA Public Key Reply to Registration Reply */ 879 } 880 else { 881 /* do nothing */ 882 } 883 /* append mobile-home authentication extension at end */ 885 8. Miscellaneous Foreign Agent Operations 887 This section details various operational considerations important 888 for foreign agents wishing to support smooth handoff, including 889 algorithms for establishment of registration keys. 891 8.1. Foreign Agent Handling Key Requests 893 The foreign agent, when it receives a request from a mobile node for 894 a registration key, is faced with a variety of possible actions. The 895 action selected by the foreign agent depends on the resources it has 896 available. The foreign agent typically attempts to reduce as much 897 as possible the computational burden placed on the mobile node, but 898 relies on the security association with the greatest cryptographic 899 strength to encode the registration key. Furthermore, if the foreign 900 agent performs the key selection, it still supplies the encoded key 901 in an extension to the Registration Request message, so that the 902 process of registration will also have the effect of authenticating 903 its choice of registration key to the mobile node. This strategy 904 reduces the opportunity for interlopers to mount man-in-the-middle 905 attacks. 907 The following code fragment, executed when the foreign agent receives 908 a key request of some variety, exhibits an algorithm which may be 909 useful for implementors of foreign agents. The algorithm is supposed 910 to be used when a foreign agent gets a Registration Request with one 911 of the key request extensions included. 913 if (Previous Foreign Agent Notification) { 914 /* build the Binding Update and authentication extension */ 915 } 917 /* Set up registration key */ 918 if (have security association with HA) { 919 /* Append FA key request to Registration Request */ 920 } 921 else if (have a public key) { 922 /* append FA Public Key request to Registration Request */ 923 } 924 else if (have mobile node's public key) { 925 /* pick a good key */ 926 /* append FA Public Key Reply to Registration Request */ 927 } 928 else if (want D-H exchange) { 929 /* start the computation */ 930 /* append the result to the Registration Key Request */ 931 else { 932 /* do nothing */ 933 } 935 9. Security Considerations 937 Whenever the foreign agent is involved with the production of a 938 registration key by use of the Diffie-Hellman algorithm, the process 939 is susceptible to the "man-in-the-middle" attack, as detailed in 940 Section 3.3. This attack is not known to produce further difficulty, 941 and susceptibility is already inherent in the operation of the base 942 Mobile IP specification [7]. Attention to this detail is warranted 943 during any future changes to the Route Optimization protocol, and 944 ways to reduce the risk of direct interest for inclusion into future 945 revisions of this document. 947 The calculation of the authentication data described in Section 3.1 948 is specified to be the same as in the base Mobile IP document for 949 ease of implementation. There is a better method available (HMAC), 950 specified in RFC 2104 [4]. If the base Mobile IP specification is 951 updated to use HMAC, then this route optimization specification 952 should also be updated similarly. 954 Registration keys should typically NOT be used as master keys for 955 producing other derived keys, because of the man-in-the-middle attack 956 associated with unidentifiable foreign agents. 958 10. Summary 960 In this document, we have presented the methods for establishing 961 registration keys for use by mobile nodes and foreign agents 962 supporting smooth handoffs. The ways provided for the mobile node 963 and foreign agent to obtain a registration key are as follows: 965 - Use the mobility security association they share if it exists 967 - Use the mobile node's public key if it exists 969 - Use the foreign agent's public key, if it exists, to enable the 970 home agent to create public keys for both entities, or 972 - Use the security association between the foreign agent and home 973 agent, if it exists, to enable the home agent to create the 974 registration keys for both entities, or 976 - Use the Diffie-Hellman key exchange algorithm. 978 References 980 [1] CDPD consortium. Cellular Digital Packet Data Specification. 981 P.O. Box 809320, Chicago, Illinois, July 1993. 983 [2] W. Diffie and M. Hellman. New Directions in Cryptography. IEEE 984 Transactions on Information Theory, 22:644--654, November 1976. 986 [3] Donald E. Eastlake, Stephen D. Crocker, and Jeffrey I. Schiller. 987 Randomness Recommendations for Security. RFC 1750, December 988 1994. 990 [4] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing 991 for Message Authentication. RFC 2104, February 1997. 993 [5] RSA Laboratories. Rsaref: A cryptographic toolkit, version 2.0, 994 1994. http://www.consensus.com/rsaref/index.html. 996 [6] Charles E. Perkins and David B. Johnson. Route Optimization in 997 Mobile-IP. draft-ietf-mobileip-optim-06.txt, July 1997. (work 998 in progress). 1000 [7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1001 1996. 1003 [8] Bruce Schneier. Applied Cryptography: Protocols, Algorithms, 1004 and Source Code in C. John Wiley, New York, NY, USA, 1994. 1006 Chairs' Addresses 1008 The working group can be contacted via the current chairs: 1010 Jim Solomon Erik Nordmark 1011 Motorola, Inc. Sun Microsystems, Inc. 1012 1301 E. Algonquin Road 901 San Antonio Road 1013 Schaumburg, IL 60196 Palo Alto, California 94303 1014 USA USA 1016 Phone: +1-847-576-2753 Phone: +1 650 786-5166 1017 Fax: Fax: +1 650 786-5896 1018 E-mail: solomon@comm.mot.com E-mail: nordmark@sun.com 1020 Questions about this document can also be directed to the authors: 1022 Charles E. Perkins David B. Johnson 1023 Technology Development Group Computer Science Department 1024 Mail Stop MPK15-214 1025 Room 2682 1026 Sun Microsystems, Inc. Carnegie Mellon University 1027 901 San Antonio Road 5000 Forbes Avenue 1028 Palo Alto, California 94303 Pittsburgh, PA 15213-3891 1029 USA USA 1030 Phone: +1-650-786-6464 Phone: +1-412-268-7399 1031 Fax: +1-650-786-6445 Fax: +1-412-268-5576 1032 E-mail: charles.perkins@Sun.COM E-mail: dbj@cs.cmu.edu