idnits 2.17.1 draft-ietf-mobileip-challenge-13.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 122: '...he Challenge value in bytes; SHOULD be...' RFC 2119 keyword, line 125: '...andom value that SHOULD be at least 32...' RFC 2119 keyword, line 147: '...n Agent, then it MUST include the Chal...' RFC 2119 keyword, line 150: '...oreign agent, it SHOULD include the Ch...' RFC 2119 keyword, line 154: '... Agent, it MUST include a Mobile-For...' (44 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [8], 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) ** Obsolete normative reference: RFC 1750 (ref. '4') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '5') ** Obsolete normative reference: RFC 2344 (ref. '6') (Obsoleted by RFC 3024) ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '7') ** Obsolete normative reference: RFC 2002 (ref. '8') (Obsoleted by RFC 3220) == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-09 -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 2138 (ref. '10') (Obsoleted by RFC 2865) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '11') Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 23 June 2000 Pat R. Calhoun 4 Sun Microsystems Laboratories 6 Mobile IPv4 Challenge/Response Extensions 7 draft-ietf-mobileip-challenge-13.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 Contents 48 Status of This Memo i 50 Abstract i 52 1. Introduction 1 54 2. Mobile IP Agent Advertisement Challenge Extension 2 56 3. Operation 2 57 3.1. Mobile Node Processing for Registration Requests . . . . 2 58 3.2. Foreign Agent Processing for Registration Requests . . . 4 59 3.3. Foreign Agent Processing for Registration Replies . . . . 5 60 3.4. Home Agent Processing for the Challenge Extensions . . . 6 62 4. MN-FA Challenge Extension 7 64 5. Generalized Mobile IP Authentication Extension 7 66 6. MN-AAA Authentication subtype 8 68 7. Reserved SPIs for Mobile IP 9 70 8. SPI For RADIUS AAA Servers 9 72 9. Configurable Parameters 11 74 10. Error Values 11 76 11. IANA Considerations 11 78 12. Security Considerations 12 80 13. Acknowledgements 13 82 A. Verification Infrastructure 15 84 Addresses 16 86 1. Introduction 88 Mobile IP, as originally specified, defines an authentication 89 extension (the Mobile-Foreign Authentication extension) by 90 which a mobile node can authenticate itself to a foreign agent. 92 Unfortunately, this extension does not provide ironclad replay 93 protection, from the point of view of the foreign agent, and does 94 not allow for the use of existing techniques (such as CHAP [12]) for 95 authenticating portable computer devices. In this specification, 96 we define extensions for the Mobile IP Agent Advertisements and 97 the Registration Request that allow a foreign agent to a use 98 challenge/response mechanism to authenticate the mobile node. 100 All SPI values defined in this document refer to values for the 101 Security Parameter Index, as defined in RFC 2002 [8]. The key words 102 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 103 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 104 are to be interpreted as described in [1]. 106 2. Mobile IP Agent Advertisement Challenge Extension 108 This section defines a new extension to the Router Discovery 109 Protocol [3] for use by foreign agents that need to issue a challenge 110 for authenticating mobile nodes. 112 0 1 2 3 113 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 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Type | Length | Challenge ... 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Figure 1: The Challenge Extension 120 Type 24 122 Length The length of the Challenge value in bytes; SHOULD be 123 at least 4 125 Challenge A random value that SHOULD be at least 32 bits. 127 The Challenge extension, illustrated in figure 1, is inserted 128 in the Agent Advertisements by the Foreign Agent, in order to 129 communicate the latest challenge value that can be used by the mobile 130 node to compute an authentication for its registration request 131 message. The challenge is selected by the foreign agent to provide 132 local assurance that the mobile node is not replaying any earlier 133 registration request. Eastlake, et al. [4] provides more information 134 on generating pseudo-random numbers suitable for use as values for 135 the challenge. 137 3. Operation 139 This section describes modifications to the Mobile IP registration 140 process which may occur after the Foreign Agent issues a Mobile IP 141 Agent Advertisement containing the Challenge on its local link. 143 3.1. Mobile Node Processing for Registration Requests 145 Whenever the Agent Advertisement contains the Challenge extension, 146 if the mobile node does not have a security association with the 147 Foreign Agent, then it MUST include the Challenge value in a MN-FA 148 Challenge extension to the Registration Request message. If, on 149 the other hand, the mobile node does have a security association 150 with the foreign agent, it SHOULD include the Challenge value in its 151 Registration Request message. 153 If the Mobile Node has a security association with the Foreign 154 Agent, it MUST include a Mobile-Foreign Authentication extension 155 in its Registration Request message, according to the base Mobile 156 IP specification [8]. When the Registration Request contains the 157 MN-FA Challenge extension specified in section 4, the Mobile-Foreign 158 Authentication MUST follow the Challenge extension in the 159 Registration Request. 161 If the Mobile Node does not have a security association with the 162 Foreign Agent, the Mobile Node MUST include the MN-AAA Authentication 163 extension as defined in section 6. In addition, the Mobile 164 Node SHOULD include the NAI extension [2], to enable the foreign 165 agent to make use of any available verification infrastructure. 166 The SPI field of the MN-AAA Authentication extension specifies 167 the particular secret and algorithm (shared between the Mobile 168 Node and the verification infrastructure) that must be used 169 to perform the authentication. If the SPI value is chosen as 170 CHAP_SPI (see section 9), then the mobile node specifies CHAP-style 171 authentication [12] using MD5 [11]. 173 In either case, the MN-FA Challenge extension and one of the above 174 specified authentication extensions MUST follow the Mobile-Home 175 Authentication extension, if present. 177 A successful Registration Reply from the Foreign Agent MAY include 178 a new Challenge value (see section 3.3). The Mobile Node MAY use 179 either the value found in the latest Advertisement, or the one found 180 in the last Registration Reply from the Foreign Agent. This approach 181 enables the Mobile Node to make use of the challenge without having 182 to wait for advertisements. 184 A Mobile Node might receive an UNKNOWN_CHALLENGE error (see 185 section 9) if it moves to a new Foreign Agent that cannot validate 186 the challenge provided in the Registration Request. In such 187 instances, the Mobile Node MUST use a new Challenge value in any new 188 registration, obtained either from an Agent Advertisement, or from a 189 Challenge extension to the Registration Reply containing the error. 191 A Mobile Node that does not include a Challenge when the 192 Mobile-Foreign Authentication extension is present may receive a 193 MISSING_CHALLENGE (see section 10) error. In this case, the foreign 194 agent will not process the request from the mobile node unless the 195 request contains a valid Challenge. 197 A Mobile Node that receives a BAD_AUTHENTICATION error code (see 198 section 10) SHOULD include the MN-AAA Authentication Extension in 199 the next Registration Request. This will make it possible for the 200 Foreign Agent to use its AAA infrastructure in order to authenticate 201 the Mobile Node. 203 3.2. Foreign Agent Processing for Registration Requests 205 Upon receipt of the Registration Request, if the Foreign Agent has 206 issued a Challenge as part of its Agent Advertisements, and it does 207 not have a security association with the mobile node, then the 208 Foreign Agent MUST check that the MN-FA Challenge extension exists, 209 and that it contains a challenge value previously unused by the 210 Mobile Node. This ensures that the mobile node is not attempting 211 to replay a previous advertisement and authentication. If the 212 challenge extension is needed and does not exist, the Foreign Agent 213 MUST send a Registration Reply to the mobile node with the error code 214 MISSING_CHALLENGE. 216 A foreign agent that sends Agent Advertisements containing a 217 Challenge value MAY send a Registration Reply message with a 218 MISSING_CHALLENGE error if the mobile node sends a Registration 219 Request with a Mobile-Foreign Authentication extension without 220 including a Challenge. In other words, such a foreign agent MAY 221 refuse to process a Registration Request request from the mobile node 222 unless the request contains a valid Challenge. 224 If a mobile node retransmits a Registration Request with the same 225 Identification field and the same Challenge extension, and the 226 Foreign Agent still has a pending Registration Request record 227 in effect for the mobile node, then the Foreign Agent forwards 228 the Registration Request to the Home Agent again. In all other 229 circumstances, if the Foreign Agent receives a Registration 230 Request with a Challenge extension containing a Challenge value 231 previously used by that mobile node, the Foreign Agent SHOULD send 232 a Registration Reply to the mobile node containing the Code value 233 STALE_CHALLENGE. 235 The Foreign Agent MUST NOT accept any Challenge in the Registration 236 Request unless it was offered in last successful Registration Reply 237 issued to the Mobile Node, or else advertised as one of the last 238 CHALLENGE_WINDOW (see section 9) Challenge values inserted into the 239 immediately preceding Agent advertisements. If the Challenge is not 240 one of the recently advertised values, the foreign Agent SHOULD send 241 a Registration Reply with Code UNKNOWN_CHALLENGE (see section 10). 243 Furthermore, the Foreign Agent MUST check that there is either 244 a Mobile-Foreign, or a MN-AAA Authentication extension after 245 the Challenge extension. Any registration message containing 246 the Challenge extension without either of these authentication 247 extensions MUST be silently discarded. If the registration 248 message contains a Mobile-Foreign Authentication extension with an 249 incorrect authenticator that fails verification, the Foreign Agent 250 MAY send a Registration Reply to the mobile node with Code value 251 BAD_AUTHENTICATION (see Section 10). 253 If the MN-AAA Authentication extension (see Section 6) is present 254 in the message, or if an NAI extension is included indicating that 255 the mobile node belongs to a different administrative domain, the 256 foreign agent may take actions outside the scope of this protocol 257 specification to carry out the authentication of the mobile node. 258 The Foreign Agent MUST NOT remove the MN-AAA Authentication Extension 259 from the Registration Request prior to the completion of the 260 authentication performed by the AAA infrastructure. The appendix 261 provides an example of an action that could be taken by a foreign 262 agent. 264 In the event that the Challenge extension is authenticated through 265 the Mobile-Foreign Authentication Extension, the Foreign Agent MAY 266 remove the Challenge Extension from the Registration Request without 267 disturbing the authentication value computed by the Mobile Node for 268 use by the AAA or the Home Agent. If the Challenge extension is not 269 removed, it MUST precede the Foreign-Home Authentication extension. 271 If the Foreign Agent does not remove the Challenge extension, then 272 the Foreign Agent SHOULD store the Challenge value as part of the 273 pending registration request list [8]. Also in this case, the 274 Foreign Agent MUST reject any Registration Reply message coming from 275 the Home Agent that does not also include the Challenge Extension 276 with the same Challenge Value that was included in the Registration 277 Request. The Foreign Agent MUST send the rejected Registration 278 message to the mobile node, and change the status in the Registration 279 Reply to the value MISSING_CHALLENGE (see section 10). 281 If the Foreign Agent does remove the Challenge extension and 282 applicable authentication from the Registration Request message, 283 then it SHOULD insert the Identification field from the Registration 284 Request message along with its record-keeping information about the 285 particular Mobile Node in order to protect against replays. 287 3.3. Foreign Agent Processing for Registration Replies 289 The Foreign Agent MAY include a new Challenge extension in any 290 Registration Reply, successful or not. If the foreign agent includes 291 this extension in a successful Registration Reply, the extension 292 SHOULD precede a MN-FA authentication extension. 294 Suppose the Registration Reply includes a Challenge extension from 295 the Home Agent, and the foreign agent wishes to include another 296 Challenge extension with the Registration Reply for use by the mobile 297 node. In that case, the foreign agent MUST delete the Challenge 298 extension from the Home Agent from the Registration Reply, along 299 with any FA-HA authentication extension, before appending the new 300 Challenge extension to the Registration Reply. 302 3.4. Home Agent Processing for the Challenge Extensions 304 If the Home Agent receives a Registration Request with the MN-FA 305 Challenge extension, and recognizes the extension, the Home Agent 306 MUST include the Challenge extension in the Registration Reply. 307 The Challenge Extension MUST be placed after the Mobile-Home 308 authentication extension, and the extension SHOULD be authenticated 309 by a Foreign-Home Authentication extension. 311 Since the extension type for the Challenge extension is within the 312 range 128-255, the Home Agent MUST process such a Registration 313 Request even if it does not recognize the Challenge extension [8]. 314 In this case, the Home Agent will send a Registration Reply to the 315 Foreign Agent that does not include the Challenge extension. 317 4. MN-FA Challenge Extension 319 This section specifies a new Mobile IP Registration extension that is 320 used to satisfy a Challenge in an Agent Advertisement. The Challenge 321 extension to the Registration Request message is used to indicate the 322 challenge that the mobile node is attempting to satisfy. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type | Length | Challenge... 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Figure 2: The MN-FA Challenge Extension 332 Type 132 (skippable) (see [8]) 334 Length Length of the Challenge value 336 Challenge The Challenge field is copied from the Challenge field 337 found in the Agent Advertisement Challenge extension 338 (see section 2). 340 5. Generalized Mobile IP Authentication Extension 342 Several new authentication extensions have been designed for various 343 control messages proposed for extensions to Mobile IP (see, for 344 example, [9]). A new authentication extension is required for a 345 mobile node to present its credentials to any other entity other 346 than the ones already defined; the only entities defined in the 347 base Mobile IP specification [8] are the home agent and the foreign 348 agent. It is the purpose of the generalized authentication extension 349 defined here to collect together data for all such new authentication 350 applications into a single extension type with subtypes. 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Type | Subtype | Length | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | SPI | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Authenticator ... 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 3: The Generalized Mobile IP Authentication Extension 364 Type 36 (not skippable) (see [8]) 366 Subtype a number assigned to identify the kind of 367 endpoints or characteristics of the particular 368 authentication strategy 370 Length 4 plus the number of bytes in the Authenticator; 371 MUST be at least 20. 373 SPI Security Parameters Index 375 Authenticator The variable length Authenticator field 377 In this document, only one subtype is defined: 379 1 MN-AAA Authentication subtype (see section 6) 381 6. MN-AAA Authentication subtype 383 The Generalized Authentication extension with subtype 1 will be 384 referred to as a MN-AAA Authentication extension. If the mobile 385 node does not include a Mobile-Foreign Authentication [8] extension, 386 then it MUST include the MN-AAA Authentication extension whenever 387 the Challenge extension is present. If the MN-AAA Authentication 388 extension is present, then the Registration Message sent by the 389 mobile node MUST contain the Mobile-HA Authentication extension [8] 390 if it shares a security association with the Home Agent. If present, 391 the Mobile-HA Authentication Extension MUST appear prior to the 392 MN-AAA Authentication extension. The mobile node MAY include 393 a MN-AAA Authentication extension in any Registration Request. 394 The corresponding response MUST include the MN-HA Authentication 395 Extension, and MUST NOT include the MN-AAA Authentication Extension. 397 The default algorithm for computation of the authenticator is 398 HMAC-MD5 [5] computed on the following data, in the order shown: 400 Preceding Mobile IP data || Type, Subtype, Length, SPI 402 where the Type, Length, Subtype, and SPI are as shown in section 5. 403 The resulting function call, as described in [5], would be: 405 hmac_md5(data, datalen, Key, KeyLength, authenticator); 407 Each mobile node MUST support the ability to produce the 408 authenticator by using HMAC-MD5 as shown. Just as with Mobile IP, 409 this default algorithm MUST be able to be configured for selection at 410 any arbitrary 32-bit SPI outside of the SPIs in the reserved range 411 0-255. 413 7. Reserved SPIs for Mobile IP 415 Mobile IP defines several authentication extensions for use in 416 Registration Requests and Replies. Each authentication extension 417 carries a Security Parameters Index (SPI) which should be used to 418 index a table of security associations. Values in the range 0 - 255 419 are reserved for special use. A list of reserved SPI numbers is to 420 be maintained by IANA at the following URL: 422 http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers 424 8. SPI For RADIUS AAA Servers 426 Some AAA servers only admit a single security association, and thus 427 do not use the SPI numbers for Mobile IP authentication extensions 428 for use when determining the security association that would be 429 necessary for verifying the authentication information included with 430 the Authentication extension. 432 SPI number CHAP_SPI (see section 9) is reserved (see section 7) for 433 indicating the following procedure for computing authentication 434 data (called the "authenticator"), which is used by many RADIUS 435 servers [10] today. 437 To compute the authenticator, apply MD5 [11] computed on the 438 following data, in the order shown: 440 High-order byte from Challenge || Key || 441 MD5(Preceding Mobile IP data || 442 Type, Subtype (if present), Length, SPI) || 443 Least-order 237 bytes from Challenge 445 where the Type, Length, SPI, and possibly Subtype, are the fields 446 of the authentication extension in use. For instance, all four of 447 these fields would be in use when SPI == CHAP_SPI is used with the 448 Generalized Authentication extension. Since the RADIUS protocol 449 cannot carry attributes greater than 253 in size, the preceding 450 Mobile IP data, type, subtype (if present), length and SPI are hashed 451 using MD5. Finally, the least significant 237 bytes of the challenge 452 are concatenated. 454 9. Configurable Parameters 456 Every Mobile IP agent supporting the extensions defined in this 457 document SHOULD be able to configure each parameter in the following 458 table. Each table entry contains the name of the parameter, the 459 default value, and the section of the document in which the parameter 460 first appears. 462 Parameter Name Default Value Section(s) of Document 463 -------------- ------------- ---------------------- 464 CHALLENGE_WINDOW 2 3.2 465 CHAP_SPI 2 8 467 10. Error Values 469 Each entry in the following table contains the name of Code [8] to 470 be returned in a Registration Reply, the value for the Code, and the 471 section in which the error is first mentioned in this specification. 472 Error Name Value Section of Document 473 ---------------------- ----- ------------------- 474 UNKNOWN_CHALLENGE 104 3.2 475 BAD_AUTHENTICATION 67 3.2 - also see [8] 476 MISSING_CHALLENGE 105 3.1,3.2 477 STALE_CHALLENGE 106 3.2 479 11. IANA Considerations 481 The Generalized Mobile IP Authentication extension defined in 482 Section 5 is a Mobile IP registration extension as defined in RFC 483 2002 [8] and extended in RFC 2356 [7]. IANA should assign a value of 484 36 for this extension. 486 A new number space is to be created for enumerating subtypes of the 487 Generalized Authentication extension (see section 5). New subtypes 488 of the Generalized Authentication extension, other than the number 489 (1) for the MN-AAA authentication extension specified in section 6, 490 must be specified and approved by the Mobile IP working group. 492 The MN-FA Challenge Extension defined in Section 4 is a router 493 advertisement extension as defined in RFC 1256 [3] and extended in 494 RFC 2002 [8]. IANA should assign a value of 132 for this purpose. 496 The Code values defined in Section 10 are error codes as defined in 497 RFC 2002 [8] and extended in RFC 2344 [6] and RFC 2356 [7]. They 498 correspond to error values conventionally associated with rejection 499 by the foreign agent (i.e., values from the range 64-127). The Code 500 value 67 is a pre-existing value which is to be used in some cases 501 with the extension defined in this specification. IANA should record 502 the values as defined in Section 10. 504 A new section for enumerating algorithms identified by specific SPIs 505 within the range 0-255 is to be added to 507 http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers. 509 The CHAP_SPI number (2) discussed in section 8 is to be assigned 510 from this range of reserved SPI numbers. New assignments from this 511 reserved range must be specified and approved by the Mobile IP 512 working group. SPI number 1 should not be assigned unless in the 513 future the Mobile IP working group decides that SKIP is not important 514 for enumeration in the list of reserved numbers. SPI number 0 should 515 not be assigned. 517 12. Security Considerations 519 In the event that a malicious mobile node attempts to replay the 520 authenticator for an old MN-FA Challenge, the Foreign Agent would 521 detect it since the agent always checks whether it has recently 522 advertised the Challenge (see section 3.2). Allowing mobile nodes 523 with different IP addresses or NAIs to use the same Challenge 524 value does not represent a security vulnerability, because the 525 authentication data provided by the mobile node will be computed over 526 data that is different (at least by the bytes of the mobile nodes' IP 527 addresses). 529 Whenever a Foreign Agent updates a field of the Registration Reply 530 (as suggested in section 3.2), it invalidates the authentication data 531 supplied by the Home Agent in the MN-HA Authentication extension to 532 the Registration Reply. Thus, this opens up a security exposure 533 whereby a node might try to supply a bogus Registration Reply to a 534 mobile node that causes the mobile node to act as if its Registration 535 Reply were rejected. This might happen when, in fact, a Registration 536 Reply showing acceptance of the registration might soon be received 537 by the mobile node. 539 If the foreign agent chooses a Challenge value (see section 2) with 540 fewer than 4 bytes, the foreign agent SHOULD maintain records that 541 also the Identification field for the mobile node. The foreign 542 agent can then find assurance that the Registration messages using 543 the short Challenge value are in fact unique, and thus assuredly not 544 replayed from any earlier registration. 546 Section 8 (SPI For RADIUS AAA Servers) defines a method of computing 547 the Generalized Mobile IP Authentication Extension's authenticator 548 field using MD5 in a manner that is consistent with RADIUS [10]. The 549 use of MD5 in the method described in Section 8 is less secure than 550 HMAC-MD5 [5], and should be avoided whenever possible. 552 13. Acknowledgements 554 The authors would like to thank Tom Hiller, Mark Munson, the TIA 555 TR45-6 WG, Gabriel Montenegro, Vipul Gupta, and Pete McCann for 556 their useful discussions. A recent draft by Mohamed Khalil, Raja 557 Narayanan, Emad Qaddoura, and Haseeb Akhtar has also suggested the 558 definition of a generalized authentication extension similar to the 559 specification contained in section 5. 561 References 563 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 564 Levels. Request for Comments (Best Current Practice) 2119, 565 Internet Engineering Task Force, March 1997. 567 [2] P. Calhoun and C. Perkins. Mobile IP Network Access Identifier 568 Extension for IPv4. Request for Comments (Proposed Standard) 569 2794, Internet Engineering Task Force, January 2000. 571 [3] S. Deering. ICMP Router Discovery Messages. Request for 572 Comments (Proposed Standard) 1256, Internet Engineering Task 573 Force, September 1991. 575 [4] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 576 Recommendations for Security. Request for Comments 577 (Informational) 1750, Internet Engineering Task Force, December 578 1994. 580 [5] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 581 for Message Authentication. Request for Comments 582 (Informational) 2104, Internet Engineering Task Force, 583 February 1997. 585 [6] G. Montenegro. Reverse Tunneling for Mobile IP. Request for 586 Comments (Proposed Standard) 2344, Internet Engineering Task 587 Force, May 1998. 589 [7] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 590 Mobile IP. Request for Comments (Informational) 2356, Internet 591 Engineering Task Force, June 1998. 593 [8] C. Perkins. IP Mobility Support. Request for Comments 594 (Proposed Standard) 2002, Internet Engineering Task Force, 595 October 1996. 597 [9] C. Perkins and D. Johnson. Route Optimization in Mobile IP. 598 Internet Draft, Internet Engineering Task Force. 599 draft-ietf-mobileip-optim-09.txt, February 2000. Work in 600 progress. 602 [10] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 603 Authentication Dial In User Service (RADIUS). Request for 604 Comments (Proposed Standard) 2138, Internet Engineering Task 605 Force, April 1997. 607 [11] R. Rivest. The MD5 Message-Digest Algorithm. Request for 608 Comments (Informational) 1321, Internet Engineering Task Force, 609 April 1992. 611 [12] W. Simpson. PPP Challenge Handshake Authentication Protocol 612 (CHAP). Request for Comments (Draft Standard) 1994, Internet 613 Engineering Task Force, August 1996. 615 A. Verification Infrastructure 617 The Challenge extensions in this protocol specification are expected 618 to be useful to help the Foreign Agent manage connectivity for 619 visiting mobile nodes, even in situations where the foreign agent 620 does not have any security association with the mobile node or the 621 mobile node's home agent. In order to carry out the necessary 622 authentication, it is expected that the foreign agent will need the 623 assistance of external administrative systems, which have come to be 624 called AAA systems. For the purposes of this document, we call the 625 external administrative support the "verification infrastructure". 626 The verification infrastructure is described to motivate the design 627 of the protocol elements defined in this document, and is not 628 strictly needed for the protocol to work. The foreign agent is free 629 to use any means at its disposal to verify the credentials of the 630 mobile node. This could, for instance, rely on a separate protocol 631 between the foreign agent and the Mobile IP home agent, and still be 632 completely invisible to the mobile node. 634 In order to verify the credentials of the mobile node, we imagine 635 that the foreign agent has access to a verification infrastructure 636 that can return a secure notification to the foreign agent that the 637 authentication has been performed, along with the results of that 638 authentication. This infrastructure may be visualized as shown in 639 figure 4. 641 +----------------------------------------------------+ 642 | | 643 | Verification and Key Management Infrastructure | 644 | | 645 +----------------------------------------------------+ 646 ^ | ^ | 647 | | | | 648 | v | v 649 +---------------+ +---------------+ 650 | | | | 651 | Foreign Agent | | Home Agent | 652 | | | | 653 +---------------+ +---------------+ 655 Figure 4: The Verification Infrastructure 657 After the foreign agent gets the Challenge authentication, it MAY 658 pass the authentication to the (here unspecified) infrastructure, 659 and await a Registration Reply. If the Reply has a positive status 660 (indicating that the registration was accepted), the foreign agent 661 accepts the registration. If the Reply contains the Code value 662 BAD_AUTHENTICATION (see Section 10), the foreign agent takes actions 663 indicated for rejected registrations. 665 Implicit in this picture, is the important observation that the 666 Foreign Agent and the Home Agent have to be equipped to make use 667 of whatever protocol is made available to them by the challenge 668 verification and key management infrastructure shown in the figure. 670 The protocol messages for handling the authentication within the 671 verification infrastructure, and identity of the agent performing the 672 verification of the Foreign Agent challenge, are not specified in 673 this document, because those operations do not have to be performed 674 by any Mobile IP entity. 676 Addresses 678 The working group can be contacted via the current chairs: 680 Basavaraj Patil Phil Roberts 681 Nokia Corporation Motorola 682 6000 Connection Drive 1501 West Shure Drive 683 M/S M8-540 684 Irving, Texas 75039 Arlington Heights, IL 60004 685 USA USA 686 Phone: +1 972-894-6709 Phone: +1 847-632-3148 687 Fax : +1 972-894-5349 688 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com 690 Questions about this memo can also be directed to the authors: 692 Charles E. Perkins Pat R. Calhoun 693 Communications Systems Lab Network & Security Center 694 Nokia Research Center Sun Microsystems Laboratories 695 313 Fairchild Drive 15 Network Circle 696 Mountain View, California 94043 Menlo Park, California 94025 697 USA USA 698 Phone: +1-650 625-2986 Phone: +1 650-786-7733 699 EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com 700 Fax: +1 650 625-2502 Fax: +1 650-786-6445