[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
6TiSCH                                                         S. Chasko
Internet-Draft                                                       L+G
Intended status: Informational                                    S. Das
Expires: September 23, 2014                                          ACS
                                                          R. Marin-Lopez
                                                    University of Murcia
                                                            Y. Ohba, Ed.
                                                              P. Thubert
                                                                A. Yegin
                                                          March 22, 2014

 Security Framework and Key Management Protocol Requirements for 6TiSCH


   6TiSCH is enabling IPv6 over the TSCH mode of the IEEE802.15.4e
   standard that allows the IEEE 802.15.4e TSCH wireless networks and
   nodes to connect to the backbone network via layer 3 meshes over
   IPv6.  In this operation of network architecture, understanding the
   security framework and requirements for key management protocols are
   critical.  This document discusses such security framework and key
   management protocol requirements by highlighting different phases of
   key management in which a new node can securely join the network
   under the purview of overall 6TiSCH architecture.

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 September 23, 2014.

Chasko, et al.         Expires September 23, 2014               [Page 1]

Internet-Draft               6tisch-security                  March 2014

Copyright Notice

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

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Security Framework  . . . . . . . . . . . . . . . . . . . . .   3
   4.  KMP requirements  . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Phase-1 KMP requirements  . . . . . . . . . . . . . . . .   7
     4.2.  Phase-2 KMP requirements  . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  External Informative References . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The emergence of radio technology enabled a large variety of new
   types of devices to be interconnected, at a very low marginal cost
   compared to wire, at any range from Near Field to interplanetary
   distances, and in circumstances where wiring could be less than
   practical, for instance rotating devices.

   At the same time, a new breed of Time Sensitive Networks is being
   developed to enable traffic that is highly sensitive to jitter and
   quite sensitive to latency.  Such traffic is not limited to voice and
   video, but also includes command and control operations such as found
   in industrial automation or in-vehicular sensors and actuators.

   6TiSCH aims at providing an interoperable standard with new
   capabilities, both in terms of scalability (number of IPv6 devices in
   a single subnet) and in terms of guarantees (delivery and

Chasko, et al.         Expires September 23, 2014               [Page 2]

Internet-Draft               6tisch-security                  March 2014

   timeliness).  Both the ISA100.11a [ISA100] and Wireless HART
   [WirelessHART] protocols are gaining acceptance in the automation
   industry and demonstrate that a level of determinism can be achieved
   on a wireless medium with adequate guarantees for low speed control
   loops, used in mission critical Process Control applications.  For
   industrial applications, security is not an option and a power
   efficient authentication mechanism is strictly required.

   For other usages such as rust control, intrusion detection or seismic
   activity monitoring, the capability to correlate inputs from multiple
   sources can be critical, and the value of the network directly
   augments with the number of connected devices.  In order to scale to
   appropriate levels, the need for spatial reuse of the spectrum often
   implies routing capabilities over short range radios.  Proprietary
   variations demonstrate that RPL can scale to multiple thousands of
   devices, but at the same time expose a new challenge for security
   that must enable deployments of any scale with security requirements
   that may vary widely.  If the cost of the security in terms of
   network operations and system resources depends on that degree of
   security, then 6TiSCH should enable different profiles that can match
   different requirements and capabilities.

   Since 6TiSCH enables layer 3 meshes over IPv6, key management
   protocols defined at layer 3 or above can be directly applied to the
   networks and nodes that join the mesh network.  However,
   understanding the security framework and requirements for key
   management protocols are critical before adopting an existing
   protocol or designing a new one that fits the operational needs for
   these types of networks.  This document details such operations and
   discusses the security framework with requirements within the context
   of 6TiSCH architecture [I-D.ietf-6tisch-architecture].

2.  Acronyms

   In addition to the acronyms defined in [I-D.ietf-6tisch-terminology],
   the following acronyms are used in this document.

   KMP: Key Management Protocol

   SA: Security Association

   MAC: Media Access Control

3.  Security Framework

   This section describes a security framework consisting of four phases
   of key management operation as shown in Figure 1.  It is expected
   that each node in a mesh network runs through the four phases.

Chasko, et al.         Expires September 23, 2014               [Page 3]

Internet-Draft               6tisch-security                  March 2014

                 |        Phase-0 (Implanting)     |
                 |     Phase-1 (Initialization)    |
                 |   Phase-2 (Link Establishment)  |
                 |        Phase-3 (Operational)    |

                  Figure 1: 4-Phase Key Management Model

   Each phase is explained as follows.

   o  Phase-0 (Implanting Phase): In this phase, a node installs
      credentials used for subsequent phases in a physically secure and
      managed location before the node is placed to where it is expected
      to operate.  Details on how Phase-0 can be achieved are outside
      the scope of this document.

   o  Phase-1 (Initialization Phase): Phase-1 (Initializing Phase): In
      this phase, an authentication and key Establishment protocol
      called a Phase-1 KMP is conducted either between nodes or between
      a node and the authentication/authorization server using Phase-1
      credentials.  Both symmetric and asymmetric key credentials can be
      used as Phase-1 credentials.  When phase-1 KMP is run between a
      node and an authentication/authorization server, a node
      (re)install credentials used for subsequent phases (e.g., Phase 2
      and 3).  The credentials installed during Phase-1 include Phase-2
      credentials and Phase-3 credentials, and may also include long-
      term Phase-1 credentials if the initial Phase-1 credentials are
      intended for one-time use such as a temporary PIN.  The Phase-1
      credentials usually have longer lifetime than Phase-2 and Phase-3
      credentials so that Phase-2 and Phase-3 credentials can be renewed
      using the Phase-1 credentials.  When the authentication server is
      multiple hops away from the node, mutual authentication between
      the node and the authentication server may be conducted via a
      neighboring node acting as an authentication relay.  There may be
      no link-layer security available between the node and its

Chasko, et al.         Expires September 23, 2014               [Page 4]

Internet-Draft               6tisch-security                  March 2014

      neighboring node in this phase.  An authentication/authorization
      server is typically (but is not necessarily) co-located with the
      coordinator of the mesh network.  Contacting the authentication/
      authorization server is optional if Phase-2 credentials are
      installed during Phase-0 and do not need to be updated.

   o  Phase-2 (Link Establishment Phase): In this phase, the node
      performs mutual authentication with its neighboring node using the
      Phase-2 credentials to establish SAs between adjacent nodes for
      protecting 802.15.4 MAC frames.  The authentication and key
      establishment protocol used in this phase is referred as a Phase-2
      KMP or a link establishment KMP.  For highly scalable mesh
      networks consisting of thousands of mesh nodes, certificates are
      used as the Phase-2 credentials.  The SA of a link between node i
      and node j maintains link-layer keys, i.e., 128-bit keys used in
      AES-CCM* [IEEE802154] mode, a variant of the Counter with Cipher
      Block Chaining - Message Authentication Code (CBC-MAC) Mode, for
      encryption, authentication or authenticated encryption of 802.15.4
      frames.  In the following example, K_i denotes a link-layer key
      for protecting broadcast MAC frames originated at node i.  K_ij
      denotes a link-layer key for protecting unicast MAC frames
      originated at node i and destined for node j.  There are several
      ways link-layer keys can be formed, for example, the models are:

      1.  Per-Network key model

          K_ij=K_ji=K_i=K_j=K for all i, j (i!=j)

      2.  Per-Neighbor key model

          K_ij!=K_ji, K_ij=K_i, K_i!=K_j for all i,j (i!=j)

      3.  Pair-Wise key model

          K_ij=K_ji, Kij!=Kik, K_i!=K_j, for all i,j (i!=j, j!=k)

      In model 1, a network key that is shared by all nodes in the
      network is used for enciphering and deciphering outgoing and
      incoming unicast and broadcast MAC frames at any node.  In model
      2, each node has a unique key for enciphering outgoing unicast and
      broadcast MAC frames originated at the node and its neighbors use
      the key for deciphering incoming unicast and broadcast MAC frames
      received from that node.  In model 3, each pair of nodes has a
      unique key for enciphering and deciphering unicast frames
      exchanged between them.  In addition, each node in model 3 has a
      unique key for enciphering outgoing broadcast MAC frames
      originated at the node and its neighbors use the key for
      deciphering incoming broadcast MAC frames received from that node.

Chasko, et al.         Expires September 23, 2014               [Page 5]

Internet-Draft               6tisch-security                  March 2014

      One model may be sufficient among these three models depending on
      the required security level and the number of keys maintained by
      each node.

   o  Phase-3 (Operational Phase): In this phase, the node is able to
      run various higher-layer protocols over IP over an established
      secure link.  Additional authentication, authorization and key
      establishment may take place for the higher-layer protocols using
      Phase-3 credentials.  A node in Phase-3 is able to process Phase-1
      and Phase-2 KMPs.  Example use cases are:

      *  A Phase-3 node can initiate a Phase-1 KMP to update its Phase-2
         or Phase-3 credentials.

      *  A Phase-3 node can forward Phase-1 KMP messages originated from
         or destined for a Phase-1 node that is joining the mesh network
         through the Phase-3 node.

      *  A Phase-3 node can initiate a Phase 2 KMP to establish a new
         link with a newly discovered neighbor node.

   Figure 2 shows an example sequence for authentication and
   authorization message exchanges for Phase-1 and Phase-2.  The example
   sequence is explained as follows:

   1.  Initially all nodes are in Phase-1.

   2.  Nodes B and C run Phase-1 KMP with Node A which is acting as the
       authentication/authorization server) to obtain Phase-2 and
       Phase-3 credentials.

   3.  Nodes B and C run Phase-2 KMP with Node A.

   4.  Nodes D and E run Phase-1 KMP using Node B as an authentication
       relay.  (Alternatively, Node E may use Node C as an
       authentication relay.)

   5.  Node D runs Phase-2 KMP with Node B.  Node E runs Phase-2 KMP
       with Nodes B and C.

   6.  All nodes are operational.

