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

Versions: 00 01 draft-ietf-6tisch-dtsecurity-secure-join

6tisch Working Group                                       M. Richardson
Internet-Draft                                  Sandelman Software Works
Intended status: Informational                        September 13, 2016
Expires: March 17, 2017


                      6tisch Secure Join protocol
           draft-richardson-6tisch-dtsecurity-secure-join-00

Abstract

   Charter: The WG will continue working on securing the join process
   and making that fit within the constraints of high latency, low
   throughput and small frame sizes that characterize IEEE802.15.4 TSCH.

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 March 17, 2017.

Copyright Notice

   Copyright (c) 2016 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.





Richardson               Expires March 17, 2017                 [Page 1]


Internet-Draft         6tisch Secure Join protocol        September 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Credentials . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.1.  One-Touch Assumptions . . . . . . . . . . . . . . . .   4
       1.2.2.  Factory provided credentials (if any) . . . . . . . .   4
       1.2.3.  Credentials to be introduced  . . . . . . . . . . . .   5
     1.3.  Network Assumptions . . . . . . . . . . . . . . . . . . .   5
       1.3.1.  Security above and below IP . . . . . . . . . . . . .   5
       1.3.2.  Join network assumptions  . . . . . . . . . . . . . .   6
       1.3.3.  Number and cost of round trips  . . . . . . . . . . .   6
       1.3.4.  Size of packets, number of fragments  . . . . . . . .   6
     1.4.  Target end-state for join process . . . . . . . . . . . .   6
     1.5.  Diagram of Join Process . . . . . . . . . . . . . . . . .   6
     1.6.  Description of States in Join Process . . . . . . . . . .   7
   2.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   4.  Protocol Definition . . . . . . . . . . . . . . . . . . . . .   7
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  appendix . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Enrollment of new nodes into LLNs present unique challenges.  The
   constrained nodes has no user interfaces, and even if they did,
   configuring thousands of such nodes manually is undesireable from a
   human resources issue, as well as the difficulty in getting
   consistent results.

   This document is about a standard way to introduce new nodes into a
   6tisch network that does not involve any direct manipulation of the
   nodes themselves.  This act has been called "zero-touch"
   provisioning, and it does not occur by chance, but requires
   coordination between the manufacturer of the node, the service
   operator running the LLN, and the installers actually taking the
   devices out of the shipping boxes.

   In other installations (such as some factory/industrial settings, and
   for some utilities), it is possible to pass devices through a
   "provisioning" room of some kind where the device in factory default
   state may be touched once (via a cable, or a push button, or by being
   placed in a faraday cage, etc.) such that the devices can be
   initialized in a way specific to that installation.  The devices are
   then returned to inventory, and may be deployed at some future time.



Richardson               Expires March 17, 2017                 [Page 2]


Internet-Draft         6tisch Secure Join protocol        September 2016


   The node is not provisioned with the current keying material, as the
   network will need to be regularly rekeyed (even the algorithms may
   change!), so in the one-touch provisioning case, the goal is simply
   to introduce some elements into the new node (the "pledge") such that
   the enrollment process will take less energy and fewer network
   resources.

1.1.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119] and indicate requirement levels for compliant STuPiD
   implementations.

   The following terminology is repeated from
   [I-D.ietf-anima-bootstrapping-keyinfra] so as to have a common way to
   speak:

   drop ship  The physical distribution of equipment containing the
      "factory default" configuration to a final destination.  In zero-
      touch scenarios there is no staging or pre-configuration during
      drop-ship.

   imprint  the process where a device obtains the cryptographic key
      material to identity and trust future interactions with a network.
      This term is taken from Konrad Lorenz's work in biology with new
      ducklings: during a critical period, the duckling would assume
      that anything that looks like a mother duck is in fact their
      mother.  An equivalent for a device is to obtain the fingerprint
      of the network's root certification authority certificate.  A
      device that imprints on an attacker suffers a similar fate to a
      duckling that imprints on a hungry wolf.  Securely imprinting is a
      primary focus of this document. [duckling] anticipates this use.

   enrollment  the process where a device presents key material to a
      network and acquires a network specific identity.  For example
      when a certificate signing request is presented to a certification
      authority and a certificate is obtained in response.

   pledge  the prospective device, which has the identity provided to at
      the factory.  Neither the device nor the network knows if the
      device yet knows if this device belongs with this network.  This
      is definition 6, according to [pledge].

   Audit Token  A signed token from the manufacturer authorized signing
      authority indicating that the bootstrapping event has been
      successfully logged.  This has been referred to as an



