idnits 2.17.1 draft-calhoun-diameter-mobileip-04.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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 29 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) == Unused Reference: '2' is defined on line 908, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 928, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-11 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-05 -- Possible downref: Normative reference to a draft: ref. '2' -- No information found for draft-ietf-mobileip- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 2002 (ref. '4') (Obsoleted by RFC 3220) == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-challenge-06 ** Obsolete normative reference: RFC 2486 (ref. '6') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '7') == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mn-nai-05 -- No information found for draft-calhoun-diameter-strong-security - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 2406 (ref. '10') (Obsoleted by RFC 4303, RFC 4305) == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-accounting-02 -- Possible downref: Normative reference to a draft: ref. '12' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '13') -- Duplicate reference: RFC2002, mentioned in '14', was also mentioned in '4'. ** Obsolete normative reference: RFC 2002 (ref. '14') (Obsoleted by RFC 3220) -- No information found for draft-calhoun-mobileip-aaa-keys - is the name correct? -- Possible downref: Normative reference to a draft: ref. '15' -- No information found for draft-hiller-cdma2000-AAA - is the name correct? -- Possible downref: Normative reference to a draft: ref. '16' Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Pat R. Calhoun 2 Category: Standards Track Sun Laboratories, Inc. 3 Title: draft-calhoun-diameter-mobileip-04.txt Charles E. Perkins 4 Date: December 1999 Nokia Research Center 6 DIAMETER Mobile IP Extensions 8 Status of this Memo 10 This document is an individual contribution for consideration by the 11 AAA Working Group of the Internet Engineering Task Force. Comments 12 should be submitted to the diameter@ipass.com mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 33 http://www.ietf.org/shadow.html. 35 Copyright (C) The Internet Society 1999. All Rights Reserved. 37 Abstract 39 This document specifies an extension to the DIAMETER base protocol 40 that allows a DIAMETER server to authenticate, authorize and collect 41 accounting information for services rendered to a mobile node. 42 Combined with the Inter-Domain capability of the base protocol, this 43 extension allows mobile nodes to receive service from foreign service 44 providers. The DIAMETER Accounting extension will be used by the 45 Foreign and Home agents to transfer usage information to the DIAMETER 46 servers. 48 Table of Contents 50 1.0 Introduction 51 1.1 Requirements language 52 1.2 Inter-Domain Mobile IP 53 1.3 Key Distribution Center 54 1.4 Allocation of Home Agent in Foreign Network 55 1.5 DIAMETER Session Termination 56 2.0 Command-Code AVP Values 57 2.1 AA-Mobile-Node-Request (AMR) Command 58 2.2 AA-Mobile-Node-Answer (AMA) Command 59 2.3 Home-Agent-MIP-Request (HAR) Command 60 2.4 Home-Agent-MIP-Answer (HAA) Command 61 2.5 Mobile-Node-Terminate-Ind (MTI) Command 62 3.0 Result-Code AVP Values 63 4.0 DIAMETER AVPs 64 4.1 MIP-Registration-Request AVP 65 4.2 MIP-Registration-Reply AVP 66 4.3 MN-FA-Challenge-Length AVP 67 4.4 MN-FA-Response AVP 68 4.5 Mobile-Node-Address AVP 69 4.6 Home-Agent-Address AVP 70 4.7 Previous-FA-NAI AVP 71 4.8 Foreign-Home-Agent-Available AVP 72 4.9 MN-AAA-SPI AVP 73 5.0 Key Distribution Center (KDC) AVPs 74 5.1 Mobile Node Session Key AVPs 75 5.2 Mobility Agent Session Key AVPs 76 5.3 FA-MN-Preferred-SPI AVP 77 5.4 FA-MN-Preferred-SPI AVP 78 6.0 Acknowledgements 79 7.0 IANA Considerations 80 8.0 Security Considerations 81 9.0 References 82 10.0 Authors' Addresses 83 11.0 Full Copyright Statement 85 1.0 Introduction 87 The Mobile IP [4] protocol defines a method that allows a Mobile Node 88 to change its point of attachment to the Internet without service 89 disruption. The Mobile IP protocol, as defined in [4], assumes that 90 mobility is performed in a single administrative domain, and 91 therefore does not specify how usage can be accounted for, which 92 limits the applicability of Mobile IP in a commercial deployment. 93 Further, the protocol requires that a mobile node has a static home 94 agent, and home address, which is not desirable in a commercial 95 network. 97 This document specifies an extension to the DIAMETER base protocol 98 [1] that allows a DIAMETER server to authenticate, authorize and 99 collect accounting information for services rendered to a mobile 100 node. Combined with the Inter-Domain capability of the base protocol, 101 this extension allows mobile nodes to receive service from foreign 102 service providers. The DIAMETER Accounting extension [12] will be 103 used by the Foreign and Home agents to transfer usage information to 104 the DIAMETER servers. 106 The Mobile IP protocol [4] specifies a security model that requires 107 that mobile nodes and home agents share a pre-existing security 108 association, which leads to scaling and configuration issues. This 109 specification defines an optional DIAMETER function that allows the 110 mobile's home AAA server to act as a Key Distribution Center (KDC), 111 where dynamic session keys are created and distributed to the 112 mobility entities for the purposes of securing Mobile IP Registration 113 messages. 115 As with the DIAMETER base protocol, the Mobile IP extension requires 116 the presence of users' identities in a format consistent with the 117 Network Access Identifier (NAI) specification [6], which is used for 118 DIAMETER message routing purposes. This requires mobile nodes to 119 include their identity in Registration messages, as defined in [8]. 120 The use of the NAI is consistent with the current roaming model, as 121 defined by the ROAMOPS Working Group [7]. 123 This specification defines the DIAMETER Mobile-IP Extension, and 124 addresses all of the requirements specified in [3, 16]. This section 125 will provides some examples and message flows of the Mobile IP and 126 DIAMETER messages that occur when a Mobile Node requests service in a 127 foreign network. 129 The Extension number for this draft is four (4). DIAMETER nodes 130 conforming to this specification MUST include an Extension-Id AVP 131 with a value of four in the Device-Reboot-Ind Command [1]. 133 1.1 Requirements language 135 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 136 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 137 described in [11]. 139 1.2 Inter-Domain Mobile IP 141 When a Mobile Node node requests service by issuing a Registration 142 Request to the foreign agent (FA), the FA creates the AA-Mobile- 143 Node-Request (AMR) message, which includes the AVPs defined in 144 section 2.1. The Home Address, Home Agent, Mobile Node NAI and other 145 important fields are extracted from the registration messages and 146 included as DIAMETER AVPs. The request is then forwarded to the FA's 147 local DIAMETER server, known as the AAA-Foreign, or AAAF. 149 ISP Home Network 150 +--------+ +--------+ 151 |abc.com | AMR/A |xyz.com | 152 | AAAF |<--------------->| AAAH | 153 | server | server-server | server | 154 +--------+ communication +--------+ 155 / /|\ /|\ 156 /AMR/A | client-server | HAR/A 157 / | communication | 158 |/_ \|/ \|/ 159 +---------+ +---------+ +---------+ 160 | Foreign | | Foreign | | Home | 161 | Agent | | Agent | | Agent | 162 +---------+ +---------+ +---------+ 163 /|\ 164 | Mobile IP 165 | 166 \|/ 167 +--------+ 168 | Mobile | 169 | Node | mn@xyz.com 170 +--------+ 172 Figure 1: Inter-Domain Mobility 174 Upon receiving the AMR, the AAAF follows the procedures outlined in 175 [1] to determine whether the AMR should be processed locally, or if 176 it should be forwarded to another DIAMETER Server, known as the AAA- 177 Home, or AAAH. Figure 1 describes an example of a mobile node 178 (mn@xyz.com) requests service from a foreign provider (abc.com). The 179 request received by the AAAF is forwarded to abc.com's AAAH server. 181 Figure 2 provides an example of the message flows involved when the 182 Foreign Agent invokes the AAA infrastructure to request that a mobile 183 node be authenticated and authorized. Note that it is not required 184 that the Foreign Agent invoke the AAA every time a Registration 185 Request is received by the mobile, but rather when the prior 186 authorization from the AAAH expires. The expiration of the 187 authorization (and session keys, if used) is communicated through the 188 Session-Time AVP in the response from the AAAH. 190 Mobile Node Foreign Agent AAAF AAAH Home Agent 191 ----------- ------------- ------------ ---------- ---------- 192 Advertisement + 193 <---Challenge 194 Reg-Req(MN-AAA)-> 195 AMR-------------> 196 AMR------------> 197 HAR-----------> 198 <----------HAA 199 <-----------AMA 200 <------------AMA 201 <-------Reg-Reply 203 Figure 2: Mobile IP/DIAMETER Message Exchange 205 The foreign agent depicted in figure 2 provides a challenge, which 206 allows it to have direct control over the replay protection in the 207 Mobile IP registration process, as described in [5]. The Challenge 208 and MN-AAA authentication extension is used by the AAAH to 209 authenticate the Mobile Node. If the value of the MN-AAA is invalid, 210 the AAAH returns the AA-Mobile-Node-Answer (AMA, see section 2.2) 211 with the Result-Code AVP set to an appropriate value. 213 If the Mobile Node was successfully authenticated, the AAAH checks 214 whether the Home-Agent-Address AVP specified a Home Agent. If one was 215 specified, the AAAH must validate the address to ensure that it is a 216 known Home Agent, and one that the Mobile Node is allowed to request. 217 If no Home Agent was specified the AAAH SHOULD allocate one on behalf 218 of the Mobile Node. This can be done in a variety of ways, including 219 using a load balancing algorithm in order to keep the load on all 220 Home Agents equal. The actual algorithm used and the method of 221 discovering the Home Agents is outside of this specification. 223 If the AMR's Mobile-Node-Address AVP did not specify an address, the 224 AAAH has the option of assigning an address for the Mobile Node, or 225 it can leave this up to the Home Agent. This is a local policy 226 decision. 228 The AAAH then sends a Home-Agent-MIP-Request (HAR), which contains 229 the Mobile IP Registration Request encapsulated in the MIP- 230 Registration-Request AVP, to the assigned or requested Home Agent. If 231 the Mobile-Node-Address AVP contains a NULL address (0.0.0.0), it is 232 a request on behalf of the Mobile Node that a home address be 233 assigned. The AAAH MAY manage the allocation of a home address for 234 the mobile node, or leave the NULL address if it requires that the 235 Home Agent perform the address assignment. 237 Upon receipt of the HAR, the Home Agent processes the DIAMETER 238 message as well as the Mobile IP Registration Request. If the 239 DIAMETER message is invalid, a HAR is returned with the Result-Code 240 AVP set to an appropriate value (see section 3.0). If the HAR is 241 valid, the Home Agent processes the registration message and creates 242 the Registration Reply, encapsulated within the MIP-Registration- 243 Reply AVP. If a home address was requested, the Home Agent MUST 244 assign one and include the address in both the Registration Reply and 245 within the DIAMETER Mobile-Node-Address AVP. The DIAMETER response is 246 then forwarded to the AAAH. 248 Upon receipt of the HAA, the AAAH sets the Command-Code AVP to AA- 249 Mobile-Node-Answer (AMA) to the AAAF. The AAAF is responsible for 250 ensuring that the message is properly forwarded to the correct 251 foreign agent. 253 1.3 Key Distribution Center 255 If the AAAH is configured to act as a Key Distribution Center (KDC), 256 the AAAH MUST create three short-lived keys when a Mobile Node is 257 successfully authenticated and authorized. The three keys are used by 258 the mobility entities to compute the three authentication extensions 259 defined in [4]; Mobile-Foreign, Foreign-Home and Mobile-Home. 261 The keys destined for each mobility entity are encrypted either using 262 the secret shared with the entity [1], or via its public key [9]. The 263 keys are encrypted using the security association shared with the 264 entity in question. If the AAAH does not communicate directly with 265 the Foreign Agent, the FA's keys are encrypted using the security 266 association shared with the AAAF. The Session-Timeout AVP contains 267 the number of seconds before the session keys expire. A value of zero 268 indicates infinity (no timeout). 270 KDC support requires a departure from the existing SPI usage, as 271 described in [4]. The AAAH generates SPI values for the Mobility 272 Agents as opposed to a receiver choosing its own SPI value. The SPI 273 values are used as key identifiers, meaning that each short-lived 274 session key has its own SPI value and since two nodes share a session 275 key they share an SPI as well. 277 Suppose a Mobile Node and a Foreign Agent share a key that was 278 created by the AAAH. The AAAH also generated a corresponding SPI 279 value of 37,496. All Mobile-Foreign Authentication extensions must be 280 computed by either entity using the shared session key and MUST 281 include the SPI value of 37,496. 283 The AAAH MUST include all of the session keys in the HAR message sent 284 to the Home Agent. If the HAR and the Registration Request are 285 successfully processed, the Home Agent MUST include the Mobile Node's 286 session keys in the Registration Reply [15], and the Foreign Agent's 287 session keys in the HAA message (see section 2.4). The Registration 288 Reply MUST include the Mobile-Home authentication extension using the 289 session key distributed for that purpose by the AAAH. Similarly, the 290 Reply SHOULD include the Foreign-Home authentication extension using 291 the appropriate session key distributed by the AAAH. 293 Upon receipt of the successful AA-Mobile-Node-Answer (AMA) the AAAF 294 decrypts the FA-to-MN-Key and the FA-to-HA-Key AVPs. The AMA is 295 transmitted to the Foreign Agent. 297 Upon receipt of the AMA, the Foreign Agent decrypts its session keys 298 found in the FA-to-MN-Key and FA-to-HA-Key, and validates the 299 Foreign-Home authentication extension using the session key. The 300 Foreign Agent MUST also include a Mobile-Foreign authentication 301 extension using the newly distributed session key it shares with the 302 Mobile Node. 304 Once the session keys have been distributed to the three mobility 305 entities, subsequent registrations do not need to invoke the AAA 306 infrastructure unless the keys expire. These registrations MUST 307 include the MN-FA, FA-HA and MN-HA authentication extensions. Figure 308 3 provides an example of subsequent Mobile IP message exchange. 310 Mobile Node Foreign Agent Home Agent 311 ----------- ------------- ---------- 313 Reg-Req(MN-FA-Auth, MN-HA-Auth)--------> 315 Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> 317 <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) 319 <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) 321 Figure 3: Mobile IP Message Exchange 323 1.4 Allocation of Home Agent in Foreign Network 325 The DIAMETER Mobile IP extension allows a Home Agent to be allocated 326 in a foreign network, as required in [3, 16]. When the AAAF receives 327 the AMR message with a NULL address in the Home-Agent-Address AVP, 328 it MAY add the Foreign-Home-Agent-Available AVP to inform the AAAH 329 that it is able and willing to assign a Home Agent for the Mobile 330 Node. Upon receiving such a message, the AAAH must decide whether its 331 local policy would allow the user to have a Home Agent in the foreign 332 network. 334 In the event that the AAAH is willing to let the Mobile Node have a 335 Home Agent in the foreign network, it sends the AMA message to the 336 AAAF with the Home-Agent-Address AVP set to the NULL address. The 337 Home Agent's session keys MUST be encrypted using the security 338 association the AAAH shares with the AAAF. 340 ISP Home Network 341 +--------+ +--------+ 342 | | AMR/A | | 343 | AAAF |<--------------->| AAAH | 344 | server | server-server | server | 345 +--------+ communication +--------+ 346 / /|\ 347 HAR/A /AMR/A | client-server 348 / | communication 349 |/_ \|/ 350 +---------+ +---------+ 351 | Home | | Foreign | 352 | Agent | | Agent | 353 +---------+ +---------+ 354 /|\ 355 | Mobile IP 356 | 357 \|/ 358 +--------+ 359 | Mobile | 360 | Node | 361 +--------+ 362 Figure 4: Home Agent allocated in Foreign Domain 364 Upon receiving the message, the AAAF MUST re-encrypt both the Foreign 365 and Home Agent's session keys, and forward the HAR message to a local 366 Home Agent. The HAA is sent to the AAAF, which then forwards the 367 answer to the AAAH. The return path is identical to the one 368 previously defined in section 1.2. The HAA MUST be received by the 369 AAAH, otherwise it has no assurances that service is being provided, 370 and all subsequent accounting information could be rejected. The HAA 371 is also used by the AAAH to receive the Home Address assigned to the 372 Mobile Node. Figure 5 provides a message flow for a case where the 373 Home Agent is allocated in the foreign domain. 375 Mobile Node Foreign Agent AAAF Home Agent AAAH 376 ----------- ------------- ------------- ---------- ---------- 378 <-------Challenge 379 Reg-Req(Response)-> 380 AMR-------------> 381 AMR--------------------------> 382 <------------------------HAR 383 HAR-------------> 384 <----------HAA 385 HAA--------------------------> 386 <------------------------AMA 387 <------------AMA 388 <-------Reg-Reply 389 Figure 5: Mobile IP/DIAMETER Message Exchange 391 If the Mobile Node moves to another Foreign Network, it can either 392 request to keep the same Home Agent within the old foreign network, 393 or it can request that a new one be assigned. A non-NULL Home-Agent- 394 Address AVP indicates that service from the same Home Agent is 395 desired by the Mobile Node. When the Mobile Node requests such a 396 service, the AAAH MUST interact with two AAAFs if it is willing to 397 allow the Mobile Node to receive such service. The AAAH issues the 398 HAR to the AAAF that oversees that Home Agent, and the AMA is issued 399 to the AAAF that oversees the Foreign Agent. 401 1.5 DIAMETER Session Termination 403 A Foreign and Home Agent assume that their respective AAA servers 404 maintain session state information for each mobile node in their 405 networks. In order for the DIAMETER Server to release any resources 406 allocated to a specific mobile node, the mobility agents MUST send a 407 Mobile-Node-Termination-Ind (MTI) to their respective AAA servers. 409 The MTI message MAY also be issued by a DIAMETER server towards a 410 client, which is done to request that a particular session be 411 terminated. 413 2.0 Command-Code AVP Values 415 This section defines Command-Code [1] values that MUST be supported 416 by all DIAMETER implementations conforming to this specification. 418 2.1 AA-Mobile-Node-Request (AMR) Command 420 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code AVP 421 set to 260, is sent by a Foreign Agent acting as a DIAMETER client to 422 a server to request the authentication and authorization of a Mobile 423 Node. The Foreign Agent uses information found in the Registration 424 Request to construct the AMR such as the home address (Mobile-Node- 425 Address AVP), home agent address (Home-Agent-Address AVP), mobile 426 node NAI (User-Name AVP [1]). If the home address is set to a NULL 427 address (0.0.0.0), it is an indication that the Mobile Node wishes to 428 have a home address assigned to it in the Registration Reply. 430 If the AMR message includes a Foreign-Home-Agent-Available AVP and 431 the Home-Agent-Address AVP has a NULL address, it is an indication 432 that the AAAF is willing to assign a Home Agent in the foreign 433 domain. 435 If the Previous-FA-NAI AVP is found in the request, the DIAMETER 436 client requests that the server return the session key that was 437 assigned to the previous Foreign Agent for use with the Mobile Node 438 and Home Agent. The session key is identified through the use of the 439 Mobile-Node-Address AVP. 441 Message Format 443 ::= 444 445 446 447 { || 448 } 449 [] 450 451 452 453 454 455 456 [] 457 [] 458 [] 459 [] 460 [ 461 462 ] 464 2.2 AA-Mobile-Node-Answer (AMA) Command 465 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code AVP 466 set to 261, is sent by the AAAH in response to the AA-Mobile-Node- 467 Request message. A successful response MUST include the MIP- 468 Registration-Reply AVP. The Result-Code AVP MAY contain one of the 469 values defined in section 3.0, in addition to the values defined in 470 [1]. 472 The Home-Agent-Address AVP contains the Home Agent assigned to the 473 Mobile Node, while the Mobile-Node-Address AVP contains the home 474 address that was assigned. A successful response MUST NOT have either 475 AVP set to a NULL address. 477 Message Format 479 ::= 480 481 482 { || 483 } 484 485 486 [] 487 [] 488 [] 489 [] 490 491 492 493 [] 494 [ 495 496 ] 498 2.3 Home-Agent-MIP-Request (HAR) Command 500 The Home-Agent-MIP-Request (HAR), indicated by the Command-Code AVP 501 set to 262, is sent by the AAAH to the Home Agent. If the Home Agent 502 is to be assigned in a foreign network, the HAR is issued to the AAAF 503 overseeing the Home Agent. If the HAR message includes a NULL home 504 address in the Mobile-Node-Address AVP and the request is 505 successfully processed, the Home Agent MUST allocate one such address 506 to the mobile node. 508 If a AAAF receives a HAR with the Mobile-Home-Agent AVP set to a NULL 509 address, it is a request that a Home Agent be assigned in the foreign 510 network. 512 If the AAAH is configured as a Key Distribution Center (see section 513 1.3), the AAAH MUST create the session keys and include them in the 514 HAR message. 516 Message Format 518 ::= 519 520 521 { || 522 } 523 524 [] 525 526 [] 527 [] 528 [] 529 [] 530 [] 531 [] 532 533 534 535 [] 536 [ 537 538 ] 540 2.4 Home-Agent-MIP-Answer (HAA) Command 542 The Home-Agent-MIP-Answer (HAA), indicated by the Command-Code AVP 543 set to 263, is sent by the Home Agent to its local AAA server in 544 response to a Home-Agent-MIP-Request. In the event that this message 545 is sent to an AAAF in a foreign network, the message MUST be 546 forwarded to the AAAH. The Result-Code AVP MAY contain one of the 547 values defined in section 3.0, in addition to the values defined in 548 [1]. 550 Message Format 551 ::= 552 553 554 { || 555 } 556 557 558 [] 559 560 561 562 [] 563 [] 564 [] 565 [ 566 567 ] 569 2.5 Mobile-Node-Terminate-Ind (MTI) Command 571 The Mobile-Node-Terminate-Ind (MTI), indicated by the Command-Code 572 AVP set to 264, is sent by a Foreign Agent or Home Agent to the their 573 local DIAMETER server to inform the server that an active session has 574 been terminated. The MTI message MAY be sent by a DIAMETER Server to 575 the Foreign and Home Agent as an explicit request that the Mobile 576 Node's session be terminated. 578 Message Format 580 Mobile-Node-Terminate-Ind ::= 581 582 583 { || 584 } 585 586 [] 587 588 589 [] 590 [ 591 592 ] 594 3.0 Result-Code AVP Values 596 This section defines new Result-Code [1] values that MUST be 597 supported by all DIAMETER implementations that conform to this 598 specification. 600 DIAMETER_ERROR_BAD_KEY 16 601 This error code is used by the Home Agent to indicate to the 602 local DIAMETER server that the key generated is invalid. 604 DIAMETER_ERROR_BAD_HOME_ADDRESS 17 605 This error code is used by the Home Agent to indicate that the 606 Home Address chosen by the Mobile Node or assigned by the local 607 DIAMETER server is unavailable. 609 DIAMETER_ERROR_TOO_BUSY 18 610 This error code is used by the Home Agent to inform the 611 DIAMETER Server that it cannot handle an extra Mobile Node. 612 Upon receiving this error the DIAMETER Server can try to use an 613 alternate Home Agent if one is available. 615 DIAMETER_ERROR_MIP_REPLY_FAILURE 19 616 This error code is used by the Home Agent to inform the 617 DIAMETER server that the Registration Request failed. 619 4.0 Mandatory AVPs 621 The following table describes the DIAMETER AVPs defined in the Mobie 622 IP extension, their AVP Code values, types, possible flag values and 623 whether the AVP MAY be encrypted. 625 AVP Flag rules 626 +-----+-----+------+-----+----+ 627 Attribute Section Value | | |SHOULD| MUST|Encr| 628 Attribute Name Code Defined Type | MUST| MAY | NOT | NOT|Cand| 629 --------------------------------------------------+-----+------+-----+----+ 630 MIP-Registration- 320 4.1 Data | M | P | | T,V | Y | 631 Request | | | | | | 632 MIP-Registration- 321 4.2 Data | M | P | | T,V | Y | 633 Reply | | | | | | 634 MN-FA-Challenge- 322 4.3 Integer32| M | P | | T,V | Y | 635 Length | | | | | | 636 MN-FA-Response 323 4.4 Data | M | P | | T,V | Y | 637 Mobile-Node-Address 333 4.5 Address | M | P | | T,V | Y | 638 Home-Agent-Address 334 4.6 Address | M | P | | T,V | Y | 639 Previous-FA-NAI 335 4.7 String | M | P | | T,V | Y | 640 Foreign-Home-Agent- 337 4.8 Integer32| M | P | | T,V | Y | 641 Available | | | | | | 642 MN-AAA-SPI 336 4.9 Integer32| M | P | | T,V | Y | 644 4.1 MIP-Registration-Request AVP 646 The MIP-Registration-Request AVP (AVP Code 320) is of type data and 647 contains the Mobile IP Registration Request [4] sent by the Mobile 648 Node to the Foreign Agent. 650 4.2 MIP-Registration-Reply AVP 652 The MIP-Registration-Reply AVP (AVP Code 321) is of type data and 653 contains the Mobile IP Registration Reply [4] sent by the Home Agent 654 to the Foreign Agent. 656 4.3 MN-FA-Challenge-Length AVP 658 The MN-FA-Challenge-Length AVP (AVP Code 322) is of type Interger32 659 and contains the number of octets in the MIP-Registration-Request AVP 660 that are to be used by the AAAH as the challenge value used in the 661 computation of the Response (see section 4.4). 663 4.4 MN-FA-Response AVP 665 The MN-FA-Response AVP (AVP Code 323) is of type data and contains 666 the authenticator field of the Mobile Node's challenge response found 667 in the Mobile IP MN-AAA authentication extension [5]. The 668 authenticator is the value computed by the mobile node using the 669 Registration Request and the security association shared with its 670 AAAH. This AVP is used to authenticate the Mobile Node. 672 The data field contains the mobile node's challenge response and is 673 used to authenticate the mobile node. Although any authentication 674 algorithm can be used, all implementations MUST support MD5's 675 prefix+suffix mode, as described in [5], and MAY support the HMAC 676 mode. The challenge value used in the computation is found in the 677 MIP-Registration-Request AVP. The length of the challenge is found in 678 the MN-FA-Challenge-Length AVP. 680 4.5 Mobile-Node-Address AVP 682 The Mobile-Node-Address AVP (AVP Code 333) is of type Address and 683 contains the Mobile Node's Home Address. When this AVP has a NULL 684 Address (0.0.0.0), it is a request that a Home Address be allocated 685 to the Mobile Node. 687 4.6 Home-Agent-Address AVP 689 The Home-Agent-Addess AVP (AVP Code 334) is of type Address and 690 contains the Mobile Node's Home Agent Address. When this AVP has a 691 NULL address (0.0.0.0), it is a request that a Home Agent be 692 allocated to the Mobile Node. If this AVP is set to the NULL address 693 in the AMA message, it is an indication that a Home Agent MUST be 694 allocated in the foreign network. If the address is set to 695 255.255.255.255 in the AMR, it is a request from the Mobile Node that 696 the Home Agent MUST be allocated only within the home network. 698 4.7 Previous-FA-NAI AVP 700 The Previous-FA-NAI AVP (AVP Code 335) is of type String and contains 701 the Network Access Identifier [6] of the Mobile Node's old Foreign 702 Agent. The Mobile Node will include this information in the 703 Registration Request when it moves it point of attachment to a new 704 foreign agent under the same administrative domain as the old FA 705 (identified by the domain part of the NAI). 707 When this AVP is present in the AA-Mobile-Node-Request, it indicates 708 that the local DIAMETER server overseeing the Foreign Agent should 709 attempt to return the session key that was previously allocated to 710 the old Foreign Agent for the Mobile Node. The session key is 711 identified through the use of the Mobile-Node-Address AVP, which MUST 712 be present if this extension is present. 714 This allows the Mobile Node to move from one Foreign Agent to another 715 within the same administrative domain without having to send the 716 request back to the Mobile Node's Home DIAMETER Server. 718 4.8 Foreign-Home-Agent-Available AVP 720 The Foreign-Home-Agent-Available AVP (AVP Code 336) is of type 721 Integer32 and is added with a value of one by the AAAF owned by the 722 same administrative domain as the Foreign Agent if it is willing and 723 able to allocate a Home Agent within the Foreign network for the 724 Mobile Node. 726 If this extension is present in the AMR and the Home-Agent-Address 727 AVP is set to 0.0.0.0, the AAAH MAY allow the AAAF to assign a Home 728 Agent for the Mobile Node. This is done by including the Home-Agent- 729 Address AVP with a value of 0.0.0.0 in the AMR. 731 4.9 MN-AAA-SPI AVP 732 The MN-AAA-SPI AVP (AVP Code 336) is of type Integer32 and is sent in 733 the AA-Mobile-Node-Request by the Foreign Agent, and contains the SPI 734 value found in the Mobile-IP MN-AAA Authentication Extension [5]. The 735 SPI can be used by the AAAH to identify the security context to use 736 in order to authenticate the Mobile Node. When possible, it is 737 recommended that the AAAH makes use of the Mobile Node's NAI to 738 identify the security context, when possible. 740 5.0 Key Distribution Center (KDC) AVPs 742 The Mobile-IP protocol defines a set of security associations shared 743 between the Mobile Node, Foreign Agent and Home Agents. These three 744 security associations (MN-FA, MN-HA and FA-HA), can be dynamically 745 created by the AAAH. This requires that the AAAH create Mobile-IP 746 Session Keys, and that these keys be distributed to the three mobile 747 entities, via the DIAMETER Protocol. The KDC AVPs SHOULD be 748 supported. 750 When Key Distribution Center services are required, the AAAH creates 751 three session keys; the MN-FA, MN-HA and the FA-HA keys. Each of 752 these keys are encrypted two different ways, one for each key 753 recipient. The mobile node and home agent Session Keys are sent to 754 the Home Agent, while the foreign agent's keys are sent to the 755 foreign agent via the AAAF. 757 If strong authentication and confidentiality of the session keys is 758 required, it is recommended that the strong security extension [9] be 759 used. 761 The following table describes the DIAMETER AVPs defined in the Mobie 762 IP extension, their AVP Code values, types, possible flag values and 763 whether the AVP MAY be encrypted. 765 AVP Flag rules 766 +-----+-----+------+-----+----+ 767 Attribute Section Value | | |SHOULD| MUST|Encr| 768 Attribute Name Code Defined Type | MUST| MAY | NOT | NOT|Cand| 769 --------------------------------------------------+-----+------+-----+----+ 770 MN-to-FA-Key 325 5.1 Complex | M | P | | T,V | Y | 771 MN-to-HA-Key 331 5.1 Complex | M | P | | T,V | Y | 772 FA-to-MN-Key 326 5.2 Complex | M | P | | T,V | Y | 773 FA-to-HA-Key 328 5.2 Complex | M | P | | T,V | Y | 774 HA-to-MN-Key 332 5.2 Complex | M | P | | T,V | Y | 775 HA-to-FA-Key 329 5.2 Complex | M | P | | T,V | Y | 776 FA-MN-Preferred-SPI 324 5.3 Integer32| M | P | | T,V | Y | 777 FA-HA-Preferred-SPI 327 5.4 Integer32| M | P | | T,V | Y | 779 5.1 Mobile Node Session Key AVP 781 The session keys AVPs destined for the Mobile Node are of type 782 complex, and MUST have the AVP length field set to at least 21. The 783 AVP has the following format: 785 0 1 2 3 786 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 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 AVP Header 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Reserved | Security Algorithm | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | AAA SPI | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Peer SPI | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Data ... 797 +-+-+-+-+-+-+-+-+ 799 AVP Code 800 325 for MN-FA Key, destined for Mobile Node 801 331 for MN-HA Key, destined for Mobile Node 803 Security Algorithm 804 The security algorithm field specifies the algorithm that was 805 used to encrypt the session keys. The values are consistent 806 with those found in [15], which also contains the formula used 807 for encryption. The following are currently defined: 809 Algorithm Identifier Name Reference 810 --------------------- ------------------ ------------- 811 2 MD5/prefix+suffix RFC 2002 [14] 812 3 HMAC MD5 RFC 2104 [13] 814 AAA SPI 815 A 32-bit opaque value, indicating the SPI that the target must 816 use to determine the algorithm to use for recovering the 817 encrypted security information. 819 Peer SPI 820 A 32-bit opaque value, which the target MUST use to index all 821 the necessary information recovered from the security 822 information after it is decoded. 824 Data 825 The data field contains the encrypted key used to create a 826 Mobility Security Association between the mobility nodes. 828 5.2 Mobility Agent Session Key AVPs 830 The session keys AVPs destined for the Foreign and Home Agents are of 831 type complex, and MUST have the AVP length field set to at least 13. 832 The AVP has the following format: 834 0 1 2 3 835 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 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 AVP Header 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Peer SPI | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Data ... 842 +-+-+-+-+-+-+-+-+ 844 AVP Code 845 326 for FA-MN Key, destined for Foreign Agent 846 328 for FA-HA Key, destined for Foreign Agent 847 329 for HA-FA Key, destined for Home Agent 848 332 for MN-HA Key, destined for Home Agent 850 Peer SPI 851 A 32-bit opaque value, which the target MUST use to index all 852 the necessary information recovered from the security 853 information after it is decoded. 855 Data 856 The data field contains the encrypted key used to create a 857 Mobility Security Association between the mobility nodes. 859 5.3 FA-MN-Preferred-SPI AVP 861 The FA-Preferred-SPI AVP (AVP Code 324) is of type Integer32 and is 862 sent in the AA-Mobile-Node-Request by the Foreign Agent. The AVP 863 contains the SPI that the Foreign Agent would prefer to have assigned 864 by the AAAH in the FA-to-MN-Key AVP. 866 5.4 FA-HA-Preferred-SPI AVP 868 The FA-Preferred-SPI AVP (AVP Code 324) is of type Integer32 and is 869 sent in the AA-Mobile-Node-Request by the Foreign Agent. The AVP 870 contains the SPI that the Foreign Agent would prefer to have assigned 871 by the AAAH in the FA-to-HA-Key AVP. 873 6.0 Acknowledgements 875 The authors would like to thank Nenad Trifunovic, Tony Johansson and 876 Pankaj Patel for their participation in the Document Reading Party. 877 The authors would also like to thank the participants of TIA's TR45.6 878 working group for their valuable feedback. 880 7.0 IANA Considerations 882 The values for the Command Code AVP in section 2.0 were taken from 883 the numbering space defined for Command-Code AVP in [1]. The numbers 884 for the various AVPs defined in section 4.0 and 5.0 were taken from 885 the AVP numbering space defined in [1]. The Result-Code AVP values 886 defined in section 3.0 were taken from the Result-Code AVP numbering 887 space defined in [1]. The numbering for the AVP, Command Codes and 888 Result Codes MUST NOT conflict with values specified in [1], or any 889 other DIAMETER extension. 891 8.0 Security Considerations 893 This specification describes the DIAMETER extension necessary to 894 authenticate and authorize a Mobile IP Mobile Node. The 895 authentication algorithm used is dependent upon the transforms 896 available by the Mobile IP protocol, and [5]. This specification also 897 defines a method by which the home DIAMETER server can create and 898 distribute short-lived session keys to be used to authenticate Mobile 899 IP registration messages. The keys are distributed in an encrypted 900 format through the DIAMETER protocol, and SHOULD be encrypted using 901 the methods defined in [9]. 903 9.0 References 905 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "DIAMETER Base 906 Protocol", draft-calhoun-diameter-11.txt (work in progress), 907 December 1999. 908 [2] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft-calhoun- 909 diameter-framework-05.txt (work in progress), December 1999. 910 [3] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 911 Authorization, and Accounting Requirements", draft-ietf- 912 mobileip- aaa-reqs-01.txt (work in progress), October 1999. 913 [4] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. 914 [5] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response 915 Extensions", draft-ietf-mobileip-challenge-06.txt (work in 916 progress), October 1999. 917 [6] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486. 919 January 1999. 920 [7] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 921 RFC 2477, January 1999. 922 [8] P. Calhoun, C. Perkins, "Mobile IP Network Address Identifier 923 Extension", draft-ietf-mobileip-mn-nai-05.txt (work in 924 progress), October 1999. 925 [9] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 926 Extensions", draft-calhoun-diameter-strong-security-00.txt (work 927 in progress), December 1999. 928 [10] Kent, Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 929 2406, November 1998. 930 [11] S. Bradner, "Key words for use in RFCs to Indicate Requirement 931 Levels", BCP 14, RFC 2119, March 1997. 932 [12] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "DIAMETER Accounting 933 Extension", draft-calhoun-diameter-accounting-02.txt (work in 934 progress), December 1999. 935 [13] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing 936 for Message Authentication. RFC 2104, February 1997. 937 [14] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 938 1996. 939 [15] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", 940 draft-calhoun-mobileip-aaa-keys-00.txt (work in progress), 941 October 1999. 942 [16] T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA", 943 draft-hiller-cdma2000-AAA-00.txt (work in progress), October 944 1999. 946 10.0 Authors' Addresses 948 Questions about this memo can be directed to: 950 Pat R. Calhoun 951 Network and Security Research Center, Sun Labs 952 Sun Microsystems, Inc. 953 15 Network Circle 954 Menlo Park, California, 94025 955 USA 957 Phone: 1-650-786-7733 958 Fax: 1-650-786-6445 959 E-mail: pcalhoun@eng.sun.com 960 Charles E. Perkins 961 Nokia Research Center 962 313 Fairchild Drive 963 Mountain View, California 94043 964 USA 966 Phone: +1 650-625-2986 967 Fax: +1 650-691-2170 968 E-Mail: charliep@iprg.nokia.com 970 11.0 Full Copyright Statement 972 Copyright (C) The Internet Society (1999). All Rights Reserved. 974 This document and translations of it may be copied and furnished to 975 others, and derivative works that comment on or otherwise explain it 976 or assist in its implementation may be prepared, copied, published 977 and distributed, in whole or in part, without restriction of any 978 kind, provided that the above copyright notice and this paragraph are 979 included on all such copies and derivative works. However, this 980 document itself may not be modified in any way, such as by removing 981 the copyright notice or references to the Internet Society or other 982 Internet organizations, except as needed for the purpose of 983 developing Internet standards in which case the procedures for 984 copyrights defined in the Internet Standards process must be 985 followed, or as required to translate it into languages other than 986 English. The limited permissions granted above are perpetual and will 987 not be revoked by the Internet Society or its successors or assigns. 988 This document and the information contained herein is provided on an 989 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 990 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 991 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 992 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 993 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."