idnits 2.17.1 draft-ietf-mobileip-challenge-06.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...' (33 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-06.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 MN-AAA Authentication extension (see Section 4.2) or MN-RADIUS 170 Authentication extension (see Setion 4.3) is present in the message, 171 or if an NAI extension is included indicating that the mobile node 172 belongs to a different administrative domain, the foreign agent may 173 take actions outside the scope of this protocol specification to 174 carry out the authentication of the mobile node. The appendix 175 provides an example of an action that could be taken by a foreign 176 agent. 178 Since the Challenge extension, and the authentication extension that 179 is used by the Mobile Node to satisfy the challenge, both follow 180 the Mobile-Home Authentication extension whenever the latter is 181 present, the Foreign Agent MAY remove the Challenge Extension and 182 the applicable authentication from the Registration Request without 183 disturbing the authentication value computed by the Mobile Node for 184 use by the Home Agent. 186 If the Foreign Agent does not remove those extensions, then the 187 Foreign Agent SHOULD store the Challenge value as part of the pending 188 registration request list [11]. Also in this case, the Foreign Agent 189 MUST reject any Registration Reply message coming from the Home Agent 190 that does not also include the Challenge Extension with the same 191 Challenge Value that was included in the Registration Request. The 192 Foreign Agent MUST send the rejected Registration message to the 193 mobile node, and change the status in the Registration Reply to the 194 value MISSING_CHALLENGE (see section 6). 196 If the Foreign Agent does remove the Challenge extension and 197 applicable authentication from the Registration Request message, 198 then it SHOULD insert the Identification field from the Registration 199 Request message along with its record-keeping information about the 200 particular Mobile Node in order to protect against replays. 202 3.3. Home Agent Processing for the Challenge Extensions 204 If the Home Agent receives a Registration Request with the MN-FA 205 Challenge extension, and recognizes the extension, the Home Agent 206 MUST include the Challenge extension in the Registration Reply. 207 The Challenge Extension SHOULD be included before the Mobile-Home 208 Authentication extension. 210 Since the extension type for the Challenge extension is within the 211 range 128-255, the Home Agent MUST process such a Registration 212 Request even if it does not recognize the Challenge extension [11]. 213 In this case, the Home Agent will send a Registration Reply to the 214 Foreign Agent that does not include the Challenge extension. 216 4. Mobile IP Registration Extensions 218 This section specifies new Mobile IP Registration Extensions that are 219 used to satisfy a Challenge in an Agent Advertisement. 221 4.1. MN-FA Challenge Extension 223 The Challenge extension to the Registration Request message is used 224 to indicate the challenge that the mobile node is attempting to 225 satisfy. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type | Length | Challenge... 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Figure 2: The MN-FA Challenge Extension 235 Type 132 (skippable) (see [11]) 237 Length MUST be at least 16 239 Challenge The Challenge field is copied from the Challenge field 240 found in the Agent Advertisement Challenge extension 241 (see section 2). 243 4.2. MN-AAA Authentication Extension 245 The mobile node MAY include this extension in the Registration 246 Request. If the mobile node does not include a Mobile-Foreign 247 Authentication extension, then it MUST include the MN-AAA 248 Authentication extension [11] or the MN-RADIUS extension 249 (section 4.3) whenever the Challenge extension is present. 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Type | Length | SPI ... 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 ... SPI (cont.) | Authenticator 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Figure 3: The MN-AAA Authentication Extension 261 Type 36 (not skippable) (see [11]) 263 Length 4 plus the number of bytes in the Authenticator; 264 MUST be at least 20. 266 SPI Security Parameters Index 268 Authenticator The variable length Authenticator field consists 269 random value of at least 128 bits. 271 The default algorithm for computation of the authenticator is 272 MD5 [12] computed on the following data, in the order shown: 274 Key || Preceding Mobile IP data || Type, Length, SPI || Key 276 where the Type, Length, and SPI are as shown above. Each mobile node 277 MUST support the ability to produce the authenticator by using MD5 as 278 shown (known as "prefix+suffix" mode). Just as with Mobile IP, MD5 279 in the prefix+suffix mode MUST be able to be configured for selection 280 at any arbitrary 32-bit SPI. 282 4.3. MN-RADIUS Extension 284 The mobile node MAY include this extension in the Registration 285 Request if it has a security association with a RADIUS server. If 286 the mobile node does not include a Mobile-Foreign Authentication 287 extension, then it MUST include either the MN-AAA or the MN-RADIUS 288 authentication extension. 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type | Length | SPI ... 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 ... SPI (cont.) | Authenticator 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 4: The MN-RADIUS Extension 300 Type 37 (not skippable) (see [11]) 302 Length 4 plus the number of bytes in the Authenticator; 303 MUST be at least 20. 305 SPI Security Parameters Index 307 Authenticator The variable length Authenticator field consists 308 random value of at least 128 bits. 310 The default algorithm for computation of the authenticator is 311 MD5 [12] computed on the following data, in the order shown: 313 High-order byte from Challenge || Key || 314 MD5(Preceding Mobile IP data || Type, Length, SPI) || 315 Least-order 237 bytes from challenge 317 where the Type, Length, and SPI are as shown above. Since the 318 RADIUS protocol cannot carry attributes greater than 253 in size, 319 the Preceding Mobile IP data, type, length and SPI are hashed 320 using MD5. Finally, the least significant 237 octets of the 321 challenge are concatenated. 323 5. Configurable Parameters 325 Every Mobile IP agent supporting the extensions defined in this 326 document SHOULD be able to configure each parameter in the following 327 table. Each table entry contains the name of the parameter, the 328 default value, and the section of the document in which the parameter 329 first appears. 331 Parameter Name Default Value Section of Document 332 -------------- ------------- ------------------- 333 CHALLENGE_WINDOW 2 3.2 335 6. Error Values 337 Each entry in the following table contains the name of Code [11] to 338 be returned in a Registration Reply, the value for the Code, and the 339 section in which the error is first mentioned in this specification. 341 Error Name Value Section of Document 342 ---------------------- ----- ------------------- 343 UNKNOWN_CHALLENGE 104 3.2 344 BAD_AUTHENTICATION 67 3.2; also see [11] 345 MISSING_CHALLENGE 105 3.2 346 STALE_CHALLENGE 106 3.2 348 7. IANA Considerations 350 The number for the Mobile IP Agent Advertisement Challenge extension 351 (section 2) is taken from the numbering space defined for Mobile 352 IP extensions to the ICMP Router Advertisements [4] defined in 353 RFC 2002 [11]. The number for the MN-FA Challenge extension 354 (section 4.1) and the MN-AAA Authentication extension (section 4.2) 355 is taken from the numbering space defined for Mobile IP registration 356 extensions defined in RFC 2002 [11] as extended in RFC 2356 [8]. 357 The numbering for the extensions SHOULD NOT conflict with values 358 specified in the Internet Draft for Route Optimization [10] or 359 the Internet Draft for the Mobile IP Network Address Identifier 360 Extension. The Code values specified for errors, listed in 361 section 6, MUST NOT conflict with any other code values listed in 362 RFC 2002, RFC 2344 [7], or RFC 2356 [8], or the abovementioned 363 Internet Drafts. They are to be taken from the space of error values 364 conventionally associated with rejection by the foreign agent (i.e., 365 64-127). 367 8. Security Considerations 369 In the event that a malicious mobile node attempts to replay the 370 authenticator for an old MN-FA Challenge, the Foreign Agent would 371 detect it since the agent always checks whether it has recently 372 advertised the Challenge (see section 3.2). Allowing mobile nodes 373 with different IP addresses or NAIs to use the same Challenge 374 value does not represent a security vulnerability, because the 375 authentication data provided by the mobile node will be computed over 376 data that is different (at least by the bytes of the mobile nodes' IP 377 addresses). 379 9. IPv6 Considerations 381 For use with IPv6 mobility [6], the challenge extension should be 382 applied to Router Advertisements [9]. In order to check the response 383 from the mobile node, the router would need to have a security 384 relationship with either the mobile node, its home agent, or another 385 entity within the IPv6 security infrastructure. It is not yet known 386 which security model would be more appropriate, or whether it would 387 make the most sense to enable maximum flexibility by specifying the 388 protocol for each case. 390 10. Acknowledgements 392 The authors would like to thank Tom Hiller, Mark Munson, the TIA 393 TR45-6 WG, Gabriel Montenegro, Vipul Gupta, and Pete McCann for their 394 useful discussions. 396 References 398 [1] P. Calhoun and C. E. Perkins. DIAMETER Mobile IP Extensions. 399 draft-calhoun-diameter-mobileip-01.txt, November 1998. (work in 400 progress). 402 [2] P. Calhoun and A. Rubens. DIAMETER Base Protocol. 403 draft-calhoun-diameter-07.txt, November 1998. (work in 404 progress). 406 [3] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network 407 Address Identifier Extension. draft-ietf-mobileip-mn-nai-04.txt, 408 September 1999. (work in progress). 410 [4] Stephen E. Deering, Editor. ICMP Router Discovery Messages. 411 RFC 1256, September 1991. 413 [5] Donald E. Eastlake, Stephen D. Crocker, and Jeffrey I. Schiller. 414 Randomness Recommendations for Security. RFC 1750, December 415 1994. 417 [6] D. Johnson and C. Perkins. Mobility Support in IPv6. 418 draft-ietf-mobileip-ipv6-07.txt, November 1998. (work in 419 progress). 421 [7] G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, May 422 1998. 424 [8] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 425 Mobile IP. RFC 2356, June 1998. 427 [9] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor 428 discovery for IP Version 6 (IPv6), December 1998. Status: 429 DRAFT STANDARD. 431 [10] Charles E. Perkins and David B. Johnson. Route Optimization in 432 Mobile-IP. draft-ietf-mobileip-optim-08.txt, February 1999. 433 (work in progress). 435 [11] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 436 1996. 438 [12] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, 439 April 1992. 441 [13] W. Simpson. RFC 1994: PPP challenge handshake authentication 442 protocol (CHAP), August 1996. Obsoletes RFC1334. Status: DRAFT 443 STANDARD. 445 A. Verification Infrastructure 447 The Challenge extensions in this protocol specification are expected 448 to be useful to help the Foreign Agent manage connectivity for 449 visiting mobile nodes, even in situations where the foreign agent 450 does not have any security association with the mobile node or the 451 mobile node's home agent. In order to carry out the necessary 452 authentication, it is expected that the foreign agent will need the 453 assistance of external administrative systems, which recently have 454 come to be called AAA systems. For the purposes of this document, 455 we call the external administrative support the "verification 456 infrastructure". The verification infrastructure is described 457 to motivate the design of the protocol elements defined in this 458 document, and is not strictly needed for the protocol to work. The 459 foreign agent is free to use any means at its disposal to verify the 460 credentials of the mobile node. This could, for instance, rely on a 461 separate protocol between the foreign agent and the Mobile IP home 462 agent, and still be completely invisible to the mobile node. 464 In order to verify the credentials of the mobile node, we imagine 465 that the foreign agent has access to a verification infrastructure 466 that can return a secure notification to the foreign agent that 467 the authentication has been performed, along with the results of 468 that authentication. This infrastructure may be visualized as 469 shown in figure 5. For an example of another protocol that has 470 been specified to actually carry out the challenge verification 471 operations, see [2, 1]. 473 After the foreign agent gets the Challenge authentication, it MAY 474 pass the authentication to the (here unspecified) infrastructure, 475 and await a Registration Reply. If the Reply has a positive 476 status (indicating that the registration was accepted), the foreign 477 agent accepts the registration. If the Reply contains Code value 478 BAD_AUTHENTICATION (see Section 6), the foreign agent takes actions 479 indicated for rejected registrations. 481 Implicit in this picture, is the important observation that the 482 Foreign Agent and the Home Agent have to be equipped to make use 483 of whatever protocol is made available to them by the challenge 484 verification and key management infrastructure shown in the figure. 486 +----------------------------------------------------+ 487 | | 488 | Verification and Key Management Infrastructure | 489 | | 490 +----------------------------------------------------+ 491 ^ | ^ | 492 | | | | 493 | v | v 494 +---------------+ +---------------+ 495 | | | | 496 | Foreign Agent | | Home Agent | 497 | | | | 498 +---------------+ +---------------+ 500 Figure 5: The Verification Infrastructure 502 The protocol messages for handling the authentication within the 503 verification infrastructure, and identity of the agent performing the 504 verification of the Foreign Agent challenge, are not specified in 505 this document, because those operations do not have to be performed 506 by any Mobile IP entity. 508 Addresses 510 The working group can be contacted via the current chairs: 512 Basavaraj Patil Phil Roberts 513 Nortel Networks Inc. Motorola 514 2201 Lakeside Blvd. 1501 West Shure Drive 515 Richardson, TX. 75082-4399 Arlington Heights, IL 60004 516 USA USA 518 Phone: +1 972-684-1489 Phone: +1 847-632-3148 519 EMail: bpatil@nortelnetworks.com EMail: QA3445@email.mot.com 521 Questions about this memo can be directed to: 523 Charles E. Perkins Pat R. Calhoun 524 Nokia Research Center Sun Microsystems Laboratories 525 313 Fairchild Drive 15 Network Circle 526 Mountain View, California 94043 Menlo Park, California 94025 527 USA USA 529 Phone: +1-650 625-2986 Phone: +1 650-786-7733 530 EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com 531 Fax: +1 650 691-2170 Fax: +1 650-786-6445