The IESG has approved the following documents: - 'Host Identity Protocol ' <draft-ietf-hip-base-10.txt> as an Experimental RFC - 'Using ESP transport format with HIP ' <draft-ietf-hip-esp-06.txt> as an Experimental RFC - 'Host Identity Protocol (HIP) Registration Extension ' <draft-ietf-hip-registration-02.txt> as an Experimental RFC - 'End-Host Mobility and Multihoming with the Host Identity Protocol ' <draft-ietf-hip-mm-05.txt> as an Experimental RFC - 'Host Identity Protocol (HIP) Rendezvous Extension ' <draft-ietf-hip-rvs-05.txt> as an Experimental RFC These documents are products of the Host Identity Protocol Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-base-10.txt 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. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