Chasko, et al.         Expires September 23, 2014               [Page 6]

Internet-Draft               6tisch-security                  March 2014

              N)s - Node N is running Phase-1 KMP as a server
              N)c - Node N is running Phase-1 KMP as a client
              N)r - Node N is running Phase-1 KMP as a relay
              N)) - Node N is running Phase-2 KMP
              .  .. ...
              N, N,  N  - Node N is in Phase-1, -2 and -3, respectively

        .          .           ..         ...        ...         ...
        A          A)s         A))         A)s        A           A
                  / \         / \         / \        / \         / \
      .   .      .   .       ..  ..     ... ...    ... ...     ... ...
      B   C      B)c C)c     B)) C))     B)r C      B)) C))     B   C
                                        / \ /      / \ /       / \ /
    .   .      .   .        .   .       .   .      ..  ..     ... ...
    D   E      D   E       D   E       D)c E)c    D)) E))     D   E

       (1)  ->    (2)   ->    (3)   ->    (4)  ->    (5)   ->    (6)

                        Figure 2: Example Sequence

4.  KMP requirements

   Since Phase-3 KMP requirements would depend on application protocols,
   we focus on Phase-1 and Phase-2 KMP requirements.

4.1.  Phase-1 KMP requirements

   Requirements on Phase-1 KMP are listed below.

   R1-1: Phase-1 KMP MUST support mutual authentication.

   R1-2: Phase-1 KMP MUST support stateless authentication relay

   R1-3:s Phase-1 KMP MUST support secure credential distribution.

