Subject: Re: [6tisch] [6lo] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things

From: Rene Struik <[email-masked]>
Date: Tue, 20 Jan 2015 09:44:28 -0500

Hi Ana:

Thanks for your note below. Since your draft cross-references draft-struik-6tisch-security-architectural-considerations-01, your comments and observations on this would be most welcome.

Best regards, Rene

On 1/18/2015 10:02 PM, Hedanping (Ana) wrote:
> Hi all,
> A new draft is submitted, it's about the security bootstrapping architecture and methods for IoT networks that implement IETF protocols (e.g. 6LoWPAN, 6lo, RPL, AODV, DSR) over IEEE 802.15.4.
>
> Two types of bootstrapping methods are developed: network level bootstrapping and joining device level bootstrapping
>
> The link is: http://tools.ietf.org/html/draft-he-iot-security-bootstrapping-00
>
> Your comments are welcome!
>
> Cheers,
> Danping
>
> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, January 19, 2015 10:49 AM
> To: [email-masked]
> Subject: I-D Action: draft-he-iot-security-bootstrapping-00.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>      Title           : Security Bootstrapping of IEEE 802.15.4 based Internet of Things
>      Author          : Danping He
> 	Filename        : draft-he-iot-security-bootstrapping-00.txt
> 	Pages           : 10
> 	Date            : 2015-01-18
>
> Abstract:
>     Network level security bootstrapping and joining device level
>     security bootstrapping mechanisms are described in this document.
>     They are proposed for security bootstrapping of the Internet of
>     Things networks, which implement IETF protocols (e.g. 6LoWPAN, 6lo,
>     RPL, AODV, DSR) over IEEE 802.15.4.  The network level security
>     bootstrapping is useful at the very beginning of a newly deployed IoT
>     network.  It automatically and hierarchically adds all the devices to
>     security domain and helps establish security communication.  The
>     joining device level security bootstrapping provides comprehensive
>     mechanism for different IoT devices joining an existing IoT network.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-he-iot-security-bootstrapping/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-he-iot-security-bootstrapping-00
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

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

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Wed, 21 Jan 2015 02:21:19 +0000

Hi Rene,
Thank you for your reply. It would be great if you have any comments on my draft ^_^.  http://tools.ietf.org/html/draft-he-iot-security-bootstrapping-00
We can also discuss more on the security topics for 6lo or 6tisch environment.

I took a quick review on your draft, the description is clear. The architecture you proposed not only covers the secure joining (authentication) issue, but also covers other issues like authorization.
A main problem of your solution may be the neighbor node, which is an authenticator as well as a proxy. For a constrained node, even a FFD, the authentication task is too heavy, imagine that devices from different vendor can join the same domain.
Thoughts? 

Ps. I need more time to think about the authorization architecture mentioned in your draft

Regards,
Ana

> From: Rene Struik [mailto:[email-masked]]
> Sent: Tuesday, January 20, 2015 10:44 PM
> To: Hedanping (Ana); [email-masked]
> Cc: [email-masked]
> Subject: Re: [6lo] Comments needed for Security Bootstrapping of IEEE
> 802.15.4 based Internet of Things
> 
> Hi Ana:
> 
> Thanks for your note below. Since your draft cross-references
> draft-struik-6tisch-security-architectural-considerations-01, your comments
> and observations on this would be most welcome.
> 
> Best regards, Rene
> 
> > A new draft is submitted, it's about the security bootstrapping architecture
> and methods for IoT networks that implement IETF protocols (e.g. 6LoWPAN,
> 6lo, RPL, AODV, DSR) over IEEE 802.15.4.
> >
> > Two types of bootstrapping methods are developed: network level
> bootstrapping and joining device level bootstrapping
> >
> > Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >

---

From: Rene Struik <[email-masked]>
Date: Tue, 20 Jan 2015 22:59:46 -0500

Hi Ana:

Thanks for your note. Indeed, in the draft, the neighbor node has a role 
that stretches further than simply relaying messages. Right now, the 
"weakened" role of neighbor node as relay node only is alluded to in 
remark #6 of section 1.3.3 of 
draft-struik-6tisch-security-architectural-considerations-01:

    The join protocol above can also be "weakened", e.g., by
    removing authentication of the neighbor node to the joining node
    or vice-versa. As already said, this might open the protocol to
    wide-spread denial of service attacks on the network (in case
    the neighbor node simply forwards any joining node traffic,
    without inspection) or denial of service attacks on the joining
    node (in case the neighbor node is a bogus node or a node of an
    alien network). In some settings, though, practical trade-offs
    may favor such a "weakened" approach, e.g., if one wishes to
    "sprinkle" in sufficiently many neighbor nodes to guarantee
    connectivity to the server during initial deployment. If so,
    one should still have a fall-back strategy in place should
    denial of service attacks become a reality. (NOTE: These
    "weakened" versions will be analyzed in more detail in a later
    version of this draft.)

As suggested, this will be examined in greater detail in a later version 
of the draft.

Best regards, Rene