Network Working Group Ren Yan Internet-Draft Zhang Hongke Expires: May 13, 2005 Zhang Sidong IP Lab, Beijing Jiaotong University Miao Fuyou Huawei Technologies November 12, 2004 A proposal to replace HIP base exchange with IKE-H method draft-yan-hip-ike-h-00 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, 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 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. This Internet-Draft will expire on May 13, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract renyan, et al. Expires May 13, 2005 [Page 1] Internet-Draft A proposal to replace HIP base exchange Nov 2004 This document describes using version 2 of the Internet Key Exchange (IKE) to replace current HIP protocol's base exchage. IKE-H is an extension of IKE used for performing mutual authentication and establishing and maintaining security associations. It can be used to provide continuity of communications between not only those hosts independent of the networking layer but also security gateway. IKE-H is an extension to the IKEv2. It supports HIP identity authentication method and the establishment of keying material, which is then used by IPsec Encapsulated Security payload (ESP) to establish a two-way secure communication channel between the hosts or security gateway. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document. . . . . . . . . . . . . . 3 3. IKE-H Details and Proposal . . . . . . . . . . . . . . . . . 3 4. Header and Payload Formats . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Author's address . . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property Statement . . . . . . . . . . . . . . . . . 9 Expiration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 The IKE-H method can be applied to replace current HIP protocol's base exchange which should be improved for practical application. It is an extension of IKE [4] used for performing mutual authentication and renyan, et al. Expires May 13, 2005 [Page 2] Internet-Draft A proposal to replace HIP base exchange Nov 2004 establishing and maintaining two one way IPsec security associations (SA), which should be used with IPsec Encapsulated Security Payload (ESP) to establish a two-way secured communication channel between the hosts or security gateway. Since we are using public keys as the identities for end-points, identity authentication is more effective. The IKE-H method provides confidentiality, data integrity, access control, and data source authentication to IP datagrams. These services are provided by maintaining shared state between the source and the sink of an IP datagram. IKE-H can establish this shared state dynamically. This document describes such a protocol. The goals of the IKE-H proposed in the document are: (1) to make IKE protocol support HIP and (2) to propose a improvement of present HIP base exchange. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [1]. 3. IKE-H Details and Proposal IKE-H is based on the IKEv2 protocol and is compatiable with HIP, which seperates the endpoint identifier and locator roles of IP addresses by introducing a new layer to the TCP/IP stack. 3.1 HIP introduction In HIP, a Host Identity is basically a public cryptographic key of a public-private key pair. The public key identifies the party that holds the unique copy of the private key [2]. When HIP is applied to a protocol stack, IP addresses are not used to identify the nodes any longer; they are used only for routing the packets in the network and the upper layers are not aware of the IP addresses any longer. Host Identifiers are the identifier of the destination hosts. The locator information is hidden at the new layer. 3.2 IKE-H exchange details renyan, et al. Expires May 13, 2005 [Page 3] Internet-Draft A proposal to replace HIP base exchange Nov 2004 In the IKE-H key exchange, both communicating hosts authenticate each other's identity and establishes a IKE sercurity association that includes share secret information and several cryptographic algorithms suites to be used by SAs. The SAs for ESP and/or AH that are set up through the IKE SA are "IPsec SA"s. During establishment of the IKE SA, the first IPsec SA can be negotiated. All IKE communications consist of pairs of messages: a request and a response. The pair is called an "exchange". The first exchange establishes IKE_SA_INIT, which negotiates including cryptographic algorithms suites, Nonces, Diffie-Hellman value and so on. The second exchange establishes IKE_AUTH, which authenticates prior messages, exchanges identities and establishes the first IPsec SA. Subsequent IKE exchanges CREATE_IPSEC_SA or INFORMATIONAL exchanges. In the common case, there is a single IKE_SA_INIT exchange and a single IKE_AUTH exchange (of four messages totally) to establish the IKE SA and the first IPsec SA. In exceptional cases, there may be more than one of each of these exchanges. In all cases, IKE_SA_INIT exchange MUST complete before any other exchange type, then IKE_AUTH exchange MUST complete, and following that any number of CREATE_IPSEC_SA and INFORMATIONAL exchanges may occur in any order. In some scenarios, only a single IPsec SA is needed between the IPsec endpoints and therefore there would be no additional exchanges. In the IKE-H method, a IKE_SA_INIT exchange and a single IKE_AUTH exchange are as follows: Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr HDR, SK {IDi, [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR, SK {IDr, AUTH, SAr2, TSi, TSr} HDR is the header of each IKE-H message, it contains the SPIs, version numbers, and various flags. The SAi1 payload expresses the cryptographic algorithms the Initiator supports for the IKE SA. The Responder chooses one from crptographic algorithms that are supported by Initiator and expresses that choice in the SAr1 payload. The KEi payload sends the Initiator's Diffie-Hellman value and the KEr payload establishes Diffie-Hellman exchage. Ni and Nr are the renyan, et al. Expires May 13, 2005 [Page 4] Internet-Draft A proposal to replace HIP base exchange Nov 2004 Initiator and the Responder's nonces. The Initiator asserts its identity with the IDi payload, proves knowledge of the secret corresponding to IDi and integrity protects the contents of the first message using the AUTH payload. The optional payload IDr enables Initiator to specify which of Responder's identities it wants to talk to. It initiates negotiation of a IPsec SA using the SAi2 payload. The Responder asserts its identity with the IDr payload, authenticates its identity and protects the integrity of the second message with the AUTH payload, and completes negotiation of an IPsec SA. The recipients of messages 3 and 4 MUST verify that all signatures and MACs are computed correctly and that the names in the ID payloads correspond to the keys used to generate the AUTH payload. By far, we have established initial exchange and the first IPsec SA. The following exchange is CREATE_IPSEC_SA exchange for establishing after IPsec SAs or INFORMATIONAL exchange for some management works. Some details are described in another document [4]. 4 Header and Payload Formats For extending the IKEv2 protocol, we adding HIP mechanism, 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 1: Current Identification Payload Format renyan, et al. Expires May 13, 2005 [Page 5] Internet-Draft A proposal to replace HIP base exchange Nov 2004 o ID 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 computed from the size in the ID payload header. The payload types for the Identification Payload are 35 for IDi and 36 for IDr. The following table lists the assigned values for the Identification Type field, followed by a description of the Identification Data which follows: ID Type Value ------- ----- RESERVED 0 ID_IPV4_ADDR 1 A single four (4) octet IPv4 address. ID_FQDN 2 A fully-qualified domain name string. An example of a ID_FQDN is, "example.com". The string MUST not contain any terminators (e.g., NULL, etc.). ID_RFC822_ADDR 3 A fully-qualified RFC822 email address string, An example of a ID_RFC822_ADDR is, "jim@example.com". The string MUST not contain any terminators. ID_IPV6_ADDR 5 A single sixteen (16) octet IPv6 address. ID_DER_ASN1_DN 9 The binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501]. ID_DER_ASN1_GN 10 renyan, et al. Expires May 13, 2005 [Page 6] Internet-Draft A proposal to replace HIP base exchange Nov 2004 The binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. ID_KEY_ID 11 An opaque octet stream which may be used to pass vendor- specific information necessary to do certain proprietary types of identification. Reserved to IANA 12-200 Reserved for private use 201-255 We can define a new ID type named ID_HIT whose value is required IANA to allocate. ID_HIT xx we can assigne 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. 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. IANA Considerations The new ID type ID_HIT should get an IANA allocated number. 7. Acknowledgments This document is a collaborative effort of our entire IP lab. 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: Chen Jian, Su Wei, Yang He, Yang Shen, Zheng Zuzhou. 8. References renyan, et al. Expires May 13, 2005 [Page 7] Internet-Draft A proposal to replace HIP base exchange Nov 2004 8.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. 8.2 Informative references [3] Moskowitz, R., Nikander, P., Jokela, P. and T. Henderson, "Host Identity Protocol", draft-ietf-hip-base-00 (work in progress), June 2004. [4] Charlie Kaufman, "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-14 (work in progress), May 2004. 9. Author's address Ren Yan Tel: +86 10 5168 5677 IP Lab,EIES Fax: +86 10 5168 3682 Beijing Jiaotong University of China Beijing http://iplab.njtu.edu.cn China,100044 EMail: iplabbear@126.com Zhang Hongke Tel: +86 10 5168 5677 IP Lab,EIES 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 IP Lab,EIES 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 renyan, et al. Expires May 13, 2005 [Page 8] Internet-Draft A proposal to replace HIP base exchange Nov 2004 Fax: +86 10 8288 2537 Huawei Technologies Beijing China, Email: miaofy@huawei.com Full Copyright Statement Copyright (C) The Internet Society (2004). 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. 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. renyan, et al. Expires May 13, 2005 [Page 9] Internet-Draft A proposal to replace HIP base exchange Nov 2004 Expiration This Internet-Draft (draft-yan-hip-ike-h-00.txt) expires in May 2005. renyan, et al. Expires May 13, 2005 [Page 10]