idnits 2.17.1 draft-ietf-mobileip-challenge-08.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 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. ** 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 79: '...the Challenge value in octets; MUST be...' RFC 2119 keyword, line 104: '...n Agent, then it MUST include the Chal...' RFC 2119 keyword, line 107: '...oreign agent, it SHOULD include the Ch...' RFC 2119 keyword, line 111: '... Agent, it MUST include a Mobile-For...' RFC 2119 keyword, line 115: '...n Authentication MUST follow the Chall...' (39 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. 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 (-12) exists of draft-calhoun-diameter-mobileip-01 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-07 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mn-nai-05 ** Obsolete normative reference: RFC 1750 (ref. '6') (Obsoleted by RFC 4086) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-08 == Outdated reference: A later version (-07) exists of draft-ietf-mobileip-mier-00 -- Possible downref: Normative reference to a draft: ref. '8' ** Obsolete normative reference: RFC 2344 (ref. '9') (Obsoleted by RFC 3024) ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '10') ** Obsolete normative reference: RFC 2461 (ref. '11') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2002 (ref. '12') (Obsoleted by RFC 3220) == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-08 -- Possible downref: Normative reference to a draft: ref. '13' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '14') Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 6 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 6 January 2000 Pat R. Calhoun 4 Sun Microsystems Laboratories 6 Mobile IP Challenge/Response Extensions 7 draft-ietf-mobileip-challenge-08.txt 9 Status of This Memo 11 This document is a submission by the mobile-ip Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at: 31 http://www.ietf.org/shadow.html. 33 Abstract 35 Mobile IP, as originally specified, defines an authentication 36 extension (the Mobile-Foreign Authentication extension) by 37 which a mobile node can authenticate itself to a foreign agent. 38 Unfortunately, this extension does not provide ironclad replay 39 protection for the foreign agent, and does not allow for the use 40 of existing techniques (such as CHAP) for authenticating portable 41 computer devices. In this specification, we define extensions for 42 the Mobile IP Agent Advertisements and the Registration Request 43 that allow a foreign agent to use a challenge/response mechanism to 44 authenticate the mobile node. 46 1. Introduction 48 Mobile IP, as originally specified, defines an authentication 49 extension (the Mobile-Foreign Authentication extension) by 50 which a mobile node can authenticate itself to a foreign agent. 51 Unfortunately, this extension does not provide ironclad replay 52 protection, from the point of view of the foreign agent, and does 53 not allow for the use of existing techniques (such as CHAP [15]) for 54 authenticating portable computer devices. In this specification, 55 we define extensions for the Mobile IP Agent Advertisements and 56 the Registration Request that allow a foreign agent to a use 57 challenge/response mechanism to authenticate the mobile node. 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in [1]. 63 2. Mobile IP Agent Advertisement Challenge Extension 65 This section defines a new extension to the Router Discovery 66 Protocol [5] for use by foreign agents that need to issue a challenge 67 for authenticating mobile nodes. 69 0 1 2 3 70 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 71 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 72 | Type | Length | Challenge ... 73 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 75 Figure 1: The Challenge Extension 77 Type 24 79 Length The length of the Challenge value in octets; MUST be 80 at least 16 82 Challenge A random value of at least 128 bits. 84 The Challenge extension, illustrated in figure 1, is inserted 85 in the Agent Advertisements by the Foreign Agent, in order to 86 communicate the latest challenge value that can be used by the mobile 87 node to compute an authentication for its registration request 88 message. The challenge is selected by the foreign agent to provide 89 local assurance that the mobile node is not replaying any earlier 90 registration request. Eastlake, et al. [6] provides more information 91 on generating pseudo-random numbers suitable for use as values for 92 the challenge. 94 3. Operation 96 This section describes modifications to the Mobile IP registration 97 process which may occur after the Foreign Agent issues a Mobile IP 98 Agent Advertisement containing the Challenge on its local link. 100 3.1. Mobile Node Processing for Registration Requests 102 Whenever the Agent Advertisement contains the Challenge extension, 103 if the mobile node does not have a security association with the 104 Foreign Agent, then it MUST include the Challenge value in a MN-FA 105 Challenge extension to the Registration Request message. If, on 106 the other hand, the mobile node does have a security association 107 with the foreign agent, it SHOULD include the Challenge value in its 108 Registration Request message. 110 If the Mobile Node has a security association with the Foreign 111 Agent, it MUST include a Mobile-Foreign Authentication extension 112 in its Registration Request message, according to the base 113 Mobile IP specification [12]. When the Registration Request 114 contains the MN-FA Challenge extension specified in section 4, the 115 Mobile-Foreign Authentication MUST follow the Challenge extension in 116 the Registration Request. 118 If the Mobile Node does not have a security association with the 119 Foreign Agent, the Mobile Node MUST include the MN-AAA Authentication 120 extension as defined in section 6. In addition, the Mobile 121 Node SHOULD include the NAI extension [4], to enable the foreign 122 agent to make use of any available verification infrastructure. 123 The SPI field of the MN-AAA Authentication extension specifies 124 the particular secret and algorithm (shared between the Mobile 125 Node and the verification infrastructure) that must be used 126 to perform the authentication. If the SPI value is chosen as 127 CHAP_SPI (see section 9), then the mobile node specifies CHAP-style 128 authentication [15] using MD5 [14]. 130 In either case, the MN-FA Challenge extension and one of the above 131 specified authentication extensions MUST follow the Mobile-Home 132 Authentication extension, if present. 134 A successful Registration Reply from the Foreign Agent MAY include 135 a new Challenge value (see section 3.3). The Mobile Node MAY use 136 either the value found in the latest Advertisement, or the one found 137 in the last Registration Reply from the Foreign Agent. This approach 138 enables the Mobile Node to make use of the challenge without having 139 to wait for advertisements. 141 A Mobile Node might receive an UNKNOWN_CHALLENGE error (see 142 section 9) if it moves to a new Foreign Agent that cannot validate 143 the challenge provided in the Registration Request. In such 144 instances, the Mobile Node MUST use a new Challenge value in any new 145 registration, obtained either from an Agent Advertisement, or from a 146 Challenge extension to the Registration Reply containing the error. 148 A Mobile Node that does not include a Challenge when the 149 Mobile-Foreign Authentication extension is present may receive a 150 MISSING_CHALLENGE (see section 10) error. In this case, the foreign 151 agent will not process the request from the mobile node unless the 152 request contains a valid Challenge. 154 3.2. Foreign Agent Processing for Registration Requests 156 Upon receipt of the Registration Request, if the Foreign Agent has 157 issued a Challenge as part of its Agent Advertisements, and it does 158 not have a security association with the mobile node, then the 159 Foreign Agent MUST check that the MN-FA Challenge extension exists, 160 and that it contains a challenge value previously unused by the 161 Mobile Node. This ensures that the mobile node is not attempting 162 to replay a previous advertisement and authentication. If the 163 challenge extension is needed and does not exist, the Foreign Agent 164 MUST send a Regstration Reply to the mobile node with the error code 165 MISSING_CHALLENGE. 167 A foreign agent that sends Agent Advertsements containing a Challenge 168 value MAY send a Registration Reply message with a MISSING_CHALLENGE 169 error if the mobile node sends a Registration Request with a 170 Mobile-Foreign Authentication extension without including a 171 Challenge. In other words, such a foreign agent MAY refuse to 172 process a Registration Request request from the mobile node unless 173 the request contains a valid Challenge. 175 If a mobile node retransmits a Registration Request with the same 176 Identification field and the same Challenge extension, and the 177 Foreign Agent still has a pending Registration Request record 178 in effect for the mobile node, then the Foreign Agent forwards 179 the Registration Request to the Home Agent again. In all other 180 circumstances, if the Foreign Agent receives a Registration 181 Request with a Challenge extension containing a Challenge value 182 previously used by that mobile node, the Foreign Agent SHOULD send 183 a Registration Reply to the mobile node containing the Code value 184 STALE_CHALLENGE. 186 The Foreign Agent MUST NOT accept any Challenge in the Registration 187 Request unless it was offered in last successful Registration Reply 188 issued to the Mobile Node, or else advertised as one of the last 189 CHALLENGE_WINDOW (see section 9) Challenge values inserted into the 190 immediately preceding Agent advertisements. If the Challenge is not 191 one of the recently advertised values, the foreign Agent SHOULD send 192 a Registration Reply with Code UNKNOWN_CHALLENGE (see section 10). 194 Furthermore, the Foreign Agent MUST check that there is either a 195 Mobile-Foreign, or a MN-AAA Authentication after the Challenge 196 extension. Any registration message containing the Challenge 197 extension without either of these authentication extensions MUST 198 be silently discarded. If the registration message contains 199 a Mobile-Foreign Authentication extension with an incorrect 200 authenticator that fails verification, the Foreign Agent MAY 201 send a Registration Reply to the mobile node with Code value 202 BAD_AUTHENTICATION (see Section 10). 204 If MN-AAA Authentication extension (see Section 6) is present in 205 the message, or if an NAI extension is included indicating that 206 the mobile node belongs to a different administrative domain, the 207 foreign agent may take actions outside the scope of this protocol 208 specification to carry out the authentication of the mobile node. 209 The appendix provides an example of an action that could be taken by 210 a foreign agent. 212 Since the Challenge extension, and the authentication extension that 213 is used by the Mobile Node to satisfy the challenge, both follow 214 the Mobile-Home Authentication extension whenever the latter is 215 present, the Foreign Agent MAY remove the Challenge Extension and 216 the applicable authentication from the Registration Request without 217 disturbing the authentication value computed by the Mobile Node for 218 use by the Home Agent. 220 If the Foreign Agent does not remove those extensions, then the 221 Foreign Agent SHOULD store the Challenge value as part of the pending 222 registration request list [12]. Also in this case, the Foreign Agent 223 MUST reject any Registration Reply message coming from the Home Agent 224 that does not also include the Challenge Extension with the same 225 Challenge Value that was included in the Registration Request. The 226 Foreign Agent MUST send the rejected Registration message to the 227 mobile node, and change the status in the Registration Reply to the 228 value MISSING_CHALLENGE (see section 10). 230 If the Foreign Agent does remove the Challenge extension and 231 applicable authentication from the Registration Request message, 232 then it SHOULD insert the Identification field from the Registration 233 Request message along with its record-keeping information about the 234 particular Mobile Node in order to protect against replays. 236 3.3. Foreign Agent Processing for Registration Replies 238 The Foreign Agent MAY include a new Challenge extension in any 239 Registration Reply, successful or not. If the foreign agent includes 240 this extension in a successful Registration Reply, the extension 241 SHOULD precede a MN-FA authentication extension. 243 Suppose the Registration Reply includes a Challenge extension from 244 the Home Agent, and the foreign agent wishes to include another 245 Challenge extension with the Registration Reply for use by the mobile 246 node. In that case, the foreign agent MUST delete the Challenge 247 extension from the Home Agent from the Registration Reply, along 248 with any FA-HA authentication extension, before appending the new 249 Challenge extension to the Registration Reply. 251 3.4. Home Agent Processing for the Challenge Extensions 253 If the Home Agent receives a Registration Request with the MN-FA 254 Challenge extension, and recognizes the extension, the Home Agent 255 MUST include the Challenge extension in the Registration Reply. 256 The Challenge Extension MUST be placed after the Mobile-Home 257 authentication extension, and the extension SHOULD be authenticated 258 by a Foreign-Home Authentication extension. 260 Since the extension type for the Challenge extension is within the 261 range 128-255, the Home Agent MUST process such a Registration 262 Request even if it does not recognize the Challenge extension [12]. 263 In this case, the Home Agent will send a Registration Reply to the 264 Foreign Agent that does not include the Challenge extension. 266 4. MN-FA Challenge Extension 268 This section specifies a new Mobile IP Registration extension that is 269 used to satisfy a Challenge in an Agent Advertisement. The Challenge 270 extension to the Registration Request message is used to indicate the 271 challenge that the mobile node is attempting to satisfy. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type | Length | Challenge... 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 2: The MN-FA Challenge Extension 281 Type 132 (skippable) (see [12]) 283 Length MUST be at least 16 285 Challenge The Challenge field is copied from the Challenge field 286 found in the Agent Advertisement Challenge extension 287 (see section 2). 289 5. Generalized Mobile IP Authentication Extension 291 Several new authentication extensions have been designed for various 292 control messages proposed for extensions to Mobile IP (see, for 293 example, [13]). A new authentication extension is required for a 294 mobile node to present its credentials to any other entity other 295 than the ones already defined; the only entities defined in the base 296 Mobile IP specification [12] are the home agent and the foreign 297 agent. It is the purpose of the generalized authentication extension 298 defined here to collect together data for all such new authentication 299 applications into a single extension type with subtypes. 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Type | Subtype | Length | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | SPI | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Authenticator ... 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 3: The Generalized Mobile IP Authentication Extension 312 Type 36 (not skippable) (see [12]) 314 Subtype a number assigned to identify the kind of 315 endpoints or characteristics of the particular 316 authentication strategy 318 Length 4 plus the number of bytes in the Authenticator; 319 MUST be at least 20. 321 SPI Security Parameters Index 323 Authenticator The variable length Authenticator field 325 In this document, only one subtype is defined: 327 1 MN-AAA Authentication subtype (see section 6) 329 6. MN-AAA Authentication subtype 331 The Generalized Authentication extension with subtype 1 will be 332 referred to as a MN-AAA Authentication extension. If the mobile node 333 does not include a Mobile-Foreign Authentication [12] extension, 334 then it MUST include the MN-AAA Authentication extension whenever 335 the Challenge extension is present. If the MN-AAA Authentication 336 extension is present, then the Registration Message MAY be sent by 337 the mobile node without containing the Mobile-HA Authentication 338 extension [12]. The mobile node MAY include a MN-AAA Authentication 339 extension in any Registration Request. 341 The default algorithm for computation of the authenticator is 342 MD5 [14] computed on the following data, in the order shown: 344 Key || Preceding Mobile IP data || 345 Type, Subtype, Length, SPI || Key 347 where the Type, Length, Subtype, and SPI are as shown in 348 section 5. Each mobile node MUST support the ability to produce the 349 authenticator by using MD5 as shown (known as "prefix+suffix" mode). 350 Just as with Mobile IP, this default algorithm MUST be able to be 351 configured for selection at any arbitrary 32-bit SPI outside of the 352 SPIs in the reserved range 0-255. 354 7. Reserved SPIs for Mobile IP 356 Mobile IP defines several authentication extensions for use in 357 Registration Requests and Replies. Each authentication extension 358 carries a Security Parameters Index (SPI) which should be used to 359 index a table of security associations. Values in the range 0 - 255 360 are reserved for special use. A list of reserved SPI numbers is to 361 be maintained by IANA at the following URL: 363 http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers 365 8. SPI For RADIUS AAA Servers 367 Some AAA servers only admit a single security association, and thus 368 do not use the SPI numbers for Mobile IP authentication extensions 369 for use when determining the security association that would be 370 necessary for verifying the authentication information included with 371 the Authentication extension. 373 SPI number CHAP_SPI (see section 9) is reserved (see section 7) for 374 indicating the following procedure for computing authentication data 375 (called the "authenticator"), which is used by many RADIUS servers 376 today. 378 To compute the authenticator, apply MD5 [14] computed on the 379 following data, in the order shown: 381 High-order byte from Challenge || Key || 382 MD5(Preceding Mobile IP data || 383 Type, Subtype (if present), Length, SPI || 384 Least-order 237 bytes from Challenge 386 where the Type, Length, SPI, and possibly Subtype, are the fields 387 of the authentication extension in use. For instance, all four of 388 these fields would be in use when SPI == CHAP_SPI is used with the 389 Generalized Authentication extension. Since the RADIUS protocol 390 cannot carry attributes greater than 253 in size, the preceding 391 Mobile IP data, type, subtype (if present), length and SPI are 392 hashed using MD5. Finally, the least significant 237 octets of the 393 challenge are concatenated. 395 9. Configurable Parameters 397 Every Mobile IP agent supporting the extensions defined in this 398 document SHOULD be able to configure each parameter in the following 399 table. Each table entry contains the name of the parameter, the 400 default value, and the section of the document in which the parameter 401 first appears. 403 Parameter Name Default Value Section(s) of Document 404 -------------- ------------- ---------------------- 405 CHALLENGE_WINDOW 2 3.2 406 CHAP_SPI TBD 8,11 408 10. Error Values 410 Each entry in the following table contains the name of Code [12] to 411 be returned in a Registration Reply, the value for the Code, and the 412 section in which the error is first mentioned in this specification. 414 Error Name Value Section of Document 415 ---------------------- ----- ------------------- 416 UNKNOWN_CHALLENGE 104 3.2 417 BAD_AUTHENTICATION 67 3.2 - also see [12] 418 MISSING_CHALLENGE 105 3.1,3.2 419 STALE_CHALLENGE 106 3.2 421 11. IANA Considerations 423 The number for the Mobile IP Agent Advertisement Challenge extension 424 (section 2) is taken from the numbering space defined for Mobile 425 IP [12] extensions to the ICMP Router Advertisements [5]. The number 426 for the MN-FA Challenge extension (section 4) and the Generalized 427 Authentication extension (section 5) is taken from the numbering 428 space defined for Mobile IP registration extensions [12] as extended 429 for reverse tunnels [9], and the Mobile IP Network Address Identifier 430 Extension specification [4]. The numbering for the extensions SHOULD 431 NOT conflict with values specified in the Internet Draft for Route 432 Optimization [13]. The Code values specified for errors, listed 433 in section 10, MUST NOT conflict with any other code values listed 434 in RFC 2002, RFC 2344 [9], or RFC 2356 [10], or the abovementioned 435 Internet Drafts. These code values are to be taken from the space of 436 error values conventionally associated with rejection by the foreign 437 agent (i.e., 64-127). 439 A new section for enumerating algorithms identified by specific SPIs 440 within the range 0-255 is to be added to 442 http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers. 444 The CHAP_SPI number discussed in section 8 is to be assigned from 445 this range of reserved SPI numbers. New assignments from this 446 reserved range must be specified and approved by the Mobile IP 447 working group. SPI number 1 should not be assigned unless in the 448 future the Mobile IP working group decides that SKIP is not important 449 for enumeration in the list of reserved numbers. SPI number 0 should 450 not be assigned. 452 A new number space is to be created for enumerating subtypes of the 453 Generalized Authentication extension (see section 5). New subtypes 454 of the Generalized Authentication extension, other than that for 455 the MN-AAA authentication extension specified in section 6, must be 456 specified and approved by the Mobile IP working group. 458 12. Security Considerations 460 In the event that a malicious mobile node attempts to replay the 461 authenticator for an old MN-FA Challenge, the Foreign Agent would 462 detect it since the agent always checks whether it has recently 463 advertised the Challenge (see section 3.2). Allowing mobile nodes 464 with different IP addresses or NAIs to use the same Challenge 465 value does not represent a security vulnerability, because the 466 authentication data provided by the mobile node will be computed over 467 data that is different (at least by the bytes of the mobile nodes' IP 468 addresses). 470 Whenever a Foreign Agent updates a field of the Registration Reply 471 (as suggested in section 3.2), it invalidates the authentication data 472 supplied by the Home Agent in the MN-HA Authentication extension to 473 the Registration Reply. Thus, this opens up a security exposure 474 whereby a node might try to supply a bogus Registration Reply to a 475 mobile node that causes the mobile node to act as if its Registration 476 Reply were rejected. This might happen when, in fact, a Registration 477 Reply showing acceptance of the registration might soon be received 478 by the mobile node. 480 13. IPv6 Considerations 482 For use with IPv6 mobility [7], the challenge extension should 483 be applied to Router Advertisements [11]. In order to check the 484 response from the mobile node, the router would need to have a 485 security relationship with either the mobile node, its home agent, 486 or another entity within the IPv6 security infrastructure. It is 487 not yet known which security model would be more appropriate, or 488 whether it would make the most sense to enable maximum flexibility by 489 specifying the protocol for each case. 491 14. Acknowledgements 493 The authors would like to thank Tom Hiller, Mark Munson, the TIA 494 TR45-6 WG, Gabriel Montenegro, Vipul Gupta, and Pete McCann for their 495 useful discussions. A recent draft [8] by Mohamed Khalil, Raja 496 Narayanan, Emad Qaddoura, and Haseeb Akhtar has also suggested the 497 definition of a generalized authentication extension similar to the 498 specification contained in section 5. 500 References 502 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 503 Levels. Request for Comments (Best Current Practice) 2119, 504 Internet Engineering Task Force, March 1997. 506 [2] P. Calhoun and C. Perkins. DIAMETER Mobile IP Extensions. 507 Internet Draft, Internet Engineering Task Force. 508 draft-calhoun-diameter-mobileip-01.txt, November 1998. Work in 509 progress. 511 [3] P. Calhoun and A. Rubens. DIAMETER Base Protocol. Internet 512 Draft, Internet Engineering Task Force. 513 draft-calhoun-diameter-07.txt, November 1998. Work in progress. 515 [4] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network 516 Address Identifier Extension. 517 draft-ietf-mobileip-mn-nai-05.txt, October 1999. (work in 518 progress). 520 [5] S. Deering. ICMP Router Discovery Messages. Request for 521 Comments (Proposed Standard) 1256, Internet Engineering Task 522 Force, September 1991. 524 [6] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 525 Recommendations for Security. Request for Comments 526 (Informational) 1750, Internet Engineering Task Force, December 527 1994. 529 [7] D. Johnson and C. Perkins. Mobility Support in IPv6. 530 draft-ietf-mobileip-ipv6-08.txt, June 1999. (work in progress). 532 [8] Mohamed Khalil, Raja Narayanan, Emad Qaddoura, and Haseeb 533 Akhtar. Mobile IP Extensions Rationalization (MIER). 534 draft-ietf-mobileip-mier-00.txt, December 1999. (work in 535 progress). 537 [9] G. Montenegro. Reverse Tunneling for Mobile IP. Request for 538 Comments (Proposed Standard) 2344, Internet Engineering Task 539 Force, May 1998. 541 [10] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 542 Mobile IP. Request for Comments (Informational) 2356, Internet 543 Engineering Task Force, June 1998. 545 [11] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 546 IP Version 6 (IPv6). Request for Comments (Draft Standard) 547 2461, Internet Engineering Task Force, December 1998. 549 [12] C. Perkins. IP Mobility Support. Request for Comments 550 (Proposed Standard) 2002, Internet Engineering Task Force, 551 October 1996. 553 [13] C. Perkins and D. Johnson. Route Optimization in Mobile IP. 554 Internet Draft, Internet Engineering Task Force. 555 draft-ietf-mobileip-optim-08.txt, February 1999. Work in 556 progress. 558 [14] R. Rivest. The MD5 Message-Digest Algorithm. Request for 559 Comments (Informational) 1321, Internet Engineering Task Force, 560 April 1992. 562 [15] W. Simpson. PPP Challenge Handshake Authentication Protocol 563 (CHAP). Request for Comments (Draft Standard) 1994, Internet 564 Engineering Task Force, August 1996. 566 A. Verification Infrastructure 568 The Challenge extensions in this protocol specification are expected 569 to be useful to help the Foreign Agent manage connectivity for 570 visiting mobile nodes, even in situations where the foreign agent 571 does not have any security association with the mobile node or the 572 mobile node's home agent. In order to carry out the necessary 573 authentication, it is expected that the foreign agent will need the 574 assistance of external administrative systems, which have come to be 575 called AAA systems. For the purposes of this document, we call the 576 external administrative support the "verification infrastructure". 577 The verification infrastructure is described to motivate the design 578 of the protocol elements defined in this document, and is not 579 strictly needed for the protocol to work. The foreign agent is free 580 to use any means at its disposal to verify the credentials of the 581 mobile node. This could, for instance, rely on a separate protocol 582 between the foreign agent and the Mobile IP home agent, and still be 583 completely invisible to the mobile node. 585 In order to verify the credentials of the mobile node, we imagine 586 that the foreign agent has access to a verification infrastructure 587 that can return a secure notification to the foreign agent that 588 the authentication has been performed, along with the results of 589 that authentication. This infrastructure may be visualized as 590 shown in figure 4. For an example of another protocol that has 591 been specified to actually carry out the challenge verification 592 operations, see [3, 2]. 594 +----------------------------------------------------+ 595 | | 596 | Verification and Key Management Infrastructure | 597 | | 598 +----------------------------------------------------+ 599 ^ | ^ | 600 | | | | 601 | v | v 602 +---------------+ +---------------+ 603 | | | | 604 | Foreign Agent | | Home Agent | 605 | | | | 606 +---------------+ +---------------+ 608 Figure 4: The Verification Infrastructure 610 After the foreign agent gets the Challenge authentication, it MAY 611 pass the authentication to the (here unspecified) infrastructure, 612 and await a Registration Reply. If the Reply has a positive status 613 (indicating that the registration was accepted), the foreign agent 614 accepts the registration. If the Reply contains the Code value 615 BAD_AUTHENTICATION (see Section 10), the foreign agent takes actions 616 indicated for rejected registrations. 618 Implicit in this picture, is the important observation that the 619 Foreign Agent and the Home Agent have to be equipped to make use 620 of whatever protocol is made available to them by the challenge 621 verification and key management infrastructure shown in the figure. 623 The protocol messages for handling the authentication within the 624 verification infrastructure, and identity of the agent performing the 625 verification of the Foreign Agent challenge, are not specified in 626 this document, because those operations do not have to be performed 627 by any Mobile IP entity. 629 Addresses 631 The working group can be contacted via the current chairs: 633 Basavaraj Patil Phil Roberts 634 Nortel Networks Inc. Motorola 635 2201 Lakeside Blvd. 1501 West Shure Drive 636 Richardson, TX. 75082-4399 Arlington Heights, IL 60004 637 USA USA 639 Phone: +1 972-684-1489 Phone: +1 847-632-3148 640 EMail: bpatil@nortelnetworks.com EMail: QA3445@email.mot.com 642 Questions about this memo can be directed to: 644 Charles E. Perkins Pat R. Calhoun 645 Nokia Research Center Sun Microsystems Laboratories 646 313 Fairchild Drive 15 Network Circle 647 Mountain View, California 94043 Menlo Park, California 94025 648 USA USA 650 Phone: +1-650 625-2986 Phone: +1 650-786-7733 651 EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com 652 Fax: +1 650 625-2502 Fax: +1 650-786-6445