Re: [Hipsec] Well back at this yet again -- Re: RFC4423bis review

"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Tue, 06 September 2011 15:42 UTC

Return-Path: <thomas.r.henderson@boeing.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8B121F8BF4 for <hipsec@ietfa.amsl.com>; Tue, 6 Sep 2011 08:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.439
X-Spam-Level:
X-Spam-Status: No, score=-106.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBm29PvI8soR for <hipsec@ietfa.amsl.com>; Tue, 6 Sep 2011 08:42:03 -0700 (PDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id C3FD621F8BEB for <hipsec@ietf.org>; Tue, 6 Sep 2011 08:42:03 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p86FhYbj026225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Sep 2011 10:43:39 -0500 (CDT)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p86FhYPd011293; Tue, 6 Sep 2011 08:43:34 -0700 (PDT)
Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p86FhXJN011274 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 6 Sep 2011 08:43:34 -0700 (PDT)
Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Tue, 6 Sep 2011 08:43:33 -0700
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: 'Robert Moskowitz' <rgm@htt-consult.com>
Date: Tue, 06 Sep 2011 08:43:33 -0700
Thread-Topic: [Hipsec] Well back at this yet again -- Re: RFC4423bis review
Thread-Index: Acxoz8Z0Ombg5y9TRLq7QTU+NAQzEgBcTn9gAJiSWOA=
Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CEFAF06CD@XCH-NW-10V.nw.nos.boeing.com>
References: <7CC566635CFE364D87DC5803D4712A6C4CED25B0F2@XCH-NW-10V.nw.nos.boeing.com> <4E5FC610.7030504@htt-consult.com> <7CC566635CFE364D87DC5803D4712A6C4CEFAF06C8@XCH-NW-10V.nw.nos.boeing.com>
In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CEFAF06C8@XCH-NW-10V.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: HIP <hipsec@ietf.org>
Subject: Re: [Hipsec] Well back at this yet again -- Re: RFC4423bis review
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2011 15:42:04 -0000

> -----Original Message-----
> From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On
> Behalf Of Henderson, Thomas R
> Sent: Saturday, September 03, 2011 8:02 AM
> To: 'Robert Moskowitz'
> Cc: HIP
> Subject: Re: [Hipsec] Well back at this yet again -- Re: RFC4423bis
> review
> 
> 
> 
> > -----Original Message-----
> > From: Robert Moskowitz [mailto:rgm@htt-consult.com]
> > Sent: Thursday, September 01, 2011 10:51 AM
> > To: Henderson, Thomas R
> > Cc: HIP
> > Subject: Well back at this yet again -- Re: RFC4423bis review
> >
> > Finally completed an update of 4423-bis.
> >
> > now to NOT get bogged down in minutia in 5201-bis...
> >
> > On 04/04/2011 10:35 AM, Henderson, Thomas R wrote:
> > > Robert,
> > >
> > > Here are some comments on RFC4423bis that I would be
> > > willing to provide specific text inputs if you and others agree.
> > > I also have editorial nits that can be handled offline.
> > >
> > > Section 1
> > > ---------
> > > In paragraph 2, it would read better to introduce the concept of
> > > a Host Identity before talking about the Host Identifier.  Also,
> > > clarify that there is exactly one Host Identifier for each Host
> > > Identity, but that there can be multiple Host Identities for each
> > > real computing platform.  Also, the last sentence of this paragraph
> > > should probably refer to Identifiers and not identities.
> > >
> > > Suggested text:
> > >
> > >     The proposed Host Identity namespace fills an important gap
> > between
> > >     the IP and DNS namespaces.  A Host Identity conceptually refers
> > >     to a computing platform, and there may be multiple such Host
> > >     Identities per computing platform (because the platform may
> wish
> > >     to present a different identity to different communicating
> > peers).
> > >     The Host Identity namespace consists of Host Identifiers (HI).
> > >     There is exactly one Host Identifier for each Host Identity.
> >
> > Is there? Can there be multiple hashes applied to a single Host
> > Identity
> > making for multiple Host Identifiers?
> 
> This section doesn't pertain to hashes or HITs, but to the relationship
> between host identifier (the public key) and host identity (the
> abstract notion of identity).
> 
> My proposed text was trying to make this section more internally
> consistent, but I think the main issue to resolve still is whether you
> can have multiple keys refer to the same identity, or just a single key
> per identity.  That is, there is already a statement in the draft that
> there can be multiple host identities, in the abstract sense, (e.g. an
> anonymous and a public identity) for a computing platform.  The
> question is whether each of these identities themselves can have
> multiple identifiers (keys).  If so, is there a need to be able to bind
> these host identifiers together somehow?
> 

I had some off-list discussion of this issue over the weekend so I would like to propose a resolution.  The proposed text would replace the second and third paragraphs of section 1 of rfc4423-bis-03, and it is the last paragraph below that tries to clarify the relationship between Host Identity and Host Identifier:

   The proposed Host Identity namespace fills an important gap between
   the IP and DNS namespaces.  A Host Identity conceptually refers to a
   computing platform, and there may be multiple such Host Identities
   per computing platform (because the platform may wish to present a
   different identity to different communicating peers).  The Host
   Identity namespace consists of Host Identifiers (HI).   While this
   text later talks about non-cryptographic Host Identifiers, the
   architecture focuses on the case in which Host Identifiers are
   cryptographic in nature.  Specifically, the Host Identifier is the
   public key of an asymmetric key-pair.  

   There is a subtle but important difference between Host Identities
   and Host Identifiers.  An Identity refers to the abstract entity that
   is identified.  An Identifier, on the other hand, refers to the
   concrete bit pattern that is used in the identification process.

   It is intended that no two hosts have the same Host Identity; each 
   Host Identity and corresponding Host Identifier uniquely
   identifies a single host.  If two or more computing platforms have
   the same Host Identifier, then either they are instantiating a 
   distributed host, or there has been an accidental or intentional
   violation of the uniqueness property of a Host Identity (e.g., due
   to malicious host impersonation arising from key theft).  The
   architecture also allows for multiple Host Identifiers to be
   associated with the same abstract identity, such as due to 
   key revocation and renewal procedures over time.  The Host
   Identifier can either be public (e.g. published in the DNS), or
   unpublished.  Client systems will tend to have both public and
   unpublished Host Identifiers.