Network Working Group J. Bournelle Internet-Draft M. Laurent-Maknavicius Expires: juin 1, 2005 GET/INT December 2004 Bootstrapping Mobile IPv6 using PANA draft-bournelle-pana-mip6-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she 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 juin 1, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract A mobile node using Mobile IPv6 needs a home address, a home agent address and a security association with its home agent. The problem is to find a way to dynamically configure those data in order to ease Mobile IPv6 deployment. We propose to use the PANA protocol for this. Before the authentication phase, the PANA Authentication Agent (PAA) offers the Bournelle & Laurent-Maknavicius Expires juin 1, 2005 [Page 1] Internet-Draft PANA for Mobile IPv6 December 2004 Mobile IPV6 service to the PANA Client (PaC). According to the PaC's response, after the authentication and authorization phase with the AAA infrastructure, the PAA will be in charge of allocating a home agent (HA) and a home address to the mobile node. The IKE pre-shared key would be derived from the keys exported from the EAP method. Then the PAA configures the HA and gives to the PaC in a PANA-Bind exchange the necessary information to bootstrap Mobile IPv6. Note that the IKE pre-shared key is also derived at PaC so, this key is only exported from the PAA to the HA. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. PANA overview . . . . . . . . . . . . . . . . . . . . . . . 5 4. Bootstrapping information for Mobile IPv6 . . . . . . . . . 6 5. Proposed solution . . . . . . . . . . . . . . . . . . . . . 7 6. Modifications to the PANA protocol . . . . . . . . . . . . . 10 7. Security considerations . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . 13 Bournelle & Laurent-Maknavicius Expires juin 1, 2005 [Page 2] Internet-Draft PANA for Mobile IPv6 December 2004 1. Introduction One of the major issue of Mobile IPv6 [RFC3775]is currently the bootstrapping problem. Indeed, a mobile node needs a home address, a home agent address and a security association with its home agent to register. The problem is to find a way for the mobile to get those information. The document [I-D.ietf-mip6-bootstrap-ps] describes various deployment scenarios. In particular, it makes a clear distinction between the Access Service Provider (ASP) and the Mobility Service Provider (MSP). Both can be integrated in a Integrated Access Service Provider (IASP). In this document, we propose to use the Protocol for carrying Authentication Network Access (PANA) to bootstrap Mobile IPV6. This protocol can be used as a frontend to a AAA architecture. For this, we describe what should be modify to the current PANA specification and the related operations. This solution suppose that we are in the IASP scenario. Bournelle & Laurent-Maknavicius Expires juin 1, 2005 [Page 3] Internet-Draft PANA for Mobile IPv6 December 2004 2. Terminology This document uses the following terms or abbreviations: PANA Protocol for Carrying Network Authentication for Network Access PANA Client (PaC) A mobile node (MN) using a PANA protocol implementation to authenticate itself to the network. PAA The PANA Authentication Agent (PAA) is the entity responsible to verify the credentials provided by the PANA client. It is also responsible of granting network access. HA The home agent is a Mobile IPv6 device. It is a router in charge of delivering IPv6 packets addressed to the home address of the mobile node. Bournelle & Laurent-Maknavicius Expires juin 1, 2005 [Page 4] Internet-Draft PANA for Mobile IPv6 December 2004 3. PANA overview PANA is a protocol that carries EAP over IP/UDP to authenticate users. The PAA (PANA Authentication Agent) is the endpoint of the PANA protocol at the access network. The PAA itself might not be able to authenticate the user by terminating the EAP protocol. Instead the PAA might forward the EAP payloads to the backend AAA infrastructure. The Enforcement Point (EP) is an entity which enforces the result of the PANA protocol exchange. The EP might be co-located with the PAA or separated as a stand-alone device. In the latter case, the SNMPv3 protocol [I-D.ietf-pana-snmp] is used to communicate between PAA and EP. A successful EAP authentication exchange results in a PANA security association (PANA SA) if the EAP method was able to derive session keys. In this case, all further PANA messages between PaC and PAA will be authenticated, replay and integrity protected thanks to the MAC AVP. Bournelle & Laurent-Maknavicius Expires juin 1, 2005 [Page 5] Internet-Draft PANA for Mobile IPv6 December 2004 4. Bootstrapping information for Mobile IPv6 To bootstrap Mobile IPv6, the mobile node must have the following information: o A home address. The mobile node is always reachable at this address o A home agent address. o IPsec SA with the home agent or an IKE pre-shared key The allocated home agent must have the corresponding information: o The home address of the MN. The home agent is eventually responsible of allocating this address. o IPsec SA with the mobile node or an IKE pre-shared key Bournelle & Laurent-Maknavicius Expires juin 1, 2005 [Page 6] Internet-Draft PANA for Mobile IPv6 December 2004 5. Proposed solution In this section, we describe our approach. The mobile node uses the PANA client module to be authenticated. The (visited) domain provides Mobile IPv6 service and thus is responsible of a pool of Home Agents (HA). PaC PAA HA AAA --- --- -- --- PSR[Capability=Mobile IPv6] <----------- PSA[ok for Mobile IPv6] --------------> Authentication/authorization phase <-------------------------> setting HA <-----------> PANA-Bind-Exchange[H@,HA@] . <-------------> IKE <---------------------------> Figure 1: Message flow of PANA-Mobile IPv6 solution The PANA session starts by a PANA-Start exchange (cf. Figure 1). The PAA sends a PSR message to the PaC. In this message, we propose to add a flag in the Protection-Capability AVP informing of the availability of the Mobile IPv6 service. The PaC will indicate if it is interested by this proposal in the PSA message. Then, the (visited) network authenticates the PaC using PANA-Authentication exchange. In this phase, the PAA could indicate to the AAA infrastructure that the PaC desire to use Mobile IPv6. This should allow an explicit authorization of the AAA infrastructure. +-----+ +-----+ +----+ | PaC |<-------| PAA |<---------->| HA | +-----+ +-----+ +----+ Bournelle & Laurent-Maknavicius Expires juin 1, 2005 [Page 7] Internet-Draft PANA for Mobile IPv6 December 2004 Home Address IKE psk Home Agent Address (Home address for the PaC) At the end of the authentication phase, the PaC has been correctly authenticated and the Mobile IPV6 service has been authorized. The first step for the PAA is to allocate a home agent. The method of allocation is out of scope of this document. The second step is the home address allocation for the PaC. It can be either allocated by the PAA or by the home agent. In the latter case, the PAA asks to the HA to provide a home address. The third step is to compute a IKE pre-shared key. This can be accomplished in the following way: IKE Pre-shared Key = HMAC-SHA-1 (AAA-Key, "MIPv6-IKE-psk" | Session ID) Then the PAA communicates those information to the HA using a protocol. This protocol is currently out of scope of our proposal. However we may notice that the document [I-D.giaretta-mip6-aaa-ha-goals] tries to catch requirements for such a communication. The result of this work could also be applied here. After the PAA <---> HA phases, the PAA continues the PANA session with a PANA-Bind exchange. As in [I-D.ietf-pana-ipsec], the PaC is also able to derive a IKE pre-shared key using the AAA-Key exported by the EAP method in use. Thus the PAA does not need to send the IKE psk to the mobile node. However the PAA will provide the home agent address and the home address to the PaC using dedicated AVP. (Thus we need to introduce two AVPs). PANA AAA PaC <---------> PAA <----------> AAA ^ ^ | | | IKE(v2) | ? | | | v +------------->HA At the end of the PANA exchange, the PaC has been authenticated and Bournelle & Laurent-Maknavicius Expires juin 1, 2005 [Page 8] Internet-Draft PANA for Mobile IPv6 December 2004 can access the IP network. Moreover, it has been configured with sufficient data to configure an IPsec SA with the allocated HA. Note that just after the PANA session, the home address could be the PPAC. Bournelle & Laurent-Maknavicius Expires juin 1, 2005 [Page 9] Internet-Draft PANA for Mobile IPv6 December 2004 6. Modifications to the PANA protocol This proposal requires the following changes to PANA specifications: o Add a flag to the Protection-Capability AVP or change Protection-Capability AVP by Capability AVP and also add a flag. o The PSA message needs a way to carry the answer of PaC o We introduce two AVPs to carry the home address and the home agent address. o We need a protocol for the PAA <----> HA communication. Bournelle & Laurent-Maknavicius Expires juin 1, 2005 [Page 10] Internet-Draft PANA for Mobile IPv6 December 2004 7. Security considerations This document defines a mechanism to bootstrap Mobile IPv6 service. For this, the PAA must derive an IKE pre-shared key that will be used to configure an IPsec SA between the PaC and the HA. This key is exported from the PAA to the HA and thus the message used for this purpose should provide confidentiality and integrity. 8 References [I-D.ietf-pana-pana] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-06 (work in progress), October 2004. [I-D.ietf-pana-ipsec] Parthasarathy, M., "PANA enabling IPsec based Access Control", draft-ietf-pana-ipsec-04 (work in progress), September 2004. [I-D.ietf-pana-snmp] Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for PAA-2-EP interface", draft-ietf-pana-snmp-02 (work in progress), October 2004. [I-D.giaretta-mip6-aaa-ha-goals] Giaretta, G., "Goals for AAA-HA interface", draft-giaretta-mip6-aaa-ha-goals-00 (work in progress), September 2004. [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. [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Bournelle & Laurent-Maknavicius Expires juin 1, 2005 [Page 11] Internet-Draft PANA for Mobile IPv6 December 2004 Authors' Addresses Julien Bournelle GET/INT 9 rue Charles Fourier Evry 91011 France EMail: julien.bournelle@int-evry.fr Maryline Laurent-Maknavicius GET/INT 9 rue Charles Fourier Evry 91011 France EMail: maryline.maknavicius@int-evry.fr Bournelle & Laurent-Maknavicius Expires juin 1, 2005 [Page 12] Internet-Draft PANA for Mobile IPv6 December 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 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. Bournelle & Laurent-Maknavicius Expires juin 1, 2005 [Page 13] Internet-Draft PANA for Mobile IPv6 December 2004 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bournelle & Laurent-Maknavicius Expires juin 1, 2005 [Page 14]