4.2.  Phase-2 KMP requirements

   Requirements on Phase-2 KMP are listed below.

   R2-1: Phase-2 KMP Nodes MUST mutually authenticate each other before
   establishing a link and forming a mesh network.  An authentication/
   authorization server is not a requirement for this operation.

   R2-2: Phase-2 KMP authentication credentials MAY be pre-provisioned
   or MAY be obtained via Phase-1 KMP.

   R2-3: Phase-2 KMP authentication credentials MUST have a lifetime.

Chasko, et al.         Expires September 23, 2014               [Page 7]

Internet-Draft               6tisch-security                  March 2014

   R2-4: Phase-2 KMP MUST support certificates for scalable operation.

   R2-5: Phase-2 KMP message exchanges MUST be integrity and replay
   protected after successful authentication.

   R2-6: Phase-2 KMP MUST have the capability to establish security
   association and unicast session keys after successful authentication
   to protect unicast MAC frames between nodes.

   R2-7: Phase-2 KMP MUST have the capability to establish security
   association and broadcast session keys after successful
   authentication to protect broadcast MAC frames between nodes.

   R2-8: Phase-2 KMP MUST support confidentiality to distribute the
   broadcast session keys securely.

5.  Security Considerations

   In this section, security issues that can potentially impact the
   operation of IEEE 802.15.4e TSCH MAC are described.

   In TSCH MAC, time synchronization and channel hopping information are
   advertised in Enhanced Beacon (EB) frames
   [I-D.ietf-6tisch-terminology].  The advertised information is used by
   mesh nodes to determine the timeslots available for transmission and
   reception of MAC frames.  A rogue node can inject forged EB frames
   and can cause replay and DoS attacks to TSCH MAC operation.  To
   mitigate such attacks, all EB frames MUST be integrity protected.
   While it is possible to use a pre-installed static key for protecting
   EB frames to every node, the static key becomes vulnerable when the
   associated MAC frame counter continues to be used after the frame
   counter wraps.  Therefore, the 6TiSCH solution MUST provide a
   mechanism by which mesh nodes can use the available time slots to run
   Phase-1 and Phase-2 KMPs and provide integrity protection to EB

   For use cases where certificates are used for a Phase-1 KMP, pre-
   provisioning of absolute time to devices from a trustable time source
   using an out-of-band (OOB) mechanism is a general requirement.
   Accuracy of time depends on the OOB mechanism, including use of the
   time hard-coded into the installed firmware.  The less time accuracy
   is, the more attack opportunities during Phase-1.  In addition, use
   of CRL is another requirement for Phase-1 KMP employing certificates
   to avoid an attack that can happen by a compromised server or CA

