idnits 2.17.1 draft-calhoun-diameter-mobileip-12.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 31 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 32 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 16 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.) -- The document date (February 2001) is 8470 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 1309, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1334, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1344, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 2977 (ref. '3') ** Obsolete normative reference: RFC 2002 (ref. '4') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 3012 (ref. '5') (Obsoleted by RFC 4721) ** 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-06 -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 2406 (ref. '10') (Obsoleted by RFC 4303, RFC 4305) -- Possible downref: Normative reference to a draft: ref. '12' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '13') -- Possible downref: Normative reference to a draft: ref. '14' -- 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') -- Possible downref: Normative reference to a draft: ref. '17' == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-06 -- Possible downref: Normative reference to a draft: ref. '18' Summary: 14 errors (**), 0 flaws (~~), 10 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group Pat R. Calhoun 3 Internet-Draft Sun Laboratories, Inc. 4 Category: Standards Track Charles E. Perkins 5 Nokia Research Center 6 February 2001 8 Diameter Mobile IP Extensions 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at: 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at: 29 http://www.ietf.org/shadow.html. 31 This document is an individual contribution for consideration by the 32 AAA Working Group of the Internet Engineering Task Force. Comments 33 should be submitted to the mobileip@nortelnetworks.com mailing list. 35 Distribution of this memo is unlimited. 37 Copyright (C) The Internet Society 1999. All Rights Reserved. 39 Abstract 41 This document specifies an extension to the Diameter base protocol 42 that allows a Diameter server to authenticate, authorize and collect 43 accounting information for services rendered to a mobile node. 44 Combined with the Inter-Domain capability of the base protocol, this 45 extension allows mobile nodes to receive service from foreign service 46 providers. The Diameter Accounting extension will be used by the 47 Foreign and Home agents to transfer usage information to the Diameter 48 servers. 50 Table of Contents 52 1.0 Introduction 53 1.1 Requirements language 54 1.2 Inter-Domain Mobile IP 55 1.3 Allocation of Home Agent in Foreign Network 56 1.4 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 2.5 Home-Agent-Allocated-Ind (HAI) Command 63 3.0 Result-Code AVP Values 64 3.1 Hop-by-Hop Failures 65 4.0 Diameter AVPs 66 4.1 MIP-Reg-Request AVP 67 4.2 MIP-Reg-Reply AVP 68 4.3 MIP-Mobile-Node-Address AVP 69 4.4 MIP-Home-Agent-Address AVP 70 4.5 MIP-Previous-FA-NAI AVP 71 4.6 MIP-Previous-FA-Addr AVP 72 4.7 MIP-Feature-Vector AVP 73 4.8 MIP-MN-AAA-Auth AVP 74 4.8.1 MIP-MN-AAA-SPI AVP 75 4.8.2 MIP-Auth-Input-Data-Length AVP 76 4.8.3 MIP-Authenticator-Length AVP 77 4.8.4 MIP-Authenticator-Offset AVP 78 5.0 Key Distribution Center 79 5.1 Distributing the Mobile-Home Registration Key 80 5.2 Distributing the Mobile-Foreign Registration Key 81 5.3 Distributing the Foreign-Home Registration Key 82 5.4 Key Distribution Example 83 6.0 Key Distribution Center (KDC) AVPs 84 6.1 Mobile Node Session Keys 85 6.1.1 MIP-MN-to-FA-Key AVP 86 6.1.2 MIP-MN-to-HA-Key AVP 87 6.2 Mobility Agent Session Keys 88 6.2.1 MIP-FA-to-MN-Key AVP 89 6.2.2 MIP-FA-to-HA-Key AVP 90 6.2.3 MIP-HA-to-FA-Key AVP 91 6.2.4 MIP-HA-to-MN-Key AVP 92 6.2.5 MIP-Peer-SPI AVP 93 6.2.6 MIP-Session-Key AVP 94 6.3 FA-MN-Preferred-SPI AVP 95 6.4 FA-HA-Preferred-SPI AVP 96 7.0 Accounting Considerations 97 8.0 Interactions with Resource Management 98 9.0 Acknowledgements 99 10.0 IANA Considerations 100 11.0 Security Considerations 101 12.0 References 102 13.0 Authors' Addresses 103 14.0 Full Copyright Statement 105 1.0 Introduction 107 Mobile IP, as defined in [4], defines a method that allows a Mobile 108 Node to change its point of attachment to the Internet with minimal 109 service disruption. Mobile IP does not provide any specific support 110 for mobility across disparate administrative domains, and therefore 111 does not specify how usage can be accounted for, which has limited 112 the applicability of Mobile IP in a IPv4 commercial deployment. The 113 Mobile IP protocol [4] requires that mobile nodes have static home 114 agent and home addresses, which is not desirable in a commercial 115 network. Recent specification [8] allows a mobile node to use its 116 NAI instead of its home address, which better accommodates current 117 administrative practice. 119 This document specifies Extension 4 to the Diameter base protocol [1] 120 that allows a Diameter server to authenticate, authorize and collect 121 accounting information for services rendered to a mobile node. 122 Diameter nodes conforming to this specification MUST include an 123 Extension-Id AVP with a value of four in the Device-Reboot-Ind 124 Command [1]. Combined with the Inter-Domain capability of the base 125 protocol, this extension allows mobile nodes to receive service from 126 foreign service providers. The Diameter Accounting extension [12] 127 will be used by the Foreign and Home agents to transfer usage 128 information to the Diameter servers. 130 The Mobile IP protocol [4] specifies a security model that requires 131 that mobile nodes and home agents share a pre-existing security 132 association, which leads to scaling and configuration issues. This 133 specification defines Diameter functions that allow the AAA server to 134 act as a Key Distribution Center (KDC), whereby dynamic registration 135 keys are created and distributed to the mobility entities for the 136 purposes of securing Mobile IP Registration messages. 138 As with the Diameter base protocol, AAA servers implementing the 139 Mobile IP extension can process users' identities supplied in a 140 Network Access Identifier (NAI) format [6], which is used for 141 Diameter message routing purposes. Mobile nodes include their NAI in 142 Registration messages, as defined in [8]. The use of the NAI is 143 consistent with the roaming model defined by the ROAMOPS Working 144 Group [7]. 146 The Diameter Mobile-IP Extension meets the requirements specified in 147 [3, 16]. Later subsections in this introductory section provide some 148 examples and message flows of the Mobile IP and Diameter messages 149 that occur when a Mobile Node requests service in a foreign network. 150 In this document, the role of the "attendant" [3] is performed by the 151 foreign agent for the Mobile-IP Extension, and these terms will be 152 used interchangeably. 154 1.1 Requirements language 156 In this document, the key words "MAY", "MUST", "MUST NOT", 157 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 158 interpreted as described in [11]. 160 1.2 Inter-Domain Mobile IP 162 When a Mobile Node node requests service by issuing a Registration 163 Request to the foreign agent, the foreign agent creates the AA- 164 Mobile-Node-Request (AMR) message, which includes the AVPs defined in 165 section 2.1. The Home Address, Home Agent, Mobile Node NAI and other 166 important fields are extracted from the registration messages for 167 possible inclusion as Diameter AVPs. The AMR message is then 168 forwarded to the local Diameter server, known as the AAA-Foreign, or 169 AAAF. 171 Visited Domain Home Domain 172 +--------+ +--------+ 173 |abc.com | AMR/AMA |xyz.com | 174 | AAAF |<------------------->| AAAH | 175 +->| server | server-server | server | 176 | +--------+ communication +--------+ 177 | ^ ^ 178 | AMR/AMA | client-server | HAR/HAA 179 | | communication | 180 v v v 181 +---------+ +---------+ +---------+ 182 | Foreign | | Foreign | | Home | 183 | Agent | | Agent | | Agent | 184 +---------+ +---------+ +---------+ 185 ^ 186 | Mobile IP 187 | 188 v 189 +--------+ 190 | Mobile | 191 | Node | mn@xyz.com 192 +--------+ 193 Figure 1: Inter-Domain Mobility 195 Upon receiving the AMR, the AAAF follows the procedures outlined in 196 [1] to determine whether the AMR should be processed locally, or if 197 it should be forwarded to another Diameter Server, known as the AAA- 198 Home, or AAAH. Figure 1 shows an example in which a mobile node 199 (mn@xyz.com) requests service from a foreign provider (abc.com). The 200 request received by the AAAF is forwarded to abc.com's AAAH server. 202 Figure 2 shows the message flows involved when the attendant (foreign 203 agent) invokes the AAA infrastructure to request that a mobile node 204 be authenticated and authorized. Note that it is not required that 205 the foreign agent invoke AAA services every time a Registration 206 Request is received from the mobile, but rather only when the prior 207 authorization from the AAAH expires. The expiration time of the 208 authorization (and registration keys, if allocated by the AAA server) 209 is communicated through the Authorization-Lifetime AVP in the AA- 210 Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. 212 Mobile Node Foreign Agent AAAF AAAH Home Agent 213 ----------- ------------- ------------ ---------- ---------- 214 Advertisement & 215 <--------- Challenge 216 Reg-Req&MN-AAA ----> 217 AMR-------------> 218 AMR------------> 219 HAR-----------> 220 <----------HAA 221 <-----------AMA 222 <------------AMA 223 <-------Reg-Reply 225 Figure 2: Mobile IP/Diameter Message Exchange 227 The foreign agent (as shown in Figure 2) MAY provide a challenge, 228 which gives it direct control over the replay protection in the 229 Mobile IP registration process, as described in [5]. The mobile node 230 includes the Challenge and MN-AAA authentication extension to enable 231 authorization by AAAH. If the authentication data supplied in the 232 MN-AAA extension is invalid, AAAH returns the response (AMA) with the 233 Result-Code AVP set to DIAMETER_ERROR_AUTH_FAILURE (see section 3.0). 235 If the Mobile Node was successfully authenticated, the AAAH checks 236 for the MIP-Home-Agent-Address AVP. If one was specified, the AAAH 237 checks that the address is that of a known Home Agent, and one that 238 the Mobile Node is allowed to request. If no Home Agent was 239 specified, and if the MIP-Feature-Vector has the Home-Agent-Requested 240 flag set, and if allowed by policy in the home domain, the AAAH 241 SHOULD allocate a home agent on behalf of the Mobile Node. This can 242 be done in a variety of ways, including using a load balancing 243 algorithm in order to keep the load on all home agents equal. The 244 actual algorithm used and the method of discovering the home agents 245 is outside the scope of this specification. 247 If AAAH does not know the address of the home agent (perhaps because 248 it will be allocated by AAAF within the visited domain as described 249 in section 1.3), then AAAH sends an AMA message back to AAAF which 250 does not contain a MIP-Reg-Reply AVP. 252 Otherwise, if the home agent address is known, the AAAH then sends a 253 Home-Agent-MIP-Request (HAR), which contains the Mobile IP 254 Registration Request message data encapsulated in the MIP-Reg-Request 255 AVP, to the assigned or requested Home Agent. The AAAH MAY allocate a 256 home address for the mobile node, and include it in a MIP-Mobile- 257 Node-Address AVP within the HAR, or else leave this allocation 258 responsibility for the Home Agent. 260 Upon receipt of the HAR, the Home Agent first processes the Diameter 261 message. If the HAR is invalid, a HAA is returned with the Result- 262 Code AVP set to DIAMETER_ERROR_BAD_HAR (see section 3.0). Otherwise, 263 the Home Agent processes the MIP-Reg-Req AVP and creates the 264 Registration Reply, encapsulating it within the MIP-Reg-Reply AVP. 265 If a home address is needed, the Home Agent MUST assign one and 266 include the address in both the Registration Reply and within the 267 MIP-Mobile-Node-Address AVP. The Diameter response is then forwarded 268 to the AAAH. 270 Upon receipt of the HAA, the AAAH sets the Command-Code field to AA- 271 Mobile-Node-Answer (AMA) and forwards the message to the AAAF. The 272 AAAH includes the MIP-Home-Agent-Address and MIP-Mobile-Node-Address 273 AVPs in the AMA message, enabling appropriate firewall controls for 274 the penetration of tunneled traffic between the Home Agent and the 275 Mobile Node. 277 The AAAF is responsible for ensuring that the AMA message is properly 278 forwarded to the correct foreign agent. 280 1.3 Allocation of Home Agent in Foreign Network 282 The Diameter Mobile IP extension allows a Home Agent to be allocated 283 in a foreign network, as required in [3, 16]. When a foreign agent 284 detects that the mobile node has a home agent address equal to 285 0.0.0.0 or 255.255.255.255 in the Registration Request message, it 286 MUST add a MIP-Feature-Vector AVP with the Home-Agent-Requested flag 287 set to one. If the home agent address is equal to 255.255.255.255, 288 then the foreign agent also MUST set the Home-Address-Allocatable- 289 Only-in-Home-Domain flag equal to one. 291 When the AAAF receives a AMR message with the Home-Agent-Requested 292 flag set to one, and the Home-Address-Allocatable-Only-in-Home-Domain 293 flag equal to zero, AAAF MAY set the Foreign-Home-Agent-Available 294 flag in the MIP-Feature-Vector AVP to inform the AAAH that it is 295 willing and able to assign a Home Agent for the Mobile Node. 297 In the event that the mobile node requests a home agent in the 298 foreign network, and the AAAF authorizes its use, the AAAF MUST set 299 the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. 300 This could happen when the AAA request is sent to "extend" a mobile 301 node's current session. 303 When the AAAH receives a AMR message, it first checks the 304 authentication data supplied by the mobile node, according to the 305 MIP-Reg-Req AVP and MIP-MN-AAA-Auth AVP, and determines whether to 306 authorize the mobile node. If the AMR indicates that the AAAF has 307 offered to allocate a home agent for the mobile node, then the AAAH 308 must decide whether its local policy would allow the user to have a 309 Home Agent in the foreign network. If so, and after checking 310 authorization from the data in the AMR message, the AAAH sends the 311 AMA message to the AAAF that does not contain the MIP-Home-Agent- 312 Address. 314 Visited Domain Home Domain 315 +--------+ +--------+ 316 | | AMR/AMA | | 317 | AAAF |<------------------>| AAAH | 318 +--->| server | server-server | server | 319 | +--------+ communication +--------+ 320 | ^ 321 | | 322 HAR/HAA | AMR/AMA | client-server 323 v v communication 324 +---------+ +---------+ 325 | Home | | Foreign | 326 | Agent | | Agent | 327 +---------+ +---------+ 328 ^ 329 +--------+ | 330 | Mobile |<----------+ 331 | Node | Mobile IP 332 +--------+ 333 Figure 3: Home Agent allocated in Visited Domain 335 Upon receipt of a HAA from the Home Agent in the Visited Domain, with 336 the Result-Code AVP indicating success, the AAAF MUST issue a HAI 337 message to the AAAH. The HAI message MUST include the MIP-Home- 338 Agent-Address and the MIP-Mobile-Node-Address AVPs. 340 Mobile Node Foreign Agent Home Agent AAAF AAAH 341 ----------- ------------- ------------- ---------- ---------- 343 <----Challenge---- 344 Reg-Req (Response)-> 345 ------------AMR-------------> 346 -----AMR----> 347 <----AMA----- 348 <-----HAR------ 349 ------HAA------> 350 <-------------AMA------------AMA 351 ---HAI------> 352 <---Reg-Reply---- 353 Figure 4: Mobile IP/Diameter Message Exchange 355 If the Mobile Node moves to another Foreign Network, it MAY either 356 request to keep the same Home Agent within the old foreign network, 357 or request to get a new one in the new foreign network. If the AAAH 358 is willing to provide the requested service, the mobile node will 359 have to interact with two AAAFs. 361 Figure 5 shows the message flows for a Mobile Node requesting to keep 362 the Home Agent assigned in Foreign network 1 when it moves to foreign 363 network 2. Upon reception of the AMR in Foreign network 2, the AAAF 364 follows the procedures described earlier and forwards AMR to the 365 Mobile Node's home network, i.e. its AAAH. If the Mobile Node was 366 successfully authenticated the AAAH checks for the MIP-Home-Agent- 367 Address and the MIP-Previous-FA-NAI AVPs. If a Home Agent was 368 specified, and it belongs to a different domain than the Foreign 369 Agent in the MIP-Previous-FA-NAI AVP, the AAAH MUST verify whether it 370 will permit this type of the service to the Mobile Node. 372 +---------------+ +---------------+ +-------------+ 373 |Foreign net 2 | |Foreign net 1 | |Home network | 374 | | | | | | 375 Mobile Node | FA AAAF | | HA AAAF | | AAAH | 376 ----------- | ---- ---- | | ---- ------ | | ------ | 377 +---------------+ +---------------+ +-------------+ 379 <----Challenge---- 380 Reg-Req (Response)-> 381 ---AMR---> 382 ----------------AMR---------------> 383 <-----HAR----- 384 <--HAR--- 385 --HAR--> 386 ------HAA----> 387 <--------------AMA---------------- 388 <--AMA---- 389 <-Reg-Reply-- 390 Figure 5: Request to access Home Agent from new Foreign Network 392 If the Mobile Node is allowed to keep the Home Agent the AAAH then 393 sends a HAR, which contains the Mobile IP Registration Request 394 message data encapsulated in the MIP-Reg-Request AVP and the MIP- 395 Home-Agent-Address AVP with Home Agent address, the optional KDC 396 session keys to the AAAF in foreign network 1. Upon reception the 397 AAAF in foreign network 1 will forward the HAR to the Home Agent if 398 its local policy allows such service. If the AAAF does not permit 399 such service, it MUST return a DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. 401 When the AAAF receives a successful HAA, the AAAF will forward the 402 HAA back to the AAAH. The HAA MUST include the MIP-Home-Agent-Address 403 and the MIP-Mobile-Node-Address AVPs. The AAAH will then send back an 404 AMA to the AAAF in foreign network 2. 406 If the old Foreign Network does not permit the use of its Home Agent 407 when the Mobile Node moves to a new foreign network, the Mobile Node 408 MAY allocate a new Home Agent in its current network, as described 409 above. However, when the AAAH receives such a request, it MUST send a 410 Diameter Session-Termination-Indication message to the old AAAF, 411 which will enable the old foreign network to release any resources, 412 and will cause any necessary accounting messages. 414 [ed: Charlie would prefer that the AMA be sent directly from foreign 415 net 1 to foreign net 2. This would optimize the signaling, and would 416 reduce latency involved in the handoff. More work needed here] 418 1.4 Diameter Session Termination 420 A Foreign and Home Agent following this specification MAY expect 421 their respective Diameter servers to maintain session state 422 information for each mobile node in their networks. In order for the 423 Diameter Server to release any resources allocated to a specific 424 mobile node, the mobility agents MUST send a Session-Termination- 425 Request (STR) [1] to their respective Diameter servers. 427 The Home Diameter server SHOULD only deallocate all resources after 428 the STR is received from the Home Agent. This ensures that a Mobile 429 Node that moves from one Foreign Agent to another (hand-off) does not 430 cause the Home Diameter Server to free all resources for the Mobile 431 Node. The Diameter Server is free to initiate the session termination 432 at any time by issuing the Session-Termination-Ind (STI) [1]. 434 2.0 Command-Code Values 436 This section defines Command-Code [1] values that MUST be supported 437 by all Diameter implementations conforming to this specification. 438 The following Command Codes are defined in this specification: 440 Command-Name Abbreviation Code Section 441 ----------------------------------------------------------- 442 AA-Mobile-Node-Answer AMA 261 2.2 443 AA-Mobile-Node-Request AMR 260 2.1 444 Home-Agent-Allocated-Ind HAI 279 2.5 445 Home-Agent-MIP-Answer HAA 263 2.4 446 Home-Agent-MIP-Request HAR 262 2.3 448 2.1 AA-Mobile-Node-Request (AMR) Command 450 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field 451 set to 260, is sent by an attendant, acting as a Diameter client, to 452 a server in order to request the authentication and authorization of 453 a Mobile Node. The Foreign Agent uses information found in the 454 Registration Request to construct the following AVPs that are to be 455 included as part of the AMR: 457 home address (MIP-Mobile-Node-Address AVP), 458 home agent address (MIP-Home-Agent-Address AVP), 459 mobile node NAI (User-Name AVP [1]). 461 If the mobile node's home address is zero, the foreign agent MUST NOT 462 include a MIP-Mobile-Node-Address AVP in the AMR. In this case, the 463 AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP- 464 Feature-Vector AVP in the AMR message to indicate that it is willing 465 to assign a Home Agent in the visited domain. 467 If the MIP-Previous-FA-NAI AVP is found in the request, the Diameter 468 client requests that the server return the registration key that was 469 assigned to the previous Foreign Agent for use with the Mobile Node 470 and Home Agent. The registration key is identified through the use of 471 the MIP-Mobile-Node-Address AVP. 473 Message Format 475 ::= < Diameter Header: 260 > 476 { Session-ID } 477 { User-Name } 478 { Host-Name } 479 { Authorization-Lifetime } 480 { MIP-Reg-Request } 481 { MIP-MN-AAA-Auth } 482 [ MIP-Mobile-Node-Address ] 483 [ MIP-Home-Agent-Address ] 484 [ MIP-Feature-Vector ] 485 [ MIP-FA-MN-Preferred-SPI ] 486 [ MIP-FA-HA-Preferred-SPI ] 487 [ MIP-Previous-FA-NAI ] 488 [ MIP-Previous-FA-Addr ] 489 * [ AVP ] 490 * [ Proxy-State ] 491 * [ Route-Record ] 492 * [ Routing-Realm ] 493 0*1< Integrity-Check-Value > 495 2.2 AA-Mobile-Node-Answer (AMA) Command 497 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field 498 set to 261, is sent by the AAAH in response to the AA-Mobile-Node- 499 Request message. The Result-Code AVP MAY contain one of the values 500 defined in section 3.0, in addition to the values defined in [1]. If 501 the home agent is situated in the home domain, a successful response 502 MUST include the MIP-Reg-Reply AVP. 504 The MIP-Home-Agent-Address AVP contains the Home Agent assigned to 505 the Mobile Node, while the MIP-Mobile-Node-Address AVP contains the 506 home address that was assigned. 508 The AMA message MUST contain the MIP-FA-to-HA-Key, MIP-FA-to-MN-Key 509 and MIP-Reg-Reply AVPs if they were received by AAAH in the HAA 510 message. 512 Message Format 514 ::= < Diameter Header: 261 > 515 { Session-Id } 516 { Session-Timeout } 517 { Authorization-Lifetime } 518 { Result-Code } 519 [ Host-Name ] 520 [ MIP-Reg-Reply ] 521 [ MIP-MN-to-HA-Key ] 522 [ MIP-FA-to-MN-Key ] 523 [ MIP-FA-to-HA-Key ] 524 [ MIP-Home-Agent-Address ] 525 [ MIP-Mobile-Node-Address ] 526 * [ AVP ] 527 * [ Proxy-State ] 528 * [ Route-Record ] 529 * [ Routing-Realm ] 530 0*1< Integrity-Check-Value > 532 2.3 Home-Agent-MIP-Request (HAR) Command 534 The Home-Agent-MIP-Request (HAR), indicated by the Command-Code field 535 set to 262, is sent by the AAA to the Home Agent. If the Home Agent 536 is to be assigned in a foreign network, the HAR is issued by AAAF. 537 If the HAR message does not include a MIP-Mobile-Node-Address AVP, 538 and the Registration Request has 0.0.0.0 for the home address, and 539 the HAR is successfully processed, the Home Agent MUST allocate one 540 such address to the mobile node. If the home agent's local AAA server 541 allocates the mobile node's home address, it MUST include the 542 assigned address in an MIP-Mobile-Node-Address AVP. 544 If a AAAF receives a HAR that does not include the MIP-Reg-Reply AVP, 545 then a Home Agent MUST be assigned in the foreign network. 547 When registration keys are requested for use by the mobile node (see 548 section 5.0), the AAAH MUST create them and include them in the HAR 549 message. When a Foreign-Home registration key is requested, it will 550 be created and distributed by the AAA server in the same domain as 551 the home agent. 553 Message Format 555 ::= < Diameter Header: 262 > 556 { Session-Id } 557 { Session-Timeout } 558 { Authorization-Lifetime } 559 { MIP-Reg-Request } 560 { Host-Name } 561 { User-Name } 562 [ MIP-MN-to-HA-Key ] 563 [ MIP-MN-to-FA-Key ] 564 [ MIP-HA-to-MN-Key ] 565 [ MIP-HA-to-FA-Key ] 566 [ MIP-Mobile-Node-Address ] 567 * [ AVP ] 568 * [ Proxy-State ] 569 * [ Route-Record ] 570 * [ Routing-Realm ] 571 0*1< Integrity-Check-Value > 573 2.4 Home-Agent-MIP-Answer (HAA) Command 575 The Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field 576 set to 263, is sent by the Home Agent to its local AAA server in 577 response to a Home-Agent-MIP-Request. If the home agent allocated a 578 home address for the Mobile Node, the address MUST be included in the 579 MIP-Mobile-Node-Address AVP. The Result-Code AVP MAY contain one of 580 the values defined in section 3.0 instead of the values defined in 581 [1]. 583 Message Format 585 ::= < Diameter Header: 263 > 586 { Session-Id } 587 { Session-Timeout } 588 { Authorization-Lifetime } 589 { Result-Code } 590 [ MIP-Home-Agent-Address ] 591 [ MIP-Mobile-Node-Address ] 592 * [ AVP ] 593 * [ Proxy-State ] 594 * [ Route-Record ] 595 * [ Routing-Realm ] 596 0*1< Integrity-Check-Value > 598 2.5 Home-Agent-Allocated-Ind (HAI) Command 600 The Home-Agent-Allocated-Ind (HAI), indicated by the Command-Code 601 field set to 279, is sent by the AAAF to the AAAH upon receipt of a 602 successful HAA when the Home Agent was assigned in the visited 603 network. The HAI MUST include the MIP-Home-Agent-Address and MIP- 604 Mobile-Node-Address AVPs. 606 Message Format 608 ::= < Diameter Header: 279 > 609 { Session-Id } 610 { Session-Timeout } 611 { Authorization-Lifetime } 612 [ MIP-Home-Agent-Address ] 613 [ MIP-Mobile-Node-Address ] 614 * [ AVP ] 615 * [ Proxy-State ] 616 * [ Route-Record ] 617 * [ Routing-Realm ] 618 0*1< Integrity-Check-Value > 620 3.0 Result-Code AVP Values 622 This section defines new Result-Code [1] values that MUST be 623 supported by all Diameter implementations that conform to this 624 specification. 626 3.1 Hop-by-Hop Failures 627 Proxies receiving messages with the Result-Code AVP set to an error 628 within the Hop-by-Hop failure category SHOULD attempt to take some 629 local action to correct the error. If no local action can be taken to 630 correct the problem, the error MUST be forwarded towards the 631 originator of the message. 633 DIAMETER_ERROR_BAD_KEY 6009 634 This error code is used by the Home Agent to indicate to the 635 local Diameter server that the key generated is invalid. 637 DIAMETER_ERROR_BAD_HOME_ADDRESS 6010 638 This error code is used by the Home Agent to indicate that the 639 Home Address chosen by the Mobile Node or assigned by the local 640 Diameter server is unavailable. 642 DIAMETER_ERROR_AUTH_FAILURE 6011 643 This error code is used by AAAH to inform AAAF that the 644 authentication data in the MN-AAA authentication extension is 645 invalid. 647 DIAMETER_ERROR_MIP_REPLY_FAILURE 6012 648 This error code is used by the Home Agent when processing of 649 the Registration Request has failed. 651 DIAMETER_ERROR_BAD_HAR-day 6013 652 This error code is used by HA to inform the AAA server that the 653 Home-Agent-Request (HAR) message could not be processed 654 correctly. 656 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 6014 657 This error is used by the AAAF to inform the AAAH that 658 allocation of a Home Agent in the Foreign Agent is not 659 permitted at this time. 661 4.0 Mandatory AVPs 663 The following table describes the Diameter AVPs defined in the Mobile 664 IP extension, their AVP Code values, types, possible flag values and 665 whether the AVP MAY be encrypted. 667 +---------------------+ 668 | AVP Flag rules | 669 |----+-----+----+-----|----+ 670 AVP Section | | |SHLD| MUST|MAY | 671 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 672 -----------------------------------------|----+-----+----+-----|----| 673 MIP-Auth-Input- 338 4.8.2 Unsigned32 | M | P | | V | Y | 674 Data-Length | | | | | | 675 MIP- 339 4.8.3 Unsigned32 | M | P | | V | Y | 676 Authenticator-Length | | | | | | 677 MIP- 340 4.8.4 Unsigned32 | M | P | | V | Y | 678 Authenticator-Offset | | | | | | 679 MIP-Feature- 337 4.7 Unsigned32 | M | P | | V | Y | 680 Vector | | | | | | 681 MIP-Home-Agent- 334 4.4 Address | M | P | | V | Y | 682 Address | | | | | | 683 MIP-MN-AAA-Auth 322 4.8 Grouped | M | P | | V | Y | 684 MIP-MN-AAA-SPI 341 4.8.1 Unsigned32 | M | P | | V | Y | 685 MIP-Mobile-Node- 333 4.3 Address | M | P | | V | Y | 686 Address | | | | | | 687 MIP-Previous-FA- 336 4.6 Address | M | P | | V | Y | 688 Addr | | | | | | 689 MIP-Previous-FA- 335 4.5 OctetString| M | P | | V | Y | 690 NAI | | | | | | 691 MIP-Reg-Request 320 4.1 OctetString| M | P | | V | Y | 692 MIP-Reg-Reply 321 4.2 OctetString| M | P | | V | Y | 694 4.1 MIP-Reg-Request AVP 696 The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and 697 contains the Mobile IP Registration Request [4] sent by the Mobile 698 Node to the Foreign Agent. 700 4.2 MIP-Reg-Reply AVP 702 The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and 703 contains the Mobile IP Registration Reply [4] sent by the Home Agent 704 to the Foreign Agent. 706 4.3 MIP-Mobile-Node-Address AVP 708 The Mobile-Node-Address AVP (AVP Code 333) is of type Address and 709 contains the Mobile Node's Home Address. 711 4.4 MIP-Home-Agent-Address AVP 713 The Home-Agent-Addess AVP (AVP Code 334) is of type Address and 714 contains the Mobile Node's Home Agent Address. 716 4.5 MIP-Previous-FA-NAI AVP 718 The MIP-Previous-FA-NAI AVP (AVP Code 335) is of type OctetString and 719 contains the Network Access Identifier [6] of the Mobile Node's old 720 Foreign Agent. The Mobile Node MAY include this information in the 721 Registration Request when it moves its point of attachment to a new 722 foreign agent under the same administrative domain as the old FA 723 (identified by the realm portion of the NAI). 725 When this AVP is present in the AA-Mobile-Node-Request, it indicates 726 that the local Diameter server overseeing the Foreign Agent should 727 attempt to return the registration key that was previously allocated 728 to the old Foreign Agent for the Mobile Node. The registration key is 729 identified through the use of the MIP-Mobile-Node-Address AVP, which 730 MUST be present if this extension is present. 732 In many circumstances, this allows the Mobile Node to move from one 733 Foreign Agent to another within the same administrative domain 734 without having to send the request back to the Mobile Node's Home 735 Diameter Server (AAAH). 737 4.6 MIP-Previous-FA-Addr AVP 739 The MIP-Previous-FA-Addr AVP (AVP Code 336) is of type Address and 740 contains the IP Address of the Mobile Node's old Foreign Agent. The 741 Mobile Node MAY include this information in the Previous Foreign 742 Agent Notification Extension to the Mobile IP Registration Request 743 when it moves its point of attachment to a new foreign agent. 745 When this AVP is present in the AA-Mobile-Node-Request, it indicates 746 that the local Diameter server overseeing the Foreign Agent should 747 attempt to return the registration key that was previously allocated 748 to the old Foreign Agent for the Mobile Node. The registration key is 749 identified through the use of the MIP-Mobile-Node-Address AVP, which 750 MUST be present if this extension is present. 752 In many circumstances, this allows the Mobile Node to move from one 753 Foreign Agent to another within the same administrative domain 754 without having to send the request back to the Mobile Node's Home 755 Diameter Server (AAAH). 757 4.7 MIP-Feature-Vector AVP 759 The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and 760 is added with flag values set by the Foreign Agent or by the AAAF 761 owned by the same administrative domain as the Foreign Agent. The 762 Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR 763 message it sends to the AAAF. 765 Flag values currently defined include: 766 1 Mobile-Node-Home-Address-Requested 767 2 Home-Address-Allocatable-Only-in-Home-Domain 768 4 Home-Agent-Requested 769 8 Foreign-Home-Agent-Available 770 16 MN-HA-Key-Request 771 32 MN-FA-Key-Request 772 64 FA-HA-Key-Request 773 128 Home-Agent-In-Foreign-Network 775 The flags are set according to the following rules. 777 If the mobile node includes a valid home address (i.e., not equal to 778 0.0.0.0 or 255.255.255.255) in its Registration Request, the Foreign 779 Agent zeroes the Mobile-Node-Home-Address-Requested flag in the MIP- 780 Feature-Vector AVP. 782 If the mobile node sets the home address field equal to 0.0.0.0 in 783 its Registration Request, the Foreign Agent sets the Mobile-Node- 784 Home-Address-Requested flag to one, and zeroes the Home-Address- 785 Allocatable-Only-in-Home-Domain flag in the MIP-Feature-Vector AVP. 787 If the mobile node sets the home address field equal to 788 255.255.255.255 in its Registration Request, the Foreign Agent sets 789 both the Mobile-Node-Home-Address-Requested flag and the Home- 790 Address-Allocatable-Only-in-Home-Domain flag to one in the MIP- 791 Feature-Vector AVP. 793 If the mobile node sets the home agent field equal to 0.0.0.0 in its 794 Registration Request, the Foreign Agent sets the Home-Agent-Requested 795 flag to one in the MIP-Feature-Vector AVP. 797 Whenever the Foreign Agent sets either the Home-Address-Requested 798 flag or the Home-Agent-Request flag to one, it MUST also set the MN- 799 HA-Key-Request flag to one. 801 If the mobile node includes a Registration Key Request [17] extension 802 in its Registration Request, the Foreign Agent sets the MN-FA-Key- 803 Request flag to one in the MIP-Feature-Vector AVP. 805 If the mobile node requests a home agent in the foreign network, and 806 the AAAF authorizes the request, the AAAF MUST set the Home-Agent- 807 In-Foreign-Network bit to one. 809 The Foreign Agent MUST NOT set the FA-HA-Key-Request flag, Foreign- 810 Home-Agent-Available, and Home-Agent-In-Foreign-Network flag to one. 812 When the AAAF receives the AMR message, it MUST first verify that the 813 sender was an authorized Foreign Agent. The AAAF then takes any 814 actions indicated by the settings of the MIP-Feature-Vector AVP 815 flags. The AAAF then MAY set additional flags. Only the AAAF may 816 set the FA-HA-Key-Request flag or the Foreign-Home-Agent-Available 817 flag to one. This is done according to local administrative policy. 818 When the AAAF has finished setting additional flags according to its 819 local policy, then the AAAF transmits the AMR with the possibly 820 modified MIP-Feature-Vector AVP to the AAAH. 822 4.8 MIP-MN-AAA-Auth AVP 824 The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains 825 some ancillary data to simplify processing of the authentication data 826 in the Mobile IP Registration Request [4] by the target AAA server. 827 Its value has the following ABNF grammar: 829 MIP-MN-AAA-Auth = ma-spi authinlen authlen authoffset 830 ma-spi = ; MIP-MN-AAA-SPI, See Section 4.8.1 831 authinlen = ; MIP-Auth-Input-Data-Length, / 832 ; See Section 4.8.2 833 authlen = ; MIP-Authenticator-Length, / 834 ; See Section 4.8.3 835 authoffset = ; MIP-Authenticator-Offset, / 836 ; See Section 4.8.4 838 +---------------------------------------------------------------+ 839 | AVP Header (AVP Code = 322) | 840 +---------------------------------------------------------------+ 841 | MIP-MN-AAA-SPI AVP | 842 +---------------------------------------------------------------+ 843 | MIP-Auth-Input-Data-Length AVP | 844 +---------------------------------------------------------------+ 845 | MIP-Authenticator-Length AVP | 846 +---------------------------------------------------------------+ 847 | MIP-Authenticator-Offset AVP | 848 +---------------------------------------------------------------+ 850 4.8.1 MIP-MN-AAA-SPI AVP 851 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 852 indicates the algorithm by which the targeted AAA server (AAAH) 853 should attempt to validate the Authenticator computed by the mobile 854 node over the Registration Request data. 856 4.8.2 MIP-Auth-Input-Data-Length AVP 858 The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type 859 Unsigned32 and contains the length, in bytes, of the Registration 860 Request data (data portion of MIP-Reg-Request AVP) that should be 861 used as input to the algorithm (indicated by the MN-AAA-SPI AVP) used 862 to determine whether the Authenticator Data supplied by the Mobile 863 Node is valid. 865 4.8.3 MIP-Authenticator-Length AVP 867 The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32 868 and contains the length of the authenticator to be validated by the 869 targeted AAA server (i.e., AAAH). 871 4.8.4 MIP-Authenticator-Offset AVP 873 The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32 874 and contains the offset into the Registration Request Data, of the 875 authenticator to be validated by the targeted AAA server (i.e., 876 AAAH). 878 5.0 Key Distribution Center 880 The mobile node and mobility agents use registration keys to compute 881 authentication extensions applied to registration messages, as 882 defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If 883 registration keys are requested the AAA server(s) MUST create them 884 after the Mobile Node is successfully authenticated and authorized. 886 The keys destined for each mobility entity are encrypted either using 887 the secret shared with the entity [1], or via its public key [9], as 888 indicated by the relevant security association. If the AAAH does not 889 communicate directly with the Foreign Agent, those keys are encrypted 890 using the security association shared with the AAAF. The 891 Authorization-Lifetime AVP contains the number of seconds before 892 registration keys destined for the Home Agent and/or Foreign Agent 893 expire. Absence or the AVP, or a value of zero indicates infinity 894 (no timeout). 896 AAA support for key distribution departs slightly from the existing 897 SPI usage, as described in [4]. The SPI values are used as key 898 identifiers, meaning that each registration key has its own SPI 899 value; nodes that share a key also share an SPI. If no preferred SPI 900 value is indicated the registration keys the foreign agent needs, the 901 AAA server MAY generate SPI values for the Mobility Agents as opposed 902 to the receiver choosing its own SPI value. For example, suppose a 903 Mobile Node and a Foreign Agent share a key that was generatied by 904 AAAH with a corresponding SPI value of 37,496. All Mobile-Foreign 905 Authentication extensions will be computed by either entity (in this 906 example) using the shared key and MUST include the SPI value of 907 37,496. 909 Once the registration keys have been distributed, subsequent Mobile 910 IP registrations need not invoke the AAA infrastructure until the 911 keys expire. These registrations MUST include the Mobile-Home 912 authentication extension. In addition, subsequent registrations MUST 913 also include Mobile-Foreign authentication extension if the Mobile- 914 Foreign key was generated and distributed by AAA; similarly for 915 subsequent use of the Foreign-Home authentication extensions. 917 Each registration key that is generated by AAA will generally be 918 distributed to two parties; for instance, a Mobile-Foreign key goes 919 to both a mobile node and a foreign agent. The methods by which the 920 key is encoded will depend upon the security associations available 921 to the AAA server and each recipient of the key. These methods will 922 often be different for the two recipients, so that the registration 923 key under consideration has to be encoded twice. 925 See sections 6.1 and 6.2 for details about the format of the AVPs 926 used to distribute the registration keys. 928 5.1 Distributing the Mobile-Home Registration Key 930 If the mobile node does not have a Mobile-Home registration key, then 931 the AAAH is likely to be the only entity trusted that is available to 932 the mobile node. Thus, the AAAH has to generate the Mobile-Home 933 registration key, and encode it for eventual consumption by the 934 mobile node and home agent. 936 If the home agent is in the home domain, then AAAH can directly 937 encode the Mobile-Home registration key into a MIP-HA-to-MN-Key AVP 938 and include that AVP in the HAR message for delivery to the home 939 agent. 941 If, on the other hand, the home agent is to be allocated in the 942 visited domain, the AAAH does not transmit the HAR to the home agent. 944 Instead, AAAH has to include the MIP-HA-to-MN-Key AVP in the AMR 945 message which it sends to the AAAF. In this latter case, the 946 Mobile-Home registration key is encoded into MIP-HA-to-MN-Key AVP 947 using the method indicated by the security association between the 948 AAAF and the AAAH. When the AAAF receives the AMR, it first allocates 949 a home agent, and then creates a HAR message for that home agent. 950 After the AAAF decodes the registration key, it re-encodes the key 951 into a new MIP-HA-to-MN-Key AVP which is to be included within the 952 HAR message. 954 The AAAH also has to arrange for the key to be delivered to the 955 mobile node. Unfortunately, the AAA server only knows about Diameter 956 messages and AVPs, and the mobile node only knows about Mobile IP 957 messages and extensions[4]. The AAA server has to rely on a mobility 958 agent (that also understands Diameter) to transfer the key into a 959 Mobile IP MN-HA Key Reply extension to the Registration Reply 960 message. This mobility agent (actually, the mobile node's home 961 agent) can format the Reply message and extensions correctly for 962 eventual delivery to the mobile node, by way of an AMA message sent 963 to the appropriate foreign agent in the visited domain. That foreign 964 agent will use the information in the MIP-Reg-Reply AVP to create a 965 Mobile IP Registration Reply message, containing the MN-HA Key Reply 966 extension, and transmit it to the mobile node. 968 For this purpose, AAAH encodes the Mobile-Home registration key into 969 a MIP-MN-to-HA-Key AVP, using its security association with the 970 mobile node. If the home agent is in the home domain, AAAH puts the 971 MIP-MN-to-HA-Key AVP into the HAR message. Otherwise, the AAAH puts 972 the MIP-MN-to-HA-Key AVP into the AMR message which will be sent back 973 to AAAF. When AAAF creates the HAR message for the home agent in the 974 visited domain, and decodes the registration key in the MIP-HA-to- 975 MN-Key AVP from the AVP received from AAAH, AAAF then recodes the 976 registration key into a new MIP-HA-to-MN-Key AVP which is to be 977 included as part of the HAR message. In either case, the home agent 978 creates a Registration Reply with the MN-HA Key Reply extension, and 979 formats the reply data into a MIP-Reg-Rep-AVP for delivery in a HAA 980 message to the AAA server. After the HAA message is parsed by the AAA 981 server, the AMA message containing the MIP-Reg-Rep AVP will 982 eventually be received by the attendant (i.e., the foreign agent). 983 The foreign agent can then use that AVP to recreate a Registration 984 Reply message, containing the MN-HA Key Reply extension, for delivery 985 to the mobile node. 987 In summary, the AAAH generates the Mobile-Home registration key and 988 encodes it into a MIP-HA-to-MN-Key AVP and a MIP-MN-to-HA-Key AVP. 989 These AVPs are delivered to a home agent by including them in a HAR 990 message sent from either AAAH or AAAF. The home agent decodes the key 991 for its own use. The home agent also copies the encoded registration 992 key from the MIP-MN-to-HA-Key AVP into a MN-HA Key Reply extension 993 appended to the Mobile IP Registration Reply message. This 994 Registration Reply message MUST also include the Mobile-Home 995 authentication extension, created using the newly allocated Mobile- 996 Home registration key. The home agent then encodes the Registration 997 Reply message and extensions into a MIP-Reg-Reply AVP included as 998 part of the HAA message to be sent back to the AAA server. 1000 5.2 Distributing the Mobile-Foreign Registration Key 1002 The Mobile-Foreign registration key is also generated by AAAH (upon 1003 request), so that it can be encoded into a MIP-MN-to-FA-Key AVP and 1004 copied by the home agent into a "Registration Key Reply from Home 1005 Agent" extension [17] to the Mobile IP Registration Reply message. 1006 Since the foreign agent is in the same administrative domain as AAAF, 1007 the sequence of events for handling the MIP-FA-to-MN-Key AVP is 1008 similar to the way the MIP-HA-to-MN-Key AVP is handled when the home 1009 agent is allocated in the visited domain. Most of the other 1010 considerations for distributing the Mobile-Foreign registration key 1011 are also similar. 1013 When the home agent is in the home domain, AAAH includes the MIP-MN- 1014 to-FA-Key AVP in the HAR message. Otherwise, AAAH includes the MIP- 1015 MN-to-FA-Key AVP in the AMR message to be sent back to the AAAF. In 1016 the latter case, AAAF sends the HAR message to the (newly allocated) 1017 home agent. 1019 In either case, the home agent decodes the key, and recodes it into 1020 the key reply extension to the Mobile IP registration message. Then 1021 the home agent (as before) copies the Registration Reply message into 1022 the MIP-Reg-Reply AVP and places the result (possibly also containing 1023 the MN-HA Key Reply extension as in section 1.4.1) into the HAA 1024 message to be sent back to the AAA server. The home agent MUST also 1025 append a Foreign-Home authentication extension to the Registration 1026 Reply message, using the newly allocated Foreign-Home registration 1027 key. 1029 When the home agent is in the home domain, AAAH receives the HAA, and 1030 then includes the MIP-Reg-Reply AVP in the AMA message to be sent to 1031 AAAF. Otherwise, AAAF receives the HAA, and inserts it into an AMA 1032 message to be sent to the foreign agent. 1034 AAAH also has to make the Mobile-Foreign registration key available 1035 to AAAF. It does this by encoding the key into a MIP-FA-to-MN-Key 1036 AVP, using its security association with AAAF, and placing the 1037 results in the AMA. Then the AAAF decodes the registration key, and 1038 recodes it into a newly formulated MIP-FA-to-MN-Key AVP which is to 1039 be sent to the foreign agent in the AMA message containing the MIP- 1040 Reg-Reply AVP from the home agent. 1042 5.3 Distributing the Foreign-Home Registration Key 1044 If the home agent is in the home domain, then AAAH has to generate 1045 the Foreign-Home registration key. Otherwise, it is generated by 1046 AAAF. 1048 In the former case, AAAH encodes the registration key into a MIP-HA- 1049 to-FA-Key AVP and includes that AVP as part of the HAR message sent 1050 to the home agent, and waits for the HAA message to be returned. 1052 Whether or not AAAH sends the HAR message, it also further encodes 1053 the same registration key and puts it into a MIP-FA-to-HA-Key AVP 1054 included as part of the AMA message to be transmitted back to AAAF. 1056 If the home agent is in the visited domain, the AAAH includes the 1057 MIP-HA-to-FA-Key AVP as part of the AMR also. In this case, AAAF has 1058 to decode the Foreign-Home registration key and include it as part of 1059 the HAR message to be sent to the (newly allocated) home agent. 1061 In either case, AAAF sends a AMA message, containing a MIP-Reg-Reply 1062 AVP and the MIP-FA-to-HA-Key AVP, to the foreign agent. First, the 1063 foreign agent recreates the necessary Registration Reply message from 1064 the AMA message. Then the foreign agent recovers the Foreign-Home 1065 registration key, using its security association with AAAF. The 1066 foreign agent MUST then use this key to create a Mobile-Foreign 1067 authentication extension to the Registration Reply message. 1069 5.4 Key Distribution Example 1071 Figure 6 provides an example of subsequent Mobile IP message 1072 exchange, assuming that AAAH distributed registration keys for all 1073 three MN-FA, FA-HA and HA-MN authentication extensions. 1075 Mobile Node Foreign Agent Home Agent 1076 ----------- ------------- ---------- 1078 Reg-Req(MN-HA-Auth, MN-FA-Auth)--------> 1080 Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> 1082 <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) 1084 <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) 1086 Figure 6: Mobile IP Message Exchange 1088 6.0 Key Distribution Center (KDC) AVPs 1090 The Mobile-IP protocol defines a set of security associations shared 1091 between the Mobile Node, Foreign Agent and Home Agents. These three 1092 security associations (Mobile-Home, Mobile-Foreign, and Foreign- 1093 Home), can be dynamically created by the AAAH. This requires that the 1094 AAAH create Mobile-IP Registration Keys, and that these keys be 1095 distributed to the three mobile entities, via the Diameter Protocol. 1096 AAA servers supporting the Diameter Mobile IP Extension MUST 1097 implement the KDC AVPs defined in this document. In other words, AAA 1098 servers MUST be able to create three registration keys: the Mobile- 1099 Home, Mobile-Foreign, and Foreign-Home keys. 1101 Each of these keys is encrypted two different ways, as needed for 1102 each key recipient. The mobile node and home agent registration keys 1103 are sent to the Home Agent, while the foreign agent's keys are sent 1104 to the foreign agent via the AAAF. This leads to six different AVPs, 1105 since there are three keys, and each one has to be able to be 1106 encrypted in two different ways. 1108 The names of the KDC AVPs indicate the two entities sharing the 1109 security association defined by the encrypted key material; the 1110 intended receiver of the AVP is the first named entity. So, for 1111 instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key 1112 encrypted in a way that allows it to be recovered by the mobile node. 1114 If strong authentication and confidentiality of the registration keys 1115 is required, it is recommended that the strong security extension [9] 1116 be used. 1118 The following table describes the Diameter AVPs defined in the Mobile 1119 IP extension, their AVP Code values, types, possible flag values and 1120 whether the AVP MAY be encrypted. 1122 +---------------------+ 1123 | AVP Flag rules | 1124 |----+-----+----+-----|----+ 1125 AVP Section | | |SHLD| MUST|MAY | 1126 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1127 -----------------------------------------|----+-----+----+-----|----| 1128 MIP-FA-to-MN-Key 326 6.2.1 Grouped | M | P | | V | Y | 1129 MIP-FA-to-HA-Key 328 6.2.2 Grouped | M | P | | V | Y | 1130 MIP-HA-to-FA-Key 329 6.2.3 Grouped | M | P | | V | Y | 1131 MIP-HA-to-MN-Key 332 6.2.4 Grouped | M | P | | V | Y | 1132 MIP-MN-to-FA-Key 325 6.1.1 OctetString| M | P | | V | Y | 1133 MIP-MN-to-HA-Key 331 6.1.2 OctetString| M | P | | V | Y | 1134 MIP-Peer-SPI 342 6.2.5 Unsigned32 | M | P | | V | Y | 1135 MIP-FA-MN- 324 6.3 Unsigned32 | M | P | | V | Y | 1136 Preferred-SPI | | | | | | 1137 MIP-FA-HA- 327 6.4 Unsigned32 | M | P | | V | Y | 1138 Preferred-SPI | | | | | | 1139 MIP-Session-Key 343 6.2.6 OctetString| M | P | | V | Y | 1141 6.1 Mobile Node Registration Keys 1143 When the AAAH acts as a Key Distribution Center, and it is determined 1144 that keying material is to be created for Mobile Nodes, the AAAH 1145 creates the keys and encodes them in the MIP-MN-to-FA-Key and MIP- 1146 MN-to-HA-Key AVPs as opaque data. The actual format of the AVP value 1147 is described in [15], and would contains the data immediately 1148 following the Mobile IP extension header. 1150 The Mobile IP key described in [15] refers to the AAA SPI, which MUST 1151 be set to the value the AAAH shares with the Mobile Node. The Key 1152 Lifetime field is set to the same value as the one found in the 1153 Authorization-Lifetime AVP. 1155 6.1.1 MIP-MN-to-FA-Key AVP 1157 The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type OctetString, and 1158 contains the Keying material described in the "Unsolicited MN-FA Key 1159 from AAA Subtype" in [15]. The FA SPI field of the data structure in 1160 [15] MUST be set to the same value as the Peer-SPI AVP within the 1161 FA-to-MN-Key AVP. 1163 6.1.2 MIP-MN-to-HA-Key AVP 1165 The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type OctetString, and 1166 contains the Keying material described in the "Unsolicited MN-HA Key 1167 from AAA Subtype" in [15]. The HA SPI field of the data structure in 1168 [15] MUST be set to the same value as the Peer-SPI AVP within the 1169 HA-to-MN-Key AVP. 1171 6.2 Mobility Agent Session Keys 1173 The Mobility Agent session keys are the keys created by a Diameter 1174 server, which it distributes to Foreign and Home Agents, acting as 1175 Diameter clients. These session keys, described below, are of type 1176 Grouped, and therefore their value have the following ABNF format: 1178 Mobility Agent Session Key AVP = Peer-SPI Session-Key 1179 Peer-SPI = ; MIP-Peer-SPI, See Section 6.2.5 1180 Session-Key = ; MIP-Session-Key, See Section 6.2.6 1182 The MIP-Peer-SPI AVP contains the Security Parameter Index, which the 1183 Mobility Agent MUST use to refer to the Key contained in the MIP- 1184 Session-Key AVP. 1186 +---------------------------------------------------------------+ 1187 | AVP Header (AVP Code = see below) | 1188 +---------------------------------------------------------------+ 1189 | MIP-Peer-SPI AVP | 1190 +---------------------------------------------------------------+ 1191 | MIP-Session-Key AVP | 1192 +---------------------------------------------------------------+ 1194 6.2.1 MIP-FA-to-MN-Key AVP 1196 The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and 1197 contains the Foreign Agent's session key, which it shares with the 1198 Mobile Node. Its format is described in Section 6.2. 1200 6.2.2 MIP-FA-to-HA-Key AVP 1202 The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and 1203 contains the Foreign Agent's session key, which it shares with the 1204 Home Agent. Its format is described in Section 6.2. 1206 6.2.3 MIP-HA-to-FA-Key AVP 1208 The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and 1209 contains the Home Agent's session key, which it shares with the 1210 Foreign Agent. Its format is described in Section 6.2. 1212 6.2.4 MIP-HA-to-MN-Key AVP 1214 The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and 1215 contains the Home Agent's session key, which it shares with the 1216 Mobile Node. Its format is described in Section 6.2. 1218 6.2.5 MIP-Peer-SPI AVP 1220 The MIP-Peer-SPI AVP (AVP Code 342) is of type Unsigned32, and 1221 contains the Security Parameter Index to use to reference the key in 1222 the associated MIP-Session-Key AVP. 1224 6.2.6 MIP-Session-Key AVP 1226 The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 1227 contains the Session Key to be used between two Mobile IP entities. 1229 6.3 MIP-FA-MN-Preferred-SPI AVP 1231 The MIP-FA-MN-Preferred-SPI AVP (AVP Code 324) is of type Unsigned32 1232 and is sent in the AA-Mobile-Node-Request by the Foreign Agent. The 1233 AVP contains the SPI that the Foreign Agent would prefer to have 1234 assigned by the AAAH in the MIP-FA-to-MN-Key AVP. 1236 6.4 MIP-FA-HA-Preferred-SPI AVP 1238 The MIP-FA-HA-Preferred-SPI AVP (AVP Code 324) is of type Unsigned32 1239 and is sent in the AA-Mobile-Node-Request by the Foreign Agent. The 1240 AVP contains the SPI that the Foreign Agent would prefer to have 1241 assigned by the AAAH in the MIP-FA-to-HA-Key AVP. 1243 7.0 Accounting Considerations 1245 This section contains the AVPs defined in this extension that are to 1246 be present in the Accounting-Request and optionally in the 1247 Accounting-Answer messages, defined in [12]. 1249 ::= { MIP-Mobile-Node-Address } 1250 { MIP-Home-Agent-Address } 1251 [ MIP-Previous-FA-NAI ] 1252 [ MIP-Previous-FA-Address ] 1253 [ MIP-Feature-Vector ] 1255 8.0 Interactions with Resource Management 1257 The Resource Management extension [18] provides the ability for a 1258 Diameter node to query a peer for session state information. The 1259 document states that service-specific extensions are responsible for 1260 specifying what AVPs are to be present in the Resource-Token [18] 1261 AVP. 1263 In addition to the AVPs listed in [18], the Resource-Token with the 1264 Extension-Id AVP set to four (4) MUST include the MIP-Mobile-Node- 1265 Address and the MIP-Home-Agent-Address AVP. 1267 9.0 Acknowledgements 1269 The authors would like to thank Nenad Trifunovic and Pankaj Patel for 1270 their participation in the Document Reading Party, to Erik Guttman 1271 for his very useful proposed text, and to Tony Johansson for the 1272 proposed text AND being in the doc reading party. The authors would 1273 also like to thank the participants of 3GPP2's TSG-P working group 1274 for their valuable feedback. 1276 10.0 IANA Considerations 1278 The command codes defined in Section 2.0 are values taken from the 1279 Command-Code [1] address space and extended in [9], [12] and [14]. 1280 IANA should record the values as defined in Section 2.0. 1282 The Result-Code values defined in Section 3.0 are error codes as 1283 defined in [1] and extended in [9], [12] and [14]. They correspond to 1284 error values specific to the Mobile IP extension. IANA should record 1285 the values as defined in Section 3.0. 1287 The AVPs defined in sections 4.0 and 6.0 were allocated from the AVP 1288 numbering space defined in [1], and extended in [9], [12] and [14]. 1289 IANA should record the values as defined in Sections 4.0 and 6.0. 1291 11.0 Security Considerations 1293 This specification describes the Diameter extension necessary to 1294 authenticate and authorize a Mobile IP Mobile Node. The 1295 authentication algorithm used is dependent upon the transforms 1296 available by the Mobile IP protocol, and [5]. This specification also 1297 defines a method by which the home Diameter server can create and 1298 distribute registration keys to be used to authenticate Mobile IP 1299 registration messages. The keys are distributed in an encrypted 1300 format through the Diameter protocol, and SHOULD be encrypted using 1301 the methods defined in [9]. 1303 12.0 References 1305 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "Diameter Base 1306 Protocol", draft-calhoun-diameter-18.txt, IETF work in progress, 1307 January 2001. 1309 [2] Calhoun, Zorn, Pan, Akhtar, "Diameter Framework", draft-calhoun- 1310 diameter-framework-09.txt, IETF work in progress, January 2001. 1312 [3] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 1313 Authorization, and Accounting Requirements". RFC 2977. October 1314 2000. 1316 [4] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. 1318 [5] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Exten- 1319 sions". RFC 3012. November 2000. 1321 [6] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486. 1322 January 1999. 1324 [7] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 1325 RFC 2477, January 1999. 1327 [8] P. Calhoun, C. Perkins, "Mobile IP Network Address Identifier 1328 Extension", RFC 2794, March 2000. 1330 [9] P. Calhoun, W. Bulley, S. Farrell, "Diameter Strong Security 1331 Extensions", draft-calhoun-diameter-strong-crypto-06.txt, IETF 1332 work in progress, January 2001. 1334 [10] Kent, Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1335 2406, November 1998. 1337 [11] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1338 Levels", BCP 14, RFC 2119, March 1997. 1340 [12] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "Diameter Accounting 1341 Extension", draft-calhoun-diameter-accounting-09.txt, IETF work 1342 in progress, January 2001. 1344 [13] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing 1345 for Message Authentication. RFC 2104, February 1997. 1347 [14] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ 1348 Extension", draft-calhoun-diameter-nasreq-06.txt, IETF work in 1349 progress, January 2001. 1351 [15] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", 1352 draft-calhoun-mobileip-aaa-key-01.txt, IETF work in progress, 1353 January 2000. 1355 [16] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", 1356 draft-hiller-cdma2000-aaa-01.txt, IETF work in progress, June 1357 2000. 1359 [17] C. Perkins, D. Johnson, N. Asokan, "Registration Keys for Route 1360 Optimization", draft-ietf-mobileip-regkey-03.txt, IETF work in 1361 progress, July 2000. 1363 [18] P. Calhoun, "Diameter Resource Management", draft-calhoun- 1364 diameter-res-mgmt-06.txt, IETF Work in Progress, January 2001. 1366 13.0 Authors' Addresses 1368 Questions about this memo can be directed to: 1370 Pat R. Calhoun 1371 Network and Security Research Center, Sun Labs 1372 Sun Microsystems, Inc. 1373 15 Network Circle 1374 Menlo Park, California, 94025 1375 USA 1377 Phone: +1 650-786-7733 1378 Fax: +1 650-786-6445 1379 E-mail: pcalhoun@eng.sun.com 1381 Charles E. Perkins 1382 Nokia Research Center 1383 313 Fairchild Drive 1384 Mountain View, California 94043 1385 USA 1387 Phone: +1 650-625-2986 1388 Fax: +1 650-625-2502 1389 E-Mail: charliep@iprg.nokia.com 1391 14.0 Full Copyright Statement 1392 Copyright (C) The Internet Society (2001). All Rights Reserved. 1394 This document and translations of it may be copied and furnished to 1395 others, and derivative works that comment on or otherwise explain it 1396 or assist in its implementation may be prepared, copied, published 1397 and distributed, in whole or in part, without restriction of any 1398 kind, provided that the above copyright notice and this paragraph are 1399 included on all such copies and derivative works. However, this docu- 1400 ment itself may not be modified in any way, such as by removing the 1401 copyright notice or references to the Internet Society or other 1402 Internet organizations, except as needed for the purpose of develop- 1403 ing Internet standards in which case the procedures for copyrights 1404 defined in the Internet Standards process must be followed, or as 1405 required to translate it into languages other than English. The lim- 1406 ited permissions granted above are perpetual and will not be revoked 1407 by the Internet Society or its successors or assigns. This document 1408 and the information contained herein is provided on an "AS IS" basis 1409 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1410 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1411 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1412 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1413 FITNESS FOR A PARTICULAR PURPOSE. 1415 15.0 Expiration Date 1417 This memo is filed as and 1418 expires in July 2001.