I agree that the mechanism for K1 is concrete, but the rationale behind pre-provisioning (in whatever flavor its instantiated) is somewhat abstract, since it¹s a concept with a numper of concrete mappings, per the examples I earlier enumerated. I included cable modems and residential gateways because they have pre-provisioned (some at manufacturing, some at fulfillment) certificates or PSKs that allow bootstrapping of other trust relationships. 802.1AR is another example (incidentally, 802.1AR was used in an ANIMA presentation in Dallas).
I think if our requirements for zero-touch in 6tisch overlap significantly with the goals of ANIMA, then it might make sense for ANIMA to handle common bootstrap issues. Some of what I¹m talking about is not exactly what I would call ³minimal², but the concept I¹m talking about still applies (with regard to the pre-provisioning of K1). Randy On 5/5/15, 9:45 PM, "Michael Richardson" <[email protected]> wrote: > >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 =- > > > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
