Dear Samita,Thanks for the detailed review and positive comments. We have now submitted an updated version which can be found here: https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-05. The diff from the previous version can be found here: https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-crypto-sensors-05.
Please find our responses to your specific comments inline. Let us know if the modifications are not sufficient.
--Mohit On 11/06/2017 11:37 AM, Samita Chakrabarti wrote:
You rightly point out that security is important at all the different stages in the lifecycle of an IoT device. The Thing-to-thing Research Group (T2TRG) has a security considerations document (https://tools.ietf.org/html/draft-irtf-t2trg-iot-seccons-09) that discusses the different stages in the lifecycle and reviews the possible security threats. We reference this document in the related work section. We have modified the text to better highlight this.Reviewer: Samita Chakrabarti Review result: Ready with Nits I have reviewed draft-ietf-lwig-crypto-sensors-04 document for IOT-Directorate review. The following are my comments: General : The document is easy reading and informative about current and previous work. It is ready to publish with minor changes based on review comments. Other comments: Introduction: It might be useful to discuss/clarify that multi-level security may be important for IOT devices all the way from 'bootstrapping and management' to application security. That perhaps can include obtaining IP-addresses securely, mutual authentication between server and devices , etc. ( see https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-03) in those cases where each device has an IP address.
Our focus in this document is mostly on IETF IoT security work. You correctly pointed out that there are many L2 protocols and they might use different provisioning methods.This can be challenge. Therefore we have added a new bullet in section 3. I provide the relevant text here for your convenience: "Smart object networks may rely on different radio technologies. Provisioning methods that rely on specific link-layer features may not work with other radio technologies in a heterogeneous network.".Section 2: Regarding problems of provisioning and management of networks for the IOT devices there may be additional issues – 1) different types of IOT devices and the lack of standards way to provision them as they might be talking different RF technologies and running L2 protocols only. 2) The iot nodes may be moving individually or collectively and change networks; identifying the movement of the iot nodes or identifying a particular node at any point of time uniquely requires an intrinsic identification which might be useful to set during bootstrapping of the node Regarding related work – does it consider IETF IOT security work only? There have been some work and thought process going on regarding blockchain IOT security in the industry. Perhaps that is out-of-scope of this document, but I wanted to mention for authors’ considerations. Section 5: Authors of the document may also want to browse a SRAM PUF based technology which provides unique ID based authentication mechanism. https://www.intrinsic-id.com/intrinsic-id-joins-wi-sun-alliance/
Identifying nodes or networks as they move can be seen as a requirement or an invasion of privacy, depending on the application scenario. Based on security directorate feedback on privacy of identifiers from Christian Huitema, we added this text: "small resource-constrained devices are often shipped with a single static identity. In many cases, it is a single raw public key. These long-term static identities makes it easy to track the devices (and their owners) when they move. The static identities may also allow an attacker to track these devices across ownership changes.".
Section 10, 11, 12, 13, 14 were related but somehow incorrectly placed. This was an xml formatting error on our part. We have now fixed section/subsection order.Section 9: Does the example simulate any particular deployment model or research experiments ? It might be good to clarify that. Section 10 and 11: Looks like section 11 is closely related to section 10. Should they be combined together ? Else some more text is needed in section 10 on design trade-offs.
We do rely on a particular deployment model in our experiments. This is documented in section 4 and 7. I provide the relevant text snippet here for your convenience: "The security of this system relies on an SSH-like approach. In Step 1, upon first boot, sensors generate keys and register themselves in the publish-subscribe broker. Their public key is submitted along with the registration as an attribute in the CORE Link Format data [RFC6690]."
Section 13: Does this document recommend one layer of security to IOT devices ? There are different types of IOT devices – some of them are very tiny and some are more capable. Some definitely benefit for multi-level security than single layer of security. L2 security is generally recommended for for all IOT networks. Does data object protection only protect the application data (payload) or more ?
For our experiments, we only protected CoAP application data (payload).
Thanks for the initiative in documenting the valuable work in IOT security implementation and crypto comparison. -Samita
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
