[hiprg] New thoughts on HIT construction
Robert Moskowitz <rgm@htt-consult.com> Tue, 15 June 2010 12:44 UTC
Return-Path: <rgm@htt-consult.com>
X-Original-To: hiprg@core3.amsl.com
Delivered-To: hiprg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83BE93A6A6B for <hiprg@core3.amsl.com>; Tue, 15 Jun 2010 05:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.387
X-Spam-Level:
X-Spam-Status: No, score=0.387 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSRDKnzBvW-v for <hiprg@core3.amsl.com>; Tue, 15 Jun 2010 05:44:45 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 9B67C3A68E4 for <hiprg@irtf.org>; Tue, 15 Jun 2010 05:44:45 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 6656C68B59 for <hiprg@irtf.org>; Tue, 15 Jun 2010 12:37:16 +0000 (UTC)
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LB3WzxJC8iM for <hiprg@irtf.org>; Tue, 15 Jun 2010 08:37:07 -0400 (EDT)
Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 2808B68B51 for <hiprg@irtf.org>; Tue, 15 Jun 2010 08:37:07 -0400 (EDT)
Message-ID: <4C1775B5.80702@htt-consult.com>
Date: Tue, 15 Jun 2010 08:44:37 -0400
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4
MIME-Version: 1.0
To: "hiprg@irtf.org" <hiprg@irtf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [hiprg] New thoughts on HIT construction
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/hiprg>
List-Post: <mailto:hiprg@irtf.org>
List-Help: <mailto:hiprg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jun 2010 12:44:46 -0000
While out on my 8Km morning walk I had some thoughts on HIT construction.... Current HIT construction is a truncation of the hash of the Host ID public key. This binds the HIT strongly to the HI, a key component This was OK with our initial (and current) limited choices of Public Keys (RSA or DSA) and hash (SHA-1). We are now looking at a significant change in the composite of what identifies a host. What I propose it including the 'domain' of the HIT in composing the HIT. This means to take the HIT prefix and HostIDSuite and concatenate this with the public key before hashing. This binds the prefix and Suite ID into the HIT. For the 'simple' case in BEX where only the IPv6 prefix and Suite ID are now included in the HIT generation, one might wonder what is gained with this construct. Little, I suspect. But consider other classes of uses that we have talked about and are even currently working on: Hierarchical HITs The HIT is clearly restricted within the domain of the assigned hierarchy by including the Hierarchy ID value in the HIT generation. MACsec There are only 24 bits available in EUI-48, but if the 24 bit OUI is included in the HIT construction the HIT is specifically bound to the OUI as well as the Host ID. This effectively reduces the NIC population to 2^23, as well as needing to add logic to deal with MAC collisions on a sub-net, but it offers some interesting binding possiblities. RFID I don't know how large the vendor controlled field is in RFID. I did just a couple of searches and came up empty. I once knew more about this (back in my Chrysler days). But would this be a way to fold RFIDs into our HIT concept? What other places where a host can have an Identity that we can think about the construction of a HIT within the framework of that hosts network protocol? This needs fleshing out. Anyone interested in this? This IS a good time to look deeper into HITs while we are developing 5201-bis.
- [hiprg] New thoughts on HIT construction Robert Moskowitz
- Re: [hiprg] New thoughts on HIT construction Pascal Urien
- Re: [hiprg] New thoughts on HIT construction Tobias Heer
- [hiprg] HIP for RFID -- Re: New thoughts on HIT c… Robert Moskowitz