Subject: [6tisch] 6top security

From: Randy Turner <[email-masked]>
Date: Thu, 19 Jan 2017 07:59:56 -0500 (EST)

Hi All,

In draft-ietf-6tisch-6top-protocol-03, the security considerations section implies no additional security mechanisms for 6top — instead, the draft relies on existing layer-2 security mechanisms for integrity and confidentiality.

I was curious if others in the WG have considered whether or not a one-hop neighbor is “authorized” to add a cell to another neighbor’s schedule?  We’re assuming if a neighbor has securely joined the network, then all neighbors are implicitly authorized to modify each other’s schedule (or possibly a PCE is authorized).

In looking at the IEEE 802.15.12 ULI work, there may be an opportunity to introduce authorization into the ULI, and the ACE group has one solution for potentially enabling this functionality.

Just curious if anyone on the list has considered authorization as a third security vector for 6top, in addition to confidentiality and integrity.

Thanks!

Randy

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 20 Jan 2017 12:41:49 +0100

Randy,

We have not ruled out neighbor-to-neighbor authentication, but would like
to keep that mechanism independent from draft-ietf-6tisch-6top-protocol to
that (1) draft-ietf-6tisch-6top-protocol doesn't define two things and (2)
we can assemble draft-ietf-6tisch-6top-protocol with different security
solutions.

Happy to hear input from others.

Thomas

On Thu, Jan 19, 2017 at 1:59 PM, Randy Turner <[email-masked]>
wrote:

> Hi All,
>
> In draft-ietf-6tisch-6top-protocol-03, the security considerations
> section implies no additional security mechanisms for 6top — instead, the
> draft relies on existing layer-2 security mechanisms for integrity and
> confidentiality.
>
> I was curious if others in the WG have considered whether or not a one-hop
> neighbor is “authorized” to add a cell to another neighbor’s schedule?
> We’re assuming if a neighbor has securely joined the network, then all
> neighbors are implicitly authorized to modify each other’s schedule (or
> possibly a PCE is authorized).
>
> In looking at the IEEE 802.15.12 ULI work, there may be an opportunity to
> introduce authorization into the ULI, and the ACE group has one solution
> for potentially enabling this functionality.
>
> Just curious if anyone on the list has considered authorization as a third
> security vector for 6top, in addition to confidentiality and integrity.
>
> Thanks!
>
> Randy
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: Randy Turner <[email-masked]>
Date: Fri, 20 Jan 2017 08:40:51 -0500 (EST)

Hi Thomas,

Thanks for the reply….you used the term “authentication” in your email below, however, the topic I  mentioned was “authorization”, and if the focus is on 6top core functionality for now, that’s fine - I was just curious if others considered authorization as a potential need for 6top.

Thanks,

Randy

On January 20, 2017 at 6:41 AM Thomas Watteyne <[email-masked]> wrote:

Randy,

We have not ruled out neighbor-to-neighbor authentication, but would like to keep that mechanism independent from draft-ietf-6tisch-6top-protocol to that (1) draft-ietf-6tisch-6top-protocol doesn't define two things and (2) we can assemble draft-ietf-6tisch-6top-protocol with different security solutions.

Thomas

On Thu, Jan 19, 2017 at 1:59 PM, Randy Turner <[email-masked]> wrote:

Hi All,

Thanks!

Randy

--

Thomas Watteyne, PhD

Co-chair, IETF 6TiSCH

www.thomaswatteyne.com