Getting on with Things

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Michael and others,

This is a very interesting discussion.

On 3/9/16 3:35 PM, Michael Richardson wrote:
> I tend to agree... the only reason we aren't as "concerned" about non-IoT
> things is because we can (in theory) update them, the devices are used
> directly by humans who sometimes notice if they are broken (or p0wned),
> and the passwords, as weak as they are, can in theory, be stored in the
> human, rather than in the system.  (In practice: it's better to let the
> browser store them)

Things being what they are will vary in shape, size, function,
capability, and support.  It's that latter issue that I get worked up
about.  There are a number of different connection models that will all
be in play, one of them being CoAP, but as common one being where
devices "call home".  In the latter case there will be no password.  In
the former, there needs to be a step to somehow initialize credentials. 
I think the work you're doing in ANIMA is a really good example of that,
and deserves a lot more eyes.  Many different work flows need to be
worked out.  I am somewhat less concerned about industrial or
enterprise, since we know how to do 802.1X and the 802.1AR, but I am
very concerned about the consumer case.

But even once that happens, the Thing remains at risk, due to
vulnerabilities.  What's more, Things that we think are secure today (we
don't really know) will assuredly not be in the future, because at some
point the manufacturer is going to stop supporting the device.  This can
take as little as 90 days and as long as 40 years, but it will happen. 
And then what?  Even if the manufacturer is still supporting the device,
the ability to update it may be limited, depending on how it is
implemented and deployed, and what its duty cycle is.

And so the question turns to this: how do we add layers of protection to
Things when they may not be in a good position to protect themselves? 
I've floated an idea in draft-lear-mud-framework-00.txt which talks a
little about this.  The idea is to learn what the Thing is and then have
its manufacturer communicate to a deployment how the thing is intended
to be used.  This is not meant as the Be All End All of Thing
Protection, but to reduce its threat surface.  Hopefully substantially. 
And I'm looking for ways (and dare I say collaborators) to improve the work.

Eliot

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]