idnits 2.17.1 draft-ietf-mip4-rfc3012bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1132. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1109. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1116. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1122. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document obsoletes RFC3012, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document updates RFC3344, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2, 2004) is 7078 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'FAERR' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2138 (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 3012 (Obsoleted by RFC 4721) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Charles E. Perkins 2 Internet-Draft Nokia Research Center 3 Expires: June 2, 2005 Pat R. Calhoun 4 Black Storm Networks 5 Jayshree. Bharatia 6 Nortel Networks 7 December 2, 2004 9 Mobile IPv4 Challenge/Response Extensions (revised) 10 draft-ietf-mip4-rfc3012bis-03.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 2, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 Mobile IP, as originally specified, defines an authentication 46 extension (the Mobile-Foreign Authentication extension) by which a 47 mobile node can authenticate itself to a foreign agent. 48 Unfortunately, that extension does not provide the foreign agent any 49 direct guarantee that the protocol is protected from replays, and 50 does not allow for the use of existing techniques (such as CHAP) for 51 authenticating portable computer devices. 53 In this specification, we define extensions for the Mobile IP Agent 54 Advertisements and the Registration Request that allow a foreign 55 agent to use a challenge/response mechanism to authenticate the 56 mobile node. 58 Furthermore, this document updates RFC3344 by including new 59 authentication extension called the Mobile-AAA Authentication 60 extension. This new extension is provided so that a mobile node can 61 supply credentials for authorization using commonly available AAA 62 infrastructure elements. This Authorization-enabling extension MAY 63 co-exist in the same Registration Request with Authentication 64 extensions defined for Mobile IP Registration by RFC3344. This 65 document obsoletes RFC3012. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Mobile IP Agent Advertisement Challenge Extension . . . . . . 6 72 2.1 Handling of Solicited Agent Advertisements . . . . . . . . 6 73 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.1 Mobile Node Processing for Registration Requests . . . . . 8 75 3.2 Foreign Agent Processing for Registration Requests . . . . 9 76 3.3 Foreign Agent Processing for Registration Replies . . . . 11 77 3.4 Home Agent Processing for the Challenge Extensions . . . . 12 78 3.5 Mobile Node Processing for Registration Replies . . . . . 12 79 4. Mobile-Foreign Challenge Extension . . . . . . . . . . . . . . 14 80 5. Generalized Mobile IP Authentication Extension . . . . . . . . 15 81 6. Mobile-AAA Authentication subtype . . . . . . . . . . . . . . 16 82 7. Reserved SPIs for Mobile IP . . . . . . . . . . . . . . . . . 17 83 8. SPIs for RADIUS AAA Servers . . . . . . . . . . . . . . . . . 18 84 9. Configurable Parameters . . . . . . . . . . . . . . . . . . . 19 85 10. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 20 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 87 12. Security Considerations . . . . . . . . . . . . . . . . . . 22 88 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 89 A. Change History . . . . . . . . . . . . . . . . . . . . . . . . 24 90 B. Verification Infrastructure . . . . . . . . . . . . . . . . . 26 91 C. Message Flow for FA Challenge Messaging with Mobile-AAA 92 Extension . . . . . . . . . . . . . . . . . . . . . . . . . . 28 93 D. Message Flow for FA Challenge Messaging with MN-FA 94 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 29 95 E. Foreign Agent Algorithm for Tracking Used Challenges . . . . . 30 96 14. Normative References . . . . . . . . . . . . . . . . . . . . 31 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32 98 Intellectual Property and Copyright Statements . . . . . . . . 33 100 1. Introduction 102 Mobile IP defines the Mobile-Foreign Authentication extension to 103 allow a mobile node to authenticate itself to a foreign agent. Such 104 authentication mechanisms are mostly external to the principal 105 operation of Mobile IP, since the foreign agent can easily route 106 packets to and from a mobile node whether or not the mobile node is 107 reporting a legitimately owned home address to the foreign agent. 108 Unfortunately, that extension does not provide the foreign agent any 109 direct guarantee that the protocol is protected from replays, and 110 does not allow for the use of CHAP [RFC1994] for authenticating 111 portable computer devices. In this specification, we define 112 extensions for the Mobile IP Agent Advertisements and the 113 Registration Request that allow a foreign agent to a use 114 challenge/response mechanism to authenticate the mobile node. 115 Furthermore, an additional authentication extension, the Mobile-AAA 116 authentication extension, is provided so that a mobile node can 117 supply credentials for authorization using commonly available AAA 118 infrastructure elements. The foreign agent may be able to interact 119 with an AAA infrastructure (using protocols outside the scope of this 120 document) to obtain a secure indication that the mobile node is 121 authorized to use the local network resources. 123 1.1 Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 This document uses the term Security Parameters Index (SPI) as 130 defined in the base Mobile IP protocol specification [RFC3344]. All 131 SPI values defined in this document refer to values for the SPI as 132 defined in that specification. 134 The following additional terminology is used in addition to that 135 defined in [RFC3344]: 136 previously used challenge: 137 The challenge is previously used challenge if the mobile node 138 sent the same challenge to the foreign agent in a previous 139 Registration Request, and that previous Registration Request 140 passed all validity checks performed by the foreign agent. The 141 foreign agent may not be able to keep records for all 142 previously used challenges, but see Section 3.2 for minimal 143 requirements. 144 security association: 145 A "mobility security association", as defined in [RFC3344]. 146 unknown challenge: 148 Any challenge from a particular mobile node that the foreign 149 agent has no record of having put either into one of its recent 150 Agent Advertisements or into a registration reply message to 151 that mobile node. 152 unused challenge: 153 A challenge that has not been already accepted by the foreign 154 agent from the mobile node in the Registration Request -- i.e., 155 a challenge that is neither unknown nor previously used. 157 2. Mobile IP Agent Advertisement Challenge Extension 159 This section defines a new extension to the Router Discovery Protocol 160 [RFC1256] for use by foreign agents that need to issue a challenge 161 for authenticating mobile nodes. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type | Length | Challenge ... 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Figure 1: The Challenge Extension 171 Type: 172 24 173 Length: 174 The length of the Challenge value in bytes; SHOULD be at least 175 4 176 Challenge: 177 A random value that SHOULD be at least 32 bits 179 The Challenge extension, illustrated in Figure 1, is inserted in the 180 Agent Advertisements by the foreign agent, in order to communicate a 181 previously unused challenge value that can be used by the mobile node 182 to compute an authentication for its next registration request 183 message. The challenge is selected by the foreign agent to provide 184 local assurance that the mobile node is not replaying any earlier 185 registration request. Eastlake, et al. [RFC1750] provides more 186 information on generating pseudo-random numbers suitable for use as 187 values for the challenge. 189 Note that the storage of different Challenges received in Agent 190 Advertisements from multiple foreign agents is implementation 191 specific and hence, out of scope for this specification. 193 2.1 Handling of Solicited Agent Advertisements 195 When a foreign agent generates an Agent Advertisement in response to 196 a Router Solicitation [RFC1256], some additional considerations come 197 into play. According to the Mobile IP base specification [RFC3344], 198 the resulting Agent Advertisement may be either multicast or unicast. 200 If the solicited Agent Advertisement is multicast, it MUST NOT 201 generate a new Challenge value and update its window of remembered 202 advertised Challenges. It must instead re-use the most recent of the 203 CHALLENGE_WINDOW Advertisement Challenge values. 205 If the agent advertisement is unicast back to the soliciting mobile 206 node, it MUST be handled as follows: If the challenge most recently 207 unicast to the soliciting mobile node has not been previously used 208 (as defined in Section 1.1), it SHOULD be repeated in the newly 209 issued unicast agent advertisement, otherwise a new challenge MUST be 210 generated and remembered as the most recent challenge issued to the 211 mobile node. For further discussion of this, see Section 12. 213 3. Operation 215 This section describes modifications to the Mobile IP registration 216 process [RFC3344] which may occur after the foreign agent issues a 217 Mobile IP Agent Advertisement containing the Challenge on its local 218 link. See Appendix C for a diagram showing the canonical message 219 flow for messages related to the processing of the foreign agent 220 challenge values. 222 3.1 Mobile Node Processing for Registration Requests 224 Retransmission behavior for Registration Requests is identical to 225 that specified in Mobile IP specification [RFC3344]. A retransmitted 226 Registration Request MAY use the same Challenge value as given in the 227 original Registration Request. 229 Whenever the Agent Advertisement contains the Challenge extension, if 230 the mobile node does not have a security association with the foreign 231 agent, then it MUST include the Challenge value in a Mobile-Foreign 232 Challenge extension to the Registration Request message. If, on the 233 other hand, the mobile node does have a security association with the 234 foreign agent, it SHOULD include the Challenge value in its 235 Registration Request message. 237 If the mobile node has a security association with the Foreign Agent, 238 it MUST include a Mobile-Foreign Authentication extension in its 239 Registration Request message, according to the base Mobile IP 240 specification [RFC3344]. When the Registration Request contains the 241 Mobile-Foreign Challenge extension specified in Section 4, the 242 Mobile-Foreign Authentication MUST follow the Challenge extension in 243 the Registration Request. The mobile node MAY also include the 244 Mobile-AAA Authentication extension. If both, the Mobile-Foreign 245 Authentication and the Mobile-AAA Authentication extensions are 246 present, the Mobile-Foreign Challenge extension MUST precede the 247 Mobile-AAA Authentication extension and the Mobile-AAA Authentication 248 extension MUST precede the Mobile-Foreign Authentication extension. 250 If the mobile node does not have a security association with the 251 foreign agent, the mobile node MUST include the Mobile-AAA 252 Authentication extension as defined in Section 6 when it includes the 253 Mobile-Foreign Challenge extension. In addition, the mobile node 254 SHOULD include the NAI extension [RFC2794], to enable the foreign 255 agent to make use of available verification infrastructure which 256 requires this. The SPI field of the Mobile-AAA Authentication 257 extension specifies the particular secret and algorithm (shared 258 between the mobile node and the verification infrastructure) that 259 must be used to perform the authentication. If the SPI value is 260 chosen as CHAP_SPI (see Section 9), then the mobile node specifies 261 CHAP-style authentication [RFC1994] using MD5 [RFC1321]. 263 In either case, the Mobile-Foreign Challenge extension followed by 264 one of the above specified authentication extensions MUST follow the 265 Mobile-Home Authentication extension, if present. 267 A mobile node MAY include the Mobile-AAA Authentication extension in 268 the Registration Request when the mobile node registers directly with 269 its home agent (using a co-located care-of address). In this case, 270 if the mobile node uses an SPI value of CHAP_SPI (Section 8) in the 271 MN-AAA Authentication extension, the mobile node MUST include the 272 Mobile-Foreign Challenge extension prior to the Mobile-AAA 273 Authentication extension. The mechanism used by the mobile node to 274 obtain the Challenge value in this case is outside the scope of this 275 document. 277 3.2 Foreign Agent Processing for Registration Requests 279 Upon receipt of the Registration Request, if the foreign agent has 280 issued a Challenge as part of its Agent Advertisements, and it does 281 not have a security association with the mobile node, then the 282 foreign agent SHOULD check that the Mobile-Foreign Challenge 283 extension exists, and that it contains a challenge value previously 284 unused by the mobile node. This ensures that the mobile node is not 285 attempting to replay a previous advertisement and authentication. In 286 this case, if the Registration Request does not include a challenge 287 extension, the foreign agent MUST include FA Error extension (defined 288 in [FAERR]) in the Registration Reply message with Status code set to 289 MISSING_CHALLENGE. 291 A foreign agent that sends Agent Advertisements containing a 292 Challenge value MAY send a Registration Reply message with a 293 MISSING_CHALLENGE error if the mobile node sends a Registration 294 Request with a Mobile-Foreign Authentication extension without 295 including a Challenge. In other words, such a foreign agent MAY 296 refuse to process a Registration Request from the mobile node unless 297 the request contains an unused Challenge. 299 If a mobile node retransmits a Registration Request with the same 300 Challenge extension, and the foreign agent still has a pending 301 Registration Request record in effect for the mobile node, then the 302 foreign agent forwards the Registration Request to the Home Agent 303 again. The foreign agent SHOULD check that the mobile node is 304 actually performing a retransmission, by verifying that the relevant 305 fields of the retransmitted request (including, if present, the 306 mobile node NAI Extension [RFC2794]) are the same as represented in 307 the visitor list entry for the pending Registration Request (section 308 3.7.1 of [RFC3344]). This verification MUST NOT include the 309 "remaining Lifetime of the pending registration", or the 310 Identification field since those values are likely to change even for 311 requests that are merely retransmissions and not new Registration 312 Requests. In all other circumstances, if the foreign agent receives 313 a Registration Request with a Challenge extension containing a 314 Challenge value previously used by that mobile node, the foreign 315 agent SHOULD send a Registration Reply to the mobile node containing 316 the Code value STALE_CHALLENGE. 318 The foreign agent MUST NOT accept any Challenge in the Registration 319 Request unless it was offered in the last Registration Reply or 320 unicast Agent Advertisement sent to the mobile node, or else 321 advertised as one of the last CHALLENGE_WINDOW (see Section 9) 322 Challenge values inserted into the immediately preceding Agent 323 advertisements. If the Challenge is not one of the recently 324 advertised values, the foreign Agent SHOULD send a Registration Reply 325 with Code value UNKNOWN_CHALLENGE (see Section 10). The foreign 326 agent MUST maintain the last challenge used by each mobile node that 327 has registered using any one of the last CHALLENGE_WINDOW challenge 328 values. This last challenge value can be stored as part of the 329 mobile node's registration records. Also, see Appendix E for a 330 possible algorithm that can be used to satisfy this requirement. 332 Furthermore, the foreign agent MUST check that there is either a 333 Mobile-Foreign, or a Mobile-AAA Authentication extension after the 334 Challenge extension. Any registration message containing the 335 Challenge extension without either of these authentication extensions 336 MUST be silently discarded. If the registration message contains a 337 Mobile-Foreign Authentication extension with an incorrect 338 authenticator that fails verification, the foreign agent MAY send a 339 Registration Reply to the mobile node with Code value 340 BAD_AUTHENTICATION (see Section 10). 342 If the Mobile-AAA Authentication extension (see Section 6) is present 343 in the message, or if an NAI extension is included indicating that 344 the mobile node belongs to a different administrative domain, the 345 foreign agent may take actions outside the scope of this protocol 346 specification to carry out the authentication of the mobile node. If 347 the registration message contains a Mobile-AAA Authentication 348 extension with an incorrect authenticator that fails verification, 349 the foreign agent MAY send a Registration Reply to the mobile node 350 with Code value FA_BAD_AAA_AUTH. If the Mobile-AAA Authentication 351 Extension is present in the Registration Request, the foreign agent 352 MUST NOT remove the Mobile-AAA Authentication Extension and the 353 Mobile-Foreign Challenge Extension from the Registration Request. 354 Appendix C provides an example of an action that could be taken by a 355 foreign agent. 357 In the event that the Challenge extension is authenticated through 358 the Mobile-Foreign Authentication extension and the Mobile-AAA 359 Authentication extension is not present, the foreign agent MAY remove 360 the Challenge Extension from the Registration Request without 361 disturbing the authentication value computed by the mobile node for 362 use by the AAA or the home agent. If the Mobile-AAA Authentication 363 extension is present and a security association exists between the 364 foreign agent and the home agent, the Mobile-Foreign Challenge 365 extension and the Mobile-AAA Authentication extension MUST precede 366 the Foreign-Home Authentication extension. 368 If the foreign agent does not remove the Challenge extension, then 369 the foreign agent SHOULD store the Challenge value as part of the 370 pending registration request list [RFC3344]. Also, if the 371 Registration Reply coming from the home agent does not include the 372 Challenge Extension, the foreign agent SHOULD NOT reject the 373 Registration Request message. If the Challenge Extension is present 374 in the Registration Reply, it MUST be the same Challenge value that 375 was included in the Registration Request. If the Challenge value 376 differs in the Registration Reply received from the home agent, the 377 foreign agent MUST insert a rejection Code value MISSING_CHALLENGE in 378 the Registration Reply sent to the mobile node (see Section 10). 380 If the foreign agent does remove the Challenge extension and 381 applicable authentication from the Registration Request message, then 382 it SHOULD insert the Identification field from the Registration 383 Request message along with its record-keeping information about the 384 particular mobile node in order to protect against replays. 386 3.3 Foreign Agent Processing for Registration Replies 388 The foreign agent SHOULD include a new Mobile-Foreign Challenge 389 Extension in any Registration Reply, successful or not. If the 390 foreign agent includes this extension in a successful Registration 391 Reply, the extension SHOULD precede a Mobile-Foreign authentication 392 extension if present. Suppose the Registration Reply includes a 393 Challenge extension from the home agent, and the foreign agent wishes 394 to include another Challenge extension with the Registration Reply 395 for use by the mobile node. In that case, the foreign agent MUST 396 delete the Challenge extension from the home agent from the 397 Registration Reply, along with any Foreign-Home authentication 398 extension, before appending the new Challenge extension to the 399 Registration Reply. 401 One example of a situation where the foreign agent MAY omit the 402 inclusion of a Mobile-Foreign Challenge Extension in the Registration 403 Reply would be when a new challenge has been multicast recently. 405 If a foreign agent has conditions in which it omits the inclusion of 406 a Mobile-Foreign Challenge Extension in the Registration Reply, it 407 still MUST respond with an agent advertisement containing a 408 previously unused challenge in response to a subsequent agent 409 solicitation from the same mobile node. Otherwise (when the said 410 conditions are not met) the foreign agent MUST include a previously 411 unused challenge in any Registration Reply, successful or not. 413 A mobile node MUST be prepared to use a challenge from a unicast or 414 multicast Agent Advertisement in lieu of one returned in a 415 Registration Reply, and MUST solicit for one if it has not already 416 received one in a Registration Reply. 418 If the foreign agent receives a Registration Reply with the Code 419 value HA_BAD_AAA_AUTH, it MUST be relayed to the mobile node. 421 3.4 Home Agent Processing for the Challenge Extensions 423 If the home agent receives a Registration Request with the 424 Mobile-Foreign Challenge extension, and recognizes the extension, the 425 home agent MUST include the Challenge extension in the Registration 426 Reply. The Challenge Extension MUST be placed after the Mobile-Home 427 authentication extension, and the extension SHOULD be authenticated 428 by a Foreign-Home Authentication extension. 430 The home agent MAY receive a Registration Request with the Mobile-AAA 431 Authentication extension. If the Mobile-AAA Authentication extension 432 is used by the home agent as an authorization-enabling extension and 433 the verification fails due to incorrect authenticator, the home agent 434 MAY reject the Registration Reply with the error code 435 HA_BAD_AAA_AUTH. 437 Since the extension type for the Challenge extension is within the 438 range 128-255, the home agent MUST process such a Registration 439 Request even if it does not recognize the Challenge extension 440 [RFC3344]. In this case, the home agent will send a Registration 441 Reply to the foreign agent that does not include the Challenge 442 extension. 444 3.5 Mobile Node Processing for Registration Replies 446 A mobile node might receive the following error codes in the 447 Registration Reply from the foreign agent as a response to the 448 Registration Request. The error codes are defined in Section 10. 450 UNKNOWN_CHALLENGE: This error code is received by the mobile node in 451 the case where the mobile node has moved to a new foreign agent that 452 cannot validate the challenge provided in the Registration Request. 454 In such instances, the mobile node MUST use a new Challenge value in 455 any new registration, obtained either from an Agent Advertisement, or 456 from a Challenge extension to the Registration Reply containing the 457 error. 459 MISSING_CHALLENGE: A mobile node that does not include a Challenge 460 when the Mobile-Foreign Authentication extension is present may 461 receive a MISSING_CHALLENGE error. In this case, the mobile node 462 SHOULD send a Challenge extension containing an unused challenge in 463 the next Registration Request. 465 BAD_AUTHENTICATION: This error is sent by the foreign agent if the 466 Registration Request contains a Mobile-Foreign Authentication 467 extension with an incorrect authenticator that fails verification. A 468 mobile node that receives a BAD_AUTHENTICATION Code value SHOULD 469 include the Mobile-AAA Authentication Extension in the next 470 Registration Request. This will make it possible for the Foreign 471 Agent to use its AAA infrastructure in order to authenticate the 472 mobile node. In this case, the mobile node MUST use a new Challenge 473 value in any new registration, obtained either from an Agent 474 Advertisement, or from a Challenge extension to the Registration 475 Reply containing the error. 477 FA_BAD_AAA_AUTH: This error is sent by the foreign agent if the 478 Registration Request contains a Mobile-AAA Authentication extension 479 with an incorrect authenticator that fails verification. A mobile 480 node that receives a FA_BAD_AAA_AUTH MUST use a new Challenge value 481 in any new registration, obtained either from an Agent Advertisement, 482 or from a Challenge extension to the Registration Reply containing 483 the error. 485 HA_BAD_AAA_AUTH: This error is sent by the home agent if the 486 Registration Request contains a Mobile-AAA Authentication extension 487 with an incorrect authenticator that fails verification. A mobile 488 node that receives a HA_BAD_AAA_AUTH MUST use a new Challenge value 489 in any new registration, obtained either from an Agent Advertisement, 490 or from a Challenge extension to the Registration Reply containing 491 the error. 493 STALE_CHALLENGE: If the foreign agent receives a Registration Request 494 with a Challenge extension containing a Challenge value previously 495 used by that mobile node, the mobile node MAY receive a Registration 496 Reply to the mobile node containing the Code value STALE_CHALLENGE. 497 In such instances, the mobile node MUST use a new Challenge value in 498 next Registration Request, obtained either from an Agent 499 Advertisement, or from a Challenge extension to the Registration 500 Reply containing the error. 502 4. Mobile-Foreign Challenge Extension 504 This section specifies a new Mobile IP Registration extension that is 505 used to satisfy a Challenge in an Agent Advertisement. The Challenge 506 extension to the Registration Request message is used to indicate the 507 challenge that the mobile node is attempting to satisfy. 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Type | Length | Challenge ... 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Figure 2: The Mobile-Foreign Challenge Extension 517 Type: 518 132 (skippable) (see [RFC3344]) 519 Length: 520 Length of the Challenge value 521 Challenge: 522 The Challenge field is copied from the Challenge field found in 523 the Agent Advertisement Challenge extension (see section 2). 525 Suppose the mobile node has successfully registered using one of the 526 Challenge Values within the CHALLENGE_WINDOW values advertised by the 527 foreign agent. In that case, in any new Registration Request the 528 mobile node MUST NOT use any Challenge Value which was advertised by 529 the foreign agent before the Challenge Value in the mobile node's 530 last Registration Request. 532 5. Generalized Mobile IP Authentication Extension 534 Several new authentication extensions have been designed for various 535 control messages proposed for extensions to Mobile IP. A new 536 authentication extension is required for a mobile node to present its 537 credentials to any other entity other than the ones already defined; 538 the only entities defined in the base Mobile IP specification 539 [RFC3344] are the home agent and the foreign agent. It is the 540 purpose of the generalized authentication extension defined here to 541 collect together data for all such new authentication applications 542 into a single extension type with subtypes. 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Type | Subtype | Length | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | SPI | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Authenticator ... 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Figure 3: The Generalized Mobile IP Authentication Extension 556 Type: 557 36 (not skippable) (see [RFC3344]) 558 Subtype: 559 A number assigned to identify the kind of endpoints or other 560 characteristics of the particular authentication strategy 561 Length: 562 4 plus the number of bytes in the Authenticator; MUST be at 563 least 20. 564 SPI: 565 Security Parameters Index 566 Authenticator: 567 The variable length Authenticator field 569 In this document, only one subtype is defined: 571 1 Mobile-AAA Authentication subtype (see Section 6) 573 6. Mobile-AAA Authentication subtype 575 The Generalized Authentication extension with subtype 1 will be 576 referred to as a Mobile-AAA Authentication extension. The mobile 577 node MAY include a Mobile-AAA Authentication extension in any 578 Registration Request. This extension MAY co-exist in the same 579 Registration Request with Authentication extensions defined for 580 Mobile IP Registration by [RFC3344]. If the mobile node does not 581 include a Mobile-Foreign Authentication [RFC3344] extension, then it 582 MUST include the Mobile-AAA Authentication extension whenever the 583 Challenge extension is present. If both are present, the Mobile-AAA 584 Authentication extension MUST precede the Mobile-Foreign 585 Authentication extension. 587 If the Mobile-AAA Authentication extension is present, then the 588 Registration Message sent by the mobile node MUST contain the 589 Mobile-Home Authentication extension [RFC3344] if it shares a 590 security association with the home agent. If both are present, the 591 Mobile-Home Authentication Extension MUST appear prior to the 592 Mobile-AAA Authentication extension. The corresponding response MUST 593 include the Mobile-Home Authentication Extension, and MUST NOT 594 include the Mobile-AAA Authentication Extension. 596 The default algorithm for computation of the authenticator is 597 HMAC-MD5 [RFC2104] computed on the following data, in the order 598 shown: 600 Preceding Mobile IP data || Type, Subtype, Length, SPI 602 where the Type, Length, Subtype, and SPI are as shown in Section 5. 603 The resulting function call, as described in [RFC2104], would be: 605 hmac_md5(data, datalen, Key, KeyLength, authenticator); 607 Each mobile node MUST support the ability to produce the 608 authenticator by using HMAC-MD5 as shown. Just as with Mobile IP, it 609 must be possible to configure the use of any arbitrary 32-bit SPI 610 outside of the SPIs in the reserved range 0-255 for selection of this 611 default algorithm. 613 7. Reserved SPIs for Mobile IP 615 Mobile IP defines several authentication extensions for use in 616 Registration Requests and Replies. Each authentication extension 617 carries a Security Parameters Index (SPI) which should be used to 618 index a table of security associations. Values in the range 0 - 255 619 are reserved for special use. A list of reserved SPI numbers is to 620 be maintained by IANA at the following URL: 622 http://www.iana.org/numbers.html 624 8. SPIs for RADIUS AAA Servers 626 Some AAA servers only admit a single security association, and thus 627 do not use the SPI numbers for Mobile IP authentication extensions 628 for use when determining the security association that would be 629 necessary for verifying the authentication information included with 630 the Authentication extension. 632 SPI number CHAP_SPI (see Section 9) is reserved for indicating the 633 following procedure for computing authentication data (called the 634 "authenticator"), which is used by many RADIUS servers [RFC2138] 635 today. 637 To compute the authenticator, apply MD5 [RFC1321] computed on the 638 following data, in the order shown: 640 High-order byte from Challenge || Key || 641 MD5(Preceding Mobile IP data || 642 Type, Subtype (if present), Length, SPI) || 643 Least-order 237 bytes from Challenge 645 where the Type, Length, SPI, and possibly Subtype, are the fields of 646 the authentication extension in use. For instance, all four of these 647 fields would be in use when SPI == CHAP_SPI is used with the 648 Generalized Authentication extension. Since the RADIUS protocol 649 cannot carry attributes of length greater than 253, the preceding 650 Mobile IP data, type, subtype (if present), length and SPI are hashed 651 using MD5. Finally, the least significant 237 bytes of the challenge 652 are concatenated. If the challenge has fewer than 238 bytes, this 653 algorithm includes the high-order byte in the computation twice, but 654 ensures that the challenge is used exactly as is. Additional padding 655 is never used to increase the length of the challenge; the input data 656 is allowed to be shorter than 237 bytes long. 658 9. Configurable Parameters 660 Every Mobile IP agent supporting the extensions defined in this 661 document SHOULD be able to configure each parameter in the following 662 table. Each table entry contains the name of the parameter, the 663 default value, and the section of the document in which the parameter 664 first appears. 666 +------------------+---------------+---------------------+ 667 | Parameter Name | Default Value | Section of Document | 668 +------------------+---------------+---------------------+ 669 | CHALLENGE_WINDOW | 2 | 3.2 | 670 | | | | 671 | CHAP_SPI | 2 | 8 | 672 +------------------+---------------+---------------------+ 674 Table 1: Configurable Parameters 676 Note that CHALLENGE_WINDOW SHOULD be at least 2. This makes it far 677 less likely that mobile nodes will register using a Challenge value 678 that is outside the set of values allowable by the foreign agent. 680 10. Error Values 682 Each entry in the following table contains the name of the Code 683 [RFC3344] to be returned in a Registration Reply, the value for the 684 Code, and the section in which the error is first mentioned in this 685 specification. 687 +--------------------+-------+--------------------------+ 688 | Error Name | Value | Section of Document | 689 +--------------------+-------+--------------------------+ 690 | UNKNOWN_CHALLENGE | 104 | 3.2 | 691 | | | | 692 | BAD_AUTHENTICATION | 67 | 3.2 - also see [RFC3344] | 693 | | | | 694 | MISSING_CHALLENGE | 105 | 3.1,3.2 | 695 | | | | 696 | STALE_CHALLENGE | 106 | 3.2 | 697 | | | | 698 | FA_BAD_AAA_AUTH | TBD | 3.2 | 699 | | | | 700 | HA_BAD_AAA_AUTH | TBD | 3.4 | 701 +--------------------+-------+--------------------------+ 703 Table 2: Error Values 705 11. IANA Considerations 707 All protocol values in this specification are to be the same as 708 defined in RFC 3012 [RFC3012]. Additionaly, new error codes 709 FA_BAD_AAA_AUTH and HA_BAD_AAA_AUTH are defined by this document. 710 The Status code list for the FA Error extension defined in [FAERR] is 711 extended with the new Status code MISSING_CHALLENGE along with the 712 new sub-type (TBD) for the protocol extension specified in this 713 document. 715 12. Security Considerations 717 In the event that a malicious mobile node attempts to replay the 718 authenticator for an old Mobile-Foreign Challenge, the foreign agent 719 would detect it since the agent always checks whether it has recently 720 advertised the Challenge (see Section 3.2). Allowing mobile nodes 721 with different IP addresses or NAIs to use the same Challenge value 722 does not represent a security vulnerability, because the 723 authentication data provided by the mobile node will be computed over 724 data that is different (at least by the bytes of the mobile nodes' IP 725 addresses). 727 If the foreign agent chooses a Challenge value (see Section 2) with 728 fewer than 4 bytes, the foreign agent SHOULD include the value of the 729 Identification field in the records it maintains for the mobile node. 730 The foreign agent can then determine whether the Registration 731 messages using the short Challenge value are in fact unique, and thus 732 assuredly not replayed from any earlier registration. 734 Section 8 (SPI For RADIUS AAA Servers) defines a method of computing 735 the Generalized Mobile IP Authentication Extension's authenticator 736 field using MD5 in a manner that is consistent with RADIUS [RFC2138]. 737 The use of MD5 in the method described in Section 8 is less secure 738 than HMAC-MD5 [RFC2104], and should be avoided whenever possible. 740 Note that an active attacker may try to prevent successful 741 registrations by sending a large number of Agent Solicitations or 742 bogus Registration Requests, each of which could cause the FA to 743 respond with a fresh challenge, invalidating the challenge that the 744 MN is currently trying to use. To prevent such attacks, the FA MUST 745 NOT invalidate previously unused challenges when responding to 746 unauthenticated Registration Requests or Agent Solicitations. In 747 addition, the FA MUST NOT allocate new storage when responding to 748 such messages, because this would also create the possibility of 749 denial of service. 751 13. Acknowledgments 753 The authors would like to thank Tom Hiller, Mark Munson, the TIA 754 TR45-6 WG, Gabriel Montenegro, Vipul Gupta, Pete McCann, Robert 755 Marks, Ahmad Muhanna, and Luca Salgarelli for their useful 756 discussions. A recent draft by Mohamed Khalil, Raja Narayanan, Emad 757 Qaddoura, and Haseeb Akhtar has also suggested the definition of a 758 generalized authentication extension similar to the specification 759 contained in Section 5. 761 Appendix A. Change History 763 List of the changes for draft-ietf-mobileip-rfc3012bis-03: 764 o Foreign agent recommended to include a Challenge in every 765 Registration Reply, so that mobile node can re-register without 766 waiting for an Advertisement. 767 o Foreign agent MUST record applicable challenge values used by each 768 mobile node. 769 o Mobile node forbidden to use Challenge values which were 770 advertised previous to the last Challenge value which it had used 771 for a registration. 772 o Terminology for stale challenge vs. unused challenge clarified. 773 o Terminology for "valid" challenge deleted in favor of "unused 774 challenge". 775 o Programming suggestion added as an appendix. 777 List of the changes for draft-ietf-mobileip-rfc3012bis-04: 778 o The definition of "previously used challenge" is merged with 779 "stale challenge" definition in section 1.1. 780 o Reference 7 is updated from RFC 3320 to RFC 3344 and reference 9 781 is updated from RFC 2138 to RFC 2865 in "Reference" section. 782 o Reference to RFC 3344 is added in section 3. 783 o HMAC_CHAP_SPI option is added for Generalized Mobile IP 784 Authentication extension. Upon receipt of HMAC_CHAP_SPI, HMAC-MD5 785 is used instead of MD5 for computing the authenticator. 786 o Clarified processing of error messages at the mobile node (section 787 3.1). 788 o Modified text of section 2.1 and 3.2 for further clarity. 790 List of the changes for draft-ietf-mobileip-rfc3012bis-05: 791 o Added BAD_AAA_AUTHENTICATION_SET_BY_FA and 792 BAD_AAA_AUTHENTICATION_SET_BY_HA error codes to report 793 authentication errors caused while processing Mobile-AAA 794 Authentication extension. 795 o Processing of the Mobile-AAA Authentication extension is clarified 796 for the foreign agent and the home agent. 797 o Co-existence of the Mobile-AAA Authentication extension in the 798 same Registration Request is made explicit. 799 o The situation in which the foreign agent sets MISSING_CHALLENGE is 800 clarified further. 801 o The use of Mobile-AAA Authentication Extension is allowed by the 802 mobile node with co-located care-of-address. 804 List of the changes for draft-ietf-mip4-rfc3012bis-00: 805 o Minor editorial changes are made through out the document. 806 o Added definition of "previously used challenge" and removed 807 definition of "stale challenge" from section 1.1. 809 o Renamed BAD_AAA_AUTHENTICATION_SET_BY_FA to FA_BAD_AAA_AUTH and 810 BAD_AAA_AUTHENTICATION_SET_BY_HA to HA_BAD_AAA_AUTH. 811 o Defined an order of the Mobile-AAA Authentication extension 812 received with the authentication extension(s) defined in RFC 3344 813 [RFC3344]. 814 o Added protection against bogus Registration Reply and Agent 815 Advertisement. Also, the processing of the Challenge is clarified 816 if it is received in the multicast/unicast Agent Advertisement. 818 List of the changes for draft-ietf-mip4-rfc3012bis-01: 819 o Minor editorial changes are made through out the document. 820 o Added reference of FA Error extension in the References section 821 and also updated relevant text in section 3.2 and section 11. 823 List of the changes for draft-ietf-mip4-rfc3012bis-02: 824 o Minor editorial changes are made in Appendix C and Appendix D. 825 o Updated Boilerplate. 827 List of the changes for draft-ietf-mip4-rfc3012bis-03: 828 o Removed HMAC_MD5_SPI support from section 3.1, 8 and 9. 829 o Corrected figure titles 1 and 3. 831 Appendix B. Verification Infrastructure 833 The Challenge extensions in this protocol specification are expected 834 to be useful to help the foreign agent manage connectivity for 835 visiting mobile nodes, even in situations where the foreign agent 836 does not have any security association with the mobile node or the 837 mobile node's home agent. In order to carry out the necessary 838 authentication, it is expected that the foreign agent will need the 839 assistance of external administrative systems, which have come to be 840 called AAA systems. For the purposes of this document, we call the 841 external administrative support the "verification infrastructure". 842 The verification infrastructure is described to motivate the design 843 of the protocol elements defined in this document, and is not 844 strictly needed for the protocol to work. The foreign agent is free 845 to use any means at its disposal to verify the credentials of the 846 mobile node. This could, for instance, rely on a separate protocol 847 between the foreign agent and the Mobile IP home agent, and still be 848 completely invisible to the mobile node. 850 In order to verify the credentials of the mobile node, we imagine 851 that the foreign agent has access to a verification infrastructure 852 that can return a secure notification to the foreign agent that the 853 authentication has been performed, along with the results of that 854 authentication. This infrastructure may be visualized as shown in 855 Figure 4. 857 +----------------------------------------------------+ 858 | | 859 | Verification and Key Management Infrastructure | 860 | | 861 +----------------------------------------------------+ 862 ^ | ^ | 863 | | | | 864 | v | v 865 +---------------+ +---------------+ 866 | | | | 867 | foreign agent | | home agent | 868 | | | | 869 +---------------+ +---------------+ 871 Figure 4: The Verification Infrastructure 873 After the foreign agent gets the Challenge authentication, it MAY 874 pass the authentication to the (here unspecified) infrastructure, and 875 await a Registration Reply. If the Reply has a positive status 876 (indicating that the registration was accepted), the foreign agent 877 accepts the registration. If the Reply contains the Code value 878 BAD_AUTHENTICATION (see Section 10), the foreign agent takes actions 879 indicated for rejected registrations. 881 Implicit in this picture, is the important observation that the 882 foreign agent and the home agent have to be equipped to make use of 883 whatever protocol is made available to them by the challenge 884 verification and key management infrastructure shown in the figure. 886 The protocol messages for handling the authentication within the 887 verification infrastructure, and identity of the agent performing the 888 verification of the foreign agent challenge, are not specified in 889 this document, because those operations do not have to be performed 890 by any Mobile IP entity. 892 Appendix C. Message Flow for FA Challenge Messaging with Mobile-AAA 893 Extension 895 MN FA Verification home agent 896 |<-- Adv+Challenge--| Infrastructure | 897 | (if needed) | | | 898 | | | | 899 |-- RReq+Challenge->| | | 900 | + Auth.Ext. | | | 901 | | Auth. Request, incl. | | 902 | |--- RReq + Challenge --->| | 903 | | + Auth.Ext | RReq + | 904 | | |-- Challenge -->| 905 | | | | 906 | | | | 907 | | |<--- RRep ----- | 908 | | Authorization, incl. | | 909 | |<-- RRep + Auth.Ext.-----| | 910 | | | | 911 |<-- RRep+Auth.Ext--| | | 912 | + New Challenge | | | 914 Figure 5: Message Flows for FA Challenge Messaging 916 In Figure 5, the following informational message flow is illustrated: 917 1. The foreign agent disseminates a Challenge Value in an Agent 918 Advertisement if needed. This advertisement MAY have been 919 produced after receiving an Agent Solicitation from the mobile 920 node (not shown in the diagram). 921 2. The mobile node creates a Registration Request including the 922 advertised Challenge Value in the Challenge Extension, along with 923 an Mobile-AAA authentication extension. 924 3. The foreign agent relays the Registration Request either to the 925 home agent specified by the mobile node, or else to its locally 926 configured Verification Infrastructure (see Appendix B), 927 according to local policy. 928 4. The foreign agent receives a Registration Reply with the 929 appropriate indications for authorizing connectivity for the 930 mobile node. 931 5. The foreign agent relays the Registration Reply to the mobile 932 node, possibly along with a new Challenge Value to be used by the 933 mobile node in its next Registration Request message. 935 Appendix D. Message Flow for FA Challenge Messaging with MN-FA 936 Authentication 938 MN FA home agent 939 |<-- Adv+Challenge--| | 940 | (if needed) | | 941 | | | 942 |-- RReq+Challenge->| | 943 | + Auth.Ext. | | 944 | |--- RReq + Challenge --->| 945 | | + HA-FA Auth.Ext | 946 | | | 947 | |<-- RRep + Challenge ----| 948 | | + HA-FA Auth.Ext | 949 | | | 950 |<-- RRep+Auth.Ext--| | 951 | + New Challenge | | 953 Figure 6: Message Flows for FA Challenge Messaging with MN-FA 954 Authentication 956 In Figure 6, the following informational message flow is illustrated: 957 1. The foreign agent disseminates a Challenge Value in an Agent 958 Advertisement if needed. This advertisement MAY have been 959 produced after receiving an Agent Solicitation from the mobile 960 node (not shown in the diagram). 961 2. The mobile node creates a Registration Request including the 962 advertised Challenge Value in the Challenge Extension, along with 963 an Mobile-Foreign Authentication extension. 964 3. The foreign agent relays the Registration Request to the home 965 agent specified by the mobile node. 966 4. The foreign agent receives a Registration Reply with the 967 appropriate indications for authorizing connectivity for the 968 mobile node. 969 5. The foreign agent relays the Registration Reply to the mobile 970 node, possibly along with a new Challenge Value to be used by the 971 mobile node in its next Registration Request message. If the 972 Reply contains the Code value HA_BAD_AAA_AUTH (see Section 10), 973 the foreign agent takes actions indicated for rejected 974 registrations. 976 Appendix E. Foreign Agent Algorithm for Tracking Used Challenges 978 If the foreign agent maintains a large CHALLENGE_WINDOW, it becomes 979 more important for scalability purposes to efficiently compare 980 incoming challenges against the set of Challenge values which have 981 been advertised recently. This can be done by keeping the Challenge 982 values in order of advertisement, and by making use of the mandated 983 behavior that mobile nodes MUST NOT use Challenge values which were 984 advertised before the last advertised Challenge value that the mobile 985 node has attempted to use. The following stylized programmatic 986 algorithm accomplishes this objective. The maximum amount of total 987 storage required by this algorithm is equal to Size*(CHALLENGE_WINDOW 988 + (2*N)), where N is the current number of mobile nodes for which the 989 foreign agent is storing challenge values. Note that, whenever the 990 stored challenge value is no longer in the CHALLENGE_WINDOW, it can 991 be deleted from the foreign agent's records, perhaps along with all 992 other registration information for the mobile node if it is no longer 993 registered. 995 In the program fragment, it is presumed that the foreign agent keeps 996 an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record 997 of the last advertised challenge used by a mobile node, and also a 998 record of the last challenge provided to a mobile node in a 999 Registration Reply or unicast Agent Advertisement. 1001 To meet the security obligations outlined in Section 12, the FA 1002 SHOULD use one of the already stored, previously unused challenges 1003 when responding to an unauthenticated Registration Request or Agent 1004 Solicitation. If none of the already stored challenges are 1005 previously unused, the FA SHOULD generate a new challenge, include it 1006 in the response, and store it in the per-Mobile data structure. 1008 current_chal := RegistrationRequest.challenge_extension_value 1009 last_chal := mobile_node_record.last_used_adv_chal 1011 if (current_chal == mobile_node_record.RegReply_challenge) { 1012 update (mobile_node_record, current_chal) 1013 return (OK) 1014 } 1015 else if (current_chal "among" VALID_ADV_CHALLENGES[]{ 1016 if (last_chal "among" VALID_ADV_CHALLENGES[]) { 1017 if (current_chal is "before" last_chal) { 1018 send_error(STALE_CHALLENGE) 1019 return (FAILURE) 1020 } 1021 else { 1022 update (mobile_node_record, current_chal) 1023 return (OK) 1024 } 1025 } 1026 else { 1027 update (mobile_node_record, current_chal) 1028 return (OK) 1029 } 1030 } 1031 else { 1032 send_error(UNKNOWN_CHALLENGE); 1033 } 1035 14 Normative References 1037 [FAERR] Perkins, C., "Foreign Agent Error Extension for Mobile 1038 IPv4", draft-perkins-mip4-faerr-00.txt (work in progress), 1039 January 2004. 1041 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1042 September 1991. 1044 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1045 April 1992. 1047 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1048 Recommendations for Security", RFC 1750, December 1994. 1050 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1051 Protocol (CHAP)", RFC 1994, August 1996. 1053 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 1054 Keyed-Hashing for Message Authentication", RFC 2104, 1055 February 1997. 1057 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1058 Requirement Levels", BCP 14, RFC 2119, March 1997. 1060 [RFC2138] Rigney, C., Rigney, C., Rubens, A., Simpson, W. and S. 1061 Willens, "Remote Authentication Dial In User Service 1062 (RADIUS)", RFC 2138, April 1997. 1064 [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access 1065 Identifier Extension for IPv4", RFC 2794, March 2000. 1067 [RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 1068 Challenge/Response Extensions", RFC 3012, November 2000. 1070 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1071 August 2002. 1073 Authors' Addresses 1075 Charles E. Perkins 1076 Nokia Research Center 1077 Communications Systems Lab 1078 313 Fairchild Drive 1079 Mountain View, California 94043 1081 Fax: +1 650 625-2502 1082 EMail: charles.perkins@nokia.com 1084 Pat R. Calhoun 1085 Black Storm Networks 1086 110 Nortech Parkway 1087 San Jose, CA 95134 1089 Fax: +1 720-293-7501 1090 EMail: pcalhoun@diameter.org 1092 Jayshree Bharatia 1093 Nortel Networks 1094 2221, Lakeside Blvd 1095 Richardson, TX 75082 1097 Fax: +1 972-684-3775 1098 EMail: jayshree@nortelnetworks.com 1100 Intellectual Property Statement 1102 The IETF takes no position regarding the validity or scope of any 1103 Intellectual Property Rights or other rights that might be claimed to 1104 pertain to the implementation or use of the technology described in 1105 this document or the extent to which any license under such rights 1106 might or might not be available; nor does it represent that it has 1107 made any independent effort to identify any such rights. Information 1108 on the procedures with respect to rights in RFC documents can be 1109 found in BCP 78 and BCP 79. 1111 Copies of IPR disclosures made to the IETF Secretariat and any 1112 assurances of licenses to be made available, or the result of an 1113 attempt made to obtain a general license or permission for the use of 1114 such proprietary rights by implementers or users of this 1115 specification can be obtained from the IETF on-line IPR repository at 1116 http://www.ietf.org/ipr. 1118 The IETF invites any interested party to bring to its attention any 1119 copyrights, patents or patent applications, or other proprietary 1120 rights that may cover technology that may be required to implement 1121 this standard. Please address the information to the IETF at 1122 ietf-ipr@ietf.org. 1124 Disclaimer of Validity 1126 This document and the information contained herein are provided on an 1127 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1128 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1129 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1130 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1131 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1132 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1134 Copyright Statement 1136 Copyright (C) The Internet Society (2004). This document is subject 1137 to the rights, licenses and restrictions contained in BCP 78, and 1138 except as set forth therein, the authors retain all their rights. 1140 Acknowledgment 1142 Funding for the RFC Editor function is currently provided by the 1143 Internet Society.