idnits 2.17.1 draft-ietf-mobileip-aaa-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. ** 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 113: '...om AAA extension MUST also contain a s...' RFC 2119 keyword, line 116: '...om AAA extension MUST also contain a s...' RFC 2119 keyword, line 136: '... it MUST share a security associatio...' RFC 2119 keyword, line 155: '...all mobile nodes MUST be able to verif...' RFC 2119 keyword, line 200: '... value, which the mobile node MUST use...' (5 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 (-13) exists of draft-ietf-mobileip-challenge-08 == 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) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2138 (ref. '9') (Obsoleted by RFC 2865) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Working Group Charles E. Perkins 3 INTERNET DRAFT Nokia Research Center 4 28 January 2000 Pat R. Calhoun 5 Sun Microsystems Laboratories 7 AAA Registration Keys for Mobile IP 8 draft-ietf-mobileip-aaa-key-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@STANDARDS.NORTELNETWORKS.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: 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 Abstract 36 AAA servers, such as RADIUS and DIAMETER, are in use within the 37 Internet today to provide authentication and authorization services 38 for dial-up computers. Mobile IP requires strong authentication 39 between the mobile node and its home agent. When the mobile node 40 shares a security association with its home AAA server, however, it 41 is possible to use that security association to create derivative 42 security associations between the mobile node and its home agent, 43 and again between the mobile node and the foreign agent currently 44 offering a care-of address to the mobile node. This document 45 specifies extensions to the Mobile IP Registration Reply packet that 46 can be used to distribute such security information to the mobile 47 node. 49 1. Introduction 51 AAA servers, such as RADIUS [9] and DIAMETER [3], are in use within 52 the Internet today to provide authentication and authorization 53 services for dial-up computers. Such services are likely to be 54 equally valuable for mobile nodes using Mobile IP when the nodes are 55 attempting to connect to foreign domains with AAA servers. Mobile 56 IP [7] requires strong authentication between the mobile node and its 57 home agent. When the mobile node shares a security association with 58 its home AAA server, however, it is possible to use that security 59 association to create derivative security associations between the 60 mobile node and its home agent, and again between the mobile node 61 and the foreign agent currently offering a care-of address to the 62 mobile node. This document specifies extensions to the Mobile 63 IP Registration Reply packet that can be used to distribute such 64 security information to the mobile node. 66 AAA servers typically use the Network Access Identifier (NAI) [1] to 67 uniquely identify the mobile node; the mobile node's home address 68 is not always necessary to provide that function. Thus, it is 69 possible for a mobile node to authenticate itself, and be authorized 70 for connection to the foreign domain, without even having a home 71 address. However, for Mobile IP to work, the mobile node is required 72 to have a security association with its home agent. When the 73 Mobile IP Registration Reply packet is authenticated by the MN-AAA 74 Authentication Extension [2], the mobile node can verify that the 75 keys contained in the extensions were produced by the AAA server, and 76 thus may be reliably used to create security associations with the 77 home agent, or alternatively with the foreign agent. 79 The following operations are envisioned between the mobile node, AAA 80 server, home agent, and foreign agent. 82 1. When a mobile node travels away from home, it may not have a 83 security association with its home agent, perhaps because it does 84 not yet have a home address. 86 2. When the mobile node first registers away from home, it includes 87 a MN-AAA Authentication extension if it does not yet have a 88 Mobility Security Association with a home agent. 90 3. At the time the information within the MN-AAA Authentication 91 extension is verified by the AAA server, the AAA server also 92 generates keys for the mobile node, encodes the keys according 93 to its own security association with the mobile node, and causes 94 insertion of the new key or keys along with the Registration 95 Reply. 97 4. If the Reply passes authentication and contains the Unsolicited 98 MN-HA Key From AAA extension (see section 6), the mobile node 99 decodes the key according to its security association with 100 the AAA. The resulting key is used to establish the mobile 101 node's security association with its home agent, and is used to 102 authenticate the MN-HA authentication extension. 104 5. Similarly, if the Reply passes authentication and contains the 105 Unsolicited MN-FA Key From AAA extension (see section 4), the 106 mobile node decodes the key according to its security association 107 with the AAA. The resulting key is used to establish the mobile 108 node's security association with its new foreign agent, and 109 is used to compute the authentication data used in the MN-FA 110 authentication extension. 112 Any registration reply containing the Unsolicited MN-HA Key 113 From AAA extension MUST also contain a subsequent Mobile Home 114 Authentication Extension, created using the decrypted version of the 115 MN-HA key. Similarly, a reply containing the Unsolicited MN-FA Key 116 From AAA extension MUST also contain a subsequent Mobile Foreign 117 Authentication Extension, created using the decrypted version of the 118 MN-FA key. 120 2. Security Algorithms 122 Mobility Security Associations between Mobile IP entities 123 (mobile nodes, home agents, foreign agents) contain both the 124 necessary cryptographic key information, and a way to identify 125 the cryptographic algorithm which uses the key to produce the 126 authentication information typically included in the Mobile Home 127 Authentication extension or the Mobile Foreign Authentication 128 extension. In order for the mobile node to make use of key 129 information sent to it by the AAA server, the mobile node also has to 130 be able to select the appropriate cryptographic algorithm that uses 131 the key to produce the authentication. 133 For use with the key extensions specified in this document, the 134 supported security algorithms are also specified. In order for a 135 mobile node to be able to decode the keys defined in this document, 136 it MUST share a security association with its' Home AAA server. 137 The security association is the one by which the mobile node is 138 instructed to decode the keying material in the the Unsolicited MN-FA 139 or MN-HA Key From AAA extensions. 141 Reserved SPI number Name Reference 142 --------------------- ------------------ ------------ 143 3 MD5/prefix+suffix RFC 2002 [7] 144 4 HMAC MD5 RFC 2104 [4] 146 New algorithms will be allocated as indicated by practical experience 147 using the extensions defined in this document. See section 3 for 148 specific information about using Algorithm MD5/prefix+suffix. The 149 HMAC MD5 algorithm is used in exactly the same way, except that the 150 specific computation used with MD5 follows RFC 2104 instead of RFC 151 2002. 153 3. Using the MD5/prefix+suffix Algorithm 155 As with Mobile IP, all mobile nodes MUST be able to verify the 156 authenticator within a MN-HA Authentication extension by using MD5 in 157 prefix+suffix mode, signified by selection at a SPI of any arbitrary 158 32-bit value. Therefore, it is economical to use the MD5 algorithm 159 in prefix+suffix mode to encode the key within the particular key 160 extension, as follows. 162 1. The AAA server identifies the mobile node's IP address, call it 163 ``node-address''. 165 2. The AAA server calculates 167 (key XOR (MD5(AAA-key | node-address | AAA-key))) 169 3. The AAA server inserts this result into the Key extension in the 170 ``Encoded Key'' field. 172 4. The mobile node calculates 174 temp = MD5(AAA-key | node-address | AAA-key) 176 5. The mobile node extracts the Security_Information of the key 177 extension and calculates 179 key = Encoded Key XOR temp 181 4. Unsolicited MN-FA Key From AAA Subtype 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | AAA SPI | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | FA SPI | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | MN-FA Encoded Key data ... 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 1: The Unsolicited MN-FA Key From AAA 194 Subtype-Specific Data 196 AAA SPI A 32-bit opaque value, indicating the SPI that the 197 mobile node must use to determine the algorithm to use 198 for recovering the FA security information. 200 FA SPI A 32-bit opaque value, which the mobile node MUST use 201 to index all the necessary information recovered from 202 the FA security information after it is decoded. 204 MN-FA Encoded Key data 205 The necessary information (including the key) required 206 by the mobile node to create a Mobility Security 207 Assocation between itself and the foreign agent. 209 The Unsolicited MN-FA Key From AAA extension, shown in figure 1, uses 210 subtype 7 of the Generalized MN-FA Key Reply Extension [8]. The key 211 is encoded by the home domain AAA server (AAAH) for use by the mobile 212 node to secure future Mobile IP registrations with the same foreign 213 agent. The Unsolicited MN-FA Key From AAA extension MUST appear in 214 the Registration Reply before the MN-FA Authentication extension. 216 Once the mobile node decodes the FA Security Information, by using 217 the algorithm indexed by the AAA SPI, it stores the FA Security 218 Information indexed by the FA SPI in its list of Mobile Security 219 Associations. 221 If the foreign agent receives a Registration Reply that does not 222 have a Unsolicited MN-FA Key From AAA extension, and thus does not 223 have a way to establish a Mobility Security Association with the 224 mobile node, the foreign agent SHOULD change the Code value of the 225 Registration Reply to MISSING_MN_FA (see section 7), effectively 226 causing the registration to fail. 228 5. Generalized MN-HA Key Reply Extension 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type | Subtype | Length | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Lifetime | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Registration Key Distribution Data ... 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Figure 2: The Generalized Mobile IP MN-HA Key Reply Extension 242 Type 42 (not skippable) (see [7]) 244 Subtype a number assigned to identify the way in which the 245 Encoded Registration Key Data is to be decrypted 246 to obtain the registration key 248 Length The 16-bit Length field indicates the length of 249 the extension. It is equal to 4 plus the number 250 of bytes in the Encoded Registration Key Data. 252 Lifetime This field indicates the duration of time (in 253 seconds) for which the MH-HA key is valid. 255 Registration Key Distribution Data 256 An encrypted copy of the registration key, along 257 with any other information needed by the mobile 258 node to create the designated Mobility Security 259 Association with the home agent. 261 6. Unsolicited MN-HA Key From AAA Subtype 263 The Unsolicited MN-HA Key From AAA is subtype 1 of the Generalized 264 MN-HA Key Reply Extension (see section 5). 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 | AAA SPI | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | HA SPI | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | MN-HA Encoded Key data ... 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 3: The Unsolicited MN-HA Key From AAA 277 Subtype-Specific Data 279 AAA SPI A 32-bit opaque value, indicating the SPI that the 280 mobile node must use to determine the algorithm to use 281 for recovering the HA security information. 283 HA SPI A 32-bit opaque value, which the mobile node MUST use 284 to index all the necessary information recovered from 285 the HA security information after it is decoded. 287 MN-HA Encoded Key data 288 The necessary information (including the key) required 289 by the mobile node to create a Mobility Security 290 Assocation between itself and the home agent. 292 The Unsolicited MN-HA Key From AAA subtype-specific data is shown 293 in figure 3. The Mobile Node Encoded Key data is to be decoded 294 according to the given SPI between the mobile node and the home 295 domain AAA server (AAAH). The key is intended for use the mobile node 296 to secure future Mobile IP registrations with its home agent. The 297 MN-HA Key Reply MUST appear in the Registration Reply before the 298 MN-HA Authentication extension. 300 Once the mobile node decodes the MN-HA Encoded Key data, by using 301 the algorithm indexed by the AAA SPI, it stores the HA Security 302 Information indexed by the HA SPI in its list of Mobile Security 303 Associations. The mobile node uses the Identification field data 304 from the Registration Request as its initial synchronization data 305 with the home agent. 307 7. Error Values 309 Each entry in the following table contains the name of Code [7] to 310 be returned in a Registration Reply, the value for the Code, and the 311 section in which the error is first mentioned in this specification. 313 Error Name Value Section 314 ---------------------- ----- --------- 315 MISSING_MN_FA 107 4 317 8. IANA Considerations 319 The number for the Generalized MN-HA Key Reply Extension is 320 taken from the numbering space defined for Mobile IP registration 321 extensions defined in RFC 2002 [7] as extended in RFC 2356 [6]. 323 The subtype address space for the Generalized MN-HA Key Reply 324 extension is defined in this document. From this space, subtype 325 value 1 is assigned to the Unsolicited MN-HA Key From AAA Subtype 326 extension. 328 The number assigned to the Unsolicited MN-FA Key From AAA Subtype 329 extension was taken from the numbering space defined for the 330 Generalized MN-FA Key Reply Extension, defined in [8]. 332 The Code values specified for errors, listed in section 7, MUST NOT 333 conflict with any other code values listed in RFC 2002, RFC 2344 [5], 334 or RFC 2356 [6]. They are to be taken from the space of error values 335 conventionally associated with rejection by the foreign agent (i.e., 336 64-127). 338 SPI values 3 and 4 are taken from the reserved space of SPI numbers 339 (0-255) created for special Mobile IP algorithm identifiers. 341 9. Security Considerations 343 The extensions in this document are intended to provide the 344 appropriate level of security for Mobile IP entities (mobile node, 345 foreign agent, and home agent) to operate Mobile IP registration 346 protocol. The security associations resulting from use of these 347 extensions do not offer any higher level of security than what is 348 already implicit in use of the security association between the 349 mobile node and the AAA. 351 References 353 [1] B. Aboba and M. Beadles. The Network Access Identifier. Request 354 for Comments (Proposed Standard) 2486, Internet Engineering Task 355 Force, January 1999. 357 [2] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 358 Challenge/Response Extension. 359 draft-ietf-mobileip-challenge-08.txt, January 2000. (work in 360 progress). 362 [3] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER Base 363 Protocol. Internet Draft, Internet Engineering Task Force. 364 draft-calhoun-diameter-12.txt, December 1999. Work in progress. 366 [4] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for 367 Message Authentication. Request for Comments (Informational) 368 2104, Internet Engineering Task Force, February 1997. 370 [5] G. Montenegro. Reverse Tunneling for Mobile IP. Request for 371 Comments (Proposed Standard) 2344, Internet Engineering Task 372 Force, May 1998. 374 [6] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 375 Mobile IP. Request for Comments (Informational) 2356, Internet 376 Engineering Task Force, June 1998. 378 [7] C. Perkins. IP Mobility Support. Request for Comments (Proposed 379 Standard) 2002, Internet Engineering Task Force, October 1996. 381 [8] C. Perkins and D. Johnson. Registration Keys for Route 382 Optimization. Internet Draft, Internet Engineering Task Force, 383 December 1997. Work in progress. 385 [9] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 386 Authentication Dial In User Service (RADIUS). Request for 387 Comments (Proposed Standard) 2138, Internet Engineering Task 388 Force, April 1997. 390 Addresses 392 The working group can be contacted via the current chairs: 394 Basavaraj Patil Phil Roberts 395 Nortel Networks Inc. Motorola 396 2201 Lakeside Blvd. 1501 West Shure Drive 397 Richardson, TX. 75082-4399 Arlington Heights, IL 60004 398 USA USA 399 Phone: +1 972-684-1489 Phone: +1 847-632-3148 400 EMail: bpatil@nortelnetworks.com EMail: QA3445@email.mot.com 402 Questions about this memo can also be directed to the authors: 404 Charles E. Perkins Pat R. Calhoun 405 Communications Systems Lab Network & Security Center 406 Nokia Research Center Sun Microsystems Laboratories 407 313 Fairchild Drive 15 Network Circle 408 Mountain View, California 94043 Menlo Park, California 94025 409 USA USA 410 Phone: +1-650 625-2986 Phone: +1 650-786-7733 411 EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com 412 Fax: +1 650 625-2502 Fax: +1 650-786-6445