Internet DRAFT - draft-yan-hip-ike-h

draft-yan-hip-ike-h




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]