idnits 2.17.00 (12 Aug 2021) /tmp/idnits21957/draft-ietf-mip6-bootstrap-ps-03.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 965. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1077. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1054. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1067. ** 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 (July 14, 2005) is 6154 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.ietf-seamoby-mobility' is defined on line 977, but no explicit reference was found in the text == Unused Reference: 'I-D.giaretta-mip6-authorization-eap' is defined on line 998, but no explicit reference was found in the text == Unused Reference: 'I-D.kempf-mip6-bootstrap' is defined on line 1011, but no explicit reference was found in the text == Outdated reference: draft-ietf-mip6-auth-protocol has been published as RFC 4285 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-auth-protocol (ref. 'I-D.ietf-mip6-mn-auth-protocol-02') == Outdated reference: draft-ietf-seamoby-mobility-terminology has been published as RFC 3753 ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-mobility-terminology (ref. 'I-D.ietf-seamoby-mobility') ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- 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-00 == Outdated reference: draft-ietf-mip6-mn-ident-option has been published as RFC 4283 == Outdated reference: A later version (-01) exists of draft-mariblanca-aaa-eap-lla-00 == Outdated reference: draft-ietf-mip6-ro-sec has been published as RFC 4225 Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 A. Patel, Editor 3 Internet-Draft Cisco 4 Expires: January 15, 2006 July 14, 2005 6 Problem Statement for bootstrapping Mobile IPv6 7 draft-ietf-mip6-bootstrap-ps-03 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 15, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 A mobile node needs at least the following information: a home 41 address, home agent address and a security association with home 42 agent to register with the home agent. The process of obtaining this 43 information is called bootstrapping. This document discuss the 44 issues involved with how the mobile node can be bootstrapped for 45 Mobile IPv6 and various potential deployment scenarios for 46 bootstrapping the mobile node. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1 Overview of the Problem . . . . . . . . . . . . . . . . . 3 52 1.2 What is Bootstrapping? . . . . . . . . . . . . . . . . . . 4 53 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 5. Motivation for bootstrapping . . . . . . . . . . . . . . . . . 10 58 5.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 10 59 5.1.1 Dynamic Home Address Assignment . . . . . . . . . . . 10 60 5.1.2 Dynamic Home Agent Assignment . . . . . . . . . . . . 11 61 5.1.3 Management requirements . . . . . . . . . . . . . . . 12 62 5.2 Security Infrastructure . . . . . . . . . . . . . . . . . 13 63 5.2.1 Integration with AAA Infrastructure . . . . . . . . . 13 64 5.2.2 "Opportunistic" or "Local" Discovery . . . . . . . . . 13 65 5.3 Topology Change . . . . . . . . . . . . . . . . . . . . . 13 66 5.3.1 Dormant Mode Mobile Nodes . . . . . . . . . . . . . . 13 67 6. Network Access and Mobility services . . . . . . . . . . . . . 15 68 7. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 17 69 7.1 Mobility Service Subscription Scenario . . . . . . . . . . 17 70 7.2 Integrated ASP network scenario . . . . . . . . . . . . . 17 71 7.3 Third party MSP scenario . . . . . . . . . . . . . . . . . 18 72 7.4 Infrastructure-less scenario . . . . . . . . . . . . . . . 19 73 8. Parameters for authentication . . . . . . . . . . . . . . . . 20 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 75 9.1 Security Requirements of Mobile IPv6 . . . . . . . . . . . 22 76 9.2 Threats to the Bootstrapping Process . . . . . . . . . . . 23 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 78 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 79 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 80 13. IPR Disclosure Acknowledgement . . . . . . . . . . . . . . . 28 81 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 82 14.1 Normative References . . . . . . . . . . . . . . . . . . . 29 83 14.2 Informative References . . . . . . . . . . . . . . . . . . 29 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 30 85 Intellectual Property and Copyright Statements . . . . . . . . 31 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, via anycast discovery 93 mechanisms, via DNS lookup; Mobile IPv6 signaling messages between 94 the mobile node and the home agent are secured with IPsec or 95 authentication protocol [I-D.ietf-mip6-mn-auth-protocol-02]. The 96 requirements for this security architecture are created with 97 [RFC3775] and the details of this procedure are described in 98 [RFC3776]. 100 In [RFC3775] there is an implicit requirement that the MN be 101 provisioned with enough information that will permit it to register 102 successfully with its home agent. However, having this information 103 statically provisioned creates practical deployment issues. 105 This document serves to define the problem of bootstrapping. 106 Bootstrapping is defined as the process of the mobile node obtaining 107 enough information, so that it can successfully register with an 108 appropriate home agent. 110 The requirements for bootstrapping could consider various scenarios/ 111 network deployment issues. It is the basic assumption of this 112 document that certain minimal parameters (seed information) is 113 available to the mobile node to aid in bootstrapping. The exact seed 114 information available differs depending on the deployment scenario. 115 This document defines/describes various deployment scenarios and 116 provides for a set of minimal parameters that are available in each 117 deployment scenario. 119 This document stops short of suggesting the various solutions to 120 obtaining information on the mobile node. Such details will be 121 available from separate documents. 123 1.1 Overview of the Problem 125 Mobile IPv6 [RFC3775] expects the mobile node to have a static home 126 address, home agent address (or anycast address and do dynamic home 127 agent discovery of Home Agent using ICMP messages) and a security 128 association with a home agent (multiple home agents on the home 129 network if dynamic home agent discovery is in use and multiple home 130 agents are deployed.) 132 This static provisioning of information has various problems as 133 discussed in Section 5. 135 The aim of this draft is to: 137 o Define bootstrapping. 139 o Identify sample deployment scenarios where MIPv6 will be deployed, 140 taking into account the relationship between the subscriber and 141 the service provider. 143 o Identify the minimal set of information required on the Mobile 144 Node (and/or) in the network in order for the mobile node to 145 obtain address and security credentials, to register with the home 146 agent. 148 1.2 What is Bootstrapping? 150 Bootstrapping is defined as obtaining enough information at the 151 mobile node, so that the mobile node can successfully register with 152 an appropriate home agent. Specifically, this means obtaining the 153 home agent address, home address and security credentials for the 154 mobile node and home agent to authenticate and mutually construct 155 security credentials for Mobile IPv6 without requiring 156 preconfiguration. 158 Typically, bootstrapping happens when a mobile node does not have all 159 the information it needs to setup the Mobile IPv6 service. This 160 includes, but is not limited to MN not having any information when it 161 boots up for the first time (out of the box), it does not retain any 162 information during reboots, is instructed by the Home Agent (via some 163 form of signalling) to do so etc. 165 Also, in certain scenarios, after the MN bootstraps for the first 166 time (out of the box), subsequent bootstrapping is implementation 167 dependent. For instance, the MN may bootstrap everytime it boots, 168 bootstrap everytime on prefix change, bootstrap periodically to 169 anchor to an optimal (distance, load etc) HA, etc. 171 1.3 Terminology 173 General mobility terminology can be found in [I-D.ietf-seamoby- 174 mobility]. The following additional terms are used here: 176 Trust relationship 177 In the context of this draft, trust relationship means that two 178 parties in question, typically the user of the mobile host and the 179 mobility or access service provider, have some sort of prior 180 contact in which the mobile host was provisioned with credentials. 181 These credentials allow the mobile host to authenticate itself to 182 the mobility or access service authorizer and to prove its 183 authorization to obtain service. 185 Infrastructureless relationship 187 In the context of this draft, an infrastructureless relationship 188 is one in which the user of the mobile host and the mobility or 189 access service provider have no previous contact and the mobile 190 host is not required to supply credentials to authenticate and 191 prove authorization for service. Mobility and/or network access 192 service is provided without any authentication or authorization. 193 Infrastructureless in this context does not mean that there is no 194 network infrastructure, such as would be the case for an ad hoc 195 network. 197 Credentials 199 Data or mechanism used by a mobile host to authenticate itself to 200 a mobility or access network service provider and prove 201 authorization to receive service. User name/passwords, one time 202 password cards, public/private key pairs with certificates, 203 biometric information, etc. are some examples. 205 ASA 207 Access Service Authorizer. A network operator that authenticates 208 a mobile host and establishes the mobile host's authorization to 209 receive Internet service. 211 ASP 213 Access Service Provider. A network operator that provides direct 214 IP packet forwarding to and from the end host. 216 Serving Network Access Provider 218 A network operator that is the mobile host's ASP but not its ASA. 219 The serving network accesss provider may or may not additionally 220 provide mobility service. 222 Home Network Access Provider 223 A network operator that is both the mobile host's ASP and ASA. 224 The home network access provider may or may not additionally 225 provide mobility service (note that this is a slighlty different 226 definition from RFC 3775). 228 IASP 230 Integrated Access Service Provider. A service provider that 231 provides both authorization for network access and also provides 232 mobility service. 234 MSA 236 Mobility Service Authorizer. A service provider that authorizes 237 Mobile IPv6 service. 239 MSP 241 Mobility Service Provider. A service provider that provides 242 Mobile IPv6 service. In order to obtain such service, the mobile 243 host must be authenticated and prove authorization to obtain the 244 service. 246 Home Mobility Service Provider 248 A MSP that both provides mobility service and authorizes it. 250 Serving Mobility Service Provider 252 A MSP that provides mobility service but depends on another 253 service provider to authorize it. 255 2. Assumptions 257 o A basic assumption in the Mobile IPv6 RFC [RFC3775] is that there 258 is a trust relationship between the mobile node and MSP. This 259 trust relationship can be direct, or indirect through, for 260 instance, an ASP that has a contract with the MSP. This trust 261 relationship can be used to bootstrap the MN. 263 One typical way of verifying the trust relationship is using 264 authentication, authorization, and accounting (AAA). 265 infrastructure. In this document, two distinct uses of AAA are 266 considered: 268 AAA for Network Access 270 This functionality provides authentication and authorization to 271 access the network (obtain address and send/receive packets). 273 AAA for Mobility Service 275 This functionality provides authentication and authorization 276 for mobility services. 278 These functionalities may be implemented in a single entity or in 279 different entities, depending on the service models described in 280 Section 6 or deployment scenarios as described in Section 7. 282 o Yet another assumption is that some identifier, such as NAI, as 283 defined in [I-D.ietf-mip6-mn-ident-option-02] or [RFC2794] is 284 provisioned on the MN which permits the MN to identify itself to 285 the ASP and ASP. 287 3. Design Goals 289 A solution to the bootstrapping problem has the following design 290 goals: 292 o The following information must be available at the end of 293 bootstrapping, to enable the MN to register with the HA. 295 * MN's home agent address 297 * MN's home address 299 * IPsec SA between MN and HA, IKE pre-shared secret between MN 300 and HA or shared secret/security association for authentication 301 protocol [I-D.ietf-mip6-mn-auth-protocol-02] 303 o The bootstrapping procedure can be triggered at any time, either 304 by the MN or by the network. Bootstrapping can occur, for 305 instance due to administrative action, information going stale, HA 306 indicating the MN etc. Bootstrapping may be initiated even when 307 the MN is registered with the HA and has all the required 308 credentials. This may typically happen to refresh/renew the 309 credentials. 311 o Subsequent protocol interaction (for example updating the IPsec 312 SA) can be executed between the MN and the HA itself without 313 involving the infrastructure that was used during bootstrapping. 315 o Solutions to the bootstrapping problem should enable storage of 316 user-specific information on entities other than the home agent. 318 o Solutions to the bootstrapping problem should not exclude storage 319 of user-specific information on entities other than the home 320 agent. 322 o Configuration information which is exchanged between the mobile 323 node and the home agent needs to be secured using integrity and 324 replay protection. Confidentiality protection should be provided 325 if necessary. 327 o All feasible deployment scenarios, along with the relevant 328 authentication/authorization models should be considered. 330 4. Non-Goals 332 This following issues are clearly outside the scope of bootstrapping: 334 o Home prefix renumbering is not explicity supported as part of 335 bootstrapping. If the MN executes the bootstrap procedures 336 everytime it powers-on (as opposed to caching state information 337 from previous bootstrap process), then home network renumbering is 338 taken care of automatically. 340 o Bootstrapping in the absence of a trust relationship between MN 341 and any provider is not considered. 343 5. Motivation for bootstrapping 345 5.1 Addressing 347 The default bootstrapping described in the Mobile IPv6 base 348 specification [RFC3775] has a tight binding to the home addresses and 349 home agent addresses. 351 In this section, we discuss the problems caused by the currently 352 tight binding to home addresses and home agent addresses. 354 5.1.1 Dynamic Home Address Assignment 356 Currently, the home agent uses the mobile node's home address for 357 authorization. When manual keying is used, this happens through the 358 security policy database, which specifies that a certain security 359 association may only use a specific home address. When dynamic 360 keying is used, the home agent ensures that the IKE Phase 1 identity 361 is authorized to request security associations for the given home 362 address. Mobile IPv6 uses IKEv1, which is unable to update the 363 security policy database based on a dynamically assigned home 364 address. As a result, static home address assignment is really the 365 only home address configuration technique compatible with the current 366 specification. 368 However, support for dynamic home address assignment would be 369 desirable for the following reasons: 371 DHCP-based address assignment 373 Some ASPs may want to use DHCPv6 from the home network to 374 configure home addresses. 376 Recovery from a duplicate address collision 378 It may be necessary to recover from a collision of addresses on 379 the home network. 381 Addressing privacy 383 It may be desirable to establish randomly generated addresses as 384 in RFC 3041 and use them for a short period of time. 385 Unfortunately, current protocols make it possible to use such 386 addresses only from the visited network. As a result, these 387 addresses can not be used for communications lasting longer than 388 the attachment to a particular visited network. 390 Ease of deployment 392 In order to simplify the deployment of Mobile IPv6, it is 393 desirable to free users and administrators from the task of 394 allocating home addresses and specifying them in the security 395 policy database. 397 This is consistent with the general IPv6 design goal of using 398 autoconfiguration wherever possible. 400 Prefix changes in the home network 402 The Mobile IPv6 specification contains support for a mobile node 403 to autoconfigure a home address based on its discovery of prefix 404 information on the home subnet [RFC3775]. Autoconfiguration in 405 case of network renumbering is done by replacing the existing 406 network prefix with the new network prefix. 408 Subsequently, the MN needs to update the mobility binding in the 409 HA to register the newly configured Home Address. However, the MN 410 may not be able to register the newly configured address with the 411 HA if a security association related to that reconfigured Home 412 Address does not exist in the MN and the HA. This situation is 413 not handled in the current MIPv6 specification [RFC3775]. 415 5.1.2 Dynamic Home Agent Assignment 417 Currently, the address of the home agent is specified in the security 418 policy database. Support for multiple home agents requires the 419 configuration of multiple security policy database entries. 421 However, support for dynamic home agent assignment would be desirable 422 for the following reasons: 424 Home agent discovery 426 The Mobile IPv6 specification contains support for a mobile node 427 to autoconfigure a home agent address based on a discovery 428 protocol [RFC3775]. 430 Independent network management 432 An ASP may want to dynamically assign home agents in different 433 subnets, that is, not require that a roaming mobile node have a 434 fixed home subnet. 436 Local home agents 438 The mobile node's home ASP may want to allow a local roaming 439 partner ASP to assign a local home agent for the mobile node. 440 This is useful both from the point of view of communications 441 efficiency, and has also been mentioned as one approach to support 442 location privacy. 444 Ease of deployment 446 MSP may want to allow "opportunistic" discovery and utilization of 447 its mobility services without any prearranged contact. These 448 scenarios will require dynamic home address assignment. 450 5.1.3 Management requirements 452 As described earlier, new addresses invalidate configured security 453 policy databases and authorization tables. Regardless of the 454 specific protocols used, there is a need for either an automatic 455 system for updating the security policy entries, or manual 456 configuration. These requirements apply to both home agents and 457 mobile nodes, but it can not be expected that mobile node users are 458 capable of performing the required tasks. 460 5.2 Security Infrastructure 462 5.2.1 Integration with AAA Infrastructure 464 The current IKEv1-based dynamic key exchange protocol described in 465 [RFC3776] has no integration with backend authentication, 466 authorization and accounting techniques unless the authentication 467 credentials and trust relationships use certificates or pre-shared 468 secrets. 470 Using certificates may require the ASP to deploy a PKI, which may not 471 be possible or desirable in certain circumstances. Where a 472 traditional AAA infrastructure is used, the home agent is not able to 473 leverage authentication and authorization information established 474 between the mobile node, the foreign AAA server, and the home AAA 475 server when the mobile node gains access to the foreign network, in 476 order to authenticate the mobile node's identity and determine if the 477 mobile node is authorized for mobility service. 479 The lack of connection to the AAA infrastructure also means the home 480 agent does not know where to issue accounting records at appropriate 481 times during the mobile node's session, as determined by the business 482 relationship between the home ASP and the mobile node's owner. 484 Presumably, some backend AAA protocol between the home agent and home 485 AAA could be utilized, but IKEv1 does not contain support for 486 exchanging full AAA credentials with the mobile node. It is 487 worthwhile to note that IKEv2 provides this feature. 489 5.2.2 "Opportunistic" or "Local" Discovery 491 The home agent discovery protocol does not support an "opportunistic" 492 or local discovery mechanisms in an ASP's local access network. It 493 is expected that the mobile node must know the prefix of the home 494 subnet in order to be able to discover a home agent. It must either 495 obtain that information through prefix update or have it statically 496 configured. A more typical pattern for interdomain service discovery 497 in the Internet is that the client (mobile node in this case) knows 498 the domain name of the service, and uses DNS in some manner to find 499 the server in the other domain. For local service discovery, DHCP is 500 typically used. 502 5.3 Topology Change 504 5.3.1 Dormant Mode Mobile Nodes 506 The description of the protocol to push prefix information to mobile 507 nodes in Section 10.6 in [RFC3775] has an implicit assumption that 508 the mobile node is active and taking IP traffic. In fact, many, if 509 not most, mobile devices will be in a low power "dormant mode" to 510 save battery power, or even switched off, so they will miss any 511 propagation of prefix information. As a practical matter, if this 512 protocol is used, an ASP will need to keep the old prefix around and 513 handle any queries to the old home agent anycast address on the old 514 subnet, whereby the mobile node asks for a new home agent as 515 described in Section 11.4, until all mobile nodes are accounted for. 516 Even then, since some mobile nodes are likely to be turned off for 517 long periods, some owners would need to be contacted by other means, 518 reducing the utility of the protocol. 520 Bootstrapping does not explicitly try to solve this problem of home 521 network renumbering when MN is in dormant mode. If the MN can 522 configure itself after it 'comes back on' by reinitiating the 523 bootstrapping process, then network renumbering problem is fixed as a 524 side-effect. 526 6. Network Access and Mobility services 528 This section defines some terms as it pertains to authentication and 529 practical network deployment/roaming scenarios. This description 530 lays the ground work for Section 7. The focus is on the 'service' 531 model since, ultimately, it is the provider providing the service 532 that wants to authenticate the mobile (and vice-versa for mutual 533 authentication between provider and the user of the service). 535 Network access service enables a host to send and receive IP packets 536 on the Internet or an intranet. IP address configuration and IP 537 packet forwarding capabilities are required to deliver this service. 538 A network operator providing this service is called an access service 539 provider (ASP). An ASP can, for example, be a commercial ASP, the IT 540 department of an enterprise network, or the maintainer of a home 541 (residential) network. 543 If the mobile host is within the geographical area in which network 544 access service is not provided by its home network access service 545 provider, the mobile host is roaming. The home network access 546 service provider in this case acts as the access service authorizer, 547 but the actual network access is provided by the serving network 548 access provider. During the authentication and authorization prior 549 to the mobile host having Internet access, the serving network access 550 provider may simply act as a routing agent for authentication and 551 authorization back to the access service authorizer, or it may 552 require an additional authentication and authorization step itself. 553 An example of a roaming situation is when a business person is using 554 a hotspot service in an airport, and the hotspot service provider has 555 a roaming agreement with the business person's cellular provider. In 556 that case, the hotspot network is acting as the serving network 557 access provider, while the cellular network is acting as the access 558 service authorizer. When the business person moves from the hotspot 559 network to the cellular network, the cellular network is both the 560 home access service provider and the access service authorizer. 562 Mobility service using Mobile IPv6 is conceptually and possibly also 563 in practice separate from network access service, though of course 564 network access is required prior to providing mobility. Mobile IPv6 565 service enables an IPv6 host to maintain its reachability despite 566 changing its network attachment point (subnets). A network operator 567 providing Mobile IPv6 service is called a mobility service provider 568 (MSP). Granting Mobile IPv6 service requires a host to authenticate 569 and prove authorization for the service. A network operator that 570 authenticates a mobile host and authorizes mobility service is called 571 a mobility service authorizer. If both types of operation are 572 performed by the same operator, that operator is called a home 573 mobility service provider. If authentication and authorization is 574 provided by one operator and the actual service is provider by 575 another, the operator providing the service is called the serving 576 mobility service provider. The serving MSP must contact the mobile 577 host's mobility service authorizer to check the mobile host's 578 authorization prior to granting mobility service. 580 The service model defined here clearly separates the entity providing 581 the service from the entity that authentications and authorizes the 582 service. In the case of basic network access, this supports the 583 traditional and well-known roaming model, in which inter-operator 584 roaming agreements allow a host to obtain network access in areas 585 where their home network access provider does not have coverage. In 586 the case of mobility service, this allows a roaming mobile host to 587 obtain mobility service in the local operator's network while having 588 that service authorized by the home operator. The service model also 589 allows mobility service and network access service to be provided by 590 different entities. This allows a network operator with no wireless 591 access, like, for example, an enterprise network operator, to deploy 592 a Mobile IPv6 home agent for mobility service while the actual 593 wireless network access is provided by the serving network access 594 providers with which the enterprise operator has a contract. Here 595 are some other possible combinations of ASPs and MSPs: 597 o The serving ASP might be the home ASP. Similarly, the serving MSP 598 might be the home MSP. 600 o The home ASP and the home MSP may be the same operator, or not. 601 When they are the same, the same set of credentials may be used 602 for both services. 604 o The serving ASP and the serving MSP may be the same operator, or 605 not. 607 o It is possible that serving ASP and home MSP are the same 608 operator. 610 Similarly the home ASP and serving MSP may be the same. Also, the 611 ASA and MSA may be the same. 613 These entities and possible combinations must be taken into 614 consideration when solving the Mobile IPv6 bootstraping problem. 615 They impact home agent discovery, home address configuration, and 616 mobile node to home agent authentication aspects. 618 7. Deployment scenarios 620 This section describes the various network deployment scenarios. The 621 various combinations of service providers as described in Section 6 622 are considered. 624 For each scenario, the underlying assumptions are described. The 625 basic assumption is that there is a trust relationship between mobile 626 user and the MSP. Typically, this trust relationship is between the 627 mobile user and AAA in the MSA's network. Seed information needed to 628 bootstrap the mobile node is considered in two cases: 630 o AAA authentication is mandatory for network access 632 o AAA authentication is not part of network access. The seed 633 information is described further in Section 8. 635 7.1 Mobility Service Subscription Scenario 637 Many commercial deployments are based on the assumption that mobile 638 nodes have a subscription with a service provider. In particular, in 639 this scenario the MN has a subscription with an MSP, called the home 640 MSP, for Mobile IPv6 service. As stated in Section 6, the MSP is 641 responsible of setting up a home agent on a subnet that acts as a 642 Mobile IPv6 home link. As a consequence, the home MSP should 643 explicitly authorize and control the whole bootstrapping procedure. 645 Since the MN is assumed to have a pre-established trust relationship 646 with its home provider, it must be configured with an identity and 647 credentials, for instance an NAI and a shared secret by some out-of- 648 band means before bootstrapping, for example by manual configuration. 650 In order to guarantee ubiquitous service, the MN should be able to 651 bootstrap MIPv6 operations with its home MSP from any possible access 652 location, such as an open network or a network managed by an ASP, 653 that may be different from the MSP and may not have any pre- 654 established trust relationship with it. 656 7.2 Integrated ASP network scenario 658 In this scenario, the ASP and MSP are the same ASP. MN shares 659 security credentials for access to the network and these credentials 660 can be used to bootstrap MIPv6. This bootstrapping can be done 661 during the same phase as access authentication/authorization or at a 662 later time (probably based on some state created during access 663 authentication/authorization). 665 Figure 1 describes an example AAA design for integrated ASP scenario. 667 +----------------------------+ 668 | IASP(ASP+MSP) | 669 +----+ +-----+ +----+ | 670 | MN |--- | NAS | | HA | | 671 +----+ +-----+ +----+ | 672 | \ \ | 673 | \ +------+ \ +-------+ | 674 | -|AAA-NA| -|AAA-MIP| | 675 | +------+ +-------+ | 676 +----------------------------+ 678 NAS: Network Access Server 679 AAA-NA: AAA for network access 680 AAA-MIP: AAA for Mobile IP service 682 Figure 1: Integrated ASP network 684 7.3 Third party MSP scenario 686 Mobility service has traditionally been provided by the same entity 687 that authenticates and authorizes the subscriber for network access. 688 This is certainly the only model support by the base Mobile IPv6 689 specification. 691 In the 3rd party mobility service provider scenario, the subscription 692 for mobility service is made with one entity (home MSA for instance a 693 corporate network), but the actual mobility service is provided by 694 yet another entity (such as an operator specializing on this service, 695 the serving MSP). These two entities have a trust relationship. 696 Transitive trust among the mobile node and these two entities may be 697 used to assure the participants that they are dealing with, are 698 trustworthy peers. 700 This arrangement is similar to the visited - home operator roaming 701 arrangement for network access. 703 Figure 2 describes an example network for third party MSP scenario. 705 +--------------+ +--------+ 706 | | |Serving | 707 | ASP | | MSP | 708 +----+ +-----+ | | +----+ | 709 | MN |--- | NAS | | | | HA | | +-------------------+ 710 +----+ +-----+ |===| +----+ | | Home MSP | 711 | \ | | \ | | (e.g.corporate NW)| 712 | \ +------+ | | \ | +-------+ | 713 | -|AAA-NA| | | -------|AAA-MIP| | 714 | +------+ | | | | +-------+ | 715 +------------ + +--------+ +-------------------+ 717 Figure 2: Third Party MSP network 719 7.4 Infrastructure-less scenario 721 Infrastructure refers to network entities like AAA, PKI, HLR etc. 722 Infrastructure-less implies that there is no dependency on any 723 elements in the network with which the user has any form of trust 724 relationship. 726 In such a scenario, there is absolutely no relationship between host 727 and infrastructure. 729 A good example of infrastructure-less environment for MIP6 730 bootstrapping is the IETF network at IETF meetings. It is possible 731 that there could be MIP6 service available on this network (i.e a 732 MIPv6 HA). However there is not really any AAA infrastructure or for 733 that matter any trust relationship that a user attending the meeting 734 has with any entity in the network. 736 This specific scenario is not supported in this document. The reason 737 for this is described in Section 9. 739 8. Parameters for authentication 741 The following is a list of parameters that are used as the seed for 742 the bootstrapping procedure. The parameters vary depending on 743 whether authentication for network access is independent of 744 authentication for mobility services or not. Authentication for 745 network access is always independent of authentication for mobility 746 services if different client identities are used for network access 747 and mobility services. 749 o Parameter Set 1 751 In this case, authentication for network access is independent of 752 authentication for mobility services. 754 If the home agent address is not known to the mobile node the 755 following parameter is needed for discovering the home agent 756 address: 758 * The domain name or FQDN of the home agent 760 This parameter may be derived in various ways such as (but not 761 limited to) static configuration, use of the domain name from the 762 network access NAI (even if AAA for network access is not 763 otherwise used) or use of the domain name of the serving ASP where 764 the domain name may be obtained via DHCP in the serving ASP. 766 If the home agent address is not known but the home subnet prefix 767 is known, Dynamic Home Agent Address Discovery of Mobile IPv6 may 768 be used for discovering the home agent address and the above 769 parameter may not be used. 771 When the home agent address is known to the mobile node, the 772 following parameter is needed for performing mutual authentication 773 between the mobile node and the home agent by using IKE: 775 * IKE credentials(*) 776 In the case where the home agent does not have the entire set of 777 IKE credentials, the home agent may communicate with other entity 778 (for example a AAA server) to perform mutual authentication in 779 IKE. In such a case, the IKE credentials include the credentials 780 used between the mobile node and the other entity. In the case 781 where a AAA protocol is used for the communication between the 782 home agent and the other entity during the IKE procedure, AAA for 783 Mobile IPv6 service may be involved in IKE. 785 If authentication protocol [I-D.ietf-mip6-mn-auth-protocol-02] is 786 used, the shared key based security association with home agent is 787 needed. 789 o Parameter Set 2 791 In this case, some dependency exists between authentication for 792 network access and authentication for mobility services in that a 793 security association that is established as a result of 794 authentication for network access is re-used for authentication 795 for mobility services. 797 All required information including IKE credentials are 798 bootstrapped from the following parameter: 800 * Network access credentials(*) 802 (*) A pair of a NAI and a pre-shared secret is an example set of 803 credentials. A pair of an NAI and a public key, which may be 804 provided as a digital certificate, is another example set of 805 credentials. 807 9. Security Considerations 809 There are two aspects of security for the Mobile IPv6 bootstrapping 810 problem: 812 1. The security requirements imposed on the outcome of the 813 bootstrapping process by RFC 3775 and other RFCs used by Mobile 814 IPv6 for security. 816 2. The security of the bootstrapping process itself, in the sense of 817 threats to the bootstrapping process imposed by active or passive 818 attackers. 820 Note that the two are related, in that if the bootstrapping process 821 is compromised, the level of security required by RFC 3775 may not be 822 obtained. 824 The following two sections discuss these issues. 826 9.1 Security Requirements of Mobile IPv6 828 The Mobile IPv6 specification in RFC 3775 requires the establishment 829 of a collection of IPsec SAs between the home agent and mobile host 830 to secure the signaling traffic for Mobile IP, and, optionally, also 831 to secure data traffic. The security of an IPsec SA required by the 832 relevent IPsec RFCs must be quite strong. Provisioning of keys and 833 other cryptographic material during the establishment of the SA 834 through bootstrapping must be done in a manner such that authenticity 835 is proved and confidentiality is ensured. In addition, the 836 generation of any keying material or other cryptographic material for 837 the SA must be done in a way such that the probability of compromise 838 after the SA is in place is minimized. The best way to minimize the 839 probability of such a compromise is to have the cryptographic 840 material only known or calculable by the two end nodes that share the 841 SA, in this case, the home agent and mobile host. If other parties 842 are involved in the establishing the SA, through key distribution for 843 example, the process should follow the constraints [eap_keying] 844 designed to provide equivalent security. 846 RFC 3775 also requires a trust relationship as defined in Section 1.3 847 between the mobile host and mobility service provider. This is 848 necessary, for instance, to ensure that fradulent mobile hosts which 849 attempt to flood other mobile hosts with traffic can not only be shut 850 off but tracked down [I-D.rosec]. An infrastructureless relationship 851 as defined in Section 1.3 does not satisfy this requirement. Any 852 bootstrapping solution must include a trust relationship between 853 mobile host and mobility service provider. Solutions that depend on 854 an infrastructureless relationship are out of scope for 855 bootstrapping. 857 Another requirement is that a home address is authorized to one 858 specific host at a time. RFC 3775 requires this in order to that 859 misbehaving mobile hosts can be shut down. This implies that, in 860 addition to the IPsec SA, the home agent must somehow authorize the 861 mobile host for a home address. The authorization can be either 862 implicit (for example, as a side effect of the authentication for 863 mobility service) or explicit. The authorization can either be done 864 at the time the SA is created or dynamically managed through a first 865 come, first served allocation policy. 867 9.2 Threats to the Bootstrapping Process 869 Various attacks are possible on the bootstrapping process itself. 870 These attacks can compromise the process such that the RFC 3775 871 requirements for Mobile IP security are not met, or they can serve to 872 simply disrupt the process such that bootstrapping cannot complete. 873 Here are some possible attacks: 875 o An attacking network entity purporting to offer the mobile host a 876 legitimate home agent address or boostrapping for the IPsec SAs 877 may, instead, offer a bogus home agent address or configure bogus 878 SAs that allow the home agent to steal the mobile host's traffic 879 or otherwise disrupts the mobile host's mobility service. 881 o An attacking mobile host may attempt to steal mobility service by 882 offering up fake credentials to a bootstrapping network entity or 883 otherwise disrupt the home agent's ability to offer mobility 884 service. 886 o A man in the middle on the link between the mobile host and the 887 bootstrapping network entity could steal credentials or other 888 sensitive information and use that to steal mobility service or 889 deny it to the legitimate owner of the credentials. Refer to 890 Section 7.15 in [2284bis] and [I-D.mariblanca-aaa-eap-lla-00] for 891 further information. 893 o An attacker could arrange for a distributed denial of service 894 attack on the bootstrapping entity, to disrupt legitimate users 895 from bootstrapping. 897 In addition to these attacks, there are other considerations that are 898 important in achieving a good security design. As mobility and 899 network access authentication are separate services, keys generated 900 for these services need to be cryptographically separate, separately 901 named, and have separate lifetimes, including if the keys are 902 generated from the same authentication credentials This is necessary 903 because a mobile host must be able to move from one serving (or 904 roaming) network access provider to another without needing to change 905 its mobility access provider. Finally, basic cryptographic processes 906 must provide for multiple algorithms in order to accommodate the 907 widely varying deployment needs. 909 10. IANA Considerations 911 No new protocol numbers are required. 913 11. Contributors 915 This contribution is a joint effort of the problem statement design 916 team of the Mobile IPv6 WG. The contributors include Basavaraj 917 Patil, Gerardo Giaretta, Jari Arkko, James Kempf, Yoshihiro Ohba, 918 Ryuji Wakikawa, Hiroyuki Ohnishi, Mayumi Yanagiya Samita Chakrabarti, 919 Gopal Dommety, Kent Leung, Alper Yegin, Hannes Tschofenig, Vijay 920 Devarapalli, Kuntal Chowdury. 922 The design team members can be reached at: 924 Basavaraj Patil basavaraj.patil@nokia.com 926 Gerardo Giaretta gerardo.giaretta@tilab.com 928 Jari Arkko jari.arkko@kolumbus.fi 930 James Kempf kempf@docomolabs-usa.com 932 Yoshihiro Ohba yohba@tari.toshiba.com 934 Ryuji Wakikawa ryuji@sfc.wide.ad.jp 936 Hiroyuki Ohnishi ohnishi.hiroyuki@lab.ntt.co.jp 938 Mayumi Yanagiya yanagiya.mayumi@lab.ntt.co.jp 940 Samita Chakrabarti Samita.Chakrabarti@eng.sun.com 942 Gopal Dommety gdommety@cisco.com 944 Kent Leung kleung@cisco.com 946 Alper Yegin alper.yegin@samsung.com 948 Hannes Tschofenig hannes.tschofenig@siemens.com 950 Vijay Devarapalli vijayd@iprg.nokia.com 952 Kuntal Chowdury kchowdury@starentnetworks.com 954 12. Acknowledgments 956 Special thanks to James Kempf and Jari Arkko for writing the initial 957 version of the bootstrapping statement. Thanks to John Loughney for 958 a detailed editorial review. 960 13. IPR Disclosure Acknowledgement 962 By submitting this Internet-Draft, each author represents that any 963 applicable patent or other IPR claims of which he or she is aware 964 have been or will be disclosed, and any of which he or she becomes 965 aware will be disclosed, in accordance with Section 6 of BCP 79. 967 14. References 969 14.1 Normative References 971 [I-D.ietf-mip6-mn-auth-protocol-02] 972 Patel et. al., A., "Authentication Protocol for Mobile 973 IPv6", draft-ietf-mip6-auth-protocol-02.txt (work in 974 progress), November 2004, 975 . 977 [I-D.ietf-seamoby-mobility] 978 Manner, J. and M. Kojo, "Mobility Related Terminology", 979 draft-ietf-seamoby-mobility-terminology-06 (work in 980 progress), February 2004, 981 . 983 [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access 984 Identifier Extension for IPv4", RFC 2794, March 2000. 986 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 987 in IPv6", RFC 3775, June 2004. 989 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 990 Protect Mobile IPv6 Signaling Between Mobile Nodes and 991 Home Agents", RFC 3776, June 2004. 993 14.2 Informative References 995 [2284bis] Levkowetz, Ed., H., "Extensible Authentication Protocol 996 (EAP)", February 2004, . 998 [I-D.giaretta-mip6-authorization-eap] 999 Giaretta, G., "MIPv6 Authorization and Configuration based 1000 on EAP", draft-giaretta-mip6-authorization-eap-00 (work in 1001 progress), February 2004, 1002 . 1004 [I-D.ietf-mip6-mn-ident-option-02] 1005 Patel, A., Leung, K., Akthar, H., Khalil, M., and K. 1006 Chowdhury, "Mobile Node Identifier Option for Mobile 1007 IPv6", draft-ietf-mip6-mn-ident-option-02.txt (work in 1008 progress), February 2004, 1009 . 1011 [I-D.kempf-mip6-bootstrap] 1012 Kempf, J. and J. Arkko, "The Mobile IPv6 Bootstrapping 1013 Problem", draft-kempf-mip6-bootstrap-00 (work in 1014 progress), March 2004, 1015 . 1017 [I-D.mariblanca-aaa-eap-lla-00] 1018 Mariblanca, D., "EAP lower layer attributes for AAA 1019 protocols", May 2004, 1020 . 1022 [I-D.rosec] 1023 Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1024 Nordmark, "Mobile IP version 6 Route Optimization Security 1025 Design Background", draft-ietf-mip6-ro-sec-02 (work in 1026 progress), October 2004, . 1028 [eap_keying] 1029 Aboba et. al., B., "Extensible Authentication Protocol 1030 (EAP) Key Management Framework", 1031 draft-ietf-eap-keying-05.txt (work in progress), 1032 February 2005, . 1034 Author's Address 1036 Alpesh Patel 1037 Cisco 1038 170 W. Tasman Drive 1039 San Jose, CA 95134 1040 USA 1042 Phone: +1 408 853 9580 1043 Email: alpesh@cisco.com 1045 Intellectual Property Statement 1047 The IETF takes no position regarding the validity or scope of any 1048 Intellectual Property Rights or other rights that might be claimed to 1049 pertain to the implementation or use of the technology described in 1050 this document or the extent to which any license under such rights 1051 might or might not be available; nor does it represent that it has 1052 made any independent effort to identify any such rights. Information 1053 on the procedures with respect to rights in RFC documents can be 1054 found in BCP 78 and BCP 79. 1056 Copies of IPR disclosures made to the IETF Secretariat and any 1057 assurances of licenses to be made available, or the result of an 1058 attempt made to obtain a general license or permission for the use of 1059 such proprietary rights by implementers or users of this 1060 specification can be obtained from the IETF on-line IPR repository at 1061 http://www.ietf.org/ipr. 1063 The IETF invites any interested party to bring to its attention any 1064 copyrights, patents or patent applications, or other proprietary 1065 rights that may cover technology that may be required to implement 1066 this standard. Please address the information to the IETF at 1067 ietf-ipr@ietf.org. 1069 Disclaimer of Validity 1071 This document and the information contained herein are provided on an 1072 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1073 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1074 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1075 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1076 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1077 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1079 Copyright Statement 1081 Copyright (C) The Internet Society (2005). This document is subject 1082 to the rights, licenses and restrictions contained in BCP 78, and 1083 except as set forth therein, the authors retain all their rights. 1085 Acknowledgment 1087 Funding for the RFC Editor function is currently provided by the 1088 Internet Society.