Host Identity Protocol
RFC 5201
| Document | Type |
RFC - Experimental
(April 2008; Errata)
Obsoleted by RFC 7401
Updated by RFC 6253
Was draft-ietf-hip-base (hip WG)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 5201 (Experimental) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Mark Townsley | ||
| Send notices to | (None) | ||
Network Working Group R. Moskowitz
Request for Comments: 5201 ICSAlabs
Category: Experimental P. Nikander
P. Jokela, Ed.
Ericsson Research NomadicLab
T. Henderson
The Boeing Company
April 2008
Host Identity Protocol
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
IESG Note
The following issues describe IESG concerns about this document. The
IESG expects that these issues will be addressed when future versions
of HIP are designed.
This document doesn't currently define support for parameterized
(randomized) hashing in signatures, support for negotiation of a key
derivation function, or support for combined encryption modes.
HIP defines the usage of RSA in signing and encrypting data. Current
recommendations propose usage of, for example, RSA OAEP/PSS for these
operations in new protocols. Changing the algorithms to more current
best practice should be considered.
The current specification is currently using HMAC for message
authentication. This is considered to be acceptable for an
experimental RFC, but future versions must define a more generic
method for message authentication, including the ability for other
MAC algorithms to be used.
SHA-1 is no longer a preferred hashing algorithm. This is noted also
by the authors, and it is understood that future, non-experimental
versions must consider more secure hashing algorithms.
HIP requires that an incoming packet's IP address be ignored. In
simple cases this can be done, but when there are security policies
based on incoming interface or IP address rules, the situation
Moskowitz, et al. Experimental [Page 1]
RFC 5201 Host Identity Protocol April 2008
changes. The handling of data needs to be enhanced to cover
different types of network and security configurations, as well as to
meet local security policies.
Abstract
This memo specifies the details of the Host Identity Protocol (HIP).
HIP allows consenting hosts to securely establish and maintain shared
IP-layer state, allowing separation of the identifier and locator
roles of IP addresses, thereby enabling continuity of communications
across IP address changes. HIP is based on a Sigma-compliant Diffie-
Hellman key exchange, using public key identifiers from a new Host
Identity namespace for mutual peer authentication. The protocol is
designed to be resistant to denial-of-service (DoS) and man-in-the-
middle (MitM) attacks. When used together with another suitable
security protocol, such as the Encapsulated Security Payload (ESP),
it provides integrity protection and optional encryption for upper-
layer protocols, such as TCP and UDP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 5
1.2. The HIP Base Exchange . . . . . . . . . . . . . . . . . . 6
1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 7
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 7
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 7
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
3. Host Identifier (HI) and Its Representations . . . . . . . . 8
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 9
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 9
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 10
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 12
4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 13
4.1.3. Authenticated Diffie-Hellman Protocol . . . . . . . . 14
4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 14
4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 15
4.1.6. HIP Opportunistic Mode . . . . . . . . . . . . . . . 16
4.2. Updating a HIP Association . . . . . . . . . . . . . . . 18
Show full document text