idnits 2.17.1 draft-ietf-mobileip-aaa-key-08.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. ** 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 92: '...oreign agent, it SHOULD include an MN-...' RFC 2119 keyword, line 96: '...e home agent, it MUST add an MN-HA Key...' RFC 2119 keyword, line 129: '...om AAA extension MUST also contain a s...' RFC 2119 keyword, line 132: '...om AAA extension MUST also contain a s...' RFC 2119 keyword, line 176: '...as those listed in 3 MAY also be used....' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [2], 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) ** Obsolete normative reference: RFC 2486 (ref. '1') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 3012 (ref. '3') (Obsoleted by RFC 4721) == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-07 ** Obsolete normative reference: RFC 1750 (ref. '5') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '6') ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '8') ** Obsolete normative reference: RFC 2434 (ref. '9') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 2002 (ref. '11') (Obsoleted by RFC 3220) -- Possible downref: Normative reference to a draft: ref. '12' Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 20 July 2001 Pat R. Calhoun 4 Sun Microsystems Laboratories 6 AAA Registration Keys for Mobile IP 7 draft-ietf-mobileip-aaa-key-08.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 AAA servers, such as RADIUS and DIAMETER, are in use within the 36 Internet today to provide authentication and authorization services 37 for dial-up computers. Mobile IP requires strong authentication 38 between the mobile node and its home agent. When the mobile node 39 shares a security association with its home AAA server, however, it 40 is possible to use that security association to create derivative 41 security associations between the mobile node and its home agent, 42 and again between the mobile node and the foreign agent currently 43 offering connectivity to the mobile node. This document specifies 44 extensions to the Mobile IP Registration Reply packet that can be 45 used to create such security information at the mobile node. 47 1. Introduction 49 AAA servers, such as RADIUS [13] and DIAMETER [4], are in use within 50 the Internet today to provide authentication and authorization 51 services for dial-up computers. Such services are likely to be 52 equally valuable for mobile nodes using Mobile IP when the nodes 53 are attempting to connect to foreign domains with AAA servers. 54 Mobile IP [11] requires strong authentication between the mobile 55 node and its home agent. When the mobile node shares a security 56 association with its home AAA server, however, it is possible to use 57 that security association to create derivative security associations 58 between the mobile node and its home agent, and again between the 59 mobile node and the foreign agent currently offering connectivity to 60 the mobile node. This document specifies extensions to the Mobile 61 IP Registration messages that can be used to create those security 62 associations at the mobile node. 64 AAA servers typically use the Network Access Identifier (NAI) [1] 65 to uniquely identify the mobile node; the mobile node's home 66 address is not always necessary to provide that function. Thus, 67 it is possible for a mobile node to authenticate itself, and be 68 authorized for connection to the foreign domain, without having any 69 home address. However, for Mobile IP to work, the mobile node is 70 required to have a security association with its home agent. When 71 the Mobile IP Registration Reply packet is authenticated by the 72 MN-AAA Authentication Extension [3], the mobile node can verify that 73 the keys contained in the extensions were produced by the AAA server, 74 and thus may be reliably used to create security associations with 75 the home agent, or alternatively with the foreign agent. 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [2]. 81 2. Scope of Protocol 83 The protocol and messages in this document are intended to facilitate 84 the following operations which may occur between the mobile node, AAA 85 server, home agent, and foreign agent. 87 1. When a mobile node travels away from home, it may not have a 88 security association with its home agent, perhaps because it does 89 not yet have a home address. 91 2. If the mobile node does not have a Mobility Security Association 92 with the foreign agent, it SHOULD include an MN-FA Key Request 93 extension. 95 3. Similarly, if the mobile node does not have a Mobility Security 96 Association with the home agent, it MUST add an MN-HA Key Request 97 extension. 99 4. If one or more Key Request extensions were added, the MN-AAA 100 Authentication extension is added to the Registration Request. 102 5. At the time the information within the MN-AAA Authentication 103 extension is verified by the AAA server, the AAA server also 104 generates Key Material for the keys requested by the mobile node, 105 and causes insertion of the Key Material fields along with the 106 Registration Reply. 108 6. The respective AAA keys are distributed to the Home and Foreign 109 Agent via the AAA protocol. 111 7. If the Reply passes authentication and contains the Unsolicited 112 MN-HA Key Material From AAA extension (see section 6), the mobile 113 node generates the key using the Key Material provided, according 114 to its security association with the AAA. The resulting key is 115 used to establish the mobile node's security association with its 116 home agent, and is used to authenticate the MN-HA authentication 117 extension. 119 8. Similarly, if the Reply passes authentication and contains 120 the Unsolicited MN-FA Key Material From AAA extension (see 121 section 5), the mobile node generates the key using the Key 122 Material provided, according to its security association with the 123 AAA. The resulting key is used to establish the mobile node's 124 security association with its new foreign agent, and is used to 125 compute the authentication data used in the MN-FA authentication 126 extension. 128 Any registration reply containing the Unsolicited MN-HA Key Material 129 From AAA extension MUST also contain a subsequent Mobile Home 130 Authentication Extension, created using the generated MN-HA key. 131 Similarly, a reply containing the Unsolicited MN-FA Key Material 132 From AAA extension MUST also contain a subsequent Mobile Foreign 133 Authentication Extension, created using the the MN-FA key. 135 3. Dynamic Security Associations 137 Mobility Security Associations between Mobile IP entities 138 (mobile nodes, home agents, foreign agents) contain both the 139 necessary cryptographic key information, and a way to identify 140 the cryptographic algorithm which uses the key to produce the 141 authentication information typically included in the Mobile Home 142 Authentication extension or the Mobile Foreign Authentication 143 extension. In order for the mobile node to make use of key 144 information sent to it by the AAA server, the mobile node also has to 145 be able to select the appropriate cryptographic algorithm that uses 146 the key to produce the authentication. The following table contains 147 the supported algorithm identifiers. 149 Algorithm Identifier Name Reference 150 --------------------- ------------------ ------------ 151 1 MD5/prefix+suffix RFC 2002 [11] 152 2 HMAC MD5 RFC 2104 [6] 153 3 SHA-1 FIPS 180-1 [10] 155 New algorithms will be allocated as indicated by practical experience 156 using the extensions defined in this document. 158 Dynamic Mobility Security Associations shared between mobile nodes 159 and home agents also requires a replay protection method. The 160 following table contains the supported replay methods. 161 Replay Method Name Reference 162 -------------- ------------ -------------- 163 1 None RFC 2002 [11] 164 2 Timestamps RFC 2002 [11] 165 3 Nonces RFC 2002 [11] 167 4. Key Material Creation and Derivation 169 This section contains the procedures followed in the creation of the 170 Key Material by AAA servers, and the key derivation procedures used 171 by mobile nodes. Note that the AAA servers will also make use of the 172 derivation procedures to deliver the keys via the AAA protocol. 174 The example that follows makes use of MD5 in prefix+suffix mode, 175 whose support is mandatory in Mobile IP [11]. Other cryptographic 176 functions, such as those listed in 3 MAY also be used. 178 1. The AAA server identifies the mobile node's via a 179 ``node-address''. If the Home Address field of the 180 Registration Request is zero (0), the Mobile Node's NAI is used 181 instead. 183 2. The AAA server generates a random [5] value of at least 64 bits. 185 3. The AAA server inserts the random value into the Key extension in 186 the ``Key Material'' field. 188 4. The mobile node calculates 190 key = MD5(AAA-key | Key Material | node-address | AAA-key) 192 5. The mobile node creates the dynamic security association, using 193 the key, and the other relevant information in the Key Extension. 195 5. Unsolicited MN-FA Key Material From AAA Subtype 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Lifetime | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | AAA SPI | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | FA SPI | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Algorithm Identifier | Key Material ... 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 1: The Unsolicited MN-FA Key Material From AAA 210 Subtype-Specific Data 212 lifetime This field indicates the duration of time (in seconds) 213 for which the MN-FA key is valid. 215 AAA SPI A 32-bit opaque value, indicating the SPI that the 216 mobile node must use to determine the algorithm to use 217 for establishing the FA security information. 219 FA SPI A 32-bit opaque value, which the mobile node MUST use 220 to index all the necessary information established for 221 the FA security information after it is decoded. 223 Algorithm Identifier 224 This field indicates the algorithm to be used for 225 future computations of the MN-FA Authentication 226 Extension (see section 3) 228 Key Material 229 A random [5] value of at least 64 bits. 231 The Unsolicited MN-FA Key Material From AAA extension, shown 232 in figure 1, uses subtype 7 of the Generalized MN-FA Key Reply 233 Extension [12]. The Key Material is added by the home domain AAA 234 server (AAAH) for use by the mobile node in creating the MN-FA key, 235 which is used to secure future Mobile IP registrations with the same 236 foreign agent. The Unsolicited MN-FA Key Material From AAA extension 237 MUST appear in the Registration Reply before the MN-FA Authentication 238 extension. 240 Once the mobile node creates the FA Security Information, by using 241 the algorithm indexed by the AAA SPI, it stores the FA Security 242 Information indexed by the FA SPI in its list of Mobile Security 243 Associations. 245 If the foreign agent receives a Registration Reply that has no 246 Unsolicited MN-FA Key Material From AAA extension, and thus cannot 247 establish a Mobility Security Association with the mobile node, the 248 foreign agent MAY change the Code value of the Registration Reply to 249 MISSING_MN_FA (see section 9), effectively causing the registration 250 to fail. 252 6. Unsolicited MN-HA Key Material From AAA Subtype 254 The Unsolicited MN-HA Key Material From AAA is subtype 1 of the 255 Generalized MN-HA Key Reply Extension [12]. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | AAA SPI | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | HA SPI | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Algorithm Identifier | Replay Method | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Key Material ... 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 2: The Unsolicited MN-HA Key Material From AAA 270 Subtype-Specific Data 272 AAA SPI A 32-bit opaque value, indicating the SPI that the 273 mobile node must use to determine the algorithm to use 274 for establishing the HA security information. 276 HA SPI A 32-bit opaque value, which the mobile node MUST use 277 to index all the necessary information established for 278 the HA security information after it is decoded. 280 Algorithm Identifier 281 This field indicates the algorithm to be used for 282 future computations of the MN-HA Authentication 283 Extension (see section 3) 285 Replay Method 286 This field contains the replay method to be used for 287 future Registration messages (see section 3). 289 Key Material 290 A random [5] value of at least 64 bits. 292 The Unsolicited MN-HA Material Key From AAA subtype-specific data 293 is shown in figure 2. The Mobile Node creates the MN-HA key using 294 the Key Material provided by the home domain AAA server (AAAH). The 295 key is intended for use the mobile node to secure future Mobile IP 296 registrations with its home agent. The MN-HA Key Reply MUST appear 297 in the Registration Reply before the MN-HA Authentication extension. 299 Once the mobile node creates the MN-HA Key, by using the algorithm 300 specified in the AAA SPI, it stores the HA Security Information 301 indexed by the HA SPI in its list of Mobile Security Associations. 302 The mobile node uses the Identification field data from the 303 Registration Request as its initial synchronization data with the 304 home agent. 306 7. MN-FA Key Request From AAA Subtype 308 The MN-FA Key Request From AAA subtype data uses subtype 7 of the 309 Generalized MN-FA Key Request Extension [12]. The MN-FA Key Request 310 From AAA extension MUST appear in the Registration Request before the 311 MN-AAA Authentication extension. The subtype data field is zero in 312 length. 314 8. MN-HA Key Request From AAA Subtype 316 The MN-HA Key Request From AAA subtype data uses subtype 7 of the 317 Generalized MN-HA Key Request Extension [12]. The MN-HA Key Request 318 From AAA extension MUST appear in the Registration Request before the 319 MN-AAA Authentication extension. The subtype data field is zero in 320 length. 322 9. Error Values 324 Each entry in the following table contains the name of Code [11] to 325 be returned in a Registration Reply, the value for the Code, and the 326 section in which the error is first mentioned in this specification. 328 Error Name Value Section 329 ---------------------- ----- --------- 330 MISSING_MN_FA 107 5 332 10. IANA Considerations 334 The number for the Generalized MN-HA Key Reply Extension is 335 taken from the numbering space defined for Mobile IP registration 336 extensions defined in RFC 2002 [11] as extended in RFC 2356 [8]. 338 The number 7, assigned to the Unsolicited MN-HA Key Material From AAA 339 Subtype extension, was taken from the numbering space defined for the 340 Generalized MN-HA Key Reply Extension, defined in [12]. 342 The number 7, assigned to the MN-FA Key Request From AAA Subtype 343 extension, was taken from the numbering space defined for the 344 Generalized MN-FA Key Request Extension, defined in [12]. 346 The number 1, assigned to the Unsolicited MN-FA Key Material From AAA 347 Subtype extension, was taken from the numbering space defined for the 348 Generalized MN-FA Key Reply Extension, defined in [12]. 350 The number 7, assigned to the MN-HA Key Request From AAA Subtype 351 extension, was taken from the numbering space defined for the 352 Generalized MN-HA Key Request Extension, defined in [12]. 354 The Code values specified for errors, listed in section 9, MUST NOT 355 conflict with any other code values listed in RFC 2002, RFC 3024 [7], 356 or RFC 2356 [8]. They are to be taken from the space of error values 357 conventionally associated with rejection by the foreign agent (i.e., 358 64-127). 360 Section 3 introduces the Algorithm Identifier namespace that requires 361 IANA management. This specification makes use of 1-3; all other 362 values other than zero (0) are available for assignment, pending 363 review and approval by a Designated Expert [9]. 365 Section 3 introduces the Replay Method Identifier namespace that 366 requires IANA management. This specification makes use of 1-3; 367 all other values other than zero (0) are available for assignment, 368 pending review and approval by a Designated Expert [9]. 370 11. Security Considerations 372 The extensions in this document are intended to provide the 373 appropriate level of security for Mobile IP entities (mobile node, 374 foreign agent, and home agent) to operate Mobile IP registration 375 protocol. The security associations resulting from use of these 376 extensions do not offer any higher level of security than what is 377 already implicit in use of the security association between the 378 mobile node and the AAA. 380 Since the extensions defined in this specification only carries Key 381 Material, which is used to derive keys, it does not expose any data 382 that could be used in an attack aimed at recovering the key shared 383 between the mobile node and the AAA. The authors do not believe this 384 specification introduces new security risks. 386 References 388 [1] B. Aboba and M. Beadles. The Network Access Identifier. 389 Request for Comments (Proposed Standard) 2486, Internet 390 Engineering Task Force, January 1999. 392 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 393 Levels. Request for Comments (Best Current Practice) 2119, 394 Internet Engineering Task Force, March 1997. 396 [3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 397 Challenge/Response Extension. Request for Comments (Proposed 398 Standard) 3012, Internet Engineering Task Force, December 2000. 400 [4] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER 401 Base Protocol (work in progress). Internet Draft, Internet 402 Engineering Task Force. draft-ietf-aaa-diameter-07.txt, July 403 2001. 405 [5] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 406 Recommendations for Security. Request for Comments 407 (Informational) 1750, Internet Engineering Task Force, December 408 1994. 410 [6] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 411 for Message Authentication. Request for Comments 412 (Informational) 2104, Internet Engineering Task Force, 413 February 1997. 415 [7] Editor G. Montenegro. Reverse Tunneling for Mobile IP, revised. 416 Request for Comments (Proposed Standard) 3024, Internet 417 Engineering Task Force, January 2001. 419 [8] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 420 Mobile IP. Request for Comments (Informational) 2356, Internet 421 Engineering Task Force, June 1998. 423 [9] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 424 Considerations Section in RFCs. Request for Comments (Best 425 Current Practice) 2434, Internet Engineering Task Force, October 426 1998. 428 [10] National Institute of Standards and Technology. Secure Hash 429 Standard. Technical Report NIST FIPS PUB 180-1, U.S. Department 430 of Commerce, April 1995. 432 [11] C. Perkins. IP Mobility Support. Request for Comments 433 (Proposed Standard) 2002, Internet Engineering Task Force, 434 October 1996. 436 [12] C. Perkins and P. Calhoun. Generalized Key Distribution 437 Extensions for Mobile IP (work in progress). 438 draft-ietf-mobileip-gen-key-01.txt, July 2001. 440 [13] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 441 Authentication Dial In User Service (RADIUS). Request for 442 Comments (Proposed Standard) 2865, Internet Engineering Task 443 Force, June 2000. 445 Addresses 447 The working group can be contacted via the current chairs: 449 Basavaraj Patil Phil Roberts 450 Nokia Megisto Corp. 451 6000 Connection Dr. Suite 120 452 20251 Century Blvd 453 Irving, TX. 75039 Germantown MD 20874 454 USA USA 455 Phone: +1 972-894-6709 Phone: +1 847-202-9314 456 Email: Basavaraj.Patil@nokia.com Email: PRoberts@MEGISTO.com 458 Questions about this memo can also be directed to the authors: 460 Charles E. Perkins Pat R. Calhoun 461 Communications Systems Lab Network & Security Center 462 Nokia Research Center Sun Microsystems Laboratories 463 313 Fairchild Drive 15 Network Circle 464 Mountain View, California 94043 Menlo Park, California 94025 465 USA USA 466 Phone: +1-650 625-2986 Phone: +1 650-786-7733 467 EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com 468 Fax: +1 650 625-2502 Fax: +1 650-786-6445