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