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