Re: [hiprg] Slot for the next IETF meeting

["Henderson, Thomas R" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Andrei Gurtov
> Sent: Monday, October 19, 2009 5:20 AM
> To: Pascal Urien
> Cc: [e-mail]
> Subject: Re: [hiprg] Slot for the next IETF meeting
>
> -----BEGIN PGP SIGNED MESSAGE-----
> 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?

Regards,
Tom