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

Versions: 00 01                                                         
6TiSCH                                                         R. Struik
Internet-Draft                               Struik Security Consultancy
Intended status: Informational                                   Y. Ohba
Expires: April 30, 2015                                          Toshiba
                                                                  S. Das
                                                                     ACS
                                                        October 27, 2014


6TiSCH Security Architectural Elements, Desired Protocol Properties, and
                               Framework
         draft-struik-6tisch-security-architecture-elements-01

Abstract

   This document describes 6TiSCH security architectural elements with
   high level requirements and the security framework that are relevant
   for the design of the 6TiSCH security solution.

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 April 30, 2015.

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



Struik, et al.           Expires April 30, 2015                 [Page 1]


Internet-Draft               6tisch-security                October 2014


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Security Architecture Elements  . . . . . . . . . . . . . . .   2
     1.1.  Device Types and Roles  . . . . . . . . . . . . . . . . .   2
     1.2.  Device Enrollment Phases  . . . . . . . . . . . . . . . .   3
     1.3.  Desired Protocol Properties . . . . . . . . . . . . . . .   3
   2.  Security Framework  . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Single-Stage Authentication Framework . . . . . . . . . .   4
     2.2.  Two-Stage Authentication Framework  . . . . . . . . . . .   5
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Security Architecture Elements

1.1.  Device Types and Roles

   There are two types of devices (or nodes) that are involved in the
   6TiSCH security architecture: end devices that intend to join the LLN
   (commonly known as joining nodes) and network devices that help the
   joining node to be authenticated and authorized by the network.  From
   a security operations perspective, each device has a distinct role in
   the network.  An end device has normally a client role, while the
   network device can be a proxy or assume a server role.  A proxy is an
   intermediate node that helps the end device to establish a
   communication with the server.  An end device may move in and out of
   networks (that may be alien to it) and may have little network
   management functionality on board.  However, it usually does have the
   right credential required for initializing the network joining
   process.  A proxy is an intermediary node that that may be more tied
   into a relatively stable infrastructure and may have more support for
   network management functionality and generally has reliable access to
   back-end systems of the network.  A server provides stable, highly
   available infrastructure and network management support and is
   capable of authenticating and authorizing a joining node.

   It is important to note that a network node may assume multiple roles
   at the same time and that a particular role may be assumed by
   multiple network nodes.  Furthermoe, the roles of a network node may
   change over time and can be dynamic in nature along a node or a
   network's lifecycle.





Struik, et al.           Expires April 30, 2015                 [Page 2]


Internet-Draft               6tisch-security                October 2014


1.2.  Device Enrollment Phases

   Device Authentication: The joining node and network node authenticate
   each other and establish a shared key, so as to ensure on-going
   authenticated communications.  This may involve a server as a third
   party.

   Authorization: The network node decides on whether/how to authorize a
   joining node (if denied, this may result in loss of bandwidth).
   Authorization decisions may involve other nodes in the network.

   Configuration/Parameterization: The network node distributes
   configuration information to the joined node, such as scheduling
   information, IP address assignment information, and network policies.
   This may originate from other network devices, for which it acts as
   proxy.  This step may also include distribution of information from
   the joining node to the network node and, more generally,
   synchronization of information between these entities.

1.3.  Desired Protocol Properties

   Security-Related:

   1.  Parties executing a security protocol should be explicitly aware
       of its security properties;

   2.  Compromise of keys or devices should have limited effect on
       security of other devices or services;

   3.  Attacks should not have a serious impact beyond the time
       interval/space during/in which these take place;

   4.  Security protocols should minimize the impact of network outages,
       denial of service attacks.

   Communication Flows:

   1.  Security protocols should allow to be run locally, without third
       party involvement, wherever possibl;

   2.  The number of message exchanges for a joining device should be
       reduced;

   3.  Message exchanges should be structured so as to allow parallel
       execution of protocol steps, wherever possible.

   Computational Cost:




Struik, et al.           Expires April 30, 2015                 [Page 3]


Internet-Draft               6tisch-security                October 2014


   1.  Security protocols should not impose an undue computational
       burden, especially on joining devices (An exception here may
       arise, when recovering from an event seriously impacting
       availability of the network.)

   Device Capabilities:

   1.  Dependency on an accurate time-keeping mechanism should be
       reduced;

   2.  Computational/time latency trade-offs should be tweaked to
       benefit those of joining node, wherever possible;

   3.  Dependency on "homogeneous trust models" should be reduced,
       without jeopardizing the security properties;

   4.  Dependency on on-board trusted platforms and trusted I/O
       interfaces should be reduced.

2.  Security Framework

