idnits 2.17.1 draft-le-aaa-diameter-mobileipv6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 35 longer pages, the longest (page 0) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 36 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 186: '...is specification MAY advertise support...' RFC 2119 keyword, line 256: '...ssumed that an IPv6 mobile node SHOULD...' RFC 2119 keyword, line 258: '... node SHOULD be able to use its NAI ...' RFC 2119 keyword, line 274: '... SHOULD use the MN_NAI to get aut...' RFC 2119 keyword, line 279: '... MAY use the IPv6 home address to...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 22 has weird spacing: '... It is inapp...' == Line 227 has weird spacing: '...ion and auth...' == Line 740 has weird spacing: '...chanism that ...' == Line 1162 has weird spacing: '...chanism that ...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 1430, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1434, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2409 (ref. '5') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AAA WG Stefano M. Faccin 2 INTERNET-DRAFT Franck Le 3 Date: November 2001 Basavaraj Patil 4 Expires: May 2002 Charles E. Perkins 5 Nokia Research Center 7 Diameter Mobile IPv6 Application 8 10 Status of This Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 Mobile IPv6 capable mobile nodes can roam between networks that 34 belong to their home service provider as well as others. Roaming in 35 foreign networks is enabled as a result of the service level and 36 roaming agreements that exist between operators. One of the key 37 protocols that allows this kind of a roaming mechanism to be enabled 38 is Diameter. This Internet Draft specifies a new application to 39 Diameter that enables Mobile IPv6 roaming in networks other than its 40 home. 42 Table of Contents 44 Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i 46 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 50 2. Advertising Application support . . . . . . . . . . . . . . . . . 2 52 3. The model and assumptions . . . . . . . . . . . . . . . . . . . . 2 53 3.1. The model . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Basic features supported in this Internet Draft . . . . . . . . . 5 57 4.1. Authentication/authorization . . . . . . . . . . . . . . . . 5 58 4.2. Dynamic Home Agent assignment in Home domain . . . . . . . . 5 59 4.3. Key distribution . . . . . . . . . . . . . . . . . . . . . . 6 60 4.4. Optimization of Binding Updates . . . . . . . . . . . . . . 7 61 4.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. Mobile IPv6 Application Diameter messages . . . . . . . . . . . . 7 64 5.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.2. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.2.1. MIP-Binding-Update AVP . . . . . . . . . . . . . . . . 8 67 5.2.2. MIP-Binding-acknowledgement AVP . . . . . . . . . . . . 8 68 5.2.3. MIPv6-Mobile-Node-Address AVP . . . . . . . . . . . . . 8 69 5.2.4. MIPv6-Home-Agent-Address AVP . . . . . . . . . . . . . 8 70 5.2.5. MIPv6-Feature-Vector AVP . . . . . . . . . . . . . . . 9 71 5.2.6. Security Key AVPs . . . . . . . . . . . . . . . . . . . 9 73 6. Information exchange between the mobile node and the AAA Client . 9 74 6.1. MIP Feature Data . . . . . . . . . . . . . . . . . . . . . . 9 75 6.2. EAP Data . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.3. Security Key Data . . . . . . . . . . . . . . . . . . . . . 10 77 6.4. Embedded Data . . . . . . . . . . . . . . . . . . . . . . . 10 79 7. Basic Protocol Overview . . . . . . . . . . . . . . . . . . . . . 10 80 7.1. Authentication . . . . . . . . . . . . . . . . . . . . . . . 11 81 7.2. Information flows . . . . . . . . . . . . . . . . . . . . . 11 82 7.3. MN Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 7.3.1. Generation of information in MN . . . . . . . . . . . . 12 84 7.3.2. Replies to MN . . . . . . . . . . . . . . . . . . . . . 13 85 7.4. AAA Client Operation . . . . . . . . . . . . . . . . . . . . 13 86 7.5. AAAv Operation . . . . . . . . . . . . . . . . . . . . . . . 14 87 7.6. AAAh operations . . . . . . . . . . . . . . . . . . . . . . 15 88 7.7. Home Agent Behavior . . . . . . . . . . . . . . . . . . . . 16 90 8. Enhanced features . . . . . . . . . . . . . . . . . . . . . . . . 17 91 8.1. Dynamic Home Agent/ Home Address assignment in Visited 92 domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 8.2. Dynamic Home address assignment in Home Domain . . . . . . . 18 94 8.3. Enhanced AVPs . . . . . . . . . . . . . . . . . . . . . . . 18 95 8.3.1. MIPv6-Feature-Vector AVP . . . . . . . . . . . . . . . 18 97 9. Enhanced Protocol Overview . . . . . . . . . . . . . . . . . . . 19 98 9.1. Information flow . . . . . . . . . . . . . . . . . . . . . . 19 99 9.2. MN Considerations . . . . . . . . . . . . . . . . . . . . . 20 100 9.2.1. Generation of information in MN . . . . . . . . . . . . 20 101 9.2.2. Replies to MN . . . . . . . . . . . . . . . . . . . . . 22 102 9.3. AAA Client Operation . . . . . . . . . . . . . . . . . . . . 22 103 9.4. AAAv Operation . . . . . . . . . . . . . . . . . . . . . . . 23 104 9.5. AAAh operations . . . . . . . . . . . . . . . . . . . . . . 24 105 9.5.1. Home Agent Assignement in Visited Network . . . . . . . 25 106 9.5.2. Home Agent Assignment in Home Network . . . . . . . . . 26 107 9.6. Home Agent Behavior . . . . . . . . . . . . . . . . . . . . 28 109 10. Key distribution . . . . . . . . . . . . . . . . . . . . . . . . 28 110 10.1. Key distribution based on Random numbers . . . . . . . . . 28 111 10.2. Key distribution based on Diffie Hellman . . . . . . . . . 29 113 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 30 115 12. Security Considerations . . . . . . . . . . . . . . . . . . . . 30 117 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 119 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 120 1. Introduction 122 Mobile IP defines a method that allows a Mobile Node to change its 123 point of attachment to the Internet with minimal service disruption. 124 Mobile IP in itself does not provide any specific support for 125 mobility across different administrative domains, which limits the 126 applicability of Mobile IP in a large scale commercial deployment. 128 AAA protocols such as Diameter precisely enable mobile users to roam 129 and obtain service in networks that may not necessarily be owned by 130 their home service provider. For Mobile IP to be deployed in 131 commercial networks, there therefore has to be AAA support for the 132 protocol. 134 Diameter extensions for Mobile IPv4 [1] have already been specified 135 allowing a MIPv4 node to receive services from service providers 136 (home and foreign) and allowing the Diameter servers to authenticate, 137 authorize and collect accounting information for those MIPv4 nodes. 139 Even though MIPv4 and MIPv6 are similar when observed at high level, 140 the two protocols are actually quite different when considering the 141 support for Inter Domain deployment. Mobile IPv6 e.g. does not have 142 the equivalent of a Foreign Agent as defined in Mobile IPv4, and as a 143 result does not define any mechanism by which the visited network can 144 authenticate and authorize access to the network and use of 145 resources. In addition, extending the Diameter Mobile IPv4 146 Application [1] to support Mobile IPv6 will reduce the flexibility 147 and result in some AAA capability exchange issues: it will be 148 difficult to differentiate which AAA nodes support only Mobile IPv4, 149 which ones support only Mobile IPv6 and which ones support both. This 150 document therefore provides a solution for Mobile IPv6 and AAA 151 interworking and e.g. defines the IPv6 specific solution to support 152 roaming of an IPv6 mobile node between different administrative 153 domains. 155 In order to give access to a mobile node to network resources, the 156 mobile node needs to be authenticated and authorized. Besides 157 supporting mobile node authentication and authorization, the AAA 158 infrastructure can also be used for distributing the security keys 159 needed to support the mobile node roaming. Optionally, the AAA 160 infrastructure can be used to support mobility procedures and to 161 optimize authentication, authorization and mobility in a common 162 procedure. 164 This internet draft defines the Diameter Mobile IPv6 application. It 165 identifies the information that needs to be exchanged between the MN 166 and the AAA Client but it does not specify any particular mechanism 167 to convey information between the mobile node and the AAA Client: the 168 set of information identified in the following internet draft, can be 169 conveyed between the mobile node and the AAA client in a different 170 suitable manner outside the scope of this document (e.g. ICMP, the 171 protocol defined by the PANA WG, etc.). The extensions defined for 172 Diameter allow for any of these alternatives, thus enabling such 173 extensions to be deployed independently of the choice of the protocol 174 used between the MN and the AAA client in the visited or access 175 network. 177 The basic AAA model for inter domain roaming and the assumptions 178 behind the model are described first. The basic features supported by 179 the Diameter Mobile IPv6 application are described next, with the 180 definition of the Diameter messages and AVPs and with the behavior of 181 the various elements. Finally, enhanced features are described and 182 the AVPs and the behavior of the various elements is described. 184 2. Advertising Application support 186 Diameter nodes conforming to this specification MAY advertise support 187 by including the value of (TBD) in the Auth-Application-Id or the 188 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 189 Capabilities-Exchange-Answer command [7]. 191 3. The model and assumptions 193 3.1. The model 195 The following entities are involved in the model: 197 Visited Domain Home Domain 198 +--------+ +--------+ 199 |abc.com | (3) |xyz.com | 200 | AAAv |<------------------->| AAAH | 201 +->| server | server-server | server | 202 | +--------+ communication +--------+ 203 | ^ ^ 204 (2) | | (2) client-server | (4) 205 | | communication | 206 v v v 207 +---------+ +---------+ +---------+ 208 | AAA | | AAA | | Home | 209 | Client | | Client | | Agent | 210 +---------+ +---------+ +---------+ 211 ^ 212 | (1) 213 | 214 v 215 +--------+ 216 | Mobile | 217 | Node | mn@xyz.com 218 +--------+ 220 * The Mobile Node 222 * The AAA Client: it is the function that allows the MN to register 223 and be authenticated by the network service provider, by providing 224 identity and authentication information to the local network which 225 then uses a AAA infrastructure to validate the user, generate 226 accounting data for network usage and, authorize use of resources. 227 In addition to authorization and authentication, the MN may 228 provide the AAA Client with mobility management information (e.g. 229 embedded Binding Updates) to perform Mobile IP procedures. The AAA 230 Client can be an attendant, e.g. located in an Access Router, or 231 can be an AA Agent (Auth/Authorization agent) as the one 232 identified in UNAP. 234 * AAAv: is the AAA server in the visited network 236 * AAAh: is the AAA server in the home network of the MN 238 * HA: is a Home Agent 240 3.2. Assumptions 242 1) Mobile nodes are identified by their Network Access Identifier 243 (NAI) in an unique manner: 245 RFC2794 specifies an identifier for mobile nodes, the MN-NAI. The MN- 246 NAI is used by the AAA infrastructure to authenticate mobile IPv4 247 nodes. 249 The Mobile IPv6 specification mandates the existence of a security 250 association between the MN and its Home Agent (HA). In certain 251 scenarios and future deployments a MN may not have any Home Agent or 252 a home address assigned to it. A MN may instead have a security 253 association with the home AAA network element and may use this to 254 obtain a home address, and an HA. 256 In this document it is assumed that an IPv6 mobile node SHOULD 257 identified by a MN-NAI in a unique manner, and that an IPv6 mobile 258 node SHOULD be able to use its NAI instead of its home address to get 259 authenticated/authorized by the AAA infrastructure when roaming to 260 foreign domains. In fact, in general the network needs to 261 authenticate the user that is roaming, not the specific device, and 262 in the future there may be cases where a specific user is accessing 263 the network through several devices, or several users are accessing 264 the network through the same device. 266 In general, anyway, it is better to allow identification of an IPv6 267 mobile node also through the use of its IPv6 home address: this 268 allows users that have not been provided with a NAI by their home 269 domain to get authenticated and authorized by the AAA infrastructure. 271 The assumption made in this document is that: 273 * When the identifier associated with a mobile is the MN-NAI, it 274 SHOULD use the MN_NAI to get authenticated/authorized by the AAA 275 infrastructure, independently of whether the MN has or not a home 276 address 278 * when the MN does not have a MN-NAI but only a home address, the MN 279 MAY use the IPv6 home address to get authenticated/authorized by 280 the AAA infrastructure 282 2) Mobile Node and AAAh share a long-term key: 284 This long-term key provides network authentication and user 285 authentication; it can also be used in order to derive session keys 286 or local security associations as explained in the following 287 sections. 289 3) Communications between AAAv and AAAh are secure 291 This inter AAA security association allows the home and visited 292 domain to trust each other, and to exchange information in an 293 authenticated and protected manner. 295 4. Basic features supported in this Internet Draft 297 4.1. Authentication/authorization 299 Before giving access to the network, the visited network wants to 300 authenticate the user. The IPv6 mobile node may also want to 301 authenticate the network to prevent network impersonation such as 302 false BTS attacks. 304 The IPv6 mobile nodes SHOULD have the capability to use many 305 different authentication methods: The IPv6 mobile nodes could e.g. 306 use EAP at layer 3 for authentication: This document does not define 307 how the authentication information are exchanged between the Mobile 308 nodes and the network (it could be performed using the protocol 309 defined by the PANA WG, ICMPv6 messages) but the AAA infrastructure 310 allows that authentication and authorization; and the defined 311 Diameter messages support many round trips if the authentication 312 method adopted requires it. 314 4.2. Dynamic Home Agent assignment in Home domain 316 It is possible that when the mobile node needs to send a Binding 317 Update to its home agent to register its new primary care-of address, 318 the mobile node may not know the address of any router on its home 319 link that can serve as a home agent for it. For example, some nodes 320 on its home link may have been reconfigured while the mobile node has 321 been away from home, such that the router that was operating as the 322 mobile node's home agent has been replaced by a different router 323 serving this role. 325 The dynamic Home agent assignment feature also provides more 326 flexibility to the service provider: in general, a mobile node home 327 network may not assign statically a home agent to the mobile node to 328 maintain flexibility in the allocation of the home agent to achieve 329 better load sharing and fault tolerance. 331 In this case, the mobile node MAY use the dynamic home agent address 332 discovery mechanism to find the address of a suitable home agent on 333 its home link. 335 The current Mobile IPv6 specification describes a dynamic Home Agent 336 discovery procedure; as an alternative, this document describes 337 another home agent assignment procedure relying on the present AAA 338 infrastructure. 340 Whereas the current dynamic home agent address discovery mechanism 341 requires many round trips between the mobile node and its home domain 342 thus resulting in additional signaling over the access link and 343 between the home and visited domains; and also adding more delay in 344 the procedure, the solution relying on the AAA infrastructure only 345 requires one round trip. 347 And instead of sending specific IP address to request for a Home 348 address/Home agent in the Home/Visited domain, the proposed solution 349 is based on flags: less data thus needs to be sent over the access 350 link, and the AAAh (AAAv) instead creates the binding update message 351 when assigning the home agent. 353 4.3. Key distribution 355 Many security associations need to be dynamically established such 356 as: 358 * the security association between the mobile node and the visited 359 network to protect data (e.g. confidentiality and integrity 360 protection) over the access link 362 * the security association between the mobile node and the home 363 agent, to authenticate the binding update/acknowledgement 364 messages. According to the current specifications, after the 365 dynamic home agent address discovery is performed, the mobile node 366 sends a Binding Update to the selected Home agent to create the to 367 create a forwarding entry in the route table for the home address 368 associated with the MN. This Binding Update MUST be authenticated, 369 therefore a key distribution, e.g. IKE, may need to be executed. 370 This requires many messages to be exchanged between the mobile 371 node and the Home Agent. 373 As an alternative, after the authentication and authorization steps, 374 the AAA servers can be involved and play a role in the key generation 375 and/or the key distribution. 377 Diameter Mobile IPv4 Application defines one key distribution 378 mechanism; for Mobile IPv6, many different schemes could be applied 379 thus providing more flexibility and different properties as outlined 380 in the following sections. 382 4.4. Optimization of Binding Updates 384 As previously explained, in addition to authentication, authorization 385 and key distribution functionalities, the AAA servers can perform 386 mobility procedures such as dynamic home agent assignment. In case, 387 the IPv6 mobile node already has a pre-configured Home Agent, some 388 optimization can also be achieved by having the mobile node 389 encapsulating the binding update to its Home agent in the AAA request 390 message. 392 4.5. Summary 394 MN authentication is in general required to grant access to a MN to 395 the foreign domain. In fact, this may be needed in most of the cases 396 even if access to the foreign domain resources is free. Due to the 397 fact that the MN is away from its home network and hence considered 398 roaming the MN needs to perform also mobility procedures to obtain 399 reachability in the new location. Optionally, key distribution may be 400 need to take place. Using the AAA infrastructure to achieve these 401 functions can significantly reduce inter domain signaling and time 402 delay of the overall procedure performed by a MN to get access to the 403 foreign domain. 405 Currently the mobile node first gets authenticated using the AAA 406 infrastructure to obtain network access, then it may perform dynamic 407 home agent address discovery [4] and set up a security association 408 (using e.g. Internet Key Exchange [5]) with the selected Home agent 409 before sending a Binding Update. This will require many round trips 410 between the foreign domain and the home domain, whereas the use of 411 the AAA infrastructure provides a more efficient and quicker 412 alternative. 414 5. Mobile IPv6 Application Diameter messages 416 This memo introduces some new Command codes (AA-Registration-Request, 417 AA-Registration-Answer, Home-Agent-MIPv6-Request, Home-Agent- 418 MIPv6-Answer) and AVPs (MIP-Binding-Update AVP, MIP-Binding- 419 acknowledgement AVP, MIPv6-Mobile-Node-Address AVP, MIPv6-Home-Agent- 420 Address AVP, MIPv6-Feature-Vector AVP, Key-Request AVP, MN-Key- 421 Distribution AVP, Key-Distribution AVP) to achieve all the previously 422 identified functionalities. 424 5.1. Command Codes 426 This document introduces four new Command Codes: 428 * AA-Registration-Request Command (ARR) (Code TBD) 430 * AA-Registration-Answer Command(ARA) (Code TBD) 432 * Home-Agent-MIPv6-Request Command (HOR) (Code TBD) 434 * Home-Agent-MIPv6-Answer Command (HOA) (Code TBD) 436 5.2. AVPs 438 5.2.1. MIP-Binding-Update AVP 440 The MIP-Binding-Update AVP (AVP Code TBD) is of type OctetString and 441 contains the Mobile IP Binding Update message. 443 5.2.2. MIP-Binding-acknowledgement AVP 445 The MIP-Binding-acknowledgement AVP (AVP Code TBD) is of type 446 OctetString and contains the Mobile IP Binding Acknowledgement 447 message sent by the Home Agent to the MN. 449 5.2.3. MIPv6-Mobile-Node-Address AVP 451 The Mobile-Node-Address AVP (AVP Code TBD) is of type IPAddress and 452 contains the Mobile Node's Home Address. 454 5.2.4. MIPv6-Home-Agent-Address AVP 456 The Home-Agent-Address AVP (AVP Code TBD) is of type IPAddress and 457 contains the Mobile Node's Home Agent Address. 459 5.2.5. MIPv6-Feature-Vector AVP 461 The MIPv6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned32 and 462 allows for dynamic Home Agent assignment in Home Domain. In the basic 463 proposal, only one flag is defined; the other ones are reserved for 464 the enhanced version and for future utilization. 466 Flag values currently defined include: 468 1 Home-Agent-Requested: This flag is set to 1 when the 469 mobile node requests for a dynamic home agent 470 assignment. When this flag is set to 1, a dynamic 471 session key to be shared between the MN and the HA is 472 also required in order to authenticate BUs from the MN 473 to the HA: the MN may indicate through some Security Key 474 Request the methods it supports to compute it; or a 475 default method known to the MN and the AAAh should 476 exist(e.g. pre-set by the home domain and communicated 477 to the MN at subscription time). 479 5.2.6. Security Key AVPs 481 The AAA servers can play a role in key distribution and many methods 482 can be used with their own properties and characteristics. The 483 security keys AVPs format and utilization will be described in more 484 details in the next versions as well as the AAA servers' behaviors. 486 6. Information exchange between the mobile node and the AAA Client 488 Although this document is not intended to specify any particular 489 mechanism to convey information between the mobile node and the AAA 490 Client, the information that needs to be exchanged is described. The 491 set of information identified in the follow can actually be conveyed 492 between the mobile node and the network in a different suitable 493 manner outside the scope of this document (e.g. ICMP, the protocol 494 defined by the PANA WG, etc.). The extensions defined for Diameter 495 allow for any of these alternatives, thus enabling such extensions to 496 be deployed independently of the choice of the protocol used between 497 the MN and the network. 499 6.1. MIP Feature Data 501 Contrary to Mobile IPv4 where the Mobile nodes send a Registration 502 Request with specific IP addresses values to request for dynamic home 503 agent assignment in home/visited networks; the IPv6 mobiles nodes 504 SHOULD use some MIP Feature data whose content includes the 505 information required in the previously defined MIPv6 Feature Vector 506 AVP: The IPv6 mobile nodes will not use specific IPv6 addresses 507 values but use flags and this will significantly reduces the amount 508 of data to be sent over the access link. In addition, the attendant 509 will only need to encapsulate that data in the corresponding 510 MIPv6-Feature-Vector AVP. 512 The MIP Feature data could be sent as an extension to ICMPv6 513 messages, a new Destination Option or carried in any other way. 515 6.2. EAP Data 517 The IPv6 Mobile Node should be able to use different authentication 518 methods such as the different EAP types. 520 The EAP Data could be sent as an extension to ICMPv6 messages, 521 carried using the protocol defined by the PANA WG or any other 522 protocol. 524 6.3. Security Key Data 526 This document does not defines the protocol between the mobile nodes 527 and the network but the mobile node SHOULD use some key request to 528 indicate the keys it needs, but also the methods it supports to 529 generate them. 531 Those Security Key data SHOULD contain the relevant information so 532 the AAA client can create the corresponding Security Keys AVPs. 534 6.4. Embedded Data 536 The embedded data enables the mobile node to send a binding update at 537 the same time the mobile node gets authorized/authenticated by the 538 network (e.g. by mechanism that the protocol defined by the PANA WG 539 will provide) thus saving round trips between the home and the 540 visited domains. 542 7. Basic Protocol Overview 543 7.1. Authentication 545 Authentication is required before providing network access to the 546 user. 548 Different authentication should be supported to allow more 549 flexibility; but as demonstrated in [6], both network and user 550 authentication should be supported. 552 And current authentication mechanisms, even those recently specified 553 in different standardization fora (e.g. CAVE based security functions 554 in IS41 Systems) have security flaws. 556 For these reasons, even as previously mentioned any existing 557 authentication could be used, in the following illustrations and 558 procedures, a mutual challenge response based authentication method 559 will be suggested and used as default. 561 The authentication mechanism assumed here assumes that a Local 562 Challenge is broadcast over the access link e.g. in Router 563 Advertisement messages. 565 7.2. Information flows 567 Basic Procedure with dynamic Home Agent assignment in the Home 568 network or pre-configured Home Agent 570 Mobile Node AAA Client AAAv AAAh Home Agent 571 ----------- ----------- ------------ ---------- ---------- 572 Advertisement & 573 <---1.1 - Challenge 574 -1.2 --------> 575 1.3 ARR-------------> 576 1.4 ARR------------> 577 1.5 HOR-------> 578 <------1.6 HOA 579 <---------1.7 ARA 580 <------------1.8 ARA 581 <-------1.9 583 7.3. MN Considerations 585 7.3.1. Generation of information in MN 587 1) When entering a new network or at power up, the MN listens to the 588 router advertisements and retrieves: 590 The Local Challenge 591 The visited network identifier 592 The information to derive the CoA 594 2) It computes the CoA, and based on the following information, 596 * The NAI 597 * The long-term security key shared with its AAAh 598 * The Home Address: in the basic mode, the mobile node is 599 assumed to have a pre-configured Home IP address 600 * The Home Agent (if any), otherwise MN can request to have one 601 assigned 603 creates a message with the CoA as the Source IP address and the AAA 604 Client address as the Destination IP address. (The MN can learn the 605 IP address of the AAA Client through router advertisements or others 606 mechanisms outside the scope of this document.) As previously 607 explained, the mobile node also sends its NAI. 609 3) The MN optionally generates a Host Challenge that it will send to 610 the network for both network authentication and anti replay attacks. 611 Then the MN computes the MN authentication data using the long-term 612 key, the host challenge, the visited network identifier, the local 613 challenge, and an authentication algorithm it shares with its home 614 network. The MN authentication data is then sent to the AAA Client, 616 4) If the MN does not have a Home Agent and requests one, the MN 617 includes some MIP Feature data with the Home-Agent-Requested flag set 618 to 1. The home agent will then be assigned by the home AAA server, 619 and the binding update will be sent by the AAA server to the Home 620 Agent on behalf of the mobile node that, in turn, does not need to 621 send any. 623 If the MN have a pre configured Home Agent, it may creates the 624 binding update message and sends it encapsulated to the AAA client. 625 The Binding Update message will be forwarded to the designated home 626 agent via the AAA infrastructure. This binding update message has 627 the MN IP CoA as the source IP address, the pre-configured HA as the 628 destination IP address and the BU option with the pre-configured Home 629 IP address in the Home address option. 631 5) The MN may also requests for some security keys thanks to the 632 Security Key Request. 634 The MN SHOULD perform authentication in the following cases: 636 * When changing visited domain: MN can know that by 637 listening the router advertisements 638 * When requesting session keys 639 * When requesting a Home Agent assignment 641 7.3.2. Replies to MN 643 When receiving the reply from the AAA Client, the MN: 645 * Authenticates the network thanks to the network authentication 646 data sent by the AAA Client 648 * If the MN requested a Home agent, it will learn and store the Home 649 Agent address from the source IP address of the Home Binding 650 Acknowledgement. 652 The MN creates the security associations from the keying material 653 received. 655 7.4. AAA Client Operation 657 As indicated above, the mobile node may interact with the AAA Client 658 to perform authentication/authorization and optionally Mobile IP 659 procedures. Thus, the AAA client may perform authentication functions 660 and optionally Mobile IP functions 662 When the AAA Client receives an authentication request message from a 663 IPv6 Mobile node: 665 The AAA Client first verifies the freshness of the request thanks to 666 the Local Challenge contained in it (i.e. the MN may use an older 667 Local Challenge) and if successful, performs Duplicate Address 668 Detection and creates a Diameter ARR (AA-Registration-Request) [7] 669 message carrying the following information to the AAAh: 671 * User Name AVP [7] carrying the user's NAI 673 * EAP AVP to carry the authentication data for mutual authentication 674 derived from the content of the received authentication data 676 * if some MIP feature data were received from the MN, a 677 MIPv6-Feature-Vector AVP whose content is derived from the MIP 678 feature data, sent within the ARR message it sends to the AAAv 680 * MIP-Binding Update AVP if the MN sent a Home Binding Update as 681 Embedded data 683 * MIPv6-Home-Agent-Address AVP if the MN sent a binding update 684 message: the Home agent address value is extracted from the 685 Destination IP address field of the embedded home binding update. 686 This AVP enables the AAAh to know where to send the MIP-Home- 687 binding-Update AVP if one was present. 689 * if the MN provides some Key Request data, some Security Key AVPs 690 whose content is derived from the Key Request data. 692 When receiving an ARA [7] (AA-Registration-Answer) message from AAAv, 693 the AAA Client converts the message to the appropriate protocol to 694 the MN; this message carries: 696 * the authentication data 698 * Binding Acknowledgement as Embedded Data if MN sent a home Binding 699 Update or requested for a dynamic home agent assignement. 701 The message may also include: 703 * Keying material to set up the different session keys, converted 704 and conveyed in the appropriate protocol by the AAA Client from 705 the Security Key AVPs. When the MN asks for a dynamic Home Agent, 706 AAAh SHOULD compute the security key to be shared between MN and 707 the HA for authenticating subsequent Binding Updates, and sends 708 the corresponding keying material to the MN. 710 7.5. AAAv Operation 712 When AAAv receives an ARR message [7]: 714 First the AAAv verifies the message is coming from a valid AAA Client 715 and then, checks the MIPv6 Feature Vector AVP, and then sends it to 716 the MN's home AAA server. 718 When receiving a ARA message from the AAAh, the AAAv MAY optionally, 719 according to the behaviour specific for speficic EAPs or other 720 mechanisms defined elsewhere, store locally information contained in 721 the AVPs of the message received from the AAAh (e.g. session keys, 722 etc.) and then forwards the message to the AAA Client. 724 7.6. AAAh operations 726 * When receiving an ARR message from an AAAv, the AAAh first 727 verifies the message is coming from a valid AAAv. Security 728 associations between AAA server are outside the scope of the 729 present document. 731 The AAAh then authenticates the user using the NAI provided by the MN 732 as MN identity. If the mobile Node is successfully authenticated: 734 * AAAh also computes some network authentication data based on the 735 Host Challenge and eventually other information depending on the 736 authentication algorithm adopted. 738 Depending on the authentication method requirements, the AAAh may 739 exchange many messages with the MN via the AAAv (e.g. for a user 740 authentication mechanism that requires more than one round-trip): 741 AAAh may send a ARA Command with the appropriate authentication 742 information and indication, which will be converted to EAP data by 743 the AAA Client to the MN and conveyed to the MN in a suitable manner 744 (outside the scope of this document). The number of round trips 745 varies depending on the authentication mechanism used. 747 * If the MN asks for some security keys, the AAAh performs the 748 appropriate steps and eventually sends the corresponding messages 749 to achieve the key distribution: many mechanisms exist and some of 750 them will be described later on. Such steps may require the AAAh 751 to distribute keys and keying material to the MN, to other AAA 752 servers or other nodes. 754 * If a MIPv6-Home-Agent-Address AVP is present: the AAAh checks that 755 the address is that of a known and valid Home Agent, and one that 756 the Mobile Node is allowed to request. AAAh then forwards the MIP- 757 Home-Binding-Update AVP to the Home Agent in a HOR (Home-Agent- 758 MIP-Request) message. 760 * If no MIPv6-Home-Agent-Address AVP is present, AAAh looks at the 761 MIPv6-Feature-Vector AVP if any. If present, AAAh performs the 762 dynamic home agent assignment in the Home network: 764 Mobile Node AAA Client AAAv AAAh Home Agent 765 ----------- ----------- ------------ ---------- ---------- 766 Advertisement & 767 <---1.1 -- Challenge 768 -1.2 --------> 769 1.3 ARR-------------> 770 1.4 ARR----------> 771 1.5 HOR-------> 772 <--------1.6 HOA 773 <-------1.7 ARA 774 <------------1.8 ARA 775 <-------1.9 777 (1.5) AAAh allocates a Home agent on behalf of the MN: this can be 778 done in a variety of ways, including using a load balancing 779 algorithm in order to keep the load on all HAs equal. 781 * AAAh sends a HOR message to the HA including a newly created 782 binding update. 784 * AAAh sends some security keying material to allow the Home 785 Agent to comupte the key(s) for the security association 786 between the MN and the Home Agent to authenticate future 787 Binding Updates. 789 (1.6) the Home Agent creates the Binding Cache and computes the 790 key(s) for the security association with the MN from the data 791 received. It also generates a Binding Acknowledgement message to 792 be sent encapsulated to the MN. 794 * The HA sends a HOA message to the AAAh including the Binding 795 Ack. 797 (1.7) AAAh may also compute other keying material according to the 798 keys requested by the MN and send it to the MN passing through the 799 AAAv. 801 * AAAh then send an ARA message to the AAAv including the MIP- 802 Binding-acknowledgement AVP if the MN sent an embedded BU or 803 request for a HA. 805 7.7. Home Agent Behavior 807 Upon receipt of the HOR, the Home Agent first processes the DIAMETER 808 message: if the HOR is invalid, a HOA is returned with the Result- 809 Code AVP set to DIAMETER_ERROR_BAD_HOR. Otherwise, the Home Agent 810 processes the MIP-Binding-update AVP and creates the Binding 811 Acknowledgement, encapsulating it within the MIP-binding- 812 acknowledgement AVP. 814 HA also creates the Binding Cache and computes the key(s) for the 815 security association with the MN from the data received. 817 8. Enhanced features 819 In addition to the previously described features, additional features 820 can be supported by the AAA infrastructure for the inter-domain 821 roaming of an IPv6 mobile node, thus providing more flexibility and 822 allowing new options to the services providers to develop business 823 models. 825 A IPv6 mobile node can have a pre-configured home address, may have a 826 pre-configured home agent or request for one and, as explained in the 827 previous section, the basic features of the Mobile IPv6 Diameter 828 Application allow an optimization of the authentication, the binding 829 update, the optional home agent assignment in the home domain and the 830 key distribution procedures. 832 Optionally, two enhanced features are suggested: 834 * The dynamic Home agent assignment in the Visited Domain 835 * The dynamic Home address assignment 837 8.1. Dynamic Home Agent/ Home Address assignment in Visited domain 839 The Dynamic Home Agent assignment in visited networks allows more 840 flexibility and allows new business scenarios. As an example, service 841 providers may just own a AAA server for accounting purposes and, 842 thanks to roaming agreements, they may offer Mobile IP services to 843 its subscribers. Another scenario where this can be applied is when 844 IPv6 mobile nodes need to obtain reachability from other CN only at 845 the application level, i.e. through a SIP infrastructure. This may be 846 the case of a basic IPv6 MN supporting only voice services through 847 SIP. In such cases, when a CN needs to reach the MN an identifier at 848 the application level (e.g. MN SIP URL) is used, and the CN does not 849 need to know the home address of the MN. Somebody may argue that 850 Mobile IP is not needed at all in such cases, but it may instead be 851 used to support mobility between the initial point of attachment 852 (i.e. when the MN powered up in the foreign domain) and following 853 points of attachment in the foreign domain. 855 8.2. Dynamic Home address assignment in Home Domain 857 The mobile node may not always have a pre-configured IPv6 address and 858 may need to have one dynamically assigned. In addition since the Home 859 Agent and the mobile node home address need to be on the same link, 860 to support dynamic home agent assignment in visited networks, dynamic 861 home address assignment in visited networks is supported. 863 Finally, this dynamic Home address feature provides more flexibility 864 to the service provider even when the Home agent is to be assigned in 865 the Home network since the Home agent and the home address should be 866 on the same subnet. Additionally, the scenario described in section 867 7.2 of a MN node needing reachability only at the application layer 868 applies to this case too. 870 8.3. Enhanced AVPs 872 In addition to the Command Codes and AVPs described in section 4, 873 some new AVP need to be defined to support the enhanced features. 875 8.3.1. MIPv6-Feature-Vector AVP 877 In the extended mode, dynamic home agent assignment in the visited 878 network is feasible.Additional flags of the MIPv6-Feature-Vector AVP 879 are therefore defined. 881 The following flags allow the Visited AAA server, AAAv, to inform of 882 its capabilities and if the Home agent is assigned in the visited 883 network, the Home address must also be assigned in the visited 884 network. 886 The AAA Client includes a MIPv6-Feature-Vector AVP within the ARR 887 message it sends to the AAAv if the MN sent some MIP Feature data. 889 Flag values currently defined include: 891 1 Home-Agent-Requested: This flag is set to 1 when the 892 mobile node requests for a dynamic home agent 893 assignment. When this flag is set to 1, a dynamic 894 session key to be shared between the MN and the HA is 895 also required in order to authenticate BUs from the MN 896 to the HA: the MN may indicate through some Security Key 897 Request the methods it supports to compute it; or a 898 default method known to the MN and the AAAh should 899 exist(e.g. pre-set by the home domain and communicated 900 to the MN at subscription time). 902 2 Mobile-Node-Home-Address-Requested flag: This flag is 903 set to 1 if the mobile node does not have any Home 904 address and requires one. Default value is 0. 906 4 Home-Address-Allocatable-Only-in-Home-Domain flag: This 907 flags is set to 1 if the mobile node requests for one 908 Home address and wants it to be assigned by its home 909 network. Default value is 0 and means that the MN does 910 not have any preference on whether the Home Address 911 shall be allocated in the home domain and visited 912 domain. 914 8 Home-Agent-in-Visited-Domain flag: The mobile node 915 indicates its preference to have its Home Agent 916 allocated in the visited domain by having this flag set 917 to 1 919 16 Visited-Home-Agent-Available flag: The Visited Domain 920 sets this flag to 1 if the MN asks a dynamic Home Agent 921 assignment in the Visited Domain and the Visited Domain 922 agrees to allocate one to the MN. 924 9. Enhanced Protocol Overview 926 The enhanced mode allows dynamic home agent assignment in the visited 927 network and dynamic home address assignment. The mobile node may not 928 have any preconfigured home address nor any home agent. The following 929 text describes the different entities' behaviors in the Enhanced 930 mode. 932 The authentication procedure is the same than the one described 933 above. 935 All the functionalities (key distribution, optimization of Binding 936 Upate, dynamic Home Agent assignment in Home network) of the basic 937 mode are present but in addition the Home agent can be assigned in 938 the visited network and the home address can be dynamically assigned 939 either in the home or visited domain: the entities behaviours and the 940 way the corresponding AVPs are processed, are explained 942 9.1. Information flow 944 Enhanced Procedure with dynamic Home agent assignment in the visited 945 network and dynamic home address assignment in home or visited domain 947 Mobile Node AAA Client Home Agent AAAv AAAh 948 ----------- ----------- ------------- ---------- ---------- 949 <---2.1 Challenge--- 950 -2.2 -----> 951 ----------2.3 ARR-------------> 952 ---2.4 ARR----> 953 <--2.5 HOR----- 954 <---2.6 HOR--- 955 ----2.7 HOA---> 956 ---2.8 HOA----> 957 <--2.9 ARA----- 958 <-----------2.10 ARA------------ 959 <-2.11-- 961 9.2. MN Considerations 963 9.2.1. Generation of information in MN 965 The mobile node performs the same steps as in the basic mode (steps 966 (1), (2), (3) section 6.3.1) and then 968 4) If the MN does not have a Home Address and requests one, the MN 969 also includes some MIP Feature data with the Mobile-Node-Home- 970 Address-Requested flag set to 1: 972 * If MN wants its Home address to be allocated by its home network, 973 it also sets the value of Home-Address-Allocatable-Only-in-Home- 974 Domain flag to 1. 976 If the MN does not have a Home Agent and requests one, the MN also 977 includes some MIP Feature data with the Home-Agent-Requested flag set 978 to 1. The home agent will then be assigned by the AAA server, and the 979 binding update will be sent by the AAA server to the Home Agent on 980 behalf of the mobile node that, in turn, does not need to send any. 982 * If MN wants its Home agent to be allocated by the visited network, 983 it also sets the Home-Agent-in-Visited-Network flag to 1. 985 The following table describes the different supported cases and the 986 flags that need to be set according to the needs: 988 HD means Home Domain 989 VD means Visited Domain 990 NP means MN has No Preference 991 X means not supported 993 P: Mobile-Node-Home-Address-Requested flag 994 H: Home-Address-Allocatable-Only-in-Home-Domain 995 A: Home-Agent-Requested 996 V: Home-Agent-In-Visited-Network 998 +---------+------------------------------------------------+ 999 | | Home agent Requested | 1000 +---------+---+--------------------+-----------------------+ 1001 | | | YES | NO | 1002 | +---+--+-----+-----+-----+-----------------------+ 1003 | | | | HD | VD | NP | | 1004 |Home addr| +--+-----+-----+-----+-----------------------+ 1005 |Requested| |HD| PAH | x | x | PH | 1006 | | +--+-----+-----+-----+-----------------------+ 1007 | |YES|VD| x |PAV | x | x | 1008 | | +--+-----+-----+-----+-----------------------+ 1009 | | |NP| x | x |PA | P | 1010 | +---+--+-----+-----+-----+-----------------------+ 1011 | | | | | | | | 1012 | | NO| | A* | x | x | no MIP Feature data | 1013 | | | | | | | | 1014 +---------+---+--+-----+-----+-----+-----------------------+ 1016 A*: MN already has a home address in its Home network and may request 1017 for a Home Agent. The HA can thus only be assigned in the Home 1018 Network. 1020 While the MN gets authenticated and authorized, if the MN already has 1021 a home address and a home agent, it can send a Home Binding Update 1022 together with the request to be authorized and authenticated to save 1023 one round trip over the access link and between the visited and home 1024 networks. This binding update is in this case sent as Embedded Data: 1026 The Home Binding Update has: 1028 * The H flag set to 1. 1029 * The source IP address equals to the CoA 1030 * The destination IP address set to the Home agent address 1031 * The Home Address option set to the MN Home address 1033 5) The MN may also requests for some security keys thanks to the 1034 Security Key Request. 1036 The MN SHOULD perform authentication in the following cases: 1038 * When changing visited domain: MN can know that by 1039 listening the router advertisements 1040 * When requesting session keys 1041 * When requesting a Home Agent assignment 1042 * When requesting a home address assignment 1044 9.2.2. Replies to MN 1046 When receiving the reply from the AAA Client, the MN: 1048 * Authenticates the network thanks to the network authentication 1049 data sent by the AAA Client 1051 * If the MN requested a Home agent, it will learn and store the Home 1052 Agent address from the source IP address of the Home Binding 1053 Acknowledgement. 1055 * If the MN did not have a Home IP address and requested for one, 1056 the MN will learn and store the assigned home address from the 1057 home address option of the Home Binding Acknowledgement (embedded 1058 data). 1060 The MN creates the security associations from the keying material 1061 received. 1063 9.3. AAA Client Operation 1065 As indicated above, the mobile node may interact with the AAA Client 1066 to perform authentication/authorization and optionally Mobile IP 1067 procedures. Thus, the AAA client may perform authentication functions 1068 and optionally Mobile IP functions 1070 When the AAA Client receives an authentication request message from a 1071 IPv6 Mobile node: 1073 The AAA Client first verifies the freshness of the request thanks to 1074 the Local Challenge contained in it (i.e. the MN may use an older 1075 Local Challenge) and if successful, performs Duplicate Address 1076 Detection and creates a Diameter ARR (AA-Registration-Request) [7] 1077 message carrying the following information to the AAAh: 1079 * User Name AVP [7] carrying the user's NAI 1081 * EAP AVP to carry the authentication data for mutual authentication 1082 derived from the content of the received authentication data 1084 * if some MIP feature data were received from the MN, a 1085 MIPv6-Feature-Vector AVP whose content is derived from the MIP 1086 feature data, sent within the ARR message it sends to the AAAv 1088 * MIP-Binding Update AVP if the MN sent a Home Binding Update as 1089 Embedded data 1091 * MIPv6-Home-Agent-Address AVP if the MN sent a Home binding update: 1092 the Home agent address value is extracted from the Destination IP 1093 address field of the embedded home binding update. This AVP 1094 enables the AAAh to know where to send the MIP-Home-binding-Update 1095 AVP if one was present. 1097 * if the MN provides a Key Request, some Security Key AVPs whose 1098 content is derived from the Key Request. 1100 When receiving an ARA [7] (AA-Registration-Answer) message from AAAv, 1101 the AAA Client converts the message to appropriate protocol to the 1102 MN; this message carries: 1104 * the authentication data 1106 * Binding Acknowledgement as Embedded Data if MN sent a home Binding 1107 Update or requested for a dynamic home agent assignment. 1109 The message may also include: 1111 * Keying material to set up the different session keys, in different 1112 Security Key Data created by the AAA Client from the Security Key 1113 AVPs. When the MN asks for a dynamic Home Agent, AAAh must compute 1114 the security key to be shared between MN and the HA for 1115 authenticating subsequent Binding Updates, and sends the 1116 corresponding keying material to the MN. 1118 9.4. AAAv Operation 1120 When AAAv receives an ARR message [7]: 1122 First the AAAv verifies the message is coming from a valid AAA Client 1123 and then, checks the MIPv6 Feature Vector AVP: 1125 * If the MN requested a Home Agent by setting the Home-Agent- 1126 Requested flag to 1, and does not specify that this one should be 1127 assigned only in its Home domain by setting the Home-Address- 1128 Allocatable-Only-in-Home-Domain flag to 1, the AAAv checks if it 1129 can allocate a Home Agent for the mobile node in the visited 1130 domain. If AAAv can allocate a Home Agent in the visited domain, 1131 it indicates this to the AAAh by setting the Visited-Home-Agent- 1132 Available flag to 1 of the MIPv6 Feature Vector AVP forwarded to 1133 the AAAh. 1135 When receiving a HOR message from the AAAh for a dynamic Home Agent 1136 assignment in the visited network, the AAAv performs the dynamic Home 1137 agent assignment and MAY perform some key distribution depending on 1138 the mechanisms. 1140 When receiving a ARA message from the AAAh, the AAAv MAY optionally, 1141 according to the behavior specific for speficic EAPs or other 1142 mechanisms defined elsewhere, store locally information contained in 1143 the AVPs of the message received from the AAAh (e.g. session keys, 1144 etc.) and then forwards the message to the AAA Client. 1146 9.5. AAAh operations 1148 * When receiving an ARR message from an AAAv, the AAAh first 1149 verifies the message is coming from a valid AAAv. Security 1150 associations between AAA server are outside the scope of the 1151 present document. 1153 The AAAh then authenticates the user using the NAI provided by the MN 1154 as MN identity. If the mobile Node is successfully authenticated: 1156 * AAAh also computes some network authentication data based on the 1157 Host Challenge and eventually other information depending on the 1158 authentication algorithm adopted. 1160 Depending on the authentication method requirements, the AAAh may 1161 exchange many messages with the MN via the AAAv (e.g. for a user 1162 authentication mechanism that requires more than one round-trip): 1163 AAAh may send a ARA Command with the appropriate authentication 1164 information and indication, which will be converted to EAP data by 1165 the AAA Client to the MN or conveyed to the MN in other suitable 1166 manner (outside the scope of this document). The number of round 1167 trips varies depending on the authentication mechanism used. 1169 * If the MN asks for some security keys, the AAAh performs the 1170 appropriate steps and eventually sends the corresponding messages 1171 to achieve the key distribution: many mechanisms exist and will be 1172 described later on. Such steps may require the AAAh to distribute 1173 keys and keying material to the MN, to other AAA servers or other 1174 nodes. 1176 * If a MIPv6-Home-Agent-Address AVP is present: the AAAh checks that 1177 the address is that of a known and valid Home Agent, and one that 1178 the Mobile Node is allowed to request. AAAh then forwards the MIP- 1179 Home-Binding-Update AVP to the Home Agent in a HOR (Home-Agent- 1180 MIP-Request) message including the appropriate key material to set 1181 up the security association between the MN and the Home Agent. 1183 * If no MIPv6-Home-Agent-Address AVP is present, AAAh looks at the 1184 MIPv6-Feature-Vector AVP if any. Depending on the mobile node 1185 request (Home-Agent-in-Visited-Network flag, Home-Address- 1186 Allocatable-Only-in-Home-Domain), the visited network capabilities 1187 (Visited-Agent-Available AVP) and the local policy, the AAAh 1188 decides whether to assign the HA in the home or visited network: 1190 9.5.1. Home Agent Assignement in Visited Network 1192 If the AAAh accepts the HA to be assigned in the visited domain, the 1193 following exchange of messages takes place: 1195 Mobile Node AAA Client Home Agent AAAv AAAh 1196 ----------- ----------- ------------- ---------- ---------- 1197 <---2.1 Challenge- 1198 -2.2 ----> 1199 ----------2.3 ARR-------------> 1200 ---2.4 ARR----> 1201 <--2.5 HOR----- 1202 <---2.6 HOR----- 1203 ----2.7 HOA-----> 1204 ---2.8 HOA----> 1205 <--2.9 ARA----- 1206 <-----------2.10 ARA------------ 1207 <-2.11 --- 1209 (2.5): AAAh sends a HOR message to the AAAv with neither any 1210 MIPv6-Mobile-Node-Address AVP nor any MIPv6-Home-Agent-Address 1211 AVP. 1213 * AAAh may send some keying material for HA to derive the key(s) 1214 for the security association between the MN and the Home Agent 1215 to authenticate future Binding Updates depending on the key 1216 distribution mechanism chosen 1218 * AAAh may also send other keying material according to the keys 1219 requested by the MN 1221 (2.6): AAAv assigns a Home agent and then creates and sends it a 1222 newly created Binding Update encapsulated in the HOR message. 1224 * AAAv may assign Home IP address for the MN and informs the Home 1225 Agent by adding a MIPv6-Mobile-Node-Address AVP in the HOR 1226 message; or let the Home Agent assigns the Home address by not 1227 providing a MIPv6-Mobile-Node-Address AVP in the HOR message. 1229 * AAAv may forward to the Home Agent some keying material 1230 depending on the key distribution mechanism adopted to set up 1231 the security association between the MN and the Home Agent 1233 (2.7): The Home agent assigns a Home IP address if requested and 1234 creates a Binding Cache for the MN. 1236 * The Home agent creates the Security Association according to 1237 the mechanism adopted 1239 * The Home Agent creates the Binding Acknowledgement to be sent 1240 encapsulated to the MN. 1242 * The Home Agent sends back a HOA to the AAAv to inform it of the 1243 status: it includes the assigned Mobile Node Home Address if 1244 the Home Agent assigned one; it also includes the Binding ack 1245 created by the Home Agent to be sent encapsulated to the MN. 1247 (2.8) The AAAh is informed of the assigned Home IP address 1248 (contained in the MIPv6-Mobile-Node-Address AVP) and the Home 1249 Agent address (contained in the MIPv6-Home-Agent-Address AVP) by 1250 the HOA message sent from the AAAv. 1252 (2.9) The AAAh sends the AAAv an ARA carrying the Home IP address, 1253 the Home Agent IP address, the keying material with the previous 1254 information. 1256 9.5.2. Home Agent Assignment in Home Network 1258 If the AAAh decides to assign the HA in the Home network, the 1259 following exchange of messages takes place: 1261 Mobile Node AAA Client AAAv AAAh Home Agent 1262 ----------- ----------- ------------ ---------- ---------- 1263 Advertisement & 1264 <---3.1 -- Challenge 1265 -3.2 -----> 1266 3.3 ARR-------------> 1267 3.4 ARR--------> 1268 3.5 HOR------> 1269 <----3.6 HOA 1270 <------3.7 ARA 1271 <------------3.8 ARA 1272 <-------3.9 1274 (3.5) AAAh allocates a Home agent on behalf of the MN: this can be 1275 done in a variety of ways, including using a load balancing algorithm 1276 in order to keep the load on all HAs equal. 1278 * AAAh sends a HOR message to the HA including a newly created 1279 binding update and: 1281 * The AAAh may allocate a home address for the mobile node and 1282 include it in a MIPv6-Mobile-Node-Address AVP within the HOR or 1283 else leave this allocation responsibility for the HA by leaving 1284 the Home address option of the binding update to zero and not 1285 sending any MIPv6-Mobile-Node-Address AVP. 1287 * AAAh sends some security keying material to allow the Home Agent 1288 to compute the key(s) for the security association between the MN 1289 and the Home Agent to authenticate future Binding Updates. 1291 (3.6) If the Home Agent does not receive any MIP-Mobile-node-address, 1292 and receives a BU with a Home address equals to 0, it assigns a Home 1293 IP address for that user; then creates the Binding Cache and computes 1294 the key(s) for the security association with the MN from the data 1295 received. It also generates a Binding Acknowledgement message to be 1296 sent encapsulated to the MN. 1298 * The HA sends a HOA message to the AAAh including the Binding Ack 1299 and eventually the assigned Home IP address if one was requested. 1301 (3.7) AAAh may also compute other keying material according to the 1302 keys requested by the MN and send it to the MN passing through the 1303 AAAv. 1305 * AAAh then send an ARA message to the AAAv including the 1306 MIPv6-Mobile-Node-Address and MIPv6-Home-Agent-Address AVPs if the 1307 MN did not have any Home address or Home agent. 1309 9.6. Home Agent Behavior 1311 Upon receipt of the HOR, the Home Agent first processes the DIAMETER 1312 message: if the HOR is invalid, a HOA is returned with the Result- 1313 Code AVP set to DIAMETER_ERROR_BAD_HOR. Otherwise, the Home Agent 1314 processes the MIP-Binding-update AVP and creates the Binding 1315 Acknowledgement, encapsulating it within the MIP-binding- 1316 acknowledgement AVP. 1318 If a home address is needed, the Home Agent assigns one and includes 1319 the address in both the Binding acknowledgement message (Home address 1320 option) and in the MIPv6-Mobile-Node-Address AVP. 1322 HA then creates the Binding Cache and computes the key(s) for the 1323 security association with the MN from the data received. 1325 10. Key distribution 1327 As identified in the previous sections, many security keys need to be 1328 set up and shared between the IPv6 mobile nodes and other network 1329 entities, such as: 1331 * the key between the mobile node and its Home Agent to authenticate 1332 the binding Update and Binding acknowledgement messages 1334 * the key between the mobile node and the access router to protect 1335 (e.g. for confidentiality and integrity protection) the data over 1336 the access link. 1338 The AAA entities can play a major role in the computation and 1339 distribution of these security keys. Two key distribution methods, 1340 relying on this AAA infrastructure and allowing authenticated key 1341 distribution, are proposed. 1343 10.1. Key distribution based on Random numbers 1345 The home AAA server generates one random number for each required 1346 security key. Then taking as inputs, to a key derivation algorithm 1347 shared with the mobile node, this random number, the long term key 1348 shared with the mobile node and optionally other data, the home AAA 1349 server derives the desired security key. 1351 This one is securely transmitted to the network entity, the mobile 1352 node wants to share the key with. 1354 And the random number is sent to the Mobile node which can derive the 1355 security session key thanks to the knowledge of the long term key and 1356 the key derivation algorithm shared with its home network. 1358 This key distribution based on Random numbers is currently used in 1359 cellular networks and in the Diameter Mobile IPv4 Application [1] 1361 10.2. Key distribution based on Diffie Hellman 1363 As another possibility, the key distribution can be based on the 1364 Diffie Hellman mechanism. 1366 Diffie Hellman allows two nodes to establish a shared secret key in a 1367 secure fashion. It, although, has a major vulnerability since it does 1368 not allow a node to figure out with whom it is establishing that 1369 secret key. To defeat this vulnerability, the two nodes public values 1370 must be authenticated. 1372 The AAA infrastructure, and more particularly the security 1373 association between the Mobile node and its home network (AAAh) and 1374 the security association between the AAAv and AAAh, can provide that 1375 authentication. 1377 If the mobile node wants to set up a securiy association with an 1378 entity in the visited domain (e.g. home agent assigned in the visited 1379 domain), the mobile node first sends its public Diffie Hellman value 1380 DH_MN authenticated with the long term security association shared 1381 with its AAAh. If the entity with whom the MN wants to set up a 1382 security association is in the visited domain, AAAv retrieves the 1383 entity's Diffie Hellman public value using intra domain security and 1384 sends this value, authenticated with the security association it 1385 shares with the AAAh, to the home network of the MN together with the 1386 message from the MN. 1388 AAAh authenticates the Diffie Hellman Public values of the entity and 1389 the MN. It then sends the MN's Diffie Hellman Public Value to the 1390 AAAv using the security association it shares with AAAv, and sends 1391 the entity's Diffie Hellman Public Value to the MN, authenticated 1392 with the security association shared with the MN. 1394 In this way, AAAh is used to authenticate the Diffie Hellman public 1395 values but as a difference with the previous method, since it does 1396 not have knowledge of the secret values, it can not derive the value 1397 of the session key. This method thus allow to securely distribute 1398 the security keys without having the AAA servers being aware of the 1399 value of those keys. AAA servers are here used as certificate 1400 authorities. 1402 11. Conclusions 1404 The Diameter Mobile IPv6 application defined in this document allows 1405 for support of authentication and authorization of IPv6 mobile nodes 1406 roaming between different domains. In addition, it support key 1407 distribution and mobility by optimizing these procedures. The 1408 application defines also new enhanced features that introduce 1409 flexibility in the definition of business models for service 1410 providers and allow for different types of terminals. 1412 This first version focuses on the different functionalities involved 1413 in the support by the AAA infrastructure of inter domain roaming of 1414 Mobile IPv6 nodes. 1416 12. Security Considerations 1418 The Diameter Mobile IPv6 application defined in this document does 1419 not create new security breaches for the IPv6 MN and the foreign and 1420 visited domain. On the contrary, it allows for an effective and 1421 efficient MN authentication and authorization when roaming between 1422 different domains. 1424 13. References 1426 [1] Pat R. Calhoun, Charles E. Perkins, "Diameter Mobile IPv4 1427 Application" Internet draft, Internet Engineer Task Force, 1428 November 2001 1430 [2] Diffie, W. and Hellman, M., "New Directions ijn 1431 Cryptography", IEEE Transactions on Information Theory, 1432 Vol. IT-22, Nov. 1976, pp. 664-654 1434 [3] Franck Le, Stefano M. Faccin, "Key distribution mechanisms 1435 for Mobile IPv6" Internet draft, Internet Engineer Task 1436 Force, February 2001 1438 [4] David B. Johnson, Charles Perkins, "Mobility Support in 1439 IPv6" Internet draft, Internet Engineer Task Force, 1440 November 2001 1442 [5] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 1443 RFC 2409, Internet Engineer Task Force, November 1998 1445 [6] Sarvar Patel, "Weaknesses of North American Wireless 1446 Authentication Protocol", IEEE Personal Communications, 1447 June 1997 1449 [7] Pat R. Calhoun, Haseeb Akhtar, Jari Arkko, Erik Guttman, 1450 Allan C. Rubens,Glen Zorn, "Diameter Base Protocol" 1451 Internet draft, Internet Engineer Task Force, November 2001 1453 14. Authors' Addresses 1455 Stefano M. Faccin 1456 Nokia Research Center 1457 6000 Connection Drive 1458 Irving, TX 75039 1459 USA 1461 Phone: +1 972 894-4994 1462 E-mail: stefano.faccin@nokia.com 1464 Franck Le 1465 Nokia Research Center 1466 6000 Connection Drive 1467 Irving, TX 75039 1468 USA 1470 Phone: +1 972 374-1256 1471 E-mail: franck.le@nokia.com 1473 Basavaraj Patil 1474 Nokia Corporation 1475 6000 Connection Drive 1476 Irving, TX 75039 1477 USA 1479 Phone: +1 972-894-6709 1480 E-Mail: basavaraj.patil@nokia.com 1482 Charles E. Perkins 1483 Nokia Research Center 1484 313 Fairchild Drive 1485 Mountain View, California 94043 1486 USA 1488 Phone: +1 650-625-2986 1489 E-Mail: charles.perkins@nokia.com