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 ::= < 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 ] ::= < 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 ] ::= < 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 ] ::= < 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]