[hiprg] review of HIP RFID draft

"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Wed, 13 June 2012 17:05 UTC

From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: "hiprg@irtf.org" <hiprg@irtf.org>
Date: Wed, 13 Jun 2012 10:05:34 -0700
Thread-Topic: review of HIP RFID draft
Thread-Index: Ac1Jhr7OLDVRIFn9RMmrJHzqsjU6pg==
Message-ID: <758141CC3D829043A8C3164DD3D593EA1BD324E076@XCH-NW-16V.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [hiprg] review of HIP RFID draft
Precedence: list

This message is to review the current status of the HIP RFID draft: http://tools.ietf.org/html/draft-irtf-hiprg-rfid-05

Pascal has indicated an interest to try to progress this draft towards experimental RFC, while the HIP RG remains open.

When we have discussed this draft in the past, RG members have expressed interest in the general topic of HIP/RFID integration. I'd like to ask the RG to review the specifics of this draft.

This draft proposes an adaptation of HIP to support a use case in which an active RFID can communicate its EPC-code to a portal (several hops away), such that only the portal can discover the EPC-code. The draft proposes to adapt the HIP protocol in the following ways:
- the HITs are not cryptographic in nature; they are either null or a nonce value
- there is no Diffie Hellman key exchange
- there is an intermediate node (a reader) that acts as a catalyst to trigger an exchange between an RFID and a portal, and to facilitate the message transfer, but the reader does not learn the RFID identity
- the R1 can not be authenticated by the initiator (the RFID). The security section suggests that the portal and reader should operate over a secure channel; otherwise, the RFID could be subjected to resource depletion attacks
- the portal and RFID share secret keys; this allows the portal to learn the RFID EPC-code while other nodes cannot learn this. Two cases are elaborated:
1) the EPC-code is the only shared key, and the portal can recover this by trial-and-error. This relies on the list of known possible EPC codes being sparse in a large space of all possible EPC-codes.
2) a case in which a set of preshared keys is used for HMAC operations

There is also a mention of a HIP Encapsulation Protocol (HEP) that is left unspecified by this document.

I believe that there would need to be additional editorial work done to make it ready for the review process, but I would prefer to see whether there is any technical consensus first. As far as I can remember, this draft has not been carefully reviewed by any other RG members outside of the authors. To continue with this in the RG, we really need some other RG members to participate in the review and endorsement of this as a product of the RG. Please review this if you have interest in it moving forward.

- Tom

[hiprg] review of HIP RFID draft Henderson, Thomas R