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

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

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

---

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Jan 2015 19:34:23 -0500

I have added a number of CCs, I think that this fits into ANIMA best.

Hedanping (Ana) <[email-masked]> wrote:
    > 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.

    > The link is:

I read the document with great interest.
I found that you explained the incremental boot-strapping process quite well,
and nobody has clearly articulated the process yet.  People have just assumed
that everyone knows this process, but really it needs to get written down, so
I thank you for doing that.

Given that:

   Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standard
   security bootstrapping protocol should be light-weight with low
   complexity.  The protocol must allow for commissioning of devices

I was surprised that the draft then suggested EAP with PANA as a transport:

   If EAP is used, PANA can be used to relay the authentication message
   from configured FFDs to 6LBR.  If the validation is successful, the
   IP address and network key are generated and delivered to the FFD.

But, EAP-TLS with PANA is exactly what the Zigbee IP specification has
specified.  Do you envision any changes from that specification?
A minority of people had prefered this mechanism for 6tisch-security, but
none stepped forward to write up that mechanism.   Perhaps this draft could
fulfill that need?

You write that the IP address would be generated; usually that occurs via
distribution of PIOs via ND (router-adveristments) or RPL.  Were you going to
suggest something else here?

From the ANIMA and 6tisch-security point of view, my view is that this is all
about the choice of certificates for the TLS setup.  Do you have any view on
how that might work?

The 6tisch-security bootstrap process aims to create a
YANG/CBOR-over-CoAP-over-DTLS session between a Join Coordinator and the
Joining Node: over that management link, security (and timeslot scheduling)
would be provisioned.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-