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