< draft-giaretta-mip6-authorization-eap-01.txt   draft-giaretta-mip6-authorization-eap-02.txt >
MIP6 Working Group G. Giaretta MIP6 Working Group G. Giaretta
Internet Draft I. Guardini Internet Draft I. Guardini
Expires: January 14, 2005 E. Demaria Expires: April 2005 E. Demaria
TILab TILab
J. Bournelle J. Bournelle
M. Laurent-Maknavicius M. Laurent-Maknavicius
GET/INT GET/INT
July 16, 2004 October 2004
MIPv6 Authorization and Configuration based on EAP MIPv6 Authorization and Configuration based on EAP
<draft-giaretta-mip6-authorization-eap-01.txt> <draft-giaretta-mip6-authorization-eap-02.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, I
and any of which I become aware will be disclosed, in accordance certify that any applicable patent or other IPR claims of which I am
with RFC 3668. aware have been disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This draft defines an architecture, and related protocols, for This draft defines an architecture, and related protocols, for
performing dynamic Mobile IPv6 authorization and configuration performing dynamic Mobile IPv6 authorization and configuration
relying on a AAA infrastructure. The necessary interaction between relying on a AAA infrastructure. The necessary interaction between
the AAA server of the home provider and the mobile node is realized the AAA server of the home provider and the mobile node is realized
using EAP, exploiting the capability of some EAP methods to convey using EAP, exploiting the capability of some EAP methods to convey
generic information items together with authentication data. This generic information items together with authentication data. This
approach has the advantage that the access equipment acts as a simple approach has the advantage that the access equipment acts as a simple
pass-through for EAP messages and therefore does not play any active pass-through for EAP messages and therefore does not play any active
role in the Mobile IPv6 negotiation procedure, which makes the role in the Mobile IPv6 negotiation procedure, which makes the
solution easier to deploy and maintain. solution easier to deploy and maintain.
Table of Contents Table of Contents
1. Introduction................................................2 1. Introduction................................................3
2. Terminology.................................................3 2. Terminology.................................................4
3. Protocol Overview...........................................3 3. Protocol Overview...........................................5
4. Requirements on EAP methods.................................8 4. Requirements on EAP methods................................10
5. Detailed Description of the Protocol........................9 5. Detailed description of the Protocol.......................12
5.1 Mobile Node bootstrap....................................9 5.1 Mobile node bootstrapping...............................12
5.2 Management of reauthentication events...................14 5.2 Management of re-authentication events..................17
6. Home Agent considerations..................................15 6. Home Agent considerations..................................19
6.1 Requirements on AAAH-HA communication...................15 6.1 Requirements on AAAH-HA communication...................19
6.2 Management of MIPv6 authorization state.................16 6.2 Management of MIPv6 authorization state.................20
7. New EAP TLVs...............................................17 7. The MIPv6-Authorization container..........................22
8. Security Considerations....................................22 7.1 PEAPv2..................................................22
Acknowledgments.................................................22 7.2 EAP-FAST................................................23
References......................................................22 7.3 EAP-SIM.................................................23
Authors' Addresses..............................................24 7.4 EAP-AKA.................................................24
Intellectual Property Statement.................................25 7.5 EAP-TTLS................................................24
7.6 EAP-IKEv2...............................................25
8. New TLVs...................................................26
8.1 Service-Status-TLV......................................26
8.2 Service-Selection-TLV...................................27
8.3 Service-Options-TLV.....................................27
8.4 Home-Agent-Address-TLV..................................28
8.5 Home-Address-TLV........................................28
8.6 IKE-Authentication-Options-TLV..........................29
8.7 IKE-Bootstrap-Information-TLV...........................30
8.8 Negotiation-Result-TLV..................................31
8.9 Authorization-Lifetime-TLV..............................32
9. Security Considerations....................................33
10. References.................................................34
10.1 Normative References..................................34
10.2 Informative References................................34
Acknowledgments.................................................36
Authors' Addresses..............................................36
Intellectual Property Statement.................................37
1. Introduction 1. Introduction
Mobile IPv6 [1] requires that Mobile Nodes (MNs) and Home Agents Mobile IPv6 [RFC3775] requires that Mobile Nodes (MNs) and Home
(HAs) share a set of configuration parameters: the MN must know its Agents (HAs) share a set of configuration parameters: the MN must
Home Address, the Home Agent Address and the cryptographic material know its Home Address, the Home Agent Address and the cryptographic
needed to protect MIPv6 signaling (e.g. shared keys or certificates material needed to protect MIPv6 signaling (e.g. shared keys or
to setup an IPsec security association). MIPv6 base protocol does not certificates to setup an IPsec security association). MIPv6 base
specify any method to automatically acquire this information; which protocol does not specify any method to automatically acquire this
means that network administrators are normally required to manually information; which means that network administrators are normally
set configuration data on MNs and HAs. required to manually set configuration data on MNs and HAs.
Manual configuration of Home Agents and Mobile Nodes also works as an Manual configuration of Home Agents and Mobile Nodes also works as an
implicit method for Mobile IPv6 authorization, because only the users implicit method for Mobile IPv6 authorization, because only the users
that have been administratively enabled on a specific Home Agent are that have been administratively enabled on a specific Home Agent are
allowed to exploit Mobile IPv6 and its features. allowed to exploit Mobile IPv6 and its features.
However, in a large network (e.g. the network of a mobile operator), However, in a large network (e.g. the network of a mobile operator),
which may include millions of users and many Home Agents, the which may include millions of users and many Home Agents, the
operational and administrative burden of this procedure may easily operational and administrative burden of this procedure may easily
become overwhelming. In addition, the extensive use of manual and become overwhelming. In addition, the extensive use of manual and
static configurations limits the flexibility and reliability of the static configurations limits the flexibility and reliability of the
system, in that it is not possible to dynamically assign the HA when system, in that it is not possible to dynamically assign the HA when
the user enters the network, which would help to optimize performance the user enters the network, which would help to optimize performance
and resource utilization (e.g. assignment of the HA closest to the and resource utilization (e.g. assignment of the HA closest to the
MN's point of attachment). MN's point of attachment).
This is generally referred as the Mobile IPv6 bootstrapping problem. This is generally referred to as the Mobile IPv6 bootstrapping
As discussed in [2], several bootstrapping scenarios can be problem. As discussed in [MIPv6PS], several bootstrapping scenarios
identified depending on the relationship between the network operator can be identified depending on the relationship between the network
providing IP services to the MN (Access Service Provider, ASP) and operator providing IP services to the MN (Access Service Provider,
the service provider managing the HA (Mobility Service Provider, ASP) and the service provider managing the HA (Mobility Service
MSP). This document describes a solution to the bootstrapping problem Provider, MSP). This document describes a solution to the
that is applicable in a scenario where the ASP and the MSP are the bootstrapping problem that is applicable in a scenario where the ASP
same provider (Integrated ASP, IASP). and the MSP are the same provider (Integrated ASP, IASP).
The proposed solution performs dynamic Mobile IPv6 authorization and The proposed solution performs dynamic Mobile IPv6 authorization and
configuration together with MN authentication for network access. configuration together with MN authentication for network access.
MIPv6 negotiation and bootstrapping is controlled by the AAA server MIPv6 negotiation and bootstrapping is controlled by the AAA server
of the home provider (IASP), that interacts with the mobile node of the home provider (IASP), that interacts with the mobile node
relying on AAA routing and EAP, exploiting the capability of some EAP relying on AAA routing and EAP, exploiting the capability of some EAP
methods (e.g. PEAPv2 [4], EAP-FAST [5]) to convey generic information methods (e.g. PEAPv2 [PEAPv2], EAP-FAST [EAP-FAST]) to convey generic
items together with authentication data. information items together with authentication data.
2. Terminology 2. Terminology
General mobility terminology can be found in [3]. The following General mobility terminology can be found in [RFC3753]. The following
additional terms are used here: additional terms are used here:
ASP Access Service Provider ASP Access Service Provider
IASP Integrated Access Service Provider IASP Integrated Access Service Provider
MSP Mobility Service Provider MSP Mobility Service Provider
AAA Authentication Authorization Accounting AAA Authentication Authorization Accounting
skipping to change at page 3, line 39 skipping to change at page 5, line 4
ASP Access Service Provider ASP Access Service Provider
IASP Integrated Access Service Provider IASP Integrated Access Service Provider
MSP Mobility Service Provider MSP Mobility Service Provider
AAA Authentication Authorization Accounting AAA Authentication Authorization Accounting
AAAH AAA server of the Home domain AAAH AAA server of the Home domain
3. Protocol Overview 3. Protocol Overview
The basic idea behind the solution proposed herewith is to perform The basic idea behind the solution proposed herewith is to perform
Mobile IPv6 authorization and configuration during the authentication Mobile IPv6 bootstrapping during the authentication procedure
procedure undertaken by the Mobile Node to gain network access. undertaken by the Mobile Node to gain network access.
In particular, this draft defines a method to: In particular, this draft defines a method to:
- explicitly authorize the use of Mobile IPv6 based on the service - explicitly authorize the use of Mobile IPv6 based on the service
profile of the user, its position within the network, etc. profile of the user, its position within the network, etc.
- dynamically allocate a Home Agent to the Mobile Node; - dynamically allocate a Home Agent to the Mobile Node;
- dynamically configure Mobile IPv6 start-up parameters (i.e. MIPv6
bootstrapping) 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
Acknowledgements);
- allow the MN to negotiate additional Mobile IPv6 service options, - dynamically configure Mobile IPv6 start-up parameters (i.e. MIPv6
such as the assignment of a HA within the visited domain. 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 Figure 1 shows the overall architecture of the solution proposed in
this draft. The central element of the architecture is the AAA server 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 of the Home Domain (i.e. AAAH), which interacts with both the MN and
the selected HA to perform service authorization and configuration. the selected HA to perform service authorization and configuration.
AAA AAA
Client Client
IEEE 802.1x +------+ RADIUS IEEE 802.1x +------+ RADIUS
or PANA | | or Diameter or PANA | | or Diameter
skipping to change at page 4, line 41 skipping to change at page 5, line 49
(pass through) Protocol || (pass through) Protocol ||
\||/ \||/
\/ \/
+--------+ +--------+
| Home | | Home |
| Agent | | Agent |
+--------+ +--------+
Figure 1 - Solution architecture Figure 1 - Solution architecture
The solution is applicable to any access network relying on EAP [6] The solution is applicable to any access network relying on EAP
for user authentication and works with all EAP methods supporting the [RFC3748] for user authentication and works with all EAP methods
exchange of general purpose information elements, in the form of TLVs supporting the exchange of general purpose information elements, in
or AVPs, between EAP peers. Exploiting this capability, MN and AAAH any form (e.g. TLVs or AVPs), between EAP peers. Exploiting this
can embed MIPv6 negotiation signaling within the same EAP capability, MN and AAAH can piggyback Mobile IPv6 negotiation
conversation used to carry out user authentication. messages within the same EAP conversation used to carry out user
authentication.
This kind of operation is already supported by several tunneled (e.g. This kind of operation is already supported by several tunneled (e.g.
PEAPv2 [4]) and non tunneled (e.g. EAP-IKEv2 [8]) EAP methods, that PEAPv2 [PEAPv2]) and non tunneled (e.g. EAP-IKEv2 [EAP-IKEv2]) EAP
also include native support for encryption, authentication and methods, that also include native support for encryption,
integrity protection of exchanged configuration information (e.g. HA authentication and integrity protection of exchanged configuration
address). data (e.g. HA address).
Figure 2 shows an overview of the procedure defined to handle MIPv6 Figure 2 shows an overview of the procedure defined to handle MIPv6
bootstrap on the Mobile Node. For the sake of simplicity it is bootstrap on the Mobile Node. For the sake of simplicity it is
assumed that the employed AAA protocol is Diameter, but obviously assumed that the employed AAA protocol is Diameter, but obviously
RADIUS is suitable as well. RADIUS is suitable as well.
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 sensible information;
3.authentication phase. The actual authentication procedure and its
security properties depend on the selected EAP method. In 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 in TLVs (or
AVPs) 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 (e.g. SNMPv3 [16], COPS-PR [15], a new Diameter
application), whose specification is out of the scope of the
present document. At the end of this phase, the MN knows its own
Home Address, the address of the correspondent Home Agent and the
cryptographic material (i.e. pre-shared key) needed to set-up an
IPsec security association with IKE [12]. The IKE pre-shared key
can be either constructed by AAAH and then delivered to MN in a
proper TLV or can be 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 and, optionally,
other authorization AVPs containing some filtering rules to be
enforced on the NAS (e.g. the AP if the access network is a WLAN,
or the Enforcement Point in case of an IP network running the PANA
[13] protocol). Then the NAS 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, using the cryptographic
material collected during the MIPv6 negotiation phase (step 4), 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 EAP over
IEEE 802.1x EAP over Diameter AAAH-HA IEEE 802.1x EAP over Diameter AAAH-HA
or PANA AAA (or RADIUS) AAAH Protocol or PANA AAA (or RADIUS) AAAH Protocol
MN +---------+ Client +----------------+ Server +-------------+ HA MN +---------+ Client +----------------+ Server +-------------+ HA
1) <--Req. Id.--- 1) <--Req. Id.---
--Identity---> --Diameter EAP Req.--> --Identity---> --Diameter EAP Req.-->
/-------------------------------------\ /-------------------------------------\
2) / Set-up of protected channel \ 2) / Set-up of protected channel \
\ e.g. TLS Tunnel (optional) / \ e.g. TLS Tunnel (optional) /
skipping to change at page 7, line 4 skipping to change at page 7, line 4
5) <-----EAP----- <-----Diameter EAP---- 5) <-----EAP----- <-----Diameter EAP----
Success/Failure Answer (Success/Failure Success/Failure Answer (Success/Failure
and authorization AVPs) and authorization AVPs)
/----------------------------------------------------------\ /----------------------------------------------------------\
6) / Set-up Security Association MN-HA and \ 6) / Set-up Security Association MN-HA and \
\ Mobile IPv6 registration (exchange of BU and BA) / \ Mobile IPv6 registration (exchange of BU and BA) /
\----------------------------------------------------------/ \----------------------------------------------------------/
Figure 2 - Overview of Mobile IPv6 bootstrap procedure 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 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 [AAAH-HA] 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 This draft also defines the procedures to handle re-authentication
events and to manage the termination of the Mobile IPv6 session. events and to manage the termination of the Mobile IPv6 session.
In summary, the proposed architecture has the following advantages: In summary, the proposed architecture has the following advantages:
- allows the operator to maintain a centralized management (on the - allows the MSP to maintain a centralized management (on the AAA
AAA server) of the user profiles and the authentication, server) of the user profiles and the authentication, authorization
authorization and accounting procedures for any type of service, and accounting procedures for any type of service, including
including Mobile IPv6; Mobile IPv6;
- improves the reliability and performance of the Mobile IPv6 - improves the reliability and performance of the Mobile IPv6
protocol, in that the HA to be dynamically assigned to the MN can 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 be freely chosen among those that are closest to the user's point
of attachment, thus optimizing network usage and reducing the of attachment, thus optimizing network usage and reducing the
transfer delay for data traffic in bi-directional tunneling; transfer delay for data traffic in bi-directional tunneling;
- can be deployed, or extended with new features, without having to - can be deployed, or extended with new features, without having to
update the access equipment and the AAA protocols in use. Only update the access equipment and the AAA protocols in use. Only
minor changes in the AAA servers, the Home Agents and the mobile minor changes in the AAA servers, the Home Agents and the mobile
skipping to change at page 7, line 37 skipping to change at page 8, line 44
solution easy to use even when a Mobile Node is roaming with a solution easy to use even when a Mobile Node is roaming with a
provider different from its own; provider different from its own;
- allows the usage of any AAA protocol supporting the transport of - allows the usage of any AAA protocol supporting the transport of
EAP messages for the communication between the AAA client and EAP messages for the communication between the AAA client and
server (i.e. not just Diameter, but also RADIUS). This server (i.e. not just Diameter, but also RADIUS). This
significantly simplifies the deployment of MIPv6 in existing significantly simplifies the deployment of MIPv6 in existing
communication networks, where support for Diameter protocol in communication networks, where support for Diameter protocol in
access equipment is not so extensive. 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 As a whole, the solution adds a maximum of 2 RTTs (see the detailed
protocol description in section 5) to the EAP conversation carried protocol description in section 5) to the EAP conversation carried
out by the mobile node to authenticate itself and gain network out by the mobile node to authenticate itself and gain network
access. The number of extra RTTs can be reduced if the employed EAP access. The number of extra RTTs can be reduced if the employed EAP
method has the capability of transporting MIPv6 negotiation TLVs (or method has the capability of transporting MIPv6 negotiation TLVs (or
AVPs) together with authentication data. Nonetheless, it should be AVPs) together with authentication data. Nonetheless, it should be
noted that the full negotiation procedure can be undertaken by the MN noted that the full negotiation procedure can be undertaken by the MN
only during its initial bootstrap, and therefore the performance only during its initial bootstrapping, and therefore the performance
requirements are not so strict. requirements are not so strict.
4. Requirements on EAP methods 4. Requirements on EAP methods
In EAP methods, the EAP peer and EAP server exchange data in order In EAP methods, the EAP peer and EAP server exchange data in order to
to authenticate the EAP peer and eventually the EAP server (mutual authenticate the EAP peer and eventually the EAP server (mutual
authentication). This draft proposes the use of these exchanges to authentication). This draft proposes the use of these exchanges to
transport MIPv6 parameters, as part of an handshake that requires at transport MIPv6 parameters, as part of an handshake that requires at
maximum 2 RTTs. Thus, the main requirement for the applicability of maximum 2 RTTs. Thus, the main requirement for the applicability of
our proposal is: the solution is:
- the EAP method must provide a way to carry arbitrary parameters - the EAP method must provide a way to carry arbitrary parameters
during or after the authentication phase. This implies that the during or after the authentication phase. This implies that the
EAP method must provide messages and mechanisms for this purpose. EAP method must provide messages and mechanisms for this purpose.
Then, for security reasons, the EAP method must provide the following Then, for security reasons, the EAP method must provide the following
properties: properties:
- mutual authentication: the EAP method must provide mutual - mutual authentication: the EAP method must provide mutual
authentication. The access network must authenticate users authentication. The access network must authenticate users
skipping to change at page 9, line 33 skipping to change at page 11, line 33
| EAP-AKA | x | x | x | x | x | | EAP-AKA | x | x | x | x | x |
+------------+---+----------+---+---------------+-------------+ +------------+---+----------+---+---------------+-------------+
| EAP-TLS | x | x | x | x | | | EAP-TLS | x | x | x | x | |
+------------+---+----------+---+---------------+-------------+ +------------+---+----------+---+---------------+-------------+
| EAP-MD5 | | | | | | | EAP-MD5 | | | | | |
+------------+---|----------|---|---------------|-------------| +------------+---|----------|---|---------------|-------------|
In summary, it is possible to note that the procedure described in In summary, it is possible to note that the procedure described in
this draft can be successfully undertaken with several tunneled this draft can be successfully undertaken with several tunneled
(PEAPv2, EAP-FAST and EAP-TTLS) and non tunneled EAP methods (EAP- (PEAPv2, EAP-FAST and EAP-TTLS) and non tunneled EAP methods (EAP-
IKEv2, EAP-SIM, EAP-AKA, EAP-TLS), that all support the transport of IKEv2, EAP-SIM, EAP-AKA), that all support the transport of arbitrary
arbitrary parameters in the form of TLVs or AVPs. parameters.
5. Detailed Description of the Protocol 5. Detailed description of the Protocol
This section details the procedures and message exchanges that can be This section details the procedures and message exchanges that can be
adopted by the network operator to explicitly authorize the adopted by the network operator to explicitly authorize the
activation of Mobile IPv6 support for a specific user as well as activation of Mobile IPv6 support for a specific user as well as
enable dynamic bootstrapping of MIPv6 protocol parameters (e.g. Home enable dynamic bootstrapping of MIPv6 protocol parameters (e.g. Home
Address, Home Agent Address). Address, Home Agent Address).
5.1 Mobile Node bootstrap 5.1 Mobile node bootstrapping
If EAP is used for access control, when the MN enters the network it 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 is immediately polled for its identity, by means of an EAP Request
Identity message. This message is used to start the EAP Identity message. This message is used to start the EAP
communication. The MN replies sending its identity, in the form of a communication. The MN replies sending its identity, in the form of a
NAI (Network Access Identifier), within an EAP Response Identity NAI (Network Access Identifier), within an EAP Response Identity
message, that is received by a local attendant (e.g. the Access Point message, that is received by a AAA client (e.g. the Access Point in
in the case of a Wireless LAN) and forwarded via AAA routing to the the case of a Wireless LAN) and forwarded via AAA routing to the AAAH
AAAH server using the Diameter EAP Application (or the RADIUS EAP server using the Diameter EAP Application (or the RADIUS EAP
extensions). Then the AAAH server selects an EAP method (e.g. based 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 on the user service profile) and proposes it to the MN in subsequent
EAP messages. In order to enable the Mobile IPv6 negotiation EAP messages. In order to enable the Mobile IPv6 negotiation
procedure defined in this document, the EAP method chosen by the AAAH procedure defined in this document, the EAP method chosen by the AAAH
server must be an EAP method supporting the transport of general server must be an EAP method supporting the transport of general
purpose and variable length information elements, in the form of TLVs purpose and variable length information elements, in the form of TLVs
(or AVPs), together with authentication data (see section 4). (or AVPs), together with authentication data (see section 4).
After this initial handshake, MN and AAAH undertake the actual After this initial handshake, MN and AAAH undertake the actual
authentication phase, that may require the exchange of a variable authentication phase, that may require the exchange of a variable
number of EAP Request/Response messages. In many EAP methods, like number of EAP Request/Response messages. In many EAP methods, like
PEAPv2 or EAP-IKEv2, the authentication phase is preceded by the PEAPv2 or EAP-IKEv2, the authentication phase is preceded by the
establishment of an encrypted channel between MN and AAAH that establishment of an encrypted channel between MN and AAAH that
provides protection capabilities (i.e. privacy, integrity protection, provides protection capabilities (i.e. privacy, integrity protection,
etc.) for all the messages exchanged during the rest of the EAP etc.) for all the messages exchanged during the rest of the EAP
conversation. conversation.
As soon as the authentication phase is completed, the procedure for As soon as the authentication phase is completed, the procedure for
MIPv6 bootstrapping may take place. In order to do that, the MN and MIPv6 bootstrapping may take place. For that purpose, the MN and the
the AAAH server exploit the on-going EAP communication to exchange a AAAH server exploit the on-going EAP communication to exchange a
sequence of signaling messages encapsulated in a new TLV, called sequence of signaling messages transporting configuration parameters.
MIPv6-Authorization-TLV. This TLV is used as a generic container for
other, more specific, TLVs. 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. The whole bootstrapping procedure is depicted in Figure 3.
AAAH AAAH
MN +----------------------------+ Server +----------------+ HA MN +----------------------------+ Server +----------------+ HA
<--------------------- <---------------------
MIPv6-Authorization-TLV( MIPv6-Authorization-TLV(
Service-Status, Service-Status,
[Service-Options]) [Service-Options])
-----------------------> ----------------------->
MIPv6-Authorization-TLV( MIPv6-Authorization-TLV(
Service-Selection, [Service-Options], Service-Selection, [Service-Options],
[Home-Agent-Address], [Home-Address], [Home-Agent-Address], [Home-Address],
[Interface-Identifier]) [Interface-Identifier],
[IKE-Authentication-Options])
+-+ +-+ +-+ +-+
| |/----------------\| | | |/----------------\| |
| |\----------------/| | | |\----------------/| |
+-+ +-+ +-+ +-+
Home Agent HA Home Agent HA
Selection Conf. Selection Conf.
<--------------------- <---------------------
MIPv6-Authorization-TLV( MIPv6-Authorization-TLV(
Home-Address, HA-Address, Home-Address, Home-Agent-Address,
[IKE-PSK]) IKE-Bootstrap-Information,
Authorization-Lifetime)
-----------------------> ----------------------->
MIPv6-Authorization-TLV( MIPv6-Authorization-TLV(
Negotiation-Result) Negotiation-Result)
Figure 3 - MIPv6 bootstrapping procedure Figure 3 - MIPv6 bootstrapping procedure
AAAH starts the MIPv6 negotiation phase sending to the MN a MIPv6- AAAH starts the MIPv6 negotiation phase sending to the MN a MIPv6-
Authorization-TLV including the following TLVs: Authorization-TLV including the following TLVs:
skipping to change at page 12, line 27 skipping to change at page 14, line 35
may be assigned a Home Agent different from the one previously may be assigned a Home Agent different from the one previously
requested; requested;
- Home-Address-TLV (optional): used by the MN to suggest a preferred - 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 Home Address (e.g. an address pre-configured on one of its network
interfaces); like the previous TLV, this indication is considered interfaces); like the previous TLV, this indication is considered
only as a hint by the AAAH server; only as a hint by the AAAH server;
- Interface-Identifier-TLV (optional): through this TLV, the MN can - Interface-Identifier-TLV (optional): through this TLV, the MN can
suggest a preferred Interface Identifier (selected according to suggest a preferred Interface Identifier (selected according to
[9] or following other criteria) to be used by the AAA [RFC3041] or following other criteria) to be used by the AAA
infrastructure to build the Home Address starting from the infrastructure to build the Home Address starting from the
selected home prefix. Also in this case, this information, if selected home prefix. Also in this case, this information, if
present, is treated as a pure hint by AAAH. 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 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 Mobile IPv6, AAAH terminates the EAP communication sending an EAP
Success message, since the authentication procedure has been Success message, since the authentication procedure has been
accomplished successfully. accomplished successfully.
Otherwise, if the MN has confirmed its willingness to start MIPv6 Otherwise, if the MN has confirmed its willingness to start MIPv6
service, AAAH selects a suitable Home Agent through a Home Agent service, AAAH selects a suitable Home Agent through a Home Agent
Selection Algorithm. Possible parameters to be taken into account by Selection Algorithm. Possible parameters to be taken into account by
this algorithm include: current load of available HAs (e.g. number of this algorithm include: current load of available HAs (e.g. number of
active bindings), location of the MN and, eventually, the preferences active bindings), location of the MN and, eventually, the preferences
provided by the MN itself in the previous message exchange (i.e. provided by the MN itself in the previous message exchange (i.e.
Service-Options-TLV, Home-Agent-Address-TLV, Home-Address-TLV). For Service-Options-TLV, Home-Agent-Address-TLV, Home-Address-TLV, IKE-
example, based on the knowledge of the MN's current point of Authentication-Options-TLV). For example, based on the knowledge of
attachment (i.e. the current NAS), the AAAH server may select, among the MN's current point of attachment (i.e. the current AAA client),
the HAs available in the home domain, the one that is closest to the the AAAH server may select, among the HAs available in the home
MN in terms of IP routing hops. This approach is normally expected to domain, the one that is closest to the MN in terms of IP routing
improve performance. However, the detailed definition of a Home Agent hops. This approach is normally expected to improve performance.
Selection Algorithm is out of the scope of this document. 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, AAAH interacts with it to After a suitable HA has been identified, the AAAH server selects the
dynamically configure all the state needed to enable subsequent MIPv6 peer authentication method to be used in IKE phase 1. The peer
protocol operations, including the authorization lifetime of the authentication methods supported by the MN are known from the IKE-
MIPv6 service granted to the MN. Possible protocols that can be used Authentication-Options-TLV received during the previous exchange. If
for this purpose include Diameter (through a new Diameter possible, the AAAH server should choose the method on top of the list
Application), SNMPv3 or COPS-PR. Further details about this provided by the MN (i.e. the one with the highest preference).
communication are provided in section 6. Anyway, the detailed
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 specification of the interface between AAAH and HA is out of the
scope of this document. scope of this document. Additional considerations on the nature and
goals of such an interface can be found in [AAAH-HA] and [AAAMIPFWK].
As soon as the AAAH server has configured the state on the HA, it 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 continues the EAP session communicating to the MN all the MIPv6
configuration data it is waiting for. This is achieved delivering to configuration data it is waiting for. This is achieved delivering to
the MN an EAP Request containing a MIPv6-Authorization-TLV and the the MN an EAP Request containing a MIPv6-Authorization-TLV and the
following sub-TLVs: Home-Address-TLV (i.e. the home address) and following sub-TLVs: Home-Address-TLV (i.e. the home address), Home-
Home-Agent-Address-TLV (i.e. the address of the HA). Agent-Address-TLV (i.e. the address of the HA), IKE-Bootstrap-
Information-TLV (i.e. the peer authentication method to be used in
The pre-shared key needed to bootstrap the IKE session with the Home IKE phase 1 and associated cryptographic material) and Authorization-
Agent, and set-up the correspondent IPsec Security Association, can Lifetime-TLV (i.e. the lifetime granted to the MN for this session).
be derived by the MN from the keying material exported by the
employed EAP method. This approach provides excellent security
guarantees but requires the definition of a specific Application
Master Session Key (AMSK) [14] bound to MIPv6. Alternatively, if the
on-going EAP session provides confidentiality support, the AAAH
server can override the default behaviour by explicitly delivering a
valid PSK to the MN within an IKE-PSK-TLV.
After the MN has received all the configuration data from the AAAH After the MN has received all the configuration data from the AAAH
server (i.e. HA address, Home Address and optionally the PSK), it server (i.e. HA address, Home Address and IKE bootstrap information),
sends back an EAP Response containing a Negotiation-Result-TLV, it sends back an EAP Response containing a Negotiation-Result-TLV,
stating whether it accepts, or refuses, the proposed arrangement. If stating whether it accepts, or refuses, the proposed arrangement. If
the MN refuses the configuration, the AAAH server should immediately the MN refuses the configuration, the AAAH server should immediately
release the resources previously allocated on the Home Agent. release the resources previously allocated on the Home Agent.
After the completion of the EAP session, MN holds all data needed to After the completion of the EAP session, MN holds all data needed to
perform Mobile IPv6 registration: the MN knows its Home Address, the perform Mobile IPv6 registration: the MN knows its Home Address, the
address of the correspondent Home Agent and all cryptographic data address of the correspondent Home Agent and all cryptographic data
needed to establish the IPsec security association with it; needed to establish the IPsec security association with it;
furthermore, since it has been successfully authenticated, the MN can furthermore, since it has been successfully authenticated, the MN can
acquire an IPv6 address to be used as Care-of Address. acquire an IPv6 address to be used as Care-of Address.
The first operation carried out by the MN after the acquisition of The first operation carried out by the MN after the acquisition of
the Care-of Address is the establishment of the IPsec Security the Care-of Address is the establishment of the IPsec Security
Association with the HA, that is mandated by [1] to protect MIPv6 Association with the HA, that is mandated by [RFC3775] to protect
location update signaling. Set-up of the IPsec SA can be accomplished MIPv6 location update signaling. Set-up of the IPsec SA can be
following the procedure detailed in [11]. In this regard, it is accomplished following the procedure detailed in [RFC3776].
important to note that:
- since 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 [12]. Indeed, the NAI of the MN is the only
identity information stored in the HA (see section 6.2);
- in IKE phase 1 messages, the source address used by the MN has to
be the Care-of Address, as described in [11]; 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 As soon as the IPsec Security Association is established, MN can send
a Binding Update to the HA, thus starting up Mobile IPv6 service. a Binding Update to the HA, thus starting up Mobile IPv6 service.
5.2 Management of reauthentication events 5.2 Management of re-authentication events
At the expiration of AAA session time-outs or after a change in the 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 point of attachment to the network (e.g. change of Access Point), a
re-authentication procedure is performed leading to the user identity re-authentication procedure is performed leading to the user identity
to be checked again along with its right to continue exploitation of to be checked again along with its right to continue exploiting
network resources. To that purpose the AAAH server may repeat a full network resources. To that purpose the AAAH server may repeat a full
authentication or, alternatively, decide to use optimizations in authentication or, alternatively, decide to use optimizations in
order to make the procedure faster. Once this phase is completed the order to make the procedure faster. Once this phase is completed the
AAAH server also undertakes the re-negotiation of the MIPv6 service. AAAH server also undertakes the re-negotiation of the MIPv6 service.
Since the MIPv6 bootstrapping procedure is assumed to be completely Since the MIPv6 bootstrapping procedure is assumed to be completely
stateless, when a re-authentication event occurs the AAAH server may 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 not know the state of the MIPv6 service on the MN. For this reason
the AAAH server starts the MIPv6 negotiation as in the bootstrap the AAAH server starts the MIPv6 negotiation like in the
case: it delivers a MIPv6-Authorization-TLV containing a Service- bootstrapping case: it delivers a MIPv6-Authorization-TLV containing
Status-TLV and optionally a Service-Options-TLV. a Service-Status-TLV and optionally a Service-Options-TLV.
If the MIPv6 service is not active on the MN the procedure continues 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- as described in section 5.1. Otherwise, the MN replies with a MIPv6-
Authorization-TLV containing a Service-Selection-TLV indicating that Authorization-TLV containing a Service-Selection-TLV indicating that
the MIPv6 service is already in use. Furthermore, the MN inserts the the MIPv6 service is already in use. Furthermore, the MN inserts the
Home-Agent-Address-TLV and the Home-Address-TLV to inform the AAAH Home-Agent-Address-TLV, the Home-Address-TLV and the IKE-
server about its current state. The AAAH server can then get in touch Authentication-Options-TLV to inform the AAAH server about its
with the HA to check the integrity of the state and eventually renew current state. The AAAH server can then get in touch with the HA to
the MIPv6 authorization lifetime. If this procedure is accomplished check the integrity of the state, renew the MIPv6 authorization
successfully, the AAAH server terminates the EAP communication lifetime and eventually refresh the security parameters.
sending an EAP Success message. Otherwise, the AAAH server should
continue the EAP communication renegotiating the MIPv6 service (i.e. If the peer authentication method used by the MN in IKE phase 1 is
allocation of a new HA and related Home Address). 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 This solution can be easily deployed even within a network including
several AAA servers, each one managing a subset of the available several AAA servers, each one managing a subset of the available
Network Access Servers (NASs). This is because the re-negotiation Network Access Servers (NASs). This is because the re-negotiation
procedure does not assume to have any long term state related to procedure does not assume to have any long term state related to
Mobile IPv6 stored on the AAAH server. In this way, everything works 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 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 server that handles the re-authentication is not the same server that
authenticated the MN for the first time and performed the MIPv6 authenticated the MN for the first time and performed the MIPv6
bootstrapping procedure. 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.
6. Home Agent considerations 6. Home Agent considerations
This section provides further thougths about the AAAH-HA This section provides further thoughts about the AAAH-HA
communication and lists specific features that have to be supported communication and lists specific features that have to be supported
by the Home Agent to allow dynamic negotiation of Mobile IPv6 by the Home Agent to allow dynamic negotiation of Mobile IPv6
protocol parameters. protocol parameters.
6.1 Requirements on AAAH-HA communication 6.1 Requirements on AAAH-HA communication
This draft details only the message exchange between the MN and the This draft details only the message exchange between the MN and the
AAAH server. Obviously a complete Mobile IPv6 bootstrapping solution AAAH server. Obviously a complete Mobile IPv6 bootstrapping solution
requires also the definition of a mechanism for the communication requires also the definition of a mechanism for the communication
between the Home Agent and the AAAH server. Possible protocols that between the AAAH server and the Home Agent. Possible protocols that
may be used for this purpose include SNMPv3, COPS-PR or Diameter. 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.
The selected protocol should allow the AAAH server to: A detailed analysis of the goals for a generic AAAH-HA protocol can
be found in [AAAH-HA]; in this section some requirements, specific to
this scenario, are highlighted.
- verify if the selected HA is available to serve the MN (e.g. based The selected protocol should allow the AAAH server to:
on current traffic load and on the number of active bindings);
- send to the HA the MN's NAI, the authorization lifetime of the - use a Network Access Identifier (NAI) to identify the mobile node
Mobile IPv6 service granted to the MN, the IKE PSK to be used to in the communication with the HA;
bootstrap the IPsec Security Association and, optionally, a set of
hints for the construction of the Home Address (i.e. a preferred
Home Address or a preferred Interface Identifier);
- obtain from the selected Home Agent a valid Home Address to be - send an authorization lifetime to the HA to limit Mobile IPv6
assigned to the MN; session duration for the MN;
- force the termination of the Mobile IPv6 service for a specific MN - send to the HA a set of hints for the construction of the Home
removing the state stored on the correspondent HA; Address (e.g. a preferred Home Address or a preferred Interface
Identifier);
- manage the extension of the authorization lifetime for a specific - poll the designated HA for the allocation of a Home Address to the
MN; MN;
- retrieve the state associated to a specific MN from the - force the HA to terminate an active Mobile IPv6 session for
correspondent HA. 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 Moreover, the protocol selected to implement the communication
between the AAAH server and the HA should fulfill the following between the AAAH server and the HA should fulfill the following
general requirements: general requirements:
- inactive peer detection: the AAAH server should be able to - the AAAH server and the HA must be able to authenticate each other
promptly detect an HA failure. This may be useful to aid the HA (mutual authentication) in order to prevent the installation of
selection algorithm;
- mutual-authentication: the AAAH server and the HA must be able to
authenticate each other in order to prevent the installation of
unauthorized state on the HA; unauthorized state on the HA;
- confidentiality: since the IKE pre-shared key is derived by the - the AAA-HA interface must provide integrity protection in order to
AAAH server and then delivered to the HA, the correspondent prevent any alteration of exchanged data (e.g. Mobile IPv6
message exchange must be protected against eavesdropping. This configuration parameters);
implies that confidentiality is one of the main requirements;
- integrity: the exchanged configuration parameters must be - the AAA-HA interface must provide replay protection;
protected against any alteration and thus the protocol must
provide integrity 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 6.2 Management of MIPv6 authorization state
The Home Agent is required to store some authorization data for each 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 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: purpose and it should include at least the following fields:
- NAI of the user; - NAI of the user;
- Home Address assigned to the MN; - Home Address assigned to the MN;
- Cryptographic Data: this field includes all the information to be - Cryptographic Data: this field includes the peer authentication
used for bootstrapping IKE, that is the PSK value and its method to be used in IKE and, if needed, the pre-shared key and
lifetime; its lifetime;
- Authorization Lifetime: it is the lifetime of the Mobile IPv6 - Authorization Lifetime: it is the lifetime of the Mobile IPv6
service granted to the MN; service granted to the MN;
At the expiration of the Authorization Lifetime the HA should check 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 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 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 available the Home Agent should negotiate with the AAAH server an
extension of the Authorization Lifetime granted to the MN. Otherwise, extension of the Authorization Lifetime granted to the MN. Otherwise,
the HA should immediately release the authorization state associated the HA should immediately release the authorization state associated
skipping to change at page 17, line 21 skipping to change at page 22, line 5
allocated to the MN may vary depending on the user service profile. allocated to the MN may vary depending on the user service profile.
For instance, the AAAH server may decide to postpone the release of 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 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 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 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 a network providing cost-free access). In that case, the MN can
continue to rely on the IPsec SA previously negotiated with the HA continue to rely on the IPsec SA previously negotiated with the HA
and the respective authorization is managed through the Mobile IPv6 and the respective authorization is managed through the Mobile IPv6
Authorization Lifetime. Authorization Lifetime.
7. New EAP TLVs 7. The MIPv6-Authorization container
The general format of an EAP-TLV is depicted below. 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.
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 The MIPv6-Authorization container can be implemented as a TLV, as an
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP or in some other way depending on the specific characteristics of
|M|R| Type | Length | the EAP method used for network access authentication (see Figure 4).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLVs defined in this draft are: +----------------------------------------------------------+
| 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 | | | | |
+------------+ +------------+ +------------+ +-------------+
- MIPv6-Authorization-TLV. This is a generic TLV which carries all Figure 4 - Transport of MIPv6 bootstrapping messages
TLVs related to MIPv6 authorization and configuration. It is
defined as follows: 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 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 | |M|R| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M M
0 - Non-mandatory TLV 0 - Non-mandatory TLV
R R
Reserved, set to zero (0) Reserved, set to zero (0)
Type Type
TBD - MIPv6-Authorization TBD - MIPv6-Authorization
Length Length
The length of the Value field in octets The length of the Value field in octets
Value Value
This field carries the subsequent TLVs This field carries the subsequent TLVs
- Service-Status-TLV. This TLV is sent by the AAAH to inform the MN 7.2 EAP-FAST
about the status of Mobile IPv6 service. It is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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 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 | | Type=Service-Status | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | | Code |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type Type
TBD - Service-Status TBD - Service-Status
Length Length
1 1
Code Code
0 = MIPv6 service is available 0 = MIPv6 service is available
1 = MIPv6 service is not available 1 = MIPv6 service is not available
8.2 Service-Selection-TLV
- Service-Selection-TLV. This TLV is sent by the MN to inform the This TLV is sent by the MN to inform the AAAH whether it wants to
AAAH whether it wants to activate MIPv6 service or whether the activate MIPv6 service or whether the service is already active.
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 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 | | Type=Service-Selection | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | | Code |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type Type
TBD - Service-Selection TBD - Service-Selection
Length Length
1 1
Code Code
0 = activate MIPv6 service 0 = activate MIPv6 service
1 = MIPv6 service already active 1 = MIPv6 service already active
2 = do not activate MIPv6 service 2 = do not activate MIPv6 service
- Service-Options-TLV. This TLV is used by the AAAH server to 8.3 Service-Options-TLV
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 This TLV is used by the AAAH server to advertise the service options
the HA in visited domain option has been defined. The TLV has the the MN can ask for. It is also used by the MN to communicate its
following format: 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 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 | | Type=Service-Options | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V| Reserved | |V| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
skipping to change at page 19, line 38 skipping to change at page 28, line 4
|V| Reserved | |V| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD - Service-Options TBD - Service-Options
Length Length
2 2
V V
from AAAH to MN: from AAAH to MN:
0 = AAAH cannot provide a HA in the visited domain 0 = AAAH cannot provide a HA in the visited domain
1 = AAAH can provide a HA in the visited domain 1 = AAAH can provide a HA in the visited domain
from MN to AAAH: from MN to AAAH:
0 = MN does not specify any preference on HA location 0 = MN does not specify any preference on HA location
1 = MN is requesting a HA in the visited domain 1 = MN is requesting a HA in the visited domain
Reserved Reserved
15 bit reserved set to 0 15 bit reserved set to 0
- Home-Agent-Address-TLV. It is defined as follows: 8.4 Home-Agent-Address-TLV
This TLV carries the Home Agent's address and it's 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 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 | | Type=HA-Address | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Home Agent Address | | Home Agent Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 29 skipping to change at page 28, line 44
TBD - Home-Agent-Address TBD - Home-Agent-Address
Length Length
16 16
Value Value
Home Agent Address Home Agent Address
- Home-Address-TLV. It is defined as follows: 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 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 | | Type=Home-Address | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Home Address | | Home Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 5 skipping to change at page 29, line 27
TBD - Home-Address TBD - Home-Address
Length Length
16 16
Value Value
Home Address Home Address
- IKE-PSK-TLV. This TLV carries data related to IKE bootstrap; the 8.6 IKE-Authentication-Options-TLV
value field contains the PSK lifetime and the PSK value.
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 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-PSK | Length | |Type=IKE-Authentication-Options| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Lifetime | | AuthMethod-1 | AuthMethod-2 | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Value...
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type= IKE-Bootstrap-Information| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AuthMethod | key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD - IKE-PSK TBD - IKE-Bootstrap-Information
Length Length
4 + Key length Length of this TLV.
Value Value
Key Lifetime - the lifetime of the PSK in seconds. A value of AuthMethod - the authentication method to be used in IKE
all ones means infinite phase 1. This field can assume a value among
those defined in section 8.6 (i.e. PSK, AMSK
or CERT).
Key Value - the value of the PSK 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.
- Negotiation-Result-TLV. It is defined as follows: 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 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 | | Type=Negotiation-Result | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result-Code | | Result-Code |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type Type
TBD - Result TBD - Result
Length Length
1 1
Value Value
0 = Success 0 = Success
128 = Failure 128 = Failure
8.9 Authorization-Lifetime-TLV
8. Security Considerations 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)
9. Security Considerations
The Mobile IPv6 bootstrapping procedure described in this document The Mobile IPv6 bootstrapping procedure described in this document
assumes the MN and the AAA server of the home domain exchange the assumes the MN and the AAA server of the home domain exchange the
necessary parameters exploiting the EAP communication established for necessary parameters exploiting the EAP communication established for
network access authentication. Therefore, to secure the bootstrapping network access authentication. Therefore, to secure the bootstrapping
procedure, the employed EAP method must support mutual authentication procedure, the employed EAP method must support mutual authentication
as well as integrity and replay protection. Moreover, if the pre- as well as integrity and replay protection.
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.
Acknowledgments 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.
The authors would like to thank Simone Ruffino, Tom Hiller, Hannes 10. References
Tschofening, Rafael Marin Lopez, Hiroyuki Ohnishi, Mayumi Yanagiya
and Yoshihiro Ohba for their valuable comments.
References 10.1 Normative References
[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[2] Patel, A. et al. "Problem Statement for bootstrapping Mobile [RFC3776] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to
IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress), July Protect Mobile IPv6 Signaling between Mobile Nodes and
2004. Home Agents", RFC 3776, June 2004.
[3] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 3753, [RFC3748] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H.
June 2004. Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[4] Palekar, A. et al., "Protected EAP Protocol (PEAP) Version 2", [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange
draft-josefsson-pppext-eap-tls-eap-07 (work in progress), (IKE)", RFC 2409, November 1998.
October 2003.
[5] N.Cam-Winget, D. McGrew, J. Salowey, H.Zhou, "EAP Flexible [PEAPv2] Palekar, A. et al., "Protected EAP Protocol (PEAP)
Authentication via Secure Tunneling (EAP-FAST)", draft-cam- Version 2", draft-josefsson-pppext-eap-tls-eap-08 (work
winget-eap-fast-00.txt (work in progress), February 2004 in progress), July 2004.
[6] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, [EAPKEYFWK] Aboba, B., Simon, D., Arkko, J., Levkowetz, H., "EAP
"Extensible Authentication Protocol (EAP)", RFC 3748, June Key Management Framework", draft-ietf-eap-keying-03 (work
2004. in progress), July 2004.
[7] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS Authentication [MIPv6AMSK] Giaretta, G., Guardini, I., Demaria, E., Bournelle,
Protocol (EAP-TTLS)", draft-ietf-pppext-eap-ttls-04 (work in J., Laurent-Maknavicius, M., "Application Master Session
progress), April 2004. Key (AMSK) for Mobile IPv6", draft-giaretta-mip6-amsk-00
(work in progress), September 2004
[8] Tschofenig, H., Kroeselberg, D., Ohba, Y., "EAP IKEv2 Method", 10.2 Informative References
draft-tschofenig-eap-ikev2-03, February 2004.
[9] Narten, T., Draves, R., "Privacy Extensions for Stateless [MIPv6PS] Patel, A. et al. "Problem Statement for bootstrapping
Address Autoconfiguration in IPv6", RFC 3041, January 2001. Mobile IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in
progress), July 2004.
[10] Faccin, S., Perkins, C., Le, F., Patil, B., "Diameter Mobile [RFC3753] Manner, J., Kojo, M. "Mobility Related Terminology", RFC
IPv6 Application", draft-le-aaa-diameter- mobileipv6-03 3753, June 2004.
(expired), April 2003.
[11] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to Protect [RFC3041] Narten, T., Draves, R., "Privacy Extensions for Stateless
Mobile IPv6 Signaling between Mobile Nodes and Home Agents", Address Autoconfiguration in IPv6", RFC 3041, January
RFC 3776, June 2004. 2001.
[12] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC [AAAH-HA] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J.,
2409, November 1998. Lopez, R., "Goals for AAA-HA interface", draft-giaretta-
mip6-aaa-ha-goals-00 (work in progress), September 2004
[13] Forsberg, D. et al., "Protocol for Carrying Authentication for [AAAMIPFWK] Yegin, A., "AAA Mobile IPv6 Application Framework",
Network Access (PANA)", draft-ietf-pana-pana-04 (work in draft-yegin-mip6-aaa-fwk-00 (work in progress), August
progress), May 2004. 2004
[14] Aboba, B., Simon, D., Arkko, J., Levkowetz, H., "EAP Key [RFC3084] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F.
Management Framework", draft-ietf-eap-keying-02 (work in Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS
progress), July 2004. Usage for Policy Provisioning,", RFC 3084, March 2001.
[15] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. [MIPv6APP] Faccin, S., Perkins, C., Le, F., Patil, B., "Diameter
Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage for Mobile IPv6 Application", draft-le-aaa-diameter-
Policy Provisioning,", RFC 3084, March 2001. mobileipv6-03 (expired), April 2003.
[16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction [PANA] Forsberg, D. et al., "Protocol for Carrying
and Applicability Statements for Internet-Standard Management Authentication for Network Access (PANA)", draft-ietf-
Framework", RFC 3410, December 2002. pana-pana-04 (work in progress), May 2004.
[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 (work in progress), July 2004.
[EAP-IKEv2] Tschofenig, H., Kroeselberg, D., Ohba, Y., "EAP
IKEv2 Method", draft-tschofenig-eap-ikev2-03, February
2004.
[EAP-SIM] Haverinen, H. and J. Salowey, "Extensible Authentication
Protocol Method for GSM Subscriber Identity Modules (EAP-
SIM)", draft-haverinen-pppext-eap-sim-13 (work in
progress), April 2004.
[EAP-AKA] Arkko, J. and H. Haverinen, "EAP-AKA Authentication",
draft-arkko-pppext-eap-aka-12 (work in progress), April
2004.
[EAP-FAST] N.Cam-Winget, D. McGrew, J. Salowey, H.Zhou, "EAP
Flexible Authentication via Secure Tunneling (EAP-FAST)",
draft-cam-winget-eap-fast-00.txt (expired),
February 2004
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 Authors' Addresses
Gerardo Giaretta Gerardo Giaretta
Telecom Italia Lab Telecom Italia Lab
via G. Reiss Romoli, 274 via G. Reiss Romoli, 274
10148 TORINO 10148 TORINO
Italy Italy
Phone: +39 011 2286904 Phone: +39 011 2286904
Email: gerardo.giaretta@tilab.com Email: gerardo.giaretta@tilab.com
skipping to change at page 24, line 42 skipping to change at page 36, line 43
Phone: +39 011 2285403 Phone: +39 011 2285403
Email: elena.demaria@tilab.com Email: elena.demaria@tilab.com
Julien Bournelle Julien Bournelle
GET/INT GET/INT
9 rue Charles Fourier 9 rue Charles Fourier
Evry 91011 Evry 91011
France France
Email: julien.bournelle@int-evry.fr Email: julien.bournelle@int-evry.fr
Maryline Maknavicius-Laurent Maryline Laurent-Maknavicius
GET/INT GET/INT
9 rue Charles Fourier 9 rue Charles Fourier
Evry 91011 Evry 91011
France France
Email: maryline.maknavicius@int-evry.fr Email: maryline.maknavicius@int-evry.fr
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 25, line 41 skipping to change at page 37, line 40
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 108 change blocks. 
347 lines changed or deleted 698 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/