idnits 2.17.1 draft-ietf-mobileip-challenge-10.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...' (43 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [9], 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) == Outdated reference: A later version (-07) exists of draft-ietf-mobileip-mier-00 -- Possible downref: Normative reference to a draft: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '6') ** Obsolete normative reference: RFC 2344 (ref. '7') (Obsoleted by RFC 3024) ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '8') ** Obsolete normative reference: RFC 2002 (ref. '9') (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. '10' ** Obsolete normative reference: RFC 2138 (ref. '11') (Obsoleted by RFC 2865) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '12') Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 June 2000 Pat R. Calhoun 4 Sun Microsystems Laboratories 6 Mobile IP Challenge/Response Extensions 7 draft-ietf-mobileip-challenge-10.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 [13]) 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 [9]. 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 [9]. 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 [13] using MD5 [12]. 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 a 203 Mobile-Foreign, or a MN-AAA Authentication after the Challenge 204 extension. Any registration message containing the Challenge 205 extension without either of these authentication extensions MUST 206 be silently discarded. If the registration message contains 207 a Mobile-Foreign Authentication extension with an incorrect 208 authenticator that fails verification, the Foreign Agent MAY 209 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. The appendix provides an example of 219 an action that could be taken by a foreign agent. 221 Since the Challenge extension, and the authentication extension that 222 is used by the Mobile Node to satisfy the challenge, both follow 223 the Mobile-Home Authentication extension whenever the latter is 224 present, the Foreign Agent MAY remove the Challenge Extension and 225 the applicable authentication from the Registration Request without 226 disturbing the authentication value computed by the Mobile Node for 227 use by the Home Agent. 229 If the Foreign Agent does not remove those extensions, then the 230 Foreign Agent SHOULD store the Challenge value as part of the pending 231 registration request list [9]. Also in this case, the Foreign Agent 232 MUST reject any Registration Reply message coming from the Home Agent 233 that does not also include the Challenge Extension with the same 234 Challenge Value that was included in the Registration Request. The 235 Foreign Agent MUST send the rejected Registration message to the 236 mobile node, and change the status in the Registration Reply to the 237 value MISSING_CHALLENGE (see section 10). 239 If the Foreign Agent does remove the Challenge extension and 240 applicable authentication from the Registration Request message, 241 then it SHOULD insert the Identification field from the Registration 242 Request message along with its record-keeping information about the 243 particular Mobile Node in order to protect against replays. 245 3.3. Foreign Agent Processing for Registration Replies 247 The Foreign Agent MAY include a new Challenge extension in any 248 Registration Reply, successful or not. If the foreign agent includes 249 this extension in a successful Registration Reply, the extension 250 SHOULD precede a MN-FA authentication extension. 252 Suppose the Registration Reply includes a Challenge extension from 253 the Home Agent, and the foreign agent wishes to include another 254 Challenge extension with the Registration Reply for use by the mobile 255 node. In that case, the foreign agent MUST delete the Challenge 256 extension from the Home Agent from the Registration Reply, along 257 with any FA-HA authentication extension, before appending the new 258 Challenge extension to the Registration Reply. 260 3.4. Home Agent Processing for the Challenge Extensions 262 If the Home Agent receives a Registration Request with the MN-FA 263 Challenge extension, and recognizes the extension, the Home Agent 264 MUST include the Challenge extension in the Registration Reply. 265 The Challenge Extension MUST be placed after the Mobile-Home 266 authentication extension, and the extension SHOULD be authenticated 267 by a Foreign-Home Authentication extension. 269 Since the extension type for the Challenge extension is within the 270 range 128-255, the Home Agent MUST process such a Registration 271 Request even if it does not recognize the Challenge extension [9]. 272 In this case, the Home Agent will send a Registration Reply to the 273 Foreign Agent that does not include the Challenge extension. 275 4. MN-FA Challenge Extension 277 This section specifies a new Mobile IP Registration extension that is 278 used to satisfy a Challenge in an Agent Advertisement. The Challenge 279 extension to the Registration Request message is used to indicate the 280 challenge that the mobile node is attempting to satisfy. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type | Length | Challenge... 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 2: The MN-FA Challenge Extension 290 Type 132 (skippable) (see [9]) 292 Length Length of the Challenge value 294 Challenge The Challenge field is copied from the Challenge field 295 found in the Agent Advertisement Challenge extension 296 (see section 2). 298 5. Generalized Mobile IP Authentication Extension 300 Several new authentication extensions have been designed for various 301 control messages proposed for extensions to Mobile IP (see, for 302 example, [10]). A new authentication extension is required for a 303 mobile node to present its credentials to any other entity other 304 than the ones already defined; the only entities defined in the 305 base Mobile IP specification [9] are the home agent and the foreign 306 agent. It is the purpose of the generalized authentication extension 307 defined here to collect together data for all such new authentication 308 applications into a single extension type with subtypes. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Type | Subtype | Length | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | SPI | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Authenticator ... 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Figure 3: The Generalized Mobile IP Authentication Extension 322 Type 36 (not skippable) (see [9]) 324 Subtype a number assigned to identify the kind of 325 endpoints or characteristics of the particular 326 authentication strategy 328 Length 4 plus the number of bytes in the Authenticator; 329 MUST be at least 20. 331 SPI Security Parameters Index 333 Authenticator The variable length Authenticator field 335 In this document, only one subtype is defined: 337 1 MN-AAA Authentication subtype (see section 6) 339 6. MN-AAA Authentication subtype 341 The Generalized Authentication extension with subtype 1 will be 342 referred to as a MN-AAA Authentication extension. If the mobile 343 node does not include a Mobile-Foreign Authentication [9] extension, 344 then it MUST include the MN-AAA Authentication extension whenever 345 the Challenge extension is present. If the MN-AAA Authentication 346 extension is present, then the Registration Message sent by the 347 mobile node MUST contain the Mobile-HA Authentication extension [9] 348 if it shares a security association with the Home Agent. If present, 349 the Mobile-HA Authentication Extension MUST appear prior to the 350 MN-AAA Authentication extension. The mobile node MAY include 351 a MN-AAA Authentication extension in any Registration Request. 352 The corresponding response MUST include the MN-HA Authentication 353 Extension, and MUST NOT include the MN-AAA Authentication Extension. 355 The default algorithm for computation of the authenticator is 356 HMAC-MD5 [6] computed on the following data, in the order shown: 358 Preceding Mobile IP data || Type, Subtype, Length, SPI 360 where the Type, Length, Subtype, and SPI are as shown in section 5. 361 The resulting function call, as described in [6], would be: 363 hmac_md5(data, datalen, Key, KeyLength, authenticator); 365 Each mobile node MUST support the ability to produce the 366 authenticator by using HMAC-MD5 as shown. Just as with Mobile IP, 367 this default algorithm MUST be able to be configured for selection at 368 any arbitrary 32-bit SPI outside of the SPIs in the reserved range 369 0-255. 371 7. Reserved SPIs for Mobile IP 373 Mobile IP defines several authentication extensions for use in 374 Registration Requests and Replies. Each authentication extension 375 carries a Security Parameters Index (SPI) which should be used to 376 index a table of security associations. Values in the range 0 - 255 377 are reserved for special use. A list of reserved SPI numbers is to 378 be maintained by IANA at the following URL: 380 http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers 382 8. SPI For RADIUS AAA Servers 384 Some AAA servers only admit a single security association, and thus 385 do not use the SPI numbers for Mobile IP authentication extensions 386 for use when determining the security association that would be 387 necessary for verifying the authentication information included with 388 the Authentication extension. 390 SPI number CHAP_SPI (see section 9) is reserved (see section 7) for 391 indicating the following procedure for computing authentication 392 data (called the "authenticator"), which is used by many RADIUS 393 servers [11] today. 395 To compute the authenticator, apply MD5 [12] computed on the 396 following data, in the order shown: 398 High-order byte from Challenge || Key || 399 MD5(Preceding Mobile IP data || 400 Type, Subtype (if present), Length, SPI) || 401 Least-order 237 bytes from Challenge 403 where the Type, Length, SPI, and possibly Subtype, are the fields 404 of the authentication extension in use. For instance, all four of 405 these fields would be in use when SPI == CHAP_SPI is used with the 406 Generalized Authentication extension. Since the RADIUS protocol 407 cannot carry attributes greater than 253 in size, the preceding 408 Mobile IP data, type, subtype (if present), length and SPI are hashed 409 using MD5. Finally, the least significant 237 bytes of the challenge 410 are concatenated. 412 9. Configurable Parameters 414 Every Mobile IP agent supporting the extensions defined in this 415 document SHOULD be able to configure each parameter in the following 416 table. Each table entry contains the name of the parameter, the 417 default value, and the section of the document in which the parameter 418 first appears. 420 Parameter Name Default Value Section(s) of Document 421 -------------- ------------- ---------------------- 422 CHALLENGE_WINDOW 2 3.2 423 CHAP_SPI 2 8 425 10. Error Values 427 Each entry in the following table contains the name of Code [9] to 428 be returned in a Registration Reply, the value for the Code, and the 429 section in which the error is first mentioned in this specification. 430 Error Name Value Section of Document 431 ---------------------- ----- ------------------- 432 UNKNOWN_CHALLENGE 104 3.2 433 BAD_AUTHENTICATION 67 3.2 - also see [9] 434 MISSING_CHALLENGE 105 3.1,3.2 435 STALE_CHALLENGE 106 3.2 437 11. IANA Considerations 439 The Generalized Mobile IP Authentication extension defined in 440 Section 5 is a Mobile IP registration extension as defined in RFC 441 2002 [9] and extended in RFC 2356 [8]. IANA should assign a value of 442 36 for this extension. 444 A new number space is to be created for enumerating subtypes of the 445 Generalized Authentication extension (see section 5). New subtypes 446 of the Generalized Authentication extension, other than the number 447 (1) for the MN-AAA authentication extension specified in section 6, 448 must be specified and approved by the Mobile IP working group. 450 The MN-FA Challenge Extension defined in Section 4 is a router 451 advertisement extension as defined in RFC 1256 [3] and extended in 452 RFC 2002 [9]. IANA should assign a value of 132 for this purpose. 454 The Code values defined in Section 10 are error codes as defined in 455 RFC 2002 [9] and extended in RFC 2344 [7] and RFC 2356 [8]. They 456 correspond to error values conventionally associated with rejection 457 by the foreign agent (i.e., values from the range 64-127). The Code 458 value 67 is a pre-existing value which is to be used in some cases 459 with the extension defined in this specification. IANA should record 460 the values as defined in Section 10. 462 A new section for enumerating algorithms identified by specific SPIs 463 within the range 0-255 is to be added to 465 http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers. 467 The CHAP_SPI number (2) discussed in section 8 is to be assigned 468 from this range of reserved SPI numbers. New assignments from this 469 reserved range must be specified and approved by the Mobile IP 470 working group. SPI number 1 should not be assigned unless in the 471 future the Mobile IP working group decides that SKIP is not important 472 for enumeration in the list of reserved numbers. SPI number 0 should 473 not be assigned. 475 12. Security Considerations 477 In the event that a malicious mobile node attempts to replay the 478 authenticator for an old MN-FA Challenge, the Foreign Agent would 479 detect it since the agent always checks whether it has recently 480 advertised the Challenge (see section 3.2). Allowing mobile nodes 481 with different IP addresses or NAIs to use the same Challenge 482 value does not represent a security vulnerability, because the 483 authentication data provided by the mobile node will be computed over 484 data that is different (at least by the bytes of the mobile nodes' IP 485 addresses). 487 Whenever a Foreign Agent updates a field of the Registration Reply 488 (as suggested in section 3.2), it invalidates the authentication data 489 supplied by the Home Agent in the MN-HA Authentication extension to 490 the Registration Reply. Thus, this opens up a security exposure 491 whereby a node might try to supply a bogus Registration Reply to a 492 mobile node that causes the mobile node to act as if its Registration 493 Reply were rejected. This might happen when, in fact, a Registration 494 Reply showing acceptance of the registration might soon be received 495 by the mobile node. 497 If the foreign agent chooses a Challenge value (see section 2) with 498 fewer than 4 bytes, the foreign agent SHOULD maintain records that 499 also the Identification field for the mobile node. The foreign 500 agent can then find assurance that the Registration messages using 501 the short Challenge value are in fact unique, and thus assuredly not 502 replayed from any earlier registration. 504 Section 8 (SPI For RADIUS AAA Servers) defines a method of computing 505 the Generalized Mobile IP Authentication Extension's authenticator 506 field using MD5 in a manner that is consistent with RADIUS [11]. The 507 use of MD5 in the method described in Section 8 is less secure than 508 HMAC-MD5 [6], and should be avoided whenever possible. 510 13. Acknowledgements 512 The authors would like to thank Tom Hiller, Mark Munson, the TIA 513 TR45-6 WG, Gabriel Montenegro, Vipul Gupta, and Pete McCann for their 514 useful discussions. A recent draft [5] by Mohamed Khalil, Raja 515 Narayanan, Emad Qaddoura, and Haseeb Akhtar has also suggested the 516 definition of a generalized authentication extension similar to the 517 specification contained in section 5. 519 References 521 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 522 Levels. Request for Comments (Best Current Practice) 2119, 523 Internet Engineering Task Force, March 1997. 525 [2] P. Calhoun and C. Perkins. Mobile IP Network Access Identifier 526 Extension for IPv4. Request for Comments (Proposed Standard) 527 2794, Internet Engineering Task Force, January 2000. 529 [3] S. Deering. ICMP Router Discovery Messages. Request for 530 Comments (Proposed Standard) 1256, Internet Engineering Task 531 Force, September 1991. 533 [4] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 534 Recommendations for Security. Request for Comments 535 (Informational) 1750, Internet Engineering Task Force, December 536 1994. 538 [5] Mohamed Khalil, Raja Narayanan, Emad Qaddoura, and Haseeb 539 Akhtar. Mobile IP Extensions Rationalization (MIER). 540 draft-ietf-mobileip-mier-00.txt, December 1999. (work in 541 progress). 543 [6] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 544 for Message Authentication. Request for Comments 545 (Informational) 2104, Internet Engineering Task Force, 546 February 1997. 548 [7] G. Montenegro. Reverse Tunneling for Mobile IP. Request for 549 Comments (Proposed Standard) 2344, Internet Engineering Task 550 Force, May 1998. 552 [8] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 553 Mobile IP. Request for Comments (Informational) 2356, Internet 554 Engineering Task Force, June 1998. 556 [9] C. Perkins. IP Mobility Support. Request for Comments 557 (Proposed Standard) 2002, Internet Engineering Task Force, 558 October 1996. 560 [10] C. Perkins and D. Johnson. Route Optimization in Mobile IP. 561 Internet Draft, Internet Engineering Task Force. 562 draft-ietf-mobileip-optim-09.txt, February 2000. Work in 563 progress. 565 [11] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 566 Authentication Dial In User Service (RADIUS). Request for 567 Comments (Proposed Standard) 2138, Internet Engineering Task 568 Force, April 1997. 570 [12] R. Rivest. The MD5 Message-Digest Algorithm. Request for 571 Comments (Informational) 1321, Internet Engineering Task Force, 572 April 1992. 574 [13] W. Simpson. PPP Challenge Handshake Authentication Protocol 575 (CHAP). Request for Comments (Draft Standard) 1994, Internet 576 Engineering Task Force, August 1996. 578 A. Verification Infrastructure 580 The Challenge extensions in this protocol specification are expected 581 to be useful to help the Foreign Agent manage connectivity for 582 visiting mobile nodes, even in situations where the foreign agent 583 does not have any security association with the mobile node or the 584 mobile node's home agent. In order to carry out the necessary 585 authentication, it is expected that the foreign agent will need the 586 assistance of external administrative systems, which have come to be 587 called AAA systems. For the purposes of this document, we call the 588 external administrative support the "verification infrastructure". 589 The verification infrastructure is described to motivate the design 590 of the protocol elements defined in this document, and is not 591 strictly needed for the protocol to work. The foreign agent is free 592 to use any means at its disposal to verify the credentials of the 593 mobile node. This could, for instance, rely on a separate protocol 594 between the foreign agent and the Mobile IP home agent, and still be 595 completely invisible to the mobile node. 597 In order to verify the credentials of the mobile node, we imagine 598 that the foreign agent has access to a verification infrastructure 599 that can return a secure notification to the foreign agent that the 600 authentication has been performed, along with the results of that 601 authentication. This infrastructure may be visualized as shown in 602 figure 4. 604 +----------------------------------------------------+ 605 | | 606 | Verification and Key Management Infrastructure | 607 | | 608 +----------------------------------------------------+ 609 ^ | ^ | 610 | | | | 611 | v | v 612 +---------------+ +---------------+ 613 | | | | 614 | Foreign Agent | | Home Agent | 615 | | | | 616 +---------------+ +---------------+ 618 Figure 4: The Verification Infrastructure 620 After the foreign agent gets the Challenge authentication, it MAY 621 pass the authentication to the (here unspecified) infrastructure, 622 and await a Registration Reply. If the Reply has a positive status 623 (indicating that the registration was accepted), the foreign agent 624 accepts the registration. If the Reply contains the Code value 625 BAD_AUTHENTICATION (see Section 10), the foreign agent takes actions 626 indicated for rejected registrations. 628 Implicit in this picture, is the important observation that the 629 Foreign Agent and the Home Agent have to be equipped to make use 630 of whatever protocol is made available to them by the challenge 631 verification and key management infrastructure shown in the figure. 633 The protocol messages for handling the authentication within the 634 verification infrastructure, and identity of the agent performing the 635 verification of the Foreign Agent challenge, are not specified in 636 this document, because those operations do not have to be performed 637 by any Mobile IP entity. 639 Addresses 641 The working group can be contacted via the current chairs: 643 Basavaraj Patil Phil Roberts 644 Nokia Corporation Motorola 645 6000 Connection Drive 1501 West Shure Drive 646 M/S M8-540 647 Irving, Texas 75039 Arlington Heights, IL 60004 648 USA USA 649 Phone: +1 972-894-6709 Phone: +1 847-632-3148 650 Fax : +1 972-894-5349 651 EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com 653 Questions about this memo can also be directed to the authors: 655 Charles E. Perkins Pat R. Calhoun 656 Communications Systems Lab Network & Security Center 657 Nokia Research Center Sun Microsystems Laboratories 658 313 Fairchild Drive 15 Network Circle 659 Mountain View, California 94043 Menlo Park, California 94025 660 USA USA 661 Phone: +1-650 625-2986 Phone: +1 650-786-7733 662 EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com 663 Fax: +1 650 625-2502 Fax: +1 650-786-6445