From thomas.r.henderson@boeing.com Wed Jun 13 10:05:39 2012 Return-Path: X-Original-To: hiprg@ietfa.amsl.com Delivered-To: hiprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C3221F856C for ; Wed, 13 Jun 2012 10:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8yNLSJd917H for ; Wed, 13 Jun 2012 10:05:38 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id BBB2421F8514 for ; Wed, 13 Jun 2012 10:05:38 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5DH5Pf4030885 for ; Wed, 13 Jun 2012 12:05:26 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5DH5OBT030874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jun 2012 12:05:25 -0500 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5DH5aVe022601; Wed, 13 Jun 2012 10:05:36 -0700 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5DH5ZFU022561 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 13 Jun 2012 10:05:36 -0700 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.238]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Wed, 13 Jun 2012 10:05:35 -0700 From: "Henderson, Thomas R" To: "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 X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: [hiprg] review of HIP RFID draft X-BeenThere: hiprg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Host Identity Protocol \(HIP\) Research Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 17:05:39 -0000 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 expe= rimental RFC, while the HIP RG remains open. When we have discussed this draft in the past, RG members have expressed in= terest in the general topic of HIP/RFID integration. I'd like to ask the R= G 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), s= uch 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 trigg= er 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 securit= y section suggests that the portal and reader should operate over a secure = channel; otherwise, the RFID could be subjected to resource depletion attac= ks - the portal and RFID share secret keys; this allows the portal to learn th= e RFID EPC-code while other nodes cannot learn this. Two cases are elabora= ted: 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 mak= e 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