idnits 2.17.1 draft-calhoun-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: ---------------------------------------------------------------------------- ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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 116: '... extension MUST also contain a subse...' RFC 2119 keyword, line 119: '...former extension MUST come first. Lik...' RFC 2119 keyword, line 121: '... the former extension MUST come first....' RFC 2119 keyword, line 168: '...all mobile nodes MUST be able to verif...' RFC 2119 keyword, line 195: '...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: 11 errors (**), 0 flaws (~~), 4 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 22 October 1999 Pat R. Calhoun 4 Sun Microsystems Laboratories 6 AAA Registration Keys for Mobile IP 7 draft-calhoun-mobileip-aaa-key-00.txt 9 Status of This Memo 11 This document is an individual submission to the mobile-ip Working 12 Group of the Internet Engineering Task Force (IETF). Comments should 13 be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing 14 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 32 The list of Internet-Draft Shadow Directories can be accessed at: 33 http://www.ietf.org/shadow.html. 35 Abstract 37 AAA servers, such as RADIUS and DIAMETER, are in use within the 38 Internet today to provide authentication and authorization services 39 for dial-up computers. Mobile IP requires strong authentication 40 between the mobile node and its home agent. When the mobile node 41 shares a security association with its home AAA server, however, it 42 is possible to use that security association to create derivative 43 security associations between the mobile node and its home agent, 44 and again between the mobile node and the foreign agent currently 45 offering a care-of address to the mobile node. This document 46 specifies extensions to the Mobile IP Registration Reply packet that 47 can be used to distribute such security information to the mobile 48 node. 50 1. Introduction 52 AAA servers, such as RADIUS [8] and DIAMETER [2], are in use within 53 the Internet today to provide authentication and authorization 54 services for dial-up computers. Such services are likely to be 55 equally valuable for mobile nodes using Mobile IP when the nodes are 56 attempting to connect to foreign domains with AAA servers. Mobile 57 IP [7] requires strong authentication between the mobile node and its 58 home agent. When the mobile node shares a security association with 59 its home AAA server, however, it is possible to use that security 60 association to create derivative security associations between the 61 mobile node and its home agent, and again between the mobile node 62 and the foreign agent currently offering a care-of address to the 63 mobile node. This document specifies extensions to the Mobile 64 IP Registration Reply packet that can be used to distribute such 65 security information to the mobile node. 67 AAA servers typically use the Network Access Identifier (NAI) [1] to 68 uniquely identify the mobile node; the mobile node's home address 69 is not always necessary to provide that function. Thus, it is 70 possible for a mobile node to authenticate itself, and be authorized 71 for connection to the foreign domain, without even having a home 72 address. However, for Mobile IP to work, the mobile node is required 73 to have a security association with its home agent. When the 74 Mobile IP Registration Reply packet is authenticated by the MN-AAA 75 Authentication Extension [?], the mobile node can verify that the 76 keys contained in the extensions were produced by the AAA server, and 77 thus may be reliably used to create security associations with the 78 home agent, or alternatively with the foreign agent. 80 The following operations are envisioned between the mobile node, AAA 81 server, home agent, and foreign agent. 83 1. When a mobile node travels away from home, it may not have a 84 security association with its home agent, perhaps because it does 85 not yet have a home address. 87 2. When the mobile node first registers away from home, it includes 88 a MN-AAA Authentication extension if it does not yet have a 89 Mobility Security Association with a home agent. 91 3. At the time the information within the MN-AAA Authentication 92 extension is verified by the AAA server, the AAA server also 93 generates keys for the mobile node, encodes the keys according 94 to its own security association with the mobile node, and causes 95 insertion of the new key or keys along with the Registration 96 Reply. 98 4. When the mobile node receives the Registration Reply message, it 99 verifies the authenticity (and integrity) of the reply message 100 by using information provided in the MN-AAA Authentication 101 extension. 103 5. If the Reply passes authentication and contains the MN-HA Key 104 extension (see section 4), the mobile node decodes the key 105 according to its security association with the AAA. The resulting 106 key is used to establish the mobile node's security association 107 with its home agent. 109 6. Similarly, if the Reply passes authentication and contains the 110 MN-FA Key extension (see section 5), the mobile node decodes 111 the key according to its security association with the AAA. The 112 resulting key is used to establish the mobile node's security 113 association with its new foreign agent. 115 Any message containing the MN-HA Key extension or the MN-FA Key 116 extension MUST also contain a subsequent MN-AAA Authentication 117 Extension. If a Registration Reply message contains both a MN-HA 118 Key extension and a Mobile-Home Authentication extension, the 119 former extension MUST come first. Likewise, if a Registration Reply 120 message contains both a MN-FA Key extension and a Mobile-Foreign 121 Authentication extension, the former extension MUST come first. 123 2. Security Algorithms 125 Mobility Security Associations between Mobile IP entities 126 (mobile nodes, home agents, foreign agents) contain both the 127 necessary cryptographic key information, and a way to identify 128 the cryptographic algorithm which uses the key to produce the 129 authentication information typically included in the Mobile Home 130 Authentication extension or the Mobile Foreign Authentication 131 extension. In order for the mobile node to make use of key 132 information sent to it by the AAA server, the mobile node also has to 133 be able to select the appropriate cryptographic algorithm that uses 134 the key to produce the authentication. 136 For use with the key extensions specified in this document, a table 137 of security algorithm identifiers is also specified. This table is 138 intended to conform to the table of reserved SPIs from RFC 2002, and 139 to allocate some of the currently unused reserved numbers to identify 140 certain common algorithm identifiers. 142 Algorithm identifier 0 is taken to mean that the mobile node 143 and the AAA server share only one security association, and that 144 unique security association is the one by which the mobile node is 145 instructed to decode the key information in the MN-HA or the MN-FA 146 Key extension. 148 Other numbers are defined as follows: 150 Algorithm Identifier Name Reference 151 --------------------- ------------------ ------------ 152 2 MD5/prefix+suffix RFC 2002 [7] 153 3 HMAC MD5 RFC 2104 [3] 155 New identifiers will be allocated as indicated by practical 156 experience using the extensions defined in this document. See 157 section 3 for specific information about using Algorithm Identifier 158 2. Algorithm Identifier 3 is used in exactly the same way, except 159 that the specific computation used with MD5 follows RFC 2104 instead 160 of RFC 2002. 162 3. Using Algorithm Identifier 2: MD5/prefix+suffix 164 The AAA indicates that the mobile node must use MD5 in prefix+suffix 165 mode to recover the key information, by inserting the value 2 into 166 the Algorithm Identifier field of the Key extension. 168 As with Mobile IP, all mobile nodes MUST be able to verify the 169 authenticator within a MN-AAA Authentication extension by using 170 MD5 in prefix+suffix mode, signified by selection at a SPI of any 171 arbitrary 32-bit value. Therefore, it is economical to use the 172 MD5 algorithm in prefix+suffix mode to encode the key within the 173 particular key extension, as follows. 175 1. The AAA server identifies the mobile node's IP address, call it 176 ``node-address''. 178 2. The AAA server calculates 179 (key XOR (MD5(AAA-key | node-address | AAA-key))) 181 3. The AAA server inserts this result into the Key extension in the 182 ``Security Information'' field. 184 4. The mobile node calculates 185 temp = MD5(AAA-key | node-address | AAA-key) 187 5. The mobile node extracts the Security_Information of the key 188 extension and calculates 189 key = Security_Information XOR temp 191 4. MN-HA Key Extension 193 The MN-HA Key extension, shown in figure 1, contains the key for use 194 by the mobile node to secure future Mobile IP registrations with its 195 home agent. The MN-HA Key extension MUST appear in the Registration 196 Request before the MN-AAA Authentication extension. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Type | Length | Security Algorithm | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | AAA SPI | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | HA SPI | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | HA security information ... 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 1: The MN-HA Key Extension 212 Type 126 (not skippable) [7] 214 Length 10 plus the length in bytes of the HA security 215 information field 217 Security Algorithm A value in the table defined in section 2. 219 AAA SPI A 32-bit opaque value, indicating the SPI that the 220 mobile node must use to determine the algorithm to use 221 for recovering the HA security information. 223 HA SPI A 32-bit opaque value, which the mobile node MUST use 224 to index all the necessary information recovered from 225 the HA security information after it is decoded. 227 HA Security Information The necessary information (including the 228 key) required by the mobile node to create a Mobility 229 Security Assocation between itself and the home agent. 231 Once the mobile node decodes the HA Security Information, by 232 using the algorithm indexed by the AAA SPI, it stores the Security 233 Algorithm field, and the HA Security Information indexed by the HA 234 SPI in its list of Mobile Security Associations. 236 5. MN-FA Key Extension 238 The MN-FA Key extension, shown in figure 1, contains the key for use 239 by the mobile node to secure future Mobile IP registrations with 240 the same foreign agent. The MN-FA Key extension MUST appear in the 241 Registration Request before the MN-AAA Authentication extension. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type | Length | Security Algorithm | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | AAA SPI | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | FA SPI | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | FA security information ... 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 2: The MN-FA Key Extension 257 Type 133 (skippable) [7] 259 Length 10 plus the length in bytes of the FA security 260 information field 262 Security Algorithm A value in the table defined in section 2. 264 AAA SPI A 32-bit opaque value, indicating the SPI that the 265 mobile node must use to determine the algorithm to use 266 for recovering the FA security information. 268 FA SPI A 32-bit opaque value, which the mobile node MUST use 269 to index all the necessary information recovered from 270 the FA security information after it is decoded. 272 HA Security Information The necessary information (including the 273 key) required by the mobile node to create a Mobility 274 Security Assocation between itself and the foreign 275 agent. 277 Once the mobile node decodes the FA Security Information, by 278 using the algorithm indexed by the AAA SPI, it stores the Security 279 Algorithm field, and the FA Security Information indexed by the FA 280 SPI in its list of Mobile Security Associations. 282 If the foreign agent receives a Registration Reply that does not have 283 a MN-FA Key extension, and thus does not have a way to establish 284 a Mobility Security Association with the mobile node, the foreign 285 agent SHOULD change the Code value of the Registration Reply to 286 MISSING_MN_FA (see section 6), effectively causing the registration 287 to fail. 289 6. Error Values 291 Each entry in the following table contains the name of Code [7] to 292 be returned in a Registration Reply, the value for the Code, and the 293 section in which the error is first mentioned in this specification. 295 Error Name Value Section 296 ---------------------- ----- --------- 297 MISSING_MN_FA 106 5 299 7. IANA Considerations 301 The number for the MN-HA Key and MN-FA Key extensions are taken from 302 the numbering space defined for Mobile IP registration extensions 303 defined in RFC 2002 [7] as extended in RFC 2356 [5]. The numbering 304 for the extension also SHOULD NOT conflict with values specified in 305 the Internet Draft for Route Optimization [6] Mobile Node NAI ??, or 306 Foreign Agent Challenge extensions [?]. The Code values specified 307 for errors, listed in section 6, MUST NOT conflict with any other 308 code values listed in RFC 2002, RFC 2344 [4], or RFC 2356 [5]. 309 They are to be taken from the space of error values conventionally 310 associated with rejection by the foreign agent (i.e., 64-127). 312 8. Security Considerations 314 The extensions in this document are intended to provide the 315 appropriate level of security for Mobile IP entities (mobile node, 316 foreign agent, and home agent) to operate Mobile IP registration 317 protocol. The security associations resulting from use of these 318 extensions do not offer any higher level of security than what is 319 already associated with the security association between the mobile 320 node and the AAA. The security association with the AAA is the one 321 from which both the Mobile IP described in this draft are derived. 323 References 325 [1] B. Aboba and M. Beadles. RFC 2486: The Network Access 326 Identifier, January 1999. Status: PROPOSED STANDARD. 328 [2] P. Calhoun and A. Rubens. DIAMETER Base Protocol. 329 draft-calhoun-diameter-07.txt, November 1998. (work in 330 progress). 332 [3] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing 333 for Message Authentication. RFC 2104, February 1997. 335 [4] G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, May 336 1998. 338 [5] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 339 Mobile IP. RFC 2356, June 1998. 341 [6] Charles E. Perkins and David B. Johnson. Route Optimization in 342 Mobile-IP. draft-ietf-mobileip-optim-08.txt, February 1999. 343 (work in progress). 345 [7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 346 1996. 348 [8] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 349 Authentication Dial In User Service (RADIUS). RFC 2138, April 350 1997. 352 Addresses 354 The working group can be contacted via the current chairs: 356 Basavaraj Patil Phil Roberts 357 Nortel Networks Inc. Motorola 358 2201 Lakeside Blvd. 1501 West Shure Drive 359 Richardson, TX. 75082-4399 Arlington Heights, IL 60004 360 USA USA 362 Phone: +1 972-684-1489 Phone: +1 847-632-3148 363 EMail: bpatil@nortelnetworks.com EMail: QA3445@email.mot.com 365 Questions about this memo can be directed to: 367 Charles E. Perkins Pat R. Calhoun 368 Nokia Research Center Sun Microsystems Laboratories 369 313 Fairchild Drive 15 Network Circle 370 Mountain View, California 94043 Menlo Park, California 94025 371 USA USA 373 Phone: +1-650 625-2986 Phone: +1 650-786-7733 374 EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com 375 Fax: +1 650 691-2170 Fax: +1 650-786-6445