Alpesh.A. Patel, (Editor)Editor Internet-Draft cisco SystemsCisco Expires: April 13,September 16, 2005 March 18, 2005 October 13, 2004Problem Statement for bootstrapping Mobile IPv6 draft-ietf-mip6-bootstrap-ps-01draft-ietf-mip6-bootstrap-ps-02.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 13,September 16, 2005. Copyright Notice Copyright (C) The Internet Society (2004).(2005). All Rights Reserved. Abstract A mobile node needs at least the following information: a home address, home agent address and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document definesdiscuss the problem forissues involved with how the mobile node can be bootstrapped infor Mobile IPv6 and various potential deployment scenarios.scenarios for bootstrapping the mobile node. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Overview of the Problem . . . . . . . . . . . . . . . . . 3 1.2 What is Bootstrapping? . . . . . . . . . . . . . . . . . . 4 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 67 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 78 4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5. Motivation for bootstrapping . . . . . . . . . . . . . . . . . 910 5.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 910 5.1.1 Dynamic Home Address Assignment . . . . . . . . . . . 910 5.1.2 Dynamic Home Agent Assignment . . . . . . . . . . . . 1011 5.1.3 Management requirements . . . . . . . . . . . . . . . 1112 5.2 Security Infrastructure . . . . . . . . . . . . . . . . . 1112 5.2.1 Integration with AAA Infrastructure . . . . . . . . . 1112 5.2.2 Opportunistic"Opportunistic" or Local"Local" Discovery . . . . . . . . . . . 1213 5.3 Topology Change . . . . . . . . . . . . . . . . . . . . . 1213 5.3.1 Dormant Mode Mobile Nodes . . . . . . . . . . . . . . 1213 6. Network Access and Mobility services . . . . . . . . . . . . . 1314 7. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 1516 7.1 Mobility Service Subscription Scenario . . . . . . . . . . 1516 7.2 Integrated ASP network scenario . . . . . . . . . . . . . 1516 7.3 Third party MSP scenario . . . . . . . . . . . . . . . . . 1617 7.4 Infrastructure-less scenario . . . . . . . . . . . . . . . 1718 8. Parameters for authentication . . . . . . . . . . . . . . . . 1819 9. Security Considerations . . . . . . . . . . . . . . . . . . . 2021 9.1 Security Requirements of Mobile IPv6 . . . . . . . . . . . 21 9.2 Threats to the Bootstrapping Process . . . . . . . . . . . 22 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 2223 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 2324 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 2425 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 2425 12.2 Informative References . . . . . . . . . . . . . . . . . . . 2425 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 2526 Intellectual Property and Copyright Statements . . . . . . . . 2627 1. Introduction Mobile IPv6 [RFC3775] specifies mobility support based on the assumption that a mobile node has a trust relationship with an entity called the home agent. Once the home agent address has been learned eitherfor example via manual configuration orconfiguration, via anycast discovery mechanisms, via DNS lookup; Mobile IPv6 signaling messages between the mobile node and the home agent are secured with IPsec.IPsec or authentication protocol [I-D.ietf-mip6-mn-auth-protocol-02]. The requirements for this security architecture are created with [RFC3775] and the details of this procedure are described in .[RFC3776]. In [RFC3775] there is an implicit requirement that the MN be provisioned with enough information that will permit it to register successfully with its home agent. The requirement to haveHowever, having this information statically provisioned creates practical deployment issues. This document serves to define the problem of bootstrapping. Bootstrapping is defined as obtaining enough information atthe mobile node, so thatprocess of the mobile node obtaining enough information, so that it can successfully register with an appropriate home agent. The requirements for bootstrapping could consider various scenarios/ network deployment issues. It is the basic assumption of this document that certain minimal parameters (seed information) is available to the mobile node to aid in bootstrapping. The exact seed information available differs depending on the deployment scenario. This document defines/describes various deployment scenarios and provides for a set of minimal parameters that are available in each deployment scenario. This document stops short of suggesting the various solutions to obtaining information on the mobile node. Such details will be available from separate documents. 1.1 Overview of the Problem Mobile IPv6 [RFC3775] expects the mobile node to have a static home address, home agent address (or anycast address and do dynamic home agent discovery of Home Agent using ICMP messages) and a security association with a home agent (multiple home agents on the home network if dynamic home agent discovery is in use and multiple home agents are deployed.) This static provisioning of information has various problems as discussed in Section 5. The aim of this draft is to: o Define bootstrapping. o Identify sample deployment scenarios where MIPv6 will be deployed, taking into account the relationship between the subscriber and the service provider. o Identify the minimal set of information required on the Mobile Node (and/or) in the network in order for the themobile node to obtain address and security credentials, to register with the home agent. 1.2 What is Bootstrapping? Bootstrapping is defined as obtaining enough information at the mobile node, so that the mobile node can successfully register with an appropriate home agent. Specifically, this means obtaining the home agent address, home address and security credentials for the mobile node and home agent to authenticate and mutually construct security credentials for Mobile IPv6 without requiring preconfiguration. Typically, bootstrapping happens when a mobile node does not have all the information it needs to setup the Mobile IPv6 service. This includes, but is not limited to MN not having any information when it boots up for the first time (out of the box), it does not retain any information during reboots, is instructed by the Home Agent (via some form of signalling) to do so etc. Also, in certain scenarios, after the MN bootstraps for the first time (out of the box), subsequent bootstrapping is implementation dependent. For instance, the MN may bootstrap everytime it boots, bootstrap everytime on prefix change, bootstrap periodically to anchor to an optimal (distance, load etc) HA, etc. 1.3 Terminology For a complete introduction to terminology, please refer to .General mobility terminology can be found in .[I-D.ietf-seamoby-mobility]. The following additional terms are used here: ASP Access Service Provider. A network operatorTrust relationship In the context of this draft, trust relationship means that provides direct IP packet forwarding to and fromtwo parties in question, typically the end host. IASP Integrated Access Service Provider. A service provider providing both network accessuser of the mobile host and mobility. Referred to as IASP or ASP/MSP inthe document. MSP Mobility Service Provider. A service provider that provides Mobile IPv6 service. Granting suchmobility or access service requires authentication. 2. Assumptions o A basic assumptionprovider, have some sort of prior contact in which the Mobile IPv6 RFC  is that there is a trust relationship betweenmobile host was provisioned with credentials. These credentials allow the mobile node and MSP.host to authenticate itself to the mobility or access service authorizer and to prove its authorization to obtain service. Infrastructureless relationship In the context of this draft, an infrastructureless relationship is one in which the user of the mobile host and the mobility or access service provider have no previous contact and the mobile host is not required to supply credentials to authenticate and prove authorization for service. Mobility and/or network access service is provided without any authentication or authorization. Infrastructureless in this context does not mean that there is no network infrastructure, such as would be the case for an ad hoc network. Credentials Data or mechanism used by a mobile host to authenticate itself to a mobility or access network service provider and prove authorization to receive service. User name/passwords, one time password cards, public/private key pairs with certificates, biometric information, etc. are some examples. ASA Access Service Authorizer. A network operator that authenticates a mobile host and establishes the mobile host's authorization to receive Internet service. ASP Access Service Provider. A network operator that provides direct IP packet forwarding to and from the end host. Serving Network Access Provider A network operator that is the mobile host's ASP but not its ASA. The serving network accesss provider may or may not additionally provide mobility service. Home Network Access Provider A network operator that is both the mobile host's ASP and ASA. The home network access provider may or may not additionally provide mobility service (note that this is a slighlty different definition from RFC 3775). IASP Integrated Access Service Provider. A service provider that provides both authorization for network access and also provides mobility service. MSA Mobility Service Authorizer. A service provider that authorizes Mobile IPv6 service. MSP Mobility Service Provider. A service provider that provides Mobile IPv6 service. In order to obtain such service, the mobile host must be authenticated and prove authorization to obtain the service. Home Mobility Service Provider A MSP that both provides mobility service and authorizes it. Serving Mobility Service Provider A MSP that provides mobility service but depends on another service provider to authorize it. 2. Assumptions o A basic assumption in the Mobile IPv6 RFC [RFC3775] is that there is a trust relationship between the mobile node and MSP. This trust relationship can be direct, or indirect through, for instance, an ASP that has a contract with the MSP. This trust relationship can be used to bootstrap the MN. One typical way of verifying the trust relationship is using authentication, authorization, and accounting (AAA). infrastructure. In this document, two distinct typesuses of AAA are considered: AAA for Network Access This functionality provides authentication and authorization to access the network (obtain anaddress and send/receive packets). AAA for Mobility Service This functionality provides authentication and authorization for mobility services. These functionalities may be implemented in a single entity or in different entities, depending on the service models described in Section 6 or deployment scenarios as described in Section 7. o Yet another assumption is that some identifier, such as NAI, as defined in [I-D.ietf-mip6-mn-ident-option-02] or [RFC2794] is provisioned on the MN which permits the MN to identify itself to the ASP and MSP.ASP. 3. Design Goals A solution to the bootstrapping problem has the following design goals: o The following information must be available at the end of bootstrapping, to enable the MN to register with the HA. * MN's home agent address * MN's home agentaddress * IPsec SA between MN and HA orHA, IKE pre-shared secret between MN and HA.HA or shared secret/security association for authentication protocol [I-D.ietf-mip6-mn-auth-protocol-02] o The bootstrapping procedure can be triggered at any time.triggered at any time, either by the MN or by the network. Bootstrapping can occur, for instance due to administrative action, information going stale, HA indicating the MN etc. Bootstrapping may be initiated even when the MN is registered with the HA and has all the required credentials. This may typically happen to refresh/renew the credentials. o Subsequent protocol interaction (for example updating the IPsec SA) can be executed between the MN and the HA itself without involving the infrastructure that was used during bootstrapping. o Solutions to the bootstrapping problem should enable storage of user-specific information on entities other than the home agent. o Solutions to the bootstrapping problem should not exclude storage of user-specific information on entities other than the home agent. o Configuration information which is exchanged between the mobile node and the home agent mustneeds to be secured using integrity and replay protection. Confidentiality protection SHOULDshould be provided if necessary. o All feasible deployment scenarios, along with the relevant authentication/authorization models mustshould be considered. 4. Non-Goals This following issues are clearly outside the scope of bootstrapping: o Home prefix renumbering is not explicity supported as part of bootstrapping. If the MN executes the bootstrap procedures everytime it powers-on (as opposed to caching state information from previous bootstrap process), then home network renumbering is taken care of automatically. o Bootstrapping in the absence of a trust relationship between MN and any provider,provider is not considered. The reason for this is described in Section 9.5. Motivation for bootstrapping 5.1 Addressing The default bootstrapping described in the Mobile IPv6 base specification [RFC3775] has a tight binding to the home addresses and home agent addresses. In this section, we discuss the problems caused by the currently tight binding to home addresses and home agent addresses. 5.1.1 Dynamic Home Address Assignment While it is possible forCurrently, the home agent uses the mobile node's home address to be dynamically assigned,for authorization. When manual keying is used, this happens through the HA cannot verifysecurity policy database, which specifies that a certain security association may only use a specific home address. When dynamic keying is used, the home agent ensures that the MNIKE Phase 1 identity is authorized to userequest security associations for the given home address. Mobile IPv6 uses IKEv1, which is unable to update the security policy database based on a particulardynamically assigned home address. As a result, static home address assignment is really the only home address configuration technique compatible with the current specification. However, support for dynamic home address assignment would be desirable for the following reasons: DHCP-based address assignment Some ASPs may want to use DHCPv6 from the home network to configure home addresses. Recovery from a duplicate address collision It may be necessary to recover from a collision of addresses on the home network. Addressing privacy It may be desirable to establish randomly generated addresses as in RFC 3041 and use them for a short period of time. Unfortunately, current protocols make it possible to use such addresses only from the visited network. As a result, these addresses can not be used for communications lasting longer than the attachment to a particular visited network. Ease of deployment In order to makesimplify the deployment of Mobile IPv6 easy,IPv6, it would beis desirable to free users and administrators from the task of allocating home addresses and specifying them in the security policy database. This is consistent with the general IPv6 design goal of using autoconfiguration whereeverwherever possible. Prefix changes in the home network The Mobile IPv6 specification contains support for a mobile node to autoconfigure a home address based on its discovery of prefix information on the home subnet .[RFC3775]. Autoconfiguration in case of network renumbering is done by replacing the existing network prefix with the new network prefix. Subsequently, the MN needs to update the mobility binding in the HA to register the newly configured Home Address. However, the MN may not be able to register the newly configured address with the HA if a security association related to that reconfigured Home Address does not exist in the MN and the HA. This situation is not handled in the current MIPv6 specification .[RFC3775]. 5.1.2 Dynamic Home Agent Assignment Currently, the address of the home agent is specified in the security policy database. Support for multiple home agents requires the configuration of multiple security policy database entries. However, support for dynamic home agent assignment would be desirable for the following reasons: Home agent discovery The Mobile IPv6 specification contains support for a mobile node to autoconfigure a home agent address based on a discovery protocol .[RFC3775]. Independent network management An ASP may want to dynamically assign home agents in different subnets, that is, not require that a roaming mobile node have a fixed home subnet. Local home agents The mobile node's home ASP may want to allow a local roaming partner ASP to assign a local home agent for the mobile node. This is useful both from the point of view of communications efficiency, and has also been mentioned as one approach to support location privacy. Ease of deployment MSP may want to allow "opportunistic" discovery and utilization of its mobility services without any prearranged contact. These scenarios will require dynamic home address assignment. 5.1.3 Management requirements As described earlier, new addresses invalidate configured security policy databases and authorization tables. Regardless of the specific protocols used, there is a need for either an automatic system for updating the security policy entries, or manual configuration. These requirements apply to both home agents and mobile nodes, but it can not be expected that mobile node users are capable of performing the required tasks. 5.2 Security Infrastructure 5.2.1 Integration with AAA Infrastructure The current IKEv1-based dynamic key exchange protocol described in [RFC3776] has no integration with backend authentication, authorization and accounting techniques unless the authentication credentials and trust relationships use certificates or pre-shared secrets. Using certificates may require the ASP to deploy a PKI, which may not be possible or desirable in certain circumstances. Where a traditional AAA infrastructure is used, the home agent is not able to leverage authentication and authorization information established between the mobile node, the foreign AAA server, and the home AAA server when the mobile node gains access to the foreign network, in order to authenticate the mobile node's identity and determine if the mobile node is authorized for mobility service. The lack of connection to the AAA infrastructure also means the home agent does not know where to issue accounting records at appropriate times during the mobile node's session, as determined by the business relationship between the home ASP and the mobile node's owner. Presumably, some backend AAA protocol between the home agent and home AAA could be utilized, but IKEv1 does not contain support for exchanging full AAA credentials with the mobile node. It is worthwhile to note that IKEv2 provides this feature. 5.2.2 Opportunistic"Opportunistic" or Local"Local" Discovery The home agent discovery protocol does not support an "opportunistic" or local discovery mechanisms in an ASP's local access network. It is expected that the mobile node must know the prefix of the home subnet in order to be able to discover a home agent. It must either obtain that information through prefix update or have it statically configured. A more typical pattern for interdomain service discovery in the Internet is that the client (mobile node in this case) knows the domain name of the service, and uses DNS in some manner to find the server in the other domain. For local service discovery, DHCP is typically used. 5.3 Topology Change 5.3.1 Dormant Mode Mobile Nodes The description of the protocol to push prefix information to mobile nodes in Section 10.6 in [RFC3775] has an implicit assumption that the mobile node is active and taking IP traffic. In fact, many, if not most, mobile devices will be in a low power "dormant mode" to save battery power, or even switched off, so they will miss any propagation of prefix information. As a practical matter, if this protocol is used, an ASP will need to keep the old prefix around and handle any queries to the old home agent anycast address on the old subnet, whereby the mobile node asks for a new home agent as described in Section 11.4, until all mobile nodes are accounted for. Even then, since some mobile nodes are likely to be turned off for long periods, some owners would need to be contacted by other means, reducing the utility of the protocol. Bootstrapping does not explicitly try to solve this problem of home network renumbering when MN is in dormant mode. If the MN can configure itself after it 'comes back on' by reinitiating the bootstrapping process, then network renumbering problem is fixed as a side-effect. 6. Network Access and Mobility services This section defines some terms as it pertains to authentication and practical network deployment/roaming scenarios. This description lays the ground work for Section 7. The focus is on the 'service' model since, ultimately, it is the provider providing the service that wants to authenticate the mobile (and vice-versa for mutual authentication between provider and the user of the service). Network access service enables a host to send and receive IP packets on the Internet or an intranet. IP address configuration and IP packet forwarding capabilities are required to deliver this service. A network operator providing this service is called an access service provider (ASP). An ASP cancan, for example, be a commercial ASP, the IT department of an enterprise network, orenterprise network, or the maintainer of a home (residential) network. If the mobile host is within the geographical area in which network access service is not provided by its home network access service provider, the mobile host is roaming. The home network access service provider in this case acts as the access service authorizer, but the actual network access is provided by the serving network access provider. During the authentication and authorization prior to the mobile host having Internet access, the serving network access provider may simply act as a routing agent for authentication and authorization back to the access service authorizer, or it may require an additional authentication and authorization step itself. An example of a roaming situation is when a business person is using a hotspot service in an airport, and the maintainer ofhotspot service provider has a home (residential) network. Whenroaming agreement with the business person's cellular provider. In that case, the hotspot network service requires authentication,is acting as the concept of home ASP andserving ASP comes intonetwork access provider, while the picture. Home ASPcellular network is acting as the provider with whomaccess service authorizer. When the user has an account. Therefore, whenbusiness person moves from the user directly connectshotspot network to the home ASPcellular network, the ASP can perform authentication without relying on any other service provider. On the other hand, when the user is roaming on the Internet, it may connect to another ASPcellular network that has a roaming agreement with the home ASP. That ASPis called serving ASP. The serving ASP cannot authenticate a roaming user on its own, for that it needs to contactboth the home ASP. A host does not always have to use an IP address from one of its home ASP prefixes. It may be configured with one from the serving ASP's prefixes. In fact,access service provider and the home ASP may not even have a physicalaccess network, in which case it could be identified as a virtual operator. Anotherservice is calledauthorizer. Mobility service using Mobile IPv6 is conceptually and possibly also in practice separate from network access service, whichthough of course network access is required prior to providing mobility. Mobile IPv6 service enables aan IPv6 host to maintain its IPreachability despite changing its network attachment pointspoint (subnets). Providing Mobile IPv6 service involves setting up a home agent on a subnet that acts as a Mobile IPv6 home link. Home agent's responsibility include tunneling host's IP packets between the home link and its current point-of attachment.A network operator providing thisMobile IPv6 service is called a mobility service provider (MSP). Granting Mobile IPv6 service requires authentication betweena host to authenticate and prove authorization for the service. A network operator that authenticates a mobile host and authorizes mobility service is called a mobility service authorizer. If both types of operation are performed by the home agent. The MSPsame operator, that maintains an account for the useroperator is called a home MSP. A home MSP can authenticate its users without relying on any othermobility service provider. Conceptually, the user may be receivingIf authentication and authorization is provided by one operator and the Mobile IPactual service from another MSP that has a roaming agreement withis provider by another, the operator providing the home MSP. Such aservice provideris called the serving MSP. Amobility service provider. The serving MSP needs tomust contact the home MSP in ordermobile host's mobility service authorizer to authenticate the user before providingcheck the mobile host's authorization prior to granting mobility service. A host may authenticate with a MSP based onThe service model defined here clearly separates the some kind of AAA association withentity providing the ASP (typicallyservice from the home ASP or throughentity that authentications and authorizes the home ASP). Aservice. In the case of basic network access, this supports the traditional and well-known roaming model, in which inter-operator roaming agreements allow a host to obtain network access in areas where their home network access provider does not alwayshave to use a Mobile IPv6 home address from one of its home MSP prefixes. It may be configured with one from the serving MSP's prefixes.coverage. In fact,the home MSP may not even have a physical access network, in whichcase it could be identified asof mobility service, this allows a virtual operator. Network access and Mobile IPv6 are two distinct services. Aroaming mobile host can chooseto have onlyobtain mobility service in the local operator's network while having that service authorized by the home operator. The service model also allows mobility service and network access service, or bothservice to be provided by different entities. This allows a network operator with no wireless access, like, for example, an enterprise network access and Mobile IPv6 services at the same time. Only havingoperator, to deploy a Mobile IPv6 home agent for mobility service is not possible, sincewhile the Mobile IPv6 protocol requires ability to send and receive IPv6 packets. Even when both services are receivedactual wireless network access is provided by a host,the serviceserving network access providers involved might vary. All combinations are possiblewith respect towhich the choiceenterprise operator has a contract. Here are some other possible combinations of ASPs and MSPs: o The serving ASP might be the home ASP. Similarly, the serving MSP might be the home MSP. o The home ASP and the home MSP may be the same operator, or not. When they are the same, the same set of credentials may be used for both services. o The serving ASP and the serving MSP may be the same operator, or not. o It is possible that serving ASP and home MSP are the same operator. Similarly the home ASP and serving MSP may be the same. Also, the ASA and MSA may be the same. These entities and possible combinations must be taken into consideration when solving the Mobile IPv6 bootstraping problem. They impact home agent discovery, home address configuration, and mobile node to home agent authentication aspects. 7. Deployment scenarios This section describes the various network deployment scenarios. The various combinations of service providers as described in Section 6 are considered. For each scenario, the underlying assumptions are described. The basic assumption is that there is a trust relationship between mobile user and the MSP. Typically, this trust relationship is between the mobile user and AAA in the MSPMSA's network. Seed information needed to bootstrap the mobile node is considered in two cases (i)cases: o AAA authentication is mandatory for network access "&" (ii)o AAA authentication is not part of network access. The seed information is described further in Section 8. 7.1 Mobility Service Subscription Scenario Many commercial deployments are based on the assumption that mobile nodes have a subscription with a service provider. In particular, in this scenario the MN has a subscription with an MSP, called the home MSP, for Mobile IPv6 service. As stated in Section 6, the MSP is responsible of setting up a home agent on a subnet that acts as a Mobile IPv6 home link. As a consequence, the home MSP should explicitly authorize and control the whole bootstrapping procedure. Since the MN is assumed to have a pre-established trust relationship with its home provider, it must be configured with an identity and credentials, for instance an NAI and a shared secret by some out-of-band means before bootstrapping, for example by manual configuration. In order to guarantee ubiquitous service, the MN should be able to bootstrap MIPv6 operations with its home MSP from any possible access location, such as an open network or a network managed by an ASP, that may be different from the MSP and may not have any pre-established trust relationship with it. 7.2 Integrated ASP network scenario In this scenario, the ASP and MSP are the same ASP. MN shares security credentials for access to the network and these credentials can be used to bootstrap MIPv6. This bootstrapping can be done during the same phase as access authentication/authorization or at a later time (probably based on some state created during access authentication/authorization). Figure 1 describes an example AAA design for integrated ASP scenario. +----------------------------+ | IASP(ASP+MSP) | +----+ +-----+ +----+ | | MN |--- | NAS | | HA | | +----+ +-----+ +----+ | | \ \ | | \ +------+ \ +-------+ | | -|AAA-NA| -|AAA-MIP| | | +------+ +-------+ | +----------------------------+ NAS: Network Access Server AAA-NA: AAA for network access AAA-MIP: AAA for Mobile IP service Figure 1: Integrated ASP network 7.3 Third party MSP scenario Mobility service has traditionally been provided by the same entity that authenticates and authorizes the subscriber for network access. This is certainly the only model supportedsupport by the base Mobile IPv6 specification. In the 3rd party mobility service provider scenario, the subscription for mobility service is made with one entity (home MSPMSA for instance a corporate network), but the actual mobility service is provided by yet another entity (such as an operator specializing on this service, the serving MSP). These two entities have a trust relationship. Transitive trust among the mobile node and these two entities may be used to assure the participants that they are dealing with, are trustworthy peers. This arrangement is similar to the visited - home operator roaming arrangement for network access. Figure 2 describes an example network for third party MSP scenario. +--------------+ +--------+ | | |Serving | | ASP | | MSP | +----+ +-----+ | | +----+ | | MN |--- | NAS | | | | HA | | +-------------------+ +----+ +-----+ |===| +----+ | | Home MSP | | \ | | \ | | (e.g.corporate NW)| | \ +------+ | | \ | +-------+ | | -|AAA-NA| | | -------|AAA-MIP| | | +------+ | | | | +-------+ | +------------ + +--------+ +-------------------+ Figure 2: Third Party MSP network 7.4 Infrastructure-less scenario Infrastructure refers to network entities like AAA, PKI, HLR etc. Infrastructure-less implies that there is no dependency on any elements in the network with which the user has any form of trust relationship. In such a scenario, there is absolutely no relationship between host and infrastructure. A good example of infrastructure-less environment for MIP6 bootstrapping is the IETF network at IETF meetings. It is possible that there could be MIP6 service available on this network (i.e a MIPv6 HA). However there is not really any AAA infrastructure or for that matter any trust relationship that a user attending the meeting has with any entity in the network. This specific scenario is not supported in this document. The reason for this is described in Section 9. 8. Parameters for authentication The following is a list of parameters that are used as the seed for the bootstrapping procedure. The parameters vary depending on whether authentication for network access is independent of authentication for mobility services or not. Authentication for network access is always independent of authentication for mobility services if different client identities are used for network access and mobility services. o Parameter Set 1 In this case, authentication for network access is independent of authentication for mobility services. If the home agent address is not known to the mobile node the following parameter is needed for discovering the home agent address: * The domain name or FQDN of the home agent This parameter may be derived in various ways such as (but not limited to) static configuration, use of the domain name from the network access NAI (even if AAA for network access is not otherwise used) or use of the domain name of the serving ASP where the domain name may be obtained via DHCP in the serving ASP. If the home agent address is not known but the home subnet prefix is known, Dynamic Home Agent Address Discovery of Mobile IPv6 may be used for discovering the home agent address and the above parameter may not be used. When the home agent address is known to the mobile node, the following parameter is needed for performing mutual authentication between the mobile node and the home agent by using IKE: * IKE credentials(*) In the case where the home agent does not have the entire set of IKE credentials, the home agent may communicate with anotherother entity (e.g.,(for example a AAA server) to perform mutual authentication in IKE. In such a case, the IKE credentials include the credentials used between the mobile node and the other entity. In the case where a AAA protocol is used for the communication between the home agent and the other entity during the IKE procedure, AAA for Mobile IPv6 service may be involved in IKE. If authentication protocol [I-D.ietf-mip6-mn-auth-protocol-02] is used, the shared key based security association with home agent is needed. o Parameter Set 2 In this case, some dependency exists between authentication for network access and authentication for mobility services in that a security association that is established as a result of authentication for network access is re-used for authentication for mobility services. All required information including IKE credentials are bootstrapped from the following parameter: * Network access credentials(*) (*) A pair of a NAI and a pre-shared secret is an example set of credentials. A pair of an NAI and a public key, which maya public key, which may be provided as a digital certificate, is another example set of credentials. 9. Security Considerations There are two aspects of security for the Mobile IPv6 bootstrapping problem: 1. The security requirements imposed on the outcome of the bootstrapping process by RFC 3775 and other RFCs used by Mobile IPv6 for security. 2. The security of the bootstrapping process itself, in the sense of threats to the bootstrapping process imposed by active or passive attackers. Note that the two are related, in that if the bootstrapping process is compromised, the level of security required by RFC 3775 may not be obtained. The following two sections discuss these issues. 9.1 Security Requirements of Mobile IPv6 The Mobile IPv6 specification in RFC 3775 requires the establishment of a collection of IPsec SAs between the home agent and mobile host to secure the signaling traffic for Mobile IP, and, optionally, also to secure data traffic. The security of an IPsec SA required by the relevent IPsec RFCs must be quite strong. Provisioning of keys and other cryptographic material during the establishment of the SA through bootstrapping must be done in a manner such that authenticity is proved and confidentiality is ensured. In addition, the generation of any keying material or other cryptographic material for the SA must be provided asdone in a digital certificate, is another example setway such that the probability of credentials. 9. Security Considerationscompromise after the SA is in place is minimized. The bootstrapping procedure needsbest way to createminimize the probability of such a security associationcompromise is to have the cryptographic material only known or calculable by the two end nodes that matchesshare the requirements set for its use. Mobile IPv6 base specification expects strong, mutual authenticationSA, in this case, the home agent and mobile host. If other parties are involved in the establishing the SA, through key distribution for example, the process should follow the constraints [eap_keying] designed to provide equivalent security. RFC 3775 also requires a trust relationship as defined in Section 1.3 between the mobile nodehost and home agent.mobility service provider. This is necessary, for instance, to ensure that fraudulentfradulent mobile nodes thathosts which attempt to flood other nodesmobile hosts with traffic [draft-ietf-mipv6-ro-sec]can not only be shut off from the service,but alsotracked down. The use ofdown [I-D.rosec]. An infrastructureless techniquesrelationship as defined in Section 1.3 does not satisfy these requirements, at least not without introducing additional routability tests to the Mobile IPv6 home registration procedure. Thus, the case of infrastructure-less network where there is absolutely no pre-mediatedthis requirement. Any bootstrapping solution must include a trust is kept outsiderelationship between mobile host and mobility service provider. Solutions that depend on an infrastructureless relationship are out of scope of this document.for bootstrapping. Another requirement is that the "ownership" toa particularhome address must beis authorized to at mostone mobile nodespecific host at a time. RFC 3775 requires this in order to that misbehaving mobile hosts can be shut down. This implies that a Mobile IPv6 security association is always tiedthat, in addition to zerothe IPsec SA, the home agent must somehow authorize the mobile host for a home address. The authorization can be either implicit (for example, as a side effect of the authentication for mobility service) or more such authorizations; these authorizationsexplicit. The authorization can either be createddone at the time the security associationthe SA is created,created or dynamically managed through, for instance,through a First Come First Servedfirst come, first served allocation policy. Where an automatic bootstrap process is used, it becomes necessary9.2 Threats to associate a lifetime with allthe parameters whichBootstrapping Process Various attacks are bootstrapped. Otherwise a large number of unused security associations would have to be stored bypossible on the participating nodes, either by accident or through malicious behaviour orbootstrapping process itself. These attacks can compromise the mobile node will have stale information. The specific mean of verifyingprocess such that the RFC 3775 requirements for Mobile IP security association isare not defined in this document, but itmet, or they can be, for exampleserve to simply disrupt the process such that bootstrapping cannot complete. Here are some possible attacks: o An attacking network entity purporting to offer the mobile host a set of IKE credentials, anlegitimate home agent address or boostrapping for the IPsec security association,SAs may, instead, offer a username-password -like associationbogus home agent address or digital signature constructedconfigure bogus SAs that allow the home agent to steal the mobile host's traffic or otherwise disrupts the mobile host's mobility service. o An attacking mobile host may attempt to steal mobility service by offering up fake credentials to a certified key. The bootstrap process itself may have vulnerabilities. The following issues needbootstrapping network entity or otherwise disrupt the home agent's ability to be addressed:offer mobility service. o Mutual authentication and trust relationshipA man in the middle on the link between the mobile nodehost and the bootstrapping network entity handlingcould steal credentials or other sensitive information and use that to steal mobility service or deny it to the bootstrap process.legitimate owner of the credentials. Refer to Section 7.15 in [2284bis] and [I-D.mariblanca-aaa-eap-lla-00] for further information. o Cryptographic separation and namingAn attacker could arrange for a distributed denial of sessionservice attack on the bootstrapping entity, to disrupt legitimate users from bootstrapping. In addition to these attacks, there are other considerations that are important in achieving a good security design. As mobility and network access authentication are separate services, keys usedgenerated for multiple purposes, such asthese services need to be cryptographically separate, separately named, and have separate lifetimes, including if the keys are generated from the same authentication credentials This is necessary because a mobile host must be able to move from one serving (or roaming) network access authentication and mobility service. o Ensuring that key lifetimes are not exceeded. o Binding security associationsprovider to specific home agent and address allocations. o Support ofanother without needing to change its mobility access provider. Finally, basic cryptographic processes must provide for multiple algorithms forin order to accommodate the resulting security associations. o Avoidance of denial-of-service vulnerabilities.widely varying deployment needs. 10. Contributors This contribution is a joint effort of the problem statement design team of the Mobile IPv6 WG. The contributors (alphabetical order)include Jari Arkko, Samita Chakrabarti, Kuntal Chowdhury, Vijay Devarapalli, Gopal Dommety,Basavaraj Patil, Gerardo Giaretta, Jari Arkko, James Kempf, Kent Leung,Yoshihiro Ohba, Ryuji Wakikawa, Hiroyuki Ohnishi, Basavaraj Patil,Mayumi Yanagiya Samita Chakrabarti, Gopal Dommety, Kent Leung, Alper Yegin, Hannes Tschofenig, Vijay Devarapalli, Kuntal Chowdury. The design team members can be reached at: Basavaraj Patil email@example.com Gerardo Giaretta firstname.lastname@example.org Jari Arkko email@example.com James Kempf firstname.lastname@example.org Yoshihiro Ohba email@example.com Ryuji Wakikawa,Wakikawa firstname.lastname@example.org Hiroyuki Ohnishi email@example.com Mayumi Yanagiya firstname.lastname@example.org Samita Chakrabarti Samita.Chakrabarti@eng.sun.com Gopal Dommety email@example.com Kent Leung firstname.lastname@example.org Alper Yegin.Yegin email@example.com Hannes Tschofenig firstname.lastname@example.org Vijay Devarapalli email@example.com Kuntal Chowdury firstname.lastname@example.org 11. Acknowledgments Special thanks to James Kempf and Jari Arkko for writing the initial version of the bootstrapping statement. Thanks to John Loughney for a detailed editorial review. 12. References 12.1 Normative References  Bradner, S., "Key words[I-D.ietf-mip6-mn-auth-protocol-02] Patel et. al., A., "Authentication Protocol for useMobile IPv6", draft-ietf-mip6-auth-protocol-02.txt (work in RFCs to Indicate Requirement Levels",progress), November 2004, <http://www.ietf.org/internet-drafts/draft-ietf-mip6-auth-protocol-02.txt> . [I-D.ietf-seamoby-mobility] Manner, J. and M. Kojo, "Mobility Related Terminology", draft-ietf-seamoby-mobility-terminology-06 (work in progress), February 2004, <http://www.ietf.org/internet-drafts/draft-ietf-seamoby-mobility-terminology -06.txt> . [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2119,2794, March 1997. 2000. [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, July 2003. June 2004. [RFC3776] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling betweenBetween Mobile Nodes and Home Agents", RFC 3776, July 2003.  Manner, J. and M. Kojo, "Mobility Related Terminology", draft-ietf-seamoby-mobility-terminology-06 (work in progress), FebruaryJune 2004. 12.2 Informative References [2284bis] Levkowetz, Ed., H., "Extensible Authentication Protocol (EAP)", February 2004, <http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-09.txt> . [I-D.giaretta-mip6-authorization-eap] Giaretta, G., "MIPv6 Authorization and Configuration based on EAP", draft-giaretta-mip6-authorization-eap-00 (work in progress), February 2004.  Kempf, J. and J. Arkko, "The Mobile IPv6 Bootstrapping Problem", draft-kempf-mip6-bootstrap-00 (work in progress), March 2004. 2004, <http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization-eap-0 0.txt> . [I-D.ietf-mip6-mn-ident-option-02] Patel, A., Leung, K., Akthar, H., Khalil, M. and K. Chowdhury, "Network Access"Mobile Node Identifier Option for Mobile IPv6", draft-ietf-mip6-nai-option-00draft-ietf-mip6-mn-ident-option-02.txt (work in progress), February 2004.  Calhoun, P.2004, <http://www.ietf.org/internet-drafts/draft-ietf-mip6-mn-ident-option-02.txt> . [I-D.kempf-mip6-bootstrap] Kempf, J. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.  Levkowetz, Ed., H., "Extensible Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-09J. Arkko, "The Mobile IPv6 Bootstrapping Problem", draft-kempf-mip6-bootstrap-00 (work in progress), February 2004. March 2004, <http://www.ietf.org/internet-drafts/draft-kempf-mip6-bootstrap-00.txt> . [I-D.mariblanca-aaa-eap-lla-00] Mariblanca, D., "EAP lower layer attributes for AAA protocols", draft-mariblanca-aaa-eap-lla-00.txtMay 2004, <http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt> . [I-D.rosec] Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", draft-ietf-mip6-ro-sec-02 (work in progress), May 2004.  Yegin, A., "AAA Mobile IPv6 ApplicationOctober 2004, <http://www.ietf.org/internet-drafts/draft-ietf-mip6-ro-sec-02.txt> . [eap_keying] Aboba et. al., B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-yegin-mip6-aaa-fwk-00draft-ietf-eap-keying-05.txt (work in progress), August 2004.February 2005, <http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-05.txt> . Author's Address Alpesh Patel cisco SystemsCisco 170 W. Tasman Drive San Jose, CA 95134 USA Phone: +1 408 853 9580 EMail: email@example.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004).(2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.