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]