idnits 2.17.1 draft-ietf-aaa-diameter-mobileip-20.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 3667, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2489. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2004) is 7193 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: 'MIPKEY' is mentioned on line 266, but not defined == Missing Reference: 'RFC2607' is mentioned on line 254, but not defined == Missing Reference: 'AAAKEY' is mentioned on line 2222, but not defined == Unused Reference: 'NAI' is defined on line 2330, but no explicit reference was found in the text ** 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 2486 (ref. 'NAI') (Obsoleted by RFC 4282) -- Possible downref: Non-RFC (?) normative reference: ref. 'HMAC' -- No information found for draft-ietf-mipv4-aaa-key - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MIPKEYS' -- No information found for draft-mip4-aaa-nai - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AAANAI' ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 3546 (ref. 'TLS') (Obsoleted by RFC 4366) -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group Pat R. Calhoun 3 Internet Draft Airespace 4 draft-ietf-aaa-diameter-mobileip-20.txt Tony Johansson 5 Bytemobile Inc 6 Charles E. Perkins 7 Nokia Research Center 8 Tom Hiller (editor) 9 Peter J. McCann 10 Lucent Technologies 11 August 2004 13 Diameter Mobile IPv4 Application 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 and any of which I become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document specifies a Diameter application that allows a Diameter 41 server to authenticate, authorize and collect accounting information 42 for Mobile IPv4 services rendered to a mobile node. Combined with 43 the Inter-Realm capability of the base protocol, this application 44 allows mobile nodes to receive service from foreign service 45 providers. Diameter Accounting messages will be used by the foreign 46 and home agents to transfer usage information to the Diameter 47 servers. 49 Diameter MIP August 2004 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 57 Table of Contents 59 1. Introduction.....................................................3 60 1.1. Entities and Relationships...................................4 61 1.2. Mobility Security Associations...............................4 62 1.3. Handoff......................................................6 63 1.4. Structure of the Document....................................6 64 2. Acronyms.........................................................7 65 3. Scenarios and Message Flows......................................7 66 3.1. Inter-Realm Mobile IPv4......................................7 67 3.2. Allocation of Home Agent in Foreign Network.................13 68 3.3. Co-located Mobile Node......................................16 69 3.4. Key Distribution............................................18 70 4. Diameter Protocol Considerations................................20 71 4.1. Diameter Session Management.................................20 72 5. Command-Code Values.............................................23 73 5.1. AA-Mobile-Node-Request......................................23 74 5.2. AA-Mobile-Node-Answer.......................................24 75 5.3. Home-Agent-MIP-Request......................................25 76 5.4. Home-Agent-MIP-Answer.......................................26 77 6. Result-Code AVP Values..........................................27 78 6.1. Transient Failures..........................................27 79 6.2. Permanent Failures..........................................28 80 7. Mandatory AVPs..................................................28 81 7.1. MIP-Reg-Request AVP.........................................29 82 7.2. MIP-Reg-Reply AVP...........................................29 83 7.3. MIP-Mobile-Node-Address AVP.................................29 84 7.4. MIP-Home-Agent-Address AVP..................................30 85 7.5. MIP-Feature-Vector AVP......................................30 86 7.6. MIP-MN-AAA-Auth AVP.........................................31 87 7.7. MIP-FA-Challenge AVP........................................32 88 7.8. MIP-Filter-Rule AVP.........................................32 89 7.9. MIP-Candidate-Home-Agent-Host...............................33 90 7.10. MIP-Originating-Foreign-AAA AVP............................33 91 7.11. MIP-Home-Agent-Host AVP....................................33 92 8. Key Distribution................................................33 93 8.1. Authorization Lifetime vs. MIP Key Lifetime.................34 94 8.2. Nonce vs. Session Key.......................................34 95 8.3. Distributing the Mobile-Home Session Key....................35 96 8.4. Distributing the Mobile-Foreign Session Key.................36 97 8.5. Distributing the Foreign-Home Session Key...................36 98 9. Key Distribution AVPs...........................................37 99 9.1. MIP-FA-to-MN-MSA AVP........................................38 100 9.2. MIP-FA-to-HA-MSA AVP........................................39 101 9.3. MIP-HA-to-FA-MSA AVP........................................39 102 9.4. MIP-HA-to-MN-MSA AVP........................................39 103 Diameter MIP August 2004 105 9.5. MIP-MN-to-FA-MSA AVP........................................40 106 9.6. MIP-MN-to-HA-MSA AVP........................................40 107 9.7. MIP-Session-Key AVP.........................................40 108 9.8. MIP-Algorithm-Type AVP......................................41 109 9.9. MIP-Replay-Mode AVP.........................................41 110 9.10. MIP-FA-to-MN-SPI AVP.......................................41 111 9.11. MIP-FA-to-HA-SPI AVP.......................................41 112 9.12. MIP-Nonce AVP..............................................41 113 9.13. MIP-MSA-Lifetime AVP.......................................42 114 9.14. MIP-HA-to-FA-SPI AVP.......................................42 115 10. Accounting AVPs................................................42 116 10.1. Accounting-Input-Octets AVP................................42 117 10.2. Accounting-Output-Octets AVP...............................42 118 10.3. Acct-Session-Time AVP......................................42 119 10.4. Accounting-Input-Packets AVP...............................43 120 10.5. Accounting-Output-Packets AVP..............................43 121 10.6. Event-Timestamp AVP........................................43 122 11. AVP Occurrence Tables..........................................43 123 11.1. Mobile IP Command AVP Table................................44 124 11.2. Accounting AVP Table.......................................45 125 12. IANA Considerations............................................45 126 12.1. Command Codes..............................................45 127 12.2. AVP Codes..................................................45 128 12.3. Result-Code AVP Values.....................................46 129 12.4. MIP-Feature-Vector AVP Values..............................46 130 12.5. MIP-Algorithm-Type AVP Values..............................46 131 12.6. MIP-Replay-Mode AVP Values.................................46 132 12.7. Application Identifier.....................................46 133 13. Security Considerations........................................46 134 14. References.....................................................48 135 14.1. Normative..................................................48 136 14.2. Informative................................................49 137 15. Acknowledgements...............................................49 138 16. Authors' Addresses.............................................50 140 1. Introduction 142 Mobile IPv4 [MOBILEIP] allows a Mobile Node (MN) to change its point 143 of attachment to the Internet while maintaining its fixed home 144 address. Packets directed to the home address are intercepted by a 145 Home Agent (HA), encapsulated in a tunnel, and forwarded to the MN at 146 its current point of attachment. Optionally, a Foreign Agent (FA) 147 may be deployed at this point of attachment, which can serve as the 148 tunnel endpoint and may also provide access control for the visited 149 network link. In this role, the FA needs to authenticate each MN 150 that may attach to it, whether the MN is from the same or a different 151 administrative domain. The FA needs to verify that the MN is 152 authorized to attach and use resources in the foreign domain. Also, 153 the FA must provide information to the home administrative domain 154 about the resources used by the MN while it is attached in the 155 foreign domain. 157 Diameter MIP August 2004 159 The Authentication, Authorization, and Accounting requirements for 160 Mobile IPv4 are described in detail in other documents [MIPREQ, 161 CDMA2000]. This document specifies a Diameter application to meet 162 these requirements. This application is not applicable to the Mobile 163 IPv6 protocol. 165 1.1. Entities and Relationships 167 The Diameter Mobile IPv4 Application supports the HA and FA in 168 providing Mobile IPv4 service to MNs. Both the HA and FA act as 169 Diameter clients. The MNs interact with the HA and FA using only 170 Mobile IPv4, and therefore do not implement Diameter. 172 The FA, when present, is always assumed to exist in the visited 173 administrative domain. The HA may be statically or dynamically 174 allocated to the MN in the home administrative domain, or may be 175 dynamically allocated to the MN in a visited administrative domain. 176 The home domain contains a home AAA server (AAAH) and the visited 177 domain contains a foreign AAA server (AAAF). When the MN is "at 178 home" (present on its home network), the AAAH and AAAF may be the 179 same. 181 1.2. Mobility Security Associations 183 The base Mobile IPv4 protocol [MOBILEIP] assumes the existence of a 184 Mobility Security Association (MSA) between the MN and HA (MN-HA 185 MSA). The MN-HA MSA is used to authenticate, using a keyed hash 186 style algorithm, the Mobile IP Registration Request that is sent from 187 the MN to the HA. It is important to authenticate Registration 188 Requests because they serve to inform the HA about the MN's current 189 Care-of-Address, which is the destination for tunneled packets from 190 the home network. Without authentication, malicious attackers would 191 be able to redirect packets to anywhere on the Internet. The MSA 192 comprises an agreement on a Security Parameters Index (SPI, a 32-bit 193 number) that will be used to refer to the MSA, an algorithm that will 194 be used to compute keyed hashes over messages, and a shared secret 195 key. To enable authentication of a message, the sender appends a 196 Mobile IP Authentication Extension that contains the SPI and the 197 result of running the keyed hash over the entire previous contents of 198 the message. The recipient checks the Authentication Extension by 199 looking up the MSA based on the SPI, re-computing the keyed hash, and 200 verifying that the result is equal to the contents of the received 201 Authentication Extension. 203 The base Mobile IPv4 protocol also supports an optional MSA between 204 the MN and FA (MN-FA MSA). If available, the MN-FA MSA is used by 205 the FA to authenticate each Registration Request passing through it 206 on the way to the HA. While not critical to the operation of the 207 base protocol, the MN-FA MSA is useful when the FA needs to know the 208 Diameter MIP August 2004 210 authenticity of a Registration Request, e.g., when it will be 211 generating accounting records for a session. The MN-FA MSA may also 212 be useful in future work related to handoff optimization. 214 Similarly, Mobile IPv4 supports an optional MSA between the FA and HA 215 (FA-HA MSA). The FA-HA MSA is useful for authenticating messages 216 between the FA and HA, such as when the HA wants to inform the FA 217 that it has revoked a Mobile IP registration. 219 Note that configuration of MSAs that involve FAs is substantially 220 more difficult than configuring the one between the MN and HA, 221 because the MN and HA are often in the same administrative domain and 222 the MN will retain the same HA for long periods of time. In 223 contrast, the MN is likely to encounter many FAs over time and may 224 often find itself in foreign administrative domains. 226 The base Mobile IPv4 protocol assumes that MNs are identified by 227 their static home IP addresses, and assumes that all MSAs are 228 statically preconfigured. The Diameter Mobile IPv4 application, 229 together with extensions [MIPNAI, MIPCHAL, MIPKEY, AAANAI] to the 230 base Mobile IPv4 protocol, allows an MN to be dynamically assigned a 231 home address and/or home agent when it attaches to the Internet. 232 This set of specifications also supports the dynamic configuration of 233 the MN-HA, MN-FA, and FA-HA MSAs. The dynamic configuration of these 234 relationships is important to support deployments where the MN can 235 attach to a visited network without having a pre-established 236 relationship with it. 238 Initially, the MN is assumed to have a long-term AAA security 239 association only with the AAAH. This security association is indexed 240 by the MN's NAI, and, like the MSAs, comprises an agreement on a SPI, 241 algorithm, and shared secret key. The MN enters a visited network 242 and requests service from some FA by sending a Mobile IPv4 243 Registration Request. The FA contacts a AAAF in its own 244 administrative domain to authenticate and authorize the request for 245 service. The AAAF and AAAH may establish a Diameter session directly 246 with each other, such as via a Diameter Redirect, or may pass 247 messages via a network of Diameter proxies. Where the AAAF and AAAH 248 route messages to each other through proxies, rather than a direct 249 connection, transitive trust is assumed. MNs can include their 250 Network Access Identifier (NAI) in a Mobile IPv4 Registration Request 251 [MIPNAI], which serves in place of the home address to identify the 252 MN. The NAI is used to route Diameter messages towards the correct 253 AAAH. This use of the NAI is consistent with the roaming model 254 defined by the ROAMOPS Working Group [EVALROAM, RFC2607]. 256 The AAAH can authenticate the Registration Request with the use of 257 the MN-AAA security association [MIPCHAL]. If authentication is 258 successful, the AAAH then generates and distributes MSAs to the MN, 259 HA, and FA. For each of the MSA pairs that involve the MN (i.e., MN- 260 HA/HA-MN MSAs and MN-FA/FA-MN MSAs), the AAAH generates a nonce and 261 then hashes that together with the MN-AAA shared key to derive the 262 session key for the MSA pair. The nonces are sent to the HA which 263 Diameter MIP August 2004 265 includes them in the Registration Reply, which enables the MN to 266 derive the same keys [MIPKEY]. At the same time, the AAAH must 267 distribute the MN-HA/HA-MN MSAs and the FA-HA/HA-FA MSAs to the HA 268 and must distribute the MN-FA/FA-MN MSAs and the FA-HA/HA-FA MSAs to 269 the FA. These are sent in Diameter AVPs and must be independently 270 secured using IPSec or TLS between the AAAH and the FA and between 271 the AAAH and the HA. See Section 8 for more information on key 272 derivation and distribution. 274 Note that MSAs in Mobile IP are unidirectional in that, e.g., the MN- 275 HA MSA (used to protect traffic from the MN to the HA) and the HA-MN 276 MSA (used to protect traffic from the HA to the MN) can use different 277 SPIs, algorithms, and shared secrets. This is true of the base 278 Mobile IP protocol despite common existing practice during manual 279 configuration of MSAs in which all parameters are set to the same 280 value in both directions. This document supports the use of 281 different SPIs in each direction; however, it only supports the 282 distribution of a single session key for each pair of MSAs between 283 two nodes. The security implications of this fact are discussed in 284 Section 13. This document sometimes names only one of the two 285 unidirectional MSAs when referring to the distribution of the single 286 shared secret and pair of SPIs for the pair of MSAs between two 287 entities. 289 1.3. Handoff 291 In addition to supporting the derivation and transport of the MN-HA, 292 MN-FA and FA-HA MSAs, this application also supports MIPv4 handoff. 293 When an MN moves from one point of attachment to another, the MN can 294 continue the same Mobile IPv4 session using its existing HA and home 295 address. 297 The MN accomplishes this by sending a Mobile IPv4 Registration 298 Request from its new point of attachment. To enable a single set of 299 accounting records to be maintained for the entire session, including 300 handoffs, it is necessary to allow the AAAH to bind the new 301 registration to the pre-existing session. To enable the Mobile IPv4 302 Registration Request to be routed to the same AAAH, the MN SHOULD 303 include the AAAH NAI [AAANAI] in such re-registrations. Also, to 304 assist the AAAH in routing the messages to the MN's existing HA the 305 mobile node SHOULD include the HA NAI [AAANAI] in such re- 306 registrations. If the mobile node does not support the Mobile IPv4 307 AAA NAI extension [AAANAI], this functionality is not available. 309 1.4. Structure of the Document 311 The remainder of this document is structured as follows. Section 2 312 provides acronym definitions. Section 3 provides some examples and 313 message flows illustrating both the Mobile IPv4 and Diameter messages 314 that occur when a mobile node attaches to the Internet. Section 4 315 Diameter MIP August 2004 317 defines the relationship of this application to the Diameter Base 318 Protocol. Section 5 defines the new command codes used by this 319 application. Section 6 defines the new result codes used by this 320 application. Section 7 defines the set of mandatory Attribute-Value- 321 Pairs (AVPs) used by this application. Section 8 gives an overview 322 of the key distribution capability, and Section 9 defines the key 323 distribution AVPs used by this application. Section 10 defines the 324 accounting AVPs, and Section 11 contains a listing of all AVPs and 325 their occurrence in Diameter commands. Finally, Sections 12 and 13 326 give IANA and Security considerations, respectively. 328 2. Acronyms 330 AAAH Authentication, Authorization, and Accounting Home 331 AAAF Authentication, Authorization, and Accounting Foreign 332 AMA AA-Mobile-Node-Answer 333 AMR AA-Mobile-Node-Request 334 ASR Abort-Session-Request 335 AVP Attribute Value Pair 336 CoA Care-of-Address 337 FA Foreign Agent 338 FQDN Fully Qualified Domain Name 339 HA Home Agent 340 HAA Home-Agent-MIP-Answer 341 HAR Home-Agent-MIP-Request 342 MN Mobile Node 343 MSA Mobility Security Association 344 NAI Network Authentication Identity 345 RRQ Registration Request 346 SPI Security Parameters Index 347 STR Session-Termination-Request 349 3. Scenarios and Message Flows 351 This section presents four scenarios illustrating Diameter Mobile 352 IPv4 application, and describes the operation of key distribution. 354 In this document, the role of the "attendant" [MIPREQ] is performed 355 by either the FA (when present in a visited network) or the HA (for 356 co-located mobile nodes not registering via an FA), and these terms 357 will be used interchangeably in the following scenarios. 359 3.1. Inter-Realm Mobile IPv4 361 When a mobile node requests service by issuing a Registration Request 362 to the foreign agent, the foreign agent creates the AA-Mobile-Node- 363 Request (AMR) message, which includes the AVPs defined in section 7. 364 The Home Address, Home Agent, Mobile Node NAI and other important 365 fields are extracted from the registration messages for possible 366 Diameter MIP August 2004 368 inclusion as Diameter AVPs. The AMR message is then forwarded to the 369 local Diameter server, known as the AAA-Foreign, or AAAF. 371 Visited Realm Home Realm 372 +-----------+ +-----------+ 373 |example.net| AMR/AMA |example.org| 374 | AAAF |<------------------->| AAAH | 375 +->| server | server-server | server | 376 | +-----------+ communication +-----------+ 377 | ^ ^ 378 | AMR/AMA | client-server | HAR/HAA 379 | | communication | 380 v v v 381 +---------+ +---------+ +---------+ 382 | Foreign | | Foreign | | Home | 383 | Agent | | Agent | | Agent | 384 +---------+ +---------+ +---------+ 385 ^ 386 | Mobile IP 387 | 388 v 389 +--------+ 390 | Mobile | 391 | Node | mn@example.org 392 +--------+ 394 Figure 1: Inter-Realm Mobility 396 Upon receiving the AMR, the AAAF follows the procedures outlined in 397 [DIAMBASE] to determine whether the AMR should be processed locally, 398 or if it should be forwarded to another Diameter server, known as the 399 AAA-Home, or AAAH. Figure 1 shows an example in which a mobile node 400 (mn@example.org) requests service from a foreign provider 401 (example.net). The request received by the AAAF is forwarded to 402 example.org's AAAH server. 404 Figure 2 shows the message flows involved when the foreign agent 405 invokes the AAA infrastructure to request that a mobile node be 406 authenticated and authorized. Note that it is not required that the 407 foreign agent invoke AAA services every time a Registration Request 408 is received from the mobile, but rather only when the prior 409 authorization from the AAAH expires. The expiration time of the 410 authorization is communicated through the Authorization-Lifetime AVP 411 in the AA-Mobile-Node-Answer (AMA, see section 5.2) from the AAAH. 413 Diameter MIP August 2004 415 Mobile Node Foreign Agent AAAF AAAH Home 416 Agent 417 ----------- ------------- ------------ ---------- ------- 418 Advertisement & 419 <--------- Challenge 421 Reg-Req&MN-AAA ----> 423 AMR------------> 424 Session-Id = foo 426 AMR------------> 427 Session-Id = foo 429 HAR-----------> 430 Session-Id = bar 432 <----------HAA 433 Session-Id = bar 435 <-----------AMA 436 Session-Id = foo 438 <------------AMA 439 Session-Id = foo 441 <-------Reg-Reply 443 Figure 2: Mobile IPv4/Diameter Message Exchange 445 The foreign agent (as shown in Figure 2) MAY provide a challenge, 446 which gives it direct control over the replay protection in the 447 Mobile IPv4 registration process, as described in [MIPCHAL]. The 448 mobile node includes the Challenge and MN-AAA authentication 449 extension to enable authorization by the AAAH. If the authentication 450 data supplied in the MN-AAA extension is invalid, the AAAH returns 451 the response (AMA) with the Result-Code AVP set to 452 DIAMETER_AUTHENTICATION_REJECTED. 454 The above scenario causes the MN-FA and MN-HA keys to be exposed to 455 Diameter agents all along the Diameter route. If this is a concern, 456 a more secure approach is to eliminate the AAAF and other Diameter 457 agents as in Figure 3: 459 Diameter MIP August 2004 461 Redirect 462 FA AAAF Agent AAAH 463 AMR 464 ----------------> 465 AMR 466 ----------------> 467 AMA (Redirect) 468 <---------------- 469 AMA (Redirect) 470 <---------------- 472 Setup Security Association 473 <--------------------------------------------------> 475 AMR 476 --------------------------------------------------> 477 AMA (MN-FA key) 478 <--------------------------------------------------- 480 Figure 3: Use of a Redirect Server with AMR/AMA 482 In Figure 3, the FA sets up a TLS [TLS] or IPSec [IPSEC] based 483 security association with the AAAH directly and runs the AMR/AMA 484 exchange over it. This provides end-to-end security for secret keys 485 that may need to be distributed. 487 Figure 4 shows the interaction between the AAAH and HA with the help 488 of a redirect agent. When the AAAH and HA are in the same network, 489 it is likely that the AAAH knows the IP address of the HA, so the 490 redirect server would therefore not be needed; however, it is shown 491 anyway for completeness. The redirect server will most likely be 492 used in the case where the HA is allocated in a foreign network (see 493 Section 3.2 for more details of HA allocation in foreign networks). 495 Diameter MIP August 2004 497 Redirect 498 HA Agent AAAH 499 HAR 500 <-------------------- 501 HAA (Redirect) 502 --------------------> 503 Setup Security Association 504 <----------------------------------------> 505 HAR (MN-HA key) 506 <----------------------------------------- 507 HAA 508 -----------------------------------------> 510 Figure 4: Use of a Redirect Server with HAR/HAA 512 As in Figure 2, the FA of Figure 3 would still provide the challenge 513 and the mobile sends the RRQ, etc.; however, these were eliminated 514 from Figure 3 to reduce clutter. The redirect server eliminates the 515 AAAF and any other Diameter agents from seeing the keys as they are 516 transported to the FA and HA. Note that the message flows in Figure 517 3 and Figure 4 apply only to the initial authentication and key 518 exchange. Accounting messages would still be sent via Diameter 519 agents, not the direct connection, unless network policies dictate 520 otherwise. 522 A mobile node that supports the AAA NAI extension [AAANAI], which has 523 been previously authenticated and authorized, MUST always include the 524 assigned home agent in the HA Identity subtype of the AAA NAI 525 extension, and the authorizing Home AAA server in the AAAH Identity 526 subtype of the AAA NAI extension, when re-authenticating. So, in the 527 event that the AMR generated by the FA is for a session that was 528 previously authorized, it MUST include the Destination-Host AVP, with 529 the identity of the AAAH found in the AAAH-NAI, and the MIP-Home- 530 Agent-Host AVP with the identity and realm of the assigned HA found 531 in the HA-NAI. If on the other hand the mobile node does not support 532 the AAA NAI extension, the FA may not have the identity of the AAAH 533 and the identity and realm of the assigned HA. This means that 534 without support of the AAA NAI extension, the FA may not be able to 535 guarantee that the AMR will be destined to the same AAAH, which 536 previously authenticated and authorized the mobile node, since the FA 537 may not know the identity of the AAAH. 539 If the mobile node was successfully authenticated, the AAAH then 540 determines which Home Agent to use for the session. First, the AAAH 541 checks if an HA has been requested by the MN, by checking the MIP- 542 Home-Agent-Address AVP and the MIP-Home-Agent-Host AVP. The 543 administrative domain owning the HA may be determined from the realm 544 portion of the MIP-Home-Agent-Host AVP, or by checking the Home- 545 Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP and the 546 value of the MIP-Originating-Foreign-AAA AVP. If the requested HA 547 belongs to a permitted administrative domain, the AAAH SHOULD use the 548 Diameter MIP August 2004 550 given HA for the session. Otherwise, the AAAH returns the response 551 (AMA) with the Result-Code AVP set to either 552 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE or 553 DIAMETER_ERROR_HA_NOT_AVAILABLE. 555 If the MN has not requested any particular HA, then an HA MUST be 556 dynamically allocated. In this case the MIP-Feature-Vector will have 557 the Home-Agent-Requested flag set. If the Home-Address-Allocatable- 558 Only-in-Home-Realm flag is not set, and if the Foreign-Home-Agent- 559 Available flag is set, then the AAAH SHOULD allow the foreign realm 560 to allocate the HA (see Section 3.2) but MAY allocate one itself in 561 the home realm if dictated by local policy. If the Home-Address- 562 Allocatable-Only-in-Home-Realm flag is set, then the AAAH MUST 563 allocate an HA in the home realm on behalf of the MN. Allocation of 564 the HA can be done in a variety of ways, including using a load- 565 balancing algorithm in order to keep the load on all home agents 566 equal. The actual algorithm used and the method of discovering the 567 home agents is outside the scope of this specification. 569 The AAAH then sends a Home-Agent-MIP-Request (HAR), which contains 570 the Mobile IPv4 Registration Request message data encapsulated in the 571 MIP-Reg-Request AVP, to the assigned or requested Home Agent. Refer 572 to Figure 4 if the HA does not have a direct path to the HA. The 573 AAAH MAY allocate a home address for the mobile node, while the Home 574 Agent MUST support home address allocation. In the event the AAAH 575 handles address allocation, it includes it in a MIP-Mobile-Node- 576 Address AVP within the HAR. The absence of this AVP informs the Home 577 Agent to perform the home address allocation. 579 Upon receipt of the HAR, the home agent first processes the Diameter 580 message. The home agent processes the MIP-Reg-Request AVP and 581 creates the Registration Reply, encapsulating it within the MIP-Reg- 582 Reply AVP. In the creation of the Registration Reply the Home Agent 583 MUST include the HA NAI and the AAAH NAI, which will be created from 584 the Origin-Host AVP and Origin-Realm AVP of the HAR. If a home 585 address is needed, the home agent MUST also assign one, as well as 586 include the address in both the Registration Reply and the MIP- 587 Mobile-Node-Address AVP. 589 Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer 590 (AMA) message, includes the Acct-Multi-Session-Id that was present in 591 the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node-Address AVPs 592 in the AMA message. See Figure 3 and Figure 4 for the use of the 593 redirect agent for the secure transport of the HAA and AMA messages. 595 See Section 4.1 for information on the management of sessions and 596 session identifiers by the Diameter Mobile IPv4 entities. 598 Diameter MIP August 2004 600 3.2. Allocation of Home Agent in Foreign Network 602 The Diameter Mobile IPv4 application allows a home agent to be 603 allocated in a foreign network, as required in [MIPREQ, CDMA2000]. 604 When a foreign agent detects that the mobile node has a home agent 605 address equal to 0.0.0.0 or 255.255.255.255 in the Registration 606 Request message, it MUST add a MIP-Feature-Vector AVP with the Home- 607 Agent-Requested flag set to one. If the home agent address is set to 608 255.255.255.255, the foreign agent MUST set the Home-Address- 609 Allocatable-Only-in-Home-Realm flag equal to one. If the home agent 610 address is set to 0.0.0.0, the foreign agent MUST set the Home- 611 Address-Allocatable-Only-in-Home-Realm flag equal to zero. 613 When the AAAF receives an AMR message with the Home-Agent-Requested 614 flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm 615 flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available 616 flag in the MIP-Feature-Vector AVP to inform the AAAH that it is 617 willing and able to assign a Home Agent for the mobile node. When 618 doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP 619 and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home- 620 Agent-Host AVP contains the identity (i.e., a DiameterIdentity, which 621 is an FQDN) of the home agent that would be assigned to the mobile 622 node and the MIP-Originating-Foreign-AAA AVP contains the identity of 623 the AAAF. The AAAF now sends the AMR to the AAAH. However, as 624 discussed above, the use of Diameter agents between the FA and AAAH 625 in this exchange would expose the MN-FA key. If this is deemed 626 undesirable, a redirect server approach SHOULD be utilized to 627 communicate the AMR to the AAAH. This causes the FA to communicate 628 the AMR directly to the AAAH via a security association. 630 In the event that the mobile node with AAA NAI extension support 631 [AAANAI] has been previously authorized by the AAAH and now needs to 632 be re-authenticated, and requests to keep the assigned home agent in 633 the foreign network, the mobile node MUST include the HA NAI and the 634 AAAH NAI in the registration request to the FA. Upon receipt, the FA 635 will create the AMR including the MIP-Home-Agent-Address AVP, the 636 Destination-Host AVP based on the AAAH NAI and include the MIP-Home- 637 Agent-Host AVP based on the home agent NAI. If the AAAF authorizes 638 the use of the requested home agent, the AAAF MUST set the Home- 639 Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. 641 In the event that the mobile node needs to be re-authenticated but 642 does not support the AAA NAI extension, it sends a registration 643 request without the AAA NAI and the HA NAI, even though it has been 644 previously authorized by the AAAH and requests to keep the assigned 645 home agent in the foreign network. Upon receipt, the FA will create 646 the AMR including the MIP-Home-Agent-Address AVP. If the AAAF 647 authorizes the use of the requested home agent, and if it has 648 knowledge that the requested home agent is in its own domain, the 649 AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP- 650 Feature-Vector AVP. 652 Diameter MIP August 2004 654 When the AAAH receives an AMR message, it first checks the 655 authentication data supplied by the mobile node, according to the 656 MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether 657 to authorize the mobile node. If the AMR indicates that the AAAF has 658 offered to allocate a Home Agent for the mobile node, i.e. the 659 Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP, or 660 the AMR indicates that the AAAF has offered a previously allocated 661 Home Agent for the mobile node, i.e. the Home-Agent-In-Foreign- 662 Network is set in the MIP-Feature-Vector AVP, then the AAAH must 663 decide whether its local policy would allow the user to have or keep 664 a home agent in the foreign network. Assuming the mobile node is 665 permitted to have or keep a home agent in the foreign network, the 666 AAAH determines the IP address of the HA based upon the FQDN of the 667 HA using DNS, or learns it via an MIP-Home-Agent-Address AVP in a 668 redirect response to an HAR (i.e., if the redirect server adds this 669 AVP to the HAA), and sends an HAR message to Home Agent by including 670 the Destination-Host AVP set to the value found in the AMR's MIP- 671 Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP. If DNS is 672 used to determine the HA IP address, this specification makes the 673 assumption that the HA has a public address and it can be resolved by 674 DNS. 676 Security considerations may require that the HAR be sent directly 677 from the AAAH to the HA without the use of intermediary Diameter 678 agents. This requires that a security association between the AAAH 679 and HA be established, as in Figure 4. If no security association 680 can be established, the AAAH MUST return an AMA with the Result-Code 681 AVP set to DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. 683 If Diameter agents are being used (i.e., there is no redirect server, 684 etc.) the AAAH sends the HAR to the originating AAAF. In this HAR 685 the Destination-Host AVP is set to the value found in the AMR's MIP- 686 Originating-Foreign-AAA AVP, and the MIP-Home-Agent-Host AVP or the 687 MIP-Candidate-Home-Agent-Host AVP found in the AMR are copied into 688 the HAR. 690 Therefore, the AAAH MUST always copy the MIP-Originating-Foreign-AAA 691 AVP from the AMR message to the HAR message. In cases when another 692 AAAF receives the HAR, this new AAAF will send the HAR to the HA. 694 Diameter MIP August 2004 696 Visited Home 697 Realm Realm 698 +--------+ ------- AMR -------> +--------+ 699 | AAAF | <------ HAR -------- | AAAH | 700 | | | | 701 +--->| server | ------- HAA -------> | server | 702 | +--------+ <------ AMA -------- +--------+ 703 | ^ | 704 | | | 705 HAR/HAA | AMR | | AMA 706 v | v 707 +---------+ +---------+ 708 | Home | | Foreign | 709 | Agent | | Agent | 710 +---------+ +---------+ 711 ^ 712 +--------+ | 713 | Mobile |<----------+ 714 | Node | Mobile IP 715 +--------+ 717 Figure 5: Home Agent allocated in Visited Realm 719 Upon receipt of an HAA from the Home Agent in the visited realm, the 720 AAAF forwards the HAA to the AAAH in the home realm. The AMA is then 721 constructed, and issued to the AAAF, and finally to the FA. If the 722 Result-Code indicates success, the HAA and AMA MUST include the MIP- 723 Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. 725 If exposing keys to the Diameter Agents along the way represents an 726 unacceptable security risk, then the redirect approach depicted in 727 Figure 3 and Figure 4 MUST be used instead. 729 Diameter MIP August 2004 731 Mobile Node Foreign Agent Home Agent AAAF AAAH 732 ----------- ------------- ------------- ---------- ---------- 734 <----Challenge---- 735 Reg-Req (Response)-> 736 ------------AMR-------------> 737 -----AMR----> 738 <----HAR----- 739 <-----HAR------ 740 ------HAA------> 742 -----HAA----> 743 <----AMA----- 744 <-------------AMA------------ 745 <---Reg-Reply---- 747 Figure 6: MIP/Diameter Exchange for HA is allocated in 748 Visited Realm 750 If the mobile node moves to another foreign Network, it MAY either 751 request to keep the same Home Agent within the old foreign network, 752 or request to get a new one in the new foreign network. If the AAAH 753 is willing to provide the requested service, the AAAH will have to 754 provide services for both visited networks, e.g., key refresh. 756 3.3. Co-located Mobile Node 758 In the event that a mobile node registers with the Home Agent as a 759 co-located mobile node, there is no foreign agent involved. 760 Therefore, when the Home Agent receives the Registration Request, an 761 AMR message is sent to the local AAAH server, with the Co-Located- 762 Mobile-Node bit set in the MIP-Feature-Vector AVP. The Home Agent 763 also includes the Acct-Multi-Session-Id AVP in the AMR sent to the 764 AAAH, as the AAAH may find this a useful piece of session-state or 765 log entry information. 767 Diameter MIP August 2004 769 Home 770 Realm 771 +--------+ 772 | AAAH | 773 | | 774 | server | 775 +--------+ 776 ^ | 777 | | 778 AMR | | AMA 779 | v 780 +--------+ +---------+ 781 | Mobile | Registration | Home | 782 | Node |-------------->| Agent | 783 +--------+ Request +---------+ 785 Figure 7: Co-located Mobile Node 787 If the MN-HA-Key-Requested bit was set in the AMR message from the 788 Home Agent, the home agent and mobile node's session keys would be 789 present in the AMA message. 791 Figure 8 shows the secure solution using redirect servers. In Figure 792 8, the Proxy AAA represents any AAA server or servers that the HA may 793 use. This applies to the visited or home network. 795 Local redirect 796 HA Proxy AAA Agent AAAH 798 AMR 799 ---------------> 800 AMR (Redirect) 801 --------------------> 802 AMA (Redirect) 803 <--------------------- 804 AMA (Redirect) 805 <---------------- 806 Setup Security Association 807 <------------------------------------------------------> 808 AMR 809 -------------------------------------------------------> 810 AMA (MN-HA key) 811 <------------------------------------------------------- 813 Figure 8: Use of Redirect Server for Co-located CoA and 814 AMR/AMA 815 Diameter MIP August 2004 817 3.4. Key Distribution 819 In order to allow the scaling of wireless data access across 820 administrative domains, it is necessary to minimize the number of 821 pre-existing Mobility Security Associations (MSAs) required. This 822 means that each Foreign Agent should not be required have a pre- 823 configured MSA with each Home Agent on the Internet, nor should the 824 mobile node be required to have a pre-configured MSA with any 825 specific home agent or any specific foreign agent, as defined in 826 [MOBILEIP]. 828 The Diameter Mobile IPv4 application solves this by including key 829 distribution functionality, which means that after a Mobile Node is 830 authenticated the authorization phase includes the generation of 831 session keys and nonces. Specifically, three session keys and two 832 nonces are generated: 834 - K1 - the MN-HA Session Key, which will be part of the MSA between 835 the Mobile Node and the Home Agent. An associated nonce is 836 generated that the Mobile Node uses to derive the 837 (identical) session key. 839 - K2 - the MN-FA Key, which will be part of the MSA between the 840 Mobile Node and the Foreign Agent. An associated nonce is 841 generated that the Mobile Node uses to derive the 842 (identical) session key. 844 - K3 - the FA-HA Key, which will be part of the MSA between the 845 Foreign Agent and the Home Agent. 847 The same session key is used in both directions between two entities, 848 e.g., the Mobile Node and the Foreign Agent use the same session key 849 for the MN-FA and the FA-MN authentication extensions. Security 850 implications of this fact are examined in Section 13. However, the 851 SPIs may be different for the MN-FA and the FA-MN authentication 852 extensions. The SPI for the MN-FA MSA is used on messages sent from 853 the MN to the FA, and the SPI for the FA-MN MSA is used on messages 854 sent from the FA to the MN. 856 All keys and nonces are generated by the AAAH, even if a Home Agent 857 is dynamically allocated in the foreign network. 859 Figure 9 depicts the MSAs used for Mobile-IPv4 message integrity 860 using the keys created by the DIAMETER server. 862 Diameter MIP August 2004 864 +--------+ +--------+ 865 |Foreign | K3 | Home | 866 |Agent |<-------------------->| Agent | 867 | | | | 868 +--------+ +--------+ 869 ^ ^ 870 | K2 K1 | 871 | +--------+ | 872 | | Mobile | | 873 +------>| Node |<------+ 874 | | 875 +--------+ 877 Figure 9: Mobility Security Associations after Session 878 Key and Nonce Distribution 880 The keys destined for the foreign and home agent are propagated to 881 the mobility nodes via the Diameter protocol. If exposing keys to 882 the Diameter Agents along the way represents an unacceptable security 883 risk, then the keys MUST be protected either by IPSec or TLS security 884 associations that exist directly between the HA and AAAH or the FA 885 and AAAF, as explained above. 887 The keys destined for the mobile node MUST also be propagated via the 888 Mobile IPv4 protocol and MUST therefore instead follow the mechanisms 889 described in [MIPKEYS]. In [MIPKEYS], the keys distributed to the 890 mobile node are instead sent as nonces, and the mobile node will use 891 the nonce and the long-term shared secret to create the keys (see 892 section 8). 894 Once the session keys have been established and propagated, the 895 mobility devices can exchange registration information directly as 896 defined in [MOBILEIP] without the need of the Diameter 897 infrastructure. However, the session keys have a lifetime, after 898 which the Diameter infrastructure MUST be invoked again to acquire 899 new session keys and nonces. 901 Diameter MIP August 2004 903 4. Diameter Protocol Considerations 905 This section details the relationship of the Diameter Mobile IPv4 906 application to the Diameter base protocol. 908 This document specifies Diameter Application-ID 2. Diameter nodes 909 conforming to this specification MAY advertise support by including 910 the value of two (2) in the Auth-Application-Id or the Acct- 911 Application-Id AVP of the Capabilities-Exchange-Request and 912 Capabilities-Exchange-Answer command [DIAMBASE]. The value of two 913 (2) MUST be used as the Application-Id in all AMR/AMA and HAR/HAA 914 commands. The value of two (2) MUST be used as the Application-Id in 915 all ACR/ACA commands, because this application defines new, mandatory 916 AVPs for accounting. The value of zero (0) SHOULD be used as the 917 Application-Id in all STR/STA and ASR/ASA commands, because these are 918 defined in the Diameter base protocol and no additional mandatory 919 AVPs for those commands are defined in this document. 921 Given the nature of Mobile IPv4, re-authentication can only be 922 initiated by a mobile node, which does not participate in the 923 Diameter message exchanges. Therefore, Diameter server initiated re- 924 auth does not apply to this application and RAR/RAA commands MUST NOT 925 be sent for Diameter Mobile IPv4 sessions. 927 4.1. Diameter Session Management 929 The AAAH and AAAF MAY maintain session-state or MAY be session- 930 stateless. AAA redirect agents and AAA relay agents MUST NOT 931 maintain session-state. The AAAH, AAAF, proxies and relays agents 932 MUST maintain transaction state. 934 A mobile node's session is identified via its identity in the User- 935 Name AVP, the MIP-Mobile-Node-Address, and the MIP-Home-Agent-Address 936 AVPs. This is necessary in order to allow the session state machine, 937 defined in the base protocol [DIAMBASE], to be used unmodified with 938 this application. However, because the MN may interact with more 939 than one FA during the life of its session, it is important for the 940 Diameter Mobile IPv4 application to distinguish the two pieces of the 941 session (some state at the FA, some state at the HA) and to manage 942 them independently. The following sub-sections give further details. 944 4.1.1. Session Identifiers 946 During creation of the AMR, the FA will choose a session identifier. 947 During the creation of the HAR, the AAAH MUST use a different session 948 identifier than the one used in the AMR/AMA. If the AAAH is session- 949 stateful, it MUST send the same session identifier for all HARs 950 initiated on behalf of a given mobile node's session. Otherwise, if 951 the AAAH is session-stateless, it will manufacture a unique session- 952 id for every HAR. 954 Diameter MIP August 2004 956 When the HA is first allocated, it MUST create and include an Acct- 957 Multi-Session-Id AVP in the HAA returned to the AAAH. This 958 identifier will be kept constant for the life of the Mobile IPv4 959 session, as detailed in the next subsection. 961 4.1.2. Managing Sessions During Mobile IPv4 Handoffs 963 Given the nature of Mobile IPv4, a mobile node MAY receive service 964 from many foreign agents during a period of time. However, the home 965 realm should not view these handoffs as different sessions, since 966 this could affect billing systems. Furthermore, foreign agents 967 usually do not communicate between each other, which implies AAA 968 information cannot be exchanged between these entities. Therefore, 969 it MUST be assumed that a foreign agent is not aware that a 970 registration request from a mobile node has been previously 971 authorized. 973 A handoff registration request from a mobile node will cause the FA 974 to send an AMR to its AAAF. The AMR will include a new session 975 identifier, and MAY be sent to a new AAAF (i.e., a AAAF different 976 from the one used by the previous FA). However, assuming the MN 977 supports the AAA NAI, the AMR shall be received by the AAAH to which 978 the user is currently registered (possibly via the redirect mechanism 979 depicted in Figure 3). 981 Since the AAAH may be session-stateless, it is necessary for the 982 resulting HAR received by the HA to be identified as a continuation 983 of an existing session. If the HA receives an HAR for a mobile node 984 with a new session identifier, and the HA can guarantee that this 985 request is to extend service for an existing service, then the HA 986 MUST be able to modify its internal session state information to 987 reflect the new session identifier. 989 It is necessary for accounting records to have some commonality 990 across handoffs in order for correlation to occur. Therefore, the 991 home agent MUST send the same Acct-Multi-Session-Id AVP value in all 992 HAAs for the mobile's session. That is, the HA generates a unique 993 Acct-Multi-Session-Id when receiving an HAR for a new session, and 994 returns this same value in every HAA for the session. This Acct- 995 Multi-Session-Id AVP will be returned to the foreign agent by the 996 AAAH in the AMA. Both the foreign and home agents MUST include the 997 Acct-Multi-Session-Id in the accounting messages. 999 Diameter MIP August 2004 1001 ACR, Session-Id = foo ACR, Session-Id = bar 1002 Acct-Multi-Session-Id = a Acct-Multi-Session-Id = a 1003 ---------------------> <-------------------- 1004 +----+ +------+ +------+ +----+ 1005 | FA | | AAAF | | AAAH | | HA | 1006 +----+ +------+ +------+ +----+ 1007 <--------------------- ---------------------> 1008 ACA, Session-Id = foo ACA, Session-Id = bar 1010 Figure 10: Accounting messages w/ Mobile IPv4 1011 Application 1013 4.1.3. Diameter Session Termination 1015 A foreign and home agent following this specification MAY expect 1016 their respective Diameter servers to maintain session state 1017 information for each mobile node in their networks. In order for the 1018 Diameter Server to release any resources allocated to a specific 1019 mobile node, the mobility agents MUST send a Session-Termination- 1020 Request (STR) to the Diameter server that authorized the service. 1021 The mobility agents MUST issue the Session-Termination-Request (STR) 1022 if the Authorization Lifetime has expired and no subsequent MIP 1023 registration request has been received. 1025 The AAAH SHOULD only deallocate all resources after the STR is 1026 received from the home agent. This ensures that a mobile node that 1027 moves from one foreign agent to another (hand-off) does not cause the 1028 Home Diameter Server to free all resources for the mobile node. 1029 Therefore, an STR from a foreign agent would free the session from 1030 the foreign agent, but not the one towards the home agent (see Figure 1031 11). 1033 STR, Session-Id = foo STR, Session-Id = bar 1034 ---------------------> <-------------------- 1035 +----+ +------+ +------+ +----+ 1036 | FA | | AAAF | | AAAH | | HA | 1037 +----+ +------+ +------+ +----+ 1038 <--------------------- ---------------------> 1039 STA, Session-Id = foo STA, Session-Id = bar 1041 Figure 11: Session Termination and Session Identifiers 1043 When deallocating all of the mobile node's resources the home 1044 Diameter server (and the foreign Diameter server in case of HA 1045 allocated in foreign network) MUST destroy all session keys that may 1046 still be valid. 1048 In the event that the AAAF wishes to terminate a session, its Abort- 1049 Session-Request (ASR) [DIAMBASE] message SHOULD be sent to the FA. 1050 Similarly, the AAAH SHOULD send its message to the Home Agent. 1052 Diameter MIP August 2004 1054 5. Command-Code Values 1056 This section defines Command-Code [DIAMBASE] values that MUST be 1057 supported by all Diameter implementations conforming to this 1058 specification. The following Command Codes are defined in this 1059 specification: 1061 Command-Name Abbreviation Code Section 1062 ----------------------------------------------------------- 1063 AA-Mobile-Node-Request AMR 260 5.1 1064 AA-Mobile-Node-Answer AMA 260 5.2 1065 Home-Agent-MIP-Request HAR 262 5.3 1066 Home-Agent-MIP-Answer HAA 262 5.4 1068 5.1. AA-Mobile-Node-Request 1070 The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field 1071 set to 260 and the 'R' bit set in the Command Flags field, is sent by 1072 an attendant, acting as a Diameter client, to a AAAH in order to 1073 request the authentication and authorization of a mobile node. The 1074 foreign agent (or home agent in the case of a co-located Mobile Node) 1075 uses information found in the Registration Request to construct the 1076 following AVPs that are to be included as part of the AMR: 1078 Home Address (MIP-Mobile-Node-Address AVP) 1079 Home Agent address (MIP-Home-Agent-Address AVP) 1080 Mobile Node NAI (User-Name AVP [DIAMBASE]) 1081 MN-HA Key Request (MIP-Feature-Vector AVP) 1082 MN-FA Key Request (MIP-Feature-Vector AVP) 1083 MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP) 1084 Foreign Agent Challenge Extension (MIP-FA-Challenge AVP) 1085 Home Agent NAI (MIP-Home-Agent-Host AVP) 1086 Home AAA server NAI (Destination-Host AVP [DIAMBASE]) 1087 Home Agent to Foreign Agent SPI (MIP-HA-to-FA-SPI AVP) 1089 If the mobile node's home address is zero, the foreign or home agent 1090 MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. If the 1091 home agent address is zero or all ones, the MIP-Home-Agent-Address 1092 AVP MUST NOT be present in the AMR. 1094 If a home agent is used in a visited network, the AAAF MAY set the 1095 Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in 1096 the AMR message to indicate that it is willing to assign a Home Agent 1097 in the visited realm. 1099 If the mobile node's home address is all ones, the foreign or home 1100 agent MUST include a MIP-Mobile-Node-Address AVP, set to all ones. 1102 Diameter MIP August 2004 1104 If the mobile node includes the home agent NAI and the home AAA 1105 server NAI [AAANAI], the foreign agent MUST include the MIP-Home- 1106 Agent-Host AVP and the Destination-Host AVP in the AMR. 1108 Message Format 1110 ::= < Diameter Header: 260, REQ, PXY > 1111 < Session-ID > 1112 { Auth-Application-Id } 1113 { User-Name } 1114 { Destination-Realm } 1115 { Origin-Host } 1116 { Origin-Realm } 1117 { MIP-Reg-Request } 1118 { MIP-MN-AAA-Auth } 1119 [ Acct-Multi-Session-Id ] 1120 [ Destination-Host ] 1121 [ Origin-State-Id ] 1122 [ MIP-Mobile-Node-Address ] 1123 [ MIP-Home-Agent-Address ] 1124 [ MIP-Feature-Vector ] 1125 [ MIP-Originating-Foreign-AAA ] 1126 [ Authorization-Lifetime ] 1127 [ Auth-Session-State ] 1128 [ MIP-FA-Challenge ] 1129 [ MIP-Candidate-Home-Agent-Host ] 1130 [ MIP-Home-Agent-Host ] 1131 [ MIP-HA-to-FA-SPI ] 1132 * [ Proxy-Info ] 1133 * [ Route-Record ] 1134 * [ AVP ] 1136 5.2. AA-Mobile-Node-Answer 1138 The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field 1139 set to 260 and the 'R' bit cleared in the Command Flags field, is 1140 sent by the AAAH in response to the AA-Mobile-Node-Request message. 1141 The User-Name MAY be included in the AMA if present in the AMR. The 1142 Result-Code AVP MAY contain one of the values defined in section 6, 1143 in addition to the values defined in [DIAMBASE]. 1145 An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST 1146 include the MIP-Home-Agent-Address AVP, MUST include the MIP-Mobile- 1147 Node-Address AVP, and includes the MIP-Reg-Reply AVP if and only if 1148 the Co-Located-Mobile-Node bit was not set in the MIP-Feature-Vector 1149 AVP. The MIP-Home-Agent-Address AVP contains the Home Agent assigned 1150 to the mobile node, while the MIP-Mobile-Node-Address AVP contains 1151 the home address that was assigned. The AMA message MUST contain the 1152 MIP-FA-to-HA-MSA, MIP-FA-to-MN-MSA if they were requested in the AMR, 1153 and they were present in the HAR. The MIP-MN-to-HA-MSA and MIP-HA- 1154 to-MN-MSA AVPs MUST be present if the session keys were requested in 1155 Diameter MIP August 2004 1157 the AMR, and the Co-Located-Mobile-Node bit was set in the MIP- 1158 Feature-Vector AVP. 1160 Message Format 1162 ::= < Diameter Header: 260, PXY > 1163 < Session-Id > 1164 { Auth-Application-Id } 1165 { Result-Code } 1166 { Origin-Host } 1167 { Origin-Realm } 1168 [ Acct-Multi-Session-Id ] 1169 [ User-Name ] 1170 [ Authorization-Lifetime ] 1171 [ Auth-Session-State ] 1172 [ Error-Message ] 1173 [ Error-Reporting-Host ] 1174 [ Re-Auth-Request-Type ] 1175 [ MIP-Feature-Vector ] 1176 [ MIP-Reg-Reply ] 1177 [ MIP-MN-to-FA-MSA ] 1178 [ MIP-MN-to-HA-MSA ] 1179 [ MIP-FA-to-MN-MSA ] 1180 [ MIP-FA-to-HA-MSA ] 1181 [ MIP-HA-to-MN-MSA ] 1182 [ MIP-MSA-Lifetime ] 1183 [ MIP-Home-Agent-Address ] 1184 [ MIP-Mobile-Node-Address ] 1185 * [ MIP-Filter-Rule ] 1186 [ Origin-State-Id ] 1187 * [ Proxy-Info ] 1188 * [ AVP ] 1190 5.3. Home-Agent-MIP-Request 1192 The AAA sends the Home-Agent-MIP-Request (HAR), indicated by the 1193 Command-Code field set to 262 and the 'R' bit set in the Command 1194 Flags field, to the Home Agent. If the Home Agent is to be assigned 1195 in a foreign network, the HAR is issued by the AAAH and forwarded by 1196 the AAAF to the HA if no redirect servers are involved. If redirect 1197 servers are involved the HAR is sent directly to the HA via a 1198 security association. If the HAR message does not include a MIP- 1199 Mobile-Node-Address AVP, and the Registration Request has 0.0.0.0 for 1200 the home address, and the HAR is successfully processed, the Home 1201 Agent MUST allocate the mobile nodes address. If on the other hand 1202 the home agent's local AAA server allocates the mobile node's home 1203 address, the local AAA server MUST include the assigned address in an 1204 MIP-Mobile-Node-Address AVP. 1206 Diameter MIP August 2004 1208 When session keys are requested for use by the mobile node, the AAAH 1209 MUST create them and include them in the HAR message. When a FA-HA 1210 session key is requested, it will be created and distributed by the 1211 AAAH server. 1213 Message Format 1215 ::= < Diameter Header: 262, REQ, PXY > 1216 < Session-Id > 1217 { Auth-Application-Id } 1218 { Authorization-Lifetime } 1219 { Auth-Session-State } 1220 { MIP-Reg-Request } 1221 { Origin-Host } 1222 { Origin-Realm } 1223 { User-Name } 1224 { Destination-Realm } 1225 { MIP-Feature-Vector } 1226 [ Destination-Host ] 1227 [ MIP-MN-to-HA-MSA ] 1228 [ MIP-MN-to-FA-MSA ] 1229 [ MIP-HA-to-MN-MSA ] 1230 [ MIP-HA-to-FA-MSA ] 1231 [ MIP-MSA-Lifetime ] 1232 [ MIP-Originating-Foreign-AAA ] 1233 [ MIP-Mobile-Node-Address ] 1234 [ MIP-Home-Agent-Address ] 1235 * [ MIP-Filter-Rule ] 1236 [ Origin-State-Id ] 1237 * [ Proxy-Info ] 1238 * [ Route-Record ] 1239 * [ AVP ] 1241 5.4. Home-Agent-MIP-Answer 1243 The Home Agent sends the Home-Agent-MIP-Answer (HAA), indicated by 1244 the Command-Code field set to 262 and the 'R' bit cleared in the 1245 Command Flags field, to its local AAA server in response to a Home- 1246 Agent-MIP-Request. The User-Name MAY be included in the HAA if 1247 present in the HAR. If the home agent allocated a home address for 1248 the mobile node, the address MUST be included in the MIP-Mobile-Node- 1249 Address AVP. The Result-Code AVP MAY contain one of the values 1250 defined in section 6 instead of the values defined in [DIAMBASE]. 1252 Diameter MIP August 2004 1254 Message Format 1256 ::= < Diameter Header: 262, PXY > 1257 < Session-Id > 1258 { Auth-Application-Id } 1259 { Result-Code } 1260 { Origin-Host } 1261 { Origin-Realm } 1262 [ Acct-Multi-Session-Id ] 1263 [ User-Name ] 1264 [ Error-Reporting-Host ] 1265 [ Error-Message ] 1266 [ MIP-Reg-Reply ] 1267 [ MIP-Home-Agent-Address ] 1268 [ MIP-Mobile-Node-Address ] 1269 [ MIP-FA-to-HA-SPI ] 1270 [ MIP-FA-to-MN-SPI ] 1271 [ Origin-State-Id ] 1272 * [ Proxy-Info ] 1273 * [ AVP ] 1275 6. Result-Code AVP Values 1277 This section defines new Result-Code [DIAMBASE] values that MUST be 1278 supported by all Diameter implementations that conform to this 1279 specification. 1281 6.1. Transient Failures 1283 Errors that fall within the transient failures category are used to 1284 inform a peer that the request could not be satisfied at the time it 1285 was received, but may be able to satisfy the request in the future. 1287 DIAMETER_ERROR_MIP_REPLY_FAILURE 4005 1288 This error code is used by the home agent when processing of 1289 the Registration Request has failed. 1291 DIAMETER_ERROR_HA_NOT_AVAILABLE 4006 1292 This error code is used to inform the foreign agent that the 1293 requested Home Agent cannot be assigned to the mobile node 1294 at this time. The foreign agent MUST return a Mobile IPv4 1295 Registration Reply to the mobile node with an appropriate 1296 error code. 1298 DIAMETER_ERROR_BAD_KEY 4007 1299 This error code is used by the home agent to indicate to the 1300 local Diameter server that the key generated is invalid. 1302 Diameter MIP August 2004 1304 DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED 4008 1305 This error code is used by a mobility agent to indicate to 1306 the home Diameter server that the requested packet filter 1307 Rules cannot be supported. 1309 6.2. Permanent Failures 1311 Errors that fall within the permanent failures category are used to 1312 inform the peer that the request failed, and SHOULD NOT be attempted 1313 again. 1315 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5024 1316 This error is used by the AAAF to inform the AAAH that 1317 allocation of a home agent in the foreign domain is not 1318 permitted at this time. 1320 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025 1322 This error is used by the AAAF / AAAH to inform the peer 1323 that the requested Mobile IPv4 session keys could not be 1324 delivered via a security association. 1326 7. Mandatory AVPs 1328 The following table describes the Diameter AVPs defined in the Mobile 1329 IPv4 application, their AVP Code values, types, possible flag values 1330 and whether the AVP MAY be encrypted. 1332 Due to space constraints, the short form IPFiltrRule is used to 1333 represent IPFilterRule and DiamIdent is used to represent 1334 DiameterIdentity. 1336 Diameter MIP August 2004 1338 +--------------------------+ 1339 | AVP Flag rules | 1340 |----+-----+----+-----|----+ 1341 AVP Section | | |SHLD| MUST|MAY | 1342 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1343 -----------------------------------------|----+-----+----+-----|----| 1344 MIP-Reg-Request 320 7.1 OctetString| M | P | | V | Y | 1345 MIP-Reg-Reply 321 7.2 OctetString| M | P | | V | Y | 1346 MIP-MN-AAA-Auth 322 7.6 Grouped | M | P | | V | Y | 1347 MIP-Mobile-Node- 333 7.3 Address | M | P | | V | Y | 1348 Address 1349 MIP-Home-Agent- 334 7.4 Address | M | P | | V | Y | 1350 Address 1351 MIP-Candidate- 336 7.9 DiamIdent | M | P | | V | N | 1352 Home-Agent-Host 1353 MIP-Feature- 337 7.5 Unsigned32 | M | P | | V | Y | 1354 Vector 1355 MIP-Auth-Input- 338 7.6.2 Unsigned32 | M | P | | V | Y | 1356 Data-Length 1357 MIP- 339 7.6.3 Unsigned32 | M | P | | V | Y | 1358 Authenticator-Length 1359 MIP- 340 7.6.4 Unsigned32 | M | P | | V | Y | 1360 Authenticator-Offset 1361 MIP-MN-AAA-SPI 341 7.6.1 Unsigned32 | M | P | | V | Y | 1362 MIP-Filter-Rule 342 7.8 IPFiltrRule| M | P | | V | Y | 1363 MIP-FA-Challenge 344 7.7 OctetString| M | P | | V | Y | 1365 MIP-Originating- 347 7.10 Grouped | M | P | | V | Y | 1366 Foreign-AAA 1367 MIP-Home-Agent- 348 7.9 DiamIdent | M | P | | V | N | 1368 Host 1370 7.1. MIP-Reg-Request AVP 1372 The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and 1373 contains the Mobile IPv4 Registration Request [MOBILEIP] sent by the 1374 mobile node to the foreign agent. 1376 7.2. MIP-Reg-Reply AVP 1378 The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and 1379 contains the Mobile IPv4 Registration Reply [MOBILEIP] sent by the 1380 home agent to the foreign agent. 1382 7.3. MIP-Mobile-Node-Address AVP 1384 The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and 1385 contains the mobile node's home IP address. 1387 Diameter MIP August 2004 1389 7.4. MIP-Home-Agent-Address AVP 1391 The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and 1392 contains the mobile node's home agent IP address. 1394 7.5. MIP-Feature-Vector AVP 1396 The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and 1397 is added with flag values set by the foreign agent or by the AAAF 1398 owned by the same administrative domain as the foreign agent. The 1399 foreign agent SHOULD include MIP-Feature-Vector AVP within the AMR 1400 message it sends to the AAAF. 1402 Flag values currently defined include: 1403 1 Mobile-Node-Home-Address-Requested 1404 2 Home-Address-Allocatable-Only-in-Home-Realm 1405 4 Home-Agent-Requested 1406 8 Foreign-Home-Agent-Available 1407 16 MN-HA-Key-Request 1408 32 MN-FA-Key-Request 1409 64 FA-HA-Key-Request 1410 128 Home-Agent-In-Foreign-Network 1411 256 Co-Located-Mobile-Node 1413 The flags are set according to the following rules. 1415 If the mobile node includes a valid home address (i.e., not equal to 1416 0.0.0.0 or 255.255.255.255) in its Registration Request, the foreign 1417 agent sets the Mobile-Node-Home-Address-Requested flag in the MIP- 1418 Feature-Vector AVP to zero. 1420 If the mobile node sets the home address field equal to 0.0.0.0 in 1421 its Registration Request, the foreign agent sets the Mobile-Node- 1422 Home-Address-Requested flag to one. 1424 If the mobile node sets the home agent field equal to 255.255.255.255 1425 in its Registration Request, the foreign agent sets both the Home- 1426 Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home- 1427 Realm flag to one in the MIP-Feature-Vector AVP. 1429 If the mobile node sets the home agent field equal to 0.0.0.0 in its 1430 Registration Request, the foreign agent sets the Home-Agent-Requested 1431 flag to one, and zeroes the Home-Address-Allocatable-Only-in-Home- 1432 Realm flag in the MIP-Feature-Vector AVP. 1434 Whenever the foreign agent sets either the Mobile-Node-Home-Address- 1435 Requested flag or the Home-Agent-Requested flag to one, it MUST set 1436 the MN-HA-Key-Request flag to one. The MN-HA-Key-Request flag is 1437 also set to one if the mobile node includes a "Generalized MN-HA Key 1438 Nonce Generation Request" [MIPKEYS] extension, with the subtype set 1439 to AAA. 1441 Diameter MIP August 2004 1443 If the mobile node includes a "Generalized MN-FA Key Nonce Generation 1444 Request" [MIPKEYS] extension with the AAA subtype in its Registration 1445 Request, the foreign agent sets the MN-FA-Key-Request flag to one in 1446 the MIP-Feature-Vector AVP. 1448 If the mobile node requests a home agent in the foreign network 1449 either by setting the home address field to all ones, or by 1450 specifying a home agent in the foreign network, and the AAAF 1451 authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign- 1452 Network bit to one. 1454 If the Home Agent receives a Registration Request from the mobile 1455 node indicating that the MN is acting as a co-located mobile node, 1456 the home agent sets the Co-Located-Mobile-Node bit to one. 1458 If the foreign agent's local policy allows it to receive AAA session 1459 keys, and it does not have any existing FA-HA key with the home 1460 agent, the foreign agent MAY set the FA-HA-Key-Request flag 1462 The foreign agent MUST NOT set the Foreign-Home-Agent-Available and 1463 Home-Agent-In-Foreign-Network flag both to one. 1465 When the AAAF receives the AMR message, it MUST first verify that the 1466 sender was an authorized foreign agent. The AAAF then takes any 1467 actions indicated by the settings of the MIP-Feature-Vector AVP 1468 flags. The AAAF then MAY set additional flags. Only the AAAF may 1469 set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign- 1470 Network flags to one. This is done according to local administrative 1471 policy. When the AAAF has finished setting additional flags 1472 according to its local policy, then the AAAF transmits the AMR with 1473 the possibly modified MIP-Feature-Vector AVP to the AAAH. 1475 7.6. MIP-MN-AAA-Auth AVP 1477 The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains 1478 some ancillary data to simplify processing of the authentication data 1479 in the Mobile IPv4 Registration Request [MOBILEIP, MIPCHAL] by the 1480 target AAA server. Its value has the following ABNF grammar: 1482 MIP-MN-AAA-Auth ::= < AVP Header: 322 > 1483 { MIP-MN-AAA-SPI } 1484 { MIP-Auth-Input-Data-Length } 1485 { MIP-Authenticator-Length } 1486 { MIP-Authenticator-Offset } 1487 * [ AVP ] 1488 Diameter MIP August 2004 1490 7.6.1. MIP-MN-AAA-SPI AVP 1492 The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 1493 indicates the MSA by which the targeted AAA server (AAAH) should 1494 attempt to validate the Authenticator computed by the mobile node 1495 over the Registration Request data. 1497 7.6.2. MIP-Auth-Input-Data-Length AVP 1499 The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type 1500 Unsigned32 and contains the length, in bytes, of the Registration 1501 Request data (data portion of MIP-Reg-Request AVP)that should be used 1502 as input to the algorithm, as indicated by the MN-AAA-SPI AVP, used 1503 to determine whether the Authenticator Data supplied by the mobile 1504 node is valid. 1506 7.6.3. MIP-Authenticator-Length AVP 1508 The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32 1509 and contains the length of the authenticator to be validated by the 1510 targeted AAA server (i.e., AAAH). 1512 7.6.4. MIP-Authenticator-Offset AVP 1514 The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32 1515 and contains the offset into the Registration Request Data, of the 1516 authenticator to be validated by the targeted AAA server (i.e., 1517 AAAH). 1519 7.7. MIP-FA-Challenge AVP 1521 The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and 1522 contains the challenge advertised by the foreign agent to the mobile 1523 node. This AVP MUST be present in the AMR if the mobile node used 1524 the RADIUS-style MN-AAA computation algorithm. 1526 7.8. MIP-Filter-Rule AVP 1528 The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule, and 1529 provides filter rules that need to be configured on the foreign or 1530 home agent for the user. The packet filtering rules are set by the 1531 AAAH by adding one or more MIP-Filter-Rule AVPs in the HAR if 1532 destined for the home agent and/or in the AMA if destined for the 1533 foreign agent. 1535 Diameter MIP August 2004 1537 7.9. MIP-Candidate-Home-Agent-Host 1539 The MIP-Candidate-Home-Agent-Host AVP (AVP Code 336) is of type 1540 DiameterIdentity and contains the identity of a home agent in the 1541 foreign network that the AAAF proposes be dynamically assigned to the 1542 mobile node. 1544 7.10. MIP-Originating-Foreign-AAA AVP 1546 The MIP-Originating-Foreign-AAA AVP (AVP Code 347) if of type 1547 Grouped, and contains the identity of the AAAF, which issues the AMR 1548 to the AAAH. The MIP- Originating-Foreign-AAA AVP MUST only be used 1549 in cases when the home agent is or may be allocated in a foreign 1550 domain. If present in the AMR, the AAAH MUST copy the MIP- 1551 Originating-Foreign-AAA AVP into the HAR. 1553 MIP-Originating-Foreign-AAA ::= < AVP Header: 347 > 1554 { Origin-Realm } 1555 { Origin-Host } 1556 * [ AVP ] 1558 7.11. MIP-Home-Agent-Host AVP 1560 The MIP-Home-Agent-Host AVP (AVP Code 348) is of type Grouped, and 1561 contains the identity of the assigned Home Agent. If present in 1562 the AMR, the AAAH MUST copy the MIP-Home-Agent-Host AVP into the 1563 HAR. 1565 MIP-Home-Agent-Host ::= < AVP Header: 348 > 1566 { Destination-Realm } 1567 { Destination-Host } 1568 * [ AVP ] 1570 8. Key Distribution 1572 The mobile node and mobility agents use session keys (i.e., the MN- 1573 FA, FA-HA and MN-HA session keys) to compute authentication 1574 extensions applied to MIP registration messages, as defined in 1575 [MOBILEIP]. If session keys are requested the AAAH MUST return the 1576 keys and nonces after the mobile node is successfully authenticated 1577 and authorized. 1579 The SPI values are used as key identifiers, each session key has its 1580 own SPI value; nodes that share a key can have different SPIs. The 1581 mobile node allocates SPIs for use in the mobility security 1582 associations of the MN-FA and MN-HA authentication extensions, via 1583 the Mobile IPv4 AAA Key Request extensions [MIPKEYS]. The home agent 1584 allocates SPIs for the MN-HA and FA-HA mobility security association. 1586 Diameter MIP August 2004 1588 The foreign agent chooses a SPI for the MN-FA and HA-FA mobility 1589 security association. In all cases, the entity that receives an 1590 authentication extension (i.e., verifies the authentication 1591 extension) is providing the entity that sends the authentication 1592 extension (i.e., computes the authentication extension) the value of 1593 the SPI to use for that key and extension. Note that the keys in 1594 this regime are symmetric in the sense they are used in both 1595 directions, even though the SPIs do not have to be symmetric. 1597 Once the session keys and nonces have been distributed, subsequent 1598 Mobile IPv4 registrations need not invoke the AAA infrastructure 1599 until the keys expire. These registrations MUST include the MN-HA 1600 authentication extension. In addition, subsequent registrations MUST 1601 also include MN-FA authentication extension if the MN-FA session key 1602 was generated and distributed by AAA; similarly for subsequent use of 1603 the FA-HA authentication extensions. 1605 8.1. Authorization Lifetime vs. MIP Key Lifetime 1607 The Diameter Mobile IPv4 application makes use of two timers - the 1608 Authorization-Lifetime AVP [DIAMBASE] and the MIP-MSA-Lifetime AVP. 1610 The Authorization-Lifetime contains the number of seconds before the 1611 mobile node must issue a subsequent MIP registration request. The 1612 content of the Authorization-Lifetime AVP corresponds to the Lifetime 1613 field in the MIP header [MOBILEIP]. 1615 The MIP-MSA-Lifetime AVP contains the number of seconds before 1616 session keys destined for the mobility agents and the mobile node 1617 expire. A value of zero indicates infinity (no timeout). If not 1618 zero, the value of the MIP-MSA-Lifetime AVP MUST is at least equal to 1619 the value in the Authorization Lifetime AVP. 1621 8.2. Nonce vs. Session Key 1623 As described in section 3.4, the AAAH generates session keys and 1624 transmits them to the home agent and foreign agent. The AAAH 1625 generates nonces that correspond to the same keys and transmits them 1626 to the mobile node. Where it is necessary to protect the session 1627 keys and SPIs from un-trusted Diameter agents, end-to-end security 1628 mechanisms such as TLS or IPSec are required to eliminate the all 1629 Diameter Agents between the FA or HA and the AAAH, as outlined above. 1631 In [MIPKEYS] the mobility security associations are established via 1632 nonces transmitted to the mobile node via Mobile IPv4. To provide 1633 the nonces, the AAAH must generate a random [RANDOM] value of at 1634 least 128 bits [MIPKEYS]. The mobile node then uses the nonce to 1635 derive the MN-HA and MN-FA session keys. 1637 Diameter MIP August 2004 1639 More details of the MN-HA and the MN-FA session key creation 1640 procedure are found in [MIPKEYS]. 1642 It is important that the hashing algorithm used by the mobile node to 1643 construct the session key is the same as the one used by the AAAH in 1644 the session key generation procedure. The AAAH therefore indicates 1645 the algorithm used along with the nonce. 1647 The FA-HA and HA-FA session key is shared between the FA and HA. The 1648 AAAH generates a random [RANDOM] value of at least 128 bits for use 1649 as this session key. 1651 See sections 9 for details about the format of the AVPs used to 1652 transport the session keys. 1654 8.3. Distributing the Mobile-Home Session Key 1656 If the mobile node does not have a MN-HA session key, then the AAAH 1657 is likely to be the only entity trusted that is available to the 1658 mobile node. Thus, the AAAH has to generate the MN-HA session key. 1660 The distribution of the HA-MN (session) key to the HA has been 1661 specified above. The HA and AAAH establish a security association 1662 (IPSec or TLS) and transport the key over that security association. 1663 If no security association exists between the AAAH and the home 1664 agent, and a security association cannot be established the AAAH MUST 1665 return a Result-Code AVP with 1666 DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. 1668 The AAAH also has to arrange for the key to be delivered to the 1669 mobile node. Unfortunately, the AAAH only knows about Diameter 1670 messages and AVPs, and the mobile node only knows about Mobile IPv4 1671 messages and extensions [MOBILEIP]. For this purpose, AAAH includes 1672 the MN-HA MIP-nonce AVP into a MIP-MN-to-HA-MSA AVP, which is added 1673 to the HAR for FA COA style Mobile IPv4 or AMA for collocated COA 1674 style Mobile IPv4 messages, and delivered either to a local home 1675 agent or a home agent in the visited network. Recall the mobile node 1676 will use the nonce to create the MN-HA session key using the MN-AAA 1677 key it shares with the AAAH [MIPKEYS]. The AAAH has to rely on the 1678 home agent (that also understands Diameter) to transfer the nonce 1679 into a Mobile IPv4 "Generalized MN-HA Key Generation Nonce Reply" 1680 extension [MIPKEYS] in the Registration Reply message. The HA 1681 includes the SPIs proposed by the mobile node and the home agent in 1682 the "Generalized MN-HA Key Generation Nonce Request" extension. The 1683 home agent can format the Reply message and extensions correctly for 1684 eventual delivery to the mobile node. The resulting Registration 1685 Reply is added to the HAA's MIP-Reg-Reply AVP. 1687 The AAAH parses the HAA message, transforms it into an AMA message 1688 containing an MIP-Reg-Reply AVP, and sends the AMA message to the 1689 foreign agent. The foreign agent then uses that AVP to recreate a 1690 Diameter MIP August 2004 1692 Registration Reply message containing the "Generalized MN-HA Key 1693 Generation Nonce Reply" extension for delivery to the mobile node. 1695 In summary, the AAAH generates the MN-HA nonce, which is added to the 1696 MIP-MN-to-HA-MSA AVP, and a session key, which is added to the MIP- 1697 HA-to-MN-MSA AVP. These AVPs are delivered to the home agent in HAR 1698 or AMA messages. The home agent retains the session key for its own 1699 use, and copies the nonce from the MIP-MN-to-HA-MSA AVP into a 1700 "Generalized MN-HA Key Generation Nonce Reply" extension, which is 1701 appended to the Mobile IPv4 Registration Reply message. This 1702 Registration Reply message MUST also include the HA-MN authentication 1703 extension, which is created using the newly allocated HA-MN session 1704 key. The home agent then includes the Registration Reply message and 1705 extensions into a MIP-Reg-Reply AVP as part of the HAA message to be 1706 sent back to the AAA server. 1708 The key derived by the MN from the MN-HA session nonce is identical 1709 to the HA-MN session key provided to the HA. 1711 8.4. Distributing the Mobile-Foreign Session Key 1713 The MN-FA session nonce is also generated by AAAH (upon request) and 1714 is added to the MIP-MN-to-FA-MSA AVP, which is added to the HAR, and 1715 copied by the home agent into a "Generalized MN-FA Key Generation 1716 Nonce Reply" extension [MIPKEYS] to the Mobile IPv4 Registration 1717 Reply message. The HA also includes the SPIs proposed by the mobile 1718 node and foreign agent in the "MN-FA Key Generation Nonce Request" 1719 extension. The AAAH includes the FA-MN session key in the MIP-FA-to- 1720 MN-MSA AVP in the AMA, to be used by the foreign agent in the 1721 computation of the FA-MN authentication extension. 1723 The key derived by the MN from the MN-FA session nonce is identical 1724 to the FA-MN session key provided to the FA. 1726 8.5. Distributing the Foreign-Home Session Key 1728 If the foreign agent requests an FA-HA session key, it also includes 1729 a MIP-HA-to-FA-SPI AVP in the AMR to convey the SPI to be used by the 1730 home agent for this purpose. The AAAH generates the FA-HA session 1731 key, which is identical to the HA-FA session key, and distributes 1732 that to both the HA and the FA over respective security associations 1733 to each using the MIP-HA-to-FA-MSA and MIP-FA-to-HA-MSA AVPs. The HA 1734 conveys the SPI the FA MUST use in the HAA; this is similar to the 1735 way that the FA conveys the SPI the HA MUST use in the AMR. The AAAH 1736 later includes these SPIs in the MIP-FA-HA-MSA and MIP-HA-FA-MSA 1737 AVPs, respectively, along with the session key. 1739 Refer to Figure 2, Figure 3, Figure 4 and Figure 6 for the messages 1740 involved. 1742 Diameter MIP August 2004 1744 Note that if multiple MNs are registered on the same pair of FA and 1745 HA, then multiple mobility security associations would be 1746 distributed. However, only one is required to protect the Mobile IP 1747 control traffic between FA and HA. This creates an unacceptable 1748 level of state (i.e., to store the two SPIs and shared key for each 1749 FA-HA mobility security association). To improve scalablity the FA 1750 and HA may discard FA-HA mobility security associations prior to the 1751 time they actually expire. However, if a proper discard policy is 1752 not chosen, this could cause Mobile IP messages in transit or waiting 1753 in queues for transmission to fail authentication. 1755 The FA MUST always use the FA-HA security association with the latest 1756 expiry time when computing authentication extensions on outgoing 1757 messages. The FA MAY discard HA-FA mobility security associations 10 1758 seconds after a new HA-FA mobility security association arrives with 1759 a later expiry time. 1761 The HA SHOULD use the HA-FA mobility security association that has 1762 the latest expiry time when computing authentication extensions in 1763 outgoing messages. However, when the HA receives a new HA-FA 1764 mobility security association with a later expiry time, the HA SHOULD 1765 wait 4 seconds for the AMA to propagate to the FA before using the 1766 new association. Note that the HA always uses the mobility security 1767 association from the HAR when constructing the Mobile IP Registration 1768 Reply in the corresponding HAA. The HA may discard an FA-HA mobility 1769 security association once it receives a message authenticated by a 1770 FA-HA mobility security association with a later expiry time. 1772 9. Key Distribution AVPs 1774 The Mobile-IP protocol defines a set of mobility security 1775 associations shared between the mobile node, foreign agent and home 1776 agent. These three mobility security associations (MN-HA, MN-FA, and 1777 FA-HA) are dynamically created by the AAAH, and has previously been 1778 described in section 3.4 and section 8. AAA servers supporting the 1779 Diameter Mobile IP Application MUST implement the key distribution 1780 AVPs defined in this document. 1782 The names of the key distribution AVPs indicate the two entities 1783 sharing the mobility security association. The first named entity in 1784 the AVP name will use the mobility security association to create 1785 authentication extensions using the given SPI and key. The second 1786 named entity in the AVP name will use the mobility security 1787 association to verify the authentication extensions of received 1788 Mobile IP messages. 1790 So for instance, the MIP-MN-to-HA-MSA AVP contains the MN-HA nonce, 1791 which the mobile node will use to derive the MN-HA Key, and the MIP- 1792 HA-to-MN-MSA AVP contains the MN-HA key for the home agent. Note 1793 that mobility security associations are unidirectional, however, this 1794 application delivers only one key that is shared between both 1795 Diameter MIP August 2004 1797 unidirectional security associations that exist between two peers. 1798 The security considerations of using the same key in each direction 1799 are given in Section 13. The SPIs are however unique to each 1800 unidirectional security association and are chosen by the peer that 1801 will receive the Mobile IP messages authenticated with that security 1802 association. 1804 The following table describes the Diameter AVPs defined in the Mobile 1805 IP application, their AVP Code values, types, and possible flag 1806 values. 1808 +--------------------------+ 1809 | AVP Flag Rules | 1810 |----+-----+----+-----|----+ 1811 AVP Section | | |SHLD| MUST|MAY | 1812 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 1813 -----------------------------------------|----+-----+----+-----|----| 1814 MIP-FA-to-HA-SPI 318 9.11 Unsigned32 | M | P | | V | Y | 1815 MIP-FA-to-MN-SPI 319 9.10 Unsigned32 | M | P | | V | Y | 1816 MIP-HA-to-FA-SPI 323 9.14 Unsigned32 | M | P | | V | Y | 1817 MIP-MN-to-FA-MSA 325 9.5 Grouped | M | P | | V | Y | 1818 MIP-FA-to-MN-MSA 326 9.1 Grouped | M | P | | V | Y | 1819 MIP-FA-to-HA-MSA 328 9.2 Grouped | M | P | | V | Y | 1820 MIP-HA-to-FA-MSA 329 9.3 Grouped | M | P | | V | Y | 1821 MIP-MN-to-HA-MSA 331 9.6 Grouped | M | P | | V | Y | 1822 MIP-HA-to-MN-MSA 332 9.4 Grouped | M | P | | V | Y | 1823 MIP-Nonce 335 9.12 OctetString| M | P | | V | Y | 1824 MIP-Session-Key 343 9.7 OctetString| M | P | | V | Y | 1825 MIP-Algorithm- 345 9.8 Enumerated | M | P | | V | Y | 1826 Type 1827 MIP-Replay-Mode 346 9.9 Enumerated | M | P | | V | Y | 1828 MIP-MSA-Lifetime 367 9.13 Unsigned32 | M | P | | V | Y | 1830 9.1. MIP-FA-to-MN-MSA AVP 1832 The MIP-FA-to-MN-MSA AVP (AVP Code 326) is of type Grouped, and 1833 contains the FA-MN session key. This AVP is conveyed to the FA in an 1834 AMA message. The MN allocates the MIP-FA-to-MN-SPI. The FA creates 1835 an FA-MN authentication extension using the session key and 1836 algorithm, and the MN verifies that extension using the same session 1837 key and algorithm. The data field of this AVP has the following ABNF 1838 grammar: 1840 MIP-FA-to-MN-MSA ::= < AVP Header: 326 > 1841 { MIP-FA-to-MN-SPI } 1842 { MIP-Algorithm-Type } 1843 { MIP-Session-Key } 1844 * [ AVP ] 1845 Diameter MIP August 2004 1847 9.2. MIP-FA-to-HA-MSA AVP 1849 The MIP-FA-to-HA-MSA AVP (AVP Code 328) is of type Grouped, and 1850 contains the FA-HA session key. This AVP is conveyed to the FA in an 1851 AMA message. The HA allocates the MIP-FA-to-HA-SPI. The FA creates 1852 the FA-HA authentication extension using the session key and 1853 algorithm, and the HA verifies that extension using the same session 1854 key and algorithm. The AVP's data field has the following ABNF 1855 grammar: 1857 MIP-FA-to-HA-MSA ::= < AVP Header: 328 > 1858 { MIP-FA-to-HA-SPI } 1859 { MIP-Algorithm-Type } 1860 { MIP-Session-Key } 1861 * [ AVP ] 1863 9.3. MIP-HA-to-FA-MSA AVP 1865 The MIP-HA-to-FA-MSA AVP (AVP Code 329) is of type Grouped, and 1866 contains the Home Agent's session key, which it shares with the 1867 foreign agent. This AVP is conveyed to the HA in an HAR message. 1868 The FA allocates the MIP-HA-to-FA-SPI. The HA creates the HA-FA 1869 authentication extension using the session key and algorithm, and the 1870 FA verifies that extension using the same session key and algorithm. 1871 The AVP's data field has the following ABNF grammar: 1873 MIP-HA-to-FA-MSA ::= < AVP Header: 329 > 1874 { MIP-HA-to-FA-SPI } 1875 { MIP-Algorithm-Type } 1876 { MIP-Session-Key } 1877 * [ AVP ] 1879 9.4. MIP-HA-to-MN-MSA AVP 1881 The MIP-HA-to-MN-MSA AVP (AVP Code 332) is of type Grouped, and 1882 contains the HA-MN session key. This AVP is conveyed to the HA in an 1883 HAR for the case of FA COA Mobile IPv4 and in an AMA for the case of 1884 collocated COA Mobile IPv4. The MN allocates the MIP-HA-to-MN-SPI. 1885 The HA creates the HA-MN authentication extension using the session 1886 key and algorithm, and the MN verifies that extension using the same 1887 session key and algorithm. The AVP's field has the following ABNF 1888 grammar: 1890 MIP-HA-to-MN-MSA ::= < AVP Header: 332 > 1891 { MIP-HA-to-MN-SPI } 1892 { MIP-Algorithm-Type } 1893 { MIP-Replay-Mode } 1894 { MIP-Session-Key } 1895 * [ AVP ] 1896 Diameter MIP August 2004 1898 9.5. MIP-MN-to-FA-MSA AVP 1900 The MIP-MN-to-FA-MSA AVP (AVP Code 325) is of type Grouped, and 1901 contains the MN-FA session nonce, which the mobile node uses to 1902 derive the MN-FA session key. This AVP is conveyed to the HA in an 1903 HAR message. The FA allocates the MIP-MN-to-FA-SPI. The MN creates 1904 the MN-FA authentication extension using the session key and 1905 algorithm, and the FA verifies that extension using the same session 1906 key and algorithm. 1908 The home agent uses this AVP in the construction of the Mobile IP 1909 "Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS]. 1911 MIP-MN-to-FA-MSA ::= < AVP Header: 325 > 1912 { MIP-MN-FA-SPI } 1913 { MIP-Algorithm-Type } 1914 { MIP-nonce } 1915 * [ AVP ] 1917 9.6. MIP-MN-to-HA-MSA AVP 1919 The MIP-MN-to-HA-MSA AVP (AVP Code 331) is of type Grouped, and 1920 contains the MN-HA session nonce, which the mobile node uses to 1921 derive the MN-HA session key. This AVP is conveyed to the HA in an 1922 HAR message for the case of FA COA Mobile IPv4 and in an AMR for the 1923 case of collocated Mobile IPv4. The HA allocates the MIP-MN-to-HA- 1924 SPI. The MN creates the MN-FA authentication extension using the 1925 session key and algorithm, and the HA verifies that extension using 1926 the same session key and algorithm. 1928 The Home Agent uses this AVP in the construction of the Mobile IP 1929 "Generalized MN-HA Key Generation Nonce Reply" extension [MIPKEYS]. 1931 MIP-MN-to-HA-MSA ::= < AVP Header: 331 > 1932 { MIP-MN-HA-SPI } 1933 { MIP-Algorithm-Type } 1934 { MIP-Replay-Mode } 1935 { MIP-nonce } 1936 * [ AVP ] 1938 9.7. MIP-Session-Key AVP 1940 The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 1941 contains the Session Key for the associated Mobile IPv4 1942 authentication extension. The HAAA selects the session key. 1944 Diameter MIP August 2004 1946 9.8. MIP-Algorithm-Type AVP 1948 The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, and 1949 contains the Algorithm identifier for the associated Mobile IPv4 1950 authentication extension. The HAAA selects the algorithm type. The 1951 following values are currently defined: 1953 2 HMAC-SHA-1 [HMAC] 1955 9.9. MIP-Replay-Mode AVP 1957 The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and 1958 contains the replay mode the Home Agent for authenticating the mobile 1959 node. The HAAA selects the replay mode. 1961 The following values are supported (see [MOBILEIP] for more 1962 information): 1964 1 None 1965 2 Timestamps 1966 3 Nonces 1968 9.10. MIP-FA-to-MN-SPI AVP 1970 The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and it 1971 contains the Security Parameter Index the FA and MN use to refer to 1972 the FA-MN session key. The MN allocates the SPI, and it MUST NOT 1973 have a value between zero (0) and 255, which is the reserved 1974 namespace defined in [MOBILEIP]. 1976 9.11. MIP-FA-to-HA-SPI AVP 1978 The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32, and 1979 contains the Security Parameter Index the FA and HA use to refer to 1980 the FA-HA session key. The HA allocates the SPI , and it MUST NOT 1981 have a value between zero (0) and 255, which is the reserved 1982 namespace defined in [MOBILEIP]. 1984 9.12. MIP-Nonce AVP 1986 The MIP-Nonce AVP (AVP Code 335) is of type OctetString and contains 1987 the nonce sent to the mobile node for the associated authentication 1988 extension. The mobile node follows the procedures in [MIPKEYS] to 1989 generate the session key used to authenticate Mobile IPv4 1990 registration messages. The HAAA selects the nonce. 1992 Diameter MIP August 2004 1994 9.13. MIP-MSA-Lifetime AVP 1996 The MIP-MSA-Lifetime AVP (AVP Code 367) is of type Unsigned32 and 1997 represents the period of time (in seconds) for which the session key 1998 or nonce is valid. The associated session key or nonce, as the case 1999 may be, MUST NOT be used if the lifetime has expired; if the session 2000 key or nonce lifetime expires while the session to which it applies 2001 is still active, either the session key or nonce MUST be changed or 2002 the association Mobile IPv4 session MUST be terminated. 2004 9.14. MIP-HA-to-FA-SPI AVP 2006 The MIP-HA-to-FA-SPI AVP (AVP Code 323) is of type Unsigned32, and 2007 contains the Security Parameter Index the HA and FA use to refer to 2008 the HA-FA session key. The FA allocates the SPI, and it MUST NOT 2009 have a value between zero (0) and 255, which is the reserved 2010 namespace defined in [MOBILEIP]. 2012 10. Accounting AVPs 2014 10.1. Accounting-Input-Octets AVP 2016 The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64, 2017 and contains the number of octets in IP packets received from the 2018 user. This AVP MUST be included in all Accounting-Request messages 2019 and MAY be present in the corresponding Accounting-Answer messages as 2020 well. 2022 10.2. Accounting-Output-Octets AVP 2024 The Accounting-Output-Octets AVP (AVP Code 364) is of type 2025 Unsigned64, and contains the number of octets in IP packets sent to 2026 the user. This AVP MUST be included in all Accounting-Request 2027 messages and MAY be present in the corresponding Accounting-Answer 2028 messages as well. 2030 10.3. Acct-Session-Time AVP 2032 The Acct-Time AVP (AVP Code 46) is of type Unsigned32, and indicates 2033 the length of the current session in seconds. This AVP MUST be 2034 included in all Accounting-Request messages and MAY be present in the 2035 corresponding Accounting-Answer messages as well. 2037 Diameter MIP August 2004 2039 10.4. Accounting-Input-Packets AVP 2041 The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64, 2042 and contains the number of IP packets received from the user. This 2043 AVP MUST be included in all Accounting-Request messages and MAY be 2044 present in the corresponding Accounting-Answer messages as well. 2046 10.5. Accounting-Output-Packets AVP 2048 The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64, 2049 and contains the number of IP packets sent to the user. This AVP 2050 MUST be included in all Accounting-Request messages and MAY be 2051 present in the corresponding Accounting-Answer messages as well. 2053 10.6. Event-Timestamp AVP 2055 The Event-Timestamp (AVP Code 55) is of type Time, and MAY be 2056 included in an Accounting-Request message to record the time that 2057 this event occurred on the mobility agent, in seconds since January 2058 1, 1970 00:00 UTC. 2060 11. AVP Occurrence Tables 2062 The following tables presents the AVPs defined in this document and 2063 their occurrences in Diameter messages. Note that AVPs that can only 2064 be present within a Grouped AVP are not represented in this table. 2066 The table uses the following symbols: 2067 0 The AVP MUST NOT be present in the message. 2068 0+ Zero or more instances of the AVP MAY be present in the 2069 message. 2070 0-1 Zero or one instance of the AVP MAY be present in the 2071 message. 2072 1 One instance of the AVP MUST be present in the message. 2074 Diameter MIP August 2004 2076 11.1. Mobile IP Command AVP Table 2078 The table in this section is limited to the Command Codes defined in 2079 this specification. 2081 +-----------------------+ 2082 | Command-Code | 2083 |-----+-----+-----+-----+ 2084 Attribute Name | AMR | AMA | HAR | HAA | 2085 ------------------------------|-----+-----+-----+-----+ 2086 Authorization-Lifetime | 0-1 | 0-1 | 1 | 0 | 2087 Auth-Application-Id | 1 | 1 | 1 | 1 | 2088 Auth-Session-State | 0-1 | 0-1 | 1 | 0 | 2089 Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 0-1 | 2090 Destination-Host | 0-1 | 0 | 0-1 | 0 | 2091 Destination-Realm | 1 | 0 | 1 | 0 | 2092 Error-Message | 0 | 0-1 | 0 | 0-1 | 2093 Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 | 2094 MIP-Candidate-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 | 2095 MIP-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 | 2096 MIP-Originating-Foreign-AAA | 0-1 | 0 | 0-1 | 0 | 2097 MIP-FA-Challenge | 0-1 | 0 | 0 | 0 | 2098 MIP-FA-to-MN-MSA | 0 | 0-1 | 0 | 0 | 2099 MIP-FA-to-HA-MSA | 0 | 0-1 | 0 | 0 | 2100 MIP-HA-to-FA-MSA | 0 | 0 | 0-1 | 0 | 2101 MIP-HA-to-MN-MSA | 0 | 0-1 | 0-1 | 0 | 2102 MIP-MN-to-FA-MSA | 0 | 0 | 0-1 | 0 | 2103 MIP-MN-to-HA-MSA | 0 | 0-1 | 0-1 | 0 | 2104 MIP-FA-to-HA-SPI | 0 | 0 | 0 | 0-1 | 2105 MIP-HA-to-FA-SPI | 0 | 0 | 0 | 0-1 | 2107 MIP-FA-to-MN-SPI | 0 | 0 | 0 | 0-1 | 2108 MIP-MN-to-FA-SPI | 0 | 0 | 0 | 0-1 | 2110 MIP-HA-to-MN-SPI | 0 | 0 | 0 | 0-1 | 2111 MIP-MN-to-HA-SPI | 0 | 0 | 0 | 0-1 | 2112 MIP-Feature-Vector | 0-1 | 0-1 | 1 | 0 | 2113 MIP-Filter-Rule | 0 | 0+ | 0+ | 0 | 2114 MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 | 2115 MIP-MSA-Lifetime | 0 | 0-1 | 0-1 | 0 | 2116 MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 | 2117 MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 | 2118 MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 | 2119 MIP-Reg-Request | 1 | 0 | 1 | 0 | 2120 Origin-Host | 1 | 1 | 1 | 1 | 2121 Origin-Realm | 1 | 1 | 1 | 1 | 2122 Origin-State-Id | 0-1 | 0-1 | 0-1 | 0-1 | 2123 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 2124 Redirect-Host | 0 | 0+ | 0 | 0+ | 2125 Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 | 2126 Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 | 2127 Result-Code | 0 | 1 | 0 | 1 | 2128 Diameter MIP August 2004 2130 Re-Auth-Request-Type | 0 | 0-1 | 0 | 0 | 2131 Route-Record | 0+ | 0 | 0+ | 0 | 2132 Session-Id | 1 | 1 | 1 | 1 | 2133 User-Name | 1 | 0-1 | 1 | 0-1 | 2134 ------------------------------|-----+-----+-----+-----| 2136 11.2. Accounting AVP Table 2138 The table in this section is used to represent which AVPs defined in 2139 this document are to be present in the Accounting messages, defined 2140 in [DIAMBASE]. 2142 +-------------+ 2143 | Command-Code| 2144 |------+------+ 2145 Attribute Name | ACR | ACA | 2146 -------------------------------------|------+------+ 2147 Accounting-Input-Octets | 1 | 0-1 | 2148 Accounting-Input-Packets | 1 | 0-1 | 2149 Accounting-Output-Octets | 1 | 0-1 | 2150 Accounting-Output-Packets | 1 | 0-1 | 2151 Acct-Multi-Session-Id | 1 | 0-1 | 2152 Acct-Session-Time | 1 | 0-1 | 2153 MIP-Feature-Vector | 1 | 0-1 | 2154 MIP-Home-Agent-Address | 1 | 0-1 | 2155 MIP-Mobile-Node-Address | 1 | 0-1 | 2156 Event-Timestamp | 0-1 | 0 | 2157 -------------------------------------|------+------+ 2159 12. IANA Considerations 2161 This section contains the namespaces that have either been created in 2162 this specification, or the values assigned to existing namespaces 2163 managed by IANA. 2165 12.1. Command Codes 2167 This specification assigns the values 260 and 262 from the Command 2168 Code namespace defined in [DIAMBASE]. See section 5 for the 2169 assignment of the namespace in this specification. 2171 12.2. AVP Codes 2173 This specification assigns the values 318-348 and 363-366 from the 2174 AVP Code namespace defined in [DIAMBASE]. See sections 7, 9, and 10 2175 for the assignment of the namespace in this specification. 2177 Diameter MIP August 2004 2179 12.3. Result-Code AVP Values 2181 This specification assigns the values 4005-4008, and 5024-5025 from 2182 the Result-Code AVP (AVP Code 268) value namespace defined in 2183 [DIAMBASE]. See section 6 for the assignment of the namespace in 2184 this specification. 2186 12.4. MIP-Feature-Vector AVP Values 2188 There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that 2189 are available for assignment. This document assigns bits 1-9, as 2190 listed in section 7.5. The remaining bits should only be assigned 2191 via Standards Action [IANA]. 2193 12.5. MIP-Algorithm-Type AVP Values 2195 As defined in Section 9.8, the MIP-Algorithm-Type AVP (AVP Code 345) 2196 defines the value 2. All remaining values, except zero, are 2197 available for assignment via Designated Expert [IANA]. 2199 12.6. MIP-Replay-Mode AVP Values 2201 As defined in Section 9.9, the MIP-Replay-Mode AVP (AVP Code 346) 2202 defines the values 1-3. All remaining values, except zero, are 2203 available for assignment via Designated Expert [IANA]. 2205 12.7. Application Identifier 2207 This specification assigns the value two (2) to the Application 2208 Identifier namespace defined in [DIAMBASE]. See section 4 for more 2209 information. 2211 13. Security Considerations 2213 This specification describes a Mobile IPv4 Diameter Application for 2214 authenticating and authorizing a Mobile IPv4 mobile node. The 2215 authentication algorithm used is dependent upon the transforms used 2216 within the Mobile IPv4 protocol, and [MIPCHAL]. This specification, 2217 in conjunction with [MIPKEYS], also defines a method by which the 2218 home Diameter server can create and distribute session keys and 2219 nonces for use in authenticating and integrity-protecting Mobile IPv4 2220 registration messages [MOBILEIP]. The key distribution is asymmetric 2221 since communication with the mobile node occurs via the Mobile IPv4 2222 protocol [AAAKEY, MOBILEIP], while communication to the Home Agent 2223 and Foreign Agent occurs via the Diameter protocol. Where untrusted 2224 Diameter agents are present, end-to-end security MUST be used. The 2225 end-to-end security takes the form of TLS or IPSec security 2226 Diameter MIP August 2004 2228 associations between the AAAH and the FA and between the AAAH and the 2229 HA. These connections will be authenticated with the use of public 2230 keys and certificates; however, the identities that appear in the 2231 certificates must be authorized and bound to a particular Mobile IPv4 2232 Diameter session before the AAAH can safely begin distribution of 2233 keys. 2235 Note that the direct connections are established as a result of 2236 Diameter redirect messages. For example, in Figure 3, the FA gets a 2237 redirect response containing the Redirect-Host AVP of the AAAH. This 2238 is the identity that should be matched against the certificate 2239 presented by the AAAH when the secure connection is established. In 2240 this case, the network of Diameter proxies and redirect agents is 2241 trusted with the task of returning the correct AAAH identity to the 2242 FA. 2244 The AAAH must also make an authorization decision at the time the FA 2245 establishes the connection. If the AAAH is one and the same with the 2246 redirect server, then it may have observed and noted the original AMR 2247 message that contained the identity of the FA, and so may authorize 2248 the establishment of a TLS or IPSec connection from the same entity. 2249 Otherwise, the AAAH would need to maintain a list of all authorized 2250 visited domains (roaming partners) and authorize TLS or IPSec 2251 connections based on this list. Note that establishment of the 2252 connection is only the first step, and the AAAH has another 2253 opportunity to deny service upon receipt of the AMR message itself. 2254 At this step, the AAAH can check the internal AVPs of the AMR to 2255 ensure that the FA is valid; for example, it can check that the 2256 Mobile IP COA is equal to the IP address used as the endpoint of the 2257 TLS or IPSec connection. However, such a policy would prevent the FA 2258 from using different interfaces for AAA and Mobile IP tunnel packets, 2259 and may not be desirable in every deployment situation. 2261 A similar set of considerations applies to the connection between 2262 AAAH and HA when those entities are in different administrative 2263 domains. However, here the roles are reversed because it is the AAAH 2264 that contacts the HA via the HAR. The identity of the candidate HA 2265 is given to the AAAH in the AMR, and the AAAH should expect to 2266 receive the same identity in the public key certificates during TLS 2267 or IPSec negotiation. The HA may authorize individual connections by 2268 acting as its own redirect server or it may maintain a list of 2269 trusted roaming partners. 2271 This application creates and distributes a single session key for 2272 each pair of MSAs between two entities, e.g., the same session key is 2273 used for the MN-HA MSA and the HA-MN MSA. It is safe to do so from a 2274 security perspective because the session keys are only used with 2275 keyed hash functions to generate authenticator values that protect 2276 the integrity of each Mobile IP control message. Mobile IP messages 2277 have built in replay protection with the use of timestamps or nonces 2278 [MOBILEIP] and, due to the nature of the protocol, requests are 2279 always bitwise different from responses at least in the message type 2280 code. This avoids problems that might arise in other situations 2281 Diameter MIP August 2004 2283 where an attacker could mount a replay or reflection attack if the 2284 same key were used to, e.g., encrypt otherwise unprotected traffic on 2285 more than one connection leg in the network. 2287 Nonces are sent to the mobile node, which are used to generate the 2288 session keys via the HMAC-SHA-1 one-way function. Because the nonces 2289 and authentication extensions may be observed by anyone with access 2290 to a clear-text copy of the Registration Reply, the pre-shared key 2291 between the mobile node and the home Diameter server would be 2292 vulnerable to an offline dictionary attack if it does not contain 2293 enough entropy. To prevent this, the pre-shared key between the 2294 mobile node and the home Diameter server SHOULD be a randomly chosen 2295 quantity of at least 96 bits. 2297 Because the session key is determined by the long-term secret and the 2298 nonce, the nonce SHOULD be temporally and globally unique; if the 2299 nonce were to repeat, then so would the session key. To prevent 2300 this, a nonce is strongly recommended to be a random [RANDOM] value 2301 of at least 128 bits. The long-term secret between the MN and AAAH 2302 MUST be periodically refreshed, to guard against recovery of the 2303 long-term secret due to nonce reuse or other factors. This is 2304 accomplished using out-of-band mechanisms, which are not specified in 2305 this document. 2307 It should also be noted that it is not recommended to set the MIP- 2308 MSA-Lifetime AVP value equal to zero, since keeping session keys for 2309 a long time (no refresh) increases the level of vulnerability. 2311 14. References 2313 14.1. Normative 2315 [DIAMBASE] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. 2316 Rubens,"Diameter Base Protocol", RFC 3588, September 2317 2003. 2319 [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA C 2320 Considerations Section in RFCs", BCP 26, RFC 2434, 2321 October 1998 2323 [MOBILEIP] C. Perkins, Editor. IP Mobility Support. RFC 3344, 2324 August 2002. 2326 [MIPCHAL] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response 2327 Extensions", Request 2328 For Comments 3021, December 2000. 2330 [NAI] B. Aboba, M. Beadles "The Network Access Identifier." 2331 Request For Comments 2486, January 1999. 2333 [HMAC] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: 2335 Diameter MIP August 2004 2337 Keyed Hashing for Message Authentication. RFC 2104, 2338 February 1997. 2340 [MIPKEYS] C. Perkins, P. Calhoun, "AAA Registration Keys for 2341 Mobile IP", draft-ietf-mipv4-aaa-key-04.txt, 2342 IETF work in progress, November 2003. 2344 [AAANAI] F. Johansson, T. Johansson, "AAA NAI for Mobile IP 2345 Extension", draft-mip4-aaa-nai-02.txt, IETF work 2346 December 2003. (approved for 2347 publication)_ 2349 [IPSEC] S. Kent, Security Architecture for the Internet, RFC 2350 2401, November 1998. 2352 [TLS] Blake-Wilson, Transport Layer Security Extensions, RFC 2353 3546, June 2003. 2355 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 2356 Requirement Levels", BCP 14, RFC 2119, March 1997. 2358 14.2. Informative 2360 [MIPREQ] S. Glass, S. Jacobs, C. Perkins, "Mobile IP 2361 Authentication, Authorization, and Accounting 2362 Requirements". RFC 2977. October 2000. 2364 [CDMA2000] T. Hiller and al, "CDMA2000 Wireless Data Requirements 2365 for AAA", RFC 3141, June 2001. 2367 [EVALROAM] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming 2368 Protocols", RFC 2477, January 1999. 2370 [MIPNAI] P. Calhoun, C. Perkins, "Mobile IP Network Address 2371 Identifier Extension", RFC 2794, March 2000. 2373 [RANDOM] D. Eastlake, 3rd, S. Crocker, and J. Schiller. 2374 Radomness Recommendations for Security. RFC 1750, 2375 Internet Engineering Task Force, December 1994. 2377 15. Acknowledgements 2379 The authors would like to thank Nenad Trifunovic, Haseeb Akhtar and 2380 Pankaj Patel for their participation in the pre-IETF Document Reading 2381 Party, to Erik Guttman for his very useful proposed text, and to 2382 Fredrik Johansson, Martin Julien and Bob Kopacz for their very useful 2383 contributed text. 2385 Diameter MIP August 2004 2387 The authors would also like to thank the participants of 3GPP2's TSG- 2388 X working group for their valuable feedback and also the following 2389 people for their contribution in the development of the protocol: 2391 Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael 2392 Chen, Henry Haverinen, Johan Johansson. General redirect server text 2393 due to Pasi Eronen was borrowed from Diameter-EAP. 2395 Pat Calhoun would like to thank Sun Microsystems since most of the 2396 effort put into this document was done while he was in their employ. 2398 16. Authors' Addresses 2400 Questions about this memo can be directed to: 2402 Pat Calhoun Tony Johansson 2403 Airespace Bytemobile, Inc. 2404 110 Nortech Parkway 2029 Stierlin Court 2405 San Jose, CA 95154 Mountain View, CA 94043 2406 USA USA 2408 Phone: +1 408-635-2023 Phone: +1 650-641-7817 2409 Email: pcalhoun@airespace.com Fax: +1 650-641-7701 2410 Email: tony.johansson@bytemobile.com 2412 Charles E. Perkins Tom Hiller 2413 Nokia Research Center Lucent Technologies 2414 313 Fairchild Drive 1960 Lucent Lane 2415 Mountain View, CA 94043 Naperville, IL 60566 2416 USA USA 2418 Phone: +1 650-625-2986 Phone: +1 630-979-7673 2419 Fax: +1 650-625-2502 Email: tomhiller@lucent.com 2420 Email: charliep@iprg.nokia.com 2422 Peter J. McCann 2423 Lucent Technologies 2424 1960 Lucent Lane 2425 Naperville, IL 60563 2426 USA 2428 Phone: +1 630-713-9359 2429 Fax: +1 630-713-1921 2430 Email: mccap@lucent.com 2431 Diameter MIP August 2004 2433 A. Change Log (to be removed before publication) 2435 Changes since draft-18: 2437 - Added text to section 4 to clarify the value of the Application 2438 ID used with each of the various Diameter commands. 2440 - Removed spurious "MIP-Type-Algorithm" AVP, which was not defined 2441 anywhere in the document, from the answer commands. 2443 Changes since draft-19: 2445 - Changed Application ID from 4 to 2, as specified in the base 2446 Diameter protocol 2448 - Reserved MIP-Algorithm-Type zero from future Designated Expert 2449 allocation in Section 12.5. 2451 Diameter MIP August 2004 2453 Full Copyright Statement 2455 Copyright (C) The Internet Society (2004). This document is subject 2456 to the rights, licenses and restrictions contained in BCP 78, and 2457 except as set forth therein, the authors retain all their rights. 2459 This document and the information contained herein are provided on an 2460 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2461 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2462 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2463 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2464 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2465 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2467 Intellectual Property 2469 The IETF takes no position regarding the validity or scope of any 2470 Intellectual Property Rights or other rights that might be claimed to 2471 pertain to the implementation or use of the technology described in 2472 this document or the extent to which any license under such rights 2473 might or might not be available; nor does it represent that it has 2474 made any independent effort to identify any such rights. Information 2475 on the procedures with respect to rights in RFC documents can be 2476 found in BCP 78 and BCP 79. 2478 Copies of IPR disclosures made to the IETF Secretariat and any 2479 assurances of licenses to be made available, or the result of an 2480 attempt made to obtain a general license or permission for the use of 2481 such proprietary rights by implementers or users of this 2482 specification can be obtained from the IETF on-line IPR repository at 2483 http://www.ietf.org/ipr. 2485 The IETF invites any interested party to bring to its attention any 2486 copyrights, patents or patent applications, or other proprietary 2487 rights that may cover technology that may be required to implement 2488 this standard. Please address the information to the IETF at ietf- 2489 ipr@ietf.org. 2491 Acknowledgement 2493 Funding for the RFC Editor function is currently provided by the 2494 Internet Society.