[hiprg] some questions for draft-irtf-hiprg-rfid-02

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

Pascal, Guy, and Guy,
I had a few questions and comments regarding the most recent draft on HIP support for RFID that we could perhaps try to discuss at the meeting tomorrow (or on the list in the meantime).

As background, it seems that the main goal of this protocol is to avoid disclosing the EPC to unauthorized readers; the RFID can disclose it to those portals that hold a shared secret with the RFID.  

In the current draft, there seems to me that there is no need to include host identifier fields in this protocol.  The draft states that the HIT-I is a random number and the HIT-R could be a null value.  All of the identification seems to be done on the basis of the f value passed in the exchange, which contains enough information to find the EPC.  Could you explain how HITs are used, if at all?  

On a related note, the last sentence in Section 1 mentions that it is similar to the BLIND in the case that only one HIT is blinded.  I am wondering whether that case applies here-- the initiator host identifier needs to be blinded, but the responder HIT doesn't really matter.  This left me wondering whether the protocol could be refactored as a variant of BLIND, in which case the EPC could be somehow embedded in the HIT-I and recoverable based on the shared secret and nonce exchange.  For example, make the HIT-I some reversible function f(key,EPC).  That would restore the use of HITs in the protocol.

It wasn't clear to me how ESP would work, how are the keys derived for it?  The existing keys in the draft seem to be directly drawn from functions such as g(r1,r2, EPC) but there seems to be no analogy to the DH keymat derivation process in HIP.  Could you clarify what are the requirements in your framework for a general key derivation function?

Another major section missing in this document is the Security Considerations section, which will need to be carefully written to state the security claims and known vulnerabilities of this protocol.

- Tom