Subject: [hiprg] Slot for the next IETF meeting

From: Pascal Urien <[email-masked]>
Date: Sun, 18 Oct 2009 16:21:44 +0200

Dear all,

In the context of a french reserach project called T2TIT (For things to
thinfs in the internet of things)
we made some experiments for HIP for the Internet Of Things, the protocol
is desbribed by,

http://tools.ietf.org/html/draft-urien-hip-tag-02

Some open and free software material is available at

http://perso.telecom-paristech.fr/~urien/hiptag/index.html

I tried to summarize some issues for introducing HIP for the IOT in

http://tools.ietf.org/html/draft-urien-hip-iot-00

I would like to present these items during the next meeting in Hiroshima
The main idea should be to start a working item on that subject if some
people from the research community are interested

Best Regrds
Pr Pascal Urien
Telecom ParisTech
France www.enst.fr

---

From: Andrei Gurtov <[email-masked]>
Date: Mon, 19 Oct 2009 15:19:38 +0300

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.

BR
Andrei

Pascal Urien wrote:
> we made some experiments for HIP for the Internet Of Things, the
> protocol is desbribed by,
>  
> France www.enst.fr <http://www.enst.fr/>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 19 Oct 2009 11:09:57 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Andrei Gurtov
> Sent: Monday, October 19, 2009 5:20 AM
> To: Pascal Urien
> Cc: [email-masked]
> Subject: Re: [hiprg] Slot for the next IETF meeting
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hi Pascal,
>

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?

Regards,
Tom

---

From: Pascal Urien <[email-masked]>
Date: Tue, 20 Oct 2009 16:46:17 +0200

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

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

   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
issue

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

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.

> Tom

Regards
Pascal