idnits 2.17.1 draft-ietf-aaa-diameter-mobileip-15.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 40 longer pages, the longest (page 12) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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: Calhoun Standards Track - March 2003 2 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 (November 2003) is 7467 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) -- Looks like a reference, but probably isn't: '1' on line 19 -- Looks like a reference, but probably isn't: '2' on line 57 == Missing Reference: 'AAAKEY' is mentioned on line 1895, but not defined == Unused Reference: 'KEYWORDS' is defined on line 1968, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-ietf-aaa-diameter is -16, but you're referring to -17. -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' ** Obsolete normative reference: RFC 3344 (ref. 'MOBILEIP') (Obsoleted by RFC 5944) == Outdated reference: A later version (-05) exists of draft-ietf-mip4-rfc3012bis-00 ** Obsolete normative reference: RFC 2486 (ref. 'NAI') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') -- No information found for draft-ietf-mipv4-aaa-key - is the name correct? -- 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' -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 12 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 Airespace 4 draft-ietf-aaa-diameter-mobileip-15.txt Tony Johansson 5 Category: Standards Track Bytemobile Inc 6 Charles E. Perkins 7 Nokia Research Center 8 Tom Hiller 9 (editor) 10 Lucent Technologies 11 November 2003 13 Diameter Mobile IP Application 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [1]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 1. Abstract 37 This document specifies a Diameter application that allows a Diameter 38 server to authenticate, authorize and collect accounting information 39 for Mobile IP services rendered to a mobile node. Combined with the 40 Inter-Realm capability of the base protocol, this application allows 41 mobile nodes to receive service from foreign service providers. 42 Diameter Accounting messages will be used by the foreign and home 43 agents to transfer usage information to the Diameter servers. 45 2. Conventions used in this document 47 50 In examples, "C:" and "S:" indicate lines sent by the client and 51 server respectively. 53 Calhoun et al Standards Track - March 2004 1 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 56 this document are to be interpreted as described in RFC-2119 [2]. 58 3. Introduction 60 Mobile IP, as defined in [MOBILEIP], defines a method that allows a 61 mobile node to change its point of attachment to the Internet with 62 minimal service disruption. Mobile IP does not provide any specific 63 support for mobility across disparate administrative domains, and 64 therefore does not specify how usage can be accounted for, which has 65 limited the applicability of Mobile IP in a IPv4 commercial 66 deployment. The Mobile IP specification as defined in [MOBILEIP] 67 recommends mobile nodes to have a static home address and a home 68 agent. However this may not be always possible in certain deployment 69 scenarios. Recent developments in areas that impact IP mobility in 70 the IETF allow Mobile IP [MOBILEIP] to work just as well when mobile 71 nodes do not have a static home agent and home address. In addition, 72 another specification [MIPNAI] allows a mobile node to use its NAI 73 instead of its home address, which better accommodates current 74 administrative practice. 76 This document specifies Application-ID 4 to the Diameter base 77 protocol [DIAMBASE] that allows a Diameter server to authenticate, 78 authorize and collect accounting information for Mobile IP services 79 rendered to a mobile node. This application MUST NOT be used in 80 conjunction with the Mobile IPv6 protocol. 82 Combined with the Inter-Realm capability of the Diameter base 83 protocol, this application allows mobile nodes to receive service 84 from foreign service providers. The Diameter Accounting messages will 85 be used by the foreign and home agents to transfer usage information 86 to the Diameter servers. 88 The Mobile IP protocol [MOBILEIP] specifies a security model that 89 requires that mobile nodes and home agents share a pre-existing 90 security association, which leads to scaling and configuration 91 issues. This specification defines Diameter functions that allow the 92 AAA server to act as a Key Distribution Center (KDC), whereby dynamic 93 session keys are created and distributed to the mobility entities for 94 the purposes of securing Mobile IP Registration messages. Strong 95 authentication and confidentiality of session keys is required, and 96 is to be provided via mutually authenticated TLS or IPsec. 98 As with the Diameter base protocol, AAA servers implementing the 99 Mobile IP application can process users' identities supplied in a 100 Network Access Identifier (NAI) format [NAI], which is used for 101 Diameter message routing purposes. Mobile nodes include their NAI in 102 Registration messages, as defined in [MIPNAI]. The use of the NAI is 103 consistent with the roaming model defined by the ROAMOPS Working 104 Group [EVALROAM]. 106 Calhoun Standards Track - March 2003 2 107 A home AAA server (AAAH) and foreign AAA server (AAAF), which support 108 the Mobile-IP authentication application MAY maintain session-state 109 or MAY be session-stateless. AAA redirect agents and AAA relay agents 110 MUST not maintain session-state. The AAAH, AAAF, proxies and relays 111 agents MUST maintain transaction state. 113 Given the nature of Mobile IP, a re-authentication can only be 114 initiated by a mobile node, which does not participate in the 115 Diameter message exchanges. Therefore Diameter server initiated re- 116 auth does not apply to this application. 118 Furthermore, the nature of Mobile IP also means that the mobile node 119 will do handoffs between different foreign agents. To guarantee that 120 a registered user always ends up in the same initial AAAH, the mobile 121 node SHOULD always include the AAAH NAI [AAANAI]. Finally, to assist 122 the AAAH in routing the messages to a mobile node's home agent the 123 mobile node SHOULD always include the HA NAI [AAANAI]. If the mobile 124 node does not support the Mobile IP AAA NAI extension [AAANAI], this 125 MAY limit the functionality that can be offered to such a mobile 126 node. 128 The Diameter Mobile-IP Application meets the requirements specified 129 in [MIPREQ, CDMA2000]. Later subsections in this introductory section 130 provide some examples and message flows of the Mobile IP and Diameter 131 messages that occur when a mobile node requests service in a foreign 132 network. In this document, the role of the "attendant" [MIPREQ] is 133 performed by either the home agents (for co-located mobile nodes) or 134 foreign agents for the Mobile-IP Application, and these terms will be 135 used interchangeably. 137 3.2 Inter-Realm Mobile IP 139 When a mobile node requests service by issuing a Registration Request 140 to the foreign agent, the foreign agent creates the AA-Mobile-Node- 141 Request (AMR) message, which includes the AVPs defined in section 142 2.1. The Home Address, Home Agent, Mobile Node NAI and other 143 important fields are extracted from the registration messages for 144 possible inclusion as Diameter AVPs. The AMR message is then 145 forwarded to the local Diameter server, known as the AAA-Foreign, or 146 AAAF. 148 Visited Realm Home Realm 149 +--------+ +--------+ 151 Calhoun Standards Track - March 2003 3 152 |abc.com | AMR/AMA |xyz.com | 153 | AAAF |<------------------->| AAAH | 154 +->| server | server-server | server | 155 | +--------+ communication +--------+ 156 | ^ ^ 157 | AMR/AMA | client-server | HAR/HAA 159 | | communication | 160 v v v 161 +---------+ +---------+ +---------+ 162 | Foreign | | Foreign | | Home | 163 | Agent | | Agent | | Agent | 164 +---------+ +---------+ +---------+ 165 ^ 166 | Mobile IP 167 | 168 v 169 +--------+ 170 | Mobile | 171 | Node | mn@xyz.com 172 +--------+ 173 Figure 1: Inter-Realm Mobility 175 Upon receiving the AMR, the AAAF follows the procedures outlined in 176 [DIAMBASE] to determine whether the AMR should be processed locally, 177 or if it should be forwarded to another Diameter server, known as the 178 AAA-Home, or AAAH. Figure 1 shows an example in which a mobile node 179 (mn@xyz.com) requests service from a foreign provider (abc.com). The 180 request received by the AAAF is forwarded to xyz.com's AAAH server. 182 Figure 2 shows the message flows involved when the foreign agent 183 invokes the AAA infrastructure to request that a mobile node be 184 authenticated and authorized. Note that it is not required that the 185 foreign agent invoke AAA services every time a Registration Request 186 is received from the mobile, but rather only when the prior 187 authorization from the AAAH expires. The expiration time of the 188 authorization is communicated through the Authorization-Lifetime AVP 189 in the AA-Mobile-Node-Answer (AMA, see section 2.2) from the AAAH. 191 Mobile Node Foreign Agent AAAF AAAH Home 192 Agent 194 Calhoun Standards Track - March 2003 4 195 ----------- ------------- ------------ ---------- ------- 196 Advertisement & 197 <--------- Challenge 199 Reg-Req&MN-AAA ----> 201 AMR------------> 202 Session-Id = foo 204 AMR------------> 205 Session-Id = foo 207 HAR-----------> 208 Session-Id = bar 210 <----------HAA 211 Session-Id = bar 213 <-----------AMA 214 Session-Id = foo 216 <------------AMA 217 Session-Id = foo 219 <-------Reg-Reply 221 Figure 2: Mobile IP/Diameter Message Exchange 223 The foreign agent (as shown in Figure 2) MAY provide a challenge, 224 which gives it direct control over the replay protection in the 225 Mobile IP registration process, as described in [MIPCHAL]. The 226 mobile node includes the Challenge and MN-AAA authentication 227 extension to enable authorization by AAAH. If the authentication data 228 supplied in the MN-AAA extension is invalid, AAAH returns the 229 response (AMA) with the Result-Code AVP set to 230 DIAMETER_AUTHENTICATION_REJECTED. 232 The above scenario causes the MN-FA and MN-HA keys to be exposed to 233 Diameter agents all along the Diameter route. A more proper approach 234 is to eliminate the AAAF and other Diameter agents as follows: 236 Calhoun Standards Track - March 2003 5 237 Local redirect Home 238 FA AAAF Agent Server 239 AMR 240 ----------------> 241 AMA (Redirect) 242 ----------------> 243 AMA (Redirect) 244 <---------------- 245 AMA (Redirect) 246 <---------------- 248 Setup Security Association 249 <--------------------------------------------------> 251 AMR 252 --------------------------------------------------> 253 AMA (MN-FA key) 254 <--------------------------------------------------- 256 Figure 3: Use of a Redirect Server with AMR/AMA 258 Figure 4 shows the HA and the AAAH are in the same network so it is 259 likely that the HAAA knows the IP address of the HA, and the redirect 260 server would therefore not be needed, but are shown for completeness. 262 The FA still provides the challenge and the mobile sends the RRQ, 263 etc., as in the previous figure, however these were eliminated from 264 Figure 3 and 4 to reduce figure clutter. The redirect server 265 eliminates the AAAF and any other Diameter agents from seeing the 266 keys as they are transported to the FA and HA. 268 Local Redirect Home 269 HA Agent Server 270 HAR 271 <-------------------- 272 HAA (Redirect) 273 --------------------> 274 Setup Security Association 275 <----------------------------------------> 276 HAR (MN-HA key) 277 <----------------------------------------- 278 HAA 279 -----------------------------------------> 281 Figure 4: Use of a Redirect Server with HAR/HAA 283 Accounting messages are sent via Diameter agents, not the direct 284 connection, unless network policies dictate otherwise. 286 Calhoun Standards Track - March 2003 6 287 A mobile node with AAA NAI extension support [AAANAI], which has been 288 previously authenticated and authorized, MUST always include the 289 assigned home agent in the HA Identity subtype of the AAA NAI 290 extension, and the authorizing Home AAA server in the AAAH Identity 291 subtype of the AAA NAI extension, when re-authenticating. So, in the 292 event that the AMR generated by the FA is for a session that was 293 previously authorized, it MUST include the Destination-Host AVP, with 294 the identity of the AAAH found in the AAAH-NAI, and the MIP-Home- 295 Agent-Host AVP with the identity and realm of the assigned HA found 296 in the HA-NAI. If on the other hand the mobile node does not support 297 the AAA NAI extension, the FA may not have the identity of the AAAH 298 and the identity and realm of the assigned HA. This means that 299 without support of the AAA NAI extension, the FA may not be able to 300 guarantee, that the AMR will be destined to the same AAAH, which 301 previously authenticated and authorized the mobile node, since the FA 302 may not know the identity of the AAAH. 304 If the mobile node was successfully authenticated, the AAAH checks if 305 the home agent was located in the foreign realm, by checking Home- 306 Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. Other 307 AVP's like the MIP-Home-Agent-Host AVP and the MIP-Originating- 308 Foreign-AAA AVP may also be used to verify the location of the home 309 agent. If the home agent is located in the home realm, then the AAAH 310 sends an HAR message to the home agent, which contains a MIP-Reg- 311 Request AVP. 313 However, as in the case of the AMA and the MN-FA key, using Diameter 314 agents exposes the MN-HA key to Diameter agents along the way. 315 Figure 4 shows the use of a redirect server to avoid this problem. 317 If the home agent was not located in the foreign realm, the AAAH 318 checks for the MIP-Home-Agent-Address AVP and if present the MIP- 319 Home-Agent-Host AVP. If one was specified, the AAAH checks that the 320 address is that of a known home agent and that the mobile node is 321 allowed to request this particular home agent, and that the home 322 agent's identity is included in the MIP-Home-Agent-Host AVP. If no 323 home agent was specified, and if the MIP-Feature-Vector has the Home- 324 Agent-Requested flag set, and if allowed by policy in the home realm, 325 the AAAH SHOULD allocate a home agent on behalf of the mobile node. 326 This can be done in a variety of ways, including using a load- 327 balancing algorithm in order to keep the load on all home agents 328 equal. The actual algorithm used and the method of discovering the 329 home agents is outside the scope of this specification. 331 The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains 332 the Mobile IP Registration Request message data encapsulated in the 333 MIP-Reg-Request AVP, to the assigned or requested Home Agent. Refer 334 to Figure 4 if the HA does not have a direct path to the HA. The 335 AAAH MAY allocate a home address for the mobile node, while the Home 336 Agent MUST support home address allocation. In the event the AAAH 337 handles address allocation, it includes it in a MIP-Mobile-Node- 338 Address AVP within the HAR. The absence of this AVP informs the Home 339 Agent to perform the allocation. 341 Calhoun Standards Track - March 2003 7 342 During the creation of the HAR, the AAAH MUST use a different session 343 identifier than the one used in the AMR/AMA (see Figure 2). If the 344 AAAH is session-stateful, it MUST send the same session identifier 345 for all HARs initiated on behalf of a given mobile node's session. 346 Otherwise, if the AAAH is session-stateless, it will manufacture a 347 unique session-id for every HAR. 349 A mobile node's session is identified via its identity in the User- 350 Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address 351 AVPs. This is necessary in order to allow the session state machine, 352 defined in the base protocol [DIAMBASE], to be used unmodified with 353 this application. Therefore, an STR from a foreign agent would free 354 the session from the foreign agent, but not the one towards the home 355 agent (see figure 5). 357 STR, Session-Id = foo STR, Session-Id = bar 358 ---------------------> <-------------------- 359 +----+ +------+ +------+ +----+ 360 | FA | | AAAF | | AAAH | | HA | 361 +----+ +------+ +------+ +----+ 362 <--------------------- ---------------------> 363 STA, Session-Id = foo STA, Session-Id = bar 365 Figure 5: Session Termination and Session Identifiers 367 Upon receipt of the HAR, the home agent first processes the Diameter 368 message. The home agent processes the MIP-Reg-Request AVP and creates 369 the Registration Reply, encapsulating it within the MIP-Reg-Reply 370 AVP. In the creation of the Registration Reply the Home Agent must 371 include the HA NAI and the AAAH NAI, which will be created from the 372 Origin-Host AVP and Origin-Realm AVP of the HAR. If a home address is 373 needed, the home agent MUST also assign one and include the address 374 in both the Registration Reply and within the MIP-Mobile-Node-Address 375 AVP. 377 The HA MUST include an Acct-Multi-Session-Id AVP in the HAA returned 378 to the AAAH. Upon receipt of the HAA, the AAAH creates the AA- 379 Mobile-Node-Answer (AMA) message, includes the Acct-Multi-Session-Id 380 that was present in the HAA, and the MIP-Home-Agent-Address, MIP- 381 Mobile-Node-Address AVPs in the AMA message. See Figure 3 and 4 for 382 the use of the redirect agent for the secure transport of the HAA and 383 AMA messages. 385 3.3 Support for Mobile IP Handoffs 387 Given the nature of Mobile IP, a mobile node MAY receive service from 388 many foreign agents during a period of time. However, the home realm 389 should not view these handoffs as different sessions, since this 390 could affect billing systems. Furthermore, many foreign agents do not 391 communicate, which makes it quite difficult for AAA information to be 392 exchanged between these entities. Therefore, it MUST be assumed that 394 Calhoun Standards Track - March 2003 8 395 a foreign agent is not aware that a registration request from a 396 mobile node has been previously authorized. 398 A handoff registration request from a mobile node will cause an AMR 399 to be sent to its AAAF. The AMR will include a new session 400 identifier, and MAY be sent to an AAAF in the visited network other 401 than the AAAF, which received the previous AMR. However, with the 402 usage of the AAA NAI, this AMR is guaranteed to be received by the 403 AAAH to which the user is currently registered. 405 As discussed above, it may be undesirable for keys, such as the MN-FA 406 keys, to be exposed to any Diameter Agents. In this case the FA 407 should establish a security association with the AAAH directly, using 408 redirects as described above. This completely eliminates the AAAF 409 from the transaction. 411 Since the AAAH may be session-stateless, it is necessary for the 412 resulting HAR received by the HA to be identified as a continuation 413 of an existing session. If the HA receives an HAR for a mobile node, 414 with a new session identifier, and the HA can guarantee that this 415 request is to extend service for an existing service, then the HA 416 MUST be able to modify its internal session state information to 417 reflect the new session identifier. 419 It is necessary for accounting records to have some commonality 420 across handoffs in order for correlation to occur. Therefore, the 421 home agent MUST send the same Acct-Multi-Session-Id AVP value in all 422 HAAs for the mobile's session. That is, the HA generates a unique 423 Acct-Multi-Session-Id when receiving an HAR for a new session, and 424 returns this same value in every HAA for the session. This Acct- 425 Multi-Session-Id AVP will be returned to the foreign agent by the 426 AAAH in the AMA. Both the foreign and home agents MUST include the 427 Acct-Multi-Session-Id in the accounting messages. 429 ACR, Session-Id = foo ACR, Session-Id = bar 430 Acct-Multi-Session-Id = a Acct-Multi-Session-Id = a 431 ---------------------> <-------------------- 432 +----+ +------+ +------+ +----+ 433 | FA | | AAAF | | AAAH | | HA | 434 +----+ +------+ +------+ +----+ 435 <--------------------- ---------------------> 436 ACA, Session-Id = foo ACA, Session-Id = bar 438 Figure 6: Accounting messages w/ Mobile IP Application 440 3.4 Allocation of Home Agent in Foreign Network 442 The Diameter Mobile IP application allows a home agent to be 443 allocated in a foreign network, as required in [MIPREQ, CDMA2000]. 444 When a foreign agent detects that the mobile node has a home agent 445 address equal to 0.0.0.0 or 255.255.255.255 in the Registration 446 Request message, it MUST add a MIP-Feature-Vector AVP with the Home- 448 Calhoun Standards Track - March 2003 9 449 Agent-Requested flag set to one. If the home agent address is equal 450 to 255.255.255.255, then the foreign agent also MUST set the Home- 451 Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home 452 agent address is set to 0.0.0.0, the foreign agent MUST set the Home- 453 Address-Allocatable-Only-in-Home-Realm flag equal to zero. 455 When the AAAF receives an AMR message with the Home-Agent-Requested 456 flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm 457 flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available 458 flag in the MIP-Feature-Vector AVP to inform the AAAH that it is 459 willing and able to assign a Home Agent for the mobile node. When 460 doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP 461 and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home- 462 Agent-Host AVP contains the identity of the home agent that would be 463 assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP 464 contains the identity of the AAAF. 466 In the event that the mobile node with AAA NAI extension support 467 [AAANAI] has been previously authorized by the AAAH and now needs to 468 be re-authenticated, and requests to keep the assigned home agent in 469 the foreign network, the mobile node MUST include the HA NAI and the 470 AAAH NAI in the registration request to the FA. Upon receipt, the FA 471 will create the AMR including the MIP-Home-Agent-Address AVP, the 472 Destination-Host AVP based on the AAAH NAI and include the MIP-Home- 473 Agent-Host AVP based on the home agent NAI. If the AAAF authorizes 474 the use of the requested home agent, the AAAF MUST set the Home- 475 Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. 477 In the event that the mobile node that does not support the AAA NAI 478 extension has been previously authorized by the AAAH and now needs to 479 be re-authenticated, and requests to keep the assigned home agent in 480 the foreign network, the mobile node sends a registration request 481 without the AAA NAI and the HA NAI. Upon receipt, the FA will create 482 the AMR including the MIP-Home-Agent-Address AVP. If the AAAF 483 authorizes the use of the requested home agent, and if it has 484 knowledge that the requested home agent is in its own domain, the 485 AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP- 486 Feature-Vector AVP. 488 As above, the use of Diameter servers in this exchange will expose 489 keys. If this is deemed undesirable, a redirect server approach 490 should be utilized to communicate the AMR to the AAAH. This causes 491 the FA to communicate the AMR directly to the AAAH via a security 492 association. 494 When the AAAH receives an AMR message, it first checks the 495 authentication data supplied by the mobile node, according to the 496 MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether 497 to authorize the mobile node. If the AMR indicates that the AAAF has 498 offered to allocate a Home Agent for the mobile node, i.e. the 499 Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP, or 500 the AMR indicates that the AAAF has offered a previously allocated 501 Home Agent for the mobile node, i.e. the Home-Agent-In-Foreign- 503 Calhoun Standards Track - March 2003 10 504 Network is set in the MIP-Feature-Vector AVP, then the AAAH must 505 decide whether its local policy would allow the user to have a Home 506 Agent in the foreign network or to keep the Home Agent in the foreign 507 network. If so, and after checking authorization from the data in the 508 AMR message, the AAAH sends the HAR message to Home Agent by 509 including the Destination-Host AVP set to the value found in the 510 AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP if 511 the HA has been previously allocated and authorized by the AAAH. If 512 the HA has not been previously allocated by the foreign domain, the 513 HAR sent by the AAAH does not contain the MIP-Home-Agent-Address. 515 If the AAAH does not have the IP address of the HA and if there isn't 516 a security association, then a redirect server approach of Figure Y 517 should be utilized to communicate the HAR to the HA. This requires a 518 security association between the AAAH and HA be established. If the 519 redirect server cannot resolve the HA, or no security association can 520 be established, the AAAH MUST return an AMA with the Result-Code AVP 521 set to DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. 523 If Diameter agents are being used (i.e., there is no redirect server, 524 etc.) the AAAH sends the HAR to the originating AAAF. In this HAR the 525 Destination-Host AVP is set to the value found in the AMR's MIP- 526 Originating-Foreign-AAA AVP, and the MIP-Home-Agent-Host AVP or the 527 MIP-Candidate-Home-Agent-Host AVP found in the AMR are copied into 528 the HAR. 530 Therefore, the AAAH MUST always copy the MIP-Originating-Foreign-AAA 531 AVP from the AMR message to the HAR message. In cases when another 532 AAAF receives the HAR, this new AAAF will send the HAR to the HA. 534 Visited Home 535 Realm Realm 536 +--------+ ------- AMR -------> +--------+ 537 | AAAF | <------ HAR -------- | AAAH | 538 | | | | 539 +--->| server | ------- HAA -------> | server | 540 | +--------+ <------ AMA -------- +--------+ 541 | ^ | 542 | | | 543 HAR/HAA | AMR | | AMA 544 v | v 545 +---------+ +---------+ 546 | Home | | Foreign | 547 | Agent | | Agent | 548 +---------+ +---------+ 549 ^ 550 +--------+ | 551 | Mobile |<----------+ 552 | Node | Mobile IP 553 +--------+ 555 Figure 7: Home Agent allocated in Visited Realm 557 Calhoun Standards Track - March 2003 11 558 Upon receipt of a HAA from the Home Agent in the visited realm, the 559 AAAF forwards the HAA to the AAAH in the home realm. The AMA is then 560 constructed, and issued to the AAAF, and finally to the FA. If the 561 Result-Code indicates success, the HAA and AMA MUST include the MIP- 562 Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. 564 Mobile Node Foreign Agent Home Agent AAAF AAAH 565 ----------- ------------- ------------- ---------- ---------- 567 <----Challenge---- 568 Reg-Req (Response)-> 569 ------------AMR-------------> 570 -----AMR----> 571 <----HAR----- 572 <-----HAR------ 573 ------HAA------> 575 -----HAA----> 576 <----AMA----- 577 <-------------AMA------------ 578 <---Reg-Reply---- 580 Figure 8: Mobile IP/Diameter Message Exchange when HA is allocated in 581 Visited Realm 583 Figures 9 and 10 shows the secure approach involving redirect agents. 585 Local Redirect Home 586 FA FAAA Agent Server 588 AMR 589 ---------------> 590 AMR 591 (Redirect, f-HA) 592 --------------------> 593 AMA 594 (Redirect, f-HA)) 595 <-------------------- 596 AMA 597 (Redirect, f-HA) 598 <--------------- 599 AMR (f-HA) 600 ------------------------------------------------------> 601 AMA (MN-FA key) 602 <------------------------------------------------------ 604 Figure 9: Use of Redirect Server for AMR/AMA 606 Calhoun Standards Track - March 2003 12 607 Local Redirect Home 608 HA Agent Server 609 HAR 610 <---------------------- 611 HAA (Redirect) 612 ----------------------> 613 HAR (MN-HA key) 614 <------------------------------------------ 615 HAA 616 ------------------------------------------> 618 Figure 10: Use of Redirect Server for HAR/HAA 620 If the mobile node moves to another foreign Network, it MAY either 621 request to keep the same Home Agent within the old foreign network, 622 or request to get a new one in the new foreign network. If the AAAH 623 is willing to provide the requested service, the AAAH will have to 624 provide services for both visited networks, e.g., key refresh, per 625 Figures 9 and 10. 627 3.5 Co-located Mobile Node 629 In the event that a mobile node registers with the Home Agent as a 630 co-located mobile node, there is no foreign agent involved. 631 Therefore, when the Home Agent receives the Registration Request, an 632 AMR message is sent to the local AAAH server, with the Co-Located- 633 Mobile-Node bit set in the MIP-Feature-Vector AVP. The Home Agent 634 also includes the Acct-Multi-Session-Id AVP in the AMR sent to the 635 AAAH, as the AAAH may find this a useful piece of session-state or 636 log entry information. 638 Home 639 Realm 640 +--------+ 641 | AAAH | 642 | | 643 | server | 644 +--------+ 645 ^ | 646 | | 647 AMR | | AMA 648 | v 649 +--------+ +---------+ 650 | Mobile | Registration | Home | 651 | Node |-------------->| Agent | 652 +--------+ Request +---------+ 654 Calhoun Standards Track - March 2003 13 655 Figure 11: Co-located Mobile Node 657 If the MN-HA-Key-Requested bit was set in the AMR message from the 658 Home Agent, the home agent and mobile node's session keys would be 659 present in the AMA message. 661 Figure 12 shows the secure solution using redirect servers. In 662 Figure 12, the Proxy AAA represents any AAA server or servers that 663 the HA may use. This applies to the visited or home network. 665 Local redirect Home 666 HA Proxy AAA Agent Server 668 AMR 669 ---------------> 670 AMR (Redirect) 671 --------------------> 672 AMA (Redirect) 673 <--------------------- 674 AMA (Redirect) 675 <---------------- 676 Setup Security Association 677 <------------------------------------------------------> 678 AMR 679 -------------------------------------------------------> 680 AMA (MN-HA key) 681 <------------------------------------------------------- 683 Figure 12: Use of Redirect Server for Co-located CoA and AMR/AMA 685 3.6 Key Distribution Center (KDC) 687 In order to allow the scaling of wireless data access across 688 administrative domains, it is necessary to minimize the specific 689 security associations required. This means that each Foreign Agent 690 should not be required have a pre-configured shared security 691 association with each Home Agent on the Internet, nor should the 692 mobile node be required to have a pre-configured shared security 693 association with any specific home agent or any specific foreign 694 agent, as defined in [MOBILEIP]. 696 Diameter Mobile IP application solves this by including a key 697 distribution center (KDC), which means that after a Mobile Node is 698 authenticated, the authorization phase includes the generation of 699 sessions keys. Specifically, three keys are generated and are 700 required by [MOBILEIP]: 702 - K1 - the MN-HA Key, which will work as security association 703 between 704 the Mobile Node and the Home Agent. 705 - K2 - the MN-FA Key, which will work as the security association 707 Calhoun Standards Track - March 2003 14 708 between the Mobile Node and the Foreign Agent 709 - K3 - the FA-HA Key, which will work as the security association 710 between the Foreign Agent and the Home Agent 712 Figure 13 depicts the new security associations used for Mobile-IP 713 message integrity using the keys derived by the DIAMETER server. 715 +--------+ +--------+ 716 |Foreign | K3 | Home | 717 |Agent |<-------------------->| Agent | 718 | | | | 719 +--------+ +--------+ 720 ^ ^ 721 | K2 K1 | 722 | +--------+ | 723 | | Mobile | | 724 +------>| Node |<------+ 725 | | 726 +--------+ 727 Figure 13 - Security Association after Key Distribution 729 If the home agent is assigned in the home network, each key is 730 generated and encrypted by the home Diameter server. If instead the 731 home agent is assigned in the foreign network the K3 key is generated 732 and encrypted by the foreign network's local Diameter server, while 733 the K1 and K2 is still generated and encrypted by the home Diameter 734 server. 736 The keys destined for the foreign and home agent are propagated to 737 the mobility nodes via the Diameter protocol, and the keys must be 738 protected either by IPSec or TLS security associations that exist 739 directly between the HA and AAAH or the FA and AAAF, as explained 740 above. 742 The keys destined for the mobile node must also be propagated via the 743 Mobile IP protocol and must therefore instead follow the mechanisms 744 described in [aaa-keys]. In [MIPKEYS], the keys distributed to the 745 mobile node are instead sent as a nonce, and the mobile node and the 746 home Diameter will use the nonce and the long-term shared secret to 747 create the keys (see section 5.2). 749 Once the session keys have been established and propagated, the 750 mobility devices can exchange registration information directly as 751 defined in [MOBILEIP] without the need of the Diameter 752 infrastructure. However the session keys have a lifetime, after 753 which the Diameter infrastructure must be invoked again to acquire 754 new session keys. 756 3.7 Diameter Session Termination 758 A foreign and home agent following this specification MAY expect 759 their respective Diameter servers to maintain session state 760 information for each mobile node in their networks. In order for the 762 Calhoun Standards Track - March 2003 15 763 Diameter Server to release any resources allocated to a specific 764 mobile node, the mobility agents MUST send a Session-Termination- 765 Request (STR) to the Diameter server that authorized the service. The 766 Session-Termination-Request (STR) MUST be issued by the mobility 767 agents if the Authorization Lifetime has expired and no subsequent 768 MIP registration request have been received. 770 The home Diameter server SHOULD only deallocate all resources after 771 the STR is received from the home agent. This ensures that a mobile 772 node that moves from one foreign agent to another (hand-off) does not 773 cause the Home Diameter Server to free all resources for the mobile 774 node. 776 When deallocating all of the mobile node's resources the home 777 Diameter server (and the foreign Diameter server in case of HA 778 allocated in foreign network) MUST destroy all session keys that may 779 still be valid. 781 In the event that the AAAF wishes to terminate a session, its Abort- 782 Session-Request (ASR) [DIAMBASE] message SHOULD be sent to the FA. 783 Similarly, the AAAH SHOULD send its message to the Home Agent. 785 3.8 Advertising application support 787 Diameter nodes conforming to this specification MAY advertise support 788 by including the value of four (4) in the Auth-Application-Id or the 789 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 790 Capabilities-Exchange-Answer command [DIAMBASE]. 792 4.0 Command-Code Values 794 This section defines Command-Code [DIAMBASE] values that MUST be 795 supported by all Diameter implementations conforming to this 796 specification. The following Command Codes are defined in this 797 specification: 799 Command-Name Abbreviation Code Section 800 ----------------------------------------------------------- 801 AA-Mobile-Node-Answer AMA 260 2.2 802 AA-Mobile-Node-Request AMR 260 2.1 803 Home-Agent-MIP-Answer HAA 262 2.4 804 Home-Agent-MIP-Request HAR 262 2.3 806 4.1 AA-Mobile-Node-Request 808 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field 809 set to 260 and the 'R' bit set in the Command Flags field, is sent by 810 an attendant, acting as a Diameter client, to a server in order to 811 request the authentication and authorization of a mobile node. The 812 foreign agent (or home agent in the case of a co-located Mobile Node) 813 uses information found in the Registration Request to construct the 814 following AVPs that are to be included as part of the AMR: 816 Calhoun Standards Track - March 2003 16 817 Home Address (MIP-Mobile-Node-Address AVP) 818 Home Agent address (MIP-Home-Agent-Address AVP) 819 Mobile Node NAI (User-Name AVP [DIAMBASE]) 820 MN-HA Key Request (MIP-Feature-Vector AVP) 821 MN-FA Key Request (MIP-Feature-Vector AVP) 822 MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP) 823 Foreign Agent Challenge Extension (MIP-FA-Challenge AVP) 824 Home Agent NAI (MIP-Home-Agent-Host AVP) 825 Home AAA server NAI (Destination-Host AVP [DIAMBASE]) 827 If the mobile node's home address is zero, the foreign or home agent 828 MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. If the 829 home agent address is zero or all ones, the MIP-Home-Agent-Address 830 AVP MUST NOT be present in the AMR. 832 If a home agent is used in a visited network, the AAAF MAY set the 833 Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in 834 the AMR message to indicate that it is willing to assign a Home Agent 835 in the visited realm. 837 If the mobile node's home address is all ones, the foreign or home 838 agent MUST include a MIP-Mobile-Node-Address AVP, set to all ones. 840 If the mobile node includes the home agent NAI and the home AAA 841 server NAI [AAANAI], the foreign agent MUST include the MIP-Home- 842 Agent-Host AVP and the Destination-Host AVP in the AMR. 844 Message Format 846 ::= < Diameter Header: 260, REQ, PXY > 847 < Session-ID > 848 { Auth-Application-Id } 849 { User-Name } 850 { Destination-Realm } 851 { Origin-Host } 852 { Origin-Realm } 853 { MIP-Reg-Request } 854 { MIP-MN-AAA-Auth } 855 [ Acct-Multi-Session-Id ] 856 [ Destination-Host ] 857 [ Origin-State-Id ] 858 [ MIP-Mobile-Node-Address ] 859 [ MIP-Home-Agent-Address ] 860 [ MIP-Feature-Vector ] 861 [ MIP-Originating-Foreign-AAA ] 862 [ Authorization-Lifetime ] 863 [ Auth-Session-State ] 864 [ MIP-FA-Challenge ] 865 [ MIP-Candidate-Home-Agent-Host ] 866 [ MIP-Home-Agent-Host ] 867 [ MIP-HA-to-FA-SPI ] 868 * [ Proxy-Info ] 870 Calhoun Standards Track - March 2003 17 871 * [ Route-Record ] 872 * [ AVP ] 874 4.2 AA-Mobile-Node-Answer 876 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field 877 set to 260 and the 'R' bit cleared in the Command Flags field, is 878 sent by the AAAH in response to the AA-Mobile-Node-Request message. 879 The User-Name MAY be included in the AMA if present in the AMR. The 880 Result-Code AVP MAY contain one of the values defined in section 3.0, 881 in addition to the values defined in [DIAMBASE]. 883 An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST 884 include the MIP-Home-Agent-Address AVP, MUST include the MIP-Mobile- 885 Node-Address AVP, and includes the MIP-Reg-Reply AVP if and only if 886 the Co-Located-Mobile-Node bit was not set in the MIP-Feature-Vector 887 AVP. The MIP-Home-Agent-Address AVP contains the Home Agent assigned 888 to the mobile node, while the MIP-Mobile-Node-Address AVP contains 889 the home address that was assigned. The AMA message MUST contain the 890 MIP-FA-to-HA-Key, MIP-FA-to-MN-Key if they were requested in the AMR, 891 and they were present in the HAR. The MIP-MN-to-HA-Key and MIP-HA-to- 892 MN-Key AVPs MUST be present if the session keys were requested in the 893 AMR, and the Co-Located-Mobile-Node bit was set in the MIP-Feature- 894 Vector AVP. 896 An AMA message with the Result-Code AVP set to 897 DIAMETER_LIMITED_SUCCESS MAY include the MIP-Home-Agent-Address AVP 898 if a dynamically assigned home agent was requested by the mobile 899 node. Upon receipt of this result code, the foreign agent MUST issue 900 the Registration Request to the Home Agent in the manner described in 901 [MOBILEIP]. 903 An AMA message with the Result-Code set to DIAMETER_MULTI_ROUND_AUTH 904 MAY include mobile node session key AVPs (see Section 6.1) such as 905 the MIP-MN-to-FA-Key AVP and the MIP-MN-to-HA-Key AVP. If such an AVP 906 is present in the AMA message, the foreign agent MUST include the 907 corresponding Mobile IP key distribution extension in the 908 Registration Reply it sends to the mobile node. This is to support 909 multi-roundtrip authentication mechanisms. 911 Message Format 913 ::= < Diameter Header: 260, PXY > 914 < Session-Id > 915 { Auth-Application-Id } 916 { Result-Code } 917 { Origin-Host } 918 { Origin-Realm } 919 [ Acct-Multi-Session-Id ] 920 [ User-Name ] 921 [ Authorization-Lifetime ] 923 Calhoun Standards Track - March 2003 18 925 [ Auth-Session-State ] 926 [ Error-Message ] 927 [ Error-Reporting-Host ] 928 [ Re-Auth-Request-Type ] 929 [ MIP-Feature-Vector ] 930 [ MIP-Reg-Reply ] 931 [ MIP-MN-to-FA-Key ] 932 [ MIP-MN-to-HA-Key ] 933 [ MIP-FA-to-MN-Key ] 934 [ MIP-FA-to-HA-Key ] 935 [ MIP-HA-to-MN-Key ] 936 [ MIP-Key-Lifetime ] 937 [ MIP-Type-Algorithm ] 938 [ MIP-Home-Agent-Address ] 939 [ MIP-Mobile-Node-Address ] 940 * [ MIP-Filter-Rule ] 941 [ Origin-State-Id ] 942 * [ Proxy-Info ] 943 * [ AVP ] 945 4.3 Home-Agent-MIP-Request 947 The Home-Agent-MIP-Request (HAR), indicated by the Command-Code field 948 set to 262 and the 'R' bit set in the Command Flags field, is sent by 949 the AAA to the Home Agent. If the Home Agent is to be assigned in a 950 foreign network, the HAR is issued by the AAAH and forwarded by the 951 AAAF. If the HAR message does not include a MIP-Mobile-Node-Address 952 AVP, and the Registration Request has 0.0.0.0 for the home address, 953 and the HAR is successfully processed, the Home Agent MUST allocate 954 the mobile nodes address. If on the other hand the home agent's local 955 AAA server allocates the mobile node's home address, the local AAA 956 server MUST include the assigned address in an MIP-Mobile-Node- 957 Address AVP. 959 When session keys are requested for use by the mobile node (see 960 section 5.0), the AAAH MUST create them and include them in the HAR 961 message. When a Foreign-Home session key is requested, it will be 962 created and distributed by the AAA server in the same realm as the 963 home agent. 965 Message Format 967 ::= < Diameter Header: 262, REQ, PXY > 968 < Session-Id > 969 { Auth-Application-Id } 970 { Authorization-Lifetime } 971 { Auth-Session-State } 972 { MIP-Reg-Request } 973 { Origin-Host } 974 { Origin-Realm } 975 { User-Name } 976 { Destination-Realm } 978 Calhoun Standards Track - March 2003 19 979 { MIP-Feature-Vector } 980 [ Destination-Host ] 981 [ MIP-MN-to-HA-Key ] 982 [ MIP-MN-to-FA-Key ] 983 [ MIP-HA-to-MN-Key ] 984 [ MIP-HA-to-FA-Key ] 985 [ MIP-HA-to-FA-SPI ] 986 [ MIP-Key-Lifetime ] 987 [ MIP-Originating-Foreign-AAA ] 988 [ MIP-Mobile-Node-Address ] 989 [ MIP-Home-Agent-Address ] 990 [ MIP-Type-Algorithm ] 991 * [ MIP-Filter-Rule ] 992 [ Origin-State-Id ] 993 * [ Proxy-Info ] 994 * [ Route-Record ] 995 * [ AVP ] 997 4.4 Home-Agent-MIP-Answer 999 The Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field 1000 set to 262 and the 'R' bit cleared in the Command Flags field, is 1001 sent by the Home Agent to its local AAA server in response to a Home- 1002 Agent-MIP-Request. The User-Name MAY be included in the HAA if 1003 present in the HAR. If the home agent allocated a home address for 1004 the mobile node, the address MUST be included in the MIP-Mobile-Node- 1005 Address AVP. The Result-Code AVP MAY contain one of the values 1006 defined in section 3.0 instead of the values defined in [DIAMBASE]. 1008 Message Format 1010 ::= < Diameter Header: 262, PXY > 1011 < Session-Id > 1012 { Auth-Application-Id } 1013 { Result-Code } 1014 { Origin-Host } 1015 { Origin-Realm } 1016 [ Acct-Multi-Session-Id ] 1017 [ User-Name ] 1018 [ Error-Reporting-Host ] 1019 [ Error-Message ] 1020 [ MIP-Reg-Reply ] 1021 [ MIP-Home-Agent-Address ] 1022 [ MIP-Mobile-Node-Address ] 1023 [ MIP-FA-to-HA-SPI ] 1024 [ MIP-FA-to-MN-SPI ] 1025 [ Origin-State-Id ] 1026 * [ Proxy-Info ] 1027 * [ AVP ] 1029 5.0 Result-Code AVP Values 1031 Calhoun Standards Track - March 2003 20 1032 This section defines new Result-Code [DIAMBASE] values that MUST be 1033 supported by all Diameter implementations that conform to this 1034 specification. 1036 5.1 Transient Failures 1038 Errors that fall within the transient failures category are used to 1039 inform a peer that the request could not be satisfied at the time it 1040 was received, but MAY be able to satisfy the request in the future. 1042 DIAMETER_ERROR_MIP_REPLY_FAILURE 4005 1043 This error code is used by the home agent when processing of 1044 the Registration Request has failed. 1046 DIAMETER_ERROR_HA_NOT_AVAILABLE 4006 1047 This error code is used to inform the foreign agent that the 1048 requested Home Agent cannot be assigned to the mobile node 1049 at this time. The foreign agent MUST return a Mobile IP 1050 Registration Reply to the mobile node with an appropriate 1051 Error code. 1053 DIAMETER_ERROR_BAD_KEY 4007 1054 This error code is used by the home agent to indicate to the 1055 local Diameter server that the key generated is invalid. 1057 DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED 4008 1058 This error code is used by a mobility agent to indicate to 1059 The home Diameter server that the requested packet filter 1060 Rules cannot be supported. 1062 5.2 Permanent Failures 1064 Errors that fall within the permanent failures category are used to 1065 inform the peer that the request failed, and should not be attempted 1066 again. 1068 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5024 1069 This error is used by the AAAF to inform the AAAH that 1070 allocation of a home agent in the foreign domain is not 1071 permitted at this time. 1073 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025 1075 This error is used by the AAAF / AAAH to inform that the 1076 requested Mobile IP session keys could not be encrypted with 1077 the CMS strong security application and therefore failed. 1079 5.0 Mandatory AVPs 1081 The following table describes the Diameter AVPs defined in the Mobile 1082 IP application, their AVP Code values, types, possible flag values 1083 and whether the AVP MAY be encrypted. 1085 Calhoun Standards Track - March 2003 21 1086 Due to space constraints, the short form IPFiltrRule is used to 1087 represent IPFilterRule and DiamIdent is used to represent 1088 DiameterIdentity. 1090 +--------------------------+ 1091 | AVP Flag rules | 1092 |----+-----+----+-----|----+ 1093 AVP Section | | |SHLD| MUST|MAY | 1094 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1095 -----------------------------------------|----+-----+----+-----|----| 1096 MIP-Filter-Rule 342 5.8 IPFiltrRule| M | P | | V | Y | 1097 MIP-Auth-Input- 338 5.6.2 Unsigned32 | M | P | | V | Y | 1098 Data-Length | | | | | | 1099 MIP- 339 5.6.3 Unsigned32 | M | P | | V | Y | 1100 Authenticator-Length | | | | | | 1101 MIP- 340 5.6.4 Unsigned32 | M | P | | V | Y | 1102 Authenticator-Offset | | | | | | 1103 MIP-Candidate- 336 5.9 DiamIdent | M | P | | V | N | 1104 Home-Agent-Host | | | | | | 1105 MIP-Home-Agent- 348 5.11 DiamIdent | M | P | | V | N | 1106 Host | | | | | | 1107 MIP-FA-Challenge 344 5.7 OctetString| M | P | | V | Y | 1108 MIP-Feature- 337 5.5 Unsigned32 | M | P | | V | Y | 1109 Vector | | | | | | 1110 MIP-Home-Agent- 334 5.4 Address | M | P | | V | Y | 1111 Address | | | | | | 1112 MIP-MN-AAA-Auth 322 5.6 Grouped | M | P | | V | Y | 1113 MIP-MN-AAA-SPI 341 5.6.1 Unsigned32 | M | P | | V | Y | 1114 MIP-Mobile-Node- 333 5.3 Address | M | P | | V | Y | 1115 Address | | | | | | 1116 MIP-Reg-Request 320 5.1 OctetString| M | P | | V | Y | 1117 MIP-Reg-Reply 321 5.2 OctetString| M | P | | V | Y | 1118 MIP-Originating- 347 5.10 Grouped | M | P | | V | Y | 1119 Foreign-AAA | | | | | | 1121 5.1 MIP-Reg-Request AVP 1123 The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and 1124 contains the Mobile IP Registration Request [MOBILEIP] sent by the 1125 mobile node to the foreign agent. 1127 5.2 MIP-Reg-Reply AVP 1129 The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and 1130 contains the Mobile IP Registration Reply [MOBILEIP] sent by the home 1131 agent to the foreign agent. 1133 5.3 MIP-Mobile-Node-Address AVP 1135 Calhoun Standards Track - March 2003 22 1136 The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and 1137 contains the mobile node's home IP address. 1139 5.4 MIP-Home-Agent-Address AVP 1141 The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and 1142 contains the mobile node's home agent IP address. 1144 5.5 MIP-Feature-Vector AVP 1146 The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and 1147 is added with flag values set by the foreign agent or by the AAAF 1148 owned by the same administrative domain as the foreign agent. The 1149 foreign agent SHOULD include MIP-Feature-Vector AVP within the AMR 1150 message it sends to the AAAF. 1152 Flag values currently defined include: 1153 1 Mobile-Node-Home-Address-Requested 1154 2 Home-Address-Allocatable-Only-in-Home-Realm 1155 4 Home-Agent-Requested 1156 8 Foreign-Home-Agent-Available 1157 16 MN-HA-Key-Request 1158 32 MN-FA-Key-Request 1159 64 FA-HA-Key-Request 1160 128 Home-Agent-In-Foreign-Network 1161 256 Co-Located-Mobile-Node 1163 The flags are set according to the following rules. 1165 If the mobile node includes a valid home address (i.e., not equal to 1166 0.0.0.0 or 255.255.255.255) in its Registration Request, the foreign 1167 agent zeroes the Mobile-Node-Home-Address-Requested flag in the MIP- 1168 Feature-Vector AVP. 1170 If the mobile node sets the home address field equal to 0.0.0.0 in 1171 its Registration Request, the foreign agent sets the Mobile-Node- 1172 Home-Address-Requested flag to one. 1174 If the mobile node sets the home agent field equal to 255.255.255.255 1175 in its Registration Request, the foreign agent sets both the Home- 1176 Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home- 1177 Realm flag to one in the MIP-Feature-Vector AVP. 1179 If the mobile node sets the home agent field equal to 0.0.0.0 in its 1180 Registration Request, the foreign agent sets the Home-Agent-Requested 1181 flag to one, and zeroes the Home-Address-Allocatable-Only-in-Home- 1182 Realm flag in the MIP-Feature-Vector AVP. 1184 Whenever the foreign agent sets either the Mobile-Node-Home-Address- 1185 Requested flag or the Home-Agent-Requested flag to one, it MUST set 1186 the MN-HA-Key-Request flag to one. The MN-HA-Key-Request flag is also 1188 Calhoun Standards Track - March 2003 23 1189 set to one if the mobile node includes a Generalized MN-HA Key 1190 Request [MIPKEYS] extension, with the subtype set to AAA. 1192 If the mobile node includes a Generalized MN-FA Key Request [MIPKEYS] 1193 extension with the AAA subtype in its Registration Request, the 1194 foreign agent sets the MN-FA-Key-Request flag to one in the MIP- 1195 Feature-Vector AVP. 1197 If the mobile node requests a home agent in the foreign network 1198 either by setting the home address field to all ones, or by 1199 specifying a home agent in the foreign network, and the AAAF 1200 authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign- 1201 Network bit to one. 1203 If the Home Agent receives a Registration Request from the mobile 1204 node indicating that the MN is acting as a co-located mobile node, 1205 the home agent sets the Co-Located-Mobile-Node bit to one. 1207 If the foreign agent's local policy allows it to receive AAA session 1208 keys, and it does not have any existing FA-HA key with the home 1209 agent, the foreign agent MAY set the FA-HA-Key-Request flag 1211 The foreign agent MUST NOT set the Foreign-Home-Agent-Available, and 1212 Home-Agent-In-Foreign-Network flag to one. 1214 When the AAAF receives the AMR message, it MUST first verify that the 1215 sender was an authorized foreign agent. The AAAF then takes any 1216 actions indicated by the settings of the MIP-Feature-Vector AVP 1217 flags. The AAAF then MAY set additional flags. Only the AAAF may set 1218 the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network 1219 flags to one. This is done according to local administrative policy. 1220 When the AAAF has finished setting additional flags according to its 1221 local policy, then the AAAF transmits the AMR with the possibly 1222 modified MIP-Feature-Vector AVP to the AAAH. 1224 5.6 MIP-MN-AAA-Auth AVP 1226 The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains 1227 some ancillary data to simplify processing of the authentication data 1228 in the Mobile IP Registration Request [MOBILEIP, MIPCHAL] by the 1229 target AAA server. Its value has the following ABNF grammar: 1231 MIP-MN-AAA-Auth ::= < AVP Header: 322 > 1232 { MIP-MN-AAA-SPI } 1233 { MIP-Auth-Input-Data-Length } 1234 { MIP-Authenticator-Length } 1235 { MIP-Authenticator-Offset } 1236 * [ AVP ] 1238 5.6.1 MIP-MN-AAA-SPI AVP 1240 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 1241 indicates the algorithm by which the targeted AAA server (AAAH) 1243 Calhoun Standards Track - March 2003 24 1244 should attempt to validate the Authenticator computed by the mobile 1245 node over the Registration Request data. 1247 5.6.2 MIP-Auth-Input-Data-Length AVP 1249 The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type 1250 Unsigned32 and contains the length, in bytes, of the Registration 1251 Request data (data portion of MIP-Reg-Request AVP) that should be 1252 used as input to the algorithm (indicated by the MN-AAA-SPI AVP) used 1253 to determine whether the Authenticator Data supplied by the mobile 1254 node is valid. 1256 5.6.3 MIP-Authenticator-Length AVP 1258 The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32 1259 and contains the length of the authenticator to be validated by the 1260 targeted AAA server (i.e., AAAH). 1262 5.6.4 MIP-Authenticator-Offset AVP 1264 The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32 1265 and contains the offset into the Registration Request Data, of the 1266 authenticator to be validated by the targeted AAA server (i.e., 1267 AAAH). 1269 5.7 MIP-FA-Challenge AVP 1271 The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and 1272 contains the challenge advertised by the foreign agent to the mobile 1273 node. This AVP MUST be present in the AMR if the mobile node used the 1274 RADIUS-style MN-AAA computation algorithm. 1276 5.8 MIP-Filter-Rule AVP 1278 The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule, and 1279 provides filter rules that need to be configured on the foreign or 1280 home agent for the user. The packet filtering rules are set by the 1281 AAAH by adding one or more MIP-Filter-Rule AVPs in the HAR if 1282 destined for the home agent and/or in the AMA if destined for the 1283 foreign agent. 1285 5.9 MIP-Candidate-Home-Agent-Host 1287 The MIP-Candidate-Home-Agent-Host AVP (AVP Code 336) is of type 1288 DiameterIdentity and contains the identity of a home agent in the 1289 foreign network that the AAAF proposes be dynamically assigned to the 1290 mobile node. 1292 5.10 MIP-Originating-Foreign-AAA AVP 1294 The MIP-Originating-Foreign-AAA AVP (AVP Code 347) if of type 1295 Grouped, and contains the identity of the AAAF, which issues the AMR 1296 to the AAAH. The MIP- Originating-Foreign-AAA AVP MUST only be used 1298 Calhoun Standards Track - March 2003 25 1299 in cases when the home agent is or may be allocated in a foreign 1300 domain. If present in the AMR, the AAAH MUST copy the MIP- 1301 Originating-Foreign-AAA AVP into the HAR. 1303 MIP-Originating-Foreign-AAA ::= < AVP Header: 347 > 1304 { Origin-Realm } 1305 { Origin-Host } 1306 * [ AVP ] 1308 5.11 MIP-Home-Agent-Host AVP 1310 The MIP-Home-Agent-Host AVP (AVP Code 348) if of type Grouped, and 1311 contains the identity of the assigned Home Agent. If present in 1312 the 1313 AMR, the AAAH MUST copy the MIP-Home-Agent-Host AVP into the HAR. 1315 MIP-Home-Agent-Host ::= < AVP Header: 348 > 1316 { Destination-Realm } 1317 { Destination-Host } 1318 * [ AVP ] 1320 6.0 Key Distribution Center 1322 The mobile node and mobility agents use session keys to compute 1323 authentication extensions applied to registration messages, as 1324 defined in [MOBILEIP]: Mobile-Foreign, Foreign-Home and Mobile-Home. 1325 If session keys are requested the AAA server(s) MUST return the key 1326 material after the mobile node is successfully authenticated and 1327 authorized. 1329 The SPI values are used as key identifiers, meaning that each session 1330 key has its own SPI value; nodes that share a key also share an SPI. 1331 The mobile node proposes SPIs for use in computing the Mobile-Foreign 1332 and Mobile-Home authentication extensions, via the Mobile IP AAA Key 1333 Request extensions [MIPKEYS], while the home agent allocates the 1334 Mobile-Foreign, Mobile-Home and Foreign-Home SPIs. 1336 Once the session keys have been distributed, subsequent Mobile IP 1337 registrations need not invoke the AAA infrastructure until the keys 1338 expire. These registrations MUST include the Mobile-Home 1339 authentication extension. In addition, subsequent registrations MUST 1340 also include Mobile-Foreign authentication extension if the Mobile- 1341 Foreign key was generated and distributed by AAA; similarly for 1342 subsequent use of the Foreign-Home authentication extensions. 1344 6.1 Authorization Lifetime vs. MIP Key Lifetime 1346 The Diameter Mobile IP application makes use of two timers - the 1347 Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. 1349 The Authorization-Lifetime contains the number of seconds before the 1350 mobile node must issue a subsequent MIP registration request. The 1352 Calhoun Standards Track - March 2003 26 1353 content of the Authorization-Lifetime AVP corresponds to the Lifetime 1354 field in the MIP header [MOBILEIP]. 1356 The MIP-Key-Lifetime AVP contains the number of seconds before 1357 session keys destined for the mobility agents and the mobile node 1358 expire. A value of zero indicates infinity (no timeout). If not zero, 1359 the value of the MIP-Key-Lifetime AVP MUST be at least equal to the 1360 value in the Authorization Lifetime AVP. 1362 6.2 Key Material vs. Session Key 1364 As described in section 1.6, session keys and nonces are generated by 1365 the AAAH and are transmitted to the home agent, foreign agent and 1366 mobile node. Security associations destined for the home and foreign 1367 agents are established via transmission of session keys and SPIs, 1368 protected by transmission-level security as defined in [DIAMBASE]. 1369 Where it is necessary to protect the nonces, session keys, and SPIs 1370 from untrusted Diameter agents, end-to-end security mechanisms are 1371 required to eliminate the all Diameter Agents between the FA or HA 1372 and the AAAH, as outlined above. 1374 In [MIPKEYS] the mobile node security associations are established 1375 via nonces transmitted to the mobile node via Mobile IP. To provide 1376 the nonces, the AAAH must generate a random [RANDOM] value of at 1377 least 128 bits [MIPKEYS]. The mobile node then uses the nonce to 1378 derive the MN-HA and MN-FA session keys. 1380 More details of the MN-HA and the MN-FA session key creation 1381 procedure are found in [MIPKEYS]. 1383 It is important that the hashing algorithm used by the mobile node to 1384 construct the session key is the same as the one used by the AAAH in 1385 the session key generation procedure. The AAAH therefore indicates 1386 the algorithm used along with the key material. 1388 The Foreign-Home session key is shared between two mobility agents: 1389 the FA and HA. Since this key is not destined for the mobile node, 1390 there is no need to follow the session key generation procedures 1391 detailed above. Instead, the AAAH generates a random [RANDOM] value 1392 of at least 128 bits for use as the Foreign-Home session key. 1394 See sections 7.0 for details about the format of the AVPs used to 1395 transport the session keys. 1397 6.3 Distributing the Mobile-Home Session Key 1399 If the mobile node does not have a Mobile-Home session key, then the 1400 AAAH is likely to be the only entity trusted that is available to the 1401 mobile node. Thus, the AAAH has to generate the Mobile-Home session 1402 key, and encode it for eventual consumption by the mobile node and 1403 home agent. 1405 Calhoun Standards Track - March 2003 27 1406 The distribution of the MN-HA key to the HA has been specified above. 1407 The HA and AAAH establish a security association (IPSec or TLS) and 1408 transport the key over that security association. 1410 If no security association exists between the AAAH and the home 1411 agent, and a security association cannot be established the AAAH MUST 1412 return a Result-Code AVP with 1413 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. 1415 The AAAH also has to arrange for the key to be delivered to the 1416 mobile node. Unfortunately, the AAA server only knows about Diameter 1417 messages and AVPs, and the mobile node only knows about Mobile IP 1418 messages and extensions [MOBILEIP]. For this purpose, AAAH includes 1419 the Mobile-Home session Key Material AVP into a MIP-MN-to-HA-Key AVP, 1420 which is added to the HAR message, and delivered either to a local 1421 home agent or a home agent in the visited network. The AAAH has to 1422 rely on the home agent (that also understands Diameter) to transfer 1423 the keying material (nonce) into a Mobile IP Generalized MN-HA Key 1424 Reply extension [MIPKEYS] in the Registration Reply message, using 1425 the SPI proposed by the Mobile Node in the MN-HA Key Request From AAA 1426 Subtype extension. The home agent can format the Reply message and 1427 extensions correctly for eventual delivery to the mobile node. The 1428 resulting Registration Reply is added to the HAA's MIP-Reg-Reply AVP. 1430 The AAAH parses the HAA message, transforms it into an AMA containing 1431 an MIP-Reg-Reply AVP, and sends the AMA message to the foreign agent. 1432 The foreign agent then uses that AVP to recreate a Registration Reply 1433 message containing the Generalized MN-HA Key Reply extension for 1434 delivery to the mobile node. 1436 In summary, the AAAH generates the Mobile-Home key material, which is 1437 added to the MIP-MN-to-HA-Key AVP, and a session key, which is added 1438 to the MIP-HA-to-MN-Key AVP. These AVPs are delivered to the home 1439 agent in an HAR message. The home agent retains the session key for 1440 its own use, and copies the key material (nonce) from the MIP-MN-to- 1441 HA-Key AVP into a Generalized MN-HA Key Reply extension, which is 1442 appended to the Mobile IP Registration Reply message. This 1443 Registration Reply message MUST also include the Mobile-Home 1444 authentication extension, created using the newly allocated Mobile- 1445 Home session key. The home agent then includes the Registration Reply 1446 message and extensions into a MIP-Reg-Reply AVP as part of the HAA 1447 message to be sent back to the AAA server. 1449 6.4 Distributing the Mobile-Foreign Session Key 1451 The Mobile-Foreign session key material (nonce) is also generated by 1452 AAAH (upon request) and is added to the MIP-MN-to-FA-Key Material 1453 AVP, which is added to the HAR, and copied by the home agent into a 1454 Generalized MN-FA Key Reply Extension [MIPKEYS] to the Mobile IP 1455 Registration Reply message, using the SPI proposed by the mobile node 1456 in the MN-FA Key Material From AAA Request Subtype extension. The 1457 AAAH includes the session key in the MIP-FA-to-MN-Key AVP in the AMA, 1459 Calhoun Standards Track - March 2003 28 1460 to be used by the foreign agent in the computation of the Mobile- 1461 Foreign authentication extension. 1463 6.5 Distributing the Foreign-Home Session Key 1465 If the foreign agent requests a foreign home key, it also includes a 1466 MIP-HA-to-FA-SPI AVP in the AMR to convey the SPI to be used by the 1467 home agent for this purpose. The AAAH generates the Foreign-Home 1468 session key and distributes it to both the HA and the FA over 1469 respective security associations to each using the MIP-HA-to-FA and 1470 MIP-FA-to-HA-Key AVPs. The HA conveys the SPI the FA should use in 1471 the HAA; the AAAH later includes that in the MIP-FA-HA-Key AVP, along 1472 with the session key. 1474 Refer to Figures 3, 4, 9, and 10 for the messages involved. 1476 7.0 Key Distribution Center (KDC) AVPs 1478 The Mobile-IP protocol defines a set of security associations shared 1479 between the mobile node, foreign agent and home agent. These three 1480 security associations (Mobile-Home, Mobile-Foreign, and Foreign-Home) 1481 can be dynamically created by the AAAH, and has previously been 1482 described in section 1.6 and 5.2. AAA servers supporting the Diameter 1483 Mobile IP Application MUST implement the KDC AVPs defined in this 1484 document. 1486 The names of the KDC AVPs indicate the two entities sharing the 1487 security association defined by the key or the key material; the 1488 intended receiver of the AVP is the first named entity. So, for 1489 instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key 1490 material (nonce), which the mobile node will use to derive the 1491 Mobile-Home Key, and the MIP-HA-to-MN-Key AVP contains the Mobile- 1492 Home key for the home agent. 1494 The following table describes the Diameter AVPs defined in the Mobile 1495 IP application, their AVP Code values, types, possible flag values 1496 and whether the AVP MAY be encrypted. 1498 [Editor note: The following table has errors.] 1500 +--------------------------+ 1501 | AVP Flag Rules | 1502 |----+-----+----+-----|----+ 1503 AVP Section | | |SHLD| MUST|MAY | 1504 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1505 -----------------------------------------|----+-----+----+-----|----| 1506 MIP-Algorithm- 345 7.8 Enumerated | M | P | | V | Y | 1507 Type | | | | | | 1508 MIP-FA-to-HA-Key 328 7.2 Grouped | M | P | | V | Y | 1509 MIP-FA-to-HA-SPI 318 7.11 Unsigned32 | M | P | | V | Y | 1510 MIP-HA-to-FA-SPI 3** 7.14 Unsigned32 | M | P | | V | Y | 1511 MIP-FA-to-MN-Key 326 7.1 Grouped | M | P | | V | Y | 1513 Calhoun Standards Track - March 2003 29 1514 MIP-FA-to-MN-SPI 319 7.10 Unsigned32 | M | P | | V | Y | 1515 MIP-HA-to-FA-Key 329 7.3 Grouped | M | P | | V | Y | 1516 MIP-HA-to-MN-Key 332 7.4 Grouped | M | P | | V | Y | 1517 MIP-Key-Lifetime 367 7.13 Unsigned32 | M | P | | V | Y | 1518 MIP-Key-Material 335 7.12 OctetString| M | P | | V | Y | 1519 MIP-MN-to-FA-Key 325 7.5 Grouped | M | P | | V | Y | 1520 MIP-MN-to-HA-Key 331 7.6 Grouped | M | P | | V | Y | 1521 MIP-Replay-Mode 346 7.9 Enumerated | M | P | | V | Y | 1522 MIP-Session-Key 343 7.7 OctetString| M | P | | V | Y | 1524 7.1 MIP-FA-to-MN-Key AVP 1526 The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and 1527 contains the foreign agent's session key, which it shares with the 1528 mobile node. Its Data field has the following ABNF grammar: 1530 MIP-FA-to-MN-Key ::= < AVP Header: 326 > 1531 { MIP-FA-to-MN-SPI } 1532 { MIP-Algorithm-Type } 1533 { MIP-Session-Key } 1534 * [ AVP ] 1536 7.2 MIP-FA-to-HA-Key AVP 1538 The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and 1539 contains the foreign agent's session key, which it shares with the 1540 home agent. Its Data field has the following ABNF grammar: 1542 MIP-FA-to-HA-Key ::= < AVP Header: 328 > 1543 { MIP-FA-to-HA-SPI } 1544 { MIP-Algorithm-Type } 1545 { MIP-Session-Key } 1546 * [ AVP ] 1548 7.3 MIP-HA-to-FA-Key AVP 1550 The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and 1551 contains the Home Agent's session key, which it shares with the 1552 foreign agent. Its Data field has the following ABNF grammar: 1554 MIP-HA-to-FA-Key ::= < AVP Header: 329 > 1555 { MIP-Algorithm-Type } 1556 { MIP-Session-Key } 1557 * [ AVP ] 1559 7.4 MIP-HA-to-MN-Key AVP 1561 The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and 1562 contains the Home Agent's session key, which it shares with the 1563 mobile node. Its Data field has the following ABNF grammar: 1565 Calhoun Standards Track - March 2003 30 1566 MIP-HA-to-MN-Key ::= < AVP Header: 332 > 1567 { MIP-Algorithm-Type } 1568 { MIP-Replay-Mode } 1569 { MIP-Session-Key } 1570 * [ AVP ] 1572 7.5 MIP-MN-to-FA-Key AVP 1574 The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type Grouped, and 1575 contains the mobile node's key material (a nonce), which it uses to 1576 derive the session key it shares with the foreign agent. The home 1577 agent uses this AVP in the construction of the Mobile IP "Unsolicted 1578 MN-FA Key from AAA Subtype" extension [MIPKEYS]. The SPI in the 1579 extension's FA SPI field is allocated by the home agent, but it 1580 SHOULD take into consideration the SPI requested by the mobile node 1581 in the "MN-FA Key Request From AAA Subtype" extension. 1583 MIP-MN-to-FA-Key ::= < AVP Header: 325 > 1584 { MIP-Algorithm-Type } 1585 { MIP-Key-Material } 1586 { MIP-MN-AAA-SPI } 1587 * [ AVP ] 1589 7.6 MIP-MN-to-HA-Key AVP 1591 The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type Grouped, and 1592 contains the mobile node's key material, which it uses to derive the 1593 session key it shares with the Home Agent. The Home Agent uses this 1594 AVP in the construction of the Mobile IP "Unsolicted MN-HA Key from 1595 AAA Subtype" extension [MIPKEYS]. The SPI in the extension's HA SPI 1596 field is allocated by the Home Agent, but it SHOULD take into 1597 consideration the SPI requested by the mobile node in the "MN-HA Key 1598 Request From AAA Subtype" extension. 1600 MIP-MN-to-HA-Key ::= < AVP Header: 331 > 1601 { MIP-Algorithm-Type } 1602 { MIP-Replay-Mode } 1603 { MIP-Key-Material } 1604 { MIP-MN-AAA-SPI } 1605 * [ AVP ] 1607 7.7 MIP-Session-Key AVP 1609 The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 1610 contains the Session Key to be used between two Mobile IP entities. 1612 7.8 MIP-Algorithm-Type AVP 1614 The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, 1615 and 1616 contains the Algorithm identifier used to generate the associated 1617 Mobile IP authentication extension. The following values are 1618 currently defined: 1620 Calhoun Standards Track - March 2003 31 1621 1 HMAC-MD5 [HMAC] 1622 2 HMAC-SHA-1 [HMAC] 1624 7.9 MIP-Replay-Mode AVP 1626 The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and 1627 contains the replay mode the Home Agent should use when 1628 authenticating the mobile node. 1630 The following values are supported (see [MOBILEIP] for more 1631 information): 1633 1 None 1634 2 Timestamps 1635 3 Nonces 1637 7.10 MIP-FA-to-MN-SPI AVP 1639 The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and 1640 contains the Security Parameter Index the foreign agent is to use to 1641 refer to the session key it shares with the mobile node. The SPI 1642 created MUST NOT be a value between zero (0) and 255, which is the 1643 reserved namespace defined in [MOBILEIP]. This AVP MAY be added in 1644 the HAA message by the home agent for the AAAH's use in MIP-FA-to-MN- 1645 SPI AVP of the MIP-FA-to-MN-Key AVP. 1647 7.11 MIP-FA-to-HA-SPI AVP 1649 The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32, and 1650 contains the Security Parameter Index the foreign agent is to use to 1651 refer to the session key it shares with the home agent. The SPI 1652 created MUST NOT be a value between zero (0) and 255, which is the 1653 reserved namespace defined in [MOBILEIP]. If FA-HA keys are being 1654 generated, this AVP MUST be added in the HAA message by the Home 1655 Agent for the AAAH's (or AAAF's) use in providing the value of the 1656 MIP-FA-to-HA-SPI member of the grouped MIP-FA-to-HA-Key AVP. 1658 7.12 MIP-Key-Material AVP 1660 The MIP-Key-Material AVP (AVP Code 335) is of type OctetString and 1661 contains the key material sent to the mobile node. The mobile node 1662 follows the procedures in [MIPKEYS] to generate the session key used 1663 to authenticate Mobile IP registration messages. 1665 7.13 MIP-Key-Lifetime AVP 1667 The MIP-Key-Lifetime AVP (AVP Code 367) is of type Unsigned32 and 1668 represents the period of time (in seconds) for which the session key 1669 is valid. The session key MUST NOT be used if the lifetime has 1670 expired; if the key lifetime expires while the session to which it 1672 Calhoun Standards Track - March 2003 32 1673 applies is still active, either the session key MUST be changed or 1674 the or the session MUST be terminated. 1676 7.14 MIP-HA-to-FA-SPI AVP 1678 The MIP-HA-to-FA-SPI AVP (AVP Code 3**) is of type Unsigned32, and 1679 contains the Security Parameter Index the home agent is to use to 1680 refer to the session key it shares with the foreign agent. The SPI 1681 created MUST NOT be a value between zero (0) and 255, which is the 1682 reserved namespace defined in [MOBILEIP]. If FA-HA keys are being 1683 generated, this AVP MUST be added in the HAA message by the Home 1684 Agent for the AAAH's (or AAAF's) use in providing the value of the 1685 MIP-HA-to-FA-SPI member of the grouped MIP-HA-to-FA-Key AVP. 1687 The FA should provide this to the AAAH in the AMR, as it should 1688 control the assignment of this SPI. 1690 8.0 Accounting AVPs 1692 [Editor note: Will anyone use the AVPs of this section? Deployments 1693 using MIP, e.g., 3GPP2 have VSAs for this purpose.] 1695 8.1 Accounting-Input-Octets AVP 1697 The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64, 1698 and contains the number of octets in IP packets received from the 1699 user. This AVP MUST be included in all Accounting-Request messages 1700 and MAY be present in the corresponding Accounting-Answer messages as 1701 well. 1703 8.2 Accounting-Output-Octets AVP 1705 The Accounting-Output-Octets AVP (AVP Code 364) is of type 1706 Unsigned64, and contains the number of octets in IP packets sent to 1707 the user. This AVP MUST be included in all Accounting-Request 1708 messages and MAY be present in the corresponding Accounting-Answer 1709 messages as well. 1711 8.3 Acct-Session-Time AVP 1713 The Acct-Time AVP (AVP Code 46) is of type Unsigned32, and indicates 1714 the length of the current session in seconds. This AVP MUST be 1715 included in all Accounting-Request messages and MAY be present in the 1716 corresponding Accounting-Answer messages as well. 1718 8.4 Accounting-Input-Packets AVP 1720 The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64, 1721 and contains the number of IP packets received from the user. This 1722 AVP MUST be included in all Accounting-Request messages and MAY be 1723 present in the corresponding Accounting-Answer messages as well. 1725 Calhoun Standards Track - March 2003 33 1726 8.5 Accounting-Output-Packets AVP 1728 The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64, 1729 and contains the number of IP packets sent to the user. This AVP MUST 1730 be included in all Accounting-Request messages and MAY be present in 1731 the corresponding Accounting-Answer messages as well. 1733 8.6 Event-Timestamp AVP 1735 The Event-Timestamp (AVP Code 55) is of type Time, and MAY be 1736 included in an Accounting-Request message to record the time that 1737 this event occurred on the mobility agent, in seconds since January 1738 1, 1970 00:00 UTC. 1740 9.0 AVP Occurrence Tables 1742 The following tables presents the AVPs defined in this document, and 1743 specifies in which Diameter messages they MAY, or MAY NOT be present. 1744 Note that AVPs that can only be present within a Grouped AVP are not 1745 represented in this table. 1747 The table uses the following symbols: 1748 0 The AVP MUST NOT be present in the message. 1749 0+ Zero or more instances of the AVP MAY be present in the 1750 message. 1751 0-1 Zero or one instance of the AVP MAY be present in the 1752 message. 1753 1 One instance of the AVP MUST be present in the message. 1755 9.1 Mobile IP Command AVP Table 1757 The table in this section is limited to the Command Codes defined in 1758 this specification. 1760 +-----------------------+ 1761 | Command-Code | 1762 |-----+-----+-----+-----+ 1763 Attribute Name | AMR | AMA | HAR | HAA | 1764 ------------------------------|-----+-----+-----+-----+ 1765 Authorization-Lifetime | 0-1 | 0-1 | 1 | 0 | 1766 Auth-Application-Id | 1 | 1 | 1 | 1 | 1767 Auth-Session-State | 0-1 | 0-1 | 1 | 0 | 1768 Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 0-1 | 1769 Destination-Host | 0-1 | 0 | 0-1 | 0 | 1770 Destination-Realm | 1 | 0 | 1 | 0 | 1771 Error-Message | 0 | 0-1 | 0 | 0-1 | 1772 Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 | 1773 MIP-Candidate-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 | 1774 MIP-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 | 1775 MIP-Originating-Foreign-AAA | 0-1 | 0 | 0-1 | 0 | 1776 MIP-FA-Challenge | 0-1 | 0 | 0 | 0 | 1778 Calhoun Standards Track - March 2003 34 1779 MIP-FA-to-HA-Key | 0 | 0-1 | 0-1 | 0 | 1780 MIP-FA-to-HA-SPI | 0 | 0 | 0 | 0-1 | 1781 MIP-HA-to-FA-SPI | 0 | 0 | 0 | 0-1 | 1782 MIP-MN-to-FA-Key | 0 | 0-1 | 0 | 0 | 1783 MIP-FA-to-MN-SPI | 0 | 0 | 0 | 0-1 | 1784 MIP-MN-to-FA-SPI | 0 | 0 | 0 | 0-1 | 1785 MIP-MN-to-HA-Key | 0 | 0-1 | 0 | 0 | 1786 MIP-HA-to-MN-SPI | 0 | 0 | 0 | 0-1 | 1787 MIP-MN-to-HA-SPI | 0 | 0 | 0 | 0-1 | 1788 MIP-Feature-Vector | 0-1 | 0-1 | 1 | 0 | 1789 MIP-Filter-Rule | 0 | 0+ | 0+ | 0 | 1790 MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 | 1791 MIP-Key-Lifetime | 0 | 0-1 | 0-1 | 0 | 1792 MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 | 1793 MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 | 1794 MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 | 1795 MIP-Reg-Request | 1 | 0 | 1 | 0 | 1796 Origin-Host | 1 | 1 | 1 | 1 | 1797 Origin-Realm | 1 | 1 | 1 | 1 | 1798 Origin-State-Id | 0-1 | 0-1 | 0-1 | 0-1 | 1799 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 1800 Redirect-Host | 0 | 0+ | 0 | 0+ | 1801 Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 | 1802 Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 | 1803 Result-Code | 0 | 1 | 0 | 1 | 1804 Re-Auth-Request-Type | 0 | 0-1 | 0 | 0 | 1805 Route-Record | 0+ | 0 | 0+ | 0 | 1806 Session-Id | 1 | 1 | 1 | 1 | 1807 User-Name | 1 | 0-1 | 1 | 0-1 | 1808 ------------------------------|-----+-----+-----+-----| 1810 9.2 Accounting AVP Table 1811 The table in this section is used to represent which AVPs defined in 1812 this document are to be present in the Accounting messages, defined 1813 in [DIAMBASE]. 1815 +-------------+ 1816 | Command-Code| 1817 |------+------+ 1818 Attribute Name | ACR | ACA | 1819 -------------------------------------|------+------+ 1820 Accounting-Input-Octets | 1 | 0-1 | 1821 Accounting-Input-Packets | 1 | 0-1 | 1822 Accounting-Output-Octets | 1 | 0-1 | 1823 Accounting-Output-Packets | 1 | 0-1 | 1824 Acct-Multi-Session-Id | 1 | 0-1 | 1825 Acct-Session-Time | 1 | 0-1 | 1826 MIP-Feature-Vector | 1 | 0-1 | 1827 MIP-Home-Agent-Address | 1 | 0-1 | 1828 MIP-Mobile-Node-Address | 1 | 0-1 | 1829 Event-Timestamp | 0-1 | 0 | 1830 -------------------------------------|------+------+ 1832 Calhoun Standards Track - March 2003 35 1833 10.0 IANA Considerations 1835 This section contains the namespaces that have either been created in 1836 this specification, or the values assigned to existing namespaces 1837 managed by IANA. 1839 10.1 Command Codes 1841 This specification assigns the values 260 and 262 from the Command 1842 Code namespace defined in [DIAMBASE]. See section 2.0 for the 1843 assignment of the namespace in this specification. 1845 10.2 AVP Codes 1847 This specification assigns the values 318-348 and 363-367 from the 1848 AVP Code namespace defined in [DIAMBASE]. See sections 4.0 and 6.0 1849 for the assignment of the namespace in this specification. 1851 10.3 Result-Code AVP Values 1853 This specification assigns the values 4005-4008, and 5024-5025 from 1854 the Result-Code AVP (AVP Code 268) value namespace defined in 1855 [DIAMBASE]. See section 3.0 for the assignment of the namespace in 1856 this specification. 1858 10.4 MIP-Feature-Vector AVP Values 1860 There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that 1861 are available for assignment. This document assigns bits 1-9, 1862 aslisted in section 4.5. The remaining bits should only be assigned 1863 via Standards Action [IANA]. 1865 10.5 MIP-Algorithm-Type AVP Values 1867 As defined in Section 6.8, the MIP-Algorithm-Type AVP (AVP Code 345) 1868 defines the values 1-3. All remaining values are available for 1869 assignment via Designated Expert [IANA]. 1871 10.6 MIP-Replay-Mode AVP Values 1873 As defined in Section 6.9, the MIP-Replay-Mode AVP (AVP Code 346) 1874 defines the values 1-3. All remaining values, except zero, are 1875 available for assignment via Designated Expert [IANA]. 1877 10.7 Application Identifier 1879 Calhoun Standards Track - March 2003 36 1880 This specification assigns the value four (4) to the Application 1881 Identifier namespace defined in [DIAMBASE]. See section 1.8 for more 1882 information. 1884 11.0 Security Considerations 1886 This specification describes a Mobile IP Diameter Application for 1887 authenticating and authorizing a Mobile IP mobile node. The 1888 authentication algorithm used is dependent upon the transforms used 1889 within the Mobile IP protocol, and [MIPCHAL]. This specification, 1890 conjunction with [MIPKEYS] also defines a method by which the home 1891 Diameter server can create and distribute session keys and nonces for 1892 use in authenticating and integrity-protecting Mobile IP registration 1893 messages [MOBILEIP]. The key distribution is asymmetric since 1894 communication with the mobile node occurs via the Mobile IP protocol 1895 [AAAKEY, MOBILEIP], while communication to the Home Agent and Foreign 1896 Agent occurs via the Diameter protocol. Where untrusted Diameter 1897 agents are present, end-to-end security MUST be used Between the AAAH 1898 and the HA/FA. 1900 Nonces are sent to the mobile node, which are used to generate the 1901 session keys via the HMAC-MD5 one-way function. If the nonces are 1902 compromised, then the pre-shared key between the mobile node and the 1903 home Diameter server would be vulnerable to an offline dictionary 1904 attack. To prevent this, the pre-shared key between the mobile node 1905 and the home Diameter server SHOULD be a randomly chosen quantity of 1906 at least 96 bits. 1908 Since the session key is determined by the long-term secret and the 1909 nonce, the nonce SHOULD be temporally and globally unique; if the 1910 nonce were to repeat, then so would the session key. To prevent this, 1911 a nonce is strongly recommended to be random [RANDOM] value of at 1912 least 128 bits. The long-term secret between the MN and HA MUST be 1913 periodically refreshed, to guard against recovery of the long-term 1914 secret due to nonce reuse or other factors. This is accomplished 1915 using out-of-band mechanisms, which are not specified in this 1916 document. 1918 It should also be noted that it is not recommended to set the MIP- 1919 Session-Key AVP value equal to zero, since keeping session keys for a 1920 long time (no refresh) increases the level of vulnerability. 1922 12.0 References 1924 12.1 Normative 1926 [DIAMBASE] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. 1927 Rubens, 1928 "Diameter Base Protocol", draft-ietf-aaa-diameter- 1929 17.txt (editor queue status), December 2002. 1931 [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA C 1933 Calhoun Standards Track - March 2003 37 1934 Considerations Section in RFCs", BCP 26, RFC 2434, 1935 October 1998 1937 [MOBILEIP] C. Perkins, Editor. IP Mobility Support. RFC 3344, 1938 August 2002. 1940 [MIPCHAL] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response 1941 Extensions", draft-ietf-mip4-rfc3012bis-00.txt. 1942 November 2003. 1944 [NAI] B. Aboba, M. Beadles "The Network Access Identifier." 1945 RFC 2486. January 1999. 1947 [HMAC] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: 1948 Keyed Hashing for Message Authentication. RFC 2104, 1949 February 1997. 1951 [MIPKEYS] C. Perkins, P. Calhoun, "AAA Registration Keys for 1952 Mobile IP", draft-ietf-mipv4-aaa-key-00.txt, 1953 IETF work in progress, November 2003. 1955 [AAANAI] F. Johansson, T.Johansson, "AAA NAI for Mobile IP 1956 Extension", draft-mobileip-aaa-nai-05.txt, IETF work 1957 In progress, March 2003. 1959 12.2 Informative 1961 [MIPREQ] S. Glass, S. Jacobs, C. Perkins, "Mobile IP 1962 Authentication, Authorization, and Accounting 1963 Requirements". RFC 2977. October 2000. 1965 [CDMA2000] T. Hiller and al, "CDMA2000 Wireless Data Requirements 1966 for AAA", RFC 3141, June 2001. 1968 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 1969 Requirement Levels", BCP 14, RFC 2119, March 1997. 1971 [EVALROAM] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming 1972 Protocols", RFC 2477, January 1999. 1974 [MIPNAI] P. Calhoun, C. Perkins, "Mobile IP Network Address 1975 Identifier Extension", RFC 2794, March 2000. 1977 [RANDOM] D. Eastlake, 3rd, S. Crocker, and J. Schiller. 1978 Radomness Recommendations for Security. RFC 1750, 1979 Internet Engineering Task Force, December 1994. 1981 13.0 Acknowledgements 1983 The authors would like to thank Nenad Trifunovic, Haseeb Akhtar and 1984 Pankaj Patel for their participation in the pre-IETF Document Reading 1986 Calhoun Standards Track - March 2003 38 1987 Party, to Erik Guttman for his very useful proposed text, and to 1988 Fredrik Johansson, Martin Julien and Bob Kopacz for their very useful 1989 contributed text. 1991 The authors would also like to thank the participants of 3GPP2's TSG- 1992 X working group for their valuable feedback and also the following 1993 people for their contribution in the development of the protocol: 1995 Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael 1996 Chen, Henry Haverinen, Johan Johansson. In addition, general text 1997 for use with the redirect server were borrowed from Diameter-EAP text 1998 by Pasi Eronen. 2000 Pat Calhoun would like to thank Sun Microsystems since most of the 2001 effort put into this document was done while he was in their employ. 2003 14.0 Authors' Addresses 2005 Questions about this memo can be directed to: 2007 Pat Calhoun 2008 Airespace 2009 110 Nortech Parkway 2010 San Jose, CA 95154 2011 USA 2013 Phone: +1 408-635-2023 2014 Email: pcalhoun@airespace.com 2016 Tony Johansson 2017 Bytemobile, Inc 2018 2029 Stierlin Court 2019 Mountain View, California 94043 2020 USA 2022 Phone: +1 650-641-7817 2023 Fax: +1 650-641-7701 2024 E-Mail: tony.johansson@bytemobile.com 2026 Charles E. Perkins 2027 Nokia Research Center 2028 313 Fairchild Drive 2029 Mountain View, California 94043 2030 USA 2032 Phone: +1 650-625-2986 2033 Fax: +1 650-625-2502 2034 E-Mail: charliep@iprg.nokia.com 2036 Tom Hiller 2037 Lucent Technologies 2038 1960 Lucent Lane 2040 Calhoun Standards Track - March 2003 39 2041 Naperville, IL 60566 2042 USA 2043 Phone: +1 630-979-7673 2044 E-mail: tomhiller@lucent.com 2046 Calhoun Standards Track - March 2003 40 2047 Full Copyright Statement 2049 "Copyright (C) The Internet Society (date). All Rights Reserved. 2050 This document and translations of it may be copied and furnished to 2051 others, and derivative works that comment on or otherwise explain it 2052 or assist in its implmentation may be prepared, copied, published 2053 and distributed, in whole or in part, without restriction of any 2054 kind, provided that the above copyright notice and this paragraph 2055 are included on all such copies and derivative works. However, this 2056 document itself may not be modified in any way, such as by removing 2057 the copyright notice or references to the Internet Society or other 2058 Internet organizations, except as needed for the purpose of 2059 developing Internet standards in which case the procedures for 2060 copyrights defined in the Internet Standards process must be 2061 followed, or as required to translate it into 2063 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 2064 9, RFC 2026, October 1996. 2066 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 2067 Levels", BCP 14, RFC 2119, March 1997 2069 Calhoun Standards Track - March 2003 41