idnits 2.17.1 draft-calhoun-diameter-mobileip-08.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 22 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 23 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 14 instances of too long lines in the document, the longest one being 1 character 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) == Missing Reference: '31' is mentioned on line 855, but not defined == Unused Reference: '2' is defined on line 900, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 926, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 936, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 939, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-15 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-08 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-04) exists of draft-ietf-mobileip-aaa-reqs-03 ** Downref: Normative reference to an Informational draft: draft-ietf-mobileip-aaa-reqs (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-12 ** 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 (-07) exists of draft-calhoun-diameter-strong-crypto-03 -- 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-06 -- 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' == Outdated reference: A later version (-02) exists of draft-hiller-cdma2000-aaa-01 ** Downref: Normative reference to an Informational draft: draft-hiller-cdma2000-aaa (ref. '16') == Outdated reference: A later version (-06) exists of draft-calhoun-diameter-nasreq-03 -- Possible downref: Normative reference to a draft: ref. '17' Summary: 14 errors (**), 0 flaws (~~), 17 warnings (==), 10 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-08.txt Charles E. Perkins 4 Date: June 2000 Nokia Research Center 6 DIAMETER Mobile IP Extensions 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at: 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at: 27 http://www.ietf.org/shadow.html. 29 This document is an individual contribution for consideration by the 30 AAA Working Group of the Internet Engineering Task Force. Comments 31 should be submitted to the diameter@diameter.org mailing list. 33 Distribution of this memo is unlimited. 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 3.0 Result-Code AVP Values 62 4.0 DIAMETER AVPs 63 4.1 MIP-Registration-Request AVP 64 4.2 MIP-Registration-Reply AVP 65 4.3 MN-FA-Challenge-Length AVP 66 4.4 MN-FA-Response AVP 67 4.5 Mobile-Node-Address AVP 68 4.6 Home-Agent-Address AVP 69 4.7 Previous-FA-NAI AVP 70 4.8 Foreign-Home-Agent-Available AVP 71 4.9 MN-AAA-SPI AVP 72 5.0 Key Distribution Center (KDC) AVPs 73 5.1 Mobile Node Session Key AVPs 74 5.2 Mobility Agent Session Key AVPs 75 5.3 FA-MN-Preferred-SPI AVP 76 5.4 FA-HA-Preferred-SPI AVP 77 6.0 Interactions with Resource Management 78 7.0 Acknowledgements 79 8.0 IANA Considerations 80 9.0 Security Considerations 81 10.0 References 82 11.0 Authors' Addresses 83 12.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/AMA | client-server | HAR/A 157 | | communication | 158 v v v 159 +---------+ +---------+ +---------+ 160 | Foreign | | Foreign | | Home | 161 | Agent | | Agent | | Agent | 162 +---------+ +---------+ +---------+ 163 ^ 164 | Mobile IP 165 | 166 v 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 HAA 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) and forwards the message to the AAAF. The 250 AAAF is responsible for ensuring that the message is properly 251 forwarded to the correct 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 324 The DIAMETER Mobile IP extension allows a Home Agent to be allocated 325 in a foreign network, as required in [3, 16]. When the AAAF receives 326 the AMR message with a NULL address in the Home-Agent-Address AVP, 327 it MAY add the Foreign-Home-Agent-Available AVP to inform the AAAH 328 that it is able and willing to assign a Home Agent for the Mobile 329 Node. Upon receiving such a message, the AAAH must decide whether its 330 local policy would allow the user to have a Home Agent in the foreign 331 network. 333 In the event that the AAAH is willing to let the Mobile Node have a 334 Home Agent in the foreign network, it sends the AMA message to the 335 AAAF with the Home-Agent-Address AVP set to the NULL address. The 336 Home Agent's session keys MUST be encrypted using the security 337 association the AAAH shares with the AAAF. 339 ISP Home Network 340 +--------+ +--------+ 341 | | AMR/A | | 342 | AAAF |<--------------->| AAAH | 343 +->| server | server-server | server | 344 | +--------+ communication +--------+ 345 | ^ 346 HAR/A | AMR/A | client-server 347 | | communication 348 v v 349 +---------+ +---------+ 350 | Home | | Foreign | 351 | Agent | | Agent | 352 +---------+ +---------+ 353 ^ 354 | Mobile IP 355 | 356 v 357 +--------+ 358 | Mobile | 359 | Node | 360 +--------+ 361 Figure 4: Home Agent allocated in Foreign Domain 363 Upon receiving the message, the AAAF MUST re-encrypt both the Foreign 364 and Home Agent's session keys, and forward the HAR message to a local 365 Home Agent. The HAA is sent to the AAAF, which then forwards the 366 answer to the AAAH. The return path is identical to the one 367 previously defined in section 1.2. The HAA MUST be received by the 368 AAAH, otherwise it has no assurances that service is being provided, 369 and all subsequent accounting information could be rejected. The HAA 370 is also used by the AAAH to receive the Home Address assigned to the 371 Mobile Node. Figure 5 provides a message flow for a case where the 372 Home Agent is allocated in the foreign domain. 374 Mobile Node Foreign Agent AAAF Home Agent AAAH 375 ----------- ------------- ------------- ---------- ---------- 377 <-------Challenge 378 Reg-Req(Response)-> 379 AMR-------------> 380 AMR--------------------------> 381 <------------------------HAR 382 HAR-------------> 383 <----------HAA 384 HAA--------------------------> 385 <------------------------AMA 386 <------------AMA 387 <-------Reg-Reply 388 Figure 5: Mobile IP/DIAMETER Message Exchange 390 If the Mobile Node moves to another Foreign Network, it can either 391 request to keep the same Home Agent within the old foreign network, 392 or it can request that a new one be assigned. A non-NULL Home-Agent- 393 Address AVP indicates that service from the same Home Agent is 394 desired by the Mobile Node. When the Mobile Node requests such a 395 service, the AAAH MUST interact with two AAAFs if it is willing to 396 allow the Mobile Node to receive such service. The AAAH issues the 397 HAR to the AAAF that oversees that Home Agent, and the AMA is issued 398 to the AAAF that oversees the Foreign Agent. 400 1.5 DIAMETER Session Termination 402 A Foreign and Home Agent assume that their respective DIAMETER 403 servers maintain session state information for each mobile node in 404 their networks. In order for the DIAMETER Server to release any 405 resources allocated to a specific mobile node, the mobility agents 406 MUST send a Session-Termination-Request (STR) [1] to their respective 407 DIAMETER servers. 409 Since Mobile IP typically requires two Mobile Agents, the Home 410 DIAMETER server SHOULD only free all resources when the STR was 411 received from both the Foreign and the Home Agent. This ensures that 412 a Mobile Node that moves from one Foreign Agent to another (hand-off) 413 does not cause the Home DIAMETER Server to free all resources for the 414 Mobile Node. The DIAMETER Server is free to initiate the session 415 termination at any time by issuing the Session-Termination-Ind (STI) 416 [1]. 418 Note that an exception to the above rule exists, where a Mobile Node 419 is authenticated and/or authorized to access it's home network. The 420 Mobile IP protocol allows this to occur, and does not require the 421 presence of a Foreign Agent. Therefore, the Home DIAMETER Server MUST 422 be aware of the fact that a Foreign Agent was involved in the 423 authentication/authorization transaction. 425 2.0 Command-Code AVP Values 427 This section defines Command-Code [1] values that MUST be supported 428 by all DIAMETER implementations conforming to this specification. 429 The following Command Codes are defined in this specification: 431 Command-Name Abbrev. Code Reference 432 -------------------------------------------------------- 433 AA-Mobile-Node-Request AMR 260 2.1 434 AA-Mobile-Node-Answer AMA 261 2.2 435 Home-Agent-MIP-Request HAR 262 2.3 436 Home-Agent-MIP-Answer HAA 263 2.4 438 2.1 AA-Mobile-Node-Request (AMR) Command 440 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code AVP 441 set to 260, is sent by a Foreign Agent acting as a DIAMETER client to 442 a server to request the authentication and authorization of a Mobile 443 Node. The Foreign Agent uses information found in the Registration 444 Request to construct the AMR such as the home address (Mobile-Node- 445 Address AVP), home agent address (Home-Agent-Address AVP), mobile 446 node NAI (User-Name AVP [1]). If the home address is set to a NULL 447 address (0.0.0.0), it is an indication that the Mobile Node wishes to 448 have a home address assigned to it in the Registration Reply. 450 If the AMR message includes a Foreign-Home-Agent-Available AVP and 451 the Home-Agent-Address AVP has a NULL address, it is an indication 452 that the AAAF is willing to assign a Home Agent in the foreign 453 domain. 455 If the Previous-FA-NAI AVP is found in the request, the DIAMETER 456 client requests that the server return the session key that was 457 assigned to the previous Foreign Agent for use with the Mobile Node 458 and Home Agent. The session key is identified through the use of the 459 Mobile-Node-Address AVP. 461 Message Format 462 ::= 463 464 465 466 467 [] 468 469 470 471 472 473 474 [] 475 [] 476 [] 477 [] 478 [] 479 [ 480 481 ] 483 2.2 AA-Mobile-Node-Answer (AMA) Command 485 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code AVP 486 set to 261, is sent by the AAAH in response to the AA-Mobile-Node- 487 Request message. A successful response MUST include the MIP- 488 Registration-Reply AVP. The Result-Code AVP MAY contain one of the 489 values defined in section 3.0, in addition to the values defined in 490 [1]. 492 The Home-Agent-Address AVP contains the Home Agent assigned to the 493 Mobile Node, while the Mobile-Node-Address AVP contains the home 494 address that was assigned. A successful response MUST NOT have either 495 AVP set to a NULL address. 497 The AMA message MUST contain the optional FA-to-HA-Key, FA-to-MN-Key 498 and MIP-Registration-Reply AVPs if they were present in the HAA 499 message. 501 Message Format 502 ::= 503 504 505 506 507 508 [] 509 [] 510 [] 511 512 513 514 [] 515 [ 516 517 ] 519 2.3 Home-Agent-MIP-Request (HAR) Command 521 The Home-Agent-MIP-Request (HAR), indicated by the Command-Code AVP 522 set to 262, is sent by the AAAH to the Home Agent. If the Home Agent 523 is to be assigned in a foreign network, the HAR is issued to the AAAF 524 overseeing the Home Agent. If the HAR message includes a NULL home 525 address in the Mobile-Node-Address AVP and the request is 526 successfully processed, the Home Agent MUST allocate one such address 527 to the mobile node. 529 If a AAAF receives a HAR with the Mobile-Home-Agent AVP set to a NULL 530 address, it is a request that a Home Agent be assigned in the foreign 531 network. 533 If the AAAH is configured as a Key Distribution Center (see section 534 1.3), the AAAH MUST create the session keys and include them in the 535 HAR message. 537 Message Format 538 ::= 539 540 541 542 543 [] 544 545 [] 546 [] 547 [] 548 [] 549 [] 550 [] 551 552 553 554 [] 555 [ 556 557 ] 559 2.4 Home-Agent-MIP-Answer (HAA) Command 561 The Home-Agent-MIP-Answer (HAA), indicated by the Command-Code AVP 562 set to 263, is sent by the Home Agent to its local AAA server in 563 response to a Home-Agent-MIP-Request. In the event that this message 564 is sent to an AAAF in a foreign network, the message MUST be 565 forwarded to the AAAH. The Result-Code AVP MAY contain one of the 566 values defined in section 3.0, in addition to the values defined in 567 [1]. 569 The HAA message MUST contain the optional FA-to-HA-Key and FA-to-MN- 570 Key AVPs if they were present in the HAR message. 572 Message Format 573 ::= 574 575 576 577 578 579 580 581 582 [] 583 [] 584 [] 585 [ 586 587 ] 589 3.0 Result-Code AVP Values 591 This section defines new Result-Code [1] values that MUST be 592 supported by all DIAMETER implementations that conform to this 593 specification. 595 DIAMETER_ERROR_BAD_KEY 16 596 This error code is used by the Home Agent to indicate to the 597 local DIAMETER server that the key generated is invalid. 599 DIAMETER_ERROR_BAD_HOME_ADDRESS 17 600 This error code is used by the Home Agent to indicate that the 601 Home Address chosen by the Mobile Node or assigned by the local 602 DIAMETER server is unavailable. 604 DIAMETER_ERROR_TOO_BUSY 18 605 This error code is used by the Home Agent to inform the 606 DIAMETER Server that it cannot handle an extra Mobile Node. 607 Upon receiving this error the DIAMETER Server can try to use an 608 alternate Home Agent if one is available. 610 DIAMETER_ERROR_MIP_REPLY_FAILURE 19 611 This error code is used by the Home Agent to inform the 612 DIAMETER server that the Registration Request failed. 614 4.0 Mandatory AVPs 616 The following table describes the DIAMETER AVPs defined in the Mobie 617 IP extension, their AVP Code values, types, possible flag values and 618 whether the AVP MAY be encrypted. 620 +---------------------+ 621 | AVP Flag rules | 622 |----+-----+----+-----|----+ 623 AVP Section Value | | |SHLD| MUST|May | 624 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr| 625 -----------------------------------------|----+-----+----+-----|----+ 626 MIP- 320 4.1 Data | M | P | | T,V | Y | 627 Registration-Request | | | | | | 628 MIP- 321 4.2 Data | M | P | | T,V | Y | 629 Registration-Reply | | | | | | 630 MN-FA-Challenge- 322 4.3 Integer32| M | P | | T,V | Y | 631 Length | | | | | | 632 MN-FA-Response 323 4.4 Data | M | P | | T,V | Y | 633 Mobile-Node- 333 4.5 Address | M | P | | T,V | Y | 634 Address | | | | | | 635 Home-Agent- 334 4.6 Address | M | P | | T,V | Y | 636 Address | | | | | | 637 Previous-FA-NAI 335 4.7 String | M | P | | T,V | Y | 638 Foreign-Home- 337 4.8 Integer32| M | P | | T,V | Y | 639 Agent-Available | | | | | | 640 MN-AAA-SPI 336 4.9 Integer32| M | P | | T,V | Y | 642 4.1 MIP-Registration-Request AVP 644 The MIP-Registration-Request AVP (AVP Code 320) is of type data and 645 contains the Mobile IP Registration Request [4] sent by the Mobile 646 Node to the Foreign Agent. 648 4.2 MIP-Registration-Reply AVP 650 The MIP-Registration-Reply AVP (AVP Code 321) is of type data and 651 contains the Mobile IP Registration Reply [4] sent by the Home Agent 652 to the Foreign Agent. 654 4.3 MN-FA-Challenge-Length AVP 656 The MN-FA-Challenge-Length AVP (AVP Code 322) is of type Interger32 657 and contains the number of octets in the MIP-Registration-Request AVP 658 that are to be used by the AAAH as the challenge value used in the 659 computation of the Response (see section 4.4). 661 4.4 MN-FA-Response AVP 663 The MN-FA-Response AVP (AVP Code 323) is of type data and contains 664 the authenticator field of the Mobile Node's challenge response found 665 in the Mobile IP MN-AAA authentication extension [5]. The 666 authenticator is the value computed by the mobile node using the 667 Registration Request and the security association shared with its 668 AAAH. This AVP is used to authenticate the Mobile Node. 670 The data field contains the mobile node's challenge response and is 671 used to authenticate the mobile node. Although any authentication 672 algorithm can be used, all implementations MUST support MD5's 673 prefix+suffix mode, as described in [5], and MAY support the HMAC 674 mode. The challenge value used in the computation is found in the 675 MIP-Registration-Request AVP. The length of the challenge is found in 676 the MN-FA-Challenge-Length AVP. 678 4.5 Mobile-Node-Address AVP 680 The Mobile-Node-Address AVP (AVP Code 333) is of type Address and 681 contains the Mobile Node's Home Address. When this AVP has a NULL 682 Address (0.0.0.0), it is a request that a Home Address be allocated 683 to the Mobile Node. 685 4.6 Home-Agent-Address AVP 687 The Home-Agent-Addess AVP (AVP Code 334) is of type Address and 688 contains the Mobile Node's Home Agent Address. When this AVP has a 689 NULL address (0.0.0.0), it is a request that a Home Agent be 690 allocated to the Mobile Node. If this AVP is set to the NULL address 691 in the AMA message, it is an indication that a Home Agent MUST be 692 allocated in the foreign network. If the address is set to 693 255.255.255.255 in the AMR, it is a request from the Mobile Node that 694 the Home Agent MUST be allocated only within the home network. 696 4.7 Previous-FA-NAI AVP 698 The Previous-FA-NAI AVP (AVP Code 335) is of type String and contains 699 the Network Access Identifier [6] of the Mobile Node's old Foreign 700 Agent. The Mobile Node will include this information in the 701 Registration Request when it moves it point of attachment to a new 702 foreign agent under the same administrative domain as the old FA 703 (identified by the realm portion of the NAI). 705 When this AVP is present in the AA-Mobile-Node-Request, it indicates 706 that the local DIAMETER server overseeing the Foreign Agent should 707 attempt to return the session key that was previously allocated to 708 the old Foreign Agent for the Mobile Node. The session key is 709 identified through the use of the Mobile-Node-Address AVP, which MUST 710 be present if this extension is present. 712 This allows the Mobile Node to move from one Foreign Agent to another 713 within the same administrative domain without having to send the 714 request back to the Mobile Node's Home DIAMETER Server. 716 4.8 Foreign-Home-Agent-Available AVP 718 The Foreign-Home-Agent-Available AVP (AVP Code 337) is of type 719 Integer32 and is added with a value of one by the AAAF owned by the 720 same administrative domain as the Foreign Agent if it is willing and 721 able to allocate a Home Agent within the Foreign network for the 722 Mobile Node. 724 If this extension is present in the AMR and the Home-Agent-Address 725 AVP is set to 0.0.0.0, the AAAH MAY allow the AAAF to assign a Home 726 Agent for the Mobile Node. This is done by including the Home-Agent- 727 Address AVP with a value of 0.0.0.0 in the AMR. 729 4.9 MN-AAA-SPI AVP 731 The MN-AAA-SPI AVP (AVP Code 336) is of type Integer32 and is sent in 732 the AA-Mobile-Node-Request by the Foreign Agent, and contains the SPI 733 value found in the Mobile-IP MN-AAA Authentication Extension [5]. The 734 SPI can be used by the AAAH to identify the security context to use 735 in order to authenticate the Mobile Node. When possible, it is 736 recommended that the AAAH makes use of the Mobile Node's NAI to 737 identify the security context, when possible. 739 5.0 Key Distribution Center (KDC) AVPs 741 The Mobile-IP protocol defines a set of security associations shared 742 between the Mobile Node, Foreign Agent and Home Agents. These three 743 security associations (MN-FA, MN-HA and FA-HA), can be dynamically 744 created by the AAAH. This requires that the AAAH create Mobile-IP 745 Session Keys, and that these keys be distributed to the three mobile 746 entities, via the DIAMETER Protocol. The KDC AVPs SHOULD be 747 supported. 749 When Key Distribution Center services are required, the AAAH creates 750 three session keys; the MN-FA, MN-HA and the FA-HA keys. Each of 751 these keys are encrypted two different ways, one for each key 752 recipient. The mobile node and home agent Session Keys are sent to 753 the Home Agent, while the foreign agent's keys are sent to the 754 foreign agent via the AAAF. 756 If strong authentication and confidentiality of the session keys is 757 required, it is recommended that the strong security extension [9] be 758 used. 760 The following table describes the DIAMETER AVPs defined in the Mobie 761 IP extension, their AVP Code values, types, possible flag values and 762 whether the AVP MAY be encrypted. 764 +---------------------+ 765 | AVP Flag rules | 766 |----+-----+----+-----|----+ 767 AVP Section Value | | |SHLD| MUST|MAY | 768 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr| 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- 324 5.3 Integer32| M | P | | T,V | Y | 777 SPI | | | | | | 778 FA-HA-Preferred- 327 5.4 Integer32| M | P | | T,V | Y | 779 SPI | | | | | | 781 5.1 Mobile Node Session Key AVP 783 The session keys AVPs destined for the Mobile Node are of type 784 complex, and are created by the AAAH. There are two Mobile Node 785 Session Key AVPs; the MN-FA Key and the MN-HA Key. 787 The MN-FA-Key AVP (AVP Code 325) contains the data immediately 788 following the Mobile IP extension header of the "Unsolicited MN-FA 789 Key From AAA Subtype", as documented in [15]. 791 The MN-HA-Key AVP (AVP Code 331) contains the data immediately 792 following the Mobile IP extension header of the "Unsolicited MN-HA 793 Key From AAA Subtype", as documented in [15]. 795 The AAA SPI field of the Mobile IP session keys are set to the value 796 the AAAH shares with the Mobile Node. The MN-HA-Key's HA SPI field 797 contains the same value as the one found in the HA-MN-Key AVP. The 798 MN-FA-Key's FA SPI field contains the same value as the one found in 799 the FA-MN-Key AVP. The session key's Lifetime field is set to the 800 same value as the one found in the Session-Timeout AVP. 802 5.2 Mobility Agent Session Key AVPs 804 The session keys AVPs destined for the Foreign and Home Agents are of 805 type complex, and MUST have the AVP length field set to at least 13. 806 The AVP has the following format: 808 0 1 2 3 809 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 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 AVP Header 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Peer SPI | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Data ... 816 +-+-+-+-+-+-+-+-+ 818 AVP Code 819 326 for FA-MN Key, destined for Foreign Agent 820 328 for FA-HA Key, destined for Foreign Agent 821 329 for HA-FA Key, destined for Home Agent 822 332 for MN-HA Key, destined for Home Agent 824 Peer SPI 825 A 32-bit opaque value, which the target MUST use to index all 826 the necessary information recovered from the security 827 information after it is decoded. 829 Data 830 The data field contains the key used to create a Mobility 831 Security Association between the mobility nodes. 833 5.3 FA-MN-Preferred-SPI AVP 835 The FA-Preferred-SPI AVP (AVP Code 324) is of type Integer32 and is 836 sent in the AA-Mobile-Node-Request by the Foreign Agent. The AVP 837 contains the SPI that the Foreign Agent would prefer to have assigned 838 by the AAAH in the FA-to-MN-Key AVP. 840 5.4 FA-HA-Preferred-SPI AVP 842 The FA-Preferred-SPI AVP (AVP Code 324) is of type Integer32 and is 843 sent in the AA-Mobile-Node-Request by the Foreign Agent. The AVP 844 contains the SPI that the Foreign Agent would prefer to have assigned 845 by the AAAH in the FA-to-HA-Key AVP. 847 6.0 Interactions with Resource Management 849 The Resource Management extension [31] provides the ability for a 850 DIAMETER node to query a peer for session state information. The 851 document states that service-specific extensions are responsible for 852 specifying what AVPs are to be present in the Resource-Token [31] 853 AVP. 855 In addition to the AVPs listed in [31], the Resource-Token with the 856 Extension-Id AVP set to four (4) MUST include the Mobile-Node-Address 857 and the Home-Agent-Address AVP. 859 7.0 Acknowledgements 861 The authors would like to thank Nenad Trifunovic, Tony Johansson and 862 Pankaj Patel for their participation in the Document Reading Party. 863 The authors would also like to thank the participants of TIA's TR45.6 864 working group for their valuable feedback. 866 8.0 IANA Considerations 868 The command codes defined in Section 2.0 are values taken from the 869 Command-Code AVP [1] address space and extended in [9], [12] and 870 [17]. IANA should record the values as defined in Section 2.0. 872 The Result-Code values defined in Section 3.0 are error codes as 873 defined in [1] and extended in [9], [12] and [17]. They correspond to 874 error values specific to the Mobile IP extension. IANA should record 875 the values as defined in Section 3.0. 877 The AVPs defined in sections 4.0 and 5.0 were alllocated from from 878 the AVP numbering space defined in [1], and extended in [9], [12] and 879 [17]. IANA should record the values as defined in Sections 4.0 and 880 5.0. 882 9.0 Security Considerations 884 This specification describes the DIAMETER extension necessary to 885 authenticate and authorize a Mobile IP Mobile Node. The 886 authentication algorithm used is dependent upon the transforms 887 available by the Mobile IP protocol, and [5]. This specification also 888 defines a method by which the home DIAMETER server can create and 889 distribute short-lived session keys to be used to authenticate Mobile 890 IP registration messages. The keys are distributed in an encrypted 891 format through the DIAMETER protocol, and SHOULD be encrypted using 892 the methods defined in [9]. 894 10.0 References 896 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "DIAMETER Base 897 Protocol", draft-calhoun-diameter-15.txt, IETF work in progress, 898 June 2000. 900 [2] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft-calhoun- 901 diameter-framework-08.txt, IETF work in progress, June 2000. 903 [3] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 904 Authorization, and Accounting Requirements", draft-ietf- 905 mobileip-aaa-reqs-03.txt, IETF work in progress, March 2000. 907 [4] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. 909 [5] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Exten- 910 sions", draft-ietf-mobileip-challenge-12.txt, IETF work in pro- 911 gress, June 2000. 913 [6] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486. 914 January 1999. 916 [7] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 917 RFC 2477, January 1999. 919 [8] P. Calhoun, C. Perkins, "Mobile IP Network Address Identifier 920 Extension", RFC 2794, March 2000. 922 [9] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 923 Extensions", draft-calhoun-diameter-strong-crypto-03.txt, IETF 924 work in progress, April 2000. 926 [10] Kent, Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 927 2406, November 1998. 929 [11] S. Bradner, "Key words for use in RFCs to Indicate Requirement 930 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-06.txt, IETF work 934 in progress, June 2000. 936 [13] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing 937 for Message Authentication. RFC 2104, February 1997. 939 [14] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 940 1996. 942 [15] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", 943 draft-calhoun-mobileip-aaa-keys-01.txt, IETF work in progress, 944 January 2000. 946 [16] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", 947 draft-hiller-cdma2000-aaa-01.txt, IETF work in progress, June 948 2000. 950 [17] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ 951 Extension", draft-calhoun-diameter-nasreq-03.txt, IETF work in 952 progress, April 2000. 954 11.0 Authors' Addresses 956 Questions about this memo can be directed to: 958 Pat R. Calhoun 959 Network and Security Research Center, Sun Labs 960 Sun Microsystems, Inc. 961 15 Network Circle 962 Menlo Park, California, 94025 963 USA 965 Phone: +1 650-786-7733 966 Fax: +1 650-786-6445 967 E-mail: pcalhoun@eng.sun.com 969 Charles E. Perkins 970 Nokia Research Center 971 313 Fairchild Drive 972 Mountain View, California 94043 973 USA 975 Phone: +1 650-625-2986 976 Fax: +1 650-691-2170 977 E-Mail: charliep@iprg.nokia.com 979 12.0 Full Copyright Statement 980 Copyright (C) The Internet Society (1999). All Rights Reserved. 982 This document and translations of it may be copied and furnished to 983 others, and derivative works that comment on or otherwise explain it 984 or assist in its implementation may be prepared, copied, published 985 and distributed, in whole or in part, without restriction of any 986 kind, provided that the above copyright notice and this paragraph are 987 included on all such copies and derivative works. However, this docu- 988 ment itself may not be modified in any way, such as by removing the 989 copyright notice or references to the Internet Society or other 990 Internet organizations, except as needed for the purpose of develop- 991 ing Internet standards in which case the procedures for copyrights 992 defined in the Internet Standards process must be followed, or as 993 required to translate it into languages other than English. The lim- 994 ited permissions granted above are perpetual and will not be revoked 995 by the Internet Society or its successors or assigns. This document 996 and the information contained herein is provided on an "AS IS" basis 997 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 998 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 999 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1000 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1001 FITNESS FOR A PARTICULAR PURPOSE.