Re: [hiprg] Slot for the next IETF meeting

[Pascal Urien <[e-mail]>]

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




> Regards,
> Tom
>

Regards
Pascal