idnits 2.17.1 draft-ietf-mobileip-challenge-01.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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 2 characters 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 121: '...ration Request, the Foreign Agent MUST...' RFC 2119 keyword, line 159: '...he Foreign Agent MUST NOT accept any C...' RFC 2119 keyword, line 173: '... Length MUST be at least 18...' RFC 2119 keyword, line 195: '... Length MUST be at least 16...' RFC 2119 keyword, line 202: '... The mobile node MUST include this ext...' (3 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) == Unused Reference: '3' is defined on line 268, but no explicit reference was found in the text == 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-00 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mn-nai-01 ** Obsolete normative reference: RFC 1970 (ref. '5') (Obsoleted by RFC 2461) ** Obsolete normative reference: RFC 2461 (ref. '6') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2002 (ref. '7') (Obsoleted by RFC 3220) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '8') Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Working Group Pat R. Calhoun 3 INTERNET DRAFT Sun Microsystems, Inc. 4 25 February 1999 Charles E. Perkins 5 Sun Microsystems, Inc. 7 Mobile IP Challenge/Response Extensions 8 draft-ietf-mobileip-challenge-01.txt 10 Status of This Memo 12 This document is a submission by the mobile-ip Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 to the mobile-ip@smallworks.com mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 35 http://www.ietf.org/shadow.html. 37 Abstract 39 Mobile IP, as originally specified, defined an authentication 40 extension (the Mobile-Foreign Authentication Extension) by which 41 a mobile node could authenticate itself to a foreign agent. 42 Unfortunately, this extension does not provide ironclad replay 43 protection, and worse yet does not conform to existing techniques 44 (such as CHAP) for authenticating transportable computer devices. 45 In this specification, we define extensions for the Mobile IP 46 Agent Advertisements and the Registration Request that allow use of 47 such challenge/response mechanisms for allowing a foreign agent to 48 authenticate the mobile node. 50 1. Introduction 52 In this document, we postulate that the foreign agent has access to 53 a verification infrastructure that can return a secure notification 54 to the foreign agent that the authentication has been performed, 55 along with the results of that authentication. This infrastructure 56 may be visualized as shown in figure 1. For an example of another 57 protocol that has been specified to actually carry out the key 58 creation and challenge verification operations, see [2, 1]. After 60 +----------------------------------------------------+ 61 | | 62 | Verification and Key Management Infrastructure | 63 | | 64 +----------------------------------------------------+ 65 ^ | ^ | 66 | | | | 67 | v | v 68 +---------------+ +---------------+ 69 | | | | 70 | Foreign Agent | | Home Agent | 71 | | | | 72 +---------------+ +---------------+ 74 Figure 1: The Verification Infrastructure 76 the foreign agent gets the Challenge Response, it passes the Response 77 along to the (here unspecified) infrastructure, and awaits a a 78 Registration Reply. If the reply has a positive status (indicating 79 that the registration was accepted), the foreign agent accepts the 80 registration. If the reply does not have a positive status code, 81 then the foreign agent assumes that the challenge did not pass 82 verification, for reasons that may or may not be specified by the 83 infrastructure agents. 85 Implicit in this picture, however, is the important observation that 86 the Foreign Agent and the Home Agent have to be equipped to make 87 use of whatever protocol is made available to them by the challenge 88 verification and key management infrastructure shown in the figure. 90 The protocol messages for handling the authentication within the 91 verification infrastructure, and identity of the agent performing the 92 verification of the Foreign Agent challenge, are not specified in 93 this document, because those operations do not have to be performed 94 by any Mobile IP entity. On the other hand, and consistent with the 95 figure, either the foreign agent or the home agent could perform the 96 verification if configured to do so. 98 1.1. Operation 100 This section describes the modifications to the Mobile IP 101 registration process which occur after the Foreign Agent issues a 102 Mobile IP Agent Advertisement containing the Challenge on its local 103 link, which is captured and processed by the mobile node. 105 1.2. Registration Request Generation 107 The mobile node extracts the Challenge from the advertisement and 108 computes the Mobile-Challenge-Response extension using the challenge 109 and the Registration Request message hashed with a secret which is 110 known within the verification infrastructure. The mobile node's 111 Registration Request is forwarded to the Foreign Agent and includes 112 the following extensions: 114 115 , if present 116 (see section 3.1) 117 , if present 118 (see section 3.2) 119 , if present 121 Upon receipt of the Registration Request, the Foreign Agent MUST 122 ensure that the Foreign-Agent-Challenge extension contains a 123 previously unused challenge value. This ensures that the mobile node 124 is not attempting to replay a previous Mobile-Challenge-Response. If 125 the Mobile-Challenge-Response extension is present in the message, 126 or if the Mobile-Node-NAI shows that it belongs to a different 127 administrative domain, the foreign agent forwards the Registration 128 Request to the verification infrastructure (see figure 1). 130 1.3. Registration Reply Processing 132 The following actions occur when the foreign agent receives a 133 Registration Reply containing the information pertinent to the 134 authentication of the Challenge Response computed by the mobile 135 node. It then validates the Foreign-Home Authentication extension 136 as specified in [7]. If the packet is successfully authenticated, 137 the Foreign Agent adds the Mobile-Foreign Authentication extension. 138 The Registration Reply message forwarded to the mobile node has the 139 following format: 141 142 143 , if present 145 2. Mobile IP Agent Discovery Extensions 147 This section will define a new extension to the Router Discovery 148 Protocol [4] for use by mobility agents that need to issue a 149 challenge for authenticating mobile nodes. A mobile node can assume 150 that the Foreign Agent supports this specification if the extensions 151 in this section are part of the Router Advertisements. 153 2.1. Challenge Extension 155 The Challenge Extension is inserted in the Agent Advertisements by 156 the Foreign Agent, in order to communicate the latest Challenge value 157 that can be used by the mobile node to compute a Challenge Response. 159 The Foreign Agent MUST NOT accept any Challenge in the Registration 160 Request unless it was advertised as one of the last two Challenge 161 values inserted into the immediately preceding Agent advertisements. 163 The Challenge Extension is defined as follows: 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Type | Length | Challenge ... 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Type TBD 173 Length MUST be at least 18 175 Challenge A random value of at least 128 bits. 177 3. Mobile IP Registration Extensions 179 This section specifies new Mobile IP Registration Extensions that are 180 used to satisfy a Challenge in an Agent Advertisement. 182 3.1. Foreign-Agent-Challenge Extension 184 The Foreign-Agent-Challenge extension is copied from the Challenge in 185 the Agent Advertisement. 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Type | Length | Challenge... 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Type TBD 195 Length MUST be at least 16 197 Challenge The Challenge field is copied from the Agent 198 Advertisement's Challenge. 200 3.2. Mobile-Challenge-Response Extension 202 The mobile node MUST include this extension in the Registration 203 Request if the foreign agent's advertisement contains the Challenge 204 Extension. 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Type | Length | SPI ... 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 ... SPI (cont.) | Authenticator 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Type TBD 216 Length 6 plus the number of bytes in the Authenticator; 217 MUST be at least 22. 219 SPI Security Parameters Index 221 Authenticator The Challenge field consists random value of at 222 least 128 bits. Variable length hash. 224 The authenticator is computed on the following data, in the order 225 shown: 227 Key || Preceding Mobile IP data || Type, Length, SPI || Key 229 where the Type, Length, and SPI are as shown above. Each mobile 230 node MUST support the ability to produce the authenticator by using 231 MD5 [8] on the specified data, which is known as "prefix+suffix" 232 mode. Just as with Mobile IP, MD5 in the prefix+suffix mode MUST be 233 able to be configured for selection at any arbitrary 32-bit SPI. 235 4. Security Considerations 237 In the event that a malicious mobile node attempts to replay an old 238 Foreign-Agent-Challenge and Mobile-Node-Response pair, the Foreign 239 Agent would detect it since the Foreign Agent would be able to verify 240 that it had not recently advertised the Challenge. 242 5. IPv6 Considerations 244 For use with IPv6 mobility, the challenge extension would have to be 245 applied to Router Advertisements [6]. In order to check the response 246 from the mobile node, the router would need to have a security 247 relationship with either the mobile node or its home agent. It is 248 not yet known which security model would be more appropriate, or 249 whether it would make the most sense to enable maximum flexibility by 250 specifying the protocol for both cases. 252 6. Acknowledgements 254 The authors would like to thank Tom Hiller, Mark Munson, the TIA 255 TR45-6 WG, Gabriel Montenegro and Vipul Gupta for their useful 256 discussions. 258 References 260 [1] P. Calhoun and C. E. Perkins. DIAMETER Mobile IP Extensions. 261 draft-calhoun-diameter-mobileip-01.txt, November 1998. (work in 262 progress). 264 [2] P. Calhoun and A. Rubens. DIAMETER Base Protocol. 265 draft-calhoun-diameter-00.txt, February 1998. (work in 266 progress). 268 [3] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network 269 Address Identifier Extension. draft-ietf-mobileip-mn-nai-01.txt, 270 February 1999. (work in progress). 272 [4] Stephen E. Deering, Editor. ICMP Router Discovery Messages. RFC 273 1256, September 1991. 275 [5] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 276 IP version 6 (IPv6). RFC 1970, August 1996. 278 [6] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor 279 discovery for IP Version 6 (IPv6), December 1998. Obsoletes 280 RFC1970 [5]. Status: DRAFT STANDARD. 282 [7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 283 1996. 285 [8] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, 286 April 1992. 288 Chairs' Addresses 290 The working group can be contacted via the current chairs: 292 Jim Solomon Erik Nordmark 293 Redback Networks, Inc. Sun Microsystems, Inc. 294 1301 E. Algonquin Road 17 Network Circle 295 Schaumburg, IL 60196 Menlo Park, California 94025 296 USA USA 298 Phone: +1-847-576-2753 Phone: +1 650 786-5166 299 Fax: Fax: +1 650 786-5896 300 E-mail: solomon@redbacknetworks.com E-mail: nordmark@sun.com 302 Author's Addresses 304 Questions about this memo can be directed to: 306 Pat R. Calhoun Charles E. Perkins 307 Sun Microsystems Laboratories Sun Microsystems Laboratories 308 15 Network Circle 15 Network Circle 309 Menlo Park, CA 94025 Menlo Park, CA 94025 310 USA USA 312 Phone: +1-650-786-7733 Phone: +1 650 786-6464 313 EMail: pat.calhoun@sun.com EMail: cperkins@eng.sun.com 314 Fax: +1 650 786-6445