Subject: Document Action: 'Host Identity Protocol' to Experimental RFC

From: The IESG <[email-masked]>
Date: Wed, 05 Dec 2007 12:49:55 -0500

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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce