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