idnits 2.17.1 draft-ietf-mobileip-aaa-key-04.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 112: '...om AAA extension MUST also contain a s...' RFC 2119 keyword, line 115: '...om AAA extension MUST also contain a s...' RFC 2119 keyword, line 135: '... it MUST share a security associatio...' RFC 2119 keyword, line 154: '...all mobile nodes MUST be able to verif...' RFC 2119 keyword, line 204: '... value, which the mobile node MUST use...' (7 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) ** Obsolete normative reference: RFC 2486 (ref. '1') (Obsoleted by RFC 4282) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-12 -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '4') ** Obsolete normative reference: RFC 2344 (ref. '5') (Obsoleted by RFC 3024) ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '6') ** Obsolete normative reference: RFC 2002 (ref. '7') (Obsoleted by RFC 3220) -- Unexpected draft version: The latest known version of draft-ietf-mobileip-gen-key is -01, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 2138 (ref. '10') (Obsoleted by RFC 2865) Summary: 11 errors (**), 0 flaws (~~), 2 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 March 2001 Pat R. Calhoun 4 Sun Microsystems Laboratories 6 AAA Registration Keys for Mobile IP 7 draft-ietf-mobileip-aaa-key-04.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@STANDARDS.NORTELNETWORKS.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 a care-of address to the mobile node. This document 44 specifies extensions to the Mobile IP Registration Reply packet that 45 can be used to distribute such security information to the mobile 46 node. 48 1. Introduction 50 AAA servers, such as RADIUS [10] and DIAMETER [3], are in use within 51 the Internet today to provide authentication and authorization 52 services for dial-up computers. Such services are likely to be 53 equally valuable for mobile nodes using Mobile IP when the nodes are 54 attempting to connect to foreign domains with AAA servers. Mobile 55 IP [7] requires strong authentication between the mobile node and its 56 home agent. When the mobile node shares a security association with 57 its home AAA server, however, it is possible to use that security 58 association to create derivative security associations between the 59 mobile node and its home agent, and again between the mobile node 60 and the foreign agent currently offering a care-of address to the 61 mobile node. This document specifies extensions to the Mobile 62 IP Registration Reply packet that can be used to distribute such 63 security information to the mobile node. 65 AAA servers typically use the Network Access Identifier (NAI) [1] to 66 uniquely identify the mobile node; the mobile node's home address 67 is not always necessary to provide that function. Thus, it is 68 possible for a mobile node to authenticate itself, and be authorized 69 for connection to the foreign domain, without even having a home 70 address. However, for Mobile IP to work, the mobile node is required 71 to have a security association with its home agent. When the 72 Mobile IP Registration Reply packet is authenticated by the MN-AAA 73 Authentication Extension [2], the mobile node can verify that the 74 keys contained in the extensions were produced by the AAA server, and 75 thus may be reliably used to create security associations with the 76 home agent, or alternatively with the foreign agent. 78 The following operations are envisioned between the mobile node, AAA 79 server, home agent, and foreign agent. 81 1. When a mobile node travels away from home, it may not have a 82 security association with its home agent, perhaps because it does 83 not yet have a home address. 85 2. When the mobile node first registers away from home, it includes 86 a MN-AAA Authentication extension if it does not yet have a 87 Mobility Security Association with a home agent. 89 3. At the time the information within the MN-AAA Authentication 90 extension is verified by the AAA server, the AAA server also 91 generates keys for the mobile node, encodes the keys according 92 to its own security association with the mobile node, and causes 93 insertion of the new key or keys along with the Registration 94 Reply. 96 4. If the Reply passes authentication and contains the Unsolicited 97 MN-HA Key From AAA extension (see section 5), the mobile node 98 decodes the key according to its security association with 99 the AAA. The resulting key is used to establish the mobile 100 node's security association with its home agent, and is used to 101 authenticate the MN-HA authentication extension. 103 5. Similarly, if the Reply passes authentication and contains the 104 Unsolicited MN-FA Key From AAA extension (see section 4), the 105 mobile node decodes the key according to its security association 106 with the AAA. The resulting key is used to establish the mobile 107 node's security association with its new foreign agent, and 108 is used to compute the authentication data used in the MN-FA 109 authentication extension. 111 Any registration reply containing the Unsolicited MN-HA Key 112 From AAA extension MUST also contain a subsequent Mobile Home 113 Authentication Extension, created using the decrypted version of the 114 MN-HA key. Similarly, a reply containing the Unsolicited MN-FA Key 115 From AAA extension MUST also contain a subsequent Mobile Foreign 116 Authentication Extension, created using the decrypted version of the 117 MN-FA key. 119 2. Security Algorithms 121 Mobility Security Associations between Mobile IP entities 122 (mobile nodes, home agents, foreign agents) contain both the 123 necessary cryptographic key information, and a way to identify 124 the cryptographic algorithm which uses the key to produce the 125 authentication information typically included in the Mobile Home 126 Authentication extension or the Mobile Foreign Authentication 127 extension. In order for the mobile node to make use of key 128 information sent to it by the AAA server, the mobile node also has to 129 be able to select the appropriate cryptographic algorithm that uses 130 the key to produce the authentication. 132 For use with the key extensions specified in this document, the 133 supported security algorithms are also specified. In order for a 134 mobile node to be able to decode the keys defined in this document, 135 it MUST share a security association with its' Home AAA server. 136 The security association is the one by which the mobile node is 137 instructed to decode the keying material in the the Unsolicited MN-FA 138 or MN-HA Key From AAA extensions. 140 Reserved SPI number Name Reference 141 --------------------- ------------------ ------------ 142 3 MD5/prefix+suffix RFC 2002 [7] 143 4 HMAC MD5 RFC 2104 [4] 145 New algorithms will be allocated as indicated by practical experience 146 using the extensions defined in this document. See section 3 for 147 specific information about using Algorithm MD5/prefix+suffix. The 148 HMAC MD5 algorithm is used in exactly the same way, except that the 149 specific computation used with MD5 follows RFC 2104 instead of RFC 150 2002. 152 3. Using the MD5/prefix+suffix Algorithm 154 As with Mobile IP, all mobile nodes MUST be able to verify the 155 authenticator within a MN-HA Authentication extension by using MD5 in 156 prefix+suffix mode, signified by selection at a SPI of any arbitrary 157 32-bit value. Therefore, it is economical to use the MD5 algorithm 158 in prefix+suffix mode to encode the key within the particular key 159 extension, as follows. 161 1. The AAA server identifies the mobile node's IP address, call it 162 ``node-address''. 164 2. The AAA server calculates 166 (key XOR (MD5(AAA-key | node-address | AAA-key))) 168 3. The AAA server inserts this result into the Key extension in the 169 ``Encoded Key'' field. 171 4. The mobile node calculates 173 temp = MD5(AAA-key | node-address | AAA-key) 175 5. The mobile node extracts the Security_Information of the key 176 extension and calculates 178 key = Encoded Key XOR temp 180 4. Unsolicited MN-FA Key From AAA Subtype 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Lifetime | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | AAA SPI | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | FA SPI | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | MN-FA Encoded Key data ... 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 1: The Unsolicited MN-FA Key From AAA 195 Subtype-Specific Data 197 lifetime This field indicates the duration of time (in seconds) 198 for which the MN-FA key is valid. 200 AAA SPI A 32-bit opaque value, indicating the SPI that the 201 mobile node must use to determine the algorithm to use 202 for recovering the FA security information. 204 FA SPI A 32-bit opaque value, which the mobile node MUST use 205 to index all the necessary information recovered from 206 the FA security information after it is decoded. 208 MN-FA Encoded Key data 209 The necessary information (including the key) required 210 by the mobile node to create a Mobility Security 211 Assocation between itself and the foreign agent. 213 The Unsolicited MN-FA Key From AAA extension, shown in figure 1, uses 214 subtype 7 of the Generalized MN-FA Key Reply Extension [9]. The key 215 is encoded by the home domain AAA server (AAAH) for use by the mobile 216 node to secure future Mobile IP registrations with the same foreign 217 agent. The Unsolicited MN-FA Key From AAA extension MUST appear in 218 the Registration Reply before the MN-FA Authentication extension. 220 Once the mobile node decodes the FA Security Information, by using 221 the algorithm indexed by the AAA SPI, it stores the FA Security 222 Information indexed by the FA SPI in its list of Mobile Security 223 Associations. 225 If the foreign agent receives a Registration Reply that does not 226 have a Unsolicited MN-FA Key From AAA extension, and thus does not 227 have a way to establish a Mobility Security Association with the 228 mobile node, the foreign agent SHOULD change the Code value of the 229 Registration Reply to MISSING_MN_FA (see section 8), effectively 230 causing the registration to fail. 232 5. Unsolicited MN-HA Key From AAA Subtype 234 The Unsolicited MN-HA Key From AAA is subtype 1 of the Generalized 235 MN-HA Key Reply Extension [8]. 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | AAA SPI | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | HA SPI | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | MN-HA Encoded Key data ... 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 2: The Unsolicited MN-HA Key From AAA 248 Subtype-Specific Data 250 AAA SPI A 32-bit opaque value, indicating the SPI that the 251 mobile node must use to determine the algorithm to use 252 for recovering the HA security information. 254 HA SPI A 32-bit opaque value, which the mobile node MUST use 255 to index all the necessary information recovered from 256 the HA security information after it is decoded. 258 MN-HA Encoded Key data 259 The necessary information (including the key) required 260 by the mobile node to create a Mobility Security 261 Assocation between itself and the home agent. 263 The Unsolicited MN-HA Key From AAA subtype-specific data is shown 264 in figure 2. The Mobile Node Encoded Key data is to be decoded 265 according to the given SPI between the mobile node and the home 266 domain AAA server (AAAH). The key is intended for use the mobile node 267 to secure future Mobile IP registrations with its home agent. The 268 MN-HA Key Reply MUST appear in the Registration Reply before the 269 MN-HA Authentication extension. 271 Once the mobile node decodes the MN-HA Encoded Key data, by using 272 the algorithm indexed by the AAA SPI, it stores the HA Security 273 Information indexed by the HA SPI in its list of Mobile Security 274 Associations. The mobile node uses the Identification field data 275 from the Registration Request as its initial synchronization data 276 with the home agent. 278 6. MN-FA Key Request From AAA Subtype 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | AAA SPI | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | FA SPI | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 3: The MN-FA Key Request From AAA Subtype-Specific Data 290 AAA SPI A 32-bit opaque value, indicating the SPI that the 291 mobile node must use to determine the algorithm to use 292 for recovering the FA security information. 294 FA SPI A 32-bit opaque value, which the mobile node proposes 295 for use with the foreign agent to identify the security 296 association determined by the granted key, and to index 297 all the necessary information to be used as part of the 298 security association. 300 The MN-FA Key Request From AAA subtype data, shown in figure 3, 301 uses subtype 7 of the Generalized MN-FA Key Request Extension [8]. 302 The key is encoded by the home domain AAA server (AAAH) for use by 303 the mobile node to secure future Mobile IP registrations with the 304 same foreign agent. The MN-FA Key Request From AAA extension MUST 305 appear in the Registration Request before the MN-AAA Authentication 306 extension. 308 7. MN-HA Key Request From AAA Subtype 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | AAA SPI | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | HA SPI | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 4: The MN-HA Key Request From AAA Subtype-Specific Data 320 AAA SPI A 32-bit opaque value, indicating the SPI that the 321 mobile node must use to determine the algorithm to use 322 for recovering the HA security information. 324 HA SPI A 32-bit opaque value, which the mobile node proposes 325 for use with the foreign agent to identify the security 326 association determined by the granted key, and to index 327 all the necessary information to be used as part of the 328 security association. 330 The MN-HA Key Request From AAA subtype data, shown in figure 4, 331 uses subtype 7 of the Generalized MN-HA Key Request Extension [8]. 332 The key is encoded by the home domain AAA server (AAAH) for use by 333 the mobile node to secure future Mobile IP registrations with the 334 same foreign agent. The MN-HA Key Request From AAA extension MUST 335 appear in the Registration Request before the MN-AAA Authentication 336 extension. 338 8. Error Values 340 Each entry in the following table contains the name of Code [7] to 341 be returned in a Registration Reply, the value for the Code, and the 342 section in which the error is first mentioned in this specification. 344 Error Name Value Section 345 ---------------------- ----- --------- 346 MISSING_MN_FA 107 4 348 9. IANA Considerations 350 The number for the Generalized MN-HA Key Reply Extension is 351 taken from the numbering space defined for Mobile IP registration 352 extensions defined in RFC 2002 [7] as extended in RFC 2356 [6]. 354 The subtype address space for the Generalized MN-HA Key Reply 355 extension is defined in this document. From this space, subtype 356 value 1 is assigned to the Unsolicited MN-HA Key From AAA Subtype 357 extension. 359 The number assigned to the MN-FA Key Request From AAA Subtype 360 extension was taken from the numbering space defined for the 361 Generalized MN-FA Key Request Extension, defined in [9]. 363 The number assigned to the Unsolicited MN-FA Key From AAA Subtype 364 extension was taken from the numbering space defined for the 365 Generalized MN-FA Key Reply Extension, defined in [9]. 367 The number assigned to the MN-HA Key Request From AAA Subtype 368 extension was taken from the numbering space defined for the 369 Generalized MN-HA Key Request Extension, defined in [9]. 371 The Code values specified for errors, listed in section 8, MUST NOT 372 conflict with any other code values listed in RFC 2002, RFC 2344 [5], 373 or RFC 2356 [6]. They are to be taken from the space of error values 374 conventionally associated with rejection by the foreign agent (i.e., 375 64-127). 377 SPI values 3 and 4 are taken from the reserved space of SPI numbers 378 (0-255) created for special Mobile IP algorithm identifiers. 380 10. Security Considerations 382 The extensions in this document are intended to provide the 383 appropriate level of security for Mobile IP entities (mobile node, 384 foreign agent, and home agent) to operate Mobile IP registration 385 protocol. The security associations resulting from use of these 386 extensions do not offer any higher level of security than what is 387 already implicit in use of the security association between the 388 mobile node and the AAA. 390 References 392 [1] B. Aboba and M. Beadles. The Network Access Identifier. 393 Request for Comments (Proposed Standard) 2486, Internet 394 Engineering Task Force, January 1999. 396 [2] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 397 Challenge/Response Extension (work in progress). 398 draft-ietf-mobileip-challenge-13.txt, June 2000. 400 [3] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER 401 Base Protocol (work in progress). Internet Draft, Internet 402 Engineering Task Force. 403 draft-calhoun-diameter-12.txt, December 1999. 405 [4] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 406 for Message Authentication. Request for Comments 407 (Informational) 2104, Internet Engineering Task Force, 408 February 1997. 410 [5] G. Montenegro. Reverse Tunneling for Mobile IP. Request for 411 Comments (Proposed Standard) 2344, Internet Engineering Task 412 Force, May 1998. 414 [6] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 415 Mobile IP. Request for Comments (Informational) 2356, Internet 416 Engineering Task Force, June 1998. 418 [7] C. Perkins. IP Mobility Support. Request for Comments 419 (Proposed Standard) 2002, Internet Engineering Task Force, 420 October 1996. 422 [8] C. Perkins and P. Calhoun. Generalized Key Distribution 423 Extensions for Mobile IP (work in progress). 424 draft-ietf-mobileip-gen-key-02.txt, July 2000. 426 [9] C. Perkins and D. Johnson. Registration Keys for Route 427 Optimization (work in progress). Internet Draft, Internet 428 Engineering Task Force, December 1997. 430 [10] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 431 Authentication Dial In User Service (RADIUS). Request for 432 Comments (Proposed Standard) 2138, Internet Engineering Task 433 Force, April 1997. 435 Addresses 437 The working group can be contacted via the current chairs: 439 Basavaraj Patil Phil Roberts 440 Nortel Networks Inc. Motorola 441 2201 Lakeside Blvd. 1501 West Shure Drive 442 Richardson, TX. 75082-4399 Arlington Heights, IL 60004 443 USA USA 444 Phone: +1 972-684-1489 Phone: +1 847-632-3148 445 EMail: bpatil@nortelnetworks.com EMail: QA3445@email.mot.com 447 Questions about this memo can also be directed to the authors: 449 Charles E. Perkins Pat R. Calhoun 450 Communications Systems Lab Network & Security Center 451 Nokia Research Center Sun Microsystems Laboratories 452 313 Fairchild Drive 15 Network Circle 453 Mountain View, California 94043 Menlo Park, California 94025 454 USA USA 455 Phone: +1-650 625-2986 Phone: +1 650-786-7733 456 EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com 457 Fax: +1 650 625-2502 Fax: +1 650-786-6445