Network Working Group Chen Jian Internet-Draft Ren Yan Expires: MAY 11, 2006 Zhang Hongke Zhang Sidong NGI Research Center BeiJing Jiaotong University Miao Fuyou Huawei Technologies November 10, 2005 A proposal to replace HIP base exchange with IKE-H method draft-yan-hip-ike-h-02 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract chen, et al. Expires May 11, 2006 [Page 1] Internet-Draft A proposal to replace HIP base exchange Nov 2006 This document is proposed to use version 2 of the Internet Key Exchange (IKEv2) to replace current HIP protocol's base exchange. IKE-H is an extension of IKE used for performing mutual authentication, establishing and maintaining security associations. It provides continuity of communications between not only hosts but also security gateways. It supports HIP identity authentication method and the establishment of keying material, consequently being used by IPsec Encapsulated Security payload (ESP) to establish a two- way secure communication channel between the hosts or security gateways. Table of Contents 1. Introduction......................................................2 1.1 Background.......................................................3 1.2 Design Objectives................................................3 1.3 IKE-H Overview...................................................3 2. IKE-H Details and Proposals.......................................4 2.1 The Initial Exchanges............................................4 2.2 Generating SA Binding to HITs....................................5 2.3 Rekeying IKE_SAs.................................................5 3. Header and Payload Formats........................................5 3.1 The IKE Header...................................................6 3.2 HI Payload.......................................................6 3.3 Identification Payloads..........................................7 4. Packet Processing.................................................8 4.1 Outgoing Packet Processing.......................................8 4.2 Incoming Packet Processing.......................................9 5. Security Considerations...........................................9 6. Influence to HIP..................................................9 7. IANA Considerations...............................................9 8. Acknowledgments...................................................9 9. References.......................................................10 9.1 Normative references............................................10 9.2 Informative references..........................................10 10. Author's address................................................10 Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [Bra97]. The term "Expert Review" is to be interpreted as defined in [RFC2434]. 1. Introduction chen, et al. Expires May 11, 2006 [Page 2] Internet-Draft A proposal to replace HIP base exchange Nov 2006 This section describes the background, design goals and an overview of IKE-H. 1.1 Background HIP[4] decouples the host identity from IP addresses, provides a rapid exchange of Host Identities between two hosts, and establishes a pair of IPsec Security Associations (SA) associated with the HIs, consequently which is used with IPsec Encapsulated Security Payload (ESP) [6]. HIP can be easily extended to support mobility because of the adoption of HIs. When a host moves, it notifies the peer with new IP addresses, updates the mapping of IP addresses and HIs, and leaves the SAs unchanged. This mechanism leads to a fast mobile handoff. However, HIP introduces the base exchange which is designed as a light-way key negotiating protocol and reduces the security of HIP. The paper[3] points out several security issues in the current HIP base exchange. IKEv2[5] is proposed to simplify the IKEv1 but do not decrease its security. Combining host identifier and IKEv2 will make it possible to use IKEv2 as a HIP control plane. 1.2 Design Objectives IKE-H is designed to enhance the security of HIP by replacing the base exchange but keep compatibility with other HIP elements. It should support establishing SA associated with HIs by extension to IKEv2. Besides, this design could make HIP benefit from the possibility of wide deployment of IKEv2. 1.3 IKE-H Overview IKE-H extends IKEv2 to support establishing and managing HIP SAs. Communicating hosts using IKE-H establish a pair of SA, which is associated with Host Identifiers of them. Mobile host renews its own SAs and notifies the corresponding host with the new IP address whenever its IP address changes. And the corresponding host updates the mapping of HIT and new IP address to keep the SA unchanged and still available in no time after it receives the update notification. Some new payloads and messages are added in IKE-H to implement new functions of IKEv2. At the initial exchanges phase, IKE-H provides a rapid exchange of HIT (Host Identity Tag) between hosts and establishes the SAs. When the mobile host moves, Readdressing Exchanges will be utilized to notify the changed IP addresses. Security policy could be implemented based on IP addresses, up-layer chen, et al. Expires May 11, 2006 [Page 3] Internet-Draft A proposal to replace HIP base exchange Nov 2006 protocols and application ports. In IKE-H, security policy based HIT need more consideration because HIT is used to as a host identifier. The host authentication by using HIT is a reasonable choice. 2. IKE-H Details and Proposals 2.1 The Initial Exchanges Communication using IKE-H begins with IKE_SA_INIT and IKE_AUTH exchanges. The initial exchange consists of four messages, and in some scenarios that number can grow. Figure 1 depicts the IKE_SA_INIT exchange. Initiator Responder --------- --------- HDR*,SAi1,HI_i,KEi,Ni ----> <---- HDR*,SAr1,HI_r,KEr,Nr Figure 1: IKE_SA_INIT exchange H flag bit in IKE header MUST be set 1 in IKE-H exchange messages. The messages in IKE_SA_INIT exchange MUST contain HIT payload. Otherwise the receivers will drop these messages silently. The first pair of messages (IKE_SA_INIT) negotiates cryptographic algorithms, exchanges nonces, HITs, and do a Diffie-Hellman exchange. HIT payload carries both source and destination HITs. In the fist message, source HIT MUST be set to the initiator's HIT and destination HIT MUST be set to 0. The response message contains responder's HIT as the source HIT and source HIT of the first message as the destination HIT. An IKE_SA is established to provide a secure tunnel after the first exchange. Initiator Responder ----------- ------------ HDR*,SK{IDI, [CERT,][CERTREQ,] [IDR,]AUTH,SAI2,TSI,TSR} ----> HDR*,SK{IDR,[CERT,],[CERTREQ,] <---- [IDR,],AUTH,SAI2,TSI,TSR} Figure 2: IKE_AUTH exchange The second exchange verifies the identities of both peers and establishes a CHILD_SA, which is exactly the same of IKEv2 except being bound with HITs instead of IP addresses. H flag bit in second exchange MUST be set to identify an IKE-H exchange. chen, et al. Expires May 11, 2006 [Page 4] Internet-Draft A proposal to replace HIP base exchange Nov 2006 2.2 Generating SA Binding to HITs IKE-H utilizes the general security API such as PF_KEYv2[7] to manage SAs. Messages like SADB_ACQUIRE and SADB_ADD of PF_KEYv2 are usually used to add a new SA into SADB. Addresses which are associated with SAs, are used as parameters in these messages. IKE-H implementation uses HITs instead of the addresses as parameters of these messages. The reason is that the SAs in IKE-H are no longer associated with addresses. The definition of HIT must keep IKE-H easy to implement. The same length of HITs and IP addresses is required for the sake of APIs compatiblility. Though the IP addresses change for some reasons, SAs in SADB need no updates. Instead, hosts must maintain a mapping table of HITs and their corresponding IP addresses. And when the IP addresses change, the mapping must be updated immediately to keep the context of communication. 2.3 Rekeying IKE_SAs The CREATE_CHILD_SA exchange is used to rekey an IKE_SA. There are many reasons to rekey an IKE_SA, such as an IKE_SA expires or changing to a more preferable HI. This exchange consists of a single request/response pair. Figure 3 describes it. Initiator Responder ----------- ------------ HDR*, SK{[N],SA,Ni,[KEi], [HI],[TSI, TSR]} ----> HDR*, SK{SA, Nr, [KEr] <---- [HI], [TSI,TSR]} Figure 3 CREATE_CHILD_SA exchange Traffic selectors are omitted if the request is being used to change the key of the IKE_SA. HI payloads are used if a more preferable HI is by request of the initiator. 3. Header and Payload Formats This section explains the headers and payloads specific to IKE-H. Some header or payloads are also available in IKEv2, but they are chen, et al. Expires May 11, 2006 [Page 5] Internet-Draft A proposal to replace HIP base exchange Nov 2006 changed slightly to meet IKE-H requirements. 3.1 The IKE Header The format of the IKE header is shown in Figure 4. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IKE_SA Initiator's SPI ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! IKE_SA Responder's SPI ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Message ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: IKE Header Format Here, a new flag bit is defined. --H (HIP) (bit 2) ¨C This bit MUST be set in IKE-H exchanges and MUST be cleared in IKEv2 exchanges. It is used both by initiator and responder to identify IKE-H Exchanges. 3.2 HI Payload The HI Payload is used to exchange HIT information. HITs are used to identify a temporary session between two hosts and SAs between them are bound with HITs. A HIT Payload MUST appear in an Initial Exchanges messages when the H bit in the IKE header is set and also in a Create_Child_SA exchange messages while rekeying. When the initiator does not know the peer's HIT, the "Source HIT" field MUST be set to initiator's HIT and the "Destination HIT" field MUST be set to zeros. In the Response message, the Responder MUST set the "Source HIT" field to his own HIT and the "Destination HIT" field to peer's HIT copied from the Request message. The format of the HI payload is shown in Figure 5. chen, et al. Expires May 11, 2006 [Page 6] Internet-Draft A proposal to replace HIP base exchange Nov 2006 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Source HI ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Destination HI ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: HI Payload 3.3 Identification Payloads For extending the IKEv2 protocol and compatibility with HIP, current Identification Payload type is extended. The following diagram illustrates the content of the Identification Payload consists of the IKE generic payload header followed by identification fields as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Identification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Identification Payload oID Type (1 octet) - Specifies the type of Identification being used. o RESERVED - MUST be sent as zero; MUST be ignored on receipt. o Identification Data (variable length) - Value, as indicated by the Identification Type. The length of the Identification Data is chen, et al. Expires May 11, 2006 [Page 7] Internet-Draft A proposal to replace HIP base exchange Nov 2006 computed from the size in the ID payload header. The payload types for the Identification Payload are 35 for IDi and 36 for IDr. We can define a new ID type named ID_HIT whose value is required IANA to allocate. ID_HIT xx We can assign HIT's concretely values at the Identification Data field. In this way, we can use HITi in IDi payload and use HITr in IDr payload. 4. Packet Processing The IKE-H is able to simultaneously maintain SAs with more than one host. Furthermore, the IKE-H could have more than one active SA with another host. In this case, SAs are distinguished by their respective HITs. It is not possible to have more than one HIP association between any given pair of HITs. This section describes how the right SA for a packet is found. The packet processing details are dependent on what protocol used to encrypt this packet. 4.1 Outgoing Packet Processing In an IKE-H host, an application always constructs packets using IP addresses as source and destination addresses. For the IKE-H SAs are binding to the HITs, the IP addresses MUST be converted into HITs before searching the SADB for the right SA. IP security policies MUST be implemented to check the outgoing packets for IPSec processing. The following steps define the conceptual processing rules for outgoing packets. 1) If the packet MUST be dealt with IPSec, search through the binding cache for the correspond HITs of the source and destination IP addresses. If the destination HIT is not found, initiate the IKE-H to negotiate an SA. 2) If the SA bound with HITs pair is not found, initiate the IKE-H to negotiate an SA. 3) If the right SA is found, the packet will be processed be encrypted and/or integrity protected before being sent out. chen, et al. Expires May 11, 2006 [Page 8] Internet-Draft A proposal to replace HIP base exchange Nov 2006 4.2 Incoming Packet Processing The way to find a right SA for incoming packets is different from that for the outgoing packets. The following steps define the conceptual processing rules for incoming packets. The specific transport format and method specifications define in more detail the packet processing, related to the method. 1) The incoming packet is mapped to an existing SA, typically using some information from the packet. For example, such mapping may be based on ESP Security Parameter Index (SPI). 2) Check the HITs bound with the found SAs to make sure it is consistent with the IP addresses. 3) Unwrap the packet, in a way depending on the transport format, yield a packet that looks like a standard IP packet. 4) Send the packet to the upper layer. 5. Security Considerations About HIP security has been extensively discussed in [3] and IKE security has been discussed in [4]. A new identification type would not compromise the security of HIP or IKEv2. 6. Influence to HIP Using IKE-H to replace the base exchange makes HIP more secure and more likely to be deployed. Host Identifiers contribute to HIP's flexibility and they are also used in IKE-H, in fact, IKE-H is an extension of IKE and a bridge between IKE and HIP. The current HIP only supports host-to-host Security Association is not suit for more complex environments and using separate HITs is not satisfying. IKE-H can provide for more granularity and creation of several ESP SAs between a pair of HITs. Current IKE-H is simplex, more changes SHOULD be added to future edition. 7. IANA Considerations The new ID type ID_HIT SHOULD get an IANA allocated number. 8. Acknowledgments This document is a collaborative effort of our entire research center. chen, et al. Expires May 11, 2006 [Page 9] Internet-Draft A proposal to replace HIP base exchange Nov 2006 If there were no limit to the number of authors that could appear on the proposal, the following, in alphabetical order, would have been listed: Lu Hongmei, Yang Shen, Zhang Hui, Zhang Bingyi. 9. References 9.1 Normative references [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Nikander, P.A, "Applying host identity protocol to the Internet addressing architecture", Applications and the Internet, 2004. Proceedings. 2004 International Symposium on, 2004. [3] Analysis of the HIP Base Exchange Protocol, Tuomas Aura, Microsoft Research, Cambridge, United Kingdom 9.2 Informative references [4] Moskowitz R., Nikander P., Jokela P. and T. Henderson, "Host Identity Protocol", draft-ietf-hip-base-00 (work in progress), June 2004. [5] Charlie Kaufman, "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17 (work in progress), May 2004. [6] Kent, S., "IP Encapsulating Security Payload (ESP)", draft- ietf-ipsec-esp-v3-05 (work in progress), April 2003. [7] D.McDonald, "PF_KEY Management API, Version 2", RFC2367, July 1998 [8] T. Henderson, "End-Host Mobility and Multihoming with the Host Identity Protocol", draft-ietf-hip-mm-02, July 17, 2005. [9] P. Eronen, Ed., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", draft-ietf-mobike-protocol-04, October 7, 2005. 10. Author's address Chen Jian Tel: +86 10 5168 5677 NGI Research Center Fax: +86 10 5168 3682 Beijing Jiaotong University of China chen, et al. Expires May 11, 2006 [Page 10] Internet-Draft A proposal to replace HIP base exchange Nov 2006 Beijing http://iplab.njtu.edu.cn China,100044 EMail: chenjian0518@126.com Ren Yan Tel: +86 10 5168 5677 NGI Research Center Fax: +86 10 5168 3682 Beijing Jiaotong University of China Beijing http://iplab.njtu.edu.cn China,100044 EMail: yren@center.njtu.edu.cn Zhang Hongke Tel: +86 10 5168 5677 NGI Research Center Fax: +86 10 5168 3682 Beijing Jiaotong University of China Beijing http://iplab.njtu.edu.cn China,100044 EMail: hkzhang@center.njtu.edu.cn Zhang Sidong Tel: +86 10 5168 5677 NGI Research Center Fax: +86 10 5168 3682 Beijing Jiaotong University of China Beijing http://iplab.njtu.edu.cn China,100044 EMail: sdzhang@center.njtu.edu.cn Miao Fuyou Tel: +86 10 8288 2350 Huawei Technologies Fax: +86 10 8288 2537 Beijing China Email: miaofy@huawei.com 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. chen, et al. Expires May 11, 2006 [Page 11] Internet-Draft A proposal to replace HIP base exchange Nov 2006 Full Copyright Notice 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. 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. chen, et al. Expires May 11, 2006 [Page 12]