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

[Pascal Urien <[e-mail]>]

Hi Thoams

2011/3/28 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.
>

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


>
> 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

-

>
> 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.


>
> - Tom
>
>
Pascal

>
> _______________________________________________
> hiprg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/hiprg
>