2.1.  Single-Stage Authentication Framework

   In the single-stage authentication and authorization framework,
   depicted in Figure 1, it is assumed that devices have access to
   certificates and that entities have access to the root CA certificate
   of their communicating parties (initial set-up requirement).  Under
   these assumptions, the authentication step of the device enrollment
   process does not require online involvement of a third party.
   Authentication is performed between the joining node and the proxy
   using their certificates.  Upon successful authentication, link-layer
   keys are established between the client and the proxy.  The proxy
   will deny bandwidth if authorization is not successful.  After
   successful authentication and authorization, configuration
   information is exchanged.

   When a device rejoins the network in the same authorization domain,
   the authorization step could be omitted if the server distributes the
   authorization state for the device to the proxys when the device
   initially joined the network.  However, this generally still requires
   the exchange of updated configuration information, e.g., related to
   time schedules and bandwidth allocation.









Struik, et al.           Expires April 30, 2015                 [Page 4]


Internet-Draft               6tisch-security                October 2014


{joining node}      {neighbor}                 {server, etc.}
+---------+         +---------+                 +---------+
|  Node   |         |  Proxy  |              +--|    CA   |e.g., certificate
|    A    |         |    B    |              |  +---------+       issuance
+---------+         +---------+              |  +---------+
    |                    |                   +--|Authoriz.|e.g., membership
    |<----Beaconing------|                   |  +---------+         test
    |                    |                   |  +---------+
    |<--Authentication-->|                   +--| Routing |e.g., IP address
    |                    |<--Authorization-->|  +---------+       assignment
    |<-------------------|                   |  +---------+
    |                    |                   +--| Gateway |e.g., backbone,
    |------------------->|                   |  +---------+      cloud
    |                    |<--Configuration-->|  +---------+
    |<-------------------|                   +--|Bandwidth|e.g., PCE
                                                +---------+      schedule
    .                    .                   .
    .                    .                   .


            Figure 1: Single-stage authentication/authorization

2.2.  Two-Stage Authentication Framework

   In the two-stage authentication and authorization framework, depicted
   in Figure 2, a joining node performs two authentication and
   authorization steps.  The first step, called Phase-1 authentication,
   is performed between the joining node and the server via a proxy.
   Phase-1 authentication and authorization uses deployment-specific
   enrollment credentials and results in issuance of a certificate by
   the CA to the joining node.  Here, the node's certificate and root CA
   certificates of its communicating parties are distributed from the
   server to the client.

   The second step, called Phase-2 authentication, follows the
   successful completion of Phase-1 authentication and authorization.
   Phase-2 authentication is performed between the joining node and the
   proxy using their certificates.  Upon successful authentication,
   link-layer keys are established between the joining node and the
   proxy.  The proxy will deny bandwidth if Phase-2 authorization is not
   successful.  After successful authentication and authorization,
   configuration information is exchanged.

   Once a joining node obtains a certificate for Phase-2 authentication,
   no additional Phase-1 authentication and authorization is needed,
   i.e., only Phase-2 authentication and the configuration are required
   for rejoining the network via a proxy under the same authorization




Struik, et al.           Expires April 30, 2015                 [Page 5]


Internet-Draft               6tisch-security                October 2014


   domain.  This reduces to the single-stage authentication framework
   discussed in the previous section.


{joining node}        {neighbor}              {server, etc.}
+---------+           +---------+             +---------+
|  Node   |           |  Proxy  |          +--|    CA   |e.g., certificate
|    A    |           |    B    |          |  +---------+       issuance
+---------+           +---------+          |  +---------+
    |                      |               +--|Authoriz.|e.g., membership
    |<----Beaconing--------|               |  +---------+         test
    |                      |               |  +---------+
    |<-Ph1 Authentication & Authorization->+--| Routing |e.g., IP address
    |                      |               |  +---------+       assignment
    |<-Ph2 Authentication->|               |  +---------+
    |                      |               +--| Gateway |e.g., backbone,
    |--------------------->|               |  +---------+      cloud
    |                      |<-- Config. -->|  +---------+
    |<---------------------|               +--|Bandwidth|e.g., PCE schedule
    .                      .               .  +---------+
    .                      .               .


             Figure 2: Two-stage authentication/authorization

3.  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
   authentication protocols and provide integrity protection to EB
   frames.

   For use cases where certificates are used for authentication, pre-
   provisioning of absolute time to devices from a trustable time source
   using an out-of-band (OOB) mechanism is a general requirement.



Struik, et al.           Expires April 30, 2015                 [Page 6]


Internet-Draft               6tisch-security                October 2014


   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 authentication employing
   certificates to avoid an attack that can happen by a compromised
   server or CA certificate.

4.  IANA Considerations

   There is no IANA action required for this document.

5.  Acknowledgments

   TBD.

6.  Normative References

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

   [I-D.ietf-6tisch-terminology]
              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-02 (work in
              progress), July 2014.

Authors' Addresses

   Rene Struik
   Struik Security Consultancy

   Email: rstruik.ext@gmail.com


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

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









Struik, et al.           Expires April 30, 2015                 [Page 7]


Internet-Draft               6tisch-security                October 2014


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

   Email: sdas@appcomsci.com












































Struik, et al.           Expires April 30, 2015                 [Page 8]