idnits 2.17.1 draft-ietf-mobileip-aaa-key-10.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 194: '..., the AAA server MAY provide unsolicit...' RFC 2119 keyword, line 195: '... the mobile node MUST then calculate n...' RFC 2119 keyword, line 220: '...oreign agent, it SHOULD include an MN-...' RFC 2119 keyword, line 225: '...e home agent, it MUST add an MN-HA Key...' RFC 2119 keyword, line 230: '... mobile node MUST add the MN-AAA A...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 424 has weird spacing: '...Subtype a n...' == Line 514 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 23 October 2002 Pat R. Calhoun 4 Black Storm Systems 6 AAA Registration Keys for Mobile IP 7 draft-ietf-mobileip-aaa-key-10.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 a AAA security association with its home AAA server, however, 40 it is possible to use that 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 62 the Mobile IP mobility agents so that they can translate between 63 Mobile IP registration messages and the messages used within the 64 AAA infrastructure 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 Mobile IP requires strong authentication between the mobile node 71 and its home agent. When the mobile node shares a AAA security 72 association with its home AAA server, however, it is possible to use 73 that security association to create derivative Mobility Security 74 Associations between the mobile node and its home agent, and again 75 between the mobile node and the foreign agent currently offering 76 connectivity to the mobile node. This document specifies extensions 77 to Mobile IP registration messages that can be used to create those 78 Mobility Security Associations at the mobile node. The extensions 79 in this document are intended to provide the appropriate level of 80 security for Mobile IP entities (mobile node, foreign agent, and home 81 agent) to calculate the Authentication Data needed by authentication 82 extensions used with Mobile IP registration messages. It is assumed 83 that the security association between the mobile node and its AAA 84 server has been appropriately configured so that the AAA server has 85 authorization to provide key material to be used as the basis for the 86 necessary mobility security association(s) between the mobile node 87 and its prospective mobility agents. 89 AAA servers typically use the Network Access Identifier (NAI) [1] to 90 uniquely identify the mobile node; the mobile node's home address is 91 not always necessary to provide that function. Thus, it is possible 92 for a mobile node to authenticate itself, and be authorized for 93 connection to the foreign domain, without having any home address. 94 However, for Mobile IP to work, the mobile node is required to have a 95 home address and a Mobility Security Association [13] with its home 96 agent. When the Mobile IP Registration Reply packet is authenticated 97 by the MN-AAA Authentication Extension [4], the mobile node can 98 verify that the key material contained in the extensions were 99 produced by the AAA server, and thus may be reliably used to create 100 Mobility Security Associations with the home agent, or alternatively 101 with the foreign agent. 103 It is also assumed that the AAA entities involved (i.e., the AAAH, 104 AAAL, and the AAA interface features of the foreign agents and home 105 agents) all have means outside of the scope of this document for 106 exchanging keys. The extensions within this document are intended to 107 work with any AAA protocol suite that allows for such key exchange, 108 as long as it satisfies the requirements specified in RFC 2977 [7]. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [2]. 116 AAA Authentication, Authorization, and Accounting 117 (see [9]). 119 AAA entity A network node processing AAA messages according to 120 the requirements for AAA protocols (see [9]). 122 AAA security association 123 A security association between a AAA entity 124 and another node needing the services of that 125 AAA entity. In this document all AAA security 126 associations are between a mobile node and its home 127 AAA server (AAAH). A mobile node's AAA security 128 association with its home AAA server (AAAH) may be 129 based either on the mobile node's IP address or on 130 its NAI [1]. 132 Key a number, kept secret. Only nodes in possession 133 of the key have any hope of using the security 134 transform to obtain correct results. 136 Key Material 137 Data used for the purpose of creating a key. 139 Mobility security association 140 A security association between a mobility agent and 141 another node needing the services of that mobility 142 agent (i.e., foreign agent or home agent). In this 143 document all Mobility security associations are 144 between a mobile node and a mobility agent. 146 Registration Key 147 A key used as the basis of a Mobility Security 148 Association between a mobile node and a foreign 149 agent. A registration key is typically only used 150 once or a very few times, and only for the purposes 151 of verifying a small volume of Authentication data. 153 Security Association 154 The information shared by two network nodes that 155 enables them to carry out the operations needed for 156 some security protocol that the nodes intend to 157 operate. For the purposes of this document, all 158 security associations will contain a key, and will 159 be able to be indexed using a SPI. 161 Security Algorithm 162 A set of rules for using input data and a secret key 163 for producing data for use in security protocols. 165 SPI Security Parameters Index. This number enables 166 selection of one security association in case that 167 several exist between the two nodes operaing a 168 security procedure. 170 Other terminology is used as defined in the base Mobile IP 171 specification [13]. Furthermore, in order to simplify the 172 discussion, we have used the word "Extension" instead of "Subtype of 173 the Generalized Extension" in many cases. So, for instance, instead 174 of using the phrase "The MN-FA Key Material From AAA Subtype of the 175 Generalized MN-FA Key Reply Extension", we would instead use the 176 phrase "The MN-FA Key Material From AAA Extension". 178 3. Overview of Operations with Key Extensions 180 When a mobile node depends on an AAA infrastructure to obtain 181 authorization for network connectivity and Mobile IP registration, 182 it may lack any pre-existing Mobility Security Associations with 183 either its home agent, or the foreign agent controlling the access to 184 the foreign network. The extensions defined in this document allow 185 a AAA entity to supply key material to mobile nodes to be used as 186 the basis of its Mobility Security Association with mobile agents. 187 The AAA entity that will act on these extensions is part of the AAA 188 infrastructure, and is typically identified within the foreign domain 189 by methods outside the scope of this specification (see appendix C). 191 The key material may be requested by the mobile node in new 192 extensions to Mobile IP Registration Request messages, and supplied 193 to the mobile node in extensions to the Mobile IP Registration Reply 194 messages. Alternatively, the AAA server MAY provide unsolicited key 195 material to mobile nodes; the mobile node MUST then calculate new 196 keys and update or create its relevant Mobility Security Association. 197 The method by which key material is supplied to the mobility agents 198 themselves is out of scope for this document, and would depend on the 199 particular details of the security architecture for the AAA servers 200 in the foreign and home domains (see RFC 2977 and appendix C). For 201 the purposes of this document, we assume that there is a suitable AAA 202 infrastructure available to the foreign agents, and that the mobile 203 node does have a security association with at least one AAA server in 204 its home domain. 206 When a mobile node travels away from home, it may not have a Mobility 207 Security Association with its home agent, perhaps because it does 208 not yet have a home address [3]. The protocol and messages in this 209 document are intended to facilitate the following operations which 210 may occur between the mobile node, foreign agent, home agent, and AAA 211 servers in the visited (local) domain (AAAL) and in the home domain 212 (AAAH). In the following sequence of messages, the only message flows 213 specified in this document are the Registration Request between the 214 mobile node and the foreign agent, and Registration Reply between the 215 foreign agent and the mobile node. The other messages described here 216 result from the presumed action of the AAA entities as described in 217 RFC 2977. See also appendix D. 219 1. If the mobile node does not have a Mobility Security Association 220 with the foreign agent, it SHOULD include an MN-FA Key Request 221 extension (see Section 7.1) as part of its Registration Request 222 that it sends to the Foreign Agent. 224 2. If the mobile node does not have a Mobility Security Association 225 with the home agent, it MUST add an MN-HA Key Request extension 226 (see Section 7.3) as part of its Registration Request that it 227 sends to the Foreign Agent. 229 3. If one or more AAA Key Request extensions were added, the 230 mobile node MUST add the MN-AAA Authentication extension to its 231 Registration Request. 233 4. By action of the foreign agent, which is presumed to be also a 234 AAA entity, the mobile node's key requests and authentication 235 data are transferred to the local AAA server (AAAL), typically 236 after reformatting to fit into the appropriate AAA messages, 237 which are out of scope for this document. 239 5. After the information within the MN-AAA Authentication extension 240 is verified by the AAA server in the home domain (AAAH), it then 241 also generates the Key Material that has been requested by the 242 mobile node, for the necessary Mobility Security Associations. 244 6. The respective keys for the mobility security associations are 245 distributed to the Home Agent and Foreign Agent via the AAA 246 protocol. 248 7. The mobile node receives the Registration Reply message from the 249 Foreign Agent. 251 8. If a MN-HA Key Material from AAA extension is present in the 252 Registration Reply message, then the mobile node MUST create or 253 update its Mobility Security Association with the Home Agent 254 indicated in the Registration Reply, using the key computed from 255 the Key Material in the AAA Key Material extension. In this 256 case, if no Key Material extension is present, the mobile node 257 MUST discard the Registration Reply. If the mobile node does 258 not already have a Mobility Security Association with the Home 259 Agent indicated in the Registration Reply message, and if no Key 260 Material extension is present, the mobile node MUST discard the 261 Registration Reply. 263 9. Using its (perhaps newly created) Mobility Security Association 264 with the home agent, the mobile node authenticates the 265 Registration Reply message, by checking the Authentication Data 266 in the Mobile-Home Authentication extension. 268 10. If the Registration Reply passes authentication and contains a 269 MN-FA Key Material From AAA extension (see section 7.2), the 270 mobile node generates the registration key using the Key Material 271 provided, according to its security association with the AAA. The 272 resulting registration key is used to establish the mobile node's 273 Mobility Security Association with its foreign agent, and is used 274 to compute the authentication data used in the Mobile-Foreign 275 authentication extension. 277 Any registration reply containing the MN-HA Key Material From AAA 278 extension MUST also contain a subsequent Mobile Home Authentication 279 extension, created using the generated MN-HA key. Similarly, a 280 reply containing the MN-FA Key Material From AAA extension MUST also 281 contain a subsequent Mobile Foreign Authentication extension, created 282 using the registration key. 284 4. Mobility Security Associations 286 Mobility Security Associations between Mobile IP entities 287 (mobile nodes, home agents, foreign agents) contain both the 288 necessary cryptographic key information, and a way to identify 289 the cryptographic transform which uses the key to produce the 290 authentication information which is present in the Mobile-Home 291 Authentication extension or the Mobile-Foreign Authentication 292 extension. In order for the mobile node to make use of key material 293 created by the AAA server, the mobile node also has to be able to 294 identify and select the appropriate cryptographic transform that uses 295 the key to produce the authentication. 297 The transform identifiers are shared with IPsec. They are 298 tabulated in the list of Authentication Algorithms allowable 299 as values for the "Attribute Type" (5) (i.e., "Authentication 300 Algorithm"), one of the classifications in the tabulated 301 Attribute Types for "IPSEC Security Association Attributes". See 302 http://www.iana.org/assignments/isakmp-registry for the full listing 303 of all Attribute Types and other Attributes for IPSEC Security 304 Associations. 306 Mobility Security Associations shared between mobile nodes and home 307 agents also require a replay protection method. The following table 308 contains the supported replay methods. 310 Replay Method Name Reference 311 -------------- ------------ -------------- 312 0,1 Reserved 313 2 Timestamps RFC 3344 [13] 314 3 Nonces RFC 3344 [13] 315 4-65535 Unallocated 317 5. Key Material Creation and Derivation 319 This section contains the procedures followed in the creation of the 320 Key Material by AAA servers, and the key derivation procedures used 321 by mobile nodes. Note that the AAA servers will also to deliver the 322 keys to the mobility agents (home agent, foreign agent) via the AAA 323 protocol. AAA servers that follow these procedures will produce 324 results that can be understood by mobile nodes. The mobility agents 325 will faithfully transcribe the results into the appropriate Mobile IP 326 extensions. 328 The example that follows makes use of HMAC-MD5 [8]. All mobile nodes 329 and mobility agents implementing Mobile IP [13], and implementing the 330 extensions specified in this document, MUST implement HMAC-MD5 [13]. 331 Other cryptographic functions MAY also be used. 333 The following steps are performed on the AAA server: 335 1. The AAA server identifies the mobile node. If the Home Address 336 field of the Registration Request is either zero (0), or all ones 337 (0xffffffff), then the Mobile Node's NAI is used instead of the 338 mobile node's home address. 340 2. The AAA server generates a random [6] value of at least 64 bits 341 to be used as the Key Material. 343 3. The AAA server inserts the random value into the Key Reply 344 extension, in the ``Key Material'' field. 346 The following steps are performed by the mobile node: 348 1. Using the Key Material from the extension, the mobile node 349 calculates 351 key = HMAC-MD5 (AAA-key, {Key Material || home address}) 353 2. The mobile node creates mobility the security association, using 354 the key and the other relevant information in the Key Extension. 356 The secret key used within the HMAC-MD5 computation is indicated by 357 the AAA Security Association indexed by the AAA SPI, which has been 358 previously configured as the basis for a security association between 359 the mobile node and the AAA server creating the key material. 361 6. Generalized Key Request/Reply Extensions 363 The extensions in this section are Generalized Extensions [13], and 364 have subtypes as specified in section 7. 366 6.1. Generalized MN-FA Key Request Extension 368 Figure 1 illustrates the Generalized MN-FA Key Request Extension. 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type | Subtype | Length | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Mobile Node SPI | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | MN-FA Key Request Subtype Data ... 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Figure 1: The Generalized Mobile IP MN-FA Key Request Extension 381 Type TBD (not skippable) (see [13] and section 9) 383 Subtype a number assigned to identify the way in 384 which the Key Request Data is to be used when 385 generating the registration key 387 Length The 16-bit Length field indicates the length of 388 the extension. It is equal to the number of 389 bytes in the MN-FA Key Request Subtype Data plus 390 4 (for the Mobile Node SPI field). 392 Mobile Node SPI The Security Parameters Index that the mobile 393 node will assign for the security association 394 created for use with the registration key. 396 MN-FA Key Request Subtype Data 397 Data needed to carry out the creation of the 398 registration key on behalf of the mobile node. 400 The Generalized MN-FA Key Request Extension defines a set of 401 extensions, identified by subtype, which may be used by a mobile node 402 in a Mobile IP Registration Request message to request that some 403 other entity create a Registration Key for use by the mobile node 404 with the mobile node's new foreign agent. 406 6.2. Generalized MN-FA Key Reply Extension 408 The Generalized MN-FA Key Reply extension supplies a registration key 409 requested by using one of the subtypes of the Generalized MN-FA Key 410 Request extension. Figure 2 illustrates the format Generalized MN-FA 411 Key Reply Extension. 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Subtype | Length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | MN-FA Key Reply Subtype Data ... 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Figure 2: The Generalized Mobile IP MN-FA Key Reply Extension 423 Type TBD (not skippable) (see [13] and section 9) 424 Subtype a number assigned to identify the way in which the 425 MN-FA Key Reply Subtype Data is to be decrypted to 426 obtain the registration key 428 Length The 16-bit Length field is equal to the number of bytes 429 in the MN-FA Key Reply Subtype Data. 431 MN-FA Key Reply Subtype Data 432 An encoded copy of the registration key, along with any 433 other information needed by the recipient to create the 434 designated Mobility Security Association. 436 For each subtype, the format of the MN-FA Key Reply Subtype Data has 437 to be separately defined according to the particular method required 438 to set up the security association. 440 For the subtypes defined in this document, the MN-FA Key supplied 441 in the data for a subtype of this extension may come by a request 442 which was sent using a subtype of the Generalized MN-FA Key Request 443 Extension. In such cases, the SPI to be used when employing the 444 security association defined by the registration key is the same as 445 given in the original request. 447 Once the mobile node creates the Mobility Security Association with 448 the foreign agent, by using the transform indexed by the AAA SPI, it 449 stores that Mobility Security Association indexed by the FA SPI in 450 its list of Mobile Security Associations. 452 If the foreign agent receives a Registration Reply that has no MN-FA 453 Key Reply extension, and if it has no existing Mobility Security 454 Association with the mobile node, the foreign agent MAY change 455 the Code value of the Registration Reply to MISSING_MN_FA (see 456 section 8), effectively causing the registration to fail. 458 6.3. Generalized MN-HA Key Request Extension 460 Figure 3 illustrates the Generalized MN-HA Key Request Extension. 462 Type TBD (not skippable) (see [13] and section 9) 464 Subtype a number assigned to identify the way in 465 which the Key Request Data is to be used when 466 generating the registration key 468 Length The 16-bit Length field indicates the length of 469 the extension. It is equal to the number of 470 bytes in the MN-HA Key Request Subtype Data plus 471 4 (for the Mobile Node SPI field). 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Type | Subtype | Length | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Mobile Node SPI | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | MN-HA Key Request Subtype Data ... 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Figure 3: The Generalized Mobile IP MN-HA Key Request Extension 485 Mobile Node SPI The Security Parameters Index that the mobile 486 node will assign for the security association 487 created for use with the registration key. 489 MN-HA Key Request Subtype Data 490 Data needed to carry out the creation of the 491 registration key on behalf of the mobile node. 493 The Generalized MN-HA Key Request Extension defines a set of 494 extensions, identified by subtype, which may be used by a mobile node 495 in a Mobile IP Registration Request message to request that some 496 other entity create a MN-HA key for use by the mobile node with the 497 mobile node's new home agent. 499 6.4. Generalized MN-HA Key Reply Extension 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Type | Subtype | Length | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Lifetime | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | MN-HA Key Reply Subtype Data ... 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 Figure 4: The Generalized Mobile IP MN-HA Key Reply Extension 513 Type TBD (not skippable) (see [13] and section 9) 514 Subtype a number assigned to identify the way in which the 515 MN-HA Key Reply Subtype Data is to be decrypted to 516 obtain the MN-HA key 518 Length The 16-bit Length field indicates the length of the 519 extension. It is equal to the number of bytes in the 520 MN-HA Key Reply Subtype Data plus 4 (for the Lifetime 521 field). 523 Lifetime This field indicates the duration of time (in seconds) 524 for which the MN-HA key is valid. 526 MN-HA Key Reply Subtype Data 527 An encrypted copy of the MN-HA key, along with any 528 other information needed by the mobile node to create 529 the designated Mobility Security Association with the 530 home agent. 532 For each subtype, the format of the MN-HA Key Reply Subtype Data has 533 to be separately defined according to the particular method required 534 to set up the security association. 536 7. Key Request/Reply Subtypes 538 The extension subtypes in this section are subtypes of the 539 Generalized Extensions specified in section 6. 541 7.1. MN-FA Key Request From AAA Subtype 543 The MN-FA Key Request From AAA subtype data uses subtype 7 of the 544 Generalized MN-FA Key Request Extension (see section 6.1). The 545 MN-FA Key Request From AAA extension MUST appear in the Registration 546 Request before the MN-AAA Authentication extension. The subtype data 547 field is zero in length. 549 7.2. MN-FA Key Material From AAA Subtype 551 The MN-FA Key Material From AAA extension, shown in figure 5, 552 uses subtype 7 of the Generalized MN-FA Key Reply Extension (see 553 section 6.2). 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Lifetime | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | AAA SPI | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | FA SPI | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Algorithm Identifier | Key Material ... 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Figure 5: The MN-FA Key Material From AAA Subtype-Specific Data 569 lifetime This field indicates the duration of time (in seconds) 570 for which the registration key is valid. 572 AAA SPI A 32-bit opaque value, indicating the SPI that the 573 mobile node must use to determine the transform to use 574 for establishing the mobility security association 575 between the mobile node and its prospective foreign 576 agent. 578 FA SPI The SPI for the Mobility Security Association to the FA 579 that the mobile node creates using the Key Material 581 Algorithm Identifier 582 This field indicates the transform to be used (stored 583 as part of the Mobility Security Association with 584 the foreign agent, and selected from among the 585 values in the "Authentication Algorithm" table 586 cited in section 4), for future computations of the 587 Mobile-Foreign Authentication Extension. 589 Key Material 590 A random [6] value of at least 128 bits. 592 The MN-FA Key Material From AAA extension MUST appear in the 593 Registration Reply before the Mobile-Foreign Authentication 594 extension. The Key Material is provided by the AAA server for use by 595 the mobile node in creating the registration key, which is used to 596 secure future Mobile IP registrations with the same foreign agent. 598 7.3. MN-HA Key Request From AAA Subtype 600 The MN-HA Key Request From AAA subtype data uses subtype 7 of the 601 Generalized MN-HA Key Request Extension (see section 6.3). The 602 MN-HA Key Request From AAA extension MUST appear in the Registration 603 Request before the MN-AAA Authentication extension. The subtype data 604 field is zero in length. 606 7.4. MN-HA Key Material From AAA Subtype 608 The MN-HA Key Material From AAA is subtype 1 of the Generalized MN-HA 609 Key Reply Extension (see section 6.4). 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | AAA SPI | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | HA SPI | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Algorithm Identifier | Replay Method | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Key Material ... 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 Figure 6: The MN-HA Key Material From AAA Subtype-Specific Data 624 AAA SPI A 32-bit opaque value, indicating the SPI that the 625 mobile node must use to determine the transform to use 626 for establishing the mobility security association 627 between the mobile node and its home agent. 629 HA SPI The SPI for the Mobility Security Association to the HA 630 that the mobile node creates using the Key Material 632 Algorithm Identifier 633 This field indicates the transform to be used for 634 future computations of the Mobile-Home Authentication 635 Extension (see section 4) 637 Replay Method 638 This field contains the replay method to be used for 639 future Registration messages (see section 4). 641 Key Material 642 A random [6] value of at least 128 bits. 644 The MN-HA Material Key From AAA subtype-specific data is shown in 645 figure 6. The Mobile Node calculates the MN-HA key using the Key 646 Material provided by the AAA server. The calculation proceeds by 647 using the key shared between the mobile node and the AAA server that 648 has previously been configured for securing all such communication 649 requirements with the AAA server which will be contacted within the 650 AAA infrastructure (see appendix C). The MN-HA key is intended for 651 use by the mobile node to secure future Mobile IP registrations with 652 its home agent. The MN-HA Key Material extension MUST appear in the 653 Registration Reply before the MN-HA Authentication extension. 655 Once the mobile node creates the MN-HA Key, by using the transform 656 specified in the AAA SPI, it stores the HA Security Information 657 indexed by the HA SPI in its list of Mobile Security Associations. 658 The mobile node uses the Identification field data from the 659 Registration Request as its initial synchronization data with the 660 home agent. 662 8. Error Values 664 Each entry in the following table contains the name of th Code [13] 665 value to be returned in a Registration Reply, the value for that 666 Code, and the section in which the error is first mentioned in this 667 specification. 669 Error Name Value Section 670 ---------------------- ----- --------- 671 MISSING_MN_FA 107 7.2 673 9. IANA Considerations 675 The numbers for the Generalized Extensions in section 6 are 676 taken from the numbering space defined for Mobile IP registration 677 extensions defined in RFC 3344 [13] as extended in RFC 2356 [11]. 678 The numbers suggested in this section are already in use by 679 implementations which have been tested for interoperability. 681 The number 7, assigned to the MN-HA Key Material From AAA Subtype 682 extension, is taken from the numbering space defined for the 683 Generalized MN-HA Key Reply Extension (see section 6.4). 685 The number 7, assigned to the MN-FA Key Request From AAA Subtype 686 extension, is taken from the numbering space defined for the 687 Generalized MN-FA Key Request Extension (see section 6.1). 689 The number 1, assigned to the MN-FA Key Material From AAA Subtype 690 extension, is taken from the numbering space defined for the 691 Generalized MN-FA Key Reply Extension (see section 6.2). 693 The number 7, assigned to the MN-HA Key Request From AAA Subtype 694 extension, is taken from the numbering space defined for the 695 Generalized MN-HA Key Request Extension (see section 6.3). 697 The Code value specified for error MISSING_MN_FA, listed in 698 section 8, MUST NOT conflict with any other code values listed in 699 RFC 3344, RFC 3024 [10], or RFC 2356 [11]. This value is to be 700 taken from the space of error values conventionally associated with 701 rejection by the foreign agent (i.e., 64-127). 703 Section 4 introduces the Replay Method Identifier namespace that 704 requires IANA management. This specification makes use of 1-3; 705 all other values other than zero (0) or one (1) are available for 706 assignment, pending review and approval by a Designated Expert [12]. 708 10. Security Considerations 710 The extensions in this document are intended to provide the 711 appropriate level of security for Mobile IP entities (mobile node, 712 foreign agent, and home agent) to calculate the Authentication Data 713 needed by authentication extensions used with Mobile IP registration 714 messages. The Mobility Security Associations resulting from use of 715 these extensions do not offer any higher level of security than what 716 is already implicit in use of the AAA security association between 717 the mobile node and the AAA. In order to deny any adversary the 718 luxury of unbounded time to analyze and break the secrecy of the 719 security association between the mobile node and the AAA server, that 720 security association needs to be refreshed periodically. 722 Since the extensions defined in this specification only carries Key 723 Material, which is used to derive keys, it does not expose any data 724 that could be used in an attack aimed at recovering the key shared 725 between the mobile node and the AAA. The authors do not believe this 726 specification introduces any new security vulnerability. 728 11. Acknowledgements 730 Thanks to Fredrik Johansson and the members of the IESG for their 731 useful comments on this document. 733 References 735 [1] B. Aboba and M. Beadles. The Network Access Identifier. 736 Request for Comments (Proposed Standard) 2486, Internet 737 Engineering Task Force, January 1999. 739 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 740 Levels. Request for Comments (Best Current Practice) 2119, 741 Internet Engineering Task Force, March 1997. 743 [3] P. Calhoun and C. Perkins. Mobile IP Network Access Identifier 744 Extension for IPv4. Request for Comments (Proposed Standard) 745 2794, Internet Engineering Task Force, January 2000. 747 [4] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 748 Challenge/Response Extension. Request for Comments (Proposed 749 Standard) 3012, Internet Engineering Task Force, December 2000. 751 [5] Pat R. Calhoun, John Loughney, E. Guttman, Glen Zorn, 752 and Jari Arkko. DIAMETER Base Protocol (work in 753 progress). Internet Draft, Internet Engineering Task 754 Force. draft-ietf-aaa-diameter-15.txt, October 2002. 756 [6] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 757 Recommendations for Security. Request for Comments 758 (Informational) 1750, Internet Engineering Task Force, December 759 1994. 761 [7] S. Glass, T. Hiller, S. Jacobs, and C. Perkins. Mobile IP 762 Authentication, Authorization, and Accounting Requirements. 763 Request for Comments (Proposed Standard) 2977, Internet 764 Engineering Task Force, October 2000. 766 [8] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 767 for Message Authentication. Request for Comments 768 (Informational) 2104, Internet Engineering Task Force, 769 February 1997. 771 [9] D. Mitton, M. St.Johns, S. Barkley, D. Nelson, B. Patil, 772 M. Stevens, and B. Wolff. Authentication, Authorization, 773 and Accounting: Protocol Evaluation. Request for Comments 774 (Informational) 3127, Internet Engineering Task Force, June 775 2001. 777 [10] Editor G. Montenegro. Reverse Tunneling for Mobile IP, revised. 778 Request for Comments (Proposed Standard) 3024, Internet 779 Engineering Task Force, January 2001. 781 [11] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 782 Mobile IP. Request for Comments (Informational) 2356, Internet 783 Engineering Task Force, June 1998. 785 [12] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 786 Considerations Section in RFCs. Request for Comments (Best 787 Current Practice) 2434, Internet Engineering Task Force, October 788 1998. 790 [13] C. Perkins. IP Mobility Support. Request for Comments 791 (Proposed Standard) 3344, Internet Engineering Task Force, 792 August 2002. 794 [14] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 795 Authentication Dial In User Service (RADIUS). Request for 796 Comments (Proposed Standard) 2865, Internet Engineering Task 797 Force, June 2000. 799 A. Changes Since Previous Revision 801 - Cleaned up terminology: 803 * New terminology entries for "Registration Key", "AAA", "AAA 804 entity", "Mobility Security Association", "AAA Security 805 Association", 807 * All instances of MN-FA key are now called "registration key" 809 * All instances of the key between mobile node and home agent 810 are called "MN-HA" key. 812 - Removed extraneous IANA considerations paragraph for HMAC_MD5 814 - Removed "Unsolicited" from subtype names 816 - Changed minimum Key Material length from 64 bits to 128 bits 818 B. Older Changes 820 In this revision of the document, there have been several major 821 changes as a result of suggestions received during Last Call. 823 - Generalized Key Extensions previously specified in another 824 document have been instead specified in this document in order 825 that this document can be self-contained and not dependent on the 826 standardization status of the other document. 828 - Additional explanation has been included for the purposes of 829 clarifying the problem space and solution approach. 831 - An appendix has been added to describe the expected AAA 832 infrastructure that will produce the keys that are to be 833 distributed within the extensions specified in this document. 835 - Ladder diagrams have been included to illustrate the expected 836 message flows containing the extensions defined in this document. 838 - HMAC-MD5 has been mandated for implementation by the mobile node, 839 for compatibility with RFC 3344 [13]. The example text has been 840 modified accordingly (see section 5). 842 - A table of Algorithm Identifiers has been identified as the 843 numbering space for transform selection when establishing 844 the security association using the keys distributed with the 845 extensions in this document. See section 4. 847 - A terminology section has been added. 849 - This appendix has been added. 851 C. AAA Infrastructure 853 In this appendix, we attempt to capture the main features of a basic 854 model for operation of AAA servers that is assumed for understanding 855 of the use of the Mobile IP registration extensions described in this 856 document. This information has been adapted from the discussion in 857 RFC 2977 [7]. 859 Within the Internet, a mobile node belonging to one administrative 860 domain (called the home domain) often needs to use resources 861 provided by another administrative domain (called the foreign 862 domain). A foreign agent that handles the mobile node's Registration 863 Request is likely to require that the mobile node provide some 864 credentials that can be authenticated before access to the resources 865 is permitted. These credentials may be provided as part of the 866 Mobile-AAA Authentication extension [4], relying on the existence 867 of an AAA infrastructure such as is described in this section, and 868 also described in RFC 2977 and RFC 3012 [4]. Such credentials are 869 typically managed by entities within the mobile node's home domain. 870 They may be also used for setting up secure communications with the 871 mobile node and the foreign agent, or between the mobile node and its 872 home agent if necessary. 874 The foreign agent often does not have direct access to the data 875 needed to verify the credentials. Instead, the foreign agent is 876 Local Domain Home Domain 877 +--------------+ +----------------------+ 878 | +------+ | | +------+ | 879 | | | | | | | | 880 | | AAAL | | | | AAAH | | 881 | | +-------------------+ | | 882 | +---+--+ | | +------+ | 883 | | | | | 884 | | | +----------------------+ 885 +------+ | +---+--+ | 886 | | | | | | MN = mobile node 887 | MN |- -|- -| FA | | FA = foreign agent 888 | | | | | | AAAL = local authority 889 +------+ | +------+ | AAAH = home authority 890 | | 891 +--------------+ 893 Figure 7: AAA Servers in Home and Local Domains 895 expected to consult an authority (typically in the same foreign 896 domain) in order to request proof that the mobile node has acceptable 897 credentials. Since the foreign agent and the local authority (AAAL) 898 are part of the same administrative domain, they are expected to have 899 established, or be able to establish for the necessary lifetime, a 900 secure channel for the purposes of exchanging sensitive (access) 901 information, and keeping it private from (at least) the visiting 902 mobile node. 904 The local authority (AAAL) itself may not have enough information 905 stored locally to carry out the verification for the credentials of 906 the mobile node. In contrast to the foreign agent, however, the AAAL 907 is expected to be configured with enough information to negotiate the 908 verification of mobile node credentials with its home domain. The 909 home and foreign domains should be configured with sufficient AAA 910 security associations and access controls so that they can negotiate 911 the authorization, and also enable the mobile node to acquire 912 Mobility Security Associations with the mobility agents within the 913 foreign domain. For the purposes of the key exchanges specified 914 within this document, the authorization is expected to depend only 915 upon secure authentication of the mobile node's credentials. 917 Once the authorization has been obtained by the local authority, and 918 the authority has notified the foreign agent about the successful 919 negotiation, the foreign agent can deliver the Registration Reply to 920 the mobile node along with the key material. 922 In figure 7, there might be many mobile nodes from many different 923 Home Domains. Each Home Domain provides a AAAH that can check 924 credentials originating from mobile nodes administered by that Home 925 Domain. There is a security model implicit in figure 7, and it is 926 crucial to identify the specific security associations assumed in 927 the security model. These security associations are illustrated in 928 figure 8, and are considered to be relatively long-lived security 929 associations. 931 First, it is natural to assume that the mobile node has a security 932 association with the AAAH, since that is roughly what it means for 933 the mobile node to belong to the home domain. 935 Second, from the model illustrated in figure 7 it is clear that AAAL 936 and AAAH have to share a security association, because otherwise 937 they could not rely on the authentication results, authorizations, 938 nor even the accounting data which might be transacted between them. 939 Requiring such bilateral AAA Security Associations is, however, 940 in the end not scalable; the AAA framework must provide for more 941 scalable mechanisms, but the methods by which such a broker model is 942 to be created are out of scope for this document. See RFC 2977 for 943 more details. 945 Finally, from figure 7, it is clear that the foreign agent can 946 naturally share a security association with the AAAL. This is 947 necessary in order for the model to work because the foreign agent 948 has to have a way to find out that it is permissible to allocate 949 the local resources to the mobile node, and further to transmit any 950 successful Registration Reply to the mobile node. 952 Figure 8 illustrates the natural security associations we understand 953 from our proposed model. Note that there may be, by mutual agreement 954 between AAAL and AAAH, a third party inserted between AAAL and 955 AAAH to help them arbitrate secure transactions in a more scalable 956 fashion. The broker model which has been designed to enable such 957 third-party processing should not have any effect on the Mobile IP 958 extensions specified in this document, and so no description is 959 provided here; see RFC 2977 [7] for more details. 961 Nodes in two separate administrative domains (for instance, AAAH 962 and AAAL) often must take additional steps to verify the identity 963 of their communication partners, or alternatively to guarantee 964 the privacy of the data making up the communication. While these 965 considerations lead to important security requirements, as mentioned 966 above in the context of security between servers, we consider the 967 exact choice of security associations between the AAA servers to 968 be beyond the scope of this document. The choices are unlikely 969 to depend upon Mobile IP, or any specific features of the general 970 model illustrated in figure 7. On the other hand, the security 971 +------+ +------+ 972 | | | | 973 | AAAL +--------------+ AAAH | 974 | | | | 975 +---+--+ +--+---+ 976 | | 977 | | 978 +---+--+ +--+---+ 979 MN = mobile node | | | | 980 FA = foreign agent | FA | | MN | 981 AAAL = local authority | | | | 982 AAAH = home authority +------+ +------+ 984 Figure 8: Security Associations 986 associations needed between Mobile IP entities are of central 987 importance in the design of the key derivation extensions in this 988 document. 990 One further detail deserves mention. The mobility security 991 association to be established between the mobile node and the foreign 992 agent have to be communicated to the foreign agent as well as to the 993 mobile node. The way that the key is distributed to the foreign 994 agent is not relevant to any material in this document, and is 995 expected to be handled as part of the AAA protocol processing between 996 the AAAH and AAAL, and the further AAA protocol processing between 997 the AAAL and the foreign agent. Any method by which the key can be 998 securely transmitted to the AAAL and then relayed (possibly with 999 re-encryption) to the foreign agent, is expected to be outside the 1000 jurisdiction of any Mobile IP specification, and thus compatible (by 1001 reason of non-interference) with the protocol extensions specified in 1002 this document. 1004 D. Message Flow for Requesting and Receiving Registration Keys 1006 In this section, we show message flows for requesting and receiving 1007 a reqistration key from the AAA infrastructure, described in 1008 section C. Challenge values, as specified in [4], might be added to 1009 the Advertisement and Registration messages for additional replay 1010 protection, but are not illustrated here. 1012 Diagram 9 illustrates the message flow for the case when the mobile 1013 node explicitly requests a registration key. 1015 In diagram 9, the following message flow is illustrated: 1017 MN FA AAA Infrastructure 1018 | | | 1019 |<--- Advertisement-----| | 1020 | (if needed) | | 1021 | | | 1022 |-- RReq+AAA Key Req.-->| | 1023 | |--- RReq + AAA Key Req.--->| 1024 | | | 1025 | |<--- RRep + AAA Key Rep.---| 1026 |<-- RRep+AAA Key Rep.--| | 1027 | | | 1029 Figure 9: Message Flows for Requesting and 1030 Receiving Registration Keys 1032 1. The foreign agent disseminates an Agent Advertisement. This 1033 advertisement MAY have been produced after receiving an Agent 1034 Solicitation from the mobile node (not shown in the diagram). 1036 2. The mobile node creates a Registration Request including the 1037 MN-HA Key Request and/ore MN-FA Key Request, as needed, along 1038 with an authorization-enabling authentication extension as 1039 required by Mobile IP [13]. 1041 3. The foreign agent relays the Registration Request either to its 1042 locally configured AAA Infrastructure (see appendix C), according 1043 to local policy. 1045 4. The foreign agent receives a Registration Reply with the 1046 appropriate indications for authorizing connectivity for the 1047 mobile node, which also includes the necessary AAA Key Material 1048 extensions. Along with this Registration Reply, the foreign 1049 agent may also receive key material by some other secure method 1050 appropriate for communications between it and its local AAA 1051 infrastructure. 1053 5. The foreign agent relays the Registration Reply to the mobile 1054 node, along with the new Key Material extensions to be used by 1055 the mobile node to establish security associations with the 1056 relevant mobility agents (foreign agent and/or home agent). 1058 Diagram 10 illustrates the message flow for the case when the 1059 mobile node receives an unsolicited registration key from the AAA 1060 Infrastructure. 1062 In diagram 10, the following message flow is illustrated: 1064 MN FA AAA Infrastructure 1065 | | | 1066 |<--- Advertisement-----| | 1067 | (if needed) | | 1068 | | | 1069 | ------ RReq --------->| | 1070 | |------- RReq ------------->| 1071 | | | 1072 | |<--- RRep + AAA Key Rep.---| 1073 |<-- RRep+AAA Key Rep.--| | 1074 | | | 1076 Figure 10: Message Flow for Receiving 1077 Unsolicited Registration Keys 1079 1. The foreign agent disseminates an Agent Advertisement. This 1080 advertisement MAY have been produced after receiving an Agent 1081 Solicitation from the mobile node (not shown in the diagram). 1083 2. The mobile node creates a Registration Request including an 1084 authorization-enabling authentication extension as required by 1085 Mobile IP [13]. 1087 3. The foreign agent relays the Registration Request either to its 1088 locally configured AAA Infrastructure (see appendix C), according 1089 to local policy. 1091 4. The foreign agent receives a Registration Reply with the 1092 appropriate indications for authorizing connectivity for the 1093 mobile node, which also includes the necessary AAA Key Material 1094 extensions. Along with this Registration Reply, the foreign 1095 agent may also receive key material by some other secure method 1096 appropriate for communications between it and its local AAA 1097 infrastructure. 1099 5. The foreign agent relays the Registration Reply to the mobile 1100 node, along with the new Key Material extensions to be used by 1101 the mobile node to establish security associations with the 1102 relevant mobility agents (foreign agent and/or home agent). 1104 Addresses 1106 The working group can be contacted via the current chairs: 1108 Basavaraj Patil Phil Roberts 1109 Nokia Megisto Corp. 1110 6000 Connection Dr. Suite 120 1111 20251 Century Blvd 1112 Irving, TX. 75039 Germantown MD 20874 1113 USA USA 1114 Phone: +1 972-894-6709 Phone: +1 847-202-9314 1115 Email: Basavaraj.Patil@nokia.com Email: PRoberts@MEGISTO.com 1117 Questions about this memo can also be directed to the authors: 1119 Charles E. Perkins Pat R. Calhoun 1120 Communications Systems Lab 1121 Nokia Research Center Black Storm Networks 1122 313 Fairchild Drive 250 Cambridge Avenue, Suite 200 1123 Mountain View, California 94043 Palo Alto, California, 94306 1124 USA USA 1125 Phone: +1-650 625-2986 Phone: +1 650-617-2932 1126 EMail: charliep@iprg.nokia.com Email: pcalhoun@bstormnetworks.com 1127 Fax: +1 650 625-2502 Fax: +1 650-786-6445