Turner, Randy <[email protected]> wrote: > Yes, by pre-provisioned, I meant at any time prior to the device being > deployed and operational - (what telcos sometimes call "fulfillment") - > this means during manufacturing time or by a field service tech > installing the device. And I'm treating "K1" in an abstract sense, > where K1 is essentially the idea of provisioning trust in the device > prior to being in an online operational state.
We are talking about K1 being set by the manufacturer, i.e. before
"fulfillment", and the device being shipping directly to the consumer without
touching any field service tech, etc. That's what "zero touch" means.
Granted: minimal is not zero touch.
And K1 is not abstract, it's very definite, and it isn't abstraction for
providing trust into the device. It's about getting minimally on the network
so that something more complex can occur. That's *ALL*.
There is nothing more. The rest is not part of minimal, but getting K1 right
in minimal matters to later work.
> Examples of this type of pre-provisioned trust are cable modems, some
> residential gateways that use TR-069, and AMI endpoints just to name a
> few.
On TR-069 devices (which, wearing the [email protected] hat, I'm rather
familiar with), the operator *communicates* the intent to the device of which
network it should be connected to by... well.. plugging the cable in.
This seems a overly subtle point, but it's really important, because with
wireless, if there are multiple networks around, there is no such active
intent as plugging a cable in.
Further, the TR-069 trust model assumes that *all* cable operators are
equally trusted. That is, I can take a cable modem from my house (Rogers
cable land), and bring it down to Atlanta (Comcast I think) and plug it in,
and the *cable modem* won't care. Further, since the root CA in the cable
modem is provided by CableLabs, Comcast will be able to authenticate the
device *just fine* (They may not be willing to provide you service, that's a
different discussion).
The important point here is that *at no point* does the cable modem actually
authenticate that this is the correct cable operator. Seriously. If a truck
of cable modems on their way to Ottawa gets diverted to Atlanta, and Comcast
scans them, the vendor of the cable modems will never know.
The bulk of this work (at least from point of view) has/is moving from
6tisch-security design team to the ANIMA working group, btw.
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Michael
Richardson
> Sent: Tuesday, May 05, 2015 2:39 PM
> To: [email protected]
> Cc: Turner, Randy
> Subject: Re: [6tisch] Shipping minimal
> Turner, Randy <[email protected]> wrote:
>> I think it's a false assumption that just because K1 is pre-provisioned
>> that K2 will be pre-provisioned as well -- there are many network
>> success stories that utilize pre-provisioning of an endpoint-unique K1
>> to bootstrap other trust relationships.
> You didn't say what I said.,
> I'm saying that if K1 has to be provisioned in the field, (not
pre-provisioned at manufacturer time), that one might as well provision K2 to
as well.
> I wonder what you mean by "pre-provisioning" here, and if you can point
at the the success stories you mention.
>> -----Original Message-----
>> From: 6tisch [mailto:[email protected]] On Behalf Of Michael
Richardson
>> Sent: Tuesday, May 05, 2015 2:06 PM
>> To: [email protected]
>> Subject: Re: [6tisch] Shipping minimal
>> Tero Kivinen <[email protected]> wrote:
>>> Kris Pister writes:
>>>> > there would be no false sense of security
>>>>
>>>> Can we see a show of hands of all of the people on the list who
>>>> think that there is any sense of security from using a key that is
>>>> published in an RFC? No? No one?
>>> And ask that same question from normal users installing termostats or
>>> other internet of things devices?
>> But, 6tisch (minimal) is not targetted at that kind of use.
>> It's targetted at industrial users that need deterministic work.
>> Minimal is further targetted at well... interop.
>> Let me put it differently: Bluetooth didn't specify a default key, and
didn't do enrollment for headsets sanely, and now the "K1" *and* "K2" keys are
"0000"
>> We can't keep people from doing stupid things. We need known K1 in
order to bootstrap to a KMP in order to set up K2.
>> If K1 has to be provisioned, then K2 will get set at the same time, and
K1 and K2 will get set to "0000".
>> --
>> Michael Richardson <[email protected]>, Sandelman Software Works -=
IPv6 IoT consulting =-
>> P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.
>> This e-mail (including any attachments) is confidential and may be
legally privileged. If you are not an intended recipient or an authorized
representative of an intended recipient, you are prohibited from using, copying
or distributing the information in this e-mail or its attachments. If you have
received this e-mail in error, please notify the sender immediately by return
e-mail and delete all copies of this message and any attachments. Thank you.
>> _______________________________________________
>> 6tisch mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/6tisch
> --
> Michael Richardson <[email protected]>, Sandelman Software Works -=
IPv6 IoT consulting =-
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
