idnits 2.17.1 draft-ietf-mobileip-challenge-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 206: '... Mobility Agents MUST share a security...' RFC 2119 keyword, line 245: '...ration Request, the Foreign Agent MUST...' RFC 2119 keyword, line 254: '...he Foreign Agent MAY provide the Mobi...' RFC 2119 keyword, line 339: '... Mobile Node MUST also ensure that t...' RFC 2119 keyword, line 344: '... Foreign Agent MUST include the Mobi...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1998) is 9265 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 982, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 991, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 994, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2002 (ref. '2') (Obsoleted by RFC 3220) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-00 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-01 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-00 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-04) exists of draft-calhoun-diameter-proxy-00 -- Possible downref: Normative reference to a draft: ref. '7' -- No information found for draft-ietf-mobileip-ha-alloc - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Charles E. Perkins 4 Title: draft-ietf-mobileip-challenge-00.txt Sun Laboratories, Inc. 5 Date: November 1998 7 Mobile IP Foreign Agent Challenge/Response Extension 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@smallworks.com mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To view the entire list of current Internet-Drafts, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 30 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 31 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 33 Abstract 35 RFC2002, which defines the base Mobile IP protocol, assumes that a 36 shared secret exists with all mobility agents and the Mobile Node. 37 However, in larger networks, this assumption can lead to scalability 38 problems, especially in situations where the Mobility Agents are 39 owned by different administrative domains. This document specifies 40 the Router Advertisement and Mobile IP extensions necessary to 41 integrate Mobile IP with Key Distribution Centers (KDC). 43 Table of Contents 45 1.0 Introduction 46 1.1 Terminology 47 2.0 Operation 48 2.1 Intra-Domain Mobile IP 49 2.2 Inter-Domain Mobile IP 50 2.3 Allocation of a Home Agent in a Foreign Network 51 2.4 Smooth Handoff 52 2.5 Key Expiration 53 2.6 Interaction with Home Agent Allocation 54 3.0 Router Discovery Extensions 55 3.1 Foreign Agent Challenge Extension 56 3.2 Foreign Agent NAI Extension 57 4.0 Mobile IP Registration Extensions 58 4.1 Foreign-Agent-Challenge Extension 59 4.2 Mobile-Challenge-Response 60 4.3 Mobile-Foreign-SPI Extension 61 4.4 Mobile-Home-SPI Extension 62 4.5 Mobile-Foreign-Key Extension 63 4.6 Mobile-Home-Key Extension 64 4.7 Previous-Foreign-Agent-NAI Extension 65 4.8 Key-Lifetime Extension 66 5.0 Security Analysis 67 5.1 Challenge/Response Replay 68 5.1 Malicious FA 69 5.2 Malicious Foreign KDC 70 6.0 References 71 7.0 Acknowledgements 72 8.0 Chairs' Addresses 73 9.0 Author's Address 75 1.0 Introduction 77 RFC2002, which defines the base Mobile IP protocol, assumes that a 78 shared secret exists with all mobility agents and the Mobile Node. 79 However, in larger networks, this assumption can lead to scalability 80 problems, especially in situations where the Mobility Agents are 81 owned by different administrative domains. 83 In this proposal, we recommend the integration of Mobile IP and KDCs 84 to solve the problem. Our primary design goal is to minimize the 85 number of security associations that a given Mobility Agent requires 86 in order to get service. In fact, this proposal requires that 87 Mobility Agent and Node have only a single security association with 88 the Key Distribution Center, known as the Home Domain Allocation 89 Agency (HDAA). 91 In order to make this proposal scale in larger networks, we propose 92 that if the Mobility Agents are not owned by the same administrative 93 domain, that only the HDAAs share a security association. This allows 94 cross domain mobility with a single security association between both 95 networks. 97 The document [9] describes the extensions necessary for a Home Agent 98 to be dynamically assigned to a Mobile Node during the first 99 Registration Request. Making use of the security extensions defined 100 in RFC 2002, would require the Home Agent to share a security 101 association with the Mobile Node, which means that the Home Agent 102 must be owned by the same administrative domain as the Mobile Node. 103 This extension will describe the security extensions necessary for 104 the Home Agent to be assigned within the foreign network. 106 This proposal will also specify how the Mobile Node can move to 107 another foreign domain and must keep the same Home Agent that was 108 assigned within the initial foreign domain. This can be achieved even 109 though both foreign domains do not share any security associations, 110 but both share one with the home domain. 112 The extensions described here are designed for new generation 113 cellular networks. 115 1.1 Terminology 117 KDC 119 Key Distribution Center is a central server that issues short- 120 lived keys to requesting agents in order to grant access to the 121 visiting network's foreign agent as well as access to the home 122 network. 124 KEYID 126 Key ID is an ID that references a key instance. 128 ICV 130 The Integrity Check Vector is the message authentication code of 131 the Registration message and the long lived shared secret. The 132 Mobile IP [2] document refers to this field as the authenticator. 134 SS1 136 A secret of up to 16 octets in length shared between the Mobile 137 Node and the HDAA. 139 SS2 141 A secret of up to 16 octets in length shared between the Foreign 142 Agent and its HDAA. 144 SS3 146 A secret of up to 16 octets in length shared between the Home 147 Agent and its HDAA. 149 2.0 Operation 151 The extensions in this document are specified to enable Mobile IP to 152 interoperate with another protocol that can create keys for use 153 between the foreign agent and mobile node, the foreign agent and the 154 home agent, and the mobile node and its home agent. The protocol 155 messages for key creation, and verification of the Foreign Agent 156 challenge, are not specified in this document, because they are part 157 of a different protocol that processes messages sent to a port other 158 than 434. Therefore, those key creation and challenge verification 159 messages are not considered to be part of Mobile IP, and are not 160 processed by Mobile IP software. All of the extensions specified in 161 this document are expected to be processed by Mobile IP software that 162 has been updated to handle the additional syntax presented in these 163 extensions. For an example of another protocol that has been 164 specified to actually carry out the key creation and challenge 165 verification operations, see [3] [6]. 167 The shared secrets (SS1, SS2, and SS3) indicated in this document are 168 shared with a KDC agent in the home domain. SS2 may be shared 169 between this KDC agent and the foreign agent, or more likely between 170 the KDC agent and a proxy acting in concert with the foreign agent. 171 For an example of how this works, consider the following diagram: 173 ------------------------------------------------------ 174 | | 175 | Verification and Key Management Infrastructure | 176 | | 177 ------------------------------------------------------ 178 ^ | ^| 179 | | || 180 | v |v 181 ----------------- ----------------- 182 | | | | 183 | Foreign Agent | | Home Agent | 184 | | | | 185 ----------------- ----------------- 187 After the foreign agent gets the Challenge Response, it passes the 188 Response along to the (here unspecified) infrastructure, and awaits a 189 a Registration Reply. If the reply has a positive status (indicating 190 that the registration was accepted), the foreign agent accepts the 191 registration, and decodes the Mobile IP keys and SPIs for use with 192 future Mobile IP registration messages. If the reply does not have a 193 positive status code, then the foreign agent assumes that the 194 challenge did not pass verification, for reasons that may or may not 195 be specified by the infrastructure agents. 197 Implicit in this picture, however, is the important observation that 198 the Foreign Agent and the Home Agent have to be equipped to make use 199 of whatever protocol is made available to them by the key management 200 and challenge verification shown in the figure. 202 2.1 Intra-Domain Mobile IP 204 In the simplest case, the Mobility Agents and the Mobile Node are 205 owned by the same administrative domain. In this following example, 206 all Mobility Agents MUST share a security association with the Home 207 Domain Allocation Agency (HDAA). 209 +------+ +------+ +------+ 210 | | | | | | 211 | MN |- - - -| FA |- - - - - - - - - -| HA | 212 | | | | | | 213 +---+--+ +---+--+ +---+--+ 214 | | | SS3 215 | | SS2 +---+--+ 216 | +----------------------+ | 217 | SS1 | HDAA | 218 +-------------------------------------+ | 219 +------+ 221 In this example, the Foreign Agent issues a Router Advertisement on 222 its local link, which is captured by the Mobile Node. The Router 223 Advertisement message includes the Foreign Agent Challenge and the 224 Foreign Agent NAI extensions. 226 The Mobile Node extracts the Foreign Agent NAI, and uses the NAI to 227 determine whether it is attached to its home network. 229 The Mobile Node then extracts the Foreign Agent Challenge from the 230 advertisement and computes the Mobile-Challenge-Response extension 231 using the challenge and the Registration Request message hashed with 232 SS1, but not including the UDP and IP headers. The Registration 233 Request is forwarded to the Foreign Agent and has the following 234 format: 236 ::= 237 238 239 240 [] 241 [] 242 243 [] 245 Upon receipt of the Registration Request, the Foreign Agent MUST 246 ensure that the Foreign-Agent-Challenge extension contains a recently 247 advertised challenge value. This ensures that the Mobile Node is not 248 attempting to replay a previous Mobile-Challenge-Response. If the 249 Mobile-Challenge-Response extension is present in the message, or if 250 the Mobile-Node-NAI shows that it belongs to a different 251 administrative domain, the foreign agent (or its proxy) forwards the 252 Registration Request to the HDAA. 254 Note that the Foreign Agent MAY provide the Mobile-Challenge- 255 Response extension in the KDC message. The HDAA can then easily find 256 the authenticator necessary to authenticate the user. 258 The HDAA will extract the Mobile-Challenge-Response extension and 259 compute a response using the Foreign Agent Challenge, SS1 and the 260 packet. If the response matches the authenticator in the Mobile- 261 Challenge-Response extension, the user is authenticated. The HDAA may 262 also perform some additional access control checks such as: 264 - Whether the Mobile Node can use the Foreign Agent. 265 - Whether the Mobile Node can use the Foreign Network. 266 - Whether the Mobile Node can use the network at the requested 267 day and time. 269 If successfully authenticated and authorized, the HDAA will generate 270 three separate short-lived sessions keys, associated Security 271 Parameter Index (SPI) values and key lifetime, which are sent to the 272 Home Agent in the KDC response message. The three keys have the 273 following properties (see figure 1 for the distribution of keys SS1, 274 SS2 and SS3): 276 - K1 is used to authenticate Mobile IP messages between the Mobile 277 Node and the Home Agent, and is encrypted using SS1 for the Mobile 278 Node (Mobile-Home-Key) and using SS3 for the Home Agent. 280 - K2 is used to authenticate Mobile IP messages between the Mobile 281 Node and the Foreign Agent, and is encrypted using SS1 for the 282 Mobile Node (Mobile-Foreign-Key) and using SS2 for the Foreign 283 Agent (Foreign-Mobile-Key). 285 - K3 is used to authenticate Mobile IP messages between the 286 Foreign Agent and the Home Agent, and is encrypted using SS2 for 287 the Foreign Agent (Foreign-Home-Key) and using SS3 for the Home 288 Agent. 290 The HDAA will forward the response to the Home Agent which includes 291 all of the Security Parameter Index and Keys. 293 Upon receipt of the response from the HDAA, the Home Agent will 294 proceed to process the Registration Request as defined in [2] and 295 will construct a Registration Reply message in the following format: 297 ::= 298 299 300 301 302 303 304 305 307 The Mobile-Home Authentication extension will be computed by the Home 308 Agent using the decrypted version of K1, and the Foreign-Home 309 Authentication extension is computed using the decrypted version of 310 K3. The Registration Reply is then sent back to the HDAA in the KDC 311 message, which forwards it to the Foreign Agent. 313 The Foreign Agent processes the Registration Reply by extracting the 314 Foreign-Home-Key and decrypting it using SS2. It then validates the 315 Foreign-Home Authentication extension by ensuring that the SPI value 316 matches the value that was provided in the Foreign-Home-SPI, and that 317 the authenticator was computed using the key (K3). If the packet is 318 successfully authenticated, the Foreign Agent adds the Mobile-Foreign 319 Authentication extension using the decrypted version of the key found 320 in the Foreign-Mobile-Key extension, and includes the SPI value found 321 in Foreign-Mobile-SPI. The Registration Reply message forwarded to 322 the Mobile Node has the following format: 324 ::= 325 326 327 328 329 330 331 332 334 Upon receipt of the Registration Reply, the Mobile Node must extract 335 the Mobile-Foreign-Key and Mobile-Home-Key and decrypt the session 336 key using the secret shared with the HDAA (SS1). The Registration 337 Reply's Mobile-Foreign Authentication and Mobile-Home Authentication 338 extensions are computed using the decrypted version of the keys. The 339 Mobile Node MUST also ensure that the SPIs used in these extensions 340 are consistent with the values returned in the Mobile-Foreign-SPI and 341 Mobile-Home-SPI extensions. 343 All subsequent Registration Requests sent by the Mobile Node to the 344 Foreign Agent MUST include the Mobile-Foreign Authentication and the 345 Mobile-Home Authentication computed using K2 and K1, respectively. 346 The authentication extensions MUST include the SPIs that refer to the 347 session keys used, Mobile-Foreign-SPI (K2) and Mobile-Home-SPI (K1). 349 The keys may be used until either the Mobile Node registers with a 350 new Foreign Agent, or until the keys expire which is known through 351 the Key-Lifetime extension. Once the keys expire, the Mobile Node 352 must request a new key by including the Foreign-Agent-Challenge and 353 the Mobile-Challenge-Response extensions. 355 2.2 Inter-Domain Mobile IP 357 In the previous section, we discussed how the extensions described in 358 this document could be used in a network where all mobility entities 359 were owned by the same administrative domain. There is a typical 360 requirement to have Foreign Agents, owned by a different 361 administrative domain from the home network, provide service to the 362 Mobile Nodes. 364 Unfortunately the scheme described in the previous section cannot be 365 used in this network configuration since it would require the HDAA to 366 have a security association with Foreign Agents that are not under 367 its administrative control, which would introduce serious scalability 368 and security problems. 370 In order to be able to support such a configuration, the KDC must 371 support proxying capabilities, one such method is described in [7]. 372 Proxying means that a KDC receives a request and is able to forward 373 the request to another KDC for processing in a secure fashion. 375 In the following figure we introduce a foreign network which consists 376 of a Foreign Agent which shares a security association with its 377 Visiting VDAA 1 (VDAA-1). Both of these network entities are owned by 378 the same administrative domain. Notice that HDAA and VDAA-1 share a 379 security association, which means that these domains can provide 380 Mobile IP services to each other with a single association. 382 +------+ +------+ +------+ 383 | | | | | | 384 | MN |- - - -| FA |- - - - - - - - - -| HA | 385 | | | | | | 386 +---+--+ +---+--+ +---+--+ 387 | | SS2 | SS3 388 +------------------------------+ | 389 | | | 390 +---+--+ | SS1 +---+--+ 391 | | +------+ | 392 |VDAA-1| | HDAA | 393 | +--------------SS4--+ | 394 +------+ +------+ 396 In this example, the Foreign Agent advertises its service in the same 397 manner as previously discussed. The Mobile Node adds the Challenge 398 and the Mobile-Challenge-Response extensions to the Registration 399 Request as previously explained. 401 When the Foreign Agent receives the Mobile Node's Registration 402 Request, it validates the challenge and forwards the request to 403 VDAA-1, which includes the Registration Request, the Mobile Node's 404 NAI, the Challenge and the Mobile-Challenge-Response extensions. 405 VDAA-1 uses the domain portion of the Mobile Node's NAI to identify 406 the Mobile Node's Home KDC, and forwards the request to the HDAA. 408 At this point, the HDAA authenticates the user and generates the 409 session keys as described in the previous section. The only 410 difference are that all keys destined for the Foreign Agent are 411 encrypted using SS4, which is the security assocation shared between 412 HDAA and VDAA-1. HDAA then forwards all keys, and the Registration 413 Request to the Home Agent within the Home network. 415 Upon receipt of this message, the Home Agent decrypts all keys which 416 belong to the Home Agent using SS3 and generates the Registration 417 Reply in the following format: 419 ::= 420 421 422 423 424 425 426 427 429 The Home Agent forwards the Registration Reply back to the HDAA in a 430 KDC message, which also includes the encrypted version of the session 431 keys destined for the Foreign Agent (which was present in the KDC 432 request to the Home Agent). The HDAA forwards this response back to 433 the VDAA-1, which descrypts the keys for the Foreign Agent using SS4, 434 and re-encrypts the keys using SS2, then forwards the response to the 435 Foreign Agent. Note that in this case the keys destined for the 436 Foreign Agent are carried within the KDC messages, and not in the 437 Mobile IP messages. 439 The Foreign Agent extracts the session keys and the Registration 440 Reply from the KDC message. The keys are decrypted using SS2 and the 441 Registration Reply's Foreign-Home Authentication extension is 442 authenticated using the decrypted version of the Foreign-Home-Key 443 extension. The Foreign Agent then adds the Foreign-Home 444 Authentication extension and forwards the Reply to the Mobile Node, 445 in the following format: 447 ::= 448 449 450 451 452 453 454 455 457 Once the keys have been distributed, the Mobile Node can proceed to 458 issue Registration Requests using the new session keys until either 459 the Mobile Node uses a new Foreign Agent, or the keys expire. 461 2.3 Allocation of a Home Agent in a Foreign Network 463 The document [9] describes the method of dynamically assigning a Home 464 Agent to a Mobile Node. The examples provided in the earlier sections 465 would work well if the Home Agent allocated belonged within the home 466 network. Here we will look at the how a Home Agent could be allocated 467 within a foreign network. 469 In the following figure, we show the Mobile Node which shares the 470 security association with its HDAA, and the Foreign and Home Agents 471 share one with their VDAA-1. When the HDAA receives the KDC message 472 from VDAA-1, the Mobile Node is authenticated using the Challenge and 473 the Response and additional authorization checks may be performed. 474 The keys are generated and returned to the VDAA-1, however all keys 475 for the Foreign and the Home Agent are encrypted using SS4. 477 Upon receipt of the response, VDAA-1 decrypts all keys for the 478 Foreign and Home Agent using SS4, and re-encrypts them using SS2 and 479 SS5, respectively, and the processing continues as previously 480 described. 482 +------+ +------+ +------+ 483 | | | | | | 484 | MN |- - - -| FA |- - - - -| HA | 485 | | | | +---+ | 486 +---+--+ +---+--+ | +------+ 487 | | SS2 | 488 +-----------------------|------+ 489 | | | 490 +---+--+ SS5 | | SS1 +------+ 491 | +-----+ +------+ | 492 |VDAA-1| | HDAA | 493 | +--------------SS4--+ | 494 +------+ +------+ 496 It is desirable for the Mobile Node to maintain the same Home Agent 497 within the Foreign Network, even if the Mobile Node enters a new 498 Foreign Network. However, it is possible that both Foreign Network's 499 KDCs do not share a security association, and it is also mandatory 500 that the HDAA be involved since ultimately it will be responsible for 501 any payments. 503 In the following figure the Mobile Node enters a new network which 504 includes the new Foreign Agent and VDAA-2. The Mobile Node receives 505 the Router Advertisement that inclues the new Foreign Agent's NAI 506 (and domain). The Mobile Node will determine that it has entered a 507 new network and will therefore issue a Registration Request that 508 includes the Old Foreign Agent's NAI, the old Home Agent, the 509 Challenge and the Response. 511 +------+ 512 | | 513 +- -+ HA + 514 | | 515 | +---+--+ 516 | SS5 517 | | 518 +---+--+ +------+ 519 | | +--------------SS4--+ | 520 |VDAA-1| | HDAA | 521 | | | +------+ | 522 +------+ | SS1 +---+--+ 523 | | | 524 +------------------------------+ | 525 | | | 526 +------+ +------+ +---+--+ | 527 | | +- -+ | SS7 | | SS6 | 528 | MN |- - - -| FA +--------+VDAA-2+-------+ 529 | | | | | | 530 +------+ +------+ +------+ 532 The Foreign Agent will forward this request to its VDAA-2, which will 533 forward the request towards HDAA. HDAA will determine that the Mobile 534 Node was already registered with a Home Agent in the old Foreign 535 Network and will therefore create a new set of session keys. In this 536 case the session keys destined for the Home Agent will be encrypted 537 using SS4 and the ones for the Foreign Agent will be encrypted using 538 SS6. 540 Upon receipt of the request, VDAA-1 will decrypt the keys for the 541 Home Agent and re-encrypt them using SS5. Further processing of the 542 packet will occur as previously described. When the KDC response is 543 received by VDAA-2, the session keys for the Foreign Agent will be 544 decrypted using SS6, and re-encrypted using SS7. The message will 545 then be forwarded to the Foreign Agent and further processing will 546 occur as previously described. 548 In the event that the Mobile Node does NOT wish to maintain the Home 549 Agent within the Foreign Network, the Home Agent field within the 550 Registration Request is set to zero. 552 2.4 Smooth Handoff 554 In order to support smooth hand-off, the Mobile Node MUST examine the 555 Foreign Agent NAI within the Router Advertisement when it receives 556 advertisements from a new Foreign Agent. If the Mobile Node 557 determines that both the old and the new Foreign Agents belong to the 558 same administrative domain it can attempt to request smooth hand-off. 559 The Mobile Node MUST include the Challenge and Response as previously 560 described as well as the Mobile-Foreign Authentication and Mobile- 561 Home Authentication extensions. 563 Upon receipt of this Request, the new Foreign Agent (FA-2) can issue 564 the KDC request to its local KDC (VDAA-1), which can determine if it 565 is able to provide smooth hand-off. If VDAA-1 had kept state 566 information that included the session keys previously distributed by 567 the HDAA, VDAA-1 can re-encrypt the session keys using SS5 and return 568 these to the Foreign Agent. At this point, the Foreign Agent can add 569 authenticate the request from the Mobile-Node through the Mobile- 570 Foreign Authentication extension, and can add the Foreign-Home 571 Authentication extension prior to forwarding the request to the Home 572 Agent. 574 +------+ +------+ +------+ 575 | | | | | | 576 | MN |- - - -| FA-2 |- - - - - - - - - -| HA | 577 | | | | | | 578 +---+--+ +---+--+ +---+--+ 579 | | SS5 | SS3 580 +------------------------------+ | 581 | | | 582 +------+ +---+--+ | SS1 +---+--+ 583 | | | | +------+ | 584 | FA-1 +-------+VDAA-1| | HDAA | 585 | | SS2 | +--------------SS4--+ | 586 +------+ +------+ +------+ 588 If VDAA-1 was not able to provide smooth hand-off services, either 589 because it did not have the functionality or because it no longer had 590 a copy of the session keys, it can opt to simply forward the KDC 591 message to HDAA as previously described and the Challenge and 592 Response extensions would be used to authenticate the Mobile Node. 594 2.5 Key Expiration 596 The Key-Lifetime extension, which MUST be present in the Registration 597 Reply if any of the Key extensions are present in the reply, contains 598 the time at which the keys are considered expired. The value of this 599 extension is the high-order 32 bit value of the NTP timstamp. 601 When the Mobile Node needs to re-register and the keys have expired, 602 it MUST request a that new keys be distributed by including ONLY the 603 Foreign-Agent-Challenge and Mobile-Node-Response extensions without 604 any other authentication extension. 606 2.6 Interaction with Home Agent Allocation 608 Earlier we described that the authentication extensions defined in 609 this specification lends well with the Dynamic Home Agent Allocation 610 as described in [9]. In fact, if the Foreign Agent initiates the KDC 611 request, it is envisioned that the KDC also include the functionality 612 that would dynamically assign the Home Agent to the Mobile Node. 614 3.0 Router Discovery Extensions 616 This section will define the extensions necessary to the Router 617 Discovery Protocol [8]. The Mobile Node can assume that the Foreign 618 Agent supports this specification if the extensions in this section 619 are part of the Router Advertisements. 621 3.1 Foreign Agent Challenge Extension 623 The Foreign Agent Challenge Extension is present in the Router 624 Advertisements by the Foreign Agent in order to communicate the 625 latest Challenge value that can be used by the Mobile Node to compute 626 the Challenge Response. 628 The Foreign Agent is responsible for ensuring that the Challenge 629 Value in the Registration Request is current (the Foreign Agent may 630 wish to accept the last two challenge values advertised). 632 The Foreign Agent Challenge Extension is defined as follows: 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Type | Length | Foreign Agent Challenge ... 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Type 642 TDB 644 Length 646 (4 + N), where N is the length of the challenge value. 648 Challenge 650 The Challenge field consists random value of at least 128 bits. 652 3.2 Foreign Agent NAI Extension 654 The Foreign Agent NAI Extension contains the Foreign Agent's Network 655 Access Identifier. This value is used by the Mobile Node to determine 656 if it has entered a new Administrative Domain. 658 For smooth hand-off, the Mobile Node may wish to use the same Session 659 Key and SPI it shared with a previous Foreign Agent if both Foreign 660 Agents are part of the same administrative domain. 662 The Foreign Agent NAI Extension is defined as follows: 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Type | Length | Foreign Agent NAI ... 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 Type 672 TDB 674 Length 676 N, where N is the length of the NAI. 678 FA NAI 680 Foreign Agent's Network Access Identifier 682 4.0 Mobile IP Registration Extensions 684 This section will define new Mobile IP Registration Extensions that 685 must be used in order to use the functionality described in this 686 document. 688 This extension requires that the following new Code be supported in 689 the Registration Reply: 691 SPI_IN_USE TBD 693 The Foreign Agent uses this error code to indicate to the 694 Mobile Node that the SPI received by the HDAA is already in use 695 for another key (one chance in 2^32). Upon receiving this error 696 code the Mobile Node SHOULD re-issue a new Registration 697 Request. 699 4.1 Foreign-Agent-Challenge Extension 701 The Foreign-Agent-Challenge extension is copied from the Challenge in 702 the Foreign Agent's Router Advertisement. This extension SHOULD only 703 be present while there are no keys shared between the Mobile Node and 704 the Foreign Agent (upon initial contact, or upon once the keys have 705 expired). 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Type | Length | Challenge... 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 Type 715 TDB 717 Length 719 Must be at least 18 721 Challenge 723 The Challenge field is copied from the Router Advertisement's 724 Foreign Agent Challenge. 726 4.2 Mobile-Challenge-Response Extension 728 This Extension MUST be included in the Registration Request if either 729 the Home Agent or the Home Address fields are set to zero (0). The 730 authenticator is computed as shown below: 732 FA-Challenge || Packet || Timestamp || Shared Secret 734 Note that the authentication does NOT cover this extension. 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Type | Length | Timestamp .... 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 ... Timestamp (cont.) | Authenticator ... 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 Type 745 TDB 747 Length 749 2 plus the number of bytes in the Authenticator. 751 Timestamp 753 Contains a monotonically increasing value and is used in the hash 754 calculation. This field SHOULD be used to detect replay attacks. 756 Authenticator 758 Variable length hash. 760 4.3 Mobile-Foreign-SPI Extension 762 The Mobile-Foreign-SPI extension contains the Key Identifier created 763 by the HDAA and is used to identify the Mobile-Foreign-Key and the 764 Foreign-Mobile-Key. This SPI is to be used in subsequent Registration 765 Request and Replies within the Mobile-Foreign Authentication 766 extension. 768 0 1 2 3 769 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 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Type | Length | SPI .... 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 ... SPI (cont.) | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 fi 777 Type 779 TDB 781 Length 783 Must be 6 785 SPI 787 The SPI field contains the Security Parameter Index (or Key 788 Identifier) that was created by the HDAA which is used to identify 789 the key found in the Mobile-Foreign-Key extension. 791 4.4 Mobile-Home-SPI Extension 793 The Mobile-Home-SPI extension contains the Key Identifier created by 794 the HDAA and is used to identify the Mobile-Home-Key. This SPI is to 795 be used in subsequent Registration Request and Replies within the 796 Mobile-Home Authentication extension. 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Type | Length | SPI .... 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 ... SPI (cont.) | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 Type 808 TDB 810 Length 812 Must be 6 814 SPI 816 The SPI field contains the Security Parameter Index (Or Key 817 Identifier) that was created by the HDAA which is used to identify 818 the key found in the Mobile-Home-Key extension. 820 4.5 Mobile-Foreign-Key Extension 822 The Mobile-Foreign-Key extension contains the encrypted version of 823 the session key that the Mobile Node is to share with the Foreign 824 Agent in subsequent Registration Request. The key is created by the 825 HDAA and is used in the computation of the Mobile-Foreign 826 Authentication extension. 828 0 1 2 3 829 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 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Type | Length | MN-FA-KEY... 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 Type 836 TDB 838 Length 840 Must be at least 3 842 MN-FA-Key 844 The MN-FA-Key field contains the encrypted version of the session 845 key created by the HDAA. 847 4.6 Mobile-Home-Key Extension 849 The Mobile-Home-Key extension contains the encrypted version of the 850 session key that the Mobile Node is to share with the Home Agent in 851 subsequent Registration Request. The key is created by the HDAA and 852 is used in the computation of the Mobile-Home Authentication 853 extension. 855 0 1 2 3 856 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 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Type | Length | MN-HA-KEY... 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 Type 863 TDB 865 Length 867 Must be at least 3 869 MN-HA-KEY 871 The MN-HA-KEY field contains the encrypted version of the session 872 key created by the HDAA. 874 4.7 Previous-FA-NAI Extension 876 The Previous-FA-NAI Extension contains the NAI which provided service 877 to the Mobile Node prior to the hand-off. The presence of this 878 extension informs the Foreign Agent that smooth hand-off should be 879 done, if possible. 881 The Mobile Node MUST assume that the new Foreign Agent cannot perform 882 smooth hand-off, and therefore MUST include the Foreign-Agent- 883 Challenge and the Mobile-Node-Response extensions as well as the 884 normal authentication extensions. 886 The Previous-FA-NAI Extension is defined as follows: 888 0 1 2 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Type | Length | Previous-FA-NAI... 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 Type 896 TDB 898 Length 900 Must be at least 3 902 Previous-FA-NAI 904 The Previous-FA-NAI field contains the NAI of the Foreign Agent 905 that was servicing the Mobile Node before detecting a new Foreign 906 Agent. 908 4.8 Key-Lifetime Extension 910 The Key-Lifetime extension contains the timestamp at which the keys 911 include in the Registration Reply will be considered expired. The 912 value of the number of seconds before the key expires. 914 Once the keys have expired they can no longer be used. Therefore a 915 request for new keys must be made on behalf of the Mobile Node by 916 including the Challenge and Response 918 0 1 2 3 919 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 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Type | Length | Key-Lifetime .... 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 Key-Lifetime .... | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 Type 928 TDB 930 Length 931 Must be 6 933 Lifetime 935 The Lifetime field contains the number of seconds before the key 936 expires. 938 5.0 Security Analysis 940 This section, although incomplete, attempts to illustrate a few 941 attacks the authors have thought of and how they are dealt with when 942 using the extensions defined in this specification: 944 5.1 Challenge/Response Replay 946 In the event that a malicious Mobile Node attempts to replay an old 947 Foreign-Agent-Challenge and Mobile-Node-Response pair, the Foreign 948 Agent would detect it since the Foreign Agent would be able to verify 949 that it had not recently advertised the Challenge. 951 In the event that both the Mobile Node and the Foreign Agent were 952 malicious, the KDC would recognize the Challenge as being a replay 953 since the timestamp would be invalid. 955 5.2 Malicious FA 957 The possible attack here is where a malicious FA keeps an old KEY and 958 attempts to create a Registration Request on behalf of the Mobile 959 Node using the old KEY. 961 Since both the Mobile Node and the Home Agent share a different key 962 than the Foreign Agent does with both the Mobile Node and the Home 963 Agent this attack is not possible. 965 5.3 Malicious Foreign KDC 967 It is possible for a foreign KDC (perhaps proxying between both the 968 home and the visiting network's KDC) to either keep the KEY for some 969 time to be replayed at a later time, or changes the contents of the 970 KEY. 972 In the case of replay of old keys, the problem is already addressed 973 in section 5.1. In the case where the malicious KDC attempts to alter 974 the KEY, the Home Agent will notice that the Registration Request was 975 not authenticated using the correct KEY and will reject the request. 977 Although this can cause a denial of service attack, the culprit can 978 be traced using the KDC logs. 980 6.0 References 982 [1] P. Calhoun, G. Montenegro, C. Perkins, "Tunnel Establishment 983 Protocol", draft-ietf-mobileip-calhoun-tep-01.txt, March 1998. 985 [2] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 986 1996. 988 [3] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol", 989 draft-calhoun-diameter-00.txt, February 1998. 991 [4] B. Aboba. "The Network Access Identifier." Internet-Draft, 992 August 1997. 994 [5] P. Calhoun, G. Zorn, P. Pan, "DIAMETER Framework", 995 draft-calhoun-diameter-framework-01.txt, August 1998. 997 [6] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extension", 998 draft-calhoun-diameter-mobileip-00.txt, July 1998. 1000 [7] P. Calhoun, W. Bulley, "DIAMETER Proxy Extension". 1001 Internet-Draft, draft-calhoun-diameter-proxy-00.txt, 1002 August 1998. 1004 [8] Deering, S., Editor, "ICMP Router Discovery Messages", 1005 RFC 1256, September 1991. 1007 [9] P. Calhoun, C. Perkins, "Mobile IP Dynamic Home Agent 1008 Allocation", draft-ietf-mobileip-ha-alloc-00.txt, 1009 November 1998. 1011 7.0 Acknowledgements 1013 The authors would like to thank Tom Hiller, Mark Munson, the TIA TR45-6 1014 WG, Gabriel Montenegro and Vipul Gupta for their useful discussions. 1016 8.0 Chairs' Addresses 1018 The working group can be contacted via the current chairs: 1020 Jim Solomon 1021 RedBack Networks 1022 1389 Moffett Park Drive 1023 Sunnyvale, CA 94089-1134 1024 USA 1026 Phone: +1 408 548-3583 1027 Fax: +1 408 548-3599 1028 E-mail: solomon@rback.com 1030 Erik Nordmark 1031 Sun Microsystems, Inc. 1032 901 San Antonio Road 1033 Mailstop UMPK17-202 1034 Mountain View, California 94303 1036 Phone: +1 650 786-5166 1037 Fax: +1 650 786-5896 1038 E-Mail: erik.nordmark@eng.sun.com 1040 9.0 Author's Address 1042 Questions about this memo can be directed to: 1044 Pat R. Calhoun 1045 Network and Security Center 1046 Sun Microsystems Laboratories, Inc. 1047 15 Network Circle 1048 Menlo Park, California, 94025 1049 USA 1051 Phone: 1-650-786-7733 1052 Fax: 1-650-786-6445 1053 E-mail: pat.calhoun@eng.sun.com 1055 Charles E. Perkins 1056 Network and Security Center 1057 Sun Microsystems Laboratories, Inc. 1058 15 Network Circle 1059 Menlo Park, California, 94025 1060 USA 1062 Phone: 1-650-786-6464 1063 Fax: 1-650-786-6445 1064 E-mail: charles.perkins@eng.sun.com