A summary of security-enabling technologies for IoT devices
draft-moran-iot-nets-00

Document Type Active Internet-Draft (individual)
Author Brendan Moran 
Last updated 2021-07-12
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
IOTOPS                                                          B. Moran
Internet-Draft                                               Arm Limited
Intended status: Informational                             July 12, 2021
Expires: January 13, 2022

      A summary of security-enabling technologies for IoT devices
                        draft-moran-iot-nets-00

Abstract

   The IETF regularly develops new technologies.  Sometimes there are
   several standards that can be combined to become vastly more than the
   sum of their parts.  Right now, there are six technologies either
   recently adopted or poised for adoption that create such a cluster.
   Combining secure onboarding, remote attestation, secure update,
   software bill-of-materials/expected attestation, automated network
   policy enforcement, and trusted execution environment provisioning,
   devices can be defended from many threats.  This is an opportunity
   for an inflection point for more secure and trustworthy devices.
   Simultaneous adoption of two or more of these six standards could
   create the foundation of computing devices that are worth trusting.

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 https://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 January 13, 2022.

Copyright Notice

   Copyright (c) 2021 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
   (https://trustee.ietf.org/license-info) in effect on the date of

Moran                   Expires January 13, 2022                [Page 1]
Internet-Draft     IoT networking security guidelines          July 2021

   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.  Barriers to IoT Adoption  . . . . . . . . . . . . . . . . . .   3
   3.  Foundations of Trustworthy IoT  . . . . . . . . . . . . . . .   3
     3.1.  Detecting a Compromise  . . . . . . . . . . . . . . . . .   4
     3.2.  Halting Malicious Activity  . . . . . . . . . . . . . . .   5
     3.3.  Remedying Vulnerabilities . . . . . . . . . . . . . . . .   5
   4.  Baseline Requirements for Secure Networks . . . . . . . . . .   5
   5.  IoT Technologies for Secure Networks  . . . . . . . . . . . .   6
     5.1.  Trust Relationships in Secure IoT Networks  . . . . . . .   7
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   IoT devices (unattended devices with network connections) are often
   considered a weak point in networks and have often been used by
   malicious parties to extract information, serve as relays, or mount
   attacks.  Appropriate use of security technologies can mitigate this
   trend and enable users allow for security polices that do not have to
   be overly protective of IoT systems and enable them to add the full
   potential of value they were designed to add.

   This draft addresses six trustworthiness problems in IoT devices and
   proposes solutions to them with six technologies.  The problems are:

   1.  What software is my device running?

   2.  How should my device connect to a network?

   3.  With which systems should my device communicate?

   4.  What is the provenance of my device's software?

   5.  Who is authorised to initiate a software update and under what
       circumstances?

   6.  How should my device update its trusted software?

Moran                   Expires January 13, 2022                [Page 2]
Internet-Draft     IoT networking security guidelines          July 2021

   Each of these questions is answered by recently developed or
   developing standards.

2.  Barriers to IoT Adoption

   IoT adoption is generally presented as a platform problem or a data
   acquisition and analysis problem.  The result is a proliferation of
   communication formats, radio standards, network technologies,
   operating systems, data gathering schemes, etc.  Despite this effort,
   IoT is not growing at the projected rates.

   IoT is not simply a combination of a device platform and a data-
   gathering platform.  In the life-cycle of devices, they must be
   commissioned and onboarded.  When a flaw is discovered, they must be
   updated to restore trustworthiness and there must be evidence that
   they are effectively trustworthy (e.g. running the intended/expected
   software).  Acknowledging the chance of security breaches, network
   infrastructure must be configured to allow access to necessary
   services and restrict access to everything else.

   Commissioning, onboarding, attestation, update, and access control
   are complex core technologies that are difficult to implement well.
   This can be seen with the plethora of poorly implemented IoT devices
   that have been reported in the news whenever a defect is found.

   IoT adoption is hampered by a lack of core technologies surrounding
   the development of trustworthy devices and device trustworthiness.
   These core technologies do not present obvious revenue streams and
   they require cooperation between many vendors for them to succeed,
   which may explain the low rate of innovation in this space.

   To reduce this barrier to entry, the IETF has been investing in these
   core technologies.

3.  Foundations of Trustworthy IoT

   IoT devices can bring a lot of value to businesses and individuals,
   but they are also difficult to manage because of their diversity,
   difficulty in auditing, maintenance, onboarding practices, and lack
   of visibility about device security posture and device software.

   Initiatives such as PSA Certified focus on device level security
   principles and encourage the use of a hardware Root of Trust (RoT)
   that provides a source of confidentiality and integrity for IoT
   systems.  The security principles led security requirements of PSA
   Certified Level 1 cover topics such as trusted boot, validating
   updates, attestation and secure communications.  Complementary to
   this, IETF provides standards that can be used to create secure

Moran                   Expires January 13, 2022                [Page 3]
Internet-Draft     IoT networking security guidelines          July 2021

   networks; this memo focuses on six standards that can beneficially be
   used together at the network level.

   Building trustworthy IoT is about more than just building devices
   conforming to best-practice security.  Users, Owners, Operators, and
   Vendors must be able to respond when a compromise occurs.  Responding
   to compromised IoT consists of three key points:

   1.  Detecting a compromise

   2.  Halting malicious activity

   3.  Remedying vulnerabilities and flawed software.

   Once a compromise has been detected, the affected device needs to be
   quarantined from the network, then security patches must be applied.

3.1.  Detecting a Compromise

   There are two broadly applicable ways to remotely detect a
   compromised IoT device:

   1.  Detect anomalous software on the device.

   2.  Detect anomalous network traffic from the device.

   Detecting anomalous software on the device requires remote
   attestation of software measurements; the report of what software the
   device is running must be trustworthy even if the software is not.
   However, attestation is an incomplete solution if the recipient of
   attestation evidence does not know what to expect.  Hence,
   trustworthy and authortative sources with understanding of what is to
   be expected are required.  Furthermore, automated systems for
   delivering these expected values must be very secure or else they
   will become targets for threat actors as well.

   Detecting anomalous traffic from the device requires a baseline of
   expected traffic; otherwise, network infrastructure cannot know what
   traffic is legitimate and what is not.  This expected traffic
   information needs to be closely associated with each individual
   device, since network traffic patterns may shift from device to
   device or version to version.  These trustworthy and authoritative
   sources of patterns must also be protected: a compromised device
   could report an incorrect expected network traffic pattern, or a
   threat actor could modify an expected network traffic pattern.

Moran                   Expires January 13, 2022                [Page 4]
Internet-Draft     IoT networking security guidelines          July 2021

3.2.  Halting Malicious Activity

   Halting malicious activity is done by network infrastructure.  A
   Network Access Control (NAC) system, such as a router, gateway,
   firewall, or L3 managed switch, can apply a network access policy on
   a per-device basis.  The NAC system uses a policy that is provided to
   it in advance in order to determine the access requirements of each
   connected autonomous device.  Assuming that these policies are
   constructed according to the principle of least privilege, This
   allows the NAC system to drop any communication that does not match
   the defined policies, effectively eliminating the use of IoT devices
   as relays, proxies, or mechanism to pivot in a network.  It may even
   prevent compromises before they occur because inbound traffic to IoT
   devices that does not conform to policy can be discarded.

   For shared media, such as radio protocols, intra-LAN policies cannot
   be preemptively effectively enforced, but they can be monitored and
   enforced after violation, for example by removing network access
   rights.  Per-device Internet-to-LAN policies and LAN-to-Internet
   policies can still be applied as normal.

3.3.  Remedying Vulnerabilities

   Remedying vulnerabilities requires a remote update system.  Where
   there are secure components that are independently updatable,
   additional considerations are required.  In both cases, the new
   software must be signed, but that alone is insufficient: new software
   must be authenticated against a known, authorized party.  It must
   also come with a statement of provenance: a software bill of
   materials or SBoM.  This statement must describe all the components
   of the software along with defining the authorship of the software,
   which may be separate from the authority to install that software on
   a given device.

4.  Baseline Requirements for Secure Networks

   To establish a trustworthy IoT network, devices MUST be able to
   prove:

   1.  What software they are running and, by extension:

       1.  The provenance of the software.

       2.  (Optionally) that it has been checked for common malware,
           backdoors, etc.

   2.  Who they will connect to or exchange data with so that anomalies
       can be registered.

Moran                   Expires January 13, 2022                [Page 5]
Internet-Draft     IoT networking security guidelines          July 2021

   To install and maintain IoT devices, authorized entities MUST be able
   to:

   1.  Connect a device to a secure network.

   2.  Initiate an update of a device.

   3.  (Optionally) Add or remove authorized entities from the device.

   4.  (Optionally) Deploy and remove protected assets to and from the
       device.

   Each of these requirements stops a particular avenue of attack
   against device, networks, or data collection systems.

5.  IoT Technologies for Secure Networks

   Assembling the foundations of trustworthy IoT and the baseline
   requirements for secure networks, the result is a set of
   requirements, described here with enabling standards:

   1.  To deploy new keys into a device and connect it to a network,
       devices SHOULD support a secure onboarding protocol such as FIDO
       Device Onboarding [FDO] or LwM2M Bootstrap ([LwM2M]).

   2.  To enable devices to report their current software version and
       related data securely, devices SHOULD support a support a
       mechanism of performing attestation measurements in a trustworthy
       way and a Remote Attestation protocol, such as
       [I-D.ietf-rats-eat].

   3.  To enable devices to be updated securely in the field, they
       SHOULD support a remote update protocol such as
       [I-D.ietf-suit-manifest].

   4.  To prove the provenance of a firmware update, update manifests
       SHOULD include (directly, or by secure reference) a Software
       Identifier or Software Bill of Materials, such as
       [I-D.ietf-sacm-coswid].

   5.  To enable a Relying Party of the Remote Attestation to correctly
       evaluate the Attestation Report, the SBoM (such as
       [I-D.ietf-sacm-coswid]) SHOULD contain expected values for the
       Attestation Report.

   6.  To ensure that network infrastructure is configured discern the
       difference between authentic traffic and anomalous traffic,
       network infrastructure SHOULD contain a [RFC8520] Manufacturer

Moran                   Expires January 13, 2022                [Page 6]
Internet-Draft     IoT networking security guidelines          July 2021

       Usage Description (MUD) Controller which accepts MUD files in
       order to automatically program rules into the network
       infrastructure.

   7.  In order for network infrastructure to be configured in advance
       of any changes to devices, MUD files SHOULD be transported
       (directly or by secure reference) within update manifests.

   8.  To enable rapid response to evolving threats, the MUD controller
       SHOULD also support dynamic update of MUD files.

   9.  Network infrastructure SHOULD apply risk management policy to
       devices that attest non-compliant configuration.  For example, a
       device with out-of-date firmware may only be permitted to access
       the update system.

5.1.  Trust Relationships in Secure IoT Networks

   [FDO] and [LwM2M] enable the installation of trust anchors in IoT
   devices.  These enable the services to ascertain that the devices are
   not counterfeit.  They also enable the devices to trust that the
   services are not on-path attackers.

   The combination of SUIT, CoSWID and RATS Attestation secures these
   trust relationships further.  A device operator receives a SUIT
   manifest, that contains a CoSWID.  They apply the SUIT manifest to a
   device.  The newly updated device then attests its software version
   (one or more digests) to the device operator's infrastructure.  The
   device operator can then automatically compare the attestation
   evidence to the CoSWID.

   The device operator can trust that expected values are correct
   because they are signed by the software author.  The device operator
   can trust that the attestation report is correct because it is signed
   by the verifier and, finally, the device operator can trust the
   device because its attestation evidence content matches its CoSWID.

   To extend this relationship to Trusted Applications (TAs) as well,
   devices that support TAs can also implement
   [I-D.ietf-teep-architecture].

   Adding MUD to the combination above cements the established trust
   with enforcement.  The network operator also receives the SUIT
   manifest for the device.  The manifest contains a MUD file in
   addition to the above.  The device does not need to report a MUD URI
   as described in [RFC8520]-which stops the device from falsifying it.
   Instead, the network operator also receives an attestation report for
   the device.  If the attestation report matches the CoSWID in the

Moran                   Expires January 13, 2022                [Page 7]
Internet-Draft     IoT networking security guidelines          July 2021

   manifest, then the network operator automatically applies the MUD
   file that is also contained in the manifest.  This allows a secure
   link to be established between a particular MUD file and a particular
   software version.

   The trust relationships are somewhat more complex with MUD: the
   network operator may not trust the software author to produce
   vulnerability-free software.  This means that the network operator
   may choose to override the MUD file in the manifest.  Because the MUD
   file is not even reported by the device, the network operator is free
   to do this.  The network operator can trust the attestation report
   because it is signed by the verifier.  They trust that the values
   reported in the CoSWID are accurate because it is signed by the
   software author who also signs the software.  They trust that the
   device is running the software described in the CoSWID because it
   matches the attestation report.  They trust the MUD file because it
   is signed by the software author - or because they have supplied that
   MUD file themselves.  MUD files may also be obtained from third-party
   providers, such as Global Platform Iotopia
   (https://globalplatform.org/iotopia/mud-file-service/).

6.  Normative References

   [FDO]      FIDO Alliance, ., "FIDO Device Onboarding", n.d.,
              <https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-
              RD-v1.0-20201202.html>.

   [I-D.ietf-rats-eat]
              Mandyam, G., Lundblade, L., Ballesteros, M., and J.
              O'Donoghue, "The Entity Attestation Token (EAT)", draft-
              ietf-rats-eat-09 (work in progress), March 2021.

   [I-D.ietf-sacm-coswid]
              Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
              Waltermire, "Concise Software Identification Tags", draft-
              ietf-sacm-coswid-17 (work in progress), February 2021.

   [I-D.ietf-suit-manifest]
              Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg,
              "A Concise Binary Object Representation (CBOR)-based
              Serialization Format for the Software Updates for Internet
              of Things (SUIT) Manifest", draft-ietf-suit-manifest-12
              (work in progress), February 2021.

Moran                   Expires January 13, 2022                [Page 8]
Internet-Draft     IoT networking security guidelines          July 2021

   [I-D.ietf-teep-architecture]
              Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
              "Trusted Execution Environment Provisioning (TEEP)
              Architecture", draft-ietf-teep-architecture-14 (work in
              progress), February 2021.

   [IoTopia]  "Global Platform Iotopia", n.d.,
              <https://globalplatform.org/iotopia/mud-file-service/>.

   [LwM2M]    "LwM2M Core Specification", n.d.,
              <http://openmobilealliance.org/release/LightweightM2M/
              V1_2-20201110-A/OMA-TS-LightweightM2M_Core-
              V1_2-20201110-A.pdf>.

   [RFC8520]  Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
              Description Specification", RFC 8520,
              DOI 10.17487/RFC8520, March 2019,
              <https://www.rfc-editor.org/info/rfc8520>.

   [SWID]     NIST, ., "Software Identification (SWID) Tagging", n.d.,
              <https://csrc.nist.gov/Projects/Software-Identification-
              SWID/guidelines>.

Author's Address

   Brendan Moran
   Arm Limited

   EMail: Brendan.Moran@arm.com

Moran                   Expires January 13, 2022                [Page 9]