Internet DRAFT - draft-yacine-preauth-ipsec
draft-yacine-preauth-ipsec
Network Working Group Y. El Mghazli
Internet-Draft Alcatel
Expires: December 10, 2006 J. Bournelle
GET/INT
J. Laganier
DoCoMo Euro-Labs
June 8, 2006
MPA using IKEv2 and MOBIKE
draft-yacine-preauth-ipsec-01
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 10, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes how to achieve media-independent pre-
authentication (MPA) in the context of network accesses protected by
IPsec. In such environments, access is protected by an IPsec tunnel
mode security association (SA) established between a client of the
network and an access gateway. This SA normally needs to be
El Mghazli, et al. Expires December 10, 2006 [Page 1]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
established by running an IKE exchange between the two SA endpoints.
The duration of this IKE exchange make it impractical to use when the
node is mobile and frequently change either its location or its
access gateway during a handover. In most case it is expected that
real time traffic will be impacted by the handover. This note
describes a method that alleviate this issue by leveraging on the
IKEv2 Mobility and Multihoming Protocol (MOBIKE). The described
method supresses the need to run a full IKE exchange after each
handover, thereby greatly reducing the impacts of handovers on real-
time traffic.
Table of Contents
1. Terminology and Definitions . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Media Pre-Authentication Framework . . . . . . . . . . . . 5
2.2. IKEv2 and MOBIKE overview . . . . . . . . . . . . . . . . 5
2.2.1. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. MOBIKE . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. IPsec protection in the access network . . . . . . . . . . 6
3. MPA with IKEv2 and MOBIKE . . . . . . . . . . . . . . . . . . 7
3.1. First Step: IKEv2 pre-authentication . . . . . . . . . . . 7
3.2. Completing MPA with MOBIKE . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
El Mghazli, et al. Expires December 10, 2006 [Page 2]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
1. Terminology and Definitions
Most of the terms are extracted from [I-D.ohba-mobopts-mpa-framework]
and [I-D.ietf-mobike-protocol].
Media-independent Pre-Authentication Mobile Node (MN):
A mobile terminal of media-independent pre-authentication (MPA)
which is a mobile-assisted, secure handover optimization scheme
that works over any link-layer and with any mobility management
protocol. An MPA mobile node is an IP node. In this document,
the term "mobile node" or "MN" without a modifier refers to "MPA
mobile node". An MPA mobile node usually has a functionality of a
mobile node of a mobility management protocol as well.
Candidate Target Network (CTN):
A network to which the mobile may move in the near future.
Gateway (GW):
In this document, a Gateway is an Access Router using IKEv2.
IPsec TIA
Inner Address of the IPsec Tunnel.
IPsec TOA
Outer Address of the IPsec Tunnel.
Target Network (TN):
The network to which the mobile has decided to move. The target
network is selected from one or more candidate target network.
Proactive Handover Tunnel:
A bidirectional IP tunnel that is established between the MPA
mobile node and an access router of a candidate target network.
In this document, the term "tunnel" without a modifier refers to
"proactive handover tunnel".
Care-of Address:
El Mghazli, et al. Expires December 10, 2006 [Page 3]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
An IP address used by a mobility management protocol as a locator
of the MPA mobile node.
El Mghazli, et al. Expires December 10, 2006 [Page 4]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
2. Introduction
2.1. Media Pre-Authentication Framework
One of the current goal in IP based network is to achieve seamless
handover. While it exists solutions at layer 2 or IP level, the
authentication process is most of the time not considered. The
document [I-D.ohba-mobopts-mpa-framework] introduces a framework to
achieve this goal by relying on pre-authentication. This means the
mobile authenticates to a candidate target network before attaching
to it.
The proposed framework is the following (extracted from [I-D.ohba-
mobopts-mpa-framework]):
1. The Mobile establish a Security Association with a Candidate
Target Network (CTN) to secure subsequent protocol signalling.
2. It securely executes a configuration protocol to obtain an IP
address and other parameters from the CTN.
3. It executes a tunnel management protocol to establish a Proactive
Handover Tunnel (PHT) (i.e. a bidirectionnal tunnel between the
MN and an access router of the CTN).
4. Through this PHT, the MN can send and receives IP packets
including signaling messages for the Mobility Management
Protocol. As a consequence, it can receives IP data packets
resulting from this new binding.
5. Finally, it deletes or disables the PHT immediatly before
attaching to the CTN. Then it reassigns the inner address of the
PHT to the physical interface immediatly after the MN is attached
to the CTN.
In this document, we propose a solution for MPA based on IKEv2 and
MOBIKE.
2.2. IKEv2 and MOBIKE overview
2.2.1. IKEv2
The IKEv2 protocol [RFC4306] mutually authenticate two peers (named
Initiator and Responder) in order to dynamically and securely
establish IPsec SAs. It can be divided in two main phases. In the
first phase called IKE_SA_INIT, the two peers establish an IKE SA
(Security Association) to protect subsequent messages. In the second
phase, called IKE_AUTH, the two peers authenticate each other and
El Mghazli, et al. Expires December 10, 2006 [Page 5]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
start to configure IPsec SAs. If others IPsec SAs are needed, they
use the CREATE_CHILD_SA exchange which relies on previous
authenticated IKE SA.
The two main features of interest for this document are:
1. The IKEv2 specification allows the Responder to authenticate
Initiator by using the EAP protocol [RFC3748]. This permits to
the Responder to rely on a AAA server to authenticate the
Initiator. Note that Initiator authenticates the responder based
on public-key based mechanism.
2. The IKEv2 allows to establish an IPsec tunnel between the
Initiator and the Responder to protect data traffic.
2.2.2. MOBIKE
The MOBIKE protocol [I-D.ietf-mobike-protocol] is an extension of
IKEv2. It allows to change an IP address associated with IKEv2 and
an IPsec tunnel to change without reusing IKEv2 from scratch. This
feature is particulary useful to achieve an efficient MPA with IKEv2.
2.3. IPsec protection in the access network
In such environments, access is protected by an IPsec tunnel mode
security association (SA) established between a client of the network
and an access gateway. This SA normally needs to be established by
running an IKE exchange between the two SA endpoints. The duration
of this IKE exchange make it impractical to use when the node is
mobile and frequently change either its location or its access
gateway during a handover. In most case it is expected that real
time traffic will be impacted by the handover.
Examples of access networks typically protected by IPsec are 3G/WLAN
interworking technologies, namely UMA [UMA] and I-WLAN [I-WLAN].
El Mghazli, et al. Expires December 10, 2006 [Page 6]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
3. MPA with IKEv2 and MOBIKE
This document describes a method to achieve media-independent pre-
authentication (MPA) in the context of network accesses protected by
IPsec. This method alleviates the issues of long delays involved
with running a complete IKE exchange after handover by leveraging on
the IKEv2 Mobility and Multihoming Protocol (MOBIKE). It does so by
supressing the need to run a full IKE exchange after each handover,
thereby greatly reducing the impacts of handovers on real-time
traffic.
The solution is to pre-establish a pre-handover IPsec tunnel mode
(PHT) SA with the access gateway; When a handover occurs, the mobile
node use MOBIKE to update the outer address of the tunnel, thereby
transforming the PHT into a regular Access Tunnel.
Thus, combining MOBIKE and Pre-Authentication allows in this context
to reduce the overall IP connectivity re-establishment delay to the
L2 handoff only.
The MPA framework considers the 3 following entities:
1. The Authentication Agent: this entity is responsible of the pre-
authentication.
2. The Configuration Agent: this entity is responsible to securely
deliver an IP address and other configuration parameters to the
mobile node.
3. The Access Router: It is the router with which the Mobile Node
establishes a proactive handover tunnel.
In the proposed approach, the three following functionalities are
handled by the IKEv2 Responder colocated with the Access Router.
3.1. First Step: IKEv2 pre-authentication
Initially, the Mobile Node obtains IP connectivity in a access
domain. Thanks to a mechanism out-of scope of this document, the
Mobile Node discovers a new GW to which it may attach.
It starts a pre-authentication procedure with this nGW using IKEv2.
This IKEv2 preauthentication procedure has the following goals:
o Establish an IPsec tunnel between MN and the nGW.
El Mghazli, et al. Expires December 10, 2006 [Page 7]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
o Obtains an address valid in the Candidate Target Network. This is
achieved thanks to CFG_REQUEST/CFG_REPLY of IKEv2.
This address will be be attached to the physical interface after the
Mobile Node attaches to the new access network. As a consequence,
after attachment, this new address will be used as the outer address
of the tunnel between MN and the nGW and thus must be valid in the
new visited access network.
The following IKEv2 messages are exchanged between MN and the nGW.
These exchanges occur while the Mobile Node is still in the previous
access network.
Mobile Node new GW
----------- ------
(coa:500 -> nGW:500)
---------------------------------->
HDR, SAi1, KEi, Ni
(nGW:500 -> coa:500)
<----------------------------------
HDR, SAr1, KEr, Nr
---------------------------------->
HDR, SK{IDi, [CERTREQ,], CP(CFG_REQUEST)
SAi2, TSi, TSr, N(MOBIKE_SUPPORTED)}
(MN does not include AUTH to be authenticated by EAP)
<----------------------------------
HDR, SK{IDr, [CERT,], AUTH, EAP}
...
<----------------------------------
HDR, SK{ EAP (success)}
----------------------------------->
HDR, SK{AUTH}
<-----------------------------------
HDR, SK{AUTH, CP(CFG_REPLY), SAr2,
TSi, TSr, N(MOBIKE_SUPPORTED)
After IKEv2 preauthentication, the Mobile Node has an IPsec tunnel
with the nGW.
The IPsec tunnel with nGW has the following header:
o IPsec TOA: CoA and nGW
El Mghazli, et al. Expires December 10, 2006 [Page 8]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
o IPsec TIA: nCoA and Correspondent Node
This IPsec tunnel corresponds to the secure Proactive Tunnel. The
Mobile Node can use its Mobility Management Protocol inside this
tunnel to indicate its future new location (nCoA).
When the MN changes of visited network, the source outer adress is no
longer valid. The next section explains how MOBIKE can be used to
achieve an efficient handover.
The new GW has allocated the nCoA for the Mobile Node which is not
yet in its access network. However, it knows that the Mobile Node is
supposed to come in its access network.
At this point of time, it is not clear if the Mobile Node must
indicate in this IKEv2 exchange that it is a pre-authentication.
3.2. Completing MPA with MOBIKE
As a result of the IKEv2 preauthentication with nGW, the Mobile has
an IKE_SA with the nGW. However, the source outer address of the
IPsec tunnel is not valid in nGW's access network. To avoid a
complete reauthentication procedure with nGW, we propose to use the
MOBIKE protocol.
For this purpose, the Mobile Node sends an INFORMATIONAL IKEv2
messages containg an UPDATE_SA_ADDRESSES:
Mobile Node nGW
----------- -----------
HDR, SK { N(UPDATE_SA_ADDRESSES),
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } -->
Note that this packet is sent right after the Mobile Node has
performed its IP handover and as such the Mobile Node uses its nCoA
as source IP address.
As it is the nGW which has allocated this nCoA, it can validate this
request. Then it updates its IKE_SA with the IP address of the IP
header of the IKEv2 message. It replies with an IKEv2 INFORMATIONAL
message and finally it updates the IPsec SAs associated with this
IKE_SA with the new addresses.
If the MOBIKE exchange is successfull, the Mobile Node now has the
El Mghazli, et al. Expires December 10, 2006 [Page 9]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
following tunnel with the nGW:
o IPsec TOA: nCoA and nGW
o IPsec TIA: nCoA and CN
This optimized approach recycles the PHT as the IPsec tunnel, which
protects the data flows in an IPsec-protected access environment.
This avoids the need to re-authenticate with the nGW and re-establish
an IPsec tunnel for this purpose.
El Mghazli, et al. Expires December 10, 2006 [Page 10]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
4. Security Considerations
The security considerations on this proposal need to be further
studied. However, because the proposal uses unmodified IKEv2 and
MOBIKE protocols in the context of pre-authentication with IPsec
protected network accesses, it is believed by the authors that the
proposal does not introduce any additional threats neither to the
existing IKEv2 and MOBIKE protocols, nor to the architecture which
relies on them for network access authentication (e.g. 3GPP IWLAN,
UMA).
El Mghazli, et al. Expires December 10, 2006 [Page 11]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
5. IANA Considerations
This document has no IANA considerations.
El Mghazli, et al. Expires December 10, 2006 [Page 12]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
6. Acknowledgements
The authors would like to thank Maryline Laurent-Maknavicius and
Olivier Marce for useful discussions on this topic.
El Mghazli, et al. Expires December 10, 2006 [Page 13]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
7. References
7.1. Normative References
[I-D.ietf-mobike-protocol]
Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", draft-ietf-mobike-protocol-08 (work in
progress), February 2006.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
7.2. Informative References
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[I-D.ietf-mobike-design]
Kivinen, T. and H. Tschofenig, "Design of the MOBIKE
Protocol", draft-ietf-mobike-design-08 (work in progress),
March 2006.
[I-D.ohba-mobopts-mpa-framework]
Ohba, Y., "A Framework of Media-Independent Pre-
Authentication (MPA)", draft-ohba-mobopts-mpa-framework-02
(work in progress), March 2006.
[I-D.ohba-mobopts-mpa-implementation]
Ohba, Y., "Media-Independent Pre-Authentication (MPA)
Implementation Results",
draft-ohba-mobopts-mpa-implementation-02 (work in
progress), March 2006.
[I-D.ohba-mobopts-heterogeneous-requirement]
Dutta, A., "Problem Statement for Heterogeneous Handover",
draft-ohba-mobopts-heterogeneous-requirement-01 (work in
progress), March 2006.
[I-D.ietf-pana-preauth]
Ohba, Y., "Pre-authentication Support for PANA",
draft-ietf-pana-preauth-01 (work in progress), March 2006.
El Mghazli, et al. Expires December 10, 2006 [Page 14]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
[I-WLAN] 3GPP, "3GPP system to Wireless Local Area Network (WLAN)
interworking; System description", TS 23.234,
December 2005.
[UMA] UMA technology, "Unlicensed Mobile Access", Stage 2
Specifications R1.0.4, May 2005.
El Mghazli, et al. Expires December 10, 2006 [Page 15]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
Authors' Addresses
Yacine El Mghazli
Alcatel
Route de Nozay
Marcoussis 91460
France
Email: yacine.el_mghazli@alcatel.fr
Julien Bournelle
GET/INT
9, rue Charles Fourier
Evry 91011
France
Email: julien.bournelle@int-evry.fr
Julien Laganier
DoCoMo Communications Laboratories Europe GmbH
Landsberger Strasse 312
Munich 80687
Germany
Phone: +49 89 56824 231
Email: julien.ietf@laposte.net
URI: http://www.docomolab-euro.com/
El Mghazli, et al. Expires December 10, 2006 [Page 16]
Internet-Draft MPA using IKEv2 and MOBIKE June 2006
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 (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.
El Mghazli, et al. Expires December 10, 2006 [Page 17]
