idnits 2.17.1 draft-ietf-mobileip-challenge-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 75: '... Length MUST be at least 16...' RFC 2119 keyword, line 99: '...n Agent, then it MUST include the Chal...' RFC 2119 keyword, line 102: '...oreign agent, it MAY include the Chall...' RFC 2119 keyword, line 106: '... it MUST include a Mobile-Foreign Au...' RFC 2119 keyword, line 109: '...Foreign Authentication MUST follow the...' (36 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-01 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-07 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mn-nai-04 ** Obsolete normative reference: RFC 1750 (ref. '5') (Obsoleted by RFC 4086) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-07 ** Obsolete normative reference: RFC 2344 (ref. '7') (Obsoleted by RFC 3024) ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '8') ** Obsolete normative reference: RFC 2461 (ref. '9') (Obsoleted by RFC 4861) == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-08 -- Possible downref: Normative reference to a draft: ref. '10' ** Obsolete normative reference: RFC 2002 (ref. '11') (Obsoleted by RFC 3220) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '12') ** Obsolete normative reference: RFC 1334 (ref. '13') (Obsoleted by RFC 1994) Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Charles E. Perkins 2 INTERNET DRAFT Nokia Research Center 3 25 October 1999 Pat R. Calhoun 4 Sun Microsystems Laboratories 6 Mobile IP Challenge/Response Extensions 7 draft-ietf-mobileip-challenge-04.txt 9 Status of This Memo 11 This document is a submission by the mobile-ip Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the mobile-ip@smallworks.com mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at: 31 http://www.ietf.org/shadow.html. 33 Abstract 35 Mobile IP, as originally specified, defines an authentication 36 extension (the Mobile-Foreign Authentication extension) by 37 which a mobile node can authenticate itself to a foreign agent. 38 Unfortunately, this extension does not provide ironclad replay 39 protection for the foreign agent, and does not conform to existing 40 techniques (such as CHAP) for authenticating portable computer 41 devices. In this specification, we define extensions for the Mobile 42 IP Agent Advertisements and the Registration Request that allow a 43 foreign agent to use a challenge/response mechanism to authenticate 44 the mobile node. 46 1. Introduction 48 Mobile IP, as originally specified, defines an authentication 49 extension (the Mobile-Foreign Authentication extension) by 50 which a mobile node can authenticate itself to a foreign agent. 51 Unfortunately, this extension does not provide ironclad replay 52 protection, and does not conform to existing techniques (such 53 as CHAP) for authenticating portable computer devices. In this 54 specification, we define extensions for the Mobile IP Agent 55 Advertisements and the Registration Request that allow a foreign 56 agent to a use challenge/response mechanism to authenticate the 57 mobile node. 59 2. Mobile IP Agent Advertisement Challenge Extension 61 This section defines a new extension to the Router Discovery 62 Protocol [4] for use by foreign agents that need to issue a challenge 63 for authenticating mobile nodes. 65 0 1 2 3 66 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 67 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 68 | Type | Length | Challenge ... 69 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 71 Figure 1: The Challenge Extension 73 Type 24 75 Length MUST be at least 16 77 Challenge A random value of at least 128 bits. 79 The Challenge extension, illustrated in figure 1, is inserted 80 in the Agent Advertisements by the Foreign Agent, in order to 81 communicate the latest challenge value that can be used by the mobile 82 node to compute an authentication for its registration request 83 message. The challenge is selected by the foreign agent to provide 84 local assurance that the mobile node is not replaying any earlier 85 registration request. Eastlake, et al. [5] provides more information 86 on generating pseudo-random numbers suitable for use as values for 87 the challenge. 89 3. Operation 91 This section describes modifications to the Mobile IP registration 92 process which may occur after the Foreign Agent issues a Mobile IP 93 Agent Advertisement containing the Challenge on its local link. 95 3.1. Mobile Node Processing for Registration Requests 97 Whenever the Agent Advertisement contains the Challenge extension, 98 if the mobile node does not have a security association with the 99 Foreign Agent, then it MUST include the Challenge value in a MN-FA 100 Challenge extension to the Registration Request message. If, on the 101 other hand, the mobile node does have a security association with the 102 foreign agent, it MAY include the Challenge value in its Registration 103 Request message. 105 If the Mobile Node has a security association with the Foreign Agent, 106 it MUST include a Mobile-Foreign Authentication extension in its 107 Registration Request message, according to RFC 2002 [11]. When the 108 Registration Request contains the MN-FA Challenge extension specified 109 in section 4, the Mobile-Foreign Authentication MUST follow the 110 Challenge extension in the Registration Request. 112 If the Mobile Node does not have a security association with the 113 Foreign Agent, the Mobile Node MUST include the MN-AAA Authentication 114 extension as defined in section 4.2, or the MN-RADIUS extension as 115 defined in section 4.3. In addition, the Mobile Node SHOULD include 116 the NAI extension [3], to enable the foreign agent to make use of 117 any available verification infrastructure. The SPI field of the 118 MN-AAA Authentication extension specifies the particular secret 119 and algorithm (shared between the Mobile Node and the verification 120 infrastructure) that must be used to perform the authentication. The 121 MN-RADIUS extension only supports CHAP-style authentication [13] 122 using MD5 [12], and the SPI field MAY be set to any value. 124 In either case, the MN-FA Challenge extension and one of the above 125 specified authentication extensions MUST follow the Mobile-Home 126 Authentication extension, if present. 128 3.2. Foreign Agent Processing for Registration Requests 130 Upon receipt of the Registration Request, if the Foreign Agent has 131 issued a Challenge as part of its Agent Advertisements, and it does 132 not have a security association with the mobile node, then the 133 Foreign Agent MUST check that the MN-FA Challenge extension exists, 134 and that it contains a challenge value previously unused by the 135 Mobile Node. This ensures that the mobile node is not attempting 136 to replay a previous advertisement and authentication. If the 137 challenge extension is needed and does not exist, the Foreign Agent 138 MUST send a Regstration Reply to the mobile node with the error code 139 MISSING_CHALLENGE. 141 If a mobile node retransmits a Registration Request with the same 142 Identification field and the same Challenge extension, and the 143 Foreign Agent still has a pending Registration Request record 144 in effect for the mobile node, then the Foreign Agent forwards 145 the Registration Request to the Home Agent again. In all other 146 circumstances, if the Foreign Agent receives a Registration 147 Request with a Challenge extension containing a Challenge value 148 previously used by that mobile node, the Foreign Agent SHOULD send 149 a Registration Reply to the mobile node containing the Code value 150 STALE_CHALLENGE. 152 The Foreign Agent MUST NOT accept any Challenge in the Registration 153 Request unless it was advertised as one of the last CHALLENGE_WINDOW 154 (see section 5) Challenge values inserted into the immediately 155 preceding Agent advertisements. If the Challenge is not one of 156 the recently advertised values, the foreign Agent SHOULD send a 157 Registration Reply with Code UNKNOWN_CHALLENGE (see section 6). 159 Furthermore, the Foreign Agent MUST check that there is either a 160 Mobile-Foreign, a MN-AAA Authentication, or a MN-RADIUS extension 161 after the Challenge value. Any registration message containing the 162 Challenge value without either of these authentication extensions 163 MUST be silently discarded. If the registration message contains 164 a Mobile-Foreign Authentication extension with an incorrect 165 authenticator that fails verification, the Foreign Agent MAY 166 send a Registration Reply to the mobile node with Code value 167 BAD_AUTHENTICATION (see Section 6). 169 If the MN-AAA Authentication extension (see Section 4.2) is present 170 in the message, or if an NAI extension is included indicating that 171 the mobile node belongs to a different administrative domain, the 172 foreign agent may take actions outside the scope of this protocol 173 specification to carry out the authentication of the mobile node. 174 For instance, the foreign agent MAY forward the Registration Request 175 to the verification infrastructure (see figure 5 in the Appendix). 176 If the MN-RADIUS extension (see Section 4.3) is present, the foreign 177 agent SHOULD forward the request to the Home Agent, and does not need 178 to interact with the verification infrastructure. 180 Since the Challenge extension, and the authentication extension that 181 is used by the Mobile Node to satisfy the challenge, both follow 182 the Mobile-Home Authentication extension whenever the latter is 183 present, the Foreign Agent MAY remove the Challenge Extension and 184 the applicable authentication from the Registration Request without 185 disturbing the authentication value computed by the Mobile Node for 186 use by the Home Agent. 188 If the Foreign Agent does not remove those extensions, then the 189 Foreign Agent SHOULD store the Challenge value as part of the pending 190 registration request list [11]. Also in this case, the Foreign Agent 191 MUST reject any Registration Reply message coming from the Home Agent 192 that does not also include the Challenge Extension with the same 193 Challenge Value that was included in the Registration Request. The 194 Foreign Agent MUST send the rejected Registration message to the 195 mobile node, and change the status in the Registration Reply to the 196 value MISSING_CHALLENGE (see section 6). 198 If the Foreign Agent does remove the Challenge extension and 199 applicable authentication from the Registration Request message, 200 then it SHOULD insert the Identification field from the Registration 201 Request message along with its record-keeping information about the 202 particular Mobile Node in order to protect against replays. 204 3.3. Home Agent Processing for the Challenge Extensions 206 If the Home Agent receives a Registration Request with the MN-FA 207 Challenge extension, and recognizes the extension, the Home Agent 208 MUST include the Challenge extension in the Registration Reply. 209 The Challenge Extension SHOULD be included before the Mobile-Home 210 Authentication extension. 212 Since the extension type for the Challenge extension is within the 213 range 128-255, the Home Agent MUST process such a Registration 214 Request even if it does not recognize the Challenge extension [11]. 215 In this case, the Home Agent will send a Registration Reply to the 216 Foreign Agent that does not include the Challenge extension. 218 4. Mobile IP Registration Extensions 220 This section specifies new Mobile IP Registration Extensions that are 221 used to satisfy a Challenge in an Agent Advertisement. 223 4.1. MN-FA Challenge Extension 225 The Challenge extension to the Registration Request message is used 226 to indicate the challenge that the mobile node is attempting to 227 satisfy. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type | Length | Challenge... 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 2: The MN-FA Challenge Extension 237 Type 132 (skippable) (see [11]) 239 Length MUST be at least 16 241 Challenge The Challenge field is copied from the Challenge field 242 found in the Agent Advertisement Challenge extension 243 (see section 2). 245 4.2. MN-AAA Authentication Extension 247 The mobile node MAY include this extension in the Registration 248 Request. If the mobile node does not include a Mobile-Foreign 249 Authentication extension, then it MUST include the MN-AAA 250 Authentication extension [11] or the MN-RADIUS extension 251 (section 4.3) whenever the Challenge extension is present. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Type | Length | SPI ... 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 ... SPI (cont.) | Authenticator 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 3: The MN-AAA Authentication Extension 263 Type 36 (not skippable) (see [11]) 265 Length 4 plus the number of bytes in the Authenticator; 266 MUST be at least 20. 268 SPI Security Parameters Index 270 Authenticator The variable length Authenticator field consists 271 random value of at least 128 bits. 273 The default algorithm for computation of the authenticator is 274 MD5 [12] computed on the following data, in the order shown: 276 Key || Preceding Mobile IP data || Type, Length, SPI || Key 278 where the Type, Length, and SPI are as shown above. Each mobile node 279 MUST support the ability to produce the authenticator by using MD5 as 280 shown (known as "prefix+suffix" mode). Just as with Mobile IP, MD5 281 in the prefix+suffix mode MUST be able to be configured for selection 282 at any arbitrary 32-bit SPI. 284 4.3. MN-RADIUS Extension 286 The mobile node MAY include this extension in the Registration 287 Request if it has a security association with a RADIUS server. If 288 the mobile node does not include a Mobile-Foreign Authentication 289 extension, then it MUST include either the MN-AAA or the MN-RADIUS 290 authentication extension. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Length | SPI ... 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 ... SPI (cont.) | Authenticator 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 4: The MN-RADIUS Extension 302 Type 37 (not skippable) (see [11]) 304 Length 4 plus the number of bytes in the Authenticator; 305 MUST be at least 20. 307 SPI Security Parameters Index 309 Authenticator The variable length Authenticator field consists 310 random value of at least 128 bits. 312 The default algorithm for computation of the authenticator is 313 MD5 [12] computed on the following data, in the order shown: 315 Key || 240 bytes (or less) of preceding Mobile IP data || 316 Type, Length, SPI 318 where the Type, Length, and SPI are as shown above. Since the 319 RADIUS protocol cannot carry objects greater than 253 in size, it is 320 necessary that only the first 240 bytes of the preceding Mobile IP 321 data be used. The challenge extension MUST be present in the first 322 240 bytes of the Registration Request. 324 5. Configurable Parameters 326 Every Mobile IP agent supporting the extensions defined in this 327 document SHOULD be able to configure each parameter in the following 328 table. Each table entry contains the name of the parameter, the 329 default value, and the section of the document in which the parameter 330 first appears. 332 Parameter Name Default Value Section of Document 333 -------------- ------------- ------------------- 334 CHALLENGE_WINDOW 2 3.2 336 6. Error Values 338 Each entry in the following table contains the name of Code [11] to 339 be returned in a Registration Reply, the value for the Code, and the 340 section in which the error is first mentioned in this specification. 342 Error Name Value Section of Document 343 ---------------------- ----- ------------------- 344 UNKNOWN_CHALLENGE 104 3.2 345 BAD_AUTHENTICATION 67 3.2; also see [11] 346 MISSING_CHALLENGE 105 3.2 347 STALE_CHALLENGE 106 3.2 349 7. IANA Considerations 351 The number for the Mobile IP Agent Advertisement Challenge extension 352 (section 2) is taken from the numbering space defined for Mobile 353 IP extensions to the ICMP Router Advertisements [4] defined in 354 RFC 2002 [11]. The number for the MN-FA Challenge extension 355 (section 4.1) and the MN-AAA Authentication extension (section 4.2) 356 is taken from the numbering space defined for Mobile IP registration 357 extensions defined in RFC 2002 [11] as extended in RFC 2356 [8]. 358 The numbering for the extensions SHOULD NOT conflict with values 359 specified in the Internet Draft for Route Optimization [10] or 360 the Internet Draft for the Mobile IP Network Address Identifier 361 Extension. The Code values specified for errors, listed in 362 section 6, MUST NOT conflict with any other code values listed in 363 RFC 2002, RFC 2344 [7], or RFC 2356 [8], or the abovementioned 364 Internet Drafts. They are to be taken from the space of error values 365 conventionally associated with rejection by the foreign agent (i.e., 366 64-127). 368 8. Security Considerations 370 In the event that a malicious mobile node attempts to replay the 371 authenticator for an old MN-FA Challenge, the Foreign Agent would 372 detect it since the agent always checks whether it has recently 373 advertised the Challenge (see section 3.2). Allowing mobile nodes 374 with different IP addresses or NAIs to use the same Challenge 375 value does not represent a security vulnerability, because the 376 authentication data provided by the mobile node will be computed over 377 data that is different (at least by the bytes of the mobile nodes' IP 378 addresses). 380 9. IPv6 Considerations 382 For use with IPv6 mobility [6], the challenge extension should be 383 applied to Router Advertisements [9]. In order to check the response 384 from the mobile node, the router would need to have a security 385 relationship with either the mobile node, its home agent, or another 386 entity within the IPv6 security infrastructure. It is not yet known 387 which security model would be more appropriate, or whether it would 388 make the most sense to enable maximum flexibility by specifying the 389 protocol for each case. 391 10. Acknowledgements 393 The authors would like to thank Tom Hiller, Mark Munson, the TIA 394 TR45-6 WG, Gabriel Montenegro, Vipul Gupta, and Pete McCann for their 395 useful discussions. 397 References 399 [1] P. Calhoun and C. E. Perkins. DIAMETER Mobile IP Extensions. 400 draft-calhoun-diameter-mobileip-01.txt, November 1998. (work in 401 progress). 403 [2] P. Calhoun and A. Rubens. DIAMETER Base Protocol. 404 draft-calhoun-diameter-07.txt, November 1998. (work in 405 progress). 407 [3] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network 408 Address Identifier Extension. 409 draft-ietf-mobileip-mn-nai-04.txt, 410 September 1999. (work in progress). 412 [4] Stephen E. Deering, Editor. ICMP Router Discovery Messages. 413 RFC 1256, September 1991. 415 [5] Donald E. Eastlake, Stephen D. Crocker, and Jeffrey I. Schiller. 416 Randomness Recommendations for Security. RFC 1750, December 417 1994. 419 [6] D. Johnson and C. Perkins. Mobility Support in IPv6. 420 draft-ietf-mobileip-ipv6-07.txt, November 1998. (work in 421 progress). 423 [7] G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, May 424 1998. 426 [8] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 427 Mobile IP. RFC 2356, June 1998. 429 [9] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor 430 discovery for IP Version 6 (IPv6), December 1998. Status: 431 DRAFT STANDARD. 433 [10] Charles E. Perkins and David B. Johnson. Route Optimization in 434 Mobile-IP. draft-ietf-mobileip-optim-08.txt, February 1999. 435 (work in progress). 437 [11] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 438 1996. 440 [12] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, 441 April 1992. 443 [13] W. Simpson. RFC 1994: PPP challenge handshake authentication 444 protocol (CHAP), August 1996. Obsoletes RFC1334. Status: DRAFT 445 STANDARD. 447 A. Verification Infrastructure 449 The Challenge extensions in this protocol specification are expected 450 to be useful to help the Foreign Agent manage connectivity for 451 visiting mobile nodes, even in situations where the foreign agent 452 does not have any security association with the mobile node or the 453 mobile node's home agent. In order to carry out the necessary 454 authentication, it is expected that the foreign agent will need the 455 assistance of external administrative systems, which recently have 456 come to be called AAA systems. For the purposes of this document, 457 we call the external administrative support the "verification 458 infrastructure". The verification infrastructure is described 459 to motivate the design of the protocol elements defined in this 460 document, and is not strictly needed for the protocol to work. The 461 foreign agent is free to use any means at its disposal to verify the 462 credentials of the mobile node. This could, for instance, rely on a 463 separate protocol between the foreign agent and the Mobile IP home 464 agent, and still be completely invisible to the mobile node. 466 In order to verify the credentials of the mobile node, we imagine 467 that the foreign agent has access to a verification infrastructure 468 that can return a secure notification to the foreign agent that 469 the authentication has been performed, along with the results of 470 that authentication. This infrastructure may be visualized as 471 shown in figure 5. For an example of another protocol that has 472 been specified to actually carry out the challenge verification 473 operations, see [2, 1]. 475 After the foreign agent gets the Challenge authentication, it MAY 476 pass the authentication to the (here unspecified) infrastructure, 477 and await a Registration Reply. If the Reply has a positive 478 status (indicating that the registration was accepted), the foreign 479 agent accepts the registration. If the Reply contains Code value 480 BAD_AUTHENTICATION (see Section 6), the foreign agent takes actions 481 indicated for rejected registrations. 483 Implicit in this picture, is the important observation that the 484 Foreign Agent and the Home Agent have to be equipped to make use 485 of whatever protocol is made available to them by the challenge 486 verification and key management infrastructure shown in the figure. 488 +----------------------------------------------------+ 489 | | 490 | Verification and Key Management Infrastructure | 491 | | 492 +----------------------------------------------------+ 493 ^ | ^ | 494 | | | | 495 | v | v 496 +---------------+ +---------------+ 497 | | | | 498 | Foreign Agent | | Home Agent | 499 | | | | 500 +---------------+ +---------------+ 502 Figure 5: The Verification Infrastructure 504 The protocol messages for handling the authentication within the 505 verification infrastructure, and identity of the agent performing the 506 verification of the Foreign Agent challenge, are not specified in 507 this document, because those operations do not have to be performed 508 by any Mobile IP entity. 510 Addresses 512 The working group can be contacted via the current chairs: 514 Basavaraj Patil Phil Roberts 515 Nortel Networks Inc. Motorola 516 2201 Lakeside Blvd. 1501 West Shure Drive 517 Richardson, TX. 75082-4399 Arlington Heights, IL 60004 518 USA USA 520 Phone: +1 972-684-1489 Phone: +1 847-632-3148 521 EMail: bpatil@nortelnetworks.com EMail: QA3445@email.mot.com 523 Questions about this memo can be directed to: 525 Charles E. Perkins Pat R. Calhoun 526 Nokia Research Center Sun Microsystems Laboratories 527 313 Fairchild Drive 15 Network Circle 528 Mountain View, California 94043 Menlo Park, California 94025 529 USA USA 531 Phone: +1-650 625-2986 Phone: +1 650-786-7733 532 EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com 533 Fax: +1 650 691-2170 Fax: +1 650-786-6445