Subject: [6tisch-security] security architecture and terminology updates

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Dec 2014 16:47:30 -0500

1) we have to have some security terminology for the architecture document,
   I have posted an email to the 6tisch list with proposed text.
   
2) I propose to remove the following text from the architecture document:
   section 4:

   -Security is often handled at layer 2 and Layer 4. Authentication
   -during the join process can be handled by the Protocol for Carrying
   -Authentication for Network access (PANA) [RFC5191].

and also:
   -(tbd PANA) There is a debate whether PANA (layer 3) or IEEE802.1x
   -(layer 2) should be used in the join process.  There is also a debate
   -whether the node should be able to send any unprotected packet on the
   -medium.  Regardless, the security model must ensure that, prior to a
   -join process, packets from a untrusted device must be controlled in
   -volume and in reachability.

I would add after a brief description of the 6top/YANG interface used by the
the PCE, which seems to be missing from section 4:

   +Security is performed at layer 2, but configured using the same
   layer-5 provisioning interface used for provisioning the schedule.

3) I would propose text about the join process as follows.  
   This is cut down and slightly edited from what was proposed two weeks ago.

X.1.  Entities involves in the join process

   The following actors are involved: there is a new joining node.  It
   is (radio) adjacent to the join assistant.  The join assistant is
   part of the production network, and participates in one or more
   DODAGs, such that it is reachable from the 6LBR, and the JCE.

X.2.  Join Protocol deliverables

   The ultimate goal of the join protocol is to provide a new node with
   locally significant security credentials so that it is able to take
   part in the network directly.  The credentials may vary by deployment.
   They can be one or both of:

   1)  a network-wide shared symmetric key (this is the production
       network key, or MasterKey)

   2)  a locally significant (one-level only) 802.11AR type LDevID
       certificate (which allows it to negotiate a pair-wise keys)

   These two items is delivered by JCE to the joining node using
   the 6top protocol.  That is, the JCE provisions using a secure
   "northbound" interface.  A Join Protocol describes the authentication
   of this interface.

   The above credential (2) can be used for authentication to generate per-peer
   L2, using a key exchange protocol.  The choice of key exchange
   protocol, and what kind of link and multicast keying needs to be done
   is also provisioned by the JCE.  There are a number of options for
   doing this, such as:

   1)  Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment]
       (IMPORTANT, a good option.  Uses certificates from common CA)

   2)  work in 802.15.9 (uses certificates from common CA)

   3)  Security Framework and Key Management Protocol Requirements for
       6TiSCH [I-D.ohba-6tisch-security] (this document provides the
       phase 0 required, using the network-wide shared key)

   4)  Layer-2 security aspects for the IEEE 802.15.4e MAC
       [I-D.piro-6tisch-security-issues]: the MasterKey is used to
       derive per-peer L2 keys

   Per-peer L2 keying is critical when doing peer-2-peer schedule
   negotiation over 15.4 Information Elements.  Therefore a network-wide
   layer-2 key is inappropriate for the self-organizing networks, and a
   protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys.

   For networks where there is a PCE present, it will do all schedule
   computation.  As a result the only trust relationship necessary is
   between the individual node and the PCE, and it MAY be acceptable to
   have a network-wide L2 key derived in ways such as
   [I-D.piro-6tisch-security-issues] describes in section ?.  The trust
   relationship between the PCE and the joining node flows from the
   LDevID certificate loaded by the JCE.  When the PCE and JCE are co-
   located, the existing 6top/DTLS security association could be reused.

X.3.  Join Protocol connection setup

   The intermediate level goal of the join protocol is to enable a Join
   Coordination Entity (JCE) to reach out to the new node, and install
   the credentials detailed above.  The JCE must authenticate itself to
   the joining node so that the joining node will know that it has
   joined the correct network, and the joining node must authenticate
   itself to the JCE so that the JCE will know that this node belongs in
   the network.  This two way authentication occurs in the 6top/CoAP/
   DTLS session that is established between the JCE and the joining
   node.

   [I-D.ietf-6tisch-6top-interface] presents a way to interface to a
   6top information model (defined in YANG).  [I-D.ietf-6tisch-coap]
   explains how to access that information model using CoAP.  This
   information model will include security attributes for the network.
   The JCE would therefore reach out to the joining node and simply
   provision appropriate security properties into the joining node, much
   like the PCE will provision schedules.

   This 6top-based secure join protocol has defined a push model for
   security provisioning by the JCE.  This has been done for three
   reasons:

   1)  6tisch nodes already have to have a 6top CoAP server for schedule
       provising

   2)  this permits the JCE to manage how many nodes are trying to join
       at the same time, and limit how much bandwidth/energy is used for
       the join operation, and also for the JCE to prioritize the join
       order for nodes.

   3)  making the JCE initiate the DTLS connection significantly
       simplies the certificate chains that must be exchanged as the
       most constrained side (the joining node) provides it's
       credentials first, and lets the less constrained JCE figure out
       what kind of certificate chain will be required to authenticate
       the JCE to the joining node.  In EAP-TLS/802.1x situations, the
       TLS channel is created in the opposite direction, and it would
       have to complete in a tentative way, and then further
       authorization occur in-band.

