I'd recommend we document consecutive steps that bring a piece of 6tisch product from manufacturing to full operation to EOL -- in the context of security. Agreeing to naming the steps (e.g., provisioning, bootstrapping, commissioning, etc.) and input&output of each step would be useful.
Once we do that and get on the same page, then we can proceed to what parts of that we can standardize in this WG. A lot of early-steps are very scenario- (product type, deployment type, etc.) specific. So, we cannot possibly reach the ideal IETF case: mandating one and only credential/algorithm/protocol to use. my o.o2 cents Alper On May 7, 2015, at 6:58 PM, Timothy J. Salo wrote: >> It was in that spirit that I proposed using an LED as a low-sensitivity >> photodiode (which admittedly is a 2-terminal device, not what I had >> sleepily misstated as a 3-terminal device), together with a smartphone. >> The smartphone need not be connected to the target network if it merely >> serves as an optical relay proxy to convey credentials between a device >> currently in the network and the new device. >> >> Conveying a device credential to a network agent or proxy might be >> performed simply by having the smartphone scan a QR code on the device >> or its packaging, then conveying that optically or by RF to the proxy or >> agent, or by normal WiFi or cell connection to a site JCE. > > This seems like an area where a specification should include > requirements, but not solutions. That is, it might be reasonable > to require that devices include some process by which certain values > are configured as part of the provisioning and/or commissioning process. > > Typically, some vendors will do this better than others. For example, > some vendors might enable customers to do this themselves with a > smartphone app, while vendors may require a trip to the factory. > Personally, I don't think that standards should try to minimize > the advantage that a vendor might gain by making greater > investments in technology (in commissioning/provisioning technology, > in this case). > > Some beacon vendors are starting to do some interesting things in this > area. In particular, some beacons can be configured from a smartphone. > Of course, beacons have the advantage that they have a Bluetooth LE > interface. > > And, at least one beacon vendor permits customers to load new firmware > into a beacon from a smartphone. (Shouldn't the ability to load > new firmware into be node be a security requirement?) > > -tjs > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
