Subject: [6tisch] [email-masked]: New Version Notification for draft-richardson-6tisch-security-architecture-01.txt

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Mar 2014 04:42:24 -0500

There is much work to do.

<#secure method=pgpmime mode=sign>

Subject: New Version Notification for draft-richardson-6tisch-security-architecture-01.txt
From: [email-masked]
To: "Michael C. Richardson" <[email-masked]>, "Michael Richardson" <[email-masked]>
Date: Mon, 03 Mar 2014 01:18:46 -0800

A new version of I-D, draft-richardson-6tisch-security-architecture-01.txt
has been successfully submitted by Michael C. Richardson and posted to the
IETF repository.

Name:		draft-richardson-6tisch-security-architecture
Revision:	01
Title:		security architecture for 6top: requirements and structure
Document date:	2014-03-03
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-richardson-6tisch-security-architecture-01.txt
Status:         https://datatracker.ietf.org/doc/draft-richardson-6tisch-security-architecture/
Htmlized:       http://tools.ietf.org/html/draft-richardson-6tisch-security-architecture-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-richardson-6tisch-security-architecture-01

Abstract:
   This document details minimal layer-2 requirements for 6top use in
   industrial settings, and a few options for accomplishing this.  The
   layer-2 mechanism is then extended to provide for per-node
   authentication and authorization of the node/PCE communications.
   This internet-draft is intended for later inclusion into the 6tisch
   architecture document.

   This might be the worst written internet draft yet.  You have been
   warned

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.

The IETF Secretariat

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

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 3 Mar 2014 16:47:59 +0100

Michael,

Thanks for submitting this. I'd like to ask for reviewers to send their
notes about this drafts to the ML. Please do so by Wednesday so we can
integrate those by the WG meeting on Thursday.

Thomas

On Mon, Mar 3, 2014 at 10:42 AM, Michael Richardson
<[email-masked]>wrote:

> ---------- Forwarded message ----------
> Cc:
> Subject: New Version Notification for
> draft-richardson-6tisch-security-architecture-01.txt
>
> URL:
> http://www.ietf.org/internet-drafts/draft-richardson-6tisch-security-architecture-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-richardson-6tisch-security-architecture/
> Htmlized:
> http://tools.ietf.org/html/draft-richardson-6tisch-security-architecture-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-richardson-6tisch-security-architecture-01
>
> Abstract:
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Mar 2014 12:14:23 -0500

Herman Storey <[email-masked]> asked:
    > Do you intend to cover authentication of users or workers as well as
    > nodes?

and I answered:
    mcr> No.  Devices big enough to interact with humans in a meaningful way are big
    mcr> enough to run any number of existing protocols, and likely even web browsers.

Herman clarified his question:
    > Users or workers need to be authenticated at some level.  Some protocols
    > authenticate users at the application level, and some do not authenticate at
    > any level.  The protocols that do not authenticate basically give users
    > superuser to every machine on the network.

I answered:

6tisch does not interact with humans.

There are in general, no PCs or tablets involved: humans need to interact
with management systems.  How those management systems interact (are
authorized by or to) with sensors/actuators is up to an application specific
set of policies.  Whether the management system is or has "superuser"
priviledges on all other devices and doles that out to humans based upon a
local policy, or whether the human is involved in the authorization is up to
the application-specific authorization server.

The ACE BOF (meeting tomorrow at IETF) deals with how authorization is dealt
with given that the devices are constrainted, and likely can not evaluate
complex policies.

6tisch only deals with m2m connectivity: there are two kinds of interactions.
Those that permit a node to join the network, and those that permit a PCE to
update a schedule.

Being on the network SHOULD NOT in of itself, give any node any priviledge
other than being able to send packets.   Perhaps this is where our disconnect
is: I guess some industrial (15.4e) networks have trusted that every packet
on the network is authorized.

I asked if I might re-post his comments to the list, and Herman agreed.