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

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY ZigBeeIP SYSTEM "http://www.sandelman.ca/rfc/xml/reference.ZigBeeIP.xml">
<!ENTITY RFC5191 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5191.xml">
<!ENTITY RFC5247 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml">
<!ENTITY RFC6786 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6786.xml">
<!ENTITY RFC6869 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6869.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.ietf-6tisch-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-architecture.xml">
<!ENTITY I-D.wang-6tisch-6top-sublayer SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wang-6tisch-6top-sublayer.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.irtf-nmrg-autonomic-network-definitions SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.irtf-nmrg-autonomic-network-definitions">
<!ENTITY I-D.pritikin-bootstrapping-keyinfrastructures SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.pritikin-bootstrapping-keyinfrastructures">
<!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-02">



<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="April" year="2014" />

<abstract>
  <t>
    This document details security requirements for 6tisch nodes that use
    6top in an industrial settings.  Layer-2 and a layer-4 authentication
    and authorization requirements and assumptions are identified.
    Two approaches to accomplishing these requirements are outlined,
    with the goal of eventually picking one.
    This internet-draft is intended for later inclusion into the 6tisch
    architecture document.
  </t>
</abstract>

</front>

<middle>

<section title="Introduction: secure bootstrap requirements">
<t>
There are five security problems that must be solved in the 6tisch environment in order to permit
the nodes to come together and function as a network.  They are:
<list hangIndent="4" style="hanging">
<t>layer 2 join: new nodes must be recognized by the network, and provided with layer-2 symmetric credentials</t>
<t>zero-touch join: new nodes must recognize the network without explicit provisioning, and attempt to join</t>
<t>new nodes must become a part of the RPL DODAG, and make contact with parent and child nodes</t>
<t>in networks with a PCE, new nodes must authorize the PCE to update the nodes' schedule using 6top</t>
<t>in networks without a PCE, and some situations where a PCE delegates details of a bundle to the nodes, the nodes must
be authorized to allocate time slots in their DODAG children</t>
</list>
</t>
<t>
This document, presently a stand-alone document, but later to be a section of <xref target="I-D.ietf-6tisch-architecture" />,
explains the assumptions of how the node is expected to be provisioned in the factory, and how it will react
to networks that it encounters.  As is explained in every Internet of Things document, the nodes are constrainted, have
no end-user interfaces, and therefore it is desired that they function in a "zero-touch" manner.
<xref target="I-D.irtf-nmrg-autonomic-network-definitions" /> introduces the term "autonomic", and it is exactly the properties
described there that are desired for 6tisch networks.
</t>
<t>
A <xref target="IEEE.802.1AR">802.1AR</xref> certificate provisioned in each node at the factory, combined with a certificate
chain provided to the network service provider, permits the node to be recognized by the network, and also for the network
to assert it's authority to own and control the node.  The authentication part of a security protocol (TLS, DTLS, EAP-TLS,
details TBD) will establish identities, and then, said security protocol will be used to provide integrity protection for
a control protocol (YANG/6top, as discussed in <xref target="I-D.wang-6tisch-6top-sublayer"/>) to configure the TSCH cells.
</t>

<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 join">
<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, as described below.
</t>
</section>

<section title="Terminology">
<t>
<list hangIndent="16" style="hanging">
<t hangText="Plant Installation:"> the (6tisch) network installed for control purposes.</t>
<t hangText=">Service Provider:"> the operator of the network.  The service provider may a department internal to the plant, or may be
an external contractor.  It is a role.</t>
<t hangText="Authorization server:"> a centralized entity that makes both layer-2 admission control decisions, and acting as a super-user for all nodes, delegates 6top authorization to a PCE, or to parent nodes for PCE-less operation.</t>
<t hangText="New Entity:"> a new 6LN that wishes to join the network.</t>
</list>
</t>

<t>
<xref target="I-D.pritikin-bootstrapping-keyinfrastructures"/> explains the architecture for use
of 802.1AR certificates in a bootstrap process.  In that document a number of terms of introduced, and in this
section those terms are mapped to 6tisch entities and processes.
Section 2 of <xref target="I-D.pritikin-bootstrapping-keyinfrastructures"/> defines:
<list hangIndent="16" style="hanging">
<t hangText="Domain:"> this refers to the entire 6tisch installation</t>
<t hangText="Domain CA:"> this is a CA operated by the service provider.  It is a role: physically, it may be
   co-located with an Authorization Server and/or with a PCE and have private interfaces with those
   entities, or may be elsewhere with interfaces to be determined, but out of scope for this document.</t>
