idnits 2.17.1 draft-ietf-mobileip-aaa-key-09.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 1 character 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 184: '...oreign agent, it SHOULD include an MN-...' RFC 2119 keyword, line 189: '...e home agent, it MUST add an MN-HA Key...' RFC 2119 keyword, line 230: '...om AAA extension MUST also contain a s...' RFC 2119 keyword, line 233: '...om AAA extension MUST also contain a s...' RFC 2119 keyword, line 280: '... extensions specified in this document, MUST implement HMAC-MD5 [12]....' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 374 has weird spacing: '...Subtype a n...' == Line 455 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. '3') (Obsoleted by RFC 4721) == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-07 ** Obsolete normative reference: RFC 1750 (ref. '5') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 2977 (ref. '6') ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '7') ** Obsolete normative reference: RFC 2109 (ref. '8') (Obsoleted by RFC 2965) ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '10') ** Obsolete normative reference: RFC 2434 (ref. '11') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3220 (ref. '12') (Obsoleted by RFC 3344) 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 26 February 2002 Pat R. Calhoun 4 Black Storm Systems 6 AAA Registration Keys for Mobile IP 7 draft-ietf-mobileip-aaa-key-09.txt 9 Status of This Memo 11 This document is a submission by the mobile-ip Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the mobile-ip@sunroof.eng.sun.com mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at: 31 http://www.ietf.org/shadow.html. 33 Abstract 35 AAA servers, such as RADIUS and DIAMETER, are in use within the 36 Internet today to provide authentication and authorization services 37 for dial-up computers. Mobile IP requires strong authentication 38 between the mobile node and its home agent. When the mobile node 39 shares a security association with its home AAA server, however, it 40 is possible to use that security association to create derivative 41 security associations between the mobile node and its home agent, 42 and again between the mobile node and the foreign agent currently 43 offering connectivity to the mobile node. This document specifies 44 extensions to the Mobile IP Registration Reply packet that can be 45 used to create such security information at the mobile node. 47 1. Introduction 49 AAA servers, such as RADIUS [13] and DIAMETER [4], are in use within 50 the Internet today to provide authentication and authorization 51 services for dial-up computers. Such services are likely to be 52 equally valuable for mobile nodes using Mobile IP [12] when the 53 nodes are attempting to connect to foreign domains with AAA servers. 54 Requirements for interactions between AAA and Mobile IP are outlined 55 in RFC 2977 [6]; that document describes an infrastructure which 56 enables AAA servers to authenticate and authorize network access 57 requests from mobile nodes. See also appendix B. The Mobile IP 58 Registration Request is considered to be a request for network 59 access. It is then possible to augment the functionality of 60 the Mobile IP mobility agents so that they can translate between 61 Mobile IP registration messages and the messages used within the 62 AAA infrastructure architected in RFC 2977. Mobility agents and 63 AAA servers that conform to the requirements of RFC 2977 can be 64 considered as appropriate network entities to support the message 65 types specified in this document. Please consult RFC 2977 for 66 further details. 68 Mobile IP requires strong authentication between the mobile node and 69 its home agent. When the mobile node shares a security association 70 with its home AAA server, however, it is possible to use that 71 security association to create derivative security associations 72 between the mobile node and its home agent, and again between the 73 mobile node and the foreign agent currently offering connectivity to 74 the mobile node. This document specifies extensions to the Mobile 75 IP Registration messages that can be used to create those security 76 associations at the mobile node. 78 AAA servers typically use the Network Access Identifier (NAI) [1] 79 to uniquely identify the mobile node; the mobile node's home 80 address is not always necessary to provide that function. Thus, 81 it is possible for a mobile node to authenticate itself, and be 82 authorized for connection to the foreign domain, without having any 83 home address. However, for Mobile IP to work, the mobile node is 84 required to have a security association with its home agent. When 85 the Mobile IP Registration Reply packet is authenticated by the 86 MN-AAA Authentication Extension [3], the mobile node can verify that 87 the keys contained in the extensions were produced by the AAA server, 88 and thus may be reliably used to create security associations with 89 the home agent, or alternatively with the foreign agent. 91 It is also assumed that the AAA entities involved (i.e., the AAAH, 92 AAAL, and the AAA interface features of the foreign agents and home 93 agents) all have means outside of the scope of this document for 94 exchanging keys. The extensions within this document are intended to 95 work with any AAA protocol suite that allows for such key exchange. 97 2. Terminology 99 security association 100 The information shared by two network nodes that 101 enables them to carry out the operations needed for 102 some security protocol that the nodes intend to 103 operate. For the purposes of this document, all 104 security associations will contain the following 105 information: 107 key a number, kept secret. Only nodes in 108 possession of the key have any hope of 109 using the security algorithm to obtain 110 correct results. 111 SPI Security Parameters Index. This number 112 enables selection of one security 113 association in case that several exist 114 between the two nodes operaing a security 115 procedure. 117 Also for the purposes of this document, a mobile 118 node is allowed to have a security association with 119 another node even though it does not necessarily 120 know the IP address of that node. It is only 121 required that the mobile node use the security 122 association for purpose in accordance with the 123 expectations of the other node. 125 security algorithm 126 A set of rules for using input data and a secret key 127 for producing data for use in security protocols. 128 For example, HMAC-MD5 [8] is the security algorithm 129 that all nodes using Mobile IP must implement 130 for the purposes of producing and verifying 131 authentication data. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 134 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 135 in this document are to be interpreted as described in [2]. 136 Other terminology is used as defined in the base Mobile IP 137 specification [12]. 139 Furthermore, in order to simplify the discussion, we have used the 140 word "Extension" instead of "Subtype of the Generalized Extension" 141 in many cases. So, for instance, instead of using the phrase "The 142 Unsolicited MN-FA Key Material From AAA Subtype of the Generalized 143 MN-FA Key Reply Extension", we would instead use the phrase "The 144 Unsolicited MN-FA Key Material From AAA Extension". 146 3. Overview of Operations with Key Extensions 148 When a mobile node depends on an AAA infrastructure to obtain 149 authorization for network connectivity and Mobile IP registration, 150 it may not have any pre-existing security relationships with either 151 its home agent, or the foreign agent controlling the access to the 152 foreign network. The extensions defined in this document allow a AAA 153 agent to supply key material to mobile nodes to be used as the basis 154 of its security association with mobile agents (foreign agents and 155 home agents). The AAA agent that will act on these extensions is 156 part of the AAA infrastructure, and is typically identified within 157 the foreign domain by methods outside the scope of this specification 158 (see appendix B). 160 The key material is requested by the mobile node in new extensions to 161 Mobile IP Registration Request messages, and supplied to the mobile 162 node in extensions to the Mobile IP Registration Reply messages. 163 The method by which key material is supplied to the mobility agents 164 themselves is out of scope for this document, and would depend on the 165 particular details of the security architecture for the AAA servers 166 in the foreign and home domains (see RFC 2977 and appendix B). For 167 the purposes of this document, we assume that there is a suitable AAA 168 infrastructure available to the foreign agents, and that the mobile 169 node does have a security association with at least one AAA server in 170 its home domain. 172 The protocol and messages in this document are intended to facilitate 173 the following operations which may occur between the mobile node, AAA 174 server, home agent, and foreign agent. However, the only message 175 flows specified in this document are the Registration Request between 176 the mobile node and the foreign agent, and Registration Reply between 177 the foreign agent and the mobile node. 179 1. When a mobile node travels away from home, it may not have a 180 security association with its home agent, perhaps because it does 181 not yet have a home address. 183 2. If the mobile node does not have a Mobility Security Association 184 with the foreign agent, it SHOULD include an MN-FA Key Request 185 extension (see Section 10) as part of its Registration Request 186 that it sends to the Foreign Agent. 188 3. Similarly, if the mobile node does not have a Mobility Security 189 Association with the home agent, it MUST add an MN-HA Key Request 190 extension (see Section 11) as part of its Registration Request 191 that it sends to the Foreign Agent. 193 4. If one or more Key Request extensions were added, the mobile 194 node adds the MN-AAA Authentication extension is added to its 195 Registration Request. 197 5. By action of the foreign agent, which is presumed to be also 198 a participant in some AAA protocol, the mobile node's key 199 requests and authentication data are transferred, typically after 200 reformatting to fit into the appropriate AAA messages, which are 201 out of scope for this document. 203 6. At the time the information within the MN-AAA Authentication 204 extension is verified by the AAA server, the AAA server also 205 generates Key Material, if it has been requested by the mobile 206 node. 208 7. The respective AAA keys are distributed to the Home and Foreign 209 Agent via the AAA protocol. 211 8. The mobile node first generates the key using the Key Material 212 provided, according to its security association with the AAA. 213 Using that key, the mobile node authenticates the Reply message. 214 If the Reply passes authentication and contains the Unsolicited 215 MN-HA Key Material From AAA extension (see section 9), the 216 generated key is then used to establish the mobile node's 217 security association with its home agent, and is used to 218 authenticate the MN-HA authentication extension. 220 9. Similarly, if the Reply passes authentication and contains 221 the Unsolicited MN-FA Key Material From AAA extension (see 222 section 8), the mobile node generates the key using the Key 223 Material provided, according to its security association with the 224 AAA. The resulting key is used to establish the mobile node's 225 security association with its new foreign agent, and is used 226 to compute the authentication data used in the Mobile-Foreign 227 authentication extension. 229 Any registration reply containing the Unsolicited MN-HA Key Material 230 From AAA extension MUST also contain a subsequent Mobile Home 231 Authentication Extension, created using the generated MN-HA key. 232 Similarly, a reply containing the Unsolicited MN-FA Key Material 233 From AAA extension MUST also contain a subsequent Mobile Foreign 234 Authentication Extension, created using the the MN-FA key. 236 4. Mobility Security Associations 238 Mobility Security Associations between Mobile IP entities 239 (mobile nodes, home agents, foreign agents) contain both the 240 necessary cryptographic key information, and a way to identify 241 the cryptographic algorithm which uses the key to produce the 242 authentication information typically included in the Mobile Home 243 Authentication extension or the Mobile Foreign Authentication 244 extension. In order for the mobile node to make use of key material 245 created by the AAA server, the mobile node also has to be able to 246 identify and select the appropriate cryptographic algorithm that uses 247 the key to produce the authentication. 249 The algorithm identifiers are tabulated in the list of Authentication 250 Algorithms allowable as values for the "Attribute Type" (5) 251 (i.e., "Authentication Algorithm"), one of the classifications 252 in the tabulated Attribute Types for "IPSEC Security Association 253 Attributes". See http://www.iana.org/assignments/isakmp-registry 254 for the full listing of all Attribute Types and other Attributes for 255 IPSEC Security Associations. 257 Mobility Security Associations shared between mobile nodes and home 258 agents also require a replay protection method. The following table 259 contains the supported replay methods. 261 Replay Method Name Reference 262 -------------- ------------ -------------- 263 1 None RFC 3220 [12] 264 2 Timestamps RFC 3220 [12] 265 3 Nonces RFC 3220 [12] 267 5. Key Material Creation and Derivation 269 This section contains the procedures followed in the creation of the 270 Key Material by AAA servers, and the key derivation procedures used 271 by mobile nodes. Note that the AAA servers will also make use of the 272 derivation procedures to deliver the keys via the AAA protocol. AAA 273 servers that follow these procedures will produce results that can 274 be understood by mobile nodes. Mobility agents (home agent, foreign 275 agent) will faithfully transcribe the results into the appropriate 276 Mobile IP extensions. 278 The example that follows makes use of HMAC-MD5 [7]. All mobile nodes 279 and mobility agents implementing Mobile IP, and implementing the 280 extensions specified in this document, MUST implement HMAC-MD5 [12]. 281 Other cryptographic functions MAY also be used. 283 The following steps are performed on the AAA server: 285 1. The AAA server identifies the mobile node. If the Home Address 286 field of the Registration Request is either zero (0), or all ones 287 (1), then the Mobile Node's NAI is used instead of the mobile 288 node's home address. 290 2. The AAA server generates a random [5] value of at least 64 bits 291 to be used as the Key Material. 293 3. The AAA server provides the random value for later insertion into 294 the Key extension, in the ``Key Material'' field. 296 The following steps are performed on the mobile node: 298 1. The mobile node calculates 300 key = HMAC-MD5 (Key Material | home address) 302 2. The mobile node creates the security association, using the key 303 and the other relevant information in the Key Extension. 305 The secret key used within the HMAC-MD5 computation is the AAA-key 306 pointed to by the AAA SPI, which has been previously configured as 307 the basis for a security assocation between the mobile node and the 308 AAA server creating the key. 310 6. Generalized Key Request/Reply Extensions 312 The extensions in this section are Generalized Extensions, and have 313 subtypes as specified in section 7. 315 6.1. Generalized MN-FA Key Request Extension 317 Figure 1 illustrates the Generalized MN-FA Key Request Extension. 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type | Subtype | Length | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Mobile Node SPI | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | MN-FA Key Request Subtype Data ... 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 1: The Generalized Mobile IP MN-FA Key Request Extension 330 Type TBD (not skippable) (see [12] and section 13) 332 Subtype a number assigned to identify the way in 333 which the Key Request Data is to be used when 334 generating the registration key 336 Length The 16-bit Length field indicates the length of 337 the extension. It is equal to the number of 338 bytes in the MN-FA Key Request Subtype Data plus 339 4 (for the Mobile Node SPI field), and SHOULD be 340 at least 20. 342 Mobile Node SPI The Security Parameters Index that the mobile 343 node will assign for the security association 344 created for use with the registration key. 346 MN-FA Key Request Subtype Data 347 Data needed to carry out the creation of the 348 registration key on behalf of the mobile node. 350 The Generalized MN-FA Key Request Extension defines a set of 351 extensions, identified by subtype, which may be used by a mobile node 352 in a Mobile IP Registration Request message to request that some 353 other entity create a key for use by the mobile node with the mobile 354 node's new foreign agent. 356 6.2. Generalized MN-FA Key Reply Extension 358 The Generalized MN-FA Key Reply extension supplies a registration key 359 requested by using one of the subtypes of the Generalized MN-FA Key 360 Request extension. Figure 2 illustrates the format Generalized MN-FA 361 Key Reply Extension. 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type | Subtype | Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | MN-FA Key Reply Subtype Data ... 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 2: The Generalized Mobile IP MN-FA Key Reply Extension 373 Type TBD (not skippable) (see [12] and section 13) 374 Subtype a number assigned to identify the way in which the 375 MN-FA Key Reply Subtype Data is to be decrypted to 376 obtain the registration key 378 Length The 16-bit Length field is equal to the number of bytes 379 in the MN-FA Key Reply Subtype Data. 381 MN-FA Key Reply Subtype Data 382 An encoded copy of the key to be used between the 383 mobile node and the foreign agent, along with any other 384 information needed by the recipient to create the 385 designated Mobility Security Association. 387 For each subtype, the format of the MN-FA Key Reply Subtype Data has 388 to be separately defined according to the particular method required 389 to set up the security association. 391 In some cases, the MN-FA Key supplied in the data for a subtype of 392 this extension comes by a request which was sent using a subtype of 393 the Generalized MN-FA Key Request Extension. In that case, the SPI 394 to be used when employing the security association defined by the 395 registration key is the same as given in the original request. 397 6.3. Generalized MN-HA Key Request Extension 399 Figure 3 illustrates the Generalized MN-HA Key Request Extension. 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Type | Subtype | Length | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Mobile Node SPI | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | MN-HA Key Request Subtype Data ... 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Figure 3: The Generalized Mobile IP MN-HA Key Request Extension 413 Type TBD (not skippable) (see [12] and section 13) 415 Subtype a number assigned to identify the way in 416 which the Key Request Data is to be used when 417 generating the registration key 419 Length The 16-bit Length field indicates the length of 420 the extension. It is equal to the number of 421 bytes in the MN-HA Key Request Subtype Data plus 422 4 (for the Mobile Node SPI field), and SHOULD be 423 at least 20. 425 Mobile Node SPI The Security Parameters Index that the mobile 426 node will assign for the security association 427 created for use with the registration key. 429 MN-HA Key Request Subtype Data 430 Data needed to carry out the creation of the 431 registration key on behalf of the mobile node. 433 The Generalized MN-HA Key Request Extension defines a set of 434 extensions, identified by subtype, which may be used by a mobile node 435 in a Mobile IP Registration Request message to request that some 436 other entity create a key for use by the mobile node with the mobile 437 node's new home agent. 439 6.4. Generalized MN-HA Key Reply Extension 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Type | Subtype | Length | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Lifetime | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | MN-HA Key Reply Subtype Data ... 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Figure 4: The Generalized Mobile IP MN-HA Key Reply Extension 453 Type TBD (not skippable) (see [12] and section 13) 455 Subtype a number assigned to identify the way in which the 456 MN-HA Key Reply Subtype Data is to be decrypted to 457 obtain the registration key 459 Length The 16-bit Length field indicates the length of the 460 extension. It is equal to the number of bytes in the 461 MN-HA Key Reply Subtype Data plus 4 (for the Lifetime 462 field). 464 Lifetime This field indicates the duration of time (in seconds) 465 for which the MN-HA key is valid. 467 MN-HA Key Reply Subtype Data 468 An encrypted copy of the key to be used between the 469 mobile node and its home agent, along with any other 470 information needed by the mobile node to create the 471 designated Mobility Security Association with the home 472 agent. 474 For each subtype, the format of the MN-HA Key Reply Subtype Data has 475 to be separately defined according to the particular method required 476 to set up the security association. 478 7. Key Request/Reply Subtypes 480 The extension subtypes in this section are subtypes of the 481 Generalized Extensions specified in section 6. 483 8. Unsolicited MN-FA Key Material From AAA Subtype 485 The Unsolicited MN-FA Key Material From AAA extension, shown in 486 figure 5, uses subtype 7 of the Generalized MN-FA Key Reply Extension 487 (see section 6.2). 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Lifetime | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | AAA SPI | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | FA SPI | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Algorithm Identifier | Key Material ... 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Figure 5: The Unsolicited MN-FA Key Material From AAA 502 Subtype-Specific Data 504 lifetime This field indicates the duration of time (in seconds) 505 for which the MN-FA key is valid. 507 AAA SPI A 32-bit opaque value, indicating the SPI that the 508 mobile node must use to determine the algorithm to use 509 for establishing the FA security information. 511 FA SPI The SPI for the Security Association to the FA that the 512 MN creates as a result of processing this extension 514 Algorithm Identifier 515 This field indicates the algorithm to be used (selected 516 from among the values in the "Authentication Algorithm" 517 table cited in section 4). for future computations of 518 the Mobile-Foreign Authentication Extension. 520 Key Material 521 A random [5] value of at least 64 bits. 523 The Key Material is added by the AAA server for use by the mobile 524 node in creating the MN-FA key, which is used to secure future Mobile 525 IP registrations with the same foreign agent. The Unsolicited MN-FA 526 Key Material From AAA extension MUST appear in the Registration Reply 527 before the Mobile-Foreign Authentication extension. 529 Once the mobile node creates the FA Security Information, by using 530 the algorithm indexed by the AAA SPI, it stores the FA Security 531 Information indexed by the FA SPI in its list of Mobile Security 532 Associations. 534 If the foreign agent receives a Registration Reply that has no 535 Unsolicited MN-FA Key Material From AAA extension, and thus cannot 536 establish a Mobility Security Association with the mobile node, the 537 foreign agent MAY change the Code value of the Registration Reply to 538 MISSING_MN_FA (see section 12), effectively causing the registration 539 to fail. 541 9. Unsolicited MN-HA Key Material From AAA Subtype 543 The Unsolicited MN-HA Key Material From AAA is subtype 1 of the 544 Generalized MN-HA Key Reply Extension (see section 6.4). 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | AAA SPI | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | HA SPI | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Algorithm Identifier | Replay Method | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Key Material ... 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Figure 6: The Unsolicited MN-HA Key Material From AAA 559 Subtype-Specific Data 561 AAA SPI A 32-bit opaque value, indicating the SPI that the 562 mobile node must use to determine the algorithm to use 563 for establishing the HA security information. 565 HA SPI The SPI for the Security Association to the HA that the 566 MN creates as a result of processing this extension 568 Algorithm Identifier 569 This field indicates the algorithm to be used for 570 future computations of the MN-HA Authentication 571 Extension (see section 4) 573 Replay Method 574 This field contains the replay method to be used for 575 future Registration messages (see section 4). 577 Key Material 578 A random [5] value of at least 64 bits. 580 The Unsolicited MN-HA Material Key From AAA subtype-specific data is 581 shown in figure 6. The Mobile Node creates the MN-HA key using the 582 Key Material that has previously been configured for securing all 583 such communication requirements with the AAA server which will be 584 contacted within the AAA infrastructure (see appendix B). The key 585 is intended for use by the mobile node to secure future Mobile IP 586 registrations with its home agent. The MN-HA Key Reply MUST appear 587 in the Registration Reply before the MN-HA Authentication extension. 589 Once the mobile node creates the MN-HA Key, by using the algorithm 590 specified in the AAA SPI, it stores the HA Security Information 591 indexed by the HA SPI in its list of Mobile Security Associations. 593 The mobile node uses the Identification field data from the 594 Registration Request as its initial synchronization data with the 595 home agent. 597 10. MN-FA Key Request From AAA Subtype 599 The MN-FA Key Request From AAA subtype data uses subtype 7 of the 600 Generalized MN-FA Key Request Extension (see section 6.1). The 601 MN-FA Key Request From AAA extension MUST appear in the Registration 602 Request before the MN-AAA Authentication extension. The subtype data 603 field is zero in length. 605 11. MN-HA Key Request From AAA Subtype 607 The MN-HA Key Request From AAA subtype data uses subtype 7 of the 608 Generalized MN-HA Key Request Extension (see section 6.3). The 609 MN-HA Key Request From AAA extension MUST appear in the Registration 610 Request before the MN-AAA Authentication extension. The subtype data 611 field is zero in length. 613 12. Error Values 615 Each entry in the following table contains the name of Code [12] to 616 be returned in a Registration Reply, the value for the Code, and the 617 section in which the error is first mentioned in this specification. 619 Error Name Value Section 620 ---------------------- ----- --------- 621 MISSING_MN_FA 107 8 623 13. IANA Considerations 625 The numbers for the Generalized Extensions in section 6 are 626 taken from the numbering space defined for Mobile IP registration 627 extensions defined in RFC 3220 [12] as extended in RFC 2356 [10]. 628 The numbers suggested in this section are already in use by 629 implementations which have been tested for interoperability. 631 The number 7, assigned to the Unsolicited MN-HA Key Material From AAA 632 Subtype extension, was taken from the numbering space defined for the 633 Generalized MN-HA Key Reply Extension (see section 6.4). 635 The number 7, assigned to the MN-FA Key Request From AAA Subtype 636 extension, was taken from the numbering space defined for the 637 Generalized MN-FA Key Request Extension (see section 6.1). 639 The number 1, assigned to the Unsolicited MN-FA Key Material From AAA 640 Subtype extension, was taken from the numbering space defined for the 641 Generalized MN-FA Key Reply Extension (see section 6.2). 643 The number 7, assigned to the MN-HA Key Request From AAA Subtype 644 extension, was taken from the numbering space defined for the 645 Generalized MN-HA Key Request Extension (see section 6.3). 647 The Code values specified for errors, listed in section 12, MUST NOT 648 conflict with any other code values listed in RFC 3220, RFC 3024 [9], 649 or RFC 2356 [10]. They are to be taken from the space of error 650 values conventionally associated with rejection by the foreign agent 651 (i.e., 64-127). 653 Section 4 introduces the Algorithm Identifier namespace that requires 654 IANA management. This specification makes use of 1-3; all other 655 values other than zero (0) are available for assignment, pending 656 review and approval by a Designated Expert [11]. 658 Section 4 introduces the Replay Method Identifier namespace that 659 requires IANA management. This specification makes use of 1-3; 660 all other values other than zero (0) are available for assignment, 661 pending review and approval by a Designated Expert [11]. 663 14. Security Considerations 665 The extensions in this document are intended to provide the 666 appropriate level of security for Mobile IP entities (mobile node, 667 foreign agent, and home agent) to operate Mobile IP registration 668 protocol. The security associations resulting from use of these 669 extensions do not offer any higher level of security than what is 670 already implicit in use of the security association between the 671 mobile node and the AAA. 673 Since the extensions defined in this specification only carries Key 674 Material, which is used to derive keys, it does not expose any data 675 that could be used in an attack aimed at recovering the key shared 676 between the mobile node and the AAA. The authors do not believe this 677 specification introduces new security risks. 679 15. Acknowledgements 681 Thanks to Fredrik Johansson and the members of the IESG for their 682 useful comments on this document. 684 References 686 [1] B. Aboba and M. Beadles. The Network Access Identifier. 687 Request for Comments (Proposed Standard) 2486, Internet 688 Engineering Task Force, January 1999. 690 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 691 Levels. Request for Comments (Best Current Practice) 2119, 692 Internet Engineering Task Force, March 1997. 694 [3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 695 Challenge/Response Extension. Request for Comments (Proposed 696 Standard) 3012, Internet Engineering Task Force, December 2000. 698 [4] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER 699 Base Protocol (work in progress). Internet Draft, Internet 700 Engineering Task Force. draft-ietf-aaa-diameter-07.txt, July 701 2001. 703 [5] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness 704 Recommendations for Security. Request for Comments 705 (Informational) 1750, Internet Engineering Task Force, December 706 1994. 708 [6] S. Glass, T. Hiller, S. Jacobs, and C. Perkins. Mobile IP 709 Authentication, Authorization, and Accounting Requirements. 710 Request for Comments (Proposed Standard) 2977, Internet 711 Engineering Task Force, October 2000. 713 [7] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 714 for Message Authentication. Request for Comments 715 (Informational) 2104, Internet Engineering Task Force, 716 February 1997. 718 [8] D. Kristol and L. Montulli. HTTP State Management Mechanism. 719 Request for Comments (Proposed Standard) 2109, Internet 720 Engineering Task Force, February 1997. 722 [9] Editor G. Montenegro. Reverse Tunneling for Mobile IP, revised. 723 Request for Comments (Proposed Standard) 3024, Internet 724 Engineering Task Force, January 2001. 726 [10] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for 727 Mobile IP. Request for Comments (Informational) 2356, Internet 728 Engineering Task Force, June 1998. 730 [11] T. Narten and H. Alvestrand. Guidelines for Writing an IANA 731 Considerations Section in RFCs. Request for Comments (Best 732 Current Practice) 2434, Internet Engineering Task Force, October 733 1998. 735 [12] C. Perkins. IP Mobility Support. Request for Comments 736 (Proposed Standard) 3220, Internet Engineering Task Force, 737 December 2001. 739 [13] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote 740 Authentication Dial In User Service (RADIUS). Request for 741 Comments (Proposed Standard) 2865, Internet Engineering Task 742 Force, June 2000. 744 A. Changes Since Previous Revision 746 In this revision of the document, there have been several major 747 changes as a result of suggestions received during Last Call. 749 - Generalized Key Extensions previously specified in another 750 document have been instead specified in this document in order 751 that this document can be self-contained and not dependent on the 752 standardization status of the other document. 754 - Additional explanation has been included for the purposes of 755 clarifying the problem space and solution approach. 757 - An appendix has been added to describe the expected AAA 758 infrastructure that will produce the keys that are to be 759 distributed within the extensions specified in this document. 761 - Ladder diagrams have been included to illustrate the expected 762 message flows containing the extensions defined in this document. 764 - HMAC-MD5 has been mandated for implementation by the mobile node, 765 for compatibility with RFC 3220 [12]. The example text has been 766 modified accordingly (see section 5). 768 - A table of Algorithm Identifiers has been identified as the 769 numbering space for algorithm selection when establishing 770 the security association using the keys distributed with the 771 extensions in this document. See section 4. 773 - A terminology section has been added. 775 - This appendix has been added. 777 B. AAA Infrastructure 779 In this appendix, we attempt to capture the main features of a basic 780 model for operation of AAA servers that is assumed for understanding 781 of the use of the Mobile IP registration extensions described in this 782 document. This information has been adapted from the discussion in 783 RFC 2977 [6]. 785 Within the Internet, a mobile node belonging to one administrative 786 domain (called the home domain) often needs to use resources provided 787 by another administrative domain (called the foreign domain). 788 An foreign agent that handles the mobile node's Registration 789 Request is likely to require that the mobile node provide some 790 credentials that can be authenticated before access to the resources 791 is permitted. These credentials may be provided as part of the 792 Mobile-AAA Authentication extension [3], relying on the existence 793 of an AAA infrastructure such as is described in this section, and 794 also described in RFC 2977 and RFC 3012 [3]. Such credentials are 795 typically managed by entities within the mobile node's home domain. 796 They may be also used for setting up secure communications with the 797 mobile node. 799 Local Domain Home Domain 800 +--------------+ +----------------------+ 801 | +------+ | | +------+ | 802 | | | | | | | | 803 | | AAAL | | | | AAAH | | 804 | | +-------------------+ | | 805 | +---+--+ | | +------+ | 806 | | | | | 807 | | | +----------------------+ 808 +------+ | +---+--+ | 809 | | | | | | MN = mobile node 810 | MN |- -|- -| FA | | FA = foreign agent 811 | | | | | | AAAL = local authority 812 +------+ | +------+ | AAAH = home authority 813 | | 814 +--------------+ 816 Figure 7: AAA Servers in Home and Local Domains 818 The foreign agent often does not have direct access to the data 819 needed to verify the credentials. Instead, the foreign agent is 820 expected to consult an authority (typically in the same foreign 821 domain) in order to request proof that the mobile node has acceptable 822 credentials. Since the foreign agent and the local authority (AAAL) 823 are part of the same administrative domain, they are expected to have 824 established, or be able to establish for the necessary lifetime, a 825 secure channel for the purposes of exchanging sensitive (access) 826 information, and keeping it private from (at least) the visiting 827 mobile node. 829 The local authority (AAAL) itself may not have enough information 830 stored locally to carry out the verification for the credentials 831 of the mobile node. In contrast to the foreign agent, however, 832 the AAAL is expected to be configured with enough information to 833 negotiate the verification of mobile node credentials with its home 834 domain. The home and foreign domains should be configured with 835 sufficient security relationships and access controls so that they 836 can negotiate the authorization, and also enable the mobile node to 837 acquire security associations with the foreign domain. requested 838 resources. For the purposes of the key exchanges specified within 839 this document, the authorization is expected to depend only upon 840 secure authentication of the mobile node's credentials. 842 Once the authorization has been obtained by the local authority, and 843 the authority has notified the foreign agent about the successful 844 negotiation, the foreign agent can deliver the Registration Reply to 845 the mobile node along with the desired key material. 847 In figure 7, there might be many mobile nodes from many different 848 Home Domains. Each Home Domain provides a AAAH that can check 849 credentials originating from mobile nodes administered by that Home 850 Domain. There is a security model implicit in figure 7, and it is 851 crucial to identify the specific security associations assumed in 852 the security model. These security associations are illustrated in 853 figure 8, and are considered to be relatively long-lived security 854 associations. 856 First, it is natural to assume that the mobile node has a security 857 association with the AAAH, since that is roughly what it means for 858 the mobile node to belong to the home domain. 860 Second, from the model illustrated in figure 7 it is clear that AAAL 861 and AAAH have to share a security association, because otherwise 862 they could not rely on the authentication results, authorizations, 863 nor even the accounting data which might be transacted between them. 864 Requiring such bilateral security relationships is, however, in the 865 end not scalable; the AAA framework MUST provide for more scalable 866 mechanisms, but the methods by which such a broker model is to be 867 created are out of scope for this document. See RFC 2977 for more 868 details. 870 Finally, from figure 7, it is clear that the foreign agent can 871 naturally share a security association with the AAAL. This is 872 necessary in order for the model to work because the foreign agent 873 has to have a way to find out that it is permissible to allocate 874 the local resources to the mobile node, and further to transmit any 875 successful Registration Reply to the mobile node. 877 Figure 8 illustrates the natural security associations we understand 878 from our proposed model. Note that there may be, by mutual agreement 879 between AAAL and AAAH, a third party inserted between AAAL and 880 AAAH to help them arbitrate secure transactions in a more scalable 881 fashion. The broker model which has been designed to enable such 882 third-party processing should not have any effect on the Mobile IP 883 extensions specified in this document, and so no description is 884 provided here; see RFC 2977 [6] for more details. 886 +------+ +------+ 887 | | | | 888 | AAAL +--------------+ AAAH | 889 | | | | 890 +---+--+ +--+---+ 891 | | 892 | | 893 +---+--+ +--+---+ 894 MN = mobile node | | | | 895 FA = foreign agent | FA | | MN | 896 AAAL = local authority | | | | 897 AAAH = home authority +------+ +------+ 899 Figure 8: Security Associations 901 Nodes in two separate administrative domains (for instance, AAAH 902 and AAAL) often must take additional steps to verify the identity 903 of their communication partners, or alternatively to guarantee 904 the privacy of the data making up the communication. While these 905 considerations lead to important security requirements, as mentioned 906 above in the context of security between servers, we consider the 907 exact choice of security associations between the AAA servers to 908 be beyond the scope of this document. The choices are unlikely 909 to depend upon Mobile IP, or any specific features of the general 910 model illustrated in figure 7. On the other hand, the security 911 associations needed between Mobile IP entities are of central 912 importance in the design of the key exchange extensions in this 913 document. 915 One further detail deserves mention. The key associations to be 916 established between the mobile node and the foreign agent have 917 to be communicated to the foreign agent as well as to the mobile 918 node. The way that the key is distributed to the foreign agent 919 is not relevant to any material in this document, and is expected 920 to be handled as part of the AAA protocol processing between the 921 AAAH and AAAL, and the further AAA protocol processing between the 922 AAAL and the foreign agent. Any method by which the key can be 923 securely transmitted to the AAAL and then relayed (possibly with 924 re-encryption) to the foreign agent, is expected to be outside the 925 jurisdiction of any Mobile IP specification, and thus compatible ( by 926 reason of non-interference) with the protocol extensions specified in 927 this document. 929 C. Message Flow for Requesting and Receiving Registration Keys 931 In this section, we show message flows for requesting and receiving 932 a reqistration key from the AAA infrastructure, described in 933 section B. Challenge values, as specified in [3], might be added to 934 the Advertisement and Registration messages for additional replay 935 protection, but are not illustrated here. 937 Diagram 9 illustrates the message flow for the case when the mobile 938 node explicitly requests a registration key. 940 MN FA AAA Infrastructure 941 | | | 942 |<--- Advertisement-----| | 943 | (if needed) | | 944 | | | 945 |-- RReq+AAA Key Req.-->| | 946 | |--- RReq + AAA Key Req.--->| 947 | | | 948 | |<--- RRep + AAA Key Rep.---| 949 |<-- RRep+AAA Key Rep.--| | 950 | | | 952 Figure 9: Message Flows for Requesting and 953 Receiving Registration Keys 955 In diagram 9, the following message flow is illustrated: 957 1. The foreign agent disseminates an Agent Advertisement. This 958 advertisement MAY have been produced after receiving an Agent 959 Solicitation from the mobile node (not shown in the diagram). 961 2. The mobile node creates a Registration Request including the 962 MN-HA Key Request and/ore MN-FA Key Request, as needed, along 963 with an authorization-enabling authentication extension as 964 required by Mobile IP [12]. 966 3. The foreign agent relays the Registration Request either to its 967 locally configured AAA Infrastructure (see appendix B), according 968 to local policy. 970 4. The foreign agent receives a Registration Reply with the 971 appropriate indications for authorizing connectvity for the 972 mobile node, which also includes the necessary AAA Key Reply 973 extensions. Along with this Registration Reply, the foreign 974 agent may also receive key material by some other secure method 975 appropriate for communications between it and its local AAA 976 infrastructure. 978 5. The foreign agent relays the Registration Reply to the mobile 979 node, along with the new Key Reply extensions to be used by the 980 mobile node to establish security associations with the relevant 981 mobility agents (foreign agent and/or home agent). 983 Diagram 10 illustrates the message flow for the case when the 984 mobile node receives an unsolicited registration key from the AAA 985 Infrastructure. 987 MN FA AAA Infrastructure 988 | | | 989 |<--- Advertisement-----| | 990 | (if needed) | | 991 | | | 992 | ------ RReq --------->| | 993 | |------- RReq ------------->| 994 | | | 995 | |<--- RRep + AAA Key Rep.---| 996 |<-- RRep+AAA Key Rep.--| | 997 | | | 999 Figure 10: Message Flow for Receiving 1000 Unsolicited Registration Keys 1002 In diagram 10, the following message flow is illustrated: 1004 1. The foreign agent disseminates an Agent Advertisement. This 1005 advertisement MAY have been produced after receiving an Agent 1006 Solicitation from the mobile node (not shown in the diagram). 1008 2. The mobile node creates a Registration Request including an 1009 authorization-enabling authentication extension as required by 1010 Mobile IP [12]. 1012 3. The foreign agent relays the Registration Request either to its 1013 locally configured AAA Infrastructure (see appendix B), according 1014 to local policy. 1016 4. The foreign agent receives a Registration Reply with the 1017 appropriate indications for authorizing connectvity for the 1018 mobile node, which also includes the necessary AAA Key Reply 1019 extensions. Along with this Registration Reply, the foreign 1020 agent may also receive key material by some other secure method 1021 appropriate for communications between it and its local AAA 1022 infrastructure. 1024 5. The foreign agent relays the Registration Reply to the mobile 1025 node, along with the new Key Reply extensions to be used by the 1026 mobile node to establish security associations with the relevant 1027 mobility agents (foreign agent and/or home agent). 1029 Addresses 1031 The working group can be contacted via the current chairs: 1033 Basavaraj Patil Phil Roberts 1034 Nokia Megisto Corp. 1035 6000 Connection Dr. Suite 120 1036 20251 Century Blvd 1037 Irving, TX. 75039 Germantown MD 20874 1038 USA USA 1039 Phone: +1 972-894-6709 Phone: +1 847-202-9314 1040 Email: Basavaraj.Patil@nokia.com Email: PRoberts@MEGISTO.com 1042 Questions about this memo can also be directed to the authors: 1044 Charles E. Perkins Pat R. Calhoun 1045 Communications Systems Lab 1046 Nokia Research Center Black Storm Networks 1047 313 Fairchild Drive 250 Cambridge Avenue, Suite 200 1048 Mountain View, California 94043 Palo Alto, California, 94306 1049 USA USA 1050 Phone: +1-650 625-2986 Phone: +1 650-617-2932 1051 EMail: charliep@iprg.nokia.com Email: pcalhoun@diameter.org 1052 Fax: +1 650 625-2502 Fax: +1 650-786-6445