Network Working Group Y. El Mghazli
Internet-Draft Alcatel
Expires: August 27, 2006 J. Bournelle
GET/INT
February 23, 2006
MPA using IKEv2 and MOBIKE
draft-yacine-preauth-ipsec-00
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 August 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document discusses the details of pre-authentication in a IPsec
protected access environment. It describes an optimized solution
that avoids re-establishing an IPsec tunnel after the handover,
leveraging on IKEv2 and MOBIKE protocol.
El Mghazli & Bournelle Expires August 27, 2006 [Page 1]
Internet-Draft MPA using IKEv2 and MOBIKE February 2006
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. Initial Step: IKEv2 authentication . . . . . . . . . . . . 7
3.2. First Step: IKEv2 pre-authentication . . . . . . . . . . . 7
3.3. 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 & Bournelle Expires August 27, 2006 [Page 2]
Internet-Draft MPA using IKEv2 and MOBIKE February 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 & Bournelle Expires August 27, 2006 [Page 3]
Internet-Draft MPA using IKEv2 and MOBIKE February 2006
An IP address used by a mobility management protocol as a locator
of the MPA mobile node.
El Mghazli & Bournelle Expires August 27, 2006 [Page 4]
Internet-Draft MPA using IKEv2 and MOBIKE February 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 & Bournelle Expires August 27, 2006 [Page 5]
Internet-Draft MPA using IKEv2 and MOBIKE February 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
This document discusses the specific case where IPsec protection is
used systematically in the access segment. This is typically the
case in 3G/WLAN interworking technologies, namely UMA [UMA] and
I-WLAN [I-WLAN]. Here one or several IPsec tunnels are used to
connect the terminal to the mobile operators network.
El Mghazli & Bournelle Expires August 27, 2006 [Page 6]
Internet-Draft MPA using IKEv2 and MOBIKE February 2006
3. MPA with IKEv2 and MOBIKE
The solution described here leverage on MOBIKE extensions to IKEv2 in
order to keep the PHT SA for the Access Tunnel. This avoids the need
to re-establish new SA after the handover. When coupled with a
seamless handover mechanism in the Access network, combining the
benefits of MOBIKE and Pre-Authentication in such specific contexts
enables to reduce the overall IP connectivity establishment delay to
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. Initial Step: IKEv2 authentication
At the beginning, the Mobile Node establish an IPsec tunnel with a
Gateway (GW). This GW is located in the Access Router and is
collocated with the IKEv2 Responder. In this access network, the
mobile node uses the CoA as the address attached to its physical
interface.
The IPsec tunnel has the following header:
o IPsec TOA: CoA and GW
o IPsec TIA: CoA and Correspondant Node
3.2. First Step: IKEv2 pre-authentication
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:
El Mghazli & Bournelle Expires August 27, 2006 [Page 7]
Internet-Draft MPA using IKEv2 and MOBIKE February 2006
o Establish an IPsec tunnel between MN and the nGW.
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:
El Mghazli & Bournelle Expires August 27, 2006 [Page 8]
Internet-Draft MPA using IKEv2 and MOBIKE February 2006
o IPsec TOA: CoA and nGW
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).
Thus, at this point of time, the Mobile Node owns 2 tunnels: one with
the current Gateway and one with the new Gateway. While the binding
is executed, the Mobile Node is ready to moves in the CTN.
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.3. 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
El Mghazli & Bournelle Expires August 27, 2006 [Page 9]
Internet-Draft MPA using IKEv2 and MOBIKE February 2006
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
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 & Bournelle Expires August 27, 2006 [Page 10]
Internet-Draft MPA using IKEv2 and MOBIKE February 2006
4. Security Considerations
TBD
El Mghazli & Bournelle Expires August 27, 2006 [Page 11]
Internet-Draft MPA using IKEv2 and MOBIKE February 2006
5. IANA Considerations
El Mghazli & Bournelle Expires August 27, 2006 [Page 12]
Internet-Draft MPA using IKEv2 and MOBIKE February 2006
6. Acknowledgements
The authors would like to thank Maryline Laurent-Maknavicius and
Olivier Marce for useful discussions on this topic.
El Mghazli & Bournelle Expires August 27, 2006 [Page 13]
Internet-Draft MPA using IKEv2 and MOBIKE February 2006
7. References
7.1. Normative References
[I-D.ietf-mobike-protocol]
Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", draft-ietf-mobike-protocol-07 (work in
progress), December 2005.
[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-07 (work in progress),
January 2006.
[I-D.ohba-mobopts-mpa-framework]
Ohba, Y., "A Framework of Media-Independent Pre-
Authentication (MPA)", draft-ohba-mobopts-mpa-framework-01
(work in progress), July 2005.
[I-D.ohba-mobopts-mpa-implementation]
Ohba, Y., "Media-Independent Pre-Authentication (MPA)
Implementation Results",
draft-ohba-mobopts-mpa-implementation-01 (work in
progress), July 2005.
[I-D.ohba-mobopts-heterogeneous-requirement]
Dutta, A., "Problem Statement for Heterogeneous Handover",
draft-ohba-mobopts-heterogeneous-requirement-00 (work in
progress), October 2005.
[I-D.ietf-pana-preauth]
Ohba, Y., "Pre-authentication Support for PANA",
draft-ietf-pana-preauth-00 (work in progress),
El Mghazli & Bournelle Expires August 27, 2006 [Page 14]
Internet-Draft MPA using IKEv2 and MOBIKE February 2006
October 2005.
[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 & Bournelle Expires August 27, 2006 [Page 15]
Internet-Draft MPA using IKEv2 and MOBIKE February 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
El Mghazli & Bournelle Expires August 27, 2006 [Page 16]
Internet-Draft MPA using IKEv2 and MOBIKE February 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 & Bournelle Expires August 27, 2006 [Page 17]