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]