Subject: Re: [hiprg] New thoughts on HIT construction

From: Tobias Heer <[email-masked]>
Date: Mon, 19 Jul 2010 15:41:08 +0200

Hello Pascal, 

I briefly read draft-irtf-hiprg-rfid-00.txtand have some comments/questions in addition to Bob's comments:

A very minor issue: HIP-Tag may be easy to confuse with Host Identity Tag / HIT. I don't have a proposal for a better name but I believe a more different name could avoid some confusion.
Am 27.06.2010 um 18:50 schrieb Pascal Urien:

In section 1.4 you mention three entities but provide a list of five things, four of them being entities, one being a data structure implemented on one of the four. I think this list is a bit misleading and could be structured in a better way.

About the HAT: Is HIP Address translator really the right name for it? As far as I understood it, it is rather a protocol translator than an address translator.

Section 1.5 states that the HIT can be traced. Ephemeral HIs allow for some anonymity (equivalent to the one used in the RFID document) even in baseline HIP.

It would be good to state the security goals/services that the T-BEX offers in the beginning. Who authenticates to whom? What is the result of the T-BEX? One can derive these things from the technical description but explicitly stating these things might help comprehension.

What are the security assumptions? What is the attacker model? Is the reader trustworthy? Is an MITM attack by the reader an issue?

Do the new parameters use the same type space as baseline HIP? If yes, are they all non-critical? The critical bit seems not to be set in any of the parameters.

BR, 

Tobias

> Hi All,
> 
> The document draft-irtf-hiprg-rfid has been posted to ietf
> 
> See
> http://www.ietf.org/staging/draft-irtf-hiprg-rfid-00.txt
> 
> Following Thomas review
> (http://www.ietf.org/mail-archive/web/hiprg/current/msg00719.html) ,
> the document draft-urien-hip-tag-03 has been modified and reviewed by
> Pascal Urien,  Gyu Myoung Lee, and Guy Pujolle
> 
> Best Regards
> 
> Pascal
> _______________________________________________
> hiprg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hiprg

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 19 Jul 2010 10:43:04 -0400

On 07/19/2010 09:41 AM, Tobias Heer wrote:
> Hello Pascal,
>
> I briefly read draft-irtf-hiprg-rfid-00.txt and have some comments/questions in addition to Bob's comments:
>

everything is in a name, and naming is everything. So it would be good 
for us to come up with a usable name for this. Good catch.

> About the HAT: Is HIP Address translator really the right name for it? As far as I understood it, it is rather a protocol translator than an address translator.

Is it more of a IP proxy service? The place where the device's 
communication gets stuffed into an IP datagram?

> Section 1.5 states that the HIT can be traced. Ephemeral HIs allow for some anonymity (equivalent to the one used in the RFID document) even in baseline HIP.

HITs here can either be random values as called out, or a hash of the 
device number. More on this at the end.

> What are the security assumptions? What is the attacker model? Is the reader trustworthy? Is an MITM attack by the reader an issue?

More in this area would be very useful. There have been pieces of this 
in the past presentations and I think in the paper behind this draft.

> Do the new parameters use the same type space as baseline HIP? If yes, are they all non-critical? The critical bit seems not to be set in any of the parameters.

As has been covered on the HIP list, we need to carefully think out our 
use of parameter types and be careful NOT to over use a parameter.

Now on to somemore thoughts on my part.

The ID uses SHA-1 in the hash based function. I have another 
recommendation. Go with one of the block-cipher hashs like: 
Matyas--Meyer--Oseas. This simplifies the coding demand on a tag that 
would also be implementing AES-CCM for data protection.

Matyas--Meyer--Oseas is used by Zigbee, but not being a Zigbee member 
(yet) I don't have details as to the selection process.

I do have some papers on 'PGV style block-cipher based hash functions' 
forwarded to me by a colleague that I could share if you need them.