Chasko, et al.         Expires September 23, 2014               [Page 8]

Internet-Draft               6tisch-security                  March 2014

6.  IANA Considerations

   There is no IANA action required for this document.

7.  Acknowledgments

   We would like to thank Thomas Watteyne, Jonathan Simon, Maria Rita
   Palattella and Rene Struik for their valuable comments.

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.

              Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
              "Terminology in IPv6 over the TSCH mode of IEEE
              802.15.4e", draft-ietf-6tisch-terminology-01 (work in
              progress), February 2014.

              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.

8.2.  External Informative References

              IEEE standard for Information Technology, "IEEE std.
              802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
              and Physical Layer (PHY) Specifications for Low-Rate
              Wireless Personal Area Networks", June 2011.

   [ISA100]   ANSI/ISA-100.11a-2011, "Wireless systems for industrial
              automation: Process control and related applications",

              IEC 62591 Ed. 1.0 b:2010, "Industrial communication
              networks - Wireless communication network and
              communication profiles - WirelessHART", 2010.

Chasko, et al.         Expires September 23, 2014               [Page 9]

Internet-Draft               6tisch-security                  March 2014

Authors' Addresses

   Stephen Chasko
   3000 Mill Creek Ave.
   Alpharetta, GA  30022

   Email: Stephen.Chasko@landisgyr.com

   Subir Das
   Applied Communication Sciences
   1 Telcordia Drive
   Piscataway, NJ  08854

   Email: sdas@appcomsci.com

   Rafa Marin-Lopez
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia  30100

   Phone: +34 868 88 85 01
   Email: rafa@um.es

   Yoshihiro Ohba (editor)
   Toshiba Corporate Research and Development Center
   1 Komukai-Toshiba-cho
   Saiwai-ku, Kawasaki, Kanagawa  212-8582

   Phone: +81 44 549 2127
   Email: yoshihiro.ohba@toshiba.co.jp

Chasko, et al.         Expires September 23, 2014              [Page 10]

Internet-Draft               6tisch-security                  March 2014

   Pascal Thubert
   Cisco Systems, Inc
   Village d'Entreprises Green Side
   400, Avenue de Roumanille
   Batiment T3
   Biot - Sophia Antipolis  06410

   Phone: +33 497 23 26 34
   Email: pthubert@cisco.com

   Alper Yegin

   Email: alper.yegin@yegin.org

Chasko, et al.         Expires September 23, 2014              [Page 11]