<t hangText="Orchestrator:"> the role of the orchestrator is provided by Authorization Server (a term used by both ACE and
   PANA <xref target="RFC5191" />), or the EAP Server (see <xref target="RFC5247"/>).</t>
<t hangText="Factory:"> this is the vendor of the mote.  It may consist of a supplier chain of value-added resellers.</t>
<t hangText="Factory CA:"> this is the root CA that is placed into the mote.  Each device also has an 802.1AR identity
issued from that CA.</t>
<t hangText="Registrar:"> the role of registrar is performed by the Authorization Server. </t>
<t hangText="MASA Cloud Service:"> A Manufacturer Authorized Signing Authority.  These will typically be co-located in the
Authorization Server.</t>
</list>
</t>
</section>

<section title="Use of 802.1AR certificates">
<t>
This section explains how the process detailed in <xref target="I-D.pritikin-bootstrapping-keyinfrastructures"/> is to be
implemented in the 6tisch case.  To recap, the process looks like:
<list style="format (%d)">
<t>Proxy Discovery</t>
<t>Receiving and accepting the Domain Identity</t>
<t>Enrollment</t>
<t>After Enrollment</t>
<t>Behavior of a proxy</t>
<t>Behavior of the Registrar</t>
<t>Authenticating the Device</t>
<t>Accepting the Entity</t>
<t>Claiming the new entity</t>
<t>Behavior of the MASA Cloud Service</t>
<t>Issue Authorization Token and Log the event</t>
</list>
</t>
<section title="Proxy Discovery">
<t>
The Proxy Discovery step may occur via one of two mechanisms, which are further described in section <xref target="l2join"/>.
One method involves using an EAP-TLS (or rather, EAP-EST, as imagined by
<xref target="I-D.pritikin-bootstrapping-keyinfrastructures"/>), over either 1X or PANA.  A nearby node provides a 
PANA Authentication Agent (PAA) (<xref target="RFC5191"/>), or 802.1X Authenticator.  A well-known L2-JOIN key is used during
bootstrap.   A second method involves using leveraging the ARO ND messages that 6LOWPAN mandates be exchanged.
</t>
<t>In either case, a (D)TLS channel is created from the New Entity/6LN to the Registrar/Authorization Server</t>
<section title="Certificate Chains">
<t>In forming the TLS channel, two certificate chains are validated.  The Registrar validates a certificate (possibly chain) 
presented by the New Entity. This certificate chain would be communicated using the TLS Client Certificate message.
The Registrar sends a certificate chain in the TLS Server Certificate message which the New Entity must be able to validate.
</t>
<t>As the Registar will in general perform enrollment for all 6LN on a network, it will have multiple identities, and should
send only the certificate chain relevant to each New Entity.  </t>
<t>The New Entity must also send some TBD extension to the server to indicate who it is.   This has to be done 
before the server sends it's Server Certificate message.  This is a variation of the problem the TLS 1.2 SNI extension 
was designed to solve.
</t>
</section>
</section>
<section title="Registrar/Authorization server access to certificate chain">
<t>
The certificate chain that the Registrar returns may not exist until the New Entity attempts to join.
It may be retrieved/created through a number of different mechanisms which are out of scope of this document, but may include:
<list style="format (%d)">
<t>loaded from a diskette/USB/QR code that was included in the packaging</t>
<t>downloaded via some interactive web interface provided by the manufacturer and/or logistics company</t>
<t>acquired via an online enrollment protocol, such as EST protocol.  This could be secured using a one-time password provided
in the packaging.</t>
<t>out of band, by having a human talk to another human.</t>
</list>
An important aspect to note is that it may be some minutes to days between the time the New Entity initiates the join
 operation, and when the Registrar is able to respond properly: some kind of error code and back-off process may be appropriate.
