idnits 2.17.1 draft-ietf-mobileip-aaa-key-13.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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 196: '..., the AAA server MAY provide unsolicit...' RFC 2119 keyword, line 197: '... the mobile node MUST then calculate n...' RFC 2119 keyword, line 222: '...oreign agent, it SHOULD include an MN-...' RFC 2119 keyword, line 227: '...e home agent, it MUST add an MN-HA Key...' RFC 2119 keyword, line 232: '... mobile node MUST add the MN-AAA A...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 420 has weird spacing: '...Subtype a n...' == Line 510 has weird spacing: '...Subtype a n...' ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [2], but that reference does not seem to mention RFC 2119 either. -- 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) ** Obsolete normative reference: RFC 3012 (ref. '4') (Obsoleted by RFC 4721) == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-15 ** Obsolete normative reference: RFC 1750 (ref. '6') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 2977 (ref. '7') ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 3127 (ref. '9') ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '11') ** Obsolete normative reference: RFC 2434 (ref. '12') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3344 (ref. '13') (Obsoleted by RFC 5944) Summary: 17 errors (**), 0 flaws (~~), 4 warnings (==), 2 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 June 2003 Pat R. Calhoun 4 Airespace Systems 6 AAA Registration Keys for Mobile IP 7 draft-ietf-mobileip-aaa-key-13.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@sunroof.eng.sun.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 an AAA Security Association with its home AAA server, however, 40 it is possible to use that AAA Security Association to create derived 41 Mobility Security Associations between the mobile node and its home 42 agent, and again between the mobile node and the foreign agent 43 currently offering connectivity to the mobile node. This document 44 specifies extensions to Mobile IP registration messages that can be 45 used to create Mobility Security Associations between the mobile node 46 and its home agent, and/or between the mobile node and a foreign 47 agent. 49 1. Introduction 51 AAA servers, such as RADIUS [14] and DIAMETER [5], 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 valuable for mobile nodes using Mobile IP [13] when the nodes 55 are attempting to connect to foreign domains with AAA servers. 56 Requirements for interactions between AAA and Mobile IP are outlined 57 in RFC 2977 [7]; that document describes an infrastructure which 58 enables AAA servers to authenticate and authorize network access 59 requests from mobile nodes. See also appendix C. The Mobile IP 60 Registration Request is considered to be a request for network 61 access. It is then possible to augment the functionality of the 62 Mobile IP mobility agents so that they can translate between Mobile 63 IP registration messages and the messages used within the AAA 64 infrastructure, as described in RFC 2977. Mobility agents and 65 AAA servers that conform to the requirements of RFC 2977 can be 66 considered as appropriate network entities to support the message 67 types specified in this document. Please consult RFC 2977 [7] for 68 further details. 70 This specification makes use of a single AAA Security Association 71 to create derivative Mobility Security Associations. A Mobility 72 Security Association in this specification is a simplex connection 73 that serves to authenticate MIPv4 control traffic between a MN and HA 74 and/or a MN and FA. A Mobility Security Association is identified by 75 the two end points, such as a MN IP address and a HA IP address, and 76 a SPI. Two nodes may have one or more Mobility Security Associations 77 established between each other; however, typically there is no reason 78 to have more than one Mobility Security Association between two 79 nodes. 81 This document specifies extensions to Mobile IP registration messages 82 that can be used to create Mobiity Security Associations between the 83 MN and FA and/or MN and HA based on the AAA Security Association 84 between the MN and HAAA. These additional Mobility Security 85 Associations may then be used in Mobile IP extensions to calculate 86 the Authentication Data need by authentication extensions used in 87 Mobile IP control messages. It is assumed that the AAA Security 88 Association between the MN and its HAAA has been appropriately 89 configured so that the AAA server has the authorization to provide 90 key material to be used as the basis for the necessary Mobility 91 Security Assocation between the MN and its prospective mobility 92 agents. 94 AAA servers typically use the Network Access Identifier (NAI) [1] to 95 uniquely identify the mobile node; the mobile node's home address is 96 not always necessary to provide that function. Thus, it is possible 97 for a mobile node to authenticate itself, and be authorized for 98 connection to the foreign domain, without having any home address. 99 However, for Mobile IP to work, the mobile node is required to have a 100 home address and a Mobility Security Association [13] with its home 101 agent. When the Mobile IP Registration Reply packet is authenticated 102 by the MN-AAA Authentication Extension [4], the mobile node can 103 verify that the key material contained in the extensions were 104 produced by the AAA server, and thus may be reliably used to create 105 Mobility Security Associations with the home agent, or alternatively 106 with the foreign agent. 108 It is also assumed that the AAA entities involved (i.e., the AAAH, 109 AAAL, and the AAA interface features of the foreign agents and home 110 agents) all have means outside of the scope of this document for 111 exchanging keys. The extensions within this document are intended to 112 work with any AAA protocol suite that allows for such key exchange, 113 as long as it satisfies the requirements specified in RFC 2977 [7]. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [2]. 121 AAA Authentication, Authorization, and Accounting 122 (see [9]). 124 AAA entity A network node processing AAA messages according to 125 the requirements for AAA protocols (see [9]). 127 AAA security association 128 A security association between a AAA entity 129 and another node needing the services of that 130 AAA entity. In this document all AAA security 131 associations are between a mobile node and its home 132 AAA server (AAAH). A mobile node's AAA security 133 association with its home AAA server (AAAH) may be 134 based either on the mobile node's IP address or on 135 its NAI [1]. 137 Key a number, kept secret. Only nodes in possession 138 of the key have any hope of using the security 139 transform to obtain correct results. 141 Key Material 142 Data used for the purpose of creating a key. 144 Mobility security association 145 A Mobility Security Association is a simplex 146 connection that serves to authenticate MIPv4 control 147 traffic such as between a MN and HA and/or a MN and 148 FA. A Mobility Security Association is identified 149 by the two end points, such as a MN IP address and 150 a HA IP address, and a SPI. Two nodes may have one 151 or more Mobility Security Associations established 152 between each other; however, typically there is 153 no reason to have more than one Mobility Security 154 Association between two nodes. 156 Registration Key 157 A key used as the basis of a Mobility Security 158 Association between a mobile node and a foreign 159 agent. A registration key is typically only used 160 once or a very few times, and only for the purposes 161 of verifying a small volume of Authentication data. 163 Security Algorithm 164 A set of rules for using input data and a secret key 165 for producing data for use in security protocols. 167 SPI 168 Security Parameters Index. The SPI is an arbitrary 169 32-bit value that assists in the identification of 170 an AAA, IP, or Mobility Security Association. 172 Other terminology is used as defined in the base Mobile IP 173 specification [13]. Furthermore, in order to simplify the 174 discussion, we have used the word "Extension" instead of "Subtype of 175 the Generalized Extension" in many cases. So, for instance, instead 176 of using the phrase "The MN-FA Key Material From AAA Subtype of the 177 Generalized MN-FA Key Reply Extension", we would instead use the 178 phrase "The MN-FA Key Material From AAA Extension". 180 3. Overview of Operations with Key Extensions 182 When a mobile node depends on an AAA infrastructure to obtain 183 authorization for network connectivity and Mobile IP registration, 184 it may lack any pre-existing Mobility Security Associations with 185 either its home agent, or the foreign agent controlling the access to 186 the foreign network. The extensions defined in this document allow 187 a AAA entity to supply key material to mobile nodes to be used as 188 the basis of its Mobility Security Association with mobile agents. 189 The AAA entity that will act on these extensions is part of the AAA 190 infrastructure, and is typically identified within the foreign domain 191 by methods outside the scope of this specification (see appendix C). 193 The key material may be requested by the mobile node in new 194 extensions to Mobile IP Registration Request messages, and supplied 195 to the mobile node in extensions to the Mobile IP Registration Reply 196 messages. Alternatively, the AAA server MAY provide unsolicited key 197 material to mobile nodes; the mobile node MUST then calculate new 198 keys and update or create its relevant Mobility Security Association. 199 The method by which key material is supplied to the mobility agents 200 themselves is out of scope for this document, and would depend on the 201 particular details of the security architecture for the AAA servers 202 in the foreign and home domains (see RFC 2977 and appendix C). For 203 the purposes of this document, we assume that there is a suitable AAA 204 infrastructure available to the foreign agents, and that the mobile 205 node does have an AAA Security Association with at least one AAA 206 server in its home domain. 208 When a mobile node travels away from home, it may not have a Mobility 209 Security Association with its home agent, perhaps because it does 210 not yet have a home address [3]. The protocol and messages in this 211 document are intended to facilitate the following operations which 212 may occur between the mobile node, foreign agent, home agent, and AAA 213 servers in the visited (local) domain (AAAL) and in the home domain 214 (AAAH). In the following sequence of messages, the only message flows 215 specified in this document are the Registration Request between the 216 mobile node and the foreign agent, and Registration Reply between the 217 foreign agent and the mobile node. The other messages described here 218 result from the presumed action of the AAA entities as described in 219 RFC 2977. See also appendix D. 221 1. If the mobile node does not have a Mobility Security Association 222 with the foreign agent, it SHOULD include an MN-FA Key Request 223 extension (see Section 7.1) as part of its Registration Request 224 that it sends to the Foreign Agent. 226 2. If the mobile node does not have a Mobility Security Association 227 with the home agent, it MUST add an MN-HA Key Request extension 228 (see Section 7.3) as part of its Registration Request that it 229 sends to the Foreign Agent. 231 3. If one or more AAA Key Request extensions were added, the 232 mobile node MUST add the MN-AAA Authentication extension to its 233 Registration Request after the AAA Key Request extension. 235 4. By action of the foreign agent, which is presumed to be also a 236 AAA entity, the mobile node's key requests and authentication 237 data are transferred to the local AAA server (AAAL), typically 238 after reformatting to fit into the appropriate AAA messages, 239 which are out of scope for this document. 241 5. After the information within the MN-AAA Authentication extension 242 is verified by the AAA server in the home domain (AAAH), it then 243 also generates the Key Material that has been requested by the 244 mobile node, for the necessary Mobility Security Associations. 246 6. The respective keys for the Mobility Security Associations are 247 distributed to the Home Agent and Foreign Agent via the AAA 248 protocol. 250 7. The mobile node receives the Registration Reply message from the 251 Foreign Agent. 253 8. If a MN-HA Key Material from AAA Key Material extension is 254 present in the Registration Reply message, then the mobile node 255 MUST create or update its Mobility Security Association with the 256 Home Agent indicated in the Registration Reply, using the key 257 computed from the Key Material in the AAA extension. In this 258 case, if no Key Material extension is present, the mobile node 259 MUST discard the Registration Reply. If the mobile node does 260 not already have a Mobility Security Association with the Home 261 Agent indicated in the Registration Reply message, and if no Key 262 Material extension is present, the mobile node MUST discard the 263 Registration Reply. 265 9. Using its (perhaps newly created) Mobility Security Association 266 with the home agent, the mobile node authenticates the 267 Registration Reply message, by checking the Authentication Data 268 in the Mobile-Home Authentication extension. 270 10. If the Registration Reply passes authentication and contains a 271 MN-FA Key Material From AAA extension (see section 7.2), the 272 mobile node generates the registration key using the Key Material 273 provided, according to its AAA security Association with the 274 AAA. The resulting registration key is used to establish the 275 mobile node's Mobility Security Association with its foreign 276 agent, and is used to compute the authentication data used in the 277 Mobile-Foreign authentication extension. 279 Any registration reply containing the MN-HA Key Material From AAA 280 extension MUST also contain a subsequent Mobile Home Authentication 281 extension, created using the generated MN-HA key. Similarly, a 282 reply containing the MN-FA Key Material From AAA extension MUST also 283 contain a subsequent Mobile Foreign Authentication extension, created 284 using the registration key. 286 4. Mobility Security Associations 288 Mobility Security Associations between Mobile IP entities 289 (mobile nodes, home agents, foreign agents) contain both the 290 necessary cryptographic key information, and a way to identify 291 the cryptographic transform which uses the key to produce the 292 authentication information which is present in the Mobile-Home 293 Authentication extension or the Mobile-Foreign Authentication 294 extension. In order for the mobile node to make use of key material 295 created by the AAA server, the mobile node also has to be able to 296 identify and select the appropriate cryptographic transform that uses 297 the key to produce the authentication. 299 The transform identifiers are the same as those used in IPsec. They 300 are tabulated in the list of Authentication Algorithms allowable 301 as values for the "Attribute Type" (5) (i.e., "Authentication 302 Algorithm"), one of the classifications in the tabulated 303 Attribute Types for "IPSEC Security Association Attributes". See 304 http://www.iana.org/assignments/isakmp-registry for the full listing 305 of all Attribute Types and other Attributes for IPSEC Security 306 Associations. 308 Mobility Security Associations shared between mobile nodes and home 309 agents also require a replay protection method. The following table 310 contains the supported replay methods. 312 Replay Method Name Reference 313 -------------- ------------ -------------- 314 0,1 Reserved 315 2 Timestamps RFC 3344 [13] 316 3 Nonces RFC 3344 [13] 317 4-65535 Unallocated 319 5. Key Material Creation and Derivation 321 This section contains the procedures followed in the creation of 322 the Key Material by AAA servers, and the key derivation procedures 323 used by mobile nodes. Note that the AAA servers will also deliver 324 the keys to the mobility agents (home agent, foreign agent) via the 325 AAA protocol. AAA servers that follow these procedures will produce 326 results that can be understood by mobile nodes. The mobility agents 327 will faithfully transcribe the results into the appropriate Mobile IP 328 extensions. 330 The example that follows makes use of HMAC-MD5 [8]. All mobile nodes 331 and mobility agents implementing Mobile IP [13], and implementing the 332 extensions specified in this document, MUST implement HMAC-MD5 [13]. 333 Other cryptographic functions MAY also be used. 335 The following steps are performed on the AAA server: 337 1. The AAA server identifies the mobile node. If the Home Address 338 field of the Registration Request is either zero (0), or all ones 339 (0xffffffff), then the Mobile Node's NAI is used instead of the 340 mobile node's home address. 342 2. The AAA server generates a random [6] value of at least 128 bits 343 to be used as the Key Material. 345 3. The AAA server inserts the random value into the Key Reply 346 extension, in the ``Key Material'' field. 348 The following steps are performed by the mobile node: 350 1. Using the Key Material from the extension, the mobile node 351 calculates 353 key = HMAC-MD5 (AAA-key, {Key Material || home address}) 355 2. The mobile node creates the Mobility Security Association, using 356 the key and the other relevant information in the Key Extension. 358 The secret key used within the HMAC-MD5 computation is indicated by 359 the AAA Security Association indexed by the AAA SPI, which has been 360 previously configured as the basis for the AAA Security Association 361 between the mobile node and the AAA server creating the key material. 363 6. Generalized Key Request/Reply Extensions 365 The extensions in this section are Generalized Extensions [13], and 366 have subtypes as specified in section 7. 368 6.1. Generalized MN-FA Key Request Extension 370 Figure 1 illustrates the Generalized MN-FA Key Request Extension. 372 Type TBD (not skippable) (see [13] and section 9) 374 Subtype a number assigned to identify the way in 375 which the Key Request Data is to be used when 376 generating the registration key 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Type | Subtype | Length | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Mobile Node SPI | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | MN-FA Key Request Subtype Data ... 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Figure 1: The Generalized Mobile IP MN-FA Key Request Extension 390 Length The 16-bit Length field indicates the length of 391 the extension. It is equal to the number of 392 bytes in the MN-FA Key Request Subtype Data plus 393 4 (for the Mobile Node SPI field). 395 Mobile Node SPI The Security Parameters Index that the mobile 396 node will assign for the Mobility Security 397 Association created for use with the registration 398 key. 400 MN-FA Key Request Subtype Data 401 Data needed to carry out the creation of the 402 registration key on behalf of the mobile node. 403 This field is zero in length and carries no data. 405 The Generalized MN-FA Key Request Extension defines a set of 406 extensions, identified by subtype, which may be used by a mobile node 407 in a Mobile IP Registration Request message to request that some 408 other entity create a Registration Key for use by the mobile node 409 with the mobile node's new foreign agent. 411 6.2. Generalized MN-FA Key Reply Extension 413 The Generalized MN-FA Key Reply extension supplies a registration key 414 requested by using one of the subtypes of the Generalized MN-FA Key 415 Request extension. Figure 2 illustrates the format Generalized MN-FA 416 Key Reply Extension. 418 Type TBD (not skippable) (see [13] and section 9) 420 Subtype a number assigned to identify the way in which the 421 MN-FA Key Reply Subtype Data is to be decrypted to 422 obtain the registration key 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Type | Subtype | Length | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | MN-FA Key Reply Subtype Data ... 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 2: The Generalized Mobile IP MN-FA Key Reply Extension 434 Length The 16-bit Length field is equal to the number of bytes 435 in the MN-FA Key Reply Subtype Data. 437 MN-FA Key Reply Subtype Data 438 An encoded copy of the registration key, along with any 439 other information needed by the recipient to create the 440 designated Mobility Security Association. 442 For each subtype, the format of the MN-FA Key Reply Subtype Data has 443 to be separately defined according to the particular method required 444 to set up the Mobility Security Association. 446 For the subtypes defined in this document, the MN-FA Key supplied 447 in the data for a subtype of this extension may come by a request 448 which was sent using a subtype of the Generalized MN-FA Key Request 449 Extension. In such cases, the SPI to be used when employing the 450 Mobility Security Association defined by the registration key is the 451 same as given in the original request. 453 Once the mobile node creates the Mobility Security Association with 454 the foreign agent, by using the transform indexed by the AAA SPI, it 455 stores that Mobility Security Association indexed by the FA SPI in 456 its list of Mobile Security Associations. 458 If the foreign agent receives a Registration Reply that has no MN-FA 459 Key Reply extension, and if it has no existing Mobility Security 460 Association with the mobile node, the foreign agent MAY change 461 the Code value of the Registration Reply to MISSING_MN_FA (see 462 section 8), effectively causing the registration to fail. 464 6.3. Generalized MN-HA Key Request Extension 466 Figure 3 illustrates the Generalized MN-HA Key Request Extension. 468 Type TBD (not skippable) (see [13] and section 9) 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Type | Subtype | Length | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Mobile Node SPI | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | MN-HA Key Request Subtype Data ... 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Figure 3: The Generalized Mobile IP MN-HA Key Request Extension 481 Subtype a number assigned to identify the way in 482 which the Key Request Data is to be used when 483 generating the registration key 485 Length The 16-bit Length field indicates the length of 486 the extension. It is equal to the number of 487 bytes in the MN-HA Key Request Subtype Data plus 488 4 (for the Mobile Node SPI field). 490 Mobile Node SPI The Security Parameters Index that the mobile 491 node will assign for the Mobility Security 492 Association created for use with the registration 493 key. 495 MN-HA Key Request Subtype Data 496 Data needed to carry out the creation of the 497 registration key on behalf of the mobile node. 498 This field is zero in length and carries no data. 500 The Generalized MN-HA Key Request Extension defines a set of 501 extensions, identified by subtype, which may be used by a mobile node 502 in a Mobile IP Registration Request message to request that some 503 other entity create a MN-HA key for use by the mobile node with the 504 mobile node's new home agent. 506 6.4. Generalized MN-HA Key Reply Extension 508 Type TBD (not skippable) (see [13] and section 9) 510 Subtype a number assigned to identify the way in which the 511 MN-HA Key Reply Subtype Data is to be decrypted to 512 obtain the MN-HA key 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Type | Subtype | Length | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Lifetime | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | MN-HA Key Reply Subtype Data ... 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Figure 4: The Generalized Mobile IP MN-HA Key Reply Extension 526 Length The 16-bit Length field indicates the length of the 527 extension. It is equal to the number of bytes in the 528 MN-HA Key Reply Subtype Data plus 4 (for the Lifetime 529 field). 531 Lifetime This field indicates the duration of time (in seconds) 532 for which the MN-HA key is valid. 534 MN-HA Key Reply Subtype Data 535 An encrypted copy of the MN-HA key, along with any 536 other information needed by the mobile node to create 537 the designated Mobility Security Association with the 538 home agent. 540 For each subtype, the format of the MN-HA Key Reply Subtype Data has 541 to be separately defined according to the particular method required 542 to set up the Mobility Security Association. 544 7. Key Request/Reply Subtypes 546 The extension subtypes in this section are subtypes of the 547 Generalized Extensions specified in section 6. 549 7.1. MN-FA Key Request From AAA Subtype 551 The MN-FA Key Request From AAA subtype data uses subtype 7 of the 552 Generalized MN-FA Key Request Extension (see section 6.1). The 553 MN-FA Key Request From AAA extension MUST appear in the Registration 554 Request before the MN-AAA Authentication extension. The subtype data 555 field is zero in length. 557 7.2. MN-FA Key Material From AAA Subtype 559 The MN-FA Key Material From AAA extension, shown in figure 5, 560 uses subtype 1 of the Generalized MN-FA Key Reply Extension (see 561 section 6.2). 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Lifetime | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | AAA SPI | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | FA SPI | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Algorithm Identifier | Key Material ... 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Figure 5: The MN-FA Key Material From AAA Subtype-Specific Data 577 lifetime This field indicates the duration of time (in seconds) 578 for which the registration key is valid. 580 AAA SPI A 32-bit opaque value, indicating the SPI that the 581 mobile node must use to determine the transform to use 582 for establishing the Mobility Security Association 583 between the mobile node and its prospective foreign 584 agent. 586 FA SPI The SPI for the Mobility Security Association to the FA 587 that the mobile node creates using the Key Material 589 Algorithm Identifier 590 This field indicates the transform to be used (stored 591 as part of the Mobility Security Association with 592 the foreign agent, and selected from among the 593 values in the "Authentication Algorithm" table 594 cited in section 4), for future computations of the 595 Mobile-Foreign Authentication Extension. 597 Key Material 598 A random [6] value of at least 128 bits. 600 The MN-FA Key Material From AAA extension MUST appear in the 601 Registration Reply before the Mobile-Foreign Authentication 602 extension. The Key Material is provided by the AAA server for use by 603 the mobile node in creating the registration key, which is used to 604 secure future Mobile IP registrations with the same foreign agent. 606 7.3. MN-HA Key Request From AAA Subtype 608 The MN-HA Key Request From AAA subtype data uses subtype 7 of the 609 Generalized MN-HA Key Request Extension (see section 6.3). The 610 MN-HA Key Request From AAA extension MUST appear in the Registration 611 Request before the MN-AAA Authentication extension. The subtype data 612 field is zero in length. 614 7.4. MN-HA Key Material From AAA Subtype 616 The MN-HA Key Material From AAA is subtype 7 of the Generalized MN-HA 617 Key Reply Extension (see section 6.4). 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | AAA SPI | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | HA SPI | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Algorithm Identifier | Replay Method | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Key Material ... 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Figure 6: The MN-HA Key Material From AAA Subtype-Specific Data 632 AAA SPI A 32-bit opaque value, indicating the SPI that the 633 mobile node must use to determine the transform to use 634 for establishing the Mobility Security Association 635 between the mobile node and its home agent. 637 HA SPI The SPI for the Mobility Security Association to the HA 638 that the mobile node creates using the Key Material 640 Algorithm Identifier 641 This field indicates the transform to be used for 642 future computations of the Mobile-Home Authentication 643 Extension (see section 4) 645 Replay Method 646 This field contains the replay method to be used for 647 future Registration messages (see section 4). 649 Key Material 650 A random [6] value of at least 128 bits. 652 The MN-HA Material Key From AAA subtype-specific data is shown in 653 figure 6. The Mobile Node calculates the MN-HA key using the Key 654 Material provided by the AAA server. The calculation proceeds by 655 using the key shared between the mobile node and the AAA server that 656 has previously been configured for securing all such communication 657 requirements with the AAA server which will be contacted within the 658 AAA infrastructure (see appendix C). The MN-HA key is intended for 659 use by the mobile node to secure future Mobile IP registrations with 660 its home agent. The MN-HA Key Material extension MUST appear in the 661 Registration Reply before the MN-HA Authentication extension. 663 Once the mobile node creates the MN-HA Key, by using the transform 664 specified in the AAA SPI, it stores the HA Security Information 665 indexed by the HA SPI in its list of Mobile Security Associations. 666 The mobile node uses the Identification field data from the 667 Registration Request as its initial synchronization data with the 668 home agent. 670 8. Error Values 672 Each entry in the following table contains the name of the Code [13] 673 value to be returned in a Registration Reply, the value for that 674 Code, and the section in which the error is first mentioned in this 675 specification. 677 Error Name Value Section 678 ---------------------- ----- --------- 679 MISSING_MN_FA 107 6.2 681 9. IANA Considerations 683 The numbers for the Generalized Extensions in section 6 are 684 taken from the numbering space defined for Mobile IP registration 685 extensions defined in RFC 3344 [13] as extended in RFC 2356 [11]. 686 The numbers suggested in this section are already in use by 687 implementations which have been tested for interoperability. 689 The number 7, assigned to the MN-FA Key Request From AAA Subtype 690 extension (see section 7.1), is taken from the numbering space 691 defined for the Generalized MN-FA Key Request Extension (see 692 section 6.1). 694 The number 1, assigned to the MN-FA Key Material From AAA Subtype 695 extension (see section 7.2), is taken from the numbering space 696 defined for the Generalized MN-FA Key Reply Extension (see 697 section 6.2). 699 The number 7, assigned to the MN-HA Key Request From AAA Subtype 700 extension (see section 7.4), is taken from the numbering space 701 defined for the Generalized MN-HA Key Request Extension (see 702 section 6.3). 704 The number 7, assigned to the MN-HA Key Material From AAA Subtype 705 extension (see section 7.4), is taken from the numbering space 706 defined for the Generalized MN-HA Key Reply Extension (see 707 section 6.4). 709 The Code value specified for error MISSING_MN_FA, listed in 710 section 8, MUST NOT conflict with any other code values listed in 711 RFC 3344, RFC 3024 [10], or RFC 2356 [11]. This value is to be 712 taken from the space of error values conventionally associated with 713 rejection by the foreign agent (i.e., 64-127). 715 Section 4 introduces the Replay Method Identifier namespace that 716 requires IANA management. This specification makes use of 1-3; 717 all other values other than zero (0) or one (1) are available for 718 assignment, pending review and approval by a Designated Expert [12]. 720 10. Security Considerations 722 The extensions in this document are intended to provide the 723 appropriate level of security for Mobile IP entities (mobile node, 724 foreign agent, and home agent) to calculate the Authentication Data 725 needed by authentication extensions used with Mobile IP registration 726 messages. The Mobility Security Associations resulting from use of 727 these extensions do not offer any higher level of security than what 728 is already implicit in use of the AAA Security Association between 729 the mobile node and the AAAH. In order to deny any adversary the 730 luxury of unbounded time to analyze and break the secrecy of the AAA 731 Security Association between the mobile node and the AAA server, that 732 AAA Security Association MUST be refreshed periodically. 734 The provisioning and refreshing of the AAA key in the MN and AAA 735 server is outside the scope of this document. Typical methods for 736 provisioning and refresh at the MN include the use of https between 737 the MN and a trusted provisioning server (e.g., over a wireless link 738 layer). Wireless standards organizations specify the details of the 739 wireless link operation, including authentication of the MN at the 740 link layer. 742 Since the extensions defined in this specification only carries Key 743 Material, which is used to derive keys, it does not expose any data 744 that could be used in an attack aimed at recovering the key shared 745 between the mobile node and the AAA. The authors do not believe this 746 specification introduces any new security vulnerability. 748 11. Acknowledgements 750 Thanks to Fredrik Johansson, Tom Hiller, and the members of the IESG 751 for their useful comments on this document. 753 References 755 [1] B. Aboba and M. Beadles. The Network Access Identifier. 756 Request for Comments (Proposed Standard) 2486, Internet 757 Engineering Task Force, January 1999. 759 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 760 Levels. Request for Comments (Best Current Practice) 2119, 761 Internet Engineering Task Force, March 1997. 763 [3] P. Calhoun and C. Perkins. Mobile IP Network Access Identifier 764 Extension for IPv4. Request for Comments (Proposed Standard) 765 2794, Internet Engineering Task Force, January 2000. 767 [4] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 768 Challenge/Response Extension. Request for Comments (Proposed 769 Standard) 3012, Internet Engineering Task Force, December 2000. 771 [5] Pat R. Calhoun, John Loughney, E. Guttman, Glen Zorn, 772 and Jari Arkko. DIAMETER Base Protocol (work in 773 progress). Internet Draft, Internet Engineering Task 774 Force. draft-ietf-aaa-diameter-15.txt, October 2002. 776 [6] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 777 Recommendations for Security. Request for Comments 778 (Informational) 1750, Internet Engineering Task Force, December 779 1994. 781 [7] S. Glass, T. Hiller, S. Jacobs, and C. Perkins. Mobile IP 782 Authentication, Authorization, and Accounting Requirements. 783 Request for Comments (Proposed Standard) 2977, Internet 784 Engineering Task Force, October 2000. 786 [8] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 787 for Message Authentication. Request for Comments 788 (Informational) 2104, Internet Engineering Task Force, 789 February 1997. 791 [9] D. Mitton, M. St.Johns, S. Barkley, D. Nelson, B. Patil, 792 M. Stevens, and B. Wolff. Authentication, Authorization, 793 and Accounting: Protocol Evaluation. Request for Comments 794 (Informational) 3127, Internet Engineering Task Force, June 795 2001. 797 [10] Editor G. Montenegro. Reverse Tunneling for Mobile IP, revised. 798 Request for Comments (Proposed Standard) 3024, Internet 799 Engineering Task Force, January 2001. 801 [11] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 802 Mobile IP. Request for Comments (Informational) 2356, Internet 803 Engineering Task Force, June 1998. 805 [12] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 806 Considerations Section in RFCs. Request for Comments (Best 807 Current Practice) 2434, Internet Engineering Task Force, October 808 1998. 810 [13] C. Perkins. IP Mobility Support. Request for Comments 811 (Proposed Standard) 3344, Internet Engineering Task Force, 812 August 2002. 814 [14] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 815 Authentication Dial In User Service (RADIUS). Request for 816 Comments (Proposed Standard) 2865, Internet Engineering Task 817 Force, June 2000. 819 A. Changes Since Previous Revision 821 - Cleaned up terminology: 823 * Clarified the use of "security association" throughout the 824 document as either "IPSec" or "Mobility" or "AAA". 826 B. Older Changes 828 In this revision of the document, there have been several major 829 changes as a result of suggestions received during Last Call. 831 - Generalized Key Extensions previously specified in another 832 document have been instead specified in this document in order 833 that this document can be self-contained and not dependent on the 834 standardization status of the other document. 836 - Additional explanation has been included for the purposes of 837 clarifying the problem space and solution approach. 839 - An appendix has been added to describe the expected AAA 840 infrastructure that will produce the keys that are to be 841 distributed within the extensions specified in this document. 843 - Ladder diagrams have been included to illustrate the expected 844 message flows containing the extensions defined in this document. 846 - HMAC-MD5 has been mandated for implementation by the mobile node, 847 for compatibility with RFC 3344 [13]. The example text has been 848 modified accordingly (see section 5). 850 - A table of Algorithm Identifiers has been identified as the 851 numbering space for transform selection when establishing the 852 Mobility Security Association using the keys distributed with the 853 extensions in this document. See section 4. 855 - A terminology section has been added. 857 - This appendix has been added. 859 * New terminology entries for "Registration Key", "AAA", "AAA 860 entity", "Mobility Security Association", "AAA Security 861 Association", 863 * All instances of MN-FA key are now called "registration key" 865 * All instances of the key between mobile node and home agent 866 are called "MN-HA" key. 868 - Removed extraneous IANA considerations paragraph for HMAC_MD5 870 - Removed "Unsolicited" from subtype names 872 - Changed minimum Key Material length from 64 bits to 128 bits 874 C. AAA Infrastructure 876 In this appendix, we attempt to capture the main features of a basic 877 model for operation of AAA servers that is assumed for understanding 878 of the use of the Mobile IP registration extensions described in this 879 document. This information has been adapted from the discussion in 880 RFC 2977 [7]. 882 Within the Internet, a mobile node belonging to one administrative 883 domain (called the home domain) often needs to use resources 884 provided by another administrative domain (called the foreign 885 domain). A foreign agent that handles the mobile node's Registration 886 Request is likely to require that the mobile node provide some 887 credentials that can be authenticated before access to the resources 888 is permitted. These credentials may be provided as part of the 889 Mobile-AAA Authentication extension [4], relying on the existence 890 of an AAA infrastructure such as is described in this section, and 891 also described in RFC 2977 and RFC 3012 [4]. Such credentials are 892 typically managed by entities within the mobile node's home domain. 893 They may be also used for setting up secure communications with the 894 mobile node and the foreign agent, or between the mobile node and its 895 home agent if necessary. 897 Local Domain Home Domain 898 +--------------+ +----------------------+ 899 | +------+ | | +------+ | 900 | | | | | | | | 901 | | AAAL | | | | AAAH | | 902 | | +-------------------+ | | 903 | +---+--+ | | +------+ | 904 | | | | | 905 | | | +----------------------+ 906 +------+ | +---+--+ | 907 | | | | | | MN = mobile node 908 | MN |- -|- -| FA | | FA = foreign agent 909 | | | | | | AAAL = local authority 910 +------+ | +------+ | AAAH = home authority 911 | | 912 +--------------+ 914 Figure 7: AAA Servers in Home and Local Domains 916 The foreign agent often does not have direct access to the data 917 needed to verify the credentials. Instead, the foreign agent is 918 expected to consult an authority (typically in the same foreign 919 domain) in order to request proof that the mobile node has acceptable 920 credentials. Since the foreign agent and the local authority (AAAL) 921 are part of the same administrative domain, they are expected to have 922 established, or be able to establish for the necessary lifetime, a 923 secure channel for the purposes of exchanging sensitive (access) 924 information, and keeping it private from (at least) the visiting 925 mobile node. 927 The local authority (AAAL) itself may not have enough information 928 stored locally to carry out the verification for the credentials of 929 the mobile node. In contrast to the foreign agent, however, the AAAL 930 is expected to be configured with enough information to negotiate 931 the verification of mobile node credentials with its home domain. 932 The home and foreign domains should be configured with sufficient IP 933 Security Associations and access controls so that they can negotiate 934 the authorization, and also enable the mobile node to acquire 935 Mobility Security Associations with the mobility agents within the 936 foreign domain. For the purposes of the key exchanges specified 937 within this document, the authorization is expected to depend only 938 upon secure authentication of the mobile node's credentials. 940 Once the authorization has been obtained by the local authority, and 941 the authority has notified the foreign agent about the successful 942 negotiation, the foreign agent can deliver the Registration Reply to 943 the mobile node along with the key material. 945 In figure 7, there might be many mobile nodes from many different 946 Home Domains. Each Home Domain provides a AAAH that can check 947 credentials originating from mobile nodes administered by that Home 948 Domain. There is a security model implicit in figure 7, and it is 949 crucial to identify the specific security associations assumed in 950 the security model. These IP Security Associations are illustrated 951 in figure 8, and are considered to be relatively long-lived security 952 associations. 954 First, it is natural to assume that the mobile node has an AAA 955 Security Association with the AAAH, since that is roughly what it 956 means for the mobile node to belong to the home domain. 958 Second, from the model illustrated in figure 7 it is clear that AAAL 959 and AAAH have to share an IP Security Association, because otherwise 960 they could not rely on the authentication results, authorizations, 961 nor even the accounting data which might be transacted between them. 962 Requiring such bilateral IP Security Associations is, however, in the 963 end not scalable; the AAA framework must provide for more scalable 964 mechanisms, but the methods by which such a broker model is to be 965 created are out of scope for this document. See RFC 2977 for more 966 details. 968 Finally, from figure 7, it is clear that the foreign agent can 969 naturally share an IP Security Association with the AAAL. This is 970 necessary in order for the model to work because the foreign agent 971 has to have a way to find out that it is permissible to allocate 972 the local resources to the mobile node, and further to transmit any 973 successful Registration Reply to the mobile node. 975 Figure 8 illustrates the IP Security Associations we understand from 976 our proposed model. Note that there may be, by mutual agreement 977 between AAAL and AAAH, a third party inserted between AAAL and 978 AAAH to help them arbitrate secure transactions in a more scalable 979 fashion. The broker model which has been designed to enable such 980 third-party processing should not have any effect on the Mobile IP 981 extensions specified in this document, and so no description is 982 provided here; see RFC 2977 [7] for more details. 984 Nodes in two separate administrative domains (for instance, AAAH 985 and AAAL) often must take additional steps to verify the identity 986 of their communication partners, or alternatively to guarantee 987 the privacy of the data making up the communication. While these 988 considerations lead to important security requirements, as mentioned 989 +------+ +------+ 990 | | | | 991 | AAAL +--------------+ AAAH | 992 | | | | 993 +---+--+ +--+---+ 994 | | 995 | | 996 +---+--+ +--+---+ 997 MN = mobile node | | | | 998 FA = foreign agent | FA | | MN | 999 AAAL = local authority | | | | 1000 AAAH = home authority +------+ +------+ 1002 Figure 8: IP Security Associations 1004 above in the context of security between servers, we consider the 1005 exact choice of IP Security Associations between the AAA servers to 1006 be beyond the scope of this document. The choices are unlikely to 1007 depend upon Mobile IP, or any specific features of the general model 1008 illustrated in figure 7. On the other hand, the Mobility Security 1009 Associations needed between Mobile IP entities are of central 1010 importance in the design of the key derivation extensions in this 1011 document. 1013 One further detail deserves mention. The Mobility Security 1014 Association to be established between the mobile node and the foreign 1015 agent have to be communicated to the foreign agent as well as to the 1016 mobile node. The way that the key is distributed to the foreign 1017 agent is not relevant to any material in this document, and is 1018 expected to be handled as part of the AAA protocol processing between 1019 the AAAH and AAAL, and the further AAA protocol processing between 1020 the AAAL and the foreign agent. Any method by which the key can be 1021 securely transmitted to the AAAL and then relayed (possibly with 1022 re-encryption) to the foreign agent, is outside the jurisdiction 1023 of any Mobile IP specification, and thus compatible (by reason of 1024 non-interference) with the protocol extensions specified in this 1025 document. 1027 D. Message Flow for Requesting and Receiving Registration Keys 1029 In this section, we show message flows for requesting and receiving 1030 a registration key from the AAA infrastructure, described in 1031 section C. Challenge values, as specified in [4], might be added to 1032 the Advertisement and Registration messages for additional replay 1033 protection, but are not illustrated here. 1035 Diagram 9 illustrates the message flow for the case when the mobile 1036 node explicitly requests a registration key. 1038 MN FA AAA Infrastructure 1039 | | | 1040 |<--- Advertisement-----| | 1041 | (if needed) | | 1042 | | | 1043 |-- RReq+AAA Key Req.-->| | 1044 | |--- RReq + AAA Key Req.--->| 1045 | | | 1046 | |<--- RRep + AAA Key Rep.---| 1047 |<-- RRep+AAA Key Rep.--| | 1048 | | | 1050 Figure 9: Message Flows for Requesting and 1051 Receiving Registration Keys 1053 In diagram 9, the following message flow is illustrated: 1055 1. The foreign agent disseminates an Agent Advertisement. This 1056 advertisement MAY have been produced after receiving an Agent 1057 Solicitation from the mobile node (not shown in the diagram). 1059 2. The mobile node creates a Registration Request including the 1060 MN-HA Key Request and/or MN-FA Key Request, as needed, along with 1061 an authorization-enabling authentication extension as required by 1062 Mobile IP [13]. 1064 3. The foreign agent relays the Registration Request and/or Key 1065 Request(s) to its locally configured AAA Infrastructure (see 1066 appendix C), according to local policy. 1068 4. The foreign agent receives a AAA Response with the appropriate 1069 indications for authorizing connectivity for the mobile node. 1070 Along with this AAA Response, the foreign agent may also receive 1071 key material by some secure method appropriate for communications 1072 between it and its local AAA infrastructure. At this point if 1073 the foreign agent has not relayed the Registration Request, 1074 it forwards it directly to the Home Agent and waits for a 1075 Registration Reply (not shown in the figure). 1077 5. The foreign agent relays the Registration Reply to the mobile 1078 node, along with the new Key Material extensions to be used by 1079 the mobile node to establish Mobility Security Associations with 1080 the relevant mobility agents (foreign agent and/or home agent). 1082 Diagram 10 illustrates the message flow for the case when the 1083 mobile node receives an unsolicited registration key from the AAA 1084 Infrastructure. 1086 MN FA AAA Infrastructure 1087 | | | 1088 |<--- Advertisement-----| | 1089 | (if needed) | | 1090 | | | 1091 | ------ RReq --------->| | 1092 | |------- RReq ------------->| 1093 | | | 1094 | |<--- RRep + AAA Key Rep.---| 1095 |<-- RRep+AAA Key Rep.--| | 1096 | | | 1098 Figure 10: Message Flow for Receiving 1099 Unsolicited Registration Keys 1101 In diagram 10, the following message flow is illustrated: 1103 1. The foreign agent disseminates an Agent Advertisement. This 1104 advertisement MAY have been produced after receiving an Agent 1105 Solicitation from the mobile node (not shown in the diagram). 1107 2. The mobile node creates a Registration Request including an 1108 authorization-enabling authentication extension as required by 1109 Mobile IP [13]. 1111 3. The foreign agent sends a AAA Request (possibly containing 1112 the Registration Request) to its locally configured AAA 1113 Infrastructure (see appendix C), according to local policy. 1115 4. The foreign agent receives a AAA Response with the appropriate 1116 indications for authorizing connectivity for the mobile node. 1117 Along with this AAA Response, the foreign agent may also receive 1118 key material by some secure method appropriate for communications 1119 between it and its local AAA infrastructure. At this point, 1120 if the foreign agent has not relayed the Registration Request, 1121 it forwards it directly to the Home Agent and waits for a 1122 Registration Reply (not shown in the figure). 1124 5. The foreign agent relays the Registration Reply to the mobile 1125 node, along with the new Key Material extensions to be used by 1126 the mobile node to establish Mobility Security Associations with 1127 the relevant mobility agents (foreign agent and/or home agent). 1129 Addresses 1131 Questions about this memo can also be directed to the authors: 1133 Charles E. Perkins Pat R. Calhoun 1134 Communications Systems Lab 1135 Nokia Research Center Airespace Networks 1136 313 Fairchild Drive 110 Nortech Parkway 1137 Mountain View, California 94043 San Jose, CA 95134 1138 USA USA 1139 Phone: +1-650 625-2986 Phone: +1 408 635 2000 1140 EMail: charliep@iprg.nokia.com Email: pcalhoun@bstormnetworks.com 1141 Fax: +1 650 625-2502 Fax: +1 408 635 2020