idnits 2.17.1 draft-ietf-aaa-diameter-mobileip-12.txt: -(2055): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2058): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2129): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2132): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2135): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2139): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 10 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 52 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 53 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 18 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A home AAA server (AAAH) and foreign AAA server (AAAF), which support the Mobile-IP authentication application MAY maintain session-state or MAY be session-stateless. AAA redirect agents and AAA relay agents MUST not maintain session-state. The AAAH, AAAF, proxies and relays agents MUST maintain transaction state. == 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 tables 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 (August 2002) is 7917 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) == Missing Reference: 'AAAKEY' is mentioned on line 1986, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-12 ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3220 (ref. 'MOBILEIP') (Obsoleted by RFC 3344) ** Obsolete normative reference: RFC 3012 (ref. 'MIPCHAL') (Obsoleted by RFC 4721) ** Obsolete normative reference: RFC 2486 (ref. 'NAI') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-aaa-key-09 -- Possible downref: Normative reference to a draft: ref. 'MIPKEYS' -- No information found for draft-mobileip-aaa-nai - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AAANAI' -- Unexpected draft version: The latest known version of draft-ietf-aaa-diameter-cms-sec is -04, but you're referring to -05. (However, the state information for draft-mobileip-aaa-nai is not up-to-date. The last update was unsuccessful) -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 8 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 Black Storm Networks 4 Category: Standards Track Tony Johansson 5 Ericsson Inc 6 Charles E. Perkins 7 Nokia Research Center 8 August 2002 10 Diameter Mobile IPv4 Application 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC 2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Distribution of this memo is unlimited. 35 Copyright (C) The Internet Society 2002. All Rights Reserved. 37 Abstract 39 This document specifies a Diameter application that allows a Diameter 40 server to authenticate, authorize and collect accounting information 41 for Mobile IPv4 services rendered to a mobile node. Combined with 42 the Inter-Realm capability of the base protocol, this application 43 allows mobile nodes to receive service from foreign service 44 providers. Diameter Accounting messages will be used by the foreign 45 and home agents to transfer usage information to the Diameter 46 servers. 48 Table of Contents 50 1.0 Introduction 51 1.1 Requirements language 52 1.2 Inter-Realm Mobile IP 53 1.3 Support for Mobile IP Handoffs 54 1.4 Allocation of Home Agent in Foreign Network 55 1.5 Co-located Mobile Node 56 1.6 Key Distribution Center (KDC) 57 1.7 Diameter Session Termination 58 1.8 Advertising Application support 59 1.9 Fast Handoff support 60 1.10 Packet filtering support 61 2.0 Command-Code Values 62 2.1 AA-Mobile-Node-Request 63 2.2 AA-Mobile-Node-Answer 64 2.3 Home-Agent-MIP-Request 65 2.4 Home-Agent-MIP-Answer 66 3.0 Result-Code AVP Values 67 3.1 Transient Failures 68 3.2 Permanent Failures 69 4.0 Diameter AVPs 70 4.1 MIP-Reg-Request AVP 71 4.2 MIP-Reg-Reply AVP 72 4.3 MIP-Mobile-Node-Address AVP 73 4.4 MIP-Home-Agent-Address AVP 74 4.5 MIP-Feature-Vector AVP 75 4.6 MIP-MN-AAA-Auth AVP 76 4.6.1 MIP-MN-AAA-SPI AVP 77 4.6.2 MIP-Auth-Input-Data-Length AVP 78 4.6.3 MIP-Authenticator-Length AVP 79 4.6.4 MIP-Authenticator-Offset AVP 80 4.7 MIP-FA-Challenge AVP 81 4.8 MIP-Filter-Rule AVP 82 4.9 MIP-Candidate-Home-Agent-Host 83 4.10 MIP-Originating-Foreign-AAA AVP 84 4.11 MIP-Home-Agent-Host AVP 85 5.0 Key Distribution Center 86 5.1 Authorization Lifetime vs. MIP Key Lifetime 87 5.2 Key Material vs. Session Key 88 5.3 Distributing the Mobile-Home Session Key 89 5.4 Distributing the Mobile-Foreign Session Key 90 5.5 Distributing the Foreign-Home Session Key 91 5.6 Key Distribution Example 92 6.0 Key Distribution Center (KDC) AVPs 93 6.1 MIP-FA-to-MN-Key AVP 94 6.2 MIP-FA-to-HA-Key AVP 95 6.3 MIP-HA-to-FA-Key AVP 96 6.4 MIP-HA-to-MN-Key AVP 97 6.5 MIP-MN-to-FA-Key AVP 98 6.6 MIP-MN-to-HA-Key AVP 99 6.7 MIP-Session-Key AVP 100 6.8 MIP-Algorithm-Type AVP 101 6.9 MIP-Replay-Mode AVP 102 6.10 MIP-FA-to-MN-SPI 103 6.11 MIP-FA-to-HA-SPI 104 6.12 MIP-Key-Material AVP 105 6.13 MIP-Key-Lifetime AVP 106 7.0 Accounting AVPs 107 7.1 Accounting-Input-Octets AVP 108 7.2 Accounting-Output-Octets AVP 109 7.3 Acct-Session-Time AVP 110 7.4 Accounting-Input-Packets AVP 111 7.5 Accounting-Output-Packets AVP 112 7.6 Event-Timestamp AVP 113 8.0 AVP Table 114 8.1 Mobile IP Command AVP Table 115 8.2 Accounting AVP Table 116 9.0 IANA Considerations 117 9.1 Command Codes 118 9.2 AVP Codes 119 9.3 Result-Code AVP Values 120 9.4 MIP-Feature-Vector AVP Values 121 9.5 MIP-Algorithm-Type AVP Values 122 9.6 MIP-Replay-Mode AVP Values 123 9.7 Application Identifier 124 10.0 Security Considerations 125 11.0 References 126 11.1 Normative 127 11.2 Informative 128 12.0 Acknowledgements 129 13.0 Authors' Addresses 130 14.0 Full Copyright Statement 131 15.0 Expiration Date 133 1.0 Introduction 135 Mobile IP, as defined in [MOBILEIP], defines a method that allows a 136 mobile node to change its point of attachment to the Internet with 137 minimal service disruption. Mobile IP does not provide any specific 138 support for mobility across disparate administrative domains, and 139 therefore does not specify how usage can be accounted for, which has 140 limited the applicability of Mobile IP in a IPv4 commercial 141 deployment. The Mobile IP specification as defined in [MOBILEIP] 142 recommends mobile nodes to have a static home address and a home 143 agent. However this may not be always possible in certain deployment 144 scenarios. Recent developments in areas that impact IP mobility in 145 the IETF allow Mobile IP [MOBILEIP] to work just as well when mobile 146 nodes do not have a static home agent and home address. In addition, 147 another specification [MIPNAI] allows a mobile node to use its NAI 148 instead of its home address, which better accommodates current 149 administrative practice. 151 This document specifies an Application of 4 to the Diameter base 152 protocol [DIAMBASE] that allows a Diameter server to authenticate, 153 authorize and collect accounting information for Mobile IPv4 services 154 rendered to a mobile node. This application MUST NOT be used in 155 conjunction with the Mobile IPv6 protocol. 157 Combined with the Inter-Realm capability of the Diameter base 158 protocol, this application allows mobile nodes to receive service 159 from foreign service providers. The Diameter Accounting messages will 160 be used by the foreign and home agents to transfer usage information 161 to the Diameter servers. 163 The Mobile IP protocol [MOBILEIP] specifies a security model that 164 requires that mobile nodes and home agents share a pre-existing 165 security association, which leads to scaling and configuration 166 issues. This specification defines Diameter functions that allow the 167 AAA server to act as a Key Distribution Center (KDC), whereby dynamic 168 session keys are created and distributed to the mobility entities for 169 the purposes of securing Mobile IP Registration messages. 171 Strong authentication and confidentiality of session keys is 172 required, and it is recommended to be provided using the CMS security 173 application [CMS], but may be provided via other security mechanisms, 174 e.g. using mutually authenticated TLS or IPsec, when deployed in an 175 environment without Diameter agents, then hop-by-hop security is 176 sufficient for protecting session keys. (It should be noted that the 177 CMS security application is referenced as informative in this 178 application and the usage is only a recommendation.) However, if a 179 home AAA server is explicitly configured to need the CMS security 180 application for this domain/transaction then it will not proceed 181 without it, that is, the requested service MUST fail if CMS isn't 182 available. 184 As with the Diameter base protocol, AAA servers implementing the 185 Mobile IP application can process users' identities supplied in a 186 Network Access Identifier (NAI) format [NAI], which is used for 187 Diameter message routing purposes. Mobile nodes include their NAI in 188 Registration messages, as defined in [MIPNAI]. The use of the NAI is 189 consistent with the roaming model defined by the ROAMOPS Working 190 Group [EVALROAM]. 192 A home AAA server (AAAH) and foreign AAA server (AAAF), which support 193 the Mobile-IP authentication application MAY maintain session-state 194 or MAY be session-stateless. AAA redirect agents and AAA relay agents 195 MUST not maintain session-state. The AAAH, AAAF, proxies and relays 196 agents MUST maintain transaction state. 198 Given the nature of Mobile IP, a re-authentication can only be 199 initiated by a mobile node, which does not participate in the 200 Diameter message exchanges. Therefore Diameter server initiated re- 201 auth does not apply to this application. 203 Furthermore, the nature of mobile IP also means that the mobile node 204 will do handoffs between different foreign agents. To guarantee that 205 a registered user always ends up in the same initial AAAH, the mobile 206 node SHOULD always include the AAAH NAI [AAANAI]. Finally, to assist 207 the AAAH in routing the messages to a mobile node's home agent the 208 mobile node SHOULD always include the HA NAI [AAANAI]. If the mobile 209 node does not support the Mobile IP AAA NAI extension [AAANAI], this 210 MAY limit the functionality that can be offered to such a mobile 211 node. 213 The Diameter Mobile-IP Application meets the requirements specified 214 in [MIPREQ, CDMA2000]. Later subsections in this introductory section 215 provide some examples and message flows of the Mobile IP and Diameter 216 messages that occur when a mobile node requests service in a foreign 217 network. In this document, the role of the "attendant" [MIPREQ] is 218 performed by either the home agents (for co-located mobile nodes) or 219 foreign agents for the Mobile-IP Application, and these terms will be 220 used interchangeably. 222 1.1 Requirements language 224 In this document, the key words "MAY", "MUST", "MUST NOT", 225 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 226 interpreted as described in [KEYWORDS]. 228 1.2 Inter-Realm Mobile IP 230 When a mobile node requests service by issuing a Registration Request 231 to the foreign agent, the foreign agent creates the AA-Mobile-Node- 232 Request (AMR) message, which includes the AVPs defined in section 233 2.1. The Home Address, Home Agent, Mobile Node NAI and other 234 important fields are extracted from the registration messages for 235 possible inclusion as Diameter AVPs. The AMR message is then 236 forwarded to the local Diameter server, known as the AAA-Foreign, or 237 AAAF. 239 Visited Realm Home Realm 240 +--------+ +--------+ 241 |abc.com | AMR/AMA |xyz.com | 242 | AAAF |<------------------->| AAAH | 243 +->| server | server-server | server | 244 | +--------+ communication +--------+ 245 | ^ ^ 246 | AMR/AMA | client-server | HAR/HAA 248 | | communication | 249 v v v 250 +---------+ +---------+ +---------+ 251 | Foreign | | Foreign | | Home | 252 | Agent | | Agent | | Agent | 253 +---------+ +---------+ +---------+ 254 ^ 255 | Mobile IP 256 | 257 v 258 +--------+ 259 | Mobile | 260 | Node | mn@xyz.com 261 +--------+ 262 Figure 1: Inter-Realm Mobility 264 Upon receiving the AMR, the AAAF follows the procedures outlined in 266 [DIAMBASE] to determine whether the AMR should be processed locally, 267 or if it should be forwarded to another Diameter server, known as the 268 AAA-Home, or AAAH. Figure 1 shows an example in which a mobile node 269 (mn@xyz.com) requests service from a foreign provider (abc.com). The 270 request received by the AAAF is forwarded to xyz.com's AAAH server. 272 Figure 2 shows the message flows involved when the foreign agent 273 invokes the AAA infrastructure to request that a mobile node be 274 authenticated and authorized. Note that it is not required that the 275 foreign agent invoke AAA services every time a Registration Request 276 is received from the mobile, but rather only when the prior 277 authorization from the AAAH expires. The expiration time of the 278 authorization is communicated through the Authorization-Lifetime AVP 279 in the AA-Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. 281 Mobile Node Foreign Agent AAAF AAAH Home Agent 282 ----------- ------------- ------------ ---------- ---------- 283 Advertisement & 284 <--------- Challenge 286 Reg-Req&MN-AAA ----> 288 AMR------------> 289 Session-Id = foo 291 AMR------------> 292 Session-Id = foo 294 HAR-----------> 295 Session-Id = bar 297 <----------HAA 298 Session-Id = bar 300 <-----------AMA 301 Session-Id = foo 303 <------------AMA 304 Session-Id = foo 306 <-------Reg-Reply 308 Figure 2: Mobile IP/Diameter Message Exchange 310 The foreign agent (as shown in Figure 2) MAY provide a challenge, 311 which gives it direct control over the replay protection in the 312 Mobile IP registration process, as described in [MIPCHAL]. The 313 mobile node includes the Challenge and MN-AAA authentication 314 extension to enable authorization by AAAH. If the authentication data 315 supplied in the MN-AAA extension is invalid, AAAH returns the 316 response (AMA) with the Result-Code AVP set to 317 DIAMETER_AUTHENTICATION_REJECTED. 319 A mobile node with AAA NAI extension support [AAANAI], which has been 320 previously authenticated and authorized, MUST always include the 321 assigned home agent in the HA Identity subtype of the AAA NAI 322 extension, and the authorizing Home AAA server in the AAAH Identity 323 subtype of the AAA NAI extension, when re-authenticating. So, in the 324 event that the AMR generated by the FA is for a session that was 325 previously authorized, it MUST include the Destination-Host AVP, with 326 the identity of the AAAH found in the AAAH-NAI, and the MIP-Home- 327 Agent- Host AVP with the identity and realm of the assigned HA found 328 in the HA-NAI. If on the other hand the mobile node does not support 329 the AAA NAI extension, the FA may not have the identity of the AAAH 330 and the identity and realm of the assigned HA. This means that 331 without support of the AAA NAI extension, the FA may not be able to 332 guarantee, that the AMR will be destined to the same AAAH, which 333 previously authenticated and authorized the mobile node, since the FA 334 may not know the identity of the AAAH. 336 If the mobile node was successfully authenticated, the AAAH checks if 337 the home agent was located in the foreign realm, by checking Home- 338 Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. Other 339 AVP's like the MIP-Home-Agent-Host AVP and the MIP-Originating- 340 Foreign-AAA AVP may also be used to verify the location of the home 341 agent. If the home agent is located in the foreign realm, then the 342 AAAH sends an HAR message to the home agent, which contains a MIP- 343 Reg-Request AVP. 345 If the home agent was not located in the foreign realm, the AAAH 346 checks for the MIP-Home-Agent-Address AVP and if present the MIP- 347 Home-Agent-Host AVP. If one was specified, the AAAH checks that the 348 address is that of a known home agent and that the mobile node is 349 allowed to request this particular home agent, and that the home 350 agent's identity is included in the MIP-Home-Agent-Host AVP. If no 351 home agent was specified, and if the MIP-Feature-Vector has the Home- 352 Agent-Requested flag set, and if allowed by policy in the home realm, 353 the AAAH SHOULD allocate a home agent on behalf of the mobile node. 354 This can be done in a variety of ways, including using a load 355 balancing algorithm in order to keep the load on all home agents 356 equal. The actual algorithm used and the method of discovering the 357 home agents is outside the scope of this specification. 359 The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains 360 the Mobile IP Registration Request message data encapsulated in the 361 MIP-Reg-Request AVP, to the assigned or requested Home Agent. The 362 AAAH MAY allocate a home address for the mobile node, while the Home 363 Agent MUST support home address allocation. In the event the AAAH 364 handles address allocation, it includes it in a MIP-Mobile-Node- 365 Address AVP within the HAR. The absence of this AVP informs the Home 366 Agent to perform the allocation. 368 During the creation of the HAR, the AAAH MUST use a different session 369 identifier than the one used in the AMR/AMA (see Figure 2). If the 370 AAAH is session-stateful, it MUST send the same session identifier 371 for all HARs initiated on behalf of a given mobile node's session. 372 Otherwise, if the AAAH is session-stateless, it will manufacture a 373 unique session-id for every HAR. 375 A mobile node's session is identified via its identity in the User- 376 Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address 377 AVPs. This is necessary in order to allow the session state machine, 378 defined in the base protocol [DIAMBASE], to be used unmodified with 379 this application. Therefore, an STR from a foreign agent would free 380 the session from the foreign agent, but not the one towards the home 381 agent (see figure 3). 383 STR, Session-Id = foo STR, Session-Id = bar 384 ---------------------> <-------------------- 385 +----+ +------+ +------+ +----+ 386 | FA | | AAAF | | AAAH | | HA | 387 +----+ +------+ +------+ +----+ 388 <--------------------- ---------------------> 389 STA, Session-Id = foo STA, Session-Id = bar 390 Figure 3: Session Termination and Session Identifiers 392 Upon receipt of the HAR, the home agent first processes the Diameter 393 message. The home agent processes the MIP-Reg-Request AVP and creates 394 the Registration Reply, encapsulating it within the MIP-Reg-Reply 395 AVP. In the creation of the Registration Reply the Home Agent must 396 include the HA NAI and the AAAH NAI, which will be created from the 397 Origin-Host AVP and Origin-Realm AVP of the HAR. If a home address is 398 needed, the home agent MUST also assign one and include the address 399 in both the Registration Reply and within the MIP-Mobile-Node-Address 400 AVP. 402 The HA MUST include an Acct-Multi-Session-Id AVP in the HAA returned 403 to the AAAH. 405 Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer 406 (AMA) message, includes the Acct-Multi-Session-Id that was present in 407 the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node-Address AVPs 408 in the AMA message. 410 1.3 Support for Mobile IP Handoffs 412 Given the nature of Mobile IP, a mobile node MAY receive service from 413 many foreign agents during a period of time. However, the home realm 414 should not view these handoffs as different sessions, since this 415 could affect billing systems. Furthermore, many foreign agents do not 416 communicate, which makes it quite difficult for AAA information to be 417 exchanged between these entities. Therefore, it MUST be assumed that 418 a foreign agent is not aware that a registration request from a 419 mobile node has been previously authorized. 421 A handoff registration request from a mobile node will cause an AMR 422 to be sent to its AAAF. The AMR will include a new session 423 identifier, and MAY be sent to an AAAF in the visited network other 424 than the AAAF, which received the previous AMR. However, with the 425 usage of the AAA NAI, this AMR is guaranteed to be received by the 426 AAAH to which the user is currently registered. 428 Since the AAAH may be session-stateless, it is necessary for the 429 resulting HAR received by the HA to be identified as a continuation 430 of an existing session. If the HA receives an HAR for a mobile node, 431 with a new session identifier, and the HA can guarantee that this 432 request is to extend service for an existing service, then the HA 433 MUST be able to modify its internal session state information to 434 reflect the new session identifier. 436 It is necessary for accounting records to have some commonality 437 across handoffs in order for correlation to occur. Therefore, the 438 home agent MUST send the same Acct-Multi-Session-Id AVP value in all 439 HAAs for the mobile's session. That is, the HA generates a unique 440 Acct-Multi-Session-Id when receiving an HAR for a new session, and 441 returns this same value in every HAA for the session. This Acct- 442 Multi-Session-Id AVP will be returned to the foreign agent by the 443 AAAH in the AMA. Both the foreign and home agents MUST include the 444 Acct-Multi-Session-Id in the accounting messages. 446 ACR, Session-Id = foo ACR, Session-Id = bar 447 Acct-Multi-Session-Id = a Acct-Multi-Session-Id = a 448 ---------------------> <-------------------- 449 +----+ +------+ +------+ +----+ 450 | FA | | AAAF | | AAAH | | HA | 451 +----+ +------+ +------+ +----+ 452 <--------------------- ---------------------> 453 ACA, Session-Id = foo ACA, Session-Id = bar 455 Figure 4: Accounting messages w/ Mobile IP Application 457 1.4 Allocation of Home Agent in Foreign Network 459 The Diameter Mobile IP application allows a home agent to be 460 allocated in a foreign network, as required in [MIPREQ, CDMA2000]. 461 When a foreign agent detects that the mobile node has a home agent 462 address equal to 0.0.0.0 or 255.255.255.255 in the Registration 463 Request message, it MUST add a MIP-Feature-Vector AVP with the Home- 464 Agent- Requested flag set to one. If the home agent address is equal 465 to 255.255.255.255, then the foreign agent also MUST set the Home- 466 Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home 467 agent address is set to 0.0.0.0, the foreign agent MUST set the Home- 468 Address-Allocatable-Only-in-Home-Realm flag equal to zero. 470 When the AAAF receives an AMR message with the Home-Agent-Requested 471 flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm 472 flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available 473 flag in the MIP-Feature-Vector AVP to inform the AAAH that it is 474 willing and able to assign a Home Agent for the mobile node. When 475 doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP 476 and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home- 477 Agent-Host AVP contains the identity of the home agent that would be 478 assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP 479 contains the identity of the AAAF. 481 In the event that the mobile node with AAA NAI extension support 482 [AAANAI] has been previously authorized by the AAAH and now needs to 483 be re-authenticated, and requests to keep the assigned home agent in 484 the foreign network, the mobile node MUST include the HA NAI and the 485 AAAH NAI in the registration request to the FA. Upon receipt, the FA 486 will create the AMR including the MIP-Home-Agent-Address AVP, the 487 Destination-Host AVP based on the AAAH NAI and include the MIP-Home- 488 Agent-Host AVP based on the home agent NAI. If the AAAF authorizes 489 the use of the requested home agent, the AAAF MUST set the Home- 490 Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. 492 In the event that the mobile node that does not support the AAA NAI 493 extension has been previously authorized by the AAAH and now needs to 494 be re-authenticated, and requests to keep the assigned home agent in 495 the foreign network, the mobile node sends a registration request 496 without the AAA NAI and the HA NAI. Upon receipt, the FA will create 497 the AMR including the MIP-Home-Agent-Address AVP. If the AAAF 498 authorizes the use of the requested home agent, and if it has 499 knowledge that the requested home agent is in its own domain, the 500 AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP- 501 Feature-Vector AVP. 503 When the AAAH receives an AMR message, it first checks the 504 authentication data supplied by the mobile node, according to the 505 MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether 506 to authorize the mobile node. If the AMR indicates that the AAAF has 507 offered to allocate a Home Agent for the mobile node, i.e. the 508 Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP, or 509 the AMR indicates that the AAAF has offered a previously allocated 510 Home Agent for the mobile node, i.e. the Home-Agent-In-Foreign- 511 Network is set in the MIP-Feature-Vector AVP, then the AAAH must 512 decide whether its local policy would allow the user to have a Home 513 Agent in the foreign network or to keep the Home Agent in the foreign 514 network. If so, and after checking authorization from the data in the 515 AMR message, the AAAH sends the HAR message to Home Agent by 516 including the Destination-Host AVP set to the value found in the 517 AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP if 518 the HA has been previously allocated and authorized by the AAAH. If 519 the HA has not been previously allocated by the foreign domain, the 520 HAR sent by the AAAH does not contain the MIP-Home-Agent-Address. 522 If the AAAH's local policy determines that the generated session keys 523 must be encrypted to protect against untrusted intermediate Diameter 524 agent(s) between the visited and the home realm, the AAAH will make 525 use of the CMS application [CMS] to establish a security association. 526 If no security association can be established the AAAH MUST return an 527 AMA with the Result-Code AVP set to 528 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. Otherwise, upon 529 completion of the security association, the AAAH sends the HAR to the 530 originating AAAF. In this HAR the Destination-Host AVP is set to the 531 value found in the AMR's MIP-Originating-Foreign-AAA AVP, and the 532 MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP 533 found in the AMR are copied into the HAR. 535 If the AAAH's local policy determines that session keys can be 536 encrypted using mechanisms defined in [DIAMBASE] as in Figure 5, the 537 HAR is sent by the AAAH back to the foreign realm with the 538 Destination-Host AVP set to the home agent's identity. This HAR may 539 not necessarily be received by the same AAAF, which sent the AMR. 541 Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA 542 AVP from the AMR message to the HAR message. In cases when another 543 AAAF receives the HAR, this new AAAF will use the MIP-Originating- 544 Foreign-AAA AVP for policy decisions, such as determining if the FA- 545 HA Key should be encrypted or not. 547 Visited Home 548 Realm Realm 549 +--------+ ------- AMR -------> +--------+ 550 | AAAF | <------ HAR -------- | AAAH | 551 | | | | 552 +--->| server | ------- HAA -------> | server | 553 | +--------+ <------ AMA -------- +--------+ 554 | ^ | 555 | | | 556 HAR/HAA | AMR | | AMA 557 v | v 558 +---------+ +---------+ 559 | Home | | Foreign | 560 | Agent | | Agent | 561 +---------+ +---------+ 562 ^ 563 +--------+ | 564 | Mobile |<----------+ 565 | Node | Mobile IP 566 +--------+ 567 Figure 5: Home Agent allocated in Visited Realm 569 Upon receipt of a HAA from the Home Agent in the visited realm, the 570 AAAF forwards the HAA to the AAAH in the home realm. The AMA is then 571 constructed, and issued to the AAAF, and finally to the FA. If the 572 Result-Code indicates success, the HAA and AMA MUST include the MIP- 573 Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. 575 Mobile Node Foreign Agent Home Agent AAAF AAAH 576 ----------- ------------- ------------- ---------- ---------- 578 <----Challenge---- 579 Reg-Req (Response)-> 580 ------------AMR-------------> 581 -----AMR----> 582 <----HAR----- 583 <-----HAR------ 584 ------HAA------> 585 -----HAA----> 586 <----AMA----- 587 <-------------AMA------------ 588 <---Reg-Reply---- 589 Figure 6: Mobile IP/Diameter Message Exchange when HA is allocated in 590 Visited Realm 592 If the mobile node moves to another foreign Network, it MAY either 593 request to keep the same Home Agent within the old foreign network, 594 or request to get a new one in the new foreign network. If the AAAH 595 is willing to provide the requested service, the mobile node will 596 have to be serviced by two AAAFs. 598 Figure 7 shows the message flows for a mobile node requesting to keep 599 the home agent assigned in foreign network 1 when it moves to foreign 600 network 2. Upon reception of the AMR in foreign network 2, the AAAF 601 follows the procedures described earlier and forwards AMR to the 602 mobile node's home network, i.e. its AAAH. If the mobile node was 603 successfully authenticated, the AAAH checks the identity of the 604 foreign and home agent to determine whether the user is in a third 605 realm. If this is the case, the AAAH must check whether the mobile is 606 still permitted to use the previously assigned home agent. 608 +---------------+ +---------------+ +-------------+ 609 |Foreign net 2 | |Foreign net 1 | |Home network | 610 | | | | | | 611 Mobile Node | FA AAAF | | HA AAAF | | AAAH | 612 ----------- | ---- ---- | | ---- ------ | | ------ | 613 +---------------+ +---------------+ +-------------+ 615 <----Challenge---- 616 Reg-Req (Response)-> 617 ---AMR---> 618 ----------------AMR---------------> 619 <-----HAR----- 620 <---HAR---- 621 ----HAA---> 622 ------HAA----> 623 <---------------AMA---------------- 624 <--AMA---- 625 <----Reg-Reply----- 626 Figure 7: Request to access Home Agent from new foreign network 628 If the mobile node is allowed to keep the home agent the AAAH then 629 sends a HAR, which contains the Mobile IP Registration Request 630 message data encapsulated in the MIP-Reg-Request AVP and the MIP- 631 Home-Agent-Address AVP with home agent address, as well as any 632 optional KDC session keys, to the AAAF in foreign network 1. 633 Furthermore, the AAAH MUST always copy MIP-Originating-Foreign-AAA 634 AVP from AMR and include it in the HAR when a third foreign domain is 635 involved, since the AAAF will use the MIP-Originating-Foreign-AAA AVP 636 for policy decisions, such as determining if the FA-HA Key keys can 637 be encrypted using mechanisms defined in [DIAMBASE] or not, see 638 further details in section 5.5. Upon reception the AAAF in foreign 639 network 1 will forward the HAR to the Home Agent if its local policy 640 allows such service. If the AAAF does not permit such service, it 641 MUST return a DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. 643 If the AAAH's local policy determines that the MN-HA keys must be 644 encrypted to protect against untrusted intermediate Diameter agent(s) 645 between the foreign network 1 realm and the home realm, the AAAH will 646 make use of the CMS application [CMS]. If no security association is 647 known to the home agent, the AAAH MUST send the HAR to the AAAF in 648 foreign network 1, which originally assigned the HA in foreign 649 network 1, by including its identity in the Destination-Host AVP. 651 When the AAAF receives a HAA, the AAAF will forward the HAA back to 652 the AAAH. If successful, the HAA MUST include the MIP-Home-Agent- 653 Address and the MIP-Mobile-Node-Address AVPs. The AAAH will then send 654 back an AMA to the AAAF in foreign network 2. 656 If the old foreign network does not permit the use of its Home Agent 657 when the mobile node moves to a new foreign network, the AAAH or AAAF 658 MUST return an AMA with the Result-Code AVP set to 659 DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the 660 foreign agent MUST issue a Mobile IP Registration Reply to the mobile 661 node with an appropriate error. The mobile node MAY attempt to 662 request that a new Home Agent and Address be allocated. When the AAAH 663 transmits such an error, it MUST issue a Diameter Abort-Session- 664 Request message to the Home Agent to enable it to release any 665 resources. 667 1.5 Co-located Mobile Node 669 In the event that a mobile node registers with the Home Agent as a 670 co-located mobile node, there is no foreign agent involved. 671 Therefore, when the Home Agent receives the Registration Request, an 672 AMR message is sent to the local AAAH server, with the Co-Located- 673 Mobile-Node bit set in the MIP-Feature-Vector AVP. The Home Agent 674 also includes the Acct-Multi-Session-Id AVP in the AMR sent to the 675 AAAH, as the AAAH may find this a useful piece of session-state or 676 log entry information. 678 Home 679 Realm 680 +--------+ 681 | AAAH | 682 | | 683 | server | 684 +--------+ 685 ^ | 686 | | 687 AMR | | AMA 688 | v 689 +--------+ +---------+ 690 | Mobile | Registration | Home | 691 | Node |-------------->| Agent | 692 +--------+ Request +---------+ 693 Figure 8: Co-located Mobile Node 695 If the MN-HA-Key-Requested bit was set in the AMR message from the 696 Home Agent, the home agent and mobile node's session keys would be 697 present in the AMA message. 699 1.6 Key Distribution Center (KDC) 701 In order to allow the scaling of wireless data access across 702 administrative domains, it is necessary to minimize the specific 703 security associations required. This means that each Foreign Agent 704 should not be required have a pre-configured shared security 705 association with each Home Agent on the Internet, nor should the 706 mobile node be required to have a pre-configured shared security 707 association with any specific home agent or any specific foreign 708 agent, as defined in [MOBILEIP]. 710 Diameter Mobile IPv4 application solves this by including a key 711 distribution center (KDC), which means that after a Mobile Node is 712 authenticated, the authorization phase includes the generation of 713 sessions keys. Specifically, three keys are generated and are 714 required by [MOBILEIP]: 716 - K1 - the MN-HA Key, which will work as security association between 717 the Mobile Node and the Home Agent. 718 - K2 - the MN-FA Key, which will work as the security association 719 between the Mobile Node and the Foreign Agent 720 - K3 - the FA-HA Key, which will work as the shared between the 721 Foreign Agent and the Home Agent 723 Figure 9 depicts the new security associations used for Mobile-IP 724 message integrity using the keys derived by the DIAMETER server. 726 +--------+ +--------+ 727 |Foreign | K3 | Home | 728 |Agent |<-------------------->| Agent | 729 | | | | 730 +--------+ +--------+ 731 ^ ^ 732 | K2 K1 | 733 | +--------+ | 734 | | Mobile | | 735 +------>| Node |<------+ 736 | | 737 +--------+ 738 Figure 9 - Security Association after Key Distribution 740 If the home agent is assigned in the home network, each key is 741 generated and encrypted by the home Diameter server. If instead the 742 home agent is assigned in the foreign network the K3 key is generated 743 and encrypted by the foreign network's local Diameter server, while 744 the K1 and K2 is still generated and encrypted by the home Diameter 745 server. 747 The keys destined for the foreign and home agent are propagated to 748 the mobility nodes via the Diameter protocol, and the keys must be 749 encrypted either by IPSec or TLS when deployed in an environment 750 without Diameter agents. When deployed in an environment with 751 Diameter agents, the keys must be encrypted by means described in 752 [CMS]. 754 The keys destined for the mobile node must also be propagated via the 755 Mobile IP protocol and must therefore instead follow the mechanisms 756 described in [AAAKEY]]. This means that the keys distributed to the 757 mobile node are instead sent as key material, and the mobile node and 758 the home Diameter will use the material and the long term shared 759 secret to create the keys (see section 5.2). 761 Once the session keys have been established and propagated, the 762 mobility devices can exchange registration information directly as 763 defined in [MOBILEIP] without the need of the Diameter 764 infrastructure. However the session keys have a lifetime, after 765 which the Diameter infrastructure must be invoked again to acquire 766 new session keys. 768 1.7 Diameter Session Termination 770 A foreign and home agent following this specification MAY expect 771 their respective Diameter servers to maintain session state 772 information for each mobile node in their networks. In order for the 773 Diameter Server to release any resources allocated to a specific 774 mobile node, the mobility agents MUST send a Session-Termination- 775 Request (STR) to the Diameter server that authorized the service. The 776 Session-Termination-Request (STR) MUST be issued by the mobility 777 agents if the Authorization Lifetime has expired and no subsequent 778 MIP registration request have been received. 780 The home Diameter server SHOULD only deallocate all resources after 781 the STR is received from the home agent. This ensures that a mobile 782 node that moves from one foreign agent to another (hand-off) does not 783 cause the Home Diameter Server to free all resources for the mobile 784 node. 786 When deallocating all of the mobile node's resources the home 787 Diameter server (and the foreign Diameter server in case of HA 788 allocated in foreign network) MUST destroy all session keys that may 789 still be valid. 791 In the event that the AAAF wishes to terminate a session, its Abort- 792 Session-Request (ASR) [DIAMBASE] message SHOULD be sent to the FA. 793 Similarly, the AAAH SHOULD send its message to the Home Agent. 795 1.8 Advertising application support 797 Diameter nodes conforming to this specification MAY advertise support 798 by including the value of four (4) in the Auth-Application-Id or the 799 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 800 Capabilities-Exchange-Answer command [DIAMBASE]. 802 1.9 Fast Handoff support 804 This application requires that foreign agents issue an AMR upon 805 receipt of the first registration message from a mobile node, 806 regardless of the fact that the mobile node MAY have been previously 807 authorized to another foreign agent. 809 The Mobile IP Working Group is currently investigating fast handoff 810 proposals, and the Seamoby WG is looking at creating a protocol that 811 would allow AAA state information to be exchange between foreign 812 agents during a handoff. These proposals MAY allow future 813 enhancements to the Diameter protocol, in order to reduce the amount 814 of Diameter exchanges required during a handoff. 816 1.10 Packet filtering support 818 This application has support for pushing packet filtering rules to 819 either of the mobility agents to enable appropriate firewall controls 820 for the penetration of tunneled traffic between the home agent and 821 the mobile node. The packet filtering rules are set by the AAAH by 822 adding one or more MIP-Filter-Rule AVPs in the HAR if destined for 823 the home agent and/or in the AMA if destined for the foreign agent. 825 If MIP-Filter-Rule AVPs are included in the HAR and the home agent 826 does not have firewall support, due to legacy reason, the home agent 827 MUST return a HAA with Result-Code AVP equal to 828 DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED. 830 If the MIP-Filter-Rule AVPs are included in the AMA and the foreign 831 agent does not have firewall support, due to legacy reason, the 832 foreign agent SHOULD log the event and MUST issue a Session- 833 Termination-Request (STR) back to its local Diameter server. 835 2.0 Command-Code Values 837 This section defines Command-Code [DIAMBASE] values that MUST be 838 supported by all Diameter implementations conforming to this 839 specification. The following Command Codes are defined in this 840 specification: 842 Command-Name Abbreviation Code Section 843 ----------------------------------------------------------- 844 AA-Mobile-Node-Answer AMA 260 2.2 845 AA-Mobile-Node-Request AMR 260 2.1 846 Home-Agent-MIP-Answer HAA 262 2.4 847 Home-Agent-MIP-Request HAR 262 2.3 849 2.1 AA-Mobile-Node-Request 851 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field 852 set to 260 and the 'R' bit set in the Command Flags field, is sent by 853 an attendant, acting as a Diameter client, to a server in order to 854 request the authentication and authorization of a mobile node. The 855 foreign agent (or home agent in the case of a co-located Mobile Node) 856 uses information found in the Registration Request to construct the 857 following AVPs that are to be included as part of the AMR: 859 home address (MIP-Mobile-Node-Address AVP) 860 home agent address (MIP-Home-Agent-Address AVP) 861 mobile node NAI (User-Name AVP [DIAMBASE]) 862 MN-HA Key Request (MIP-Feature-Vector AVP) 863 MN-FA Key Request (MIP-Feature-Vector AVP) 864 MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP) 865 foreign agent Challenge Extension (MIP-FA-Challenge AVP) 866 home agent NAI (MIP-Home-Agent-Host AVP) 867 home AAA server NAI (Destination-Host AVP [DIAMBASE]) 869 If the mobile node's home address is zero, the foreign or home agent 870 MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. If the 871 home agent address is zero or all ones, the MIP-Home-Agent-Address 872 AVP MUST NOT be present in the AMR. 874 If a foreign agent is used in a visited network, the AAAF MAY set the 875 Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in 876 the AMR message to indicate that it is willing to assign a Home Agent 877 in the visited realm. 879 If the mobile node's home address is all ones, the foreign or home 880 agent MUST include a MIP-Mobile-Node-Address AVP, set to all ones. 882 If the mobile node includes the home agent NAI and the home AAA 883 server NAI [AAANAI], the foreign agent MUST include the MIP-Home- 884 Agent-Host AVP and the Destination-Host AVP in the AMR. 886 Message Format 888 ::= < Diameter Header: 260, REQ, PXY > 889 < Session-ID > 890 { Auth-Application-Id } 891 { User-Name } 892 { Destination-Realm } 893 { Origin-Host } 894 { Origin-Realm } 895 { MIP-Reg-Request } 896 { MIP-MN-AAA-Auth } 897 [ Acct-Multi-Session-Id ] 898 [ Destination-Host ] 899 [ Origin-State-Id ] 900 [ MIP-Mobile-Node-Address ] 901 [ MIP-Home-Agent-Address ] 902 [ MIP-Feature-Vector ] 903 [ MIP-Originating-Foreign-AAA ] 904 [ Authorization-Lifetime ] 905 [ Auth-Session-State ] 906 [ MIP-FA-Challenge ] 907 [ MIP-Candidate-Home-Agent-Host ] 908 * [ Proxy-Info ] 909 * [ Route-Record ] 910 * [ AVP ] 912 2.2 AA-Mobile-Node-Answer 914 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field 915 set to 260 and the 'R' bit cleared in the Command Flags field, is 916 sent by the AAAH in response to the AA-Mobile-Node-Request message. 917 The User-Name MAY be included in the AMA if present in the AMR. The 918 Result-Code AVP MAY contain one of the values defined in section 3.0, 919 in addition to the values defined in [DIAMBASE]. 921 An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST 922 include the MIP-Home-Agent-Address AVP, MUST include the MIP-Mobile- 923 Node-Address AVP, and includes the MIP-Reg-Reply AVP if and only if 924 the Co-Located-Mobile-Node bit was not set in the MIP-Feature-Vector 925 AVP. The MIP-Home-Agent-Address AVP contains the Home Agent assigned 926 to the mobile node, while the MIP-Mobile-Node-Address AVP contains 927 the home address that was assigned. The AMA message MUST contain the 928 MIP-FA-to-HA-Key, MIP-FA-to-MN-Key if they were requested in the AMR, 929 and they were present in the HAR. The MIP-MN-to-HA-Key and MIP-HA-to- 930 MN-Key AVPs MUST be present if the session keys were requested in the 931 AMR, and the Co-Located-Mobile-Node bit was set in the MIP-Feature- 932 Vector AVP. 934 An AMA message with the Result-Code AVP set to 935 DIAMETER_LIMITED_SUCCESS MAY include the MIP-Home-Agent-Address AVP 936 if a dynamically assigned home agent was requested by the mobile 937 node. Upon receipt of this result code, the foreign agent MUST issue 938 the Registration Request to the Home Agent in the manner described in 939 [MOBILEIP]. 941 An AMA message with the Result-Code set to DIAMETER_MULTI_ROUND_AUTH 942 MAY include mobile node session key AVPs (see Section 6.1) such as 943 the MIP-MN-to-FA-Key AVP and the MIP-MN-to-HA-Key AVP. If such an AVP 944 is present in the AMA message, the foreign agent MUST include the 945 corresponding Mobile IP key distribution extension in the 946 Registration Reply it sends to the mobile node. This is to support 947 multi-roundtrip authentication mechanisms. 949 Message Format 951 ::= < Diameter Header: 260, PXY > 952 < Session-Id > 953 { Auth-Application-Id } 954 { Result-Code } 955 { Origin-Host } 956 { Origin-Realm } 957 [ Acct-Multi-Session-Id ] 958 [ User-Name ] 959 [ Authorization-Lifetime ] 960 [ Auth-Session-State ] 961 [ Error-Message ] 962 [ Error-Reporting-Host ] 963 [ Re-Auth-Request-Type ] 964 [ MIP-Feature-Vector ] 965 [ MIP-Reg-Reply ] 966 [ MIP-MN-to-FA-Key ] 967 [ MIP-MN-to-HA-Key ] 968 [ MIP-FA-to-MN-Key ] 969 [ MIP-FA-to-HA-Key ] 970 [ MIP-HA-to-MN-Key ] 971 [ MIP-HA-to-FA-Key ] 972 [ MIP-Key-Lifetime ] 973 [ MIP-Home-Agent-Address ] 974 [ MIP-Mobile-Node-Address ] 975 * [ MIP-Filter-Rule ] 976 [ Origin-State-Id ] 977 * [ Proxy-Info ] 978 * [ AVP ] 980 2.3 Home-Agent-MIP-Request 982 The Home-Agent-MIP-Request (HAR), indicated by the Command-Code field 983 set to 262 and the 'R' bit set in the Command Flags field, is sent by 984 the AAA to the Home Agent. If the Home Agent is to be assigned in a 985 foreign network, the HAR is issued by the AAAH and forwarded by the 986 AAAF. If the HAR message does not include a MIP-Mobile-Node-Address 987 AVP, and the Registration Request has 0.0.0.0 for the home address, 988 and the HAR is successfully processed, the Home Agent MUST allocate 989 one such address to the mobile node. If the home agent's local AAA 990 server allocates the mobile node's home address, it MUST include the 991 assigned address in an MIP-Mobile-Node-Address AVP. 993 When session keys are requested for use by the mobile node (see 994 section 5.0), the AAAH MUST create them and include them in the HAR 995 message. When a Foreign-Home session key is requested, it will be 996 created and distributed by the AAA server in the same realm as the 997 home agent. 999 Message Format 1001 ::= < Diameter Header: 262, REQ, PXY > 1002 < Session-Id > 1003 { Auth-Application-Id } 1004 { Authorization-Lifetime } 1005 { Auth-Session-State } 1006 { MIP-Reg-Request } 1007 { Origin-Host } 1008 { Origin-Realm } 1009 { User-Name } 1010 { Destination-Realm } 1011 { MIP-Feature-Vector } 1012 [ Destination-Host ] 1013 [ MIP-MN-to-HA-Key ] 1014 [ MIP-MN-to-FA-Key ] 1015 [ MIP-HA-to-MN-Key ] 1016 [ MIP-HA-to-FA-Key ] 1017 [ MIP-Key-Lifetime ] 1018 [ MIP-Originating-Foreign-AAA ] 1019 [ MIP-Mobile-Node-Address ] 1020 [ MIP-Home-Agent-Address ] 1021 * [ MIP-Filter-Rule ] 1022 [ Origin-State-Id ] 1023 * [ Proxy-Info ] 1024 * [ Route-Record ] 1025 * [ AVP ] 1027 2.4 Home-Agent-MIP-Answer 1029 The Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field 1030 set to 262 and the 'R' bit cleared in the Command Flags field, is 1031 sent by the Home Agent to its local AAA server in response to a Home- 1032 Agent-MIP-Request. The User-Name MAY be included in the HAA if 1033 present in the HAR. If the home agent allocated a home address for 1034 the mobile node, the address MUST be included in the MIP-Mobile-Node- 1035 Address AVP. The Result-Code AVP MAY contain one of the values 1036 defined in section 3.0 instead of the values defined in [DIAMBASE]. 1038 Message Format 1040 ::= < Diameter Header: 262, PXY > 1041 < Session-Id > 1042 { Auth-Application-Id } 1043 { Result-Code } 1044 { Origin-Host } 1045 { Origin-Realm } 1046 [ Acct-Multi-Session-Id ] 1047 [ User-Name ] 1048 [ Error-Reporting-Host ] 1049 [ Error-Message ] 1050 [ MIP-Reg-Reply ] 1051 [ MIP-Home-Agent-Address ] 1052 [ MIP-Mobile-Node-Address ] 1053 [ MIP-FA-to-HA-SPI ] 1054 [ MIP-FA-to-MN-SPI ] 1055 [ Origin-State-Id ] 1056 * [ Proxy-Info ] 1057 * [ AVP ] 1059 3.0 Result-Code AVP Values 1061 This section defines new Result-Code [DIAMBASE] values that MUST be 1062 supported by all Diameter implementations that conform to this 1063 specification. 1065 3.1 Transient Failures 1067 Errors that fall within the transient failures category are used to 1068 inform a peer that the request could not be satisfied at the time it 1069 was received, but MAY be able to satisfy the request in the future. 1071 DIAMETER_ERROR_MIP_REPLY_FAILURE 4005 1072 This error code is used by the home agent when processing of 1073 the Registration Request has failed. 1075 DIAMETER_ERROR_HA_NOT_AVAILABLE 4006 1076 This error code is used to inform the foreign agent that the 1077 requested Home Agent cannot be assigned to the mobile node at 1078 this time. The foreign agent MUST return a Mobile IP 1079 Registration Reply to the mobile node with an appropriate error 1080 code. 1082 DIAMETER_ERROR_BAD_KEY 4007 1083 This error code is used by the home agent to indicate to the 1084 local Diameter server that the key generated is invalid. 1086 DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED 4008 1087 This error code is used by a mobility agent to indicate to the 1088 home Diameter server that the requested packet filter rules 1089 cannot be supported. 1091 3.2 Permanent Failures 1093 Errors that fall within the permanent failures category are used to 1094 inform the peer that the request failed, and should not be attempted 1095 again. 1097 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5024 1098 This error is used by the AAAF to inform the AAAH that 1099 allocation of a home agent in the foreign domain is not 1100 permitted at this time. 1102 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025 1103 This error is used by the AAAF / AAAH to inform that the 1104 requested mobile IP session keys could not be encrypted with 1105 the CMS strong security application and therefore failed. 1107 4.0 Mandatory AVPs 1109 The following table describes the Diameter AVPs defined in the Mobile 1110 IP application, their AVP Code values, types, possible flag values 1111 and whether the AVP MAY be encrypted. 1113 Due to space constraints, the short form IPFiltrRule is used to 1114 represent IPFilterRule and DiamIdent is used to represent 1115 DiameterIdentity. 1117 +---------------------+ 1118 | AVP Flag rules | 1119 |----+-----+----+-----|----+ 1120 AVP Section | | |SHLD| MUST|MAY | 1121 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1122 -----------------------------------------|----+-----+----+-----|----| 1123 MIP-Filter-Rule 342 4.8 IPFiltrRule| M | P | | V | Y | 1124 MIP-Auth-Input- 338 4.6.2 Unsigned32 | M | P | | V | Y | 1125 Data-Length | | | | | | 1126 MIP- 339 4.6.3 Unsigned32 | M | P | | V | Y | 1127 Authenticator-Length | | | | | | 1128 MIP- 340 4.6.4 Unsigned32 | M | P | | V | Y | 1129 Authenticator-Offset | | | | | | 1130 MIP-Candidate- 336 4.9 DiamIdent | M | P | | V | N | 1131 Home-Agent-Host | | | | | | 1132 MIP-Home-Agent- 348 4.11 DiamIdent | M | P | | V | N | 1133 Host | | | | | | 1134 MIP-FA-Challenge 344 4.7 OctetString| M | P | | V | Y | 1135 MIP-Feature- 337 4.5 Unsigned32 | M | P | | V | Y | 1136 Vector | | | | | | 1137 MIP-Home-Agent- 334 4.4 IPAddress | M | P | | V | Y | 1138 Address | | | | | | 1139 MIP-MN-AAA-Auth 322 4.6 Grouped | M | P | | V | Y | 1140 MIP-MN-AAA-SPI 341 4.6.1 Unsigned32 | M | P | | V | Y | 1141 MIP-Mobile-Node- 333 4.3 IPAddress | M | P | | V | Y | 1142 Address | | | | | | 1143 MIP-Reg-Request 320 4.1 OctetString| M | P | | V | Y | 1144 MIP-Reg-Reply 321 4.2 OctetString| M | P | | V | Y | 1145 MIP-Originating- 347 4.10 Grouped | M | P | | V | Y | 1146 Foreign-AAA | | | | | | 1148 4.1 MIP-Reg-Request AVP 1150 The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and 1151 contains the Mobile IP Registration Request [MOBILEIP] sent by the 1152 mobile node to the foreign agent. 1154 4.2 MIP-Reg-Reply AVP 1156 The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and 1157 contains the Mobile IP Registration Reply [MOBILEIP] sent by the home 1158 agent to the foreign agent. 1160 4.3 MIP-Mobile-Node-Address AVP 1162 The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type IPAddress 1163 and contains the mobile node's home address. 1165 4.4 MIP-Home-Agent-Address AVP 1167 The MIP-Home-Agent-Addess AVP (AVP Code 334) is of type IPAddress and 1168 contains the mobile node's home agent address. 1170 4.5 MIP-Feature-Vector AVP 1172 The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and 1173 is added with flag values set by the foreign agent or by the AAAF 1174 owned by the same administrative domain as the foreign agent. The 1175 foreign agent SHOULD include MIP-Feature-Vector AVP within the AMR 1176 message it sends to the AAAF. 1178 Flag values currently defined include: 1179 1 Mobile-Node-Home-Address-Requested 1180 2 Home-Address-Allocatable-Only-in-Home-Realm 1181 4 Home-Agent-Requested 1182 8 Foreign-Home-Agent-Available 1183 16 MN-HA-Key-Request 1184 32 MN-FA-Key-Request 1185 64 FA-HA-Key-Request 1186 128 Home-Agent-In-Foreign-Network 1187 256 Co-Located-Mobile-Node 1189 The flags are set according to the following rules. 1191 If the mobile node includes a valid home address (i.e., not equal to 1192 0.0.0.0 or 255.255.255.255) in its Registration Request, the foreign 1193 agent zeroes the Mobile-Node-Home-Address-Requested flag in the MIP- 1194 Feature-Vector AVP. 1196 If the mobile node sets the home address field equal to 0.0.0.0 in 1197 its Registration Request, the foreign agent sets the Mobile-Node- 1198 Home-Address-Requested flag to one. 1200 If the mobile node sets the home agent field equal to 255.255.255.255 1201 in its Registration Request, the foreign agent sets both the Home- 1202 Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home- 1203 Realm flag to one in the MIP-Feature-Vector AVP. 1205 If the mobile node sets the home agent field equal to 0.0.0.0 in its 1206 Registration Request, the foreign agent sets the Home-Agent-Requested 1207 flag to one, and zeroes the Home-Address-Allocatable-Only-in-Home- 1208 Realm flag in the MIP-Feature-Vector AVP. 1210 Whenever the foreign agent sets either the Mobile-Node-Home-Address- 1211 Requested flag or the Home-Agent-Requested flag to one, it MUST set 1212 the MN-HA-Key-Request flag to one. The MN-HA-Key-Request flag is also 1213 set to one if the mobile node includes a Generalized MN-HA Key 1214 Request [MIPKEYS] extension, with the subtype set to AAA. 1216 If the mobile node includes a Generalized MN-FA Key Request [MIPKEYS] 1217 extension with the AAA subtype in its Registration Request, the 1218 foreign agent sets the MN-FA-Key-Request flag to one in the MIP- 1219 Feature-Vector AVP. 1221 If the mobile node requests a home agent in the foreign network 1222 either by setting the home address field to all ones, or by 1223 specifying a home agent in the foreign network, and the AAAF 1224 authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign- 1225 Network bit to one. 1227 If the Home Agent receives a Registration Request from the mobile 1228 node indicating that the MN is acting as a co-located mobile node, 1229 the home agent sets the Co-Located-Mobile-Node bit to one. 1231 If the foreign agent's local policy allows it to receive AAA session 1232 keys, and it does not have any existing FA-HA key with the home 1233 agent, the foreign agent MAY set the FA-HA-Key-Request flag 1235 The foreign agent MUST NOT set the Foreign-Home-Agent-Available, and 1236 Home-Agent-In-Foreign-Network flag to one. 1238 When the AAAF receives the AMR message, it MUST first verify that the 1239 sender was an authorized foreign agent. The AAAF then takes any 1240 actions indicated by the settings of the MIP-Feature-Vector AVP 1241 flags. The AAAF then MAY set additional flags.Only the AAAF may set 1242 the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network 1243 flags to one. This is done according to local administrative policy. 1244 When the AAAF has finished setting additional flags according to its 1245 local policy, then the AAAF transmits the AMR with the possibly 1246 modified MIP-Feature-Vector AVP to the AAAH. 1248 4.6 MIP-MN-AAA-Auth AVP 1250 The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains 1251 some ancillary data to simplify processing of the authentication data 1252 in the Mobile IP Registration Request [MOBILEIP] by the target AAA 1253 server. Its value has the following ABNF grammar: 1255 MIP-MN-AAA-Auth ::= < AVP Header: 322 > 1256 { MIP-MN-AAA-SPI } 1257 { MIP-Auth-Input-Data-Length } 1258 { MIP-Authenticator-Length } 1259 { MIP-Authenticator-Offset } 1260 * [ AVP ] 1262 4.6.1 MIP-MN-AAA-SPI AVP 1263 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 1264 indicates the algorithm by which the targeted AAA server (AAAH) 1265 should attempt to validate the Authenticator computed by the mobile 1266 node over the Registration Request data. 1268 4.6.2 MIP-Auth-Input-Data-Length AVP 1270 The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type 1271 Unsigned32 and contains the length, in bytes, of the Registration 1272 Request data (data portion of MIP-Reg-Request AVP) that should be 1273 used as input to the algorithm (indicated by the MN-AAA-SPI AVP) used 1274 to determine whether the Authenticator Data supplied by the mobile 1275 node is valid. 1277 4.6.3 MIP-Authenticator-Length AVP 1279 The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32 1280 and contains the length of the authenticator to be validated by the 1281 targeted AAA server (i.e., AAAH). 1283 4.6.4 MIP-Authenticator-Offset AVP 1285 The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32 1286 and contains the offset into the Registration Request Data, of the 1287 authenticator to be validated by the targeted AAA server (i.e., 1288 AAAH). 1290 4.7 MIP-FA-Challenge 1292 The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and 1293 contains the challenge advertised by the foreign agent to the mobile 1294 node. This AVP MUST be present in the AMR if the mobile node used the 1295 RADIUS-style MN-AAA computation algorithm. 1297 Next text --- 1298 4.8 MIP-Filter-Rule AVP 1300 The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule, and 1301 provides filter rules that need to be configured on the foreign or 1302 home agent for the user. The packet filtering rules are set by the 1303 AAAH by adding one or more MIP-Filter-Rule AVPs in the HAR if 1304 destined for the home agent and/or in the AMA if destined for the 1305 foreign agent. 1307 4.9 MIP-Candidate-Home-Agent-Host 1309 The MIP-Candidate-Home-Agent-Host AVP (AVP Code 336) is of type 1310 DiameterIdentity and contains the identity of a home agent in the 1311 foreign network that the AAAF proposes be dynamically assigned to the 1312 mobile node. 1314 4.10 MIP-Originating-Foreign-AAA AVP 1316 The MIP-Originating-Foreign-AAA AVP (AVP Code 347) if of type 1317 Grouped, and contains the identity of the AAAF, which issues the AMR 1318 to the AAAH. The MIP- Originating-Foreign-AAA AVP MUST only be used 1319 in cases when the home agent is or may be allocated in a foreign 1320 domain. If present in the AMR, the AAAH MUST copy the MIP- 1321 Originating-Foreign-AAA AVP into the HAR. 1323 MIP-Originating-Foreign-AAA ::= < AVP Header: 347 > 1324 { Origin-Realm } 1325 { Origin-Host } 1326 * [ AVP ] 1328 4.11 MIP-Home-Agent-Host AVP 1330 The MIP-Home-Agent-Host AVP (AVP Code 348) if of type Grouped, and 1331 contains the identity of the assigned Home Agent. If present in the 1332 AMR, the AAAH MUST copy the MIP-Home-Agent-Host AVP into the HAR. 1334 MIP-Home-Agent-Host ::= < AVP Header: 348 > 1335 { Destination-Realm } 1336 { Destination-Host } 1338 * [ AVP ] 1340 5.0 Key Distribution Center 1342 The mobile node and mobility agents use session keys to compute 1343 authentication extensions applied to registration messages, as 1344 defined in [MOBILEIP]: Mobile-Foreign, Foreign-Home and Mobile-Home. 1345 If session keys are requested the AAA server(s) MUST return the key 1346 material after the mobile node is successfully authenticated and 1347 authorized. 1349 The SPI values are used as key identifiers, meaning that each session 1350 key has its own SPI value; nodes that share a key also share an SPI. 1351 The mobile node proposes SPIs for use in computing the Mobile-Foreign 1352 and Mobile-Home authentication extensions, via the Mobile IP AAA Key 1353 Request extensions [MIPKEYS], while the home agent allocates the 1354 Mobile-Foreign, Mobile-Home and Foreign-Home SPIs. 1356 Once the session keys have been distributed, subsequent Mobile IP 1357 registrations need not invoke the AAA infrastructure until the keys 1358 expire. These registrations MUST include the Mobile-Home 1359 authentication extension. In addition, subsequent registrations MUST 1360 also include Mobile-Foreign authentication extension if the Mobile- 1361 Foreign key was generated and distributed by AAA; similarly for 1362 subsequent use of the Foreign-Home authentication extensions. 1364 5.1 Authorization Lifetime vs. MIP Key Lifetime 1366 The Diameter Mobile IP application makes use of two timers - the 1367 Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. 1369 The Authorization-Lifetime contains the number of seconds before the 1370 mobile node must issue a subsequent MIP registration request. The 1371 content of the Authorization-Lifetime AVP corresponds to the Lifetime 1372 field in the MIP header [MOBILEIP]. 1374 The MIP-Key-Lifetime AVP contains the number of seconds before 1375 session keys destined for the mobility agents and the mobile node 1376 expire. A value of zero indicates infinity (no timeout). If not zero, 1377 the value of the MIP-Key-Lifetime AVP MUST be at least equal to the 1378 value in the Authorization Lifetime AVP. 1380 5.2 Key Material vs. Session Key 1382 As described in section 1.6, each mobile IP security association that 1383 is generated by the AAAH will be propagated to the mobility agents 1384 and the mobile node in two different ways. All security associations 1385 destined for the home and foreign agents are sent as session keys, 1386 protected by IPSec or TLS as defined in the [DIAMBASE]. If strong 1387 authentication and confidentiality of the session keys is required 1388 due to involvement of intermediate Diameter agents, it is recommended 1389 that the CMS security application [CMS] be used. 1391 Since the security associations for the mobile node are propagated 1392 through the mobile IPv4 protocol, the security associations are 1393 always sent in the form of key material, which the AAAH computes by 1394 generating a random [RANDOM] value of at least 64 bits. The mobile 1395 node will then use the key material to derive the session key to be 1396 used for the security associations. 1398 The following is an example of a session creation procedure, which 1399 the mobile node has to comply with, using HMAC-MD5 as the hashing 1400 algorithm to derive the key (of course the same session creation 1401 procedure must also be used by the AAAH for the opposite key sent to 1402 the home agent and foreign agent). Additional algorithms are 1403 supported, and listed in [MIPKEYS], where also the HMAC-SHA1 1404 algorithm is recommended to be used. 1406 key = HMAC-MD5(AAA-key,{Key Material | node-address}) 1408 Where: 1410 - AAA-Key is the long term secret shared between the mobile 1411 node and the AAAH. 1412 - Key material is a random [RANDOM] value of at least 64 bits. 1413 - node-address is the mobile node's identity. This is the 1414 contents of the MIP-Mobile-Node-Address AVP, unless the value 1415 of the AVP is all zero or ones, in which case of value of the 1416 User-Name AVP is used instead. 1418 It is important that the hashing algorithm used by the mobile node to 1419 construct the session key is the same as the one used by the AAAH in 1420 the session key generation procedure. The AAAH therefore indicates 1421 the algorithm used along with the key material. 1423 The Foreign-Home session key is shared between two mobility agents: 1424 the FA and HA. Since this key is not destined for the mobile node, 1425 there is no need to follow the session key generation procedures 1426 detailed above. Instead, the AAAH generates a random [RANDOM] value 1427 of at least 64 bits for use as the Foreign-Home session key. 1429 See sections 6.0 for details about the format of the AVPs used to 1430 transport the session keys. 1432 5.3 Distributing the Mobile-Home Session Key 1434 If the mobile node does not have a Mobile-Home session key, then the 1435 AAAH is likely to be the only entity trusted that is available to the 1436 mobile node. Thus, the AAAH has to generate the Mobile-Home session 1437 key, and encode it for eventual consumption by the mobile node and 1438 home agent. 1440 If the home agent is in the home realm, then the AAAH can directly 1441 encode the Mobile-Home session key into a MIP-HA-to-MN-Key AVP and 1442 include that AVP in the HAR message for delivery to the home agent. 1444 If, on the other hand, the home agent is to be allocated in the 1445 visited realm, the AAAH transmits the HAR to the foreign home agent, 1446 where, prior to delivery to the home agent, it is perused by the AAAF 1447 hosting the home agent. If the session key needs to be encrypted the 1448 AAAH will encrypt the MIP-HA-to-MN Key AVP and the MIP-FA-to-MN AVP 1449 with help of CMS security application [CMS] using the security 1450 association with the AAAF associated with the home agent. If no 1451 security association exists between the AAAH and the AAAF associated 1452 with the home agent, the AAAH will check if a security association 1453 can be established. If no security association exists and cannot be 1454 created, the AAAH MUST return a Result-Code AVP with 1455 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. 1457 The AAAH also has to arrange for the key to be delivered to the 1458 mobile node. Unfortunately, the AAA server only knows about Diameter 1459 messages and AVPs, and the mobile node only knows about Mobile IP 1460 messages and extensions [MOBILEIP]. For this purpose, AAAH encodes 1461 the Mobile-Home session key material into a MIP-MN-to-HA-Key AVP, 1462 using its security association with the mobile node, which is added 1463 to the HAR message, and delivered either to a local home agent, or to 1464 the AAAF in the case where the home agent is in the visited network. 1465 The AAAH has to rely on the home agent (that also understands 1466 Diameter) to transfer the keying information into a Mobile IP 1467 Generalized MN-HA Key Reply extension [MIPKEYS] in the Registration 1468 Reply message, using the SPI proposed by the Mobile Node in the MN-HA 1469 Key Request From AAA Subtype extension. The home agent can format the 1470 Reply message and extensions correctly for eventual delivery to the 1471 mobile node. The resulting Registration Reply is added to the HAA's 1472 MIP-Reg-Reply AVP. 1474 After the HAA message is parsed by the AAAH, and transformed into an 1475 AMA, the AMA message containing the MIP-Reg-Reply AVP will eventually 1476 be received by the the foreign agent. The foreign agent can then use 1477 that AVP to recreate a Registration Reply message, containing the 1478 Generalized MN-HA Key Reply extension, for delivery to the mobile 1479 node. 1481 In summary, the AAAH generates the Mobile-Home key material, which is 1482 added to the MIP-MN-to-HA-Key AVP. The key material is then used to 1483 compute the home agent's session key as specified in [MIPKEYS], which 1484 is then added to the MIP-HA-to-MN-Key AVP. These AVPs are delivered 1485 to a home agent by including them in a HAR message sent from either 1486 AAAH or AAAF. The home agent decodes the key for its own use. The 1487 home agent also copies the encoded key material from the MIP-MN-to- 1488 HA-Key AVP into a Generalized MN-HA Key Reply extension appended to 1489 the Mobile IP Registration Reply message. This Registration Reply 1490 message MUST also include the Mobile-Home authentication extension, 1491 created using the newly allocated Mobile-Home session key. The home 1492 agent then encodes the Registration Reply message and extensions into 1493 a MIP-Reg-Reply AVP included as part of the HAA message to be sent 1494 back to the AAA server. 1496 5.4 Distributing the Mobile-Foreign Session Key 1498 The Mobile-Foreign session key material is also generated by AAAH 1499 (upon request) and is added to the MIP-MN-to-FA-Key AVP, which is 1500 added to the HAR, and copied by the home agent into a Generalized MN- 1501 FA Key Reply Extension [MIPKEYS] to the Mobile IP Registration Reply 1502 message, using the SPI proposed by the mobile node in the MN-FA Key 1503 Request From AAA Subtype extension. Further, the home agent includes 1504 the SPI in the HAA's MIP-FA-to-MN-SPI AVP. The AAAH includes the 1505 session key in the MIP-FA-to-MN-Key AVP in the HAA, which contains 1506 the session key used by the foreign agent in the computation of the 1507 Mobile-Foreign authentication extension. 1509 If the MIP-FA-to-MN-Key AVP was present in the AMA, the foreign agent 1510 MUST include the Mobile-Foreign authentication extension in the 1511 Registration Reply, using the newly distributed key. 1513 5.5 Distributing the Foreign-Home Session Key 1515 If the home agent is in the home realm, then the AAAH has to generate 1516 the Foreign-Home session key. Otherwise, it is generated by the AAAF. 1518 5.5.1 Home Agent in the home network 1520 In the cases when the AAAH generates the Foreign-Home session key, 1521 the AAAH includes the session key in the MIP-HA-to-FA-Key AVP, and 1522 includes the AVP as part of the HAR message sent to the home agent. 1523 The corresponding session key and algorithm that is to be sent to the 1524 foreign agent is cached in the AAAH until the HAA is received. 1526 Upon receipt of the HAR, the home agent recovers the Foreign-Home 1527 session key, allocates an SPI to be used with the key. The allocated 1528 SPI is included in the HAA's MIP-FA-to-HA SPI AVP. 1530 Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key AVP, 1531 using the SPI in the MIP-FA-to-HA-SPI, and includes the AVP in the 1532 AMA. 1534 5.5.2 Home Agent in foreign network 1536 In the cases when the AAAF generates the Foreign-Home session key 1537 (home agent in foreign domain), the AAAF will, upon receipt of the 1538 HAR message, generate the Foreign-Home session key and include the 1539 session key in the MIP-HA-to-FA-Key AVP as part of the HAR message 1540 forwarded to the home agent. The corresponding session key and 1541 algorithm that is to be sent to the foreign agent is cached in the 1542 AAAF until the HAA is received. 1544 Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA Key AVP, 1545 using the SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the 1546 Foreign-Home session key destined for the foreign agent needs to be 1547 encrypted. 1549 If the AAAF's local policy determines that the session key needs to 1550 be encrypted by means other then through IPSec or TLS, as defined in 1551 [DIAMBASE], due to involvement of more then one local Diameter server 1552 or any intermediate Diameter agents, the AAAF will check if a 1553 security association can be established, using the CMS security 1554 application [CMS] with the originating host found in the MIP- 1555 Originating-Foreign-AAA AVP. If the security association 1556 establishment is successful, the AAAF will encrypt the MIP-FA-to-HA 1557 Key AVP with help of the CMS security application [CMS] with the AAAF 1558 as originator and the recipient copied from the MIP-Originating- 1559 Foreign-AAA AVP. The encrypted FA-HA Key is included by the AAAF in 1560 the HAA destined for the AAAH. Otherwise, if the security association 1561 cannot be created, the AAAF MUST return a Result-Code AVP with 1562 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. 1564 If the session key does not need to be encrypted, the AAAF will add 1565 MIP-FA-to-HA Key to the HAA, upon reception from the HA and forward 1566 the HAA to the AAAH. 1568 In either case, the AAAF removes the MIP-FA-to-HA-SPI AVP from the 1569 HAA returned to the AAAH. 1571 Upon reception of the HAA, the AAAH MUST copy either the MIP-FA-to-HA 1572 Key AVP if present or the CMS-Encrypted-data AVP if present and not 1573 destined for the AAAH into the AMA. 1575 If a Foreign-Home session key was present in the AMA, the foreign 1576 agent MUST include the Mobile-Foreign authentication extension in the 1577 Registration Reply, using the newly distributed key. 1579 5.6 Key Distribution Example 1581 Figure 9 provides an example of subsequent Mobile IP message 1582 exchange, assuming that AAAH distributed session keys for all three 1583 MN-FA, FA-HA and HA-MN authentication extensions. 1585 Mobile Node Foreign Agent Home Agent 1586 ----------- ------------- ---------- 1588 Reg-Req(MN-HA-Auth, MN-FA-Auth)--------> 1589 Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> 1591 <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) 1593 <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) 1595 Figure 9: Mobile IP Message Exchange 1597 6.0 Key Distribution Center (KDC) AVPs 1599 The Mobile-IP protocol defines a set of security associations shared 1600 between the mobile node, foreign agent and home agents. These three 1601 security associations (Mobile-Home, Mobile-Foreign, and Foreign-Home) 1602 can be dynamically created by the AAAH, known as session key and key 1603 material, and has previously been described in section 1.6 and 5.2. 1604 AAA servers supporting the Diameter Mobile IP Application MUST 1605 implement the KDC AVPs defined in this document. 1607 The names of the KDC AVPs indicate the two entities sharing the 1608 security association defined by the key or the key material; the 1609 intended receiver of the AVP is the first named entity. So, for 1610 instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key 1611 material, which the mobile node will use to derive the Mobile-Home 1612 Key, and the MIP-HA-to-MN-Key AVP contains the Mobile-Home key for 1613 the home agent. 1615 If strong authentication and confidentiality of the session keys is 1616 required, due to involvement of intermediate Diameter agents, it is 1617 recommended that the CMS security application [CMS] be used. 1619 The following table describes the Diameter AVPs defined in the Mobile 1620 IP application, their AVP Code values, types, possible flag values 1621 and whether the AVP MAY be encrypted. 1623 +---------------------+ 1624 | AVP Flag rules | 1625 |----+-----+----+-----|----+ 1626 AVP Section | | |SHLD| MUST|MAY | 1627 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1628 -----------------------------------------|----+-----+----+-----|----| 1629 MIP-Algorithm- 345 6.8 Enumerated | M | P | | V | Y | 1630 Type | | | | | | 1631 MIP-FA-to-HA-Key 328 6.2 Grouped | M | P | | V | Y | 1632 MIP-FA-to-HA-SPI 318 6.11 Unsigned32 | M | P | | V | Y | 1633 MIP-FA-to-MN-Key 326 6.1 Grouped | M | P | | V | Y | 1634 MIP-FA-to-MN-SPI 319 6.10 Unsigned32 | M | P | | V | Y | 1635 MIP-HA-to-FA-Key 329 6.3 Grouped | M | P | | V | Y | 1636 MIP-HA-to-MN-Key 332 6.4 Grouped | M | P | | V | Y | 1637 MIP-Key-Lifetime 367 6.13 Unsigned32 | M | P | | V | Y | 1638 MIP-Key-Material 335 6.12 OctetString| M | P | | V | Y | 1639 MIP-MN-to-FA-Key 325 6.5 Grouped | M | P | | V | Y | 1640 MIP-MN-to-HA-Key 331 6.6 Grouped | M | P | | V | Y | 1641 MIP-Replay-Mode 346 6.9 Enumerated | M | P | | V | Y | 1642 MIP-Session-Key 343 6.7 OctetString| M | P | | V | Y | 1644 6.1 MIP-FA-to-MN-Key AVP 1646 The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and 1647 contains the foreign agent's session key, which it shares with the 1648 mobile node. Its Data field has the following ABNF grammar: 1650 MIP-FA-to-MN-Key ::= < AVP Header: 326 > 1651 { MIP-FA-to-MN-SPI } 1652 { MIP-Algorithm-Type } 1653 { MIP-Session-Key } 1654 * [ AVP ] 1656 The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and 1657 contains the foreign agent's session key, which it shares with the 1658 home agent. Its Data field has the following ABNF grammar: 1660 MIP-FA-to-HA-Key ::= < AVP Header: 328 > 1661 { MIP-FA-to-HA-SPI } 1662 { MIP-Algorithm-Type } 1663 { MIP-Session-Key } 1664 * [ AVP ] 1666 6.3 MIP-HA-to-FA-Key AVP 1668 The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and 1669 contains the Home Agent's session key, which it shares with the 1670 foreign agent. Its Data field has the following ABNF grammar: 1671 MIP-HA-to-FA-Key ::= < AVP Header: 329 > 1672 { MIP-Algorithm-Type } 1673 { MIP-Session-Key } 1674 * [ AVP ] 1676 6.4 MIP-HA-to-MN-Key AVP 1678 The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and 1679 contains the Home Agent's session key, which it shares with the 1680 mobile node. Its Data field has the following ABNF grammar: 1682 MIP-HA-to-MN-Key ::= < AVP Header: 332 > 1683 { MIP-Algorithm-Type } 1684 { MIP-Replay-Mode } 1685 { MIP-Session-Key } 1686 * [ AVP ] 1688 6.5 MIP-MN-to-FA-Key AVP 1690 The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type Grouped, and 1691 contains the mobile node's key material, which it uses to derive the 1692 session key it shares with the foreign agent. The home agent uses 1693 this AVP in the construction of the Mobile IP "Unsolicted MN-FA Key 1694 from AAA Subtype" extension [MIPKEYS]. The SPI in the extension's FA 1695 SPI field is allocated by the home agent, but it SHOULD take into 1696 consideration the SPI requested by the mobile node in the "MN-FA Key 1697 Request From AAA Subtype" extension. 1699 MIP-MN-to-FA-Key ::= < AVP Header: 325 > 1700 { MIP-Algorithm-Type } 1701 { MIP-Key-Material } 1702 { MIP-MN-AAA-SPI } 1703 * [ AVP ] 1705 6.6 MIP-MN-to-HA-Key AVP 1707 The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type Grouped, and 1708 contains the mobile node's key material, which it uses to derive the 1709 session key it shares with the Home Agent. The Home Agent uses this 1710 AVP in the construction of the Mobile IP "Unsolicted MN-HA Key from 1711 AAA Subtype" extension [MIPKEYS]. The SPI in the extension's HA SPI 1712 field is allocated by the Home Agent, but it SHOULD take into 1713 consideration the SPI requested by the mobile node in the "MN-HA Key 1714 Request From AAA Subtype" extension. 1716 MIP-MN-to-HA-Key ::= < AVP Header: 331 > 1717 { MIP-Algorithm-Type } 1718 { MIP-Replay-Mode } 1719 { MIP-Key-Material } 1720 { MIP-MN-AAA-SPI } 1721 * [ AVP ] 1723 6.7 MIP-Session-Key AVP 1725 The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 1726 contains the Session Key to be used between two Mobile IP entities. 1728 6.8 MIP-Algorithm-Type AVP 1730 The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, and 1731 contains the Algorithm identifier used to generate the associated 1732 Mobile IP authentication extension. The following values are 1733 currently defined: 1735 1 HMAC-MD5 [HMAC] 1736 2 HMAC-SHA-1 [HMAC] 1738 6.9 MIP-Replay-Mode AVP 1740 The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and 1741 contains the replay mode the Home Agent should use when 1742 authenticating the mobile node. 1744 The following values are supported (see [MOBILEIP] for more 1745 information): 1747 1 None 1748 2 Timestamps 1749 3 Nonces 1751 6.10 MIP-FA-to-MN-SPI AVP 1753 The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and 1754 contains the Security Parameter Index the foreign agent is to use to 1755 refer to the session key it shares with the mobile node. The SPI 1756 created MUST NOT be a value between zero (0) and 255, which is the 1757 reserved namespace defined in [MOBILEIP]. This AVP MAY be added in 1758 the HAA message by the home agent for the AAAH's use in MIP-FA-to-MN- 1759 SPI AVP of the MIP-FA-to-MN-Key AVP. 1761 6.11 MIP-FA-to-HA-SPI AVP 1763 The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32, and 1764 contains the Security Parameter Index the foreign agent is to use to 1765 refer to the session key it shares with the home agent. The SPI 1766 created MUST NOT be a value between zero (0) and 255, which is the 1767 reserved namespace defined in [MOBILEIP]. If FA-HA keys are being 1768 generated, this AVP MUST be added in the HAA message by the Home 1769 Agent for the AAAH's (or AAAF's) use in providing the value of the 1770 MIP-FA-to-HA-SPI member of the grouped MIP-FA-to-HA-Key AVP. 1772 6.12 MIP-Key-Material AVP 1773 The MIP-Key-Material AVP (AVP Code 335) is of type OctetString and 1774 contains the key material sent to the mobile node. The mobile node 1775 follows the procedures in [MIPKEYS] to generate the session key used 1776 to authenticate Mobile IP registration messages. 1778 6.13 MIP-Key-Lifetime AVP 1780 The MIP-Key-Lifetime AVP (AVP Code 367) is of type Unsigned32 and 1781 represents the period of time (in seconds) for which the session key 1782 is valid. The session key MUST NOT be used if the lifetime has 1783 expired; if the key lifetime expires while the session to which it 1784 applies is still active, either the session key MUST be changed or 1785 the or the session MUST be terminated. 1787 7.0 Accounting AVPs 1789 This section will define the Accounting AVPs that are specific to 1790 Mobile IP. 1792 7.1 Accounting-Input-Octets AVP 1794 The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64, 1795 and contains the number of octets in IP packets received from the 1796 user. This AVP MUST be included in all Accounting-Request messages 1797 and MAY be present in the corresponding Accounting-Answer messages as 1798 well. 1800 7.2 Accounting-Output-Octets AVP 1802 The Accounting-Output-Octets AVP (AVP Code 364) is of type 1803 Unsigned64, and contains the number of octets in IP packets sent to 1804 the user. This AVP MUST be included in all Accounting-Request 1805 messages and MAY be present in the corresponding Accounting-Answer 1806 messages as well. 1808 7.3 Acct-Session-Time AVP 1810 The Acct-Time AVP (AVP Code 46) is of type Unsigned32, and indicates 1811 the length of the current session in seconds. This AVP MUST be 1812 included in all Accounting-Request messages and MAY be present in the 1813 corresponding Accounting-Answer messages as well. 1815 7.4 Accounting-Input-Packets AVP 1817 The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64, 1818 and contains the number of IP packets received from the user. This 1819 AVP MUST be included in all Accounting-Request messages and MAY be 1820 present in the corresponding Accounting-Answer messages as well. 1822 7.5 Accounting-Output-Packets AVP 1824 The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64, 1825 and contains the number of IP packets sent to the user. This AVP MUST 1826 be included in all Accounting-Request messages and MAY be present in 1827 the corresponding Accounting-Answer messages as well. 1829 7.6 Event-Timestamp AVP 1831 The Event-Timestamp (AVP Code 55) is of type Time, and MAY be 1832 included in an Accounting-Request message to record the time that 1833 this event occurred on the mobility agent, in seconds since January 1834 1, 1970 00:00 UTC. 1836 8.0 AVP Occurrence Tables 1838 The following tables presents the AVPs defined in this document, and 1839 specifies in which Diameter messages they MAY, or MAY NOT be present. 1840 Note that AVPs that can only be present within a Grouped AVP are not 1841 represented in this table. 1843 The table uses the following symbols: 1844 0 The AVP MUST NOT be present in the message. 1845 0+ Zero or more instances of the AVP MAY be present in the 1846 message. 1847 0-1 Zero or one instance of the AVP MAY be present in the 1848 message. 1849 1 One instance of the AVP MUST be present in the message. 1851 8.1 Mobile IP Command AVP Table 1853 The table in this section is limited to the Command Codes defined in 1854 this specification. 1856 +-----------------------+ 1857 | Command-Code | 1858 |-----+-----+-----+-----+ 1859 Attribute Name | AMR | AMA | HAR | HAA | 1860 ------------------------------|-----+-----+-----+-----+ 1861 Authorization-Lifetime | 0-1 | 0-1 | 1 | 0 | 1862 Auth-Application-Id | 1 | 1 | 1 | 1 | 1863 Auth-Session-State | 0-1 | 0-1 | 1 | 0 | 1864 Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 0-1 | 1865 Destination-Host | 0-1 | 0 | 0-1 | 0 | 1866 Destination-Realm | 1 | 0 | 1 | 0 | 1867 Error-Message | 0 | 0-1 | 0 | 0-1 | 1868 Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 | 1869 MIP-Candidate-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 | 1870 MIP-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 | 1871 MIP-Originating-Foreign-AAA | 0-1 | 0 | 0-1 | 0 | 1872 MIP-FA-Challenge | 0-1 | 0 | 0 | 0 | 1873 MIP-FA-to-HA-Key | 0 | 0-1 | 0-1 | 0 | 1874 MIP-FA-to-HA-SPI | 0 | 0 | 0 | 0-1 | 1875 MIP-FA-to-MN-Key | 0 | 0-1 | 0 | 0 | 1876 MIP-FA-to-MN-SPI | 0 | 0 | 0 | 0-1 | 1877 MIP-Feature-Vector | 0-1 | 0-1 | 1 | 0 | 1878 MIP-Filter-Rule | 0 | 0+ | 0+ | 0 | 1879 MIP-HA-to-FA-Key | 0 | 0-1 | 0-1 | 0 | 1880 MIP-HA-to-MN-Key | 0 | 0-1 | 0-1 | 0 | 1881 MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 | 1882 MIP-Key-Lifetime | 0 | 0-1 | 0-1 | 0 | 1883 MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 | 1884 MIP-MN-to-FA-Key | 0 | 0-1 | 0-1 | 0 | 1885 MIP-MN-to-HA-Key | 0 | 0-1 | 0-1 | 0 | 1886 MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 | 1887 MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 | 1888 MIP-Reg-Request | 1 | 0 | 1 | 0 | 1889 Origin-Host | 1 | 1 | 1 | 1 | 1890 Origin-Realm | 1 | 1 | 1 | 1 | 1891 Origin-State-Id | 0-1 | 0-1 | 0-1 | 0-1 | 1892 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 1893 Redirect-Host | 0 | 0+ | 0 | 0+ | 1894 Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 | 1895 Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 | 1896 Result-Code | 0 | 1 | 0 | 1 | 1897 Re-Auth-Request-Type | 0 | 0-1 | 0 | 0 | 1898 Route-Record | 0+ | 0 | 0+ | 0 | 1899 Session-Id | 1 | 1 | 1 | 1 | 1900 User-Name | 1 | 0-1 | 1 | 0-1 | 1901 ------------------------------|-----+-----+-----+-----| 1903 8.2 Accounting AVP Table 1905 The table in this section is used to represent which AVPs defined in 1906 this document are to be present in the Accounting messages, defined 1907 in [DIAMBASE]. 1909 +-------------+ 1910 | Command-Code| 1911 |------+------+ 1912 Attribute Name | ACR | ACA | 1913 -------------------------------------|------+------+ 1914 Accounting-Input-Octets | 1 | 0-1 | 1915 Accounting-Input-Packets | 1 | 0-1 | 1916 Accounting-Output-Octets | 1 | 0-1 | 1917 Accounting-Output-Packets | 1 | 0-1 | 1918 Acct-Multi-Session-Id | 1 | 0-1 | 1919 Acct-Session-Time | 1 | 0-1 | 1920 MIP-Feature-Vector | 1 | 0-1 | 1921 MIP-Home-Agent-Address | 1 | 0-1 | 1922 MIP-Mobile-Node-Address | 1 | 0-1 | 1923 Event-Timestamp | 0-1 | 0 | 1924 -------------------------------------|------+------+ 1926 9.0 IANA Considerations 1928 This section contains the namespaces that have either been created in 1929 this specification, or the values assigned to existing namespaces 1930 managed by IANA. 1932 9.1 Command Codes 1934 This specification assigns the values 260 and 262 from the Command 1935 Code namespace defined in [DIAMBASE]. See section 2.0 for the 1936 assignment of the namespace in this specification. 1938 9.2 AVP Codes 1940 This specification assigns the values 318-348 and 363-367 from the 1941 AVP Code namespace defined in [DIAMBASE]. See sections 4.0 and 6.0 1942 for the assignment of the namespace in this specification. 1944 9.3 Result-Code AVP Values 1946 This specification assigns the values 4005-4008, and 5024-5025 from 1947 the Result-Code AVP (AVP Code 268) value namespace defined in 1948 [DIAMBASE]. See section 3.0 for the assignment of the namespace in 1949 this specification. 1951 9.4 MIP-Feature-Vector AVP Values 1953 There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that 1954 are available for assignment. This document assigns bits 1-9, as 1955 listed in section 4.5. The remaining bits should only be assigned via 1956 Standards Action [IANA]. 1958 9.5 MIP-Algorithm-Type AVP Values 1960 As defined in Section 6.8, the MIP-Algorithm-Type AVP (AVP Code 345) 1961 defines the values 1-3. All remaining values are available for 1962 assignment via Designated Expert [IANA]. 1964 9.6 MIP-Replay-Mode AVP Values 1966 As defined in Section 6.9, the MIP-Replay-Mode AVP (AVP Code 346) 1967 defines the values 1-3. All remaining values, except zero, are 1968 available for assignment via Designated Expert [IANA]. 1970 9.7 Application Identifier 1972 This specification assigns the value four (4) to the Application 1973 Identifier namespace defined in [DIAMBASE]. See section 1.7 for more 1974 information. 1976 10.0 Security Considerations 1978 This specification describes the Diameter Application necessary to 1979 authenticate and authorize a Mobile IP mobile node. The 1980 authentication algorithm used is dependent upon the transforms 1981 available by the Mobile IP protocol, and [MIPCHAL]. This 1982 specification also defines a method by which the home Diameter server 1983 can create and distribute session keys to be used to authenticate 1984 Mobile IP registration messages [MOBILEIP]. The key distribution is 1985 asymmetric due to the fact the keys to the mobile node have to be 1986 propagated via the mobile IP protocol [AAAKEY, MOBILEIP], while the 1987 mobility agent keys are propagated via the Diameter protocol. This 1988 means that the keys destined to the mobility agents are always 1989 protected by IPSec or TLS as defined in [DIAMBASE], when deployed 1990 without any Diameter agents, or protected using the methods defined 1991 in [CMS], when deployed in an environment that includes Diameter 1992 agents. The keys destined for the mobile node are always sent as key 1993 material, which is used to derive the actual keys, which means that 1994 it does not expose any data that could be used in an attack aimed at 1995 recovering the long term key shared between the mobile node and the 1996 home Diameter server. 1998 Periodic key refreshment is a fundamental security practice that 1999 helps against potential weaknesses of the function and keys, and 2000 limits the damage of an exposed key. Therefore, must the long-term 2001 shared secret between the mobile node and the home Diameter server 2002 also be periodically refreshed, by utilizing some out-of-band 2003 mechanism, since this shared secret cannot be refreshed by any in- 2004 band mechanism. 2006 It should also be noted that it is not recommended to set the MIP- 2007 Session-Key AVP value equal to zero, since keeping session keys for a 2008 long time (no refresh) increases the vulnerability of the system. 2010 11.0 References 2012 11.1 Normative 2014 [DIAMBASE] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, 2015 "Diameter Base Protocol", draft-ietf-aaa-diameter-12.txt, 2016 IETF work in progress, July 2002. 2018 [IANA] Narten, Alvestrand,"Guidelines for Writing an IANA Con� 2019 siderations Section in RFCs", BCP 26, RFC 2434, October 2020 1998 2022 [MOBILEIP] C. Perkins, Editor. IP Mobility Support. RFC 3220, Jan� 2023 uary 2002. 2025 [MIPCHAL] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response 2026 Extensions". RFC 3012. November 2000. 2028 [NAI] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2029 2486. January 1999. 2031 [HMAC] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed- 2032 Hashing for Message Authentication. RFC 2104, February 2033 1997. 2035 [MIPKEYS] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile 2036 IP", draft-ietf-mobileip-aaa-key-09.txt, IETF work in 2037 progress, July 2001. 2039 [AAANAI] F. Johansson, T.Johansson, "AAA NAI for Mobile IPv4 2040 Extension", draft-mobileip-aaa-nai-02.txt, IETF work in 2041 progress, May 2002. 2043 11.2 Informative 2045 [MIPREQ] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentica� 2046 tion, Authorization, and Accounting Requirements". RFC 2047 2977. October 2000. 2049 [CDMA2000] T. Hiller and al, "CDMA2000 Wireless Data Requirements 2050 for AAA", RFC 3141, June 2001. 2052 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 2053 Requirement Levels", BCP 14, RFC 2119, March 1997. 2055 [EVALROAM] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Pro� 2056 tocols", RFC 2477, January 1999. 2058 [MIPNAI] P. Calhoun, C. Perkins, "Mobile IP Network Address Iden� 2059 tifier Extension", RFC 2794, March 2000. 2061 [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security 2062 Application", draft-ietf-aaa-diameter-cms-sec-05.txt, 2063 IETF work in progress, April 2002. 2065 [RANDOM] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Random� 2066 ness Recommendations for Security. Request for Comments 2067 (Informational) 1750, Internet Engineering Task Force, 2068 December 1994. 2070 12.0 Acknowledgements 2072 The authors would like to thank Nenad Trifunovic, Haseeb Akhtar and 2073 Pankaj Patel for their participation in the pre-IETF Document Reading 2074 Party, to Erik Guttman for his very useful proposed text, and to 2075 Fredrik Johansson, Martin Julien and Bob Kopacz for their very useful 2076 contributed text. 2078 The authors would also like to thank the participants of 3GPP2's TSG- 2079 P working group for their valuable feedback and also the following 2080 people for their contribution in the development of the protocol: 2082 Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael 2083 Chen, Henry Haverinen, Johan Johansson 2085 Finally, Pat Calhoun would like to thank Sun Microsystems since most 2086 of the effort put into this document was done while he was in their 2087 employ. 2089 13.0 Authors' Addresses 2091 Questions about this memo can be directed to: 2093 Pat R. Calhoun 2094 Black Storm Networks 2095 250 Cambridge Avenue, Suite 200 2096 Palo Alto, California, 94306 2097 USA 2099 Phone: +1 650-617-2932 2100 Fax: +1 650-786-6445 2101 E-mail: pcalhoun@bstormnetworks.com 2102 Tony Johansson 2103 Ericsson Inc 2104 2100 Shattuck Avenue 2105 Berkeley, California 94704 2106 USA 2108 Phone: +1 510-541-8783 2109 Fax: +1 510-666-3900 2110 E-Mail: tony.johansson@ericsson.com 2112 Charles E. Perkins 2113 Nokia Research Center 2114 313 Fairchild Drive 2115 Mountain View, California 94043 2116 USA 2118 Phone: +1 650-625-2986 2119 Fax: +1 650-625-2502 2120 E-Mail: charliep@iprg.nokia.com 2122 Copyright (C) The Internet Society (2001). All Rights Reserved. 2124 This document and translations of it may be copied and furnished to 2125 others, and derivative works that comment on or otherwise explain it 2126 or assist in its implementation may be prepared, copied, published 2127 and distributed, in whole or in part, without restriction of any 2128 kind, provided that the above copyright notice and this paragraph are 2129 included on all such copies and derivative works. However, this docu� 2130 ment itself may not be modified in any way, such as by removing the 2131 copyright notice or references to the Internet Society or other 2132 Internet organizations, except as needed for the purpose of develop� 2133 ing Internet standards in which case the procedures for copyrights 2134 defined in the Internet Standards process must be followed, or as 2135 required to translate it into languages other than English. The lim� 2136 ited permissions granted above are perpetual and will not be revoked 2137 by the Internet Society or its successors or assigns. This document 2138 and the information contained herein is provided on an "AS IS" basis 2139 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS� 2140 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 2141 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2142 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2143 FITNESS FOR A PARTICULAR PURPOSE. 2145 15.0 Expiration Date 2147 This memo is filed as and 2148 expires in January 2003.