Richardson               Expires March 17, 2017                 [Page 3]


Internet-Draft         6tisch Secure Join protocol        September 2016


      "authorization token" indicating that it authorizes bootstrapping
      to proceed.

   Ownership Voucher  A signed voucher from the vendor vouching that a
      specific domain "owns" the new entity as defined in
      [I-D.ietf-netconf-zerotouch].

1.2.  Credentials

   In the zero-touch scenario, every device expected to be drop shipped
   would have an [ieee802-1AR] manufacturer installed certificate (MIC).
   The private key part of the certificate would either be generated in
   the device, or installed securely (and privately) as part of the
   manufacturer process.  [cullenCiscoPhoneDeploy] provides an example
   of process which has been active for a good part of a decade.

   The MIC would be signed by the manufacturer's CA, the public key
   component of that would be included in the firmware.

1.2.1.  One-Touch Assumptions

   In a one-touch scenario, devices would be provided with some
   mechanism by which a secure association may be made in a controlled
   environment.  There are many ways in which this might be done, and
   detailing any of them is out of scope for this document.  But, some
   notion of how this might be done is important so that the underlying
   assumptions can be reasoned about.

   Some examples of how to do this could include: * JTAG interface *
   serial (craft) console interface * pushes of physical buttons
   simulatenous to network attachment * insecured devices operated in a
   Faraday cage

   There are likely many other ways as well.  What is assumed is that
   there can be a secure, private conversation between the Join
   Coordination Entity, and the Pledge, and that the two devices can
   exchange some trusted bytes of information.

1.2.2.  Factory provided credentials (if any)

   When a manufacturer installed certificate is provided as the IDevID,
   it SHOULD contain a number of fields.
   [I-D.ietf-anima-bootstrapping-keyinfra] provides a detailed set of
   requirements.

   A manufacturer unique serial number MUST be provided in the
   serialNumber SubjectAltName extension, and MAY be repeated in the
   Common Name.  There are no sequential or numeric requirements on the



Richardson               Expires March 17, 2017                 [Page 4]


Internet-Draft         6tisch Secure Join protocol        September 2016


   serialNumber, it may be any unique value that the manufacturer wants
   to use.  The serialNumber SHOULD be printed on the packaging and/or
   on the device in a discrete way.

1.2.3.  Credentials to be introduced

   The goal of the bootstrap process is to introduce one or more new
   locally relevant credentials:

   1.  a certificate signed by a local certificate authority/registrar.
       This is the LDevID of [ieee802-1AR].

   2.  alternatively, a network-wide key to be used to secure L2
       traffic.

   3.  alternatively, a network-wide key to be used to authenticate per-
       peer keying of L2 traffic using a mechanism such as provided by
       [ieee802159].

1.3.  Network Assumptions

   This document is about enrollment of constrained devices [RFC7228] to
   a constrained network.  Constrained networks is such as [ieee802154],
   and in particular the time-slotted, channel hopping (tsch) mode,
   feature low bandwidths, and limited opportunities to transmit.  A key
   feature of these networks is that receivers are only listening at
   certain times.

1.3.1.  Security above and below IP

   802.15.4 networks have three kinds of layer-2 security:

   o  a network key that is shared with all nodes and is used for
      unicast and multicast.

   o  a series of network keys that are shared (agreed to) between pairs
      of nodes (the per-peer key)

   o  a network key that is shared with all nodes (through a group key
      management system), and is used for multicast traffic only

   Setting up the credentials to bootstrap one of these kinds of
   security, (or directly configuring the key itself for the first case)
   is required.  This is the security below the IP layer.

   Security is required above the IP layer: there are three aspects
   which the credentials in the previous section are to be used.




Richardson               Expires March 17, 2017                 [Page 5]


Internet-Draft         6tisch Secure Join protocol        September 2016


   o  to provide for secure connection with a Path Computation Element
      [RFC4655], or other LLC (see ({RFC7554}} section 3).

   o  to initiate a connection between a Resource Server (RS) and an
      application layer Authorization Server (AS and CAS from
      [I-D.ietf-ace-actors]).

