Dear colleagues:
Great suggestion.
I would suggest a systematic approach to this, where we start with the
join protocol scenario described in great detail in Section 1.3 of
draft-struik-6tisch-security-architectural-considerations-01. While the
description in that section does not cover all deployment scenarios
(yet) {as also acknowledged in that draft}, it provides a good starting
point. This also seemed to be in line of what was suggested as next step
during the informal (non-IETF) discussion on Thursday evening, March 24,
2015, by various stakeholders in Dallas.
In my mind, I think we can capture most deployment scenarios and
ultimately view these as an extension of the approach in that section.
Best regards, Rene
On 5/8/2015 4:07 AM, Alper Yegin wrote:
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
--
email: [email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