</t>
</section>
<section title="Receiving and accepting the Domain Identity">
<t>
The two certificate chains described in the previous section are critical for permitting the zero-touch operation
of the 6LN New Entity.   This section describes the contents of the Server Certificate that the 6LN expects to verify.
For the purposes of this explanation, assume the 6LN has a deviceID of 3145191, and is manufactured by Example Corp, that it was
distributed by Example Logistics, and it is being installed at ACME Widgets.
</t>
<t>
The certificate chain will be rooted with the 6LN's manufacturer certificate: Example Corp.  
<list style="format (%c)">
<t>An 802.1AR certificate signed by Example Corp. delegates deviceID 3145191 to Example Logistics.</t>
<t>An 802.1AR certificate signed by Example Logistics delegates deviceID 3145191 to ACME Widgets</t>
</list>
This chain permits the 6LN to verify that ACME Widgets is in fact it's rightful owner.  
The certificate chain MAY have a validity permit, or MAY be valid indefinitely.  Given that it is unlikely that the 6LN 
will have a reliable real-time clock, or access to a secure network time source, validation of validity permits may
be useless.
</t>
<t>
The certificate chain that the New Entity presents to the Registrar would look like:
<list style="format (%c)">
<t>An 802.1AR certificate signed by Example Corp. binds deviceID 3145191 to the public key of the New Entity.</t>
</list>
1While a longer certificate chain could be embedded in the device, it is not advised.  Any part of
the manufacturing chain that can do such a thing should simply put it's own identity there, and provide a new
certificate chain path to the Registrar. 
</t>
</section>
<section title="Enrollment">
<t>
  
</t>
</section>

</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 title="no-PCE and 6LR to 6LR 6top authorization">
<t>
</t>
</section>
</section>
</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="Layer-2 Join" anchor="l2join">
<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 title="Advantages of the EAP-TLS based methods">
<t>
</t>
</section>

<section title="Bandwidth considerations for joins">
<t>
Calculations show that with a contention-based medium, using slotted Aloha style, there will be
only 1-3 cells available per slotframe, at most 36% of bandwidth.  Typical slotframes repeat 10 times/second.
Calculations show that it take about 10-15s for each node to join, or about 30 minutes for 10-hop deep,
100-node network.  This assumes 300 bytes for a certificate.
</t>

<t>
JS: in WHART, all frames sent to centralized manager to set up
tyransport session. Primary different is tha the number fo frame is
very small (1 frame up, 1 frame down) to get transport session
started.
</t>

<t>
JS: limitation is that you cannot cleanly separate joining flows from
 steady-state flws in the netowkr. You can take device from box,
 which will disrupt data traffic. In a typical HART network, amount
 of BW for joining is really low. Limitation, no external validation
 of the manager's ID, other than it posesses the right key.
</t>
</section>

<section title="Challenges with this method">
<t>
<list hangIndent="26" style="hanging">
<t>number of messages</t>
<t>size of certificate exchanges</t>
<t>EAP and TLS code not used for anything else</t>
<t>ability to support non-PCE case</t>
</list>
</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 title="Advantages of this method">
</section>
<section title="Challenges with the CoAP method">
<t>
<list hangIndent="26" style="hanging">
<t>new protocol to initiate layer-2</t>
<t>potentially weaker resistance to layer-2 DoS</t>
</list>
</t>
</section>
</section>
</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.ietf-6tisch-architecture;
      &I-D.wang-6tisch-6top-sublayer;
      &I-D.roll-security-threats;
      &I-D.gerdes-core-dcaf-authorize;
      &I-D.pritikin-bootstrapping-keyinfrastructures;
      &I-D.irtf-nmrg-autonomic-network-definitions;
      <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>

      <reference anchor="IEEE.802.1AR"
                 target="http://www.ieee802.org/1/pages/802.1ar.html">
        <front>
          <title>Secure Device Identity</title>
          <author>
            <organization>Institute of Electrical and Electronics Engineers</organization>
          </author>
          <date month="" year="2009"/>
        </front>
        <seriesInfo name="IEEE" value="802.1AR"/>
      </reference>

</references>

<references title="Informative references">
     &I-D.behringer-autonomic-network-framework;
     &RFC5191;
     &RFC5247;
     &RFC6869;
</references>

</back>
</rfc>