One document matched: draft-richardson-6tisch-security-architecture-01.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY ZigBeeIP SYSTEM "http://www.sandelman.ca/rfc/xml/reference.ZigBeeIP.xml">
<!ENTITY RFC6786 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6786.xml">
<!ENTITY I-D.roll-security-threats SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-roll-security-threats.xml">
<!ENTITY I-D.behringer-autonomic-network-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.behringer-autonomic-network-framework">
<!ENTITY I-D.gerdes-core-dcaf-authorize SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.gerdes-core-dcaf-authorize">

]>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>

<rfc category="info" ipr="trust200902" docName="draft-richardson-6tisch-security-architecture-01">



<front>
  <title abbrev="6tisch-security">
      security architecture for 6top: requirements and structure
  </title>

  <author initials="M." surname="Richardson" fullname="Michael C. Richardson">
    <organization abbrev="SSW">Sandelman Software Works</organization>
    <address>
      <postal>
        <street>470 Dawson Avenue</street>
        <city>Ottawa</city>
        <region>ON</region>
        <code>K1Z 5V7</code>
        <country>CA</country>
      </postal>
      <email>mcr+ietf@sandelman.ca</email>
      <uri>http://www.sandelman.ca/</uri>
    </address>
  </author>

  <date month="March" year="2014" />

<abstract>
  <t>
    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.
  </t>
<t>This might be the worst written internet draft yet. You have been warned</t>
</abstract>

</front>

<middle>

<section title="Introduction: security bootstrap requirements">
<t>
</t>
</section>
<section title="Requirements Language">
  <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in <xref
  target="RFC2119">RFC 2119</xref>.</t>
</section>

<section title="layer-2 security requirements">
<t>
As outlined in <xref target="I-D.ietf-roll-security-threats"/> there are a number of threats in LLNs,
and in RPL which are solved if there is layer-2 security.  The requirement is therefore to provide
keying for the layer-2 security features: encryption and integrity protection.
</t>
<t>
In addition to serving to protect the routing traffic against attacks, use of the layer-2 access
control serves as adminission control to the network.  It is therefore part of the layer-2 join process
to authenticate the new node, as well as authorize it to join the network.  The admission control
SHOULD be controlled by autonomic certificates, see section X.
</t>
</section>

<section title="6top/PCE security requirements">
<t>
In addition to authorization a node to join the network, the node agree to provide authorization
to a PCE in order for the 6top protocol to run.  This protocol, described in section X of 6tisch
architecture (this) document and in [6top], permits the PCE to program a timeslot schedule into the node.
</t>
<t>
So, the second part of the 6tisch security requirements is to establish the identities of the the
node and the PCE, and to establish an authorization that permits the new node to be programmed by the PCE.
</t>
</section>

<section title="leveraging layer-2 identities for layer-4 security">
<t>
As explained in <xref target="I-D.behringer-autonomic-network-framework"/> the layer-2 identity of the
node will be given by a certificate signed by the vendor of the node.  The vendor's certificate authority
is loaded into the (PANA) Authorization Server, and permits the AS to authenticate the node.
</t>
<t>
The vendor provides a certificate (chain) to the (PANA) Authorization Server (PAS) attesting to that the
PAS is the rightful owner/controller of the node.  This permits the node to validate that the network
it is joining is the correct network.  This process permits the bootstrap of one of the
layer-2 security mechanism(s) describe in sections below.
</t>
<t>
The same set of trust relationships can then permit the PAS to act as an Authorization Server (now, in the context of <xref target="I-D.gerdes-core-dcaf-authorize"/>).  The PCE and it's Authorization Manager
(AM, again from  <xref target="I-D.gerdes-core-dcaf-authorize"/>) can now get a ticket to permit it to
write the timeslot schedule.  In option 2, below, it also permits updates to the security parameters.
</t>
</section>

<section title="option 1: The ZigBeeIP/PANA way">
<t>
This is an adaptation of the process described in <xref target="ZigBeeIP"/>, section
and expounded upon in section 6.3: "Network Discovery", 6.4: "Network Selection", and 6.5, "Node Joining".
The process is abridged below.
</t>
<section title="Network Discovery">
<t>
The MAC beacon facility is used.  A critical difference in 6tisch from ZigBee IP is that
because nodes transmit and receive according to their own schedule, every node is in
essence a coordinator.  While nodes may sleep a lot, they will not in general be sleep Hosts, from a
ZigBee IP point of view, and MLE is not necessary.
</t>
<t>
Each response to the Beacon is a potential network-joining-parent.
</t>
<t>
As an option, it may be desireable for this document to define a well known NetworkID.
</t>
</section>

