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

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 28 Mar 2011 05:42:55 -0700

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

---

From: Pascal Urien <[email-masked]>
Date: Mon, 28 Mar 2011 15:10:05 +0200

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

>
> 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
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hiprg
>