idnits 2.17.1 draft-ietf-mobileip-aaa-key-12.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 May 2003 Pat R. Calhoun 4 Airespace Systems 6 AAA Registration Keys for Mobile IP 7 draft-ietf-mobileip-aaa-key-12.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 7 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 1 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-HA Key Material From AAA Subtype 690 extension, is taken from the numbering space defined for the 691 Generalized MN-HA Key Reply Extension (see section 6.4). 693 The number 7, assigned to the MN-FA Key Request From AAA Subtype 694 extension, is taken from the numbering space defined for the 695 Generalized MN-FA Key Request Extension (see section 6.1). 697 The number 1, assigned to the MN-FA Key Material From AAA Subtype 698 extension, is taken from the numbering space defined for the 699 Generalized MN-FA Key Reply Extension (see section 6.2). 701 The number 7, assigned to the MN-HA Key Request From AAA Subtype 702 extension, is taken from the numbering space defined for the 703 Generalized MN-HA Key Request Extension (see section 6.3). 705 The Code value specified for error MISSING_MN_FA, listed in 706 section 8, MUST NOT conflict with any other code values listed in 707 RFC 3344, RFC 3024 [10], or RFC 2356 [11]. This value is to be 708 taken from the space of error values conventionally associated with 709 rejection by the foreign agent (i.e., 64-127). 711 Section 4 introduces the Replay Method Identifier namespace that 712 requires IANA management. This specification makes use of 1-3; 713 all other values other than zero (0) or one (1) are available for 714 assignment, pending review and approval by a Designated Expert [12]. 716 10. Security Considerations 718 The extensions in this document are intended to provide the 719 appropriate level of security for Mobile IP entities (mobile node, 720 foreign agent, and home agent) to calculate the Authentication Data 721 needed by authentication extensions used with Mobile IP registration 722 messages. The Mobility Security Associations resulting from use of 723 these extensions do not offer any higher level of security than what 724 is already implicit in use of the AAA Security Association between 725 the mobile node and the AAAH. In order to deny any adversary the 726 luxury of unbounded time to analyze and break the secrecy of the AAA 727 Security Association between the mobile node and the AAA server, that 728 AAA Security Association MUST be refreshed periodically. 730 The provisioning and refreshing of the AAA key in the MN and AAA 731 server is outside the scope of this document. Typical methods for 732 provisioning and refresh at the MN include the use of https between 733 the MN and a trusted provisioning server (e.g., over a wireless link 734 layer). Wireless standards organizations specify the details of the 735 wireless link operation, including authentication of the MN at the 736 link layer. 738 Since the extensions defined in this specification only carries Key 739 Material, which is used to derive keys, it does not expose any data 740 that could be used in an attack aimed at recovering the key shared 741 between the mobile node and the AAA. The authors do not believe this 742 specification introduces any new security vulnerability. 744 11. Acknowledgements 746 Thanks to Fredrik Johansson, Tom Hiller, and the members of the IESG 747 for their useful comments on this document. 749 References 751 [1] B. Aboba and M. Beadles. The Network Access Identifier. 752 Request for Comments (Proposed Standard) 2486, Internet 753 Engineering Task Force, January 1999. 755 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 756 Levels. Request for Comments (Best Current Practice) 2119, 757 Internet Engineering Task Force, March 1997. 759 [3] P. Calhoun and C. Perkins. Mobile IP Network Access Identifier 760 Extension for IPv4. Request for Comments (Proposed Standard) 761 2794, Internet Engineering Task Force, January 2000. 763 [4] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 764 Challenge/Response Extension. Request for Comments (Proposed 765 Standard) 3012, Internet Engineering Task Force, December 2000. 767 [5] Pat R. Calhoun, John Loughney, E. Guttman, Glen Zorn, 768 and Jari Arkko. DIAMETER Base Protocol (work in 769 progress). Internet Draft, Internet Engineering Task 770 Force. draft-ietf-aaa-diameter-15.txt, October 2002. 772 [6] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 773 Recommendations for Security. Request for Comments 774 (Informational) 1750, Internet Engineering Task Force, December 775 1994. 777 [7] S. Glass, T. Hiller, S. Jacobs, and C. Perkins. Mobile IP 778 Authentication, Authorization, and Accounting Requirements. 779 Request for Comments (Proposed Standard) 2977, Internet 780 Engineering Task Force, October 2000. 782 [8] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 783 for Message Authentication. Request for Comments 784 (Informational) 2104, Internet Engineering Task Force, 785 February 1997. 787 [9] D. Mitton, M. St.Johns, S. Barkley, D. Nelson, B. Patil, 788 M. Stevens, and B. Wolff. Authentication, Authorization, 789 and Accounting: Protocol Evaluation. Request for Comments 790 (Informational) 3127, Internet Engineering Task Force, June 791 2001. 793 [10] Editor G. Montenegro. Reverse Tunneling for Mobile IP, revised. 794 Request for Comments (Proposed Standard) 3024, Internet 795 Engineering Task Force, January 2001. 797 [11] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 798 Mobile IP. Request for Comments (Informational) 2356, Internet 799 Engineering Task Force, June 1998. 801 [12] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 802 Considerations Section in RFCs. Request for Comments (Best 803 Current Practice) 2434, Internet Engineering Task Force, October 804 1998. 806 [13] C. Perkins. IP Mobility Support. Request for Comments 807 (Proposed Standard) 3344, Internet Engineering Task Force, 808 August 2002. 810 [14] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 811 Authentication Dial In User Service (RADIUS). Request for 812 Comments (Proposed Standard) 2865, Internet Engineering Task 813 Force, June 2000. 815 A. Changes Since Previous Revision 817 - Cleaned up terminology: 819 * Clarified the use of "security association" throughout the 820 document as either "IPSec" or "Mobility" or "AAA". 822 B. Older Changes 824 In this revision of the document, there have been several major 825 changes as a result of suggestions received during Last Call. 827 - Generalized Key Extensions previously specified in another 828 document have been instead specified in this document in order 829 that this document can be self-contained and not dependent on the 830 standardization status of the other document. 832 - Additional explanation has been included for the purposes of 833 clarifying the problem space and solution approach. 835 - An appendix has been added to describe the expected AAA 836 infrastructure that will produce the keys that are to be 837 distributed within the extensions specified in this document. 839 - Ladder diagrams have been included to illustrate the expected 840 message flows containing the extensions defined in this document. 842 - HMAC-MD5 has been mandated for implementation by the mobile node, 843 for compatibility with RFC 3344 [13]. The example text has been 844 modified accordingly (see section 5). 846 - A table of Algorithm Identifiers has been identified as the 847 numbering space for transform selection when establishing the 848 Mobility Security Association using the keys distributed with the 849 extensions in this document. See section 4. 851 - A terminology section has been added. 853 - This appendix has been added. 855 * New terminology entries for "Registration Key", "AAA", "AAA 856 entity", "Mobility Security Association", "AAA Security 857 Association", 859 * All instances of MN-FA key are now called "registration key" 861 * All instances of the key between mobile node and home agent 862 are called "MN-HA" key. 864 - Removed extraneous IANA considerations paragraph for HMAC_MD5 866 - Removed "Unsolicited" from subtype names 868 - Changed minimum Key Material length from 64 bits to 128 bits 870 C. AAA Infrastructure 872 In this appendix, we attempt to capture the main features of a basic 873 model for operation of AAA servers that is assumed for understanding 874 of the use of the Mobile IP registration extensions described in this 875 document. This information has been adapted from the discussion in 876 RFC 2977 [7]. 878 Within the Internet, a mobile node belonging to one administrative 879 domain (called the home domain) often needs to use resources 880 provided by another administrative domain (called the foreign 881 domain). A foreign agent that handles the mobile node's Registration 882 Request is likely to require that the mobile node provide some 883 credentials that can be authenticated before access to the resources 884 is permitted. These credentials may be provided as part of the 885 Mobile-AAA Authentication extension [4], relying on the existence 886 of an AAA infrastructure such as is described in this section, and 887 also described in RFC 2977 and RFC 3012 [4]. Such credentials are 888 typically managed by entities within the mobile node's home domain. 889 They may be also used for setting up secure communications with the 890 mobile node and the foreign agent, or between the mobile node and its 891 home agent if necessary. 893 Local Domain Home Domain 894 +--------------+ +----------------------+ 895 | +------+ | | +------+ | 896 | | | | | | | | 897 | | AAAL | | | | AAAH | | 898 | | +-------------------+ | | 899 | +---+--+ | | +------+ | 900 | | | | | 901 | | | +----------------------+ 902 +------+ | +---+--+ | 903 | | | | | | MN = mobile node 904 | MN |- -|- -| FA | | FA = foreign agent 905 | | | | | | AAAL = local authority 906 +------+ | +------+ | AAAH = home authority 907 | | 908 +--------------+ 910 Figure 7: AAA Servers in Home and Local Domains 912 The foreign agent often does not have direct access to the data 913 needed to verify the credentials. Instead, the foreign agent is 914 expected to consult an authority (typically in the same foreign 915 domain) in order to request proof that the mobile node has acceptable 916 credentials. Since the foreign agent and the local authority (AAAL) 917 are part of the same administrative domain, they are expected to have 918 established, or be able to establish for the necessary lifetime, a 919 secure channel for the purposes of exchanging sensitive (access) 920 information, and keeping it private from (at least) the visiting 921 mobile node. 923 The local authority (AAAL) itself may not have enough information 924 stored locally to carry out the verification for the credentials of 925 the mobile node. In contrast to the foreign agent, however, the AAAL 926 is expected to be configured with enough information to negotiate 927 the verification of mobile node credentials with its home domain. 928 The home and foreign domains should be configured with sufficient IP 929 Security Associations and access controls so that they can negotiate 930 the authorization, and also enable the mobile node to acquire 931 Mobility Security Associations with the mobility agents within the 932 foreign domain. For the purposes of the key exchanges specified 933 within this document, the authorization is expected to depend only 934 upon secure authentication of the mobile node's credentials. 936 Once the authorization has been obtained by the local authority, and 937 the authority has notified the foreign agent about the successful 938 negotiation, the foreign agent can deliver the Registration Reply to 939 the mobile node along with the key material. 941 In figure 7, there might be many mobile nodes from many different 942 Home Domains. Each Home Domain provides a AAAH that can check 943 credentials originating from mobile nodes administered by that Home 944 Domain. There is a security model implicit in figure 7, and it is 945 crucial to identify the specific security associations assumed in 946 the security model. These IP Security Associations are illustrated 947 in figure 8, and are considered to be relatively long-lived security 948 associations. 950 First, it is natural to assume that the mobile node has an AAA 951 Security Association with the AAAH, since that is roughly what it 952 means for the mobile node to belong to the home domain. 954 Second, from the model illustrated in figure 7 it is clear that AAAL 955 and AAAH have to share an IP Security Association, because otherwise 956 they could not rely on the authentication results, authorizations, 957 nor even the accounting data which might be transacted between them. 958 Requiring such bilateral IP Security Associations is, however, in the 959 end not scalable; the AAA framework must provide for more scalable 960 mechanisms, but the methods by which such a broker model is to be 961 created are out of scope for this document. See RFC 2977 for more 962 details. 964 Finally, from figure 7, it is clear that the foreign agent can 965 naturally share an IP Security Association with the AAAL. This is 966 necessary in order for the model to work because the foreign agent 967 has to have a way to find out that it is permissible to allocate 968 the local resources to the mobile node, and further to transmit any 969 successful Registration Reply to the mobile node. 971 Figure 8 illustrates the IP Security Associations we understand from 972 our proposed model. Note that there may be, by mutual agreement 973 between AAAL and AAAH, a third party inserted between AAAL and 974 AAAH to help them arbitrate secure transactions in a more scalable 975 fashion. The broker model which has been designed to enable such 976 third-party processing should not have any effect on the Mobile IP 977 extensions specified in this document, and so no description is 978 provided here; see RFC 2977 [7] for more details. 980 Nodes in two separate administrative domains (for instance, AAAH 981 and AAAL) often must take additional steps to verify the identity 982 of their communication partners, or alternatively to guarantee 983 the privacy of the data making up the communication. While these 984 considerations lead to important security requirements, as mentioned 985 +------+ +------+ 986 | | | | 987 | AAAL +--------------+ AAAH | 988 | | | | 989 +---+--+ +--+---+ 990 | | 991 | | 992 +---+--+ +--+---+ 993 MN = mobile node | | | | 994 FA = foreign agent | FA | | MN | 995 AAAL = local authority | | | | 996 AAAH = home authority +------+ +------+ 998 Figure 8: IP Security Associations 1000 above in the context of security between servers, we consider the 1001 exact choice of IP Security Associations between the AAA servers to 1002 be beyond the scope of this document. The choices are unlikely to 1003 depend upon Mobile IP, or any specific features of the general model 1004 illustrated in figure 7. On the other hand, the Mobility Security 1005 Associations needed between Mobile IP entities are of central 1006 importance in the design of the key derivation extensions in this 1007 document. 1009 One further detail deserves mention. The Mobility Security 1010 Association to be established between the mobile node and the foreign 1011 agent have to be communicated to the foreign agent as well as to the 1012 mobile node. The way that the key is distributed to the foreign 1013 agent is not relevant to any material in this document, and is 1014 expected to be handled as part of the AAA protocol processing between 1015 the AAAH and AAAL, and the further AAA protocol processing between 1016 the AAAL and the foreign agent. Any method by which the key can be 1017 securely transmitted to the AAAL and then relayed (possibly with 1018 re-encryption) to the foreign agent, is outside the jurisdiction 1019 of any Mobile IP specification, and thus compatible (by reason of 1020 non-interference) with the protocol extensions specified in this 1021 document. 1023 D. Message Flow for Requesting and Receiving Registration Keys 1025 In this section, we show message flows for requesting and receiving 1026 a registration key from the AAA infrastructure, described in 1027 section C. Challenge values, as specified in [4], might be added to 1028 the Advertisement and Registration messages for additional replay 1029 protection, but are not illustrated here. 1031 Diagram 9 illustrates the message flow for the case when the mobile 1032 node explicitly requests a registration key. 1034 MN FA AAA Infrastructure 1035 | | | 1036 |<--- Advertisement-----| | 1037 | (if needed) | | 1038 | | | 1039 |-- RReq+AAA Key Req.-->| | 1040 | |--- RReq + AAA Key Req.--->| 1041 | | | 1042 | |<--- RRep + AAA Key Rep.---| 1043 |<-- RRep+AAA Key Rep.--| | 1044 | | | 1046 Figure 9: Message Flows for Requesting and 1047 Receiving Registration Keys 1049 In diagram 9, the following message flow is illustrated: 1051 1. The foreign agent disseminates an Agent Advertisement. This 1052 advertisement MAY have been produced after receiving an Agent 1053 Solicitation from the mobile node (not shown in the diagram). 1055 2. The mobile node creates a Registration Request including the 1056 MN-HA Key Request and/or MN-FA Key Request, as needed, along with 1057 an authorization-enabling authentication extension as required by 1058 Mobile IP [13]. 1060 3. The foreign agent relays the Registration Request to its locally 1061 configured AAA Infrastructure (see appendix C), according to 1062 local policy. 1064 4. The foreign agent receives a Registration Reply with the 1065 appropriate indications for authorizing connectivity for the 1066 mobile node, which also includes the necessary AAA Key Material 1067 extensions. Along with this Registration Reply, the foreign 1068 agent may also receive key material by some other secure method 1069 appropriate for communications between it and its local AAA 1070 infrastructure. 1072 5. The foreign agent relays the Registration Reply to the mobile 1073 node, along with the new Key Material extensions to be used by 1074 the mobile node to establish Mobility Security Associations with 1075 the relevant mobility agents (foreign agent and/or home agent). 1077 Diagram 10 illustrates the message flow for the case when the 1078 mobile node receives an unsolicited registration key from the AAA 1079 Infrastructure. 1081 MN FA AAA Infrastructure 1082 | | | 1083 |<--- Advertisement-----| | 1084 | (if needed) | | 1085 | | | 1086 | ------ RReq --------->| | 1087 | |------- RReq ------------->| 1088 | | | 1089 | |<--- RRep + AAA Key Rep.---| 1090 |<-- RRep+AAA Key Rep.--| | 1091 | | | 1093 Figure 10: Message Flow for Receiving 1094 Unsolicited Registration Keys 1096 In diagram 10, the following message flow is illustrated: 1098 1. The foreign agent disseminates an Agent Advertisement. This 1099 advertisement MAY have been produced after receiving an Agent 1100 Solicitation from the mobile node (not shown in the diagram). 1102 2. The mobile node creates a Registration Request including an 1103 authorization-enabling authentication extension as required by 1104 Mobile IP [13]. 1106 3. The foreign agent relays the Registration Request to its locally 1107 configured AAA Infrastructure (see appendix C), according to 1108 local policy. 1110 4. The foreign agent receives a Registration Reply with the 1111 appropriate indications for authorizing connectivity for the 1112 mobile node, which also includes the necessary AAA Key Material 1113 extensions. Along with this Registration Reply, the foreign 1114 agent may also receive key material by some other secure method 1115 appropriate for communications between it and its local AAA 1116 infrastructure. 1118 5. The foreign agent relays the Registration Reply to the mobile 1119 node, along with the new Key Material extensions to be used by 1120 the mobile node to establish Mobility Security Associations with 1121 the relevant mobility agents (foreign agent and/or home agent). 1123 Addresses 1125 Questions about this memo can also be directed to the authors: 1127 Charles E. Perkins Pat R. Calhoun 1128 Communications Systems Lab 1129 Nokia Research Center Airespace Networks 1130 313 Fairchild Drive 110 Nortech Parkway 1131 Mountain View, California 94043 San Jose, CA 95134 1132 USA USA 1133 Phone: +1-650 625-2986 Phone: +1 408 635 2000 1134 EMail: charliep@iprg.nokia.com Email: pcalhoun@bstormnetworks.com 1135 Fax: +1 650 625-2502 Fax: +1 408 635 2020