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]
