idnits 2.17.1 draft-ietf-mobileip-aaa-key-03.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 199: '... 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. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Charles E. Perkins 2 INTERNET DRAFT Nokia Research Center 3 28 January 2001 Pat R. Calhoun 4 Sun Microsystems Laboratories 6 AAA Registration Keys for Mobile IP 7 draft-ietf-mobileip-aaa-key-03.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 [9] 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 6), 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 | AAA SPI | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | FA SPI | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | MN-FA Encoded Key data ... 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 1: The Unsolicited MN-FA Key From AAA 193 Subtype-Specific Data 195 AAA SPI A 32-bit opaque value, indicating the SPI that the 196 mobile node must use to determine the algorithm to use 197 for recovering the FA security information. 199 FA SPI A 32-bit opaque value, which the mobile node MUST use 200 to index all the necessary information recovered from 201 the FA security information after it is decoded. 203 MN-FA Encoded Key data 204 The necessary information (including the key) required 205 by the mobile node to create a Mobility Security 206 Assocation between itself and the foreign agent. 208 The Unsolicited MN-FA Key From AAA extension, shown in figure 1, uses 209 subtype 7 of the Generalized MN-FA Key Reply Extension [8]. The key 210 is encoded by the home domain AAA server (AAAH) for use by the mobile 211 node to secure future Mobile IP registrations with the same foreign 212 agent. The Unsolicited MN-FA Key From AAA extension MUST appear in 213 the Registration Reply before the MN-FA Authentication extension. 215 Once the mobile node decodes the FA Security Information, by using 216 the algorithm indexed by the AAA SPI, it stores the FA Security 217 Information indexed by the FA SPI in its list of Mobile Security 218 Associations. 220 If the foreign agent receives a Registration Reply that does not 221 have a Unsolicited MN-FA Key From AAA extension, and thus does not 222 have a way to establish a Mobility Security Association with the 223 mobile node, the foreign agent SHOULD change the Code value of the 224 Registration Reply to MISSING_MN_FA (see section 7), effectively 225 causing the registration to fail. 227 5. Generalized MN-HA Key Reply Extension 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type | Subtype | Length | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Lifetime | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Registration Key Distribution Data ... 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Figure 2: The Generalized Mobile IP MN-HA Key Reply Extension 241 Type 42 (not skippable) (see [7]) 243 Subtype a number assigned to identify the way in which the 244 Encoded Registration Key Data is to be decrypted 245 to obtain the registration key 247 Length The 16-bit Length field indicates the length of 248 the extension. It is equal to 4 plus the number 249 of bytes in the Encoded Registration Key Data. 251 Lifetime This field indicates the duration of time (in 252 seconds) for which the MH-HA key is valid. 254 Registration Key Distribution Data 255 An encrypted copy of the registration key, along 256 with any other information needed by the mobile 257 node to create the designated Mobility Security 258 Association with the home agent. 260 6. Unsolicited MN-HA Key From AAA Subtype 262 The Unsolicited MN-HA Key From AAA is subtype 1 of the Generalized 263 MN-HA Key Reply Extension (see section 5). 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | AAA SPI | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | HA SPI | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | MN-HA Encoded Key data ... 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Figure 3: The Unsolicited MN-HA Key From AAA 276 Subtype-Specific Data 278 AAA SPI A 32-bit opaque value, indicating the SPI that the 279 mobile node must use to determine the algorithm to use 280 for recovering the HA security information. 282 HA SPI A 32-bit opaque value, which the mobile node MUST use 283 to index all the necessary information recovered from 284 the HA security information after it is decoded. 286 MN-HA Encoded Key data 287 The necessary information (including the key) required 288 by the mobile node to create a Mobility Security 289 Assocation between itself and the home agent. 291 The Unsolicited MN-HA Key From AAA subtype-specific data is shown 292 in figure 3. The Mobile Node Encoded Key data is to be decoded 293 according to the given SPI between the mobile node and the home 294 domain AAA server (AAAH). The key is intended for use the mobile node 295 to secure future Mobile IP registrations with its home agent. The 296 MN-HA Key Reply MUST appear in the Registration Reply before the 297 MN-HA Authentication extension. 299 Once the mobile node decodes the MN-HA Encoded Key data, by using 300 the algorithm indexed by the AAA SPI, it stores the HA Security 301 Information indexed by the HA SPI in its list of Mobile Security 302 Associations. The mobile node uses the Identification field data 303 from the Registration Request as its initial synchronization data 304 with the home agent. 306 7. Error Values 308 Each entry in the following table contains the name of Code [7] to 309 be returned in a Registration Reply, the value for the Code, and the 310 section in which the error is first mentioned in this specification. 312 Error Name Value Section 313 ---------------------- ----- --------- 314 MISSING_MN_FA 107 4 316 8. IANA Considerations 318 The number for the Generalized MN-HA Key Reply Extension is 319 taken from the numbering space defined for Mobile IP registration 320 extensions defined in RFC 2002 [7] as extended in RFC 2356 [6]. 322 The subtype address space for the Generalized MN-HA Key Reply 323 extension is defined in this document. From this space, subtype 324 value 1 is assigned to the Unsolicited MN-HA Key From AAA Subtype 325 extension. 327 The number assigned to the Unsolicited MN-FA Key From AAA Subtype 328 extension was taken from the numbering space defined for the 329 Generalized MN-FA Key Reply Extension, defined in [8]. 331 The Code values specified for errors, listed in section 7, MUST NOT 332 conflict with any other code values listed in RFC 2002, RFC 2344 [5], 333 or RFC 2356 [6]. They are to be taken from the space of error values 334 conventionally associated with rejection by the foreign agent (i.e., 335 64-127). 337 SPI values 3 and 4 are taken from the reserved space of SPI numbers 338 (0-255) created for special Mobile IP algorithm identifiers. 340 9. Security Considerations 342 The extensions in this document are intended to provide the 343 appropriate level of security for Mobile IP entities (mobile node, 344 foreign agent, and home agent) to operate Mobile IP registration 345 protocol. The security associations resulting from use of these 346 extensions do not offer any higher level of security than what is 347 already implicit in use of the security association between the 348 mobile node and the AAA. 350 References 352 [1] B. Aboba and M. Beadles. The Network Access Identifier. Request 353 for Comments (Proposed Standard) 2486, Internet Engineering Task 354 Force, January 1999. 356 [2] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 357 Challenge/Response Extension. 358 draft-ietf-mobileip-challenge-08.txt, January 2000. (work in 359 progress). 361 [3] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER Base 362 Protocol. Internet Draft, Internet Engineering Task Force. 363 draft-calhoun-diameter-12.txt, December 1999. Work in progress. 365 [4] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for 366 Message Authentication. Request for Comments (Informational) 367 2104, Internet Engineering Task Force, February 1997. 369 [5] G. Montenegro. Reverse Tunneling for Mobile IP. Request for 370 Comments (Proposed Standard) 2344, Internet Engineering Task 371 Force, May 1998. 373 [6] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 374 Mobile IP. Request for Comments (Informational) 2356, Internet 375 Engineering Task Force, June 1998. 377 [7] C. Perkins. IP Mobility Support. Request for Comments (Proposed 378 Standard) 2002, Internet Engineering Task Force, October 1996. 380 [8] C. Perkins and D. Johnson. Registration Keys for Route 381 Optimization. Internet Draft, Internet Engineering Task Force, 382 December 1997. Work in progress. 384 [9] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 385 Authentication Dial In User Service (RADIUS). Request for 386 Comments (Proposed Standard) 2138, Internet Engineering Task 387 Force, April 1997. 389 Addresses 391 The working group can be contacted via the current chairs: 393 Basavaraj Patil Phil Roberts 394 Nortel Networks Inc. Motorola 395 2201 Lakeside Blvd. 1501 West Shure Drive 396 Richardson, TX. 75082-4399 Arlington Heights, IL 60004 397 USA USA 398 Phone: +1 972-684-1489 Phone: +1 847-632-3148 399 EMail: bpatil@nortelnetworks.com EMail: QA3445@email.mot.com 401 Questions about this memo can also be directed to the authors: 403 Charles E. Perkins Pat R. Calhoun 404 Communications Systems Lab Network & Security Center 405 Nokia Research Center Sun Microsystems Laboratories 406 313 Fairchild Drive 15 Network Circle 407 Mountain View, California 94043 Menlo Park, California 94025 408 USA USA 409 Phone: +1-650 625-2986 Phone: +1 650-786-7733 410 EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com 411 Fax: +1 650 625-2502 Fax: +1 650-786-6445