idnits 2.17.1 draft-ietf-mobileip-challenge-02.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 11 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. ** 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 76: '... Length MUST be at least 16...' RFC 2119 keyword, line 100: '...n Agent, then it MUST include the Chal...' RFC 2119 keyword, line 103: '...oreign agent, it MAY include the Chall...' RFC 2119 keyword, line 107: '... it MUST include a Mobile-Foreign Au...' RFC 2119 keyword, line 110: '...Foreign Authentication MUST follow the...' (28 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: 13 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 Sun Microsystems Laboratories 3 25 May 1999 Pat R. Calhoun 4 Sun Microsystems Laboratories 6 Mobile IP Challenge/Response Extensions 7 draft-ietf-mobileip-challenge-02.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 31 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 Abstract 36 Mobile IP, as originally specified, defines an authentication 37 extension (the Mobile-Foreign Authentication extension) by 38 which a mobile node can authenticate itself to a foreign agent. 39 Unfortunately, this extension does not provide ironclad replay 40 protection, and does not conform to existing techniques (such 41 as CHAP) for authenticating portable computer devices. In this 42 specification, we define extensions for the Mobile IP Agent 43 Advertisements and the Registration Request that allow a foreign 44 agent to use a challenge/response mechanism to authenticate the 45 mobile node. 47 1. Introduction 49 Mobile IP, as originally specified, defines an authentication 50 extension (the Mobile-Foreign Authentication extension) by 51 which a mobile node can authenticate itself to a foreign agent. 52 Unfortunately, this extension does not provide ironclad replay 53 protection, and does not conform to existing techniques (such 54 as CHAP) for authenticating portable computer devices. In this 55 specification, we define extensions for the Mobile IP Agent 56 Advertisements and the Registration Request that allow a foreign 57 agent to a use challenge/response mechanism to authenticate the 58 mobile node. 60 2. Mobile IP Agent Advertisement Challenge Extension 62 This section defines a new extension to the Router Discovery 63 Protocol [4] for use by foreign agents that need to issue a challenge 64 for authenticating mobile nodes. 66 0 1 2 3 67 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 68 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 69 | Type | Length | Challenge ... 70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 72 Figure 1: The Challenge Extension 74 Type 24 76 Length MUST be at least 16 78 Challenge A random value of at least 128 bits. 80 The Challenge extension, illustrated in figure 1, is inserted 81 in the Agent Advertisements by the Foreign Agent, in order to 82 communicate the latest challenge value that can be used by the mobile 83 node to compute an authentication for its registration request 84 message. The challenge is selected by the foreign agent to provide 85 local assurance that the mobile node is not replaying any earlier 86 registration request. Eastlake, et al. [5] provides more information 87 on generating pseudo-random numbers suitable for use as values for 88 the challenge. 90 3. Operation 92 This section describes modifications to the Mobile IP registration 93 process which may occur after the Foreign Agent issues a Mobile IP 94 Agent Advertisement containing the Challenge on its local link. 96 3.1. Mobile Node Processing for Registration Requests 98 Whenever the Agent Advertisement contains the Challenge extension, 99 if the mobile node does not have a security association with the 100 Foreign Agent, then it MUST include the Challenge value in a MN-FA 101 Challenge extension to the Registration Request message. If, on the 102 other hand, the mobile node does have a security association with the 103 foreign agent, it MAY include the Challenge value in its Registration 104 Request message. 106 If the Mobile Node has a security association with the Foreign Agent, 107 it MUST include a Mobile-Foreign Authentication extension in its 108 Registration Request message, according to RFC 2002 [11]. When the 109 Registration Request contains the MN-FA Challenge extension specified 110 in section 4, the Mobile-Foreign Authentication MUST follow the 111 Challenge extension in the Registration Request. 113 If the Mobile Node does not have a security association with 114 the Foreign Agent, the Mobile Node SHOULD include the MN-AAA 115 Authentication extension as defined in section 4.2. In addition, 116 the Mobile Node SHOULD include the NAI extension [3], to enable 117 the foreign agent to make use of any available verification 118 infrastructure. The SPI field of the MN-AAA Authentication extension 119 specifies the particular secret and algorithm (shared between the 120 Mobile Node and the verification infrastructure) that must be used to 121 perform the authentication. 123 In either case, the MN-FA Challenge extension and one of the above 124 specified authentication extensions MUST follow the Mobile-Home 125 Authentication extension, if present. 127 3.2. Foreign Agent Processing for Registration Requests 129 Upon receipt of the Registration Request, if the Foreign Agent has 130 issued a Challenge as part of its Agent Advertisements, and it 131 does not have a security association with mobile node, then the 132 Foreign Agent MUST check that the MN-FA Challenge extension contains 133 a challenge value previously unused by the Mobile Node. This 134 ensures that the mobile node is not attempting to replay a previous 135 advertisement and authentication. 137 The Foreign Agent MUST NOT accept any Challenge in the Registration 138 Request unless it was advertised as one of the last CHALLENGE_WINDOW 139 (see section 5) Challenge values inserted into the immediately 140 preceding Agent advertisements. If the Challenge is not one of 141 the recently advertised values, the foreign Agent SHOULD send a 142 Registration Reply with Code UNKNOWN_CHALLENGE (see section 6). 144 Furthermore, the Foreign Agent MUST check that there is either 145 a Mobile-Foreign or a MN-AAA Authentication extension after the 146 Challenge value. Any registration message containing the Challenge 147 value without either of these authentication extensions MUST 148 be silently discarded. If the registration message contains 149 a Mobile-Foreign Authentication extension with an incorrect 150 authenticator that fails verification, the Foreign Agent MAY 151 send a Registration Reply to the mobile node with Code value 152 BAD_AUTHENTICATION (see Section 6). 154 If the MN-AAA Authentication extension (see Section 4.2) is present 155 in the message, or if an NAI extension is included indicating that 156 the mobile node belongs to a different administrative domain, the 157 foreign agent may take actions outside the scope of this protocol 158 specification to carry out the authentication of the mobile node. 159 For instance, the foreign agent MAY forward the Registration Request 160 to the verification infrastructure (see figure 4 in the Appendix). 162 Since the Challenge extension, and the authentication extension that 163 is used by the Mobile Node to satisfy the challenge, both follow 164 the Mobile-Home Authentication extension whenever the latter is 165 present, the Foreign Agent MAY remove the Challenge Extension and 166 the applicable authentication from the Registration Request without 167 disturbing the authentication value computed by the Mobile Node for 168 use by the Home Agent. 170 If the Foreign Agent does not remove those extensions, then the 171 Foreign Agent SHOULD store the Challenge value as part of the pending 172 registration request list [11]. In this case, the Foreign Agent MUST 173 reject any Registration Reply message coming from the Home Agent 174 that does not also include the Challenge Extension. The Foreign 175 Agent MUST send the rejected Registration message to the mobile 176 node, and change the status in the Registration Reply to the value 177 MISSING_CHALLENGE (see section 6). 179 If the Foreign Agent does remove the Challenge extension and 180 applicable authentication from the Registration Request message, 181 then it SHOULD insert the Identification field from the Registration 182 Request message along with its record-keeping information about the 183 particular Mobile Node in order to protect against replays. 185 3.3. Home Agent Processing for the Challenge Extensions 187 If the Home Agent receives a Registration Request with the MN-FA 188 Challenge extension, and recognizes the extension, the Home Agent 189 MUST include the Challenge extension in the Registration Reply. 190 The Challenge Extension SHOULD be included before the Mobile-Home 191 Authentication extension. 193 Since the extension type for the Challenge extension is within the 194 range 128-255, the Home Agent MUST process such a Registration 195 Request even if it does not recognize the Challenge extension [11]. 196 In this case, the Home Agent will send a Registration Reply to the 197 Foreign Agent that does not include the Challenge extension. 199 4. Mobile IP Registration Extensions 201 This section specifies new Mobile IP Registration Extensions that are 202 used to satisfy a Challenge in an Agent Advertisement. 204 4.1. MN-FA Challenge Extension 206 The Challenge extension to the Registration Request message is used 207 to indicate the challenge that the mobile node is attempting to 208 satisfy. 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Type | Length | Challenge... 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Figure 2: The MN-FA Challenge Extension 218 Type 132 (skippable) [11] 220 Length MUST be at least 16 222 Challenge The Challenge field is copied from the Challenge field 223 found in the Agent Advertisement Challenge extension 224 (see section 2). 226 4.2. MN-AAA Authentication Extension 228 The mobile node MAY include this extension in the Registration 229 Request if the foreign agent's advertisement contains the Challenge 230 Extension. If the mobile node does not include a Mobile-Foreign 231 Authentication extension, then it SHOULD include the MN-AAA 232 Authentication extension. 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Type | Length | SPI ... 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 ... SPI (cont.) | Authenticator 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 3: The MN-AAA Authentication Extension 244 Type 36 (not skippable) [11] 246 Length 4 plus the number of bytes in the Authenticator; 247 MUST be at least 20. 249 SPI Security Parameters Index 251 Authenticator The variable length Authenticator field consists 252 random value of at least 128 bits. 254 The default algorithm for computation of the authenticator is 255 MD5 [12] computed on the following data, in the order shown: 257 Key || Preceding Mobile IP data || Type, Length, SPI || Key 259 where the Type, Length, and SPI are as shown above. Each mobile node 260 MUST support the ability to produce the authenticator by using MD5 as 261 shown (known as "prefix+suffix" mode). Just as with Mobile IP, MD5 262 in the prefix+suffix mode MUST be able to be configured for selection 263 at any arbitrary 32-bit SPI. 265 5. Configurable Parameters 267 Every implementation of the Mobile IP agent supporting the extensions 268 defined in this document SHOULD be able to configure each parameter 269 in the following table. Each table entry contains the name of the 270 parameter, the default value, and the section of the document in 271 which the parameter first appears. 273 Parameter Name Default Value Section of Document 274 -------------- ------------- ------------------- 275 CHALLENGE_WINDOW 2 3.2 277 6. Error Values 279 Each entry in the following table contains the name of Code [11] to 280 be returned in a Registration Reply, the value for the Code, and the 281 section in which the error is first mentioned in this specification. 283 Error Name Value Section 284 ---------------------- ----- ------------------- 285 UNKNOWN_CHALLENGE 104 3.2 286 BAD_AUTHENTICATION 67 3.2; also see [11] 287 MISSING_CHALLENGE 105 3.2 289 7. IANA Considerations 291 The number for the Mobile IP Agent Advertisement Challenge extension 292 (section 2) is taken from the numbering space defined for Mobile 293 IP extensions to the ICMP Router Advertisements [4] defined in 294 RFC 2002 [11]. The number for the MN-FA Challenge extension 295 (section 4.1) and the MN-AAA Authentication extension (section 4.2) 296 is taken from the numbering space defined for Mobile IP registration 297 extensions defined in RFC 2002 [11] as extended in RFC 2356 [8]. 298 The numbering for the extensions SHOULD NOT conflict with values 299 specified in the Internet Draft for Route Optimization [10] or 300 the Internet Draft for the Mobile IP Network Address Identifier 301 Extension. The Code values specified for errors, listed in 302 section 6, MUST NOT conflict with any other code values listed in 303 RFC 2002, RFC 2344 [7], or RFC 2356 [8], or the abovementioned 304 Internet Drafts. They are to be taken from the space of error values 305 conventionally associated with rejection by the foreign agent (i.e., 306 64-127). 308 8. Security Considerations 310 In the event that a malicious mobile node attempts to replay the 311 authenticator for an old MN-FA Challenge, the Foreign Agent would 312 detect it since the agent always checks whether it has recently 313 advertised the Challenge (see section 3.2). 315 9. IPv6 Considerations 317 For use with IPv6 mobility [6], the challenge extension should be 318 applied to Router Advertisements [9]. In order to check the response 319 from the mobile node, the router would need to have a security 320 relationship with either the mobile node, its home agent, or another 321 entity within the IPv6 security infrastructure. It is not yet known 322 which security model would be more appropriate, or whether it would 323 make the most sense to enable maximum flexibility by specifying the 324 protocol for both cases. 326 10. Acknowledgements 328 The authors would like to thank Tom Hiller, Mark Munson, the TIA 329 TR45-6 WG, Gabriel Montenegro and Vipul Gupta for their useful 330 discussions. 332 References 334 [1] P. Calhoun and C. E. Perkins. DIAMETER Mobile IP Extensions. 335 draft-calhoun-diameter-mobileip-01.txt, November 1998. (work in 336 progress). 338 [2] P. Calhoun and A. Rubens. DIAMETER Base Protocol. 339 draft-calhoun-diameter-07.txt, November 1998. (work in 340 progress). 342 [3] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network 343 Address Identifier Extension. draft-ietf-mobileip-mn-nai-02.txt, 344 May 1999. (work in progress). 346 [4] Stephen E. Deering, Editor. ICMP Router Discovery Messages. 347 RFC 1256, September 1991. 349 [5] Donald E. Eastlake, Stephen D. Crocker, and Jeffrey I. Schiller. 350 Randomness Recommendations for Security. RFC 1750, December 351 1994. 353 [6] D. Johnson and C. Perkins. Mobility Support in IPv6. 354 draft-ietf-mobileip-ipv6-07.txt, November 1998. (work in 355 progress). 357 [7] G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, May 358 1998. 360 [8] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 361 Mobile IP. RFC 2356, June 1998. 363 [9] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor 364 discovery for IP Version 6 (IPv6), December 1998. Status: 365 DRAFT STANDARD. 367 [10] Charles E. Perkins and David B. Johnson. Route Optimization in 368 Mobile-IP. draft-ietf-mobileip-optim-08.txt, February 1999. 369 (work in progress). 371 [11] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 372 1996. 374 [12] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, 375 April 1992. 377 A. Verification Infrastructure 379 The Challenge extensions in this protocol specification are expected 380 to be useful to help the Foreign Agent manage connectivity for 381 visiting mobile nodes, even in situations where the foreign agent 382 does not have any security association with the mobile node or the 383 mobile node's home agent. In order to carry out the necessary 384 authentication, it is expected that the foreign agent will need the 385 assistance of external administrative systems, which recently have 386 come to be called AAA systems. For the purposes of this document, 387 we call the external administrative support the "verification 388 infrastructure". The verification infrastructure is described 389 to motivate the design of the protocol elements defined in this 390 document, and is not strictly needed for the protocol to work. The 391 foreign agent is free to use any means at its disposal to verify the 392 credentials of the mobile node. This could, for instance, rely on a 393 separate protocol between the foreign agent and the Mobile IP home 394 agent, and still be completely invisible to the mobile node. 396 In order to verify the credentials of the mobile node, we imagine 397 that the foreign agent has access to a verification infrastructure 398 that can return a secure notification to the foreign agent that 399 the authentication has been performed, along with the results of 400 that authentication. This infrastructure may be visualized as 401 shown in figure 4. For an example of another protocol that has 402 been specified to actually carry out the challenge verification 403 operations, see [2, 1]. 405 +----------------------------------------------------+ 406 | | 407 | Verification and Key Management Infrastructure | 408 | | 409 +----------------------------------------------------+ 410 ^ | ^ | 411 | | | | 412 | v | v 413 +---------------+ +---------------+ 414 | | | | 415 | Foreign Agent | | Home Agent | 416 | | | | 417 +---------------+ +---------------+ 419 Figure 4: The Verification Infrastructure 421 After the foreign agent gets the Challenge authentication, it MAY 422 pass the authentication to the (here unspecified) infrastructure, 423 and await a Registration Reply. If the Reply has a positive 424 status (indicating that the registration was accepted), the foreign 425 agent accepts the registration. If the Reply contains Code value 426 BAD_AUTHENTICATION (see Section 6), the foreign agent takes actions 427 indicated for rejected registrations. 429 Implicit in this picture, is the important observation that the 430 Foreign Agent and the Home Agent have to be equipped to make use 431 of whatever protocol is made available to them by the challenge 432 verification and key management infrastructure shown in the figure. 434 The protocol messages for handling the authentication within the 435 verification infrastructure, and identity of the agent performing the 436 verification of the Foreign Agent challenge, are not specified in 437 this document, because those operations do not have to be performed 438 by any Mobile IP entity. 440 Addresses 442 The working group can be contacted via the current chairs: 444 Erik Nordmark Basavaraj Patil 445 Sun Microsystems, Inc. Nortel Networks Inc. 446 17 Network Circle 2201 Lakeside Blvd. 447 Menlo Park, California 94025 Richardson, TX. 75082-4399 448 USA USA 450 Phone: +1 650 786-5166 +1 972-684-1489 451 Fax: +1 650 786-5896 452 E-mail: nordmark@sun.com bpatil@nortelnetworks.com 454 Questions about this memo can be directed to: 456 Charles E. Perkins Pat R. Calhoun 457 Sun Microsystems Laboratories Sun Microsystems Laboratories 458 15 Network Circle 15 Network Circle 459 Menlo Park, California 94025 Menlo Park, California 94025 460 USA USA 462 Phone: +1-650 786-6464 Phone: +1 650-786-7733 463 EMail: cperkins@eng.sun.com EMail: pcalhoun@eng.sun.com 464 Fax: +1 650 786-6445