Re: [hiprg] Slot for the next IETF meeting

"Henderson, Thomas R" <> Mon, 19 October 2009 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF1143A68C3 for <>; Mon, 19 Oct 2009 11:10:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lm-hUkBmjA30 for <>; Mon, 19 Oct 2009 11:10:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D2BF23A68B4 for <>; Mon, 19 Oct 2009 11:10:07 -0700 (PDT)
Received: from ( []) by (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n9JI9xES027990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2009 13:10:07 -0500 (CDT)
Received: from (localhost []) by (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n9JI9wGf022138; Mon, 19 Oct 2009 11:09:58 -0700 (PDT)
Received: from ( []) by (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n9JI9w3f022128 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 19 Oct 2009 11:09:58 -0700 (PDT)
Received: from ([]) by ([]) with mapi; Mon, 19 Oct 2009 11:09:58 -0700
From: "Henderson, Thomas R" <>
To: 'Andrei Gurtov' <>, Pascal Urien <>
Date: Mon, 19 Oct 2009 11:09:57 -0700
Thread-Topic: [hiprg] Slot for the next IETF meeting
Thread-Index: AcpQtnITY3wnl3jKQ7mjgU+yVs5C3AAKGXiA
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--39.113600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [hiprg] Slot for the next IETF meeting
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Oct 2009 18:10:11 -0000

> -----Original Message-----
> From: []
> On Behalf Of Andrei Gurtov
> Sent: Monday, October 19, 2009 5:20 AM
> To: Pascal Urien
> Cc:
> Subject: Re: [hiprg] Slot for the next IETF meeting
> Hash: SHA1
> Hi Pascal,
> I've read the documents on the T2TIT page, as well as the new draft.
> I think its important work for HIP and it's nice that you've made an
> implementation and real experiments. Thus from my viewpoint,
> your draft
> would be a nice item for HIPRG to work on, since there are several
> people including Bob who're interested in this topic.

I agree that the RG has expressed interest in moving this particular use case forward (HIP for active RFID tags) and, more generally, in working on object-to-object communications as Gyu Myoung Lee has previously introduced.

I had a few questions or suggestions that perhaps you could try to address on the list or in a draft revision.  Initially, they relate to clarifying what the problem is that HIP solves, and why HIP is a preferred solution compared to other solutions.

1) Can you please state more clearly what is the problem and requirements that you are trying to address?  For instance, my read of your draft suggests the following:

1.1) Tag has two identities, a unique EPC-Code and a host identity as defined by RFC5201.  This host identity may be well-known or anonymous (randomly generated).

1.2) Disclosure of EPC-Code shall be over an encrypted channel that is dynamically set up between Tag and Portal

1.3) RFID Reader may not be HIP-aware; Tag and Portal are HIP-aware

1.4) RFID Reader to tag interface is not IP-based; RFID Reader to Portal interface is IP-based

1.5) Tag does not authenticate the Portal based on Host Identifier

1.6) Portal does not authenticate the tag based on Host Identifier

(please identify other requirements that I am missing...)

In summary, it seems that you are mainly using an adaptation of the HIP protocol to provide a dynamic secure channel to communicate the EPC-Code from tag to portal.  The draft seems less clear whether you are trying to use the identities as stable host identifiers for authentication purposes; in one section (2.1) it suggests that the HIT-I and HIT-R may be random and/or zero, respectively, while in section 1.2 last bullet, it states that the portal maintains a table linking HIT and EPC code, and in your paper, it suggests that you want the portal to be able to identify a legitimate tag and reject an imposter.  Can you please comment on this?

2) Are there already any specifications for authenticated access control outside of HIP, and if so, why do you believe HIP is preferable to the other specifications that, for instance, EPCGlobal may have proposed?