idnits 2.17.1 draft-ietf-aaa-diameter-mobileip-00.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 33 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 34 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The following table presents the AVPs defined in this document, and specifies in which Diameter messages they MAY, or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. -- 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 8464 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 1364, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1389, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1399, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-00 -- 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) == Outdated reference: A later version (-01) exists of draft-ietf-aaa-diameter-accounting-00 -- Possible downref: Normative reference to a draft: ref. '12' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '13') == Outdated reference: A later version (-17) exists of draft-ietf-aaa-diameter-nasreq-00 -- Unexpected draft version: The latest known version of draft-calhoun-mobileip-aaa-key is -00, but you're referring to -03. -- 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 (-08) exists of draft-calhoun-diameter-res-mgmt-06 -- Possible downref: Normative reference to a draft: ref. '17' Summary: 14 errors (**), 0 flaws (~~), 14 warnings (==), 9 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 2001. 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 AVP Table 99 10.0 Acknowledgements 100 11.0 IANA Considerations 101 12.0 Security Considerations 102 13.0 References 103 14.0 Authors' Addresses 104 15.0 Full Copyright Statement 106 1.0 Introduction 108 Mobile IP, as defined in [4], defines a method that allows a Mobile 109 Node to change its point of attachment to the Internet with minimal 110 service disruption. Mobile IP does not provide any specific support 111 for mobility across disparate administrative domains, and therefore 112 does not specify how usage can be accounted for, which has limited 113 the applicability of Mobile IP in a IPv4 commercial deployment. The 114 Mobile IP protocol [4] requires that mobile nodes have static home 115 agent and home addresses, which is not desirable in a commercial 116 network. Recent specification [8] allows a mobile node to use its 117 NAI instead of its home address, which better accommodates current 118 administrative practice. 120 This document specifies Extension 4 to the Diameter base protocol [1] 121 that allows a Diameter server to authenticate, authorize and collect 122 accounting information for services rendered to a mobile node. 123 Diameter nodes conforming to this specification MUST include an 124 Extension-Id AVP with a value of four in the Device-Reboot-Ind 125 Command [1]. Combined with the Inter-Domain capability of the base 126 protocol, this extension allows mobile nodes to receive service from 127 foreign service providers. The Diameter Accounting extension [12] 128 will be used by the Foreign and Home agents to transfer usage 129 information to the Diameter servers. 131 The Mobile IP protocol [4] specifies a security model that requires 132 that mobile nodes and home agents share a pre-existing security 133 association, which leads to scaling and configuration issues. This 134 specification defines Diameter functions that allow the AAA server to 135 act as a Key Distribution Center (KDC), whereby dynamic registration 136 keys are created and distributed to the mobility entities for the 137 purposes of securing Mobile IP Registration messages. 139 As with the Diameter base protocol, AAA servers implementing the 140 Mobile IP extension can process users' identities supplied in a 141 Network Access Identifier (NAI) format [6], which is used for 142 Diameter message routing purposes. Mobile nodes include their NAI in 143 Registration messages, as defined in [8]. The use of the NAI is 144 consistent with the roaming model defined by the ROAMOPS Working 145 Group [7]. 147 The Diameter Mobile-IP Extension meets the requirements specified in 148 [3, 16]. Later subsections in this introductory section provide some 149 examples and message flows of the Mobile IP and Diameter messages 150 that occur when a Mobile Node requests service in a foreign network. 151 In this document, the role of the "attendant" [3] is performed by the 152 foreign agent for the Mobile-IP Extension, and these terms will be 153 used interchangeably. 155 1.1 Requirements language 157 In this document, the key words "MAY", "MUST", "MUST NOT", 158 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 159 interpreted as described in [11]. 161 1.2 Inter-Domain Mobile IP 163 When a Mobile Node node requests service by issuing a Registration 164 Request to the foreign agent, the foreign agent creates the AA- 165 Mobile-Node-Request (AMR) message, which includes the AVPs defined in 166 section 2.1. The Home Address, Home Agent, Mobile Node NAI and other 167 important fields are extracted from the registration messages for 168 possible inclusion as Diameter AVPs. The AMR message is then 169 forwarded to the local Diameter server, known as the AAA-Foreign, or 170 AAAF. 172 Visited Domain Home Domain 173 +--------+ +--------+ 174 |abc.com | AMR/AMA |xyz.com | 175 | AAAF |<------------------->| AAAH | 176 +->| server | server-server | server | 177 | +--------+ communication +--------+ 178 | ^ ^ 179 | AMR/AMA | client-server | HAR/HAA 180 | | communication | 181 v v v 182 +---------+ +---------+ +---------+ 183 | Foreign | | Foreign | | Home | 184 | Agent | | Agent | | Agent | 185 +---------+ +---------+ +---------+ 186 ^ 187 | Mobile IP 188 | 189 v 190 +--------+ 191 | Mobile | 192 | Node | mn@xyz.com 193 +--------+ 194 Figure 1: Inter-Domain Mobility 196 Upon receiving the AMR, the AAAF follows the procedures outlined in 197 [1] to determine whether the AMR should be processed locally, or if 198 it should be forwarded to another Diameter Server, known as the AAA- 199 Home, or AAAH. Figure 1 shows an example in which a mobile node 200 (mn@xyz.com) requests service from a foreign provider (abc.com). The 201 request received by the AAAF is forwarded to xyz.com's AAAH server. 203 Figure 2 shows the message flows involved when the attendant (foreign 204 agent) invokes the AAA infrastructure to request that a mobile node 205 be authenticated and authorized. Note that it is not required that 206 the foreign agent invoke AAA services every time a Registration 207 Request is received from the mobile, but rather only when the prior 208 authorization from the AAAH expires. The expiration time of the 209 authorization (and registration keys, if allocated by the AAA server) 210 is communicated through the Authorization-Lifetime AVP in the AA- 211 Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. 213 Mobile Node Foreign Agent AAAF AAAH Home Agent 214 ----------- ------------- ------------ ---------- ---------- 215 Advertisement & 216 <--------- Challenge 217 Reg-Req&MN-AAA ----> 218 AMR-------------> 219 AMR------------> 220 HAR-----------> 221 <----------HAA 222 <-----------AMA 223 <------------AMA 224 <-------Reg-Reply 226 Figure 2: Mobile IP/Diameter Message Exchange 228 The foreign agent (as shown in Figure 2) MAY provide a challenge, 229 which gives it direct control over the replay protection in the 230 Mobile IP registration process, as described in [5]. The mobile node 231 includes the Challenge and MN-AAA authentication extension to enable 232 authorization by AAAH. If the authentication data supplied in the 233 MN-AAA extension is invalid, AAAH returns the response (AMA) with the 234 Result-Code AVP set to DIAMETER_ERROR_AUTH_FAILURE (see section 3.0). 236 If the Mobile Node was successfully authenticated, the AAAH checks 237 for the MIP-Home-Agent-Address AVP. If one was specified, the AAAH 238 checks that the address is that of a known Home Agent, and one that 239 the Mobile Node is allowed to request. If no Home Agent was 240 specified, and if the MIP-Feature-Vector has the Home-Agent-Requested 241 flag set, and if allowed by policy in the home domain, the AAAH 242 SHOULD allocate a home agent on behalf of the Mobile Node. This can 243 be done in a variety of ways, including using a load balancing 244 algorithm in order to keep the load on all home agents equal. The 245 actual algorithm used and the method of discovering the home agents 246 is outside the scope of this specification. 248 If AAAH does not know the address of the home agent (perhaps because 249 it will be allocated by AAAF within the visited domain as described 250 in section 1.3), then AAAH sends an AMA message back to AAAF which 251 does not contain a MIP-Reg-Reply AVP. 253 Otherwise, if the home agent address is known, the AAAH then sends a 254 Home-Agent-MIP-Request (HAR), which contains the Mobile IP 255 Registration Request message data encapsulated in the MIP-Reg-Request 256 AVP, to the assigned or requested Home Agent. The AAAH MAY allocate a 257 home address for the mobile node, and include it in a MIP-Mobile- 258 Node-Address AVP within the HAR, or else leave this allocation 259 responsibility for the Home Agent. 261 Upon receipt of the HAR, the Home Agent first processes the Diameter 262 message. If the HAR is invalid, a HAA is returned with the Result- 263 Code AVP set to DIAMETER_ERROR_BAD_HAR (see section 3.0). Otherwise, 264 the Home Agent processes the MIP-Reg-Req AVP and creates the 265 Registration Reply, encapsulating it within the MIP-Reg-Reply AVP. 266 If a home address is needed, the Home Agent MUST assign one and 267 include the address in both the Registration Reply and within the 268 MIP-Mobile-Node-Address AVP. The Diameter response is then forwarded 269 to the AAAH. 271 Upon receipt of the HAA, the AAAH sets the Command-Code field to AA- 272 Mobile-Node-Answer (AMA) and forwards the message to the AAAF. The 273 AAAH includes the MIP-Home-Agent-Address and MIP-Mobile-Node-Address 274 AVPs in the AMA message, enabling appropriate firewall controls for 275 the penetration of tunneled traffic between the Home Agent and the 276 Mobile Node. 278 The AAAF is responsible for ensuring that the AMA message is properly 279 forwarded to the correct foreign agent. 281 1.3 Allocation of Home Agent in Foreign Network 283 The Diameter Mobile IP extension allows a Home Agent to be allocated 284 in a foreign network, as required in [3, 16]. When a foreign agent 285 detects that the mobile node has a home agent address equal to 286 0.0.0.0 or 255.255.255.255 in the Registration Request message, it 287 MUST add a MIP-Feature-Vector AVP with the Home-Agent-Requested flag 288 set to one. If the home agent address is equal to 255.255.255.255, 289 then the foreign agent also MUST set the Home-Address-Allocatable- 290 Only-in-Home-Domain flag equal to one. 292 When the AAAF receives a AMR message with the Home-Agent-Requested 293 flag set to one, and the Home-Address-Allocatable-Only-in-Home-Domain 294 flag equal to zero, AAAF MAY set the Foreign-Home-Agent-Available 295 flag in the MIP-Feature-Vector AVP to inform the AAAH that it is 296 willing and able to assign a Home Agent for the Mobile Node. 298 In the event that the mobile node requests a home agent in the 299 foreign network, and the AAAF authorizes its use, the AAAF MUST set 300 the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. 301 This could happen when the AAA request is sent to "extend" a mobile 302 node's current session. 304 When the AAAH receives a AMR message, it first checks the 305 authentication data supplied by the mobile node, according to the 306 MIP-Reg-Req AVP and MIP-MN-AAA-Auth AVP, and determines whether to 307 authorize the mobile node. If the AMR indicates that the AAAF has 308 offered to allocate a home agent for the mobile node, then the AAAH 309 must decide whether its local policy would allow the user to have a 310 Home Agent in the foreign network. If so, and after checking 311 authorization from the data in the AMR message, the AAAH sends the 312 AMA message to the AAAF that does not contain the MIP-Home-Agent- 313 Address. 315 Visited Domain Home Domain 316 +--------+ +--------+ 317 | | AMR/AMA | | 318 | AAAF |<------------------>| AAAH | 319 +--->| server | server-server | server | 320 | +--------+ communication +--------+ 321 | ^ 322 | | 323 HAR/HAA | AMR/AMA | client-server 324 v v communication 325 +---------+ +---------+ 326 | Home | | Foreign | 327 | Agent | | Agent | 328 +---------+ +---------+ 329 ^ 330 +--------+ | 331 | Mobile |<----------+ 332 | Node | Mobile IP 333 +--------+ 334 Figure 3: Home Agent allocated in Visited Domain 336 Upon receipt of a HAA from the Home Agent in the Visited Domain, with 337 the Result-Code AVP indicating success, the AAAF MUST issue a HAI 338 message to the AAAH. The HAI message MUST include the MIP-Home- 339 Agent-Address and the MIP-Mobile-Node-Address AVPs. 341 Mobile Node Foreign Agent Home Agent AAAF AAAH 342 ----------- ------------- ------------- ---------- ---------- 344 <----Challenge---- 345 Reg-Req (Response)-> 346 ------------AMR-------------> 347 -----AMR----> 348 <----AMA----- 349 <-----HAR------ 350 ------HAA------> 351 <-------------AMA------------AMA 352 ---HAI------> 353 <---Reg-Reply---- 354 Figure 4: Mobile IP/Diameter Message Exchange 356 If the Mobile Node moves to another Foreign Network, it MAY either 357 request to keep the same Home Agent within the old foreign network, 358 or request to get a new one in the new foreign network. If the AAAH 359 is willing to provide the requested service, the mobile node will 360 have to interact with two AAAFs. 362 Figure 5 shows the message flows for a Mobile Node requesting to keep 363 the Home Agent assigned in Foreign network 1 when it moves to foreign 364 network 2. Upon reception of the AMR in Foreign network 2, the AAAF 365 follows the procedures described earlier and forwards AMR to the 366 Mobile Node's home network, i.e. its AAAH. If the Mobile Node was 367 successfully authenticated the AAAH checks for the MIP-Home-Agent- 368 Address and the MIP-Previous-FA-NAI AVPs. If a Home Agent was 369 specified, and it belongs to a different domain than the Foreign 370 Agent in the MIP-Previous-FA-NAI AVP, the AAAH MUST verify whether it 371 will permit this type of the service to the Mobile Node. 373 +---------------+ +---------------+ +-------------+ 374 |Foreign net 2 | |Foreign net 1 | |Home network | 375 | | | | | | 376 Mobile Node | FA AAAF | | HA AAAF | | AAAH | 377 ----------- | ---- ---- | | ---- ------ | | ------ | 378 +---------------+ +---------------+ +-------------+ 380 <----Challenge---- 381 Reg-Req (Response)-> 382 ---AMR---> 383 ----------------AMR---------------> 384 <-----HAR----- 385 <--HAR--- 386 --HAR--> 387 ------HAA----> 388 <--------------AMA---------------- 389 <--AMA---- 390 <-Reg-Reply-- 391 Figure 5: Request to access Home Agent from new Foreign Network 393 If the Mobile Node is allowed to keep the Home Agent the AAAH then 394 sends a HAR, which contains the Mobile IP Registration Request 395 message data encapsulated in the MIP-Reg-Request AVP and the MIP- 396 Home-Agent-Address AVP with Home Agent address, the optional KDC 397 session keys to the AAAF in foreign network 1. Upon reception the 398 AAAF in foreign network 1 will forward the HAR to the Home Agent if 399 its local policy allows such service. If the AAAF does not permit 400 such service, it MUST return a DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. 402 When the AAAF receives a successful HAA, the AAAF will forward the 403 HAA back to the AAAH. The HAA MUST include the MIP-Home-Agent-Address 404 and the MIP-Mobile-Node-Address AVPs. The AAAH will then send back an 405 AMA to the AAAF in foreign network 2. 407 If the old Foreign Network does not permit the use of its Home Agent 408 when the Mobile Node moves to a new foreign network, the Mobile Node 409 MAY allocate a new Home Agent in its current network, as described 410 above. However, when the AAAH receives such a request, it MUST send a 411 Diameter Session-Termination-Indication message to the old AAAF, 412 which will enable the old foreign network to release any resources, 413 and will cause any necessary accounting messages. 415 [ed: Charlie would prefer that the AMA be sent directly from foreign 416 net 1 to foreign net 2. This would optimize the signaling, and would 417 reduce latency involved in the handoff. More work needed here] 419 1.4 Diameter Session Termination 421 A Foreign and Home Agent following this specification MAY expect 422 their respective Diameter servers to maintain session state 423 information for each mobile node in their networks. In order for the 424 Diameter Server to release any resources allocated to a specific 425 mobile node, the mobility agents MUST send a Session-Termination- 426 Request (STR) [1] to their respective Diameter servers. 428 The Home Diameter server SHOULD only deallocate all resources after 429 the STR is received from the Home Agent. This ensures that a Mobile 430 Node that moves from one Foreign Agent to another (hand-off) does not 431 cause the Home Diameter Server to free all resources for the Mobile 432 Node. The Diameter Server is free to initiate the session termination 433 at any time by issuing the Session-Termination-Ind (STI) [1]. 435 2.0 Command-Code Values 437 This section defines Command-Code [1] values that MUST be supported 438 by all Diameter implementations conforming to this specification. 439 The following Command Codes are defined in this specification: 441 Command-Name Abbreviation Code Section 442 ----------------------------------------------------------- 443 AA-Mobile-Node-Answer AMA 261 2.2 444 AA-Mobile-Node-Request AMR 260 2.1 445 Home-Agent-Allocated-Ind HAI 279 2.5 446 Home-Agent-MIP-Answer HAA 263 2.4 447 Home-Agent-MIP-Request HAR 262 2.3 449 2.1 AA-Mobile-Node-Request (AMR) Command 451 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field 452 set to 260, is sent by an attendant, acting as a Diameter client, to 453 a server in order to request the authentication and authorization of 454 a Mobile Node. The Foreign Agent uses information found in the 455 Registration Request to construct the following AVPs that are to be 456 included as part of the AMR: 458 home address (MIP-Mobile-Node-Address AVP), 459 home agent address (MIP-Home-Agent-Address AVP), 460 mobile node NAI (User-Name AVP [1]). 462 If the mobile node's home address is zero, the foreign agent MUST NOT 463 include a MIP-Mobile-Node-Address AVP in the AMR. In this case, the 464 AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP- 465 Feature-Vector AVP in the AMR message to indicate that it is willing 466 to assign a Home Agent in the visited domain. 468 If the MIP-Previous-FA-NAI AVP is found in the request, the Diameter 469 client requests that the server return the registration key that was 470 assigned to the previous Foreign Agent for use with the Mobile Node 471 and Home Agent. The registration key is identified through the use of 472 the MIP-Mobile-Node-Address AVP. 474 Message Format 476 ::= < Diameter Header: 260 > 477 { Session-ID } 478 { User-Name } 479 { Host-Name } 480 { Authorization-Lifetime } 481 { MIP-Reg-Request } 482 { MIP-MN-AAA-Auth } 483 [ MIP-Mobile-Node-Address ] 484 [ MIP-Home-Agent-Address ] 485 [ MIP-Feature-Vector ] 486 [ MIP-FA-MN-Preferred-SPI ] 487 [ MIP-FA-HA-Preferred-SPI ] 488 [ MIP-Previous-FA-NAI ] 489 [ MIP-Previous-FA-Addr ] 490 * [ AVP ] 491 * [ Proxy-State ] 492 * [ Route-Record ] 493 * [ Routing-Realm ] 494 0*1< Integrity-Check-Value > 496 2.2 AA-Mobile-Node-Answer (AMA) Command 498 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field 499 set to 261, is sent by the AAAH in response to the AA-Mobile-Node- 500 Request message. The Result-Code AVP MAY contain one of the values 501 defined in section 3.0, in addition to the values defined in [1]. If 502 the home agent is situated in the home domain, a successful response 503 MUST include the MIP-Reg-Reply AVP. 505 The MIP-Home-Agent-Address AVP contains the Home Agent assigned to 506 the Mobile Node, while the MIP-Mobile-Node-Address AVP contains the 507 home address that was assigned. 509 The AMA message MUST contain the MIP-FA-to-HA-Key, MIP-FA-to-MN-Key 510 and MIP-Reg-Reply AVPs if they were received by AAAH in the HAA 511 message. 513 Message Format 515 ::= < Diameter Header: 261 > 516 < Session-Id > 517 { Session-Timeout } 518 { Authorization-Lifetime } 519 { Result-Code } 520 [ Host-Name ] 521 [ MIP-Reg-Reply ] 522 [ MIP-MN-to-HA-Key ] 523 [ MIP-FA-to-MN-Key ] 524 [ MIP-FA-to-HA-Key ] 525 [ MIP-Home-Agent-Address ] 526 [ MIP-Mobile-Node-Address ] 527 * [ AVP ] 528 * [ Proxy-State ] 529 * [ Route-Record ] 530 * [ Routing-Realm ] 531 0*1< Integrity-Check-Value > 533 2.3 Home-Agent-MIP-Request (HAR) Command 535 The Home-Agent-MIP-Request (HAR), indicated by the Command-Code field 536 set to 262, is sent by the AAA to the Home Agent. If the Home Agent 537 is to be assigned in a foreign network, the HAR is issued by AAAF. 538 If the HAR message does not include a MIP-Mobile-Node-Address AVP, 539 and the Registration Request has 0.0.0.0 for the home address, and 540 the HAR is successfully processed, the Home Agent MUST allocate one 541 such address to the mobile node. If the home agent's local AAA server 542 allocates the mobile node's home address, it MUST include the 543 assigned address in an MIP-Mobile-Node-Address AVP. 545 If a AAAF receives a HAR that does not include the MIP-Reg-Reply AVP, 546 then a Home Agent MUST be assigned in the foreign network. 548 When registration keys are requested for use by the mobile node (see 549 section 5.0), the AAAH MUST create them and include them in the HAR 550 message. When a Foreign-Home registration key is requested, it will 551 be created and distributed by the AAA server in the same domain as 552 the home agent. 554 Message Format 556 ::= < Diameter Header: 262 > 557 < Session-Id > 558 { Session-Timeout } 559 { Authorization-Lifetime } 560 { MIP-Reg-Request } 561 { Host-Name } 562 { User-Name } 563 [ MIP-MN-to-HA-Key ] 564 [ MIP-MN-to-FA-Key ] 565 [ MIP-HA-to-MN-Key ] 566 [ MIP-HA-to-FA-Key ] 567 [ MIP-FA-to-MN-Key ] 568 [ MIP-FA-to-HA-Key ] 569 [ MIP-Mobile-Node-Address ] 570 * [ AVP ] 571 * [ Proxy-State ] 572 * [ Route-Record ] 573 * [ Routing-Realm ] 574 0*1< Integrity-Check-Value > 576 2.4 Home-Agent-MIP-Answer (HAA) Command 578 The Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field 579 set to 263, is sent by the Home Agent to its local AAA server in 580 response to a Home-Agent-MIP-Request. If the home agent allocated a 581 home address for the Mobile Node, the address MUST be included in the 582 MIP-Mobile-Node-Address AVP. The Result-Code AVP MAY contain one of 583 the values defined in section 3.0 instead of the values defined in 584 [1]. 586 Message Format 588 ::= < Diameter Header: 263 > 589 < Session-Id > 590 { Session-Timeout } 591 { Authorization-Lifetime } 592 { Result-Code } 593 [ MIP-Reg-Reply ] 594 [ MIP-Home-Agent-Address ] 595 [ MIP-Mobile-Node-Address ] 596 [ MIP-FA-to-MN-Key ] 597 [ MIP-FA-to-HA-Key ] 598 * [ AVP ] 599 * [ Proxy-State ] 600 * [ Route-Record ] 601 * [ Routing-Realm ] 602 0*1< Integrity-Check-Value > 604 2.5 Home-Agent-Allocated-Ind (HAI) Command 606 The Home-Agent-Allocated-Ind (HAI), indicated by the Command-Code 607 field set to 279, is sent by the AAAF to the AAAH upon receipt of a 608 successful HAA when the Home Agent was assigned in the visited 609 network. The HAI MUST include the MIP-Home-Agent-Address and MIP- 610 Mobile-Node-Address AVPs. 612 Message Format 614 ::= < Diameter Header: 279 > 615 < Session-Id > 616 { Session-Timeout } 617 { Authorization-Lifetime } 618 [ MIP-Home-Agent-Address ] 619 [ MIP-Mobile-Node-Address ] 620 * [ AVP ] 621 * [ Proxy-State ] 622 * [ Route-Record ] 623 * [ Routing-Realm ] 624 0*1< Integrity-Check-Value > 626 3.0 Result-Code AVP Values 628 This section defines new Result-Code [1] values that MUST be 629 supported by all Diameter implementations that conform to this 630 specification. 632 3.1 Hop-by-Hop Failures 634 Proxies receiving messages with the Result-Code AVP set to an error 635 within the Hop-by-Hop failure category SHOULD attempt to take some 636 local action to correct the error. If no local action can be taken to 637 correct the problem, the error MUST be forwarded towards the 638 originator of the message. 640 DIAMETER_ERROR_BAD_KEY 6009 641 This error code is used by the Home Agent to indicate to the 642 local Diameter server that the key generated is invalid. 644 DIAMETER_ERROR_BAD_HOME_ADDRESS 6010 645 This error code is used by the Home Agent to indicate that the 646 Home Address chosen by the Mobile Node or assigned by the local 647 Diameter server is unavailable. 649 DIAMETER_ERROR_AUTH_FAILURE 6011 650 This error code is used by AAAH to inform AAAF that the 651 authentication data in the MN-AAA authentication extension is 652 invalid. 654 DIAMETER_ERROR_MIP_REPLY_FAILURE 6012 655 This error code is used by the Home Agent when processing of 656 the Registration Request has failed. 658 DIAMETER_ERROR_BAD_HAR-day 6013 659 This error code is used by HA to inform the AAA server that the 660 Home-Agent-Request (HAR) message could not be processed 661 correctly. 663 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 6014 664 This error is used by the AAAF to inform the AAAH that 665 allocation of a Home Agent in the Foreign Agent is not 666 permitted at this time. 668 4.0 Mandatory AVPs 670 The following table describes the Diameter AVPs defined in the Mobile 671 IP extension, their AVP Code values, types, possible flag values and 672 whether the AVP MAY be encrypted. 674 +---------------------+ 675 | AVP Flag rules | 676 |----+-----+----+-----|----+ 677 AVP Section | | |SHLD| MUST|MAY | 678 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 679 -----------------------------------------|----+-----+----+-----|----| 680 MIP-Auth-Input- 338 4.8.2 Unsigned32 | M | P | | V | Y | 681 Data-Length | | | | | | 682 MIP- 339 4.8.3 Unsigned32 | M | P | | V | Y | 683 Authenticator-Length | | | | | | 684 MIP- 340 4.8.4 Unsigned32 | M | P | | V | Y | 685 Authenticator-Offset | | | | | | 686 MIP-Feature- 337 4.7 Unsigned32 | M | P | | V | Y | 687 Vector | | | | | | 688 MIP-Home-Agent- 334 4.4 Address | M | P | | V | Y | 689 Address | | | | | | 690 MIP-MN-AAA-Auth 322 4.8 Grouped | M | P | | V | Y | 691 MIP-MN-AAA-SPI 341 4.8.1 Unsigned32 | M | P | | V | Y | 692 MIP-Mobile-Node- 333 4.3 Address | M | P | | V | Y | 693 Address | | | | | | 694 MIP-Previous-FA- 336 4.6 Address | M | P | | V | Y | 695 Addr | | | | | | 696 MIP-Previous-FA- 335 4.5 OctetString| M | P | | V | Y | 697 NAI | | | | | | 698 MIP-Reg-Request 320 4.1 OctetString| M | P | | V | Y | 699 MIP-Reg-Reply 321 4.2 OctetString| M | P | | V | Y | 701 4.1 MIP-Reg-Request AVP 703 The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and 704 contains the Mobile IP Registration Request [4] sent by the Mobile 705 Node to the Foreign Agent. 707 4.2 MIP-Reg-Reply AVP 709 The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and 710 contains the Mobile IP Registration Reply [4] sent by the Home Agent 711 to the Foreign Agent. 713 4.3 MIP-Mobile-Node-Address AVP 715 The Mobile-Node-Address AVP (AVP Code 333) is of type Address and 716 contains the Mobile Node's Home Address. 718 4.4 MIP-Home-Agent-Address AVP 720 The Home-Agent-Addess AVP (AVP Code 334) is of type Address and 721 contains the Mobile Node's Home Agent Address. 723 4.5 MIP-Previous-FA-NAI AVP 725 The MIP-Previous-FA-NAI AVP (AVP Code 335) is of type OctetString and 726 contains the Network Access Identifier [6] of the Mobile Node's old 727 Foreign Agent. The Mobile Node MAY include this information in the 728 Registration Request when it moves its point of attachment to a new 729 foreign agent under the same administrative domain as the old FA 730 (identified by the realm portion of the NAI). 732 When this AVP is present in the AA-Mobile-Node-Request, it indicates 733 that the local Diameter server overseeing the Foreign Agent should 734 attempt to return the registration key that was previously allocated 735 to the old Foreign Agent for the Mobile Node. The registration key is 736 identified through the use of the MIP-Mobile-Node-Address AVP, which 737 MUST be present if this extension is present. 739 In many circumstances, this allows the Mobile Node to move from one 740 Foreign Agent to another within the same administrative domain 741 without having to send the request back to the Mobile Node's Home 742 Diameter Server (AAAH). 744 4.6 MIP-Previous-FA-Addr AVP 746 The MIP-Previous-FA-Addr AVP (AVP Code 336) is of type Address and 747 contains the IP Address of the Mobile Node's old Foreign Agent. The 748 Mobile Node MAY include this information in the Previous Foreign 749 Agent Notification Extension to the Mobile IP Registration Request 750 when it moves its point of attachment to a new foreign agent. 752 When this AVP is present in the AA-Mobile-Node-Request, it indicates 753 that the local Diameter server overseeing the Foreign Agent should 754 attempt to return the registration key that was previously allocated 755 to the old Foreign Agent for the Mobile Node. The registration key is 756 identified through the use of the MIP-Mobile-Node-Address AVP, which 757 MUST be present if this extension is present. 759 In many circumstances, this allows the Mobile Node to move from one 760 Foreign Agent to another within the same administrative domain 761 without having to send the request back to the Mobile Node's Home 762 Diameter Server (AAAH). 764 4.7 MIP-Feature-Vector AVP 766 The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and 767 is added with flag values set by the Foreign Agent or by the AAAF 768 owned by the same administrative domain as the Foreign Agent. The 769 Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR 770 message it sends to the AAAF. 772 Flag values currently defined include: 773 1 Mobile-Node-Home-Address-Requested 774 2 Home-Address-Allocatable-Only-in-Home-Domain 775 4 Home-Agent-Requested 776 8 Foreign-Home-Agent-Available 777 16 MN-HA-Key-Request 778 32 MN-FA-Key-Request 779 64 FA-HA-Key-Request 780 128 Home-Agent-In-Foreign-Network 782 The flags are set according to the following rules. 784 If the mobile node includes a valid home address (i.e., not equal to 785 0.0.0.0 or 255.255.255.255) in its Registration Request, the Foreign 786 Agent zeroes the Mobile-Node-Home-Address-Requested flag in the MIP- 787 Feature-Vector AVP. 789 If the mobile node sets the home address field equal to 0.0.0.0 in 790 its Registration Request, the Foreign Agent sets the Mobile-Node- 791 Home-Address-Requested flag to one, and zeroes the Home-Address- 792 Allocatable-Only-in-Home-Domain flag in the MIP-Feature-Vector AVP. 794 If the mobile node sets the home address field equal to 795 255.255.255.255 in its Registration Request, the Foreign Agent sets 796 both the Mobile-Node-Home-Address-Requested flag and the Home- 797 Address-Allocatable-Only-in-Home-Domain flag to one in the MIP- 798 Feature-Vector AVP. 800 If the mobile node sets the home agent field equal to 0.0.0.0 in its 801 Registration Request, the Foreign Agent sets the Home-Agent-Requested 802 flag to one in the MIP-Feature-Vector AVP. 804 Whenever the Foreign Agent sets either the Home-Address-Requested 805 flag or the Home-Agent-Request flag to one, it MUST also set the MN- 806 HA-Key-Request flag to one. 808 If the mobile node includes a Registration Key Request [15] extension 809 in its Registration Request, the Foreign Agent sets the MN-FA-Key- 810 Request flag to one in the MIP-Feature-Vector AVP. 812 If the mobile node requests a home agent in the foreign network, and 813 the AAAF authorizes the request, the AAAF MUST set the Home-Agent- 814 In-Foreign-Network bit to one. 816 The Foreign Agent MUST NOT set the FA-HA-Key-Request flag, Foreign- 817 Home-Agent-Available, and Home-Agent-In-Foreign-Network flag to one. 819 When the AAAF receives the AMR message, it MUST first verify that the 820 sender was an authorized Foreign Agent. The AAAF then takes any 821 actions indicated by the settings of the MIP-Feature-Vector AVP 822 flags. The AAAF then MAY set additional flags. Only the AAAF may 823 set the FA-HA-Key-Request flag or the Foreign-Home-Agent-Available 824 flag to one. This is done according to local administrative policy. 825 When the AAAF has finished setting additional flags according to its 826 local policy, then the AAAF transmits the AMR with the possibly 827 modified MIP-Feature-Vector AVP to the AAAH. 829 4.8 MIP-MN-AAA-Auth AVP 831 The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains 832 some ancillary data to simplify processing of the authentication data 833 in the Mobile IP Registration Request [4] by the target AAA server. 834 Its value has the following ABNF grammar: 836 MIP-MN-AAA-Auth = ma-spi authinlen authlen authoffset 837 ma-spi = ; MIP-MN-AAA-SPI, See Section 4.8.1 838 authinlen = ; MIP-Auth-Input-Data-Length, / 839 ; See Section 4.8.2 840 authlen = ; MIP-Authenticator-Length, / 841 ; See Section 4.8.3 842 authoffset = ; MIP-Authenticator-Offset, / 843 ; See Section 4.8.4 845 +---------------------------------------------------------------+ 846 | AVP Header (AVP Code = 322) | 847 +---------------------------------------------------------------+ 848 | MIP-MN-AAA-SPI AVP | 849 +---------------------------------------------------------------+ 850 | MIP-Auth-Input-Data-Length AVP | 851 +---------------------------------------------------------------+ 852 | MIP-Authenticator-Length AVP | 853 +---------------------------------------------------------------+ 854 | MIP-Authenticator-Offset AVP | 855 +---------------------------------------------------------------+ 857 4.8.1 MIP-MN-AAA-SPI AVP 858 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 859 indicates the algorithm by which the targeted AAA server (AAAH) 860 should attempt to validate the Authenticator computed by the mobile 861 node over the Registration Request data. 863 4.8.2 MIP-Auth-Input-Data-Length AVP 865 The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type 866 Unsigned32 and contains the length, in bytes, of the Registration 867 Request data (data portion of MIP-Reg-Request AVP) that should be 868 used as input to the algorithm (indicated by the MN-AAA-SPI AVP) used 869 to determine whether the Authenticator Data supplied by the Mobile 870 Node is valid. 872 4.8.3 MIP-Authenticator-Length AVP 874 The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32 875 and contains the length of the authenticator to be validated by the 876 targeted AAA server (i.e., AAAH). 878 4.8.4 MIP-Authenticator-Offset AVP 880 The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32 881 and contains the offset into the Registration Request Data, of the 882 authenticator to be validated by the targeted AAA server (i.e., 883 AAAH). 885 5.0 Key Distribution Center 887 The mobile node and mobility agents use registration keys to compute 888 authentication extensions applied to registration messages, as 889 defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If 890 registration keys are requested the AAA server(s) MUST create them 891 after the Mobile Node is successfully authenticated and authorized. 893 The keys destined for each mobility entity are encrypted either using 894 the secret shared with the entity [1], or via its public key [9], as 895 indicated by the relevant security association. If the AAAH does not 896 communicate directly with the Foreign Agent, those keys are encrypted 897 using the security association shared with the AAAF. The 898 Authorization-Lifetime AVP contains the number of seconds before 899 registration keys destined for the Home Agent and/or Foreign Agent 900 expire. Absence or the AVP, or a value of zero indicates infinity 901 (no timeout). 903 AAA support for key distribution departs slightly from the existing 904 SPI usage, as described in [4]. The SPI values are used as key 905 identifiers, meaning that each registration key has its own SPI 906 value; nodes that share a key also share an SPI. If no preferred SPI 907 value is indicated the registration keys the foreign agent needs, the 908 AAA server MAY generate SPI values for the Mobility Agents as opposed 909 to the receiver choosing its own SPI value. For example, suppose a 910 Mobile Node and a Foreign Agent share a key that was generatied by 911 AAAH with a corresponding SPI value of 37,496. All Mobile-Foreign 912 Authentication extensions will be computed by either entity (in this 913 example) using the shared key and MUST include the SPI value of 914 37,496. 916 Once the registration keys have been distributed, subsequent Mobile 917 IP registrations need not invoke the AAA infrastructure until the 918 keys expire. These registrations MUST include the Mobile-Home 919 authentication extension. In addition, subsequent registrations MUST 920 also include Mobile-Foreign authentication extension if the Mobile- 921 Foreign key was generated and distributed by AAA; similarly for 922 subsequent use of the Foreign-Home authentication extensions. 924 Each registration key that is generated by AAA will generally be 925 distributed to two parties; for instance, a Mobile-Foreign key goes 926 to both a mobile node and a foreign agent. The methods by which the 927 key is encoded will depend upon the security associations available 928 to the AAA server and each recipient of the key. These methods will 929 often be different for the two recipients, so that the registration 930 key under consideration has to be encoded twice. 932 See sections 6.1 and 6.2 for details about the format of the AVPs 933 used to distribute the registration keys. 935 5.1 Distributing the Mobile-Home Registration Key 937 If the mobile node does not have a Mobile-Home registration key, then 938 the AAAH is likely to be the only entity trusted that is available to 939 the mobile node. Thus, the AAAH has to generate the Mobile-Home 940 registration key, and encode it for eventual consumption by the 941 mobile node and home agent. 943 If the home agent is in the home domain, then AAAH can directly 944 encode the Mobile-Home registration key into a MIP-HA-to-MN-Key AVP 945 and include that AVP in the HAR message for delivery to the home 946 agent. 948 If, on the other hand, the home agent is to be allocated in the 949 visited domain, the AAAH does not transmit the HAR to the home agent. 951 Instead, AAAH has to include the MIP-HA-to-MN-Key AVP in the AMR 952 message which it sends to the AAAF. In this latter case, the 953 Mobile-Home registration key is encoded into MIP-HA-to-MN-Key AVP 954 using the method indicated by the security association between the 955 AAAF and the AAAH. When the AAAF receives the AMR, it first allocates 956 a home agent, and then creates a HAR message for that home agent. 957 After the AAAF decodes the registration key, it re-encodes the key 958 into a new MIP-HA-to-MN-Key AVP which is to be included within the 959 HAR message. 961 The AAAH also has to arrange for the key to be delivered to the 962 mobile node. Unfortunately, the AAA server only knows about Diameter 963 messages and AVPs, and the mobile node only knows about Mobile IP 964 messages and extensions[4]. The AAA server has to rely on a mobility 965 agent (that also understands Diameter) to transfer the key into a 966 Mobile IP MN-HA Key Reply extension to the Registration Reply 967 message. This mobility agent (actually, the mobile node's home 968 agent) can format the Reply message and extensions correctly for 969 eventual delivery to the mobile node, by way of an AMA message sent 970 to the appropriate foreign agent in the visited domain. That foreign 971 agent will use the information in the MIP-Reg-Reply AVP to create a 972 Mobile IP Registration Reply message, containing the MN-HA Key Reply 973 extension, and transmit it to the mobile node. 975 For this purpose, AAAH encodes the Mobile-Home registration key into 976 a MIP-MN-to-HA-Key AVP, using its security association with the 977 mobile node. If the home agent is in the home domain, AAAH puts the 978 MIP-MN-to-HA-Key AVP into the HAR message. Otherwise, the AAAH puts 979 the MIP-MN-to-HA-Key AVP into the AMR message which will be sent back 980 to AAAF. When AAAF creates the HAR message for the home agent in the 981 visited domain, and decodes the registration key in the MIP-HA-to- 982 MN-Key AVP from the AVP received from AAAH, AAAF then recodes the 983 registration key into a new MIP-HA-to-MN-Key AVP which is to be 984 included as part of the HAR message. In either case, the home agent 985 creates a Registration Reply with the MN-HA Key Reply extension, and 986 formats the reply data into a MIP-Reg-Rep-AVP for delivery in a HAA 987 message to the AAA server. After the HAA message is parsed by the AAA 988 server, the AMA message containing the MIP-Reg-Rep AVP will 989 eventually be received by the attendant (i.e., the foreign agent). 990 The foreign agent can then use that AVP to recreate a Registration 991 Reply message, containing the MN-HA Key Reply extension, for delivery 992 to the mobile node. 994 In summary, the AAAH generates the Mobile-Home registration key and 995 encodes it into a MIP-HA-to-MN-Key AVP and a MIP-MN-to-HA-Key AVP. 996 These AVPs are delivered to a home agent by including them in a HAR 997 message sent from either AAAH or AAAF. The home agent decodes the key 998 for its own use. The home agent also copies the encoded registration 999 key from the MIP-MN-to-HA-Key AVP into a MN-HA Key Reply extension 1000 appended to the Mobile IP Registration Reply message. This 1001 Registration Reply message MUST also include the Mobile-Home 1002 authentication extension, created using the newly allocated Mobile- 1003 Home registration key. The home agent then encodes the Registration 1004 Reply message and extensions into a MIP-Reg-Reply AVP included as 1005 part of the HAA message to be sent back to the AAA server. 1007 5.2 Distributing the Mobile-Foreign Registration Key 1009 The Mobile-Foreign registration key is also generated by AAAH (upon 1010 request), so that it can be encoded into a MIP-MN-to-FA-Key AVP and 1011 copied by the home agent into a "General MN-FA Key Reply Extension" 1012 extension [15] to the Mobile IP Registration Reply message. Since the 1013 foreign agent is in the same administrative domain as AAAF, the 1014 sequence of events for handling the MIP-FA-to-MN-Key AVP is similar 1015 to the way the MIP-HA-to-MN-Key AVP is handled when the home agent is 1016 allocated in the visited domain. Most of the other considerations for 1017 distributing the Mobile-Foreign registration key are also similar. 1019 When the home agent is in the home domain, AAAH includes the MIP-MN- 1020 to-FA-Key AVP in the HAR message. Otherwise, AAAH includes the MIP- 1021 MN-to-FA-Key AVP in the AMR message to be sent back to the AAAF. In 1022 the latter case, AAAF sends the HAR message to the (newly allocated) 1023 home agent. 1025 In either case, the home agent decodes the key, and recodes it into 1026 the key reply extension to the Mobile IP registration message. Then 1027 the home agent (as before) copies the Registration Reply message into 1028 the MIP-Reg-Reply AVP and places the result (possibly also containing 1029 the MN-HA Key Reply extension as in section 1.4.1) into the HAA 1030 message to be sent back to the AAA server. The home agent MUST also 1031 append a Foreign-Home authentication extension to the Registration 1032 Reply message, using the newly allocated Foreign-Home registration 1033 key. 1035 When the home agent is in the home domain, AAAH receives the HAA, and 1036 then includes the MIP-Reg-Reply AVP in the AMA message to be sent to 1037 AAAF. Otherwise, AAAF receives the HAA, and inserts it into an AMA 1038 message to be sent to the foreign agent. 1040 AAAH also has to make the Mobile-Foreign registration key available 1041 to AAAF. It does this by encoding the key into a MIP-FA-to-MN-Key 1042 AVP, using its security association with AAAF, and placing the 1043 results in the AMA. Then the AAAF decodes the registration key, and 1044 recodes it into a newly formulated MIP-FA-to-MN-Key AVP which is to 1045 be sent to the foreign agent in the AMA message containing the MIP- 1046 Reg-Reply AVP from the home agent. 1048 5.3 Distributing the Foreign-Home Registration Key 1050 If the home agent is in the home domain, then AAAH has to generate 1051 the Foreign-Home registration key. Otherwise, it is generated by 1052 AAAF. 1054 In the former case, AAAH encodes the registration key into a MIP-HA- 1055 to-FA-Key AVP and includes that AVP as part of the HAR message sent 1056 to the home agent, and waits for the HAA message to be returned. 1058 Whether or not AAAH sends the HAR message, it also further encodes 1059 the same registration key and puts it into a MIP-FA-to-HA-Key AVP 1060 included as part of the AMA message to be transmitted back to AAAF. 1062 If the home agent is in the visited domain, the AAAH includes the 1063 MIP-HA-to-FA-Key AVP as part of the AMR also. In this case, AAAF has 1064 to decode the Foreign-Home registration key and include it as part of 1065 the HAR message to be sent to the (newly allocated) home agent. 1067 In either case, AAAF sends a AMA message, containing a MIP-Reg-Reply 1068 AVP and the MIP-FA-to-HA-Key AVP, to the foreign agent. First, the 1069 foreign agent recreates the necessary Registration Reply message from 1070 the AMA message. Then the foreign agent recovers the Foreign-Home 1071 registration key, using its security association with AAAF. The 1072 foreign agent MUST then use this key to create a Mobile-Foreign 1073 authentication extension to the Registration Reply message. 1075 5.4 Key Distribution Example 1077 Figure 6 provides an example of subsequent Mobile IP message 1078 exchange, assuming that AAAH distributed registration keys for all 1079 three MN-FA, FA-HA and HA-MN authentication extensions. 1081 Mobile Node Foreign Agent Home Agent 1082 ----------- ------------- ---------- 1084 Reg-Req(MN-HA-Auth, MN-FA-Auth)--------> 1086 Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> 1088 <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) 1090 <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) 1092 Figure 6: Mobile IP Message Exchange 1094 6.0 Key Distribution Center (KDC) AVPs 1096 The Mobile-IP protocol defines a set of security associations shared 1097 between the Mobile Node, Foreign Agent and Home Agents. These three 1098 security associations (Mobile-Home, Mobile-Foreign, and Foreign- 1099 Home), can be dynamically created by the AAAH. This requires that the 1100 AAAH create Mobile-IP Registration Keys, and that these keys be 1101 distributed to the three mobile entities, via the Diameter Protocol. 1102 AAA servers supporting the Diameter Mobile IP Extension MUST 1103 implement the KDC AVPs defined in this document. In other words, AAA 1104 servers MUST be able to create three registration keys: the Mobile- 1105 Home, Mobile-Foreign, and Foreign-Home keys. 1107 Each of these keys is encrypted two different ways, as needed for 1108 each key recipient. The mobile node and home agent registration keys 1109 are sent to the Home Agent, while the foreign agent's keys are sent 1110 to the foreign agent via the AAAF. This leads to six different AVPs, 1111 since there are three keys, and each one has to be able to be 1112 encrypted in two different ways. 1114 The names of the KDC AVPs indicate the two entities sharing the 1115 security association defined by the encrypted key material; the 1116 intended receiver of the AVP is the first named entity. So, for 1117 instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key 1118 encrypted in a way that allows it to be recovered by the mobile node. 1120 If strong authentication and confidentiality of the registration keys 1121 is required, it is recommended that the strong security extension [9] 1122 be used. 1124 The following table describes the Diameter AVPs defined in the Mobile 1125 IP extension, their AVP Code values, types, possible flag values and 1126 whether the AVP MAY be encrypted. 1128 +---------------------+ 1129 | AVP Flag rules | 1130 |----+-----+----+-----|----+ 1131 AVP Section | | |SHLD| MUST|MAY | 1132 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1133 -----------------------------------------|----+-----+----+-----|----| 1134 MIP-FA-to-MN-Key 326 6.2.1 Grouped | M | P | | V | Y | 1135 MIP-FA-to-HA-Key 328 6.2.2 Grouped | M | P | | V | Y | 1136 MIP-HA-to-FA-Key 329 6.2.3 Grouped | M | P | | V | Y | 1137 MIP-HA-to-MN-Key 332 6.2.4 Grouped | M | P | | V | Y | 1138 MIP-MN-to-FA-Key 325 6.1.1 OctetString| M | P | | V | Y | 1139 MIP-MN-to-HA-Key 331 6.1.2 OctetString| M | P | | V | Y | 1140 MIP-Peer-SPI 342 6.2.5 Unsigned32 | M | P | | V | Y | 1141 MIP-FA-MN- 324 6.3 Unsigned32 | M | P | | V | Y | 1142 Preferred-SPI | | | | | | 1143 MIP-FA-HA- 327 6.4 Unsigned32 | M | P | | V | Y | 1144 Preferred-SPI | | | | | | 1145 MIP-Session-Key 343 6.2.6 OctetString| M | P | | V | Y | 1147 6.1 Mobile Node Registration Keys 1149 When the AAAH acts as a Key Distribution Center, and it is determined 1150 that keying material is to be created for Mobile Nodes, the AAAH 1151 creates the keys and encodes them in the MIP-MN-to-FA-Key and MIP- 1152 MN-to-HA-Key AVPs as opaque data. The actual format of the AVP value 1153 is described in [15], and would contains the data immediately 1154 following the Mobile IP extension header. 1156 The Mobile IP key described in [15] refers to the AAA SPI, which MUST 1157 be set to the value the AAAH shares with the Mobile Node. The Key 1158 Lifetime field is set to the same value as the one found in the 1159 Authorization-Lifetime AVP. 1161 6.1.1 MIP-MN-to-FA-Key AVP 1163 The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type OctetString, and 1164 contains the Keying material described in the "Unsolicited MN-FA Key 1165 from AAA Subtype" in [15]. The FA SPI field of the data structure in 1166 [15] MUST be set to the same value as the Peer-SPI AVP within the 1167 FA-to-MN-Key AVP. 1169 6.1.2 MIP-MN-to-HA-Key AVP 1171 The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type OctetString, and 1172 contains the Keying material described in the "Unsolicited MN-HA Key 1173 from AAA Subtype" in [15]. The HA SPI field of the data structure in 1174 [15] MUST be set to the same value as the Peer-SPI AVP within the 1175 HA-to-MN-Key AVP. 1177 6.2 Mobility Agent Session Keys 1179 The Mobility Agent session keys are the keys created by a Diameter 1180 server, which it distributes to Foreign and Home Agents, acting as 1181 Diameter clients. These session keys, described below, are of type 1182 Grouped, and therefore their value have the following ABNF format: 1184 Mobility Agent Session Key AVP = Peer-SPI Session-Key 1185 Peer-SPI = ; MIP-Peer-SPI, See Section 6.2.5 1186 Session-Key = ; MIP-Session-Key, See Section 6.2.6 1188 The MIP-Peer-SPI AVP contains the Security Parameter Index, which the 1189 Mobility Agent MUST use to refer to the Key contained in the MIP- 1190 Session-Key AVP. 1192 +---------------------------------------------------------------+ 1193 | AVP Header (AVP Code = see below) | 1194 +---------------------------------------------------------------+ 1195 | MIP-Peer-SPI AVP | 1196 +---------------------------------------------------------------+ 1197 | MIP-Session-Key AVP | 1198 +---------------------------------------------------------------+ 1200 6.2.1 MIP-FA-to-MN-Key AVP 1202 The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and 1203 contains the Foreign Agent's session key, which it shares with the 1204 Mobile Node. Its format is described in Section 6.2. 1206 6.2.2 MIP-FA-to-HA-Key AVP 1208 The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and 1209 contains the Foreign Agent's session key, which it shares with the 1210 Home Agent. Its format is described in Section 6.2. 1212 6.2.3 MIP-HA-to-FA-Key AVP 1214 The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and 1215 contains the Home Agent's session key, which it shares with the 1216 Foreign Agent. Its format is described in Section 6.2. 1218 6.2.4 MIP-HA-to-MN-Key AVP 1220 The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and 1221 contains the Home Agent's session key, which it shares with the 1222 Mobile Node. Its format is described in Section 6.2. 1224 6.2.5 MIP-Peer-SPI AVP 1226 The MIP-Peer-SPI AVP (AVP Code 342) is of type Unsigned32, and 1227 contains the Security Parameter Index to use to reference the key in 1228 the associated MIP-Session-Key AVP. 1230 6.2.6 MIP-Session-Key AVP 1232 The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 1233 contains the Session Key to be used between two Mobile IP entities. 1235 6.3 MIP-FA-MN-Preferred-SPI AVP 1237 The MIP-FA-MN-Preferred-SPI AVP (AVP Code 324) is of type Unsigned32 1238 and is sent in the AA-Mobile-Node-Request by the Foreign Agent. The 1239 AVP contains the SPI that the Foreign Agent would prefer to have 1240 assigned by the AAAH in the MIP-FA-to-MN-Key AVP. 1242 6.4 MIP-FA-HA-Preferred-SPI AVP 1244 The MIP-FA-HA-Preferred-SPI AVP (AVP Code 324) is of type Unsigned32 1245 and is sent in the AA-Mobile-Node-Request by the Foreign Agent. The 1246 AVP contains the SPI that the Foreign Agent would prefer to have 1247 assigned by the AAAH in the MIP-FA-to-HA-Key AVP. 1249 7.0 Accounting Considerations 1251 This section contains the AVPs defined in this extension that are to 1252 be present in the Accounting-Request and optionally in the 1253 Accounting-Answer messages, defined in [12]. 1255 ::= { MIP-Mobile-Node-Address } 1256 { MIP-Home-Agent-Address } 1257 [ MIP-Previous-FA-NAI ] 1258 [ MIP-Previous-FA-Address ] 1259 [ MIP-Feature-Vector ] 1261 8.0 Interactions with Resource Management 1263 The Resource Management extension [17] provides the ability for a 1264 Diameter node to query a peer for session state information. The 1265 document states that service-specific extensions are responsible for 1266 specifying what AVPs are to be present in the Resource-Token [17] 1267 AVP. 1269 In addition to the AVPs listed in [17], the Resource-Token with the 1270 Extension-Id AVP set to four (4) MUST include the MIP-Mobile-Node- 1271 Address and the MIP-Home-Agent-Address AVP. 1273 9.0 AVP Table 1275 The following table presents the AVPs defined in this document, and 1276 specifies in which Diameter messages they MAY, or MAY NOT be present. 1277 Note that AVPs that can only be present within a Grouped AVP are not 1278 represented in this table. 1280 The table uses the following symbols: 1281 0 The AVP MUST NOT be present in the message. 1282 0+ Zero or more instances of the AVP MAY be present in the 1283 message. 1284 0-1 Zero or one instance of the AVP MAY be present in the 1285 message. 1286 1 One instance of the AVP MUST be present in the message. 1288 +-----------------------------+ 1289 | Command-Code | 1290 |-----+-----+-----+-----+-----+ 1291 Attribute Name | AMR | AMA | HAR | HAA | HAI | 1292 ------------------------------|-----+-----+-----+-----+-----| 1293 Authorization-Lifetime | 1 | 1 | 1 | 1 | 1 | 1294 Host-Name | 1 | 1 | 1 | 1 | 1 | 1295 Integrity-Check-Value | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 1296 MIP-FA-to-HA-Key | 0 | 0-1 | 0-1 | 0-1 | 0 | 1297 MIP-FA-to-MN-Key | 0 | 0-1 | 0-1 | 0-1 | 0 | 1298 MIP-Feature-Vector | 0-1 | 0 | 0 | 0 | 0 | 1299 MIP-FA-HA-Preferred-SPI | 0-1 | 0 | 0 | 0 | 0 | 1300 MIP-FA-MN-Preferred-SPI | 0-1 | 0 | 0 | 0 | 0 | 1301 MIP-HA-to-FA-Key | 0 | 0 | 0-1 | 0 | 0 | 1302 MIP-HA-to-MN-Key | 0 | 0 | 0-1 | 0 | 0 | 1303 MIP-Home-Agent-Address | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 1304 MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 | 0 | 1305 MIP-MN-to-FA-Key | 0 | 0 | 0-1 | 0 | 0 | 1306 MIP-MN-to-HA-Key | 0 | 0-1 | 0-1 | 0 | 0 | 1307 MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 1308 MIP-Previous-FA-Address | 0-1 | 0 | 0 | 0 | 0 | 1309 MIP-Previous-FA-NAI | 0-1 | 0 | 0 | 0 | 0 | 1310 MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 | 0 | 1311 MIP-Reg-Request | 1 | 0 | 1 | 0 | 0 | 1312 Proxy-State | 0+ | 0+ | 0+ | 0+ | 0+ | 1313 Result-Code | 0 | 1 | 0 | 1 | 0 | 1314 Route-Record | 0+ | 0+ | 0+ | 0+ | 0+ | 1315 Routing-Realm | 0+ | 0+ | 0+ | 0+ | 0+ | 1316 Session-Id | 1 | 1 | 1 | 1 | 1 | 1317 Session-Timeout | 0 | 1 | 1 | 1 | 1 | 1318 User-Name | 1 | 0 | 1 | 0 | 0 | 1319 ------------------------------|-----+-----+-----+-----+-----| 1321 10.0 Acknowledgements 1323 The authors would like to thank Nenad Trifunovic and Pankaj Patel for 1324 their participation in the Document Reading Party, to Erik Guttman 1325 for his very useful proposed text, and to Tony Johansson for the 1326 proposed text AND being in the doc reading party. The authors would 1327 also like to thank the participants of 3GPP2's TSG-P working group 1328 for their valuable feedback. 1330 11.0 IANA Considerations 1332 The command codes defined in Section 2.0 are values taken from the 1333 Command-Code [1] address space and extended in [9], [12] and [14]. 1335 IANA should record the values as defined in Section 2.0. 1337 The Result-Code values defined in Section 3.0 are error codes as 1338 defined in [1] and extended in [9], [12] and [14]. They correspond to 1339 error values specific to the Mobile IP extension. IANA should record 1340 the values as defined in Section 3.0. 1342 The AVPs defined in sections 4.0 and 6.0 were allocated from the AVP 1343 numbering space defined in [1], and extended in [9], [12] and [14]. 1344 IANA should record the values as defined in Sections 4.0 and 6.0. 1346 12.0 Security Considerations 1348 This specification describes the Diameter extension necessary to 1349 authenticate and authorize a Mobile IP Mobile Node. The 1350 authentication algorithm used is dependent upon the transforms 1351 available by the Mobile IP protocol, and [5]. This specification also 1352 defines a method by which the home Diameter server can create and 1353 distribute registration keys to be used to authenticate Mobile IP 1354 registration messages. The keys are distributed in an encrypted 1355 format through the Diameter protocol, and SHOULD be encrypted using 1356 the methods defined in [9]. 1358 13.0 References 1360 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "Diameter Base 1361 Protocol", draft-ietf-aaa-diameter-00.txt, IETF work in pro- 1362 gress, February 2001. 1364 [2] Calhoun, Zorn, Pan, Akhtar, "Diameter Framework", draft-calhoun- 1365 diameter-framework-09.txt, IETF work in progress, February 2001. 1367 [3] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 1368 Authorization, and Accounting Requirements". RFC 2977. October 1369 2000. 1371 [4] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. 1373 [5] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Exten- 1374 sions". RFC 3012. November 2000. 1376 [6] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486. 1377 January 1999. 1379 [7] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 1380 RFC 2477, January 1999. 1382 [8] P. Calhoun, C. Perkins, "Mobile IP Network Address Identifier 1383 Extension", RFC 2794, March 2000. 1385 [9] P. Calhoun, W. Bulley, S. Farrell, "Diameter Strong Security 1386 Extensions", draft-calhoun-diameter-strong-crypto-06.txt, IETF 1387 work in progress, February 2001. 1389 [10] Kent, Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1390 2406, November 1998. 1392 [11] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1393 Levels", BCP 14, RFC 2119, March 1997. 1395 [12] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "Diameter Accounting 1396 Extension", draft-ietf-aaa-diameter-accounting-00.txt, IETF work 1397 in progress, February 2001. 1399 [13] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing 1400 for Message Authentication. RFC 2104, February 1997. 1402 [14] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ 1403 Extension", draft-ietf-aaa-diameter-nasreq-00.txt, IETF work in 1404 progress, February 2001. 1406 [15] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", 1407 draft-calhoun-mobileip-aaa-key-03.txt, IETF work in progress, 1408 January 2001. 1410 [16] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", 1411 draft-hiller-cdma2000-aaa-01.txt, IETF work in progress, June 1412 2000. 1414 [17] P. Calhoun, "Diameter Resource Management", draft-calhoun- 1415 diameter-res-mgmt-06.txt, IETF Work in Progress, February 2001. 1417 14.0 Authors' Addresses 1419 Questions about this memo can be directed to: 1421 Pat R. Calhoun 1422 Network and Security Research Center, Sun Labs 1423 Sun Microsystems, Inc. 1424 15 Network Circle 1425 Menlo Park, California, 94025 1426 USA 1428 Phone: +1 650-786-7733 1429 Fax: +1 650-786-6445 1430 E-mail: pcalhoun@eng.sun.com 1432 Charles E. Perkins 1433 Nokia Research Center 1434 313 Fairchild Drive 1435 Mountain View, California 94043 1436 USA 1438 Phone: +1 650-625-2986 1439 Fax: +1 650-625-2502 1440 E-Mail: charliep@iprg.nokia.com 1442 15.0 Full Copyright Statement 1444 Copyright (C) The Internet Society (2001). All Rights Reserved. 1446 This document and translations of it may be copied and furnished to 1447 others, and derivative works that comment on or otherwise explain it 1448 or assist in its implementation may be prepared, copied, published 1449 and distributed, in whole or in part, without restriction of any 1450 kind, provided that the above copyright notice and this paragraph are 1451 included on all such copies and derivative works. However, this docu- 1452 ment itself may not be modified in any way, such as by removing the 1453 copyright notice or references to the Internet Society or other 1454 Internet organizations, except as needed for the purpose of develop- 1455 ing Internet standards in which case the procedures for copyrights 1456 defined in the Internet Standards process must be followed, or as 1457 required to translate it into languages other than English. The lim- 1458 ited permissions granted above are perpetual and will not be revoked 1459 by the Internet Society or its successors or assigns. This document 1460 and the information contained herein is provided on an "AS IS" basis 1461 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1462 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1463 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1464 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1465 FITNESS FOR A PARTICULAR PURPOSE. 1467 16.0 Expiration Date 1469 This memo is filed as and 1470 expires in July 2001.