idnits 2.17.1 draft-mccann-dime-rfc4004bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2416. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 11, 2007) is 6010 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2607' is mentioned on line 257, but not defined == Unused Reference: 'NAI' is defined on line 2264, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3588 (ref. 'DIAMBASE') (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3344 (ref. 'MOBILEIP') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3012 (ref. 'MIPCHAL') (Obsoleted by RFC 4721) ** Obsolete normative reference: RFC 2486 (ref. 'NAI') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 3546 (ref. 'TLS') (Obsoleted by RFC 4366) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DIME Working Group P. Calhoun 3 Internet Draft Cisco Systems, Inc. 4 Intended Status: Standards Track T. Johansson 5 Expires: May 11, 2008 Bytemobile Inc. 6 C. Perkins 7 NSN 8 T. Hiller 9 Alcatel-Lucent 10 P. McCann 11 Motorola 12 November 11, 2007 14 Diameter Mobile IPv4 Application, Revised 15 draft-mccann-dime-rfc4004bis-00.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 11, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document specifies a Diameter application that allows a Diameter 48 server to authenticate, authorize and collect accounting information 49 for Mobile IPv4 services rendered to a mobile node. Combined with 50 the Inter-Realm capability of the base protocol, this application 51 allows mobile nodes to receive service from foreign service 52 providers. Diameter Accounting messages will be used by the foreign 53 and home agents to transfer usage information to the Diameter 54 servers. 56 Table of Contents 58 1. Introduction.....................................................3 59 1.1. Entities and Relationships...................................4 60 1.2. Mobility Security Associations...............................4 61 1.3. Handoff......................................................6 62 1.4. Structure of the Document....................................7 63 2. Acronyms.........................................................7 64 3. Scenarios and Message Flows......................................7 65 3.1. Inter-Realm Mobile IPv4......................................7 66 3.2. Allocation of Home Agent in Foreign Network.................12 67 3.3. Co-located Mobile Node......................................16 68 3.4. Key Distribution............................................18 69 4. Diameter Protocol Considerations................................20 70 4.1. Diameter Session Management.................................20 71 5. Command-Code Values.............................................23 72 5.1. AA-Mobile-Node-Request......................................23 73 5.2. AA-Mobile-Node-Answer.......................................24 74 5.3. Home-Agent-MIP-Request......................................25 75 5.4. Home-Agent-MIP-Answer.......................................26 76 6. Result-Code AVP Values..........................................27 77 6.1. Transient Failures..........................................27 78 6.2. Permanent Failures..........................................28 79 7. Mandatory AVPs..................................................28 80 7.1. MIP-Reg-Request AVP.........................................29 81 7.2. MIP-Reg-Reply AVP...........................................29 82 7.3. MIP-Mobile-Node-Address AVP.................................29 83 7.4. MIP-Home-Agent-Address AVP..................................30 84 7.5. MIP-Feature-Vector AVP......................................30 85 7.6. MIP-MN-AAA-Auth AVP.........................................31 86 7.7. MIP-FA-Challenge AVP........................................32 87 7.8. MIP-Filter-Rule AVP.........................................32 88 7.9. MIP-Candidate-Home-Agent-Host...............................32 89 7.10. MIP-Originating-Foreign-AAA AVP............................32 90 7.11. MIP-Home-Agent-Host AVP....................................33 91 8. Key Distribution................................................33 92 8.1. Authorization Lifetime vs. MIP Key Lifetime.................34 93 8.2. Nonce vs. Session Key.......................................34 94 8.3. Distributing the Mobile-Home Session Key....................35 95 8.4. Distributing the Mobile-Foreign Session Key.................36 96 8.5. Distributing the Foreign-Home Session Key...................36 97 9. Key Distribution AVPs...........................................37 98 9.1. MIP-FA-to-MN-MSA AVP........................................38 99 9.2. MIP-FA-to-HA-MSA AVP........................................38 100 9.3. MIP-HA-to-FA-MSA AVP........................................39 101 9.4. MIP-HA-to-MN-MSA AVP........................................39 102 9.5. MIP-MN-to-FA-MSA AVP........................................39 103 9.6. MIP-MN-to-HA-MSA AVP........................................40 104 9.7. MIP-Session-Key AVP.........................................40 105 9.8. MIP-Algorithm-Type AVP......................................40 106 9.9. MIP-Replay-Mode AVP.........................................40 107 9.10. MIP-FA-to-MN-SPI AVP.......................................41 108 9.11. MIP-FA-to-HA-SPI AVP.......................................41 109 9.12. MIP-Nonce AVP..............................................41 110 9.13. MIP-MSA-Lifetime AVP.......................................41 111 9.14. MIP-HA-to-FA-SPI AVP.......................................41 112 10. Accounting AVPs................................................42 113 10.1. Accounting-Input-Octets AVP................................42 114 10.2. Accounting-Output-Octets AVP...............................42 115 10.3. Acct-Session-Time AVP......................................42 116 10.4. Accounting-Input-Packets AVP...............................42 117 10.5. Accounting-Output-Packets AVP..............................43 118 10.6. Event-Timestamp AVP........................................43 119 11. AVP Occurrence Tables..........................................43 120 11.1. Mobile IP Command AVP Table................................44 121 11.2. Accounting AVP Table.......................................45 122 12. IANA Considerations............................................45 123 12.1. Command Codes..............................................45 124 12.2. AVP Codes..................................................45 125 12.3. Result-Code AVP Values.....................................46 126 12.4. MIP-Feature-Vector AVP Values..............................46 127 12.5. MIP-Algorithm-Type AVP Values..............................46 128 12.6. MIP-Replay-Mode AVP Values.................................46 129 12.7. Application Identifier.....................................46 130 13. Security Considerations........................................46 131 14. References.....................................................48 132 14.1. Normative References.......................................48 133 14.2. Informative References.....................................49 134 15. Acknowledgements...............................................50 136 1. Introduction 138 Mobile IPv4 [MOBILEIP] allows a Mobile Node (MN) to change its point 139 of attachment to the Internet while maintaining its fixed home 140 address. Packets directed to the home address are intercepted by a 141 Home Agent (HA), encapsulated in a tunnel, and forwarded to the MN at 142 its current point of attachment. Optionally, a Foreign Agent (FA) 143 may be deployed at this point of attachment, which can serve as the 144 tunnel endpoint and may also provide access control for the visited 145 network link. In this role, the FA has to authenticate each MN that 146 may attach to it, whether the MN is from the same or a different 147 administrative domain. The FA has to verify that the MN is 148 authorized to attach and use resources in the foreign domain. Also, 149 the FA must provide information to the home administrative domain 150 about the resources used by the MN while it is attached in the 151 foreign domain. 153 The Authentication, Authorization, and Accounting (AAA) requirements 154 for Mobile IPv4 are described in detail in other documents [MIPREQ, 155 CDMA2000]. This document specifies a Diameter application to meet 156 these requirements. This application is not applicable to the Mobile 157 IPv6 protocol. 159 Message formats (e.g., as in section 5.1) are specified as lists of 160 Attribute-Value Pairs (AVPs) using the syntax as described in RFC 161 2234 [ABNF]. This includes the use of the "*" symbol to denote zero 162 or more occurrences of an AVP. 164 Conventions Used in This Document 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 170 1.1. Entities and Relationships 172 The Diameter Mobile IPv4 Application supports the HA and FA in 173 providing Mobile IPv4 service to MNs. Both the HA and FA act as 174 Diameter clients. The MNs interact with the HA and FA by using only 175 Mobile IPv4 and therefore do not implement Diameter. 177 The FA, when present, is always assumed to exist in the visited 178 administrative domain. The HA may be statically or dynamically 179 allocated to the MN in the home administrative domain or may be 180 dynamically allocated to the MN in a visited administrative domain. 181 The home domain contains a home AAA server (AAAH), and the visited 182 domain contains a foreign AAA server (AAAF). When the MN is "at 183 home" (present on its home network), the AAAH and AAAF may be the 184 same. 186 1.2. Mobility Security Associations 188 The base Mobile IPv4 protocol [MOBILEIP] assumes the existence of a 189 Mobility Security Association (MSA) between the MN and HA (MN-HA 190 MSA). The MN-HA MSA is used to authenticate, by using a keyed hash- 191 style algorithm, the Mobile IP Registration Request that is sent from 192 the MN to the HA. It is important to authenticate Registration 193 Requests, as they inform the HA about the MN's current Care-of- 194 Address, which is the destination for tunneled packets from the home 195 network. Without authentication, malicious attackers would be able 196 to redirect packets to anywhere on the Internet. The MSA comprises 197 an agreement on a Security Parameters Index (SPI, a 32-bit number) 198 that will be used to refer to the MSA, an algorithm that will be used 199 to compute keyed hashes over messages, and a shared secret key. To 200 enable authentication of a message, the sender appends a Mobile IP 201 Authentication Extension that contains the SPI and the result of 202 running the keyed hash over the entire previous contents of the 203 message. The recipient checks the Authentication Extension by 204 looking up the MSA based on the SPI, re-computing the keyed hash, and 205 verifying that the result is equal to the contents of the received 206 Authentication Extension. 208 The base Mobile IPv4 protocol also supports an optional MSA between 209 the MN and FA (MN-FA MSA). If available, the MN-FA MSA is used by 210 the FA to authenticate each Registration Request passing through it 211 on the way to the HA. Although not critical to the operation of the 212 base protocol, the MN-FA MSA is useful when the FA has to know the 213 authenticity of a Registration Request; e.g., when it will be 214 generating accounting records for a session. The MN-FA MSA may also 215 be useful in future work related to handoff optimization. 217 Similarly, Mobile IPv4 supports an optional MSA between the FA and HA 218 (FA-HA MSA). The FA-HA MSA is useful for authenticating messages 219 between the FA and HA, such as when the HA seeks to inform the FA 220 that it has revoked a Mobile IP registration. 222 Note that configuration of MSAs that involve FAs is substantially 223 more difficult than configuring the one between the MN and HA, 224 because the MN and HA are often in the same administrative domain and 225 the MN will retain the same HA for long periods of time. In 226 contrast, the MN is likely to encounter many FAs over time and may 227 often find itself in foreign administrative domains. 229 The base Mobile IPv4 protocol assumes that MNs are identified by 230 their static home IP addresses and that all MSAs are statically 231 preconfigured. The Diameter Mobile IPv4 application, together with 232 extensions [MIPNAI, MIPCHAL, MIPKEYS, AAANAI] to the base Mobile IPv4 233 protocol, allows an MN to be dynamically assigned a home address 234 and/or home agent when it attaches to the Internet. This set of 235 specifications also supports the dynamic configuration of the MN-HA, 236 MN-FA, and FA-HA MSAs. The dynamic configuration of these 237 relationships is important to support deployments in which the MN can 238 attach to a visited network without having a pre-established 239 relationship with it. 241 Initially, the MN is assumed to have a long-term AAA security 242 association only with the AAAH. This security association is indexed 243 by the MN's NAI, and, like the MSAs, comprises an agreement on a SPI, 244 an algorithm, and a shared secret key. The MN enters a visited 245 network and requests service from some FA by sending a Mobile IPv4 246 Registration Request. The FA contacts an AAAF in its own 247 administrative domain to authenticate and authorize the request for 248 service. The AAAF and AAAH may establish a Diameter session directly 249 with each other, such as via a Diameter Redirect, or may pass 250 messages via a network of Diameter proxies. Where the AAAF and AAAH 251 route messages to each other through proxies, rather than a direct 252 connection, transitive trust is assumed. MNs can include their 253 Network Access Identifier (NAI) in a Mobile IPv4 Registration Request 254 [MIPNAI], which serves in place of the home address to identify the 255 MN. The NAI is used to route Diameter messages toward the correct 256 AAAH. This use of the NAI is consistent with the roaming model 257 defined by the ROAMOPS Working Group [EVALROAM, RFC2607]. 259 The AAAH can authenticate the Registration Request with the use of 260 the MN-AAA security association [MIPCHAL]. If authentication is 261 successful, the AAAH then generates and distributes MSAs to the MN, 262 HA, and FA. For each of the MSA pairs that involve the MN (i.e., 263 MN-HA/HA-MN MSAs and MN-FA/FA-MN MSAs), the AAAH generates a nonce 264 and then hashes it together with the MN-AAA shared key to derive the 265 session key for the MSA pair. The nonces are sent to the HA that 266 includes them in the Registration Reply, which enables the MN to 267 derive the same keys [MIPKEYS]. At the same time, the AAAH must 268 distribute the MN-HA/HA-MN MSAs and the FA-HA/HA-FA MSAs to the HA 269 and must distribute the MN-FA/FA-MN MSAs and the FA-HA/HA-FA MSAs to 270 the FA. These are sent in Diameter AVPs and must be independently 271 secured by using IPSec or TLS between the AAAH and the FA and between 272 the AAAH and the HA. See section 8 for more information on key 273 derivation and distribution. 275 Note that MSAs in Mobile IP are unidirectional in that, for example, 276 the MN-HA MSA (used to protect traffic from the MN to the HA) and the 277 HA-MN MSA (used to protect traffic from the HA to the MN) can use 278 different SPIs, algorithms, and shared secrets. This is true of the 279 base Mobile IP protocol despite common existing practice during 280 manual configuration of MSAs in which all parameters are set to the 281 same value in both directions. This document supports the use of 282 different SPIs in each direction; however, it only supports the 283 distribution of a single session key for each pair of MSAs between 284 two nodes. The security implications of this are discussed in 285 section 13. This document sometimes names only one of the two 286 unidirectional MSAs when referring to the distribution of the single 287 shared secret and the pair of SPIs for the pair of MSAs between two 288 entities. 290 1.3. Handoff 292 In addition to supporting the derivation and transport of the MN-HA, 293 MN-FA, and FA-HA MSAs, this application also supports MIPv4 handoff. 294 When an MN moves from one point of attachment to another, the MN can 295 continue the same Mobile IPv4 session by using its existing HA and 296 home address. 298 The MN accomplishes this by sending a Mobile IPv4 Registration 299 Request from its new point of attachment. To enable a single set of 300 accounting records to be maintained for the entire session, including 301 handoffs, it is necessary to allow the AAAH to bind the new 302 registration to the pre-existing session. To enable the Mobile IPv4 303 Registration Request to be routed to the same AAAH, the MN SHOULD 304 include the AAAH NAI [AAANAI] in such re-registrations. Also, to 305 assist the AAAH in routing the messages to the MN's existing HA the 306 mobile node SHOULD include the HA NAI [AAANAI] in such re- 307 registrations. If the mobile node does not support the Mobile IPv4 308 AAA NAI extension [AAANAI], this functionality is not available. 310 1.4. Structure of the Document 312 The remainder of this document is structured as follows. Section 2 313 provides acronym definitions. Section 3 provides some examples and 314 message flows illustrating both the Mobile IPv4 and Diameter messages 315 that occur when a mobile node attaches to the Internet. Section 4 316 defines the relationship of this application to the Diameter Base 317 Protocol. Section 5 defines the new command codes. Section 6 318 defines the new result codes used by this application. Section 7 319 defines the set of mandatory Attribute-Value-Pairs (AVPs). Section 8 320 gives an overview of the key distribution capability, and Section 9 321 defines the key distribution AVPs. Section 10 defines the accounting 322 AVPs, and section 11 contains a listing of all AVPs and their 323 occurrence in Diameter commands. Finally, sections 12 and 13 give 324 IANA and security considerations, respectively. 326 2. Acronyms 328 AAAH Authentication, Authorization, and Accounting Home 329 AAAF Authentication, Authorization, and Accounting Foreign 330 AMA AA-Mobile-Node-Answer 331 AMR AA-Mobile-Node-Request 332 ASR Abort-Session-Request 333 AVP Attribute Value Pair 334 CoA Care-of-Address 335 FA Foreign Agent 336 FQDN Fully Qualified Domain Name 337 HA Home Agent 338 HAA Home-Agent-MIP-Answer 339 HAR Home-Agent-MIP-Request 340 MN Mobile Node 341 MSA Mobility Security Association 342 NAI Network Access Identifier 343 RRQ Registration Request 344 SPI Security Parameters Index 345 STR Session-Termination-Request 347 3. Scenarios and Message Flows 349 This section presents four scenarios illustrating Diameter Mobile 350 IPv4 application and describes the operation of key distribution. 352 In this document, the role of the "attendant" [MIPREQ] is performed 353 by either the FA (when it is present in a visited network) or the HA 354 (for co-located mobile nodes not registering via an FA), and these 355 terms will be used interchangeably in the following scenarios. 357 3.1. Inter-Realm Mobile IPv4 359 When a mobile node requests service by issuing a Registration Request 360 to the foreign agent, the foreign agent creates the AA-Mobile-Node- 361 Request (AMR) message, which includes the AVPs defined in section 7. 363 The Home Address, Home Agent, Mobile Node NAI, and other important 364 fields are extracted from the registration messages for possible 365 inclusion as Diameter AVPs. The AMR message is then forwarded to the 366 local Diameter server, known as the AAA-Foreign, or AAAF. 368 Visited Realm Home Realm 369 +-----------+ +-----------+ 370 |example.net| AMR/AMA |example.org| 371 | AAAF |<------------------->| AAAH | 372 +->| server | server-server | server | 373 | +-----------+ communication +-----------+ 374 | ^ ^ 375 | AMR/AMA | client-server | HAR/HAA 376 | | communication | 377 v v v 378 +---------+ +---------+ +---------+ 379 | Foreign | | Foreign | | Home | 380 | Agent | | Agent | | Agent | 381 +---------+ +---------+ +---------+ 382 ^ 383 | Mobile IP 384 | 385 v 386 +--------+ 387 | Mobile | 388 | Node | mn@example.org 389 +--------+ 391 Figure 1. Inter-realm Mobility 393 Upon receiving the AMR, the AAAF follows the procedures outlined in 394 [DIAMBASE] to determine whether the AMR should be processed locally 395 or forwarded to another Diameter server known as the AAA-Home, or 396 AAAH. Figure 1 shows an example in which a mobile node 397 (mn@example.org) requests service from a foreign provider 398 (example.net). The request received by the AAAF is forwarded to 399 example.org's AAAH server. 401 Figure 2 shows the message flows involved when the foreign agent 402 invokes the AAA infrastructure to request that a mobile node be 403 authenticated and authorized. Note that it is not required that the 404 foreign agent invoke AAA services every time a Registration Request 405 is received from the mobile, but rather only when the prior 406 authorization from the AAAH expires. The expiration time of the 407 authorization is communicated through the Authorization-Lifetime AVP 408 in the AA-Mobile-Node-Answer (AMA; see section 5.2) from the AAAH. 410 Mobile Node Foreign Agent AAAF AAAH Home 411 Agent 412 ----------- ------------- ------------ ---------- ------- 413 Advertisement & 414 <--------- Challenge 416 Reg-Req&MN-AAA ----> 418 AMR------------> 419 Session-Id = foo 421 AMR------------> 422 Session-Id = foo 424 HAR-----------> 425 Session-Id = bar 427 <----------HAA 428 Session-Id = bar 430 <-----------AMA 431 Session-Id = foo 433 <------------AMA 434 Session-Id = foo 436 <-------Reg-Reply 438 Figure 2. Mobile IPv4/Diameter Message Exchange 440 The foreign agent (as shown in Figure 2) MAY provide a challenge, 441 which would give it direct control over the replay protection in the 442 Mobile IPv4 registration process, as described in [MIPCHAL]. The 443 mobile node includes the Challenge and MN-AAA authentication 444 extension to enable authorization by the AAAH. If the authentication 445 data supplied in the MN-AAA extension is invalid, the AAAH returns 446 the response (AMA) with the Result-Code AVP set to 447 DIAMETER_AUTHENTICATION_REJECTED. 449 The above scenario causes the MN-FA and MN-HA keys to be exposed to 450 Diameter agents all along the Diameter route. If this is a concern, 451 a more secure approach is to eliminate the AAAF and other Diameter 452 agents, as shown in Figure 3. 454 Redirect 455 FA AAAF Agent AAAH 456 AMR 457 ----------------> 458 AMR 459 ----------------> 460 AMA (Redirect) 461 <---------------- 462 AMA (Redirect) 463 <---------------- 465 Setup Security Association 466 <--------------------------------------------------> 468 AMR 469 --------------------------------------------------> 470 AMA (MN-FA key) 471 <--------------------------------------------------- 473 Figure 3. Use of a Redirect Server with AMR/AMA 475 In Figure 3, the FA sets up a TLS [TLS] or IPSec [IPSEC]-based 476 security association with the AAAH directly and runs the AMR/AMA 477 exchange over it. This provides end-to-end security for secret keys 478 that may have to be distributed. 480 Figure 4 shows the interaction between the AAAH and HA with the help 481 of a redirect agent. When the AAAH and HA are in the same network, 482 it is likely that the AAAH knows the IP address of the HA, so the 483 redirect server would therefore not be needed; however, it is shown 484 anyway for completeness. The redirect server will most likely be 485 used in the case where the HA is allocated in a foreign network (see 486 section 3.2 for more details of HA allocation in foreign networks). 488 Redirect 489 HA Agent AAAH 490 HAR 491 <-------------------- 492 HAA (Redirect) 493 --------------------> 494 Setup Security Association 495 <----------------------------------------> 496 HAR (MN-HA key) 497 <----------------------------------------- 498 HAA 499 -----------------------------------------> 501 Figure 4. Use of a Redirect Server with HAR/HAA 503 As in Figure 2, the FA of Figure 3 would still provide the challenge 504 and the mobile sends the RRQ, etc.; however, these steps were 505 eliminated from Figure 3 to reduce clutter. The redirect server 506 eliminates the AAAF and any other Diameter agents from seeing the 507 keys as they are transported to the FA and HA. Note that the message 508 flows in Figure 3 and Figure 4 apply only to the initial 509 authentication and key exchange. Accounting messages would still be 510 sent via Diameter agents, not via the direct connection, unless 511 network policies dictate otherwise. 513 A mobile node that supports the AAA NAI extension [AAANAI], which has 514 been previously authenticated and authorized, MUST always include the 515 assigned home agent in the HA Identity subtype of the AAA NAI 516 extension, and the authorizing Home AAA server in the AAAH Identity 517 subtype of the AAA NAI extension, when re-authenticating. Therefore, 518 in the event that the AMR generated by the FA is for a session that 519 was previously authorized, it MUST include the Destination-Host AVP, 520 with the identity of the AAAH found in the AAAH-NAI, and the MIP- 521 Home- Agent-Host AVP with the identity and realm of the assigned HA 522 found in the HA-NAI. If, on the other hand, the mobile node does not 523 support the AAA NAI extension, the FA may not have the identity of 524 the AAAH and the identity and realm of the assigned HA. This means 525 that without support of the AAA NAI extension, the FA may not be able 526 to guarantee that the AMR will be destined to the same AAAH, which 527 previously authenticated and authorized the mobile node, as the FA 528 may not know the identity of the AAAH. 530 If the mobile node was successfully authenticated, the AAAH then 531 determines which Home Agent to use for the session. First, the AAAH 532 checks whether an HA has been requested by the MN by checking the 533 MIP-Home-Agent-Address AVP and the MIP-Home-Agent-Host AVP. The 534 administrative domain owning the HA may be determined from the realm 535 portion of the MIP-Home-Agent-Host AVP, or by checking the 536 Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP and 537 the value of the MIP-Originating-Foreign-AAA AVP. If the requested 538 HA belongs to a permitted administrative domain, the AAAH SHOULD use 539 the given HA for the session. Otherwise, the AAAH returns the 540 response (AMA) with the Result-Code AVP set to either 541 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE or 542 DIAMETER_ERROR_HA_NOT_AVAILABLE. 544 If the MN has not requested any particular HA, then an HA MUST be 545 dynamically allocated. In this case the MIP-Feature-Vector will have 546 the Home-Agent-Requested flag set. If the Home-Address-Allocatable- 547 Only-in-Home-Realm flag is not set, and if the Foreign-Home-Agent- 548 Available flag is set, then the AAAH SHOULD allow the foreign realm 549 to allocate the HA (see section 3.2) but MAY allocate one itself in 550 the home realm if dictated by local policy. If the Home-Address- 551 Allocatable-Only-in-Home-Realm flag is set, then the AAAH MUST 552 allocate an HA in the home realm on behalf of the MN. Allocation of 553 the HA can be done in a variety of ways, including by using a load- 554 balancing algorithm to keep the load on all home agents equal. The 555 actual algorithm used and the method of discovering the home agents 556 are outside the scope of this specification. 558 The AAAH then sends a Home-Agent-MIP-Request (HAR), which contains 559 the Mobile IPv4 Registration Request message data encapsulated in the 560 MIP-Reg-Request AVP, to the assigned or requested Home Agent. Refer 561 to Figure 4 if the AAAH does not have a direct path to the HA. The 562 AAAH MAY allocate a home address for the mobile node, and the Home 563 Agent MUST support home address allocation. In the event that the 564 AAAH handles address allocation, it includes the home address in a 565 MIP-Mobile-Node-Address AVP within the HAR. The absence of this AVP 566 informs the Home Agent that it must perform the home address 567 allocation. 569 Upon receipt of the HAR, the home agent first processes the Diameter 570 message. The home agent processes the MIP-Reg-Request AVP and 571 creates the Registration Reply, encapsulating it within the 572 MIP-Reg-Reply AVP. In the creation of the Registration Reply, the 573 Home Agent MUST include the HA NAI and the AAAH NAI, which will be 574 created from the Origin-Host AVP and Origin-Realm AVP of the HAR. If 575 a home address is needed, the home agent MUST also assign one and 576 include the address in both the Registration Reply and the 577 MIP-Mobile-Node-Address AVP. 579 Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer 580 (AMA) message, which includes the same Acct-Multi-Session-Id 581 contained in the HAA and the MIP-Home-Agent-Address and MIP-Mobile- 582 Node-Address AVPs in the AMA message. See Figure 3 and Figure 4 for 583 the use of the redirect agent for the secure transport of the HAA and 584 AMA messages. 586 See section 4.1 for information on the management of sessions and 587 session identifiers by the Diameter Mobile IPv4 entities. 589 3.2. Allocation of Home Agent in Foreign Network 590 The Diameter Mobile IPv4 application allows a home agent to be 591 allocated in a foreign network, as required in [MIPREQ, CDMA2000]. 592 When a foreign agent detects that the mobile node has a home agent 593 address equal to 0.0.0.0 or 255.255.255.255 in the Registration 594 Request message, it MUST add a MIP-Feature-Vector AVP with the Home- 595 Agent-Requested flag set to one. If the home agent address is set to 596 255.255.255.255, the foreign agent MUST set the Home-Address- 597 Allocatable-Only-in-Home-Realm flag equal to one. If the home agent 598 address is set to 0.0.0.0, the foreign agent MUST set the Home- 599 Address-Allocatable-Only-in-Home-Realm flag equal to zero. 601 When the AAAF receives an AMR message with the Home-Agent-Requested 602 flag set to one and with the Home-Address-Allocatable-Only-in-Home- 603 Realm flag equal to zero, the AAAF MAY set the Foreign-Home-Agent- 604 Available flag in the MIP-Feature-Vector AVP in order to inform the 605 AAAH that it is willing and able to assign a Home Agent for the 606 mobile node. When doing so, the AAAF MUST include the MIP-Candidate- 607 Home-Agent-Host AVP and the MIP-Originating-Foreign-AAA-AVP. The 608 MIP-Candidate-Home-Agent-Host AVP contains the identity (i.e., a 609 DiameterIdentity, which is an FQDN) of the home agent that would be 610 assigned to the mobile node, and the MIP-Originating-Foreign-AAA AVP 611 contains the identity of the AAAF. The AAAF now sends the AMR to the 612 AAAH. However, as discussed above, the use of Diameter agents between 613 the FA and AAAH would expose the MN-FA key. If this is deemed 614 undesirable, a redirect server approach SHOULD be utilized to 615 communicate the AMR to the AAAH. This causes the FA to communicate 616 the AMR directly to the AAAH via a security association. 618 If the mobile node with AAA NAI extension support [AAANAI] has been 619 previously authorized by the AAAH, now has to be re-authenticated, 620 and requests to keep the assigned home agent in the foreign network, 621 the mobile node MUST include the HA NAI and the AAAH NAI in the 622 registration request to the FA. Upon receipt, the FA will create the 623 AMR, including the MIP-Home-Agent-Address AVP and the Destination- 624 Host AVP based on the AAAH NAI, and include the MIP-Home-Agent-Host 625 AVP based on the home agent NAI. If the AAAF authorizes the use of 626 the requested home agent, the AAAF MUST set the Home-Agent-In- 627 Foreign-Network bit in the MIP-Feature-Vector AVP. 629 If the mobile node has to be re-authenticated but does not support 630 the AAA NAI extension, it sends a registration request without the 631 AAA NAI and the HA NAI, even though it has previously been authorized 632 by the AAAH and requests to keep the assigned home agent in the 633 foreign network. Upon receipt, the FA will create the AMR, including 634 the MIP-Home-Agent-Address AVP. If the AAAF authorizes the use of 635 the requested home agent, and if it knows that the agent is in its 636 own domain, the AAAF MUST set the Home-Agent-In-Foreign-Network bit 637 in the MIP-Feature-Vector AVP. 639 When the AAAH receives an AMR message, it first checks the 640 authentication data supplied by the mobile node, according to the 641 MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether 642 to authorize the mobile node. If the AMR indicates that the AAAF has 643 offered to allocate a Home Agent for the mobile node (i.e., the 644 Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP), 645 or if the AMR indicates that the AAAF has offered a previously 646 allocated Home Agent for the mobile node (i.e., the Home-Agent-In- 647 Foreign-Network is set in the MIP-Feature-Vector AVP), then the AAAH 648 must decide whether its local policy would allow the user to have or 649 keep a home agent in the foreign network. Assuming that the mobile 650 node is permitted to do so, the AAAH determines the IP address of the 651 HA based upon the FQDN of the HA by using DNS or learns it via an 652 MIP-Home-Agent-Address AVP in a redirect response to an HAR (i.e., if 653 the redirect server adds this AVP to the HAA). Then it sends an HAR 654 message to Home Agent by including the Destination-Host AVP set to 655 the value found in the AMR's MIP-Candidate-Home-Agent-Host AVP or 656 MIP-Home-Agent-Host AVP. If DNS is used to determine the HA IP 657 address, it is assumed that the HA has a public address and that it 658 can be resolved by DNS. 660 Security considerations may require that the HAR be sent directly 661 from the AAAH to the HA without the use of intermediary Diameter 662 agents. This requires that a security association between the AAAH 663 and HA be established, as in Figure 4. If no security association 664 can be established, the AAAH MUST return an AMA with the Result-Code 665 AVP set to DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. 667 If Diameter agents are being used (e.g., if there is no redirect 668 server) the AAAH sends the HAR to the originating AAAF. In this HAR 669 the Destination-Host AVP is set to the value found in the AMR's MIP- 670 Originating-Foreign-AAA AVP, and the MIP-Home-Agent-Host AVP or the 671 MIP-Candidate-Home-Agent-Host AVP found in the AMR is copied into the 672 HAR. 674 Therefore, the AAAH MUST always copy the MIP-Originating-Foreign-AAA 675 AVP from the AMR message to the HAR message. In cases when another 676 AAAF receives the HAR, this new AAAF will send the HAR to the HA. 678 Visited Home 679 Realm Realm 680 +--------+ ------- AMR -------> +--------+ 681 | AAAF | <------ HAR -------- | AAAH | 682 | | | | 683 +--->| server | ------- HAA -------> | server | 684 | +--------+ <------ AMA -------- +--------+ 685 | ^ | 686 | | | 687 HAR/HAA | AMR | | AMA 688 v | v 689 +---------+ +---------+ 690 | Home | | Foreign | 691 | Agent | | Agent | 692 +---------+ +---------+ 693 ^ 694 +--------+ | 695 | Mobile |<----------+ 696 | Node | Mobile IP 697 +--------+ 699 Figure 5. Home Agent Allocated in Visited Realm 701 Upon receipt of an HAA from the Home Agent in the visited realm, the 702 AAAF forwards the HAA to the AAAH in the home realm. The AMA is then 703 constructed and issued to the AAAF and, finally, to the FA. If the 704 Result-Code indicates success, the HAA and AMA MUST include the MIP- 705 Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. 707 If exposing keys to the Diameter Agents along the way represents an 708 unacceptable security risk, then the redirect approach depicted in 709 Figure 3 and Figure 4 MUST be used instead. 711 Mobile Node Foreign Agent Home Agent AAAF AAAH 712 ----------- ------------- ------------- ---------- ---------- 714 <----Challenge---- 715 Reg-Req (Response)-> 716 ------------AMR-------------> 717 -----AMR----> 718 <----HAR----- 719 <-----HAR------ 720 ------HAA------> 722 -----HAA----> 723 <----AMA----- 724 <-------------AMA------------ 725 <---Reg-Reply---- 727 Figure 6. MIP/Diameter Exchange for HA Is Allocated in 728 Visited Realm 730 If the mobile node moves to another foreign Network, it MAY either 731 request to keep the same Home Agent within the old foreign network or 732 request to get a new one in the new foreign network. If the AAAH is 733 willing to provide the requested service, the AAAH will have to 734 provide services for both visited networks; e.g., key refresh. 736 3.3. Co-located Mobile Node 738 If a mobile node registers with the Home Agent as a co-located mobile 739 node, no foreign agent is involved. Therefore, when the Home Agent 740 receives the Registration Request, an AMR message is sent to the 741 local AAAH server, with the Co-Located-Mobile-Node bit set in the 742 MIP-Feature-Vector AVP. The Home Agent also includes the Acct-Multi- 743 Session-Id AVP (see sections 4.1.1 and 4.1.2) in the AMR sent to the 744 AAAH, as the AAAH may find this piece of session-state or log entry 745 information useful. 747 Home 748 Realm 749 +--------+ 750 | AAAH | 751 | | 752 | server | 753 +--------+ 754 ^ | 755 | | 756 AMR | | AMA 757 | v 758 +--------+ +---------+ 759 | Mobile | Registration | Home | 760 | Node |-------------->| Agent | 761 +--------+ Request +---------+ 763 Figure 7. Co-located Mobile Node 765 If the MN-HA-Key-Requested bit was set in the AMR message from the 766 Home Agent, the home agent and mobile node's session keys would be 767 present in the AMA message. 769 Figure 8 shows a signaling diagram that indicates a secure way to set 770 up the necessary security associations when using redirect servers. 771 The Proxy AAA represents any AAA server or servers that the HA may 772 use. This applies to the visited or home network. 774 Local redirect 775 HA Proxy AAA Agent AAAH 777 AMR 778 ---------------> 779 AMR (Redirect) 780 --------------------> 781 AMA (Redirect) 782 <--------------------- 783 AMA (Redirect) 784 <---------------- 785 Setup Security Association 786 <------------------------------------------------------> 787 AMR 788 -------------------------------------------------------> 789 AMA (MN-HA key) 790 <------------------------------------------------------- 792 Figure 8. Use of Redirect Server for Co-located CoA 793 and AMR/AMA 794 3.4. Key Distribution 796 To allow the scaling of wireless data access across administrative 797 domains, it is necessary to minimize the number of pre-existing 798 Mobility Security Associations (MSAs) required. This means that each 799 Foreign Agent should not be required to have a pre-configured MSA 800 with each Home Agent on the Internet, nor should the mobile node be 801 required to have a pre-configured MSA (as defined in [MOBILEIP]) with 802 any specific foreign agent. Furthermore, when the mobile node 803 requests a dynamically allocated home agent, it is likely to receive 804 the address of a home agent for which it has no available mobility 805 security association. 807 The Diameter Mobile IPv4 application solves this by including key 808 distribution functionality, which means that after a Mobile Node is 809 authenticated the authorization phase includes the generation of 810 session keys and nonces. Specifically, three session keys and two 811 nonces are generated: 813 - K1: The MN-HA Session Key, which will be part of the MSA between 814 the Mobile Node and the Home Agent. The MN-HA Session Key 815 is derived from a nonce generated by AAA. The mobile node 816 obtains that nonce in the Registration Reply and generates 817 this key using the same formula that AAA uses. 819 - K2: The MN-FA Key, which will be part of the MSA between the 820 Mobile Node and the Foreign Agent. The MN-FA Key is derived 821 from a nonce generated by AAA. The mobile node obtains that 822 nonce in the Registration Reply and generates the MN-FA key 823 using the same formula that AAA uses. 825 - K3: The FA-HA Key, which will be part of the MSA between the 826 Foreign Agent and the Home Agent. 828 The same session key is used in both directions between two entities; 829 e.g., the Mobile Node and the Foreign Agent use the same session key 830 for the MN-FA and the FA-MN authentication extensions. The security 831 implications of this are examined in section 13. However, the SPIs 832 may be different for the MN-FA and the FA-MN authentication 833 extensions. The SPI for the MN-FA MSA is used on messages sent from 834 the MN to the FA, and the SPI for the FA-MN MSA is used on messages 835 sent from the FA to the MN. 837 All keys and nonces are generated by the AAAH, even if a Home Agent 838 is dynamically allocated in the foreign network. 840 Figure 9 depicts the MSAs used for Mobile-IPv4 message integrity 841 using the keys created by the DIAMETER server. 843 +--------+ +--------+ 844 |Foreign | K3 | Home | 845 |Agent |<-------------------->| Agent | 846 | | | | 847 +--------+ +--------+ 848 ^ ^ 849 | K2 K1 | 850 | +--------+ | 851 | | Mobile | | 852 +------>| Node |<------+ 853 | | 854 +--------+ 856 Figure 9. Mobility Security Associations after Session 857 Key and Nonce Distribution 859 The keys destined for the foreign and home agent are propagated to 860 the mobility agents via the Diameter protocol. If exposing keys to 861 the Diameter Agents along the way represents an unacceptable security 862 risk, then the keys MUST be protected either by IPSec or TLS security 863 associations that exist directly between the HA and AAAH or the FA 864 and AAAF, as explained above. 866 The keys destined for the mobile node MUST also be propagated via the 867 Mobile IPv4 protocol and therefore MUST follow the mechanisms 868 described in [MIPKEYS] instead. In [MIPKEYS], the mobile node 869 receives a nonce for each key it needs, and the mobile node will use 870 the nonce and the long-term shared secret to create the keys (see 871 section 8). 873 Once the session keys have been established and propagated, the 874 mobility devices can exchange registration information directly, as 875 defined in [MOBILEIP], without the need of the Diameter 876 infrastructure. However, the session keys have a lifetime, after 877 which the Diameter infrastructure MUST be invoked again if new 878 session keys and nonces are to be acquired. 880 4. Diameter Protocol Considerations 882 This section details the relationship of the Diameter Mobile IPv4 883 application to the Diameter base protocol. 885 This document specifies Diameter Application-ID 2. Diameter nodes 886 conforming to this specification MAY advertise support by including 887 the value of two (2) in the Auth-Application-Id or the Acct- 888 Application-Id AVP of the Capabilities-Exchange-Request and 889 Capabilities-Exchange-Answer commands [DIAMBASE]. The value of two 890 (2) MUST be used as the Application-Id in all AMR/AMA and HAR/HAA 891 commands. The value of two (2) MUST be used as the Application-Id in 892 all ACR/ACA commands, as this application defines new, mandatory AVPs 893 for accounting. The value of zero (0) SHOULD be used as the 894 Application-Id in all STR/STA and ASR/ASA commands, as these are 895 defined in the Diameter base protocol and no additional mandatory 896 AVPs for those commands are defined in this document. 898 Given the nature of Mobile IPv4, re-authentication can only be 899 initiated by a mobile node, which does not participate in the 900 Diameter message exchanges. Therefore, Diameter server initiated 901 re-auth does not apply to this application, and RAR/RAA commands MUST 902 NOT be sent for Diameter Mobile IPv4 sessions. 904 4.1. Diameter Session Management 906 The AAAH and AAAF MAY maintain session-state or MAY be session- 907 stateless. AAA redirect agents and AAA relay agents MUST NOT 908 maintain session-state. The AAAH, AAAF, proxies and relays agents 909 MUST maintain transaction state. 911 A mobile node's session is identified via its identity in the User- 912 Name AVP and the MIP-Mobile-Node-Address, and the MIP-Home-Agent- 913 Address AVPs. This is necessary in order to allow the session state 914 machine, defined in the base protocol [DIAMBASE], to be used without 915 modification for this application. However, as the MN may interact 916 with more than one FA during the life of its session, it is important 917 for the Diameter Mobile IPv4 application to distinguish the two 918 pieces of the session (some state at the FA, some state at the HA) 919 and to manage them independently. The following sub-sections give 920 further details. 922 4.1.1. Session Identifiers 924 During creation of the AMR, the FA will choose a session identifier. 925 During the creation of the HAR, the AAAH MUST use a different session 926 identifier than that used in the AMR/AMA. If the AAAH is session- 927 stateful, it MUST send the same session identifier for all HARs 928 initiated on behalf of a given mobile node's session. Otherwise, if 929 the AAAH is session-stateless, it will manufacture a unique session- 930 id for every HAR. 932 When the HA is first allocated, it MUST create and include an Acct- 933 Multi-Session-Id AVP in the HAA returned to the AAAH. This 934 identifier will be kept constant for the life of the Mobile IPv4 935 session, as detailed in the next subsection. 937 4.1.2. Managing Sessions During Mobile IPv4 Handoffs 939 Given the nature of Mobile IPv4, a mobile node MAY receive service 940 from many foreign agents during a period of time. However, the home 941 realm should not view these handoffs as different sessions, as this 942 could affect billing systems. Furthermore, foreign agents usually do 943 not communicate between each other, which implies that AAA 944 information cannot be exchanged between these entities. 946 A handoff registration request from a mobile node will cause the FA 947 to send an AMR to its AAAF. The AMR will include a new session 948 identifier and MAY be sent to a new AAAF (i.e., a AAAF different from 949 that used by the previous FA). However, the AMR shall be received by 950 the AAAH to which the user is currently registered (possibly via the 951 redirect mechanism depicted in Figure 3). 953 As the AAAH may be session-stateless, it is necessary for the 954 resulting HAR received by the HA to be identified as a continuation 955 of an existing session. If the HA receives an HAR for a mobile node 956 with a new session identifier and the HA can guarantee that this 957 request is to extend an existing service, then the HA MUST be able to 958 modify its internal session state information to reflect the new 959 session identifier. 961 For correlation to occur, accounting records must have some 962 commonality across handoffs. Therefore, the home agent MUST send the 963 same Acct-Multi-Session-Id AVP value in all HAAs for the mobile's 964 session. That is, the HA generates a unique Acct-Multi-Session-Id 965 when receiving an HAR for a new session and returns this same value 966 in every HAA for the session. This Acct-Multi-Session-Id AVP will be 967 returned to the foreign agent by the AAAH in the AMA. Both the 968 foreign and home agents MUST include the Acct-Multi-Session-Id in the 969 accounting messages, as depicted in Figure 10. 971 ACR, Session-Id = foo ACR, Session-Id = bar 972 Acct-Multi-Session-Id = a Acct-Multi-Session-Id = a 973 ---------------------> <-------------------- 974 +----+ +------+ +------+ +----+ 975 | FA | | AAAF | | AAAH | | HA | 976 +----+ +------+ +------+ +----+ 977 <--------------------- ---------------------> 978 ACA, Session-Id = foo ACA, Session-Id = bar 980 Figure 10: Accounting messages w/ Mobile IPv4 981 Application 983 4.1.3. Diameter Session Termination 985 A foreign and home agent following this specification MAY expect 986 their respective Diameter servers to maintain session state 987 information for each mobile node in their networks. For a Diameter 988 Server to release any resources allocated to a specific mobile node, 989 that server has to receive a Session-Termination-Request (STR) from a 990 mobility agent. The mobility agents MUST issue the Session- 991 Termination-Request (STR) if the Authorization Lifetime has expired 992 and no subsequent MIP registration request has been received. 994 The AAAH SHOULD only deallocate all resources after the STR is 995 received from the home agent. This ensures that a mobile node that 996 moves from one foreign agent to another (for example, as a result of 997 a handover) does not cause the Home Diameter Server to free all 998 resources for the mobile node. Therefore, an STR from a foreign 999 agent would free the session from the foreign agent, but not the 1000 session state associated with the home agent (see Figure 11). 1002 STR, Session-Id = foo STR, Session-Id = bar 1003 ---------------------> <-------------------- 1004 +----+ +------+ +------+ +----+ 1005 | FA | | AAAF | | AAAH | | HA | 1006 +----+ +------+ +------+ +----+ 1007 <--------------------- ---------------------> 1008 STA, Session-Id = foo STA, Session-Id = bar 1010 Figure 11. Session Termination and Session Identifiers 1012 When deallocating all of the mobile node's resources, the home 1013 Diameter server (and the foreign Diameter server in the case of an HA 1014 allocated in foreign network) MUST destroy all session keys that may 1015 still be valid. 1017 In the event that the AAAF wishes to terminate a session, its Abort- 1018 Session-Request (ASR) [DIAMBASE] message SHOULD be sent to the FA. 1019 Similarly, the AAAH SHOULD send its message to the Home Agent. 1021 5. Command-Code Values 1023 This section defines Command-Code [DIAMBASE] values that MUST be 1024 supported by all Diameter implementations conforming to this 1025 specification. The following Command Codes are defined in this 1026 specification: 1028 Command-Name Abbreviation Code Section 1029 ----------------------------------------------------------- 1030 AA-Mobile-Node-Request AMR 260 5.1 1031 AA-Mobile-Node-Answer AMA 260 5.2 1032 Home-Agent-MIP-Request HAR 262 5.3 1033 Home-Agent-MIP-Answer HAA 262 5.4 1035 5.1. AA-Mobile-Node-Request 1037 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field 1038 set to 260 and the 'R' bit set in the Command Flags field, is sent by 1039 an attendant (i.e., the Foreign Agent), acting as a Diameter client, 1040 to a AAAF in order to request the authentication and authorization of 1041 a mobile node. The foreign agent (or home agent in the case of a co- 1042 located Mobile Node) uses information found in the Registration 1043 Request to construct the following AVPs, to be included as part of 1044 the AMR: 1046 Home Address (MIP-Mobile-Node-Address AVP) 1047 Home Agent Address (MIP-Home-Agent-Address AVP) 1048 Mobile Node NAI (User-Name AVP [DIAMBASE]) 1049 MN-HA Key Request (MIP-Feature-Vector AVP) 1050 MN-FA Key Request (MIP-Feature-Vector AVP) 1051 MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP) 1052 Foreign Agent Challenge Extension (MIP-FA-Challenge AVP) 1053 Home Agent NAI (MIP-Home-Agent-Host AVP) 1054 Home AAA server NAI (Destination-Host AVP [DIAMBASE]) 1055 Home Agent to Foreign Agent SPI (MIP-HA-to-FA-SPI AVP) 1057 If the mobile node's home address is zero, the foreign or home agent 1058 MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. If the 1059 home agent address is zero or all ones, the MIP-Home-Agent-Address 1060 AVP MUST NOT be present in the AMR. 1062 If a home agent is used in a visited network, the AAAF MAY set the 1063 Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in 1064 the AMR message to indicate that it is willing to assign a Home Agent 1065 in the visited realm. 1067 If the mobile node's home address is all ones, the foreign or home 1068 agent MUST include a MIP-Mobile-Node-Address AVP, set to all ones. 1070 If the mobile node includes the home agent NAI and the home AAA 1071 server NAI [AAANAI], the foreign agent MUST include the MIP-Home- 1072 Agent-Host AVP and the Destination-Host AVP in the AMR. 1074 Message Format 1076 ::= < Diameter Header: 260, REQ, PXY > 1077 < Session-ID > 1078 { Auth-Application-Id } 1079 { User-Name } 1080 { Destination-Realm } 1081 { Origin-Host } 1082 { Origin-Realm } 1083 { MIP-Reg-Request } 1084 { MIP-MN-AAA-Auth } 1085 [ Acct-Multi-Session-Id ] 1086 [ Destination-Host ] 1087 [ Origin-State-Id ] 1088 [ MIP-Mobile-Node-Address ] 1089 [ MIP-Home-Agent-Address ] 1090 [ MIP-Feature-Vector ] 1091 [ MIP-Originating-Foreign-AAA ] 1092 [ Authorization-Lifetime ] 1093 [ Auth-Session-State ] 1094 [ MIP-FA-Challenge ] 1095 [ MIP-Candidate-Home-Agent-Host ] 1096 [ MIP-Home-Agent-Host ] 1097 [ MIP-HA-to-FA-SPI ] 1098 [ MIP-MN-to-FA-SPI ] 1099 * [ Proxy-Info ] 1100 * [ Route-Record ] 1101 * [ AVP ] 1103 5.2. AA-Mobile-Node-Answer 1105 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field 1106 set to 260 and the 'R' bit cleared in the Command Flags field, is 1107 sent by the AAAH in response to the AA-Mobile-Node-Request message. 1108 The User-Name MAY be included in the AMA if it is present in the AMR. 1109 The Result-Code AVP MAY contain one of the values defined in section 1110 6, in addition to the values defined in [DIAMBASE]. 1112 An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST 1113 include the MIP-Home-Agent-Address AVP, MUST include the MIP-Mobile- 1114 Node-Address AVP, and includes the MIP-Reg-Reply AVP if and only if 1115 the Co-Located-Mobile-Node bit was not set in the MIP-Feature-Vector 1116 AVP. The MIP-Home-Agent-Address AVP contains the Home Agent assigned 1117 to the mobile node, while the MIP-Mobile-Node-Address AVP contains 1118 the home address that was assigned. The AMA message MUST contain the 1119 MIP-FA-to-HA-MSA and MIP-FA-to-MN-MSA if they were requested in the 1120 AMR and were present in the HAR. The MIP-MN-to-HA-MSA and MIP-HA-to- 1121 MN-MSA AVPs MUST be present if the session keys were requested in the 1122 AMR and the Co-Located-Mobile-Node bit was set in the MIP-Feature- 1123 Vector AVP. 1125 Message Format 1127 ::= < Diameter Header: 260, PXY > 1128 < Session-Id > 1129 { Auth-Application-Id } 1130 { Result-Code } 1131 { Origin-Host } 1132 { Origin-Realm } 1133 [ Acct-Multi-Session-Id ] 1134 [ User-Name ] 1135 [ Authorization-Lifetime ] 1136 [ Auth-Session-State ] 1137 [ Error-Message ] 1138 [ Error-Reporting-Host ] 1139 [ Re-Auth-Request-Type ] 1140 [ MIP-Feature-Vector ] 1141 [ MIP-Reg-Reply ] 1142 [ MIP-MN-to-FA-MSA ] 1143 [ MIP-MN-to-HA-MSA ] 1144 [ MIP-FA-to-MN-MSA ] 1145 [ MIP-FA-to-HA-MSA ] 1146 [ MIP-HA-to-MN-MSA ] 1147 [ MIP-MSA-Lifetime ] 1148 [ MIP-Home-Agent-Address ] 1149 [ MIP-Mobile-Node-Address ] 1150 * [ MIP-Filter-Rule ] 1151 [ Origin-State-Id ] 1152 * [ Proxy-Info ] 1153 * [ AVP ] 1155 5.3. Home-Agent-MIP-Request 1157 The AAA sends the Home-Agent-MIP-Request (HAR), indicated by the 1158 Command-Code field set to 262 and the 'R' bit set in the Command 1159 Flags field, to the Home Agent. If the Home Agent is to be assigned 1160 in a foreign network, the HAR is issued by the AAAH and forwarded by 1161 the AAAF to the HA if no redirect servers are involved. If any are, 1162 the HAR is sent directly to the HA via a security association. If 1163 the HAR message does not include a MIP-Mobile-Node-Address AVP, the 1164 Registration Request has 0.0.0.0 for the home address, and the HAR is 1165 successfully processed, the Home Agent MUST allocate the mobile nodes 1166 address. If, on the other hand, the home agent's local AAA server 1167 allocates the mobile node's home address, the local AAA server MUST 1168 include the assigned address in a MIP-Mobile-Node-Address AVP. 1170 When session keys are requested for use by the mobile node, the AAAH 1171 MUST create them and include them in the HAR message. When a FA-HA 1172 session key is requested, it will be created and distributed by the 1173 AAAH server. 1175 Message Format 1177 ::= < Diameter Header: 262, REQ, PXY > 1178 < Session-Id > 1179 { Auth-Application-Id } 1180 { Authorization-Lifetime } 1181 { Auth-Session-State } 1182 { MIP-Reg-Request } 1183 { Origin-Host } 1184 { Origin-Realm } 1185 { User-Name } 1186 { Destination-Realm } 1187 { MIP-Feature-Vector } 1188 [ Destination-Host ] 1189 [ MIP-MN-to-HA-MSA ] 1190 [ MIP-MN-to-FA-MSA ] 1191 [ MIP-HA-to-MN-MSA ] 1192 [ MIP-HA-to-FA-MSA ] 1193 [ MIP-MSA-Lifetime ] 1194 [ MIP-Originating-Foreign-AAA ] 1195 [ MIP-Mobile-Node-Address ] 1196 [ MIP-Home-Agent-Address ] 1197 * [ MIP-Filter-Rule ] 1198 [ Origin-State-Id ] 1199 * [ Proxy-Info ] 1200 * [ Route-Record ] 1201 * [ AVP ] 1203 5.4. Home-Agent-MIP-Answer 1205 In response to a Home-Agent-MIP-Request, the Home Agent sends the 1206 Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field set 1207 to 262 and the 'R' bit cleared in the Command Flags field, to its 1208 local AAA server. The User-Name MAY be included in the HAA if it is 1209 present in the HAR. If the home agent allocated a home address for 1210 the mobile node, the address MUST be included in the MIP-Mobile-Node- 1211 Address AVP. The Result-Code AVP MAY contain one of the values 1212 defined in section 6 instead of the values defined in [DIAMBASE]. 1214 Message Format 1216 ::= < Diameter Header: 262, PXY > 1217 < Session-Id > 1218 { Auth-Application-Id } 1219 { Result-Code } 1220 { Origin-Host } 1221 { Origin-Realm } 1222 [ Acct-Multi-Session-Id ] 1223 [ User-Name ] 1224 [ Error-Reporting-Host ] 1225 [ Error-Message ] 1226 [ MIP-Reg-Reply ] 1227 [ MIP-Home-Agent-Address ] 1228 [ MIP-Mobile-Node-Address ] 1229 [ MIP-FA-to-HA-SPI ] 1230 [ MIP-FA-to-MN-SPI ] 1231 [ Origin-State-Id ] 1232 * [ Proxy-Info ] 1233 * [ AVP ] 1235 6. Result-Code AVP Values 1237 This section defines new Result-Code [DIAMBASE] values that MUST be 1238 supported by all Diameter implementations that conform to this 1239 specification. 1241 6.1. Transient Failures 1243 Errors in the transient failures category are used to inform a peer 1244 that the request could not be satisfied at the time it was received, 1245 but that it may be able to satisfy the request in the future. 1247 DIAMETER_ERROR_MIP_REPLY_FAILURE 4005 1248 This error code is used by the home agent when processing of 1249 the Registration Request has failed. 1251 DIAMETER_ERROR_HA_NOT_AVAILABLE 4006 1252 This error code is used to inform the foreign agent that the 1253 requested Home Agent cannot be assigned to the mobile node 1254 at this time. The foreign agent MUST return a Mobile IPv4 1255 Registration Reply to the mobile node with an appropriate 1256 error code. 1258 DIAMETER_ERROR_BAD_KEY 4007 1259 This error code is used by the home agent to indicate to the 1260 local Diameter server that the key generated is invalid. 1262 DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED 4008 1263 This error code is used by a mobility agent to indicate to 1264 the home Diameter server that the requested packet filter 1265 Rules cannot be supported. 1267 6.2. Permanent Failures 1269 Errors in the permanent failures category are used to inform the peer 1270 that the request failed and SHOULD NOT be attempted again. 1272 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5024 1273 This error is used by the AAAF to inform the AAAH that 1274 allocation of a home agent in the foreign domain is not 1275 permitted at this time. 1277 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025 1278 This error is used by the AAAF/AAAH to inform the peer 1279 that the requested Mobile IPv4 session keys could not be 1280 delivered via a security association. 1282 7. Mandatory AVPs 1284 The following table describes the Diameter AVPs defined in the Mobile 1285 IPv4 application; their AVP Code values, types, and possible flag 1286 values; and whether the AVP MAY be encrypted. 1288 Due to space constraints, the short form IPFiltrRule is used to 1289 represent IPFilterRule, and DiamIdent is used to represent 1290 DiameterIdentity. 1292 +--------------------------+ 1293 | AVP Flag rules | 1294 |----+-----+----+-----|----+ 1295 AVP Section | | |SHLD| MUST|MAY | 1296 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1297 -----------------------------------------|----+-----+----+-----|----| 1298 MIP-Reg-Request 320 7.1 OctetString| M | P | | V | Y | 1299 MIP-Reg-Reply 321 7.2 OctetString| M | P | | V | Y | 1300 MIP-MN-AAA-Auth 322 7.6 Grouped | M | P | | V | Y | 1301 MIP-Mobile-Node- 333 7.3 Address | M | P | | V | Y | 1302 Address 1303 MIP-Home-Agent- 334 7.4 Address | M | P | | V | Y | 1304 Address 1305 MIP-Candidate- 336 7.9 DiamIdent | M | P | | V | N | 1306 Home-Agent-Host 1307 MIP-Feature- 337 7.5 Unsigned32 | M | P | | V | Y | 1308 Vector 1309 MIP-Auth-Input- 338 7.6.2 Unsigned32 | M | P | | V | Y | 1310 Data-Length 1311 MIP- 339 7.6.3 Unsigned32 | M | P | | V | Y | 1312 Authenticator-Length 1313 MIP- 340 7.6.4 Unsigned32 | M | P | | V | Y | 1314 Authenticator-Offset 1315 MIP-MN-AAA-SPI 341 7.6.1 Unsigned32 | M | P | | V | Y | 1316 MIP-Filter-Rule 342 7.8 IPFiltrRule| M | P | | V | Y | 1317 MIP-FA-Challenge 344 7.7 OctetString| M | P | | V | Y | 1319 MIP-Originating- 347 7.10 Grouped | M | P | | V | Y | 1320 Foreign-AAA 1321 MIP-Home-Agent- 348 7.11 DiamIdent | M | P | | V | N | 1322 Host 1324 7.1. MIP-Reg-Request AVP 1326 The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and 1327 contains the Mobile IPv4 Registration Request [MOBILEIP] sent by the 1328 mobile node to the foreign agent. 1330 7.2. MIP-Reg-Reply AVP 1332 The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and 1333 contains the Mobile IPv4 Registration Reply [MOBILEIP] sent by the 1334 home agent to the foreign agent. 1336 7.3. MIP-Mobile-Node-Address AVP 1338 The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and 1339 contains the mobile node's home IP address. 1341 7.4. MIP-Home-Agent-Address AVP 1343 The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and 1344 contains the mobile node's home agent IP address. 1346 7.5. MIP-Feature-Vector AVP 1348 The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and 1349 is added with flag values set by the foreign agent or by the AAAF 1350 owned by the same administrative domain as the foreign agent. The 1351 foreign agent SHOULD include MIP-Feature-Vector AVP within the AMR 1352 message it sends to the AAAF. 1354 Flag values currently defined include the following: 1356 1 Mobile-Node-Home-Address-Requested 1357 2 Home-Address-Allocatable-Only-in-Home-Realm 1358 4 Home-Agent-Requested 1359 8 Foreign-Home-Agent-Available 1360 16 MN-HA-Key-Request 1361 32 MN-FA-Key-Request 1362 64 FA-HA-Key-Request 1363 128 Home-Agent-In-Foreign-Network 1364 256 Co-Located-Mobile-Node 1366 The flags are set according to the following rules. 1368 If the mobile node includes a valid home address (i.e., one not equal 1369 to 0.0.0.0 or 255.255.255.255) in its Registration Request, the 1370 foreign agent sets the Mobile-Node-Home-Address-Requested flag in the 1371 MIP-Feature-Vector AVP to zero. 1373 If the mobile node sets the home agent field equal to 255.255.255.255 1374 in its Registration Request, the foreign agent sets both the Home- 1375 Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home- 1376 Realm flag to one in the MIP-Feature-Vector AVP. 1378 If the mobile node sets the home agent field equal to 0.0.0.0 in its 1379 Registration Request, the foreign agent sets the Home-Agent-Requested 1380 flag to one and zeroes the Home-Address-Allocatable-Only-in-Home- 1381 Realm flag in the MIP-Feature-Vector AVP. 1383 Whenever the foreign agent sets either the 1384 Mobile-Node-Home-Address-Requested flag or the Home-Agent-Requested 1385 flag to one, it MUST set the MN-HA-Key-Request flag to one. The MN- 1386 HA-Key-Request flag is also set to one if the mobile node includes a 1387 "Generalized MN-HA Key Generation Nonce Request" [MIPKEYS] extension, 1388 with the subtype set to AAA. 1390 If the mobile node includes a "Generalized MN-FA Key Generation Nonce 1391 Request" [MIPKEYS] extension with the AAA subtype (1) in its 1392 Registration Request, the foreign agent sets the MN-FA-Key-Request 1393 flag to one in the MIP-Feature-Vector AVP. 1395 If the mobile node requests a home agent in the foreign network 1396 either by setting the home address field to all ones, or by 1397 specifying a home agent in the foreign network, and the AAAF 1398 authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign- 1399 Network bit to one. 1401 If the AAAF is willing and able to assign a home agent in the foreign 1402 network, the AAAF sets the Foreign-Home-Agent-Available flag to one. 1404 If the Home Agent receives a Registration Request from the mobile 1405 node indicating that the MN is acting as a co-located mobile node, 1406 the home agent sets the Co-Located-Mobile-Node bit to one. 1408 If the foreign agent's local policy allows it to receive AAA session 1409 keys and it does not have any existing FA-HA key with the home agent, 1410 the foreign agent MAY set the FA-HA-Key-Request flag. 1412 The foreign agent MUST NOT set the Foreign-Home-Agent-Available and 1413 Home-Agent-In-Foreign-Network flag both to one. 1415 When the AAAF receives the AMR message, it MUST first verify that the 1416 sender was an authorized foreign agent. The AAAF then takes any 1417 actions indicated by the settings of the MIP-Feature-Vector AVP 1418 flags. The AAAF then MAY set additional flags. Only the AAAF may 1419 set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign- 1420 Network flags to one. This is done according to local administrative 1421 policy. When the AAAF has finished setting additional flags 1422 according to its local policy, then the AAAF transmits the AMR with 1423 the possibly modified MIP-Feature-Vector AVP to the AAAH. 1425 7.6. MIP-MN-AAA-Auth AVP 1427 The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains 1428 some ancillary data to simplify processing of the authentication data 1429 in the Mobile IPv4 Registration Request [MOBILEIP, MIPCHAL] by the 1430 target AAA server. Its value has the following ABNF grammar: 1432 MIP-MN-AAA-Auth ::= < AVP Header: 322 > 1433 { MIP-MN-AAA-SPI } 1434 { MIP-Auth-Input-Data-Length } 1435 { MIP-Authenticator-Length } 1436 { MIP-Authenticator-Offset } 1437 * [ AVP ] 1439 7.6.1. MIP-MN-AAA-SPI AVP 1441 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 1442 indicates the MSA by which the targeted AAA server (AAAH) should 1443 attempt to validate the Authenticator computed by the mobile node 1444 over the Registration Request data. 1446 7.6.2. MIP-Auth-Input-Data-Length AVP 1448 The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type 1449 Unsigned32 and contains the length, in bytes, of the Registration 1450 Request data (data portion of MIP-Reg-Request AVP) that should be 1451 used as input to the algorithm, as indicated by the MN-AAA-SPI AVP, 1452 used to determine whether the Authenticator Data supplied by the 1453 mobile node is valid. 1455 7.6.3. MIP-Authenticator-Length AVP 1457 The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32 1458 and contains the length of the authenticator to be validated by the 1459 targeted AAA server (i.e., AAAH). 1461 7.6.4. MIP-Authenticator-Offset AVP 1463 The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32 1464 and contains the offset into the Registration Request Data, of the 1465 authenticator to be validated by the targeted AAA server (i.e., 1466 AAAH). 1468 7.7. MIP-FA-Challenge AVP 1470 The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and 1471 contains the challenge advertised by the foreign agent to the mobile 1472 node. This AVP MUST be present in the AMR if the mobile node used the 1473 RADIUS-style MN-AAA computation algorithm [MIPCHAL]. 1475 7.8. MIP-Filter-Rule AVP 1477 The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule and 1478 provides filter rules that have to be configured on the foreign or 1479 home agent for the user. The packet filtering rules are set by the 1480 AAAH by adding one or more MIP-Filter-Rule AVPs in the HAR if 1481 destined for the home agent and/or in the AMA if destined for the 1482 foreign agent. 1484 7.9. MIP-Candidate-Home-Agent-Host 1486 The MIP-Candidate-Home-Agent-Host AVP (AVP Code 336) is of type 1487 DiameterIdentity and contains the identity of a home agent in the 1488 foreign network that the AAAF proposes to be dynamically assigned to 1489 the mobile node. 1491 7.10. MIP-Originating-Foreign-AAA AVP 1493 The MIP-Originating-Foreign-AAA AVP (AVP Code 347) is of type Grouped 1494 and contains the identity of the AAAF, which issues the AMR to the 1495 AAAH. The MIP-Originating-Foreign-AAA AVP MUST only be used in cases 1496 when the home agent is or may be allocated in a foreign domain. If 1497 the MIP-Originating-Foreign-AAA AVP is present in the AMR, the AAAH 1498 MUST copy it into the HAR. 1500 MIP-Originating-Foreign-AAA ::= < AVP Header: 347 > 1501 { Origin-Realm } 1502 { Origin-Host } 1503 * [ AVP ] 1505 7.11. MIP-Home-Agent-Host AVP 1507 The MIP-Home-Agent-Host AVP (AVP Code 348) is of type Grouped and 1508 contains the identity of the assigned Home Agent. If the MIP-Home- 1509 Agent-Host AVP is present in the AMR, the AAAH MUST copy it into the 1510 HAR. 1512 MIP-Home-Agent-Host ::= < AVP Header: 348 > 1513 { Destination-Realm } 1514 { Destination-Host } 1515 * [ AVP ] 1517 8. Key Distribution 1519 The mobile node and mobility agents use session keys (i.e., the MN- 1520 FA, FA-HA, and MN-HA session keys) to compute authentication 1521 extensions applied to MIP registration messages, as defined in 1522 [MOBILEIP]. If session keys are requested, the AAAH MUST return the 1523 keys and nonces after the mobile node is successfully authenticated 1524 and authorized. 1526 The SPI values are used as key identifiers, and each session key has 1527 its own SPI value; nodes that share a key can have multiple different 1528 SPIs all referring to the same key. In all cases, the entity that 1529 receives an authentication extension (i.e., that verifies the 1530 authentication extension) is providing the entity that sends the 1531 authentication extension (i.e., that computes the authentication 1532 extension) the value of the SPI to use for that computation. Note 1533 that the keys in this model are symmetric in that they are used in 1534 both directions, even though the SPIs do not have to be symmetric. 1536 The mobile node allocates SPIs for use in the FA-MN and HA-MN 1537 mobility security associations, via the Mobile IPv4 AAA Key Request 1538 extensions [MIPKEYS]. The home agent allocates SPIs for the MN-HA 1539 and FA-HA mobility security association. The foreign agent chooses 1540 SPIs for the MN-FA and HA-FA mobility security associations. 1542 Once the session keys and nonces have been distributed, subsequent 1543 Mobile IPv4 registrations need not invoke the AAA infrastructure 1544 until the keys expire. As mandated by Mobile IPv4, these 1545 registrations MUST include the MN-HA authentication extension. 1547 Likewise, subsequent registrations MUST also include MN-FA 1548 authentication extension if the MN-FA session key was generated and 1549 distributed by AAA. The same holds true for subsequent use of the 1550 FA-HA authentication extensions. 1552 8.1. Authorization Lifetime vs. MIP Key Lifetime 1554 The Diameter Mobile IPv4 application makes use of two timers: the 1555 Authorization-Lifetime AVP [DIAMBASE] and the MIP-MSA-Lifetime AVP. 1557 The Authorization-Lifetime contains the number of seconds before the 1558 mobile node must issue a subsequent MIP registration request. The 1559 content of the Authorization-Lifetime AVP corresponds to the Lifetime 1560 field in the MIP header [MOBILEIP]. 1562 The MIP-MSA-Lifetime AVP contains the number of seconds before 1563 session keys destined for the mobility agents and the mobile node 1564 expire. A value of zero indicates infinity (no timeout). If not zero, 1565 the value of the MIP-MSA-Lifetime AVP MUST be at least equal to the 1566 value in the Authorization Lifetime AVP. 1568 8.2. Nonce vs. Session Key 1570 As described in section 3.4, the AAAH generates session keys and 1571 transmits them to the home agent and foreign agent. The AAAH 1572 generates nonces that correspond to the same keys and transmits them 1573 to the mobile node. When it is necessary to protect the session keys 1574 and SPIs from un-trusted Diameter agents, end-to-end security 1575 mechanisms such as TLS or IPSec are required to eliminate all 1576 Diameter Agents between the FA or HA and the AAAH, as outlined above. 1578 In [MIPKEYS], the mobility security associations are established via 1579 nonces transmitted to the mobile node via Mobile IPv4. To provide the 1580 nonces, the AAAH must generate a random [RANDOM] value of at least 1581 128 bits [MIPKEYS]. The mobile node then uses the nonce to derive the 1582 MN-HA and MN-FA session keys. 1584 More details of the MN-HA and the MN-FA session key creation 1585 procedures are found in [MIPKEYS]. 1587 The hashing algorithm used by the mobile node to construct the 1588 session key has to be the same as that used by the AAAH in the 1589 session key generation procedure. The AAAH therefore indicates the 1590 algorithm used along with the nonce by including a AAA SPI. 1592 The FA-HA and HA-FA session key is shared between the FA and HA. The 1593 AAAH generates a random [RANDOM] value of at least 128 bits for use 1594 as this session key. 1596 See sections 9 for details about the format of the AVPs used to 1597 transport the session keys. 1599 8.3. Distributing the Mobile-Home Session Key 1601 If the mobile node does not have an MN-HA session key, then the AAAH 1602 is likely to be the only trusted entity that is available to the 1603 mobile node. Thus, the AAAH has to generate the MN-HA session key. 1605 The distribution of the HA-MN (session) key to the HA is specified in 1606 sections 1.2 and 3.4. The HA and AAAH establish a security 1607 association (IPSec or TLS) and transport the key over it. If no 1608 security association exists between the AAAH and the home agent and a 1609 security association cannot be established, the AAAH MUST return a 1610 Result-Code AVP with DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. 1612 The AAAH also has to arrange for the key to be delivered to the 1613 mobile node. Unfortunately, the AAAH only knows about Diameter 1614 messages and AVPs, and the mobile node only knows about Mobile IPv4 1615 messages and extensions [MOBILEIP]. For this purpose, AAAH includes 1616 the MN-HA MIP-nonce AVP into a MIP-MN-to-HA-MSA AVP, which is added 1617 to the HAR (for FA COA style Mobile IPv4) or to the AMA (for 1618 collocated COA-style Mobile IPv4 messages) and delivered either to a 1619 local home agent or a home agent in the visited network. Note that 1620 the mobile node will use the nonce to create the MN-HA session key 1621 by using the MN-AAA key it shares with the AAAH [MIPKEYS]. The AAAH 1622 has to rely on the home agent (which also understands Diameter) to 1623 transfer the nonce into a Mobile IPv4 "Generalized MN-HA Key 1624 Generation Nonce Reply" extension [MIPKEYS] in the Registration Reply 1625 message. The HA includes the SPIs proposed by the mobile node and the 1626 home agent in the "Generalized MN-HA Key Generation Nonce Request" 1627 extension. The home agent can format the Reply message and extensions 1628 correctly for eventual delivery to the mobile node. The resulting 1629 Registration Reply is added to the HAA's MIP-Reg-Reply AVP. 1631 The AAAH parses the HAA message, transforms it into an AMA message 1632 containing an MIP-Reg-Reply AVP, and sends the AMA message to the 1633 foreign agent. The foreign agent then uses that AVP to recreate a 1634 Registration Reply message containing the "Generalized MN-HA Key 1635 Generation Nonce Reply" extension for delivery to the mobile node. 1637 In summary, the AAAH generates the MN-HA nonce, which is added to the 1638 MIP-MN-to-HA-MSA AVP, and a session key, which is added to the 1639 MIP-HA-to-MN-MSA AVP. These AVPs are delivered to the home agent in 1640 HAR or AMA messages. The home agent retains the session key for its 1641 own use and copies the nonce from the MIP-MN-to-HA-MSA AVP into a 1642 "Generalized MN-HA Key Generation Nonce Reply" extension, which is 1643 appended to the Mobile IPv4 Registration Reply message. This 1644 Registration Reply message MUST also include the HA-MN authentication 1645 extension, which is created by using the newly allocated HA-MN 1646 session key. The home agent then includes the Registration Reply 1647 message and extensions into a MIP-Reg-Reply AVP as part of the HAA 1648 message to be sent back to the AAA server. 1650 The key derived by the MN from the MN-HA session nonce is identical 1651 to the HA-MN session key provided to the HA. 1653 8.4. Distributing the Mobile-Foreign Session Key 1655 The MN-FA session nonce is also generated by AAAH (upon request) and 1656 added to the MIP-MN-to-FA-MSA AVP, which is added to the HAR and 1657 copied by the home agent into a "Generalized MN-FA Key Generation 1658 Nonce Reply" extension [MIPKEYS] of the Mobile IPv4 Registration 1659 Reply message. The HA also includes the SPI proposed by the FA in 1660 the "Generalized MN-FA Key Generation Nonce Reply" extension. The 1661 AAAH includes the FA-MN session key in the MIP-FA-to-MN-MSA AVP in 1662 the AMA, to be used by the foreign agent in the computation of the 1663 FA-MN authentication extension. 1665 The key derived by the MN from the MN-FA session nonce is identical 1666 to the FA-MN session key provided to the FA. 1668 8.5. Distributing the Foreign-Home Session Key 1670 If the foreign agent requests an FA-HA session key, it also includes 1671 a MIP-HA-to-FA-SPI AVP in the AMR to convey the SPI to be used by the 1672 home agent for this purpose. The AAAH generates the FA-HA session 1673 key, which is identical to the HA-FA session key, and distributes 1674 that to both the HA and the FA over respective security associations 1675 by using the MIP-HA-to-FA-MSA and MIP-FA-to-HA-MSA AVPs. The HA 1676 conveys the SPI that the FA MUST use in the HAA; this is similar to 1677 the way in which the FA conveys the SPI that the HA MUST use in the 1678 AMR. The AAAH later includes these SPIs in the MIP-FA-HA-MSA and 1679 MIP-HA-FA-MSA AVPs, respectively, along with the session key. 1681 Refer to Figure 2, Figure 3, Figure 4 and Figure 6 for the messages 1682 involved. 1684 Note that if multiple MNs are registered on the same FA and HA pair, 1685 then multiple mobility security associations would be distributed. 1686 However, only one is required to protect the Mobile IP control 1687 traffic between FA and HA. This creates an unacceptable level of 1688 state (i.e., to store the two SPIs and shared key for each FA-HA 1689 mobility security association). To improve scalability, the FA and HA 1690 may discard FA-HA mobility security associations prior to the time 1691 when they actually expire. However, if a proper discard policy is 1692 not chosen, this could cause Mobile IP messages in transit or waiting 1693 in queues for transmission to fail authentication. 1695 The FA MUST always use the FA-HA security association with the latest 1696 expiry time when computing authentication extensions on outgoing 1697 messages. The FA MAY discard HA-FA mobility security associations 10 1698 seconds after a new HA-FA mobility security association arrives with 1699 a later expiry time. 1701 The HA SHOULD use the HA-FA mobility security association that has 1702 the latest expiry time when computing authentication extensions in 1703 outgoing messages. However, when the HA receives a new HA-FA 1704 mobility security association with a later expiry time, the HA SHOULD 1705 wait 4 seconds for the AMA to propagate to the FA before using the 1706 new association. Note that the HA always uses the mobility security 1707 association from the HAR when constructing the Mobile IP Registration 1708 Reply in the corresponding HAA. The HA MAY discard an FA-HA mobility 1709 security association once it receives a message authenticated by a 1710 FA-HA mobility security association with a later expiry time. 1712 9. Key Distribution AVPs 1714 The Mobile-IP protocol defines a set of mobility security 1715 associations shared between the mobile node, foreign agent, and home 1716 agent. These three mobility security associations (MN-HA, MN-FA, and 1717 FA-HA) are dynamically created by the AAAH and have previously been 1718 described in section 3.4 and section 8. AAA servers supporting the 1719 Diameter Mobile IP Application MUST implement the key distribution 1720 AVPs defined in this document. 1722 The names of the key distribution AVPs indicate the two entities 1723 sharing the mobility security association. The first named entity in 1724 the AVP name will use the mobility security association to create 1725 authentication extensions using the given SPI and key. The second 1726 named entity in the AVP name will use the mobility security 1727 association to verify the authentication extensions of received 1728 Mobile IP messages. 1730 For instance, the MIP-MN-to-HA-MSA AVP contains the MN-HA nonce, 1731 which the mobile node will use to derive the MN-HA Key, and the 1732 MIP-HA-to-MN-MSA AVP contains the MN-HA key for the home agent. Note 1733 that mobility security associations are unidirectional; however, this 1734 application delivers only one key that is shared between both 1735 unidirectional security associations that exist between two peers. 1736 The security considerations of using the same key in each direction 1737 are given in section 13. The SPIs are, however, unique to each 1738 unidirectional security association and are chosen by the peer that 1739 will receive the Mobile IP messages authenticated with that security 1740 association. 1742 The following table describes the Diameter AVPs defined in the Mobile 1743 IP application and their AVP Code values, types, and possible flag 1744 values. 1746 +--------------------------+ 1747 | AVP Flag Rules | 1748 |----+-----+----+-----|----+ 1749 AVP Section | | |SHLD| MUST|MAY | 1750 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1751 -----------------------------------------|----+-----+----+-----|----| 1752 MIP-FA-to-HA-SPI 318 9.11 Unsigned32 | M | P | | V | Y | 1753 MIP-FA-to-MN-SPI 319 9.10 Unsigned32 | M | P | | V | Y | 1754 MIP-HA-to-FA-SPI 323 9.14 Unsigned32 | M | P | | V | Y | 1755 MIP-MN-to-FA-SPI TBD 9.16 Unsigned32 | M | P | | V | Y | 1756 MIP-MN-to-FA-MSA 325 9.5 Grouped | M | P | | V | Y | 1757 MIP-FA-to-MN-MSA 326 9.1 Grouped | M | P | | V | Y | 1758 MIP-FA-to-HA-MSA 328 9.2 Grouped | M | P | | V | Y | 1759 MIP-HA-to-FA-MSA 329 9.3 Grouped | M | P | | V | Y | 1760 MIP-MN-to-HA-MSA 331 9.6 Grouped | M | P | | V | Y | 1761 MIP-HA-to-MN-MSA 332 9.4 Grouped | M | P | | V | Y | 1762 MIP-Nonce 335 9.12 OctetString| M | P | | V | Y | 1763 MIP-Session-Key 343 9.7 OctetString| M | P | | V | Y | 1764 MIP-Algorithm- 345 9.8 Enumerated | M | P | | V | Y | 1765 Type 1766 MIP-Replay-Mode 346 9.9 Enumerated | M | P | | V | Y | 1767 MIP-MSA-Lifetime 367 9.13 Unsigned32 | M | P | | V | Y | 1768 MIP-AAA-SPI TBD 9.15 Unsigned32 | M | P | | V | Y | 1770 9.1. MIP-FA-to-MN-MSA AVP 1772 The MIP-FA-to-MN-MSA AVP (AVP Code 326) is of type Grouped and 1773 contains the FA-MN session key. This AVP is conveyed to the FA in an 1774 AMA message. The MN allocates the MIP-FA-to-MN-SPI. The FA creates 1775 an FA-MN authentication extension by using the session key and 1776 algorithm, and the MN verifies that extension by using the same 1777 session key and algorithm. The data field of this AVP has the 1778 following ABNF grammar: 1780 MIP-FA-to-MN-MSA ::= < AVP Header: 326 > 1781 { MIP-FA-to-MN-SPI } 1782 { MIP-Algorithm-Type } 1783 { MIP-Session-Key } 1784 * [ AVP ] 1786 9.2. MIP-FA-to-HA-MSA AVP 1788 The MIP-FA-to-HA-MSA AVP (AVP Code 328) is of type Grouped and 1789 contains the FA-HA session key. This AVP is conveyed to the FA in an 1790 AMA message. The HA allocates the MIP-FA-to-HA-SPI. The FA creates 1791 the FA-HA authentication extension by using the session key and 1792 algorithm, and the HA verifies that extension by using the same key 1793 and algorithm. The AVP's data field has the following ABNF grammar: 1795 MIP-FA-to-HA-MSA ::= < AVP Header: 328 > 1796 { MIP-FA-to-HA-SPI } 1797 { MIP-Algorithm-Type } 1798 { MIP-Session-Key } 1799 * [ AVP ] 1801 9.3. MIP-HA-to-FA-MSA AVP 1803 The MIP-HA-to-FA-MSA AVP (AVP Code 329) is of type Grouped and 1804 contains the Home Agent's session key, which it shares with the 1805 foreign agent. This AVP is conveyed to the HA in an HAR message. 1806 The FA allocates the MIP-HA-to-FA-SPI. The HA creates the HA-FA 1807 authentication extension by using the session key and algorithm, and 1808 the FA verifies that extension by using the same session key and 1809 algorithm. The AVP's data field has the following ABNF grammar: 1811 MIP-HA-to-FA-MSA ::= < AVP Header: 329 > 1812 { MIP-HA-to-FA-SPI } 1813 { MIP-Algorithm-Type } 1814 { MIP-Session-Key } 1815 * [ AVP ] 1817 9.4. MIP-HA-to-MN-MSA AVP 1819 The MIP-HA-to-MN-MSA AVP (AVP Code 332) is of type Grouped and 1820 contains the HA-MN session key. This AVP is conveyed to the HA in an 1821 HAR for FA COA Mobile IPv4 and in an AMA for collocated COA Mobile 1822 IPv4. The MN allocates the MIP-HA-to-MN-SPI. The HA creates the HA- 1823 MN authentication extension by using the session key and algorithm, 1824 and the MN verifies that extension by using the same key and 1825 algorithm. The AVP's field has the following ABNF grammar: 1827 MIP-HA-to-MN-MSA ::= < AVP Header: 332 > 1828 { MIP-Algorithm-Type } 1829 { MIP-Replay-Mode } 1830 { MIP-Session-Key } 1831 * [ AVP ] 1833 9.5. MIP-MN-to-FA-MSA AVP 1835 The MIP-MN-to-FA-MSA AVP (AVP Code 325) is of type Grouped and 1836 contains the MN-FA session nonce, which the mobile node uses to 1837 derive the MN-FA session key. This AVP is conveyed to the HA in an 1838 HAR message. The FA allocates the MIP-MN-to-FA-SPI. The MN creates 1839 the MN-FA session key by using the nonce and an algorithm indexed by 1840 the AAA SPI. 1842 The home agent uses this AVP in the construction of the Mobile IP 1843 "Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS]. 1845 MIP-MN-to-FA-MSA ::= < AVP Header: 325 > 1846 { MIP-MN-FA-SPI } 1847 { MIP-Algorithm-Type } 1848 { MIP-nonce } 1849 * [ AVP ] 1851 9.6. MIP-MN-to-HA-MSA AVP 1853 The MIP-MN-to-HA-MSA AVP (AVP Code 331) is of type Grouped and 1854 contains the MN-HA session nonce, which the mobile node uses to 1855 derive the MN-HA session key. This AVP is conveyed to the HA in an 1856 HAR message for FA COA Mobile IPv4 and in an AMA for collocated 1857 Mobile IPv4. The HA allocates the MIP-MN-to-HA-SPI. The MN creates 1858 the MN-HA session key using the nonce and an algorithm indexed by the 1859 AAA SPI. 1861 The Home Agent uses this AVP in the construction of the Mobile IP 1862 "Generalized MN-HA Key Generation Nonce Reply" extension [MIPKEYS]. 1864 MIP-MN-to-HA-MSA ::= < AVP Header: 331 > 1865 { MIP-Algorithm-Type } 1866 { MIP-Replay-Mode } 1867 { MIP-nonce } 1868 * [ AVP ] 1870 9.7. MIP-Session-Key AVP 1872 The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 1873 contains the Session Key for the associated Mobile IPv4 1874 authentication extension. The HAAA selects the session key. 1876 9.8. MIP-Algorithm-Type AVP 1878 The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated and 1879 contains the Algorithm identifier for the associated Mobile IPv4 1880 authentication extension. The HAAA selects the algorithm type. The 1881 following values are currently defined: 1883 2 HMAC-SHA-1 [HMAC] 1885 9.9. MIP-Replay-Mode AVP 1887 The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and 1888 contains the replay mode the Home Agent for authenticating the mobile 1889 node. The HAAA selects the replay mode. 1891 The following values are supported (see [MOBILEIP] for more 1892 information): 1894 1 None 1895 2 Timestamps 1896 3 Nonces 1898 9.10. MIP-FA-to-MN-SPI AVP 1900 The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32 and 1901 contains the Security Parameter Index that the FA and MN use to refer 1902 to the FA-MN mobility security association. The MN allocates the 1903 SPI, and it MUST NOT have a value between zero (0) and 255, which is 1904 the reserved namespace defined in [MOBILEIP]. 1906 9.11. MIP-FA-to-HA-SPI AVP 1908 The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32 and 1909 contains the Security Parameter Index the FA and HA use to refer to 1910 the FA-HA mobility security association. The HA allocates the SPI, 1911 and it MUST NOT have a value between zero (0) and 255, which is the 1912 reserved namespace defined in [MOBILEIP]. 1914 9.12. MIP-Nonce AVP 1916 The MIP-Nonce AVP (AVP Code 335) is of type OctetString and contains 1917 the nonce sent to the mobile node for the associated authentication 1918 extension. The mobile node follows the procedures in [MIPKEYS] to 1919 generate the session key used to authenticate Mobile IPv4 1920 registration messages. The HAAA selects the nonce. 1922 9.13. MIP-MSA-Lifetime AVP 1924 The MIP-MSA-Lifetime AVP (AVP Code 367) is of type Unsigned32 and 1925 represents the period of time (in seconds) for which the session key 1926 or nonce is valid. The associated session key or nonce, as the case 1927 may be, MUST NOT be used if the lifetime has expired; if the session 1928 key or nonce lifetime expires while the session to which it applies 1929 is still active, either the session key or nonce MUST be changed or 1930 the association Mobile IPv4 session MUST be terminated. 1932 9.14. MIP-HA-to-FA-SPI AVP 1934 The MIP-HA-to-FA-SPI AVP (AVP Code 323) is of type Unsigned32 and 1935 contains the Security Parameter Index the HA and FA use to refer to 1936 the HA-FA mobility security association. The FA allocates the SPI, 1937 and it MUST NOT have a value between zero (0) and 255, which is the 1938 reserved namespace defined in [MOBILEIP]. 1940 9.15. MIP-AAA-SPI AVP 1942 The MIP-AAA-SPI AVP (AVP Code TBD) is of type Unsigned32 and contains 1943 the Security Parameter Index the AAA and MN use to indicate the 1944 algorithm used to generate a Mobile IP Session Key from a Mobile IP 1945 Nonce. It appears in registration replies according to [MIPKEYS]. 1947 9.16. MIP-MN-to-FA-SPI AVP 1949 The MIP-MN-to-FA-SPI AVP (AVP Code TBD) is of type Unsigned32 and 1950 contains the Security Parameter Index the MN and FA use to refer to 1951 the MN-FA mobility security association. The FA allocates the SPI, 1952 and it MUST NOT have a value between zero (0) and 255, which is the 1953 reserved namespace defined in [MOBILEIP]. 1955 10. Accounting AVPs 1957 10.1. Accounting-Input-Octets AVP 1959 The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64, 1960 and contains the number of octets in IP packets received from the 1961 user. This AVP MUST be included in all Accounting-Request messages 1962 and MAY be present in the corresponding Accounting-Answer messages as 1963 well. 1965 10.2. Accounting-Output-Octets AVP 1967 The Accounting-Output-Octets AVP (AVP Code 364) is of type Unsigned64 1968 and contains the number of octets in IP packets sent to the user. 1969 This AVP MUST be included in all Accounting-Request messages and MAY 1970 be present in the corresponding Accounting-Answer messages as well. 1972 10.3. Acct-Session-Time AVP 1974 The Acct-Time AVP (AVP Code 46) is of type Unsigned32 and indicates 1975 the length of the current session in seconds. This AVP MUST be 1976 included in all Accounting-Request messages and MAY be present in the 1977 corresponding Accounting-Answer messages as well. 1979 10.4. Accounting-Input-Packets AVP 1981 The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64 and 1982 contains the number of IP packets received from the user. This AVP 1983 MUST be included in all Accounting-Request messages and MAY be 1984 present in the corresponding Accounting-Answer messages as well. 1986 10.5. Accounting-Output-Packets AVP 1988 The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64 1989 and contains the number of IP packets sent to the user. This AVP MUST 1990 be included in all Accounting-Request messages and MAY be present in 1991 the corresponding Accounting-Answer messages as well. 1993 10.6. Event-Timestamp AVP 1995 The Event-Timestamp (AVP Code 55) is of type Time and MAY be included 1996 in an Accounting-Request message to record the time at which this 1997 event occurred on the mobility agent, in seconds since January 1, 1998 1970, 00:00 UTC. 2000 11. AVP Occurrence Tables 2002 The following tables present the AVPs defined in this document and 2003 their occurrences in Diameter messages. Note that AVPs that can only 2004 be present within a Grouped AVP are not represented in this table. 2006 The table uses the following symbols: 2008 0 The AVP MUST NOT be present in the message. 2009 0+ Zero or more instances of the AVP MAY be present in the 2010 message. 2011 0-1 Zero or one instance of the AVP MAY be present in the 2012 message. 2013 1 One instance of the AVP MUST be present in the message. 2015 11.1. Mobile IP Command AVP Table 2017 The table in this section is limited to the Command Codes defined in 2018 this specification. 2020 +-----------------------+ 2021 | Command-Code | 2022 |-----+-----+-----+-----+ 2023 Attribute Name | AMR | AMA | HAR | HAA | 2024 ------------------------------|-----+-----+-----+-----+ 2025 Authorization-Lifetime | 0-1 | 0-1 | 1 | 0 | 2026 Auth-Application-Id | 1 | 1 | 1 | 1 | 2027 Auth-Session-State | 0-1 | 0-1 | 1 | 0 | 2028 Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 0-1 | 2029 Destination-Host | 0-1 | 0 | 0-1 | 0 | 2030 Destination-Realm | 1 | 0 | 1 | 0 | 2031 Error-Message | 0 | 0-1 | 0 | 0-1 | 2032 Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 | 2033 MIP-Candidate-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 | 2034 MIP-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 | 2035 MIP-Originating-Foreign-AAA | 0-1 | 0 | 0-1 | 0 | 2036 MIP-FA-Challenge | 0-1 | 0 | 0 | 0 | 2037 MIP-FA-to-MN-MSA | 0 | 0-1 | 0 | 0 | 2038 MIP-FA-to-HA-MSA | 0 | 0-1 | 0 | 0 | 2039 MIP-HA-to-FA-MSA | 0 | 0 | 0-1 | 0 | 2040 MIP-HA-to-MN-MSA | 0 | 0-1 | 0-1 | 0 | 2041 MIP-MN-to-FA-MSA | 0 | 0 | 0-1 | 0 | 2042 MIP-MN-to-HA-MSA | 0 | 0-1 | 0-1 | 0 | 2043 MIP-FA-to-HA-SPI | 0 | 0 | 0 | 0-1 | 2044 MIP-HA-to-FA-SPI | 0 | 0 | 0 | 0-1 | 2046 MIP-FA-to-MN-SPI | 0 | 0 | 0 | 0-1 | 2047 MIP-MN-to-FA-SPI | 0 | 0 | 0 | 0-1 | 2049 MIP-HA-to-MN-SPI | 0 | 0 | 0 | 0-1 | 2050 MIP-MN-to-HA-SPI | 0 | 0 | 0 | 0-1 | 2051 MIP-Feature-Vector | 0-1 | 0-1 | 1 | 0 | 2052 MIP-Filter-Rule | 0 | 0+ | 0+ | 0 | 2053 MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 | 2054 MIP-MSA-Lifetime | 0 | 0-1 | 0-1 | 0 | 2055 MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 | 2056 MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 | 2057 MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 | 2058 MIP-Reg-Request | 1 | 0 | 1 | 0 | 2059 Origin-Host | 1 | 1 | 1 | 1 | 2060 Origin-Realm | 1 | 1 | 1 | 1 | 2061 Origin-State-Id | 0-1 | 0-1 | 0-1 | 0-1 | 2062 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 2063 Redirect-Host | 0 | 0+ | 0 | 0+ | 2064 Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 | 2065 Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 | 2066 Result-Code | 0 | 1 | 0 | 1 | 2067 Re-Auth-Request-Type | 0 | 0-1 | 0 | 0 | 2068 Route-Record | 0+ | 0 | 0+ | 0 | 2069 Session-Id | 1 | 1 | 1 | 1 | 2070 User-Name | 1 | 0-1 | 1 | 0-1 | 2071 ------------------------------|-----+-----+-----+-----| 2073 11.2. Accounting AVP Table 2075 The table in this section is used to represent which AVPs defined in 2076 this document are to be present in the Accounting messages, as 2077 defined in [DIAMBASE]. 2079 +-------------+ 2080 | Command-Code| 2081 |------+------+ 2082 Attribute Name | ACR | ACA | 2083 -------------------------------------|------+------+ 2084 Accounting-Input-Octets | 1 | 0-1 | 2085 Accounting-Input-Packets | 1 | 0-1 | 2086 Accounting-Output-Octets | 1 | 0-1 | 2087 Accounting-Output-Packets | 1 | 0-1 | 2088 Acct-Multi-Session-Id | 1 | 0-1 | 2089 Acct-Session-Time | 1 | 0-1 | 2090 MIP-Feature-Vector | 1 | 0-1 | 2091 MIP-Home-Agent-Address | 1 | 0-1 | 2092 MIP-Mobile-Node-Address | 1 | 0-1 | 2093 Event-Timestamp | 0-1 | 0 | 2094 -------------------------------------|------+------+ 2096 12. IANA Considerations 2098 This section contains the namespaces that have either been created in 2099 this specification or had their values assigned to existing 2100 namespaces managed by IANA. 2102 12.1. Command Codes 2104 This specification assigns the values 260 and 262 from the Command 2105 Code namespace defined in [DIAMBASE]. See section 5 for the 2106 assignment of the namespace in this specification. 2108 12.2. AVP Codes 2110 This specification assigns the values 318 - 348 and 363 - 367 from 2111 the AVP Code namespace defined in [DIAMBASE]. See sections 7, 9, and 2112 10 for the assignment of the namespace in this specification. 2114 12.3. Result-Code AVP Values 2116 This specification assigns the values 4005 - 4008 and 5024 - 5025 2117 from the Result-Code AVP (AVP Code 268) value namespace defined in 2118 [DIAMBASE]. See section 6 for the assignment of the namespace in 2119 this specification. 2121 12.4. MIP-Feature-Vector AVP Values 2123 There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that 2124 are available for assignment. This document assigns bits 1-9, as 2125 listed in section 7.5. The remaining bits should only be assigned 2126 via Standards Action [IANA]. 2128 12.5. MIP-Algorithm-Type AVP Values 2130 As defined in section 9.8, the MIP-Algorithm-Type AVP (AVP Code 345) 2131 defines the value 2. All remaining values, except zero, are 2132 available for assignment via Designated Expert [IANA]. 2134 12.6. MIP-Replay-Mode AVP Values 2136 As defined in section 9.9, the MIP-Replay-Mode AVP (AVP Code 346) 2137 defines the values 1-3. All remaining values, except zero, are 2138 available for assignment via Designated Expert [IANA]. 2140 12.7. Application Identifier 2142 This specification uses the value two (2) in the Application 2143 Identifier namespace defined in [DIAMBASE]. See section 4 for more 2144 information. 2146 13. Security Considerations 2148 This specification describes a Mobile IPv4 Diameter Application for 2149 authenticating and authorizing a Mobile IPv4 mobile node. The 2150 authentication algorithm used is dependent on the transforms used 2151 within the Mobile IPv4 protocol, and [MIPCHAL]. This specification, 2152 in conjunction with [MIPKEYS], also defines a method by which the 2153 home Diameter server can create and distribute session keys and 2154 nonces for use in authenticating and integrity-protecting Mobile IPv4 2155 registration messages [MOBILEIP]. The key distribution is 2156 asymmetric, as communication with the mobile node occurs via the 2157 Mobile IPv4 protocol [MIPKEYS, MOBILEIP], where as communication to 2158 the Home Agent and Foreign Agent occurs via the Diameter protocol. 2159 Where untrusted Diameter agents are present, end-to-end security MUST 2160 be used. The end-to-end security takes the form of TLS or IPSec 2161 security associations between the AAAH and the FA and between the 2162 AAAH and the HA. These connections will be authenticated with the 2163 use of public keys and certificates; however, the identities that 2164 appear in the certificates must be authorized and bound to a 2165 particular Mobile IPv4 Diameter session before the AAAH can safely 2166 begin distribution of keys. 2168 Note that the direct connections are established as a result of 2169 Diameter redirect messages. For example, in Figure 3, the FA gets a 2170 redirect response containing the Redirect-Host AVP of the AAAH. This 2171 is the identity that should be matched against the certificate 2172 presented by the AAAH when the secure connection is established. In 2173 this case, the network of Diameter proxies and redirect agents is 2174 trusted with the task of returning the correct AAAH identity to the 2175 FA. 2177 The AAAH must also make an authorization decision when the FA 2178 establishes the connection. If the AAAH and the redirect server are 2179 one and the same, then the AAAH may have observed and noted the 2180 original AMR message that contained the identity of the FA and so may 2181 authorize the establishment of a TLS or IPSec connection from the 2182 same entity. Otherwise, the AAAH would need to maintain a list of 2183 all authorized visited domains (roaming partners) and authorize TLS 2184 or IPSec connections based on this list. Note that establishment of 2185 the connection is only the first step, and the AAAH has another 2186 opportunity to deny service upon receipt of the AMR message itself. 2187 At this step, the AAAH can check the internal AVPs of the AMR to 2188 ensure that the FA is valid; for example, it can check that the 2189 Mobile IP COA is equal to the IP address used as the endpoint of the 2190 TLS or IPSec connection. However, such a policy would prevent the FA 2191 from using different interfaces for AAA and Mobile IP tunnel packets 2192 and may not be desirable in every deployment situation. 2194 A similar set of considerations applies to the connection between 2195 AAAH and HA when those entities are in different administrative 2196 domains. However, here the roles are reversed because it is the AAAH 2197 that contacts the HA via the HAR. The identity of the candidate HA 2198 is given to the AAAH in the AMR, and the AAAH should expect to 2199 receive the same identity in the public key certificates during TLS 2200 or IPSec negotiation. The HA may authorize individual connections by 2201 acting as its own redirect server, or it may maintain a list of 2202 trusted roaming partners. 2204 This application creates and distributes a single session key for 2205 each pair of MSAs between two entities; e.g., the same session key is 2206 used for the MN-HA MSA and the HA-MN MSA. This is safe to do from a 2207 security perspective, as the session keys are only used with keyed 2208 hash functions to generate authenticator values that protect the 2209 integrity of each Mobile IP control message. Mobile IP messages have 2210 built-in replay protection with the use of timestamps or nonces 2211 [MOBILEIP], and, due to the nature of the protocol, requests are 2212 always different bitwise from responses, at least in the message type 2213 code. This avoids problems that might arise in other situations 2214 where an attacker could mount a replay or reflection attack if the 2215 same key were used (for example) to encrypt otherwise unprotected 2216 traffic on more than one connection leg in the network. 2218 Nonces are sent to the mobile node, which are used to generate the 2219 session keys via the HMAC-SHA-1 one-way function. Because the nonces 2220 and authentication extensions may be observed by anyone with access 2221 to a clear-text copy of the Registration Reply, the pre-shared key 2222 between the mobile node and the home Diameter server would be 2223 vulnerable to an offline dictionary attack if it did not contain 2224 enough entropy. To prevent this, the pre-shared key between the 2225 mobile node and the home Diameter server SHOULD be a randomly chosen 2226 quantity of at least 96 bits. 2228 Because the session key is determined by the long-term secret and the 2229 nonce, the nonce SHOULD be temporally and globally unique; if the 2230 nonce were to repeat, then so would the session key. To prevent 2231 this, a nonce is strongly recommended to be a random [RANDOM] value 2232 of at least 128 bits. The long-term secret between the MN and AAAH 2233 MUST be refreshed periodically, to guard against recovery of the 2234 long-term secret due to nonce reuse or other factors. This is 2235 accomplished by using out-of-band mechanisms, which are not specified 2236 in this document. 2238 Note that it is not recommended to set the MIP-MSA-Lifetime AVP value 2239 to zero, as keeping session keys for a long time (no refresh) 2240 increases the level of vulnerability. 2242 14. References 2244 14.1. Normative References 2246 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2247 Specifications: ABNF", RFC 2234, November 1997. 2249 [DIAMBASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and 2250 J. Arkko, "Diameter Base Protocol", RFC 3588, 2251 September 2003. 2253 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing 2254 an IANA Considerations Section in RFCs", BCP 26, RFC 2255 2434, October 1998. 2257 [MOBILEIP] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 2258 August 2002. 2260 [MIPCHAL] Perkins, C. and P. Calhoun, "Mobile IPv4 2261 Challenge/Response Extensions", RFC 3012, November 2262 2000. 2264 [NAI] Aboba, B. and M. Beadles, "The Network Access 2265 Identifier", RFC 2486, January 1999. 2267 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: 2268 Keyed-Hashing for Message Authentication", RFC 2104, 2269 February 1997. 2271 [MIPKEYS] Perkins, C. and P. Calhoun, "Authentication, 2272 Authorization, and Accounting (AAA) Registration Keys 2273 for Mobile IP", RFC 3957, March 2005. 2275 [AAANAI] Johansson, F. and T. Johansson, "Mobile IPv4 Extension 2276 for Carrying Network Access Identifiers", RFC 3846, 2277 June 2004. 2279 [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for 2280 the Internet Protocol", RFC 2401, November 1998. 2282 [TLS] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, 2283 J., and T. Wright, "Transport Layer Security (TLS) 2284 Extensions", RFC 3546, June 2003. 2286 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 2287 Requirement Levels", BCP 14, RFC 2119, March 1997. 2289 14.2. Informative References 2291 [MIPREQ] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, 2292 "Mobile IP Authentication, Authorization, and 2293 Accounting Requirements", RFC 2977, October 2000. 2295 [CDMA2000] Hiller, T., Walsh, P., Chen, X., Munson, M., Dommety, 2296 G., Sivalingham, S., Lim, B., McCann, P., Shiino, H., 2297 Hirschman, B., Manning, S., Hsu, R., Koo, H., Lipford, 2298 M., Calhoun, P., Lo, C., Jaques, E., Campbell, E., Xu, 2299 Y., Baba, S., Ayaki, T., Seki, T., and A. Hameed, 2300 "CDMA2000 Wireless Data Requirements for AAA", RFC 2301 3141, June 2001. 2303 [EVALROAM] Aboba, B. and G. Zorn, "Criteria for Evaluating 2304 Roaming Protocols", RFC 2477, January 1999. 2306 [MIPNAI] Calhoun, P. and C. Perkins, "Mobile IP Network Access 2307 Identifier Extension for IPv4", RFC 2794, March 2000. 2309 [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, 2310 "Randomness Requirements for Security", BCP 106, RFC 2311 4086, June 2005. 2313 15. Acknowledgements 2315 The authors would like to thank Nenad Trifunovic, Haseeb Akhtar, and 2316 Pankaj Patel for their participation in the pre-IETF Document Reading 2317 Party; Erik Guttman for his very useful proposed text; and Fredrik 2318 Johansson, Martin Julien, and Bob Kopacz for their very useful 2319 contributed text. 2321 The authors would also like to thank the participants of 3GPP2's 2322 TSG-X working group for their valuable feedback, and the following 2323 people for their contribution in the development of the protocol: 2324 Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael 2325 Chen, Henry Haverinen, and Johan Johansson. General redirect server 2326 text due to Pasi Eronen was borrowed from Diameter-EAP. 2328 Pat Calhoun would like to thank Sun Microsystems, as most of the 2329 effort put into this document was done while he was in their employ. 2331 Authors' Addresses 2333 Questions about this memo can be directed to: 2335 Pat Calhoun 2336 Cisco Systems, Inc. 2337 170 West Tasman Drive 2338 San Jose, CA 95134 2339 USA 2341 Phone: +1 408-853-5269 2342 EMail: pcalhoun@cisco.com 2344 Tony Johansson 2345 Bytemobile, Inc. 2346 2029 Stierlin Court 2347 Mountain View, CA 94043 2349 Phone: +1 650-641-7817 2350 Fax: +1 650-641-7701 2351 EMail: tony.johansson@bytemobile.com 2353 Charles E. Perkins 2354 Nokia Siemens Networks 2355 323 Fairchild Dr. 2356 Mountain View, CA 94043 2357 USA 2359 Email: charles.perkins@nsn.com 2360 Tom Hiller 2361 Alcatel-Lucent 2362 1960 Lucent Lane 2363 Naperville, IL 60566 2364 USA 2366 Phone: +1 630-979-7673 2367 EMail: tomhiller@alcatel-lucent.com 2369 Peter J. McCann 2370 Motorola 2371 MD 2240 2372 1301 E. Algonquin Rd 2373 Schaumburg, IL 60196 2374 USA 2376 Phone: +1 847-576-3440 2377 EMail: pete.mccann@motorola.com 2378 Full Copyright Statement 2380 Copyright (C) The IETF Trust (2007). 2382 This document is subject to the rights, licenses and restrictions 2383 contained in BCP 78, and except as set forth therein, the authors 2384 retain all their rights. 2386 This document and the information contained herein are provided on an 2387 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2388 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2389 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2390 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2391 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2392 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2394 Intellectual Property 2396 The IETF takes no position regarding the validity or scope of any 2397 Intellectual Property Rights or other rights that might be claimed to 2398 pertain to the implementation or use of the technology described in 2399 this document or the extent to which any license under such rights 2400 might or might not be available; nor does it represent that it has 2401 made any independent effort to identify any such rights. Information 2402 on the procedures with respect to rights in RFC documents can be 2403 found in BCP 78 and BCP 79. 2405 Copies of IPR disclosures made to the IETF Secretariat and any 2406 assurances of licenses to be made available, or the result of an 2407 attempt made to obtain a general license or permission for the use of 2408 such proprietary rights by implementers or users of this 2409 specification can be obtained from the IETF on-line IPR repository at 2410 http://www.ietf.org/ipr. 2412 The IETF invites any interested party to bring to its attention any 2413 copyrights, patents or patent applications, or other proprietary 2414 rights that may cover technology that may be required to implement 2415 this standard. Please address the information to the IETF at 2416 ietf-ipr@ietf.org. 2418 Acknowledgement 2420 Funding for the RFC Editor function is provided by the IETF 2421 Administrative Support Activity (IASA).