Subject: Re: [hiprg] some questions for draft-irtf-hiprg-rfid-02

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 28 Mar 2011 08:33:12 -0700

> 
> From: Pascal Urien [mailto:[email-masked]]
> Sent: Monday, March 28, 2011 6:10 AM
> To: Henderson, Thomas R
> Cc: [email-masked]; Gyu Myoung Lee;
> [email-masked]; [email-masked]
> Subject: Re: [hiprg] some questions for draft-irtf-hiprg-rfid-02
> 
> Hi Thoams
> 2011/3/28 Henderson, Thomas R <[email-masked]>
> 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.
> 
> The draft targets the protection of the ID (of the RFID). It MAY be an
> EPC Code, but also an other class of ID (why not an HIT ?)
> 
> 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?
> 
> The issue with the HTI-I is that it MUST not be a fix value, in order
> to avoid a direct link between an object and its HIT
> 
> The portal is identfied by its HIT value, zero meaning implicitely
> known (i.e the portal of a domain)
> 
> 
>> 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.
> 
> BLIND has no cryto agility, it works with a fix algorithm. From a
> cryptpgraphics point of view the f function may be a bijective
> application (reversible) or a surjective apllication (hash)
> 
>  A profile of HIP_RFID COULD be compatible with blind  with f a
> bijection and f(r1,r2, HIP_I), i.e. f is a protected value of HIP_I
> 
>

Your points are important clarifications that we should try to include in the draft.  Especially what role the HITs play in different variations of the protocol, and how this is different from traditional HIP.

>> 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?
> 
> 
> What we need for ESP is
> - A negociation of the Security Association SA, i.e. selected
> algorithms for encryption and data integrity
> - A formula, like Key(s) = PRF (r1,r2, ID, others parameters) in order
> to compute the SA keys
> 

again, please include the above in an update

> -
> 
>> 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.
> 
> Agree. I suggest to focus on the case where no ESP channel is opened.
> 
> A next draft could focus on the ESP negociation.

Thanks for the quick response.

Tom