MIP6 Working Group G. Giaretta
Internet Draft I. Guardini
Expires: August 2004 E. Demaria
TILab
February 2004
MIPv6 Authorization and Configuration based on EAP
<draft-giaretta-mip6-authorization-eap-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This draft defines an architecture, and related protocols, for
performing dynamic Mobile IPv6 authorization and configuration
relaying 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 just as a
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.
The same approach can be ported also to environments performing user
authentication with methods other than EAP (e.g. GSM, UMTS or CDMA),
by simply using PANA with null authentication to undertake MIPv6
negotiation after the user has gained IP access to the network.
Giaretta Guardini Demaria Expires - August 2004 [Page 1]
Internet-Draft MIPv6 Authorization based on EAP January 2004
Table of Contents
1. Introduction................................................2
2. Protocol Overview...........................................3
3. Detailed Description of the Protocol........................6
3.1 Mobile Node bootstrap....................................7
3.2 Management of reauthentication events...................15
3.3 Session Termination.....................................16
4. Home Agent considerations..................................19
4.1 Service Authorization Cache (SAC).......................19
4.2 Management of Binding Cache entries.....................19
5. Protocol Applicability in Cellular Networks................20
6. New Messages and Attributes................................24
6.1 New EAP-TLVs............................................24
6.2 New Diameter messages and AVPs..........................29
7. Open Issues................................................31
8. Security Considerations....................................32
Acknowledgments.................................................32
References......................................................32
Appendix A - Home Agent allocation in a foreign domain..........34
Authors' Addresses..............................................37
Intellectual Property Statement.................................37
1. Introduction
Mobile IPv6 [1] requires that Mobile Nodes (MNs) and Home Agents
(HAs) share a set of configuration parameters: for example, 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
Giaretta Guardini Demaria Expires - August 2004 [Page 2]
Internet-Draft MIPv6 Authorization based on EAP January 2004
and resource utilization (e.g. assignment of the HA closest to the
MN's point of attachment).
With the objective to solve the limitations described above, this
draft defines an architecture, and related protocols, for performing
dynamic Mobile IPv6 authorization and configuration relaying 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, and in particular
PEAPv2 [2], to convey generic information items together with
authentication data.
The suggested approach can be deployed, with no changes to existing
access equipment (Access Points, Access Gateways, etc.), in any
network supporting EAP-based authentication (e.g. IEEE 802.1x
Wireless LANs), but can be ported also to environments performing
user authentication with methods other than EAP (e.g. GSM, UMTS or
CDMA), by simply using PANA [9] with null authentication to undertake
MIPv6 negotiation after the user has gained IP access to the network.
2. Protocol Overview
The basic idea behind the solution proposed herewith is to perform
Mobile IPv6 authorization and configuration 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 on both the
Home Agent and 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 Acknowledges);
- allow the MN to negotiate additional Mobile IPv6 service options,
such as the possibility to use multiple access networks at the
same time (i.e. registration of multiple Care-of Addresses), the
assignment of a HA within the visited domain, etc.
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.
Giaretta Guardini Demaria Expires - August 2004 [Page 3]
Internet-Draft MIPv6 Authorization based on EAP January 2004
AAA
Client
IEEE 802.1x +------+ RADIUS
or PANA | | or Diameter
+--------+ /---------------TLS Tunnel------------------\ +--------+
| Mobile |/ <------------Authentication---------------> \| AAAH |
| Node |\ <--MIPv6 authorization and configuration--> /| Server |
+--------+ \-------------------------------------------/ +--------+
| | /\
+------+ /||\
Router ||
or AP Diameter ||
(pass-through) HA Appl. ||
\||/
\/
+--------+
| Home |
| Agent |
+--------+
Figure 1 - Solution architecture
The solution can be deployed in any access network where EAP [3] and,
in particular, PEAPv2 [2] are used to perform user authentication;
this is because the messages exchanged between the MN and the AAAH
server to achieve dynamic Mobile IPv6 authorization and configuration
are carried in EAP-TLVs (i.e. information fields in the form of Type
Length Value) delivered within the TLS tunnel created in the phase 1
of PEAPv2. Anyway, the same approach could be ported to any other EAP
method having the capability to establish a secure tunnel between the
MN and the AAAH server (e.g. EAP-TTLS [4]).
Figure 2 shows an overview of the procedure defined to handle MIPv6
bootstrap on the Mobile Node. The whole procedure can be divided in
five steps:
1.EAP identity exchange (i.e. exchange of EAP Request Identity and
EAP Response Identity messages);
2.PEAPv2 Phase 1: MN and AAAH establish a TLS tunnel to protect
subsequent authentication data. This phase is completely
conformant to [2];
3.PEAPv2 Phase 2: MN and AAAH negotiate an EAP method (e.g. EAP-MD5,
EAP-SIM, EAP-AKA) and undertake the authentication phase. Then,
within the TLS tunnel, MN and AAAH exchange a sequence of EAP-TLVs
to authorize and configure Mobile IPv6. During this phase, AAAH
selects a suitable Home Agent for the MN and exchanges
Giaretta Guardini Demaria Expires - August 2004 [Page 4]
Internet-Draft MIPv6 Authorization based on EAP January 2004
authorization and configuration data with it using a new Diameter
Application. At the end of this phase, the MN knows its own Home
Address, the address of the correspondent Home Agent and the
cryptographic material (e.g. pre-shared key) needed to set-up an
IPsec security association with IKE;
4.EAP session termination (EAP Success/Failure);
5.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.
stateless autoconfiguration); then, using the cryptographic
material collected in PEAPv2 phase 2, it performs an IKE exchange
to establish the IPsec Security Association with the HA. Finally,
the MN performs MIPv6 registration, sending a Binding Update
(protected with IPsec) to the HA.
EAP over
IEEE 802.1x EAP over Diameter Diameter
(or PANA) (or RADIUS) AAAH HA Application
MN +----------+ AP +-----------------+ Server +-----------------+ HA
1) <--Req. Id.---
--Identity---> --Diameter EAP Req.-->
/----------------------------------\
2) / PEAPv2 Phase 1: \
\ set-up of TLS tunnel /
\----------------------------------/
/----------------------------------\ +-+ /------------------\ +-+
3) / PEAPv2 Phase 2: authentication \| |/ Home Address \| |
\ and Mobile IPv6 negotiation /| |\ Selection /| |
\----------------------------------/ +-+ \------------------/ +-+
Home Agent DAD
Selection
4) <-----EAP----- <-----Diameter EAP----
Success/Failure Answer (Success/Failure
and authorization AVPs)
/-----------------------------------------------------------\
5) / Set-up Security Association MN-HA and \
\ Mobile IPv6 registration (BU, BA) /
\-----------------------------------------------------------/
Figure 2 - Overview of Mobile IPv6 bootstrap procedure
This draft also defines the procedures to handle re-authentication
events and to manage the termination of the Mobile IPv6 session.
Giaretta Guardini Demaria Expires - August 2004 [Page 5]
Internet-Draft MIPv6 Authorization based on EAP January 2004
In summary, the proposed architecture has the following advantages:
- allows the operator 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 user's 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 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 the arrangement
described herein in existing communication networks, where support
for Diameter protocol in access equipment is not so extensive.
Conversely, the drawback of the solution is the high number of RTTs
needed for the completion of the entire procedure. This limitation is
mainly due to the choice of relaying on a tunneled EAP method (such
as PEAPv2) for exchanging protected signaling related to MIPv6 during
the authentication phase. Nevertheless, it should be noted that the
full procedure can be undertaken by the MN only during its initial
bootstrap, and therefore the performance requirements are not so
strict.
3. Detailed Description of the Protocol
This section details all the procedures and message exchanges that
can be used by the network operator to explicitly authorize the
activation of Mobile IPv6 support for a specific user as well as
enable dynamic negotiation of MIPv6 protocol parameters (e.g. Home
Address, Home Agent Address).
Giaretta Guardini Demaria Expires - August 2004 [Page 6]
Internet-Draft MIPv6 Authorization based on EAP January 2004
For the sake of simplicity, protocol description is carried out
assuming that the access network is a Wireless LAN IEEE 802.11 where
user authentication is performed at Layer 2 through IEEE 802.1x and
EAP. However, the same approach can be deployed in any other network
using EAP for access control.
3.1 Mobile Node bootstrap
In a WLAN where IEEE 802.1x and EAP are used for access control, when
the MN enters the network it immediately receives 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 local attendant (i.e. the Access Point
in the case of a WLAN) and forwarded to AAAH 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 use the
MIPv6 negotiation procedure defined in this document, the EAP method
chosen by the AAAH server must be PEAPv2 or another tunneled EAP
method supporting the transport of optional information fields.
After this initial handshake, MN and AAAH establish a TLS tunnel
exchanging PEAPv2 phase 1 messages. The procedure is the same
specified in [2] and the Access Point acts as a simple pass-through
for all the signaling transferred, on an end-to-end basis, between
the MN and the AAA server.
As soon as the TLS tunnel is established, the actual authentication
phase takes place and all messages exchanged between MN and AAAH are
encrypted through the TLS Security Association. The authentication
can be based on any EAP method (e.g. EAP-MD5, EAP-SIM, EAP-AKA): the
choice can be done based on the desired security level and keeping in
mind that the EAP method affects the number of RTTs needed to
accomplish the authentication.
The authentication procedure performed within the TLS tunnel (i.e.
inner authentication) can be divided in three main steps:
1.Identity Exchange: exchange of EAP Identity Request/Reply
messages;
2.Authentication Algorithm: this is the real authentication
procedure. The number of round trips (RTTs) needed to complete
this phase depends on the EAP method chosen to perform inner
authentication;
Giaretta Guardini Demaria Expires - August 2004 [Page 7]
Internet-Draft MIPv6 Authorization based on EAP January 2004
3.Authentication Result: in the last round trip, AAAH sends to the
MN the result of the authentication procedure (success/failure)
and the MN confirms the reception of this notification.
PEAPv2 phase 2 messages exchanged within the TLS tunnel are conveyed
in EAP-TLVs, according to the latest version of PEAPv2 specification.
As soon as the authentication phase is completed (i.e. MN has
received an EAP Response message containing an Intermediate-Result-
TLV), the procedure for Mobile IPv6 authorization and parameter
negotiation takes place. This is achieved exploiting the TLS tunnel
to exchange a sequence of EAP messages containing a new TLV, called
MIPv6-Authorization-TLV (see section 6.1), that is a very generic TLV
containing other, more specific, TLVs.
AAAH starts the MIPv6 negotiation phase sending to the MN a MIPv6-
Authorization-TLV including the following TLVs:
- Service-Status-TLV: used to communicate to the MN whether the
Mobile IPv6 service is actually available, or unavailable, in the
visited location; this might depend on characteristics of the
visited domain, 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 (possibility to register multiple CoAs,
allocation of a HA in the visited domain, etc.). See Appendix A
for an example.
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 (e.g. a HA with whom the MN has a pre-
configured Security Association). 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;
Giaretta Guardini Demaria Expires - August 2004 [Page 8]
Internet-Draft MIPv6 Authorization based on EAP January 2004
- Home-Address-TLV (optional): used by the MN to suggest a preferred
Home Address (e.g. an address pre-configured on one of its network
interfaces); like the previous TLV, this indication is considered
only as a hint by the AAAH;
- Interface-Identifier-TLV (optional): through this TLV, the MN can
suggest a preferred Interface Identifier (selected according to
[5] 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 AAAH.
The whole message exchange is depicted in Figure 3. For the sake of
simplicity, the diagram shows only the content of the EAP-TLVs
exchanged within the TLS tunnel in place between the MN and AAAH
server.
PEAPv2 Diameter
TLS Tunnel AAAH HA Application
MN +----------------------------+ Server +---------------------+ HA
<---------------------
EAP-TLV(MIPv6-Authorization-TLV(
Service-Status, [Service-Options]))
----------------------->
EAP-TLV(MIPv6-Authorization-TLV(
Service-Selection, [Service-Options],
[Home-Agent-Address], [Home-Address],
[Interface-Identifier]))
Figure 3 - Mobile IPv6 authorization: initial handshake
If in the Service-Selection-TLV the MN has chosen not to make use of
Mobile IPv6, AAAH immediately terminates the EAP communication
skipping any further MIPv6 negotiation.
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, 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). However, the detailed definition of a
Home Agent Selection Algorithm is out of the scope of this document.
As soon as a suitable HA has been identified, AAAH interacts with it
to dynamically configure all the state needed to enable subsequent
Giaretta Guardini Demaria Expires - August 2004 [Page 9]
Internet-Draft MIPv6 Authorization based on EAP January 2004
MIPv6 protocol operations. The communication between AAAH and HA is
achieved through a new Diameter Application defined in this document,
that is called Diameter Home Agent Application and is similar to the
one specified in [6].
AAAH starts the handshake sending to the designated HA a Diameter
Home Address Request (HAR) message containing the following AVPs:
- User-Name-AVP: specifies the MN's identity, that is the NAI
provided by the user while executing the inner EAP method;
- Home-Address-AVP or Interface-Identifier-AVP (optional): specify
the Home Address, or the Interface Identifier, provided by the MN
in the correspondent TLVs (i.e. Home-Address-TLV and Interface-
Identifier-TLV);
- HA-Features-AVP (optional): lists the additional features that the
HA is required to provide to the mobile node (e.g. support for the
registration of multiple CoAs). The content of this AVP is set by
the AAAH server based on the negotiation undertaken with the MN
through the Service-Options-TLV.
When the HA receives the message, it picks up a Home Address for the
MN, generating an Interface Identifier based on [5] or using the
hints included in the Home-Address-AVP (or in the Interface-
Identifier-AVP). Then the HA undertakes the Duplicate Address
Detection (DAD) procedure to verify the uniqueness of the selected
Home Address.
If DAD fails (i.e. an address duplication is detected on the home
link), the HA selects another Home Address for the MN and repeats the
whole DAD procedure. If this operation fails for three times in a
row, the Home Agent sends to the AAAH a Diameter Home Address Answer
(HAA) message with Result-Code equal to FAILURE. At this stage, AAAH
can try to assign another HA or close the negotiation sending to the
MN a Service-Status-TLV stating that the Mobile IPv6 service is not
active and not available (see section 6.1).
If DAD is completed successfully, the HA uses proxy Neighbor
Discovery to defend the Home Address on the home link but does not
begin to intercept data packets addressed to it until a valid Binding
Update (BU) is received from the MN (see section 4). Then the HA
replies to AAAH delivering a Diameter Home Address Answer (HAA)
containing the following AVPs:
- User-Name-AVP: as usual it includes the NAI of the MN;
- Home-Address-AVP: specifies the Home Address that the Home Agent
has allocated to the MN.
Giaretta Guardini Demaria Expires - August 2004 [Page 10]
Internet-Draft MIPv6 Authorization based on EAP January 2004
Figure 4 depicts the exchange of HAR and HAA messages in the case the
Home Address selection procedure carried out by the HA terminates
without errors.
PEAPv2 Diameter
TLS Tunnel AAAH HA Application
MN +----------------------------+ Server +---------------------+ HA
+-+
|O|
+-+
Home Agent
Selection
---------------------->
Home-Address-Request(
User-Name, [HA-Features],
[Home-Address], [Interface-ID])
<-----------------------
Home-Address-Answer(
User-Name, Home-Address)
Figure 4 - Mobile IPv6 authorization: Home Address selection
AAAH also acts as Key Distribution Center, delivering to MN and HA
the cryptographic data needed to bootstrap the IPsec Security
Association for protecting subsequent Mobile IPv6 signaling. For this
reason, after the reception of the designated Home Address from the
HA, AAAH continues the handshake sending to the HA a Diameter Home
Agent Configuration Request (HACR) message containing the following
AVPs:
- User-Name-AVP: the NAI of the MN;
- Authorization-Lifetime-AVP: it is the authorization lifetime (in
seconds) of the Mobile IPv6 service granted to the MN;
- IKE-Bootstrap-Information-AVP: this AVP specifies the peer
authentication method to be used for IKE phase 1 (Pre-Shared key,
certificates, etc.) and the related parameters (e.g. value of the
pre-shared key and its lifetime). This is all the information the
HA needs to negotiate the IPsec Security Association with the MN.
This draft specifies in detail only the approach based on a Pre-
shared Key (PSK);
Giaretta Guardini Demaria Expires - August 2004 [Page 11]
Internet-Draft MIPv6 Authorization based on EAP January 2004
- Policy-AVP (optional): contains some filtering rules (e.g. access
lists) to be enforced by the HA on the traffic the MN transmits
and/or receives in bi-directional tunneling.
Once the HA has stored these data in its Service Authorization Cache
(see section 4.1), it sends to AAAH a Diameter Home Agent
Configuration Answer (HACA) containing a Result-Code-AVP used to
confirm the success (or failure) of the procedure (see Figure 5).
PEAPv2 Diameter
TLS Tunnel AAA HA Application
MN +---------------------------+ Server +----------------------+ HA
+-+
|O|
+-+
IKE Configuration
Selection
----------------------->
HA-Configuration-Request(
User-Name, Auth. Lifetime,
IKE-Bootstrap-Info, [Policy])
<-----------------------
HA-Configuration-Answer(
User-Name, Result-Code)
Figure 5 - Mobile IPv6 authorization: HA configuration
At this stage, the HA is ready to accept future MIPv6 registrations
coming from the MN. Therefore, AAAH can restart the EAP session with
the MN communicating to it all the MIPv6 configuration data it is
waiting for. This is achieved delivering to the MN an EAP Request
containing a MIPv6-Authorization-TLV including the following 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
information needed to bootstrap the IKE session with the HA).
As soon as it receives this message, the MN stores all the
configuration data and sends back an EAP Reply containing a
Negotiation-Result-TLV, stating whether it accepts, or refuses, the
proposed configuration (see Figure 6). If the MN refuses the
configuration, AAAH should immediately release the resources
previously allocated on the HA. To complete this task, AAAH sends a
Diameter Abort Session Request (ASR) message to the Home Agent (see
paragraph 3.3).
Giaretta Guardini Demaria Expires - August 2004 [Page 12]
Internet-Draft MIPv6 Authorization based on EAP January 2004
PEAPv2 Diameter
TLS Tunnel AAAH HA Application
MN +----------------------------+ Server +---------------------+ HA
<---------------------
EAP-TLV(Result-TLV,
Crypto-Binding-TLV,
MIPv6-Authorization-TLV(
Home-Address, HA-Address,
IKE-Bootstrap-Info))
----------------------->
EAP-TLV(Result-TLV,
Crypto-Binding-TLV,
MIPv6-Authorization-TLV(
Negotiation-Result))
Figure 6 - Mobile IPv6 authorization: MN configuration
To terminate the EAP session, AAAH sends to the Access Point a
Diameter EAP Answer message with Result-Code equal to SUCCESS and,
optionally, other authorization AVPs containing some filtering rules
to be enforced on MN's traffic (see Figure 7).
EAP Over EAP over Diameter
802.1x Diameter AAA HA Application
MN +---------+ AP +------------+ Server +----------------------+ HA
<-------------------
Diameter-EAP-Answer(
Result-Code-AVP(Success),
EAP-Payload-AVP(EAP-Success),
[Authorization AVPs])
+-+
|O| Enforcement of
+-+ authorization rules
<-------------
EAP-Success
Figure 7 - Termination of the EAP session
After the completion of the EAP session, MN holds all data needed to
perform Mobile IPv6 registrations: the MN knows its Home Address, the
address of the correspondent Home Agent and all cryptographic
material needed to establish the IPsec security association with it;
furthermore, since it has been successfully authenticated, the MN is
receiving Router Advertisements on the visited subnet and can build
its Care-of Address through IPv6 stateless autoconfiguration.
Giaretta Guardini Demaria Expires - August 2004 [Page 13]
Internet-Draft MIPv6 Authorization based on EAP January 2004
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 [1] to protect MIPv6
location update signaling. Set-up of the IPsec SA can be accomplished
following the procedure detailed in [7]. In this regard, it is
important to note that:
- if the mutual authentication in IKE Phase 1 is based on a Pre-
Shared Key (PSK), Aggressive Mode must be used. This is because
Aggressive Mode is the only way to use PSK authentication with a
NAI as peer identifier [8]. Indeed, the NAI of the MN is the only
identity information stored in the Service Authorization Cache of
the HA;
- in IKE phase 1 messages, the source address used by the MN has to
be the Care-of Address, as described in [7]; the Home Address is
used only in IKE phase 2;
- in IKE phase 2 (Quick Mode), while still using the CoA as source
address of IKE messages, the MN has to use the Home Address as its
peer identifier, so that the HA can correctly set the MN entries
in its Security Policy Database (SPD) and in the Security
Association Database (SAD).
As soon as the IPsec Security Association is established, MN can send
a Binding Update to the HA, thus starting up Mobile IPv6 service
(Figure 8).
AAA
MN +--------+ AP +--------------+ Server +---------------------+ HA
/------------------------------------------------------------\
/ IKE Phase 1 \
\ Aggressive Mode (2 RTT) /
\------------------------------------------------------------/
/------------------------------------------------------------\
/ IKE Phase 2 \
\ Quick Mode (1 + 1/2 RTT) /
\------------------------------------------------------------/
-------------------------------------------------->
MIPv6 Binding Update
<--------------------------------------------------
MIPv6 Binding Acknowledge
Figure 8 - IKE Negotiation and MIPv6 Registration
Giaretta Guardini Demaria Expires - August 2004 [Page 14]
Internet-Draft MIPv6 Authorization based on EAP January 2004
Considering the usage of an inner EAP method involving 2 round trips
(e.g. EAP-AKA), the bootstrap procedure described in the foregoing
requires a total of 13.5 round trips (RTTs) to be completed: 9 RTTs
for authentication and Mobile IPv6 negotiation, 3.5 RTTs for setting
up the IPsec SA (i.e. IKE) and 1 RTT for MIPv6 registration (i.e. BU,
BA). However, since the whole procedure may be performed only at the
MN bootstrap (e.g. when the terminal is switched on), the time
requirements are not critical.
Nonetheless, a number of optimization steps can be introduced in
order to make the whole procedure faster. The PEAPv2 protocol
provides for several tasks to be performed simultaneously by
conveying the correspondent message exchanges in different TLV types,
all delivered through the TLS tunnel in place between MN and AAAH.
Exploiting this feature, the negotiation procedure for the MIPv6
service can be performed in partial or complete superposition with
the authentication procedure. This optimization leads to saving 2
round trips. Additionally, the time for the HA to complete the DAD
procedure may be partially or totally absorbed within the
authentication procedure.
3.2 Management of reauthentication events
At the expiration of AAA session time-outs or after a change in the
point of attachment to the network (involving or not involving an IP
handoff), a re-authentication procedure is performed leading to the
user identity to be checked again along with its right to continue
exploitation of 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 AAA server also undertakes the re-negotiation of the
Mobile IPv6 service, communicating with the MN through the TLS
tunnels established in PEAPv2 phase 1. The actual protocol behavior
and message exchange may vary depending on the service state of the
mobile node.
If the MIPv6 service is not currently active for the MN, AAAH behaves
exactly as in the bootstrap phase (see section 3.1) and proposes the
activation of the service from scratch as if the MN was performing
its first authentication within the visited network.
Instead, if the MIPv6 service is already active, AAAH informs the MN
about the current MIPv6 service status, including the respective
service options negotiated during the bootstrap phase. AAAH performs
this operation delivering a MIPv6-Authorization-TLV including the
Service-Status-TLV and the Service-Options-TLV. The mobile node may
respond in two different ways:
Giaretta Guardini Demaria Expires - August 2004 [Page 15]
Internet-Draft MIPv6 Authorization based on EAP January 2004
- by means of a Negotiation-Result-TLV with result code equal to
SUCCESS, to indicate that the service configuration is wished to
be maintained unchanged,
- or by means of a MIPv6-Authorization-TLV with the desired
modifications (including the eventual request to stop the MIPv6
service), to undertake the full or partial re-negotiation of the
MIPv6 service.
As a whole, the described re-authentication procedure takes 10 round
trips, assuming that the employed EAP method requires 2 round trips
(e.g. EAP-AKA) and the Mobile Node has undertaken an IP handoff
without asking for any change in the service configuration.
Consequently, 3.5 round trips are saved in comparison with the
bootstrap phase, in that the MN already shares an IPsec Security
Association with the HA and therefore does not need to repeat the IKE
negotiation.
The delay involved in completing the re-authentication procedure may
be reduced by resorting to the optimization steps already described
in the foregoing with reference to the bootstrap phase and, possibly,
by exploiting some additional optimizations supported by the PEAPv2
protocol: fast resume of the TLS tunnel and fast reconnect.
3.3 Session Termination
Session termination may be triggered by the AAA server or the mobile
node. The result is normally the disconnection of the user from the
visited network, and, consequently, the release of Mobile IPv6
service and related resources (Home Agent, Home Address, etc.).
The AAA server may decide to close the session at any moment, for
instance due to credit exhaustion. In general, to interrupt the
service, the AAA server delivers to the correspondent AAA client a
Diameter Abort Session Request (ASR) message; the AAA client
disconnects the user, releases the resources previously allocated to
it and confirms the session termination through a Diameter Abort
Session Answer (ASA) message. If a plurality of clients are involved
in the service provision, the ASR message is sent to all of them. In
the specific case of the Mobile IPv6 service, the two Diameter
clients involved are the HA and the equipment that is providing
access to the network (i.e. the Access Point in case of a Wireless
LAN), therefore both receive an ASR message from AAAH (see Figure 9)
and enforce immediate user disconnection.
Giaretta Guardini Demaria Expires - August 2004 [Page 16]
Internet-Draft MIPv6 Authorization based on EAP January 2004
Diameter
AAA HA Application
MN +--------+ AP +-------------+ Server +----------------------+ HA
<-------------------
Diameter-Abort-Session-Request(
User-Name-AVP)
-------------------->
Diameter-Abort-Session-Request(
User-Name-AVP)
------------------>
Diameter-Abort-Session-Answer(
Result-Code-AVP)
<------------------------
Diameter-Abort-Session-Answer(
Result-Code-AVP)
Figure 9 - MIPv6 service termination triggered by AAAH
In the case the MN wishes to disconnect, it sends an EAPOL-Logoff
message toward the Access Point which in turn communicates the end of
the session to the AAA server via the Diameter Session Termination
Request (STR) message, while simultaneously releasing the resources
involved. At the reception of the STR message, the AAA server
releases the resources allocated on the HA exchanging Abort Session
Request and Answer messages with it, while sending a corresponding
Diameter Session Termination Answer message toward the AP.
The AAA server may possibly decide to adopt different policies for
releasing the resources (e.g. depending the user service profile).
For instance, the AAA server may decide not to release the resources
on the HA in order to allow the MN to exploit the Mobile IPv6 service
even when it moves to network for which no roaming agreements exist
(e.g. a corporate network or a network providing free and cost-free
access). In that case, the MN can continue to use the IPsec SA
previously negotiated with the HA and respective authorization is
managed by means of the MIPv6 Authorization Lifetime (see Diameter
HACR message). Once this lifetime expires (but it may even be
infinite), the HA should send a Diameter Authorization Refresh
Request message to the AAAH server asking for a confirmation of the
authorization (see Figure 10).
Giaretta Guardini Demaria Expires - August 2004 [Page 17]
Internet-Draft MIPv6 Authorization based on EAP January 2004
Diameter
AAA HA Application
MN +--------+ AP +-------------+ Server +----------------------+ HA
+-+
|O|
+-+
Authorization
Lifetime Expiration
<-------------------
Diameter-Authorization-
Refresh-Request(User-
Name-AVP)
-------------------->
Diameter-Authorization-
Refresh-Answer(User-Name-AVP,
Result-Code-AVP,
[Authorization-Lifetime-AVP])
Figure 10 - Diameter Authorization Refresh Request/Answer
In some circumstances, it might be desirable for the mobile node to
terminate the MIPv6 service only (and stop being charged for that),
while maintaining uninterrupted access to the visited network.
Relaying on the architecture described in the previous sections, this
result can be achieved in two different ways:
- the MN can wait till the next re-authentication event (usually
triggered by the network) and perform the re-negotiation of the
whole MIPv6 protocol operation (see section 3.2),
- or the MN can decide to stop sending Binding Updates to the HA,
causing the expiration of the correspondent entry in the Binding
Cache. This is interpreted by the HA as the MN's willingness to
stop using the Mobile IPv6 protocol. Therefore, the HA, behaving
similarly to a standard Network Access Server (NAS), sends a
Diameter Session Termination Request to the AAA server and, after
the reception of the correspondent Session Termination Answer,
releases all the resources previously allocated to the MN (i.e.
the Home Address and the entry in its Service Authorization
Cache).
Giaretta Guardini Demaria Expires - August 2004 [Page 18]
Internet-Draft MIPv6 Authorization based on EAP January 2004
4. Home Agent considerations
This section details some specific features and data structures that
have to be supported by the Home Agent to allow dynamic negotiation
of Mobile IPv6 protocol parameters during mobile node network
attachment.
4.1 Service Authorization Cache (SAC)
The Home Agent is required to store some authorization data for each
of the MNs it is serving. A new data structure, called Service
Authorization Cache (SAC), is used for this purpose. Each entry in
the SAC should contain at least the following fields:
- NAI of the user: it is derived from the User-Name-AVP included by
AAAH in all the Diameter messages addressed to the HA;
- Home Address: it is the Home Address (checked against DAD) that
the HA has dynamically assigned to the MN during the Mobile IPv6
bootstrap phase;
- Authorization Lifetime: it is the authorization lifetime of the
Mobile IPv6 service granted to the MN. AAAH selects this lifetime
according to administrative rules and specifies it in the
Authorization-Lifetime-AVP. Before the expiration of this
lifetime, the HA may send a Diameter Authorization Refresh Request
(ARR) message to AAAH asking for an extension (i.e. renewal) of
the authorization;
- Authentication Mode: it is the authentication mode to be used in
IKE Phase 1 for setting up the IPsec SA with the MN. This draft
specifies in detail only the approach based on a Pre-shared Key
(PSK);
- Cryptographic Data: this field includes all the information to be
used for IKE bootstrap. The actual content of this record depends
on the Authentication Mode chosen for IKE Phase 1: if Pre-shared
Key is used for this purpose, this field includes the PSK value
and its lifetime.
4.2 Management of Binding Cache entries
The selection of the Home Address to be assigned to the MN at the end
of the MIPv6 bootstrap phase is performed by the designated Home
Agent at the reception of the Diameter Home Address Request (HAR)
message from the AAAH server. Immediately after the completion of
this procedure, the HA is required to start defending the Home
Giaretta Guardini Demaria Expires - August 2004 [Page 19]
Internet-Draft MIPv6 Authorization based on EAP January 2004
Address (i.e. proxy Neighbor Discovery), even if it has not yet
received any Binding Update from the MN. This behavior is not
completely conformant with the Mobile IPv6 specification and has to
be treated carefully to avoid protocol failures on the HA. In
particular, the following anomaly might happen:
- at the end of the MIPv6 authorization and negotiation process
(i.e. the MN has completed the EAP communication and has been
explicitly authorized to use MIPv6 from its current point of
attachment), the MN sends a Binding Update (BU) message to
register its Care-of Address on the HA;
- the Home Agent receives the BU from the MN and, following the
MIPv6 protocol standard, checks the Home Address included in it
against DAD. Since the HA is already defending that Home Address,
DAD might happen to fail, blocking Mobile IPv6 functionality on
the MN.
To avoid this problem, when the HA starts defending the Home Address
allocated to the MN (i.e. immediately before replying to AAAH with
the Diameter Home Address Answer message), it should also register it
in its binding cache, creating a new entry where the Care-of Address,
that is still unknown, is initially set to unspecified (::) and the
correspondent lifetime is set to the MIPv6 authorization lifetime. In
this way, when the HA receives the first Binding Update from the MN,
the message is treated as an update of an existing entry in the
Binding Cache and therefore DAD is not performed.
In order for this procedure to work properly, the MN has to send a BU
to the HA as soon as it is granted IPv6 access to the visited subnet
(i.e. at the end of EAP authentication). If the visited subnet
happens to be on the home link, the MN should send to the HA a BU
with binding lifetime equal to 0, to make sure it cleans up the dummy
entry in its binding cache and stops defending the home address.
5. Protocol Applicability in Cellular Networks
Using the Mobile IPv6 protocol and the services offered thereby may
be desirable particularly to handle mobile node movements across a
multi-access environment, involving both WLANs and 3GPP radio
networks (i.e. vertical handoff). This scenario, in fact, is becoming
increasingly popular, due to the massive deployment of WLAN hot-spots
in public indoor areas like airports and hotels.
In cellular networks (e.g. GPRS, UMTS), access control and IP address
assignment are managed relaying on protocols that are specific of
cellular infrastructures (for instance, SS7/MAP), and therefore do
not natively support the use of EAP. For this reason, in such
Giaretta Guardini Demaria Expires - August 2004 [Page 20]
Internet-Draft MIPv6 Authorization based on EAP January 2004
environments the Mobile IPv6 authorization and configuration
procedure described in the previous sections can not be employed as
is, but must be properly adapted.
The proposed solution is based on the assumption that the MN performs
Mobile IPv6 service negotiation interacting with a AAA server
supporting Diameter, which remains logically unchanged regardless of
the access technology being used (i.e. WLAN or cellular).
Additionally, this AAA server must support a communication interface
towards the authentication center of the cellular operator (i.e.
HLR/AuC), but the details about this interaction are outside the
scope of this document.
When the MN enters a GPRS or UMTS data network, based on layer 2
signaling procedures specific of cellular environments, it is
assigned an IP address (v4 or v6) by activating a so called PDP
Context. This corresponds to establishing a direct layer 3
communication channel between the MN and the GGSN (GPRS Gateway
Support Node), that is basically the first router on the path towards
any external IP cloud (e.g. the Internet).
At this stage, to perform MIPv6 negotiation as described in the
previous sections, it is necessary to establish an additional
communication channel based on EAP over the existing IP transport
(i.e. over the PDP Context). This can be achieved activating a PANA
[9] session between the MN and the GGSN, used for the sole purpose of
authorizing and configuring (or re-negotiating, if it was already
active) the Mobile IPv6 service.
This procedure consists of the exchange of MIPv6 TLVs transported
directly over EAP (i.e. exchange of EAP messages with EAP-Type equal
to EAP-TLV). In this case, there is no need to protect this signaling
establishing a TLS tunnel through PEAP, because there is already a
secure channel in place between MN and GGSN, provided by the PDP
Context. Moreover, it is not necessary to carry out any further
authentication procedures, because the user has already been
authenticated via HLR/AuC and SS7/MAP.
The whole procedure includes the following steps (Figure 11):
- GGSN and MN establish a PANA session (PANA-Start-Request/Answer).
The communication is triggered by the GGSN message as soon as the
PDP Context activation is complete;
- GGSN sends to the AAA server a Diameter EAP Request message
containing the user identifier (NAI) and an empty EAP packet,
indicating the need of starting an EAP exchange. The NAI is
constructed directly by the GGSN, that is a trusted node, using
the MN credentials collected during the PDP Context activation.
Giaretta Guardini Demaria Expires - August 2004 [Page 21]
Internet-Draft MIPv6 Authorization based on EAP January 2004
Since these credentials (i.e. essentially the data contained in
the SIM/USIM) have already been verified using protocols specific
of cellular networks (e.g. SS7/MAP), there is no need to undertake
a new authentication phase;
- at the reception of the Diameter EAP Request message from the
GGSN, the AAA server understands that the MN is already
authenticated (e.g. interacting with the HLR/AuC) and starts
directly the Mobile IPv6 negotiation phase, sending EAP messages
containing solely the MIPv6-Authorization-TLV. The negotiation
goes on as already described in section 3.1 for WLAN access.
- if the negotiation terminates successfully, the AAA server sends
to the GGSN an EAP Success message conveyed within a Diameter EAP
Answer; the GGSN forwards this notification to the MN through a
PANA-Bind-Request message. Finally, MN closes the exchange
replying with a PANA-Bind-Answer.
At any time, the MN may request the termination of the PANA session,
and consequently the release of the MIPv6 service, by means of a
PANA-Termination-Request message sent to the GGSN node. Conversely,
the AAA server may discontinue the delivery of the service sending a
Diameter Abort Session Request message to the Home Agent.
The main advantage of this procedure lies in the possibility of re-
using those messages and TLVs defined in section 3.1 even when the MN
accesses a cellular network, or, in general, any IP network (wireless
or wired) performing user authentication with methods other than EAP.
Instead, the drawback is that the GGSN, or, in general, the first
router on the outbound routing path, has to support a new feature
(i.e. the PANA protocol) and the MIPv6 service negotiation is not
carried out together with the user authentication, but as an
additional procedure following the MN network attachment.
Giaretta Guardini Demaria Expires - August 2004 [Page 22]
Internet-Draft MIPv6 Authorization based on EAP January 2004
MN +-------------------------+ GGSN +--------------------------+ AAA
/-----PDP Context Act. ------\
\----------------------------/
<-----------------
PANA-Start-Request
------------------>
PANA-Start-Answer ----------------------->
Diameter-EAP-Request(
EAP-Payload-AVP(empty),
User-Name-AVP)
<---------------------------------
Diameter-EAP-Answer(EAP-Payload-AVP(EAP-
Request/EAP-Type=EAP-TLV(MIPv6-Authorization-TLV
(Service-Status,[Service-Options]))))
<----------------------
PANA-Auth-Request(EAP-Request)
-------------------------->
PANA-Auth-Answer(EAP-Response/EAP-Type=EAP-TLV
(MIPv6-Authorization-TLV(Service-Selection,
[Service-Options])))
------------------->
Diameter-EAP-Request +-+
HA select. |O|
and config. +-+
<---------------------------------
Diameter-EAP-Answer(EAP-Payload-AVP(
EAP-Request/EAP-Type=EAP-TLV(MIPv6
Authorization-TLV(Home-Address
HA-Address,IKE-Bootstrap-Info))))
<-----------------
PANA-Auth-Request(
EAP-Request)
------------------>
PANA-Auth-Answer(EAP-Response/EAP-Type=
EAP-TLV(MIPv6-Authorization-TLV
(Negotiation-Result))) ------------------->
Diameter-EAP-Request
<--------------------------
Diameter-EAP-Answer(
EAP-Payload-AVP(EAP-Success))
<---------------------
PANA-Bind-Request(EAP-Success)
------------------>
PANA-Bind-Answer
Figure 11 - MIPv6 service authorization in 3GPP networks
Giaretta Guardini Demaria Expires - August 2004 [Page 23]
Internet-Draft MIPv6 Authorization based on EAP January 2004
6. New Messages and Attributes
6.1 New EAP-TLVs
The general format of an EAP-TLV is depicted in Figure 12 [10].
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12 - Generic TLV format
TLVs defined in this draft are:
- MIPv6-Authorization-TLV. This is a generic TLV which carries all
TLVs related to MIPv6 authorization and configuration. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
0 - Non-mandatory TLV
R
Reserved, set to zero (0)
Type
TBD - MIPv6-Authorization
Length
The length of the Value field in octets
Value
This field carries the subsequent TLVs
Giaretta Guardini Demaria Expires - August 2004 [Page 24]
Internet-Draft MIPv6 Authorization based on EAP January 2004
- 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 not active and not available
1 = MIPv6 service is not active but available
2 = MIPv6 service is active but no more available
3 = MIPv6 service is active and available
- Service-Selection-TLV. This TLV is sent by the MN to inform the
AAAH whether it accepts the AAAH proposal.
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 |
+-+-+-+-+-+-+-+-+
Type
TBD - Service-Selection
Length
1
Code
0 = MN accepts configuration options proposed by AAAH
1 = activate MIPv6 service
Giaretta Guardini Demaria Expires - August 2004 [Page 25]
Internet-Draft MIPv6 Authorization based on EAP January 2004
2 = re-negotiate MIPv6 service
3 = deactivate MIPv6 service
- Service-Options-TLV. So far only two service options are defined:
the multiple registration option and the HA in visited network
option. This TLV 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-Options | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD - Service-Options
Length
2
H
1 - The MN is requesting a HA in the visited network
M
1 - The MN is requesting multiple registration functionalities
Reserved
14 bit reserved set to 0
- Home-Agent-Address-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=HA-Address | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Home Agent Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Giaretta Guardini Demaria Expires - August 2004 [Page 26]
Internet-Draft MIPv6 Authorization based on EAP January 2004
Type
TBD - Home-Agent-Address
Length
16
Value
Home Agent Address
- Home-Address-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=Home-Address | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Home Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD - Home-Address
Length
16
Value
Home Address
- IKE-Bootstrap-Information-TLV. This TLV carries data related to
IKE bootstrap; the generic format 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=IKE-Bootstrap-Info | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth. Type | IKE Phase 1 Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Information...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Giaretta Guardini Demaria Expires - August 2004 [Page 27]
Internet-Draft MIPv6 Authorization based on EAP January 2004
Type
TBD - IKE-Bootstrap-Information
Length
Depending on Authentication Type
Value
Authentication Type
The authentication method to be used in IKE Phase 1
IKE Phase 1 Mode
The mode to be used in IKE Phase 1
Authentication Information
This field contains cryptographic material to setup
the security association.
The figure below depicts the IKE-Bootstrap-Information-TLV when PSK
is used as Authentication Type.
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-Bootstrap-Info | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSK | Aggressive Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD - IKE-Bootstrap-Information
Length
8 + Key length
Giaretta Guardini Demaria Expires - August 2004 [Page 28]
Internet-Draft MIPv6 Authorization based on EAP January 2004
Value
Authentication Type
PSK
IKE Phase 1 Mode
Aggressive Mode
Authentication Information
Key Lifetime - the lifetime of the PSK
Key Value - the value of the PSK
- 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=Result | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result-Code |
+-+-+-+-+-+-+-+-+
Type
TBD - Result
Length
1
Value
0 - Success
128 - Failure
6.2 New Diameter messages and AVPs
In this draft a new Diameter Application, called Home Agent Diameter
Application, is proposed. The complete and detailed definition of the
application is outside the scope of this document; even so, this
section lists all new Diameter messages and AVPs introduced.
Giaretta Guardini Demaria Expires - August 2004 [Page 29]
Internet-Draft MIPv6 Authorization based on EAP January 2004
The Diameter messages defined are:
- Home Address Request. This message is sent by AAAH to the HA to
request a Home Address; it includes these AVPs:
o User-Name-AVP
o Home-Address-AVP (optional)
o Interface-Identifier-AVP (optional)
o HA-Features-AVP (optional)
- Home Address Answer. Through this message the Home Agent sends to
AAAH the parameters it has reserved for a particular MN; it
includes these AVPs:
o User-Name-AVP
o Home-Address-AVP
- Home Agent Configuration Request. AAAH sends this message to the
HA to give some information related to MIPv6 service activation;
it includes these AVPs:
o User-Name-AVP
o Authorization-Lifetime-AVP
o IKE-Bootstrap-Information-AVP
o Policy-AVP (optional)
- Home Agent Configuration Answer. Through this message the HA gives
to AAAH the result of MIPv6 configuration procedure; it includes
these AVPs:
o User-Name-AVP
o Result-Code-AVP
- Authorization Refresh Request. The HA sends this message to AAAH
when the Authorization Lifetime is going to elapse, requesting
whether the user is still authorized to use MIPv6. It includes
these AVPs:
o User-Name-AVP
- Authorization Refresh Answer. Through this message, AAAH specifies
whether the MN is still authorized to use MIPv6. If the user is no
longer authorized, the lifetime in Authorization-Lifetime-AVP is
set to 0. It includes these AVPs:
o User-Name-AVP
o Result-Code-AVP
o Authorization-Lifetime-AVP (optional)
- Foreign Home Agent Request. AAAH sends this message to AAAF to
request a Home Agent allocation.
o User-Name-AVP
o Home-Agent-Address-AVP (optional)
o HA-Features-AVP (optional)
o Home-Address-AVP (optional)
Giaretta Guardini Demaria Expires - August 2004 [Page 30]
Internet-Draft MIPv6 Authorization based on EAP January 2004
o Interface-Identifier-AVP (optional)
o Authorization-Lifetime-AVP (optional)
o Policy-AVP (optional)
- Foreign Home Agent Answer. AAAF sends this message to AAAH to give
it the parameters related to MIPv6 activation.
o User-Name-AVP
o Home-Agent-Address-AVP
o Home-Address-AVP
o Authorization-Lifetime-AVP
o IKE-Bootstrap-Information-AVP
Diameter AVPs defined in this document are:
- Home-Address-AVP. This AVP is of type IPAddress and the Data field
contains a Home Address.
- Home-Agent-Address-AVP. This AVP is of type IPAddress and the Data
field contains the address of a Home Agent.
- Interface-Identifier-AVP. This AVP is of type OctetString and the
Data field contains an Interface Identifier that the MN can
provide as a hint for Home Address selection on the HA.
- IKE-Bootstrap-Information-AVP. This AVP is of type OctetString and
contains data related to IKE bootstrap. The Data field has the
same structure of the Value field defined for the IKE-Bootstrap-
Information-TLV.
- HA-Features-AVP. This AVP (type to be defined) carries information
about specific features requested on the designated Home Agent
(e.g. support for registration of multiple CoAs).
- Policy-AVP. This AVP is of type IPFilterRule and defines a set of
access lists to be enforced by the HA on the traffic generated by
the mobile node.
7. Open Issues
Possible areas for future work are:
- the usage of the AAA infrastructure, in place of IKE, to bootstrap
the IPsec SA between the MN and the HA. This could be useful to
reduce the number of round trips required for the completion of
the MIPv6 negotiation procedure;
- the exploitation of the EAP Key Management Framework [11] to allow
the mobile node to derive the Pre-Shared Key used for IKE phase 1.
Giaretta Guardini Demaria Expires - August 2004 [Page 31]
Internet-Draft MIPv6 Authorization based on EAP January 2004
This might improve the security of the architecture, in that it
would not be necessary any more for the AAA server to send the PSK
over the air (even if within a protected TLS tunnel);
- the extension of the architecture to support the usage of digital
certificates, in addition to PSK, for peer authentication in IKE
phase 1;
- a deeper analysis of the issues related to the interface between
AAA server and HLR/AuC for the execution of the MIPv6 negotiation
procedure in cellular networks.
8. Security Considerations
The Mobile IPv6 authorization and configuration exchange between the
mobile node and the AAA server of the home domain is protected by a
TLS tunnel established using PEAPv2. Therefore the level of security
of this communication is the same of PEAPv2 message exchanges.
The interaction between the AAA server and the designated Home Agent
is based on Diameter, which means that it is protected using IPsec or
TLS, as specified by the Diameter base protocol.
Acknowledgments
The authors would like to thank Simone Ruffino (of Telecom Italia
Lab) for his feedback and suggestions.
References
[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July
2003.
[2] Palekar, A. et al., "Protected EAP Protocol (PEAP) Version 2",
draft-josefsson-pppext-eap-tls-eap-07 (work in progress),
October 2003.
[3] Blunk, L. et al., "Extensible Authentication Protocol (EAP)",
draft-ietf-eap-rfc2284bis-07 (work in progress), November 2003.
Giaretta Guardini Demaria Expires - August 2004 [Page 32]
Internet-Draft MIPv6 Authorization based on EAP January 2004
[4] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS Authentication
Protocol (EAP-TTLS)", draft-ietf-pppext-eap-ttls-03 (work in
progress), August 2003.
[5] Narten, T., Draves, R., "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[6] Faccin, S., Perkins, C., Le, F., Patil, B., "Diameter Mobile
IPv6 Application", draft-le-aaa-diameter- mobileipv6-03
(expired), April 2003.
[7] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to Protect
Mobile IPv6 Signaling between Mobile Nodes and Home Agents",
draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in progress), June
2003.
[8] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC
2409, November 1998.
[9] Forsberg, D. et al., "Protocol for Carrying Authentication for
Network Access (PANA)", draft-ietf-pana-pana-02 (work in
progress), October 2003.
[10] Hiller, T., Palekar, A., Zorn, G., "A Container Type for the
Extensible Authentication Protocol (EAP)", draft-hiller-eap-
tlv-01, May 2003.
[11] Aboba, B., Simon, D., Arkko, J., Levkowetz, H., " EAP Key
Management Framework", draft-ietf-eap-keying-01.txt, October
2003.
Giaretta Guardini Demaria Expires - August 2004 [Page 33]
Internet-Draft MIPv6 Authorization based on EAP January 2004
Appendix A - Home Agent allocation in a foreign domain
Whenever the mobile node is switched on inside a foreign domain (i.e.
roaming scenario), it may be worthwhile assigning it a local Home
Agent provided by the visited provider, rather than allocating a
distant HA in the home domain. This may be useful to optimize network
usage and reduce transfer delay for data traffic in bi-directional
tunneling.
The decision on the preferred position of the HA is taken by the AAAH
server, either autonomously (e.g. based on the user profile or on
other administrative policies) or negotiating with the MN through the
Service-Options-TLV. In the latter case, the negotiation procedure is
undertaken as follows:
- in the first MIPv6-Authorization-TLV sent over the TLS tunnel
established with PEAPv2, the AAAH server includes, together with
the Service-Status-TLV, a Service-Options-TLV with the bit H set
to 1, meaning that the allocation of a HA within the foreign
domain is actually supported by the home provider;
- if the MN wants to exploit this feature, it responds sending a
MIPv6-Authorization-TLV including, in addition to the mandatory
Service-Selection-TLV, a Service-Options-TLV with the bit H set to
1, as a confirmation of its preference for the assignment of a
local HA within the foreign domain.
The rest of the procedure for bootstrapping MIPv6 protocol operation
on the MN is carried out essentially as already described for the
allocation of a HA inside the home domain (see section 3.1). The only
major difference is that the AAAH server cannot perform HA selection
and configuration by its own but has to interact with the AAA server
of the foreign domain (i.e. AAAF).
As a whole, the procedure undertaken by the AAAH server to obtain and
configure a HA inside the foreign domain is based on the following
steps (see Figure 13):
- AAAH sends a Diameter Foreign Home Agent Request (FHAR) message to
AAAF, indicating the user's NAI in the User-Name-AVP. Optionally,
AAAH may insert other AVPs including the configuration hints
eventually provided by the MN (HA-Address-AVP, Home-Address-AVP
and Interface-Identifier-AVP), the additional features required on
the HA (HA-Features-AVP), the desired authorization lifetime to be
set on the designated HA (Authorization-Lifetime-AVP) and the
filtering rules to be enforced on the traffic generated by the
mobile node (Policy-AVP);
Giaretta Guardini Demaria Expires - August 2004 [Page 34]
Internet-Draft MIPv6 Authorization based on EAP January 2004
- based on the information included in the request message, AAAF
determines whether it can assign a HA within the local domain. In
case the allocation is not possible (e.g. for administrative
policies), or none of the available HAs actually supports the
requested features (e.g. possibility to register multiple CoAs),
AAAF replies with a Diameter Foreign Home Agent Answer (FHAA)
message including a Result-Code-AVP set to FAILURE. In that case
AAAH continues MIPv6 negotiation allocating a HA within the home
domain. Instead, if AAAF can satisfy the request, it immediately
determines a suitable Home Agent to be allocated to the MN using a
Home Agent Selection Algorithm;
- at this stage AAAF communicates with the selected HA using the
same approach already described in section 3.1, based on the usage
of Diameter Home Agent Request/Answer and Home Agent Configuration
Request/Answer messages;
- once the designated HA is properly configured (i.e. at the
reception of the HACA message), AAAF delivers to AAAH a Diameter
Foreign Home Agent Answer message including, in correspondent
AVPs, all the information needed to activate the MIPv6 protocol
operation on the MN (i.e. HA address, Home Address, Authorization
Lifetime and IKE bootstrap information).
Giaretta Guardini Demaria Expires - August 2004 [Page 35]
Internet-Draft MIPv6 Authorization based on EAP January 2004
Diameter Diameter
AAAH HA Application AAAF HA Application
Server +-----------------------+ Server +----------------------+ HA
------------------>
Foreign-Home-Agent-Request(User-Name,
[Home-Agent-Address],[Home-Address],
[Interface-ID],[HA-Features],
[Auth. Lifetime],[Policy])
+-+
|O|
+-+
Home Agent
Selection
---------------------->
Home-Address-Request(
User-Name, [HA-Features],
[Home-Address], [Interface-ID])
<-----------------------
Home-Address-Answer(
User-Name, Home-Address,
[IKE-Bootstrap-Info])
+-+
|O|
+-+
IKE Configuration
Selection
----------------------->
HA-Configuration-Request(
User-Name, Auth. Lifetime,
IKE-Bootstrap-Info, [Policy])
<-----------------------
HA-Configuration-Answer(
User-Name, Result-Code)
<------------------
Foreign-Home-Agent-Answer(User-Name,
Home-Agent-Address,Home-Address,
Auth. Lifetime,IKE-Bootstrap-Info,
[Policy])
Figure 13 - Allocation of a Home Agent in the foreign domain
Giaretta Guardini Demaria Expires - August 2004 [Page 36]
Internet-Draft MIPv6 Authorization based on EAP January 2004
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
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Giaretta Guardini Demaria Expires - August 2004 [Page 37]
Internet-Draft MIPv6 Authorization based on EAP January 2004
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Giaretta Guardini Demaria Expires - August 2004 [Page 38]