IETF pana WG Y. Kainuma Internet-Draft KEIO University Expires: December 3, 2005 N. Ono H. Hayashi BB Mobile/Japan Telecom F. Teraoka KEIO University June 2005 FPANA: combining PANA and FMIPv6 for fast authentication at handover draft-hiko-pana-fpana-00 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 December 3, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document proposes a fast authentication protocol called FPANA. A combination of PANA (for node authentication) and FMIP (for fast handover), it offers fast node authentication upon intra-domain handover of a mobile node. Since FPANA makes use of context transfer Kainuma, et al. Expires December 3, 2005 [Page 1] Internet-Draft fast PANA authentication June 2005 of the PANA session from the previous access router to the new access router by the HI message of FMIPv6, the PANA session can be set between the mobile node and the new access router prior to the mobile node moving to the new access router. Thus, the mobile node can continue authenticated communication upon intra-domain fast handover. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. PANA Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 PANA Session . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Message Sequence . . . . . . . . . . . . . . . . . . . . . 7 3.3 Problem Statement . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 4.1 Design Principles . . . . . . . . . . . . . . . . . . . . 9 4.2 Conditions . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3 Protocol Operation of Predictive Mode . . . . . . . . . . 11 4.4 Protocol Operation of Reactive Mode . . . . . . . . . . . 12 4.5 Getting PANA Session Attributes . . . . . . . . . . . . . 13 4.6 PANA Session Termination . . . . . . . . . . . . . . . . . 15 5. Definitions of Messages . . . . . . . . . . . . . . . . . . . 16 5.1 FPANA Option Header . . . . . . . . . . . . . . . . . . . 16 5.2 Message Format . . . . . . . . . . . . . . . . . . . . . . 17 5.3 FPANA Messages . . . . . . . . . . . . . . . . . . . . . . 20 6. Node Operation . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1 All Node Operation . . . . . . . . . . . . . . . . . . . . 23 6.2 Mobile Node Operation . . . . . . . . . . . . . . . . . . 23 6.3 Previous Access Router Operation . . . . . . . . . . . . . 24 6.4 New Access Router Operation . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7.1 MN-PAR security . . . . . . . . . . . . . . . . . . . . . 26 7.2 AR-AR security . . . . . . . . . . . . . . . . . . . . . . 26 7.3 Validity of transferring PANA session attributes . . . . . 26 8. Intellectual Property Right . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . 30 Kainuma, et al. Expires December 3, 2005 [Page 2] Internet-Draft fast PANA authentication June 2005 1. Introduction In the Internet, every mobile node should be authenticated prior to network access. If a mobile node moves to other subnet, it must be authenticated again. PANA (Protocol for carrying Authentication for Network Access) [1] is a protocol for authenticating clients that are trying to access the network. PANA needs the exchange of many messages between PaC (PANA client) and PAA (PANA Authentication Agent) for authentication. Since, PAA must execute full EAP authentication by requiring PaC's AAA server to verify PaC's authentication information, authentication via PANA takes a long time. Given that mobile nodes move frequently, smooth handover will be difficult because of delay imposed by PANA authentication. FPANA, the protocol proposed in this document, enables PANA authentication upon intra-domain handover to be greatly accelerated. To realize FPANA, a mobile node (including PaC) predicts the new access router (including PAA) by using FMIPv6 (Fast Handovers for MIPv6) [2]. The previous access router (including PAA) transfers the PANA session attributes to the new access router. Thus, the mobile node can keep the PANA session a live through the handover. Kainuma, et al. Expires December 3, 2005 [Page 3] Internet-Draft fast PANA authentication June 2005 2. Terminology Most of the terms are defined in the PANA [1] and FMIPv6 [2] specifications: MN: Mobile Node. A Mobile IPv6 host. AR: Access Router. The MN's default router. NAR: New Access Router. The router to which the MN is attached after the handover. PAR: Previous Access Router. The router to which the MN was attached before the handover. AAA: Authentication, Authorization and Accounting. AAAv: AAA server in the MN's visited domain. AAAh: AAA server in the MN's home domain. AAAc: AAA client. An AAAc requests the authentication and authorization of the MN to the backend AAA server. We assume that AAAc is collocated in AR. PANA Context: PANA session attributes shared between PAA and PaC. Kainuma, et al. Expires December 3, 2005 [Page 4] Internet-Draft fast PANA authentication June 2005 PANA CT: The operation of transferring PANA context from PAR to NAR. FPANA-FBU: The message used in FPANA. The extension message of the FBU message used in FMIPv6. Message detail is described in Section 5.3. FPANA-HI: The message used in FPANA. The extension message of the HI message used in FMIPv6. Message detail is described in Section 5.3. FPANA-HAck: The message used in FPANA. The extension message of the HAck message used in FMIPv6. Message detail is described in Section 5.3. FPANA-FBack: The message used in FPANA. The extension message of the FBack message used in FMIPv6. Message detail is described in Section 5.3. FPANA-FNA: The message used in FPANA. The extension message of the FNA message used in FMIPv6. Message detail is described in Section 5.3. FPANA-NAack: The message used in FPANA. The extension message of the NAack message used in FMIPv6. Message detail is described in Section 5.3. Kainuma, et al. Expires December 3, 2005 [Page 5] Internet-Draft fast PANA authentication June 2005 3. PANA Overview PANA (Protocol for Carrying Authentication for Network Access) [1] is an authentication protocol for network access. This section describes how PANA authenticates nodes and what problems are caused by PANA authentication. It is assumed that some AAA protocol is executed in the back-end. 3.1 PANA Session To start PANA authentication, a PANA session must be established between a PaC and a PAA. The PaC and the PAA share authentication information through the PANA session. The PANA session has a lifetime, if this lifetime expires, re-authentication must be executed to continue communication. In the PANA session, the PaC and the PAA exchange the following information to complete authentication. -Session-Id -Device-Id of PaC -IP address and UDP port number of PaC -IP address of PAA -List of device identifiers of EPs -Sequence number of the last transmitted request -Sequence number of the last received request -Last transmitted message payload -Retransmission Interval -Session Lifetime -Protection-Capability -PANA SA attributes +Nonce generated by PaC +Nonce generated by PAA Kainuma, et al. Expires December 3, 2005 [Page 6] Internet-Draft fast PANA authentication June 2005 +AAA-Key +AAA-Key identifier +PANA_MAC_KEY A PANA session consists of distinct phases. The PaC initiates a PANA session in the "discovery and handshake phase". The PaC and the PAA execute EAP authentication in the "authentication and authorization phase". After the PaC succeeds in authentication and gains access to the network, the PaC and the PAA maintain the PANA session in the "access phase". The PaC and the PAA exchange attributes in the "discovery and handshake phase" and the "authentication and authorization phase". The PaC and the PAA share all attributes shown above, and the PANA session then enters the "access phase". 3.2 Message Sequence The PANA messages are sent to create and maintain the PANA session. The PANA messages contain some information in the form of AVP. The PANA session attributes shown above are also exchanged in the form of AVP. Figure 1 depicts the message flow of authentication in PANA. PaC PAA PaC's AAAh | Message ----------------------------+--------------------------- // Discovery and | handshake phase | ------> | PANA-PAA-Discover | <------ | PANA-Start-Request ------> | PANA-Start-Answer | // Authentication and | authorization phase | <------ | PANA-Auth-Request | (including EAP Request) ------> | PANA-Auth-Answer ------> | PANA-Auth-Request | (including EAP Response) <------ | PANA-Auth-Answer | ------------> | EAP Request <------------ | EAP Response | <------ | PANA-Bind-Request | (including EAP Success) ------> | PANA-Bind-Answer Kainuma, et al. Expires December 3, 2005 [Page 7] Internet-Draft fast PANA authentication June 2005 Figure 1: Authentication message flow in PANA First, the PaC multicasts the PANA-PAA-Discover message to discover a PAA. The PAA that receives the PANA-PAA-Discover message sends the PANA-Start-Request message to the PaC to start a PANA session. The EAP Request and EAP Response messages are included in the PANA-Auth- Request message. After the PaC sends the PANA-Auth-Answer message, the PaC sends own authentication information to the PAA in the PANA- Auth-Request message. After the PAA sends the PANA-Auth-Answer message to the PaC, the PAA must verify PaC's EAP Response by polling the PaC's AAAh in the home domain. If the AAAh sends the EAP Success message to the PAA, the PAA sends the PANA-Bind-Request message to inform the PaC that authentication has succeeded. 3.3 Problem Statement According to the above explanation, authentication in PANA involves the exchange of a lot of messages. Furthermore, the inquiry to the AAAh experiences long round trip times. The further the PaC is from the home domain, the longer the round trip time of the inquiry to the AAAh will be. This round trip time will be so large that the PaC may be continuing communication after the PaC's handover. Thus, for nodes that move frequently, communication may be interrupted because of the large delay caused by authentication. This is significant barrier to the practical use of PANA. Kainuma, et al. Expires December 3, 2005 [Page 8] Internet-Draft fast PANA authentication June 2005 4. Protocol Overview 4.1 Design Principles When authentication is completed in the PANA session, all session attributes denoted in Section 3.1 are shared between PAA and PaC, and the session phase is changed to the "access phase". The MN(PaC) can send and receive packets through the EP only when the PANA session is in the access phase. For seamless handover, it is necessary for the NAR(nPAA) and the MN to establish a PANA session in the access phase. In order to reduce this establishment time, FPANA operates in such a way that the PAR transfers PANA session attributes, already negotiated between the PAR(pPAA) and the MN, to the NAR. The authenticated state on the PAR can be carried over to the NAR by using FPANA without a new inquiry to the AAA server. In FPANA, the PAR should decide to which AR the context is to be transferred and when the context transfer should start. FMIPv6 is utilized to achieve these goals. Even if fast authentication is achieved, an L3 fast handover mechanism is necessary for seamless communications. FMIPv6 is also employed for this purpose. Moreover, using FMIPv6 messages to transfer PANA session attributes and using information from FMIPv6 to establish the new access phase of PANA session, means that PANA authentication can be finished with minimal message exchange compared to performing PANA and FMIPv6 sequentially. 4.2 Conditions FPANA architecture is the integration of PANA architecture with AAA architecture as denoted in Figure 2. Kainuma, et al. Expires December 3, 2005 [Page 9] Internet-Draft fast PANA authentication June 2005 +-------Visited Domain------+ +-Home Domain--+ | +-------+ | +----------+ | +------+ | | | AAAv |<------+-| Internet |-+-->| AAAh | | | +---+---+ | +----------+ | +---+--+ | | | | | | | | --+-----+------+-- | | | | | | | | | | | | +-------+-------+ | | | | | | | AR +--+-+ | +--+--+ | | +--+-+ | | | |AAAc| | | AR | | | | AR | | | | +----+ | +-----+ | | +----+ | | | +----+ +----+ | | +--------------+ | | |PAA | | EP | | | | | +----+ +----+ | | | +-------+-------+ | | | | | +---+---+ | | |MN | | | |+-----+| | | || PaC || | | |+-----+| | | +-------+ | +---------------------------+ Figure 2: FPANA Architecture By way of example, DIAMETER is used as the AAA backend protocol to poll the AAA server about EAP authentication information. AAAc, PAA and EP must be collocated in an AR, and PaC must be collocated in an MN, in order to collect some IDs and IP addresses which are some of the PANA session attributes for easy and rapid authentication (See Section 4.5.2). The following conditions must be met for FPANA operation: -A specific AAA backend infrastructure (e.g., using DIAMETER) must be present. -AAAc, PAA, and EP must reside in the same AR. -Communications between AAAv and AAAh and between PAR and NAR must be secure (e.g., through the use of IPsec). The PANA session parameters are called "the PANA context", and the Kainuma, et al. Expires December 3, 2005 [Page 10] Internet-Draft fast PANA authentication June 2005 operation of transferring the PANA context is called "context transfer (CT)". In order to protect context transfer, communications between a PAR and an NAR must be secure (e.g., through the use of IPsec). Since it is difficult to establish a secure channel between ARs of different administrative domains in advance, FPANA is more applicable for MNs that move within the same administrative domain. 4.3 Protocol Operation of Predictive Mode For realizing FPANA, the messages and the functionality defined in FMIPv6 are extended with additional messages related to PANA CT. FPANA has two operation scenarios, "Predictive mode" and "Reactive mode", that are the same as FMIPv6. In the former case, FMIP tunnel is established and the PANA CT is achieved before an MN attaches to the NAR. In the latter case, an FMIP tunnel establishment and the CT are performed after the MN attaches to the NAR. In "Predictive mode", the MN sends the FPANA-FBU message and receives the FPANA-FBack message on the PAR's link. Predictive mode operation is illustrated in Figure 3. "RtSolPr", "PrRtAdv", "Hi", "HAck", "FBack", "FNA", and "NAack" are the messages of FMPIv6. "PANA-PAA- Discovery", "PANA-Bind-Request", and "PANA-Bind-Answer" are the PANA messages. To determine which AR the MN will move to, the MN sends the RtSolPr message to the PAR and the PAR responds with the PrRtAdv message in the same manner as FMIPv6 (1,2). The MN decides the target AR (NAR) and sends the FBU message to the PAR requesting PANA CT (FPANA-FBU) (3). The PAR knows that the MN wants to perform FPANA, and so includes the MN's PANA session attributes in the HI message and sends it to the NAR (FPANA-HI) (4). Details of the transfer of PANA session attributes are clarified in Section 4.5. The NAR receives the FPANA-HI message and sends the HAck message to the PAR with the result of PANA CT (success/failure) (FPANA-HAck) (5). The PAR sends the FPANA-FBack message to the MN and the NAR in order to relay the PANA CT result (6). After receiving the FPANA-FBack message, the MN drops the PAR's link. If the result is "success", the MN sends the FPANA-FNA message to notify the NAR of a new session as soon as the MN attaches to the NAR (7). The NAR sends the PANA-Bind-Request message to the MN to confirm the new PANA session attributes (8). Lastly, the MN sends the PANA-Bind-Answer message to the NAR (9) and new PANA session are established in the access phase. If PANA CT results in "failure" when the PAR sends the FPANA-HI message including PANA session attributes, the NAR indicates the failure in FPANA-Hack and the PAR relays this to the MN. In that Kainuma, et al. Expires December 3, 2005 [Page 11] Internet-Draft fast PANA authentication June 2005 case, after attaching to the NAR, the MN initiates the full PANA process. MN PAR NAR | (1)RtSolPr | | |------------------------>| | | (2)PrRtAdv | | |<------------------------| | | (3)FBPANA-FBU | | | (Request of PANA CT) | | |------------------------>| | | |(4)FPANA-HI | | |(PANA Session Attributes)| | |------------------------>| | |(5)FPANA-HAck | | | (PANA CT Result) | | |<------------------------| |(6)FPANA-FBack |(6)FPANA-FBack | | (PANA CT Result) | (PANA CT Result) | |<------------------------|------------------------>| ~ | | disconnect from PAR | | connect to NAR | | ~ | | | (7)FPANA-FNA | |-------------------------|------------------------>| | (8)PANA-Bind-Request | |<------------------------|-------------------------| | (9)PANA-Bind-Answer | |-------------------------|------------------------>| Figure 3: Operation in Predictive Mode 4.4 Protocol Operation of Reactive Mode If an MN does not receive the FPANA-FBack message on the PAR's link, it enters the "Reactive mode". Reactive mode operation is illustrated in Figure 4. The RtSolPr message and the PrRtAdv message are sent in the same manner as FMIPv6 (1,2). After connecting to the NAR, the MN sends the FPANA-FNA message including the FPANA-FBU message to the NAR to indicate the start of FPANA (3). The NAR extracts the FPANA-FBU message from the FPANA-FNA message and sends it with the request of PANA CT to the PAR (FPANA-FBU) (4). The PAR prepares the PANA session attributes of the MN and sends the FPANA-FBack message including those attributes to the NAR (5). The NAR receives it and Kainuma, et al. Expires December 3, 2005 [Page 12] Internet-Draft fast PANA authentication June 2005 extracts the PANA session attributes. If PANA CT completes successfully, the NAR sends the FPANA-FBack message includeing some AVPs which are conventionally contained in the original PANA-Bind- Request message, to the MN (6). If the FPANA-FBack message contains the Result Code AVP without the AVPs of the original PANA-Bind- Request message, the MN knows that PANA CT has not been achieved and initiates the full PANA process. Even if the MN receives the FPANA- NAack message from the NAR in the case that the new care-of address of the MN is not available, the MN also initiates the full PANA process. In the case that the MN receives the FPANA-FBack message including the AVPs of the PANA-Bind-Request message, the MN responds by sending the PANA-Bind-Answer message to NAR (7), and a new PANA session between the MN and the NAR will be established in the access phase. MN PAR NAR | (1)RtSolPr | | |------------------------>| | | (2)PrRtAdv | | |<------------------------| | ~ | | disconnect from PAR | | connect to NAR | | ~ | | | (3)FPANA-FNA(FPANA-FBU) | |-------------------------|------------------------>| | |(4)FPANA-FBU | | | (PANA CT Request) | | |<------------------------| | |(5)FPANA-FBack | | |(PANA Session Attributes)| | |------------------------>| | (6)FPANA-FBack(PANA Bind Request) | |<------------------------|-------------------------| | (7)PANA-Bind-Answer | |-------------------------|------------------------>| Figure 4: Operation in Reactive Mode 4.5 Getting PANA Session Attributes In order to establish a PANA session in the access phase between an NAR and an MN, almost all PANA session attributes denoted in Section 3.1 must be set in the NAR and the MN. However, it isn't necessary to transfer all these parameters because some of the parameters must be changed or can be gained from FMIPv6 messages. Kainuma, et al. Expires December 3, 2005 [Page 13] Internet-Draft fast PANA authentication June 2005 4.5.1 Transfer Attributes FPANA transfers the following PANA session attributes via AVP: -Retransmission Interval -Session Lifetime -PANA_MAC_KEY -Nonce generated by PaC (PaC_nonce) -Nonce generated by PAA (PAA_nonce) -ISP's Information FPANA transfers some of the PANA session attributes such as "Session lifetime", "PaC_nonce", "PAA_nonce", "PANA_MAC_KEY" and "Retransmission interval". Although the NAR and MN use the same PANA_MAC_KEY as the previous session, security is maintained by carrying over the "Session lifetime" from the previous session. It is not necessary to transfer "AAA-Key" and "AAA-Key Identifier" because they are data of PANA_MAC_KEY. In the re-authentication phase of PANA, PaC and PAA do not exchange nonces, so that "PaC_nonce" and "PAA_nonce" must be transferred. FPANA transfers information beyond the PANA session attributes such as "ISP's information". "ISP's information" is used in the re- authentication phase of PANA to decide which AAA server the MN should go to for MN's authentication information. 4.5.2 Attributes gained from FMIPv6 When PaC is collocated in the MN, the MAC address of the MN may be utilized as "Device-Id of PaC", and the IP address of the MN may be the same as the "IP address of PaC". In predictive mode, the NAR gets these two attributes from the HI message of FMIPv6 in the options field (Figure 5): "Link-layer address of MN Option" and "New Care of Address Option". In reactive mode, the NAR gets the two attributes from the FPANA-FNA message. "Device-ID of PaC" is in the Mobility options field: "MH (Mobile Host)-LLA (Link Layer Address) option". "IP address of PaC" is in the source address field. When EP and PAA are collocated in the AR, the MAC address of an NAR may be utilized as "Device identifier of EP", and the IP address of a NAR may be the same as the "IP address of PAA", so the MN gets these two parameters from the PrRtAdv message of FMIPv6 in the fields of Kainuma, et al. Expires December 3, 2005 [Page 14] Internet-Draft fast PANA authentication June 2005 "New Router's Link-layer Address Option" and "New Router's IP Address Option". In order to get the above attributes from FMIPv6 messages, PaC must be collocated in the MN, and EP and PAA must be collocated in the AR. 4.5.3 Other Method "Session-Id" is shared between the NAR and the MN by the PANA-Bind- Request message, because it is created by combining the NAR (PAA)'s ID and the MN (PaC)'s ID, and so represents a change from the previous one. "Sequence number of last transmitted/received request" and "Last transmitted message payload" are initialized by exchanging the PANA-Bind-Request/Answer messages. 4.6 PANA Session Termination The lifetime of the PANA session between the PAR and MN may change to FMIP's tunnel lifetime when an FMIP tunnel is established. When this lifetime expires, the previous PANA session is also terminated. This termination reduces PAR's resource consumption and the risk of being attacked. At the same time, the MN achieves low packet losses, because MN's new MIPv6 binding has already established when previous PANA session is shut down according to the FMIP's tunnel lifetime. Kainuma, et al. Expires December 3, 2005 [Page 15] Internet-Draft fast PANA authentication June 2005 5. Definitions of Messages FPANA extends the FMIPv6 messages to achieve high-speed authentication. This section illustrates the new option and message formats used in FPANA. 5.1 FPANA Option Header FPANA defines the FPANA option header to append AVPs to the FMIPv6 messages. AVPs carried in the FPANA messages are appended in the FPANA option header. Figure 5 illustrates the format of the FPANA option header. +--------------+--------------+--------------+--------------+ | type | length | FPANA-transaction-ID | +--------------+--------------+--------------+--------------+ | message-type | reserved | +--------------+--------------+--------------+--------------+ | | ~ AVPs... ~ | | +--------------+--------------+--------------+--------------+ Figure 5: The format of FPANA Option Header type: Type field identifies which option is appended. The value of the type field is undecided: TYPE-FPANA: undecided length: Length field indicates option length including all fields of the FPANA option header. FPANA-transaction-ID: FPANA-transaction-ID is instantiated with the FPANA-FBU message (predictive mode) or the FPANA-FNA message (reactive mode) by the MN. This value is consistent throughout FPANA operation. Kainuma, et al. Expires December 3, 2005 [Page 16] Internet-Draft fast PANA authentication June 2005 message-type: Message type field identifies which message this option is appended to. Following list shows the correspondence between the FPANA messages and the value of the message-type field: FPANA-FBU: 1 FPANA-HI: 2 FPANA-HAck: 3 FPANA-FBack: 4 FPANA-FNA: 5 FPANA-NAack: 6 reserved: Reserved field is reserved for future work. 5.2 Message Format Some FPANA messages make use of some bits in the reserved field to distinguish FPANA messages from original FMIPv6 and PANA messages. Figures 6-8 illustrate the formats of the FPANA messages. "F" bit in Figures 6-8 indicates the FPANA bit that distinguishes FPANA messages from origial FMIPv6 and PANA messages. Kainuma, et al. Expires December 3, 2005 [Page 17] Internet-Draft fast PANA authentication June 2005 +--------------+--------------+--------------+--------------+ | | + + | | + + | IP header | + + | | + + | | +--------------+--------------+--------------+--------------+ | ICMP header | + +------------+-+ + | | reserved |F| | +--------------+------------+-+--------------+--------------+ | | ~ options ~ | | +--------------+--------------+--------------+--------------+ | | + FPANA option header + | | +--------------+--------------+--------------+--------------+ | | ~ AVPs ~ | | +--------------+--------------+--------------+--------------+ Figure 6: The format of FPANA message using ICMP header Kainuma, et al. Expires December 3, 2005 [Page 18] Internet-Draft fast PANA authentication June 2005 +--------------+--------------+--------------+--------------+ | | + + | | + + | IP header | + + | | + + | | +--------------+--------------+--------------+-+------------+ | |F| reserved | + +-+------------+ | mobility header | + + | | +--------------+--------------+--------------+--------------+ | | ~ mobility options ~ | | +--------------+--------------+--------------+--------------+ | | + FPANA option header + | | +--------------+--------------+--------------+--------------+ | | ~ AVPs ~ | | +--------------+--------------+--------------+--------------+ Figure 7: The format of FPANA-FBack message Kainuma, et al. Expires December 3, 2005 [Page 19] Internet-Draft fast PANA authentication June 2005 +--------------+--------------+--------------+--------------+ | | + + | | + + | IP header | + + | | + + | | +--------------+--------------+--------------+-+------------+ | |F| reserved | + +-+------------+ | mobility header | + + | | +--------------+--------------+--------------+--------------+ | | ~ mobility options ~ | | +--------------+--------------+--------------+--------------+ | | + FPANA option header + | | +--------------+--------------+--------------+--------------+ Figure 8: The format of FPANA-FBU and FPANA-FNA message 5.3 FPANA Messages This section describes details of each FPANA message. Some messages of FMIPv6 and PANA remain unchanged while some are extended for context transfer. RtSolPr: The RtSolPr message in FMIPv6 is unchanged. PrRtAdv: The PrRtAdv message in FMIPv6 is unchanged. Kainuma, et al. Expires December 3, 2005 [Page 20] Internet-Draft fast PANA authentication June 2005 FPANA-FBU: The FPANA-FBU message is an extension of the FMIPv6 message. This message can be distinguished from the original FBU message by the "F" bit in the mobility header in Figure 8. The FPANA option header is appended but AVPs are not. FPANA-HI: The FPANA-HI message is an extension of the FMIPv6 message. This message can be distinguished from the original HI message by the "F" bit in the ICMP header in Figure 6. This message carries the PANA session attributes in the form of AVP. AVPs are appended following the FPANA option header. Details of the attributes contained in this message are described in Section 4.5.1. FPANA-HAck: The FPANA-HAck message is an extension of the FMIPv6 message. This message can be distinguished from the original HAck message by the "F" bit in the ICMP header in Figure 6. This message contains the Result Code AVP to inform whether context transfer succeeded. FPANA-FBack: The FPANA-FBack message is an extension of the FMIPv6 message. This message can be distinguished from the original FBack message by the "F" bit in the mobility header in Figure 7. If predictive mode is executed, the FPANA option header and the Result Code AVP are appended. If reactive mode is executed, this message is sent to NAR; it carries the PANA session attributes in the form of AVP. AVPs are appended following the FPANA option header. The attributes contained in this message are described in Section 4.5.1. When sent to the MN, it contains AVPs which are conventionally contained in the original PANA-Bind-Request message to start a new PANA session. Kainuma, et al. Expires December 3, 2005 [Page 21] Internet-Draft fast PANA authentication June 2005 FPANA-FNA: The FPANA-FNA message is an extension of the FMIPv6 message. This message can be distinguished from the original FNA message by the "F" bit in the mobility header in Figure 8. The FPANA option header is appended but AVPs are not. FPANA-NAack: The FPANA-NAack message is an extension of the FMIPv6 message. This message can be distinguished from the original NAack message by the "F" bit in the ICMP header in Figure 6. If address collision is detected by the NAR in reactive mode, the FPANA-NAack message, which contains Result Code AVP, is sent to the MN. This message indicates that the FPANA operation failed and the remaining operations were not executed. PANA-Bind-Request: The PANA-Bind-Request message in PANA is unchanged. This message contains a new Session-Id calculated by the NAR and the MAC derived from the transferred PANA_MAC_KEY. PANA-Bind-Answer: The PANA-Bind-Answer message in PANA is unchanged. Kainuma, et al. Expires December 3, 2005 [Page 22] Internet-Draft fast PANA authentication June 2005 6. Node Operation MN, PAR and NAR are the main nodes in FPANA. This section describes protocol operation of each node. In this section, operations just for FMIPv6 are omitted. 6.1 All Node Operation A message in which the "F" flag is not set should be considered as the original FMIPv6 message. If a node receives a message in which the "F" flag is not set, conventional FMIPv6 or PANA operation is executed. 6.2 Mobile Node Operation When the MN detects the radio signal of a new AP, it sends the RtSolPr message to the PAR to get the NAR's information. After the MN receives the PrRtAdv message from the PAR as a response of the RtSolPr message, which contains NAR's network prefix, NAR's IP address and NAR's MAC address, the MN derives a new CoA from NAR's network prefix. At this moment, NAR's information contained in the PrRtAdv message are retained as the new PANA session attributes. The MN sends the FPANA-FBU message to inform the PAR of the new CoA, and the MN waits for a response. If the MN can send the FPANA-FBU message across the PAR's link, predictive mode will be executed. If the MN cannot send the FPANA-FBU message across the PAR's link or the MN cannot receive the FPANA-FBack message on the PAR's link, reactive mode will be executed. The MN can learn whether context transfer succeeded or not by checking the Result Code AVP contained in the FPANA-FBack message. If predictive mode is executed, after MN handover, the MN first informs the NAR that the MN has moved to NAR by sending the FPANA-FNA message. After the MN receives the PANA-Bind-Request message as the response of the FPANA-FNA message, the MN checks validity of the PANA-Bind-Request message using the PANA_MAC_KEY shared with the PAR. If the PANA-Bind-Request message is valid, the MN sends the PANA- Bind-Answer message to the NAR and authentication is complete. If reactive mode is executed, the FPANA-FNA message contains an encapsulated FPANA-FBU message. The MN receives the FPANA-FBack message as a response of the FPANA-FNA message. If PANA CT was successful, this FPANA-FBack message contains the AVPs that are conventionally contained in the PANA-Bind-Request message. If PANA CT was not successful, this FPANA-FBack message contains only Result Code AVP which indicates that PANA CT was not successful. Kainuma, et al. Expires December 3, 2005 [Page 23] Internet-Draft fast PANA authentication June 2005 6.3 Previous Access Router Operation When the PAR receives the RtSolPr message from the MN, the PAR sends the PrRtAdv message containing NAR's information, which corresponds to the AP indicated in the RtSolPr message. When the PAR receives the FPANA-FBU message, it transfers the PANA session attributes to the NAR, and establishes a binding between the MN's previous CoA and the new CoA. Additionally, the session lifetime of the previous PANA session with the MN is set to the lifetime of the binding. If the FPANA-FBU message is sent by the MN, predictive mode is executed and the PAR transfers the PANA session attributes to the NAR by the FPANA-HI message. The PAR receives the FPANA-HAck message and can learn whether context transfer succeeded or not by the Result Code AVP contained in the FPANA-HAck message. Finally, the PAR sends the FPANA-FBack message to the MN and the NAR. The FPANA-FBack message contains Result Code AVP which is the same as that of the FPANA-HAck message. If the FPANA-FBU message is sent by the NAR, reactive mode is executed and the PAR transfers the PANA session attributes to the NAR by the FPANA-FBack message. 6.4 New Access Router Operation If predictive mode is executed, the NAR receives the FPANA-HI message from the PAR. MN's new CoA and MAC address and transferred PANA session attributes are retained as the new PANA session attributes. The NAR informs the PAR as to whether the NAR received all PANA session attributes by the FPANA-HAck message. When the NAR receives the FPANA-FBack message from the PAR, the NAR's operations prior to the MN handover are completed, and the NAR waits for the FPANA-FNA message from the MN. When the NAR receives the FPANA-FNA message, the NAR learns that the MN has attached to the NAR's link. The NAR then establishes a new PANA session with the MN by using MN's information and the PANA session attributes contained in the FPANA-HI message. The NAR sends the PANA-Bind-Request message to inform the MN that the new PANA session between the NAR and the MN has been established. Finally, the NAR receives the PANA-Bind-Answer message from the MN in response to the PANA-Bind-Request message. The NAR verifies the PANA-Bind-Answer message by checking the validity of the MAC AVP contained in the FPANA-HI message using the PANA_MAC_KEY. If the PANA-Bind-Answer message is valid, MN's authentication is done. If reactive mode is executed, the NAR receives the FPANA-FNA message including the FPANA-FBU message from the MN. MN's MAC address and MN's new CoA are retained as the new PANA session attributes. The NAR extracts the FPANA-FBU message from the FPANA-FNA message, and Kainuma, et al. Expires December 3, 2005 [Page 24] Internet-Draft fast PANA authentication June 2005 then sends the extracted FPANA-FBU message to the PAR. When the NAR receives the FPANA-FBack message from the PAR, the PANA session attributes contained in the FPANA-FBack message are retained as the new PANA session attributes. The NAR then sends the FPANA-FBack message to the MN. This FPANA-FBack message contains the AVPs that are conventionally contained in the PANA-Bind-Request message. Subsequent operations are the same as those of predictive mode. Kainuma, et al. Expires December 3, 2005 [Page 25] Internet-Draft fast PANA authentication June 2005 7. Security Considerations In FPANA, there may be some security vulnerabilities. This section describes the security vulnerabilities and solutions. 7.1 MN-PAR security In FPANA, a PANA SA must be established between the MN and the PAR before MN handover. Otherwise, there is no PANA context to transfer from PAR to NAR and PANA CT can not be executed. A PANA SA means that the MN and the PAR have a relationship of mutual trust. That is, spoofing of PAR can be avoided. In addition, another security association must be established between the MN and the PAR before MN handover. All traffic including the FPANA messages between the MN and the PAR must be protected. The effect of a PANA SA is limited to just the PANA messages, so another security association (e.g. IPsec SA) to protect the FPANA messages is needed. The protected FPANA-FBU message realized by the security association between MN and PAR secures the initiation of FPANA operation. 7.2 AR-AR security To realize FPANA, the PANA session attributes must be transferred between ARs. If any packets exchanged between ARs are tampered or eavesdropped, authentication may result in failure. To protect all packets exchanged between ARs, a security association must be established between the ARs. If security association is established, integrity and confidentiality of packets exchanged between ARs are ensured. In particular, the FPANA messages containing the PANA session attributes such as the FPANA-HI message and the FPANA-FBack message must be protected (e.g. by IPsec ESP). A security association between ARs also prevent transfer to a malicious NAR. Establishing a security association between ARs predictively makes it possible to transfer the PANA session attributes without requiring prior authentication of other AR. It may be possible to establish a security association between ARs predictively. Since FPANA supports only intra-domain handover, ARs which must establish security association are limited to those in the same domain. ARs in the same domain are managed by the same administration policy, so it is just conceivable that security associations are established between all neighbor ARs in the same domain predictively. 7.3 Validity of transferring PANA session attributes In FPANA, the PANA_MAC_KEY itself is transferred between ARs. That Kainuma, et al. Expires December 3, 2005 [Page 26] Internet-Draft fast PANA authentication June 2005 is, the same PANA_MAC_KEY is used for the PANA SA before and after MN handover. All transferred PANA session attributes including PANA_MAC_KEY are protected as noted above. Furthermore, the session lifetime is transferred between ARs, so any degradation of the PANA_MAC_KEY's reliability is carried over after MN handover. Re- authentication will be executed if the session lifetime is expired, so the safety of the PANA_MAC_KEY can be ensured. FPANA performs no confirmation of MN's authorization after the handover. Since the handover is limited to AR's in the same administrative domain, MN's authorization is not changed by handover. Kainuma, et al. Expires December 3, 2005 [Page 27] Internet-Draft fast PANA authentication June 2005 8. Intellectual Property Right There are formats and mechanisms included in the following pending patent application that has been FILED to the Japanese Patent office. -Japanese application No.2005-093049 Keio University, Japan Telecom This includes the combining mechanisms of PANA CT and FMIPv6 and the formats of the messages. It must be stressed that it has only been filed, and has not been granted. We really intend to contribute to the development of the Internet community and to keep a good relationship with IETF. Our primary concern is to promote our technology so that others may feel it is useful and worthwhile in the spirit of IETF. If indeed the mechanisms and formats are granted as patents, the patents will be licensed under reasonable and non- discriminatory conditions to any person who wants to implement the mechanisms. 9. References [1] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-08 (work in progress), May 2005. [2] Koodli, R., Dommety, G., Malki, K., Khalil, M., Perkins, C., Soliman, H., Tsirtsis, G., and A. Yegin, "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-03 (work in progress), October 2004. Authors' Addresses Yoshihiko Kainuma Graduate School of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan Phone: +81-45-566-1425 Email: hiko@tera.ics.keio.ac.jp URI: http://www.tera.ics.keio.ac.jp/ Kainuma, et al. Expires December 3, 2005 [Page 28] Internet-Draft fast PANA authentication June 2005 Natsuko Ono R&D Center, BB Mobile Corp. 1-9-1 Higashi-shimbashi Minato-ku, Tokyo 105-7304 Japan Phone: +81-3-6889-2144 Email: naono@softbank.co.jp and Laboratories, Japan Telecom Co., Ltd. 1-9-1 Higashi-shimbashi Minato-ku, Tokyo 105-7316 Japan Phone: +81-50-2019-3753 Email:natsuko.ono@japan-telecom.co.jp URI: http://www.japan-telecom.co.jp/ Hideki Hayashi R&D Center, BB Mobile Corp. 1-9-1 Higashi-shimbashi Minato-ku, Tokyo 105-7304 Japan Phone: +81-3-6889-2144 Email: hidhayas@softbank.co.jp and Laboratories, Japan Telecom Co., Ltd. 1-9-1 Higashi-shimbashi Minato-ku, Tokyo 105-7316 Japan Phone: +81-50-2019-5347 Email:hideki.hayashi@japan-telecom.co.jp URI: http://www.japan-telecom.co.jp/ Fumio Teraoka Graduate School of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8522 Japan Phone: +81-45-566-1425 Email: tera@ics.keio.ac.jp URI: http://www.tera.ics.keio.ac.jp/ Kainuma, et al. Expires December 3, 2005 [Page 29] Internet-Draft fast PANA authentication June 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. Kainuma, et al. Expires December 3, 2005 [Page 30]