idnits 2.17.1 draft-le-aaa-diameter-mobileipv6-03.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 187: '...is specification MAY advertise support...' RFC 2119 keyword, line 257: '...ssumed that an IPv6 mobile node SHOULD...' RFC 2119 keyword, line 259: '... node SHOULD be able to use its NAI ...' RFC 2119 keyword, line 275: '... SHOULD use the MN_NAI to get aut...' RFC 2119 keyword, line 280: '... MAY use the IPv6 home address to...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 23 has weird spacing: '... It is inapp...' == Line 228 has weird spacing: '...ion and auth...' == Line 741 has weird spacing: '...chanism that ...' == Line 1163 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 1431, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1435, 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. -------------------------------------------------------------------------------- 2 AAA WG Stefano M. Faccin 3 INTERNET-DRAFT Franck Le 4 Date: April 2003 Basavaraj Patil 5 Expires: October 2003 Charles E. Perkins 6 Nokia Research Center 8 Diameter Mobile IPv6 Application 9 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 Mobile IPv6 capable mobile nodes can roam between networks that 35 belong to their home service provider as well as others. Roaming in 36 foreign networks is enabled as a result of the service level and 37 roaming agreements that exist between operators. One of the key 38 protocols that allows this kind of a roaming mechanism to be enabled 39 is Diameter. This Internet Draft specifies a new application to 40 Diameter that enables Mobile IPv6 roaming in networks other than its 41 home. 43 Table of Contents 45 Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i 47 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 51 2. Advertising Application support . . . . . . . . . . . . . . . . . 2 53 3. The model and assumptions . . . . . . . . . . . . . . . . . . . . 2 54 3.1. The model . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Basic features supported in this Internet Draft . . . . . . . . . 5 58 4.1. Authentication/authorization . . . . . . . . . . . . . . . . 5 59 4.2. Dynamic Home Agent assignment in Home domain . . . . . . . . 5 60 4.3. Key distribution . . . . . . . . . . . . . . . . . . . . . . 6 61 4.4. Optimization of Binding Updates . . . . . . . . . . . . . . 7 62 4.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5. Mobile IPv6 Application Diameter messages . . . . . . . . . . . . 7 65 5.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.2. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.2.1. MIP-Binding-Update AVP . . . . . . . . . . . . . . . . 8 68 5.2.2. MIP-Binding-acknowledgement AVP . . . . . . . . . . . . 8 69 5.2.3. MIPv6-Mobile-Node-Address AVP . . . . . . . . . . . . . 8 70 5.2.4. MIPv6-Home-Agent-Address AVP . . . . . . . . . . . . . 8 71 5.2.5. MIPv6-Feature-Vector AVP . . . . . . . . . . . . . . . 9 72 5.2.6. Security Key AVPs . . . . . . . . . . . . . . . . . . . 9 74 6. Information exchange between the mobile node and the AAA Client . 9 75 6.1. MIP Feature Data . . . . . . . . . . . . . . . . . . . . . . 9 76 6.2. EAP Data . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 6.3. Security Key Data . . . . . . . . . . . . . . . . . . . . . 10 78 6.4. Embedded Data . . . . . . . . . . . . . . . . . . . . . . . 10 80 7. Basic Protocol Overview . . . . . . . . . . . . . . . . . . . . . 10 81 7.1. Authentication . . . . . . . . . . . . . . . . . . . . . . . 11 82 7.2. Information flows . . . . . . . . . . . . . . . . . . . . . 11 83 7.3. MN Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 7.3.1. Generation of information in MN . . . . . . . . . . . . 12 85 7.3.2. Replies to MN . . . . . . . . . . . . . . . . . . . . . 13 86 7.4. AAA Client Operation . . . . . . . . . . . . . . . . . . . . 13 87 7.5. AAAv Operation . . . . . . . . . . . . . . . . . . . . . . . 14 88 7.6. AAAh operations . . . . . . . . . . . . . . . . . . . . . . 15 89 7.7. Home Agent Behavior . . . . . . . . . . . . . . . . . . . . 16 91 8. Enhanced features . . . . . . . . . . . . . . . . . . . . . . . . 17 92 8.1. Dynamic Home Agent/ Home Address assignment in Visited 93 domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 8.2. Dynamic Home address assignment in Home Domain . . . . . . . 18 95 8.3. Enhanced AVPs . . . . . . . . . . . . . . . . . . . . . . . 18 96 8.3.1. MIPv6-Feature-Vector AVP . . . . . . . . . . . . . . . 18 98 9. Enhanced Protocol Overview . . . . . . . . . . . . . . . . . . . 19 99 9.1. Information flow . . . . . . . . . . . . . . . . . . . . . . 19 100 9.2. MN Considerations . . . . . . . . . . . . . . . . . . . . . 20 101 9.2.1. Generation of information in MN . . . . . . . . . . . . 20 102 9.2.2. Replies to MN . . . . . . . . . . . . . . . . . . . . . 22 103 9.3. AAA Client Operation . . . . . . . . . . . . . . . . . . . . 22 104 9.4. AAAv Operation . . . . . . . . . . . . . . . . . . . . . . . 23 105 9.5. AAAh operations . . . . . . . . . . . . . . . . . . . . . . 24 106 9.5.1. Home Agent Assignement in Visited Network . . . . . . . 25 107 9.5.2. Home Agent Assignment in Home Network . . . . . . . . . 26 108 9.6. Home Agent Behavior . . . . . . . . . . . . . . . . . . . . 28 110 10. Key distribution . . . . . . . . . . . . . . . . . . . . . . . . 28 111 10.1. Key distribution based on Random numbers . . . . . . . . . 28 112 10.2. Key distribution based on Diffie Hellman . . . . . . . . . 29 114 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 30 116 12. Security Considerations . . . . . . . . . . . . . . . . . . . . 30 118 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 120 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 121 1. Introduction 123 Mobile IP defines a method that allows a Mobile Node to change its 124 point of attachment to the Internet with minimal service disruption. 125 Mobile IP in itself does not provide any specific support for 126 mobility across different administrative domains, which limits the 127 applicability of Mobile IP in a large scale commercial deployment. 129 AAA protocols such as Diameter precisely enable mobile users to roam 130 and obtain service in networks that may not necessarily be owned by 131 their home service provider. For Mobile IP to be deployed in 132 commercial networks, there therefore has to be AAA support for the 133 protocol. 135 Diameter extensions for Mobile IPv4 [1] have already been specified 136 allowing a MIPv4 node to receive services from service providers 137 (home and foreign) and allowing the Diameter servers to authenticate, 138 authorize and collect accounting information for those MIPv4 nodes. 140 Even though MIPv4 and MIPv6 are similar when observed at high level, 141 the two protocols are actually quite different when considering the 142 support for Inter Domain deployment. Mobile IPv6 e.g. does not have 143 the equivalent of a Foreign Agent as defined in Mobile IPv4, and as a 144 result does not define any mechanism by which the visited network can 145 authenticate and authorize access to the network and use of 146 resources. In addition, extending the Diameter Mobile IPv4 147 Application [1] to support Mobile IPv6 will reduce the flexibility 148 and result in some AAA capability exchange issues: it will be 149 difficult to differentiate which AAA nodes support only Mobile IPv4, 150 which ones support only Mobile IPv6 and which ones support both. This 151 document therefore provides a solution for Mobile IPv6 and AAA 152 interworking and e.g. defines the IPv6 specific solution to support 153 roaming of an IPv6 mobile node between different administrative 154 domains. 156 In order to give access to a mobile node to network resources, the 157 mobile node needs to be authenticated and authorized. Besides 158 supporting mobile node authentication and authorization, the AAA 159 infrastructure can also be used for distributing the security keys 160 needed to support the mobile node roaming. Optionally, the AAA 161 infrastructure can be used to support mobility procedures and to 162 optimize authentication, authorization and mobility in a common 163 procedure. 165 This internet draft defines the Diameter Mobile IPv6 application. It 166 identifies the information that needs to be exchanged between the MN 167 and the AAA Client but it does not specify any particular mechanism 168 to convey information between the mobile node and the AAA Client: the 169 set of information identified in the following internet draft, can be 170 conveyed between the mobile node and the AAA client in a different 171 suitable manner outside the scope of this document (e.g. ICMP, the 172 protocol defined by the PANA WG, etc.). The extensions defined for 173 Diameter allow for any of these alternatives, thus enabling such 174 extensions to be deployed independently of the choice of the protocol 175 used between the MN and the AAA client in the visited or access 176 network. 178 The basic AAA model for inter domain roaming and the assumptions 179 behind the model are described first. The basic features supported by 180 the Diameter Mobile IPv6 application are described next, with the 181 definition of the Diameter messages and AVPs and with the behavior of 182 the various elements. Finally, enhanced features are described and 183 the AVPs and the behavior of the various elements is described. 185 2. Advertising Application support 187 Diameter nodes conforming to this specification MAY advertise support 188 by including the value of (TBD) in the Auth-Application-Id or the 189 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 190 Capabilities-Exchange-Answer command [7]. 192 3. The model and assumptions 194 3.1. The model 196 The following entities are involved in the model: 198 Visited Domain Home Domain 199 +--------+ +--------+ 200 |abc.com | (3) |xyz.com | 201 | AAAv |<------------------->| AAAH | 202 +->| server | server-server | server | 203 | +--------+ communication +--------+ 204 | ^ ^ 205 (2) | | (2) client-server | (4) 206 | | communication | 207 v v v 208 +---------+ +---------+ +---------+ 209 | AAA | | AAA | | Home | 210 | Client | | Client | | Agent | 211 +---------+ +---------+ +---------+ 212 ^ 213 | (1) 214 | 215 v 216 +--------+ 217 | Mobile | 218 | Node | mn@xyz.com 219 +--------+ 221 * The Mobile Node 223 * The AAA Client: it is the function that allows the MN to register 224 and be authenticated by the network service provider, by providing 225 identity and authentication information to the local network which 226 then uses a AAA infrastructure to validate the user, generate 227 accounting data for network usage and, authorize use of resources. 228 In addition to authorization and authentication, the MN may 229 provide the AAA Client with mobility management information (e.g. 230 embedded Binding Updates) to perform Mobile IP procedures. The AAA 231 Client can be an attendant, e.g. located in an Access Router, or 232 can be an AA Agent (Auth/Authorization agent) as the one 233 identified in UNAP. 235 * AAAv: is the AAA server in the visited network 237 * AAAh: is the AAA server in the home network of the MN 239 * HA: is a Home Agent 241 3.2. Assumptions 243 1) Mobile nodes are identified by their Network Access Identifier 244 (NAI) in an unique manner: 246 RFC2794 specifies an identifier for mobile nodes, the MN-NAI. The MN- 247 NAI is used by the AAA infrastructure to authenticate mobile IPv4 248 nodes. 250 The Mobile IPv6 specification mandates the existence of a security 251 association between the MN and its Home Agent (HA). In certain 252 scenarios and future deployments a MN may not have any Home Agent or 253 a home address assigned to it. A MN may instead have a security 254 association with the home AAA network element and may use this to 255 obtain a home address, and an HA. 257 In this document it is assumed that an IPv6 mobile node SHOULD 258 identified by a MN-NAI in a unique manner, and that an IPv6 mobile 259 node SHOULD be able to use its NAI instead of its home address to get 260 authenticated/authorized by the AAA infrastructure when roaming to 261 foreign domains. In fact, in general the network needs to 262 authenticate the user that is roaming, not the specific device, and 263 in the future there may be cases where a specific user is accessing 264 the network through several devices, or several users are accessing 265 the network through the same device. 267 In general, anyway, it is better to allow identification of an IPv6 268 mobile node also through the use of its IPv6 home address: this 269 allows users that have not been provided with a NAI by their home 270 domain to get authenticated and authorized by the AAA infrastructure. 272 The assumption made in this document is that: 274 * When the identifier associated with a mobile is the MN-NAI, it 275 SHOULD use the MN_NAI to get authenticated/authorized by the AAA 276 infrastructure, independently of whether the MN has or not a home 277 address 279 * when the MN does not have a MN-NAI but only a home address, the MN 280 MAY use the IPv6 home address to get authenticated/authorized by 281 the AAA infrastructure 283 2) Mobile Node and AAAh share a long-term key: 285 This long-term key provides network authentication and user 286 authentication; it can also be used in order to derive session keys 287 or local security associations as explained in the following 288 sections. 290 3) Communications between AAAv and AAAh are secure 292 This inter AAA security association allows the home and visited 293 domain to trust each other, and to exchange information in an 294 authenticated and protected manner. 296 4. Basic features supported in this Internet Draft 298 4.1. Authentication/authorization 300 Before giving access to the network, the visited network wants to 301 authenticate the user. The IPv6 mobile node may also want to 302 authenticate the network to prevent network impersonation such as 303 false BTS attacks. 305 The IPv6 mobile nodes SHOULD have the capability to use many 306 different authentication methods: The IPv6 mobile nodes could e.g. 307 use EAP at layer 3 for authentication: This document does not define 308 how the authentication information are exchanged between the Mobile 309 nodes and the network (it could be performed using the protocol 310 defined by the PANA WG, ICMPv6 messages) but the AAA infrastructure 311 allows that authentication and authorization; and the defined 312 Diameter messages support many round trips if the authentication 313 method adopted requires it. 315 4.2. Dynamic Home Agent assignment in Home domain 317 It is possible that when the mobile node needs to send a Binding 318 Update to its home agent to register its new primary care-of address, 319 the mobile node may not know the address of any router on its home 320 link that can serve as a home agent for it. For example, some nodes 321 on its home link may have been reconfigured while the mobile node has 322 been away from home, such that the router that was operating as the 323 mobile node's home agent has been replaced by a different router 324 serving this role. 326 The dynamic Home agent assignment feature also provides more 327 flexibility to the service provider: in general, a mobile node home 328 network may not assign statically a home agent to the mobile node to 329 maintain flexibility in the allocation of the home agent to achieve 330 better load sharing and fault tolerance. 332 In this case, the mobile node MAY use the dynamic home agent address 333 discovery mechanism to find the address of a suitable home agent on 334 its home link. 336 The current Mobile IPv6 specification describes a dynamic Home Agent 337 discovery procedure; as an alternative, this document describes 338 another home agent assignment procedure relying on the present AAA 339 infrastructure. 341 Whereas the current dynamic home agent address discovery mechanism 342 requires many round trips between the mobile node and its home domain 343 thus resulting in additional signaling over the access link and 344 between the home and visited domains; and also adding more delay in 345 the procedure, the solution relying on the AAA infrastructure only 346 requires one round trip. 348 And instead of sending specific IP address to request for a Home 349 address/Home agent in the Home/Visited domain, the proposed solution 350 is based on flags: less data thus needs to be sent over the access 351 link, and the AAAh (AAAv) instead creates the binding update message 352 when assigning the home agent. 354 4.3. Key distribution 356 Many security associations need to be dynamically established such 357 as: 359 * the security association between the mobile node and the visited 360 network to protect data (e.g. confidentiality and integrity 361 protection) over the access link 363 * the security association between the mobile node and the home 364 agent, to authenticate the binding update/acknowledgement 365 messages. According to the current specifications, after the 366 dynamic home agent address discovery is performed, the mobile node 367 sends a Binding Update to the selected Home agent to create the to 368 create a forwarding entry in the route table for the home address 369 associated with the MN. This Binding Update MUST be authenticated, 370 therefore a key distribution, e.g. IKE, may need to be executed. 371 This requires many messages to be exchanged between the mobile 372 node and the Home Agent. 374 As an alternative, after the authentication and authorization steps, 375 the AAA servers can be involved and play a role in the key generation 376 and/or the key distribution. 378 Diameter Mobile IPv4 Application defines one key distribution 379 mechanism; for Mobile IPv6, many different schemes could be applied 380 thus providing more flexibility and different properties as outlined 381 in the following sections. 383 4.4. Optimization of Binding Updates 385 As previously explained, in addition to authentication, authorization 386 and key distribution functionalities, the AAA servers can perform 387 mobility procedures such as dynamic home agent assignment. In case, 388 the IPv6 mobile node already has a pre-configured Home Agent, some 389 optimization can also be achieved by having the mobile node 390 encapsulating the binding update to its Home agent in the AAA request 391 message. 393 4.5. Summary 395 MN authentication is in general required to grant access to a MN to 396 the foreign domain. In fact, this may be needed in most of the cases 397 even if access to the foreign domain resources is free. Due to the 398 fact that the MN is away from its home network and hence considered 399 roaming the MN needs to perform also mobility procedures to obtain 400 reachability in the new location. Optionally, key distribution may be 401 need to take place. Using the AAA infrastructure to achieve these 402 functions can significantly reduce inter domain signaling and time 403 delay of the overall procedure performed by a MN to get access to the 404 foreign domain. 406 Currently the mobile node first gets authenticated using the AAA 407 infrastructure to obtain network access, then it may perform dynamic 408 home agent address discovery [4] and set up a security association 409 (using e.g. Internet Key Exchange [5]) with the selected Home agent 410 before sending a Binding Update. This will require many round trips 411 between the foreign domain and the home domain, whereas the use of 412 the AAA infrastructure provides a more efficient and quicker 413 alternative. 415 5. Mobile IPv6 Application Diameter messages 417 This memo introduces some new Command codes (AA-Registration-Request, 418 AA-Registration-Answer, Home-Agent-MIPv6-Request, Home-Agent- 419 MIPv6-Answer) and AVPs (MIP-Binding-Update AVP, MIP-Binding- 420 acknowledgement AVP, MIPv6-Mobile-Node-Address AVP, MIPv6-Home-Agent- 421 Address AVP, MIPv6-Feature-Vector AVP, Key-Request AVP, MN-Key- 422 Distribution AVP, Key-Distribution AVP) to achieve all the previously 423 identified functionalities. 425 5.1. Command Codes 427 This document introduces four new Command Codes: 429 * AA-Registration-Request Command (ARR) (Code TBD) 431 * AA-Registration-Answer Command(ARA) (Code TBD) 433 * Home-Agent-MIPv6-Request Command (HOR) (Code TBD) 435 * Home-Agent-MIPv6-Answer Command (HOA) (Code TBD) 437 5.2. AVPs 439 5.2.1. MIP-Binding-Update AVP 441 The MIP-Binding-Update AVP (AVP Code TBD) is of type OctetString and 442 contains the Mobile IP Binding Update message. 444 5.2.2. MIP-Binding-acknowledgement AVP 446 The MIP-Binding-acknowledgement AVP (AVP Code TBD) is of type 447 OctetString and contains the Mobile IP Binding Acknowledgement 448 message sent by the Home Agent to the MN. 450 5.2.3. MIPv6-Mobile-Node-Address AVP 452 The Mobile-Node-Address AVP (AVP Code TBD) is of type IPAddress and 453 contains the Mobile Node's Home Address. 455 5.2.4. MIPv6-Home-Agent-Address AVP 457 The Home-Agent-Address AVP (AVP Code TBD) is of type IPAddress and 458 contains the Mobile Node's Home Agent Address. 460 5.2.5. MIPv6-Feature-Vector AVP 462 The MIPv6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned32 and 463 allows for dynamic Home Agent assignment in Home Domain. In the basic 464 proposal, only one flag is defined; the other ones are reserved for 465 the enhanced version and for future utilization. 467 Flag values currently defined include: 469 1 Home-Agent-Requested: This flag is set to 1 when the 470 mobile node requests for a dynamic home agent 471 assignment. When this flag is set to 1, a dynamic 472 session key to be shared between the MN and the HA is 473 also required in order to authenticate BUs from the MN 474 to the HA: the MN may indicate through some Security Key 475 Request the methods it supports to compute it; or a 476 default method known to the MN and the AAAh should 477 exist(e.g. pre-set by the home domain and communicated 478 to the MN at subscription time). 480 5.2.6. Security Key AVPs 482 The AAA servers can play a role in key distribution and many methods 483 can be used with their own properties and characteristics. The 484 security keys AVPs format and utilization will be described in more 485 details in the next versions as well as the AAA servers' behaviors. 487 6. Information exchange between the mobile node and the AAA Client 489 Although this document is not intended to specify any particular 490 mechanism to convey information between the mobile node and the AAA 491 Client, the information that needs to be exchanged is described. The 492 set of information identified in the follow can actually be conveyed 493 between the mobile node and the network in a different suitable 494 manner outside the scope of this document (e.g. ICMP, the protocol 495 defined by the PANA WG, etc.). The extensions defined for Diameter 496 allow for any of these alternatives, thus enabling such extensions to 497 be deployed independently of the choice of the protocol used between 498 the MN and the network. 500 6.1. MIP Feature Data 502 Contrary to Mobile IPv4 where the Mobile nodes send a Registration 503 Request with specific IP addresses values to request for dynamic home 504 agent assignment in home/visited networks; the IPv6 mobiles nodes 505 SHOULD use some MIP Feature data whose content includes the 506 information required in the previously defined MIPv6 Feature Vector 507 AVP: The IPv6 mobile nodes will not use specific IPv6 addresses 508 values but use flags and this will significantly reduces the amount 509 of data to be sent over the access link. In addition, the attendant 510 will only need to encapsulate that data in the corresponding 511 MIPv6-Feature-Vector AVP. 513 The MIP Feature data could be sent as an extension to ICMPv6 514 messages, a new Destination Option or carried in any other way. 516 6.2. EAP Data 518 The IPv6 Mobile Node should be able to use different authentication 519 methods such as the different EAP types. 521 The EAP Data could be sent as an extension to ICMPv6 messages, 522 carried using the protocol defined by the PANA WG or any other 523 protocol. 525 6.3. Security Key Data 527 This document does not defines the protocol between the mobile nodes 528 and the network but the mobile node SHOULD use some key request to 529 indicate the keys it needs, but also the methods it supports to 530 generate them. 532 Those Security Key data SHOULD contain the relevant information so 533 the AAA client can create the corresponding Security Keys AVPs. 535 6.4. Embedded Data 537 The embedded data enables the mobile node to send a binding update at 538 the same time the mobile node gets authorized/authenticated by the 539 network (e.g. by mechanism that the protocol defined by the PANA WG 540 will provide) thus saving round trips between the home and the 541 visited domains. 543 7. Basic Protocol Overview 544 7.1. Authentication 546 Authentication is required before providing network access to the 547 user. 549 Different authentication should be supported to allow more 550 flexibility; but as demonstrated in [6], both network and user 551 authentication should be supported. 553 And current authentication mechanisms, even those recently specified 554 in different standardization fora (e.g. CAVE based security functions 555 in IS41 Systems) have security flaws. 557 For these reasons, even as previously mentioned any existing 558 authentication could be used, in the following illustrations and 559 procedures, a mutual challenge response based authentication method 560 will be suggested and used as default. 562 The authentication mechanism assumed here assumes that a Local 563 Challenge is broadcast over the access link e.g. in Router 564 Advertisement messages. 566 7.2. Information flows 568 Basic Procedure with dynamic Home Agent assignment in the Home 569 network or pre-configured Home Agent 571 Mobile Node AAA Client AAAv AAAh Home Agent 572 ----------- ----------- ------------ ---------- ---------- 573 Advertisement & 574 <---1.1 - Challenge 575 -1.2 --------> 576 1.3 ARR-------------> 577 1.4 ARR------------> 578 1.5 HOR-------> 579 <------1.6 HOA 580 <---------1.7 ARA 581 <------------1.8 ARA 582 <-------1.9 584 7.3. MN Considerations 586 7.3.1. Generation of information in MN 588 1) When entering a new network or at power up, the MN listens to the 589 router advertisements and retrieves: 591 The Local Challenge 592 The visited network identifier 593 The information to derive the CoA 595 2) It computes the CoA, and based on the following information, 597 * The NAI 598 * The long-term security key shared with its AAAh 599 * The Home Address: in the basic mode, the mobile node is 600 assumed to have a pre-configured Home IP address 601 * The Home Agent (if any), otherwise MN can request to have one 602 assigned 604 creates a message with the CoA as the Source IP address and the AAA 605 Client address as the Destination IP address. (The MN can learn the 606 IP address of the AAA Client through router advertisements or others 607 mechanisms outside the scope of this document.) As previously 608 explained, the mobile node also sends its NAI. 610 3) The MN optionally generates a Host Challenge that it will send to 611 the network for both network authentication and anti replay attacks. 612 Then the MN computes the MN authentication data using the long-term 613 key, the host challenge, the visited network identifier, the local 614 challenge, and an authentication algorithm it shares with its home 615 network. The MN authentication data is then sent to the AAA Client, 617 4) If the MN does not have a Home Agent and requests one, the MN 618 includes some MIP Feature data with the Home-Agent-Requested flag set 619 to 1. The home agent will then be assigned by the home AAA server, 620 and the binding update will be sent by the AAA server to the Home 621 Agent on behalf of the mobile node that, in turn, does not need to 622 send any. 624 If the MN have a pre configured Home Agent, it may creates the 625 binding update message and sends it encapsulated to the AAA client. 626 The Binding Update message will be forwarded to the designated home 627 agent via the AAA infrastructure. This binding update message has 628 the MN IP CoA as the source IP address, the pre-configured HA as the 629 destination IP address and the BU option with the pre-configured Home 630 IP address in the Home address option. 632 5) The MN may also requests for some security keys thanks to the 633 Security Key Request. 635 The MN SHOULD perform authentication in the following cases: 637 * When changing visited domain: MN can know that by 638 listening the router advertisements 639 * When requesting session keys 640 * When requesting a Home Agent assignment 642 7.3.2. Replies to MN 644 When receiving the reply from the AAA Client, the MN: 646 * Authenticates the network thanks to the network authentication 647 data sent by the AAA Client 649 * If the MN requested a Home agent, it will learn and store the Home 650 Agent address from the source IP address of the Home Binding 651 Acknowledgement. 653 The MN creates the security associations from the keying material 654 received. 656 7.4. AAA Client Operation 658 As indicated above, the mobile node may interact with the AAA Client 659 to perform authentication/authorization and optionally Mobile IP 660 procedures. Thus, the AAA client may perform authentication functions 661 and optionally Mobile IP functions 663 When the AAA Client receives an authentication request message from a 664 IPv6 Mobile node: 666 The AAA Client first verifies the freshness of the request thanks to 667 the Local Challenge contained in it (i.e. the MN may use an older 668 Local Challenge) and if successful, performs Duplicate Address 669 Detection and creates a Diameter ARR (AA-Registration-Request) [7] 670 message carrying the following information to the AAAh: 672 * User Name AVP [7] carrying the user's NAI 674 * EAP AVP to carry the authentication data for mutual authentication 675 derived from the content of the received authentication data 677 * if some MIP feature data were received from the MN, a 678 MIPv6-Feature-Vector AVP whose content is derived from the MIP 679 feature data, sent within the ARR message it sends to the AAAv 681 * MIP-Binding Update AVP if the MN sent a Home Binding Update as 682 Embedded data 684 * MIPv6-Home-Agent-Address AVP if the MN sent a binding update 685 message: the Home agent address value is extracted from the 686 Destination IP address field of the embedded home binding update. 687 This AVP enables the AAAh to know where to send the MIP-Home- 688 binding-Update AVP if one was present. 690 * if the MN provides some Key Request data, some Security Key AVPs 691 whose content is derived from the Key Request data. 693 When receiving an ARA [7] (AA-Registration-Answer) message from AAAv, 694 the AAA Client converts the message to the appropriate protocol to 695 the MN; this message carries: 697 * the authentication data 699 * Binding Acknowledgement as Embedded Data if MN sent a home Binding 700 Update or requested for a dynamic home agent assignement. 702 The message may also include: 704 * Keying material to set up the different session keys, converted 705 and conveyed in the appropriate protocol by the AAA Client from 706 the Security Key AVPs. When the MN asks for a dynamic Home Agent, 707 AAAh SHOULD compute the security key to be shared between MN and 708 the HA for authenticating subsequent Binding Updates, and sends 709 the corresponding keying material to the MN. 711 7.5. AAAv Operation 713 When AAAv receives an ARR message [7]: 715 First the AAAv verifies the message is coming from a valid AAA Client 716 and then, checks the MIPv6 Feature Vector AVP, and then sends it to 717 the MN's home AAA server. 719 When receiving a ARA message from the AAAh, the AAAv MAY optionally, 720 according to the behaviour specific for speficic EAPs or other 721 mechanisms defined elsewhere, store locally information contained in 722 the AVPs of the message received from the AAAh (e.g. session keys, 723 etc.) and then forwards the message to the AAA Client. 725 7.6. AAAh operations 727 * When receiving an ARR message from an AAAv, the AAAh first 728 verifies the message is coming from a valid AAAv. Security 729 associations between AAA server are outside the scope of the 730 present document. 732 The AAAh then authenticates the user using the NAI provided by the MN 733 as MN identity. If the mobile Node is successfully authenticated: 735 * AAAh also computes some network authentication data based on the 736 Host Challenge and eventually other information depending on the 737 authentication algorithm adopted. 739 Depending on the authentication method requirements, the AAAh may 740 exchange many messages with the MN via the AAAv (e.g. for a user 741 authentication mechanism that requires more than one round-trip): 742 AAAh may send a ARA Command with the appropriate authentication 743 information and indication, which will be converted to EAP data by 744 the AAA Client to the MN and conveyed to the MN in a suitable manner 745 (outside the scope of this document). The number of round trips 746 varies depending on the authentication mechanism used. 748 * If the MN asks for some security keys, the AAAh performs the 749 appropriate steps and eventually sends the corresponding messages 750 to achieve the key distribution: many mechanisms exist and some of 751 them will be described later on. Such steps may require the AAAh 752 to distribute keys and keying material to the MN, to other AAA 753 servers or other nodes. 755 * If a MIPv6-Home-Agent-Address AVP is present: the AAAh checks that 756 the address is that of a known and valid Home Agent, and one that 757 the Mobile Node is allowed to request. AAAh then forwards the MIP- 758 Home-Binding-Update AVP to the Home Agent in a HOR (Home-Agent- 759 MIP-Request) message. 761 * If no MIPv6-Home-Agent-Address AVP is present, AAAh looks at the 762 MIPv6-Feature-Vector AVP if any. If present, AAAh performs the 763 dynamic home agent assignment in the Home network: 765 Mobile Node AAA Client AAAv AAAh Home Agent 766 ----------- ----------- ------------ ---------- ---------- 767 Advertisement & 768 <---1.1 -- Challenge 769 -1.2 --------> 770 1.3 ARR-------------> 771 1.4 ARR----------> 772 1.5 HOR-------> 773 <--------1.6 HOA 774 <-------1.7 ARA 775 <------------1.8 ARA 776 <-------1.9 778 (1.5) AAAh allocates a Home agent on behalf of the MN: this can be 779 done in a variety of ways, including using a load balancing 780 algorithm in order to keep the load on all HAs equal. 782 * AAAh sends a HOR message to the HA including a newly created 783 binding update. 785 * AAAh sends some security keying material to allow the Home 786 Agent to comupte the key(s) for the security association 787 between the MN and the Home Agent to authenticate future 788 Binding Updates. 790 (1.6) the Home Agent creates the Binding Cache and computes the 791 key(s) for the security association with the MN from the data 792 received. It also generates a Binding Acknowledgement message to 793 be sent encapsulated to the MN. 795 * The HA sends a HOA message to the AAAh including the Binding 796 Ack. 798 (1.7) AAAh may also compute other keying material according to the 799 keys requested by the MN and send it to the MN passing through the 800 AAAv. 802 * AAAh then send an ARA message to the AAAv including the MIP- 803 Binding-acknowledgement AVP if the MN sent an embedded BU or 804 request for a HA. 806 7.7. Home Agent Behavior 808 Upon receipt of the HOR, the Home Agent first processes the DIAMETER 809 message: if the HOR is invalid, a HOA is returned with the Result- 810 Code AVP set to DIAMETER_ERROR_BAD_HOR. Otherwise, the Home Agent 811 processes the MIP-Binding-update AVP and creates the Binding 812 Acknowledgement, encapsulating it within the MIP-binding- 813 acknowledgement AVP. 815 HA also creates the Binding Cache and computes the key(s) for the 816 security association with the MN from the data received. 818 8. Enhanced features 820 In addition to the previously described features, additional features 821 can be supported by the AAA infrastructure for the inter-domain 822 roaming of an IPv6 mobile node, thus providing more flexibility and 823 allowing new options to the services providers to develop business 824 models. 826 A IPv6 mobile node can have a pre-configured home address, may have a 827 pre-configured home agent or request for one and, as explained in the 828 previous section, the basic features of the Mobile IPv6 Diameter 829 Application allow an optimization of the authentication, the binding 830 update, the optional home agent assignment in the home domain and the 831 key distribution procedures. 833 Optionally, two enhanced features are suggested: 835 * The dynamic Home agent assignment in the Visited Domain 836 * The dynamic Home address assignment 838 8.1. Dynamic Home Agent/ Home Address assignment in Visited domain 840 The Dynamic Home Agent assignment in visited networks allows more 841 flexibility and allows new business scenarios. As an example, service 842 providers may just own a AAA server for accounting purposes and, 843 thanks to roaming agreements, they may offer Mobile IP services to 844 its subscribers. Another scenario where this can be applied is when 845 IPv6 mobile nodes need to obtain reachability from other CN only at 846 the application level, i.e. through a SIP infrastructure. This may be 847 the case of a basic IPv6 MN supporting only voice services through 848 SIP. In such cases, when a CN needs to reach the MN an identifier at 849 the application level (e.g. MN SIP URL) is used, and the CN does not 850 need to know the home address of the MN. Somebody may argue that 851 Mobile IP is not needed at all in such cases, but it may instead be 852 used to support mobility between the initial point of attachment 853 (i.e. when the MN powered up in the foreign domain) and following 854 points of attachment in the foreign domain. 856 8.2. Dynamic Home address assignment in Home Domain 858 The mobile node may not always have a pre-configured IPv6 address and 859 may need to have one dynamically assigned. In addition since the Home 860 Agent and the mobile node home address need to be on the same link, 861 to support dynamic home agent assignment in visited networks, dynamic 862 home address assignment in visited networks is supported. 864 Finally, this dynamic Home address feature provides more flexibility 865 to the service provider even when the Home agent is to be assigned in 866 the Home network since the Home agent and the home address should be 867 on the same subnet. Additionally, the scenario described in section 868 7.2 of a MN node needing reachability only at the application layer 869 applies to this case too. 871 8.3. Enhanced AVPs 873 In addition to the Command Codes and AVPs described in section 4, 874 some new AVP need to be defined to support the enhanced features. 876 8.3.1. MIPv6-Feature-Vector AVP 878 In the extended mode, dynamic home agent assignment in the visited 879 network is feasible.Additional flags of the MIPv6-Feature-Vector AVP 880 are therefore defined. 882 The following flags allow the Visited AAA server, AAAv, to inform of 883 its capabilities and if the Home agent is assigned in the visited 884 network, the Home address must also be assigned in the visited 885 network. 887 The AAA Client includes a MIPv6-Feature-Vector AVP within the ARR 888 message it sends to the AAAv if the MN sent some MIP Feature data. 890 Flag values currently defined include: 892 1 Home-Agent-Requested: This flag is set to 1 when the 893 mobile node requests for a dynamic home agent 894 assignment. When this flag is set to 1, a dynamic 895 session key to be shared between the MN and the HA is 896 also required in order to authenticate BUs from the MN 897 to the HA: the MN may indicate through some Security Key 898 Request the methods it supports to compute it; or a 899 default method known to the MN and the AAAh should 900 exist(e.g. pre-set by the home domain and communicated 901 to the MN at subscription time). 903 2 Mobile-Node-Home-Address-Requested flag: This flag is 904 set to 1 if the mobile node does not have any Home 905 address and requires one. Default value is 0. 907 4 Home-Address-Allocatable-Only-in-Home-Domain flag: This 908 flags is set to 1 if the mobile node requests for one 909 Home address and wants it to be assigned by its home 910 network. Default value is 0 and means that the MN does 911 not have any preference on whether the Home Address 912 shall be allocated in the home domain and visited 913 domain. 915 8 Home-Agent-in-Visited-Domain flag: The mobile node 916 indicates its preference to have its Home Agent 917 allocated in the visited domain by having this flag set 918 to 1 920 16 Visited-Home-Agent-Available flag: The Visited Domain 921 sets this flag to 1 if the MN asks a dynamic Home Agent 922 assignment in the Visited Domain and the Visited Domain 923 agrees to allocate one to the MN. 925 9. Enhanced Protocol Overview 927 The enhanced mode allows dynamic home agent assignment in the visited 928 network and dynamic home address assignment. The mobile node may not 929 have any preconfigured home address nor any home agent. The following 930 text describes the different entities' behaviors in the Enhanced 931 mode. 933 The authentication procedure is the same than the one described 934 above. 936 All the functionalities (key distribution, optimization of Binding 937 Upate, dynamic Home Agent assignment in Home network) of the basic 938 mode are present but in addition the Home agent can be assigned in 939 the visited network and the home address can be dynamically assigned 940 either in the home or visited domain: the entities behaviours and the 941 way the corresponding AVPs are processed, are explained 943 9.1. Information flow 945 Enhanced Procedure with dynamic Home agent assignment in the visited 946 network and dynamic home address assignment in home or visited domain 948 Mobile Node AAA Client Home Agent AAAv AAAh 949 ----------- ----------- ------------- ---------- ---------- 950 <---2.1 Challenge--- 951 -2.2 -----> 952 ----------2.3 ARR-------------> 953 ---2.4 ARR----> 954 <--2.5 HOR----- 955 <---2.6 HOR--- 956 ----2.7 HOA---> 957 ---2.8 HOA----> 958 <--2.9 ARA----- 959 <-----------2.10 ARA------------ 960 <-2.11-- 962 9.2. MN Considerations 964 9.2.1. Generation of information in MN 966 The mobile node performs the same steps as in the basic mode (steps 967 (1), (2), (3) section 6.3.1) and then 969 4) If the MN does not have a Home Address and requests one, the MN 970 also includes some MIP Feature data with the Mobile-Node-Home- 971 Address-Requested flag set to 1: 973 * If MN wants its Home address to be allocated by its home network, 974 it also sets the value of Home-Address-Allocatable-Only-in-Home- 975 Domain flag to 1. 977 If the MN does not have a Home Agent and requests one, the MN also 978 includes some MIP Feature data with the Home-Agent-Requested flag set 979 to 1. The home agent will then be assigned by the AAA server, and the 980 binding update will be sent by the AAA server to the Home Agent on 981 behalf of the mobile node that, in turn, does not need to send any. 983 * If MN wants its Home agent to be allocated by the visited network, 984 it also sets the Home-Agent-in-Visited-Network flag to 1. 986 The following table describes the different supported cases and the 987 flags that need to be set according to the needs: 989 HD means Home Domain 990 VD means Visited Domain 991 NP means MN has No Preference 992 X means not supported 994 P: Mobile-Node-Home-Address-Requested flag 995 H: Home-Address-Allocatable-Only-in-Home-Domain 996 A: Home-Agent-Requested 997 V: Home-Agent-In-Visited-Network 999 +---------+------------------------------------------------+ 1000 | | Home agent Requested | 1001 +---------+---+--------------------+-----------------------+ 1002 | | | YES | NO | 1003 | +---+--+-----+-----+-----+-----------------------+ 1004 | | | | HD | VD | NP | | 1005 |Home addr| +--+-----+-----+-----+-----------------------+ 1006 |Requested| |HD| PAH | x | x | PH | 1007 | | +--+-----+-----+-----+-----------------------+ 1008 | |YES|VD| x |PAV | x | x | 1009 | | +--+-----+-----+-----+-----------------------+ 1010 | | |NP| x | x |PA | P | 1011 | +---+--+-----+-----+-----+-----------------------+ 1012 | | | | | | | | 1013 | | NO| | A* | x | x | no MIP Feature data | 1014 | | | | | | | | 1015 +---------+---+--+-----+-----+-----+-----------------------+ 1017 A*: MN already has a home address in its Home network and may request 1018 for a Home Agent. The HA can thus only be assigned in the Home 1019 Network. 1021 While the MN gets authenticated and authorized, if the MN already has 1022 a home address and a home agent, it can send a Home Binding Update 1023 together with the request to be authorized and authenticated to save 1024 one round trip over the access link and between the visited and home 1025 networks. This binding update is in this case sent as Embedded Data: 1027 The Home Binding Update has: 1029 * The H flag set to 1. 1030 * The source IP address equals to the CoA 1031 * The destination IP address set to the Home agent address 1032 * The Home Address option set to the MN Home address 1034 5) The MN may also requests for some security keys thanks to the 1035 Security Key Request. 1037 The MN SHOULD perform authentication in the following cases: 1039 * When changing visited domain: MN can know that by 1040 listening the router advertisements 1041 * When requesting session keys 1042 * When requesting a Home Agent assignment 1043 * When requesting a home address assignment 1045 9.2.2. Replies to MN 1047 When receiving the reply from the AAA Client, the MN: 1049 * Authenticates the network thanks to the network authentication 1050 data sent by the AAA Client 1052 * If the MN requested a Home agent, it will learn and store the Home 1053 Agent address from the source IP address of the Home Binding 1054 Acknowledgement. 1056 * If the MN did not have a Home IP address and requested for one, 1057 the MN will learn and store the assigned home address from the 1058 home address option of the Home Binding Acknowledgement (embedded 1059 data). 1061 The MN creates the security associations from the keying material 1062 received. 1064 9.3. AAA Client Operation 1066 As indicated above, the mobile node may interact with the AAA Client 1067 to perform authentication/authorization and optionally Mobile IP 1068 procedures. Thus, the AAA client may perform authentication functions 1069 and optionally Mobile IP functions 1071 When the AAA Client receives an authentication request message from a 1072 IPv6 Mobile node: 1074 The AAA Client first verifies the freshness of the request thanks to 1075 the Local Challenge contained in it (i.e. the MN may use an older 1076 Local Challenge) and if successful, performs Duplicate Address 1077 Detection and creates a Diameter ARR (AA-Registration-Request) [7] 1078 message carrying the following information to the AAAh: 1080 * User Name AVP [7] carrying the user's NAI 1082 * EAP AVP to carry the authentication data for mutual authentication 1083 derived from the content of the received authentication data 1085 * if some MIP feature data were received from the MN, a 1086 MIPv6-Feature-Vector AVP whose content is derived from the MIP 1087 feature data, sent within the ARR message it sends to the AAAv 1089 * MIP-Binding Update AVP if the MN sent a Home Binding Update as 1090 Embedded data 1092 * MIPv6-Home-Agent-Address AVP if the MN sent a Home binding update: 1093 the Home agent address value is extracted from the Destination IP 1094 address field of the embedded home binding update. This AVP 1095 enables the AAAh to know where to send the MIP-Home-binding-Update 1096 AVP if one was present. 1098 * if the MN provides a Key Request, some Security Key AVPs whose 1099 content is derived from the Key Request. 1101 When receiving an ARA [7] (AA-Registration-Answer) message from AAAv, 1102 the AAA Client converts the message to appropriate protocol to the 1103 MN; this message carries: 1105 * the authentication data 1107 * Binding Acknowledgement as Embedded Data if MN sent a home Binding 1108 Update or requested for a dynamic home agent assignment. 1110 The message may also include: 1112 * Keying material to set up the different session keys, in different 1113 Security Key Data created by the AAA Client from the Security Key 1114 AVPs. When the MN asks for a dynamic Home Agent, AAAh must compute 1115 the security key to be shared between MN and the HA for 1116 authenticating subsequent Binding Updates, and sends the 1117 corresponding keying material to the MN. 1119 9.4. AAAv Operation 1121 When AAAv receives an ARR message [7]: 1123 First the AAAv verifies the message is coming from a valid AAA Client 1124 and then, checks the MIPv6 Feature Vector AVP: 1126 * If the MN requested a Home Agent by setting the Home-Agent- 1127 Requested flag to 1, and does not specify that this one should be 1128 assigned only in its Home domain by setting the Home-Address- 1129 Allocatable-Only-in-Home-Domain flag to 1, the AAAv checks if it 1130 can allocate a Home Agent for the mobile node in the visited 1131 domain. If AAAv can allocate a Home Agent in the visited domain, 1132 it indicates this to the AAAh by setting the Visited-Home-Agent- 1133 Available flag to 1 of the MIPv6 Feature Vector AVP forwarded to 1134 the AAAh. 1136 When receiving a HOR message from the AAAh for a dynamic Home Agent 1137 assignment in the visited network, the AAAv performs the dynamic Home 1138 agent assignment and MAY perform some key distribution depending on 1139 the mechanisms. 1141 When receiving a ARA message from the AAAh, the AAAv MAY optionally, 1142 according to the behavior specific for speficic EAPs or other 1143 mechanisms defined elsewhere, store locally information contained in 1144 the AVPs of the message received from the AAAh (e.g. session keys, 1145 etc.) and then forwards the message to the AAA Client. 1147 9.5. AAAh operations 1149 * When receiving an ARR message from an AAAv, the AAAh first 1150 verifies the message is coming from a valid AAAv. Security 1151 associations between AAA server are outside the scope of the 1152 present document. 1154 The AAAh then authenticates the user using the NAI provided by the MN 1155 as MN identity. If the mobile Node is successfully authenticated: 1157 * AAAh also computes some network authentication data based on the 1158 Host Challenge and eventually other information depending on the 1159 authentication algorithm adopted. 1161 Depending on the authentication method requirements, the AAAh may 1162 exchange many messages with the MN via the AAAv (e.g. for a user 1163 authentication mechanism that requires more than one round-trip): 1164 AAAh may send a ARA Command with the appropriate authentication 1165 information and indication, which will be converted to EAP data by 1166 the AAA Client to the MN or conveyed to the MN in other suitable 1167 manner (outside the scope of this document). The number of round 1168 trips varies depending on the authentication mechanism used. 1170 * If the MN asks for some security keys, the AAAh performs the 1171 appropriate steps and eventually sends the corresponding messages 1172 to achieve the key distribution: many mechanisms exist and will be 1173 described later on. Such steps may require the AAAh to distribute 1174 keys and keying material to the MN, to other AAA servers or other 1175 nodes. 1177 * If a MIPv6-Home-Agent-Address AVP is present: the AAAh checks that 1178 the address is that of a known and valid Home Agent, and one that 1179 the Mobile Node is allowed to request. AAAh then forwards the MIP- 1180 Home-Binding-Update AVP to the Home Agent in a HOR (Home-Agent- 1181 MIP-Request) message including the appropriate key material to set 1182 up the security association between the MN and the Home Agent. 1184 * If no MIPv6-Home-Agent-Address AVP is present, AAAh looks at the 1185 MIPv6-Feature-Vector AVP if any. Depending on the mobile node 1186 request (Home-Agent-in-Visited-Network flag, Home-Address- 1187 Allocatable-Only-in-Home-Domain), the visited network capabilities 1188 (Visited-Agent-Available AVP) and the local policy, the AAAh 1189 decides whether to assign the HA in the home or visited network: 1191 9.5.1. Home Agent Assignement in Visited Network 1193 If the AAAh accepts the HA to be assigned in the visited domain, the 1194 following exchange of messages takes place: 1196 Mobile Node AAA Client Home Agent AAAv AAAh 1197 ----------- ----------- ------------- ---------- ---------- 1198 <---2.1 Challenge- 1199 -2.2 ----> 1200 ----------2.3 ARR-------------> 1201 ---2.4 ARR----> 1202 <--2.5 HOR----- 1203 <---2.6 HOR----- 1204 ----2.7 HOA-----> 1205 ---2.8 HOA----> 1206 <--2.9 ARA----- 1207 <-----------2.10 ARA------------ 1208 <-2.11 --- 1210 (2.5): AAAh sends a HOR message to the AAAv with neither any 1211 MIPv6-Mobile-Node-Address AVP nor any MIPv6-Home-Agent-Address 1212 AVP. 1214 * AAAh may send some keying material for HA to derive the key(s) 1215 for the security association between the MN and the Home Agent 1216 to authenticate future Binding Updates depending on the key 1217 distribution mechanism chosen 1219 * AAAh may also send other keying material according to the keys 1220 requested by the MN 1222 (2.6): AAAv assigns a Home agent and then creates and sends it a 1223 newly created Binding Update encapsulated in the HOR message. 1225 * AAAv may assign Home IP address for the MN and informs the Home 1226 Agent by adding a MIPv6-Mobile-Node-Address AVP in the HOR 1227 message; or let the Home Agent assigns the Home address by not 1228 providing a MIPv6-Mobile-Node-Address AVP in the HOR message. 1230 * AAAv may forward to the Home Agent some keying material 1231 depending on the key distribution mechanism adopted to set up 1232 the security association between the MN and the Home Agent 1234 (2.7): The Home agent assigns a Home IP address if requested and 1235 creates a Binding Cache for the MN. 1237 * The Home agent creates the Security Association according to 1238 the mechanism adopted 1240 * The Home Agent creates the Binding Acknowledgement to be sent 1241 encapsulated to the MN. 1243 * The Home Agent sends back a HOA to the AAAv to inform it of the 1244 status: it includes the assigned Mobile Node Home Address if 1245 the Home Agent assigned one; it also includes the Binding ack 1246 created by the Home Agent to be sent encapsulated to the MN. 1248 (2.8) The AAAh is informed of the assigned Home IP address 1249 (contained in the MIPv6-Mobile-Node-Address AVP) and the Home 1250 Agent address (contained in the MIPv6-Home-Agent-Address AVP) by 1251 the HOA message sent from the AAAv. 1253 (2.9) The AAAh sends the AAAv an ARA carrying the Home IP address, 1254 the Home Agent IP address, the keying material with the previous 1255 information. 1257 9.5.2. Home Agent Assignment in Home Network 1259 If the AAAh decides to assign the HA in the Home network, the 1260 following exchange of messages takes place: 1262 Mobile Node AAA Client AAAv AAAh Home Agent 1263 ----------- ----------- ------------ ---------- ---------- 1264 Advertisement & 1265 <---3.1 -- Challenge 1266 -3.2 -----> 1267 3.3 ARR-------------> 1268 3.4 ARR--------> 1269 3.5 HOR------> 1270 <----3.6 HOA 1271 <------3.7 ARA 1272 <------------3.8 ARA 1273 <-------3.9 1275 (3.5) AAAh allocates a Home agent on behalf of the MN: this can be 1276 done in a variety of ways, including using a load balancing algorithm 1277 in order to keep the load on all HAs equal. 1279 * AAAh sends a HOR message to the HA including a newly created 1280 binding update and: 1282 * The AAAh may allocate a home address for the mobile node and 1283 include it in a MIPv6-Mobile-Node-Address AVP within the HOR or 1284 else leave this allocation responsibility for the HA by leaving 1285 the Home address option of the binding update to zero and not 1286 sending any MIPv6-Mobile-Node-Address AVP. 1288 * AAAh sends some security keying material to allow the Home Agent 1289 to compute the key(s) for the security association between the MN 1290 and the Home Agent to authenticate future Binding Updates. 1292 (3.6) If the Home Agent does not receive any MIP-Mobile-node-address, 1293 and receives a BU with a Home address equals to 0, it assigns a Home 1294 IP address for that user; then creates the Binding Cache and computes 1295 the key(s) for the security association with the MN from the data 1296 received. It also generates a Binding Acknowledgement message to be 1297 sent encapsulated to the MN. 1299 * The HA sends a HOA message to the AAAh including the Binding Ack 1300 and eventually the assigned Home IP address if one was requested. 1302 (3.7) AAAh may also compute other keying material according to the 1303 keys requested by the MN and send it to the MN passing through the 1304 AAAv. 1306 * AAAh then send an ARA message to the AAAv including the 1307 MIPv6-Mobile-Node-Address and MIPv6-Home-Agent-Address AVPs if the 1308 MN did not have any Home address or Home agent. 1310 9.6. Home Agent Behavior 1312 Upon receipt of the HOR, the Home Agent first processes the DIAMETER 1313 message: if the HOR is invalid, a HOA is returned with the Result- 1314 Code AVP set to DIAMETER_ERROR_BAD_HOR. Otherwise, the Home Agent 1315 processes the MIP-Binding-update AVP and creates the Binding 1316 Acknowledgement, encapsulating it within the MIP-binding- 1317 acknowledgement AVP. 1319 If a home address is needed, the Home Agent assigns one and includes 1320 the address in both the Binding acknowledgement message (Home address 1321 option) and in the MIPv6-Mobile-Node-Address AVP. 1323 HA then creates the Binding Cache and computes the key(s) for the 1324 security association with the MN from the data received. 1326 10. Key distribution 1328 As identified in the previous sections, many security keys need to be 1329 set up and shared between the IPv6 mobile nodes and other network 1330 entities, such as: 1332 * the key between the mobile node and its Home Agent to authenticate 1333 the binding Update and Binding acknowledgement messages 1335 * the key between the mobile node and the access router to protect 1336 (e.g. for confidentiality and integrity protection) the data over 1337 the access link. 1339 The AAA entities can play a major role in the computation and 1340 distribution of these security keys. Two key distribution methods, 1341 relying on this AAA infrastructure and allowing authenticated key 1342 distribution, are proposed. 1344 10.1. Key distribution based on Random numbers 1346 The home AAA server generates one random number for each required 1347 security key. Then taking as inputs, to a key derivation algorithm 1348 shared with the mobile node, this random number, the long term key 1349 shared with the mobile node and optionally other data, the home AAA 1350 server derives the desired security key. 1352 This one is securely transmitted to the network entity, the mobile 1353 node wants to share the key with. 1355 And the random number is sent to the Mobile node which can derive the 1356 security session key thanks to the knowledge of the long term key and 1357 the key derivation algorithm shared with its home network. 1359 This key distribution based on Random numbers is currently used in 1360 cellular networks and in the Diameter Mobile IPv4 Application [1] 1362 10.2. Key distribution based on Diffie Hellman 1364 As another possibility, the key distribution can be based on the 1365 Diffie Hellman mechanism. 1367 Diffie Hellman allows two nodes to establish a shared secret key in a 1368 secure fashion. It, although, has a major vulnerability since it does 1369 not allow a node to figure out with whom it is establishing that 1370 secret key. To defeat this vulnerability, the two nodes public values 1371 must be authenticated. 1373 The AAA infrastructure, and more particularly the security 1374 association between the Mobile node and its home network (AAAh) and 1375 the security association between the AAAv and AAAh, can provide that 1376 authentication. 1378 If the mobile node wants to set up a securiy association with an 1379 entity in the visited domain (e.g. home agent assigned in the visited 1380 domain), the mobile node first sends its public Diffie Hellman value 1381 DH_MN authenticated with the long term security association shared 1382 with its AAAh. If the entity with whom the MN wants to set up a 1383 security association is in the visited domain, AAAv retrieves the 1384 entity's Diffie Hellman public value using intra domain security and 1385 sends this value, authenticated with the security association it 1386 shares with the AAAh, to the home network of the MN together with the 1387 message from the MN. 1389 AAAh authenticates the Diffie Hellman Public values of the entity and 1390 the MN. It then sends the MN's Diffie Hellman Public Value to the 1391 AAAv using the security association it shares with AAAv, and sends 1392 the entity's Diffie Hellman Public Value to the MN, authenticated 1393 with the security association shared with the MN. 1395 In this way, AAAh is used to authenticate the Diffie Hellman public 1396 values but as a difference with the previous method, since it does 1397 not have knowledge of the secret values, it can not derive the value 1398 of the session key. This method thus allow to securely distribute 1399 the security keys without having the AAA servers being aware of the 1400 value of those keys. AAA servers are here used as certificate 1401 authorities. 1403 11. Conclusions 1405 The Diameter Mobile IPv6 application defined in this document allows 1406 for support of authentication and authorization of IPv6 mobile nodes 1407 roaming between different domains. In addition, it support key 1408 distribution and mobility by optimizing these procedures. The 1409 application defines also new enhanced features that introduce 1410 flexibility in the definition of business models for service 1411 providers and allow for different types of terminals. 1413 This first version focuses on the different functionalities involved 1414 in the support by the AAA infrastructure of inter domain roaming of 1415 Mobile IPv6 nodes. 1417 12. Security Considerations 1419 The Diameter Mobile IPv6 application defined in this document does 1420 not create new security breaches for the IPv6 MN and the foreign and 1421 visited domain. On the contrary, it allows for an effective and 1422 efficient MN authentication and authorization when roaming between 1423 different domains. 1425 13. References 1427 [1] Pat R. Calhoun, Charles E. Perkins, "Diameter Mobile IPv4 1428 Application" Internet draft, Internet Engineer Task Force, 1429 November 2001 1431 [2] Diffie, W. and Hellman, M., "New Directions ijn 1432 Cryptography", IEEE Transactions on Information Theory, 1433 Vol. IT-22, Nov. 1976, pp. 664-654 1435 [3] Franck Le, Stefano M. Faccin, "Key distribution mechanisms 1436 for Mobile IPv6" Internet draft, Internet Engineer Task 1437 Force, February 2001 1439 [4] David B. Johnson, Charles Perkins, "Mobility Support in 1440 IPv6" Internet draft, Internet Engineer Task Force, 1441 November 2001 1443 [5] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 1444 RFC 2409, Internet Engineer Task Force, November 1998 1446 [6] Sarvar Patel, "Weaknesses of North American Wireless 1447 Authentication Protocol", IEEE Personal Communications, 1448 June 1997 1450 [7] Pat R. Calhoun, Haseeb Akhtar, Jari Arkko, Erik Guttman, 1451 Allan C. Rubens,Glen Zorn, "Diameter Base Protocol" 1452 Internet draft, Internet Engineer Task Force, November 2001 1454 14. Authors' Addresses 1456 Stefano M. Faccin 1457 Nokia Research Center 1458 6000 Connection Drive 1459 Irving, TX 75039 1460 USA 1462 Phone: +1 972 894-4994 1463 E-mail: stefano.faccin@nokia.com 1465 Franck Le 1466 Nokia Research Center 1467 6000 Connection Drive 1468 Irving, TX 75039 1469 USA 1471 Phone: +1 972 374-1256 1472 E-mail: franck.le@nokia.com 1474 Basavaraj Patil 1475 Nokia Corporation 1476 6000 Connection Drive 1477 Irving, TX 75039 1478 USA 1480 Phone: +1 972-894-6709 1481 E-Mail: basavaraj.patil@nokia.com 1483 Charles E. Perkins 1484 Nokia Research Center 1485 313 Fairchild Drive 1486 Mountain View, California 94043 1487 USA 1489 Phone: +1 650-625-2986 1490 E-Mail: charles.perkins@nokia.com