One document matched: draft-jee-mip6-bootstrap-pana-00.txt
MIP6 Working Group J. Jee
Internet Draft J. Nah
Expires: April 2005 K.Chung
ETRI
October 2004
Diameter Mobile IPv6 Bootstrapping Application using PANA
draft-jee-mip6-bootstrap-pana-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, I
certify that any applicable patent or other IPR claims of which I am
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
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 document specifies a new Diameter Application to support the
Mobile IPv6's bootstrapping mechanism during the AAA authentication
and authorization phase based on PANA. PANA is used as a protocol for
network authentication between mobile nodes and access networks.
During the PANA authentication phase, the mobile node's initial
configuration information like its home address, home agent address
and IKE pre-shared keying material is piggybacked to the PANA
messages cryptographically protected by the PANA SA. The Diameter and
PANA message formats to support the Mobile IPv6 bootstrapping are
defined.
Jee, et al. Expires - April 2005 [Page 1]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................3
3. Overall Architecture...........................................5
3.1 Basic Assumptions..........................................5
3.2 Protocol Overview..........................................6
4. Protocol Operations............................................7
4.1 AVPs.......................................................7
4.2 Command Codes..............................................8
4.3 Message Sequence...........................................9
4.4 MN Operation..............................................11
4.5 AAA Client Operation......................................11
4.6 AAAv Operation............................................12
4.7 AAAh Operation............................................13
4.8 HA Operation..............................................15
4.9 IKE Pre-shared key derivation.............................15
5. Message Formats...............................................16
5.1 PANA Messages.............................................16
5.2 Diameter Messages.........................................17
6. Security Considerations.......................................18
7. Acknowledgments...............................................19
8. References....................................................19
8.1 Normative References......................................19
8.2 Informative References....................................19
Author's Addresses...............................................20
Intellectual Property Statement..................................20
Jee, et al. Expires - April 2005 [Page 2]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
1. Introduction
Mobile IPv6 Bootstrapping is defined as obtaining information at the
mobile node, so that the mobile node can successfully register with
an appropriate home agent [3]. Bootstrapping information includes the
mobile node's home address, home agent address and cryptographic
material to protect the Mobile IPv6 signaling. This information must
be secured using integrity and replay protection [3].
PANA [4] is being standardized in the IETF PANA WG to provide network
authentication between clients and access networks. The PANA messages
which are exchanged after the EAP authentication is succeeded are
cryptographically protected by the PANA SA. This PANA SA provides the
integrity protection based on keyed message digest, replay protection
based on sequence numbers and data-origin authentication [4].
This document specifies a new Diameter Application to support the
Mobile IPv6's bootstrapping mechanism during the AAA authentication
and authorization phase based on PANA. PANA is used as a protocol for
network authentication between mobile nodes and access networks.
During the PANA authentication phase, the mobile node's initial
configuration information like its home address, home agent address
and IKE pre-shared keying material is piggybacked to the PANA
messages cryptographically protected by the PANA SA.
The terminology introduced in this document is described first. The
overall architecture of the Diameter Mobile IPv6 bootstrapping
application is described next. And then, the protocol operations for
the home agent assignment in the home domain and visited domain are
described. Finally, the PANA and Diameter message formats to support
the Mobile IPv6 bootstrapping are described.
2. Terminology
This section describes some terms introduced in this document.
MN:
Mobile Node
HA:
Home Agent
HoA:
Mobile Node's home address
HAv:
Home Agent in the visited domain
Jee, et al. Expires - April 2005 [Page 3]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
HAh:
Home Agent in the home domain
AAAv:
AAA server in the visited domain
AAAh:
AAA server in the home domain
AAA Client:
AAA Client performs the diameter client function to request the
authentication and authorization of the mobile node to the
backend Diameter server. We assume the case that EP(Enforcement
Point), AR(Access Router) and the PAA(PANA Authentication Agent)
are co-located. The definition of EP and PAA is specified in [4].
In this document, the AAA Client represents the EP, AR and PAA.
PANA SA (PANA Security Association):
The definition of this is the same as specified in [4].
MIPv6 MSA:
The IPsec SA to protect the MIPv6 signaling messages between the
MN and HA.
AAA-Key:
A key derived by the EAP peer and EAP server and transported to
the authenticator [4].
PANA-AAA-Key:
An AAA-Key derived by the MN and the AAA server and transported
to the AAA Client.
MIPv6-AAA-Key:
An AAA-Key derived by the MN and the AAA server and transported
to the HA. This key is used to derive the IKE pre-shared key to
distribute the MIPv6 MSA.
PANA-AAA-Key-Id:
Identifier of PANA-AAA-Key.
MIPv6-AAA-Key-Id:
Identifier of MIPv6-AAA-Key.
Jee, et al. Expires - April 2005 [Page 4]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
3. Overall Architecture
Visited Domain Home Domain
+-------------------------------+ +--------------+
| | | |
| +--------+ +--------+ | | +--------+ |
| | | | | | | | | |
| | HAv +----| AAAv +-----|-------|--+ AAAh | |
| | +----| | | | | | |
| | | | | | | | | |
| +--------+ +--+--+--+ | | +--+--+--+ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
+------+ | +----+--+-----+ | | +--+--+--+ |
| MN |---|--------------| AAA Client | | | | HAh | |
| | | | (EP/PAA/AR) | | | | | |
+------+ | +-------------+ | | +--+--+--+ |
| | | |
+-------------------------------+ +--------------+
* PANA is used as the network authentication protocol and used to
securely deliver the bootstrapping information like, the MN's HoA,
HA address and the IKE pre-shared keying material between the MN
and the AAA Client.
* Diameter Bootstrapping Application protocol is used,
Between the AAA Client and the AAAv
Between the AAAv and the AAAh
Between the AAA Server and the HA
* The integrated ASP network scenario [3] is considered where the ASP
and the MSP are the same.
3.1 Basic Assumptions
The communication channel between the AAA Client and the AAAv is
secure using TLS or IPsec as specified in [2].
The communication channel between the AAAv and the AAAh is secure
using TLS or IPsec as specified in [2].
The communication channel between the AAA Server and the HA SHOULD be
secure using TLS or IPsec.
EAP methods used for the MN's authentication SHOULD be capable of
deriving dynamic session keys.
Jee, et al. Expires - April 2005 [Page 5]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
3.2 Protocol Overview
MN AAA Client AAA Server HA
--- ------------ ------------- --
+-----------------------+
|Network Discovery & |
|initial handshake phase|
+-----------------------+
+------------------------------------------------------------------+
| Authentication and authorization phase |
| for network access and mobility service |
+-----------------------+------------------------------------------|
| PANA Authentication | AAA Authentication & Authorization |
| | |
|<-----PANA SA--------->| |
|<----------------- MIPv6 Bootstrapping information-- |
| (HA, HoA, Keying materials for MIPv6's Bootstrap & PANA |
| |
|<-----------------------IKE for MIPv6 MSA------------------------>|
| |
+------------------------------------------------------------------+
The protocol consists of two phases.
1. Network discovery and initial handshake phase
2. Authentication and authorization phase for network access and
mobility service
In the first phase, an IP address of AAA Client is discovered and a
PANA session is established between the MN and the AAA Client.
The second phase includes the PANA authentication and the AAA's
authentication and authorization phases. When the EAP authentication
is succeeded, the PANA SA is setup to cryptographically protect the
channel between the MN and the AAA Client. Using this secure channel,
the Mobile IPv6's initial configuration information like the HoA, the
HA address and security keying material to generate the MIPv6 MSA is
transferred from the AAA server to the MN.
In this protocol, the AAA server assigns two session keys, PANA-AAA-
Key and MIPv6-AAA-Key which are derived by the EAP authentication
result. The PANA-AAA-Key is transferred to the AAA Client and the
MIPv6-AAA-Key is transferred to the HA. Also, the key identifiers for
these keys are transferred to the MN. The PANA-AAA-Key is used to
derive the PANA SA which protects the PANA messages between the MN
Jee, et al. Expires - April 2005 [Page 6]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
and the AAA Client. The MIPv6-AAA-Key is used to derive the IKE pre-
shared key for distributing the MIPv6 SA between the MN and the HA.
4. Protocol Operations
4.1 AVPs
MIPv6-Bootstrap-Vector AVP: Flag values defined include,
1 Mobile-Node-Bootstrap-Requested flag:
This flag is set to '1' when the MN requests for a
bootstrapping. Through the bootstrapping process, MN
gets its HoA, HA address and the IKE pre-shared
keying material.
2 Home-Address-Allocatable-Only-in-Home-Domain flag:
This flag is set to '1' when the MN requests the
home address to be assigned in its home network.
4 Home-Agent-in-Visited-Domain flag:
This flag is set to '1' when the AAAh allows the
allocation of HA in the visited network.
8 Visited-Home-Agent-Available flag:
This flag is set to '1' when the AAAv notifies to the
AAAh that it can support the assignment of a HA in
the visited network.
MIPv6-Mobile-Node-Address AVP:
Type of IPAddress and contains the Mobile Node's Home Address.
MIPv6-Home-Agent-Address AVP:
Type of IPAddress and contains the Mobile Node's Home Agent
Address.
MIPv6-AAA-Key AVP:
Type of OctetString and contains the keying material for
protecting the communication between the MN and HA.
PANA-AAA-Key AVP:
Type of OctetString and contains the keying material for
protecting the communication between the MN and the AAA Client.
MIPv6-AAA-Key-Id AVP:
Type of Integer32 and contains a MIPv6-AAA-Key identifier.
PANA-AAA-Key-Id AVP:
Type of Integer32 and contains a PANA-AAA-Key identifier.
EAP-Payload AVP:
Type of OctetString and is used to encapsulate the EAP packet.
Jee, et al. Expires - April 2005 [Page 7]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
MAC AVP:
The same type as defined in [4].
PANA-Session-Id AVP:
Type of UTF8String and is used to identify a specific PANA
session.
AAA-Session-Id AVP:
Type of UTF8String and is used to identify a specific AAA
session.
4.2 Command Codes
This document introduces four new Diameter Command Codes:
* AAA-MIPv6-Bootstrap-Request Command (AMR)
* AAA-MIPv6-Bootstrap-Answer Command (AMA)
* HA-MIPv6-Bootstrap-Request Command (HMR)
* HA-MIPv6-Bootstrap-Answer Command (HMA)
The following PANA messages are used to piggyback the AVPs to support
the MIPv6 bootstrapping:
* PANA-Auth-Answer
* PANA-Bind-Request
* PANA-Bind-Answer
Jee, et al. Expires - April 2005 [Page 8]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
4.3 Message Sequence
4.3.1 HA assignment in the home domain
Mobile Node AAA Client AAAv AAAh Home Agent
----------- ---------- ----- ----- ----------
+-----------------------+
|PANA Discovery & |
|initial handshake phase|
+-----------------------+
<--PANA-Auth-Request
---PANA-Auth-Answer--->
(User-Name, MIPv6-Bootstrap-Vector)
AMR-------------->
AMR---------->
(MIPv6-AAA-Key)HMR--------------->
<---------------HMA
<------------AMA
(HA,HoA,MIPv6-AAA-Key-Id,
PANA-AAA-Key, PANA-AAA-Key-Id)
<-------------AMA
<---------------------PANA-Bind-Request
(HA,HoA,MIPv6-AAA-Key-Id,PANA-AAA-Key-Id)
PANA-Bind-Answer------->
(MIPv6-AAA-Key-Id)
<---------------------IKE for MIPv6 MSA--------------------------->
Jee, et al. Expires - April 2005 [Page 9]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
4.3.2 HA assignment in the visited domain
Mobile Node AAA Client HAv AAAv AAAh
----------- ---------- ----- ------ ------
+-----------------------+
|PANA Discovery & |
|initial handshake phase|
+-----------------------+
<--PANA-Auth-Request
---PANA-Auth-Answer--->
(User-Name, MIPv6-Bootstrap-Vector)
AMR------------------------------>
AMR------------>
<------------AMA
(MIPv6-AAA-Key-Id, MIPv6-AAA-Key,
PANA-AAA-Key, PANA-AAA-Key-Id)
<--------------HMR(MIPv6-AAA-Key)
HMA-------------->
<------------------------------AMA
(HA,HoA,MIPv6-AAA-Key-Id,
PANA-AAA-Key, PANA-AAA-Key-Id)
<--------------------PANA-Bind-Request
(HA,HoA,MIPv6-AAA-Key-Id,PANA-AAA-Key-Id)
PANA-Bind-Answer------->
(MIPv6-AAA-Key-Id)
<--------IKE for MIPv6 MSA--------->
Jee, et al. Expires - April 2005 [Page 10]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
4.4 MN Operation
When a MN bootstraps, it first performs a PANA Discovery and initial
handshake phase between the MN and the AAA Client. Detailed
description about this phase is described in [4].
After the MN receives a PANA-Auth-Request message from the AAA Client,
it sends a PANA-Auth-Answer message to request EAP authentication and
bootstrapping configuration to the AAA Client. The PANA-Auth-Answer
message contains the following AVPs.
User-Name AVP
MIPv6-Bootstrap-Vector AVP
Mobile-Node-Bootstrap-Requested flag set to '1'
EAP-Payload AVP
Upon receipt of a PANA-Bind-Request message from the AAA Client, the
MN SHOULD check the integrity of the PANA-Bind-Request message using
the message authentication code derived by the PANA-AAA-Key. The
PANA-AAA-Key is can be identified by the received PANA-AAA-Key-Id AVP
value. The calculation process of the message authentication code is
specified in [4]. Replay protection SHOULD be guaranteed by checking
the sequence numbers.
And then, the MN checks the EAP-Payload value to confirm that its EAP
authentication request is accepted.
If the authenticated request is accepted, the MN checks the flag
value of the MIPv6-Bootstrap-Vector AVP contained in the PANA-Bind-
Request message. If the Mobile-Node-Bootstrap-Requested flag is set
to '1', the MN sets its HA's address using the value of the MIPv6-
Home-Agent-Address AVP and sets its HoA using the value of the MIPv6-
Mobile-Node-Address AVP and choose the MIPv6-AAA-Key based on the
value of the MIPv6-AAA-Key-Id AVP.
After that, the MN sends a PANA-Bind-Answer message by attaching the
MIPv6-AAA-Key-Id AVP to the AAA Client. This PANA-Bind-Answer message
SHOULD contain message authentication code.
And then, the MN performs the IKE exchange to distribute the MIPv6
MSA using the IKE pre-shared key which is computed using the MIPv6-
AAA-Key. The method to compute the IKE pre-shared key for the MIPv6
MSA is described in the section 4.9.
4.5 AAA Client Operation
Upon receipt of the PANA-Auth-Answer message, the AAA Client checks
the validity of this message. If the message is a valid PANA message,
the AAA Client constructs a new diameter message, AMR using the
information contained in the PANA-Auth-Answer message.
Jee, et al. Expires - April 2005 [Page 11]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
The relationship between the PANA session and AAA session SHOULD be
managed in the AAA Client.
The main AVPs contained in the AMR message are as follows.
User-Name AVP
MIPv6-Bootstrap-Vector
Mobile-Node-Bootstrap-Requested flag set to '1'
EAP-Payload
Upon receipt of an AMA message, the AAA Client checks whether the EAP
authentication for the MN is succeeded. If the MN is authenticated,
the AAA Client updates its MN-specific attributes (MN's link-local-
address, PANA-AAA-Key). The AAA Client SHOULD keep the value of
MIPv6-AAA-Key-Id AVP to confirm that the same value is contained in
the upcoming PANA-Bind-Answer message.
The AAA Client SHOULD generate the message authentication code using
the PANA-AAA-Key. The calculation process of the message
authentication code is specified in [4]. The calculated value is set
to the MAC AVP. And then AAA Client produces the PANA-Bind-Request
message using the information contained in the AMA message. After
that, the AAA Client sends the PANA-Bind-Request message by attaching
the MAC AVP. This PANA-Bind-Request message contains the following
AVPs.
MIPv6-Bootstrap-Vector AVP
Mobile-Node-Bootstrap-Requested flag set to '1'
MIPv6-Home-Agent-Address AVP
MIPv6-Mobile-Node-Address AVP
MIPv6-AAA-Key-Id AVP
PANA-AAA-Key-Id AVP
EAP-Payload AVP
MAC AVP
When the AAA Client receives the PANA-Bind-Answer message from the MN,
it SHOULD perform the integrity checking the PANA-Bind-Answer message
using the message authentication code derived by the PANA-AAA-Key.
The PANA-AAA-Key can be identified the received PANA-AAA-Key-Id AVP
value. Replay protection SHOULD be guaranteed by checking the
sequence numbers. After that, the AAA Client checks the value of
MIPv6-AAA-Key-Id AVP with the value kept from the AMA message. These
Key-Ids SHOULD be the same value.
4.6 AAAv Operation
Upon receipt of the AMR message from the AAA Client, the AAAv first
verifies that the AMR message is sent from a valid AAA Client. If the
Jee, et al. Expires - April 2005 [Page 12]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
sender is valid, the AAAv checks the flag value contained in the
MIPv6-Bootstrap-Vector AVP.
If the Home-Address-Allocatable-Only-in-Home-Domain flag is set to
'1', the AAAv just delivers the AMR message to the AAAh.
If the Mobile-Node-Bootstrap-Requested flag is set to '1' and Home-
Address-Allocatable-Only-in-Home-Domain is set to '0', and the
Visited-Home-Agent-Available flag is set to '1', the AAAv also just
delivers the message to the AAAh. This case means that mult-round EAP
authentication process is being performed.
If the Mobile-Node-Bootstrap-Requested flag is set to '1' and Home-
Address-Allocatable-Only-in-Home-Domain flag is set to '0', and the
Visited-Home-Agent-Available flag is set to '0', the AAAv checks
whether it can allocate a HA for the MN in the visited domain or not.
If AAAv can allocate a HA in the visited domain, it sets the Visited-
Home-Agent-Available flag to '1'. After that, the AAAv sends the AMR
message to the AAAh.
When the AAAv receives an AMA message from the AAAh, the AAAv checks
the validity of the message. If the message is valid and the value of
EAP-Payload contained in this message indicates that the EAP
authentication is succeeded, the AAAv checks the flag value of the
MIPv6-Bootstrap-Vector AVP to decide whether the HA assignment should
be occurred in the visited domain.
If the Mobile-Node-Bootstrap-Requested flag is set to '1' and the
Home-Agent-in-Visited-Domain flag is set to '1', the AAAv should
perform the HA assignment in the visited domain. The way to assign a
HA for the MN will be described in the next version of this draft. If
the AAAv assigns the HAv, it sets the HAv's address to MIPv6-Home-
Agent-Address AVP and assigns a HoA for this MN. The assignment of
MN's HoA MAY be performed by the HAv. If the AAAv assigns the HoA, it
sets this address value to the MIPv6-Mobile-Node-Address AVP. And
then, AAAv sends the HMR message to the assigned HA containing the
MIPv6-AAA-Key AVP. After the AAAv receives the HMA message from the
HAv, it sends the AMA message to the AAA Client.
If the HA assignment process is not required, the AAAv simply
delivers the AMA message to the AAA Client.
4.7 AAAh Operation
Upon receipt of the AMR message from the AAAv, the AAAh first
verifies that the AMR message is sent from a valid AAAv. If the
sender is valid, the AAAh investigates the EAP-Payload AVP whether
its value is empty signifying an EAP-Start. If the value of EAP-
Payload AVP is empty, the AAAh starts the EAP authentication by
sending the AMA message containing an EAP-Payload AVP that includes
Jee, et al. Expires - April 2005 [Page 13]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
an encapsulated EAP packet and Result-Code AVP set to DIAMETER-MULTI-
ROUND-AUTH.
When the EAP authentication is succeeded, the AAAh investigates the
MIPv6-Bootstrap-Vector AVP.
If the Mobile-Node-Bootstrap-Requested flag is set to '1' and the
Home-Address-Allocatable-Only-in-Home-Domain flag is set to '1', the
AAAh assigns a HAh for the MN. The way to assign a HAh for the MN
will be described in the next version of this draft. If the AAAh
assigns the HAh, it sets the HAh's address to the MIPv6-Home-Agent-
Address AVP and assigns a HoA for this MN. The assignment of the MN's
HoA MAY be performed by the HAh. If the AAAh assigns the HoA, it sets
this address value to the MIPv6-Mobile-Node-Address AVP. After that,
the AAAh assigns the MIPv6-AAA-Key and its identifier, MIPv6-AAA-Key-
Id. And then, the AAAh assigns the PANA-AAA-Key and its identifier
PANA-AAA-Key-Id. The value of MIPv6-AAA-Key and PANA-AAA-Key SHOULD
not be equal. And then, AAAh sends the HMR message to the assigned
HAh which contains the following AVPs.
User-Name AVP
MIPv6-Bootstrap-Vector AVP
MIPv6-AAA-Key AVP
MIPv6-Mobile-Node-Address AVP
MIPv6-Home-Agent-Address AVP
When the AAAh receives the HMA message from the HA, it sends the AMA
message to the AAAv which contains the following AVPs.
MIPv6-Bootstrap-Vector AVP
MIPv6-Home-Agent-Address AVP
MIPv6-Mobile-Node-Address AVP
MIPv6-AAA-Key-Id AVP
PANA-AAA-Key AVP
PANA-AAA-Key-Id AVP
If the Mobile-Node-Bootstrap-Requested flag is set to '1' and the
Visited-Home-Agent-Available flag is set to '1', the AAAh sets the
Home-Agent-in-Visited-Domain flag to '1'. Even though the AAAh
doesn't assign the HA in the home domain, the AAAh SHOULD assign the
MIPv6-AAA-Key, the MIPv6-AAA-Key-Id, the PANA-AAA-Key and the PANA-
AAA-Key-Id. After that, the AAAh sends the AMA message to the AAAv
which contains the following AVPs.
MIPv6-Bootstrap-Vector AVP
MIPv6-AAA-Key AVP
MIPv6-AAA-Key-Id AVP
PANA-AAA-Key AVP
PANA-AAA-Key-Id AVP
Jee, et al. Expires - April 2005 [Page 14]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
4.8 HA Operation
Upon receipt of the HMR message, the HA checks the validity of the
HMR message. If the HR receives the valid HMR message, it checks the
flag value contained in the MIPv6-Bootstrap-Vector AVP. If the
Mobile-Node-Bootstrap-Requested flag is set to '1' and MIPv6-Mobile-
Node-Address AVP is not included in the HMR message, the HA assigns
the home address for the MN and includes this value to the MIPv6-
Mobile-Node-Address AVP. After that, the HA sends the HMA message to
the AAA server which contains the following AVPs.
MIPv6-Home-Agent-Address AVP
MIPv6-Mobile-Node-Address AVP
After sending the HMA message, the HA generates the IKE pre-shared
key to distribute MIPv6 MSA using value of MIPv6-AAA-Key AVP as
described in the section 4.9.
4.9 IKE Pre-shared key derivation
The method to drive the IKE pre-shared key using the AAA-Key is
provided in the [5] and the same method is used to derive the pre-
shared key for MIPv6 MSA.
The IKE pre-shared key for MIPv6 MSA = HMAC-SHA-1 (MIPv6-AAA-Key,
"MIPv6-IKE-PSK" | MIPv6-Key-Id | HoA | HA)
The HoA and HA address are used to derive the IKE pre-shared key. It
means that only the authenticated, authorized and bootstrapped MN can
negotiate the IKE exchange with the assigned HA.
Jee, et al. Expires - April 2005 [Page 15]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
5. Message Formats
5.1 PANA Messages
PANA-Auth-Answer ::= < PANA-Header: 3 [SEP] [NAP] >
< PANA-Session-Id >
< EAP-Payload >
[ User-Name ]
[ MIPv6-Boostrap-Vector ]
* [ AVP ]
0*1 < MAC >
PANA-Bind-Request ::= < PANA-Header: 4, REQ [SEP] [NAP] >
< PANA-Session-Id >
{ Result-Code }
{ PPAC }
[ EAP-Payload ]
[ Device-Id ]
[ Session-Lifetime ]
[ Protection-Capability ]
[ MIPv6-Bootstrap-Vector ]
[ MIPv6-Home-Agent-Address ]
[ MIPv6-Mobile-Node-Address ]
[ PANA-AAA-Key-Id ]
[ MIPv6-AAA-Key-Id ]
* [ EP-Device-Id ]
* [ AVP ]
0*1 < MAC >
PANA-Bind-Answer ::= < PANA-Header: 4 [,SEP] [NAP] >
< Session-Id >
{ Result-Code }
[ PPAC ]
[ Device-Id ]
[ PANA-AAA-Key-Id ]
[ MIPv6-AAA-Key-Id ]
* [ AVP ]
0*1 < MAC >
Jee, et al. Expires - April 2005 [Page 16]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
5.2 Diameter Messages
<AAA-MIPv6-Bootstrap-Request> ::= < Diameter Header: TBD, REQ, PXY >
< AAA-Session-ID >
{ Auth-Application-Id }
{ User-Name }
{ Destination-Realm }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ Auth-Grace-Period ]
[ Destination-Host ]
[ Origin-State-Id ]
{ EAP-Payload }
{ MIPv6-Bootstrap-Vector }
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
<AAA-MIPv6-Bootstrap-Answer> ::= < Diameter Header: TBD, PXY >
< AAA-Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Re-Auth-Request-Type ]
{ EAP-Payload }
{ MIPv6-Bootstrap-Vector }
[ PANA-AAA-Key ]
[ PANA-AAA-Key-Id]
[ MIPv6-AAA-Key]
[ MIPv6-AAA-Key-Id]
[ MIPv6-Home-Agent-Address ]
[ MIPv6-Mobile-Node-Address ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]
Jee, et al. Expires - April 2005 [Page 17]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
<HA-MIPv6-Bootstrap-Request> ::= < Diameter Header: TBD, REQ, PXY >
< AAA-Session-Id >
{ Auth-Application-Id }
{ Authorization-Lifetime }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ User-Name }
{ Destination-Realm }
[ Destination-Host ]
[ Auth-Grace-Period ]
{ MIPv6-Bootstrap-Vector }
{ MIPv6-AAA-Key }
[ MIPv6-Mobile-Node-Address ]
[ MIPv6-Home-Agent-Address ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
<HA-MIPv6-Bootstrap-Answer> ::= < Diameter Header: TBD, PXY >
< AAA-Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Error-Reporting-Host ]
[ Error-Message ]
[ MIPv6-Home-Agent-Address ]
{ MIPv6-Mobile-Node-Address }
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]
6. Security Considerations
The Mobile IPv6's bootstrapping configuration information must be
secured using integrity and replay protection [3]. In this document,
the MN's bootstrapping information, HoA, HA address and IKE pre-
shared keying material is delivered by the PANA-Bind-Request between
the MN and AAA Client. The PANA messages which are exchanged after
the EAP authentication is succeeded are cryptographically protected
by the PANA SA. This PANA SA provides the integrity protection based
on keyed message digest, replay protection based on sequence numbers
and data-origin authentication [4]. Therefore, the integrity and
Jee, et al. Expires - April 2005 [Page 18]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
replay protection of the bootstrapping configuration information is
guaranteed.
The link between the AAA Server and the HA SHOULD be protected by the
IPsec or TLS to securely transfer the security keying materials.
We RECOMMEND the use of different AAA-Keys for the PANA SA and MIPv6
MSA to minimize the security risks. If the same AAA-Key is used, the
disclosure of one key could result in the security threat to the
entire system.
7. Acknowledgments
Special thanks to Dooho Choi for his review and valuable comments
about this document.
8. References
8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[2] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko, J.,
"Diameter Base Protocol", RFC 3588, September 2003.
8.2 Informative References
[3] Patel, A., "Problem Statement for bootstrapping Mobile
IPv6", draft-ietf-mip6-bootstrap-ps-01 (work in progress),
October 2004.
[4] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., Yegin, A.,
"Protocol for Carrying Authentication for Network Access
(PANA)", draft-ietf-pana-pana-05 (work in progress), July
2004.
[5] Parthasarathy, M., "PANA enabling IPsec based Access Control",
draft-ietf-pana-ipsec-04.txt (work in progress), September
2004.
Jee, et al. Expires - April 2005 [Page 19]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
Author's Addresses
Junghoon Jee
Electronics and Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu, Daejon, 305-350
KOREA
Phone: +82 42 8605126
Email: jhjee@etri.re.kr
Jaehoon Nah
Electronics and Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu, Daejon, 305-350
KOREA
Phone: +82 42 8606749
Email: jhnah@etri.re.kr
Kyoil Chung
Electronics and Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu, Daejon, 305-350
KOREA
Phone: +82 42 8605074
Email: kyoil@etri.re.kr
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
Jee, et al. Expires - April 2005 [Page 20]
Internet Draft Diameter MIPv6 Bootstrapping Application October 2004
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jee, et al. Expires - April 2005 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-22 23:03:14 |