idnits 2.17.1 draft-ietf-mobileip-aaa-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 115: '... extension MUST also contain a subse...' RFC 2119 keyword, line 118: '...former extension MUST come first. Lik...' RFC 2119 keyword, line 120: '... the former extension MUST come first....' RFC 2119 keyword, line 167: '...all mobile nodes MUST be able to verif...' RFC 2119 keyword, line 194: '...HA Key extension MUST appear in the Re...' (6 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-07 -- Possible downref: Normative reference to a draft: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '3') ** Obsolete normative reference: RFC 2344 (ref. '4') (Obsoleted by RFC 3024) ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '5') == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-08 -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2002 (ref. '7') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2138 (ref. '8') (Obsoleted by RFC 2865) Summary: 12 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 Sun Microsystems Laboratories 3 15 June 1999 Pat R. Calhoun 4 Sun Microsystems Laboratories 6 AAA Registration Keys for Mobile IP 7 draft-ietf-mobileip-aaa-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@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 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 [8] and DIAMETER [2], 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 [?], 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. When the mobile node receives the Registration Reply message, it 98 verifies the authenticity (and integrity) of the reply message 99 by using information provided in the MN-AAA Authentication 100 extension. 102 5. If the Reply passes authentication and contains the MN-HA Key 103 extension (see section 4), the mobile node decodes the key 104 according to its security association with the AAA. The resulting 105 key is used to establish the mobile node's security association 106 with its home agent. 108 6. Similarly, if the Reply passes authentication and contains the 109 MN-FA Key extension (see section 5), the mobile node decodes 110 the key according to its security association with the AAA. The 111 resulting key is used to establish the mobile node's security 112 association with its new foreign agent. 114 Any message containing the MN-HA Key extension or the MN-FA Key 115 extension MUST also contain a subsequent MN-AAA Authentication 116 Extension. If a Registration Reply message contains both a MN-HA 117 Key extension and a Mobile-Home Authentication extension, the 118 former extension MUST come first. Likewise, if a Registration Reply 119 message contains both a MN-FA Key extension and a Mobile-Foreign 120 Authentication extension, the former extension MUST come first. 122 2. Security Algorithms 124 Mobility Security Associations between Mobile IP entities 125 (mobile nodes, home agents, foreign agents) contain both the 126 necessary cryptographic key information, and a way to identify 127 the cryptographic algorithm which uses the key to produce the 128 authentication information typically included in the Mobile Home 129 Authentication extension or the Mobile Foreign Authentication 130 extension. In order for the mobile node to make use of key 131 information sent to it by the AAA server, the mobile node also has to 132 be able to select the appropriate cryptographic algorithm that uses 133 the key to produce the authentication. 135 For use with the key extensions specified in this document, a table 136 of security algorithm identifiers is also specified. This table is 137 intended to conform to the table of reserved SPIs from RFC 2002, and 138 to allocate some of the currently unused reserved numbers to identify 139 certain common algorithm identifiers. 141 Algorithm identifier 0 is taken to mean that the mobile node 142 and the AAA server share only one security association, and that 143 unique security association is the one by which the mobile node is 144 instructed to decode the key information in the MN-HA or the MN-FA 145 Key extension. 147 Other numbers are defined as follows: 149 Algorithm Identifier Name Reference 150 --------------------- ------------------ ------------ 151 2 MD5/prefix+suffix RFC 2002 [7] 152 3 HMAC MD5 RFC 2104 [3] 154 New identifiers will be allocated as indicated by practical 155 experience using the extensions defined in this document. See 156 section 3 for specific information about using Algorithm Identifier 157 2. Algorithm Identifier 3 is used in exactly the same way, except 158 that the specific computation used with MD5 follows RFC 2104 instead 159 of RFC 2002. 161 3. Using Algorithm Identifier 2: MD5/prefix+suffix 163 The AAA indicates that the mobile node must use MD5 in prefix+suffix 164 mode to recover the key information, by inserting the value 2 into 165 the Algorithm Identifier field of the Key extension. 167 As with Mobile IP, all mobile nodes MUST be able to verify the 168 authenticator within a MN-AAA Authentication extension by using 169 MD5 in prefix+suffix mode, signified by selection at a SPI of any 170 arbitrary 32-bit value. Therefore, it is economical to use the 171 MD5 algorithm in prefix+suffix mode to encode the key within the 172 particular key extension, as follows. 174 1. The AAA server identifies the mobile node's IP address, call it 175 ``node-address''. 177 2. The AAA server calculates 178 (key XOR (MD5(AAA-key | node-address | AAA-key))) 180 3. The AAA server inserts this result into the Key extension in the 181 ``Security Information'' field. 183 4. The mobile node calculates 184 temp = MD5(AAA-key | node-address | AAA-key) 186 5. The mobile node extracts the Security_Information of the key 187 extension and calculates 188 key = Security_Information XOR temp 190 4. MN-HA Key Extension 192 The MN-HA Key extension, shown in figure 1, contains the key for use 193 by the mobile node to secure future Mobile IP registrations with its 194 home agent. The MN-HA Key extension MUST appear in the Registration 195 Request before the MN-AAA Authentication extension. 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 | Type | Length | Security Algorithm | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | AAA SPI | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | HA SPI | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | HA security information ... 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 1: The MN-HA Key Extension 211 Type 126 (not skippable) [7] 213 Length 10 plus the length in bytes of the HA security 214 information field 216 Security Algorithm A value in the table defined in section 2. 218 AAA SPI A 32-bit opaque value, indicating the SPI that the 219 mobile node must use to determine the algorithm to use 220 for recovering the HA security information. 222 HA SPI A 32-bit opaque value, which the mobile node MUST use 223 to index all the necessary information recovered from 224 the HA security information after it is decoded. 226 HA Security Information The necessary information (including the 227 key) required by the mobile node to create a Mobility 228 Security Assocation between itself and the home agent. 230 Once the mobile node decodes the HA Security Information, by 231 using the algorithm indexed by the AAA SPI, it stores the Security 232 Algorithm field, and the HA Security Information indexed by the HA 233 SPI in its list of Mobile Security Associations. 235 5. MN-FA Key Extension 237 The MN-FA Key extension, shown in figure 1, contains the key for use 238 by the mobile node to secure future Mobile IP registrations with 239 the same foreign agent. The MN-FA Key extension MUST appear in the 240 Registration Request before the MN-AAA Authentication extension. 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Type | Length | Security Algorithm | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | AAA SPI | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | FA SPI | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | FA security information ... 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 2: The MN-FA Key Extension 256 Type 133 (skippable) [7] 258 Length 10 plus the length in bytes of the FA security 259 information field 261 Security Algorithm A value in the table defined in section 2. 263 AAA SPI A 32-bit opaque value, indicating the SPI that the 264 mobile node must use to determine the algorithm to use 265 for recovering the FA security information. 267 FA SPI A 32-bit opaque value, which the mobile node MUST use 268 to index all the necessary information recovered from 269 the FA security information after it is decoded. 271 HA Security Information The necessary information (including the 272 key) required by the mobile node to create a Mobility 273 Security Assocation between itself and the foreign 274 agent. 276 Once the mobile node decodes the FA Security Information, by 277 using the algorithm indexed by the AAA SPI, it stores the Security 278 Algorithm field, and the FA Security Information indexed by the FA 279 SPI in its list of Mobile Security Associations. 281 If the foreign agent receives a Registration Reply that does not have 282 a MN-FA Key extension, and thus does not have a way to establish 283 a Mobility Security Association with the mobile node, the foreign 284 agent SHOULD change the Code value of the Registration Reply to 285 MISSING_MN_FA (see section 6), effectively causing the registration 286 to fail. 288 6. Error Values 290 Each entry in the following table contains the name of Code [7] to 291 be returned in a Registration Reply, the value for the Code, and the 292 section in which the error is first mentioned in this specification. 294 Error Name Value Section 295 ---------------------- ----- --------- 296 MISSING_MN_FA 106 5 298 7. IANA Considerations 300 The number for the MN-HA Key and MN-FA Key extensions are taken from 301 the numbering space defined for Mobile IP registration extensions 302 defined in RFC 2002 [7] as extended in RFC 2356 [5]. The numbering 303 for the extension also SHOULD NOT conflict with values specified in 304 the Internet Draft for Route Optimization [6] Mobile Node NAI ??, or 305 Foreign Agent Challenge extensions [?]. The Code values specified 306 for errors, listed in section 6, MUST NOT conflict with any other 307 code values listed in RFC 2002, RFC 2344 [4], or RFC 2356 [5]. 308 They are to be taken from the space of error values conventionally 309 associated with rejection by the foreign agent (i.e., 64-127). 311 8. Security Considerations 313 The extensions in this document are intended to provide the 314 appropriate level of security for Mobile IP entities (mobile node, 315 foreign agent, and home agent) to operate Mobile IP registration 316 protocol. The security associations resulting from use of these 317 extensions do not offer any higher level of security than what is 318 already associated with the security association between the mobile 319 node and the AAA. The security association with the AAA is the one 320 from which both the Mobile IP described in this draft are derived. 322 References 324 [1] B. Aboba and M. Beadles. RFC 2486: The Network Access 325 Identifier, January 1999. Status: PROPOSED STANDARD. 327 [2] P. Calhoun and A. Rubens. DIAMETER Base Protocol. 328 draft-calhoun-diameter-07.txt, November 1998. (work in 329 progress). 331 [3] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing 332 for Message Authentication. RFC 2104, February 1997. 334 [4] G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, May 335 1998. 337 [5] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 338 Mobile IP. RFC 2356, June 1998. 340 [6] Charles E. Perkins and David B. Johnson. Route Optimization in 341 Mobile-IP. draft-ietf-mobileip-optim-08.txt, February 1999. 342 (work in progress). 344 [7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 345 1996. 347 [8] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 348 Authentication Dial In User Service (RADIUS). RFC 2138, April 349 1997. 351 Addresses 353 The working group can be contacted via the current chairs: 355 Erik Nordmark Basavaraj Patil 356 Sun Microsystems, Inc. Nortel Networks Inc. 357 17 Network Circle 2201 Lakeside Blvd. 358 Menlo Park, California 94025 Richardson, TX. 75082-4399 359 USA USA 361 Phone: +1 650 786-5166 +1 972-684-1489 362 Fax: +1 650 786-5896 363 E-mail: nordmark@sun.com bpatil@nortelnetworks.com 365 Questions about this memo can be directed to: 367 Charles E. Perkins Pat R. Calhoun 368 Sun Microsystems Laboratories Sun Microsystems Laboratories 369 15 Network Circle 15 Network Circle 370 Menlo Park, California 94025 Menlo Park, California 94025 371 USA USA 373 Phone: +1-650 786-6464 Phone: +1 650-786-7733 374 EMail: cperkins@eng.sun.com EMail: pcalhoun@eng.sun.com 375 Fax: +1 650 786-6445