MIP6 Working Group G. Giaretta
Internet Draft I. Guardini
Expires: April 2007 E. Demaria
Telecom Italia
J. Bournelle
M. Laurent-Maknavicius
GET/INT
October 2006
MIPv6 Authorization and Configuration based on EAP
<draft-giaretta-mip6-authorization-eap-04.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 April 27, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights
Reserved.
Abstract
This draft defines an architecture, and related protocols, for
performing dynamic Mobile IPv6 authorization and configuration
relying on a AAA infrastructure. The necessary interaction between
the AAA server of the home provider and the mobile node is
realized using EAP, exploiting the capability of some EAP methods
to convey generic information items together with authentication
data. This approach has the advantage that the access equipment
acts as a simple pass-through for EAP messages and therefore does
not play any active role in the Mobile IPv6 negotiation procedure,
which makes the solution easier to deploy and maintain.
Giaretta, et al. Expires - September 2006 [Page 1]
Internet-Draft MIPv6 Authorization based on EAP October 2006
Table of Contents
1. Introduction................................................3
2. Terminology.................................................4
3. Protocol Overview...........................................5
4. Requirements on EAP methods.................................9
5. Detailed description of the Protocol.......................11
5.1 Mobile node bootstrapping...............................11
5.2 Management of re-authentication events..................15
6. Home Agent considerations..................................16
6.1 Requirements on AAAH-HA communication...................16
6.2 Management of MIPv6 authorization state.................17
7. The MIPv6-Authorization container..........................18
7.1 PEAPv2..................................................18
7.2 EAP-FAST................................................19
7.3 EAP-SIM.................................................19
7.4 EAP-AKA.................................................19
7.5 EAP-TTLS................................................19
7.6 EAP-IKEv2...............................................20
8. New TLVs...................................................22
8.1 Service-Status-TLV......................................22
8.2 Service-Selection-TLV...................................22
8.3 Service-Options-TLV.....................................23
8.4 Home-Agent-Address-TLV..................................23
8.5 Home-Address-TLV........................................24
8.6 IKE-Authentication-Options-TLV..........................25
8.7 IKE-Bootstrap-Information-TLV...........................25
8.8 Negotiation-Result-TLV..................................26
8.9 Authorization-Lifetime-TLV..............................27
9. Security Considerations....................................28
10. References.................................................29
10.1 Normative References..................................29
10.2 Informative References................................29
Acknowledgments.................................................31
Authors Addresses..............................................31
Intellectual Property Statement.................................32
Giaretta, et al. Expires - April 2007 [Page 2]
Internet-Draft MIPv6 Authorization based on EAP October 2006
1. Introduction
Mobile IPv6 [RFC3775] requires that Mobile Nodes (MNs) and Home
Agents (HAs) share a set of configuration parameters: the MN must
know its Home Address, the Home Agent Address and the
cryptographic material needed to protect MIPv6 signaling (e.g.
shared keys or certificates to setup an IPsec security
association). MIPv6 base protocol does not specify any method to
automatically acquire this information; which means that network
administrators are normally required to manually set configuration
data on MNs and HAs.
Manual configuration of Home Agents and Mobile Nodes also works as
an implicit method for Mobile IPv6 authorization, because only the
users that have been administratively enabled on a specific Home
Agent are allowed to exploit Mobile IPv6 and its features.
However, in a large network (e.g. the network of a mobile
operator), which may include millions of users and many Home
Agents, the operational and administrative burden of this
procedure may easily become overwhelming. In addition, the
extensive use of manual and static configurations limits the
flexibility and reliability of the system, in that it is not
possible to dynamically assign the HA when the user enters the
network, which would help to optimize performance and resource
utilization (e.g. assignment of the HA closest to the MNs point
of attachment).
This is generally referred to as the Mobile IPv6 bootstrapping
problem. As discussed in [RFC4640], several bootstrapping
scenarios can be identified depending on the relationship between
the network operator providing IP services to the MN (Access
Service Provider, ASP) and the service provider managing the HA
(Mobility Service Provider, MSP). This document describes a
solution to the bootstrapping problem that is applicable in a
scenario where the ASP and the MSP are the same provider
(Integrated ASP, IASP).
The proposed solution performs dynamic Mobile IPv6 authorization
and configuration together with MN authentication for network
access. MIPv6 negotiation and bootstrapping is controlled by the
AAA server of the home provider (IASP), that interacts with the
mobile node relying on AAA routing and EAP, exploiting the
capability of some EAP methods (e.g. PEAPv2 [PEAPv2], EAP-FAST
[EAP-FAST]) to convey generic information items together with
authentication data.
Giaretta, et al. Expires - April 2007 [Page 3]
Internet-Draft MIPv6 Authorization based on EAP October 2006
2. Terminology
General mobility terminology can be found in [RFC3753]. The
following additional terms are used here:
ASP Access Service Provider
IASP Integrated Access Service Provider
MSP Mobility Service Provider
AAA Authentication Authorization Accounting
AAAH AAA server of the Home domain
Giaretta, et al. Expires - April 2007 [Page 4]
Internet-Draft MIPv6 Authorization based on EAP October 2006
3. Protocol Overview
The basic idea behind the solution proposed herewith is to perform
Mobile IPv6 bootstrapping during the authentication procedure
undertaken by the Mobile Node to gain network access.
In particular, this draft defines a method to:
- explicitly authorize the use of Mobile IPv6 based on the service
profile of the user, its position within the network, etc.
- dynamically allocate a Home Agent to the Mobile Node;
- dynamically configure Mobile IPv6 start-up parameters (i.e.
MIPv6 bootstrapping) on the Mobile Node. These parameters
include the Home Address and the cryptographic material needed
to set-up the IPsec Security Association used to protect Mobile
IPv6 signaling (i.e. Binding Updates and Binding
Acknowledgements).
Figure 1 shows the overall architecture of the solution proposed
in this draft. The central element of the architecture is the AAA
server of the Home Domain (i.e. AAAH), which interacts with both
the MN and the selected HA to perform service authorization and
configuration.
AAA
Client
IEEE 802.1x +------+ RADIUS
or PANA | | or Diameter
+--------+ /--------------EAP Exchange-----------------\ +-------
-+
| Mobile |/ <------------Authentication---------------> \| AAAH
|
| Node |\ <--MIPv6 authorization and configuration--> /| Server
|
+--------+ \-------------------------------------------/ +-------
-+
| | /\
+------+ /||\
Router ||
or AP AAAH-HA ||
(pass through) Protocol ||
\||/
\/
+-------
-+
| Home
|
| Agent
|
+-------
-+
Figure 1 - Solution architecture
The solution is applicable to any access network relying on EAP
[RFC3748] for user authentication and works with all EAP methods
supporting the exchange of general purpose information elements,
in any form (e.g. TLVs or AVPs), between EAP peers. Exploiting
this capability, MN and AAAH can piggyback Mobile IPv6 negotiation
messages within the same EAP conversation used to carry out user
authentication.
Giaretta, et al. Expires - April 2007 [Page 5]
Internet-Draft MIPv6 Authorization based on EAP October 2006
This kind of operation is already supported by several tunneled
(e.g. PEAPv2 [PEAPv2]) and non tunneled (e.g. EAP-IKEv2 [EAP-
IKEv2]) EAP methods, that also include native support for
encryption, authentication and integrity protection of exchanged
configuration data (e.g. HA address).
Figure 2 shows an overview of the procedure defined to handle
MIPv6 bootstrap on the Mobile Node. For the sake of simplicity it
is assumed that the employed AAA protocol is Diameter, but
obviously RADIUS is suitable as well.
EAP over
IEEE 802.1x EAP over Diameter AAAH-HA
or PANA AAA (or RADIUS) AAAH Protocol
MN +---------+ Client +----------------+ Server +-------------+
HA
1) <--Req. Id.---
--Identity---> --Diameter EAP Req.-->
/-------------------------------------\
2) / Set-up of protected channel \
\ e.g. TLS Tunnel (optional) /
\-------------------------------------/
/-------------------------------------\
3) / Authentication \
\ Phase /
\-------------------------------------/
/-------------------------------------\ +-+ /--------------\
+-+
4) / Mobile IPv6 service \| |/ HoA selection \|
|
\ authorization and configuration /| |\ and HA config. /|
|
\-------------------------------------/ +-+ \--------------/
+-+
Home Agent
State
Selection
Set-up
5) <-----EAP----- <-----Diameter EAP----
Success/Failure Answer (Success/Failure
and authorization AVPs)
/----------------------------------------------------------\
6) / Set-up Security Association MN-HA and \
\ Mobile IPv6 registration (exchange of BU and BA) /
\----------------------------------------------------------/
Figure 2 - Overview of Mobile IPv6 bootstrap procedure
The whole procedure can be divided in six steps:
1. EAP identity exchange (i.e. exchange of EAP Request Identity and
EAP Response Identity messages);
2. set-up of a protected channel (e.g. TLS tunnel) for the delivery
of subsequent EAP signaling. This is an optional step that is
present only if the EAP method provides confidentiality support.
It is mandatory only if the MIPv6 negotiation procedure involves
the exchange of sensitive information;
3. authentication phase. The actual authentication procedure and
its security properties depend on the selected EAP method. In
Giaretta, et al. Expires - April 2007 [Page 6]
Internet-Draft MIPv6 Authorization based on EAP October 2006
tunneled EAP methods (e.g. PEAPv2) this step may involve one or
more complete EAP conversations occurring within a previously
negotiated TLS session. Each EAP conversation may accomplish
user authentication relying on any available EAP method (e.g.
EAP-MD5, EAP-SIM, EAP-AKA);
4. Mobile IPv6 service authorization and configuration. MN and AAAH
exchange a sequence of signaling messages to authorize and
configure Mobile IPv6. Those messages are encapsulated as
requested by the employed EAP method (e.g. TLVs or AVPs) and
delivered as part of the on-going EAP session. If the EAP method
provides confidentiality this protocol handshake is encrypted
using the previously negotiated ciphersuite. During this phase,
AAAH selects a suitable Home Agent for the MN and exchanges
authorization and configuration data with it using a AAAH-HA
protocol, whose specification is out of the scope of the present
document. Further analysis on the definition of such an
interface can be found in [AAAMIP6] and [AAAMIPFWK]. At the end
of this phase, the MN knows its own Home Address, the address of
the correspondent Home Agent, the peer authentication method
(i.e. certificates or pre-shared key) and the cryptographic
material (e.g. pre-shared key) needed to set-up an IPsec
security association with IKE [RFC2409]. The IKE pre-shared key
can be either constructed by AAAH and then delivered to MN in a
proper TLV (or AVP) or independently derived by MN and AAAH from
the EAP key hierarchy;
5. EAP session termination. Assuming the mobile node has been
successfully authenticated, the AAAH server sends a Diameter EAP
Answer message with Result-Code equal to SUCCESS. The AAA client
extracts the EAP Success message from the Diameter EAP Answer
and forwards it to the MN terminating the EAP session;
6. set-up of IPsec Security Association and MIPv6 registration. At
the end of the EAP communication, the MN gains network access
and acquires a valid Care-of Address within the visited subnet
(e.g. via stateless autoconfiguration); then it performs an IKE
exchange to establish the IPsec Security Association with the
HA, using the authentication method and the cryptographic
material negotiated during the MIPv6 service configuration phase
(step 4). Finally, the MN performs MIPv6 registration, sending a
Binding Update (protected with IPsec) to the HA.
This draft also defines the procedures to handle re-authentication
events and to manage the termination of the Mobile IPv6 session.
In summary, the proposed architecture has the following
advantages:
- allows the MSP to maintain a centralized management (on the AAA
server) of the user profiles and the authentication,
authorization and accounting procedures for any type of service,
including Mobile IPv6;
- improves the reliability and performance of the Mobile IPv6
protocol, in that the HA to be dynamically assigned to the MN
can be freely chosen among those that are closest to the users
point of attachment, thus optimizing network usage and reducing
the transfer delay for data traffic in bi-directional tunneling;
- can be deployed, or extended with new features, without having
to update the access equipment and the AAA protocols in use.
Only minor changes in the AAA servers, the Home Agents and the
mobile terminals are required, in that the AAA client does not
Giaretta, et al. Expires - April 2007 [Page 7]
Internet-Draft MIPv6 Authorization based on EAP October 2006
play any active role in MIPv6 negotiation (i.e. it is a pass-
through for EAP signaling). This reduces the deployment costs
and makes the solution easy to use even when a Mobile Node is
roaming with a provider different from its own;
- allows the usage of any AAA protocol supporting the transport of
EAP messages for the communication between the AAA client and
server (i.e. not just Diameter, but also RADIUS). This
significantly simplifies the deployment of MIPv6 in existing
communication networks, where support for Diameter protocol in
access equipment is not so extensive.
- allows the operator to dynamically choose the authentication
method for IKE bootstrapping and to automatically distribute the
pre-shared key eventually needed; in this way the pre-shared key
must not be pre-configured and can be frequently changed
increasing resistance to attacks. In the case of an EAP method
providing dynamic generation of keying material the pre-shared
key can be derived from EAP hierarchy avoiding the need to
explicitly send it to the MN [MIPv6AMSK].
As a whole, the solution adds a maximum of 2 RTTs (see the
detailed protocol description in section 5) to the EAP
conversation carried out by the mobile node to authenticate itself
and gain network access. The number of extra RTTs can be reduced
if the employed EAP method has the capability of transporting
MIPv6 negotiation TLVs (or AVPs) together with authentication
data. Nonetheless, it should be noted that the full negotiation
procedure can be undertaken by the MN only during its initial
bootstrapping, and therefore the performance requirements are not
so strict.
Giaretta, et al. Expires - April 2007 [Page 8]
Internet-Draft MIPv6 Authorization based on EAP October 2006
4. Requirements on EAP methods
In EAP methods, the EAP peer and EAP server exchange data in order
to authenticate the EAP peer and eventually the EAP server (mutual
authentication). This draft proposes the use of these exchanges to
transport MIPv6 parameters, as part of an handshake that requires
at maximum 2 RTTs. Thus, the main requirement for the
applicability of the solution is:
- the EAP method must provide a way to carry arbitrary parameters
during or after the authentication phase. This implies that the
EAP method must provide messages and mechanisms for this
purpose.
Then, for security reasons, the EAP method must provide the
following properties:
- mutual authentication: the EAP method must provide mutual
authentication. The access network must authenticate users
before granting them Mobile IPv6 service and the EAP peer should
authenticate the access network before delivering sensitive
data;
- integrity: the exchanged MIPv6 parameters must be protected
against any alteration and thus the EAP method must provide
integrity protection;
- replay protection: the EAP messages containing MIPv6 parameters
must be protected against Replay Attack, so that an attacker is
not able to get previous given data by replaying an old request;
- confidentiality: depending on which data the AAA server provides
to the mobile node (e.g. an IKE pre-shared key), it may be
necessary to protect the message exchange against eavesdropping.
The table below checks some existing EAP methods against the
requirements listed above.
M-A: Mutual Authentication
R-P: Replay Protection
+---+----------+---+---------------+-------------+
| | | | | Exchange |
|M-A| Integrity|R-P|Confidentiality| of arbitrary|
| | | | | Parameters |
+------------+---+----------+---+---------------+-------------+
| PEAPv2 | x | x | x | x | x |
+------------+---+----------+---+---------------+-------------+
| EAP-FAST | x | x | x | x | x |
+------------+---+----------+---+---------------+-------------+
| EAP-TTLS | x | x | x | x | x |
+------------+---+----------+---+---------------+-------------+
Giaretta, et al. Expires - April 2007 [Page 9]
Internet-Draft MIPv6 Authorization based on EAP October 2006
| EAP-IKEv2 | x | x | x | x | x |
+------------+---+----------+---+---------------+-------------+
| EAP-SIM | x | x | x | x | x |
+------------+---+----------+---+---------------+-------------+
| EAP-AKA | x | x | x | x | x |
+------------+---+----------+---+---------------+-------------+
| EAP-TLS | x | x | x | x | |
+------------+---+----------+---+---------------+-------------+
| EAP-MD5 | | | | | |
+------------+---|----------|---|---------------|-------------|
In summary, it is possible to note that the procedure described in
this draft can be successfully undertaken with several tunneled
(PEAPv2, EAP-FAST and EAP-TTLS) and non tunneled EAP methods (EAP-
IKEv2, EAP-SIM, EAP-AKA), that all support the transport of
arbitrary parameters.
Giaretta, et al. Expires - April 2007 [Page 10]
Internet-Draft MIPv6 Authorization based on EAP October 2006
5. Detailed description of the Protocol
This section details the procedures and message exchanges that can
be adopted by the network operator to explicitly authorize the
activation of Mobile IPv6 support for a specific user as well as
enable dynamic bootstrapping of MIPv6 protocol parameters (e.g.
Home Address, Home Agent Address).
5.1 Mobile node bootstrapping
If EAP is used for access control, when the MN enters the network
it is immediately polled for its identity, by means of an EAP
Request Identity message. This message is used to start the EAP
communication. The MN replies sending its identity, in the form of
a NAI (Network Access Identifier), within an EAP Response Identity
message, that is received by a AAA client (e.g. the Access Point
in the case of a Wireless LAN) and forwarded via AAA routing to
the AAAH server using the Diameter EAP Application (or the RADIUS
EAP extensions). Then the AAAH server selects an EAP method (e.g.
based on the user service profile) and proposes it to the MN in
subsequent EAP messages. In order to enable the Mobile IPv6
negotiation procedure defined in this document, the EAP method
chosen by the AAAH server must be an EAP method supporting the
transport of general purpose and variable length information
elements, in the form of TLVs (or AVPs), together with
authentication data (see section 4).
After this initial handshake, MN and AAAH undertake the actual
authentication phase, that may require the exchange of a variable
number of EAP Request/Response messages. In many EAP methods, like
PEAPv2 or EAP-IKEv2, the authentication phase is preceded by the
establishment of an encrypted channel between MN and AAAH that
provides protection capabilities (i.e. privacy, integrity
protection, etc.) for all the messages exchanged during the rest
of the EAP conversation.
As soon as the authentication phase is completed, the procedure
for MIPv6 bootstrapping may take place. For that purpose, the MN
and the AAAH server exploit the on-going EAP communication to
exchange a sequence of signaling messages transporting
configuration parameters.
All the messages used for MIPv6 bootstrapping are encoded in TLVs
carried by a generic MIPv6-Authorization container. This choice
simplifies a lot the deployment of the procedure with any EAP
method satisfying the requirements listed in section 4. In fact,
only the structure of the MIPv6-Authorization container needs to
be adapted to the actual message format of the employed EAP
method.
For the sake of simplicity, in this section it is assumed that the
EAP method used for network access authentication supports the
transport of arbitrary parameters in TLV format. In this case the
MIPv6-Authorization container becomes a MIPv6-Authorization-TLV.
Nonetheless, in section 7 the format of the container is defined
for all the EAP methods identified in section 4.
The whole bootstrapping procedure is depicted in Figure 3.
AAAH
MN +----------------------------+ Server +----------------+ HA
<---------------------
MIPv6-Authorization-TLV(
Giaretta, et al. Expires - April 2007 [Page 11]
Internet-Draft MIPv6 Authorization based on EAP October 2006
Service-Status,
[Service-Options])
----------------------->
MIPv6-Authorization-TLV(
Service-Selection, [Service-Options],
[Home-Agent-Address], [Home-Address],
[Interface-Identifier],
[IKE-Authentication-Options])
+-+ +-+
| |/----------------\| |
| |\----------------/| |
+-+ +-+
Home Agent HA
Selection
Conf.
<---------------------
MIPv6-Authorization-TLV(
Home-Address, Home-Agent-Address,
IKE-Bootstrap-Information,
Authorization-Lifetime)
----------------------->
MIPv6-Authorization-TLV(
Negotiation-Result)
Figure 3 - MIPv6 bootstrapping procedure
AAAH starts the MIPv6 negotiation phase sending to the MN a MIPv6-
Authorization-TLV including the following TLVs:
- Service-Status-TLV: used to communicate whether the home domain
is willing to provide Mobile IPv6 service to the MN. This might
depend on the user service profile or on other administrative
rules (e.g. service accountability);
- Service-Options-TLV (optional): used to specify other service
options the MN can ask for (e.g. allocation of a HA in the
visited domain).
MN replies to this first message confirming its intention to start
Mobile IPv6 and, optionally, providing a set of hints on the
desired service capabilities; this is achieved delivering a MIPv6-
Authorization-TLV including the following TLVs:
- Service-Selection-TLV: used by the MN to specify if it is
willing to activate Mobile IPv6 protocol operation;
- Service-Options-TLV (optional): used by the MN to communicate
which service options, among those previously advertised by
AAAH, it would like make use of;
- Home-Agent-Address-TLV (optional): used by the MN to suggest a
preferred Home Agent. This can be a HA with whom the MN has a
pre-configured Security Association or a HA acquired through
dynamic HA address discovery. The AAAH server treats this
indication just as a hint, which means that, for administrative
reasons, the MN may be assigned a Home Agent different from the
one previously requested;
- Home-Address-TLV (optional): used by the MN to suggest a
preferred Home Address (e.g. an address pre-configured on one of
Giaretta, et al. Expires - April 2007 [Page 12]
Internet-Draft MIPv6 Authorization based on EAP October 2006
its network interfaces); like the previous TLV, this indication
is considered only as a hint by the AAAH server;
- Interface-Identifier-TLV (optional): through this TLV, the MN
can suggest a preferred Interface Identifier (selected according
to [RFC3041] or following other criteria) to be used by the AAA
infrastructure to build the Home Address starting from the
selected home prefix. Also in this case, this information, if
present, is treated as a pure hint by the AAAH server.
- IKE-Authentication-Options-TLV (optional): through this TLV, the
MN communicates to the AAAH server in order of preference the
peer authentication methods it supports for IKE bootstrapping.
The lack of this TLV means that the MN supports only the default
method.
The solution described in this document supports the following
methods for peer authentication in IKE phase 1:
- use of a pre-shared key (PSK) derived by the AAAH server and
sent to the MN and the HA; in this case confidentiality must be
provided by both the AAAH-HA protocol and the EAP session
between the MN and the AAAH server. This is the default method.
- use of a pre-shared key independently derived by the MN and the
AAAH server from the keying material exported by the employed
EAP method. This key can be derived from an Application Master
Session Key (AMSK) specific to Mobile IPv6, which can be
constructed as explained in [MIPv6AMSK]. The PSK is then
delivered by the AAAH server to the HA by means of a AAAH-HA
protocol providing confidentiality;
- use of digital certificates. This solution involves the
employment of digital signatures and public key encryption as
stated in [RFC2409]. This method requires the availability of a
PKI.
If in the Service-Selection-TLV the MN has chosen not to make use
of Mobile IPv6, AAAH terminates the EAP communication sending an
EAP Success message, since the authentication procedure has been
accomplished successfully.
Otherwise, if the MN has confirmed its willingness to start MIPv6
service, AAAH selects a suitable Home Agent through a Home Agent
Selection Algorithm. Possible parameters to be taken into account
by this algorithm include: current load of available HAs (e.g.
number of active bindings), location of the MN and, eventually,
the preferences provided by the MN itself in the previous message
exchange (i.e. Service-Options-TLV, Home-Agent-Address-TLV, Home-
Address-TLV, IKE-Authentication-Options-TLV). For example, based
on the knowledge of the MN's current point of attachment (i.e. the
current AAA client), the AAAH server may select, among the HAs
available in the home domain, the one that is closest to the MN in
terms of IP routing hops. This approach is normally expected to
improve performance. However, the detailed definition of a Home
Agent Selection Algorithm is out of the scope of this document.
After a suitable HA has been identified, the AAAH server selects
the peer authentication method to be used in IKE phase 1. The peer
authentication methods supported by the MN are known from the IKE-
Authentication-Options-TLV received during the previous exchange.
If possible, the AAAH server should choose the method on top of
the list provided by the MN (i.e. the one with the highest
preference).
Giaretta, et al. Expires - April 2007 [Page 13]
Internet-Draft MIPv6 Authorization based on EAP October 2006
As soon as the peer authentication method has been identified, the
AAAH server interacts with the HA to dynamically configure the
state needed to enable subsequent MIPv6 protocol operations,
including the authorization lifetime of the MIPv6 service granted
to the MN and the necessary security parameters (e.g. pre-shared
key). Possible protocols that can be used for this purpose include
Diameter (through a new Diameter Application), SNMPv3 or COPS-PR.
Further details about this communication are provided in section
6. Anyway, the detailed specification of the interface between
AAAH and HA is out of the scope of this document. Additional
considerations on the nature and goals of such an interface can be
found in [AAAMIP6] and [AAAMIPFWK].
The security parameters that the AAAH server delivers to the HA
may vary depending on the peer authentication method chosen for
IKE bootstrapping:
- if the AAAH server selects pre-shared key as peer authentication
method it needs to send the chosen PSK (randomly generated or
derived from the EAP key hierarchy) to the HA together with the
associated lifetime;
- if the AAAH server selects a peer authentication method based on
certificates it does not need to derive keys nor to send
security parameters to the HA.
After the AAAH server has configured the state on the HA, it
continues the EAP session communicating to the MN all the MIPv6
configuration data it is waiting for. This is achieved delivering
to the MN an EAP Request containing a MIPv6-Authorization-TLV and
the following sub-TLVs: Home-Address-TLV (i.e. the home address),
Home-Agent-Address-TLV (i.e. the address of the HA), IKE-
Bootstrap-Information-TLV (i.e. the peer authentication method to
be used in IKE phase 1 and associated cryptographic material) and
Authorization-Lifetime-TLV (i.e. the lifetime granted to the MN
for this session).
After the MN has received all the configuration data from the AAAH
server (i.e. HA address, Home Address and IKE bootstrap
information), it sends back an EAP Response containing a
Negotiation-Result-TLV, stating whether it accepts, or refuses,
the proposed arrangement. If the MN refuses the configuration, the
AAAH server should immediately release the resources previously
allocated on the Home Agent.
After the completion of the EAP session, MN holds all data needed
to perform Mobile IPv6 registration: the MN knows its Home
Address, the address of the correspondent Home Agent and all
cryptographic data needed to establish the IPsec security
association with it; furthermore, since it has been successfully
authenticated, the MN can acquire an IPv6 address to be used as
Care-of Address.
The first operation carried out by the MN after the acquisition of
the Care-of Address is the establishment of the IPsec Security
Association with the HA, that is mandated by [RFC3775] to protect
MIPv6 location update signaling. Set-up of the IPsec SA can be
accomplished following the procedure detailed in [RFC3776].
As soon as the IPsec Security Association is established, MN can
send a Binding Update to the HA, thus starting up Mobile IPv6
service.
Giaretta, et al. Expires - April 2007 [Page 14]
Internet-Draft MIPv6 Authorization based on EAP October 2006
5.2 Management of re-authentication events
At the expiration of AAA session time-outs or after a change in
the point of attachment to the network (e.g. change of Access
Point), a re-authentication procedure is performed leading to the
user identity to be checked again along with its right to continue
exploiting network resources. To that purpose the AAAH server may
repeat a full authentication or, alternatively, decide to use
optimizations in order to make the procedure faster. Once this
phase is completed the AAAH server also undertakes the re-
negotiation of the MIPv6 service.
Since the MIPv6 bootstrapping procedure is assumed to be
completely stateless, when a re-authentication event occurs the
AAAH server may not know the state of the MIPv6 service on the MN.
For this reason the AAAH server starts the MIPv6 negotiation like
in the bootstrapping case: it delivers a MIPv6-Authorization-TLV
containing a Service-Status-TLV and optionally a Service-Options-
TLV.
If the MIPv6 service is not active on the MN the procedure
continues as described in section 5.1. Otherwise, the MN replies
with a MIPv6-Authorization-TLV containing a Service-Selection-TLV
indicating that the MIPv6 service is already in use. Furthermore,
the MN inserts the Home-Agent-Address-TLV, the Home-Address-TLV
and the IKE-Authentication-Options-TLV to inform the AAAH server
about its current state. The AAAH server can then get in touch
with the HA to check the integrity of the state, renew the MIPv6
authorization lifetime and eventually refresh the security
parameters.
If the peer authentication method used by the MN in IKE phase 1 is
pre-shared key, the AAAH server must derive a new PSK and send it
to the HA together with the associated lifetime. In case the PSK
is not derived from the EAP key hierarchy (i.e. it is randomly
generated by the AAAH server), the AAAH server must communicate it
also to the MN. Instead, in case of authentication based on
certificates, the AAAH server does not need to derive keys nor
deliver additional security data to the HA and the MN.
If the state on the HA is successfully updated, the AAAH server
terminates the EAP communication sending an EAP Success message.
Otherwise, the AAAH server should continue the EAP communication
renegotiating the MIPv6 service (i.e. allocation of a new HA and
related Home Address).
This solution can be easily deployed even within a network
including several AAA servers, each one managing a subset of the
available Network Access Servers (NASs). This is because the re-
negotiation procedure does not assume to have any long term state
related to Mobile IPv6 stored on the AAAH server. In this way,
everything works correctly even if, due to MN's movements within
the network, the AAAH server that handles the re-authentication is
not the same server that authenticated the MN for the first time
and performed the MIPv6 bootstrapping procedure.
As explained above, the re-authentication events are normally
triggered by the network. Nonetheless, if the EAP lower layer
offers a way to trigger EAP re-authentications (e.g. PANA supports
this feature), it may be possible for the MN to re-negotiate the
MIPv6 service at any time.
Giaretta, et al. Expires - April 2007 [Page 15]
Internet-Draft MIPv6 Authorization based on EAP October 2006
6. Home Agent considerations
This section provides further thoughts about the AAAH-HA
communication and lists specific features that have to be
supported by the Home Agent to allow dynamic negotiation of Mobile
IPv6 protocol parameters.
6.1 Requirements on AAAH-HA communication
This draft details only the message exchange between the MN and
the AAAH server. Obviously a complete Mobile IPv6 bootstrapping
solution requires also the definition of a mechanism for the
communication between the AAAH server and the Home Agent. Possible
protocols that may be used for this purpose include SNMPv3, COPS-
PR or Diameter but a formal definition of such a protocol is out
of scope of this document.
A detailed analysis of the goals for a generic AAAH-HA protocol
can be found in [AAAMIP6]; in this section some requirements,
specific to this scenario, are highlighted.
The selected protocol should allow the AAAH server to:
- use a Network Access Identifier (NAI) to identify the mobile
node in the communication with the HA;
- send an authorization lifetime to the HA to limit Mobile IPv6
session duration for the MN;
- send to the HA a set of hints for the construction of the Home
Address (e.g. a preferred Home Address or a preferred Interface
Identifier);
- poll the designated HA for the allocation of a Home Address to
the MN;
- force the HA to terminate an active Mobile IPv6 session for
authorization policy reasons (e.g. credit exhaustion or
reallocation of a new HA to the MN);
- enforce explicit operational limitations and authorization
restrictions on the HA (e.g. packet filters, QoS parameters);
- retrieve the Mobile IPv6 state associated to a specific MN from
the correspondent HA. This may be useful to periodically verify
the Mobile IPv6 service status;
- send to the HA the security data needed to setup the IPsec SA
with the MN. Possible security data are the authentication
method and the cryptographic material to be used for IKE
bootstrapping.
Moreover, the protocol selected to implement the communication
between the AAAH server and the HA should fulfill the following
general requirements:
- the AAAH server and the HA must be able to authenticate each
other (mutual authentication) in order to prevent the
installation of unauthorized state on the HA;
- the AAA-HA interface must provide integrity protection in order
to prevent any alteration of exchanged data (e.g. Mobile IPv6
configuration parameters);
Giaretta, et al. Expires - April 2007 [Page 16]
Internet-Draft MIPv6 Authorization based on EAP October 2006
- the AAA-HA interface must provide replay protection;
- the AAA-HA interface should provide confidentiality since it may
be used to transfer security parameters (e.g. IKE pre-shared
key);
- the AAA-HA interface should support inactive peer detection.
This functionality can be used by the AAAH server to maintain a
list of active HAs (e.g. useful for HA selection);
6.2 Management of MIPv6 authorization state
The Home Agent is required to store some authorization data for
each of the MNs it is serving. A new data structure may be used
for this purpose and it should include at least the following
fields:
- NAI of the user;
- Home Address assigned to the MN;
- Cryptographic Data: this field includes the peer authentication
method to be used in IKE and, if needed, the pre-shared key and
its lifetime;
- Authorization Lifetime: it is the lifetime of the Mobile IPv6
service granted to the MN;
At the expiration of the Authorization Lifetime the HA should
check if there is an active entry for the MN in its Binding Cache
in order to verify if the MN is still using Mobile IPv6. If the
entry is available the Home Agent should negotiate with the AAAH
server an extension of the Authorization Lifetime granted to the
MN. Otherwise, the HA should immediately release the authorization
state associated to that MN and eventually notify the session
termination to the AAAH server (e.g. by means of a Session
Termination Request if the employed AAAH-HA protocol is Diameter).
Moreover, the release of the resources previously allocated on the
Home Agent can be undertaken at any time by the AAAH server.
Typically this happens at credit exhaustion or when the MN
disconnects from the network.
The policies adopted by the AAAH server to release the resources
allocated to the MN may vary depending on the user service
profile. For instance, the AAAH server may decide to postpone the
release of the resources on the HA in order to allow the MN to
continue using the Mobile IPv6 service even if it has moved to an
access network for which no roaming agreements are in place (e.g.
a corporate network or a network providing cost-free access). In
that case, the MN can continue to rely on the IPsec SA previously
negotiated with the HA and the respective authorization is managed
through the Mobile IPv6 Authorization Lifetime.
Giaretta, et al. Expires - April 2007 [Page 17]
Internet-Draft MIPv6 Authorization based on EAP October 2006
7. The MIPv6-Authorization container
All the messages used for MIPv6 bootstrapping are encoded in TLVs
carried by a generic MIPv6-Authorization container. In this way,
only the structure of the container needs to be adapted to the
actual message format of the employed EAP method.
The MIPv6-Authorization container can be implemented as a TLV, as
an AVP or in some other way depending on the specific
characteristics of the EAP method used for network access
authentication (see Figure 4).
+----------------------------------------------------------+
| MIPv6 bootstrapping TLVs (Sec. 8) |
+------+--------------+--------------+--------------+------+
| | | |
| | | |
+------+-----+ +------+-----+ +------+-----+ +------+------+
| MIPv6 | | MIPv6 | | MIPv6 | | MIPv6 |
| Auth. TLV | | Auth. TLV | | Auth. AVP | | Auth. IKEv2 |
| | | | | | | Payload |
| (Sec. 7.1) | | (Sec. 7.3) | | (Sec. 7.5) | | (sec. 7.6) |
+------------+ +------------+ +------------+ +-------------+
| PEAPv2 | | EAP-SIM | | EAP-TTLS | | EAP-IKEv2 |
| EAP-FAST | | EAP-AKA | | | | |
+------------+ +------------+ +------------+ +-------------+
Figure 4 - Transport of MIPv6 bootstrapping messages
In the following the format of the MIPv6-Authorization container
is defined for each EAP method identified in section 4. This list
is not exhaustive and does not prevent the use of other EAP
methods satisfying all the requirements listed in this document.
7.1 PEAPv2
The exchange of arbitrary information in PEAPv2 is based on EAP-
TLVs. In this case the MIPv6-Authorization container is encoded as
an EAP-TLV and has the structure depicted below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
|M|R| Type | Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
M
0 - Non-mandatory TLV
R
Reserved, set to zero (0)
Giaretta, et al. Expires - April 2007 [Page 18]
Internet-Draft MIPv6 Authorization based on EAP October 2006
Type
TBD - MIPv6-Authorization
Length
The length of the Value field in octets
Value
This field carries the subsequent TLVs
7.2 EAP-FAST
The format of the messages for EAP-FAST [EAP-FAST] is the same as
PEAPv2.
7.3 EAP-SIM
EAP-SIM [EAP-SIM] allows the transport of additional information
in form of TLVs. The format of the MIPv6-Authorization container
is depicted below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
Type
TBD MIPv6-Authorization
Length
Indicates the length of this attribute in multiples of four
bytes. The maximum length of an attribute is 1024 bytes. The
length includes the Type and Length bytes.
Value
This field carries the subsequent TLVs
7.4 EAP-AKA
The format of the messages for EAP-AKA [EAP-AKA] is the same as
EAP-SIM.
7.5 EAP-TTLS
EAP-TTLS messages [EAP-TTLS] allow the exchange of arbitrary data
in the form of AVPs encapsulated in the TLS record. The MIPv6-
Authorization container is encoded as depicted below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
Giaretta, et al. Expires - April 2007 [Page 19]
Internet-Draft MIPv6 Authorization based on EAP October 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| AVP Code
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
|V M r r r r r r| AVP Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Vendor ID (opt)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
AVP Code
TBD - MIPv6-Authorization
Flag 'V' (Vendor-Specific)
0
Flag 'M' (Mandatory)
0
Flag 'r' (reserved)
must be set to 0
AVP Length
the length of this AVP including the AVP Code, AVP
Length, flags, Vendor-ID (if present) and Data.
Data
this field carries subsequent TLVs
7.6 EAP-IKEv2
EAP-IKEv2 [EAP-IKEv2] allows the transport of generic data in the
form of IKEv2 payloads. The MIPv6-Authorization container is
encoded as depicted below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Next Payload |C| RESERVED | Payload Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Data
~
Giaretta, et al. Expires - April 2007 [Page 20]
Internet-Draft MIPv6 Authorization based on EAP October 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
Next Payload (1 octet)
TBD - MIPv6-Authorization
Critical (1 bit)
must be set to zero
RESERVED (7 bits)
must be sent as zero; must be ignored on receipt.
Payload Length (2 octets)
Length in octets of the current payload, including the
generic
payload header
Data
It contains subsequent TLVs
Giaretta, et al. Expires - April 2007 [Page 21]
Internet-Draft MIPv6 Authorization based on EAP October 2006
8. New TLVs
Independently from the EAP method used for network access
authentication, the MIPv6-Authorization container enables to
transport a series of TLVs. This gives more flexibility to the
whole solution and permits the definition of new TLVs that do not
need to be bound to a specific EAP method.
The following TLVs have been defined so far:
Service-Status-TLV
Service-Selection-TLV
Service-Options-TLV
Home-Agent-Address-TLV
Home-Address-TLV
IKE-Authentication-Options-TLV
IKE-Bootstrap-Information-TLV
Negotiation-Result-TLV
8.1 Service-Status-TLV
This TLV is sent by the AAAH to inform the MN about the status of
Mobile IPv6 service. It is defined as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Type=Service-Status | Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Code |
+-+-+-+-+-+-+-+-+
Type
TBD - Service-Status
Length
1
Code
0 = MIPv6 service is available
1 = MIPv6 service is not available
8.2 Service-Selection-TLV
This TLV is sent by the MN to inform the AAAH whether it wants to
activate MIPv6 service or whether the service is already active.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Type=Service-Selection | Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Code |
Giaretta, et al. Expires - April 2007 [Page 22]
Internet-Draft MIPv6 Authorization based on EAP October 2006
+-+-+-+-+-+-+-+-+
Type
TBD - Service-Selection
Length
1
Code
0 = activate MIPv6 service
1 = MIPv6 service already active
2 = do not activate MIPv6 service
8.3 Service-Options-TLV
This TLV is used by the AAAH server to advertise the service
options the MN can ask for. It is also used by the MN to
communicate its selection to the AAAH. So far only the HA in
visited domain option has been defined. The TLV has the following
format:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Type=Service-Options | Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
|V| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD - Service-Options
Length
2
V
from AAAH to MN:
0 = AAAH cannot provide a HA in the visited domain
1 = AAAH can provide a HA in the visited domain
from MN to AAAH:
0 = MN does not specify any preference on HA location
1 = MN is requesting a HA in the visited domain
Reserved
15 bit reserved set to 0
8.4 Home-Agent-Address-TLV
This TLV carries the Home Agents address and its defined as
follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
Giaretta, et al. Expires - April 2007 [Page 23]
Internet-Draft MIPv6 Authorization based on EAP October 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Type=HA-Address | Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
|
|
| Home Agent Address
|
|
|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
Type
TBD - Home-Agent-Address
Length
16
Value
Home Agent Address
8.5 Home-Address-TLV
This TLV carries the Home Address assigned to the MN. It is
defined as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Type=Home-Address | Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
|
|
| Home Address
|
|
|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
Type
TBD - Home-Address
Length
16
Giaretta, et al. Expires - April 2007 [Page 24]
Internet-Draft MIPv6 Authorization based on EAP October 2006
Value
Home Address
8.6 IKE-Authentication-Options-TLV
This TLV carries data related to IKE bootstrapping. If used during
the initial MIPv6 bootstrapping procedure, the value field
contains the list of peer authentication methods supported by the
MN. Otherwise, if used during re-authentication events, the value
field contains only the peer authentication method currently in
use.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
|Type=IKE-Authentication-Options| Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| AuthMethod-1 | AuthMethod-2 | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
Type
TBD - IKE-Authentication-Options
Length
Length of this TLV.
Value
AuthMethod code corresponding to the authentication method
supported for IKE phase 1. All the methods
supported by the MN are inserted in order of
preference. The following values are defined:
Authentication Method AuthMethod
PSK (pre-shared key generated by AAAH) 0
AMSK (pre-shared key derived from EAP) 1
CERT (use of certificates) 2
8.7 IKE-Bootstrap-Information-TLV
This TLV carries data related to the set-up of an IPsec Security
Association with the Home Agent. It contains the peer
authentication method to be used for IKE phase 1 and, eventually,
the related cryptographic material (e.g. pre-shared key).
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
Giaretta, et al. Expires - April 2007 [Page 25]
Internet-Draft MIPv6 Authorization based on EAP October 2006
|Type= IKE-Bootstrap-Information| Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| AuthMethod | key Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Key Lifetime
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Key Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
Type
TBD - IKE-Bootstrap-Information
Length
Length of this TLV.
Value
AuthMethod the authentication method to be used in IKE
phase 1. This field can assume a value among
those defined in section 8.6 (i.e. PSK, AMSK
or CERT).
Key Length the length of the key to be used as pre-shared
key
for IKE phase 1 authentication. This field must
be
present if AuthMethod is set to PSK and may be
present if AuthMethod is set to AMSK.
Key Lifetime - the lifetime of the key in seconds. A value
of
all ones means infinite. This field is
present
only if the AuthMethod field is set to PSK or
AMSK.
Key Value the value of the key. This field is present only
if
the AuthMethod field is set to PSK.
8.8 Negotiation-Result-TLV
It is defined as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Type=Negotiation-Result | Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Result-Code |
Giaretta, et al. Expires - April 2007 [Page 26]
Internet-Draft MIPv6 Authorization based on EAP October 2006
+-+-+-+-+-+-+-+-+
Type
TBD - Result
Length
1
Value
0 = Success
128 = Failure
8.9 Authorization-Lifetime-TLV
It is defined as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Type= Authorization-Lifetime | Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Authorization-Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD - Authorization-Lifetime
Length
2
Value
The lifetime granted to the MN (in seconds)
Giaretta, et al. Expires - April 2007 [Page 27]
Internet-Draft MIPv6 Authorization based on EAP October 2006
9. Security Considerations
The Mobile IPv6 bootstrapping procedure described in this document
assumes the MN and the AAA server of the home domain exchange the
necessary parameters exploiting the EAP communication established
for network access authentication. Therefore, to secure the
bootstrapping procedure, the employed EAP method must support
mutual authentication as well as integrity and replay protection.
Moreover, if the pre-shared key needed to bootstrap the IPsec SA
with the Home Agent is not derived from the EAP key hierarchy but
explicitly delivered to the MN by the AAAH server, the EAP method
must also provide confidentiality. Several tunneled and non
tunneled EAP methods, like PEAPv2 and EAP-IKEv2, fulfill all of
these security requirements.
Giaretta, et al. Expires - April 2007 [Page 28]
Internet-Draft MIPv6 Authorization based on EAP October 2006
10. References
10.1 Normative References
[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility
Support
in IPv6, RFC 3775, June 2004.
[RFC3776] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec
to
Protect Mobile IPv6 Signaling between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
[RFC3748] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[PEAPv2] Palekar, A. et al., "Protected EAP Protocol (PEAP)
Version 2", draft-josefsson-pppext-eap-tls-eap-11
(work
in progress), September 2005.
[EAPKEYFWK] Aboba, B., Simon, D., Arkko, J., Levkowetz, H.,
"Extensible Authentication Protocol (EAP) Key
Management
Framework", draft-ietf-eap-keying-14 (work in
progress),
June 2006.
[MIPv6AMSK] Giaretta, G., Guardini, I., Demaria, E., Bournelle,
J., Laurent-Maknavicius, M., "Application Master
Session
Key (AMSK) for Mobile IPv6", draft-giaretta-mip6-amsk-
02
(work in progress), October 2006
10.2 Informative References
[RFC4640] Patel, A., Giaretta, G., "Problem Statement for
bootstrapping Mobile IPv6 (MIPv6), RFC 4640,
September 2006.
[RFC3753] Manner, J., Kojo, M. "Mobility Related Terminology,
RFC
3753, June 2004.
[RFC3041] Narten, T., Draves, R., "Privacy Extensions for
Stateless
Address Autoconfiguration in IPv6", RFC 3041, January
2001.
[AAAMIP6] Giaretta, G., Guardini, I., Demaria, E., Bournelle,
J.,
Lopez, R., "AAA Goals for Mobile IPv6", draft-ietf-
mip6-aaa-ha-goals-03 (work in progress), September
2006
[AAAMIPFWK] Yegin, A., "AAA Mobile IPv6 Application Framework",
draft-yegin-mip6-aaa-fwk-01 (expired), February
2005
Giaretta, et al. Expires - April 2007 [Page 29]
Internet-Draft MIPv6 Authorization based on EAP October 2006
[RFC3084] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie,
F.
Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS
Usage for Policy Provisioning,", RFC 3084, March 2001.
[MIPv6APP] Faccin, S., Perkins, C., Le, F., Patil, B., "Diameter
Mobile IPv6 Application", draft-le-aaa-diameter-
mobileipv6-04 (expired), November 2004.
[PANA] Forsberg, D. et al., "Protocol for Carrying
Authentication for Network Access (PANA)", draft-ietf-
pana-pana-12 (work in progress), August 2006.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for
Internet-
Standard Management Framework", RFC 3410, December
2002.
[EAP-TTLS] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS
Authentication Protocol (EAP-TTLS)", draft-ietf-
pppext-
eap-ttls-05 (expired), July 2004.
[EAP-IKEv2] Tschofenig, H., Kroeselberg, D., Ohba, Y., "EAP
IKEv2 Method", draft-tschofenig-eap-ikev2-11 (work in
progress), June 2006.
[EAP-SIM] Haverinen, H. and J. Salowey, "Extensible
Authentication
Protocol Method for GSM Subscriber Identity Modules
(EAP-
SIM)", RFC 4186, January 2006.
[EAP-AKA] Arkko, J. and H. Haverinen, "EAP-AKA Authentication",
RFC 4187, January 2006.
[EAP-FAST] N.Cam-Winget, D. McGrew, J. Salowey, H.Zhou, "The
Flexible Authentication via Secure Tunneling
Extensible
Authentication Protocol Method (EAP-FAST)", draft-cam-
winget-eap-fast-05.txt (work in progress), October
2006.
Giaretta, et al. Expires - April 2007 [Page 30]
Internet-Draft MIPv6 Authorization based on EAP October 2006
Acknowledgments
The authors would like to thank Simone Ruffino, Tom Hiller, Hannes
Tschofening, Rafael Marin Lopez, Hiroyuki Ohnishi, Mayumi
Yanagiya, James Kempf and Yoshihiro Ohba for their valuable
comments.
Authors Addresses
Gerardo Giaretta
Telecom Italia Lab
via G. Reiss Romoli, 274
10148 TORINO
Italy
Phone: +39 011 2286904
Email: gerardo.giaretta@telecomitalia.it
Ivano Guardini
Telecom Italia Lab
via G. Reiss Romoli, 274
10148 TORINO
Italy
Phone: +39 011 2285424
Email: ivano.guardini@telecomitalia.it
Elena Demaria
Telecom Italia Lab
via G. Reiss Romoli, 274
10148 TORINO
Italy
Phone: +39 011 2285403
Email: elena.demaria@telecomitalia.it
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
Giaretta, et al. Expires - April 2007 [Page 31]
Internet-Draft MIPv6 Authorization based on EAP October 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Giaretta, et al. Expires - April 2007 [Page 32]