AAA Working Group Youngsong Mun Internet-Draft Miyoung Kim Expires: December, 2007 Soongsil University Jaehoon Nah Seungwon Sohn ETRI July, 2007 Authentication and Path-Provision to Traverse the VPN Gateway in Mobile IPv4 Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 December, 2007. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract Isolating the access to mobility agents by the VPN gateway which guards the home agent, home resources is disturbing the operations of mobile node away from its home that needed to perform the registration of the current location according to the specification M. Kim, et al. Expires December, 2007 [Page 1] Internet-Draft Authentication in Mobile IPv4 July 2007 because the access from the outside is restricted by the VPN policy. This paper presents the authentication and key exchange scheme using the AAA infrastructure for a user in Internet to access the Intranet behind the VPN gateway. By defining the role of authentication and tunnel processing for each agent or relaying entity, we are able to obtain our goal to the security-aware environment. Also, the performance result of the proposed scheme is discussed in depth. Table of Contents 1. Introduction.....................................................3 2. Terminology......................................................4 3. The AAA Authentication Model and Entity in VPN Environment.......5 3.1. Related Work 3.2. Authentication of MN and Home Registration using AAA in VPN 4. Authentication of the MN and Home Registration ..................9 4.1 Related Works 4.2 Authentication of MN and Home Registration using AAA in VPN 5. Message Formats.................................................11 6. Security Considerations.........................................11 7. Conclusions.....................................................11 8. References......................................................12 9. Authors' Addresses..............................................13 M. Kim, et al. Expires December, 2007 [Page 2] Internet-Draft Authentication in Mobile IPv4 July 2007 1 Introduction There has been the attempts to make the one of the representative service, the VPN being accessible in mobile environment without changes. For instance, one approach is to place the Home Agent acting the gateway role between Internet and Intranet. The more the hotspot service of IEEE 802.11 and handheld devices such as cellular phone, PDA is getting popular, the more increased the need to make the various kind of services available no matter what the type of service they use, wired or wireless. When a VPN mobile user is roaming from inside to outside the intranet, there should be a mechanism enabling the MN to keep the connection to its Home Agent with satis-fying the security policy of the VPN. When entering the home zone from Internet, the mobile node should take the authentication procedure to acquire the access right to the resources in there in prior to any mobility operations. The AAA infrastructure is em-ployed for our proposal to provide the robustness of the authentication service as well as authorization and accounting with scalable architecture optimized for mobile environment in secure manner. The proposed scheme, we define the authentication model and its entities using AAA infra-structure in Mobile IPv4 to propose the AAA authentication and key distribution to access the intranet from the outside and present the access scenario for authentication and access to the intranet for roaming VPN user. Finally, the result of performance analysis in the proposed scheme is explored in depth. 2. Terminology This document borrows all of the terminology from Mobile IPv6 [1] and AAA for Mobile MIPv6 [3]. Attendant: AAA entity which is the local AAA system entry point and the local address provider/registry. Term from [8]. AAA client: attendant. AAA home server (AAAH): AAA server of the home network. AAA local server (AAAL): AAA server of the local network. AVP (Attribute Value Pair): AAA (element of) payload. M. Kim, et al. Expires December, 2007 [Page 3] Internet-Draft Authentication in Mobile IPv4 July 2007 Binding: home address/care-of address association for a mobile node on a mobility aware IPv6 node. Care-of address (Co@): temporary address used by a mobile node. The care-of address is allocated or registered by a local entity which is assumed for simplicity in this document to be the same than the attendant. Home address (H@): fixed address used by a mobile node. The home address belongs to the home network and is in general well known by the mobile node even if the protocol described here supports home address allocation. Home agent (HA): router on the home network which forwards traffic at the destination of the home address to the mobile node. Mobile Node (MN): node using mobile IPv6 mechanisms. Correspondent Node (CN) A IPv6 host communicating with MN. Network Access Identifier (NAI): [5] mobile user identifier which is compatible with user_FQDN identities of IKE. We assume NAI can be used to identify any entity involved here even if some of them are nodes and not users. Security Association (SA): a security connection which affords security services to some traffic between peers. This notion is shared between IPsec, ISAKMP and AAA over different forms. Access Router (AR) The MN's default router. Handover A process of terminating existing connectivity and obtaining new IP connectivity. Router Solicitation for Proxy Advertisement (RtSolPr) A message from the MN to the PAR requesting information for a potential handover. Proxy Router Advertisement (PrRtAdv) A message from the PAR to the MN that provides information about neighboring links facilitating expedited movement detection. The message also acts as a trigger for network-initiated handover. M. Kim, et al. Expires December, 2007 [Page 4] Internet-Draft Authentication in Mobile IPv4 July 2007 3 Authentication of the MN and Home Registration in VPN Environment In mobile ip specification, there is no way to establish the predefined SA for CoA because it is temporally used and returned to the FA when exiting the subnet. This paper presents the successful method to authenticate the MN and binding registration to its HA. It is not allowed the MN sending the packets to the VPN directly to approach to HA via VPN gateway since it has no idea of the SA for the source IP ad-dress of the received packets, the CoA. 3.1 Related Works The access modes depending on the MN's location are defined in [5]. It describes the access scenarios for each case where the MN has configured its CoA from the Foreign Agent and DHCP server while locating in outside the intranet: 'fvc' and 'cvc' mode. To determine the current location of it, it sends the binding update(BU) message to x-HA and verifies the response from it. If the CoA has configured from the FA in visited link, the different sequence is applied to process the 'fvc' mode as [5],[6]. However, this method dose not provides such an authentication. Therefore, we inte-grated the method with AAA infrastructure, the Diameter to accomplish the secure authentication in robust way[1][8]. 3.2 Authentication of MN and Home Registration using AAA in VPN The AnT entity is a composite entity which plays multiple role of providing the path to get into the Intranet via VPN gateway and authenticating the MN. AnT always knows the VPN gateway and maintains the consistency of SA by means of message exchanges to check the SA is still alive or expires. All the traffic between the AnT and VPN gateway are encrypted with the SA that can be configured in manually or auto-matically. The other role of AnT is AAA. It authenticates the messages of approaching MN and responds back to it with the SA information that indicates the pass-thru in-formation of the binding registration message traveling into the Intranet via VPN gateway. In order to get the keying resource or materials, the MN should be authenti-cated by the AnT at the first step to approach the Intranet access. The MN starts the detection of its current location by sending the BU to i-HA and x-HA in simultaneously. If the received response has come from the i-HA, the location is determined as intranet otherwise Internet. After detecting the location, it sends the IKE message to AnT entity to obtain the key materials of the IPsec-ESP tunnel estab-lished between AnT and VPN Gateway. The authentication is provided by the interac-tion of M. Kim, et al. Expires December, 2007 [Page 4] Internet-Draft Authentication in Mobile IPv4 July 2007 Diameter protocol. First, the MN sends the authentication request (AReq) mes-sage to the FA(attendant) where the Local Challenge, MN's NAI, Replay Protection Indicator, MN's home address, MN's CoA, Home Agent address, security parame-ter(SecureParam_I),Credentials and Key Request payload are included. After com-pleting the authentication, the MN receives the response message, the ARsp that in-cludes the Local Challenge, Replay Protection Indicator, MN's home address, Home Agent address; secure parameter (SecureParam_R), Credentials and Key Response payload. The MN obtains the keying material from the received SecureParam_R and IKE key and generates the binding key to internal home agent from it. Finally, it sends the BU to i-HA where the BU message is protected by the binding key and the outer packet containing the BU is encrypted by the IKE key. The packet sent from the MN is delivered to the i-HA via the AnT that decrypts the packet and decapsulates the tunnel. 5. Message Formats To be defined. 6. Security Considerations In this draft, AAA infrastrucure are secured by IPsec and TLS. Hence, it is assumed that messages exchanging in AAA infrastructure are secured. However, obviously a deep security review is needed. 7. Conclusions MIPv6 protocol does not provide any specific support for mobility passing through different administrative domains, and hence it limits the applicability of MIPv6 in a large scale commercial deployment. For MIPv6 to be deployed in commercial networks there has to be AAA support for the protocol. Wang's scheme provides a solution for MIPv6 and AAA interworking. It also can support a fast handover, since it enables an MN to establish a security association between the MN and an HA, and to perform a home binding update through AAA procedure. However, Wang's scheme introduces a lot of signal messages and long handover latency during the handover, since Route Optimization mode is performed using Return Routability procedure. To solve this problem, we propose an optimized scheme for Route Optimization mode that the HA performs the binding update for a CN by using the AAA infrastructure between the HA and the CN instead of Return Routability procedure. The proposed scheme can reduce handover latency and signaling overhead during the handover, because Return Routability procedure for Route Optimization mode is not performed. The proposed scheme also can get a security benefit, since it uses the AAA infrastructure which is secured by IPsec and TLS. Since the proposed scheme causes shorter handover latency than the existing schemes, it may be suitable to support real-time communication such as VoIP. Fast Handover for Mobile IPv6 (FMIPv6) [10] and Hierarchical MIPv6 (HMIPv6) [11] have been standardized in IETF. FMIPv6 is an enhanced handover scheme for MIPv6, as portions of layer 3 handover are performed layer 2 handover. HMIPv6 reduces location updates, since mobility is managed locally. Therefore, the proposed scheme can be M. Kim, et al. Expires December, 2007 [Page 11] Internet-Draft Authentication in Mobile IPv4 July 2007 considered to be used in FMIPv6 or HMIPv6, since these mechanisms have enhanced MIPv6. 8. References [1] D. Johnson, C. E. Perkins, and J. Arkko, "Mobility Support in IPv6", Request for Comments (Proposed Standard) 3775, Internet Engineering Task Force, June 2004. [2] R. C. Wang, R. Y. Chen, and Han-Chieh Chao, "AAA architecture for Mobile IPv6 based on WLAN," Int. J. Network Mgmt, Volume 14, Issue 5 September 2004, pp.305-313. [3] F. Dupont, M. Laurent-Maknavicius, and J. Bournelle, "AAA for mobile IPv6," IETF Draft draft-dupont-mipv6-aaa-01.txt, May 2002. [4] F. Le, B. Patil, C. Perkins, and C. Faccin, "Diameter Mobile IPv6 Application," IETF Draft draft-le-aaa-diameter-mobileipv6- 04.txt, May 2005. [5] B. Aboba and M. Beadles, "The Network Access Identifier," IETF RFC2486, January 1999. [6] S. Kent and K. Seo, "Security Architecture for the Internet Protocol," IETF RFC4301, December 2005. [7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and T. Wright, "Transport Layer Security (TLS) Extensions," IETF RFC3546, June 2003. [8] C. de. Laat, G. Gross, L. Gommans, J. Vollbrecht, and D. Spence, "Generic AAA Architecture," IETF RFC2903, August 2000. [9] S. Glass, T. Hiller, S. Jacobs, and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements," IETF RFC2977, October 2000. [10] R. Koodli, (editor), "Fast Handovers for Mobile IPv6", Request for Comments (Experimental) 4068, Internet Engineering Task Force, July 2005. [11] H. Soliman, C. Catelluccia, K. Malki, L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", Request for Comments (Experimental) 4140, Internet Engineering Task Force, August 2005. M. Kim, et al. Expires December, 2007 [Page 12] Internet-Draft Authentication in Mobile IPv4 July 2007 9. Authors' Addresses Miyoung Kim Department of Computing, Soongsil University, #1-1 SangDo-5 Dong, DongJak-Gu, Seoul, 156-743 Korea Phone: +82-2-812-0689 Fax: +82-2-822-2236 E-mail: mizero31@sunny.soongsil.ac.kr Youngsong Mun, Professor Department of Computing, Soongsil University, #1-1 SangDo-5 Dong, DongJak-Gu, Seoul, 156-743 Korea Phone: +82-2-820-0676 Fax: +82-2-822-2236 E-mail: mun@computing.ssu.ac.kr Jaehoon Nah Network Security Department, ETRI #161 Gajeong-Dong Yuseong-Gu Daejeon, seoul, 305-350 KOREA Phone: +82-42-860-6749 Fax: +82-42-860-5611 E-mail: jhnah@etri.re.kr Seungwon Sohn Network Security Department, ETRI #161 Gajeong-Dong Yuseong-Gu Daejeon, seoul, 305-350 KOREA Phone: +82-42-860-5072 Fax: +82-42-860-5611 E-mail: swsohn@etri.re.kr 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 IETF's procedures with respect to rights in IETF Documents can M. Kim, et al. Expires December, 2007 [Page 13] Internet-Draft Authentication in Mobile IPv4 July 2007 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, THE IETF TRUST 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 IETF Trust (2007). 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.