Yikes! Not at all. I'm interested in a mechanism by which people who care about security can get what they need, and people who don't care about security don't need to be bothered. I don't see a need for a global registry, although I can imagine one emerging. I'm picturing a separate certification server for industry group X, my paranoid home security system Y, and refinery Z. The policies on things like privacy can be set by the individual groups on their specific server(s), depending on the application, etc.

My vote is for ECC. Do we have any unencumbered ECC-based RFCs to look to for guidance?

ksjp

Pascal Thubert (pthubert) wrote:
Hi Kris:

It seems to me that we are talking about another global distributed
Internet registry with the capability to store tens of billions of
entries.

A node would really own the 64bit ID once it would have registered it.
IEEE would keep some ranges and free some other up for IPv6 and others
to jump in and allocate IDs formed some other ways like CGA. Then a web
of servers would keep track of unique ids, associated keys and more
stuff overtime.

- This obviously might cause privacy issues so this ID would not be to
be used lightly
- There would be a need to obtain temporary IDs
- This could help forgery detection so I'm sure we could get some
support for the effort :)

What do you think?

Pascal

-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Kris Pister
Sent: lundi 15 juin 2009 02:09
To: Rene Struik
Cc: [email protected]
Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE:
ad hoc whiteboard
I agree.  The ability to do stuff like this is one of the big
advantages
of being connected with the internet.  Let's use it.
As usual Rene, I'm going to ask you to tell me exactly what I'm
supposed
to buy from you (I mean "implement", sorry). :)
What's right approach?  Do we start with what you did in Zigbee, or
isa100, or an existing rfc, or what?

ksjp

Rene Struik wrote:
Hi Richard:

A simple approach avoiding duplicate device identifiers would be to
register devices with a registration
authority and hand out device certificates that bind the device id with
public/private keying material. If
devices can only gain access to a network by presenting their public
key certificate, this would push counter-
feit devices off the cliff, since the registration authority would not
allow registration of more than one
device with the same device id.
(Obviously, one can still try and clone a device by trying and
extract private keys as well and copying this
info to a number of devices, all with the same device id, something -
if deemed to be a real risk - to be
dealt with by proper implementation security and security techniques
along the supply chain.)
Best regards,

Rene

-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Richard Kelsey
Sent: Friday, June 12, 2009 11:18 AM
To: Rene Struik
Cc: [email protected]
Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE:
ad hoc whiteboard (was: [Fwd: New
Version Notification for draft-ietf-6lowpan-nd-03])
   From: Rene Struik <[email protected]>
   Date: Thu, 11 Jun 2009 16:44:46 -0400

   One cautionary node: in my mind, secure, yet easy to use device
   configuration and trust lifecycle management relies on devices to
be
   uniquely identified in a static way, in a vendor independent
   fashion.

Sadly, as I learned on another part of this thread, it
appears that we may not be able to rely on having static,
globally-unique identifiers.  Manufacturers of
counterfeit-branded devices have a disincentive to
cooperate.

   As such, this assumes a globally unique name space across all
   nodes. This suggests that "globally unique" is not a proper
adjective
   for "16-bit addresses" (unless you wish global device deployment
to be
   limited to 64k devices only [which I hope not...]).

"Globally unique" was indeed incorrect.  I should have
said "unique within the LoWPAN" or some such.

                                  -Richard Kelsey
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

Reply via email to