Internet DRAFT - draft-mun-aaa-locallkm-mobileipv6
draft-mun-aaa-locallkm-mobileipv6
AAA Working Group Miyoung Kim
Internet-Draft Youngsong Mun
Expires: January, 2006 Soongsil University
Jaehoon Nah
Seungwon Sohn
ETRI
July, 2006
Authentication and Path-Provision to Traverse
the VPN Gateway in Mobile IPv4
<draft-mun-aaa-locallkm-mobileipv6-00.txt>
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 2006.
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 January, 2006 [Page 1]
Internet-Draft Authentication in Mobile IPv4 July 2006
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 January, 2006 [Page 2]
Internet-Draft Authentication in Mobile IPv4 July 2006
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 January, 2006 [Page 3]
Internet-Draft Authentication in Mobile IPv4 July 2006
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 January, 2006 [Page 4]
Internet-Draft Authentication in Mobile IPv4 July 2006
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 January, 2006 [Page 4]
Internet-Draft Authentication in Mobile IPv4 July 2006
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 January, 2006 [Page 11]
Internet-Draft Authentication in Mobile IPv4 July 2006
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 January, 2006 [Page 12]
Internet-Draft uthentication in Mobile IPv4 July 2006
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 January, 2006 [Page 13]
Internet-Draft uthentication in Mobile IPv4 July 2006
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 (2006). 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.