1.3.1.1.  Perfect Forward Secrecy

   Perfert Forward Secrecy (PFS) is the property of a protocol such that
   complete knowledge of the crypto state (for instance, via a memory
   dump) at time X does not imply that data from a disjoint time Y can
   also be recovered.  ([PFS]).

   PFS is important for two reasons: one is that it offers protection
   against the compromise of a node.  It does this by changing the keys
   in a non-deterministic way.  This second property also makes it much
   easier to remove a node from the network, as any node which has not
   participated in the key changing process will find itself no longer
   connected.

1.3.2.  Join network assumptions

   The network which the new pledge will connect to will have to have
   the following properties:

   o  a known PANID.  The PANID 0xXXXX where XXXX is the assigned RFC#
      for this document is suggested.

   o  a minimal schedule with some Aloha time.  This is usually in the
      same slotframe as the Extended Beacon, but a pledge MUST listen
      for an unencrypted Extended Beacon to so that it can synchronize.

   o  a known K1 key, as described in [I-D.ietf-6tisch-minimal] section
      10, and used for reasons similar to [iec62591].

1.3.3.  Number and cost of round trips

1.3.4.  Size of packets, number of fragments

1.4.  Target end-state for join process

1.5.  Diagram of Join Process








Richardson               Expires March 17, 2017                 [Page 6]


Internet-Draft         6tisch Secure Join protocol        September 2016


1.6.  Description of States in Join Process

2.  Security Considerations

3.  IANA Considerations

4.  Protocol Definition

5.  References

5.1.  Normative References

   [cullenCiscoPhoneDeploy]
              Jennings, C., "Transitive Trust Enrollment for Constrained
              Devices", 2012, <http://www.lix.polytechnique.fr/hipercom/
              SmartObjectSecurity/papers/CullenJennings.pdf>.

   [I-D.ietf-6tisch-minimal]
              Vilajosana, X. and K. Pister, "Minimal 6TiSCH
              Configuration", draft-ietf-6tisch-minimal-16 (work in
              progress), June 2016.

   [I-D.ietf-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Behringer, M., and S.
              Bjarnason, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-03 (work in progress), June 2016.

   [I-D.ietf-netconf-zerotouch]
              Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning
              for NETCONF or RESTCONF based Management", draft-ietf-
              netconf-zerotouch-09 (work in progress), July 2016.

   [iec62591]
              IEC, ., "62591:2016 Industrial networks - Wireless
              communication network and communication profiles -
              WirelessHART", 2016, <https://webstore.iec.ch/
              publication/24433>.

   [ieee802-1AR]
              IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier",
              2009, <http://standards.ieee.org/findstds/
              standard/802.1AR-2009.html>.








Richardson               Expires March 17, 2017                 [Page 7]


Internet-Draft         6tisch Secure Join protocol        September 2016


   [ieee802154]
              IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low-
              Rate Wireless Personal Area Networks (WPANs)", 2015,
              <http://standards.ieee.org/findstds/
              standard/802.15.4-2015.html>.

   [ieee802159]
              IEEE Standard, ., "802.15.9-2016 - IEEE Approved Draft
              Recommended Practice for Transport of Key Management
              Protocol (KMP) Datagrams", 2016,
              <http://standards.ieee.org/findstds/
              standard/802.15.9-2016.html>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <http://www.rfc-editor.org/info/rfc7228>.

5.2.  Informative References

   [duckling]
              Stajano, F. and R. Anderson, "The resurrecting duckling:
              security issues for ad-hoc wireless networks", 1999,
              <https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-
              duckling.pdf>.

   [I-D.ietf-ace-actors]
              Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An
              architecture for authorization in constrained
              environments", draft-ietf-ace-actors-04 (work in
              progress), September 2016.

   [PFS]      Wikipedia, ., "Forward Secrecy", August 2016,
              <https://en.wikipedia.org/w/
              index.php?title=Forward_secrecy&oldid=731318899>.

   [pledge]   Dictionary.com, ., "Dictionary.com Unabridged", 2015,
              <http://dictionary.reference.com/browse/pledge>.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <http://www.rfc-editor.org/info/rfc4655>.



Richardson               Expires March 17, 2017                 [Page 8]


Internet-Draft         6tisch Secure Join protocol        September 2016


   [RFC7554]  Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
              IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
              Internet of Things (IoT): Problem Statement", RFC 7554,
              DOI 10.17487/RFC7554, May 2015,
              <http://www.rfc-editor.org/info/rfc7554>.

Appendix A.  appendix

   insert appendix here

Author's Address

   Michael Richardson
   Sandelman Software Works

   Email: mcr+ietf@sandelman.ca



































Richardson               Expires March 17, 2017                 [Page 9]


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