idnits 2.17.1 draft-ietf-mobileip-regkey-02.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 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 4 instances of too long lines in the document, the longest one being 1 character 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 426: '...nodes MAY be configured to avoid using...' RFC 2119 keyword, line 458: '...he foreign agent SHOULD use the Foreig...' RFC 2119 keyword, line 531: '...rt smooth handovers SHOULD support the...' RFC 2119 keyword, line 626: '... The home agent MUST also include ano...' RFC 2119 keyword, line 727: '...foreign agent MAY truncate the MD5 dig...' (4 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 (~~), 4 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 14 July 2000 David B. Johnson 4 Carnegie Mellon University 5 N. Asokan 6 Nokia Research Center 8 Registration Keys for Route Optimization 9 draft-ietf-mobileip-regkey-02.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 to 15 the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, and 22 its working groups. Note that other groups may also distribute working 23 documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 33 http://www.ietf.org/shadow.html. 35 Abstract 37 Route optimization defines extensions to Mobile IP Registration 38 Requests that allow datagrams in flight when a mobile node moves, and 39 datagrams sent based on an out-of-date cached binding, to be forwarded 40 directly to the mobile node's new binding. These extensions for smooth 41 handoff require a registration key to be established between the mobile 42 node and foreign agent. This document defines additional extensions to 43 the registration requests to allow for the establishment of single-use 44 registration keys between a mobile node and foreign agent. 46 Contents 48 Status of This Memo i 50 Abstract i 52 1. Introduction 1 54 2. Terminology 1 56 3. Establishing Registration Keys 2 57 3.1. The Home Agent as a KDC . . . . . . . . . . . . . . . . . 4 58 3.2. Using the Foreign Agent as a KDC . . . . . . . . . . . . 5 60 4. Registration Key Request Extension Subtypes 6 61 4.1. Registration Key Request Subtype . . . . . . . . . . . . 7 62 4.2. Foreign Agent Registration Key Request Subtype . . . . . 8 63 4.3. Mobile Node Request Via Public Key Subtype . . . . . . . 8 64 4.4. Foreign Agent Public Key Request Subtype . . . . . . . . 9 65 4.5. Diffie-Hellman Registration Key Request Subtype . . . . . 9 66 4.6. Diffie-Hellman Elliptic Curve Registration Key Request . 10 68 5. Generalized MN-FA Key Reply Subtypes 11 69 5.1. Registration Key Reply from Home Agent Subtype . . . . . 12 70 5.2. Mobile Node Public Key Reply Subtype . . . . . . . . . . 12 71 5.3. Foreign Agent Public Key Reply Subtype . . . . . . . . . 13 72 5.4. Diffie-Hellman Key Reply Subtype . . . . . . . . . . . . 13 74 6. Authentication of Foreign Agent 14 76 7. Mobile Node Key Requests 15 78 8. Miscellaneous Home Agent Operations 16 79 8.1. Receiving Registration Key Requests . . . . . . . . . . . 16 80 8.2. Diffie-Hellman Considerations . . . . . . . . . . . . . . 17 81 8.3. Foreign Agent Authentication Considerations . . . . . . . 17 82 8.4. Home Agent Supplying Registration Keys . . . . . . . . . 18 84 9. Miscellaneous Foreign Agent Operations 19 85 9.1. Foreign Agent Handling Key Requests . . . . . . . . . . . 19 87 10. Security Considerations 21 89 11. Acknowledgements 21 91 References 22 92 A. Using Diffie-Hellman with the Foreign Agent 23 94 B. Diffie-Hellman Key Exchange in the Group of Integers mod p 25 96 C. Diffie-Hellman Key Exchange in Elliptic Curve Groups 25 98 Addresses 28 100 1. Introduction 102 The Binding Update is a Route Optimization [12] message that changes 103 the routing of IP datagrams to the mobile node. It can be authenticated 104 using mechanisms similar to those specified for the base Mobile IP 105 protocol [11]. The authentication relies on a mobility security 106 association established in advance between the sender and receiver of 107 such messages. The Binding Update message can be used to accomplish a 108 smooth handoff for a mobile node moving from a previous foreign agent to 109 a new foreign agent. Such smooth handoffs rely on the Previous Foreign 110 Agent Notification extension [12], which requires the transmission of a 111 Binding Update to the previous foreign agent created by the mobile node 112 after it moves. However, when a mobile node registers with a foreign 113 agent, typically it does not share a security association with the 114 foreign agent. In order for the foreign agent to process future Binding 115 Updates that it may receive from the mobile node, it needs to establish 116 such a security association. 118 This document is a specification for some useful methods for 119 establishing the necessary mobility security association between the 120 mobile node and its new foreign agent. 122 2. Terminology 124 This document makes use of many terms defined in RFC 2002 [11] to 125 describe the base Mobile IP protocol, as well as terms defined in the 126 specification for Route Optimization [12]. In addition, the following 127 terms are used: 129 Binding cache 131 A cache of mobility bindings of mobile nodes, maintained by a 132 node for use in tunneling datagrams to those mobile nodes. 134 Group Element 136 an element of one of the groups used to define the 137 Diffie-Hellman key exchange extensions. 139 Field Element 141 an element of one of the Galois Fields used to define 142 the elliptic curve group for Diffie-Hellman key exchange 143 extensions. This usage must be carefully distinguished from 144 the use of the word "field" to denote a designated part of the 145 data for a protocol unit (e.g., "Length field"). 147 Registration Key 149 A secret key shared between a mobile node and a foreign 150 agent, that may optionally be established during registration 151 with that foreign agent. When later moving and registering 152 a new care-of address elsewhere, the mobile node uses the 153 registration key shared with its previous foreign agent to send 154 it an authenticated Binding Update to this foreign agent. The 155 registration key forms the basis for the mobility security 156 association needed between the mobile node and the foreign 157 agent. 159 Registration Lifetime 161 The registration lifetime is the time duration for which a 162 binding is valid. The term remaining registration lifetime 163 means the amount of time remaining for which a registration 164 lifetime is still valid, at some time after the registration 165 was approved by the home agent. 167 Triangle Routing 169 A situation in which a correspondent node's packets to a Mobile 170 Node follow a path which is longer than the optimal path 171 because the packets must be forwarded to the Mobile Node via a 172 Home Agent. 174 In formulas requiring exponentiation, the `^' character is used. 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [1]. 180 3. Establishing Registration Keys 182 Foreign agents may become cheap and widely available, as Mobile IP 183 becomes fully deployed. Mobile nodes will likely find it difficult 184 to manage long-term security relationships with so many foreign 185 agents. To securely perform the operations needed for smooth handoffs 186 from one foreign agent to the next, however, any careful foreign 187 agent should require assurance that it is getting authentic handoff 188 information, and not arranging to forward in-flight datagrams to a bogus 189 destination. The messages described in this document are used with the 190 Mobile IP Registration Request and Registration Reply messages to create 191 (sufficient) trust between mobile node and foreign agent when none 192 exists beforehand, while allowing the use of fully trustworthy security 193 associations between foreign agents and mobile nodes whenever they do 194 exist. 196 Note that the mobile node may often be unable to verify the identity 197 of the foreign agent. It must then act only on the presumption that 198 the foreign agent is performing its duties by correct adherence to 199 protocol. The exact identity of the foreign agent is not crucial to the 200 process of establishing a registration key. Even if the identity of 201 the foreign agent were verifiable, it would be insufficient because the 202 mobile node would still not have any way of knowing whether the foreign 203 agent were trustworthy. Only an agreement to follow protocol can be 204 expected or enforced. If there is appropriate infrastructural support, 205 the trustworthiness of the foreign agent may be established in firmer 206 fashion. But the needed public key and trust management infrastructures 207 seem to be several years distant. Therefore, the methods in this 208 document enable a mobile node to create a registration key with an 209 anonymous foreign agent (i.e., one whose identity we cannot establish) 210 during the registration process. There are several proposed methods 211 for establishing a registration key, discussed in order of declining 212 preference. Other methods of establishing keys may become available in 213 the future. 215 1. If the foreign agent and mobile node share a security 216 association, it can be used to secure the Previous Foreign Agent 217 Notification without the need to establish a registration key. 219 2. If the home agent and foreign agent share a security association, 220 the home agent can provide the new registration key to the FA. 222 3. If the mobile node can transfer key information between foreign 223 agents that trust each other, it can use the same key as it had 224 used with its previous foreign agent [2]. 226 4. If the foreign agent has a public key, it can again use the home 227 agent to supply a registration key. 229 5. If the mobile node includes its public key in its Registration 230 Request, the foreign agent can choose the new registration key. 232 6. The mobile node can aid its home agent and its foreign agent 233 execute a Diffie-Hellman key exchange protocol [5], using the 234 method for elliptic curves [7, 9], or using the more familiar 235 method involving modular exponentiations. 237 Once the registration key is established, the smooth handoff method 238 can be used [12]. The following sections give a brief overview of the 239 above enumerated methods for establishing the registration key. 241 If a request for key establishment cannot be accommodated by the 242 foreign agent and/or the home agent, then the mobile node's key request 243 must go unfulfilled. This does not mean that the Registration Request 244 itself fails, so the same status code will be returned by the home agent 245 to the mobile node. The mobile node has to be able to handle the case 246 in which it has requested a key but the Registration Reply arrives 247 without any key reply extension. This could happen even when the 248 foreign agent has advertised its willingness to offer smooth handoffs, 249 and the mobile node has supplied all the necessary parameters. The 250 effect will likely be a less than smooth handover. 252 3.1. The Home Agent as a KDC 254 Crucial to methods (2) and (4) listed above is that the home 255 agent and mobile node already are known to share a mobility security 256 association, which can be used to encode the registration key for 257 delivery to the mobile node. Thus, if the home agent can securely 258 deliver the key to the foreign agent, it can be used as a Key 259 Distribution Center (KDC) for the mobile node and its new foreign 260 agent. The mobile node requests this by including a Registration Key 261 Request extension in its Registration Request message. When the home 262 agent chooses the registration key, it returns the key in two different 263 extensions to the Registration Reply. One extension has the encrypted 264 key for the foreign agent, and the other extension has the same key 265 encrypted differently for the mobile node. 267 For the registration key to be established using this method, the 268 home agent must be able to securely transmit an encrypted copy of the 269 registration key to the foreign agent. This is straightforward if the 270 foreign agent already has a mobility security association with the home 271 agent. If mobile nodes from some home network often visit a foreign 272 agent, then the effort of creating such a mobility security association 273 between that foreign agent and the home agent serving their home network 274 may be worthwhile. 276 If such a mobility security association between the home agent 277 and foreign agent does not exist, but the foreign agent has a public 278 (encryption) key available, it can send this public key to the home 279 agent and ask the home agent to use it to encode the registration key. 280 In order for this channel to be confidential, the home agent must be 281 sure that the public key does in fact belong to the current foreign 282 agent of the mobile node (the exact identity of the foreign agent is not 283 important). Otherwise an attacker located between the foreign agent and 284 the home agent can replace the foreign agent's public key with his own 285 public key. This type of attack is known as the ``man-in-the-middle'' 286 attack. We can prevent man-in-the-middle attacks by having the mobile 287 node effectively certify the foreign agent's public key. This technique 288 is described in more detail in section 6. 290 In the absenece of all of the above, the foreign agent and the home 291 agent can use the Diffie-Hellman key exchange protocol to create the 292 registration key. The home agent can send this registration key to the 293 mobile node by including it, suitably encoded, in an extension of the 294 Registration Reply. The basic Diffie-Hellman key exchange protocol 295 is susceptible to the man-in-the-middle attack as well. The same 296 prevention technique as in the foreign agent public key case applies. 298 Having the home agent choose the registration key is preferable 299 to asking the mobile node to pick a good registration key, because 300 doing so may depend upon using resources not available to all mobile 301 nodes; simply selecting pseudo-random numbers is by itself a significant 302 computational burden. Moreover, allowing the home agent to pick the key 303 fits well into the existing registration procedures. On the other hand, 304 it is conceivable that a mobile node could do with less than perfect 305 pseudo-random numbers as long as the registration key were to be used in 306 the restricted fashion envisioned for smooth handoffs. 308 Note that MD5 can be used here for the purpose of transmitting 309 registration keys, secure against eavesdroppers. The expression 311 expr1 == MD5(secret | regrep | secret) XOR (key) 313 (where regrep is the Registration Reply message payload up to but not 314 including the encoded key data, and XOR is exclusive-or) can be included 315 within the appropriate Registration Reply extension. This encodes the 316 key in a way which allows recovery only by the recipient. It is secure 317 against replay because of the Identification within the Registration 318 Reply message. The recipient recovers the key by computing 320 expr2 == MD5(secret | regrep | secret) 322 which then yields (key == expr1 XOR expr2). Use of MD5 avoids 323 entanglements with the legal issues surrounding the export of encryption 324 technology, and reducing the computational power needed to secure the 325 password against eavesdroppers. 327 3.2. Using the Foreign Agent as a KDC 329 When the foreign agent and mobile node share a mobility security 330 association, there is no need to pick a registration key. The mobile 331 node can secure its Binding Update to the foreign agent whenever it 332 needs to, by using the existing security association. This is the most 333 desirable case. 335 Otherwise, if available, the mobile node can include its public key 336 (such as RSA [14]) in its Registration Request to the foreign agent, 337 using a Mobile Node Public Key Request extension (see section 4.3). The 338 foreign agent chooses the new registration key and includes a copy of 339 it encrypted with the mobile node's public key, using a Foreign Agent 340 Public Key Reply extension (see section 5.3). This is sent to the home 341 agent for inclusion with the Registration Reply. 343 4. Registration Key Request Extension Subtypes 345 A Generalized MN-FA Key Request extension has been specified [13]. 346 This generalized extension contains the SPI that the mobile node wishes 347 to use with the registration key. Thus, it is guaranteed that the SPI 348 will not collide with another existing Mobility Security Association 349 already in place for the mobile node. 351 To simplify the discussion for protocol operations involving 352 a particular subtype, the generalized extension with a particular 353 subtype will typically be denoted as a specific extension, instead of 354 a generalized extension with a specific subtype. So, for instance, 355 there will be discussion using the terminology "Registration Key Request 356 extension", which should be interpreted to mean "Generalized Key Request 357 extension with subtype 1". Note that a key requested by any subtype of 358 this Generalized Registration Key Request extension is, by definition, 359 for use between the mobile node and the foreign agent handling its 360 Mobile IP Registration Request. The foreign agent stores the SPI from 361 the registration key request extension sent by the mobile node as part 362 of its pending registration request information. The SPI will be needed 363 if the registration key reply extension is returned in the Registration 364 Reply message from the home agent. 366 In this document, the following subtypes of the Generalized MN-FA Key 367 extension are defined: 369 1. Registration Key Request subtype (see section 4.1) 371 2. Foreign Agent Registration Key Request subtype (see section 4.2) 373 3. Mobile Node Request Via Public Key subtype (see section 4.3) 375 4. Foreign Agent Public Key Request subtype (see section 4.4) 377 5. Diffie-Hellman Registration Key Request subtype (see section 4.5) 379 6. Diffie-Hellman Elliptic Curve Registration Key Request extension 380 (see section 4.6) 382 Handling for these subtypes is specified in this section. These may 383 be used by mobile nodes or foreign agents to request the establishment 384 of a registration key. For each subtype, the MN-FA Key Request Subtype 385 Data of the Generalized Key Request extension has to be specified. 386 In this section, the MN-FA Key Request Subtype Data will generally 387 be referred as "the subtype data". See sections 7, 8.4, and 9 for 388 appropriate algorithms which allow each node to use the extensions that 389 most closely fit its configured requirements. 391 There are two Diffie-Hellman Key Request subtypes that may be 392 included by a foreign agent in a Registration Request message sent to 393 a home agent, if the other possible key establishment methods are not 394 available. For either subtype, the foreign agent should then select a 395 good pseudo-random registration key. The foreign agent initiates the 396 Diffie-Hellman key exchange algorithm (as described in Appendix A), and 397 includes a Diffie-Hellman Registration Key Request extension in the 398 Registration Request message sent to the home agent to initiate the 399 key exchange. The home agent will then complete the key exchange and 400 include the computed value in the Diffie-Hellman Registration Key Reply 401 extension in the Registration Reply sent to the mobile node, where that 402 extension can be authenticated as part of the reply message. 404 The two Diffie-Hellman key request subtypes differ in the creation 405 and processing of the Computed Value which appears in the subtype data. 407 4.1. Registration Key Request Subtype 409 The Registration Key Request subtype may be included in a 410 Registration Request to ask the foreign agent to supply a key by any 411 means it has available. The foreign agent may have a public key, or it 412 might have a security association with the home agent. Otherwise, the 413 foreign agent will attempt to employ a Diffie-Hellman key exchange. 415 If the foreign agent has advertised a Challenge value, and also 416 sets the `S' bit in its Agent Advertisements, then the mobile node 417 MUST include that Challenge value in its registration request [3]. 418 Furthermore, in this case, the Challenge value is derived from a 419 digested form of the next value that would be used, if needed, by the 420 foreign agent in its next key exchange with a home agent. Thus, if the 421 foreign agent sets the `S' bit but does NOT include a Challenge value, 422 the mobile node cannot be certain that the foreign agent is taking steps 423 to protect against the man-in-the-middle attack that can sometimes be 424 mounted against the key request methods used by the foreign agent. 425 While this is normally not an issue for registration keys, some mobile 426 nodes MAY be configured to avoid using the Registration Key Request 427 extension when the foreign agent does not advertise the Challenge value. 429 For this extension, the subtype data is empty. 431 4.2. Foreign Agent Registration Key Request Subtype 433 If the foreign agent receives a Registration Key Request from 434 a mobile node, and it has a security association with the home 435 agent, it may select a registration key and append the Foreign Agent 436 Registration Key Request extension to the Registration Request after the 437 mobile-home authentication extension. For this extension, the SPI in 438 the Generalized Key Request extension refers to the SPI of the security 439 association between the home agent and the foreign agent. 441 For this extension, the subtype data is the key selected by the 442 foreign agent and encoded according to the FA-HA security association. 444 4.3. Mobile Node Request Via Public Key Subtype 446 If the mobile node has a public key, it can ask its prospective 447 foreign agent to choose a registration key, and to use the mobile node's 448 public key to encode the chosen registration key. No eavesdropper will 449 be able to decode the registration key, even if the encoded key is 450 broadcast to all entities with access to the network medium used by the 451 mobile node. The foreign agent then includes the encoded registration 452 key in a Mobile Node Public Key Reply extension (see section 5.2) to 453 the Registration Request as it goes to the home agent. Then, the home 454 agent can insert the selected encoded registration key as part of the 455 authenticated data of the Registration Reply message. 457 However, if the foreign agent has a security association with the 458 mobile node's home agent, the foreign agent SHOULD use the Foreign Agent 459 Registration Key Request Subtype (see section 4.2) instead of using the 460 mobile node's public key to encode a registration key. 462 For the Mobile Node Request Via Public Key subtype, the subtype data 463 contains the mobile node's public key. 465 4.4. Foreign Agent Public Key Request Subtype 467 If the foreign agent has a public key, it can ask the mobile node's 468 home agent to choose a registration key, and then to use the foreign 469 agent's public key to encode the chosen registration key. As before, 470 no eavesdropper will be able to decode the registration key, even if 471 the encoded key is broadcast to all entities with access to the network 472 medium used by the home agent and the foreign agent. The home agent 473 then includes the encoded registration key in a Foreign Agent Public Key 474 Reply extension (see section 5.3) to the Registration Reply. 476 For the Foreign Agent Public Key subtype, the subtype data contains 477 the foreign agent's public key. 479 4.5. Diffie-Hellman Registration Key Request Subtype 481 The foreign agent may send the Diffie-Hellman Registration Key 482 Request extension to initiate key exchange by use of the exponentiation 483 algorithm in the finite cyclic multiplicative group of integers mod p, 484 as described in Appendix A. To initiate the key exchange the foreign 485 agent chooses a large random number, N. If g is the value of the 486 generator and p is the value of the prime, the computed value in the 487 extension is g^N mod p. See appendix B for details on the algorithm. 489 The foreign agent then appends the extension to the Registration 490 Request message, containing the values for the prime and generator, 491 along with the computed value (F) from its own private random number 492 N. The home agent will then choose its own private random number M and 493 creates its own computed value (H). The foreign agent will complete the 494 key exchange by extracting the home agent's computed value H from the 495 Diffie-Hellman Registration Key Reply extension in the registration 496 request. 498 The format of the subtype data contained in this extension is 499 illustrated below. 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Prime ... 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Generator ... 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Computed Value ... 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 Prime One of the two public numbers involved in the 512 Diffie-Hellman key exchange algorithm. The prime should 513 be a large prime number. 515 Generator 516 The other public number involved in the Diffie-Hellman 517 key exchange algorithm. If p is the value of the prime 518 used for this Diffie-Hellman exchange, the generator 519 should be less than p, and should be a primitive 520 root [14] of p. 522 Computed Value 523 The public computed value from the foreign agent for this 524 Diffie-Hellman exchange. 526 The values indicated for the prime, generator, and computed value are 527 all the same length, which must be a integral number of bytes. 529 4.6. Diffie-Hellman Elliptic Curve Registration Key Request 531 All foreign agents that support smooth handovers SHOULD support the 532 Diffie-Hellman Elliptic Curve Registration Key Request. 534 To initiate the key exchange the foreign agent chooses a large random 535 number, N. If the generating point is (X,Y), then the computed value 536 is N*(X,Y), where the integer multiplication is accomplished by adding 537 the point to itself N times. The algorithm for adding points in the 538 elliptic curve group is given in section C. The default value for the 539 generating point (X,Y) is (24,13). Note that for any point (X,Y) in the 540 elliptic curve group, both X and Y are elements of the underlying field, 541 which in the default case specified below will be the Galois Field 542 GF[2^185]. 544 The foreign agent then inserts the extension in the Registration 545 Request message, containing the values for the prime and generator, 546 along with the computed value (F) from its own private random number 547 N. The home agent will then choose its own private random number and 548 creates its own computed value (H). The foreign agent will complete the 549 key exchange by extracting the home agent's computed value H from the 550 Diffie-Hellman Registration Key Reply extension in the registration 551 request. 553 The format of the subtype data contained in this extension is 554 illustrated below. 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Y0 | First Coordinate of (V,W) = N*(X,Y) ... 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Y0 Either 02 or 03, depending upon the least significant bit 563 of the computed value N*(X,Y) 565 First Coordinate of (V,W) = N*(X,Y) 566 If the chosen random number is N, and the chosen 567 generator is (X,Y), and if (V,W) = N*(X,Y), then this 568 value is V. 570 See section C for details about the computation of N*(X,Y), its 571 compressed representation as illustrated above, and recovery of N*(X,Y) 572 given this compressed representation. 574 5. Generalized MN-FA Key Reply Subtypes 576 Key reply extensions in this document are subtypes of the Generalized 577 MN-FA Key Reply extension [13]. 579 The following subtypes are defined: 581 1. Registration Key Reply from Home Agent 582 2. Mobile Node Public Key Reply 583 3. Foreign Agent Public Key Reply 584 4. Diffie-Hellman Key Reply 586 For each subtype, the format of the MN-FA Key Reply Subtype Data has 587 to be separately defined according to the particular method required to 588 set up the security association. In this section, the term "subtype 589 data" refers to the MN-FA Key Reply Subtype Data of the Generalized 590 MN-FA Key Reply extension. 592 For the subtypes specified in this document, the Registration Key 593 supplied in the subtype data comes as a result of a request which was 594 sent using a subtype of the Generalized MN-FA Key Request Extension. 596 The SPI to be used when employing the security association defined by 597 the registration key is supplied in the original request. 599 The keys obtained by the mobile node from the Key Reply extension 600 subtypes defined in this document are expected to remain valid for as 601 long as the mobile node continuously uses the same care-of address. 602 The purpose of the registration key is to facilitate smooth handoffs, 603 as well as secure subsequent registrations. Since it would typically 604 take a huge number of encryptions with the same registration key for an 605 attacker to gain enough information to compromise the key, such intended 606 uses are unlikely to make the registration key insecure. Similarly, 607 the mobile node is unlikely to use the same registration key for enough 608 registrations to make the single smooth handover insecure. Thus, the 609 registration key does not need to have any particular lifetime unless 610 it is used for other purposes, such as for data hiding, in addition to 611 registration and smooth handover. 613 5.1. Registration Key Reply from Home Agent Subtype 615 The home agent uses the Registration Key Reply from Home Agent 616 extension in Registration Reply messages to securely deliver a 617 registration key to the mobile node. For this extension, the subtype 618 data is the registration key encoded using the SPI in the Registration 619 Reply. The method used is specified in section 3.1, where the 620 registration reply payload used in the encoding includes all the data up 621 to and including the SPI field in the Generalized Key Reply extension 622 for which this is a subtype. This key reply extension is authenticated 623 along with the rest of the Registration Reply message, and thus no 624 additional authenticator is included in the extension. 626 The home agent MUST also include another key reply extension which 627 delivers the same key to the mobile node's new foreign agent. 629 5.2. Mobile Node Public Key Reply Subtype 631 When the mobile node sends a Mobile Node Public Key Request to its 632 prospective foreign agent, the foreign agent can immediately select 633 a registration key. The foreign agent encodes this registration key 634 into the Mobile Node Public Key Reply extension to the Registration 635 Request. The foreign agent also stores the key and the SPI from the 636 Mobile Node Public Key Request for future reference as a potential 637 security association with the mobile node. The home agent subsequently 638 transcribes this extension without change into the Registration 639 Reply message. Thus, the mobile node is protected against common 640 man-in-the-middle attacks. 642 The subtype data for this subtype is the Registration Key encoded by 643 using the mobile node's public key. 645 5.3. Foreign Agent Public Key Reply Subtype 647 This extension is sent in response to a Foreign Agent Public 648 Key Request extension. The home agent selects a registration key 649 and encodes it twice into two separate key reply extensions of the 650 Registration Reply message. The Foreign Agent Public Key Reply 651 extension contains the registration key encoded with the public key of 652 the foreign agent. 654 The foreign agent also stores the SPI from the registration key 655 request extension sent by the mobile node, for future reference as a 656 potential security association with the mobile node if the registration 657 is successful. 659 The subtype data for this extension is the Registration Key encoded 660 by using the foreign agent's public key. 662 5.4. Diffie-Hellman Key Reply Subtype 664 The Diffie-Hellman Registration Key Reply extension should be 665 included in a Registration Reply message sent by a home agent to the 666 foreign agent, when the following conditions are met: 668 - the mobile node has included a Registration Key Request extension 669 in its registration request message, 671 - the foreign agent has no public key or security association with 672 the home agent or mobile node, and 674 - the foreign agent has included one of the Diffie-Hellman 675 Registration Key Request extensions in its Registration Request 676 message to the home agent (see sections 4.5 and 4.6). 678 The home agent uses the same reply extension subtype (namely, 679 the Diffie-Hellman Key Reply subtype), in response to either of the 680 Diffie-Hellman key exchange request messages. 682 The subtype data for the Diffie-Hellman Registration Key Reply 683 extension, is just the Computed Value resulting from the requested 684 Diffie-Hellman computation. 686 6. Authentication of Foreign Agent 688 The Foreign Agent Public Key Request (section 4.4) as well as the the 689 Diffie-Hellman Registration Key Requests (sections 4.5 and 4.6) require 690 foreign agent to append additional extensions to the Registration 691 Request before forwarding it to the home agent. In both cases, there 692 is no prior security association between the home agent and the foreign 693 agent, and thus the foreign agent cannot append an FA-HA authentication 694 extension. Without further measures, the home agent cannot verify the 695 authenticity of these extensions appended by the foreign agent; these 696 methods are therefore subject to man-in-the-middle attacks. In order 697 to protect against man-in-the-middle attacks, the home agent and the 698 mobile node need some way to make sure that they are dealing with the 699 same foreign agent (note that the exact identity of the foreign agent is 700 not important). 702 The authentication of the foreign agent is accomplished as follows 703 by making use of the Challenge extension [3]. Let p denote the public 704 data to be included by the foreign agent (e.g., this can be the foreign 705 agent's public encryption key, or the Diffie-Hellman public computed 706 value). Let c denote the the randomly chosen challenge that the foreign 707 agent wants to advertise at that time. Instead the foreign agent 708 advertises c1 = MD5 (p, c) as the Challenge. The Registration Request 709 sent by the mobile node will therefore include a Challenge extension 710 containing c1, followed by the MN-HA Authentication Extension. Before 711 forwarding the Request, the foreign agent adds the appropriate Key 712 Request extension, and a new Challenge extension containing c. When 713 the home agent receives a Registration Request containing two Challenge 714 extensions and a Key Request extension, it can compute the MD5 checksum 715 of the public data and the second Challenge, and compare it with the 716 first Challenge. The home agent also checks the validity of the MN-HA 717 authentication extension and whether it covers the first Challenge 718 extension. 720 This technique allows the foreign agent is free to change p and c 721 independently of each other (typically p would have a longer life time 722 than c). If the foreign agent does not need to use a challenge for 723 other purposes, then c1 can be MD5 (p). In this case, the foreign agent 724 need not append a Challenge extension to the Registration Request. 726 In order to reduce bandwidth requirements for this advertisement, the 727 foreign agent MAY truncate the MD5 digest to as few as the initial 4 728 bytes. Since all of the bits of the MD5 digest are considered equally 729 random, applying further operations (such as XOR) might even reduce the 730 resulting cryptographic strength. 732 7. Mobile Node Key Requests 734 If the mobile node receives an Agent Advertisement from a foreign 735 agent with the `S' bit set, the mobile node may attempt a smooth handoff 736 with its previous foreign agent, as well as asking its new foreign agent 737 to aid in supplying a registration key for the new registration. The 738 following code fragment illustrates a good algorithm for the mobile node 739 to use during registration, to allow flexibility in the selection of 740 the new registration key. Any particular mobile node may be configured 741 to use one, none, or any subset of the key establishment procedures 742 specified in this document. 744 The Mobile Node executes the following algorithm upon new FA 745 registration. This algorithm is intended to reduce complexity at the 746 mobile node. But, the Home Agent MAY require that the mobile node use 747 Public Key if required by the policy of the home domain administration, 748 instead of relying on other means for generating keys. 750 If (Challenge advertised) { 751 Add challenge data to Registration Request 752 /* If NewFA uses Elliptic, challenge is MD5 (N*(X,Y), c) */ 753 } 754 If (NewFA advertises 'S') { 755 if (have registration key with previous FA) { 756 /* append Previous Foreign Agent Notification (PFAN) */ 757 If (received opaque-data) { /* See [2] */ 758 append opaque-data extension after PFAN; 759 } 760 } 761 if (have security association with current FA) { 762 ; /* Don't need to create a registration key */ 763 } 764 else if (HA expects Public Key) { 765 Add public key extension; /* FA will choose key */ 766 } 767 else if (opaque-data || SA with NewFA) { 768 create MN-FA extension; 769 } 770 else { 771 Send Registration Key Extension; /* Let them do it */ 772 } 773 } 775 In this way, the mobile node can get a registration key whenever one 776 can be produced by any mechanism specified in this document. 778 8. Miscellaneous Home Agent Operations 780 8.1. Receiving Registration Key Requests 782 When the home agent receives a Registration Request message, an 783 extension requesting a registration key (Section 4) may be present in 784 the message. Then the home agent is expected to provide a registration 785 key to the mobile node and its foreign agent, as described in Section 3. 786 When needed, the home agent employs a good algorithm for producing 787 random keys [6] and encrypts the result separately for use by the 788 foreign agent and by the mobile node. The chosen key is encoded under 789 the mobility security association shared between the home agent and 790 the mobile node as described in section 3.1. The regrep data used as 791 part of the encoding includes all the preceding Registration Reply data 792 up to and including the Length field of the Generalized MN-FA Reply 793 extension for which the Registration Key Reply is the subtype. The 794 encrypted key is then placed as the Subtype Data of the Registration 795 Key Reply from Home Agent extension (section 5.1) in the Registration 796 Reply message. The same key may also be encrypted under the mobility 797 security association shared between the home agent and the foreign 798 agent, and the encoding placed in a registration key reply extension 799 in the Registration Reply message. When the home agent transmits the 800 Registration Reply message containing reply extensions to the foreign 801 agent, the message has the overall structure as follows: 802 ------------------------------------------------------------- 803 |IP|UDP| Reg-Reply| MN Key| FA Key| MN-HA Auth.| HA-FA Auth.| 804 ------------------------------------------------------------- 805 The HA-FA authentication extension is only included if the home agent 806 and foreign agent share a mobility security association. 808 If the home agent cannot satisfy a request to select a registration 809 key, but the other Mobile IP registration requirements are fulfilled, it 810 MAY still approve the registration reply. In this case, the home agent 811 returns a Registration Reply message Code indicating success, but does 812 not include any key reply extension. 814 8.2. Diffie-Hellman Considerations 816 If the home agent receives one of the Diffie-Hellman key request 817 extensions, (see sections 4.5 and 4.6), then it has to pick a good 818 random number [6] and use it to complete the key exchange algorithm. 819 Suppose the home agent picks the random number Z. Then the home agent 820 applies the group operation Z times on the data received from the 821 foreign agent, which amounts to either exponentiation to the Zth power, 822 or else (in the elliptic case) to multiplication by Z of the incoming 823 solution point. The result of this operation gives the registration 824 key, which is then encoded in a Registration Key Reply from Home Agent 825 extension and sent to the mobile node. 827 In order to deliver the registration key to the foreign agent, the 828 home agent applies the group operation Z times to the generator (or, in 829 the elliptic case, the generating point). The result of that operation 830 is placed in a Diffie-Hellman Key Reply extension and sent to the 831 foreign agent so that the foreign agent can compute the registration 832 key. 834 8.3. Foreign Agent Authentication Considerations 836 When a home agent receives one of the Diffie-Hellman Key Request 837 subtypes or the Foreign Agent Public Key Request subtype along with two 838 Challenge extensions, the Challenge Value MUST be checked against the 839 public value indicated by the foreign agent. The rule by which the 840 computed value is to be checked is described in section 6. 842 8.4. Home Agent Supplying Registration Keys 844 When the home agent receives a Registration Request message with 845 registration key extensions, it usually performs one of two operations: 847 - determine and encode a registration key for the foreign agent, 848 and when necessary, for the mobile node. 850 - transcribe the registration key already selected by the foreign 851 agent into the appropriate extension to the Registration Reply 852 message. 854 Both operations ensure that the mobile node and home agent are 855 dealing with the same foreign agent. Whenever the home agent inserts 856 one of the following key reply extensions in the Registration Reply, 858 1. Registration Key Reply from Home Agent 859 2. Mobile Node Public Key Reply 860 3. Foreign Agent Public Key Reply 862 each key reply extension MUST precede the MN-HA Authentication 863 Extension. The Diffie-Hellman Key Reply, on the other hand, is 864 consumed by the foreign agent, and SHOULD be located after the MN-HA 865 Authentication Extension whenever the Challenge value is supplied with 866 the Registration Request message. The Challenge value is typically 867 sufficient to protect against man-in-the-middle attacks. 869 When building the Registration Reply, the home agent should follow 870 an algorithm such as the one illustrated below, which is useful for 871 the registration key establishment methods currently specified. The 872 underlying theme of the algorithm is that the home agent just does as it 873 is told. 875 if (Foreign Agent Reg. Key Request) { /* HA-FA assn_exists */ 876 /* Pick a key, encode for FA */ 877 /* append MN Key Reply to Registration Reply */ 878 /* append FA key reply to Registration Reply */ 879 } 880 If (MN public key) { 881 /* Transcribe the encoded key */ 882 /* append MN Key Reply to Registration Reply */ 883 } 884 If (FA public key) { 885 /* Pick a key, encode for FA */ 886 /* append MN Key Reply to Registration Reply */ 887 /* append FA Public Key Reply to Registration Reply */ 888 } 889 If (elliptic) { 890 /* Pick multiplier `Z', do the D-H algorithm */ 891 } 892 else { 893 /* do nothing */ 894 } 895 /* append mobile-home authentication extension at end */ 897 /* Encode the key for the MN if necessary, use existing SPI */ 898 /* New registration key will then be invoked by SPI from */ 899 /* key request extension. */ 901 9. Miscellaneous Foreign Agent Operations 903 This section details various operational considerations important for 904 foreign agents wishing to support smooth handoff, including algorithms 905 for establishment of registration keys. 907 9.1. Foreign Agent Handling Key Requests 909 The foreign agent, when it receives a request from a mobile node 910 for a registration key, is faced with a variety of possible actions. 911 The action selected by the foreign agent depends on the resources it 912 has available. The foreign agent typically attempts to reduce as 913 much as possible the computational burden placed on the mobile node, 914 but relies on the security association with sufficient cryptographic 915 strength to encode the registration key. Furthermore, if the foreign 916 agent performs the key selection, it still supplies the encoded key 917 in an extension to the Registration Request message, so that the home 918 agent will authenticate its choice of registration key to the mobile 919 node. This strategy reduces the opportunity for interlopers to mount 920 man-in-the-middle attacks. 922 The following code fragment, executed when the foreign agent receives 923 a key request of some variety, exhibits an algorithm which may be useful 924 for implementors of foreign agents. The algorithm is supposed to be 925 used when a foreign agent gets a Registration Request with one of the 926 key request extensions included. The foreign agent uses the elliptic 927 curve Diffie-Hellman key exchange as a last resort, with implicit 928 well-known parameters (X-coordinate, Y-coordinate, Extension-Field), 929 picking multiplier `N'. 931 If (opaque-data) { 932 /* extract key/replay protection */ 933 /* check against replays */ 934 /* drop registration unless opaque-data passes check */ 935 } 937 if (Previous Foreign Agent Notification (PFAN)) { 938 /* Formulate Binding Update */ 939 /* Send with Smooth Handoff Authentication Extension */ 940 } 942 If (MN-FA authentication extension) { 943 /* Verify before proceeding */ 944 } 946 If (Registration Key Extension) { 947 /* Set up registration key */ 948 if (have mobile node's public key) { 949 /* pick a good key */ 950 /* append MN Public Key Reply to Reg. Request */ 951 } 952 If (opaque-data valid) { 953 /* Use old extension */ 954 } 955 if (have security association with HA) { 956 /* Append FA key request to Registration Request */ 957 } 958 If (FA public key) { 959 /* Send it; HA will pick key */ 960 } 961 else { 962 /* pick elliptic point multiplier `N' */ 963 /* append result to the Registration Key Request */ 964 } 965 } 967 10. Security Considerations 969 Whenever a key is exchanged by use of the Diffie-Hellman algorithm, 970 the process is susceptible to the "man-in-the-middle" attack, as 971 detailed in Appendix A. This attack is not known to produce further 972 difficulty, and susceptibility is already inherent in the operation of 973 the base Mobile IP specification [11]. Attention to this detail is 974 warranted during any future changes to the Route Optimization protocol. 975 Ways to reduce the risk should be incorporated into future revisions 976 of this document. Already, the risk of such an attack against the 977 registration key distribution mechanisms specified in this document are 978 greatly reduced by the authentication of the Registration Reply by the 979 home agent. 981 The calculation of the authentication data described in Section 3.1 982 is specified to be the same as in the base Mobile IP document for ease 983 of implementation. There is a better method available (HMAC), specified 984 in RFC 2104 [8]. If the base Mobile IP specification is updated to use 985 HMAC, then this route optimization specification should also be updated 986 similarly. 988 Registration keys should typically NOT be used as master keys for 989 producing other derived keys, because of the man-in-the-middle attack 990 associated with unidentifiable foreign agents. 992 References 994 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 995 Levels. Request for Comments (Best Current Practice) 2119, 996 Internet Engineering Task Force, March 1997. 998 [2] P. Calhoun, Haseeb Akhtar, Emad Qaddoura, and N. Asokan. 999 Minimal Latency Secure Hand-off. 1000 draft-calhoun-mobileip-min-lat-handoff-01.txt, February 2000. 1001 (work in progress). 1003 [3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 1004 Challenge/Response Extension. 1005 draft-ietf-mobileip-challenge-08.txt, January 2000. (work in 1006 progress). 1008 [4] CDPD consortium. Cellular Digital Packet Data Specification. 1009 P.O. Box 809320, Chicago, Illinois, July 1993. 1011 [5] W. Diffie and M. Hellman. New Directions in Cryptography. IEEE 1012 Transactions on Information Theory, 22:644--654, November 1976. 1014 [6] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 1015 Recommendations for Security. Request for Comments 1016 (Informational) 1750, Internet Engineering Task Force, December 1017 1994. 1019 [7] N. Koblitz. Elliptic Curve Cryptosystems. Mathematics of 1020 Computation, 48(177):203--209, 1987. 1022 [8] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 1023 for Message Authentication. Request for Comments 1024 (Informational) 2104, Internet Engineering Task Force, 1025 February 1997. 1027 [9] V. S. Miller. Use of Elliptic Curves in Cryptography. In 1028 Advances in Cryptology -- CRYPTO '85 Proceedings, pages 1029 417--426, Berlin, 1986. Springer-Verlag. 1031 [10] H. Orman. The OAKLEY Key Determination Protocol. Request for 1032 Comments (Informational) 2412, Internet Engineering Task Force, 1033 November 1998. 1035 [11] C. Perkins. IP Mobility Support. Request for Comments 1036 (Proposed Standard) 2002, Internet Engineering Task Force, 1037 October 1996. 1039 [12] C. Perkins and D. Johnson. Route Optimization in Mobile IP. 1040 Internet Draft, Internet Engineering Task Force, February 1999. 1041 Work in progress. 1043 [13] Charles E. Perkins and Pat R. Calhoun. Generalized Key 1044 Distribution Extensions for Mobile IP. 1045 draft-ietf-mobileip-gen-key-00.txt, February 2000. (work in 1046 progress). 1048 [14] Bruce Schneier. Applied Cryptography: Protocols, Algorithms, 1049 and Source Code in C. John Wiley, New York, NY, USA, 1994. 1051 [15] Richard Schroeppel, Hilarie Orman, and Sean OMalley. Fast Key 1052 Exchange with Elliptic Curve Systems. In Advances in Cryptology 1053 -- CRYPTO '95 Proceedings. Springer-Verlag, 1995. 1055 A. Using Diffie-Hellman with the Foreign Agent 1057 Diffie-Hellman public key cryptosystems allows two parties to 1058 establish a shared secret key, such that the shared secret key cannot 1059 be determined by other parties overhearing the messages exchanged 1060 during the algorithm. It is used in other well-known protocols that 1061 require a key exchange, such as the Cellular Digital Packet Data (CDPD) 1062 system [4]. These systems work because they are employed where the 1063 ``discrete logarithm'' problem is currently intractable. The discrete 1064 logarithm problem can be stated as follows: 1066 given a finite cyclic algebraic group with generator g, and 1067 g*N (where `*' means repeating the group operation between g 1068 and itself N times), find the value of N. 1070 The two group operations of most interest are: 1072 1. Integers modulo a (large) prime p, with modular multiplication as 1073 the group operation 1075 2. Group of solution points to particular elliptic curves over 1076 (large) fields, with elliptic curve addition as the group 1077 operation 1079 For a multiplicative group, repeating the group operation by an 1080 element on itself N times amounts to (integer) exponentiation by N. For 1081 an additive group, repeating the group operation N times amounts to an 1082 integer multiplication operation on that group element. In the elliptic 1083 curve group, the elements are not integers, but instead ordered pairs 1084 (X,Y) which represent solutions to the elliptic curve. 1086 The first groups have the advantage of being easy to understand. The 1087 second groups, proposed later than the first, have the advantage of 1088 being much faster computationally. 1090 For the purposes of the explanation in this appendix, suppose that 1091 the first party in the key exchange is the foreign agent, and the second 1092 party is the home agent. This would be the situation whenever these 1093 key exchanges are used to generate Registration Keys using the methods 1094 specified in this document. 1096 In both cases, the result depends on the fact that the group 1097 operation in the relevant groups is commutative, so that M*(N*g) == 1098 N*(M*g). When the group operation is multiplication, this is more 1099 conventionally written as (g^M)^N = (g^N)^M. 1101 This technique is known to suffer from a man-in-the-middle attack. 1102 In other words, a malicious agent could pretend to the foreign agent 1103 to be the home agent, and pretend to the home agent to be the foreign 1104 agent, and participate as an unwanted third member in the key exchange. 1105 Armed with knowledge of the registration key, the malicious agent could 1106 at a later time disrupt the smooth handoff, or initiate the handoff 1107 prematurely. The man-in-the-middle attack is no worse than a malicious 1108 agent pretending to be a foreign agent in any other circumstance; 1109 that is, it is no worse than already exists with the base Mobile IP 1110 specification [11]. In the key distribution mechanisms specified 1111 in this document, the man-in-the-middle attack is prevented in most 1112 circumstances because each registration key is effectively authenticated 1113 by the home agent. Moreover, the mobile node and/or the foreign agent 1114 are presumably in direct contact, so that such an attack is detectable 1115 if either of the nodes notices the reception of duplicate packets, and 1116 corrective action taken. 1118 Establishing a registration key using Diffie-Hellman is 1119 computationally more expensive than most methods described in Section 3. 1120 The use of Diffie-Hellman described here, though, is designed to allow 1121 the Diffie-Hellman computations to be overlapped with other activities. 1122 The foreign agent may choose (or be manually configured with) the prime 1123 and generator values (or, the generating point and Galois Field values) 1124 at any time, or may use the same values for a number of registrations. 1125 The home agent may also choose, for each mobile node, its private random 1126 number and calculate its computed value at any time. For example, after 1127 completing one registration, the foreign agent may choose the private 1128 random number for its next registration and begin the computation of 1129 its new computed value based on this random number, such that it has 1130 completed this computation before it is needed in a registration from 1131 another mobile node. Even more simply, the foreign agent may use 1132 the same private random number and computed value for any number of 1133 registrations. 1135 B. Diffie-Hellman Key Exchange in the Group of Integers mod p 1137 Briefly, the Diffie-Hellman algorithm involves the use of two large 1138 public numbers, a prime number (p) and a generator (g). The prime 1139 number and the generator must be known by both parties involved in the 1140 algorithm, but do not have to be secret; these values may be the same 1141 or different for each execution of the algorithm and are not used once 1142 the algorithm completes. Each party chooses a private random number, 1143 produces a computed value based on this random number, the prime and 1144 the generator, and sends the computed value in a registration message 1145 extension to the other party. The foreign agent creates the computed 1146 value f = g^N mod p, where N is its private random number, p is the prime 1147 which is sent as part of the transaction, and g is the generator. The 1148 home agent then creates another computed value h = g^M mod p, where M 1149 is its own private random number, and p and g are the same as for the 1150 foreign agent. Each party then computes the (same) shared secret key 1151 using its own private random number, the computed value received from 1152 the other party, and the prime and generator values. Since f^M = (g^N)^M 1153 = C = (g^M)^N = h^N, the foreign agent and the home agent can compute a 1154 shared value C that is not detectable by other network nodes. The 1155 shared secret is the number C mod p, where p is the same prime number 1156 as before. Knowing the computed values mod p does not enable passive 1157 listeners to determine the private values, so the algorithm allows the 1158 two parties to agree on an otherwise undetectable secret. 1160 If Diffie-Hellman were substantially less computationally expensive, 1161 it could likely serve the needs of many mobile nodes. But, the 1162 algorithm itself uses modular exponentiations or strange additions 1163 involving numbers with hundreds of digits. That may take a long time 1164 for some mobile nodes to do, time which would come at the expense of 1165 interactivity or convenient operation of user application programs. 1166 For this reason, Diffie-Hellman is considered the least desirable 1167 alternative for establishing registration keys. Since it requires no 1168 other configuration, it is nevertheless required in all implementations 1169 of foreign agents that advertise support for smooth handoffs. 1171 C. Diffie-Hellman Key Exchange in Elliptic Curve Groups 1173 In order to multiply a generating point (X,Y) by a large number N, 1174 it is necessary to add the point to itself N times. However, addition 1175 in elliptic curve groups is not simple componentwise addition; (X,Y) 1176 + (A,B) is NOT EQUAL to (X+A,Y+B). Instead, in order for the group 1177 addition to yield only points that are solutions to the elliptic curve, 1178 a special formula for group addition must be used. 1180 Suppose, then, that one is given two points (X1, Y1) and (X2, Y2) in 1181 the elliptic curve group of all solutions to the equation y^2 + x*y = x^3 1182 + a*x^2 + b. The function Plus (X1, Y1, X2, Y2) is defined as follows. 1184 - if X1 = X2 and Y1 = Y2, then Plus (X1, Y1, X2, Y2) = Double (X1, 1185 Y1), where Double (X, Y) is as defined below. 1187 - otherwise, if X1 = X2 but Y1 != Y2, then 1188 Plus (X1, Y1, X2, Y2) = (0,0) 1190 - otherwise, Plus (X1, Y1, X2, Y2) = (V, W), where 1192 i. V = L^2 + L + X1 + X2 + a 1194 ii. W = L*(X1 + V) + V + Y1, and 1196 iii. L = (Y1 + Y2)/(X1 + X2) 1198 The function Double (X, Y) is defined as follows: 1200 - if X = 0, then Double (X, Y) = (0,0) 1202 - otherwise, Double (X, Y) = (V, W), where 1204 i. V = L^2 + L + a, 1206 ii. W = X^2 + (L + 1) * X, and 1208 iii. L = X + Y/X 1210 The above formulas are given in a publication by Richard Schroeppel, 1211 Hilarie Orman, and Sean O'Malley [15]. Note that there are many 1212 computational shortcuts available. The referenced publication is a good 1213 start; one should also consult [14]. 1215 The following elliptic curve characteristics are used by default, 1216 and until a method is specified for offering non-default values. 1217 This information is taken from appendix E.4 of RFC 2412 [10], and is 1218 reproduced here only for completeness. 1220 The elliptic curve is based on the Galois Field GF[2^185] with 2^185 1221 field elements. The irreducible polynomial for the field is 1223 u^185 + u^69 + 1. 1225 The equation for the elliptic curve is 1227 Y^2 + X Y = X^3 + A X + B. 1229 X, Y, A, B are elements of the field. For the curve specified, A = 0 1230 and 1232 B = u^12 + u^11 + u^10 + u^9 + u^7 + u^6 + u^5 + u^3 + 1. 1234 B is represented in binary as the bit string 1111011101001; in 1235 decimal this is 7913, and in hex 1EE9. 1237 The generator is a point (X,Y) on the curve (satisfying the curve 1238 equation, mod 2 and modulo the field polynomial); 1240 X = u^4 + u^3 and Y = u^3 + u^2 + 1. 1242 For this extension, the subtype data is a standard representation 1243 using a point compression technique (not defined in RFC 2412) for the 1244 computed value of (V,W) = N*(X,Y), specified as follows. 1246 Let (V,W) be a point of the elliptic curve group defined as above. 1247 Let OCTETS be the representation of V as bits right-justified into an 1248 integer number of octets. For instance, if V = 24(decimal), OCTETS = 1249 18 shown as two hexadecimal digits. If V = 317(decimal), OCTETS = 013D 1250 shown as four hexadecimal digits. The number of hexadecimal digits 1251 needed to represent OCTETS will always be an even number since every 1252 byte of the representation takes two hexadecimal digits to represent. 1254 Then, define W0 to be zero (0) if V == 0; otherwise define W0 to be 1255 the rightmost bit of the field element W/V. If W0 == 0, then the subtype 1256 data will be 02 || OCTETS; otherwise the subtype data will be 03 || 1257 OCTETS. Here, "||" means concatenation. 1259 To recover (V,W) from this standard representation, proceed as 1260 follows. 1262 If V == 0, then W = B^(2^184), where B = 7913 from the defining 1263 elliptic curve. W is the square root of B. Otherwise, compute the field 1264 element W = V + a + B/(V^2) = V + 7913/(V^2). Find Z such that Z^2 + Z = 1265 W. Let Z0 be the rightmost bit of Z. If the received computed value has 1266 prefix 02, let W0 be 0; otherwise if the received computed value has 1267 prefix 02, let W0 be 1. If W0 != Z0, then let Z = Z + 1. Then, W = 1268 Z*V. 1270 Addresses 1272 The working group can be contacted via the current chairs: 1274 Basavaraj Patil Phil Roberts 1275 Nokia Corporation Motorola 1276 M/S M8-540 1277 6000 Connection Drive 1501 West Shure Drive 1278 Irving, TX 75039 Arlington Heights, IL 60004 1279 USA USA 1280 Phone: +1 972-894-6709 Phone: +1 847-632-3148 1281 EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com 1282 Fax : +1 972-894-5349 1284 Questions about this memo can also be directed to the authors: 1286 Charles E. Perkins David B. Johnson 1287 Communications Systems Lab Computer Science Department 1288 Nokia Research Center 5000 Forbes Avenue 1289 313 Fairchild Drive Pittsburgh, PA 15213-3891 1290 Mountain View, California 94043 Carnegie Mellon University 1291 USA USA 1292 Phone: +1-650 625-2986 Phone: +1-412-268-7399 1293 EMail: charliep@iprg.nokia.com E-mail: dbj@cs.cmu.edu 1294 Fax: +1 650 625-2502 Fax: +1-412-268-5576 1296 N. Asokan 1297 Communications Systems Lab 1298 Nokia Research Center 1299 P.O. Box 407 1300 FIN-00045, NOKIA GROUP 1301 Helsinki 1302 Finland 1303 Phone: +358 40 743 1961 1304 E-mail: n.asokan@nokia.com 1305 Fax: +358 94 376 6852