Re: [hiprg] Slot for the next IETF meeting

Pascal Urien <> Tue, 20 October 2009 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E9DA28C0FD for <>; Tue, 20 Oct 2009 07:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.298
X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tsIxcnzjXtFi for <>; Tue, 20 Oct 2009 07:46:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 904A628C0F1 for <>; Tue, 20 Oct 2009 07:46:12 -0700 (PDT)
Received: by qyk30 with SMTP id 30so4445270qyk.7 for <>; Tue, 20 Oct 2009 07:46:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=iNXlYK3e3qAD6nh4Kg04KKYs/do8iNkCUc8v5wysu5o=; b=LPsWoFIZd45ynPmDEMhiKTnxscQG1w/H5Jb/lqtUJ9uajqzRraimapjsPXBRW1tOYn IwO3CtxmYudBjDp70TSC9TgM6kk53tf5jDIMMl+t0Bp/MslNJCU7aiuGjH2ivanDJYol S8jVZagtyGvOD8G2Ll2UN6UvLyVr+N179daXk=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jhMAVOgcs73tWG/IzRnCVEcnyCraCQa5EPVCLsh6+WwLiaB/ebO3AG7h4qht+8NWc0 gDTRSWT4MWmlMim6kqdAvkL9eMlWoIwh6rqkb7fg2eZ7x/Mn9r++B331xpTXmjzmcz1u CPMKXeXp4ZfOjCEyuLrdIShlU9qAnpDt+TDNo=
MIME-Version: 1.0
Received: by with SMTP id p21mr943027qcc.101.1256049977805; Tue, 20 Oct 2009 07:46:17 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Tue, 20 Oct 2009 16:46:17 +0200
Message-ID: <>
From: Pascal Urien <>
To: "Henderson, Thomas R" <>
Content-Type: multipart/alternative; boundary="0016367f94b4bf4bfb04765eecfb"
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: Tue, 20 Oct 2009 14:46:17 -0000

Hi Tom

> 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:

  * The main issue to solve, is to hide the tag (or object) identity  to any
non authorized party

> 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).

   In our first experiment, the identity of the tag is an EPC-CODE
associated to a random HIT

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

  The EPC-Code is not sent. It is the solution of an equation produced by
the tag (or object) and solved by the portal.

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

 Yes. Readers are seen as docking host for HIP tags, they support an IP
stack. The dialog between TAG and PORTAL is HIP

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

 Yes, in our experiment, the tag doesn't include an IP stack, only a HIP

   If an IP stack is used, the idea should be that the reader should give an
ephemerous  (and pseudo random) IP address to the TAG

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

Yes because HIT is a random number. Portal is authenticated because it is
able to solve an equation, which gives the identity and then other
cryptographics keys

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

Yes because HIT is a random number. The message including the f equation is
signed with a key deduced from the identity (for example the EPC code)

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

I suggest the three main requirements

- Support of privacy, i.e identity must be protected
- Support of new naming schemes for identity
- Design of an Infrastructure compatible with these requirements

> 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?

In our experiment the portal manages a table that establishes the link
between the HIT (random number) and the EPC code.

The portal collects information about the EPC code by classical middleware

But according to the used naming scheme, the identity hidden by the f
equation may be an EPC code, a HIT value or other class of identifiers. This
is an open issue

> 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?
> HIP is clearly an identity layer, our vision is that the core
infrastructure provides IP connectivity. Mobile components (tags for
exemple) are identified by their identity rather than their IP addresses. So
HIP seems well adapted to these aplications, but privacy is really a crucial

My understanding of EPC Global specs is that a tag is a serial number, which
can be freely read by a reader. The reader collects information about the

In HIP tag we see the reader as a part of the infrastructure. It collects
and routes information, but it is not able to understand these data.

> Regards,
> Tom