idnits 2.17.1 draft-le-aaa-diameter-mobileipv6-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1439. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == 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 189: '...is specification MAY advertise support...' RFC 2119 keyword, line 259: '...ssumed that an IPv6 mobile node SHOULD...' RFC 2119 keyword, line 261: '... node SHOULD be able to use its NAI ...' RFC 2119 keyword, line 277: '... SHOULD use the MN_NAI to get aut...' RFC 2119 keyword, line 282: '... MAY use the IPv6 home address to...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 230 has weird spacing: '...ion and auth...' == Line 743 has weird spacing: '...chanism that ...' == Line 1165 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 1447, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1451, 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: 12 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA WG Franck Le 3 INTERNET-DRAFT Basavaraj Patil 4 Date: November 2004 Charles E. Perkins 5 Expires: May 2005 Stefano Faccin 6 Nokia 8 Diameter Mobile IPv6 Application 9 11 Status of This Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 Mobile IPv6 capable mobile nodes can roam between networks that 37 belong to their home service provider as well as others. Roaming in 38 foreign networks is enabled as a result of the service level and 39 roaming agreements that exist between operators. One of the key 40 protocols that allows this kind of a roaming mechanism to be enabled 41 is Diameter. This Internet Draft specifies a new application to 42 Diameter that enables Mobile IPv6 roaming in networks other than its 43 home. 45 Table of Contents 47 Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i 49 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 53 2. Advertising Application support . . . . . . . . . . . . . . . . . 2 55 3. The model and assumptions . . . . . . . . . . . . . . . . . . . . 2 56 3.1. The model . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Basic features supported in this Internet Draft . . . . . . . . . 5 60 4.1. Authentication/authorization . . . . . . . . . . . . . . . . 5 61 4.2. Dynamic Home Agent assignment in Home domain . . . . . . . . 5 62 4.3. Key distribution . . . . . . . . . . . . . . . . . . . . . . 6 63 4.4. Optimization of Binding Updates . . . . . . . . . . . . . . 7 64 4.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Mobile IPv6 Application Diameter messages . . . . . . . . . . . . 7 67 5.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.2. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.2.1. MIP-Binding-Update AVP . . . . . . . . . . . . . . . . 8 70 5.2.2. MIP-Binding-acknowledgement AVP . . . . . . . . . . . . 8 71 5.2.3. MIPv6-Mobile-Node-Address AVP . . . . . . . . . . . . . 8 72 5.2.4. MIPv6-Home-Agent-Address AVP . . . . . . . . . . . . . 8 73 5.2.5. MIPv6-Feature-Vector AVP . . . . . . . . . . . . . . . 9 74 5.2.6. Security Key AVPs . . . . . . . . . . . . . . . . . . . 9 76 6. Information exchange between the mobile node and the AAA Client . 9 77 6.1. MIP Feature Data . . . . . . . . . . . . . . . . . . . . . . 9 78 6.2. EAP Data . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 6.3. Security Key Data . . . . . . . . . . . . . . . . . . . . . 10 80 6.4. Embedded Data . . . . . . . . . . . . . . . . . . . . . . . 10 82 7. Basic Protocol Overview . . . . . . . . . . . . . . . . . . . . . 10 83 7.1. Authentication . . . . . . . . . . . . . . . . . . . . . . . 11 84 7.2. Information flows . . . . . . . . . . . . . . . . . . . . . 11 85 7.3. MN Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 7.3.1. Generation of information in MN . . . . . . . . . . . . 12 87 7.3.2. Replies to MN . . . . . . . . . . . . . . . . . . . . . 13 88 7.4. AAA Client Operation . . . . . . . . . . . . . . . . . . . . 13 89 7.5. AAAv Operation . . . . . . . . . . . . . . . . . . . . . . . 14 90 7.6. AAAh operations . . . . . . . . . . . . . . . . . . . . . . 15 91 7.7. Home Agent Behavior . . . . . . . . . . . . . . . . . . . . 16 93 8. Enhanced features . . . . . . . . . . . . . . . . . . . . . . . . 17 94 8.1. Dynamic Home Agent/ Home Address assignment in Visited 95 domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 8.2. Dynamic Home address assignment in Home Domain . . . . . . . 18 97 8.3. Enhanced AVPs . . . . . . . . . . . . . . . . . . . . . . . 18 98 8.3.1. MIPv6-Feature-Vector AVP . . . . . . . . . . . . . . . 18 100 9. Enhanced Protocol Overview . . . . . . . . . . . . . . . . . . . 19 101 9.1. Information flow . . . . . . . . . . . . . . . . . . . . . . 19 102 9.2. MN Considerations . . . . . . . . . . . . . . . . . . . . . 20 103 9.2.1. Generation of information in MN . . . . . . . . . . . . 20 104 9.2.2. Replies to MN . . . . . . . . . . . . . . . . . . . . . 22 105 9.3. AAA Client Operation . . . . . . . . . . . . . . . . . . . . 22 106 9.4. AAAv Operation . . . . . . . . . . . . . . . . . . . . . . . 23 107 9.5. AAAh operations . . . . . . . . . . . . . . . . . . . . . . 24 108 9.5.1. Home Agent Assignement in Visited Network . . . . . . . 25 109 9.5.2. Home Agent Assignment in Home Network . . . . . . . . . 26 110 9.6. Home Agent Behavior . . . . . . . . . . . . . . . . . . . . 28 112 10. Key distribution . . . . . . . . . . . . . . . . . . . . . . . . 28 113 10.1. Key distribution based on Random numbers . . . . . . . . . 28 114 10.2. Key distribution based on Diffie Hellman . . . . . . . . . 29 116 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 30 118 12. Security Considerations . . . . . . . . . . . . . . . . . . . . 30 120 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 122 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 123 1. Introduction 125 Mobile IP defines a method that allows a Mobile Node to change its 126 point of attachment to the Internet with minimal service disruption. 127 Mobile IP in itself does not provide any specific support for 128 mobility across different administrative domains, which limits the 129 applicability of Mobile IP in a large scale commercial deployment. 131 AAA protocols such as Diameter precisely enable mobile users to roam 132 and obtain service in networks that may not necessarily be owned by 133 their home service provider. For Mobile IP to be deployed in 134 commercial networks, there therefore has to be AAA support for the 135 protocol. 137 Diameter extensions for Mobile IPv4 [1] have already been specified 138 allowing a MIPv4 node to receive services from service providers 139 (home and foreign) and allowing the Diameter servers to authenticate, 140 authorize and collect accounting information for those MIPv4 nodes. 142 Even though MIPv4 and MIPv6 are similar when observed at high level, 143 the two protocols are actually quite different when considering the 144 support for Inter Domain deployment. Mobile IPv6 e.g. does not have 145 the equivalent of a Foreign Agent as defined in Mobile IPv4, and as a 146 result does not define any mechanism by which the visited network can 147 authenticate and authorize access to the network and use of 148 resources. In addition, extending the Diameter Mobile IPv4 149 Application [1] to support Mobile IPv6 will reduce the flexibility 150 and result in some AAA capability exchange issues: it will be 151 difficult to differentiate which AAA nodes support only Mobile IPv4, 152 which ones support only Mobile IPv6 and which ones support both. This 153 document therefore provides a solution for Mobile IPv6 and AAA 154 interworking and e.g. defines the IPv6 specific solution to support 155 roaming of an IPv6 mobile node between different administrative 156 domains. 158 In order to give access to a mobile node to network resources, the 159 mobile node needs to be authenticated and authorized. Besides 160 supporting mobile node authentication and authorization, the AAA 161 infrastructure can also be used for distributing the security keys 162 needed to support the mobile node roaming. Optionally, the AAA 163 infrastructure can be used to support mobility procedures and to 164 optimize authentication, authorization and mobility in a common 165 procedure. 167 This internet draft defines the Diameter Mobile IPv6 application. It 168 identifies the information that needs to be exchanged between the MN 169 and the AAA Client but it does not specify any particular mechanism 170 to convey information between the mobile node and the AAA Client: the 171 set of information identified in the following internet draft, can be 172 conveyed between the mobile node and the AAA client in a different 173 suitable manner outside the scope of this document (e.g. ICMP, the 174 protocol defined by the PANA WG, etc.). The extensions defined for 175 Diameter allow for any of these alternatives, thus enabling such 176 extensions to be deployed independently of the choice of the protocol 177 used between the MN and the AAA client in the visited or access 178 network. 180 The basic AAA model for inter domain roaming and the assumptions 181 behind the model are described first. The basic features supported by 182 the Diameter Mobile IPv6 application are described next, with the 183 definition of the Diameter messages and AVPs and with the behavior of 184 the various elements. Finally, enhanced features are described and 185 the AVPs and the behavior of the various elements is described. 187 2. Advertising Application support 189 Diameter nodes conforming to this specification MAY advertise support 190 by including the value of (TBD) in the Auth-Application-Id or the 191 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 192 Capabilities-Exchange-Answer command [7]. 194 3. The model and assumptions 196 3.1. The model 198 The following entities are involved in the model: 200 Visited Domain Home Domain 201 +--------+ +--------+ 202 |abc.com | (3) |xyz.com | 203 | AAAv |<------------------->| AAAH | 204 +->| server | server-server | server | 205 | +--------+ communication +--------+ 206 | ^ ^ 207 (2) | | (2) client-server | (4) 208 | | communication | 209 v v v 210 +---------+ +---------+ +---------+ 211 | AAA | | AAA | | Home | 212 | Client | | Client | | Agent | 213 +---------+ +---------+ +---------+ 214 ^ 215 | (1) 216 | 217 v 218 +--------+ 219 | Mobile | 220 | Node | mn@xyz.com 221 +--------+ 223 * The Mobile Node 225 * The AAA Client: it is the function that allows the MN to register 226 and be authenticated by the network service provider, by providing 227 identity and authentication information to the local network which 228 then uses a AAA infrastructure to validate the user, generate 229 accounting data for network usage and, authorize use of resources. 230 In addition to authorization and authentication, the MN may 231 provide the AAA Client with mobility management information (e.g. 232 embedded Binding Updates) to perform Mobile IP procedures. The AAA 233 Client can be an attendant, e.g. located in an Access Router, or 234 can be an AA Agent (Auth/Authorization agent) as the one 235 identified in UNAP. 237 * AAAv: is the AAA server in the visited network 239 * AAAh: is the AAA server in the home network of the MN 241 * HA: is a Home Agent 243 3.2. Assumptions 245 1) Mobile nodes are identified by their Network Access Identifier 246 (NAI) in an unique manner: 248 RFC2794 specifies an identifier for mobile nodes, the MN-NAI. The MN- 249 NAI is used by the AAA infrastructure to authenticate mobile IPv4 250 nodes. 252 The Mobile IPv6 specification mandates the existence of a security 253 association between the MN and its Home Agent (HA). In certain 254 scenarios and future deployments a MN may not have any Home Agent or 255 a home address assigned to it. A MN may instead have a security 256 association with the home AAA network element and may use this to 257 obtain a home address, and an HA. 259 In this document it is assumed that an IPv6 mobile node SHOULD 260 identified by a MN-NAI in a unique manner, and that an IPv6 mobile 261 node SHOULD be able to use its NAI instead of its home address to get 262 authenticated/authorized by the AAA infrastructure when roaming to 263 foreign domains. In fact, in general the network needs to 264 authenticate the user that is roaming, not the specific device, and 265 in the future there may be cases where a specific user is accessing 266 the network through several devices, or several users are accessing 267 the network through the same device. 269 In general, anyway, it is better to allow identification of an IPv6 270 mobile node also through the use of its IPv6 home address: this 271 allows users that have not been provided with a NAI by their home 272 domain to get authenticated and authorized by the AAA infrastructure. 274 The assumption made in this document is that: 276 * When the identifier associated with a mobile is the MN-NAI, it 277 SHOULD use the MN_NAI to get authenticated/authorized by the AAA 278 infrastructure, independently of whether the MN has or not a home 279 address 281 * when the MN does not have a MN-NAI but only a home address, the MN 282 MAY use the IPv6 home address to get authenticated/authorized by 283 the AAA infrastructure 285 2) Mobile Node and AAAh share a long-term key: 287 This long-term key provides network authentication and user 288 authentication; it can also be used in order to derive session keys 289 or local security associations as explained in the following 290 sections. 292 3) Communications between AAAv and AAAh are secure 294 This inter AAA security association allows the home and visited 295 domain to trust each other, and to exchange information in an 296 authenticated and protected manner. 298 4. Basic features supported in this Internet Draft 300 4.1. Authentication/authorization 302 Before giving access to the network, the visited network wants to 303 authenticate the user. The IPv6 mobile node may also want to 304 authenticate the network to prevent network impersonation such as 305 false BTS attacks. 307 The IPv6 mobile nodes SHOULD have the capability to use many 308 different authentication methods: The IPv6 mobile nodes could e.g. 309 use EAP at layer 3 for authentication: This document does not define 310 how the authentication information are exchanged between the Mobile 311 nodes and the network (it could be performed using the protocol 312 defined by the PANA WG, ICMPv6 messages) but the AAA infrastructure 313 allows that authentication and authorization; and the defined 314 Diameter messages support many round trips if the authentication 315 method adopted requires it. 317 4.2. Dynamic Home Agent assignment in Home domain 319 It is possible that when the mobile node needs to send a Binding 320 Update to its home agent to register its new primary care-of address, 321 the mobile node may not know the address of any router on its home 322 link that can serve as a home agent for it. For example, some nodes 323 on its home link may have been reconfigured while the mobile node has 324 been away from home, such that the router that was operating as the 325 mobile node's home agent has been replaced by a different router 326 serving this role. 328 The dynamic Home agent assignment feature also provides more 329 flexibility to the service provider: in general, a mobile node home 330 network may not assign statically a home agent to the mobile node to 331 maintain flexibility in the allocation of the home agent to achieve 332 better load sharing and fault tolerance. 334 In this case, the mobile node MAY use the dynamic home agent address 335 discovery mechanism to find the address of a suitable home agent on 336 its home link. 338 The current Mobile IPv6 specification describes a dynamic Home Agent 339 discovery procedure; as an alternative, this document describes 340 another home agent assignment procedure relying on the present AAA 341 infrastructure. 343 Whereas the current dynamic home agent address discovery mechanism 344 requires many round trips between the mobile node and its home domain 345 thus resulting in additional signaling over the access link and 346 between the home and visited domains; and also adding more delay in 347 the procedure, the solution relying on the AAA infrastructure only 348 requires one round trip. 350 And instead of sending specific IP address to request for a Home 351 address/Home agent in the Home/Visited domain, the proposed solution 352 is based on flags: less data thus needs to be sent over the access 353 link, and the AAAh (AAAv) instead creates the binding update message 354 when assigning the home agent. 356 4.3. Key distribution 358 Many security associations need to be dynamically established such 359 as: 361 * the security association between the mobile node and the visited 362 network to protect data (e.g. confidentiality and integrity 363 protection) over the access link 365 * the security association between the mobile node and the home 366 agent, to authenticate the binding update/acknowledgement 367 messages. According to the current specifications, after the 368 dynamic home agent address discovery is performed, the mobile node 369 sends a Binding Update to the selected Home agent to create the to 370 create a forwarding entry in the route table for the home address 371 associated with the MN. This Binding Update MUST be authenticated, 372 therefore a key distribution, e.g. IKE, may need to be executed. 373 This requires many messages to be exchanged between the mobile 374 node and the Home Agent. 376 As an alternative, after the authentication and authorization steps, 377 the AAA servers can be involved and play a role in the key generation 378 and/or the key distribution. 380 Diameter Mobile IPv4 Application defines one key distribution 381 mechanism; for Mobile IPv6, many different schemes could be applied 382 thus providing more flexibility and different properties as outlined 383 in the following sections. 385 4.4. Optimization of Binding Updates 387 As previously explained, in addition to authentication, authorization 388 and key distribution functionalities, the AAA servers can perform 389 mobility procedures such as dynamic home agent assignment. In case, 390 the IPv6 mobile node already has a pre-configured Home Agent, some 391 optimization can also be achieved by having the mobile node 392 encapsulating the binding update to its Home agent in the AAA request 393 message. 395 4.5. Summary 397 MN authentication is in general required to grant access to a MN to 398 the foreign domain. In fact, this may be needed in most of the cases 399 even if access to the foreign domain resources is free. Due to the 400 fact that the MN is away from its home network and hence considered 401 roaming the MN needs to perform also mobility procedures to obtain 402 reachability in the new location. Optionally, key distribution may be 403 need to take place. Using the AAA infrastructure to achieve these 404 functions can significantly reduce inter domain signaling and time 405 delay of the overall procedure performed by a MN to get access to the 406 foreign domain. 408 Currently the mobile node first gets authenticated using the AAA 409 infrastructure to obtain network access, then it may perform dynamic 410 home agent address discovery [4] and set up a security association 411 (using e.g. Internet Key Exchange [5]) with the selected Home agent 412 before sending a Binding Update. This will require many round trips 413 between the foreign domain and the home domain, whereas the use of 414 the AAA infrastructure provides a more efficient and quicker 415 alternative. 417 5. Mobile IPv6 Application Diameter messages 419 This memo introduces some new Command codes (AA-Registration-Request, 420 AA-Registration-Answer, Home-Agent-MIPv6-Request, Home-Agent- 421 MIPv6-Answer) and AVPs (MIP-Binding-Update AVP, MIP-Binding- 422 acknowledgement AVP, MIPv6-Mobile-Node-Address AVP, MIPv6-Home-Agent- 423 Address AVP, MIPv6-Feature-Vector AVP, Key-Request AVP, MN-Key- 424 Distribution AVP, Key-Distribution AVP) to achieve all the previously 425 identified functionalities. 427 5.1. Command Codes 429 This document introduces four new Command Codes: 431 * AA-Registration-Request Command (ARR) (Code TBD) 433 * AA-Registration-Answer Command(ARA) (Code TBD) 435 * Home-Agent-MIPv6-Request Command (HOR) (Code TBD) 437 * Home-Agent-MIPv6-Answer Command (HOA) (Code TBD) 439 5.2. AVPs 441 5.2.1. MIP-Binding-Update AVP 443 The MIP-Binding-Update AVP (AVP Code TBD) is of type OctetString and 444 contains the Mobile IP Binding Update message. 446 5.2.2. MIP-Binding-acknowledgement AVP 448 The MIP-Binding-acknowledgement AVP (AVP Code TBD) is of type 449 OctetString and contains the Mobile IP Binding Acknowledgement 450 message sent by the Home Agent to the MN. 452 5.2.3. MIPv6-Mobile-Node-Address AVP 454 The Mobile-Node-Address AVP (AVP Code TBD) is of type IPAddress and 455 contains the Mobile Node's Home Address. 457 5.2.4. MIPv6-Home-Agent-Address AVP 459 The Home-Agent-Address AVP (AVP Code TBD) is of type IPAddress and 460 contains the Mobile Node's Home Agent Address. 462 5.2.5. MIPv6-Feature-Vector AVP 464 The MIPv6-Feature-Vector AVP (AVP Code TBD) is of type Unsigned32 and 465 allows for dynamic Home Agent assignment in Home Domain. In the basic 466 proposal, only one flag is defined; the other ones are reserved for 467 the enhanced version and for future utilization. 469 Flag values currently defined include: 471 1 Home-Agent-Requested: This flag is set to 1 when the 472 mobile node requests for a dynamic home agent 473 assignment. When this flag is set to 1, a dynamic 474 session key to be shared between the MN and the HA is 475 also required in order to authenticate BUs from the MN 476 to the HA: the MN may indicate through some Security Key 477 Request the methods it supports to compute it; or a 478 default method known to the MN and the AAAh should 479 exist(e.g. pre-set by the home domain and communicated 480 to the MN at subscription time). 482 5.2.6. Security Key AVPs 484 The AAA servers can play a role in key distribution and many methods 485 can be used with their own properties and characteristics. The 486 security keys AVPs format and utilization will be described in more 487 details in the next versions as well as the AAA servers' behaviors. 489 6. Information exchange between the mobile node and the AAA Client 491 Although this document is not intended to specify any particular 492 mechanism to convey information between the mobile node and the AAA 493 Client, the information that needs to be exchanged is described. The 494 set of information identified in the follow can actually be conveyed 495 between the mobile node and the network in a different suitable 496 manner outside the scope of this document (e.g. ICMP, the protocol 497 defined by the PANA WG, etc.). The extensions defined for Diameter 498 allow for any of these alternatives, thus enabling such extensions to 499 be deployed independently of the choice of the protocol used between 500 the MN and the network. 502 6.1. MIP Feature Data 504 Contrary to Mobile IPv4 where the Mobile nodes send a Registration 505 Request with specific IP addresses values to request for dynamic home 506 agent assignment in home/visited networks; the IPv6 mobiles nodes 507 SHOULD use some MIP Feature data whose content includes the 508 information required in the previously defined MIPv6 Feature Vector 509 AVP: The IPv6 mobile nodes will not use specific IPv6 addresses 510 values but use flags and this will significantly reduces the amount 511 of data to be sent over the access link. In addition, the attendant 512 will only need to encapsulate that data in the corresponding 513 MIPv6-Feature-Vector AVP. 515 The MIP Feature data could be sent as an extension to ICMPv6 516 messages, a new Destination Option or carried in any other way. 518 6.2. EAP Data 520 The IPv6 Mobile Node should be able to use different authentication 521 methods such as the different EAP types. 523 The EAP Data could be sent as an extension to ICMPv6 messages, 524 carried using the protocol defined by the PANA WG or any other 525 protocol. 527 6.3. Security Key Data 529 This document does not defines the protocol between the mobile nodes 530 and the network but the mobile node SHOULD use some key request to 531 indicate the keys it needs, but also the methods it supports to 532 generate them. 534 Those Security Key data SHOULD contain the relevant information so 535 the AAA client can create the corresponding Security Keys AVPs. 537 6.4. Embedded Data 539 The embedded data enables the mobile node to send a binding update at 540 the same time the mobile node gets authorized/authenticated by the 541 network (e.g. by mechanism that the protocol defined by the PANA WG 542 will provide) thus saving round trips between the home and the 543 visited domains. 545 7. Basic Protocol Overview 546 7.1. Authentication 548 Authentication is required before providing network access to the 549 user. 551 Different authentication should be supported to allow more 552 flexibility; but as demonstrated in [6], both network and user 553 authentication should be supported. 555 And current authentication mechanisms, even those recently specified 556 in different standardization fora (e.g. CAVE based security functions 557 in IS41 Systems) have security flaws. 559 For these reasons, even as previously mentioned any existing 560 authentication could be used, in the following illustrations and 561 procedures, a mutual challenge response based authentication method 562 will be suggested and used as default. 564 The authentication mechanism assumed here assumes that a Local 565 Challenge is broadcast over the access link e.g. in Router 566 Advertisement messages. 568 7.2. Information flows 570 Basic Procedure with dynamic Home Agent assignment in the Home 571 network or pre-configured Home Agent 573 Mobile Node AAA Client AAAv AAAh Home Agent 574 ----------- ----------- ------------ ---------- ---------- 575 Advertisement & 576 <---1.1 - Challenge 577 -1.2 --------> 578 1.3 ARR-------------> 579 1.4 ARR------------> 580 1.5 HOR-------> 581 <------1.6 HOA 582 <---------1.7 ARA 583 <------------1.8 ARA 584 <-------1.9 586 7.3. MN Considerations 588 7.3.1. Generation of information in MN 590 1) When entering a new network or at power up, the MN listens to the 591 router advertisements and retrieves: 593 The Local Challenge 594 The visited network identifier 595 The information to derive the CoA 597 2) It computes the CoA, and based on the following information, 599 * The NAI 600 * The long-term security key shared with its AAAh 601 * The Home Address: in the basic mode, the mobile node is 602 assumed to have a pre-configured Home IP address 603 * The Home Agent (if any), otherwise MN can request to have one 604 assigned 606 creates a message with the CoA as the Source IP address and the AAA 607 Client address as the Destination IP address. (The MN can learn the 608 IP address of the AAA Client through router advertisements or others 609 mechanisms outside the scope of this document.) As previously 610 explained, the mobile node also sends its NAI. 612 3) The MN optionally generates a Host Challenge that it will send to 613 the network for both network authentication and anti replay attacks. 614 Then the MN computes the MN authentication data using the long-term 615 key, the host challenge, the visited network identifier, the local 616 challenge, and an authentication algorithm it shares with its home 617 network. The MN authentication data is then sent to the AAA Client, 619 4) If the MN does not have a Home Agent and requests one, the MN 620 includes some MIP Feature data with the Home-Agent-Requested flag set 621 to 1. The home agent will then be assigned by the home AAA server, 622 and the binding update will be sent by the AAA server to the Home 623 Agent on behalf of the mobile node that, in turn, does not need to 624 send any. 626 If the MN have a pre configured Home Agent, it may creates the 627 binding update message and sends it encapsulated to the AAA client. 628 The Binding Update message will be forwarded to the designated home 629 agent via the AAA infrastructure. This binding update message has 630 the MN IP CoA as the source IP address, the pre-configured HA as the 631 destination IP address and the BU option with the pre-configured Home 632 IP address in the Home address option. 634 5) The MN may also requests for some security keys thanks to the 635 Security Key Request. 637 The MN SHOULD perform authentication in the following cases: 639 * When changing visited domain: MN can know that by 640 listening the router advertisements 641 * When requesting session keys 642 * When requesting a Home Agent assignment 644 7.3.2. Replies to MN 646 When receiving the reply from the AAA Client, the MN: 648 * Authenticates the network thanks to the network authentication 649 data sent by the AAA Client 651 * If the MN requested a Home agent, it will learn and store the Home 652 Agent address from the source IP address of the Home Binding 653 Acknowledgement. 655 The MN creates the security associations from the keying material 656 received. 658 7.4. AAA Client Operation 660 As indicated above, the mobile node may interact with the AAA Client 661 to perform authentication/authorization and optionally Mobile IP 662 procedures. Thus, the AAA client may perform authentication functions 663 and optionally Mobile IP functions 665 When the AAA Client receives an authentication request message from a 666 IPv6 Mobile node: 668 The AAA Client first verifies the freshness of the request thanks to 669 the Local Challenge contained in it (i.e. the MN may use an older 670 Local Challenge) and if successful, performs Duplicate Address 671 Detection and creates a Diameter ARR (AA-Registration-Request) [7] 672 message carrying the following information to the AAAh: 674 * User Name AVP [7] carrying the user's NAI 676 * EAP AVP to carry the authentication data for mutual authentication 677 derived from the content of the received authentication data 679 * if some MIP feature data were received from the MN, a 680 MIPv6-Feature-Vector AVP whose content is derived from the MIP 681 feature data, sent within the ARR message it sends to the AAAv 683 * MIP-Binding Update AVP if the MN sent a Home Binding Update as 684 Embedded data 686 * MIPv6-Home-Agent-Address AVP if the MN sent a binding update 687 message: the Home agent address value is extracted from the 688 Destination IP address field of the embedded home binding update. 689 This AVP enables the AAAh to know where to send the MIP-Home- 690 binding-Update AVP if one was present. 692 * if the MN provides some Key Request data, some Security Key AVPs 693 whose content is derived from the Key Request data. 695 When receiving an ARA [7] (AA-Registration-Answer) message from AAAv, 696 the AAA Client converts the message to the appropriate protocol to 697 the MN; this message carries: 699 * the authentication data 701 * Binding Acknowledgement as Embedded Data if MN sent a home Binding 702 Update or requested for a dynamic home agent assignement. 704 The message may also include: 706 * Keying material to set up the different session keys, converted 707 and conveyed in the appropriate protocol by the AAA Client from 708 the Security Key AVPs. When the MN asks for a dynamic Home Agent, 709 AAAh SHOULD compute the security key to be shared between MN and 710 the HA for authenticating subsequent Binding Updates, and sends 711 the corresponding keying material to the MN. 713 7.5. AAAv Operation 715 When AAAv receives an ARR message [7]: 717 First the AAAv verifies the message is coming from a valid AAA Client 718 and then, checks the MIPv6 Feature Vector AVP, and then sends it to 719 the MN's home AAA server. 721 When receiving a ARA message from the AAAh, the AAAv MAY optionally, 722 according to the behaviour specific for speficic EAPs or other 723 mechanisms defined elsewhere, store locally information contained in 724 the AVPs of the message received from the AAAh (e.g. session keys, 725 etc.) and then forwards the message to the AAA Client. 727 7.6. AAAh operations 729 * When receiving an ARR message from an AAAv, the AAAh first 730 verifies the message is coming from a valid AAAv. Security 731 associations between AAA server are outside the scope of the 732 present document. 734 The AAAh then authenticates the user using the NAI provided by the MN 735 as MN identity. If the mobile Node is successfully authenticated: 737 * AAAh also computes some network authentication data based on the 738 Host Challenge and eventually other information depending on the 739 authentication algorithm adopted. 741 Depending on the authentication method requirements, the AAAh may 742 exchange many messages with the MN via the AAAv (e.g. for a user 743 authentication mechanism that requires more than one round-trip): 744 AAAh may send a ARA Command with the appropriate authentication 745 information and indication, which will be converted to EAP data by 746 the AAA Client to the MN and conveyed to the MN in a suitable manner 747 (outside the scope of this document). The number of round trips 748 varies depending on the authentication mechanism used. 750 * If the MN asks for some security keys, the AAAh performs the 751 appropriate steps and eventually sends the corresponding messages 752 to achieve the key distribution: many mechanisms exist and some of 753 them will be described later on. Such steps may require the AAAh 754 to distribute keys and keying material to the MN, to other AAA 755 servers or other nodes. 757 * If a MIPv6-Home-Agent-Address AVP is present: the AAAh checks that 758 the address is that of a known and valid Home Agent, and one that 759 the Mobile Node is allowed to request. AAAh then forwards the MIP- 760 Home-Binding-Update AVP to the Home Agent in a HOR (Home-Agent- 761 MIP-Request) message. 763 * If no MIPv6-Home-Agent-Address AVP is present, AAAh looks at the 764 MIPv6-Feature-Vector AVP if any. If present, AAAh performs the 765 dynamic home agent assignment in the Home network: 767 Mobile Node AAA Client AAAv AAAh Home Agent 768 ----------- ----------- ------------ ---------- ---------- 769 Advertisement & 770 <---1.1 -- Challenge 771 -1.2 --------> 772 1.3 ARR-------------> 773 1.4 ARR----------> 774 1.5 HOR-------> 775 <--------1.6 HOA 776 <-------1.7 ARA 777 <------------1.8 ARA 778 <-------1.9 780 (1.5) AAAh allocates a Home agent on behalf of the MN: this can be 781 done in a variety of ways, including using a load balancing 782 algorithm in order to keep the load on all HAs equal. 784 * AAAh sends a HOR message to the HA including a newly created 785 binding update. 787 * AAAh sends some security keying material to allow the Home 788 Agent to comupte the key(s) for the security association 789 between the MN and the Home Agent to authenticate future 790 Binding Updates. 792 (1.6) the Home Agent creates the Binding Cache and computes the 793 key(s) for the security association with the MN from the data 794 received. It also generates a Binding Acknowledgement message to 795 be sent encapsulated to the MN. 797 * The HA sends a HOA message to the AAAh including the Binding 798 Ack. 800 (1.7) AAAh may also compute other keying material according to the 801 keys requested by the MN and send it to the MN passing through the 802 AAAv. 804 * AAAh then send an ARA message to the AAAv including the MIP- 805 Binding-acknowledgement AVP if the MN sent an embedded BU or 806 request for a HA. 808 7.7. Home Agent Behavior 810 Upon receipt of the HOR, the Home Agent first processes the DIAMETER 811 message: if the HOR is invalid, a HOA is returned with the Result- 812 Code AVP set to DIAMETER_ERROR_BAD_HOR. Otherwise, the Home Agent 813 processes the MIP-Binding-update AVP and creates the Binding 814 Acknowledgement, encapsulating it within the MIP-binding- 815 acknowledgement AVP. 817 HA also creates the Binding Cache and computes the key(s) for the 818 security association with the MN from the data received. 820 8. Enhanced features 822 In addition to the previously described features, additional features 823 can be supported by the AAA infrastructure for the inter-domain 824 roaming of an IPv6 mobile node, thus providing more flexibility and 825 allowing new options to the services providers to develop business 826 models. 828 A IPv6 mobile node can have a pre-configured home address, may have a 829 pre-configured home agent or request for one and, as explained in the 830 previous section, the basic features of the Mobile IPv6 Diameter 831 Application allow an optimization of the authentication, the binding 832 update, the optional home agent assignment in the home domain and the 833 key distribution procedures. 835 Optionally, two enhanced features are suggested: 837 * The dynamic Home agent assignment in the Visited Domain 838 * The dynamic Home address assignment 840 8.1. Dynamic Home Agent/ Home Address assignment in Visited domain 842 The Dynamic Home Agent assignment in visited networks allows more 843 flexibility and allows new business scenarios. As an example, service 844 providers may just own a AAA server for accounting purposes and, 845 thanks to roaming agreements, they may offer Mobile IP services to 846 its subscribers. Another scenario where this can be applied is when 847 IPv6 mobile nodes need to obtain reachability from other CN only at 848 the application level, i.e. through a SIP infrastructure. This may be 849 the case of a basic IPv6 MN supporting only voice services through 850 SIP. In such cases, when a CN needs to reach the MN an identifier at 851 the application level (e.g. MN SIP URL) is used, and the CN does not 852 need to know the home address of the MN. Somebody may argue that 853 Mobile IP is not needed at all in such cases, but it may instead be 854 used to support mobility between the initial point of attachment 855 (i.e. when the MN powered up in the foreign domain) and following 856 points of attachment in the foreign domain. 858 8.2. Dynamic Home address assignment in Home Domain 860 The mobile node may not always have a pre-configured IPv6 address and 861 may need to have one dynamically assigned. In addition since the Home 862 Agent and the mobile node home address need to be on the same link, 863 to support dynamic home agent assignment in visited networks, dynamic 864 home address assignment in visited networks is supported. 866 Finally, this dynamic Home address feature provides more flexibility 867 to the service provider even when the Home agent is to be assigned in 868 the Home network since the Home agent and the home address should be 869 on the same subnet. Additionally, the scenario described in section 870 7.2 of a MN node needing reachability only at the application layer 871 applies to this case too. 873 8.3. Enhanced AVPs 875 In addition to the Command Codes and AVPs described in section 4, 876 some new AVP need to be defined to support the enhanced features. 878 8.3.1. MIPv6-Feature-Vector AVP 880 In the extended mode, dynamic home agent assignment in the visited 881 network is feasible.Additional flags of the MIPv6-Feature-Vector AVP 882 are therefore defined. 884 The following flags allow the Visited AAA server, AAAv, to inform of 885 its capabilities and if the Home agent is assigned in the visited 886 network, the Home address must also be assigned in the visited 887 network. 889 The AAA Client includes a MIPv6-Feature-Vector AVP within the ARR 890 message it sends to the AAAv if the MN sent some MIP Feature data. 892 Flag values currently defined include: 894 1 Home-Agent-Requested: This flag is set to 1 when the 895 mobile node requests for a dynamic home agent 896 assignment. When this flag is set to 1, a dynamic 897 session key to be shared between the MN and the HA is 898 also required in order to authenticate BUs from the MN 899 to the HA: the MN may indicate through some Security Key 900 Request the methods it supports to compute it; or a 901 default method known to the MN and the AAAh should 902 exist(e.g. pre-set by the home domain and communicated 903 to the MN at subscription time). 905 2 Mobile-Node-Home-Address-Requested flag: This flag is 906 set to 1 if the mobile node does not have any Home 907 address and requires one. Default value is 0. 909 4 Home-Address-Allocatable-Only-in-Home-Domain flag: This 910 flags is set to 1 if the mobile node requests for one 911 Home address and wants it to be assigned by its home 912 network. Default value is 0 and means that the MN does 913 not have any preference on whether the Home Address 914 shall be allocated in the home domain and visited 915 domain. 917 8 Home-Agent-in-Visited-Domain flag: The mobile node 918 indicates its preference to have its Home Agent 919 allocated in the visited domain by having this flag set 920 to 1 922 16 Visited-Home-Agent-Available flag: The Visited Domain 923 sets this flag to 1 if the MN asks a dynamic Home Agent 924 assignment in the Visited Domain and the Visited Domain 925 agrees to allocate one to the MN. 927 9. Enhanced Protocol Overview 929 The enhanced mode allows dynamic home agent assignment in the visited 930 network and dynamic home address assignment. The mobile node may not 931 have any preconfigured home address nor any home agent. The following 932 text describes the different entities' behaviors in the Enhanced 933 mode. 935 The authentication procedure is the same than the one described 936 above. 938 All the functionalities (key distribution, optimization of Binding 939 Upate, dynamic Home Agent assignment in Home network) of the basic 940 mode are present but in addition the Home agent can be assigned in 941 the visited network and the home address can be dynamically assigned 942 either in the home or visited domain: the entities behaviours and the 943 way the corresponding AVPs are processed, are explained 945 9.1. Information flow 947 Enhanced Procedure with dynamic Home agent assignment in the visited 948 network and dynamic home address assignment in home or visited domain 950 Mobile Node AAA Client Home Agent AAAv AAAh 951 ----------- ----------- ------------- ---------- ---------- 952 <---2.1 Challenge--- 953 -2.2 -----> 954 ----------2.3 ARR-------------> 955 ---2.4 ARR----> 956 <--2.5 HOR----- 957 <---2.6 HOR--- 958 ----2.7 HOA---> 959 ---2.8 HOA----> 960 <--2.9 ARA----- 961 <-----------2.10 ARA------------ 962 <-2.11-- 964 9.2. MN Considerations 966 9.2.1. Generation of information in MN 968 The mobile node performs the same steps as in the basic mode (steps 969 (1), (2), (3) section 6.3.1) and then 971 4) If the MN does not have a Home Address and requests one, the MN 972 also includes some MIP Feature data with the Mobile-Node-Home- 973 Address-Requested flag set to 1: 975 * If MN wants its Home address to be allocated by its home network, 976 it also sets the value of Home-Address-Allocatable-Only-in-Home- 977 Domain flag to 1. 979 If the MN does not have a Home Agent and requests one, the MN also 980 includes some MIP Feature data with the Home-Agent-Requested flag set 981 to 1. The home agent will then be assigned by the AAA server, and the 982 binding update will be sent by the AAA server to the Home Agent on 983 behalf of the mobile node that, in turn, does not need to send any. 985 * If MN wants its Home agent to be allocated by the visited network, 986 it also sets the Home-Agent-in-Visited-Network flag to 1. 988 The following table describes the different supported cases and the 989 flags that need to be set according to the needs: 991 HD means Home Domain 992 VD means Visited Domain 993 NP means MN has No Preference 994 X means not supported 996 P: Mobile-Node-Home-Address-Requested flag 997 H: Home-Address-Allocatable-Only-in-Home-Domain 998 A: Home-Agent-Requested 999 V: Home-Agent-In-Visited-Network 1001 +---------+------------------------------------------------+ 1002 | | Home agent Requested | 1003 +---------+---+--------------------+-----------------------+ 1004 | | | YES | NO | 1005 | +---+--+-----+-----+-----+-----------------------+ 1006 | | | | HD | VD | NP | | 1007 |Home addr| +--+-----+-----+-----+-----------------------+ 1008 |Requested| |HD| PAH | x | x | PH | 1009 | | +--+-----+-----+-----+-----------------------+ 1010 | |YES|VD| x |PAV | x | x | 1011 | | +--+-----+-----+-----+-----------------------+ 1012 | | |NP| x | x |PA | P | 1013 | +---+--+-----+-----+-----+-----------------------+ 1014 | | | | | | | | 1015 | | NO| | A* | x | x | no MIP Feature data | 1016 | | | | | | | | 1017 +---------+---+--+-----+-----+-----+-----------------------+ 1019 A*: MN already has a home address in its Home network and may request 1020 for a Home Agent. The HA can thus only be assigned in the Home 1021 Network. 1023 While the MN gets authenticated and authorized, if the MN already has 1024 a home address and a home agent, it can send a Home Binding Update 1025 together with the request to be authorized and authenticated to save 1026 one round trip over the access link and between the visited and home 1027 networks. This binding update is in this case sent as Embedded Data: 1029 The Home Binding Update has: 1031 * The H flag set to 1. 1032 * The source IP address equals to the CoA 1033 * The destination IP address set to the Home agent address 1034 * The Home Address option set to the MN Home address 1036 5) The MN may also requests for some security keys thanks to the 1037 Security Key Request. 1039 The MN SHOULD perform authentication in the following cases: 1041 * When changing visited domain: MN can know that by 1042 listening the router advertisements 1043 * When requesting session keys 1044 * When requesting a Home Agent assignment 1045 * When requesting a home address assignment 1047 9.2.2. Replies to MN 1049 When receiving the reply from the AAA Client, the MN: 1051 * Authenticates the network thanks to the network authentication 1052 data sent by the AAA Client 1054 * If the MN requested a Home agent, it will learn and store the Home 1055 Agent address from the source IP address of the Home Binding 1056 Acknowledgement. 1058 * If the MN did not have a Home IP address and requested for one, 1059 the MN will learn and store the assigned home address from the 1060 home address option of the Home Binding Acknowledgement (embedded 1061 data). 1063 The MN creates the security associations from the keying material 1064 received. 1066 9.3. AAA Client Operation 1068 As indicated above, the mobile node may interact with the AAA Client 1069 to perform authentication/authorization and optionally Mobile IP 1070 procedures. Thus, the AAA client may perform authentication functions 1071 and optionally Mobile IP functions 1073 When the AAA Client receives an authentication request message from a 1074 IPv6 Mobile node: 1076 The AAA Client first verifies the freshness of the request thanks to 1077 the Local Challenge contained in it (i.e. the MN may use an older 1078 Local Challenge) and if successful, performs Duplicate Address 1079 Detection and creates a Diameter ARR (AA-Registration-Request) [7] 1080 message carrying the following information to the AAAh: 1082 * User Name AVP [7] carrying the user's NAI 1084 * EAP AVP to carry the authentication data for mutual authentication 1085 derived from the content of the received authentication data 1087 * if some MIP feature data were received from the MN, a 1088 MIPv6-Feature-Vector AVP whose content is derived from the MIP 1089 feature data, sent within the ARR message it sends to the AAAv 1091 * MIP-Binding Update AVP if the MN sent a Home Binding Update as 1092 Embedded data 1094 * MIPv6-Home-Agent-Address AVP if the MN sent a Home binding update: 1095 the Home agent address value is extracted from the Destination IP 1096 address field of the embedded home binding update. This AVP 1097 enables the AAAh to know where to send the MIP-Home-binding-Update 1098 AVP if one was present. 1100 * if the MN provides a Key Request, some Security Key AVPs whose 1101 content is derived from the Key Request. 1103 When receiving an ARA [7] (AA-Registration-Answer) message from AAAv, 1104 the AAA Client converts the message to appropriate protocol to the 1105 MN; this message carries: 1107 * the authentication data 1109 * Binding Acknowledgement as Embedded Data if MN sent a home Binding 1110 Update or requested for a dynamic home agent assignment. 1112 The message may also include: 1114 * Keying material to set up the different session keys, in different 1115 Security Key Data created by the AAA Client from the Security Key 1116 AVPs. When the MN asks for a dynamic Home Agent, AAAh must compute 1117 the security key to be shared between MN and the HA for 1118 authenticating subsequent Binding Updates, and sends the 1119 corresponding keying material to the MN. 1121 9.4. AAAv Operation 1123 When AAAv receives an ARR message [7]: 1125 First the AAAv verifies the message is coming from a valid AAA Client 1126 and then, checks the MIPv6 Feature Vector AVP: 1128 * If the MN requested a Home Agent by setting the Home-Agent- 1129 Requested flag to 1, and does not specify that this one should be 1130 assigned only in its Home domain by setting the Home-Address- 1131 Allocatable-Only-in-Home-Domain flag to 1, the AAAv checks if it 1132 can allocate a Home Agent for the mobile node in the visited 1133 domain. If AAAv can allocate a Home Agent in the visited domain, 1134 it indicates this to the AAAh by setting the Visited-Home-Agent- 1135 Available flag to 1 of the MIPv6 Feature Vector AVP forwarded to 1136 the AAAh. 1138 When receiving a HOR message from the AAAh for a dynamic Home Agent 1139 assignment in the visited network, the AAAv performs the dynamic Home 1140 agent assignment and MAY perform some key distribution depending on 1141 the mechanisms. 1143 When receiving a ARA message from the AAAh, the AAAv MAY optionally, 1144 according to the behavior specific for speficic EAPs or other 1145 mechanisms defined elsewhere, store locally information contained in 1146 the AVPs of the message received from the AAAh (e.g. session keys, 1147 etc.) and then forwards the message to the AAA Client. 1149 9.5. AAAh operations 1151 * When receiving an ARR message from an AAAv, the AAAh first 1152 verifies the message is coming from a valid AAAv. Security 1153 associations between AAA server are outside the scope of the 1154 present document. 1156 The AAAh then authenticates the user using the NAI provided by the MN 1157 as MN identity. If the mobile Node is successfully authenticated: 1159 * AAAh also computes some network authentication data based on the 1160 Host Challenge and eventually other information depending on the 1161 authentication algorithm adopted. 1163 Depending on the authentication method requirements, the AAAh may 1164 exchange many messages with the MN via the AAAv (e.g. for a user 1165 authentication mechanism that requires more than one round-trip): 1166 AAAh may send a ARA Command with the appropriate authentication 1167 information and indication, which will be converted to EAP data by 1168 the AAA Client to the MN or conveyed to the MN in other suitable 1169 manner (outside the scope of this document). The number of round 1170 trips varies depending on the authentication mechanism used. 1172 * If the MN asks for some security keys, the AAAh performs the 1173 appropriate steps and eventually sends the corresponding messages 1174 to achieve the key distribution: many mechanisms exist and will be 1175 described later on. Such steps may require the AAAh to distribute 1176 keys and keying material to the MN, to other AAA servers or other 1177 nodes. 1179 * If a MIPv6-Home-Agent-Address AVP is present: the AAAh checks that 1180 the address is that of a known and valid Home Agent, and one that 1181 the Mobile Node is allowed to request. AAAh then forwards the MIP- 1182 Home-Binding-Update AVP to the Home Agent in a HOR (Home-Agent- 1183 MIP-Request) message including the appropriate key material to set 1184 up the security association between the MN and the Home Agent. 1186 * If no MIPv6-Home-Agent-Address AVP is present, AAAh looks at the 1187 MIPv6-Feature-Vector AVP if any. Depending on the mobile node 1188 request (Home-Agent-in-Visited-Network flag, Home-Address- 1189 Allocatable-Only-in-Home-Domain), the visited network capabilities 1190 (Visited-Agent-Available AVP) and the local policy, the AAAh 1191 decides whether to assign the HA in the home or visited network: 1193 9.5.1. Home Agent Assignement in Visited Network 1195 If the AAAh accepts the HA to be assigned in the visited domain, the 1196 following exchange of messages takes place: 1198 Mobile Node AAA Client Home Agent AAAv AAAh 1199 ----------- ----------- ------------- ---------- ---------- 1200 <---2.1 Challenge- 1201 -2.2 ----> 1202 ----------2.3 ARR-------------> 1203 ---2.4 ARR----> 1204 <--2.5 HOR----- 1205 <---2.6 HOR----- 1206 ----2.7 HOA-----> 1207 ---2.8 HOA----> 1208 <--2.9 ARA----- 1209 <-----------2.10 ARA------------ 1210 <-2.11 --- 1212 (2.5): AAAh sends a HOR message to the AAAv with neither any 1213 MIPv6-Mobile-Node-Address AVP nor any MIPv6-Home-Agent-Address 1214 AVP. 1216 * AAAh may send some keying material for HA to derive the key(s) 1217 for the security association between the MN and the Home Agent 1218 to authenticate future Binding Updates depending on the key 1219 distribution mechanism chosen 1221 * AAAh may also send other keying material according to the keys 1222 requested by the MN 1224 (2.6): AAAv assigns a Home agent and then creates and sends it a 1225 newly created Binding Update encapsulated in the HOR message. 1227 * AAAv may assign Home IP address for the MN and informs the Home 1228 Agent by adding a MIPv6-Mobile-Node-Address AVP in the HOR 1229 message; or let the Home Agent assigns the Home address by not 1230 providing a MIPv6-Mobile-Node-Address AVP in the HOR message. 1232 * AAAv may forward to the Home Agent some keying material 1233 depending on the key distribution mechanism adopted to set up 1234 the security association between the MN and the Home Agent 1236 (2.7): The Home agent assigns a Home IP address if requested and 1237 creates a Binding Cache for the MN. 1239 * The Home agent creates the Security Association according to 1240 the mechanism adopted 1242 * The Home Agent creates the Binding Acknowledgement to be sent 1243 encapsulated to the MN. 1245 * The Home Agent sends back a HOA to the AAAv to inform it of the 1246 status: it includes the assigned Mobile Node Home Address if 1247 the Home Agent assigned one; it also includes the Binding ack 1248 created by the Home Agent to be sent encapsulated to the MN. 1250 (2.8) The AAAh is informed of the assigned Home IP address 1251 (contained in the MIPv6-Mobile-Node-Address AVP) and the Home 1252 Agent address (contained in the MIPv6-Home-Agent-Address AVP) by 1253 the HOA message sent from the AAAv. 1255 (2.9) The AAAh sends the AAAv an ARA carrying the Home IP address, 1256 the Home Agent IP address, the keying material with the previous 1257 information. 1259 9.5.2. Home Agent Assignment in Home Network 1261 If the AAAh decides to assign the HA in the Home network, the 1262 following exchange of messages takes place: 1264 Mobile Node AAA Client AAAv AAAh Home Agent 1265 ----------- ----------- ------------ ---------- ---------- 1266 Advertisement & 1267 <---3.1 -- Challenge 1268 -3.2 -----> 1269 3.3 ARR-------------> 1270 3.4 ARR--------> 1271 3.5 HOR------> 1272 <----3.6 HOA 1273 <------3.7 ARA 1274 <------------3.8 ARA 1275 <-------3.9 1277 (3.5) AAAh allocates a Home agent on behalf of the MN: this can be 1278 done in a variety of ways, including using a load balancing algorithm 1279 in order to keep the load on all HAs equal. 1281 * AAAh sends a HOR message to the HA including a newly created 1282 binding update and: 1284 * The AAAh may allocate a home address for the mobile node and 1285 include it in a MIPv6-Mobile-Node-Address AVP within the HOR or 1286 else leave this allocation responsibility for the HA by leaving 1287 the Home address option of the binding update to zero and not 1288 sending any MIPv6-Mobile-Node-Address AVP. 1290 * AAAh sends some security keying material to allow the Home Agent 1291 to compute the key(s) for the security association between the MN 1292 and the Home Agent to authenticate future Binding Updates. 1294 (3.6) If the Home Agent does not receive any MIP-Mobile-node-address, 1295 and receives a BU with a Home address equals to 0, it assigns a Home 1296 IP address for that user; then creates the Binding Cache and computes 1297 the key(s) for the security association with the MN from the data 1298 received. It also generates a Binding Acknowledgement message to be 1299 sent encapsulated to the MN. 1301 * The HA sends a HOA message to the AAAh including the Binding Ack 1302 and eventually the assigned Home IP address if one was requested. 1304 (3.7) AAAh may also compute other keying material according to the 1305 keys requested by the MN and send it to the MN passing through the 1306 AAAv. 1308 * AAAh then send an ARA message to the AAAv including the 1309 MIPv6-Mobile-Node-Address and MIPv6-Home-Agent-Address AVPs if the 1310 MN did not have any Home address or Home agent. 1312 9.6. Home Agent Behavior 1314 Upon receipt of the HOR, the Home Agent first processes the DIAMETER 1315 message: if the HOR is invalid, a HOA is returned with the Result- 1316 Code AVP set to DIAMETER_ERROR_BAD_HOR. Otherwise, the Home Agent 1317 processes the MIP-Binding-update AVP and creates the Binding 1318 Acknowledgement, encapsulating it within the MIP-binding- 1319 acknowledgement AVP. 1321 If a home address is needed, the Home Agent assigns one and includes 1322 the address in both the Binding acknowledgement message (Home address 1323 option) and in the MIPv6-Mobile-Node-Address AVP. 1325 HA then creates the Binding Cache and computes the key(s) for the 1326 security association with the MN from the data received. 1328 10. Key distribution 1330 As identified in the previous sections, many security keys need to be 1331 set up and shared between the IPv6 mobile nodes and other network 1332 entities, such as: 1334 * the key between the mobile node and its Home Agent to authenticate 1335 the binding Update and Binding acknowledgement messages 1337 * the key between the mobile node and the access router to protect 1338 (e.g. for confidentiality and integrity protection) the data over 1339 the access link. 1341 The AAA entities can play a major role in the computation and 1342 distribution of these security keys. Two key distribution methods, 1343 relying on this AAA infrastructure and allowing authenticated key 1344 distribution, are proposed. 1346 10.1. Key distribution based on Random numbers 1348 The home AAA server generates one random number for each required 1349 security key. Then taking as inputs, to a key derivation algorithm 1350 shared with the mobile node, this random number, the long term key 1351 shared with the mobile node and optionally other data, the home AAA 1352 server derives the desired security key. 1354 This one is securely transmitted to the network entity, the mobile 1355 node wants to share the key with. 1357 And the random number is sent to the Mobile node which can derive the 1358 security session key thanks to the knowledge of the long term key and 1359 the key derivation algorithm shared with its home network. 1361 This key distribution based on Random numbers is currently used in 1362 cellular networks and in the Diameter Mobile IPv4 Application [1] 1364 10.2. Key distribution based on Diffie Hellman 1366 As another possibility, the key distribution can be based on the 1367 Diffie Hellman mechanism. 1369 Diffie Hellman allows two nodes to establish a shared secret key in a 1370 secure fashion. It, although, has a major vulnerability since it does 1371 not allow a node to figure out with whom it is establishing that 1372 secret key. To defeat this vulnerability, the two nodes public values 1373 must be authenticated. 1375 The AAA infrastructure, and more particularly the security 1376 association between the Mobile node and its home network (AAAh) and 1377 the security association between the AAAv and AAAh, can provide that 1378 authentication. 1380 If the mobile node wants to set up a securiy association with an 1381 entity in the visited domain (e.g. home agent assigned in the visited 1382 domain), the mobile node first sends its public Diffie Hellman value 1383 DH_MN authenticated with the long term security association shared 1384 with its AAAh. If the entity with whom the MN wants to set up a 1385 security association is in the visited domain, AAAv retrieves the 1386 entity's Diffie Hellman public value using intra domain security and 1387 sends this value, authenticated with the security association it 1388 shares with the AAAh, to the home network of the MN together with the 1389 message from the MN. 1391 AAAh authenticates the Diffie Hellman Public values of the entity and 1392 the MN. It then sends the MN's Diffie Hellman Public Value to the 1393 AAAv using the security association it shares with AAAv, and sends 1394 the entity's Diffie Hellman Public Value to the MN, authenticated 1395 with the security association shared with the MN. 1397 In this way, AAAh is used to authenticate the Diffie Hellman public 1398 values but as a difference with the previous method, since it does 1399 not have knowledge of the secret values, it can not derive the value 1400 of the session key. This method thus allow to securely distribute 1401 the security keys without having the AAA servers being aware of the 1402 value of those keys. AAA servers are here used as certificate 1403 authorities. 1405 11. Conclusions 1407 The Diameter Mobile IPv6 application defined in this document allows 1408 for support of authentication and authorization of IPv6 mobile nodes 1409 roaming between different domains. In addition, it support key 1410 distribution and mobility by optimizing these procedures. The 1411 application defines also new enhanced features that introduce 1412 flexibility in the definition of business models for service 1413 providers and allow for different types of terminals. 1415 This first version focuses on the different functionalities involved 1416 in the support by the AAA infrastructure of inter domain roaming of 1417 Mobile IPv6 nodes. 1419 12. Security Considerations 1421 The Diameter Mobile IPv6 application defined in this document does 1422 not create new security breaches for the IPv6 MN and the foreign and 1423 visited domain. On the contrary, it allows for an effective and 1424 efficient MN authentication and authorization when roaming between 1425 different domains. 1427 Full Copyright Statement 1429 Copyright (C) The Internet Society (2004). This document is subject 1430 to the rights, licenses and restrictions contained in BCP 78, and 1431 except as set forth therein, the authors retain all their rights. 1433 This document and the information contained herein are provided on an 1434 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1435 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1436 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1437 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1438 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1439 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1441 13. References 1443 [1] Pat R. Calhoun, Charles E. Perkins, "Diameter Mobile IPv4 1444 Application" Internet draft, Internet Engineer Task Force, 1445 November 2001 1447 [2] Diffie, W. and Hellman, M., "New Directions ijn 1448 Cryptography", IEEE Transactions on Information Theory, 1449 Vol. IT-22, Nov. 1976, pp. 664-654 1451 [3] Franck Le, Stefano M. Faccin, "Key distribution mechanisms 1452 for Mobile IPv6" Internet draft, Internet Engineer Task 1453 Force, February 2001 1455 [4] David B. Johnson, Charles Perkins, "Mobility Support in 1456 IPv6" Internet draft, Internet Engineer Task Force, 1457 November 2001 1459 [5] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 1460 RFC 2409, Internet Engineer Task Force, November 1998 1462 [6] Sarvar Patel, "Weaknesses of North American Wireless 1463 Authentication Protocol", IEEE Personal Communications, 1464 June 1997 1466 [7] Pat R. Calhoun, Haseeb Akhtar, Jari Arkko, Erik Guttman, 1467 Allan C. Rubens,Glen Zorn, "Diameter Base Protocol" 1468 Internet draft, Internet Engineer Task Force, November 2001 1470 14. Authors' Addresses 1472 Franck Le 1473 Nokia Research Center 1474 6000 Connection Drive 1475 Irving, TX 75039 1476 USA 1478 Phone: +1 972 374-1256 1479 E-mail: franck.le@nokia.com 1481 Basavaraj Patil 1482 Nokia Corporation 1483 6000 Connection Drive 1484 Irving, TX 75039 1485 USA 1487 Phone: +1 972-894-6709 1488 E-Mail: basavaraj.patil@nokia.com 1490 Charles E. Perkins 1491 Nokia Research Center 1492 313 Fairchild Drive 1493 Mountain View, California 94043 1494 USA 1496 Phone: +1 650-625-2986 1497 E-Mail: charles.perkins@nokia.com 1499 Stefano M. Faccin 1500 Nokia Research Center 1501 6000 Connection Drive 1502 Irving, TX 75039 1503 USA 1505 Phone: +1 972 894-4994 1506 E-mail: stefano.faccin@nokia.com