Internet DRAFT - draft-jee-mip6-bootstrap-pana
draft-jee-mip6-bootstrap-pana
MIP6 Group J. Jee
Internet-Draft J. Nah
Expires: January 15, 2006 K. Chung
ETRI
July 14, 2005
Diameter Mobile IPv6 Bootstrapping Application using PANA
draft-jee-mip6-bootstrap-pana-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
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
Jee, et al. Expires January 15, 2006 [Page 1]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
configuration information like its home address, home agent address
and IKEv2/IKEv1 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 in
the integrated bootstrapping scenario are defined.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overall Architecture . . . . . . . . . . . . . . . . . . . . . 5
4.1 Basic Assumptions . . . . . . . . . . . . . . . . . . . . 5
4.2 Protocol Overview . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 7
5.1 AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 Command Codes . . . . . . . . . . . . . . . . . . . . . . 8
5.3 Message Sequence . . . . . . . . . . . . . . . . . . . . . 8
5.3.1 HA assignment in the home domain . . . . . . . . . . . 9
5.3.2 HA assignment in the visited domain . . . . . . . . . 10
5.3.3 MN Operation . . . . . . . . . . . . . . . . . . . . . 10
5.3.4 AAA Client Operation . . . . . . . . . . . . . . . . . 11
5.3.5 AAAv Operation . . . . . . . . . . . . . . . . . . . . 12
5.3.6 AAAh Operation . . . . . . . . . . . . . . . . . . . . 13
5.3.7 HA Operation . . . . . . . . . . . . . . . . . . . . . 15
5.3.8 IKEv2/IKEv1 Pre-shared key derivation . . . . . . . . 15
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 15
6.1 PANA Messages . . . . . . . . . . . . . . . . . . . . . . 16
6.2 Diameter Messages . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1 Normative References . . . . . . . . . . . . . . . . . . . 19
9.2 Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 21
Jee, et al. Expires January 15, 2006 [Page 2]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
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 [I-D.ietf-mip6-bootstrap-ps] 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 as specified in the [[I-D.ietf-mip6-bootstrap-ps].
PANA [I-D.ietf-pana-pana] 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 procedure 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 [I-D.ietf-pana-ipsec].
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 IKEv2/IKEv1 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 proposed bootstrapping mechanism 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
HAh: Home Agent in the home domain
Jee, et al. Expires January 15, 2006 [Page 3]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
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 [I-D.ietf-
pana-pana]. 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 [I-D.ietf-pana-ipsec].
AAA-Key: A key derived by the EAP peer and EAP server and transported
to the authenticator [I-D.ietf-pana-ipsec].
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 IPsec SA.
PANA-AAA-Key-Id: Identifier of PANA-AAA-Key.
MIPv6-AAA-Key-Id: Identifier of MIPv6-AAA-Key.
3. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Jee, et al. Expires January 15, 2006 [Page 4]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
4. Overall Architecture
Visited Domain Home Domain
+-------------------------------+ +--------------+
| | | |
| +--------+ +--------+ | | +--------+ |
| | | | | | | | | |
| | HAv +----| AAAv +-----|-------|--+ AAAh | |
| | +----| | | | | | |
| | | | | | | | | |
| +--------+ +--+--+--+ | | +--+--+--+ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
+------+ | +----+--+-----+ | | +--+--+--+ |
| MN |---|--------------| AAA Client | | | | HAh | |
| | | | (EP/PAA/AR) | | | | | |
+------+ | +-------------+ | | +--+--+--+ |
| | | |
+-------------------------------+ +--------------+
Figure 1: Overall Architecture
* 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 IKEv2/IKEv1 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 boostrapping scenario [I-D.ietf-mip6-bootstrap-ps]
is considered where the ASA and the MSA are the same.
4.1 Basic Assumptions
The communication channel between the AAA Client and the AAAv is
protected using TLS or IPsec as specified in [RFC3588].
The communication channel between the AAAv and the AAAh is protected
using TLS or IPsec as specified in [RFC3588].
The communication channel between the AAA Server and the HA SHOULD be
protected using TLS or IPsec.
EAP methods used for the MN's authentication SHOULD have capability
Jee, et al. Expires January 15, 2006 [Page 5]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
to derive dynamic session keys.
4.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 |
| |
|<---------------IKEv2/IKEv1 for IPSec SA------------------------->|
| |
+------------------------------------------------------------------+
Figure 2: Overall Architecture
The protocol consists of two phases.
1. Access network discovery and initial handshake phase.
2. Authentication and authorization phase for network access and
mobility service to grant the transfer of the MIPv6 boostrapping
information.
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.
Jee, et al. Expires January 15, 2006 [Page 6]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
The denoted AAA server acts as a role of both ASA(Access Service
Authorizer) and MSA(Mobility Service Authorizer). First, it acts as
a role of ASA by checking the MN's identity and its authorization
profile regarding the accessibility for the serving network.
Regarding the granted MNs, it checks whether the MN is requesting the
MIPv6 bootstrapping by checking the AVPs of AAA application messages.
If the MN is an authorized entity for mobility service, it assignes a
home address, home agent and security keying material.
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
and the AAA Client. The MIPv6-AAA-Key is used to derive the IKEv2/
IKEv1 pre- shared key for configuring the IPsec SA between the MN and
the HA.
5. Protocol Operations
5.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
Jee, et al. Expires January 15, 2006 [Page 7]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
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.
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.
5.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
5.3 Message Sequence
Jee, et al. Expires January 15, 2006 [Page 8]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
5.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)
<------------------IKEv2/IKEv1 for IPsec SA----------------------->
Figure 3: HA assignment in the home domain
Jee, et al. Expires January 15, 2006 [Page 9]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
5.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)
<-----IKEv2/IKEv1 for IPsec SA--->
Figure 4: HA assignment in the visited domain
5.3.3 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].
Jee, et al. Expires January 15, 2006 [Page 10]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
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 with 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.
5.3.4 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.
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
Jee, et al. Expires January 15, 2006 [Page 11]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
MIPv6-Bootstrap-Vector with 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 with 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.
5.3.5 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 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.
Jee, et al. Expires January 15, 2006 [Page 12]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
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.
5.3.6 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
an encapsulated EAP packet and Result-Code AVP set to DIAMETER-MULTI-
ROUND-AUTH.
When the EAP authentication is succeeded, the AAAh investigates the
Jee, et al. Expires January 15, 2006 [Page 13]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
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 January 15, 2006 [Page 14]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
5.3.7 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 IPsec SA using value of MIPv6-AAA-Key AVP as
described in the section 4.9.
5.3.8 IKEv2/IKEv1 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 IPsec SA.
The IKEv2/IKEv1 pre-shared key for IPsec SA = 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.
6. Message Formats
Jee, et al. Expires January 15, 2006 [Page 15]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
6.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 >
6.2 Diameter Messages
<AAA-MIPv6-Bootstrap-Request> ::= < Diameter Header: TBD, REQ, PXY >
< AAA-Session-ID >
{ Auth-Application-Id }
{ User-Name }
Jee, et al. Expires January 15, 2006 [Page 16]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
{ 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 ]
<HA-MIPv6-Bootstrap-Request> ::= < Diameter Header: TBD, REQ, PXY >
< AAA-Session-Id >
Jee, et al. Expires January 15, 2006 [Page 17]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
{ 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 ]
7. 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 January 15, 2006 [Page 18]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
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 which is used in deriving
the PANA SA and IKEv2/IKEv1 pre-shared key 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.
8. Acknowledgments
Special thanks to Dooho Choi, Alper Yegin, Hannes Tschofenig and
Julien Bournelle for their valuable comments about this document.
9. References
9.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
9.2 Informative References
[I-D.ietf-mip6-bootstrap-ps]
Patel, A., "Problem Statement for bootstrapping Mobile
IPv6", draft-ietf-mip6-bootstrap-ps-03 (work in progress),
July 2005.
[I-D.ietf-pana-ipsec]
Parthasarathy, M., "PANA Enabling IPsec based Access
Control", draft-ietf-pana-ipsec-07 (work in progress),
July 2005.
[I-D.ietf-pana-pana]
Forsberg, D., "Protocol for Carrying Authentication for
Network Access (PANA)", draft-ietf-pana-pana-09 (work in
progress), July 2005.
Jee, et al. Expires January 15, 2006 [Page 19]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
Authors' Addresses
Junghoon Jee
ETRI
161 Gajeong-dong, Yuseong-gu
Daejon, 305-350
KOREA
Phone: +82 42 8605126
Email: jhjee@etri.re.kr
Jaehoon Nah
ETRI
161 Gajeong-dong, Yuseong-gu
Daejon, 305-350
KOREA
Phone: +82 42 8606749
Email: jhnah@etri.re.kr
Kyoil Chung
ETRI
161 Gajeong-dong, Yuseong-gu
Daejon, 305-350
KOREA
Phone: +82 42 8605074
Email: kyoil@etri.re.kr
Jee, et al. Expires January 15, 2006 [Page 20]
Internet-Draft DIAMETER-BOOTSTRP-PANA July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jee, et al. Expires January 15, 2006 [Page 21]
