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

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 06 Nov 2017 01:37:24 -0800

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.

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/

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

Thanks for the initiative in documenting the valuable work in IOT security
implementation and crypto comparison. -Samita

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 6 Nov 2017 09:39:08 +0000

Hi Samita,

Do you think PUFs are useful authentication technologies for IoT devices?

Ciao
Hannes

-----Original Message-----
From: IoT-DIR [mailto:[email-masked]] On Behalf Of Samita Chakrabarti
Sent: 06 November 2017 10:37
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [IoT-DIR] Iotdir early review of draft-ietf-lwig-crypto-sensors-04

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.

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/

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

Thanks for the initiative in documenting the valuable work in IOT security implementation and crypto comparison. -Samita

_______________________________________________
IoT-DIR mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iot-dir
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 6 Nov 2017 20:21:47 -0800

Hi Hannes,
I have not done comparison with other technologies. But as I mentioned that
it exists. I like the fact it can generate unique 'intrinsic-id' based on
the physical properties of the chip-set. If IOT-DIR folks like to know
more, perhaps I can find out if there is a remote presentation and Q&A
session possible from the Intrinsic-id folks sometime in the near future. (
Disclaimer: I have no particular interest other than knowing more about the
feasibility  of application of that technology) I was thinking that this ID
can be used in any mutual authentication protocols ( especially generating
the private key). Do you have more information on them or think otherwise ?

Regards,
-Samita

On Mon, Nov 6, 2017 at 1:39 AM, Hannes Tschofenig <[email-masked]
> wrote:

> I have reviewed draft-ietf-lwig-crypto-sensors-04 document for
> IOT-Directorate review. The following are my comments:
>
> important for IOT devices  all the way from 'bootstrapping and management'
> to  application security. That perhaps can include obtaining IP-addresses
> 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.
> 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 ?
> 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 ?
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>

---

From: Rene Struik <[email-masked]>
Date: Tue, 7 Nov 2017 09:52:33 -0500

Hi Samita, Hannes, et al:

I gave a presentation on physically unclonable functions at NIST key 
management workshop 5 years ago (see [1]), which explains the main 
concepts. Please note that the "unique device property" is lost as soon 
as the PUF f or a deterministically-derived key K=H(f) is exposed (see 
Slide 6 -- hence, the color coding in "red", not to be exposed 
material). One needs to do extra tricks, i.e., design a 
challenge-response protocol that witnesses possession of f without 
revealing this, to use this for ongoing authentication. There are ways 
to do this, though.

Best regards, Rene

[1] R. Struik, “Secure Key Storage and True Random Number Generation,” 
presented at/NIST-KMW: NIST Cryptographic Key Management Workshop/, 
Gaithersburg, MD, September 10-11, 2012

Available from 
https://csrc.nist.gov/csrc/media/events/cryptographic-key-management-workshop-2012/documents/struik_nist_kmw_2012.pdf

On 11/6/2017 11:21 PM, Samita Chakrabarti wrote:
> Hi Hannes,
> I have not done comparison with other technologies. But as I mentioned 
> that it exists. I like the fact it can generate unique 'intrinsic-id' 
> based on the physical properties of the chip-set. If IOT-DIR folks 
> like to know more, perhaps I can find out if there is a remote 
> presentation and Q&A session possible from the Intrinsic-id folks 
> sometime in the near future. ( Disclaimer: I have no particular 
> interest other than knowing more about the feasibility  of application 
> of that technology) I was thinking that this ID can be used in any 
> mutual authentication protocols ( especially generating the private 
> key). Do you have more information on them or think otherwise ?
>
> Regards,
> -Samita
>
> On Mon, Nov 6, 2017 at 1:39 AM, Hannes Tschofenig 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Samita,
>
>     From: IoT-DIR [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Samita Chakrabarti
>     To: [email-masked] <mailto:[email-masked]>
>     Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>;
>     [email-masked]
>     <mailto:[email-masked]>
>     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
>     <https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-03>) in those
>     cases where each  device has an IP address.
>
>     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:
>     <https://www.intrinsic-id.com/intrinsic-id-joins-wi-sun-alliance/>
>
>     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 ?
>     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 ?
>
>     Thanks for the initiative in documenting the valuable work in IOT
>     security implementation and crypto comparison. -Samita
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/iot-dir>
>     IMPORTANT NOTICE: The contents of this email and any attachments
>     are confidential and may also be privileged. If you are not the
>     intended recipient, please notify the sender immediately and do
>     not disclose the contents to any other person, use it for any
>     purpose, or store or copy the information in any medium. Thank you.
>
>
>
>
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 Nov 2017 07:31:50 +0000

Thanks for sharing your presentation, Rene.

Do you consider PUFs useful for IoT security? That’s a point I couldn’t really see from your slide deck.

