idnits 2.17.1 draft-ietf-mobileip-challenge-03.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 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** 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...' (30 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-02 ** 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') Summary: 12 errors (**), 0 flaws (~~), 6 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 September 1999 Pat R. Calhoun 4 Sun Microsystems Laboratories 6 Mobile IP Challenge/Response Extensions 7 draft-ietf-mobileip-challenge-03.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, and does not conform to existing techniques (such 40 as CHAP) for authenticating portable computer devices. In this 41 specification, we define extensions for the Mobile IP Agent 42 Advertisements and the Registration Request that allow a foreign 43 agent to use a challenge/response mechanism to authenticate the 44 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. In addition, the Mobile Node 115 SHOULD include the NAI extension [3], to enable the foreign agent 116 to make use of any available verification infrastructure. The 117 SPI field of the MN-AAA Authentication extension specifies the 118 particular secret and algorithm (shared between the Mobile Node and 119 the verification infrastructure) that must be used to perform the 120 authentication. 122 In either case, the MN-FA Challenge extension and one of the above 123 specified authentication extensions MUST follow the Mobile-Home 124 Authentication extension, if present. 126 3.2. Foreign Agent Processing for Registration Requests 128 Upon receipt of the Registration Request, if the Foreign Agent has 129 issued a Challenge as part of its Agent Advertisements, and it does 130 not have a security association with the mobile node, then the 131 Foreign Agent MUST check that the MN-FA Challenge extension exists, 132 and that it contains a challenge value previously unused by the 133 Mobile Node. This ensures that the mobile node is not attempting 134 to replay a previous advertisement and authentication. If the 135 challenge extension is needed and does not exist, the Foreign Agent 136 MUST send a Regstration Reply to the mobile node with the error code 137 MISSING_CHALLENGE. 139 If a mobile node retransmits a Registration Request with the same 140 Identification field and the same Challenge extension, and the 141 Foreign Agent still has a pending Registration Request record 142 in effect for the mobile node, then the Foreign Agent forwards 143 the Registration Request to the Home Agent again. In all other 144 circumstances, if the Foreign Agent receives a Registration 145 Request with a Challenge extension containing a Challenge value 146 previously used by that mobile node, the Foreign Agent SHOULD send 147 a Registration Reply to the mobile node containing the Code value 148 STALE_CHALLENGE. 150 The Foreign Agent MUST NOT accept any Challenge in the Registration 151 Request unless it was advertised as one of the last CHALLENGE_WINDOW 152 (see section 5) Challenge values inserted into the immediately 153 preceding Agent advertisements. If the Challenge is not one of 154 the recently advertised values, the foreign Agent SHOULD send a 155 Registration Reply with Code UNKNOWN_CHALLENGE (see section 6). 157 Furthermore, the Foreign Agent MUST check that there is either 158 a Mobile-Foreign or a MN-AAA Authentication extension after the 159 Challenge value. Any registration message containing the Challenge 160 value without either of these authentication extensions MUST 161 be silently discarded. If the registration message contains 162 a Mobile-Foreign Authentication extension with an incorrect 163 authenticator that fails verification, the Foreign Agent MAY 164 send a Registration Reply to the mobile node with Code value 165 BAD_AUTHENTICATION (see Section 6). 167 If the MN-AAA Authentication extension (see Section 4.2) is present 168 in the message, or if an NAI extension is included indicating that 169 the mobile node belongs to a different administrative domain, the 170 foreign agent may take actions outside the scope of this protocol 171 specification to carry out the authentication of the mobile node. 172 For instance, the foreign agent MAY forward the Registration Request 173 to the verification infrastructure (see figure 4 in the Appendix). 175 Since the Challenge extension, and the authentication extension that 176 is used by the Mobile Node to satisfy the challenge, both follow 177 the Mobile-Home Authentication extension whenever the latter is 178 present, the Foreign Agent MAY remove the Challenge Extension and 179 the applicable authentication from the Registration Request without 180 disturbing the authentication value computed by the Mobile Node for 181 use by the Home Agent. 183 If the Foreign Agent does not remove those extensions, then the 184 Foreign Agent SHOULD store the Challenge value as part of the pending 185 registration request list [11]. Also in this case, the Foreign Agent 186 MUST reject any Registration Reply message coming from the Home Agent 187 that does not also include the Challenge Extension with the same 188 Challenge Value that was included in the Registration Request. The 189 Foreign Agent MUST send the rejected Registration message to the 190 mobile node, and change the status in the Registration Reply to the 191 value MISSING_CHALLENGE (see section 6). 193 If the Foreign Agent does remove the Challenge extension and 194 applicable authentication from the Registration Request message, 195 then it SHOULD insert the Identification field from the Registration 196 Request message along with its record-keeping information about the 197 particular Mobile Node in order to protect against replays. 199 3.3. Home Agent Processing for the Challenge Extensions 201 If the Home Agent receives a Registration Request with the MN-FA 202 Challenge extension, and recognizes the extension, the Home Agent 203 MUST include the Challenge extension in the Registration Reply. 204 The Challenge Extension SHOULD be included before the Mobile-Home 205 Authentication extension. 207 Since the extension type for the Challenge extension is within the 208 range 128-255, the Home Agent MUST process such a Registration 209 Request even if it does not recognize the Challenge extension [11]. 210 In this case, the Home Agent will send a Registration Reply to the 211 Foreign Agent that does not include the Challenge extension. 213 4. Mobile IP Registration Extensions 215 This section specifies new Mobile IP Registration Extensions that are 216 used to satisfy a Challenge in an Agent Advertisement. 218 4.1. MN-FA Challenge Extension 220 The Challenge extension to the Registration Request message is used 221 to indicate the challenge that the mobile node is attempting to 222 satisfy. 224 Type 132 (skippable) (see [11]) 226 Length MUST be at least 16 228 Challenge The Challenge field is copied from the Challenge field 229 found in the Agent Advertisement Challenge extension 230 (see section 2). 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Type | Length | Challenge... 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 2: The MN-FA Challenge Extension 240 4.2. MN-AAA Authentication Extension 242 The mobile node MAY include this extension in the Registration 243 Request. If the mobile node does not include a Mobile-Foreign 244 Authentication extension, then it MUST include the MN-AAA 245 Authentication extension. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type | Length | SPI ... 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 ... SPI (cont.) | Authenticator 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 3: The MN-AAA Authentication Extension 257 Type 36 (not skippable) (see [11]) 259 Length 4 plus the number of bytes in the Authenticator; 260 MUST be at least 20. 262 SPI Security Parameters Index 264 Authenticator The variable length Authenticator field consists 265 random value of at least 128 bits. 267 The default algorithm for computation of the authenticator is 268 MD5 [12] computed on the following data, in the order shown: 270 Key || Preceding Mobile IP data || Type, Length, SPI || Key 272 where the Type, Length, and SPI are as shown above. Each mobile node 273 MUST support the ability to produce the authenticator by using MD5 as 274 shown (known as "prefix+suffix" mode). Just as with Mobile IP, MD5 275 in the prefix+suffix mode MUST be able to be configured for selection 276 at any arbitrary 32-bit SPI. 278 5. Configurable Parameters 280 Every Mobile IP agent supporting the extensions defined in this 281 document SHOULD be able to configure each parameter in the following 282 table. Each table entry contains the name of the parameter, the 283 default value, and the section of the document in which the parameter 284 first appears. 286 Parameter Name Default Value Section of Document 287 -------------- ------------- ------------------- 288 CHALLENGE_WINDOW 2 3.2 290 6. Error Values 292 Each entry in the following table contains the name of Code [11] to 293 be returned in a Registration Reply, the value for the Code, and the 294 section in which the error is first mentioned in this specification. 296 Error Name Value Section of Document 297 ---------------------- ----- ------------------- 298 UNKNOWN_CHALLENGE 104 3.2 299 BAD_AUTHENTICATION 67 3.2; also see [11] 300 MISSING_CHALLENGE 105 3.2 301 STALE_CHALLENGE 106 3.2 303 7. IANA Considerations 305 The number for the Mobile IP Agent Advertisement Challenge extension 306 (section 2) is taken from the numbering space defined for Mobile 307 IP extensions to the ICMP Router Advertisements [4] defined in 308 RFC 2002 [11]. The number for the MN-FA Challenge extension 309 (section 4.1) and the MN-AAA Authentication extension (section 4.2) 310 is taken from the numbering space defined for Mobile IP registration 311 extensions defined in RFC 2002 [11] as extended in RFC 2356 [8]. 312 The numbering for the extensions SHOULD NOT conflict with values 313 specified in the Internet Draft for Route Optimization [10] or 314 the Internet Draft for the Mobile IP Network Address Identifier 315 Extension. The Code values specified for errors, listed in 316 section 6, MUST NOT conflict with any other code values listed in 317 RFC 2002, RFC 2344 [7], or RFC 2356 [8], or the abovementioned 318 Internet Drafts. They are to be taken from the space of error values 319 conventionally associated with rejection by the foreign agent (i.e., 320 64-127). 322 8. Security Considerations 324 In the event that a malicious mobile node attempts to replay the 325 authenticator for an old MN-FA Challenge, the Foreign Agent would 326 detect it since the agent always checks whether it has recently 327 advertised the Challenge (see section 3.2). Allowing mobile nodes 328 with different IP addresses or NAIs to use the same Challenge 329 value does not represent a security vulnerability, because the 330 authentication data provided by the mobile node will be computed over 331 data that is different (at least by the bytes of the mobile nodes' IP 332 addresses). 334 9. IPv6 Considerations 336 For use with IPv6 mobility [6], the challenge extension should be 337 applied to Router Advertisements [9]. In order to check the response 338 from the mobile node, the router would need to have a security 339 relationship with either the mobile node, its home agent, or another 340 entity within the IPv6 security infrastructure. It is not yet known 341 which security model would be more appropriate, or whether it would 342 make the most sense to enable maximum flexibility by specifying the 343 protocol for each case. 345 10. Acknowledgements 347 The authors would like to thank Tom Hiller, Mark Munson, the TIA 348 TR45-6 WG, Gabriel Montenegro and Vipul Gupta for their useful 349 discussions. 351 References 353 [1] P. Calhoun and C. E. Perkins. DIAMETER Mobile IP Extensions. 354 draft-calhoun-diameter-mobileip-01.txt, November 1998. (work in 355 progress). 357 [2] P. Calhoun and A. Rubens. DIAMETER Base Protocol. 358 draft-calhoun-diameter-07.txt, November 1998. (work in 359 progress). 361 [3] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network 362 Address Identifier Extension. draft-ietf-mobileip-mn-nai-02.txt, 363 May 1999. (work in progress). 365 [4] Stephen E. Deering, Editor. ICMP Router Discovery Messages. 366 RFC 1256, September 1991. 368 [5] Donald E. Eastlake, Stephen D. Crocker, and Jeffrey I. Schiller. 369 Randomness Recommendations for Security. RFC 1750, December 370 1994. 372 [6] D. Johnson and C. Perkins. Mobility Support in IPv6. 373 draft-ietf-mobileip-ipv6-07.txt, November 1998. (work in 374 progress). 376 [7] G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, May 377 1998. 379 [8] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 380 Mobile IP. RFC 2356, June 1998. 382 [9] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor 383 discovery for IP Version 6 (IPv6), December 1998. Status: 384 DRAFT STANDARD. 386 [10] Charles E. Perkins and David B. Johnson. Route Optimization in 387 Mobile-IP. draft-ietf-mobileip-optim-08.txt, February 1999. 388 (work in progress). 390 [11] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 391 1996. 393 [12] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, 394 April 1992. 396 A. Verification Infrastructure 398 The Challenge extensions in this protocol specification are expected 399 to be useful to help the Foreign Agent manage connectivity for 400 visiting mobile nodes, even in situations where the foreign agent 401 does not have any security association with the mobile node or the 402 mobile node's home agent. In order to carry out the necessary 403 authentication, it is expected that the foreign agent will need the 404 assistance of external administrative systems, which recently have 405 come to be called AAA systems. For the purposes of this document, 406 we call the external administrative support the "verification 407 infrastructure". The verification infrastructure is described 408 to motivate the design of the protocol elements defined in this 409 document, and is not strictly needed for the protocol to work. The 410 foreign agent is free to use any means at its disposal to verify the 411 credentials of the mobile node. This could, for instance, rely on a 412 separate protocol between the foreign agent and the Mobile IP home 413 agent, and still be completely invisible to the mobile node. 415 In order to verify the credentials of the mobile node, we imagine 416 that the foreign agent has access to a verification infrastructure 417 that can return a secure notification to the foreign agent that 418 the authentication has been performed, along with the results of 419 that authentication. This infrastructure may be visualized as 420 shown in figure 4. For an example of another protocol that has 421 been specified to actually carry out the challenge verification 422 operations, see [2, 1]. 424 +----------------------------------------------------+ 425 | | 426 | Verification and Key Management Infrastructure | 427 | | 428 +----------------------------------------------------+ 429 ^ | ^ | 430 | | | | 431 | v | v 432 +---------------+ +---------------+ 433 | | | | 434 | Foreign Agent | | Home Agent | 435 | | | | 436 +---------------+ +---------------+ 438 Figure 4: The Verification Infrastructure 440 After the foreign agent gets the Challenge authentication, it MAY 441 pass the authentication to the (here unspecified) infrastructure, 442 and await a Registration Reply. If the Reply has a positive 443 status (indicating that the registration was accepted), the foreign 444 agent accepts the registration. If the Reply contains Code value 445 BAD_AUTHENTICATION (see Section 6), the foreign agent takes actions 446 indicated for rejected registrations. 448 Implicit in this picture, is the important observation that the 449 Foreign Agent and the Home Agent have to be equipped to make use 450 of whatever protocol is made available to them by the challenge 451 verification and key management infrastructure shown in the figure. 453 The protocol messages for handling the authentication within the 454 verification infrastructure, and identity of the agent performing the 455 verification of the Foreign Agent challenge, are not specified in 456 this document, because those operations do not have to be performed 457 by any Mobile IP entity. 459 Addresses 461 The working group can be contacted via the current chairs: 463 Basavaraj Patil Phil Roberts 464 Nortel Networks Inc. Motorola 465 2201 Lakeside Blvd. 1501 West Shure Drive 466 Richardson, TX. 75082-4399 Arlington Heights, IL 60004 467 USA USA 469 Phone: +1 972-684-1489 Phone: +1 847-632-3148 470 EMail: bpatil@nortelnetworks.com EMail: QA3445@email.mot.com 472 Questions about this memo can be directed to: 474 Charles E. Perkins Pat R. Calhoun 475 Nokia Research Center Sun Microsystems Laboratories 476 313 Fairchild Drive 15 Network Circle 477 Mountain View, California 94043 Menlo Park, California 94025 478 USA USA 480 Phone: +1-650 625-2986 Phone: +1 650-786-7733 481 EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com 482 Fax: +1 650 691-2170 Fax: +1 650-786-6445