idnits 2.17.1 draft-ietf-mip6-bootstrap-ps-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 3978, Section 5.1 on line 961. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1074. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1051. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1058. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1064. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** An RFC 3978, Section 5.1 paragraph was found, but not on the first page, as required. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2, 2006) is 6683 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.giaretta-mip6-authorization-eap' is defined on line 968, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-eap-keying-08' is defined on line 974, but no explicit reference was found in the text == Unused Reference: 'I-D.kempf-mip6-bootstrap' is defined on line 980, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2284 (Obsoleted by RFC 3748) == Outdated reference: A later version (-04) exists of draft-giaretta-mip6-authorization-eap-02 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-08 == Outdated reference: A later version (-01) exists of draft-mariblanca-aaa-eap-lla-00 == Outdated reference: A later version (-03) exists of draft-ietf-mip6-ro-sec-02 -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 A. Patel, Ed. 3 Internet-Draft Cisco 4 Expires: July 6, 2006 G. Giaretta, Ed. 5 TILAB 6 January 2, 2006 8 Problem Statement for bootstrapping Mobile IPv6 9 draft-ietf-mip6-bootstrap-ps-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This Internet-Draft will expire on July 6, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 A mobile node needs at least the following information: a home 43 address, home agent address and a security association with home 44 agent to register with the home agent. The process of obtaining this 45 information is called bootstrapping. This document discuss the 46 issues involved with how the mobile node can be bootstrapped for 47 Mobile IPv6 and various potential deployment scenarios for mobile 48 node bootstrapping. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Overview of the Problem . . . . . . . . . . . . . . . . . 3 54 1.2. What is Bootstrapping? . . . . . . . . . . . . . . . . . . 4 55 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5. Motivation for bootstrapping . . . . . . . . . . . . . . . . . 10 60 5.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 10 61 5.1.1. Dynamic Home Address Assignment . . . . . . . . . . . 10 62 5.1.2. Dynamic Home Agent Assignment . . . . . . . . . . . . 11 63 5.1.3. Management requirements . . . . . . . . . . . . . . . 12 64 5.2. Security Infrastructure . . . . . . . . . . . . . . . . . 12 65 5.2.1. Integration with AAA Infrastructure . . . . . . . . . 12 66 5.2.2. "Opportunistic" or "Local" Discovery . . . . . . . . . 13 67 5.3. Topology Change . . . . . . . . . . . . . . . . . . . . . 13 68 5.3.1. Dormant Mode Mobile Nodes . . . . . . . . . . . . . . 13 69 6. Network Access and Mobility services . . . . . . . . . . . . . 14 70 7. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 16 71 7.1. Mobility Service Subscription Scenario . . . . . . . . . . 16 72 7.2. Integrated ASP network scenario . . . . . . . . . . . . . 16 73 7.3. Third party MSP scenario . . . . . . . . . . . . . . . . . 17 74 7.4. Infrastructure-less scenario . . . . . . . . . . . . . . . 18 75 8. Parameters for authentication . . . . . . . . . . . . . . . . 19 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 77 9.1. Security Requirements of Mobile IPv6 . . . . . . . . . . . 21 78 9.2. Threats to the Bootstrapping Process . . . . . . . . . . . 22 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 80 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 81 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 82 13. IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . . 27 83 14. Informative References . . . . . . . . . . . . . . . . . . . . 27 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 85 Intellectual Property and Copyright Statements . . . . . . . . . . 30 87 1. Introduction 89 Mobile IPv6 [RFC3775] specifies mobility support based on the 90 assumption that a mobile node has a trust relationship with an entity 91 called the home agent. Once the home agent address has been learned 92 (for example via manual configuration, anycast discovery mechanisms, 93 or DNS lookup), Mobile IPv6 signaling messages between the mobile 94 node and the home agent are secured with IPsec or with the 95 authentication protocol as defined in [RFC4285]. The requirements 96 for this security architecture are created with [RFC3775] and the 97 details of this procedure are described in [RFC3776]. 99 In [RFC3775] there is an implicit requirement that the MN be 100 provisioned with enough information that will permit it to register 101 successfully with its home agent. However, having this information 102 statically provisioned creates practical deployment issues. 104 This document serves to define the problem of bootstrapping. 105 Bootstrapping is defined as the process of obtaining enough 106 information at the mobile node so that it can successfully register 107 with an appropriate home agent. 109 The requirements for bootstrapping could consider various scenarios/ 110 network deployment issues. It is the basic assumption of this 111 document that certain minimal parameters (seed information) are 112 available to the mobile node to aid in bootstrapping. The exact seed 113 information available differs depending on the deployment scenario. 114 This document describes various deployment scenarios and provides for 115 a set of minimal parameters that are available in each deployment 116 scenario. 118 This document stops short of suggesting the preferred solutions for 119 how the mobile node should obtain information. Such details will be 120 available from separate documents. 122 1.1. Overview of the Problem 124 Mobile IPv6 [RFC3775] expects the mobile node to have a static home 125 address, home agent address (which can be derived from an anycast 126 address) and a security association with a home agent (or multiple 127 home agents). 129 This static provisioning of information has various problems as 130 discussed in Section 5. 132 The aim of this draft is to: 134 o Define bootstrapping. 136 o Identify sample deployment scenarios where MIPv6 will be deployed, 137 taking into account the relationship between the subscriber and 138 the service provider. 140 o Identify the minimal set of information required on the Mobile 141 Node and in the network in order for the mobile node to obtain 142 address and security credentials, to register with the home agent. 144 1.2. What is Bootstrapping? 146 Bootstrapping is defined as obtaining enough information at the 147 mobile node so that the mobile node can successfully register with an 148 appropriate home agent. Specifically, this means obtaining the home 149 agent address and home address, and for the mobile node and home 150 agent to authenticate and mutually construct security credentials for 151 Mobile IPv6. 153 Typically, bootstrapping happens when a mobile node does not have all 154 the information it needs to setup the Mobile IPv6 service. This 155 includes, but is not limited to, the mobile node (MN) not having any 156 information when it boots up for the first time (out of the box), it 157 does not retain any information during reboots, etc. 159 Also, in certain scenarios, after the MN bootstraps for the first 160 time (out of the box), subsequent bootstrapping is implementation- 161 dependent. For instance, the MN may bootstrap every time it boots, 162 bootstrap everytime on prefix change, bootstrap periodically to 163 anchor to an optimal (distance, load etc) HA, etc. 165 1.3. Terminology 167 General mobility terminology can be found in [RFC3753]. The 168 following additional terms are used here: 170 Trust relationship 172 In the context of this draft, trust relationship means that two 173 parties in question, typically the user of the mobile host and the 174 mobility or access service authorizer , have some sort of prior 175 contact in which the mobile node was provisioned with credentials. 176 These credentials allow the mobile node to authenticate itself to 177 the mobility or access service provider and to prove its 178 authorization to obtain service. 180 Infrastructureless relationship 181 In the context of this draft, an infrastructureless relationship 182 is one in which the user of the mobile node and the mobility or 183 access service provider have no previous contact and the mobile 184 node is not required to supply credentials to authenticate and 185 prove authorization for service. Mobility and/or network access 186 service is provided without any authentication or authorization. 187 Infrastructureless in this context does not mean that there is no 188 network infrastructure, such as would be the case for an ad-hoc 189 network. 191 Credentials 193 Data used by a mobile node to authenticate itself to a mobility or 194 access network service authorizer and prove authorization to 195 receive service. User name/passwords, one time password cards, 196 public/private key pairs with certificates, biometric information, 197 etc. are some examples. 199 ASA 201 Access Service Authorizer. A network operator that authenticates 202 a mobile node and establishes the mobile node's authorization to 203 receive Internet service. 205 ASP 207 Access Service Provider. A network operator that provides direct 208 IP packet forwarding to and from the end host. 210 Serving Network Access Provider 212 A network operator that is the mobile node's ASP but not its ASA. 213 The serving network access provider may or may not additionally 214 provide mobility service. 216 Home Network Access Provider 218 A network operator that is both the mobile node's ASP and ASA. 219 The home network access provider may or may not additionally 220 provide mobility service (note that this is a slighlty different 221 definition from RFC 3775). 223 IASP 225 Integrated Access Service Provider. A service provider that 226 provides both authorization for network access, and mobility 227 service. 229 MSA 231 Mobility Service Authorizer. A service provider that authorizes 232 Mobile IPv6 service. 234 MSP 236 Mobility Service Provider. A service provider that provides 237 Mobile IPv6 service. In order to obtain such service, the mobile 238 node must be authenticated and prove authorization to obtain the 239 service. 241 Home Mobility Service Provider 243 A MSP that both provides mobility service and authorizes it. 245 Serving Mobility Service Provider 247 A MSP that provides mobility service but depends on another 248 service provider to authorize it. 250 2. Assumptions 252 o A basic assumption in the Mobile IPv6 [RFC3775] is that there is a 253 trust relationship between the mobile node and its home agent(s). 254 This trust relationship can be direct, or indirect through, for 255 instance, an ASP that has a contract with the MSP. This trust 256 relationship can be used to bootstrap the MN. 258 One typical way of verifying the trust relationship is using 259 authentication, authorization, and accounting (AAA) 260 infrastructure. In this document, two distinct uses of AAA are 261 considered: 263 AAA for Network Access 265 This functionality provides authentication and authorization to 266 access the network (obtain address and send/receive packets). 268 AAA for Mobility Service 270 This functionality provides authentication and authorization 271 for mobility services. 273 These functionalities may be implemented in a single entity or in 274 different entities, depending on the service models described in 275 Section 6 or deployment scenarios as described in Section 7. 277 o Yet another assumption is that some identifier, such as an NAI, as 278 defined in [RFC4283] or [RFC2794] is provisioned on the MN which 279 permits the MN to identify itself to the ASP and MSP. 281 3. Design Goals 283 A solution to the bootstrapping problem has the following design 284 goals: 286 o The following information must be available at the end of 287 bootstrapping, to enable the MN to register with the HA. 289 * MN's home agent address 291 * MN's home address 293 * IPsec SA between MN and HA, IKE pre-shared secret between MN 294 and HA, or shared secret/security association for 295 authentication protocol [RFC4285] 297 o The bootstrapping procedure can be triggered at any time, either 298 by the MN or by the network. Bootstrapping can occur, for 299 instance due to administrative action, information going stale, HA 300 indicating the MN etc. Bootstrapping may be initiated even when 301 the MN is registered with the HA and has all the required 302 credentials. This may typically happen to refresh/renew the 303 credentials. 305 o Subsequent protocol interaction (for example updating the IPsec 306 SA) can be executed between the MN and the HA itself without 307 involving the infrastructure that was used during bootstrapping. 309 o Solutions to the bootstrapping problem should enable storage of 310 user-specific information on entities other than the home agent. 312 o Solutions to the bootstrapping problem should not exclude storage 313 of user-specific information on entities other than the home 314 agent. 316 o Configuration information which is exchanged between the mobile 317 node and the home agent needs to be secured using integrity and 318 replay protection. Confidentiality protection should be provided 319 if necessary. 321 o All feasible deployment scenarios, along with the relevant 322 authentication/authorization models should be considered. 324 4. Non-Goals 326 This following issues are clearly outside the scope of bootstrapping: 328 o Home prefix renumbering is not explicity supported as part of 329 bootstrapping. If the MN executes the bootstrap procedures 330 everytime it powers-on (as opposed to caching state information 331 from previous bootstrap process), then home network renumbering is 332 taken care of automatically. 334 o Bootstrapping in the absence of a trust relationship between MN 335 and any provider is not considered. 337 5. Motivation for bootstrapping 339 5.1. Addressing 341 The default bootstrapping described in the Mobile IPv6 base 342 specification [RFC3775] has a tight binding to the home addresses and 343 home agent addresses. 345 In this section, we discuss the problems caused by the currently 346 tight binding to home addresses and home agent addresses. 348 5.1.1. Dynamic Home Address Assignment 350 Currently, the home agent uses the mobile node's home address for 351 authorization. When manual keying is used, this happens through the 352 security policy database, which specifies that a certain security 353 association may only be used for a specific home address. When 354 dynamic keying is used, the home agent ensures that the IKE Phase 1 355 identity is authorized to request security associations for the given 356 home address. Mobile IPv6 uses IKEv1, which is unable to update the 357 security policy database based on a dynamically assigned home 358 address. As a result, static home address assignment is really the 359 only home address configuration technique compatible with the base 360 specification. 362 However, support for dynamic home address assignment would be 363 desirable for the following reasons: 365 DHCP-based address assignment 367 Some providers may want to use DHCPv6 or other dynamic address 368 assignment (e.g. IKEv2) from the home network to configure home 369 addresses. 371 Recovery from a duplicate address collision 373 It may be necessary to recover from a collision of addresses on 374 the home network by one of the mobile nodes changing its home 375 address. 377 Addressing privacy 379 It may be desirable to establish randomly generated addresses as 380 in [RFC3041] and use them for a short period of time. 381 Unfortunately, current protocols make it possible to use such 382 addresses only from the visited network. As a result, these 383 addresses can not be used for communications lasting longer than 384 the attachment to a particular visited network. 386 Ease of deployment 388 In order to simplify the deployment of Mobile IPv6, it is 389 desirable to free users and administrators from the task of 390 allocating home addresses and specifying them in the security 391 policy database. This is consistent with the general IPv6 design 392 goal of using autoconfiguration wherever possible. 394 Prefix changes in the home network 396 The Mobile IPv6 specification contains support for a mobile node 397 to autoconfigure a home address based on its discovery of prefix 398 information on the home subnet [RFC3775]. Autoconfiguration in 399 case of network renumbering is done by replacing the existing 400 network prefix with the new network prefix. 402 Subsequently, the MN needs to update the mobility binding in the 403 HA to register the newly configured Home Address. However, the MN 404 may not be able to register the newly configured address with the 405 HA if a security association related to that reconfigured Home 406 Address does not exist in the MN and the HA. This situation is 407 not handled in the current MIPv6 specification [RFC3775]. 409 5.1.2. Dynamic Home Agent Assignment 411 Currently, the address of the home agent is specified in the security 412 policy database. Support for multiple home agents requires the 413 configuration of multiple security policy database entries. 415 However, support for dynamic home agent assignment would be desirable 416 for the following reasons: 418 Home agent discovery 420 The Mobile IPv6 specification contains support for a mobile node 421 to autoconfigure a home agent address based on a discovery 422 protocol [RFC3775]. 424 Independent network management 426 An MSP may want to dynamically assign home agents in different 427 subnets; for istance, not require that a roaming mobile node have 428 a fixed home subnet. 430 Local home agents 432 The mobile node's MSP may want to allow the serving ASP to assign 433 a local home agent for the mobile node. This is useful both from 434 the point of view of communications efficiency, and has also been 435 mentioned as one approach to support location privacy. 437 Ease of deployment 439 In order to simplify the deployment of Mobile IPv6, it is 440 desirable to free users and administrators from the task of 441 allocating home agent addresses in a static manner. Moreover, an 442 MSP may want to have a dynamic home agent assignment mechanism to 443 load balance users among home agents located on different links. 445 5.1.3. Management requirements 447 As described earlier, new addresses invalidate configured security 448 policy databases and authorization tables. Regardless of the 449 specific protocols used, there is a need for either an automatic 450 system for updating the security policy entries, or manual 451 configuration. These requirements apply to both home agents and 452 mobile nodes, but it can not be expected that mobile node users are 453 capable of performing the required tasks. 455 5.2. Security Infrastructure 457 5.2.1. Integration with AAA Infrastructure 459 The current IKEv1-based dynamic key exchange protocol described in 460 [RFC3776] has no integration with backend authentication, 461 authorization and accounting techniques unless the authentication 462 credentials and trust relationships use certificates or pre-shared 463 secrets. 465 Using certificates may require the MSP to deploy a PKI, which may not 466 be possible or desirable in certain circumstances. Where a 467 traditional AAA infrastructure is used, the home agent is not able to 468 leverage authentication and authorization information established 469 between the mobile node, the foreign AAA server, and the home AAA 470 server. This would be desirable when the mobile node gains access to 471 the foreign network, in order to authenticate the mobile node's 472 identity and determine if the mobile node is authorized for mobility 473 service. 475 The lack of connection to the AAA infrastructure also means the home 476 agent does not know where to issue accounting records at appropriate 477 times during the mobile node's session, as determined by the business 478 relationship between the MSP and the mobile node's owner. 480 Presumably, some backend AAA protocol between the home agent and home 481 AAA could be utilized, but IKEv1 does not contain support for 482 exchanging full AAA credentials with the mobile node. It is 483 worthwhile to note that IKEv2 provides this feature. 485 5.2.2. "Opportunistic" or "Local" Discovery 487 The home agent discovery protocol does not support an "opportunistic" 488 or local discovery mechanisms in an ASP's local access network. It 489 is expected that the mobile node must know the prefix of the home 490 subnet in order to be able to discover a home agent. It must either 491 obtain that information through prefix update or have it statically 492 configured. A more typical pattern for inter-domain service 493 discovery in the Internet is that the client (mobile node in this 494 case) knows the domain name of the service, and uses DNS to find the 495 server in the visited domain. For local service discovery, DHCP is 496 typically used. 498 5.3. Topology Change 500 5.3.1. Dormant Mode Mobile Nodes 502 The description of the protocol to push prefix information to mobile 503 nodes in Section 10.6 in [RFC3775] has an implicit assumption that 504 the mobile node is active and taking IP traffic. In fact, many, if 505 not most, mobile devices will be in a low power "dormant mode" to 506 save battery power, or even switched off, so they will miss any 507 propagation of prefix information. As a practical matter, if this 508 protocol is used, an MSP will need to keep the old prefix around and 509 handle any queries to the old home agent anycast address on the old 510 subnet, whereby the mobile node asks for a new home agent as 511 described in Section 11.4, until all mobile nodes are accounted for. 512 Even then, since some mobile nodes are likely to be turned off for 513 long periods, some owners would need to be contacted by other means, 514 reducing the utility of the protocol. 516 Bootstrapping does not explicitly try to solve this problem of home 517 network renumbering when MN is in dormant mode. If the MN can 518 configure itself after it 'comes back on' by reinitiating the 519 bootstrapping process, then network renumbering problem is fixed as a 520 side-effect. 522 6. Network Access and Mobility services 524 This section defines some terms as it pertains to authentication and 525 practical network deployment/roaming scenarios. This description 526 lays the groundwork for Section 7. The focus is on the 'service' 527 model since, ultimately, it is the provider providing the service 528 that wants to authenticate the mobile (and vice-versa for mutual 529 authentication between provider and the user of the service). 531 Network access service enables a host to send and receive IP packets 532 on the Internet or an intranet. IP address configuration and IP 533 packet forwarding capabilities are required to deliver this service. 534 A network operator providing this service is called an access service 535 provider (ASP). An ASP can, for example, be a commercial ASP, the IT 536 department of an enterprise network, or the maintainer of a home 537 (residential) network. 539 If the mobile node is not within the geographical area in which 540 network access service is provided by its home ASP, the mobile node 541 is roaming. In this case, the home ASP acts as the access service 542 authorizer, but the actual network access is provided by the serving 543 network access provider. During the authentication and authorization 544 prior to the mobile node having Internet access, the serving network 545 access provider may simply act as a routing agent for authentication 546 and authorization back to the access service authorizer, or it may 547 require an additional authentication and authorization step itself. 548 An example of a roaming situation is when a business person is using 549 a hotspot service in an airport, and the hotspot service provider has 550 a roaming agreement with the business person's cellular provider. In 551 that case, the hotspot network is acting as the serving network 552 access provider, while the cellular network is acting as the access 553 service authorizer. When the business person moves from the hotspot 554 network to the cellular network, the cellular network is both the 555 home access service provider and the access service authorizer. 557 Mobility service using Mobile IPv6 is conceptually and possibly also 558 in practice separate from network access service, though of course 559 network access is required prior to providing mobility. Mobile IPv6 560 service enables an IPv6 host to maintain its reachability despite 561 changing its network attachment point (subnets). A network operator 562 providing Mobile IPv6 service is called a mobility service provider 563 (MSP). Granting Mobile IPv6 service requires a host to authenticate 564 and prove authorization for the service. A network operator that 565 authenticates a mobile node and authorizes mobility service is called 566 a mobility service authorizer (MSA). If both types of operation are 567 performed by the same operator, that operator is called a home 568 mobility service provider. If authentication and authorization is 569 provided by one operator and the actual service is provider by 570 another, the operator providing the service is called the serving 571 mobility service provider. The serving MSP must contact the mobile 572 node's mobility service authorizer to check the mobile node's 573 authorization prior to granting mobility service. 575 The service model defined here clearly separates the entity providing 576 the service from the entity that authenticates and authorizes the 577 service. In the case of basic network access, this supports the 578 traditional and well-known roaming model, in which inter-operator 579 roaming agreements allow a host to obtain network access in areas 580 where their home network access provider does not have coverage. In 581 the case of mobility service, this allows a roaming mobile node to 582 obtain mobility service in the local operator's network while having 583 that service authorized by the home operator. The service model also 584 allows mobility service and network access service to be provided by 585 different entities. This allows a network operator with no wireless 586 access, like, for example, an enterprise network operator, to deploy 587 a Mobile IPv6 home agent for mobility service while the actual 588 wireless network access is provided by the serving network access 589 providers with which the enterprise operator has a contract. Here 590 are some other possible combinations of ASPs and MSPs: 592 o The serving ASP might be the home ASP. Similarly, the serving MSP 593 might be the home MSP. 595 o The home ASP and the home MSP may be the same operator, or not. 596 When they are the same, the same set of credentials may be used 597 for both services. 599 o The serving ASP and the serving MSP may be the same operator, or 600 not. 602 o It is possible that serving ASP and home MSP are the same 603 operator. 605 Similarly the home ASP and serving MSP may be the same. Also, the 606 ASA and MSA may be the same. 608 These entities and all combinations that are reasonable from a 609 deployment perspective must be taken into consideration when solving 610 the Mobile IPv6 bootstraping problem. They impact home agent 611 discovery, home address configuration, and mobile node to home agent 612 authentication aspects. 614 7. Deployment scenarios 616 This section describes the various network deployment scenarios. The 617 various combinations of service providers as described in Section 6 618 are considered. 620 For each scenario, the underlying assumptions are described. The 621 basic assumption is that there is a trust relationship between mobile 622 user and the MSA . Typically, this trust relationship is between the 623 mobile user and AAA in the MSA's network. Seed information needed to 624 bootstrap the mobile node is considered in two cases: 626 o AAA authentication is mandatory for network access 628 o AAA authentication is not part of network access. The seed 629 information is described further in Section 8. 631 7.1. Mobility Service Subscription Scenario 633 Many commercial deployments are based on the assumption that mobile 634 nodes have a subscription with a service provider. In this scenario 635 the MN has a subscription with an MSA , called also the home MSP, for 636 Mobile IPv6 service. As stated in Section 6, the MSP is responsible 637 of setting up a home agent on a subnet that acts as a Mobile IPv6 638 home link. As a consequence, the home MSP should explicitly 639 authorize and control the whole bootstrapping procedure. 641 Since the MN is assumed to have a pre-established trust relationship 642 with its home provider, it must be configured with an identity and 643 credentials, for instance an NAI and a shared secret by some out-of- 644 band means (i.e. manual configuration) before bootstrapping. 646 In order to guarantee ubiquitous service, the MN should be able to 647 bootstrap MIPv6 operations with its home MSP from any possible access 648 location, such as an open network or a network managed by an ASP, 649 that may be different from the MSP and may not have any pre- 650 established trust relationship with it. 652 7.2. Integrated ASP network scenario 654 In this scenario, the ASA and MSA are the same entity. The MN has 655 security credentials for access to the network and these credentials 656 can be used to bootstrap MIPv6. This bootstrapping can be done 657 during the same phase as access authentication/authorization or at a 658 later time (probably based on some state created during access 659 authentication/authorization). 661 Figure 1 describes an example AAA design for integrated ASP scenario. 663 +----------------------------+ 664 | IASP(ASA+MSA) | 665 +----+ +-----+ +----+ | 666 | MN |--- | NAS | | HA | | 667 +----+ +-----+ +----+ | 668 | \ \ | 669 | \ +------+ \ +-------+ | 670 | -|AAA-NA| -|AAA-MIP| | 671 | +------+ +-------+ | 672 +----------------------------+ 674 NAS: Network Access Server 675 AAA-NA: AAA for network access 676 AAA-MIP: AAA for Mobile IP service 678 Figure 1: Integrated ASP network 680 7.3. Third party MSP scenario 682 Mobility service has traditionally been provided by the same entity 683 that authenticates and authorizes the subscriber for network access. 684 This is certainly the only model support by the base Mobile IPv6 685 specification. 687 In the 3rd party mobility service provider scenario, the subscription 688 for mobility service is made with one entity (MSA for instance a 689 corporate network), but the actual mobility service is provided by 690 yet another entity (such as an operator specializing on this service, 691 the serving MSP). These two entities have a trust relationship. 692 Transitive trust among the mobile node and these two entities may be 693 used to assure the participants that they are dealing with, are 694 trustworthy peers. 696 This arrangement is similar to the visited - home operator roaming 697 arrangement for network access. 699 Figure 2 describes an example network for third party MSP scenario. 701 +--------------+ +--------+ 702 | | |Serving | 703 | ASP | | MSP | 704 +----+ +-----+ | | +----+ | 705 | MN |--- | NAS | | | | HA | | +-------------------+ 706 +----+ +-----+ |===| +----+ | | MSA | 707 | \ | | \ | | (e.g.corporate NW)| 708 | \ +------+ | | \ | +-------+ | 709 | -|AAA-NA| | | -------|AAA-MIP| | 710 | +------+ | | | | +-------+ | 711 +------------ + +--------+ +-------------------+ 713 Figure 2: Third Party MSP network 715 7.4. Infrastructure-less scenario 717 Infrastructure refers to network entities like AAA, PKI, HLR etc. 718 Infrastructure-less implies that there is no dependency on any 719 elements in the network with which the user has any form of trust 720 relationship. 722 In such a scenario, there is absolutely no relationship between host 723 and infrastructure. 725 A good example of infrastructure-less environment for MIP6 726 bootstrapping is the IETF network at IETF meetings. It is possible 727 that there could be MIP6 service available on this network (i.e a 728 MIPv6 HA). However there is not really any AAA infrastructure or for 729 that matter any trust relationship that a user attending the meeting 730 has with any entity in the network. 732 This specific scenario is not supported in this document. The reason 733 for this is described in Section 9. 735 8. Parameters for authentication 737 The following is a list of parameters that are used as the seed for 738 the bootstrapping procedure. The parameters vary depending on 739 whether authentication for network access is independent of 740 authentication for mobility services or not.If different client 741 identities are used for network access and mobility services, 742 authentication for network access is independent of authentication 743 for mobility services.. 745 o Parameter Set 1 747 In this case, authentication for network access is independent of 748 authentication for mobility services. 750 If the home agent address is not known to the mobile node the 751 following parameter is needed for discovering the home agent 752 address: 754 * The domain name or FQDN of the home agent 756 This parameter may be derived in various ways such as (but not 757 limited to) static configuration, use of the domain name from the 758 network access NAI (even if AAA for network access is not 759 otherwise used) or use of the domain name of the serving ASP where 760 the domain name may be obtained via DHCP in the serving ASP. 762 If the home agent address is not known but the home subnet prefix 763 is known, Dynamic Home Agent Address Discovery of Mobile IPv6 may 764 be used for discovering the home agent address and the above 765 parameter may not be used. 767 When the home agent address is known to the mobile node, the 768 following parameter is needed for performing mutual authentication 769 between the mobile node and the home agent by using IKE: 771 * IKE credentials(*) 773 In the case where the home agent does not have the entire set of 774 IKE credentials, the home agent may communicate with other entity 775 (for example a AAA server) to perform mutual authentication in 776 IKE. In such a case, the IKE credentials include the credentials 777 used between the mobile node and the other entity. In the case 778 where a AAA protocol is used for the communication between the 779 home agent and the other entity during the IKE procedure, AAA for 780 Mobile IPv6 service may be involved in IKE. 782 If authentication protocol [RFC4285] is used, the shared key based 783 security association with home agent is needed. 785 o Parameter Set 2 787 In this case, some dependency exists between authentication for 788 network access and authentication for mobility services in that a 789 security association that is established as a result of 790 authentication for network access is re-used for authentication 791 for mobility services. 793 All required information including IKE credentials are 794 bootstrapped from the following parameter: 796 * Network access credentials(*) 798 (*) A pair of a NAI and a pre-shared secret is an example set of 799 credentials. A pair of an NAI and a public key, which may be 800 provided as a digital certificate, is another example set of 801 credentials. 803 9. Security Considerations 805 There are two aspects of security for the Mobile IPv6 bootstrapping 806 problem: 808 1. The security requirements imposed on the outcome of the 809 bootstrapping process by RFC 3775 and other RFCs used by Mobile 810 IPv6 for security. 812 2. The security of the bootstrapping process itself, in the sense of 813 threats to the bootstrapping process imposed by active or passive 814 attackers. 816 Note that the two are related; if the bootstrapping process is 817 compromised, the level of security required by RFC 3775 may not be 818 achieved. 820 The following two sections discuss these issues. 822 9.1. Security Requirements of Mobile IPv6 824 The Mobile IPv6 specification in RFC 3775 requires the establishment 825 of a collection of IPsec SAs between the home agent and mobile node 826 to secure the signaling traffic for Mobile IP, and, optionally, also 827 to secure data traffic. The security of an IPsec SA required by the 828 relevant IPsec RFCs must be quite strong. Provisioning of keys and 829 other cryptographic material during the establishment of the SA 830 through bootstrapping must be done in a manner such that authenticity 831 is proved and confidentiality is ensured. In addition, the 832 generation of any keying material or other cryptographic material for 833 the SA must be done in a way such that the probability of compromise 834 after the SA is in place is minimized. The best way to minimize the 835 probability of such a compromise is to have the cryptographic 836 material only known or calculable by the two end nodes that share the 837 SA -- in this case, the home agent and mobile node. If other parties 838 are involved in the establishing the SA, through key distribution for 839 example, the process should follow the constraints [I-D.ietf-eap- 840 keying-08] designed to provide equivalent security. 842 RFC 3775 also requires a trust relationship as defined in Section 1.3 843 between the mobile node and its home agent(s) . This is necessary, 844 for instance, to ensure that fradulent mobile nodes which attempt to 845 flood other mobile nodes with traffic can not only be shut off but 846 tracked down [I-D.rosec]. An infrastructureless relationship as 847 defined in Section 1.3 does not satisfy this requirement. Any 848 bootstrapping solution must include a trust relationship between 849 mobile node and mobility service provider. Solutions that depend on 850 an infrastructureless relationship are out of scope for 851 bootstrapping. 853 Another requirement is that a home address is authorized to one 854 specific host at a time. RFC 3775 requires this in order to that 855 misbehaving mobile nodes can be shut down. This implies that, in 856 addition to the IPsec SA, the home agent must somehow authorize the 857 mobile node for a home address. The authorization can be either 858 implicit (for example, as a side effect of the authentication for 859 mobility service) or explicit. The authorization can either be done 860 at the time the SA is created or dynamically managed through a first 861 come, first served allocation policy. 863 9.2. Threats to the Bootstrapping Process 865 Various attacks are possible on the bootstrapping process itself. 866 These attacks can compromise the process such that the RFC 3775 867 requirements for Mobile IP security are not met, or they can serve to 868 simply disrupt the process such that bootstrapping cannot complete. 869 Here are some possible attacks: 871 o An attacking network entity purporting to offer the mobile node a 872 legitimate home agent address or bootstrapping for the IPsec SAs 873 may, instead, offer a bogus home agent address or configure bogus 874 SAs that allow the home agent to steal the mobile node's traffic 875 or otherwise disrupts the mobile node's mobility service. 877 o An attacking mobile node may attempt to steal mobility service by 878 offering up fake credentials to a bootstrapping network entity or 879 otherwise disrupt the home agent's ability to offer mobility 880 service. 882 o A man in the middle on the link between the mobile node and the 883 bootstrapping network entity could steal credentials or other 884 sensitive information and use that to steal mobility service or 885 deny it to the legitimate owner of the credentials. Refer to 886 Section 7.15 in [2284bis] and [I-D.mariblanca-aaa-eap-lla-00] for 887 further information. 889 o An attacker could arrange for a distributed denial of service 890 attack on the bootstrapping entity, to disrupt legitimate users 891 from bootstrapping. 893 In addition to these attacks, there are other considerations that are 894 important in achieving a good security design. As mobility and 895 network access authentication are separate services, keys generated 896 for these services need to be cryptographically separate, separately 897 named, and have separate lifetimes, including if the keys are 898 generated from the same authentication credentials This is necessary 899 because a mobile node must be able to move from one serving (or 900 roaming) network access provider to another without needing to change 901 its mobility access provider. Finally, basic cryptographic processes 902 must provide for multiple algorithms in order to accommodate the 903 widely varying deployment needs. 905 10. IANA Considerations 907 No new protocol numbers are required. 909 11. Contributors 911 This contribution is a joint effort of the problem statement design 912 team of the Mobile IPv6 WG. The contributors include Basavaraj 913 Patil, Gerardo Giaretta, Jari Arkko, James Kempf, Yoshihiro Ohba, 914 Ryuji Wakikawa, Hiroyuki Ohnishi, Mayumi Yanagiya Samita Chakrabarti, 915 Gopal Dommety, Kent Leung, Alper Yegin, Hannes Tschofenig, Vijay 916 Devarapalli, Kuntal Chowdury. 918 The design team members can be reached at: 920 Basavaraj Patil basavaraj.patil@nokia.com 922 Gerardo Giaretta gerardo.giaretta@tilab.com 924 Jari Arkko jari.arkko@kolumbus.fi 926 James Kempf kempf@docomolabs-usa.com 928 Yoshihiro Ohba yohba@tari.toshiba.com 930 Ryuji Wakikawa ryuji@sfc.wide.ad.jp 932 Hiroyuki Ohnishi ohnishi.hiroyuki@lab.ntt.co.jp 934 Mayumi Yanagiya yanagiya.mayumi@lab.ntt.co.jp 936 Samita Chakrabarti Samita.Chakrabarti@eng.sun.com 938 Gopal Dommety gdommety@cisco.com 940 Kent Leung kleung@cisco.com 942 Alper Yegin alper.yegin@samsung.com 944 Hannes Tschofenig hannes.tschofenig@siemens.com 946 Vijay Devarapalli vijayd@iprg.nokia.com 948 Kuntal Chowdhury kchowdhury@starentnetworks.com 950 12. Acknowledgments 952 Special thanks to James Kempf and Jari Arkko for writing the initial 953 version of the bootstrapping statement. Thanks to John Loughney and 954 T.J. Kniveton for their detailed reviews. 956 13. IPR Disclosure Acknowledgement 958 By submitting this Internet-Draft, each author represents that any 959 applicable patent or other IPR claims of which he or she is aware 960 have been or will be disclosed, and any of which he or she becomes 961 aware will be disclosed, in accordance with Section 6 of BCP 79. 963 14. Informative References 965 [2284bis] Levkowetz, Ed., H., "Extensible Authentication Protocol 966 (EAP)", February 2004, . 968 [I-D.giaretta-mip6-authorization-eap] 969 Giaretta, G., "MIPv6 Authorization and Configuration based 970 on EAP", draft-giaretta-mip6-authorization-eap-02 (work in 971 progress), February 2004, 972 . 974 [I-D.ietf-eap-keying-08] 975 Aboba et. al., B., "Extensible Authentication Protocol 976 (EAP) Key Management Framework", 977 draft-ietf-eap-keying-08.txt (work in progress), 978 October 2005, . 980 [I-D.kempf-mip6-bootstrap] 981 Kempf, J. and J. Arkko, "The Mobile IPv6 Bootstrapping 982 Problem", draft-kempf-mip6-bootstrap-00 (work in 983 progress), March 2004, 984 . 986 [I-D.mariblanca-aaa-eap-lla-00] 987 Mariblanca, D., "EAP lower layer attributes for AAA 988 protocols", May 2004, 989 . 991 [I-D.rosec] 992 Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 993 Nordmark, "Mobile IP version 6 Route Optimization Security 994 Design Background", draft-ietf-mip6-ro-sec-02 (work in 995 progress), October 2004, . 997 [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access 998 Identifier Extension for IPv4", RFC 2794, March 2000. 1000 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 1001 Stateless Address Autoconfiguration in IPv6", RFC 3041, 1002 January 2001. 1004 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1005 RFC 3753, June 2004. 1007 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1008 in IPv6", RFC 3775, June 2004. 1010 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1011 Protect Mobile IPv6 Signaling Between Mobile Nodes and 1012 Home Agents", RFC 3776, June 2004. 1014 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1015 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 1016 (MIPv6)", RFC 4283, November 2005. 1018 [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1019 Chowdhury, "Authentication Protocol for Mobile IPv6", 1020 RFC 4285, January 2006. 1022 Authors' Addresses 1024 Alpesh Patel 1025 Cisco 1026 170 W. Tasman Drive 1027 San Jose, CA 95134 1028 USA 1030 Phone: +1 408 853 9580 1031 Email: alpesh@cisco.com 1033 Gerardo Giaretta 1034 Telecom Italia LAB 1035 via Reiss Romoli 274 1036 Torino 10148 1037 Italy 1039 Phone: +39 011 228 6904 1040 Email: gerardo.giaretta@telecomitalia.it 1042 Intellectual Property Statement 1044 The IETF takes no position regarding the validity or scope of any 1045 Intellectual Property Rights or other rights that might be claimed to 1046 pertain to the implementation or use of the technology described in 1047 this document or the extent to which any license under such rights 1048 might or might not be available; nor does it represent that it has 1049 made any independent effort to identify any such rights. Information 1050 on the procedures with respect to rights in RFC documents can be 1051 found in BCP 78 and BCP 79. 1053 Copies of IPR disclosures made to the IETF Secretariat and any 1054 assurances of licenses to be made available, or the result of an 1055 attempt made to obtain a general license or permission for the use of 1056 such proprietary rights by implementers or users of this 1057 specification can be obtained from the IETF on-line IPR repository at 1058 http://www.ietf.org/ipr. 1060 The IETF invites any interested party to bring to its attention any 1061 copyrights, patents or patent applications, or other proprietary 1062 rights that may cover technology that may be required to implement 1063 this standard. Please address the information to the IETF at 1064 ietf-ipr@ietf.org. 1066 Disclaimer of Validity 1068 This document and the information contained herein are provided on an 1069 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1070 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1071 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1072 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1073 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1074 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1076 Copyright Statement 1078 Copyright (C) The Internet Society (2006). This document is subject 1079 to the rights, licenses and restrictions contained in BCP 78, and 1080 except as set forth therein, the authors retain all their rights. 1082 Acknowledgment 1084 Funding for the RFC Editor function is currently provided by the 1085 Internet Society.