Ciao
Hannes

From: Rene Struik [mailto:[email-masked]]
Sent: 07 November 2017 15:53
To: Samita Chakrabarti; Hannes Tschofenig
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: (on PUFs) Re: [Lwip] [IoT-DIR] Iotdir early review of draft-ietf-lwig-crypto-sensors-04

I gave a presentation on physically unclonable functions at NIST key management workshop 5 years ago (see [1]), which explains the main concepts. Please note that the "unique device property" is lost as soon as the PUF f or a deterministically-derived key K=H(f) is exposed (see Slide 6 -- hence, the color coding in "red", not to be exposed material). One needs to do extra tricks, i.e., design a challenge-response protocol that witnesses possession of f without revealing this, to use this for ongoing authentication. There are ways to do this, though.

Best regards, Rene

[1] R. Struik, “Secure Key Storage and True Random Number Generation,” presented at NIST-KMW: NIST Cryptographic Key Management Workshop, Gaithersburg, MD, September 10-11, 2012

Available from https://csrc.nist.gov/csrc/media/events/cryptographic-key-management-workshop-2012/documents/struik_nist_kmw_2012.pdf

On 11/6/2017 11:21 PM, Samita Chakrabarti wrote:
Hi Hannes,
I have not done comparison with other technologies. But as I mentioned that it exists. I like the fact it can generate unique 'intrinsic-id' based on the physical properties of the chip-set. If IOT-DIR folks like to know more, perhaps I can find out if there is a remote presentation and Q&A session possible from the Intrinsic-id folks sometime in the near future. ( Disclaimer: I have no particular interest other than knowing more about the feasibility  of application of that technology) I was thinking that this ID can be used in any mutual authentication protocols ( especially generating the private key). Do you have more information on them or think otherwise ?

Regards,
-Samita

On Mon, Nov 6, 2017 at 1:39 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Samita,

Ciao
Hannes

-----Original Message-----
From: IoT-DIR [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Samita Chakrabarti
Sent: 06 November 2017 10:37
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [IoT-DIR] Iotdir early review of draft-ietf-lwig-crypto-sensors-04

Other comments:
Introduction:

Section 2:

Section 5:

Section 9:

Section 13:

_______________________________________________
IoT-DIR mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/iot-dir
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Lwip mailing list

[email-masked]<mailto:[email-masked]>

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

---

From: Rene Struik <[email-masked]>
Date: Wed, 8 Nov 2017 11:07:28 -0500

Hi Hannes:

It is hard to answer a generic "useful for" question. Question for me is 
which hard security lifecycle problem you are trying to solve and how 
(presumably) physically unclonable functions could be a potential fit in 
addressing this problem; another question is where IoT security 
lifecycle is different than any security lifecycle (i.e., without the 
IoT "prefix").

My slides show two main uses of PUFs: burying keys and generating noisy 
non-repeating values (see my slides). There are some technical 
challenges as well and ways to give the technology a further "booster 
shot" (challenges/booster shot could be discussed offline).

Best regards, Rene

On 11/8/2017 2:31 AM, Hannes Tschofenig wrote:
> Do you consider PUFs useful for IoT security? That’s a point I 
> couldn’t really see from your slide deck.
>
> Ciao
>
> Hannes
>
> *From:*Rene Struik [mailto:[email-masked]]
> *Sent:* 07 November 2017 15:53
> *To:* Samita Chakrabarti; Hannes Tschofenig
> *Cc:* [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> *Subject:* (on PUFs) Re: [Lwip] [IoT-DIR] Iotdir early review of 
> draft-ietf-lwig-crypto-sensors-04
>
> concepts. Please note that the "unique device property" is lost as 
> soon as the PUF f or a deterministically-derived key K=H(f) is exposed 
> (see Slide 6 -- hence, the color coding in "red", not to be exposed 
>     I have not done comparison with other technologies. But as I
>     mentioned that it exists. I like the fact it can generate unique
>     'intrinsic-id' based on the physical properties of the chip-set.
>     If IOT-DIR folks like to know more, perhaps I can find out if
>     there is a remote presentation and Q&A session possible from the
>     Intrinsic-id folks sometime in the near future. ( Disclaimer: I
>     have no particular interest other than knowing more about the
>     feasibility  of application of that technology) I was thinking
>     that this ID can be used in any mutual authentication protocols (
>     especially generating the private key). Do you have more
>     information on them or think otherwise ?
>
>     Regards,
>
>     -Samita
>
>     https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-03) in those
>     [email-masked] <mailto:[email-masked]>
>
> email:[email-masked] <mailto:[email-masked]>  | Skype: rstruik
> recipient, please notify the sender immediately and do not disclose 
> the contents to any other person, use it for any purpose, or store or 
> copy the information in any medium. Thank you.