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)
|
|
---|---|---|---|
Authors | Robert Moskowitz , Petri Jokela , Tom Henderson , Pekka Nikander | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized 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 4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 18 4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 19Show full document text