idnits 2.17.1 draft-ietf-mobileip-gen-key-00.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 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 85: '... Data; SHOULD be at least 20...' RFC 2119 keyword, line 170: '... Data; SHOULD be at least 20...' 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) -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-07) exists of draft-ietf-mobileip-mier-06 -- Possible downref: Normative reference to a draft: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '3') ** 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: 8 errors (**), 0 flaws (~~), 3 warnings (==), 6 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 2 July 2001 Pat R. Calhoun 4 Sun Microsystems Laboratories 6 Generalized Key Distribution Extensions for Mobile IP 7 draft-ietf-mobileip-gen-key-00.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, 1, 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 2. Generalized MN-FA Key Request Extension 64 Figure 1 illustrates the Generalized MN-FA Key Request Extension. 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 | Subtype | Length | 70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 71 | Mobile Node SPI | 72 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 73 | MN-FA Key Request Subtype Data ... 74 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 76 Figure 1: The Generalized Mobile IP MN-FA Key Request Extension 78 Type 40 (not skippable) (see [4]) 80 Subtype a number assigned to identify the way in 81 which the Key Request Data is to be used 82 when generating the registration key 84 Length 4 plus the number of bytes in the Subtype 85 Data; SHOULD be at least 20. 87 Mobile Node SPI The Security Parameters Index that the 88 mobile node will assign for the security 89 association created for use with the 90 registration key. 92 MN-FA Key Request Subtype Data 93 Data needed to carry out the creation of the 94 registration key on behalf of the mobile 95 node. 97 The Generalized MN-FA Key Request Extension defines a set of 98 extensions, identified by subtype, which may be used by a mobile node 99 in a Mobile IP Registration Request message to request that some 100 other entity create a key for use by the mobile node with the mobile 101 node's new foreign agent. 103 3. Generalized MN-FA Key Reply Extension 105 The Generalized MN-FA Key Reply extension supplies a registration key 106 requested by using one of the subtypes of the Generalized MN-FA Key 107 Request extension. Figure 2 illustrates the format Generalized MN-FA 108 Key Reply Extension. 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Type | Subtype | Length | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Key Reply Subtype Data ... 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Figure 2: The Generalized Mobile IP MN-FA Key Reply Extension 120 Type 41 (not skippable) (see [4]) 122 Subtype a number assigned to identify the way in which 123 the Encoded MN-FA Key Data is to be decrypted to 124 obtain the registration key 126 Length The 16-bit Length field indicates the length of 127 the extension. It is equal to 4 plus the number 128 of bytes in the Encoded MN-FA Key Data. 130 MN-FA Key Reply Subtype Data 131 An encoded copy of the key to be used between the 132 mobile node and the foreign agent, along with 133 any other information needed by the recipient 134 to create the designated Mobility Security 135 Association. 137 For each subtype, the format of the MN-FA Key Reply Subtype Data has 138 to be separately defined according to the particular method required 139 to set up the security association. 141 In some cases, the MN-FA Key supplied in the data for a subtype of 142 this extension comes by a request which was sent using a subtype of 143 the Generalized MN-FA Key Request Extension. In that case, the SPI 144 to be used when employing the security association defined by the 145 registration key is the same as given in the original request. 147 4. Generalized MN-HA Key Request Extension 149 Figure 3 illustrates the Generalized MN-HA Key Request Extension. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Type | Subtype | Length | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Mobile Node SPI | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | MN-HA Key Request Subtype Data ... 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 3: The Generalized Mobile IP MN-HA Key Request Extension 163 Type 42 (not skippable) (see [4]) 165 Subtype a number assigned to identify the way in 166 which the Key Request Data is to be used 167 when generating the registration key 169 Length 4 plus the number of bytes in the Subtype 170 Data; SHOULD be at least 20. 172 Mobile Node SPI The Security Parameters Index that the 173 mobile node will assign for the security 174 association created for use with the 175 registration key. 177 MN-HA Key Request Subtype Data 178 Data needed to carry out the creation of the 179 registration key on behalf of the mobile 180 node. 182 The Generalized MN-HA Key Request Extension defines a set of 183 extensions, identified by subtype, which may be used by a mobile node 184 in a Mobile IP Registration Request message to request that some 185 other entity create a key for use by the mobile node with the mobile 186 node's new home agent. 188 5. Generalized MN-HA Key Reply Extension 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Type | Subtype | Length | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Lifetime | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | MN-HA Key Reply Subtype Data ... 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Figure 4: The Generalized Mobile IP MN-HA Key Reply Extension 202 Type 43 (not skippable) (see [4]) 204 Subtype a number assigned to identify the way in which 205 the Encoded MN-HA Key Data is to be decrypted to 206 obtain the registration key 208 Length The 16-bit Length field indicates the length of 209 the extension. It is equal to 4 plus the number 210 of bytes in the Encoded MN-HA Key Data. 212 Lifetime This field indicates the duration of time (in 213 seconds) for which the MN-HA key is valid. 215 MN-HA Key Reply Subtype Data 216 An encrypted copy of the key to be used between 217 the mobile node and its home agent, along with 218 any other information needed by the mobile 219 node to create the designated Mobility Security 220 Association with the home agent. 222 For each subtype, the format of the MN-HA Key Reply Subtype Data has 223 to be separately defined according to the particular method required 224 to set up the security association. 226 6. Generalized FA-HA Key Reply Extension 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type | Subtype | Length | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Lifetime | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | FA-HA Key Reply Subtype Data ... 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 5: The Generalized Mobile IP FA-HA Key Reply Extension 240 Type 45 (not skippable) (see [4]) 242 Subtype a number assigned to identify the way in which 243 the Encoded FA-HA Key Data is to be decrypted to 244 obtain the registration key 246 Length The 16-bit Length field indicates the length of 247 the extension. It is equal to 4 plus the number 248 of bytes in the Encoded FA-HA Key Data. 250 Lifetime This field indicates the duration of time (in 251 seconds) for which the FA-HA key is valid. 253 FA-HA Key Reply Subtype Data 254 An encrypted copy of the key to be used between 255 the foreign agent and the mobile node's home 256 agent, along with any other information needed 257 by the foreign agent to create the designated 258 Mobility Security Association with that home 259 agent. 261 For each subtype, the format of the FA-HA Key Reply Subtype Data has 262 to be separately defined according to the particular method required 263 to set up the security association. 265 7. Generalized FA-FA Key Reply Extension 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type | Subtype | Length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | FA-FA SPI | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | FA-FA Key Reply Subtype Data ... 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 6: The Generalized Mobile IP FA-FA Key Reply Extension 278 Type 46 (not skippable) (see [4]) 280 Subtype a number assigned to identify the way in which 281 the Encoded FA-FA Key Data is to be decrypted to 282 obtain the registration key 284 Length The 16-bit Length field indicates the length of 285 the extension. It is equal to 4 plus the number 286 of bytes in the Encoded FA-HA Key Data. 288 FA-FA SPI This field indicates the SPI that should be used 289 to decipher the FA-FA key. 291 FA-FA Key Reply Subtype Data 292 An encrypted copy of the key to be used between 293 the foreign agent and its home agent, along 294 with any other information needed by the mobile 295 node to create the designated Mobility Security 296 Association with the home agent. 298 For each subtype, the format of the FA-HA Key Reply Subtype Data has 299 to be separately defined according to the particular method required 300 to set up the security association. 302 8. IANA Considerations 304 Each generalized extension specified in this document is to be 305 numbered from the space of Mobile IP registration extension numbers 306 defined in RFC 2002 [4] as extended in RFC 2356 [3]. The numbers 40, 307 41, 42, 43, 45 and 46 chosen in the text are currently unassigned. 309 A subtype address space must be created for each generalized 310 extension defined in this document. From this space, subtype values 311 will be assigned according to standards approved principally by the 312 mobile-ip working group, but other working groups may also submit 313 requests to assign subtype numbers for Mobile IP extensions. 315 9. Security Considerations 317 The extensions in this document are intended to provide the 318 appropriate level of security for Mobile IP entities (mobile node, 319 foreign agent, and home agent) to operate Mobile IP registration 320 protocol. The security associations resulting from use of these 321 extensions do not offer any higher level of security than what is 322 already implicit in use of the security association between the 323 receiver and the entity distributing the key. 325 References 327 [1] P. Calhoun, Haseeb Akhtar, Emad Qaddoura, and N. Asokan. Foreign 328 Agent Keys Encoded as Opaque Tokens for use in Hand-off Process 329 (work in progress). draft-calhoun-mobileip-min-lat-handoff-02.txt, 330 March 2000. 332 [2] M. Khalil, R. Narayanan, H. Akhtar, and E. Qaddoura. 333 Mobile IP Extensions Rationalization (MIER) (work in 334 progress). Internet Draft, Internet Engineering Task Force. 335 draft-ietf-mobileip-mier-06.txt, April 2001. 337 [3] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 338 Mobile IP. Request for Comments (Informational) 2356, Internet 339 Engineering Task Force, June 1998. 341 [4] C. Perkins. IP Mobility Support. Request for Comments (Proposed 342 Standard) 2002, Internet Engineering Task Force, October 1996. 344 [5] C. Perkins and P. Calhoun. AAA Keys for Mobile IP (work in 345 progress). Internet Draft, Internet Engineering Task Force. 346 draft-ietf-mobileip-aaa-key-00.txt, July 2001. 348 [6] C. E. Perkins, D. Johnson, and N. Asokan. Registration Keys for 349 Route Optimization (work in progress). 350 draft-ietf-mobileip-regkey-03.txt, July 2000. 352 Addresses 354 The working group can be contacted via the current chairs: 356 Basavaraj Patil Phil Roberts 357 Nokia Megisto Corp. 358 6000 Connection Dr. Suite 120 359 20251 Century Blvd 360 Irving, TX. 75039 Germantown MD 20874 361 USA USA 362 Phone: +1 972-894-6709 Phone: +1 847-202-9314 363 Email: Basavaraj.Patil@nokia.com Email: PRoberts@MEGISTO.com 365 Questions about this memo can also be directed to the authors: 367 Charles E. Perkins Pat R. Calhoun 368 Communications Systems Lab Network & Security Center 369 Nokia Research Center Sun Microsystems Laboratories 370 313 Fairchild Drive 15 Network Circle 371 Mountain View, California 94043 Menlo Park, California 94025 372 USA USA 373 Phone: +1-650 625-2986 Phone: +1 650-786-7733 374 EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com 375 Fax: +1 650 625-2502 Fax: +1 650-786-6445