idnits 2.17.1 draft-calhoun-diameter-mobileip-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 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 854, but not defined == Unused Reference: '2' is defined on line 899, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 925, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 935, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 938, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-16 -- 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-04 -- 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-07 -- 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) -- Unexpected draft version: The latest known version of draft-calhoun-mobileip-aaa-key is -00, but you're referring to -01. -- 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-04 -- 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. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Laboratories, Inc. 4 Title: draft-calhoun-diameter-mobileip-09.txt Charles E. Perkins 5 Date: July 2000 Nokia Research Center 7 DIAMETER Mobile IP Extensions 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at: 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at: 28 http://www.ietf.org/shadow.html. 30 This document is an individual contribution for consideration by the 31 AAA Working Group of the Internet Engineering Task Force. Comments 32 should be submitted to the diameter@diameter.org mailing list. 34 Distribution of this memo is unlimited. 36 Copyright (C) The Internet Society 1999. All Rights Reserved. 38 Abstract 40 This document specifies an extension to the DIAMETER base protocol 41 that allows a DIAMETER server to authenticate, authorize and collect 42 accounting information for services rendered to a mobile node. 43 Combined with the Inter-Domain capability of the base protocol, this 44 extension allows mobile nodes to receive service from foreign service 45 providers. The DIAMETER Accounting extension will be used by the 46 Foreign and Home agents to transfer usage information to the DIAMETER 47 servers. 49 Table of Contents 51 1.0 Introduction 52 1.1 Requirements language 53 1.2 Inter-Domain Mobile IP 54 1.3 Key Distribution Center 55 1.4 Allocation of Home Agent in Foreign Network 56 1.5 DIAMETER Session Termination 57 2.0 Command-Code Values 58 2.1 AA-Mobile-Node-Request (AMR) Command 59 2.2 AA-Mobile-Node-Answer (AMA) Command 60 2.3 Home-Agent-MIP-Request (HAR) Command 61 2.4 Home-Agent-MIP-Answer (HAA) 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-HA-Preferred-SPI AVP 78 6.0 Interactions with Resource Management 79 7.0 Acknowledgements 80 8.0 IANA Considerations 81 9.0 Security Considerations 82 10.0 References 83 11.0 Authors' Addresses 84 12.0 Full Copyright Statement 86 1.0 Introduction 88 The Mobile IP [4] protocol defines a method that allows a Mobile Node 89 to change its point of attachment to the Internet without service 90 disruption. The Mobile IP protocol, as defined in [4], assumes that 91 mobility is performed in a single administrative domain, and 92 therefore does not specify how usage can be accounted for, which 93 limits the applicability of Mobile IP in a commercial deployment. 94 Further, the protocol requires that a mobile node has a static home 95 agent, and home address, which is not desirable in a commercial 96 network. 98 This document specifies an extension to the DIAMETER base protocol 99 [1] that allows a DIAMETER server to authenticate, authorize and 100 collect accounting information for services rendered to a mobile 101 node. Combined with the Inter-Domain capability of the base protocol, 102 this extension allows mobile nodes to receive service from foreign 103 service providers. The DIAMETER Accounting extension [12] will be 104 used by the Foreign and Home agents to transfer usage information to 105 the DIAMETER servers. 107 The Mobile IP protocol [4] specifies a security model that requires 108 that mobile nodes and home agents share a pre-existing security 109 association, which leads to scaling and configuration issues. This 110 specification defines an optional DIAMETER function that allows the 111 mobile's home AAA server to act as a Key Distribution Center (KDC), 112 where dynamic session keys are created and distributed to the 113 mobility entities for the purposes of securing Mobile IP Registration 114 messages. 116 As with the DIAMETER base protocol, the Mobile IP extension requires 117 the presence of users' identities in a format consistent with the 118 Network Access Identifier (NAI) specification [6], which is used for 119 DIAMETER message routing purposes. This requires mobile nodes to 120 include their identity in Registration messages, as defined in [8]. 121 The use of the NAI is consistent with the current roaming model, as 122 defined by the ROAMOPS Working Group [7]. 124 This specification defines the DIAMETER Mobile-IP Extension, and 125 addresses all of the requirements specified in [3, 16]. This section 126 will provides some examples and message flows of the Mobile IP and 127 DIAMETER messages that occur when a Mobile Node requests service in a 128 foreign network. 130 The Extension number for this draft is four (4). DIAMETER nodes 131 conforming to this specification MUST include an Extension-Id AVP 132 with a value of four in the Device-Reboot-Ind Command [1]. 134 1.1 Requirements language 136 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 137 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 138 described in [11]. 140 1.2 Inter-Domain Mobile IP 142 When a Mobile Node node requests service by issuing a Registration 143 Request to the foreign agent (FA), the FA creates the AA-Mobile- 144 Node-Request (AMR) message, which includes the AVPs defined in 145 section 2.1. The Home Address, Home Agent, Mobile Node NAI and other 146 important fields are extracted from the registration messages and 147 included as DIAMETER AVPs. The request is then forwarded to the FA's 148 local DIAMETER server, known as the AAA-Foreign, or AAAF. 150 ISP Home Network 151 +--------+ +--------+ 152 |abc.com | AMR/A |xyz.com | 153 | AAAF |<--------------->| AAAH | 154 +->| server | server-server | server | 155 | +--------+ communication +--------+ 156 | ^ ^ 157 | AMR/AMA | client-server | HAR/A 158 | | communication | 159 v v v 160 +---------+ +---------+ +---------+ 161 | Foreign | | Foreign | | Home | 162 | Agent | | Agent | | Agent | 163 +---------+ +---------+ +---------+ 164 ^ 165 | Mobile IP 166 | 167 v 168 +--------+ 169 | Mobile | 170 | Node | mn@xyz.com 171 +--------+ 173 Figure 1: Inter-Domain Mobility 175 Upon receiving the AMR, the AAAF follows the procedures outlined in 176 [1] to determine whether the AMR should be processed locally, or if 177 it should be forwarded to another DIAMETER Server, known as the AAA- 178 Home, or AAAH. Figure 1 describes an example of a mobile node 179 (mn@xyz.com) requests service from a foreign provider (abc.com). The 180 request received by the AAAF is forwarded to abc.com's AAAH server. 182 Figure 2 provides an example of the message flows involved when the 183 Foreign Agent invokes the AAA infrastructure to request that a mobile 184 node be authenticated and authorized. Note that it is not required 185 that the Foreign Agent invoke the AAA every time a Registration 186 Request is received by the mobile, but rather when the prior 187 authorization from the AAAH expires. The expiration of the 188 authorization (and session keys, if used) is communicated through the 189 Session-Time AVP in the response from the AAAH. 191 Mobile Node Foreign Agent AAAF AAAH Home Agent 192 ----------- ------------- ------------ ---------- ---------- 193 Advertisement + 194 <---Challenge 195 Reg-Req(MN-AAA)-> 196 AMR-------------> 197 AMR------------> 198 HAR-----------> 199 <----------HAA 200 <-----------AMA 201 <------------AMA 202 <-------Reg-Reply 204 Figure 2: Mobile IP/DIAMETER Message Exchange 206 The foreign agent depicted in figure 2 provides a challenge, which 207 allows it to have direct control over the replay protection in the 208 Mobile IP registration process, as described in [5]. The Challenge 209 and MN-AAA authentication extension is used by the AAAH to 210 authenticate the Mobile Node. If the value of the MN-AAA is invalid, 211 the AAAH returns the AA-Mobile-Node-Answer (AMA, see section 2.2) 212 with the Result-Code AVP set to an appropriate value. 214 If the Mobile Node was successfully authenticated, the AAAH checks 215 whether the Home-Agent-Address AVP specified a Home Agent. If one was 216 specified, the AAAH must validate the address to ensure that it is a 217 known Home Agent, and one that the Mobile Node is allowed to request. 218 If no Home Agent was specified the AAAH SHOULD allocate one on behalf 219 of the Mobile Node. This can be done in a variety of ways, including 220 using a load balancing algorithm in order to keep the load on all 221 Home Agents equal. The actual algorithm used and the method of 222 discovering the Home Agents is outside of this specification. 224 If the AMR's Mobile-Node-Address AVP did not specify an address, the 225 AAAH has the option of assigning an address for the Mobile Node, or 226 it can leave this up to the Home Agent. This is a local policy 227 decision. 229 The AAAH then sends a Home-Agent-MIP-Request (HAR), which contains 230 the Mobile IP Registration Request encapsulated in the MIP- 231 Registration-Request AVP, to the assigned or requested Home Agent. If 232 the Mobile-Node-Address AVP contains a NULL address (0.0.0.0), it is 233 a request on behalf of the Mobile Node that a home address be 234 assigned. The AAAH MAY manage the allocation of a home address for 235 the mobile node, or leave the NULL address if it requires that the 236 Home Agent perform the address assignment. 238 Upon receipt of the HAR, the Home Agent processes the DIAMETER 239 message as well as the Mobile IP Registration Request. If the 240 DIAMETER message is invalid, a HAA is returned with the Result-Code 241 AVP set to an appropriate value (see section 3.0). If the HAR is 242 valid, the Home Agent processes the registration message and creates 243 the Registration Reply, encapsulated within the MIP-Registration- 244 Reply AVP. If a home address was requested, the Home Agent MUST 245 assign one and include the address in both the Registration Reply and 246 within the DIAMETER Mobile-Node-Address AVP. The DIAMETER response is 247 then forwarded to the AAAH. 249 Upon receipt of the HAA, the AAAH sets the Command-Code field to AA- 250 Mobile-Node-Answer (AMA) and forwards the message to the AAAF. The 251 AAAF is responsible for ensuring that the message is properly 252 forwarded to the correct foreign agent. 254 1.3 Key Distribution Center 256 If the AAAH is configured to act as a Key Distribution Center (KDC), 257 the AAAH MUST create three short-lived keys when a Mobile Node is 258 successfully authenticated and authorized. The three keys are used by 259 the mobility entities to compute the three authentication extensions 260 defined in [4]; Mobile-Foreign, Foreign-Home and Mobile-Home. 262 The keys destined for each mobility entity are encrypted either using 263 the secret shared with the entity [1], or via its public key [9]. The 264 keys are encrypted using the security association shared with the 265 entity in question. If the AAAH does not communicate directly with 266 the Foreign Agent, the FA's keys are encrypted using the security 267 association shared with the AAAF. The Session-Timeout AVP contains 268 the number of seconds before the session keys expire. A value of zero 269 indicates infinity (no timeout). 271 KDC support requires a departure from the existing SPI usage, as 272 described in [4]. The AAAH generates SPI values for the Mobility 273 Agents as opposed to a receiver choosing its own SPI value. The SPI 274 values are used as key identifiers, meaning that each short-lived 275 session key has its own SPI value and since two nodes share a session 276 key they share an SPI as well. 278 Suppose a Mobile Node and a Foreign Agent share a key that was 279 created by the AAAH. The AAAH also generated a corresponding SPI 280 value of 37,496. All Mobile-Foreign Authentication extensions must be 281 computed by either entity using the shared session key and MUST 282 include the SPI value of 37,496. 284 The AAAH MUST include all of the session keys in the HAR message sent 285 to the Home Agent. If the HAR and the Registration Request are 286 successfully processed, the Home Agent MUST include the Mobile Node's 287 session keys in the Registration Reply [15], and the Foreign Agent's 288 session keys in the HAA message (see section 2.4). The Registration 289 Reply MUST include the Mobile-Home authentication extension using the 290 session key distributed for that purpose by the AAAH. Similarly, the 291 Reply SHOULD include the Foreign-Home authentication extension using 292 the appropriate session key distributed by the AAAH. 294 Upon receipt of the successful AA-Mobile-Node-Answer (AMA) the AAAF 295 decrypts the FA-to-MN-Key and the FA-to-HA-Key AVPs. The AMA is 296 transmitted to the Foreign Agent. 298 Upon receipt of the AMA, the Foreign Agent decrypts its session keys 299 found in the FA-to-MN-Key and FA-to-HA-Key, and validates the 300 Foreign-Home authentication extension using the session key. The 301 Foreign Agent MUST also include a Mobile-Foreign authentication 302 extension using the newly distributed session key it shares with the 303 Mobile Node. 305 Once the session keys have been distributed to the three mobility 306 entities, subsequent registrations do not need to invoke the AAA 307 infrastructure unless the keys expire. These registrations MUST 308 include the MN-FA, FA-HA and MN-HA authentication extensions. Figure 309 3 provides an example of subsequent Mobile IP message exchange. 311 Mobile Node Foreign Agent Home Agent 312 ----------- ------------- ---------- 314 Reg-Req(MN-FA-Auth, MN-HA-Auth)--------> 316 Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> 318 <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) 320 <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) 322 Figure 3: Mobile IP Message Exchange 324 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 v v 350 +---------+ +---------+ 351 | Home | | Foreign | 352 | Agent | | Agent | 353 +---------+ +---------+ 354 ^ 355 | Mobile IP 356 | 357 v 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 DIAMETER 404 servers maintain session state information for each mobile node in 405 their networks. In order for the DIAMETER Server to release any 406 resources allocated to a specific mobile node, the mobility agents 407 MUST send a Session-Termination-Request (STR) [1] to their respective 408 DIAMETER servers. 410 Since Mobile IP typically requires two Mobile Agents, the Home 411 DIAMETER server SHOULD only free all resources when the STR was 412 received from both the Foreign and the Home Agent. This ensures that 413 a Mobile Node that moves from one Foreign Agent to another (hand-off) 414 does not cause the Home DIAMETER Server to free all resources for the 415 Mobile Node. The DIAMETER Server is free to initiate the session 416 termination at any time by issuing the Session-Termination-Ind (STI) 417 [1]. 419 Note that an exception to the above rule exists, where a Mobile Node 420 is authenticated and/or authorized to access it's home network. The 421 Mobile IP protocol allows this to occur, and does not require the 422 presence of a Foreign Agent. Therefore, the Home DIAMETER Server MUST 423 be aware of the fact that a Foreign Agent was involved in the 424 authentication/authorization transaction. 426 2.0 Command-Code Values 428 This section defines Command-Code [1] values that MUST be supported 429 by all DIAMETER implementations conforming to this specification. 430 The following Command Codes are defined in this specification: 432 Command-Name Abbrev. Code Reference 433 -------------------------------------------------------- 434 AA-Mobile-Node-Request AMR 260 2.1 435 AA-Mobile-Node-Answer AMA 261 2.2 436 Home-Agent-MIP-Request HAR 262 2.3 437 Home-Agent-MIP-Answer HAA 263 2.4 439 2.1 AA-Mobile-Node-Request (AMR) Command 441 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field 442 set to 260, is sent by a Foreign Agent acting as a DIAMETER client to 443 a server to request the authentication and authorization of a Mobile 444 Node. The Foreign Agent uses information found in the Registration 445 Request to construct the AMR such as the home address (Mobile-Node- 446 Address AVP), home agent address (Home-Agent-Address AVP), mobile 447 node NAI (User-Name AVP [1]). If the home address is set to a NULL 448 address (0.0.0.0), it is an indication that the Mobile Node wishes to 449 have a home address assigned to it in the Registration Reply. 451 If the AMR message includes a Foreign-Home-Agent-Available AVP and 452 the Home-Agent-Address AVP has a NULL address, it is an indication 453 that the AAAF is willing to assign a Home Agent in the foreign 454 domain. 456 If the Previous-FA-NAI AVP is found in the request, the DIAMETER 457 client requests that the server return the session key that was 458 assigned to the previous Foreign Agent for use with the Mobile Node 459 and Home Agent. The session key is identified through the use of the 460 Mobile-Node-Address AVP. 462 Message Format 463 ::= 465 466 467 468 [] 469 470 471 472 473 474 475 [] 476 [] 477 [] 478 [] 479 [] 480 [ 481 482 ] 484 2.2 AA-Mobile-Node-Answer (AMA) Command 486 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field 487 set to 261, is sent by the AAAH in response to the AA-Mobile-Node- 488 Request message. A successful response MUST include the MIP- 489 Registration-Reply AVP. The Result-Code AVP MAY contain one of the 490 values defined in section 3.0, in addition to the values defined in 491 [1]. 493 The Home-Agent-Address AVP contains the Home Agent assigned to the 494 Mobile Node, while the Mobile-Node-Address AVP contains the home 495 address that was assigned. A successful response MUST NOT have either 496 AVP set to a NULL address. 498 The AMA message MUST contain the optional FA-to-HA-Key, FA-to-MN-Key 499 and MIP-Registration-Reply AVPs if they were present in the HAA 500 message. 502 Message Format 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 field 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 ::= 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 field 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 ] 588 3.0 Result-Code AVP Values 590 This section defines new Result-Code [1] values that MUST be 591 supported by all DIAMETER implementations that conform to this 592 specification. 594 DIAMETER_ERROR_BAD_KEY 16 595 This error code is used by the Home Agent to indicate to the 596 local DIAMETER server that the key generated is invalid. 598 DIAMETER_ERROR_BAD_HOME_ADDRESS 17 599 This error code is used by the Home Agent to indicate that the 600 Home Address chosen by the Mobile Node or assigned by the local 601 DIAMETER server is unavailable. 603 DIAMETER_ERROR_TOO_BUSY 18 604 This error code is used by the Home Agent to inform the 605 DIAMETER Server that it cannot handle an extra Mobile Node. 606 Upon receiving this error the DIAMETER Server can try to use an 607 alternate Home Agent if one is available. 609 DIAMETER_ERROR_MIP_REPLY_FAILURE 19 610 This error code is used by the Home Agent to inform the 611 DIAMETER server that the Registration Request failed. 613 4.0 Mandatory AVPs 615 The following table describes the DIAMETER AVPs defined in the Mobie 616 IP extension, their AVP Code values, types, possible flag values and 617 whether the AVP MAY be encrypted. 619 +---------------------+ 620 | AVP Flag rules | 621 |----+-----+----+-----|----+ 622 AVP Section Value | | |SHLD| MUST|May | 623 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr| 624 -----------------------------------------|----+-----+----+-----|----+ 625 MIP- 320 4.1 Data | M | P | | T,V | Y | 626 Registration-Request | | | | | | 627 MIP- 321 4.2 Data | M | P | | T,V | Y | 628 Registration-Reply | | | | | | 629 MN-FA-Challenge- 322 4.3 Integer32| M | P | | T,V | Y | 630 Length | | | | | | 631 MN-FA-Response 323 4.4 Data | M | P | | T,V | Y | 632 Mobile-Node- 333 4.5 Address | M | P | | T,V | Y | 633 Address | | | | | | 634 Home-Agent- 334 4.6 Address | M | P | | T,V | Y | 635 Address | | | | | | 636 Previous-FA-NAI 335 4.7 String | M | P | | T,V | Y | 637 Foreign-Home- 337 4.8 Integer32| M | P | | T,V | Y | 638 Agent-Available | | | | | | 639 MN-AAA-SPI 336 4.9 Integer32| M | P | | T,V | Y | 641 4.1 MIP-Registration-Request AVP 643 The MIP-Registration-Request AVP (AVP Code 320) is of type data and 644 contains the Mobile IP Registration Request [4] sent by the Mobile 645 Node to the Foreign Agent. 647 4.2 MIP-Registration-Reply AVP 649 The MIP-Registration-Reply AVP (AVP Code 321) is of type data and 650 contains the Mobile IP Registration Reply [4] sent by the Home Agent 651 to the Foreign Agent. 653 4.3 MN-FA-Challenge-Length AVP 655 The MN-FA-Challenge-Length AVP (AVP Code 322) is of type Interger32 656 and contains the number of octets in the MIP-Registration-Request AVP 657 that are to be used by the AAAH as the challenge value used in the 658 computation of the Response (see section 4.4). 660 4.4 MN-FA-Response AVP 662 The MN-FA-Response AVP (AVP Code 323) is of type data and contains 663 the authenticator field of the Mobile Node's challenge response found 664 in the Mobile IP MN-AAA authentication extension [5]. The 665 authenticator is the value computed by the mobile node using the 666 Registration Request and the security association shared with its 667 AAAH. This AVP is used to authenticate the Mobile Node. 669 The data field contains the mobile node's challenge response and is 670 used to authenticate the mobile node. Although any authentication 671 algorithm can be used, all implementations MUST support MD5's 672 prefix+suffix mode, as described in [5], and MAY support the HMAC 673 mode. The challenge value used in the computation is found in the 674 MIP-Registration-Request AVP. The length of the challenge is found in 675 the MN-FA-Challenge-Length AVP. 677 4.5 Mobile-Node-Address AVP 679 The Mobile-Node-Address AVP (AVP Code 333) is of type Address and 680 contains the Mobile Node's Home Address. When this AVP has a NULL 681 Address (0.0.0.0), it is a request that a Home Address be allocated 682 to the Mobile Node. 684 4.6 Home-Agent-Address AVP 686 The Home-Agent-Addess AVP (AVP Code 334) is of type Address and 687 contains the Mobile Node's Home Agent Address. When this AVP has a 688 NULL address (0.0.0.0), it is a request that a Home Agent be 689 allocated to the Mobile Node. If this AVP is set to the NULL address 690 in the AMA message, it is an indication that a Home Agent MUST be 691 allocated in the foreign network. If the address is set to 692 255.255.255.255 in the AMR, it is a request from the Mobile Node that 693 the Home Agent MUST be allocated only within the home network. 695 4.7 Previous-FA-NAI AVP 697 The Previous-FA-NAI AVP (AVP Code 335) is of type String and contains 698 the Network Access Identifier [6] of the Mobile Node's old Foreign 699 Agent. The Mobile Node will include this information in the 700 Registration Request when it moves it point of attachment to a new 701 foreign agent under the same administrative domain as the old FA 702 (identified by the realm portion of the NAI). 704 When this AVP is present in the AA-Mobile-Node-Request, it indicates 705 that the local DIAMETER server overseeing the Foreign Agent should 706 attempt to return the session key that was previously allocated to 707 the old Foreign Agent for the Mobile Node. The session key is 708 identified through the use of the Mobile-Node-Address AVP, which MUST 709 be present if this extension is present. 711 This allows the Mobile Node to move from one Foreign Agent to another 712 within the same administrative domain without having to send the 713 request back to the Mobile Node's Home DIAMETER Server. 715 4.8 Foreign-Home-Agent-Available AVP 717 The Foreign-Home-Agent-Available AVP (AVP Code 337) is of type 718 Integer32 and is added with a value of one by the AAAF owned by the 719 same administrative domain as the Foreign Agent if it is willing and 720 able to allocate a Home Agent within the Foreign network for the 721 Mobile Node. 723 If this extension is present in the AMR and the Home-Agent-Address 724 AVP is set to 0.0.0.0, the AAAH MAY allow the AAAF to assign a Home 725 Agent for the Mobile Node. This is done by including the Home-Agent- 726 Address AVP with a value of 0.0.0.0 in the AMR. 728 4.9 MN-AAA-SPI AVP 730 The MN-AAA-SPI AVP (AVP Code 336) is of type Integer32 and is sent in 731 the AA-Mobile-Node-Request by the Foreign Agent, and contains the SPI 732 value found in the Mobile-IP MN-AAA Authentication Extension [5]. The 733 SPI can be used by the AAAH to identify the security context to use 734 in order to authenticate the Mobile Node. When possible, it is 735 recommended that the AAAH makes use of the Mobile Node's NAI to 736 identify the security context, when possible. 738 5.0 Key Distribution Center (KDC) AVPs 740 The Mobile-IP protocol defines a set of security associations shared 741 between the Mobile Node, Foreign Agent and Home Agents. These three 742 security associations (MN-FA, MN-HA and FA-HA), can be dynamically 743 created by the AAAH. This requires that the AAAH create Mobile-IP 744 Session Keys, and that these keys be distributed to the three mobile 745 entities, via the DIAMETER Protocol. The KDC AVPs SHOULD be 746 supported. 748 When Key Distribution Center services are required, the AAAH creates 749 three session keys; the MN-FA, MN-HA and the FA-HA keys. Each of 750 these keys are encrypted two different ways, one for each key 751 recipient. The mobile node and home agent Session Keys are sent to 752 the Home Agent, while the foreign agent's keys are sent to the 753 foreign agent via the AAAF. 755 If strong authentication and confidentiality of the session keys is 756 required, it is recommended that the strong security extension [9] be 757 used. 759 The following table describes the DIAMETER AVPs defined in the Mobie 760 IP extension, their AVP Code values, types, possible flag values and 761 whether the AVP MAY be encrypted. 763 +---------------------+ 764 | AVP Flag rules | 765 |----+-----+----+-----|----+ 766 AVP Section Value | | |SHLD| MUST|MAY | 767 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr| 768 -----------------------------------------|----+-----+----+-----|----+ 769 MN-to-FA-Key 325 5.1 Complex | M | P | | T,V | Y | 770 MN-to-HA-Key 331 5.1 Complex | M | P | | T,V | Y | 771 FA-to-MN-Key 326 5.2 Complex | M | P | | T,V | Y | 772 FA-to-HA-Key 328 5.2 Complex | M | P | | T,V | Y | 773 HA-to-MN-Key 332 5.2 Complex | M | P | | T,V | Y | 774 HA-to-FA-Key 329 5.2 Complex | M | P | | T,V | Y | 775 FA-MN-Preferred- 324 5.3 Integer32| M | P | | T,V | Y | 776 SPI | | | | | | 777 FA-HA-Preferred- 327 5.4 Integer32| M | P | | T,V | Y | 778 SPI | | | | | | 780 5.1 Mobile Node Session Key AVP 782 The session keys AVPs destined for the Mobile Node are of type 783 complex, and are created by the AAAH. There are two Mobile Node 784 Session Key AVPs; the MN-FA Key and the MN-HA Key. 786 The MN-FA-Key AVP (AVP Code 325) contains the data immediately 787 following the Mobile IP extension header of the "Unsolicited MN-FA 788 Key From AAA Subtype", as documented in [15]. 790 The MN-HA-Key AVP (AVP Code 331) contains the data immediately 791 following the Mobile IP extension header of the "Unsolicited MN-HA 792 Key From AAA Subtype", as documented in [15]. 794 The AAA SPI field of the Mobile IP session keys are set to the value 795 the AAAH shares with the Mobile Node. The MN-HA-Key's HA SPI field 796 contains the same value as the one found in the HA-MN-Key AVP. The 797 MN-FA-Key's FA SPI field contains the same value as the one found in 798 the FA-MN-Key AVP. The session key's Lifetime field is set to the 799 same value as the one found in the Session-Timeout AVP. 801 5.2 Mobility Agent Session Key AVPs 803 The session keys AVPs destined for the Foreign and Home Agents are of 804 type complex, and MUST have the AVP length field set to at least 13. 805 The AVP has the following format: 807 0 1 2 3 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 AVP Header 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Peer SPI | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Data ... 815 +-+-+-+-+-+-+-+-+ 817 AVP Code 818 326 for FA-MN Key, destined for Foreign Agent 819 328 for FA-HA Key, destined for Foreign Agent 820 329 for HA-FA Key, destined for Home Agent 821 332 for MN-HA Key, destined for Home Agent 823 Peer SPI 824 A 32-bit opaque value, which the target MUST use to index all 825 the necessary information recovered from the security 826 information after it is decoded. 828 Data 829 The data field contains the key used to create a Mobility 830 Security Association between the mobility nodes. 832 5.3 FA-MN-Preferred-SPI AVP 834 The FA-Preferred-SPI AVP (AVP Code 324) is of type Integer32 and is 835 sent in the AA-Mobile-Node-Request by the Foreign Agent. The AVP 836 contains the SPI that the Foreign Agent would prefer to have assigned 837 by the AAAH in the FA-to-MN-Key AVP. 839 5.4 FA-HA-Preferred-SPI AVP 841 The FA-Preferred-SPI AVP (AVP Code 324) is of type Integer32 and is 842 sent in the AA-Mobile-Node-Request by the Foreign Agent. The AVP 843 contains the SPI that the Foreign Agent would prefer to have assigned 844 by the AAAH in the FA-to-HA-Key AVP. 846 6.0 Interactions with Resource Management 848 The Resource Management extension [31] provides the ability for a 849 DIAMETER node to query a peer for session state information. The 850 document states that service-specific extensions are responsible for 851 specifying what AVPs are to be present in the Resource-Token [31] 852 AVP. 854 In addition to the AVPs listed in [31], the Resource-Token with the 855 Extension-Id AVP set to four (4) MUST include the Mobile-Node-Address 856 and the Home-Agent-Address AVP. 858 7.0 Acknowledgements 860 The authors would like to thank Nenad Trifunovic, Tony Johansson and 861 Pankaj Patel for their participation in the Document Reading Party. 862 The authors would also like to thank the participants of TIA's TR45.6 863 working group for their valuable feedback. 865 8.0 IANA Considerations 867 The command codes defined in Section 2.0 are values taken from the 868 Command-Code [1] address space and extended in [9], [12] and [17]. 869 IANA should record the values as defined in Section 2.0. 871 The Result-Code values defined in Section 3.0 are error codes as 872 defined in [1] and extended in [9], [12] and [17]. They correspond to 873 error values specific to the Mobile IP extension. IANA should record 874 the values as defined in Section 3.0. 876 The AVPs defined in sections 4.0 and 5.0 were alllocated from from 877 the AVP numbering space defined in [1], and extended in [9], [12] and 878 [17]. IANA should record the values as defined in Sections 4.0 and 879 5.0. 881 9.0 Security Considerations 883 This specification describes the DIAMETER extension necessary to 884 authenticate and authorize a Mobile IP Mobile Node. The 885 authentication algorithm used is dependent upon the transforms 886 available by the Mobile IP protocol, and [5]. This specification also 887 defines a method by which the home DIAMETER server can create and 888 distribute short-lived session keys to be used to authenticate Mobile 889 IP registration messages. The keys are distributed in an encrypted 890 format through the DIAMETER protocol, and SHOULD be encrypted using 891 the methods defined in [9]. 893 10.0 References 895 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "DIAMETER Base 896 Protocol", draft-calhoun-diameter-16.txt, IETF work in progress, 897 July 2000. 899 [2] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft-calhoun- 900 diameter-framework-08.txt, IETF work in progress, June 2000. 902 [3] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 903 Authorization, and Accounting Requirements", draft-ietf- 904 mobileip-aaa-reqs-03.txt, IETF work in progress, March 2000. 906 [4] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. 908 [5] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Exten- 909 sions", draft-ietf-mobileip-challenge-12.txt, IETF work in pro- 910 gress, June 2000. 912 [6] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486. 913 January 1999. 915 [7] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 916 RFC 2477, January 1999. 918 [8] P. Calhoun, C. Perkins, "Mobile IP Network Address Identifier 919 Extension", RFC 2794, March 2000. 921 [9] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 922 Extensions", draft-calhoun-diameter-strong-crypto-04.txt, IETF 923 work in progress, July 2000. 925 [10] Kent, Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 926 2406, November 1998. 928 [11] S. Bradner, "Key words for use in RFCs to Indicate Requirement 929 Levels", BCP 14, RFC 2119, March 1997. 931 [12] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "DIAMETER Accounting 932 Extension", draft-calhoun-diameter-accounting-07.txt, IETF work 933 in progress, July 2000. 935 [13] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing 936 for Message Authentication. RFC 2104, February 1997. 938 [14] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 939 1996. 941 [15] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", 942 draft-calhoun-mobileip-aaa-key-01.txt, IETF work in progress, 943 January 2000. 945 [16] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", 946 draft-hiller-cdma2000-aaa-01.txt, IETF work in progress, June 947 2000. 949 [17] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ 950 Extension", draft-calhoun-diameter-nasreq-04.txt, IETF work in 951 progress, July 2000. 953 11.0 Authors' Addresses 955 Questions about this memo can be directed to: 957 Pat R. Calhoun 958 Network and Security Research Center, Sun Labs 959 Sun Microsystems, Inc. 960 15 Network Circle 961 Menlo Park, California, 94025 962 USA 964 Phone: +1 650-786-7733 965 Fax: +1 650-786-6445 966 E-mail: pcalhoun@eng.sun.com 968 Charles E. Perkins 969 Nokia Research Center 970 313 Fairchild Drive 971 Mountain View, California 94043 972 USA 974 Phone: +1 650-625-2986 975 Fax: +1 650-691-2170 976 E-Mail: charliep@iprg.nokia.com 978 12.0 Full Copyright Statement 979 Copyright (C) The Internet Society (1999). All Rights Reserved. 981 This document and translations of it may be copied and furnished to 982 others, and derivative works that comment on or otherwise explain it 983 or assist in its implementation may be prepared, copied, published 984 and distributed, in whole or in part, without restriction of any 985 kind, provided that the above copyright notice and this paragraph are 986 included on all such copies and derivative works. However, this docu- 987 ment itself may not be modified in any way, such as by removing the 988 copyright notice or references to the Internet Society or other 989 Internet organizations, except as needed for the purpose of develop- 990 ing Internet standards in which case the procedures for copyrights 991 defined in the Internet Standards process must be followed, or as 992 required to translate it into languages other than English. The lim- 993 ited permissions granted above are perpetual and will not be revoked 994 by the Internet Society or its successors or assigns. This document 995 and the information contained herein is provided on an "AS IS" basis 996 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 997 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 998 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 999 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1000 FITNESS FOR A PARTICULAR PURPOSE.