Host Identity Protocol
RFC 5201

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