idnits 2.17.1 draft-ietf-mip4-aaa-key-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1281. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 248: '...es. Alternatively, the AAA server MAY...' RFC 2119 keyword, line 250: '... the mobile node MUST then calculate n...' RFC 2119 keyword, line 277: '...oreign agent, it SHOULD include an MN-...' RFC 2119 keyword, line 282: '...e home agent, it MUST add an MN-HA Key...' RFC 2119 keyword, line 287: '... the mobile node MUST add the MN-AAA A...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 672 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 [4], 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 3344 (ref. '1') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 2486 (ref. '2') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 3012 (ref. '3') (Obsoleted by RFC 4721) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '6') ** Obsolete normative reference: RFC 1750 (ref. '7') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '8') ** Obsolete normative reference: RFC 2434 (ref. '9') (Obsoleted by RFC 5226) Summary: 17 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Working Group Charles E. Perkins 3 INTERNET DRAFT Nokia Research Center 4 1 June 2004 Pat R. Calhoun 5 Airespace 6 AAA Registration Keys for Mobile IPv4 7 draft-ietf-mip4-aaa-key-06.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 36 the Internet today to provide authentication and authorization 37 services for dial-up computers. Mobile IP for IPv4 requires strong 38 authentication between the mobile node and its home agent. When the 39 mobile node shares an AAA Security Association with its home AAA 40 server, however, it is possible to use that AAA Security Association 41 to create derived Mobility Security Associations between the mobile 42 node and its home agent, and again between the mobile node and the 43 foreign agent currently offering connectivity to the mobile node. 44 This document specifies extensions to Mobile IP registration messages 45 that can be used to create Mobility Security Associations between the 46 mobile node and its home agent, and/or between the mobile node and a 47 foreign agent. 49 Contents 51 Status of This Memo i 53 Abstract i 55 1. Introduction 2 57 2. Terminology 3 59 3. Overview of Operations with Key Generation Nonce Extensions 4 61 4. Mobility Security Associations 7 63 5. Key Generation Nonce Creation and Key Derivation 8 65 6. Key Generation Extensions 9 66 6.1. Generalized MN-FA Key Generation Nonce Request Extension 9 67 6.2. Generalized MN-FA Key Generation Nonce Reply Extension . 10 68 6.3. Generalized MN-HA Key Generation Nonce Request Extension 12 69 6.4. Generalized MN-HA Key Generation Nonce Reply Extension . 13 71 7. Error Values 16 73 8. IANA Considerations 16 75 9. Security Considerations 17 77 10. Acknowledgements 17 79 References 18 81 A. Changes Since Previous Revision 20 83 B. Older Changes 20 85 C. AAA Infrastructure 21 87 D. Message Flow for Requesting and Receiving Registration Keys 25 89 Intellectual Property 28 91 Full Copyright Statement 28 93 Addresses 28 94 1. Introduction 96 AAA servers, such as RADIUS [11] and DIAMETER [12], are in use within 97 the Internet today to provide authentication and authorization 98 services for dial-up computers. Such services are likely to 99 be valuable for mobile nodes using Mobile IP for IPv4 [1], when 100 the nodes are attempting to connect to foreign domains with AAA 101 servers. In this document Mobile IP for IPv4 is called "Mobile 102 IPv4" or just "Mobile IP" for short, since no confusion with other 103 versions is expected. Requirements for interactions between AAA and 104 Mobile IP are outlined in RFC 2977 [13]; that document describes 105 an infrastructure which enables AAA servers to authenticate and 106 authorize network access requests from mobile nodes. See also 107 appendix C. The Mobile IP Registration Request is considered to 108 be a request for network access. It is then possible to augment 109 the functionality of the Mobile IP mobility agents so that they can 110 translate between Mobile IP registration messages and the messages 111 used within the AAA infrastructure, as described in RFC 2977. 112 Mobility agents and AAA servers that conform to the requirements of 113 RFC 2977 can be considered as appropriate network entities to support 114 the message types specified in this document. Please consult RFC 115 2977 [13] for further details. 117 This specification makes use of a single AAA Security Association 118 to create derivative Mobility Security Associations. A Mobility 119 Security Association in this specification is a simplex connection 120 that serves to authenticate MIPv4 control traffic between a MN and HA 121 and/or a MN and FA. A Mobility Security Association is identified by 122 the two end points, such as a MN IP address and a HA IP address, and 123 a SPI. Two nodes may have one or more Mobility Security Associations 124 established between each other; however, typically there is no reason 125 to have more than one Mobility Security Association between two 126 nodes. 128 This document specifies extensions to Mobile IP registration messages 129 that can be used to create Mobility Security Associations between 130 the MN and FA and/or MN and HA based on the AAA Security Association 131 between the MN and AAA server. These new Mobility Security 132 Associations may then be used to calculate the Authentication 133 Data needed by authentication extensions used in Mobile IP control 134 messages. 136 It is assumed that the security association between the mobile node 137 and its AAA server has been appropriately configured so that the 138 AAA server can provide key material to be used as the basis for the 139 necessary Mobility Security Association(s) between the mobile node 140 and its prospective mobility agents. 142 AAA servers typically use the Network Access Identifier (NAI) [2] to 143 uniquely identify the mobile node; the mobile node's home address is 144 not always necessary to provide that function. Thus, it is possible 145 for a mobile node to authenticate itself, and be authorized for 146 connection to the foreign domain, without having any home address. 147 However, for Mobile IP to work, the mobile node is required to 148 have a home address and a Mobility Security Association [1] with 149 its home agent. When the Mobile IP Registration Reply packet is 150 authenticated by the MN-AAA Authentication Extension [3], the mobile 151 node can verify that the key material contained in the extensions 152 were produced by the AAA server, and thus may be reliably used to 153 create Mobility Security Associations with the home agent and/or the 154 foreign agent. 156 It is also assumed that the AAA entities involved (i.e., the AAAH, 157 AAAL, and the AAA interface features of the foreign agents and home 158 agents) all have means outside of the scope of this document for 159 exchanging keys. The extensions within this document are intended to 160 work with any AAA protocol suite that allows for such key exchange, 161 as long as it satisfies the requirements specified in RFC 2977 [13]. 162 One such AAA protocol is defined within the Diameter framework [14]. 164 2. Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [4]. 170 AAA Authentication, Authorization, and Accounting 171 (see [10]). 173 AAA entity A network node processing AAA messages according to 174 the requirements for AAA protocols (see [10]). 176 AAA Security Association 177 A security association between a AAA entity 178 and another node needing the services of that 179 AAA entity. In this document all AAA Security 180 Associations are between a mobile node and its home 181 AAA server (AAAH). A mobile node's AAA Security 182 Association with its home AAA server (AAAH) may be 183 based either on the mobile node's IP address or on 184 its NAI [2]. The key is referred to as "AAA-key" in 185 this specification. 187 Key a number, kept secret. Only nodes in possession 188 of the key have any hope of using the security 189 transform to obtain correct results. 191 Key Generation Nonce 192 Nonce data used for the purpose of creating a key. 194 Mobility Security Association 195 A Mobility Security Association is a simplex 196 connection that applies security services to RFC 197 3344 MIPv4 control traffic between a MN and HA (or 198 MN and FA) using RFC 3344 Authentication Extensions. 199 A Mobility Security Association is uniquely 200 identified by the peer source and destination IP 201 addresses and an SPI. Two nodes may have one or more 202 Mobility Security Associations; however, typically 203 there is no reason to have more than one Mobility 204 Security Association between two nodes, except as a 205 transient condition during re-keying events. 207 Registration Key 208 A key used in the MN-FA or MN-HA Mobility Security 209 Association A registration key is typically 210 only used once or a very few times, and only 211 for the purposes of verifying a small volume of 212 Authentication data. 214 Security Algorithm 215 A set of rules for using input data and a secret key 216 for producing data for use in security protocols. 218 SPI 219 Security Parameters Index. The SPI is an arbitrary 220 32-bit value that assists in the identification of 221 an AAA, IP, or Mobility Security Association. 223 Other terminology is used as defined in the base Mobile IP 224 specification [1]. Furthermore, in order to simplify the discussion, 225 we have used the word "Extension" instead of "Subtype of the 226 Generalized Extension" in many cases. So, for instance, instead of 227 using the phrase "The MN-FA Key Generation Nonce From AAA Subtype 228 of the Generalized MN-FA Key Generation Nonce Reply Extension", we 229 would instead use the phrase "The MN-FA Key Generation Nonce From AAA 230 Extension". 232 3. Overview of Operations with Key Generation Nonce Extensions 234 When a mobile node depends on an AAA infrastructure to obtain 235 authorization for network connectivity and Mobile IP registration, 236 it may lack any pre-existing Mobility Security Associations with 237 either its home agent, or the foreign agent controlling the access to 238 the foreign network. The extensions defined in this document allow 239 a AAA entity to supply key material to mobile nodes to be used as 240 the basis of its Mobility Security Association with mobile agents. 241 The AAA entity that will act on these extensions is part of the AAA 242 infrastructure, and is typically identified within the foreign domain 243 by methods outside the scope of this specification (see appendix C). 245 The key material may be requested by the mobile node in new 246 extensions (defined below) to Mobile IP Registration Request 247 messages, and supplied to the mobile node in extensions to the Mobile 248 IP Registration Reply messages. Alternatively, the AAA server MAY 249 provide unsolicited key material via mobility agents to mobile nodes; 250 the mobile node MUST then calculate new keys and update or create 251 its relevant Mobility Security Association. The method by which key 252 material is supplied to the mobility agents themselves is out of 253 scope for this document, and would depend on the particular details 254 of the security architecture for the AAA servers in the foreign and 255 home domains (see RFC 2977 and appendix C). For the purposes of 256 this document, we assume that there is a suitable AAA infrastructure 257 available to the home and foreign agents, and that the mobile node 258 does have an AAA Security Association with at least one AAA server in 259 its home domain. 261 When a mobile node travels away from home, it may not have a Mobility 262 Security Association with its home agent, perhaps because it does 263 not yet have a home address [5]. The protocol and messages in 264 this document are intended to facilitate the following operations 265 which may occur between the mobile node, foreign agent, home agent, 266 and AAA servers in the visited (local) domain (Authentication, 267 Authorization and Accounting Local or AAAL) and in the home domain 268 (Authentication, Authorization, and Accounting Home or AAAH). In the 269 following sequence of messages, the only message flows specified in 270 this document are the Registration Request between the mobile node 271 and the foreign agent, and Registration Reply between the foreign 272 agent and the mobile node. The other messages described here result 273 from the presumed action of the AAA entities as described in RFC 274 2977. See also appendix D. 276 1. If the mobile node does not have a Mobility Security Association 277 with the foreign agent, it SHOULD include an MN-FA Key Generation 278 Nonce Request extension (see Section 6.1) as part of its 279 Registration Request that it sends to the Foreign Agent. 281 2. If the mobile node does not have a Mobility Security Association 282 with the home agent, it MUST add an MN-HA Key Generation Nonce 283 Request extension (see Section 6.3) as part of its Registration 284 Request that it sends to the Foreign Agent. 286 3. If one or more AAA Key Generation Nonce Request extensions 287 were added, the mobile node MUST add the MN-AAA Authentication 288 extension to its Registration Request. 290 4. By action of the foreign agent, which is presumed to be also a 291 AAA entity, the mobile node's key requests and authentication 292 data are transferred to the local AAA server (AAAL), typically 293 after reformatting to fit into the appropriate AAA messages, 294 which are out of scope for this document. 296 5. After the information within the MN-AAA Authentication extension 297 is verified by the AAA server in the home domain (AAAH), it then 298 also generates the key material that has been requested by the 299 mobile node, for the necessary Mobility Security Associations. 301 6. The respective keys for the Mobility Security Associations are 302 distributed to the Home Agent and Foreign Agent via the AAA 303 protocol. 305 7. The mobile node receives the Registration Reply message from the 306 Foreign Agent. 308 8. If a MN-HA Key Generation Nonce From AAA extension is present 309 in the Registration Reply message, then the mobile node MUST 310 create or update its Mobility Security Association with the Home 311 Agent indicated in the Registration Reply, using the key computed 312 from the key material in the MN-HA Key Generation Nonce From 313 AAA extension. In this case, if no MN-HA Key Generation Nonce 314 Reply extension is present, the mobile node MUST discard the 315 Registration Reply. 317 9. Using its (perhaps newly created) Mobility Security Association 318 with the home agent, the mobile node authenticates the 319 Registration Reply message by checking the Authentication Data in 320 the Mobile-Home Authentication extension. If the check fails, 321 the MN MUST discard the Registration Reply and the new Mobility 322 Security Association, reverting to the old Mobility Security 323 Association with the home agent, if any. 325 10. If the Registration Reply passes authentication and contains a 326 MN-FA Key Generation Nonce From AAA extension (see section 6.2), 327 the mobile node generates the registration key using the 328 Key Generation Nonce provided, according to its AAA Security 329 Association with the AAA. The resulting registration key is used 330 to establish the mobile node's Mobility Security Association with 331 its foreign agent, and is used to compute the authentication data 332 used in the Mobile-Foreign authentication extension. 334 If verification of the Mobile-Foreign authentication extension 335 fails, and if the MN-FA Key Generation Nonce Reply extension was 336 not protected by another, valid authentication extension, the MN 337 MUST discard the new Mobility Security Association, reverting to 338 the old Mobility Security Association with the foreign agent, if 339 any. 341 Any registration reply containing the MN-HA Key Generation Nonce 342 From AAA extension MUST also contain a subsequent Mobile Home 343 Authentication extension, created using the generated MN-HA key. 344 Similarly, a reply containing the MN-FA Key Generation Nonce 345 From AAA extension MUST also contain a subsequent Mobile Foreign 346 Authentication extension, created using the registration key. 348 4. Mobility Security Associations 350 Mobility Security Associations between Mobile IP entities (mobile 351 nodes, home agents, foreign agents) contain both the necessary 352 cryptographic key information and a way to identify the cryptographic 353 transform that uses the key to produce the authentication information 354 that is present in the Mobile-Home Authentication extension or 355 the Mobile-Foreign Authentication extension. In order for the 356 mobile node to make use of key material created by the AAA server, 357 the mobile node also has to be able to identify and select the 358 appropriate cryptographic transform that uses the key to produce the 359 authentication. 361 The transform identifiers are the same as those used in IPsec. They 362 are tabulated in the list of Authentication Algorithms allowable 363 as values for the "Attribute Type" (5) (i.e., "Authentication 364 Algorithm"), one of the classifications in the tabulated 365 Attribute Types for "IPSEC Security Association Attributes". See 366 http://www.iana.org/assignments/isakmp-registry for the full listing 367 of all Attribute Types and other Attributes for IPSEC Security 368 Associations. 370 Mobility Security Associations shared between mobile nodes and home 371 agents also require a replay protection method. The following table 372 contains the supported replay detection methods. 374 Replay Method Name Reference 375 -------------- ------------ -------------- 376 0,1 Reserved 377 2 Timestamps RFC 3344 [1] 378 3 Nonces RFC 3344 [1] 379 4-65535 Unallocated 381 5. Key Generation Nonce Creation and Key Derivation 383 This section contains the procedures followed in the creation of 384 the Key Generation Nonce by AAA servers, and the key derivation 385 procedures used by mobile nodes. Note that the AAA servers will also 386 deliver the keys to the mobility agents (home agent, foreign agent) 387 via the AAA protocol. AAA servers that follow these procedures will 388 produce results that can be understood by mobile nodes. The mobility 389 agents will faithfully transcribe the results into the appropriate 390 Mobile IP extensions. 392 The following example uses HMAC-SHA1 [6]. All mobile nodes and 393 mobility agents implementing Mobile IP [1] and implementing the 394 extensions specified in this document MUST implement HMAC-SHA1 [1]. 395 Other message authentication codes or keyed hash functions MAY also 396 be used. The particular algorithm used is configured as part of the 397 AAA Security Association between the MN and the AAAH server, which is 398 in turn indexed by the AAA SPI. 400 The following steps are performed on the AAAH server: 402 1. The AAA server identifies the mobile node. If the NAI field is 403 present in the Registration Request, then the NAI is used as the 404 mobile node identifier. Otherwise, the Home Address field of the 405 Registration Request is used. 407 2. The AAA server generates a random [7] value of at least 128 bits 408 to be used as the Key Generation Nonce. 410 3. The AAA server inserts the random value into the Key Generation 411 Nonce Reply extension in the "Key Generation Nonce" field. 413 The following steps are performed by the mobile node (here || 414 represents concatenation): 416 1. The mobile node calculates 418 key = HMAC-SHA1 (AAA-key, {Key Generation Nonce || mobile 419 node identifier}) 421 Here the Key Generation Nonce is from the extension in the 422 Registration Reply, and the mobile node identifier is the MN's 423 NAI, if present in the Registration Request, or the Home Address 424 from the Registration Request otherwise. 426 2. The mobile node creates the Mobility Security Association(s), 427 using the resulting key and the other relevant information in the 428 Key Generation Nonce Extension. 430 The secret key used within the HMAC-SHA1 computation is indicated by 431 the AAA Security Association indexed by the AAA SPI, which has been 432 previously configured as the basis for the AAA Security Association 433 between the mobile node and the AAA server creating the key material. 435 6. Key Generation Extensions 437 This section defines new Extensions to Mobile IP Registration 438 Requests and Replies [1]. 440 6.1. Generalized MN-FA Key Generation Nonce Request Extension 442 Figure 1 illustrates the Generalized MN-FA Key Generation Nonce 443 Request Extension (MN-FA KeyGen Request for short). 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Type | Subtype | Length | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Mobile Node SPI | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | MN-FA Key Generation Nonce Request Subtype Data ... 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Figure 1: The Generalized Mobile IP MN-FA Key Generation 456 Nonce Request Extension 458 Type TBD1 (not skippable) (see [1] and section 8) 460 Subtype A number assigned to identify the way in 461 which the MN-FA Key Generation Nonce Request 462 Subtype Data is to be used when generating the 463 registration key 465 Length The 16-bit Length field indicates the length of 466 the extension. It is equal to the number of 467 bytes in the MN-FA Key Generation Nonce Request 468 Subtype Data plus 4 (for the Mobile Node SPI 469 field). 471 Mobile Node SPI The Security Parameters Index that the mobile 472 node will assign for the Mobility Security 473 Association created for use with the registration 474 key. 476 MN-FA Key Generation Nonce Request Subtype Data 477 Data needed to carry out the creation of the 478 registration key on behalf of the mobile node. 480 The MN-FA KeyGen Request defines a set of extensions, identified 481 by subtype, which may be used by a mobile node in a Mobile IP 482 Registration Request message to request that some other entity create 483 a Registration Key for use by the mobile node with the mobile node's 484 new foreign agent. 486 This document defines the subtype 1 for the MN-FA Key Generation 487 Nonce >From AAA Request (MN-FA AAA KeyGen Request for short). The 488 MN-FA AAA KeyGen Request has a zero-length Subtype Data field 489 and MUST appear in the Registration Request before the MN-AAA 490 Authentication extension. The subtype data field is zero in length. 492 6.2. Generalized MN-FA Key Generation Nonce Reply Extension 494 The Generalized MN-FA Key Generation Nonce Reply extension (MN-FA 495 KeyGen Reply for short) supplies keying material requested by the 496 MN-FA KeyGen Request extension. Figure 2 illustrates the format of 497 the Generalized MN-FA Key Generation Nonce Reply Extension. 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Type | Subtype | Length | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | MN-FA Key Generation Nonce Reply Subtype Data ... 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Figure 2: The Generalized Mobile IP MN-FA Key 508 Generation Nonce Reply Extension 510 Type TBD2 (not skippable) (see [1] and section 8) 512 Subtype A number assigned to identify the way in which the 513 MN-FA Key Generation Nonce Reply Subtype Data is to be 514 used to obtain the registration key. 516 Length The 16-bit Length field is equal to the number of bytes 517 in the MN-FA Key Generation Nonce Reply Subtype Data. 519 MN-FA Key Generation Nonce Reply Subtype Data 520 An encoded copy of the keying material, along with any 521 other information needed by the recipient to create the 522 designated Mobility Security Association. 524 For each subtype, the format of the MN-FA Key Generation Nonce Reply 525 Subtype Data has to be separately defined according to the particular 526 method required to set up the Mobility Security Association. 528 For the subtype defined in this document, the MN-FA Key Generation 529 Nonce supplied in the data for a subtype of this extension may 530 come as a result of a request which was sent using a subtype of 531 the Generalized MN-FA Key Generation Nonce Request Extension. In 532 such cases, the SPI to be used when employing the Mobility Security 533 Association defined by the registration key is the same as given in 534 the original request. 536 Once the mobile node creates the Mobility Security Association with 537 the foreign agent, by using the transform indexed by the AAA SPI, it 538 stores that Mobility Security Association indexed by the FA SPI in 539 its list of Mobile Security Associations. 541 If the foreign agent receives a Registration Reply that has no MN-FA 542 Key Generation Nonce Reply extension, and if it has no existing 543 Mobility Security Association with the mobile node, the foreign agent 544 MAY change the Code value of the Registration Reply to MISSING_MN_FA 545 (see section 7), effectively causing the registration to fail. 547 This document defines subtype 1 of the MN-FA KeyGen Reply for the 548 MN-FA Key Generation Nonce From AAA extension (MN-FA AAA KeyGen Reply 549 for short), shown in figure 3. 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Lifetime | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | AAA SPI | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | FA SPI | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Algorithm Identifier | Key Generation Nonce ... 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 Figure 3: The MN-FA Key Generation Nonce From AAA 564 Subtype-Specific Data 566 lifetime This field indicates the duration of time (in seconds) 567 for which the keying material used to create the 568 registration key is valid. 570 AAA SPI A 32-bit opaque value, indicating the SPI that the 571 mobile node must use to determine the transform to use 572 for establishing the Mobility Security Association 573 between the mobile node and its prospective foreign 574 agent. 576 FA SPI The SPI for the Mobility Security Association to the FA 577 that the mobile node creates using the Key Generation 578 Nonce 580 Algorithm Identifier 581 This field indicates the transform to be used (stored 582 as part of the Mobility Security Association with 583 the foreign agent, and selected from among the 584 values in the "Authentication Algorithm" table 585 cited in section 4), for future computations of the 586 Mobile-Foreign Authentication Extension. 588 Key Generation Nonce 589 A random [7] value of at least 128 bits. 591 The MN-FA AAA KeyGen Reply extension MUST appear in the Registration 592 Reply before the Mobile-Foreign Authentication extension. 594 The Key Generation Nonce is provided by the AAA server for use by the 595 mobile node in creating the registration key, which is used to secure 596 future Mobile IP registrations with the same foreign agent. 598 6.3. Generalized MN-HA Key Generation Nonce Request Extension 600 Figure 4 illustrates the Generalized MN-HA Key Generation Nonce 601 Request Extension (MN-HA KeyGen Request for short). 603 Type TBD3 (not skippable) (see [1] and section 8) 605 Subtype a number assigned to identify the way in 606 which the MN-HA Key Generation Nonce Request 607 Subtype Data is to be used when generating the 608 registration key 610 Length The 16-bit Length field indicates the length of 611 the extension. It is equal to the number of 612 bytes in the MN-HA Key Generation Nonce Request 614 0 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Type | Subtype | Length | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Mobile Node SPI | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | MN-HA Key Generation Nonce Request Subtype Data ... 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 Figure 4: The Generalized Mobile IP MN-HA Key Generation 625 Nonce Request Extension 627 Subtype Data plus 4 (for the Mobile Node SPI 628 field). 630 Mobile Node SPI The Security Parameters Index that the mobile 631 node will assign for the Mobility Security 632 Association created for use with the registration 633 key. 635 MN-HA Key Generation Nonce Request Subtype Data 636 Data needed to carry out the creation of the 637 MN-HA key on behalf of the mobile node. 639 The MN-HA KeyGen Request Extension defines a set of extensions, 640 identified by subtype, which may be used by a mobile node in a Mobile 641 IP Registration Request message to request that some other entity 642 create an MN-HA key for use by the mobile node with the mobile node's 643 new home agent. 645 This document defines the subtype 1 for the MN-HA Key Generation 646 Nonce >From AAA Request (MN-HA AAA KeyGen Request for short). The 647 MN-HA AAA KeyGen Request has a zero-length Subtype Data field 648 and MUST appear in the Registration Request before the MN-AAA 649 Authentication extension. The subtype data field is zero in length. 651 6.4. Generalized MN-HA Key Generation Nonce Reply Extension 653 The Generalized MN-HA Key Generation Nonce Reply extension (MN-HA 654 KeyGen Reply for short) supplies keying material requested by the 655 MN-HA KeyGen Request extension. Figure 5 illustrates the format of 656 the Generalized MN-HA Key Generation Nonce Reply Extension. 658 Type TBD4 (not skippable) (see [1] and section 8) 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Type | Subtype | Length | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Lifetime | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | MN-HA Key Generation Nonce Reply Subtype Data ... 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 Figure 5: The Generalized Mobile IP MN-HA Key 670 Generation Nonce Reply Extension 672 Subtype a number assigned to identify the way in which the 673 MN-HA Key Generation Nonce Reply Subtype Data is to be 674 used to obtain the MN-HA key 676 Length The 16-bit Length field indicates the length of the 677 extension. It is equal to the number of bytes in the 678 MN-HA Key Generation Nonce Reply Subtype Data plus 4 679 (for the Lifetime field). 681 Lifetime This field indicates the duration of time (in seconds) 682 for which the MN-HA key is valid. 684 MN-HA Key Generation Nonce Reply Subtype Data 685 Data used to derive the MN-HA key, along with any other 686 information needed by the mobile node to create the 687 designated Mobility Security Association with the home 688 agent. 690 For each subtype, the format of the MN-HA Key Generation Nonce Reply 691 Subtype Data has to be separately defined according to the particular 692 method required to set up the Mobility Security Association. 694 This document defines subtype 1 of the MN-HA KeyGen Reply for the 695 MN-HA Key Generation Nonce From AAA extension (MN-HA AAA KeyGen Reply 696 for short), shown in figure 6. 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | AAA SPI | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | HA SPI | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Algorithm Identifier | Replay Method | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Key Generation Nonce ... 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Figure 6: The MN-HA Key Generation Nonce From AAA 711 Subtype-Specific Data 713 AAA SPI A 32-bit opaque value, indicating the SPI that the 714 mobile node must use to determine the transform to use 715 for establishing the Mobility Security Association 716 between the mobile node and its home agent. 718 HA SPI The SPI for the Mobility Security Association to the HA 719 that the mobile node creates using the Key Generation 720 Nonce 722 Algorithm Identifier 723 This field indicates the transform to be used for 724 future computations of the Mobile-Home Authentication 725 Extension (see section 4) 727 Replay Method 728 This field contains the replay method to be used for 729 future Registration messages (see section 4). 731 Key Generation Nonce 732 A random [7] value of at least 128 bits. 734 The MN-HA AAA KeyGen Reply subtype-specific data is shown in 735 figure 6. The Mobile Node calculates the MN-HA key using the 736 Key Generation Nonce provided by the AAA server. The calculation 737 proceeds by using the key shared between the mobile node and the 738 AAA server that has previously been configured for securing all 739 such communication requirements with the AAA server which will be 740 contacted within the AAA infrastructure (see appendix C). The MN-HA 741 key is intended for use by the mobile node to secure future Mobile 742 IP registrations with its home agent. The MN-HA AAA KeyGen Reply 743 extension MUST appear in the Registration Reply before the MN-HA 744 Authentication extension. 746 Once the mobile node creates the MN-HA Key, by using the transform 747 specified in the AAA SPI, it stores the HA Security Information 748 indexed by the HA SPI in its list of Mobile Security Associations. 749 The mobile node uses the Identification field data from the 750 Registration Request as its initial synchronization data with the 751 home agent. 753 7. Error Values 755 Each entry in the following table contains the name of the Code [1] 756 value to be returned in a Registration Reply, the value for that 757 Code, and the section in which the error is first mentioned in this 758 specification. 760 Error Name Value Section 761 ---------------------- ----- --------- 762 MISSING_MN_FA 107 6.2 764 8. IANA Considerations 766 This document defines 4 new extensions (see Section 6) taken from the 767 (non-skippable) numbering space defined for Mobile IP registration 768 extensions defined in RFC 3344 [1] as extended in RFC 2356 [8]. The 769 values for these extensions are: 771 Name Value Section 772 --------------------- ------- --------- 773 MN-FA-KeyGen Request TBD1 6.1 774 MN-FA-KeyGen Reply TBD2 6.2 775 MN-HA-KeyGen Request TBD3 6.3 776 MN-HA-KeyGen Reply TBD4 6.4 778 IANA will create and maintain new registry for the KeyGen 779 Request/Reply subtypes. The initial contents of the registry is a 780 single entry for the subtypes defined in this document: 782 Name Value Section 783 ----------------------------- ------- --------- 784 KeyGen Request/Reply from AAA 1 6 786 New subtypes for these two registries are assigned through Standards 787 Action as defined in [9]. 789 IANA will assign a code value for error MISSING_MN_FA, listed in 790 section 7. This value is to be taken from the space of error values 791 conventionally associated with rejection by the foreign agent (i.e., 792 64-127). 794 IANA will create and maintain a namespace for the Replay Method 795 Identifier. This specification makes use of 2 and 3; all other 796 values other than zero (0) and (1) are available for assignment, 797 pending review and approval by a Designated Expert [9]. 799 9. Security Considerations 801 The extensions in this document are intended to provide the 802 appropriate level of security for Mobile IP entities (mobile node, 803 foreign agent, and home agent) to calculate the Authentication Data 804 needed by authentication extensions used with Mobile IP registration 805 messages. The Mobility Security Associations resulting from use of 806 these extensions do not offer any higher level of security than what 807 is already implicit in use of the AAA Security Association between 808 the mobile node and the AAAH. In order to deny any adversary the 809 luxury of unbounded time to analyze and break the secrecy of the AAA 810 Security Association between the mobile node and the AAA server, that 811 AAA Security Association MUST be refreshed periodically. 813 The provisioning and refreshing of the AAA key in the MN and AAA 814 server is outside the scope of this document. 816 Since the Reply extensions defined in this specification only carry 817 Key Generation Nonces, which are used to derive keys, they do not 818 expose any data that could be used in an attack aimed at recovering 819 the key shared between the mobile node and the AAA. The authors 820 do not believe this specification introduces any new security 821 vulnerability. 823 10. Acknowledgements 825 Thanks to Fredrik Johansson, Tom Hiller, and the members of the IESG 826 for their useful comments. Thanks especially to Tom Hiller who has 827 contributed many textual improvements to later revisions of this 828 document. 830 Funding for the RFC Editor function is currently provided by the 831 Internet Society. 833 Normative References 835 [1] C. Perkins. IP Mobility Support. Request for Comments 836 (Proposed Standard) 3344, Internet Engineering Task Force, 837 August 2002. 839 [2] B. Aboba and M. Beadles. The Network Access Identifier. 840 Request for Comments (Proposed Standard) 2486, Internet 841 Engineering Task Force, January 1999. 843 [3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 844 Challenge/Response Extension. Request for Comments (Proposed 845 Standard) 3012, Internet Engineering Task Force, December 2000. 847 [4] S. Bradner. Key words for use in RFCs to Indicate Requirement 848 Levels. Request for Comments (Best Current Practice) 2119, 849 Internet Engineering Task Force, March 1997. 851 [5] P. Calhoun and C. Perkins. Mobile IP network access identifier 852 extension for IPv4. Request for Comments (Proposed Standard) 853 2794, Internet Engineering Task Force, January 2000. 855 [6] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 856 for Message Authentication. Request for Comments 857 (Informational) 2104, Internet Engineering Task Force, 858 February 1997. 860 [7] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 861 Recommendations for Security. Request for Comments 862 (Informational) 1750, Internet Engineering Task Force, December 863 1994. 865 [8] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 866 Mobile IP. Request for Comments (Informational) 2356, Internet 867 Engineering Task Force, June 1998. 869 [9] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 870 Considerations Section in RFCs. Request for Comments (Best 871 Current Practice) 2434, Internet Engineering Task Force, October 872 1998. 874 Informative References 876 [10] D. Mitton, M. St.Johns, S. Barkley, D. Nelson, B. Patil, 877 M. Stevens, and B. Wolff. Authentication, Authorization, 878 and Accounting: Protocol Evaluation. Request for Comments 879 (Informational) 3127, Internet Engineering Task Force, June 880 2001. 882 [11] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 883 Authentication Dial In User Service (RADIUS). Request for 884 Comments (Proposed Standard) 2865, Internet Engineering Task 885 Force, June 2000. 887 [12] Pat R. Calhoun, John Loughney, E. Guttman, Glen Zorn, and Jari 888 Arkko. DIAMETER base protocol (work in progress). Internet 889 Draft, Internet Engineering Task Force, October 2002. 891 [13] S. Glass, T. Hiller, S. Jacobs, and C. Perkins. Mobile IP 892 Authentication, Authorization, and Accounting Requirements. 893 Request for Comments (Proposed Standard) 2977, Internet 894 Engineering Task Force, October 2000. 896 [14] P. Calhoun and C. Perkins. DIAMETER mobile IP extensions (work 897 in progress). Internet Draft, Internet Engineering Task Force, 898 February 2004. 900 A. Changes Since Previous Revision 902 The following changes were made in this document since the previous 903 revision. 905 - Clarified use of NAI by AAAH when computing the key as detailed 906 in Section 5 908 B. Older Changes 910 The following changes were also made as a result of suggestions 911 received during and after Last Call. 913 - Expanded the definition of "Registration Key" to include MN-HA as 914 well as MN-FA key. 916 - Eliminated HMAC-MD5 with HMAC-SHA1. 918 - Reorganized extensions so that subtypes appear right after the 919 generalized forms. 921 - Reorganized IANA considerations to reflect the single number 922 space for all 4 kinds of subtypes. 924 - Generalized Key Extensions previously specified in another 925 document have been instead specified in this document in order 926 that this document can be self-contained and not dependent on the 927 standardization status of the other document. 929 - Additional explanation has been included for the purposes of 930 clarifying the problem space and solution approach. 932 - An appendix has been added to describe the expected AAA 933 infrastructure that will produce the keys that are to be 934 distributed within the extensions specified in this document. 936 - Ladder diagrams have been included to illustrate the expected 937 message flows containing the extensions defined in this document. 939 - HMAC-MD5 has been mandated for implementation by the mobile node, 940 for compatibility with RFC 3344 [1]. The example text has been 941 modified accordingly (see section 5). 943 - A table of Algorithm Identifiers has been identified as the 944 numbering space for transform selection when establishing the 945 Mobility Security Association using the keys distributed with the 946 extensions in this document. See section 4. 948 - A terminology section has been added. 950 - This appendix has been added. 952 * New terminology entries for "Registration Key", "AAA", "AAA 953 entity", "Mobility Security Association", "AAA Security 954 Association", 956 * All instances of MN-FA key are now called "registration key" 958 * All instances of the key between mobile node and home agent 959 are called "MN-HA" key. 961 - Removed extraneous IANA considerations paragraph for HMAC_MD5 963 - Removed "Unsolicited" from subtype names 965 - Changed minimum Key Material length from 64 bits to 128 bits 967 - Cleaned up terminology: 969 * Clarified the use of "Security Association" throughout the 970 document as either "IPSec" or "Mobility" or "AAA". 972 * Changed "Key Material" to "Key Generation Nonce". 974 C. AAA Infrastructure 976 In this appendix, we attempt to capture the main features of a basic 977 model for operation of AAA servers that is assumed for understanding 978 of the use of the Mobile IP registration extensions described in this 979 document. This information has been adapted from the discussion in 980 RFC 2977 [13]. 982 Within the Internet, a mobile node belonging to one administrative 983 domain (called the home domain) often needs to use resources 984 provided by another administrative domain (called the foreign 985 domain). A foreign agent that handles the mobile node's Registration 986 Request is likely to require that the mobile node provide some 987 credentials that can be authenticated before access to the resources 988 is permitted. These credentials may be provided as part of the 989 Mobile-AAA Authentication extension [3], relying on the existence 990 of an AAA infrastructure such as is described in this section, and 991 also described in RFC 2977 and RFC 3012 [3]. Such credentials are 992 typically managed by entities within the mobile node's home domain. 993 They may be also used for setting up secure communications with the 994 mobile node and the foreign agent, or between the mobile node and its 995 home agent if necessary. 997 Local Domain Home Domain 998 +--------------+ +----------------------+ 999 | +------+ | | +------+ | 1000 | | | | | | | | 1001 | | AAAL | | | | AAAH | | 1002 | | +-------------------+ | | 1003 | +---+--+ | | +------+ | 1004 | | | | | 1005 | | | +----------------------+ 1006 +------+ | +---+--+ | 1007 | | | | | | MN = mobile node 1008 | MN |- -|- -| FA | | FA = foreign agent 1009 | | | | | | AAAL = local authority 1010 +------+ | +------+ | AAAH = home authority 1011 | | 1012 +--------------+ 1014 Figure 7: AAA Servers in Home and Local Domains 1016 The foreign agent often does not have direct access to the data 1017 needed to verify the credentials. Instead, the foreign agent is 1018 expected to consult an authority (typically in the same foreign 1019 domain) in order to request proof that the mobile node has acceptable 1020 credentials. Since the foreign agent and the local authority (AAAL) 1021 are part of the same administrative domain, they are expected to have 1022 established, or be able to establish for the necessary lifetime, a 1023 secure channel for the purposes of exchanging sensitive (access) 1024 information, and keeping it private from (at least) the visiting 1025 mobile node. 1027 The local authority (AAAL) itself may not have enough information 1028 stored locally to carry out the verification for the credentials 1029 of the mobile node. In contrast to the foreign agent, however, 1030 the AAAL is expected to be configured with enough information to 1031 negotiate the verification of mobile node credentials with its home 1032 domain. The home and foreign domains should be configured with 1033 sufficient IP Security Associations (i.e., IPSec) and access controls 1034 so that they can negotiate the authorization, and also enable the 1035 mobile node to acquire Mobility Security Associations with the 1036 mobility agents within the foreign domain. For the purposes of the 1037 key exchanges specified within this document, the authorization is 1038 expected to depend only upon secure authentication of the mobile 1039 node's credentials. 1041 Once the authorization has been obtained by the local authority, and 1042 the authority has notified the foreign agent about the successful 1043 negotiation, the foreign agent can deliver the Registration Reply to 1044 the mobile node along with the key material. 1046 In figure 7, there might be many mobile nodes from many different 1047 Home Domains. Each Home Domain provides a AAAH that can check 1048 credentials originating from mobile nodes administered by that Home 1049 Domain. There is a security model implicit in figure 7, and it is 1050 crucial to identify the specific security associations assumed in 1051 the security model. These IP Security Associations are illustrated 1052 in figure 8, and are considered to be relatively long-lived security 1053 associations. 1055 First, it is natural to assume that the mobile node has an AAA 1056 Security Association with the AAAH, since that is roughly what it 1057 means for the mobile node to belong to the home domain. 1059 Second, from the model illustrated in figure 7 it is clear that AAAL 1060 and AAAH have to share an IP Security Association, because otherwise 1061 they could not rely on the authentication results, authorizations, 1062 nor even the accounting data which might be transacted between them. 1063 Requiring such bilateral IP Security Associations is, however, in the 1064 end not scalable; the AAA framework must provide for more scalable 1065 mechanisms, but the methods by which such a broker model is to be 1066 created are out of scope for this document. See RFC 2977 for more 1067 details. 1069 Finally, from figure 7, it is clear that the foreign agent can 1070 naturally share an IP Security Association with the AAAL. This is 1071 necessary in order for the model to work because the foreign agent 1072 has to have a way to find out that it is permissible to allocate 1073 the local resources to the mobile node, and further to transmit any 1074 successful Registration Reply to the mobile node. 1076 Figure 8 illustrates the IP Security Associations we understand from 1077 our proposed model. Note that there may be, by mutual agreement 1078 between AAAL and AAAH, a third party inserted between AAAL and 1079 AAAH to help them arbitrate secure transactions in a more scalable 1080 fashion. The broker model which has been designed to enable such 1081 third-party processing should not have any effect on the Mobile IP 1082 extensions specified in this document, and so no description is 1083 provided here; see RFC 2977 [13] for more details. 1085 Nodes in two separate administrative domains (for instance, AAAH 1086 and AAAL) often must take additional steps to verify the identity 1087 of their communication partners, or alternatively to guarantee 1088 the privacy of the data making up the communication. While these 1089 considerations lead to important security requirements, as mentioned 1090 above in the context of security between servers, we consider the 1091 exact choice of IP Security Associations between the AAA servers to 1092 +------+ +------+ 1093 | | | | 1094 | AAAL +--------------+ AAAH | 1095 | | | | 1096 +---+--+ +--+---+ 1097 | | 1098 | | 1099 +---+--+ +--+---+ 1100 MN = mobile node | | | | 1101 FA = foreign agent | FA | | MN | 1102 AAAL = local authority | | | | 1103 AAAH = home authority +------+ +------+ 1105 Figure 8: IP Security Associations 1107 be beyond the scope of this document. The choices are unlikely to 1108 depend upon Mobile IP, or any specific features of the general model 1109 illustrated in figure 7. On the other hand, the Mobility Security 1110 Associations needed between Mobile IP entities are of central 1111 importance in the design of the key derivation extensions in this 1112 document. 1114 One further detail deserves mention. The Mobility Security 1115 Association to be established between the mobile node and the foreign 1116 agent has to be communicated to the foreign agent as well as to the 1117 mobile node. The following requirements are placed on the mechanism 1118 used by the AAA infrastructure to effect key distribution: 1120 - The AAAH must establish strong, fresh session keys. 1122 - The mechanism must maintain algorithm independence, allowing for 1123 the distribution of authentication algorithm identification along 1124 with the keys. 1126 - The mechanism must include replay detection. 1128 - The mechanism must authenticate all parties, including the AAA 1129 servers and the FA and HA. 1131 - The mechanism must provide for authorization of the client, FA, 1132 and HA. 1134 - The mechanism must not rely on plaintext passwords. 1136 - The mechanism must maintain confidentiality of session keys. 1138 - The mechanism must uniquely name session keys. 1140 - The mechanism must be such that the compromise of a single FA 1141 and HA cannot compromise any other part of the system, including 1142 session keys and long-term keys 1144 - The mechanism must bind key(s) to an appropriate context 1146 - The mechanism must not expose the keys to entities other than the 1147 AAAH and FA (or HA in the case of key distribution to the HA). 1149 The way that the key is distributed to the foreign agent (or 1150 home agent) is expected to be handled as part of the AAA protocol 1151 processing between the AAAH and AAAL, and the further AAA protocol 1152 processing between the AAAL and the foreign agent. Such processing 1153 is outside the scope of this document, but must satisfy the above 1154 requirements. 1156 D. Message Flow for Requesting and Receiving Registration Keys 1158 In this section, we show message flows for requesting and receiving 1159 a registration key from the AAA infrastructure, described in 1160 section C. Challenge values, as specified in [3], might be added to 1161 the Advertisement and Registration messages for additional replay 1162 protection, but are not illustrated here. 1164 Diagram 9 illustrates the message flow for the case when the mobile 1165 node explicitly requests keying material to create registration keys. 1167 MN FA AAA Infrastructure 1168 | | | 1169 |<--- Advertisement-----| | 1170 | (if needed) | | 1171 | | | 1172 |-- RReq+AAA Key Req.-->| | 1173 | |--- RReq + AAA Key Req.--->| 1174 | | | 1175 | |<--- RRep + AAA Key Rep.---| 1176 |<-- RRep+AAA Key Rep.--| | 1177 | | | 1179 Figure 9: Message Flows for Requesting and 1180 Receiving Key Generation Nonce 1182 In diagram 9, the following message flow is illustrated: 1184 1. The foreign agent disseminates an Agent Advertisement. This 1185 advertisement MAY have been produced after receiving an Agent 1186 Solicitation from the mobile node (not shown in the diagram). 1188 2. The mobile node creates a Registration Request including the 1189 MN-HA AAA KeyGen Request and/or MN-FA AAA KeyGen Request, as 1190 needed, along with an authorization-enabling authentication 1191 extension as required by Mobile IP [1]. 1193 3. The foreign agent relays the Registration Request and/or Key 1194 Request(s) to its locally configured AAA Infrastructure (see 1195 appendix C), according to local policy. 1197 4. The foreign agent receives a AAA Response with the appropriate 1198 indications for authorizing connectivity for the mobile node. 1199 Along with this AAA Response, the foreign agent may also receive 1200 key material by some secure method appropriate for communications 1201 between it and its local AAA infrastructure. At this point if 1202 the foreign agent has not relayed the Registration Request, 1203 it forwards it directly to the Home Agent and waits for a 1204 Registration Reply (not shown in the figure). 1206 5. The foreign agent relays the Registration Reply to the mobile 1207 node, along with the new AAA KeyGen Reply extensions to be used 1208 by the mobile node to establish Mobility Security Associations 1209 with the relevant mobility agents (foreign agent and/or home 1210 agent). 1212 Diagram 10 illustrates the message flow for the case when the 1213 mobile node receives an unsolicited keying matereial from the AAA 1214 Infrastructure. 1216 MN FA AAA Infrastructure 1217 | | | 1218 |<--- Advertisement-----| | 1219 | (if needed) | | 1220 | | | 1221 | ------ RReq --------->| | 1222 | |------- RReq ------------->| 1223 | | | 1224 | |<--- RRep + AAA Key Rep.---| 1225 |<-- RRep+AAA Key Rep.--| | 1226 | | | 1228 Figure 10: Message Flow for Receiving Unsolicited 1229 Key Generation Nonce 1231 In diagram 10, the following message flow is illustrated: 1233 1. The foreign agent disseminates an Agent Advertisement. This 1234 advertisement MAY have been produced after receiving an Agent 1235 Solicitation from the mobile node (not shown in the diagram). 1237 2. The mobile node creates a Registration Request including an 1238 authorization-enabling authentication extension as required by 1239 Mobile IP [1]. 1241 3. The foreign agent sends a AAA Request (possibly containing 1242 the Registration Request) to its locally configured AAA 1243 Infrastructure (see appendix C), according to local policy. 1245 4. The foreign agent receives a AAA Response with the appropriate 1246 indications for authorizing connectivity for the mobile node. 1247 Along with this AAA Response, the foreign agent may also receive 1248 key material by some secure method appropriate for communications 1249 between it and its local AAA infrastructure. At this point, 1250 if the foreign agent has not relayed the Registration Request, 1251 it forwards it directly to the Home Agent and waits for a 1252 Registration Reply (not shown in the figure). 1254 5. The foreign agent relays the Registration Reply to the mobile 1255 node, along with the new KeyGen Reply extensions to be used by 1256 the mobile node to establish Mobility Security Associations with 1257 the relevant mobility agents (foreign agent and/or home agent). 1259 Intellectual Property 1261 The IETF takes no position regarding the validity or scope of any 1262 Intellectual Property Rights or other rights that might be claimed to 1263 pertain to the implementation or use of the technology described in 1264 this document or the extent to which any license under such rights 1265 might or might not be available; nor does it represent that it has 1266 made any independent effort to identify any such rights. Information 1267 on the procedures with respect to rights in RFC documents can be 1268 found in BCP 78 and BCP 79. 1270 Copies of IPR disclosures made to the IETF Secretariat and any 1271 assurances of licenses to be made available, or the result of an 1272 attempt made to obtain a general license or permission for the 1273 use of such proprietary rights by implementers or users of this 1274 specification can be obtained from the IETF on-line IPR repository at 1275 http://www.ietf.org/ipr. 1277 The IETF invites any interested party to bring to its attention any 1278 copyrights, patents or patent applications, or other proprietary 1279 rights that may cover technology that may be required to implement 1280 this standard. Please address the information to the IETF at 1281 ietf-ipr@ietf.org. 1283 Full Copyright Statement 1285 Full Copyright Statement 1287 Copyright (C) The Internet Society (2004). This document is subject 1288 to the rights, licenses and restrictions contained in BCP 78 and 1289 except as set forth therein, the authors retain all their rights. 1291 This document and the information contained herein are provided 1292 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1293 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1294 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1295 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1296 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1297 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1299 Addresses 1301 The working group can be contacted via the current chairs: 1303 Pete McCann Henrik Levkowetz 1304 Lucent Technologies ipUnplugged AB 1305 Rm 9C-226R Arenavagen 27 1306 1960 Lucent Lane Stockholm S-121 28 1307 Naperville, IL 60563 Sweden 1308 USA 1309 Phone: +1 630 369 9693 Phone: +46 708 32 16 08 1310 Email: mccap@lucent.com Email: henrik@levkowetz.com 1312 Questions about this memo can also be directed to the authors: 1314 Charles E. Perkins Pat R. Calhoun 1315 Communications Systems Lab 1316 Nokia Research Center Airespace Networks 1317 313 Fairchild Drive 110 Nortech Parkway 1318 Mountain View, California 94043 San Jose, CA 95134 1319 USA USA 1320 Phone: +1-650 625-2986 Phone: +1 408 635 2000 1321 EMail: charles.perkins@nokia.com Email: pcalhoun@diameter.org 1322 Fax: +1 650 625-2502 Fax: +1 720-293-7501 1324 --CQe9RI7RYd--