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