[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                      M. Richardson
Internet-Draft                                                       SSW
Intended status: Informational                            April 28, 2014
Expires: October 30, 2014


       security architecture for 6top: requirements and structure
            draft-richardson-6tisch-security-architecture-02

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 30, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.












Richardson              Expires October 30, 2014                [Page 1]


Internet-Draft               6tisch-security                  April 2014


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction: secure bootstrap requirements . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  layer-2 join  . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     1.4.  Use of 802.1AR certificates . . . . . . . . . . . . . . .   5
       1.4.1.  Proxy Discovery . . . . . . . . . . . . . . . . . . .   5
       1.4.2.  Registrar/Authorization server access to certificate
               chain . . . . . . . . . . . . . . . . . . . . . . . .   6
       1.4.3.  Receiving and accepting the Domain Identity . . . . .   7
       1.4.4.  Enrollment  . . . . . . . . . . . . . . . . . . . . .   7
     1.5.  6top/PCE security requirements  . . . . . . . . . . . . .   8
       1.5.1.  no-PCE and 6LR to 6LR 6top authorization  . . . . . .   8
   2.  leveraging layer-2 identities for layer-4 security  . . . . .   8
   3.  Layer-2 Join  . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  option 1: The ZigBeeIP/PANA way . . . . . . . . . . . . .   8
       3.1.1.  Network Discovery . . . . . . . . . . . . . . . . . .   8
       3.1.2.  PANA protocol . . . . . . . . . . . . . . . . . . . .   9
       3.1.3.  Authorization . . . . . . . . . . . . . . . . . . . .   9
       3.1.4.  Advantages of the EAP-TLS based methods . . . . . . .   9
       3.1.5.  Bandwidth considerations for joins  . . . . . . . . .   9
       3.1.6.  Challenges with this method . . . . . . . . . . . . .  10
     3.2.  option 2: The WirelessHart/ISA100 way . . . . . . . . . .  10
       3.2.1.  Advantages of this method . . . . . . . . . . . . . .  11
       3.2.2.  Challenges with the CoAP method . . . . . . . . . . .  11
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   5.  Other Related Protocols . . . . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative references  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative references  . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction: secure bootstrap requirements





Richardson              Expires October 30, 2014                [Page 2]


Internet-Draft               6tisch-security                  April 2014


   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:

       layer 2 join: new nodes must be recognized by the network, and
       provided with layer-2 symmetric credentials

       zero-touch join: new nodes must recognize the network without
       explicit provisioning, and attempt to join

       new nodes must become a part of the RPL DODAG, and make contact
       with parent and child nodes

       in networks with a PCE, new nodes must authorize the PCE to
       update the nodes' schedule using 6top

       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

   This document, presently a stand-alone document, but later to be a
   section of [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.
   [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.

   A 802.1AR [IEEE.802.1AR] 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
   [I-D.wang-6tisch-6top-sublayer]) to configure the TSCH cells.

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].





Richardson              Expires October 30, 2014                [Page 3]


Internet-Draft               6tisch-security                  April 2014


1.2.  layer-2 join

   As outlined in [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.

   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.

1.3.  Terminology

   Plant Installation:  the (6tisch) network installed for control
                   purposes.

   >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.

   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.

   New Entity:     a new 6LN that wishes to join the network.

   [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 [I-D.pritikin-bootstrapping-keyinfrastructures] defines:

   Domain:         this refers to the entire 6tisch installation

   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.

   Orchestrator:   the role of the orchestrator is provided by
                   Authorization Server (a term used by both ACE and
                   PANA [RFC5191]), or the EAP Server (see [RFC5247]).



Richardson              Expires October 30, 2014                [Page 4]


Internet-Draft               6tisch-security                  April 2014


   Factory:        this is the vendor of the mote.  It may consist of a
                   supplier chain of value-added resellers.

   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.

   Registrar:      the role of registrar is performed by the
                   Authorization Server.

   MASA Cloud Service:  A Manufacturer Authorized Signing Authority.
                   These will typically be co-located in the
                   Authorization Server.

1.4.  Use of 802.1AR certificates

   This section explains how the process detailed in
   [I-D.pritikin-bootstrapping-keyinfrastructures] is to be implemented
   in the 6tisch case.  To recap, the process looks like:

   (1)   Proxy Discovery

   (2)   Receiving and accepting the Domain Identity

   (3)   Enrollment

   (4)   After Enrollment

   (5)   Behavior of a proxy

   (6)   Behavior of the Registrar

   (7)   Authenticating the Device

   (8)   Accepting the Entity

   (9)   Claiming the new entity

   (10)  Behavior of the MASA Cloud Service

   (11)  Issue Authorization Token and Log the event

1.4.1.  Proxy Discovery

   The Proxy Discovery step may occur via one of two mechanisms, which
   are further described in section Section 3.  One method involves
   using an EAP-TLS (or rather, EAP-EST, as imagined by
   [I-D.pritikin-bootstrapping-keyinfrastructures]), over either 1X or



Richardson              Expires October 30, 2014                [Page 5]


Internet-Draft               6tisch-security                  April 2014


   PANA.  A nearby node provides a PANA Authentication Agent (PAA)
   ([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.

   In either case, a (D)TLS channel is created from the New Entity/6LN
   to the Registrar/Authorization Server

1.4.1.1.  Certificate Chains

   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.

   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.

   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.

1.4.2.  Registrar/Authorization server access to certificate chain

   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:

   (1)  loaded from a diskette/USB/QR code that was included in the
      packaging

   (2)  downloaded via some interactive web interface provided by the
      manufacturer and/or logistics company

   (3)  acquired via an online enrollment protocol, such as EST
      protocol.  This could be secured using a one-time password
      provided in the packaging.

   (4)  out of band, by having a human talk to another human.







Richardson              Expires October 30, 2014                [Page 6]


Internet-Draft               6tisch-security                  April 2014


   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.

1.4.3.  Receiving and accepting the Domain Identity

   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.

   The certificate chain will be rooted with the 6LN's manufacturer
   certificate: Example Corp.

   (a)  An 802.1AR certificate signed by Example Corp. delegates
      deviceID 3145191 to Example Logistics.

   (b)  An 802.1AR certificate signed by Example Logistics delegates
      deviceID 3145191 to ACME Widgets

   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.

   The certificate chain that the New Entity presents to the Registrar
   would look like:

   (a)  An 802.1AR certificate signed by Example Corp. binds deviceID
      3145191 to the public key of the New Entity.

   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.

1.4.4.  Enrollment









Richardson              Expires October 30, 2014                [Page 7]


Internet-Draft               6tisch-security                  April 2014


1.5.  6top/PCE security requirements

   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.

   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.

1.5.1.  no-PCE and 6LR to 6LR 6top authorization

2.  leveraging layer-2 identities for layer-4 security

   As explained in [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.

   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.

   The same set of trust relationships can then permit the PAS to act as
   an Authorization Server (now, in the context of
   [I-D.gerdes-core-dcaf-authorize]).  The PCE and it's Authorization
   Manager (AM, again from [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.

3.  Layer-2 Join

3.1.  option 1: The ZigBeeIP/PANA way

   This is an adaptation of the process described in [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.

3.1.1.  Network Discovery





Richardson              Expires October 30, 2014                [Page 8]


Internet-Draft               6tisch-security                  April 2014


   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.

   Each response to the Beacon is a potential network-joining-parent.

   As an option, it may be desireable for this document to define a well
   known NetworkID.

3.1.2.  PANA protocol

   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.

   As per section 8.3.4 of [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)).

   When the TLS is done, the EAP derives new network security material,
   and sends it encrypted using the Encr-Encap AVP described in
   [RFC6786].

3.1.3.  Authorization

   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

   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.

3.1.4.  Advantages of the EAP-TLS based methods

3.1.5.  Bandwidth considerations for joins

   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



Richardson              Expires October 30, 2014                [Page 9]


Internet-Draft               6tisch-security                  April 2014


   about 30 minutes for 10-hop deep, 100-node network.  This assumes 300
   bytes for a certificate.

   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.

   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.

3.1.6.  Challenges with this method

                             number of messages

                             size of certificate exchanges

                             EAP and TLS code not used for anything else

                             ability to support non-PCE case

3.2.  option 2: The WirelessHart/ISA100 way

   This is an adaptation of the process described in [HART], section
   6.6.3.

   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.

   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 [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.

   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
   [I-D.gerdes-core-dcaf-authorize] Client), get a Ticket to update the
   node.

   The PCE then writes both a new timeslot schedule, and also writes new
   security parameters that permit the node to fully join the network.



Richardson              Expires October 30, 2014               [Page 10]


Internet-Draft               6tisch-security                  April 2014


   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.

3.2.1.  Advantages of this method

3.2.2.  Challenges with the CoAP method

                             new protocol to initiate layer-2

                             potentially weaker resistance to layer-2
                             DoS

4.  Security Considerations

5.  Other Related Protocols

6.  IANA Considerations

7.  Acknowledgements

8.  References

8.1.  Normative references

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [ZigBeeIP]
              ZigBee Public Document 15-002r00, "ZigBee IP
              Specification", 2013.

   [RFC6786]  Yegin, A. and R. Cragie, "Encrypting the Protocol for
              Carrying Authentication for Network Access (PANA)
              Attribute-Value Pairs", RFC 6786, November 2012.

   [I-D.ietf-6tisch-architecture]
              Thubert, P., Watteyne, T., and R. Assimiti, "An
              Architecture for IPv6 over the TSCH mode of IEEE
              802.15.4e", draft-ietf-6tisch-architecture-01 (work in
              progress), February 2014.

   [I-D.wang-6tisch-6top-sublayer]
              Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
              Operation Sublayer (6top)", draft-wang-6tisch-6top-
              sublayer-00 (work in progress), February 2014.

   [I-D.ietf-roll-security-threats]



Richardson              Expires October 30, 2014               [Page 11]


Internet-Draft               6tisch-security                  April 2014


              Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
              and M. Richardson, "A Security Threat Analysis for Routing
              Protocol for Low-power and lossy networks (RPL)", draft-
              ietf-roll-security-threats-06 (work in progress), December
              2013.

   [I-D.gerdes-core-dcaf-authorize]
              Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP
              Authentication and Authorization Framework (DCAF)", draft-
              gerdes-core-dcaf-authorize-02 (work in progress), February
              2014.

   [I-D.pritikin-bootstrapping-keyinfrastructures]
              Pritikin, M., Behringer, M., and S. Bjarnason,
              "Bootstrapping Key Infrastructures", draft-pritikin-
              bootstrapping-keyinfrastructures-00 (work in progress),
              January 2014.

   [I-D.irtf-nmrg-autonomic-network-definitions]
              Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
              Networking - Definitions and Design Goals", draft-irtf-
              nmrg-autonomic-network-definitions-00 (work in progress),
              December 2013.

   [HART]     www.hartcomm.org, "Highway Addressable Remote Transducer,
              a group of specifications for industrial process and
              control devices administered by the HART Foundation", .

   [ISA100.11a]
              ISA, "ISA100, Wireless Systems for Automation", May 2008,
              <http://www.isa.org/Community/
              SP100WirelessSystemsforAutomation>.

   [IEEE.802.1AR]
              Institute of Electrical and Electronics Engineers, "Secure
              Device Identity", IEEE 802.1AR, 2009,
              <http://www.ieee802.org/1/pages/802.1ar.html>.

8.2.  Informative references

   [I-D.behringer-autonomic-network-framework]
              Behringer, M., Pritikin, M., Bjarnason, S., and A. Clemm,
              "A Framework for Autonomic Networking", draft-behringer-
              autonomic-network-framework-01 (work in progress), October
              2013.





Richardson              Expires October 30, 2014               [Page 12]


Internet-Draft               6tisch-security                  April 2014


   [RFC5191]  Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA)", RFC 5191, May 2008.

   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              RFC 5247, August 2008.

   [RFC6869]  Salgueiro, G., Clarke, J., and P. Saint-Andre, "vCard
              KIND:device", RFC 6869, February 2013.

Author's Address

   Michael C. Richardson
   Sandelman Software Works
   470 Dawson Avenue
   Ottawa, ON  K1Z 5V7
   CA

   Email: mcr+ietf@sandelman.ca
   URI:   http://www.sandelman.ca/






























Richardson              Expires October 30, 2014               [Page 13]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/