Technical Summary
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 name space for mutual peer authentication. The protocol is
designed to be resistant to Denial-of-Service (DoS) and Man-in-the-
middle (MitM) attacks, and when used together with another suitable
security protocol, such as Encapsulated Security Payload (ESP), it
provides integrity protection and optional encryption for upper layer
protocols, suchs as TCP and UDP. Discussion related to this document
is going on at the IETF HIP Working Group mailing list.
Working Group Summary
WG consensus was strong on this document.
Document Quality
There are several known implementations of this specification. This
document was reviewed by Mark Townsley for the IESG.
Note to RFC Editor
In hip-base, please replace:
> Responder's HIT Hash Algorithm (RHASH): hash algorithm used for
> various hash calculations in this document. The algorithm is the
> same as is used to generate the Responder's HIT. RHASH can be
> determined by inspecting the Prefix of the ORCHID (HIT). The
> Prefix value has a one-to-one mapping to a hash function.
With:
Responder's HIT Hash Algorithm (RHASH): hash algorithm used for
various hash calculations in this document. The algorithm is the
same as is used to generate the Responder's HIT. RHASH is
defined by the Orchid Context ID. For HIP, the present RHASH
algorithm is defined in Section 3.2. A future version of HIP
may define a new RHASH algorithm by defining a new Context ID.
IESG Note
IESG Note for draft-ietf-hip-base
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 to 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 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.
IESG Note for draft-ietf-hip-esp
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.
In case of complex SPDs and co-existence of HIP and security-related
protocols such as IKE, implementors may encounter conditions that are
unspecified in these documents. For example, when the SPD defines an IP
address subnet to be protected and a HIP host is residing in that IP
address area, there is a possibility that the communication is encrypted
multiple times. Readers are advised to pay special attention when running
HIP with complex SPD settings. Future specifications should clearly define
when multiple encryption is intended, and when it should be avoided.