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