Re: [Lwip] Iotdir early review of draft-ietf-lwig-crypto-sensors-04

[Mohit Sethi <[e-mail]>]

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:
> 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.
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.
>
> 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/
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.".

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 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.
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.

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
>
>