idnits 2.17.1 draft-ietf-mobileip-gen-key-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: ---------------------------------------------------------------------------- ** 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 94: '... Mobile Node SPI field), and SHOULD be...' RFC 2119 keyword, line 177: '... Mobile Node SPI field), and SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 129 has weird spacing: '...Subtype a n...' == Line 210 has weird spacing: '...Subtype a n...' == Line 249 has weird spacing: '...Subtype a n...' == Line 287 has weird spacing: '...Subtype a n...' ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [1], but that reference does not seem to mention RFC 2119 either. -- 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 (-07) exists of draft-ietf-mobileip-mier-06 -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2002 (ref. '4') (Obsoleted by RFC 3220) == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-aaa-key-00 -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' Summary: 9 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 27 August 2001 Pat R. Calhoun 4 Sun Microsystems Laboratories 6 Generalized Key Distribution Extensions for Mobile IP 7 draft-ietf-mobileip-gen-key-01.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@sunroof.eng.sun.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 Recent proposals have suggested several kinds of key extensions for 36 Mobile IP registration messages. These keys may be used between 37 the mobile node and mobility agents, or between the mobility agents 38 themselves. This document specifies generalized extension formats 39 that can be useful for several kinds of key distributions. Each 40 generalized extension format will have subtypes which indicate the 41 specific format for the key distribution data. 43 1. Introduction 45 Recent proposals [5, 6] have suggested several kinds of key 46 extensions for Mobile IP [4] registration messages. These keys may 47 be used between the mobile node and mobility agents, or between the 48 mobility agents themselves. This document specifies generalized 49 extension formats that can be useful for several kinds of key 50 distributions. Each generalized extension format will have subtypes 51 which indicate the specific format for the key distribution data. 52 Each generalized format conforms to the overall format suggested for 53 generalized Mobile IP extensions recently described for MIER [2]. 55 Different generalized extensions are defined depending upon the 56 following factors: 58 - The intended use of the key 60 - Whether the extension requests a key or supplies a key 62 Extensions that request a key are allowable in Mobile IP Registration 63 Request messages. Extensions that supply key material are allowable 64 in Mobile IP Registration Reply messages. 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [1]. 70 2. Generalized MN-FA Key Request Extension 72 Figure 1 illustrates the Generalized MN-FA Key Request Extension. 74 0 1 2 3 75 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 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 | Type | Subtype | Length | 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 79 | Mobile Node SPI | 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 81 | MN-FA Key Request Subtype Data ... 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 Figure 1: The Generalized Mobile IP MN-FA Key Request Extension 86 Type TBD (not skippable) (see [4] and section 8) 87 Subtype a number assigned to identify the way in 88 which the Key Request Data is to be used when 89 generating the registration key 91 Length The 16-bit Length field indicates the length of 92 the extension. It is equal to the number of 93 bytes in the MN-FA Key Request Subtype Data plus 94 4 (for the Mobile Node SPI field), and SHOULD be 95 at least 20. 97 Mobile Node SPI The Security Parameters Index that the mobile 98 node will assign for the security association 99 created for use with the registration key. 101 MN-FA Key Request Subtype Data 102 Data needed to carry out the creation of the 103 registration key on behalf of the mobile node. 105 The Generalized MN-FA Key Request Extension defines a set of 106 extensions, identified by subtype, which may be used by a mobile node 107 in a Mobile IP Registration Request message to request that some 108 other entity create a key for use by the mobile node with the mobile 109 node's new foreign agent. 111 3. Generalized MN-FA Key Reply Extension 113 The Generalized MN-FA Key Reply extension supplies a registration key 114 requested by using one of the subtypes of the Generalized MN-FA Key 115 Request extension. Figure 2 illustrates the format Generalized MN-FA 116 Key Reply Extension. 118 0 1 2 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Type | Subtype | Length | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | MN-FA Key Reply Subtype Data ... 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 Figure 2: The Generalized Mobile IP MN-FA Key Reply Extension 128 Type TBD (not skippable) (see [4] and section 8) 129 Subtype a number assigned to identify the way in which the 130 MN-FA Key Reply Subtype Data is to be decrypted to 131 obtain the registration key 133 Length The 16-bit Length field is equal to the number of bytes 134 in the MN-FA Key Reply Subtype Data. 136 MN-FA Key Reply Subtype Data 137 An encoded copy of the key to be used between the 138 mobile node and the foreign agent, along with any other 139 information needed by the recipient to create the 140 designated Mobility Security Association. 142 For each subtype, the format of the MN-FA Key Reply Subtype Data has 143 to be separately defined according to the particular method required 144 to set up the security association. 146 In some cases, the MN-FA Key supplied in the data for a subtype of 147 this extension comes by a request which was sent using a subtype of 148 the Generalized MN-FA Key Request Extension. In that case, the SPI 149 to be used when employing the security association defined by the 150 registration key is the same as given in the original request. 152 4. Generalized MN-HA Key Request Extension 154 Figure 3 illustrates the Generalized MN-HA Key Request Extension. 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Type | Subtype | Length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Mobile Node SPI | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | MN-HA Key Request Subtype Data ... 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 3: The Generalized Mobile IP MN-HA Key Request Extension 168 Type TBD (not skippable) (see [4] and section 8) 170 Subtype a number assigned to identify the way in 171 which the Key Request Data is to be used when 172 generating the registration key 174 Length The 16-bit Length field indicates the length of 175 the extension. It is equal to the number of 176 bytes in the MN-HA Key Request Subtype Data plus 177 4 (for the Mobile Node SPI field), and SHOULD be 178 at least 20. 180 Mobile Node SPI The Security Parameters Index that the mobile 181 node will assign for the security association 182 created for use with the registration key. 184 MN-HA Key Request Subtype Data 185 Data needed to carry out the creation of the 186 registration key on behalf of the mobile node. 188 The Generalized MN-HA Key Request Extension defines a set of 189 extensions, identified by subtype, which may be used by a mobile node 190 in a Mobile IP Registration Request message to request that some 191 other entity create a key for use by the mobile node with the mobile 192 node's new home agent. 194 5. Generalized MN-HA Key Reply Extension 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Type | Subtype | Length | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Lifetime | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | MN-HA Key Reply Subtype Data ... 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 4: The Generalized Mobile IP MN-HA Key Reply Extension 208 Type TBD (not skippable) (see [4] and section 8) 210 Subtype a number assigned to identify the way in which the 211 MN-HA Key Reply Subtype Data is to be decrypted to 212 obtain the registration key 214 Length The 16-bit Length field indicates the length of the 215 extension. It is equal to the number of bytes in the 216 MN-HA Key Reply Subtype Data plus 4 (for the Lifetime 217 field). 219 Lifetime This field indicates the duration of time (in seconds) 220 for which the MN-HA key is valid. 222 MN-HA Key Reply Subtype Data 223 An encrypted copy of the key to be used between the 224 mobile node and its home agent, along with any other 225 information needed by the mobile node to create the 226 designated Mobility Security Association with the home 227 agent. 229 For each subtype, the format of the MN-HA Key Reply Subtype Data has 230 to be separately defined according to the particular method required 231 to set up the security association. 233 6. Generalized FA-HA Key Reply Extension 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type | Subtype | Length | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Lifetime | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | FA-HA Key Reply Subtype Data ... 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 5: The Generalized Mobile IP FA-HA Key Reply Extension 247 Type TBD (not skippable) (see [4] and section 8) 249 Subtype a number assigned to identify the way in which the 250 FA-HA Key Reply Subtype Data is to be decrypted to 251 obtain the registration key 253 Length The 16-bit Length field is equal to the number of bytes 254 in the FA-HA Key Reply Subtype Data plus 4 (for the 255 Lifetime field). 257 Lifetime This field indicates the duration of time (in seconds) 258 for which the FA-HA key is valid. 260 FA-HA Key Reply Subtype Data 261 An encrypted copy of the key to be used between the 262 foreign agent and the mobile node's home agent, along 263 with any other information needed by the foreign agent 264 to create the designated Mobility Security Association 265 with that home agent. 267 For each subtype, the format of the FA-HA Key Reply Subtype Data has 268 to be separately defined according to the particular method required 269 to set up the security association. 271 7. Generalized FA-FA Key Reply Extension 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type | Subtype | Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | FA-FA SPI | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | FA-FA Key Reply Subtype Data ... 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 6: The Generalized Mobile IP FA-FA Key Reply Extension 285 Type TBD (not skippable) (see [4] and section 8) 287 Subtype a number assigned to identify the way in which the 288 FA-FA Key Reply Subtype Data is to be decrypted to 289 obtain the registration key 291 Length The 16-bit Length field is equal to the number of bytes 292 in the FA-FA Key Reply Subtype Data plus 4 (for the 293 FA-FA SPI field). 295 FA-FA SPI This field indicates the SPI that should be used to 296 decipher the FA-FA key. 298 FA-FA Key Reply Subtype Data 299 An encrypted copy of the key to be used between two 300 foreign agents, along with any other information needed 301 by the foreign agents to create the desired security 302 association. 304 For each subtype, the format of the FA-FA Key Reply Subtype Data has 305 to be separately defined according to the particular method required 306 to set up the security association. 308 8. IANA Considerations 310 The numbers for the Generalized Key Extensions specified in 311 sections 2 through 7 are to be taken from the non-skippable range of 312 the Mobile IP registration extension namespace defined in [4]. 314 Section 2 introduces the Generalized MN-FA Key Request Extension 315 namespace that requires IANA management. All values other than zero 316 (0) are available for assignment via Standards Action [3]. 318 Section 3 introduces the Generalized MN-FA Key Reply Extension 319 namespace that requires IANA management. All values other than zero 320 (0) are available for assignment via Standards Action [3]. 322 Section 4 introduces the Generalized MN-HA Key Request Extension 323 namespace that requires IANA management. All values other than zero 324 (0) are available for assignment via Standards Action [3]. 326 Section 5 introduces the Generalized MN-HA Key Reply Extension 327 namespace that requires IANA management. All values other than zero 328 (0) are available for assignment via Standards Action [3]. 330 Section 6 introduces the Generalized FA-HA Key Reply Extension 331 namespace that requires IANA management. All values other than zero 332 (0) are available for assignment via Standards Action [3]. 334 Section 7 introduces the Generalized FA-FA Key Reply Extension 335 namespace that requires IANA management. All values other than zero 336 (0) are available for assignment via Standards Action [3]. 338 9. Security Considerations 340 The extensions in this document are intended to provide the 341 appropriate level of security for Mobile IP entities (mobile node, 342 foreign agent, and home agent) to operate Mobile IP registration 343 protocol. The security associations resulting from use of these 344 extensions do not offer any higher level of security than what is 345 already implicit in use of the security association between the 346 receiver and the entity distributing the key. 348 10. Acknowledgements 350 Thanks to Jouni Malinen and Madhavi Chandra for their careful review 351 and suggestions for improving this specification. 353 References 355 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 356 Levels. Request for Comments (Best Current Practice) 2119, 357 Internet Engineering Task Force, March 1997. 359 [2] M. Khalil, R. Narayanan, H. Akhtar, and E. Qaddoura. 360 Mobile IP Extensions Rationalization (MIER) (work in 361 progress). Internet Draft, Internet Engineering Task Force. 362 draft-ietf-mobileip-mier-06.txt, April 2001. 364 [3] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 365 Considerations Section in RFCs. Request for Comments (Best 366 Current Practice) 2434, Internet Engineering Task Force, October 367 1998. 369 [4] C. Perkins. IP Mobility Support. Request for Comments (Proposed 370 Standard) 2002, Internet Engineering Task Force, October 1996. 372 [5] C. Perkins and P. Calhoun. AAA Keys for Mobile IP (work in 373 progress). Internet Draft, Internet Engineering Task Force. 374 draft-ietf-mobileip-aaa-key-00.txt, July 2001. 376 [6] C. E. Perkins, D. Johnson, and N. Asokan. Registration Keys for 377 Route Optimization (work in progress). 378 draft-ietf-mobileip-regkey-03.txt, July 2000. 380 Addresses 382 The working group can be contacted via the current chairs: 383 Basavaraj Patil Phil Roberts 384 Nokia Megisto Corp. 385 6000 Connection Dr. Suite 120 386 20251 Century Blvd 387 Irving, TX. 75039 Germantown MD 20874 388 USA USA 389 Phone: +1 972-894-6709 Phone: +1 847-202-9314 390 Email: Basavaraj.Patil@nokia.com Email: PRoberts@MEGISTO.com 392 Questions about this memo can also be directed to the authors: 394 Charles E. Perkins Pat R. Calhoun 395 Communications Systems Lab 396 Nokia Research Center Black Storm Networks 397 313 Fairchild Drive 250 Cambridge Avenue, Suite 200 398 Mountain View, California 94043 Palo Alto, California, 94306 399 USA USA 400 Phone: +1-650 625-2986 Phone: +1 650-617-2932 401 EMail: charliep@iprg.nokia.com Email: pcalhoun@diameter.org 402 Fax: +1 650 625-2502 Fax: +1 650-786-6445