X.4.  End to End considerations for Join Protocol

   In order for a 6top/DTLS/CoAP connection to occur between the JCE and
   the joining node, there needs to be end-to-end IPv6 connectivity
   between those two entities.  The joining node will not participate in
   the route-over RPL mesh, but rather will be seen by the network as
   being a 6lowpan only leaf-node.

X.5.  Join node discovery mechanism

   In order the JCE reach out to provision
   the Joining Node, it needs to know that the new node is present.
   The mechanism will use a protocol piggybacked on the 6lowPAN Address Resolution
   mechanism described [RFC6775].  The 6LBR will need to inform the JCE
   about the new node.  (This interaction is presently out of scope)

   Prior to being able to announce itself in a NS, the joining node
   needs to find the Join Network.  This is done by listening to the
   enhanced beacon which are broadcast in designated slotframes by the
   network.  These are the same enhanced beacons which are used by the
   production network.  The enhanced beacons are transmitted in "MIC-
   only" (authentication only) mode.  Nodes with the production network
   key can authenticate the beacons.  The newly joining node can not
   authenticate the beacons, but it can read and process them, and can
   use this as a way to synchronize to the network.  During the Alpha
   period, the joining node can send a Router Soliticiation, and receive
   an appropriate Router Advertisement giving the Joining Node a prefix
   and default route to which to send the join traffic (the ND DAD
   mentioned above).

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

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 5 Dec 2014 01:58:33 -0800

Michael,
Some editorial comments *inline*.
Thomas

>    layer-5 provisioning interface used for provisioning the schedule.

*rather than "layer-5", "application layer"?*

> X.1.  Entities involves in the join process

*involves -> **involved*

>    DODAGs, such that it is reachable from the 6LBR, and the JCE.

*add ", possibly over multiple hops"?*

>        certificate (which allows it to negotiate a pair-wise keys)

*I would expand what "it" refers to. "which allows two neighbor nodes to
..."?*

>    These two items is

*is -> are*

> delivered by JCE

*by *the* JCE*

> to the joining node using
>    "northbound" interface.

*I know what north and southbound refers to. I'm not sure what it means
here.*

> A Join Protocol describes the authentication
>    of this interface.
>
>    L2

*word missing?*

> , using a key exchange protocol.  The choice of

**the**

> key exchange
>    Per-peer L2 keying is critical when doing peer-2-peer

*https://tools.ietf.org/html/draft-ietf-6tisch-architecture-04
<https://tools.ietf.org/html/draft-ietf-6tisch-architecture-04> refers to
"distributed" rather than P2P. I suggest to use the same terminology.*

> schedule
>    negotiation over 15.4

*IEEE802.15.4e*

> Information Elements.  Therefore a network-wide
>    layer-2

*you use both layer-2 and L2. Homogenize?*

> key is inappropriate for the self-organizing networks, and a
>    the joining node so that the joining node will know

*will know -> knows*

> that it has
>    itself to the JCE so that the JCE will know

*will know -> knows*

> that this node belongs in
> *will provision -> provisions*

>    security provisioning by the JCE.

*I would add a sentence to describe what you mean by push model.*

> This has been done for three
>    reasons:
>

*typo*

>        most constrained side (the joining node) provides it's

*it's -> its*

>    being a 6lowpan only leaf-node.

*to be generic, I would not specify route-over RPL mesh, but rather "not
participate in the multi-hop mesh"*

>    In order

**for**

> the JCE

**to**

> reach out to provision
>    The mechanism will use a protocol piggybacked on the 6lowPAN

*"6LoWPAN" (case)*

> Address Resolution
>    needs to find the Join Network.  This is done by listening to

*to -> for*

> the
>    period,

*not sure what Alpha period is*

> the joining node can send a Router Soliticiation,

*typo*

> and receive
> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security
>
>