idnits 2.17.1 draft-ietf-mip4-rfc3012bis-05.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 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1150. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1127. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1134. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1140. ** 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. 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 (January 30, 2006) is 6633 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) -- Unexpected draft version: The latest known version of draft-perkins-mip4-faerr is -00, but you're referring to -02. -- 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: 9 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Charles E. Perkins 3 Internet-Draft Nokia Research Center 4 Expires: August 3, 2006 Pat R. Calhoun 5 Cisco Systems, Inc. 6 Jayshree. Bharatia 7 Nortel Networks 8 January 30, 2006 10 Mobile IPv4 Challenge/Response Extensions (revised) 11 draft-ietf-mip4-rfc3012bis-05.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 3, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 Mobile IP, as originally specified, defines an authentication 45 extension (the Mobile-Foreign Authentication extension) by which a 46 mobile node can authenticate itself to a foreign agent. 47 Unfortunately, that extension does not provide the foreign agent any 48 direct guarantee that the protocol is protected from replays, and 49 does not allow for the use of existing techniques (such as CHAP) for 50 authenticating portable computer devices. 52 In this specification, we define extensions for the Mobile IP Agent 53 Advertisements and the Registration Request that allow a foreign 54 agent to use a challenge/response mechanism to authenticate the 55 mobile node. 57 Furthermore, this document updates RFC3344 by including new 58 authentication extension called the Mobile-AAA Authentication 59 extension. This new extension is provided so that a mobile node can 60 supply credentials for authorization using commonly available AAA 61 infrastructure elements. This Authorization-enabling extension MAY 62 co-exist in the same Registration Request with Authentication 63 extensions defined for Mobile IP Registration by RFC3344. This 64 document obsoletes RFC3012. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Mobile IP Agent Advertisement Challenge Extension . . . . . . 6 71 2.1. Handling of Solicited Agent Advertisements . . . . . . . . 6 72 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.1. Mobile Node Processing of Registration Requests . . . . . 8 74 3.2. Foreign Agent Processing of Registration Requests . . . . 9 75 3.2.1. Foreign Agent Algorithm for Tracking Used 76 Challenges . . . . . . . . . . . . . . . . . . . . . . 11 77 3.3. Foreign Agent Processing of Registration Replies . . . . . 11 78 3.4. Home Agent Processing of Challenge Extensions . . . . . . 13 79 3.5. Mobile Node Processing of Registration Replies . . . . . . 13 80 4. Mobile-Foreign Challenge Extension . . . . . . . . . . . . . . 14 81 5. Generalized Mobile IP Authentication Extension . . . . . . . . 15 82 6. Mobile-AAA Authentication subtype . . . . . . . . . . . . . . 17 83 7. Reserved SPIs for Mobile IP . . . . . . . . . . . . . . . . . 18 84 8. SPIs for RADIUS AAA Servers . . . . . . . . . . . . . . . . . 19 85 9. Configurable Parameters . . . . . . . . . . . . . . . . . . . 20 86 10. Error Values . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 88 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 89 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 90 14. Normative References . . . . . . . . . . . . . . . . . . . . . 24 91 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 25 92 Appendix B. Verification Infrastructure . . . . . . . . . . . . . 26 93 Appendix C. Message Flow for FA Challenge Messaging with 94 Mobile-AAA Extension . . . . . . . . . . . . . . . . 28 95 Appendix D. Message Flow for FA Challenge Messaging with 96 MN-FA Authentication . . . . . . . . . . . . . . . . 30 97 Appendix E. Example Pseudo-Code for Tracking Used Challenges . . 31 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 99 Intellectual Property and Copyright Statements . . . . . . . . . . 33 101 1. Introduction 103 Mobile IP defines the Mobile-Foreign Authentication extension to 104 allow a mobile node to authenticate itself to a foreign agent. Such 105 authentication mechanisms are mostly external to the principal 106 operation of Mobile IP, since the foreign agent can easily route 107 packets to and from a mobile node whether or not the mobile node is 108 reporting a legitimately owned home address to the foreign agent. 109 Unfortunately, that extension does not provide the foreign agent any 110 direct guarantee that the protocol is protected from replays, and 111 does not allow for the use of CHAP [RFC1994] for authenticating 112 portable computer devices. In this specification, we define 113 extensions for the Mobile IP Agent Advertisements and the 114 Registration Request that allow a foreign agent to use challenge/ 115 response mechanism to authenticate the mobile node. Furthermore, an 116 additional authentication extension, the Mobile-AAA authentication 117 extension, is provided so that a mobile node can supply credentials 118 for authorization using commonly available AAA infrastructure 119 elements. The foreign agent may be able to interact with an AAA 120 infrastructure (using protocols outside the scope of this document) 121 to obtain a secure indication that the mobile node is authorized to 122 use the local network resources. 124 1.1. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 This document uses the term Security Parameters Index (SPI) as 131 defined in the base Mobile IP protocol specification [RFC3344]. All 132 SPI values defined in this document refer to values for the SPI as 133 defined in that specification. 135 The following additional terminology is used in addition to that 136 defined in [RFC3344]: 138 previously used challenge: 140 The challenge is a previously used challenge if the mobile node 141 sent the same challenge to the foreign agent in a previous 142 Registration Request, and that previous Registration Request 143 passed all validity checks performed by the foreign agent. The 144 foreign agent may not be able to keep records for all 145 previously used challenges, but see Section 3.2 for minimal 146 requirements. 148 security association: 150 A "mobility security association", as defined in [RFC3344]. 152 unknown challenge: 154 Any challenge from a particular mobile node that the foreign 155 agent has no record of having put either into one of its recent 156 Agent Advertisements or into a registration reply message to 157 that mobile node. 159 unused challenge: 161 A challenge that has not been already accepted by the foreign 162 agent from the mobile node in the Registration Request -- i.e., 163 a challenge that is neither unknown nor previously used. 165 2. Mobile IP Agent Advertisement Challenge Extension 167 This section defines a new extension to the Router Discovery Protocol 168 [RFC1256] for use by foreign agents that need to issue a challenge 169 for authenticating mobile nodes. 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Type | Length | Challenge ... 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Figure 1: The Challenge Extension 179 Type: 181 24 183 Length: 185 The length of the Challenge value in bytes; SHOULD be at least 186 4 188 Challenge: 190 A random value that SHOULD be at least 32 bits 192 The Challenge extension, illustrated in Figure 1, is inserted in the 193 Agent Advertisements by the foreign agent, in order to communicate a 194 previously unused challenge value that can be used by the mobile node 195 to compute an authentication for its next registration request 196 message. The challenge is selected by the foreign agent to provide 197 local assurance that the mobile node is not replaying any earlier 198 registration request. Eastlake, et al. [RFC1750] provides more 199 information on generating pseudo-random numbers suitable for use as 200 values for the challenge. 202 Note that the storage of different Challenges received in Agent 203 Advertisements from multiple foreign agents is implementation 204 specific and hence, out of scope for this specification. 206 2.1. Handling of Solicited Agent Advertisements 208 When a foreign agent generates an Agent Advertisement in response to 209 a Router Solicitation [RFC1256], some additional considerations come 210 into play. According to the Mobile IP base specification [RFC3344], 211 the resulting Agent Advertisement may be either multicast or unicast. 213 If the solicited Agent Advertisement is multicast, it MUST NOT 214 generate a new Challenge value and update its window of remembered 215 advertised Challenges. It must instead re-use the most recent of the 216 CHALLENGE_WINDOW Advertisement Challenge values (Section 9). 218 If the agent advertisement is unicast back to the soliciting mobile 219 node, it MUST be handled as follows: If the challenge most recently 220 unicast to the soliciting mobile node has not been previously used 221 (as defined in Section 1.1), it SHOULD be repeated in the newly 222 issued unicast agent advertisement, otherwise a new challenge MUST be 223 generated and remembered as the most recent challenge issued to the 224 mobile node. For further discussion of this, see Section 12. 226 3. Operation 228 This section describes modifications to the Mobile IP registration 229 process [RFC3344] which may occur after the foreign agent issues a 230 Mobile IP Agent Advertisement containing the Challenge on its local 231 link. See Appendix C for a diagram showing the canonical message 232 flow for messages related to the processing of the foreign agent 233 challenge values. 235 3.1. Mobile Node Processing of Registration Requests 237 Retransmission behavior for Registration Requests is identical to 238 that specified in Mobile IP specification [RFC3344]. A retransmitted 239 Registration Request MAY use the same Challenge value as given in the 240 original Registration Request. 242 Whenever the Agent Advertisement contains the Challenge extension, if 243 the mobile node does not have a security association with the foreign 244 agent, then it MUST include the Challenge value in a Mobile-Foreign 245 Challenge extension to the Registration Request message. If, on the 246 other hand, the mobile node does have a security association with the 247 foreign agent, it SHOULD include the Challenge value in its 248 Registration Request message. 250 If the mobile node has a security association with the Foreign Agent, 251 it MUST include a Mobile-Foreign Authentication extension in its 252 Registration Request message, according to the base Mobile IP 253 specification [RFC3344]. When the Registration Request contains the 254 Mobile-Foreign Challenge extension specified in Section 4, the 255 Mobile-Foreign Authentication MUST follow the Challenge extension in 256 the Registration Request. The mobile node MAY also include the 257 Mobile-AAA Authentication extension. If both the Mobile-Foreign 258 Authentication and the Mobile-AAA Authentication extensions are 259 present, the Mobile-Foreign Challenge extension MUST precede the 260 Mobile-AAA Authentication extension and the Mobile-AAA Authentication 261 extension MUST precede the Mobile-Foreign Authentication extension. 263 If the mobile node does not have a security association with the 264 foreign agent, the mobile node MUST include the Mobile-AAA 265 Authentication extension as defined in Section 6 when it includes the 266 Mobile-Foreign Challenge extension. In addition, the mobile node 267 SHOULD include the NAI extension [RFC2794], to enable the foreign 268 agent to make use of available verification infrastructure which 269 requires this. The SPI field of the Mobile-AAA Authentication 270 extension specifies the particular secret and algorithm (shared 271 between the mobile node and the verification infrastructure) that 272 must be used to perform the authentication. If the SPI value is 273 chosen as CHAP_SPI (see Section 9), then the mobile node specifies 274 CHAP-style authentication [RFC1994] using MD5 [RFC1321]. 276 In either case, the Mobile-Foreign Challenge extension followed by 277 one of the above specified authentication extensions MUST follow the 278 Mobile-Home Authentication extension, if present. 280 A mobile node MAY include the Mobile-AAA Authentication extension in 281 the Registration Request when the mobile node registers directly with 282 its home agent (using a co-located care-of address). In this case, 283 the mobile node uses an SPI value of CHAP_SPI (Section 8) in the MN- 284 AAA Authentication extension and MUST NOT include the Mobile-Foreign 285 Challenge extension. Also, replay protection for the Registration 286 Request in this case is provided by the Identification field defined 287 by [RFC3344]. 289 3.2. Foreign Agent Processing of Registration Requests 291 Upon receipt of the Registration Request, if the foreign agent has 292 issued a Challenge as part of its Agent Advertisements, and if it 293 does not have a security association with the mobile node, then the 294 foreign agent SHOULD check that the Mobile-Foreign Challenge 295 extension exists, and that it contains a challenge value previously 296 unused by the mobile node. This ensures that the mobile node is not 297 attempting to replay a previous advertisement and authentication. In 298 this case, if the Registration Request does not include a Challenge 299 extension, the foreign agent MUST send a Registration Reply with the 300 Code field set to set to MISSING_CHALLENGE. 302 If a mobile node retransmits a Registration Request with the same 303 Challenge extension, and the foreign agent still has a pending 304 Registration Request record in effect for the mobile node, then the 305 foreign agent forwards the Registration Request to the Home Agent 306 again. The foreign agent SHOULD check that the mobile node is 307 actually performing a retransmission, by verifying that the relevant 308 fields of the retransmitted request (including, if present, the 309 mobile node NAI Extension [RFC2794]) are the same as represented in 310 the visitor list entry for the pending Registration Request (section 311 3.7.1 of [RFC3344]). This verification MUST NOT include the 312 "remaining Lifetime of the pending registration", or the 313 Identification field since those values are likely to change even for 314 requests that are merely retransmissions and not new Registration 315 Requests. In all other circumstances, if the foreign agent receives 316 a Registration Request with a Challenge extension containing a 317 Challenge value previously used by that mobile node, the foreign 318 agent SHOULD send a Registration Reply to the mobile node containing 319 the Code value STALE_CHALLENGE. 321 The foreign agent MUST NOT accept any Challenge in the Registration 322 Request unless it was offered in the last Registration Reply or 323 unicast Agent Advertisement sent to the mobile node, or else 324 advertised as one of the last CHALLENGE_WINDOW (see Section 9) 325 Challenge values inserted into the immediately preceding Agent 326 advertisements. If the Challenge is not one of the recently 327 advertised values, the foreign Agent SHOULD send a Registration Reply 328 with Code value UNKNOWN_CHALLENGE (see Section 10). The foreign 329 agent MUST maintain the last challenge used by each mobile node that 330 has registered using any one of the last CHALLENGE_WINDOW challenge 331 values. This last challenge value can be stored as part of the 332 mobile node's registration records. Also, see Section 3.2.1 for a 333 possible algorithm that can be used to satisfy this requirement. 335 Furthermore, the foreign agent MUST check that there is either a 336 Mobile-Foreign, or a Mobile-AAA Authentication extension after the 337 Challenge extension. Any registration message containing the 338 Challenge extension without either of these authentication extensions 339 MUST be silently discarded. If the registration message contains a 340 Mobile-Foreign Authentication extension with an incorrect 341 authenticator that fails verification, the foreign agent MAY send a 342 Registration Reply to the mobile node with Code value 343 BAD_AUTHENTICATION (see Section 10). 345 If the Mobile-AAA Authentication extension (see Section 6) is present 346 in the message, or if an NAI extension is included indicating that 347 the mobile node belongs to a different administrative domain, the 348 foreign agent may take actions outside the scope of this protocol 349 specification to carry out the authentication of the mobile node. If 350 the registration message contains a Mobile-AAA Authentication 351 extension with an incorrect authenticator that fails verification, 352 the foreign agent MAY send a Registration Reply to the mobile node 353 with Code value FA_BAD_AAA_AUTH. If the Mobile-AAA Authentication 354 Extension is present in the Registration Request, the foreign agent 355 MUST NOT remove the Mobile-AAA Authentication Extension and the 356 Mobile-Foreign Challenge extension from the Registration Request, 357 before forwarding to the home agent. Appendix C provides an example 358 of an action that could be taken by a foreign agent. 360 In the event that the Challenge extension is authenticated through 361 the Mobile-Foreign Authentication extension and the Mobile-AAA 362 Authentication extension is not present, the foreign agent MAY remove 363 the Challenge extension from the Registration Request without 364 disturbing the authentication value used for the computation. If the 365 Mobile-AAA Authentication extension is present and a security 366 association exists between the foreign agent and the home agent, the 367 Mobile-Foreign Challenge extension and the Mobile-AAA Authentication 368 extension MUST precede the Foreign-Home Authentication extension. 370 If the foreign agent does remove the Challenge extension and 371 applicable authentication from the Registration Request message, then 372 it SHOULD store the Identification field from the Registration 373 Request message as part of its record-keeping information about the 374 particular mobile node in order to protect against replays. 376 3.2.1. Foreign Agent Algorithm for Tracking Used Challenges 378 If the foreign agent maintains a large CHALLENGE_WINDOW, it becomes 379 more important for scalability purposes to efficiently compare 380 incoming challenges against the set of Challenge values which have 381 been advertised recently. This can be done by keeping the Challenge 382 values in order of advertisement, and by making use of the mandated 383 behavior that mobile nodes MUST NOT use Challenge values which were 384 advertised before the last advertised Challenge value that the mobile 385 node has attempted to use. The pseudo-code in Appendix E 386 accomplishes this objective. The maximum amount of total storage 387 required by this algorithm is equal to Size*(CHALLENGE_WINDOW + 388 (2*N)), where N is the current number of mobile nodes for which the 389 foreign agent is storing challenge values. Note that, whenever the 390 stored challenge value is no longer in the CHALLENGE_WINDOW, it can 391 be deleted from the foreign agent's records, perhaps along with all 392 other registration information for the mobile node if it is no longer 393 registered. 395 It is presumed that the foreign agent keeps an array of advertised 396 Challenges, a record of the last advertised challenge used by a 397 mobile node, and also a record of the last challenge provided to a 398 mobile node in a Registration Reply or unicast Agent Advertisement. 400 To meet the security obligations outlined in Section 12, the foreign 401 agent SHOULD use one of the already stored, previously unused 402 challenges when responding to an unauthenticated Registration Request 403 or Agent Solicitation. If none of the already stored challenges are 404 previously unused, the foreign agent SHOULD generate a new challenge, 405 include it in the response, and store it in the per-Mobile data 406 structure. 408 3.3. Foreign Agent Processing of Registration Replies 410 The foreign agent SHOULD include a new Mobile-Foreign Challenge 411 Extension in any Registration Reply, successful or not. If the 412 foreign agent includes this extension in a successful Registration 413 Reply, the extension SHOULD precede a Mobile-Foreign authentication 414 extension if present. Suppose the Registration Reply includes a 415 Challenge extension from the home agent, and the foreign agent wishes 416 to include another Challenge extension with the Registration Reply 417 for use by the mobile node. In that case, the foreign agent MUST 418 delete the Challenge extension from the home agent from the 419 Registration Reply, along with any Foreign-Home authentication 420 extension, before appending the new Challenge extension to the 421 Registration Reply. 423 One example of a situation where the foreign agent MAY omit the 424 inclusion of a Mobile-Foreign Challenge extension in the Registration 425 Reply would be when a new challenge has been multicast recently. 427 If a foreign agent has conditions in which it omits the inclusion of 428 a Mobile-Foreign Challenge extension in the Registration Reply, it 429 still MUST respond with an agent advertisement containing a 430 previously unused challenge in response to a subsequent agent 431 solicitation from the same mobile node. Otherwise (when the said 432 conditions are not met) the foreign agent MUST include a previously 433 unused challenge in any Registration Reply, successful or not. 435 If the foreign agent does not remove the Challenge extension from the 436 Registration Request received from the mobile node then the foreign 437 agent SHOULD store the Challenge value as part of the pending 438 registration request list [RFC3344]. Also, if the Registration Reply 439 coming from the home agent does not include the Challenge extension, 440 the foreign agent SHOULD NOT reject the Registration Request message. 441 If the Challenge Extension is present in the Registration Reply, it 442 MUST be the same Challenge value that was included in the 443 Registration Request. If the Challenge value differs in the 444 Registration Reply received from the home agent, the foreign agent 445 MUST insert an FA Error extension with Status value 446 HA_WRONG_CHALLENGE in the Registration Reply sent to the mobile node 447 (see Section 10). 449 A mobile node MUST be prepared to use a challenge from a unicast or 450 multicast Agent Advertisement in lieu of one returned in a 451 Registration Reply, and MUST solicit for one if it has not already 452 received one in a Registration Reply. 454 If the foreign agent receives a Registration Reply with the Code 455 value HA_BAD_AAA_AUTH, the Registration Reply with this Code value 456 MUST be relayed to the mobile node. In this document, whenever the 457 foreign agent is required to reject a Registration Request, it MUST 458 put the given code in the usual Code field of the Registration Reply, 459 unless the Registration Reply has already been received from the home 460 agent. In this case the foreign agent MUST preserve the value of the 461 Code field set by the home agent and MUST put its own rejection code 462 in the Status field of the FA Error extension (defined in [FAERR]). 464 3.4. Home Agent Processing of Challenge Extensions 466 If the home agent receives a Registration Request with the Mobile- 467 Foreign Challenge extension, and recognizes the extension, the home 468 agent MUST include the Challenge extension in the Registration Reply. 469 The Challenge extension MUST be placed after the Mobile-Home 470 authentication extension, and the extension SHOULD be authenticated 471 by a Foreign-Home Authentication extension. 473 The home agent may receive a Registration Request with the Mobile-AAA 474 Authentication extension. If the Mobile-AAA Authentication extension 475 is used by the home agent as an authorization-enabling extension and 476 the verification fails due to incorrect authenticator, the home agent 477 MAY reject the Registration Reply with the error code 478 HA_BAD_AAA_AUTH. 480 Since the extension type for the Challenge extension is within the 481 range 128-255, the home agent MUST process such a Registration 482 Request even if it does not recognize the Challenge extension 483 [RFC3344]. In this case, the home agent will send a Registration 484 Reply to the foreign agent that does not include the Challenge 485 extension. 487 3.5. Mobile Node Processing of Registration Replies 489 A mobile node might receive the error code in the Registration Reply 490 from the foreign agent as a response to the Registration Request. 491 The error codes are defined in Section 10. 493 In any case, if the mobile node attempts to register again after such 494 an error, it MUST use a new Challenge value in such a registration, 495 obtained either from an Agent Advertisement, or from a Challenge 496 extension to the Registration Reply containing the error. 498 In the co-located care-of address mode, the mobile node receives a 499 Registration Reply without the Challenge extension and processes the 500 Registration Reply as specified in [RFC3344]. In this case, the 501 Challenge value 0 is recommended for the authenticator computation 502 mentioned in Section 8. 504 4. Mobile-Foreign Challenge Extension 506 This section specifies a new Mobile IP Registration extension that is 507 used to satisfy a Challenge in an Agent Advertisement. The Challenge 508 extension to the Registration Request message is used to indicate the 509 challenge that the mobile node is attempting to satisfy. 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type | Length | Challenge ... 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Figure 2: The Mobile-Foreign Challenge Extension 519 Type: 521 132 (skippable) (see [RFC3344]) 523 Length: 525 Length of the Challenge value 527 Challenge: 529 The Challenge field is copied from the Challenge field found in 530 the received Challenge extension. 532 Suppose the mobile node has successfully registered using one of the 533 Challenge Values within the CHALLENGE_WINDOW values advertised by the 534 foreign agent. In that case, in any new Registration Request the 535 mobile node MUST NOT use any Challenge Value which was advertised by 536 the foreign agent before the Challenge Value in the mobile node's 537 last Registration Request. 539 5. Generalized Mobile IP Authentication Extension 541 Several new authentication extensions have been designed for various 542 control messages proposed for extensions to Mobile IP. A new 543 authentication extension is required for a mobile node to present its 544 credentials to any other entity other than the ones already defined; 545 the only entities defined in the base Mobile IP specification 546 [RFC3344] are the home agent and the foreign agent. The purpose of 547 the generalized authentication extension defined here is to collect 548 together data for all such new authentication applications into a 549 single extension type with subtypes. 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Type | Subtype | Length | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | SPI | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Authenticator ... 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Figure 3: The Generalized Mobile IP Authentication Extension 563 Type: 565 36 (not skippable) (see [RFC3344]) 567 Subtype: 569 A number assigned to identify the kind of endpoints or other 570 characteristics of the particular authentication strategy 572 Length: 574 4 plus the number of bytes in the Authenticator; MUST be at 575 least 20. 577 SPI: 579 Security Parameters Index 581 Authenticator: 583 The variable length Authenticator field 585 In this document, only one subtype is defined: 587 1 Mobile-AAA Authentication subtype (see Section 6) 589 6. Mobile-AAA Authentication subtype 591 The Generalized Authentication extension with subtype 1 will be 592 referred to as a Mobile-AAA Authentication extension. The mobile 593 node MAY include a Mobile-AAA Authentication extension in any 594 Registration Request. This extension MAY co-exist in the same 595 Registration Request with Authentication extensions defined for 596 Mobile IP Registration ([RFC3344]). If the mobile node does not 597 include a Mobile-Foreign Authentication extension, then it MUST 598 include the Mobile-AAA Authentication extension whenever the 599 Challenge extension is present. If both are present, the Mobile-AAA 600 Authentication extension MUST precede the Mobile-Foreign 601 Authentication extension. 603 If the Mobile-AAA Authentication extension is present, the Mobile- 604 Home Authentication Extension MUST appear prior to the Mobile-AAA 605 Authentication extension. The corresponding response MUST include 606 the Mobile-Home Authentication Extension, and MUST NOT include the 607 Mobile-AAA Authentication Extension. 609 The default algorithm for computation of the authenticator is HMAC- 610 MD5 [RFC2104] computed on the following data, in the order shown: 612 Preceding Mobile IP data || Type, Subtype, Length, SPI 614 where the Type, Length, Subtype, and SPI are as shown in Section 5. 615 The Preceding Mobile IP data refers to the UDP payload (the 616 Registration Request or Registration Reply data) and all prior 617 Extensions in their entirely. The resulting function call, as 618 described in [RFC2104], would be: 620 hmac_md5(data, datalen, Key, KeyLength, authenticator); 622 Each mobile node MUST support the ability to produce the 623 authenticator by using HMAC-MD5 as shown. Just as with Mobile IP, it 624 must be possible to configure the use of any arbitrary 32-bit SPI 625 outside of the SPIs in the reserved range 0-255 for selection of this 626 default algorithm. 628 7. Reserved SPIs for Mobile IP 630 Mobile IP defines several authentication extensions for use in 631 Registration Requests and Replies. Each authentication extension 632 carries a Security Parameters Index (SPI) which should be used to 633 index a table of security associations. Values in the range 0 - 255 634 are reserved for special use. A list of reserved SPI numbers is to 635 be maintained by IANA at the following URL: 637 http://www.iana.org/numbers.html 639 8. SPIs for RADIUS AAA Servers 641 Some AAA servers only admit a single security association, and thus 642 do not use the SPI numbers for Mobile IP authentication extensions 643 for use when determining the security association that would be 644 necessary for verifying the authentication information included with 645 the Authentication extension. 647 SPI number CHAP_SPI (see Section 9) is reserved for indicating the 648 following procedure for computing authentication data (called the 649 "authenticator"), which is used by many RADIUS servers [RFC2138] 650 today. 652 To compute the authenticator, apply MD5 [RFC1321] computed on the 653 following data, in the order shown: 655 High-order byte from Challenge || Key || 657 MD5(Preceding Mobile IP data || 659 Type, Subtype (if present), Length, SPI) || 661 Least-order 237 bytes from Challenge 663 where the Type, Length, SPI, and possibly Subtype, are the fields of 664 the authentication extension in use. For instance, all four of these 665 fields would be in use when SPI == CHAP_SPI is used with the 666 Generalized Authentication extension. Also, in case of co-located 667 care-of address, the Challenge value 0 is used (refer Section 668 Section 3.5). Since the RADIUS protocol cannot carry attributes of 669 length greater than 253, the preceding Mobile IP data, type, subtype 670 (if present), length and SPI are hashed using MD5. Finally, the 671 least significant 237 bytes of the challenge are concatenated. If 672 the challenge has fewer than 238 bytes, this algorithm includes the 673 high-order byte in the computation twice, but ensures that the 674 challenge is used exactly as is. Additional padding is never used to 675 increase the length of the challenge; the input data is allowed to be 676 shorter than 237 bytes long. 678 9. Configurable Parameters 680 Every Mobile IP agent supporting the extensions defined in this 681 document SHOULD be able to configure each parameter in the following 682 table. Each table entry contains the name of the parameter, the 683 default value, and the section of the document in which the parameter 684 first appears. 686 +------------------+---------------+---------------------+ 687 | Parameter Name | Default Value | Section of Document | 688 +------------------+---------------+---------------------+ 689 | CHALLENGE_WINDOW | 2 | 3.2 | 690 | | | | 691 | CHAP_SPI | 2 | 8 | 692 +------------------+---------------+---------------------+ 694 Table 1: Configurable Parameters 696 Note that CHALLENGE_WINDOW SHOULD be at least 2. This makes it far 697 less likely that mobile nodes will register using a Challenge value 698 that is outside the set of values allowable by the foreign agent. 700 10. Error Values 702 Each entry in the following table contains the name of the Code 703 [RFC3344] to be returned in a Registration Reply, the value for the 704 Code, and the section in which the error is mentioned in this 705 specification. 707 +--------------------+-------+--------------------------+ 708 | Error Name | Value | Section of Document | 709 +--------------------+-------+--------------------------+ 710 | UNKNOWN_CHALLENGE | 104 | 3.2 | 711 | | | | 712 | BAD_AUTHENTICATION | 67 | 3.2 - also see [RFC3344] | 713 | | | | 714 | MISSING_CHALLENGE | 105 | 3.1, 3.2 | 715 | | | | 716 | STALE_CHALLENGE | 106 | 3.2 | 717 | | | | 718 | FA_BAD_AAA_AUTH | TBD | 3.2 | 719 | | | | 720 | HA_BAD_AAA_AUTH | TBD | 3.4 | 721 | | | | 722 | HA_WRONG_CHALLENGE | TBD | 3.2 | 723 +--------------------+-------+--------------------------+ 725 Table 2: Error Values 727 11. IANA Considerations 729 The following are currently assigned by IANA for RFC 3012 ([RFC3012]) 730 which are applicable to this document. IANA should record these 731 values as part of this document. 733 The Generalized Mobile IP Authentication extension defined in 734 Section Section 5 is a Mobile IP registration extension. IANA has 735 assigned a value of 36 for this extension. 737 A new number space is to be created for enumerating subtypes of 738 the Generalized Authentication extension (see section Section 5). 739 New subtypes of the Generalized Authentication extension, other 740 than the number (1) for the MN-AAA authentication extension 741 specified in section Section 6, must be specified and approved by 742 a designated expert. 744 The MN-FA Challenge extension defined in Section Section 4 is a 745 router advertisement extension as defined in RFC 1256 [[RFC1256]] 746 and extended in RFC 3344 [[RFC3344]]. IANA should assign a value 747 of 132 for this purpose. 749 The Code values defined in section Section 10 are error codes as 750 defined in RFC 3344 ([RFC3344]). They correspond to error values 751 conventionally associated with rejection by the foreign agent 752 (i.e., values from the range 64-127). The Code value 67 is a pre- 753 existing value which is to be used in some cases with the 754 extension defined in this specification. IANA should record the 755 values as defined in section Section 10. 757 A new section for enumerating algorithms identified by specific 758 SPIs within the range 0-255 is added by IANA. The CHAP_SPI number 759 (2) discussed in section Section 8 is assigned from this range of 760 reserved SPI numbers. New assignments from this reserved range 761 must be specified and approved by the Mobile IP working group. 762 SPI number 1 should not be assigned unless in the future the 763 Mobile IP working group decides that SKIP is not important for 764 enumeration in the list of reserved numbers. SPI number 0 should 765 not be assigned. 767 Additionally, new error codes FA_BAD_AAA_AUTH, HA_BAD_AAA_AUTH, and 768 HA_WRONG_CHALLENGE are defined by this document. Among these, 769 HA_WRONG_CHALLENGE may appear in the Status code of the FA Error 770 extension defined in [FAERR]. 772 12. Security Considerations 774 In the event that a malicious mobile node attempts to replay the 775 authenticator for an old Mobile-Foreign Challenge, the foreign agent 776 would detect it since the agent always checks whether it has recently 777 advertised the Challenge (see Section 3.2). Allowing mobile nodes 778 with different IP addresses or NAIs to use the same Challenge value 779 does not represent a security vulnerability, because the 780 authentication data provided by the mobile node will be computed over 781 data that is different (at least the mobile nodes' IP address will 782 vary). 784 If the foreign agent chooses a Challenge value (see Section 2) with 785 fewer than 4 bytes, the foreign agent SHOULD include the value of the 786 Identification field in the records it maintains for the mobile node. 787 The foreign agent can then determine whether the Registration 788 messages using the short Challenge value are in fact unique, and thus 789 assuredly not replayed from any earlier registration. 791 Section 8 (SPI For RADIUS AAA Servers) defines a method of computing 792 the Generalized Mobile IP Authentication Extension's authenticator 793 field using MD5 in a manner that is consistent with RADIUS [RFC2138]. 794 The use of MD5 in the method described in Section 8 is less secure 795 than HMAC-MD5 [RFC2104], and MUST be avoided whenever possible. 797 Note that an active attacker may try to prevent successful 798 registrations by sending a large number of Agent Solicitations or 799 bogus Registration Requests, each of which could cause the foreign 800 agent to respond with a fresh challenge, invalidating the challenge 801 that the MN is currently trying to use. To prevent such attacks, the 802 foreign agent MUST NOT invalidate previously unused challenges when 803 responding to unauthenticated Registration Requests or Agent 804 Solicitations. In addition, the foreign agent MUST NOT allocate new 805 storage when responding to such messages, because this would also 806 create the possibility of denial of service. 808 The Challenge extension specified in this document need not be used 809 for co-located care-of address mode. In this case, replay protection 810 is provided by the Identification field in the Registration Request 811 message [RFC3344]. 813 13. Acknowledgments 815 The authors would like to thank Pete McCann, Ahmad Muhanna, Henrik 816 Levkowetz, Kent Leung, Alpesh Patel, Madjid Nakhjiri, Gabriel 817 Montenegro, Jari Arkko and other MIP4 WG participants for their 818 useful discussions. 820 14. Normative References 822 [FAERR] Perkins, C., "Foreign Agent Error Extension for Mobile 823 IPv4", draft-perkins-mip4-faerr-02.txt (work in progress), 824 January 2004. 826 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 827 September 1991. 829 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 830 April 1992. 832 [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 833 Recommendations for Security", RFC 1750, December 1994. 835 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 836 Protocol (CHAP)", RFC 1994, August 1996. 838 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 839 Hashing for Message Authentication", RFC 2104, 840 February 1997. 842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", BCP 14, RFC 2119, March 1997. 845 [RFC2138] Rigney, C., Rigney, C., Rubens, A., Simpson, W., and S. 846 Willens, "Remote Authentication Dial In User Service 847 (RADIUS)", RFC 2138, April 1997. 849 [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access 850 Identifier Extension for IPv4", RFC 2794, March 2000. 852 [RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/ 853 Response Extensions", RFC 3012, November 2000. 855 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 856 August 2002. 858 Appendix A. Change History 860 The following is the list of changes from RFC 3012 ([RFC3012]): 862 o Foreign agent recommended to include a Challenge in every 863 Registration Reply, so that mobile node can re-register without 864 waiting for an Advertisement. 866 o Foreign agent MUST record applicable challenge values used by each 867 mobile node. 869 o Mobile node forbidden to use Challenge values which were 870 advertised previous to the last Challenge value which it had used 871 for a registration. 873 o Challenge definitions are cleaned up. 875 o Programming suggestion added as an appendix. 877 o HMAC_CHAP_SPI option is added for Generalized Mobile IP 878 Authentication extension. Upon receipt of HMAC_CHAP_SPI, HMAC-MD5 879 is used instead of MD5 for computing the authenticator. 881 o Added FA_BAD_AAA_AUTH and HA_BAD_AAA_AUTH error codes to report 882 authentication errors caused while processing Mobile-AAA 883 Authentication extension. Also, added the error code 884 HA_WRONG_CHALLENGE to indicate that Challenge value differs in the 885 Registration Reply received from the home agent compare to the one 886 sent to the home agent in the Registration Request. 888 o Processing of the Mobile-AAA Authentication extension is clarified 889 for the foreign agent and the home agent. 891 o Co-existence of the Mobile-AAA Authentication extension in the 892 same Registration Request is made explicit. 894 o The situation in which the foreign agent sets MISSING_CHALLENGE is 895 clarified further. 897 o The use of Mobile-AAA Authentication Extension is allowed by the 898 mobile node with co-located care-of address. 900 o Added protection against bogus Registration Reply and Agent 901 Advertisement. Also, the processing of the Challenge is clarified 902 if it is received in the multicast/unicast Agent Advertisement. 904 o Added reference of FA Error extension in the References section 905 and also updated relevant text in section 3.2 and section 11. 907 Appendix B. Verification Infrastructure 909 The Challenge extensions in this protocol specification are expected 910 to be useful to help the foreign agent manage connectivity for 911 visiting mobile nodes, even in situations where the foreign agent 912 does not have any security association with the mobile node or the 913 mobile node's home agent. In order to carry out the necessary 914 authentication, it is expected that the foreign agent will need the 915 assistance of external administrative systems, which have come to be 916 called AAA systems. For the purposes of this document, we call the 917 external administrative support the "verification infrastructure". 918 The verification infrastructure is described to motivate the design 919 of the protocol elements defined in this document, and is not 920 strictly needed for the protocol to work. The foreign agent is free 921 to use any means at its disposal to verify the credentials of the 922 mobile node. This could, for instance, rely on a separate protocol 923 between the foreign agent and the Mobile IP home agent, and still be 924 completely invisible to the mobile node. 926 In order to verify the credentials of the mobile node, we assume that 927 the foreign agent has access to a verification infrastructure that 928 can return a secure notification to the foreign agent that the 929 authentication has been performed, along with the results of that 930 authentication. This infrastructure may be visualized as shown in 931 Figure 4. 933 +----------------------------------------------------+ 934 | | 935 | Verification and Key Management Infrastructure | 936 | | 937 +----------------------------------------------------+ 938 ^ | ^ | 939 | | | | 940 | v | v 941 +---------------+ +---------------+ 942 | | | | 943 | foreign agent | | home agent | 944 | | | | 945 +---------------+ +---------------+ 947 Figure 4: The Verification Infrastructure 949 After the foreign agent gets the Challenge authentication, it MAY 950 pass the authentication to the (here unspecified) infrastructure, and 951 await a Registration Reply. If the Reply has a positive status 952 (indicating that the registration was accepted), the foreign agent 953 accepts the registration. If the Reply contains the Code value 954 BAD_AUTHENTICATION (see Section 10), the foreign agent takes actions 955 indicated for rejected registrations. 957 Implicit in this picture, is the important observation that the 958 foreign agent and the home agent have to be equipped to make use of 959 whatever protocol is made available to them by the challenge 960 verification and key management infrastructure shown in the figure. 962 The protocol messages for handling the authentication within the 963 verification infrastructure, and identity of the agent performing the 964 verification of the foreign agent challenge, are not specified in 965 this document, because those operations do not have to be performed 966 by any Mobile IP entity. 968 Appendix C. Message Flow for FA Challenge Messaging with Mobile-AAA 969 Extension 971 MN FA Verification home agent 972 |<-- Adv+Challenge--| Infrastructure | 973 | (if needed) | | | 974 | | | | 975 |-- RReq+Challenge->| | | 976 | + Auth.Ext. | | | 977 | | Auth. Request, incl. | | 978 | |--- RReq + Challenge --->| | 979 | | + Auth.Ext | RReq + | 980 | | |-- Challenge -->| 981 | | | | 982 | | | | 983 | | |<--- RRep ----- | 984 | | Authorization, incl. | | 985 | |<-- RRep + Auth.Ext.-----| | 986 | | | | 987 |<-- RRep+Auth.Ext--| | | 988 | + New Challenge | | | 990 Figure 5: Message Flows for FA Challenge Messaging 992 In Figure 5, the following informational message flow is illustrated: 994 1. The foreign agent includes a Challenge Value in a unicast Agent 995 Advertisement if needed. This advertisement MAY have been 996 produced after receiving an Agent Solicitation from the mobile 997 node (not shown in the diagram). 999 2. The mobile node creates a Registration Request including the 1000 advertised Challenge Value in the Challenge extension, along with 1001 an Mobile-AAA authentication extension. 1003 3. The foreign agent relays the Registration Request either to the 1004 home agent specified by the mobile node, or else to its locally 1005 configured Verification Infrastructure (see Appendix B), 1006 according to local policy. 1008 4. The foreign agent receives a Registration Reply with the 1009 appropriate indications for authorizing connectivity for the 1010 mobile node. 1012 5. The foreign agent relays the Registration Reply to the mobile 1013 node, possibly along with a new Challenge Value to be used by the 1014 mobile node in its next Registration Request message. 1016 Appendix D. Message Flow for FA Challenge Messaging with MN-FA 1017 Authentication 1019 MN FA home agent 1020 |<-- Adv+Challenge--| | 1021 | (if needed) | | 1022 | | | 1023 |-- RReq+Challenge->| | 1024 | + Auth.Ext. | | 1025 | |--- RReq + Challenge --->| 1026 | | + HA-FA Auth.Ext | 1027 | | | 1028 | |<-- RRep + Challenge ----| 1029 | | + HA-FA Auth.Ext | 1030 | | | 1031 |<-- RRep+Auth.Ext--| | 1032 | + New Challenge | | 1034 Figure 6: Message Flows for FA Challenge Messaging with MN-FA 1035 Authentication 1037 In Figure 6, the following informational message flow is illustrated: 1039 1. The foreign agent disseminates a Challenge Value in an Agent 1040 Advertisement if needed. This advertisement MAY have been 1041 produced after receiving an Agent Solicitation from the mobile 1042 node (not shown in the diagram). 1044 2. The mobile node creates a Registration Request including the 1045 advertised Challenge Value in the Challenge extension, along with 1046 an Mobile-Foreign Authentication extension. 1048 3. The foreign agent relays the Registration Request to the home 1049 agent specified by the mobile node. 1051 4. The foreign agent receives a Registration Reply with the 1052 appropriate indications for authorizing connectivity for the 1053 mobile node. 1055 5. The foreign agent relays the Registration Reply to the mobile 1056 node, possibly along with a new Challenge Value to be used by the 1057 mobile node in its next Registration Request message. If the 1058 Reply contains the Code value HA_BAD_AAA_AUTH (see Section 10), 1059 the foreign agent takes actions indicated for rejected 1060 registrations. 1062 Appendix E. Example Pseudo-Code for Tracking Used Challenges 1064 current_chal := RegistrationRequest.challenge_extension_value 1065 last_chal := mobile_node_record.last_used_adv_chal 1067 if (current_chal == mobile_node_record.RegReply_challenge) { 1068 update (mobile_node_record, current_chal) 1069 return (OK) 1070 } 1071 else if (current_chal "among" VALID_ADV_CHALLENGES[]{ 1072 if (last_chal "among" VALID_ADV_CHALLENGES[]) { 1073 if (current_chal is "before" last_chal) { 1074 send_error(STALE_CHALLENGE) 1075 return (FAILURE) 1076 } 1077 else { 1078 update (mobile_node_record, current_chal) 1079 return (OK) 1080 } 1081 } 1082 else { 1083 update (mobile_node_record, current_chal) 1084 return (OK) 1085 } 1086 } 1087 else { 1088 send_error(UNKNOWN_CHALLENGE); 1089 } 1091 Authors' Addresses 1093 Charles E. Perkins 1094 Nokia Research Center 1095 Communications Systems Lab 1096 313 Fairchild Drive 1097 Mountain View, California 94043 1099 Phone: +1 650 625-2986 1100 Email: charles.perkins@nokia.com 1102 Pat R. Calhoun 1103 Cisco Systems, Inc. 1104 170 West Tasman Drive 1105 San Jose, CA 95134 1107 Phone: +1 408-853-5269 1108 Email: pcalhoun@cisco.com 1110 Jayshree Bharatia 1111 Nortel Networks 1112 2221, Lakeside Blvd 1113 Richardson, TX 75082 1115 Phone: +1 972-684-5767 1116 Email: jayshree@nortel.com 1118 Intellectual Property Statement 1120 The IETF takes no position regarding the validity or scope of any 1121 Intellectual Property Rights or other rights that might be claimed to 1122 pertain to the implementation or use of the technology described in 1123 this document or the extent to which any license under such rights 1124 might or might not be available; nor does it represent that it has 1125 made any independent effort to identify any such rights. Information 1126 on the procedures with respect to rights in RFC documents can be 1127 found in BCP 78 and BCP 79. 1129 Copies of IPR disclosures made to the IETF Secretariat and any 1130 assurances of licenses to be made available, or the result of an 1131 attempt made to obtain a general license or permission for the use of 1132 such proprietary rights by implementers or users of this 1133 specification can be obtained from the IETF on-line IPR repository at 1134 http://www.ietf.org/ipr. 1136 The IETF invites any interested party to bring to its attention any 1137 copyrights, patents or patent applications, or other proprietary 1138 rights that may cover technology that may be required to implement 1139 this standard. Please address the information to the IETF at 1140 ietf-ipr@ietf.org. 1142 Disclaimer of Validity 1144 This document and the information contained herein are provided on an 1145 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1146 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1147 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1148 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1149 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1150 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1152 Copyright Statement 1154 Copyright (C) The Internet Society (2006). This document is subject 1155 to the rights, licenses and restrictions contained in BCP 78, and 1156 except as set forth therein, the authors retain all their rights. 1158 Acknowledgment 1160 Funding for the RFC Editor function is currently provided by the 1161 Internet Society.