[hiprg] HIP for RFID -- Re: New thoughts on HIT construction

Robert Moskowitz <rgm@htt-consult.com> Mon, 19 July 2010 14:43 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 7AE793A69B7 for <hiprg@core3.amsl.com>; Mon, 19 Jul 2010 07:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.337
X-Spam-Level:
X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[AWL=1.263, BAYES_00=-2.599]
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 Kg6zz2X5SoAf for <hiprg@core3.amsl.com>; Mon, 19 Jul 2010 07:43:03 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 4E2AE3A6990 for <hiprg@irtf.org>; Mon, 19 Jul 2010 07:43:02 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 6F71168B53; Mon, 19 Jul 2010 14:34:31 +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 z7FrfJv8za-T; Mon, 19 Jul 2010 10:34:22 -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 E9B6868B50; Mon, 19 Jul 2010 10:34:21 -0400 (EDT)
Message-ID: <4C446478.50308@htt-consult.com>
Date: Mon, 19 Jul 2010 10:43:04 -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: Tobias Heer <heer@cs.rwth-aachen.de>
References: <4C1775B5.80702@htt-consult.com> <AANLkTim57j35gWTdp_VQXaa8Pi74rkY2lwWTSgG47QaT@mail.gmail.com> <F0CEE0CF-EC8C-4BE2-BC64-E31591F36F6D@cs.rwth-aachen.de>
In-Reply-To: <F0CEE0CF-EC8C-4BE2-BC64-E31591F36F6D@cs.rwth-aachen.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: hiprg@irtf.org
Subject: [hiprg] HIP for RFID -- Re: 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: Mon, 19 Jul 2010 14:43:04 -0000

On 07/19/2010 09:41 AM, Tobias Heer wrote:
> Hello Pascal,
>
> I briefly read draft-irtf-hiprg-rfid-00.txt and have some comments/questions in addition to Bob's comments:
>
> A very minor issue: HIP-Tag may be easy to confuse with Host Identity Tag / HIT. I don't have a proposal for a better name but I believe a more different name could avoid some confusion.
>    

everything is in a name, and naming is everything. So it would be good 
for us to come up with a usable name for this. Good catch.

> Am 27.06.2010 um 18:50 schrieb Pascal Urien:
>
> In section 1.4 you mention three entities but provide a list of five things, four of them being entities, one being a data structure implemented on one of the four. I think this list is a bit misleading and could be structured in a better way.
>
> About the HAT: Is HIP Address translator really the right name for it? As far as I understood it, it is rather a protocol translator than an address translator.
>    

Is it more of a IP proxy service? The place where the device's 
communication gets stuffed into an IP datagram?

> Section 1.5 states that the HIT can be traced. Ephemeral HIs allow for some anonymity (equivalent to the one used in the RFID document) even in baseline HIP.
>    

HITs here can either be random values as called out, or a hash of the 
device number. More on this at the end.

> It would be good to state the security goals/services that the T-BEX offers in the beginning. Who authenticates to whom? What is the result of the T-BEX? One can derive these things from the technical description but explicitly stating these things might help comprehension.
>
> What are the security assumptions? What is the attacker model? Is the reader trustworthy? Is an MITM attack by the reader an issue?
>    

More in this area would be very useful. There have been pieces of this 
in the past presentations and I think in the paper behind this draft.

> Do the new parameters use the same type space as baseline HIP? If yes, are they all non-critical? The critical bit seems not to be set in any of the parameters.

As has been covered on the HIP list, we need to carefully think out our 
use of parameter types and be careful NOT to over use a parameter.

Now on to somemore thoughts on my part.

The ID uses SHA-1 in the hash based function. I have another 
recommendation. Go with one of the block-cipher hashs like: 
Matyas--Meyer--Oseas. This simplifies the coding demand on a tag that 
would also be implementing AES-CCM for data protection.

Matyas--Meyer--Oseas is used by Zigbee, but not being a Zigbee member 
(yet) I don't have details as to the selection process.

I do have some papers on 'PGV style block-cipher based hash functions' 
forwarded to me by a colleague that I could share if you need them.