MIP6 Working Group Y. Ohba Internet-Draft TARI Expires: April 17, 2005 R. Lopez Univ. of Murcia M. Yanagiya H. Ohnishi NTT K. Chowdhury Nortel Networks October 17, 2004 Mobile IPv6 Bootstrapping Architecture Using DHCP draft-ohba-mip6-boot-arch-dhcp-00 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 17, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract A mobile node needs home address, home agent address and security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This Ohba, et al. Expires April 17, 2005 [Page 1] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 document describes a bootstrapping architecture in which there is some dependency between AAA for network access and AAA for mobility service and DHCP in the visited network is used for carrying Mobile IPv6 bootstrap information to the mobile node. The architecture is based on an assumption that the mobile node uses network access credentials as the seed information without a need to pre-configure any Mobile IPv6 service parameters. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Basic Architecture . . . . . . . . . . . . . . . . . . . . . . 4 3. Model 1: NAS as a AAA Client for Mobility Service . . . . . . 6 3.1 Integrated ASP Scenario . . . . . . . . . . . . . . . . . 9 3.2 Third Party MSP Scenario . . . . . . . . . . . . . . . . . 10 4. Model 2: NAS as a AAA Client for MIP6 Service . . . . . . . . 12 4.1 Integrated ASP Scenario . . . . . . . . . . . . . . . . . 13 4.2 Third Party MSP Scenario . . . . . . . . . . . . . . . . . 14 5. Comparison with Other Bootstrapping Architectures . . . . . . 15 5.1 Home Agent as NAS for AAA for Mobility Service . . . . . . 15 5.2 MIPv6 Authorization and Configuration based on EAP . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 8.2 Informative References . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 20 Ohba, et al. Expires April 17, 2005 [Page 2] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 1. Introduction A mobile node needs home address, home agent address and security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping [I-D.ietf-mip6-bootstrap-ps]. Two minimal sets of parameters or seed information with which the mobile node is expected to configure prior to bootstrap the rest of the parameters as well as possible deployment scenarios where bootstrapping deems necessary are also defined in [I-D.ietf-mip6-bootstrap-ps]. It is important for a bootstrapping architecture to be integrated with AAA (Authentication, Authorization and Accounting) infrastructure considering large-scale deployment where operators rely on a AAA protocol such as RADIUS for providing authentication, authorization and accounting functionalities for their subscribers of services. Such services include network access and mobility service. This document describes a bootstrapping architecture in which there is some dependency between AAA for network access and AAA for mobility service and DHCP in the visited network is used for carrying Mobile IPv6 bootstrap information to the mobile node. The architecture is based on an assumption that the mobile node uses network access credentials as the seed information without a need to pre-configure any Mobile IPv6 service parameters. This document also discusses how the proposed architecture is mapped to several deployment scenarios described in [I-D.ietf-mip6-bootstrap-ps]. The deployment scenarios discussed in this document are integrated ASP network scenario and third party MSP scenario. Other deployment scenarios, namely mobility service subscription scenario and infrastructure-less scenario, are not discussed in this document since it appears that those scenarios are used when AAA for mobility service is independent of AAA for network access. There are two other bootstrapping architectures that are developed based on different assumptions. One architecture is defined for the case where the mobile node is aware of its home agent address [I-D.yegin-mip6-aaa-fwk] by some means. Another architecture is based on an assumption that there is some dependency between AAA for network access and AAA for mobility service and EAP [RFC3748] is used for carrying Mobile IPv6 bootstrap information to the mobile node [I-D.giaretta-mip6-authorization-eap]. Comparison with those two bootstrapping architectures is also provided in this document. Ohba, et al. Expires April 17, 2005 [Page 3] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 2. Basic Architecture | ASP or IASP | Serving or Home MSP | +-------+ | +-------+ | |------------|--------| | |AAA-NA | | |AAA-MS | |Server |-----+ | |Server | +-------+ | | +-------+ | | | | | | | | | +------+ | | | | DHCP | | | | +--|Server| | | | | +------+ | ----------------------- | | | | | Serving MSP +------+ +------+ | | +------+ |Mobile| | NAS | | | | Home | |Node/ |---------| | | | | Agent| |DHCP | +------+ | | +------+ |Client|---------------------+ | +------+ Figure 1: The Basic Architecture for Bootstrapping MIP6 via DHCP In the typical Mobile IPv6 access scenario as shown above, the mobile node attaches in an Access Service Provider's (ASP) network. During this attach procedure, the NAS authenticates and authorizes the mobile node for IPv6 access service. In the scenario shown, the authentication and authorization happens via a AAA infrastructure. In the architecture shown above the mobile node acquires the Mobile IPv6 bootstrap information using Parameter Set 2 as the seed information as described in [I-D.ietf-mip6-bootstrap-ps]. There are two models described in this document. The first model termed as Model 1, shows how the mobile node performs Mobile IPv6 bootstrapping operation using a DHCP server as the AAA client. The DHCP server receives the Mobile IPv6 bootstrap information such as a home agent address, a home link prefix information from the AAA-MS (AAA for Mobility Service) server in the home Mobility Service Provider (MSP) via the AAA-NA (AAA for Network Access) server in the ASP. The AAA-MS server may also send the delayed authentication key to the DHCP server for DHCP authentication [RFC3118]. The details of the procedures and call flows are described in Section 3 of this document. In the second model termed as Model 2, the NAS authenticates and Ohba, et al. Expires April 17, 2005 [Page 4] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 authorizes the mobile node via the AAA infrastructure. The mobile node still uses Parameter Set 2 as defined in [I-D.ietf-mip6-bootstrap-ps]. The NAS receives the Mobile IPv6 bootstrap information from the AAA-MS server in the home MSP via the AAA-NA server in the ASP. The NAS forwards the received Mobile IPv6 bootstrap information along with any delayed authentication parameter such as the shared secret for the authenticator calculation [RFC3118] to the DHCP server. In this model, the NAS acts as the authorization delegation point as described in [I-D.ohba-aaaarch-authorization-delegation]. The mobile node acquires the Mobile IPv6 bootstrap information from the DHCP server via the normal DHCPv6 procedures with optional delayed authentication option. The details of the procedures involved in Model 2 is described in Section 4 of this document. Ohba, et al. Expires April 17, 2005 [Page 5] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 3. Model 1: NAS as a AAA Client for Mobility Service In this model, the DHCPv6 server acts as a AAA client for mobility service. In this model, AAA for mobility service is used not only for retrieving Mobile IPv6 bootstrap information but also DHCPv6 delayed authentication keys from the AAA infrastructure. A home address is assigned to the mobile node either through DHCPv6 or through IKE. Network Access Client Authentication +-------+ Protocol AAA-NA -------------- |Network--------------- NAS ----------------- ( ) |Access | ( ) |Client | ( ) | | | ( AAA ) | |DHCP |DHCPv6 (Infrastructure) | vkey |w/delayed auth. AAA-MS ( ) |DHCP -------------- DHCP Server ------------ ( ) |Client |<--- <--- -------------- | |MIP6 bootinfo MIP6 bootinfo{HA[,HoA]} | | |{HA[,HoA]} DHCP key | | | | AAA-MS | | IKE | |Mobile-------------- Home Agent --------------------+ |Node |<--- <--- +-------+ MIP6 bootinfo MIP6 bootinfo {[HoA]} {IKE credential[,HoA]} Figure 2: DHCPv6 Server as a AAA Client for Mobility Service In this model, the bootstrapping procedure is executed as described below; 1. First, network access authentication is executed by using a network access authentication protocol and a AAA-NA protocol. 2. After IP connectivity is established, the DHCP client sends a request message (DHCP-SOLICIT). 3. When the DHCP server has received the request message, it requests Mobile IPv6 bootstrap information and a DHCP delayed authentication key [RFC3315][RFC3118] to the AAA infrastructure. 4. According to the identifier of the mobile node such as a MAC address or an NAI (Network Access Identifier) which is included in a AAA-MS protocol request sent from the DHCP server, the AAA Ohba, et al. Expires April 17, 2005 [Page 6] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 server selects the Mobile IPv6 bootstrap information and a DHCP delayed authentication key, and sends these parameters to the DHCP server. 5. The DHCP server executes delayed authentication with the retrieved key. 6. When the DHCP server receives a valid DHCP Request message (DHCP-REQUEST) from the DHCP client, it creates the binding for the DHCP client and sends a reply message (DHCP-REPLY) including "confirmed" configuration information including Mobile IPv6 bootstrap information such as a home agent address and a home prefix. 7. The mobile node starts Mobile IPv6 binding update procedure. When the home agent receives an authentication request message (e.g., an IKE_SA_INIT request message in IKEv2) from the mobile node, it requests IKE credentials such as a symmetric key to the AAA server. Alternatively, the AAA server may send the IKE credentials to the home agent before the home agent receives the authentication request message. 8. The home agent authenticates the mobile node by using the IKE credentials. The DHCP delayed authentication key and a shared secret used for IKE can be derived dynamically in network access authentication protocol exchanges based on e.g., IEEE 802.1X or PANA. Figure 3 shows an example sequence. For simplicity, it is assumed in Figure 3 that the AAA-NA server and the AAA-MS server are integrated in a single AAA server. Ohba, et al. Expires April 17, 2005 [Page 7] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 Mobile Node/ NAS/ Home Agent AAA DHCP Client DHCP Server Server |Network Access | | |Authentication Protocol| AAA-NA | |<--------------------->|<----------------------------------->| | DHCP-SOLICIT | | | |---------------------->| AAA-MS(REQUEST parameters) | | |------------------------------------>| | | AAA-MS(parameters) | | |<------------------------------------| | +---------------+ | | | | Delayed auth. | | | | +---------------+ | | | DHCP-ADVERTISE | | | |(bootstrap info.) | | | |<---------------------| | | +--------------+ | | | | Delayed Auth | | | | +--------------+ | | | | DHCP-REQUEST | | | |--------------------->| | | | +---------------+ | | | | Delayed auth. | | | | +---------------+ | | | | | | | +----------------+ | | | | create binding | | | | +----------------+ | | | | | | DHCP-REPLY |- - - - - - - - - - - - - - - - - - >| | [confirmed bootstrap info.] | | |<----------------------| | | +--------------+ | | | | Delayed Auth | | | | +--------------+ | | | | IKE (authentication request) | | |-------------------------------------->| REQUEST(key for IKE)| | | |-------------------->| | | | REPLY (key for IKE) | | | |<--------------------| | | +-----------+ | | | | User Auth | | | | +-----------+ | | IKE (authentication result) | | |<--------------------------------------| | Figure 3: Model 1 Message Sequence Ohba, et al. Expires April 17, 2005 [Page 8] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 3.1 Integrated ASP Scenario In this scenario the ASP and MSP are in the same integrated entity called IASP (Integrated ASP). Furthermore, this scenario is based on Parameter Set 2 where it is supposed that some dependency exists between AAA-NA and AAA-MS. In this scenario, the AAA-NA server and the AAA-MS server in the IASP play the role as described below. o The AAA-NA server authorizes network access and the AAA-MS server authorizes mobility service. o The AAA-MS server provides Mobile IPv6 bootstrap information to the DHCP server. +-----------------------------+ | IASP(ASP+MSP) | +--------+ +-------------+ +------+ | | Mobile |--- | NAS/ |------| Home | | | Node | | DHCP Server | | Agent| | +--------+ +-------------+ +------+ | : | \ : \ | : | \ +------+ : \ +------+ | : | -|AAA-NA| : -|AAA-MS| | : | |Server| : |Server| | : | +------+ : +------+ | : +-------------:--------:------+ : : MIP6 bootinfo{IKE credential,[HoA]} : :<------>: : MIP6 bootinfo{HA[HoA]} : : [DHCP key] : :<----------------------->: : : Figure 4: Integrated ASP Scenario in Model 1 The DHCP server are also located in the IASP's network. In general, we can assume that there is a security association between the DHCP server and the AAA server in the IASP so that the DHCP server can get Mobile IPv6 bootstrap information from the AAA server. If the mobile node is allowed to roam among IASPs, the DHCP server that is serving the mobile node may belong to an IASP other than the home IASP. Thus, to apply this mechanism, some trust relationship such as a roaming agreement among the IASPs is required. Ohba, et al. Expires April 17, 2005 [Page 9] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 3.2 Third Party MSP Scenario In this scenario, AAA servers in the ASP, the home MSP and the serving MSP operate as described below. o The AAA-MS server in the home MSP may authorize mobility service. o The AAA-MS server in the serving MSP provides Mobile IPv6 bootstrap information to the DHCP server. o The AAA-NA server in the ASP authorizes network access service. In this scenario, the DHCP server may belong to the ASP. The DHCP server needs to get Mobile IPv6 bootstrap information from the AAA-MS server in the home MSP, and the home agent needs to get Mobile IPv6 bootstrap information from the AAA-MS server in the home MSP. So, some trust relationship between the home MSP and the ASP is required in addition to the trust relationship between the home MSP and the serving MSP. In this case, the AAA-NA server in the ASP would contact the AAA-MS server in the home MSP and the AAA-MS server in the home MSP would contact the AAA-MS server in the serving MSP to exchange Mobile IPv6 bootstrap information for a newly authenticated client. Ohba, et al. Expires April 17, 2005 [Page 10] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 +--------------+ +-----------+ | ASP | | Serving | | | | MSP | +-------+ +------------+ | | +------+ | +----------+ |Mobile |--- | NAS/ | | | | Home | | | Home | | Node | |DHCP Server | |===| | Agent| | | MSP | +-------+ +------------+ | | +------+ | | +------+ | : | \ +------+ | | : \ | | |AAA-MS| | : | -|AAA-NA| | | : ----------|Server| | : | |Server| | | : | | +------+ | : | +------+ | +--:--------+ +----:-----+ : +--------------+ : : : :MIP6 bootinfo{IKE credential,[HoA]} : :<-------------->: : : (roaming agreement) : : : MIP6 bootinfo {HA[HoA],[DHCP key] } : :<-------------------------------------->: : (roaming agreement) : Figure 5: Third Party MSP Scenario in Model 1 Ohba, et al. Expires April 17, 2005 [Page 11] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 4. Model 2: NAS as a AAA Client for MIP6 Service In this model, the NAS acts as a AAA client for mobility service as well as a AAA client for network access. The NAS delivers Mobile IPv6 bootstrap information to the DHCP server. A home address is assigned to the mobile node either through DHCPv6 or through IKE. Note that this model is assuming a MIPv6-aware NAS in the network that is providing network access, where the MIPv6-aware NAS is a NAS that receives Mobile IPv6 bootstrap information from the AAA infrastructure via a AAA-MS protocol and has the responsibility to deliver the bootstrap information to the client by some means. Client Network Access +-------+ Authentication |Network| Protocol AAA-NA -------------- |Access --------------------- NAS --------------- ( ) |Client | MIP6 bootinfo | \ ( ) | |DHCP| {HA[,HoA]}, | \ ( AAA ) | |key | [DHCP key] | \ (Infrastructure) | | | DHCPv6 | \ AAA-MS ( ) | v | w/delayed auth. v +---------- ( ) | DHCP -------------------- DHCP Server <--- -------------- |Client | <--- MIP6 bootinfo{HA[,HoA]} | | | MIP6 bootinfo{HA[,HoA]} [DHCP key] | AAA-MS | | | |Mobile | IKE | | Node ------------------- Home Agent -------------------+ +-------+ <--- <-- MIP6 bootinfo{[HoA]} MIP6 bootinfo{IKE credential[,HoA]} Figure 6: NAS as a AAA Client for MIP6 Service When network access authentication is being carried out, mobility service authentication is also carried out. That is, when the client requests network access to NAS by using a network access authentication protocol (i.e. PANA, IEEE 802.1X), the NAS acts as a AAA client for network access and sends a AAA request to the AAA infrastructure in order to authenticate to the client. Note that at the same time, the AAA client for mobility service could send a AAA request to the AAA infrastructure to get Mobile IPv6 bootstrap information. One alternative is that the AAA request sent by the NAS is used to get Mobile IPv6 bootstrap information. In this case the information is carried to the NAS during the AAA-NA procedure, meaning that the AAA-NA and AAA-MS procedures are supposed to be integrated in this case. It is also possible that the AAA client for mobility service invokes the AAA-MS procedure after completion of the AAA-NA procedure. In Ohba, et al. Expires April 17, 2005 [Page 12] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 this case, the AAA-NA and AAA-MS procedures are supposed to be performed separately. In any of these previous alternatives, when a AAA request for network access sent by the NAS is received by the AAA infrastructure and if network access authentication succeeds, the AAA-MS server in the AAA infrastructure contacts the home agent to exchange Mobile IPv6 bootstrap information and provide the mobility service for the mobile node, where the bootstrap information includes IKE credentials and optionally a home address. The home address could be assigned by the home agent instead of the AAA-MS server. When the mobility service is configured, the AAA infrastructure sends the AAA-MS client (i.e., the NAS), the following bootstrap information: a home agent address chosen by the AAA-MS server in the AAA infrastructure and optionally a DHCP delayed authentication key and/or a home address. Note that it is also possible that the DHCP delayed authentication key is derived by the NAS based on the cryptographic material (i.e. AAA_key [I-D.ietf-eap-keying]) provided by the AAA-NA server in the AAA infrastructure after successful completion of the AAA-NA procedure. When the NAS receives from the AAA-MS server MIPv6 bootstrap information for the client for which the AAA-NA procedure has been successfully completed, it pushes the information to the DHCP server. There are several protocols that can be used for carrying Mobile IPv6 bootstrap information and a DHCP delayed authentication key from the NAS to the DHCP server. SNMP is one such protocol. After that, the client obtains the Mobile IPv6 bootstrap information through DHCP. A DHCP delayed authentication key is obtained through the network access authentication procedure and installed to the DHCP client. Now, the client uses the obtained Mobile IPv6 bootstrap information to know which home agent should be contacted. Optionally the bootstrap information contains a home address though it is also possible that a home address is securely assigned through IKE between the mobile node and the home agent. 4.1 Integrated ASP Scenario In this deployment scenario (as it is specified in [I-D.ietf-mip6-bootstrap-ps]) the ASP and MSP are in the same integrated entity called IASP (Integrated ASP). Furthermore, this scenario is based on Parameter Set 2 where it is supposed that some dependency exists between AAA-NA and AAA-MS. The following two cases are considered for this scenario. Ohba, et al. Expires April 17, 2005 [Page 13] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 o In a single domain case where the home/serving ASP and the home/ serving MSP are in the same IASP. In this case, the AAA infrastructure and rest of entities (the NAS, the DHCP server, the home agent, etc.) are managed by the same IASP. o In a roaming case where really the AAA infrastructure shown in Figure 6 is at least divided in two AAA infrastructures: the AAA infrastructure of the serving IASP and the AAA infrastructure of the home IASP. If the mobility service is provided by the home IASP, the home agent depicted in Figure 6 belongs to the home IASP and it is configured by the AAA-MS server of the home IASP. On the other hand, if the mobility service is provided by the serving IASP, the home agent belongs to the serving IASP and configured by the AAA-MS server of the serving IASP. 4.2 Third Party MSP Scenario This scenario could fall into either Parameter Set 1 or Parameter Set 2 depending on whether there is a dependency between AAA-NA and AAA-MS. The first case is out of scope of this document however second one is in scope. Parameter Set 2 case happens when there is some trust relationship between the ASP and the home MSP in addition to the trust relationship between the home MSP and the serving MSP. In this case, the AAA-NA server in the ASP would contact the AAA-MS server in the home MSP and the AAA-MS server in the home MSP would contact the AAA-MS server in the serving MSP to exchange Mobile IPv6 bootstrap information for a newly authenticated client. Ohba, et al. Expires April 17, 2005 [Page 14] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 5. Comparison with Other Bootstrapping Architectures 5.1 Home Agent as NAS for AAA for Mobility Service In [I-D.yegin-mip6-aaa-fwk], a bootstrapping architecture is defined based on an assumption that the mobile node is aware of its home agent address by some means. The known home agent acts as a NAS for AAA for mobility service. This architecture is simpler than other architectures. However, if the operator wants to have more flexibility in assignment of Mobile IPv6 bootstrap information including home agent addresses, e.g., assigning different home agents depending on the profile of the subscriber of the Mobile IPv6 service, then other architectures like the one described in this document would be useful. 5.2 MIPv6 Authorization and Configuration based on EAP The architecture proposed in [I-D.giaretta-mip6-authorization-eap] uses EAP for conveying Parameter Set 2 of [I-D.ietf-mip6-bootstrap-ps] between the mobile node and the AAA-NA server. An advantage of this architecture is that access networks can be transparent to the bootstrapping procedure. A disadvantage is its potential complexity in multi-domain environments where Mobile IPv6 bootstrap information may be assigned by the visited administrative domain, not by the home administrative domain of the mobile node. In this case, the bootstrap information would need to be transferred from the visited administrative domain to the AAA-NA server in the home administrative domain in order to carry them to the mobile node over EAP. Also, this architecture requires existing EAP methods to be modified in order to carry Mobile IPv6 bootstrap information. Ohba, et al. Expires April 17, 2005 [Page 15] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 6. Security Considerations The bootstrapping architecture defined in this document uses DHCP in the visited network for carrying Mobile IPv6 bootstrap information to the mobile node. In an environment where the underlying AAA infrastructure consists of multiple administrative domains, it is possible that the Mobile IPv6 bootstrap information that is assigned and issued by a home administrative domain of the mobile node are passed to the visited administrative domain, which would result in some topological information of the home administrative domain such as home agent addresses to be known to the visited administrative domain unless the information is encrypted between the home administrative domain and the mobile node. However, such information is eventually carried in clear text once the mobile node starts using the bootstrap information by sending Mobile IPv6 Binding Update as well as subsequent data packets and will be known to the visited administrative domain. In this regard, the security risk of this bootstrapping architecture is not much different from that of other bootstrapping architectures if the bootstrap information are finally used by the mobile node. On the other hand, it is possible that the Mobile IPv6 bootstrap information are delivered to the mobile node but not used by the mobile at all. In this case, an operator of the home administrative domain may want to avoid unnecessary information leakage to the visited administrative domain. To achieve this, the bootstrap information delivered via DHCP in the visited access network may be encrypted by using the security association between the home administrative domain and the mobile node. In this case, the DHCP server would act as a configuration server for distributing opaque configuration parameters. Ohba, et al. Expires April 17, 2005 [Page 16] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 7. Open Issues o In the hybrid scenario of integrated ASP and third party MSP scenarios, it is possible that both the MSP in the integrated ASP and the third party MSP are able to provide Mobile IPv6 bootstrap information for the mobile node. In such a scenario, some policy might be needed for the mobile node and/or the MSPs to choose an appropriate MSP that provides bootstrap information to the mobile node or to have both MSPs provide bootstrap information to the mobile node. o Model 1 might have some security issue if the AAA server gives Mobile IPv6 bootstrap information and a DHCP delayed authentication key to a DHCP server per request from a DHCP client which is actually not authenticated and authorized for access to the network served by the DHCP server. Ohba, et al. Expires April 17, 2005 [Page 17] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 8. References 8.1 Normative References [I-D.ietf-mip6-bootstrap-ps] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", draft-ietf-mip6-bootstrap-ps-01 (work in progress), October 2004. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 8.2 Informative References [I-D.ohba-aaaarch-authorization-delegation] Ohba, Y., "An Extended AAA Authorization Framework with Delegation", draft-ohba-aaaarch-authorization-delegation-00 (work in progress), September 2004. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-03 (work in progress), July 2004. [I-D.yegin-mip6-aaa-fwk] Yegin, A., "AAA Mobile IPv6 Application Framework", draft-yegin-mip6-aaa-fwk-00 (work in progress), September 2004. [I-D.giaretta-mip6-authorization-eap] Giaretta, G., "MIPv6 Authorization and Configuration based on EAP", draft-giaretta-mip6-authorization-eap-02 (work in progress), October 2004. [I-D.ietf-dhc-agentopt-radius] Droms, R. and J. Schnizlein, "RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option", draft-ietf-dhc-agentopt-radius-08 (work in progress), September 2004. Ohba, et al. Expires April 17, 2005 [Page 18] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 Authors' Addresses Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 5305 EMail: yohba@tari.toshiba.com Rafael Marin Lopez University of Murcia 30071 Murcia Spain EMail: rafa@dif.um.es Mayumi Yanagiya NTT Network service systems laboratories, NTT Corporation 9-11, Midori-Cho, 3-Chome Musashino-Shi, Tokyo 180-8585 Japan EMail: yanagiya.mayumi@lab.ntt.co.jp Hiroyuki Ohnishi NTT Network service systems laboratories, NTT Corporation 9-11, Midori-Cho, 3-Chome Musashino-Shi, Tokyo 180-8585 Japan EMail: ohnishi.hiroyuki@lab.ntt.co.jp Kuntal Chowdhury Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 U.S.A. EMail: chowdury@nortelnetworks.com Ohba, et al. Expires April 17, 2005 [Page 19] Internet-Draft MIP6 Bootstrapping Architecture Using DHCPOctober 2004 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 ietf-ipr@ietf.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). 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. Ohba, et al. Expires April 17, 2005 [Page 20]