idnits 2.17.1 draft-ietf-mobileip-regkey-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages 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 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 396: '... MUST include that Challenge value in its registration request [3]....' RFC 2119 keyword, line 405: '... nodes MAY be configured to avoid us...' RFC 2119 keyword, line 508: '...rt smooth handovers SHOULD support the...' RFC 2119 keyword, line 603: '... The home agent SHOULD also include a...' RFC 2119 keyword, line 678: '..., the Home Agent MAY require that the ...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [1], but that reference does not seem to mention RFC 2119 either. -- 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) == Outdated reference: A later version (-02) exists of draft-calhoun-mobileip-min-lat-handoff-01 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-challenge-08 -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1750 (ref. '6') (Obsoleted by RFC 4086) -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 2412 (ref. '10') ** Obsolete normative reference: RFC 2002 (ref. '11') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '12' == Outdated reference: A later version (-01) exists of draft-ietf-mobileip-gen-key-00 -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Charles E. Perkins 2 INTERNET DRAFT Nokia Research Center 3 27 February 2000 David B. Johnson 4 Carnegie Mellon University 6 Registration Keys for Route Optimization 7 draft-ietf-mobileip-regkey-01.txt 9 Status of This Memo 11 This document is a submission by the mobile-ip Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at: 31 http://www.ietf.org/shadow.html. 33 Abstract 35 Route optimization defines extensions to Mobile IP Registration 36 Requests that allow datagrams in flight when a mobile node moves, 37 and datagrams sent based on an out-of-date cached binding, to 38 be forwarded directly to the mobile node's new binding. These 39 extensions for smooth handoff require a registration key to be 40 established between the mobile node and foreign agent. This document 41 defines additional extensions to the registration requests to allow 42 for the establishment of single-use registration keys between a 43 mobile node and foreign agent. 45 Contents 47 Status of This Memo i 49 Abstract i 51 1. Introduction 1 53 2. Terminology 1 55 3. Establishing Registration Keys 2 56 3.1. The Home Agent as a KDC . . . . . . . . . . . . . . . . . 4 57 3.2. Using the Foreign Agent as a KDC . . . . . . . . . . . . 5 59 4. Registration Key Request Extension Subtypes 5 60 4.1. Registration Key Request Subtype . . . . . . . . . . . . 7 61 4.2. Foreign Agent Registration Key Request Subtype . . . . . 7 62 4.3. Mobile Node Request Via Public Key Subtype . . . . . . . 8 63 4.4. Foreign Agent Public Key Request Subtype . . . . . . . . 8 64 4.5. Diffie-Hellman Registration Key Request Subtype . . . . . 8 65 4.6. Diffie-Hellman Elliptic Curve Registration Key Request . 9 67 5. Generalized MN-FA Key Reply Subtypes 10 68 5.1. Registration Key Reply from Home Agent Subtype . . . . . 11 69 5.2. Mobile Node Public Key Reply Subtype . . . . . . . . . . 11 70 5.3. Foreign Agent Public Key Reply Subtype . . . . . . . . . 12 71 5.4. Diffie-Hellman Key Reply Subtype . . . . . . . . . . . . 12 73 6. Mobile Node Key Requests 13 75 7. Miscellaneous Home Agent Operations 14 76 7.1. Receiving Registration Key Requests . . . . . . . . . . . 14 77 7.2. Diffie-Hellman Considerations . . . . . . . . . . . . . . 15 78 7.3. Home Agent Supplying Registration Keys . . . . . . . . . 16 80 8. Miscellaneous Foreign Agent Operations 17 81 8.1. Foreign Agent Handling Key Requests . . . . . . . . . . . 17 82 8.2. Advertising Digestified Diffie-Hellman Computations . . . 19 84 9. Security Considerations 19 86 References 20 88 A. Using Diffie-Hellman with the Foreign Agent 21 90 B. Diffie-Hellman Key Exchange in the Field of Integers mod p 23 91 C. Diffie-Hellman Key Exchange in Elliptic Curve Groups 23 93 Addresses 26 95 1. Introduction 97 The Binding Update is a Route Optimization [12] message that 98 changes the routing of IP datagrams to the mobile node. It can 99 be authenticated using mechanisms similar to those specified for 100 the base Mobile IP protocol [11]. The authentication relies on 101 a mobility security association established in advance between 102 the sender and receiver of such messages. The Binding Update 103 message can be used to accomplish a smooth handoff for a mobile node 104 moving from a previous foreign agent to a new foreign agent. Such 105 smooth handoffs rely on the Previous Foreign Agent Notification 106 extension [12], which requires the transmission of a Binding Update 107 to the previous foreign agent created by the mobile node after 108 it moves. However, when a mobile node registers with a foreign 109 agent, typically it does not share a security association with the 110 foreign agent. In order for the foreign agent to process future 111 Binding Updates that it may receive from the mobile node, it needs to 112 establish such a security association. 114 This document is a specification for some useful methods for 115 establishing the necessary mobility security association between the 116 mobile node and its new foreign agent. 118 2. Terminology 120 This document makes use of many terms defined in RFC 2002 [11] to 121 describe the base Mobile IP protocol, as well as terms defined in 122 the specification for Route Optimization [12]. In addition, the 123 following terms are used: 125 Binding cache 127 A cache of mobility bindings of mobile nodes, maintained by a 128 node for use in tunneling datagrams to those mobile nodes. 130 Field Element 132 an element of one of the fields used to define the 133 Diffie-Hellman key exchange extensions. This usage must be 134 carefully distinguished from the use of the word "field" to 135 denote a designated part of the data for a protocol unit. 137 Registration Key 139 A secret key shared between a mobile node and a foreign 140 agent, that may optionally be established during registration 141 with that foreign agent. When later moving and registering 142 a new care-of address elsewhere, the mobile node uses the 143 registration key shared with its previous foreign agent to send 144 it an authenticated Binding Update to this foreign agent. The 145 registration key forms the basis for the mobility security 146 association needed between the mobile node and the foreign 147 agent. 149 Registration Lifetime 151 The registration lifetime is the time duration for which a 152 binding is valid. The term remaining registration lifetime 153 means the amount of time remaining for which a registration 154 lifetime is still valid, at some time after the registration 155 was approved by the home agent. 157 Triangle Routing 159 A situation in which a correspondent node's packets to a Mobile 160 Node follow a path which is longer than the optimal path 161 because the packets must be forwarded to the Mobile Node via a 162 Home Agent. 164 In formulas requiring exponentiation, the `^' character is used. 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [1]. 170 3. Establishing Registration Keys 172 Foreign agents may become cheap and widely available, as Mobile IP 173 becomes fully deployed. Mobile nodes will likely find it difficult 174 to manage long-term security relationships with so many foreign 175 agents. To securely perform the operations needed for smooth 176 handoffs from one foreign agent to the next, however, any careful 177 foreign agent should require assurance that it is getting authentic 178 handoff information, and not arranging to forward in-flight datagrams 179 to a bogus destination. The messages described in this document are 180 used with the Mobile IP Registration Request and Registration Reply 181 messages to create (sufficient) trust between mobile node and foreign 182 agent when none exists beforehand, while allowing the use of fully 183 trustworthy security associations between foreign agents and mobile 184 nodes whenever they do exist. 186 Note that the mobile node may often be unable to verify the identity 187 of the foreign agent. It must then act only on the presumption that 188 the foreign agent is performing its duties by correct adherence to 189 protocol. The exact identity of the foreign agent is not crucial to 190 the process of establishing a registration key. Only an agreement to 191 follow protocol can be expected or enforced. If the mobile node has 192 a way to obtain a certified public key for the foreign agent, then 193 the identity may be established in a firmer fashion, but the needed 194 public key infrastructure seems to be at least five years distant. 195 Therefore, the methods in this document enable a mobile node to 196 create a registration key with an anonymous foreign agent (i.e., one 197 whose identity we cannot establish) during the registration process. 198 There are several proposed methods for establishing a registration 199 key, discussed in order of declining preference. Other methods of 200 establishing keys may become available in the future. 202 1. If the foreign agent and mobile node share a security 203 association, it can be used to secure the Previous Foreign Agent 204 Notification without need to establish a registration key. 206 2. If the home agent and foreign agent share a security association, 207 the home agent can choose the new registration key. 209 3. If the mobile node can transfer key information between foreign 210 agents that trust each other, it can use the same key as it had 211 used with its previous foreign agent [2]. 213 4. If the foreign agent has a public key, it can again use the home 214 agent to supply a registration key. 216 5. If the mobile node includes its public key in its Registration 217 Request, the foreign agent can choose the new registration key. 219 6. The mobile node and its foreign agent can execute a 220 Diffie-Hellman key exchange protocol [5], using the method 221 for elliptic curves [7, 9], or using the more familiar method 222 involving exponentiations. 224 Once the registration key is established, the smooth handoff method 225 can be used [12]. The following sections give a brief overview of 226 the above enumerated methods for establishing the registration key. 228 If a request for key establishment cannot be accommodated by 229 the foreign agent and/or the home agent, then the mobile node's 230 key request must go unfulfilled. This does not mean that the 231 Registration Request itself fails, so the same status code will be 232 returned by the home agent to the mobile node. The mobile node has 233 to be able to handle the case in which it has requested a key but 234 the Registration Reply arrives without any key reply extension. 236 This could happen even when the foreign agent has advertised its 237 willingness to offer smooth handoffs, and the mobile node has 238 supplied all the necessary parameters. The effect will likely be a 239 less than smooth handover. 241 3.1. The Home Agent as a KDC 243 Crucial to methods (2) and (4) listed above is that the home agent 244 and mobile node already are known to share a mobility security 245 association, which can be used to encode the registration key for 246 delivery to the mobile node. Thus, if the home agent can securely 247 deliver the key to the foreign agent, it can be used as a Key 248 Distribution Center (KDC) for the mobile node and its new foreign 249 agent. The mobile node requests this by including a Registration 250 Key Request extension in its Registration Request message. When the 251 home agent chooses the registration key, it returns the key in two 252 different extensions to the Registration Reply. One extension has 253 the encrypted key for the foreign agent, and the other extension has 254 the same key encrypted differently for the mobile node. 256 For the registration key to be established using this method, the 257 home agent must be able to securely transmit an encrypted copy of the 258 registration key to the foreign agent. This is straightforward if 259 the foreign agent already has a mobility security association with 260 the home agent. If mobile nodes from some home network often visit a 261 foreign agent, then the effort of creating such a mobility security 262 association between that foreign agent and the home agent serving 263 their home network may be worthwhile. 265 If the home agent does not have such a mobility security association, 266 but the foreign agent has a public key available, it can still 267 ask the home agent to use it to pick a registration key. This is 268 preferable than asking the mobile node to pick a good registration 269 key, because doing so may depend upon using resources not available 270 to all mobile nodes; simply selecting pseudo-random numbers is by 271 itself a significant computational burden. Moreover, allowing the 272 home agent to pick the key fits well into the existing registration 273 procedures. On the other hand, it is conceivable that a mobile node 274 could do with less than perfect pseudo-random numbers as long as the 275 registration key were to be used in the restricted fashion envisioned 276 for smooth handoffs. 278 Note that MD5 can be used here for the purpose of transmitting 279 registration keys, secure against eavesdroppers. The expression 281 expr1 == MD5(secret | regrep | secret) XOR (key) 283 (where regrep is the Registration Reply message payload up to but 284 not including the encoded key data, and XOR is exclusive-or) can be 285 included within the appropriate Registration Reply extension. This 286 encodes the key in a way which allows recovery only by the recipient. 287 It is secure against replay because of the Identification within 288 the Registration Reply message. The recipient recovers the key by 289 computing 291 expr2 == MD5(secret | regrep | secret) 293 which then yields (key == expr1 XOR expr2). Use of MD5 avoids 294 entanglements with the legal issues surrounding the export of 295 encryption technology, and reducing the computational power needed to 296 secure the password against eavesdroppers. 298 3.2. Using the Foreign Agent as a KDC 300 When the foreign agent and mobile node share a mobility security 301 association, there is no need to pick a registration key. The mobile 302 node can secure its Binding Update to the foreign agent whenever it 303 needs to, by using the existing security association. This is the 304 most desirable case. 306 Otherwise, if available, the mobile node can include its public key 307 (such as RSA [14]) in its Registration Request to the foreign agent, 308 using a Mobile Node Public Key Request extension (see section 4.3). 309 The foreign agent chooses the new registration key and includes a 310 copy of it encrypted with the mobile node's public key, using a 311 Foreign-Mobile Public Key Reply extension (see section 5.3). This is 312 sent to the home agent for inclusion with the Registration Reply. 314 4. Registration Key Request Extension Subtypes 316 A Generalized MN-FA Key Request extension has been specified [13]. 317 This generalized extension contains the SPI that the mobile node 318 wishes to use with the registration key. Thus, it is guaranteed that 319 the SPI will not collide with another existing Mobility Security 320 Association already in place for the mobile node. 322 To simplify the discussion for protocol operations involving a 323 particular subtype, the generalized extension with a particular 324 subtype will typically be denoted as a specific extension, instead of 325 a generalized extension with a specific subtype. So, for instance, 326 there will be discussion using the terminology "Registration Key 327 Request extension", which should be interpreted to mean "Generalized 328 Key Request extension with subtype 1". Note that a key requested by 329 any subtype of this Generalized Registration Key Request extension 330 is, by definition, for use between the mobile node and the foreign 331 agent handling its Mobile IP Registration Request. The foreign 332 agent stores the SPI from the registration key request extension 333 sent by the mobile node as part of its pending registration request 334 information. The SPI will be needed if the registration key reply 335 extension is returned in the Registration Reply message from the home 336 agent. 338 In this document, the following subtypes of the Generalized MN-FA Key 339 extension are defined: 341 1. Registration Key Request subtype (see section 4.1) 343 2. Foreign Agent Registration Key Request subtype (see section 4.2) 345 3. Mobile Node Request Via Public Key subtype (see section 4.3) 347 4. Foreign Agent Public Key Request subtype (see section 4.4) 349 5. Diffie-Hellman Registration Key Request subtype (see section 4.5) 351 6. Diffie-Hellman Elliptic Curve Registration Key Request extension 352 (see section 4.6) 354 Handling for these subtypes is specified in this section. These 355 may be used by mobile nodes or foreign agents to request the 356 establishment of a registration key. For each subtype, the MN-FA 357 Key Request Subtype Data of the Generalized Key Request extension 358 has to be specified. In this section, the MN-FA Key Request 359 Subtype Data will generally be referred as "the subtype data". See 360 sections 6, 7.3, and 8 for appropriate algorithms which allow each 361 node to use the extensions that most closely fit its configured 362 requirements. 364 There are two Diffie-Hellman Key Request subtypes that may be 365 included by a foreign agent in a Registration Request message sent 366 to a home agent, if the other possible key establishment methods are 367 not available. For either subtype, the foreign agent should then 368 select a good pseudo-random registration key. The foreign agent 369 initiates the Diffie-Hellman key exchange algorithm (as described in 370 Appendix A), and includes a Diffie-Hellman Registration Key Request 371 extension in the Registration Request message sent to the home agent 372 to initiate the key exchange. The home agent will then complete the 373 key exchange and include the computed value in the Diffie-Hellman 374 Registration Key Reply extension in the Registration Reply sent to 375 the mobile node, where that extension can be authenticated as part of 376 the reply message. 378 The two Diffie-Hellman key request subtypes differ in the creation 379 and processing of the Computed Value which appears in the subtype 380 data. 382 Note that I am not certain that the name "Diffie-Hellman" 383 applies to key exchanges using elliptic curve groups. 385 4.1. Registration Key Request Subtype 387 The Registration Key Request subtype may be included in a 388 Registration Request to ask the foreign agent to supply a key by 389 any means it has available. The foreign agent may have a public 390 key, or it might have a security association with the home agent. 391 Otherwise, the foreign agent will attempt to employ a Diffie-Hellman 392 key exchange. 394 If the foreign agent has advertised a Challenge value, and also 395 sets the `S' bit in its Agent Advertisements, then the mobile node 396 MUST include that Challenge value in its registration request [3]. 397 Furthermore, in this case, the Challenge value represents a digested 398 form of the next value that would be used, if needed, by the foreign 399 agent in its next key exchange with a home agent. Thus, if the 400 foreign agent sets the `S' bit but does NOT include a Challenge 401 value, the mobile node cannot be certain that the foreign agent is 402 taking steps to protect against the man-in-the-middle attack that can 403 sometimes be mounted against Diffie-Hellman key exchanges. While 404 this is normally not an issue for registration keys, some mobile 405 nodes MAY be configured to avoid using the Registration Key Request 406 extension when the foreign agent does not advertise the Challenge 407 value. 409 For this extension, the subtype data is empty. 411 4.2. Foreign Agent Registration Key Request Subtype 413 If the foreign agent receives a Registration Key Request from a 414 mobile node, and it has a security association with the home agent, 415 it may select a registration key and append the Foreign Agent 416 Registration Key Request extension to the Registration Request after 417 the mobile-home authentication extension. For this extension, the 418 SPI in the Generalized Key Request extension refers to the SPI of the 419 security association between the home agent and the foreign agent. 421 For this extension, the subtype data is the key selected by 422 the foreign agent and encoded according to the FA-HA security 423 association. 425 4.3. Mobile Node Request Via Public Key Subtype 427 If the mobile node has a public key, it can ask its prospective 428 foreign agent to choose a registration key, and to use the mobile 429 node's public key to encode the chosen registration key. No 430 eavesdropper will be able to decode the registration key, even if the 431 encoded key is broadcast to all entities with access to the network 432 medium used by the mobile node. The foreign agent then includes the 433 encoded registration key in a Mobile Node Public Key Reply extension 434 (see section 5.2) to the Registration Request as it goes to the home 435 agent. Then, the home agent can authenticate the selected encoded 436 registration key as part of the Registration Reply message. 438 For the Mobile Node Request Via Public Key subtype, the subtype data 439 contains the mobile node's public key. 441 4.4. Foreign Agent Public Key Request Subtype 443 If the foreign agent has a public key, it can ask the mobile node's 444 home agent to choose a registration key, and then to use the foreign 445 agent's public key to encode the chosen registration key. As before, 446 no eavesdropper will be able to decode the registration key, even 447 if the encoded key is broadcast to all entities with access to 448 the network medium used by the home agent and the foreign agent. 449 The home agent then includes the encoded registration key in a 450 Foreign Agent Public Key Reply extension (see section 5.3) to the 451 Registration Reply. 453 For the Foreign Agent Public Key subtype, the subtype data contains 454 the foreign agent's public key. 456 4.5. Diffie-Hellman Registration Key Request Subtype 458 The foreign agent may send the Diffie-Hellman Registration 459 Key Request extension to initiate key exchange by use of the 460 exponentiation algorithm in the field of integers mod p, as described 461 in Appendix A. To initiate the key exchange the foreign agent 462 chooses a large random number, N. If g is the value of the generator 463 and p is the value of the prime, the computed value in the extension 464 is g^N mod p. See appendix B for details on the algorithm. 466 The foreign agent then appends the extension to the Registration 467 Request message, containing the values for the prime and generator, 468 along with the computed value (F) from its own private random number 469 N. The home agent will then choose its own private random number 470 M and creates its own computed value (H). The foreign agent will 471 complete the key exchange by extracting the home agent's computed 472 value H from the Diffie-Hellman Registration Key Reply extension in 473 the registration request. 475 The format of the subtype data contained in this extension is 476 illustrated below. 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Prime ... 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Generator ... 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Computed Value ... 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Prime One of the two public numbers involved in the 489 Diffie-Hellman key exchange algorithm. The prime should 490 be a large prime number. 492 Generator 493 The other public number involved in the Diffie-Hellman 494 key exchange algorithm. If p is the value of the prime 495 used for this Diffie-Hellman exchange, the generator 496 should be less than p, and should be a primitive 497 root [14] of p. 499 Computed Value 500 The public computed value from the foreign agent for this 501 Diffie-Hellman exchange. 503 The values indicated for the prime, generator, and computed value are 504 all the same length, which must be a integral number of bytes. 506 4.6. Diffie-Hellman Elliptic Curve Registration Key Request 508 All foreign agents that support smooth handovers SHOULD support the 509 Diffie-Hellman Elliptic Curve Registration Key Request. 511 To initiate the key exchange the foreign agent chooses a large random 512 number, N. If the generating point is (X,Y), then the computed value 513 is N*(X,Y), where the integer multiplication is accomplished by 514 adding the point to itself N times. The algorithm for adding points 515 in the elliptic curve group is given in section C. The default value 516 for the generating point (X,Y) is (24,13). Note that for any point 517 (X,Y) in the elliptic curve group, both X and Y are elements of the 518 underlying field, which in the default case specified below will be 519 the Galois Field GF[2^185]. 521 The foreign agent then inserts the extension in the Registration 522 Request message, containing the values for the prime and generator, 523 along with the computed value (F) from its own private random number 524 N. The home agent will then choose its own private random number and 525 creates its own computed value (H). The foreign agent will complete 526 the key exchange by extracting the home agent's computed value H 527 from the Diffie-Hellman Registration Key Reply extension in the 528 registration request. 530 The format of the subtype data contained in this extension is 531 illustrated below. 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Y0 | First Coordinate of (V,W) = N*(X,Y) ... 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Y0 Either 02 or 03, depending upon the least significant bit 540 of the computed value N*(X,Y) 542 First Coordinate of (V,W) = N*(X,Y) 543 If the chosen random number is N, and the chosen 544 generator is (X,Y), and if (V,W) = N*(X,Y), then this 545 value is V. 547 See section C for details about the computation of N*(X,Y), its 548 compressed representation as illustrated above, and recovery of 549 N*(X,Y) given this compressed representation. 551 5. Generalized MN-FA Key Reply Subtypes 553 Key reply extensions in this document are subtypes of the Generalized 554 MN-FA Key Reply extension [13]. 556 The following subtypes are defined: 558 1. Registration Key Reply from Home Agent 559 2. Mobile Node Public Key Reply 560 3. Foreign Agent Public Key Reply 561 4. Diffie-Hellman Key Reply 563 For each subtype, the format of the MN-FA Key Reply Subtype Data 564 has to be separately defined according to the particular method 565 required to set up the security association. In this section, the 566 term "subtype data" refers to the MN-FA Key Reply Subtype Data of the 567 Generalized MN-FA Key Reply extension. 569 For the subtypes specified in this document, the Registration Key 570 supplied in the subtype data comes as a result of a request which was 571 sent using a subtype of the Generalized MN-FA Key Request Extension. 572 The SPI to be used when employing the security association defined by 573 the registration key is supplied in the original request. 575 The keys obtained by the mobile node from the Key Reply extension 576 subtypes defined in this document are expected to remain valid for as 577 long as the mobile node continuously uses the same care-of address. 578 The purpose of the registration key is to facilitate smooth handoffs, 579 as well as secure subsequent registrations. Since it would typically 580 take a huge number of encryptions with the same registration key for 581 an attacker to gain enough information to compromise the key, such 582 intended uses are unlikely to make the registration key insecure. 583 Similarly, the mobile node is unlikely to use the same registration 584 key for enough registrations to make the single smooth handover 585 insecure. Thus, the registration key does not need to have any 586 particular lifetime unless it is used for purposes of data hiding in 587 addition to registration and smooth handover. 589 5.1. Registration Key Reply from Home Agent Subtype 591 The home agent uses the Registration Key Reply from Home Agent 592 extension in Registration Reply messages to securely deliver a 593 registration key to the mobile node. For this extension, the 594 subtype data is the registration key encoded using the SPI in the 595 Registration Reply. The method used is specified in section 3.1, 596 where the registration reply payload used in the encoding includes 597 all the data up to and including the SPI field in the Generalized 598 Key Reply extension for which this is a subtype. This key reply 599 extension is authenticated along with the rest of the Registration 600 Reply message, and thus no additional authenticator is included in 601 the extension. 603 The home agent SHOULD also include another key reply extension which 604 delivers the same key to the mobile node's new foreign agent. 606 5.2. Mobile Node Public Key Reply Subtype 608 When the mobile node sends a Mobile Node Public Key Request to its 609 prospective foreign agent, the foreign agent can immediately select 610 a registration key. The foreign agent encodes this registration key 611 into the Mobile Node Public Key Reply extension to the Registration 612 Request. The foreign agent also stores the key and the SPI from 613 the Mobile Node Public Key Request for future reference as a 614 potential security association with the mobile node. The home agent 615 subsequently transcribes this extension without change into the 616 Registration Reply message. Thus, the mobile node is protected 617 against common man-in-the-middle attacks. 619 The subtype data for this subtype is the Registration Key encoded by 620 using the mobile node's public key. 622 5.3. Foreign Agent Public Key Reply Subtype 624 This extension is sent in response to a Foreign Agent Public Key 625 Request extension. The home agent selects a registration key and 626 encodes it twice into two separate key reply extensions of the 627 Registration Reply message. The Foreign Agent Public Key Reply 628 extension contains the registration key encoded with the public key 629 of the foreign agent. 631 The foreign agent also stores the SPI from the registration key 632 request extension sent by the mobile node, for future reference 633 as a potential security association with the mobile node if the 634 registration is successful. 636 The subtype data for this extension is the Registration Key encoded 637 by using the foreign agent's public key. 639 5.4. Diffie-Hellman Key Reply Subtype 641 The Diffie-Hellman Registration Key Reply extension should be 642 included in a Registration Request message sent by a home agent to 643 the foreign agent, when the following conditions are met: 645 - the mobile node has included a Registration Key Request extension 646 in its registration request message, 648 - the foreign agent has no public key or security association with 649 the home agent or mobile node, and 651 - the foreign agent has included one of the Diffie-Hellman 652 Registration Key Request extensions in its Registration Request 653 message to the home agent (see sections 4.5 and 4.6). 655 The home agent uses the same reply extension subtype (namely, the 656 Diffie-Hellman Key Reply subtype), in response to either of the 657 Diffie-Hellman key exchange request messages. 659 The subtype data for the Diffie-Hellman Registration Key Reply 660 extension, is just the Computed Value resulting from the requested 661 Diffie-Hellman computation. 663 6. Mobile Node Key Requests 665 If the mobile node receives an Agent Advertisement from a foreign 666 agent with the `S' bit set, the mobile node may attempt a smooth 667 handoff with its previous foreign agent, as well as asking its 668 new foreign agent to aid in supplying a registration key for the 669 new registration. The following code fragment illustrates a good 670 algorithm for the mobile node to use during registration, to allow 671 flexibility in the selection of the new registration key. Any 672 particular mobile node may be configured to use one, none, or 673 any subset of the key establishment procedures specified in this 674 document. 676 The Mobile Node executes the following algorithm upon new FA 677 registration. This algorithm is intended to reduce complexity at 678 the mobile node. But, the Home Agent MAY require that the mobile 679 node use Public Key if required by the policy of the home domain 680 administration, instead of relying on other means for generating 681 keys. 683 If (Challenge advertised) { 684 Add challenge data to Registration Request 685 /* If NewFA uses Elliptic, challenge is MD5 (N*(X,Y)) */ 686 } 687 If (NewFA advertises 'S') { 688 if (have registration key with previous FA) { 689 /* append Previous Foreign Agent Notification (PFAN) */ 690 If (received opaque-data) { /* See [2] */ 691 append opaque-data extension after PFAN; 692 } 693 } 694 if (have security association with current FA) { 695 ; /* Don't need to create a registration key */ 696 } 697 else if (HA expects Public Key) { 698 Add public key extension; /* FA will choose key */ 699 } 700 else if (opaque-data || SA with NewFA) { 701 create MN-FA extension; 702 } 703 else { 704 Send Registration Key Extension; /* Let them do it */ 705 } 706 } 708 In this way, the mobile node can get a registration key whenever one 709 can be produced by any mechanism specified in this document. 711 7. Miscellaneous Home Agent Operations 713 7.1. Receiving Registration Key Requests 715 When the home agent receives a Registration Request message, an 716 extension requesting a registration key (Section 4) may be present 717 in the message. Then the home agent is expected to provide a 718 registration key to the mobile node and its foreign agent, as 719 described in Section 3. When needed, the home agent employs a good 720 algorithm for producing random keys [6] and encrypts the result 721 separately for use by the foreign agent and by the mobile node. 722 The chosen key is encoded under the mobility security association 723 shared between the home agent and the mobile node as described in 724 section 3.1. The regrep data used as part of the encoding includes 725 all the preceding Registration Reply data up to and including the 726 Length field of the Generalized MN-FA Reply extension for which the 727 Registration Key Reply is the subtype. The encrypted key is the 728 placed as the Subtype Data of the Registration Key Reply from Home 729 Agent extension (section 5.1) in the Registration Reply message. 731 The same key may also be encrypted under the mobility security 732 association shared between the home agent and the foreign agent, 733 and the encoding placed in a registration key reply extension in 734 the Registration Reply message. When the home agent transmits the 735 Registration Reply message containing reply extensions to the foreign 736 agent, the message has the overall structure as follows: 737 ------------------------------------------------------------- 738 |IP|UDP| Reg-Reply| MN Key| FA Key| MN-HA Auth.| HA-FA Auth.| 739 ------------------------------------------------------------- 740 The HA-FA authentication extension is only included if the home agent 741 and foreign agent share a mobility security association. 743 If the home agent cannot satisfy a request to select a registration 744 key, but the other Mobile IP registration requirements are fulfilled, 745 it MAY still approve the registration reply. In this case, the home 746 agent returns a Registration Reply message Code indicating success, 747 but does not include any key reply extension. 749 7.2. Diffie-Hellman Considerations 751 If the home agent receives one of the Diffie-Hellman key request 752 extensions, (see sections 4.5 and 4.6), then it has to pick a good 753 random number [6] and use it to complete the key exchange algorithm. 754 Suppose the home agent picks the random number Z. Then the home agent 755 applies the group operation Z times on the data received from the 756 foreign agent, which amounts to either exponentiation to the Zth 757 power, or else (in the elliptic case) to multiplication by Z of the 758 incoming solution point. The result of this operation gives the 759 registration key, which is then encoded in a Registration Key Reply 760 from Home Agent extension and sent to the mobile node. 762 In order to deliver the registration key to the foreign agent, the 763 home agent takes the same number Z and applies it to the generator 764 (or, in the elliptic case, the generating point). The result of 765 that operation is placed in a Diffie-Hellman Key Reply extension and 766 sent to the foreign agent so that the foreign agent can compute the 767 registration key. 769 When a home agent receives one of the Diffie-Hellman Key Request 770 subtypes along with a Challenge extension, the Challenge Value MUST 771 be checked against the computed value selected by the foreign agent. 772 The rule by which the computed value is to be checked is described in 773 section 8.2. 775 7.3. Home Agent Supplying Registration Keys 777 When the home agent receives a Registration Request message 778 with registration key extensions, it usually performs one of two 779 operations: 781 - select and encode a registration key for both the mobile node and 782 the foreign agent, or 784 - transcribe the registration key already selected by the foreign 785 agent into the appropriate extension to the Registration Reply 786 message. 788 Both operations ensure that the mobile node and home agent are 789 dealing with the same foreign agent. Whenever the home agent inserts 790 one of the following key reply extensions in the Registration Reply, 792 1. Registration Key Reply from Home Agent 793 2. Mobile Node Public Key Reply 794 3. Foreign Agent Public Key Reply 796 each key reply extension MUST precede the MN-HA Authentication 797 Extension. The Diffie-Hellman Key Reply, on the other hand, is 798 consumed by the foreign agent, and SHOULD be located after the MN-HA 799 Authentication Extension whenever the Challenge value is supplied 800 with the Registration Request message. The Challenge value is 801 typically sufficient to protect against man-in-the-middle attacks. 803 When building the Registration Reply, the home agent should follow 804 an algorithm such as the one illustrated below, which is useful for 805 the registration key establishment methods currently specified. The 806 underlying theme of the algorithm is that the home agent just does as 807 it is told. 809 if (Foreign Agent Reg. Key Request) { /* HA-FA assn_exists */ 810 /* Pick a key, encode for FA */ 811 /* append MN Key Reply to Registration Reply */ 812 /* append FA key reply to Registration Reply */ 813 } 814 If (MN public key) { 815 /* Transcribe the encoded key */ 816 /* append MN Key Reply to Registration Reply */ 817 } 818 If (FA public key) { 819 /* Pick a key, encode for FA */ 820 /* append MN Key Reply to Registration Reply */ 821 /* append FA Public Key Reply to Registration Reply */ 822 } 823 If (elliptic) { 824 /* Pick multiplier `Z', do the D-H algorithm */ 825 } 826 else { 827 /* do nothing */ 828 } 829 /* append mobile-home authentication extension at end */ 831 /* Encode the key for the MN if necessary, use existing SPI */ 832 /* New registration key will then be invoked by SPI from */ 833 /* key request extension. */ 835 8. Miscellaneous Foreign Agent Operations 837 This section details various operational considerations important 838 for foreign agents wishing to support smooth handoff, including 839 algorithms for establishment of registration keys. 841 8.1. Foreign Agent Handling Key Requests 843 The foreign agent, when it receives a request from a mobile node for 844 a registration key, is faced with a variety of possible actions. The 845 action selected by the foreign agent depends on the resources it has 846 available. The foreign agent typically attempts to reduce as much 847 as possible the computational burden placed on the mobile node, but 848 relies on the security association with sufficient cryptographic 849 strength to encode the registration key. Furthermore, if the foreign 850 agent performs the key selection, it still supplies the encoded key 851 in an extension to the Registration Request message, so that the home 852 agent will authenticate its choice of registration key to the mobile 853 node. This strategy reduces the opportunity for interlopers to mount 854 man-in-the-middle attacks. 856 The following code fragment, executed when the foreign agent receives 857 a key request of some variety, exhibits an algorithm which may be 858 useful for implementors of foreign agents. The algorithm is supposed 859 to be used when a foreign agent gets a Registration Request with 860 one of the key request extensions included. The foreign agent uses 861 the elliptic curve Diffie-Hellman key exchange as a last resort, 862 with implicit well-known parameters (X-coordinate, Y-coordinate, 863 Extension-Field), picking multiplier `N'. 865 If (opaque-data) { 866 /* extract key/replay protection */ 867 /* check against replays */ 868 /* drop registration unless opaque-data passes check */ 869 } 871 if (Previous Foreign Agent Notification (PFAN)) { 872 /* Formulate Binding Update */ 873 /* Send with Smooth Handoff Authentication Extension */ 874 } 876 If (MN-FA authentication extension) { 877 /* Verify before proceeding */ 878 } 880 If (Registration Key Extension) { 881 /* Set up registration key */ 882 if (have mobile node's public key) { 883 /* pick a good key */ 884 /* append MN Public Key Reply to Reg. Request */ 885 } 886 If (opaque-data valid) { 887 /* Use old extension */ 888 } 889 if (have security association with HA) { 890 /* Append FA key request to Registration Request */ 891 } 892 If (FA public key) { 893 /* Send it; HA will pick key */ 894 } 895 else { 896 /* pick elliptic point multiplier `N' */ 897 /* append result to the Registration Key Request */ 898 } 899 } 901 8.2. Advertising Digestified Diffie-Hellman Computations 903 When a foreign agent advertises the `S' bit, it is expected to 904 support Diffie-Hellman key exchange with the home agent for those 905 cases when the mobile node asks for a registration key, but no other 906 means are available for producing registration keys. In order to 907 protect against man-in-the-middle attacks, the home agent and the 908 mobile node need some way to make sure that they are dealing with 909 the same foreign agent. This can be accomplished by digestifying 910 the Diffie-Hellman computed values, and advertising the digest as a 911 Challenge Value for the mobile node. The digest is produced by using 912 MD5 on the computed value, with no other data prepended or appended. 914 In order to reduce bandwidth requirements for this advertisement, the 915 foreign agent MAY truncate the MD5 digest to as few as the initial 916 4 bytes. Since all of the bits of the MD5 digest are considered 917 equally random, applying further operations (such as XOR) might even 918 reduce the resulting cryptographic strength. 920 9. Security Considerations 922 Whenever a key is exchanged by use of the Diffie-Hellman algorithm, 923 the process is susceptible to the "man-in-the-middle" attack, as 924 detailed in Appendix A. This attack is not known to produce further 925 difficulty, and susceptibility is already inherent in the operation 926 of the base Mobile IP specification [11]. Attention to this detail 927 is warranted during any future changes to the Route Optimization 928 protocol. Ways to reduce the risk should be incorporated into future 929 revisions of this document. Already, the risk of such an attack 930 against the registration key distribution mechanisms specified in 931 this document are greatly reduced by the authentication of the 932 Registration Reply by the home agent. 934 The calculation of the authentication data described in Section 3.1 935 is specified to be the same as in the base Mobile IP document for 936 ease of implementation. There is a better method available (HMAC), 937 specified in RFC 2104 [8]. If the base Mobile IP specification is 938 updated to use HMAC, then this route optimization specification 939 should also be updated similarly. 941 Registration keys should typically NOT be used as master keys for 942 producing other derived keys, because of the man-in-the-middle attack 943 associated with unidentifiable foreign agents. 945 References 947 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 948 Levels. Request for Comments (Best Current Practice) 2119, 949 Internet Engineering Task Force, March 1997. 951 [2] P. Calhoun, Haseeb Akhtar, Emad Qaddoura, and N. Asokan. 952 Minimal Latency Secure Hand-off. 953 draft-calhoun-mobileip-min-lat-handoff-01.txt, February 2000. 954 (work in progress). 956 [3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 957 Challenge/Response Extension. 958 draft-ietf-mobileip-challenge-08.txt, January 2000. (work in 959 progress). 961 [4] CDPD consortium. Cellular Digital Packet Data Specification. 962 P.O. Box 809320, Chicago, Illinois, July 1993. 964 [5] W. Diffie and M. Hellman. New Directions in Cryptography. IEEE 965 Transactions on Information Theory, 22:644--654, November 1976. 967 [6] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 968 Recommendations for Security. Request for Comments 969 (Informational) 1750, Internet Engineering Task Force, December 970 1994. 972 [7] N. Koblitz. Elliptic Curve Cryptosystems. Mathematics of 973 Computation, 48(177):203--209, 1987. 975 [8] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 976 for Message Authentication. Request for Comments 977 (Informational) 2104, Internet Engineering Task Force, 978 February 1997. 980 [9] V. S. Miller. Use of Elliptic Curves in Cryptography. In 981 Advances in Cryptology -- CRYPTO '85 Proceedings, pages 982 417--426, Berlin, 1986. Springer-Verlag. 984 [10] H. Orman. The OAKLEY Key Determination Protocol. Request for 985 Comments (Informational) 2412, Internet Engineering Task Force, 986 November 1998. 988 [11] C. Perkins. IP Mobility Support. Request for Comments 989 (Proposed Standard) 2002, Internet Engineering Task Force, 990 October 1996. 992 [12] C. Perkins and D. Johnson. Route Optimization in Mobile IP. 993 Internet Draft, Internet Engineering Task Force, February 1999. 994 Work in progress. 996 [13] Charles E. Perkins and Pat R. Calhoun. Generalized Key 997 Distribution Extensions for Mobile IP. 998 draft-ietf-mobileip-gen-key-00.txt, February 2000. (work in 999 progress). 1001 [14] Bruce Schneier. Applied Cryptography: Protocols, Algorithms, 1002 and Source Code in C. John Wiley, New York, NY, USA, 1994. 1004 [15] Richard Schroeppel, Hilarie Orman, and Sean OMalley. Fast Key 1005 Exchange with Elliptic Curve Systems. In Advances in Cryptology 1006 -- CRYPTO '95 Proceedings. Springer-Verlag, 1995. 1008 A. Using Diffie-Hellman with the Foreign Agent 1010 Diffie-Hellman public key cryptosystems allows two parties to 1011 establish a shared secret key, such that the shared secret key cannot 1012 be determined by other parties overhearing the messages exchanged 1013 during the algorithm. It is used in other well-known protocols that 1014 require a key exchange, such as the Cellular Digital Packet Data 1015 (CDPD) system [4]. These systems work because they are employed 1016 where the ``discrete logarithm'' problem is currently intractable. 1017 The discrete logarithm problem can be stated as follows: given g 1018 and g*N (where `*' means repeating the group operation between g and 1019 itself N times), find the value of N. 1021 The two group operations of most interest are: 1023 1. multiplication, in the modular field of integers mod p 1025 2. addition, in the group of solution points to particular elliptic 1026 curves 1028 For a multiplicative group, repeating the group operation by an 1029 element on itself N times amounts to (integer) exponentiation by N. 1030 For an additive group, repeating the group operation N times amounts 1031 to an integer multiplication operation on that group element. In 1032 the elliptic curve group, the elements are not integers, but instead 1033 ordered pairs (X,Y) which represent solutions to the elliptic curve. 1035 The first groups have the advantage of being easy to understand. The 1036 second groups, proposed later than the first, have the advantage of 1037 being much faster computationally. 1039 For the purposes of the explanation in this appendix, suppose that 1040 the first party in the key exchange is the foreign agent, and the 1041 second party is the home agent. This would be the situation whenever 1042 these key exchanges are used to generate Registration Keys using the 1043 methods specified in this document. 1045 In both cases, the result depends on the fact that the group 1046 operation in the relevant groups is commutative, so that M*(N*g) == 1047 N*(M*g). When the group operation is multiplication, this is more 1048 conventionally written as (g^M)^N = (g^N)^M. 1050 This technique is known to suffer from a man-in-the-middle attack. 1051 In other words, a malicious agent could pretend to the foreign 1052 agent to be the home agent, and pretend to the home agent to be the 1053 foreign agent, and participate as an unwanted third member in the 1054 key exchange. Armed with knowledge of the registration key, the 1055 malicious agent could at a later time disrupt the smooth handoff, or 1056 initiate the handoff prematurely. The man-in-the-middle attack is 1057 no worse than a malicious agent pretending to be a foreign agent in 1058 any other circumstance; that is, it is no worse than already exists 1059 with the base Mobile IP specification [11]. In the key distribution 1060 mechanisms specified in this document, the man-in-the-middle attack 1061 is prevented in most circumstances because each registration key is 1062 effectively authenticated by the home agent. Moreover, the mobile 1063 node and/or the foreign agent are presumably in direct contact, so 1064 that such an attack is detectable if either of the nodes notices the 1065 reception of duplicate packets, and corrective action taken. 1067 Establishing a registration key using Diffie-Hellman is 1068 computationally more expensive than most methods described in 1069 Section 3. The use of Diffie-Hellman described here, though, is 1070 designed to allow the Diffie-Hellman computations to be overlapped 1071 with other activities. The foreign agent may choose (or be manually 1072 configured with) the prime and generator values (or, the generating 1073 point and Galois field values) at any time, or may use the same 1074 values for a number of registrations. The home agent may also choose 1075 its private random number and calculate its computed value at any 1076 time. For example, after completing one registration, the foreign 1077 agent may choose the private random number for its next registration 1078 and begin the computation of its new computed value based on this 1079 random number, such that it has completed this computation before 1080 it is needed in a registration from another mobile node. Even more 1081 simply, the foreign agent may use the same private random number and 1082 computed value for any number of registrations. 1084 B. Diffie-Hellman Key Exchange in the Field of Integers mod p 1086 Briefly, the Diffie-Hellman algorithm involves the use of two large 1087 public numbers, a prime number (p) and a generator (g). The prime 1088 number and the generator must be known by both parties involved 1089 in the algorithm, but do not have to be secret; these values may 1090 be the same or different for each execution of the algorithm and 1091 are not used once the algorithm completes. Each party chooses a 1092 private random number, produces a computed value based on this 1093 random number, the prime and the generator, and sends the computed 1094 value in a registration message extension to the other party. The 1095 foreign agent creates the computed value f = g^N mod p, where N is its 1096 private random number, p is the prime which is sent as part of the 1097 transaction, and g is the generator. The home agent then creates 1098 another computed value h = g^y mod p, where M is its own private 1099 random number, and p and g are the same as for the foreign agent. 1100 Each party then computes the (same) shared secret key using its own 1101 private random number, the computed value received from the other 1102 party, and the prime and generator values. Since f^M = (g^N)^M = C = 1103 (g^M)^N = f^N, the foreign agent and the home agent can compute a shared 1104 value C that is not detectable by other network nodes. The shared 1105 secret is the number C mod p, where p is the same prime number as 1106 before. Knowing the computed values mod p does not enable passive 1107 listeners to determine the private values, so the algorithm allows 1108 the two parties to agree on an otherwise undetectable secret. 1110 If Diffie-Hellman were substantially less computationally expensive, 1111 it could likely serve the needs of many mobile nodes. But, the 1112 algorithm itself uses exponentiations or strange additions involving 1113 numbers with hundreds of digits. That may take a long time for 1114 some mobile nodes to do, time which would come at the expense 1115 of interactivity or convenient operation of user application 1116 programs. For this reason, Diffie-Hellman is considered the least 1117 desirable alternative for establishing registration keys. Since it 1118 requires no other configuration, it is nevertheless required in all 1119 implementations of foreign agents that advertise support for smooth 1120 handoffs. 1122 C. Diffie-Hellman Key Exchange in Elliptic Curve Groups 1124 In order to multiply a generating point (X,Y) by a large number N, it 1125 is necessary to add the point to itself N times. However, addition 1126 in elliptic curve groups is not simple componentwise addition; (X,Y) 1127 + (A,B) is NOT EQUAL to (X+A,Y+B). Instead, in order for the group 1128 addition to yield only points that are solutions to the elliptic 1129 curve, a special formula for group addition must be used. 1131 Suppose, then, that one is given two points (X1, Y1) and (X2, Y2) in 1132 the elliptic curve group of all solutions to the equation y^2 + x*y 1133 = x^3 + a*x^2 + b. The function Plus (X1, Y1, X2, Y2) is defined as 1134 follows. 1136 - if X1 = X2 and Y1 = Y2, then Plus (X1, Y1, X2, Y2) = Double (X1, 1137 Y1), where Double (X, Y) is as defined below. 1139 - otherwise, if X1 = X2 but Y1 != Y2, then 1140 Plus (X1, Y1, X2, Y2) = (0,0) 1142 - otherwise, Plus (X1, Y1, X2, Y2) = (V, W), where 1144 i. V = L^2 + L + X1 + X2 + a 1146 ii. W = L*(X1 + V) + V + Y1, and 1148 iii. L = (Y1 + Y2)/(X1 + X2) 1150 The function Double (X, Y) is defined as follows: 1152 - if X = 0, then Double (X, Y) = (0,0) 1154 - otherwise, Double (X, Y) = (V, W), where 1156 i. V = L^2 + L + a, 1158 ii. W = X^2 + (L + 1) * X, and 1160 iii. L = X + Y/X 1162 The above formulas are given in a publication by Richard Schroeppel, 1163 Hilarie Orman, and Sean O'Malley [15]. Note that there are many 1164 computational shortcuts available. The referenced publication is a 1165 good start; one should also consult [14]. 1167 The following elliptic curve characteristics are used by default, 1168 and until a method is specified for offering non-default values. 1169 This information is taken from appendix E.4 of RFC 2412 [10], and is 1170 reproduced here only for completeness. 1172 The elliptic curve is based on the Galois field GF[2^185] with 2^185 1173 field elements. The irreducible polynomial for the field is 1175 u^185 + u^69 + 1. 1177 The equation for the elliptic curve is 1179 Y^2 + X Y = X^3 + A X + B. 1181 X, Y, A, B are elements of the field. For the curve specified, A = 0 1182 and 1184 B = u^12 + u^11 + u^10 + u^9 + u^7 + u^6 + u^5 + u^3 + 1. 1186 B is represented in binary as the bit string 1111011101001; in 1187 decimal this is 7913, and in hex 1EE9. 1189 The generator is a point (X,Y) on the curve (satisfying the curve 1190 equation, mod 2 and modulo the field polynomial); 1192 X = u^4 + u^3 and Y = u^3 + u^2 + 1. 1194 For this extension, the subtype data is a standard representation 1195 using a point compression technique (not defined in RFC 2412) for the 1196 computed value of (V,W) = N*(X,Y), specified as follows. 1198 Let (V,W) be a point of the elliptic curve group defined as above. 1199 Let OCTETS be the representation of V as bits right-justified into an 1200 integer number of octets. For instance, if V = 24(decimal), OCTETS 1201 = 18 shown as two hexadecimal digits. If V = 317(decimal), OCTETS 1202 = 013D shown as four hexadecimal digits. The number of hexadecimal 1203 digits needed to represent OCTETS will always be an even number since 1204 every byte of the representation takes two hexadecimal digits to 1205 represent. 1207 Then, define W0 to be zero (0) if V == 0; otherwise define W0 to be 1208 the rightmost bit of the field element W/V. If W0 == 0, then the 1209 subtype data will be 02 || OCTETS; otherwise the subtype data will be 1210 03 || OCTETS. Here, "||" means concatenation. 1212 To recover (V,W) from this standard representation, proceed as 1213 follows. 1215 If V == 0, then W = B^(2^184), where B = 7913 from the defining 1216 elliptic curve. W is the square root of B. Otherwise, compute the 1217 field element W = V + a + B/(V^2) = V + 7913/(V^2). Find Z such 1218 that Z^2 + Z = W. Let Z0 be the rightmost bit of Z. If the received 1219 computed value has prefix 02, let W0 be 0; otherwise if the received 1220 computed value has prefix 02, let W0 be 1. If W0 != Z0, then let Z = 1221 Z + 1. Then, W = Z*V. 1223 Addresses 1225 The working group can be contacted via the current chairs: 1227 Basavaraj Patil Phil Roberts 1228 Nokia Corporation Motorola 1229 M/S M8-540 1230 6000 Connection Drive 1501 West Shure Drive 1231 Irving, TX 75039 Arlington Heights, IL 60004 1232 USA USA 1233 Phone: +1 972-894-6709 Phone: +1 847-632-3148 1234 EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com 1235 Fax : +1 972-894-5349 1237 Questions about this memo can also be directed to the authors: 1239 Charles E. Perkins David B. Johnson 1240 Communications Systems Lab Computer Science Department 1241 Nokia Research Center 5000 Forbes Avenue 1242 313 Fairchild Drive Pittsburgh, PA 15213-3891 1243 Mountain View, California 94043 Carnegie Mellon University 1244 USA USA 1245 Phone: +1-650 625-2986 Phone: +1-412-268-7399 1246 EMail: charliep@iprg.nokia.com E-mail: dbj@cs.cmu.edu 1247 Fax: +1 650 625-2502 Fax: +1-412-268-5576