<section title="PANA protocol">
<t>
The PANA payloads MUST be relayed by the chosen network-joining-parent.  It is assumed that the
PANA Authentication Agent is co-located with the PCE, if there is a PCE.
</t>
<t>
As per section 8.3.4 of <xref target="ZigBeeIP"/>, the PANA process runs over UDP using link-layer
addressing.  The process is first the PANA initialization (PCI, PAR:S, PAN:S),
followed by EAP initialization (EAP-Request, EAP-Response), which negotiates the identity,
and then EAP-TLS starts, consisting of (TLS(Start), TLS(ClientHello), TLS(ServerHello),
TLS(ServerKeyExchange), TLS(ClientKeyExchange), and TLS(ChangeCipherSpec)).
</t>
<t>
When the TLS is done, the EAP derives new network security material, and sends it encrypted
using the Encr-Encap AVP described in <xref target="RFC6786"/>.
</t>
</section>
<section title="Authorization">
<t>
QUESTION: can we find a way for the authorization protocol, such as described in draft-gerdes-core-dcaf-authorize-01, to run simultaenously with the authentication system if we assume that the dcaf AS
is also the PANA Authentication Server/Agent
</t>
<t>
In the context of draft-selander-core-access-control, the new node that is joining is the resource server,
and the origin client is the PCE.
</t>
</section>

</section>

<section title="option 2: The WirelessHart/ISA100 way">
<t>
This is an adaptation of the process described in <xref target="HART"/>, section 6.6.3.
</t>
<t>
In this process, the new node joins using a well-known layer-2 "JOIN" key.  It brings up
the layer-3, using 6loWPAN Neighbour Discovery to learn of the 6lowpan contexts, and then
uses RPL to join a well-known DODAG as a leaf node. </t>
<t>Nodes which have capacity for new joining nodes will respond to the RPL DIS messages.
Once connected, the new node uses regular unicasted IP datagrams to contact an Authorization Manager
(in the context of <xref target="I-D.gerdes-core-dcaf-authorize"/>).  The negotiation with the
Authorization Manager (AM) uses the autonomic certificates as described above to establish the trust
relationship.
</t>
<t>
Once the relationship is up, the AM needs to signal the PCE that it has a new authorized node,
and the PCE can now (acting as a <xref target="I-D.gerdes-core-dcaf-authorize"/> Client), get a Ticket to update
the node.
</t>
<t>
The PCE then writes both a new timeslot schedule, and also writes new security parameters that permit the node
to fully join the network.  Appropriate layer-2 keys are updated, as well as any appropriate layer-3 RPL credentials.
MLE may be used to establish pair-wise keying, as appropriate to the timeslot schedule.
</t>
</section>

<section title="Security Considerations">
  <t>
  </t>
</section>

<section title="Other Related Protocols"></section>
<section title="IANA Considerations">
<t>
</t>
</section>
<section title="Acknowledgements"></section>

</middle>

<back>
<references title="Normative references">
<?rfc include="reference.RFC.2119" ?>
      &ZigBeeIP;
      &RFC6786;
      &I-D.roll-security-threats;
      &I-D.behringer-autonomic-network-framework;
      &I-D.gerdes-core-dcaf-authorize;
      <reference anchor="HART">
        <front>
          <title>Highway Addressable Remote Transducer, a group of
          specifications for industrial process and control devices
          administered by the HART Foundation</title>

          <author>
            <organization>www.hartcomm.org</organization>
          </author>

          <date></date>
        </front>
      </reference>

      <reference anchor="ISA100.11a"
                 target="     http://www.isa.org/Community/SP100WirelessSystemsforAutomation">
        <front>
          <title>ISA100, Wireless Systems for Automation</title>

          <author>
            <organization>ISA</organization>
          </author>

          <date day="05" month="May" year="2008" />
        </front>
      </reference>
</references>

</back>
</rfc>