Skip to main content

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

Document Type Active Internet-Draft (individual)
Author Brendan Moran
Last updated 2022-07-11
Stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-moran-iot-nets-01
IOTOPS                                                          B. Moran
Internet-Draft                                               Arm Limited
Intended status: Informational                              12 July 2022
Expires: 13 January 2023

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

Abstract

   The IETF has developed security technologies that help to secure the
   Internet of Things even over constrained networks and when targetting
   constrained nodes.  These technologies can be used independenly or
   can be composed into larger systems to mitigate a variety of threats.
   This documents illustrates an overview over these technologies and
   highlights their relationships.  Ultimately, a threat model is
   presented as a basis to derive requirements that interconnect
   existing and emerging solution technologies.

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 13 January 2023.

Copyright Notice

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

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

   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 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Threats and Risks to IoT Deployments  . . . . . . . . . . . .   4
     2.1.  Threat: IoT Network Credential Exposure . . . . . . . . .   4
       2.1.1.  REQ.USE.NET.CREDENTIALS . . . . . . . . . . . . . . .   4
       2.1.2.  THREAT.IOT.NET.CREDENTIALS  . . . . . . . . . . . . .   4
       2.1.3.  REQ.SEC.NET.CREDENTIALS . . . . . . . . . . . . . . .   4
       2.1.4.  Technologies to Mitigate
               THREAT.IOT.NET.CREDENTIALS  . . . . . . . . . . . . .   5
     2.2.  Threat: Trust Anchor Private Key Disclosure . . . . . . .   5
       2.2.1.  THREAT.IOT.TA.DISCLOSURE  . . . . . . . . . . . . . .   5
       2.2.2.  REQ.SEC.TA.ROTATION . . . . . . . . . . . . . . . . .   5
       2.2.3.  Technologies to mitigate THREAT.IOT.TA.DISCLOSURE . .   5
     2.3.  Threat: Incorrect Firmware/Version  . . . . . . . . . . .   6
       2.3.1.  THREAT.FW.OLD . . . . . . . . . . . . . . . . . . . .   6
       2.3.2.  THREAT.DEV.ROGUE  . . . . . . . . . . . . . . . . . .   6
       2.3.3.  REQ.SEC.FW.MEASURE  . . . . . . . . . . . . . . . . .   6
       2.3.4.  Technologies to implement REQ.SEC.FW.MEASURE  . . . .   6
     2.4.  Threat: Vulnerable Firmware . . . . . . . . . . . . . . .   6
       2.4.1.  THREAT.FW.KNOWN.VULNERABILITY . . . . . . . . . . . .   7
       2.4.2.  REQ.SEC.FW.REMOTE.UPDATE  . . . . . . . . . . . . . .   7
       2.4.3.  THREAT.UPDATE.COMPROMISE  . . . . . . . . . . . . . .   7
       2.4.4.  REQ.SEC.UPDATE.SECURITY . . . . . . . . . . . . . . .   7
       2.4.5.  Technologies to implement REQ.SEC.UPDATE.SECURITY . .   7
     2.5.  Threat: Supply Chain Attacks  . . . . . . . . . . . . . .   7
       2.5.1.  RISK.SW.SUPPLY  . . . . . . . . . . . . . . . . . . .   7
       2.5.2.  THREAT.SW.SUPPLY  . . . . . . . . . . . . . . . . . .   7
       2.5.3.  REQ.SEC.SW.BOM  . . . . . . . . . . . . . . . . . . .   7
       2.5.4.  Technologies to implement REQ.SEC.UPDATE.SECURITY . .   8
     2.6.  Risk: Verification Information Supply Chain . . . . . . .   8
       2.6.1.  RISK.VERIFIER.DEFAULTS  . . . . . . . . . . . . . . .   8
       2.6.2.  THREAT.TRUST.ELEVATION  . . . . . . . . . . . . . . .   8
       2.6.3.  REQ.SEC.VERIFIER.DATA . . . . . . . . . . . . . . . .   8
       2.6.4.  Technologies to implement REQ.SEC.VERIFIER.DATA . . .   8
     2.7.  Threat: Spurious Network Capabilites  . . . . . . . . . .   9
       2.7.1.  THREAT.NET.SPURIOUS.FUNCTIONS . . . . . . . . . . . .   9
       2.7.2.  REQ.SEC.NET.ACL . . . . . . . . . . . . . . . . . . .   9
       2.7.3.  THREAT.NET.BAD.ACL  . . . . . . . . . . . . . . . . .   9

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

       2.7.4.  REQ.SEC.NET.ACL.SIGNATURE . . . . . . . . . . . . . .   9
       2.7.5.  THREAT.NET.WRONG.ACL  . . . . . . . . . . . . . . . .  10
       2.7.6.  REQ.SEC.NET.ACL.TRUST . . . . . . . . . . . . . . . .  10
       2.7.7.  RISK.NET.ACL.CONFLATION . . . . . . . . . . . . . . .  10
       2.7.8.  REQ.SEC.NET.ACL.SEPARATION  . . . . . . . . . . . . .  10
       2.7.9.  Technologies to Mitigate Spurious Network
               Capabilities  . . . . . . . . . . . . . . . . . . . .  10
     2.8.  Risk: DoS of ACL server . . . . . . . . . . . . . . . . .  11
       2.8.1.  RISK.NET.ACL.UPDATE . . . . . . . . . . . . . . . . .  11
       2.8.2.  THREAT.NET.ACL.DOS  . . . . . . . . . . . . . . . . .  11
       2.8.3.  REQ.SEC.NET.ACL.LOCAL . . . . . . . . . . . . . . . .  11
       2.8.4.  Technologies to Implement REQ.SEC.NET.ACL.LOCAL . . .  11
     2.9.  Threat: Delays in ACL Remediation . . . . . . . . . . . .  11
       2.9.1.  THREAT.NET.ACL.BROAD  . . . . . . . . . . . . . . . .  12
       2.9.2.  REQ.SEC.NET.ACL.DYNAMIC . . . . . . . . . . . . . . .  12
       2.9.3.  Technologies that implement
               REQ.SEC.NET.ACL.DYNAMIC . . . . . . . . . . . . . . .  12
     2.10. Threat: Vulnerable Devices  . . . . . . . . . . . . . . .  12
       2.10.1.  THREAT.NET.VULNERABLE.DEVICE . . . . . . . . . . . .  12
       2.10.2.  REQ.SEC.NET.DMZ  . . . . . . . . . . . . . . . . . .  12
       2.10.3.  Technologies to Implement REQ.SEC.NET.DMZ  . . . . .  12
   3.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   This memo serves as an entry-point to detail which technologies are
   available for use in IoT networks and to enable IoT designers to
   discover technologies that may solve their problems.  This draft
   addresses.

   This draft addresses six trustworthiness problems in IoT devices;
   expressed simply as six questions:

   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 and corresponding
       policies?

   5.  Who is authorised to initiate a software update and under which
       conditions?

   6.  How should my device trust updates to its software?

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

   Each of these questions is answered by recently developed or
   developing standards.  Each of these questions hides a security
   threat; so these threats are detailed in a threat model.

2.  Threats and Risks to IoT Deployments

   For this threat model to be useful to implementers, there are certain
   usability requirements that must be included to explain the origin of
   a threat.  These are noted where necessary.

   Sections are organised in groups of:

   *  usability requirement (if needed)

   *  threat

   *  security requirement

   *  mitigating technologies

2.1.  Threat: IoT Network Credential Exposure

   Network Credential Exposure describes the potential for exposure of
   credentials, including cryptographic material, used to access an IoT
   network.  Note that "network" here describes a logical network, such
   as a LwM2M server and its clients.

   Each physical network technology provides its own onboarding
   techniques.  Recommended practice is to follow best practices for the
   physical network technology in use.

2.1.1.  REQ.USE.NET.CREDENTIALS

   It must be possible to provide a device with credentials to access a
   network.  This is typically referred to as device onboarding.  This
   may be done by the manufacturer, the supply chain, the installer, or
   the end user.  It may be done by the device or on behalf of the
   device by a trusted third party.

2.1.2.  THREAT.IOT.NET.CREDENTIALS

   A threat actor extracts the credentials from a device or by
   eavesdropping on the credential provisioning flow

2.1.3.  REQ.SEC.NET.CREDENTIALS

   Network access credentials must be provisioned to a device in a way
   that secures them against eavesdropping or extraction.

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

2.1.4.  Technologies to Mitigate THREAT.IOT.NET.CREDENTIALS

   Several technologies are available for device onboarding:

   *  Lightweight M2M Bootstrap [LwM2M] provides a mechanism to
      provision keying material and configuration of any kind, according
      to a well-defined data model.

   *  FIDO Device Onboard [FDO] provides a mechanism to deliver an
      arbitrary block of data to devices.  This block of data can
      contain trust anchors, cryptographic information, and other device
      configuration.

   *  BRSKI [RFC8995] provides a mechanism for "Bootstrap Distribution
      of CA Certificates", as described in [RFC7030], Section 4.1.1.  In
      the process, a TLS connection is established that can be directly
      used for Enrollment over Secure Transport (EST).

   *  Enrollment over Secure Transport (EST) [RFC7030] provides a
      mechanism to deliver certificates and, optionally, private keys to
      devices.

2.2.  Threat: Trust Anchor Private Key Disclosure

   When a trust anchor of a device is used regularly, the chances of its
   private key being disclosed increase.

2.2.1.  THREAT.IOT.TA.DISCLOSURE

   A private key trusted by one or more devices is disclosed.  This
   could be caused by: a threat actor within the organisation, a
   compromise of a service using the key, etc.

2.2.2.  REQ.SEC.TA.ROTATION

   It must be possible to deploy new keys to devices in order to update
   their active trust anchors.  This does not mean that the ultimate
   trust anchor over a device is changed, but that its delegates are
   changed, enabling infrequent use of the ultimate trust anchor and
   higher security key management protocols to be deployed, such as key
   ceremonies and M of N threshold signatures.

2.2.3.  Technologies to mitigate THREAT.IOT.TA.DISCLOSURE

   Several technologies are available for trust anchor rotation:

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

   *  Lightweight M2M Bootstrap [LwM2M] provides a mechanism to
      provision keying material and configuration of any kind, according
      to a well-defined data model.

   *  FIDO Device Onboard [FDO] provides a mechanism to deliver an
      arbitrary block of data to devices.  This block of data can
      contain trust anchors, cryptographic information, and other device
      configuration.

   *  Enrollment over Secure Transport (EST) [RFC7030] provides a
      mechanism to deliver certificates and, optionally, private keys to
      devices.

2.3.  Threat: Incorrect Firmware/Version

   Incorrect firmware/version can come in two forms.

2.3.1.  THREAT.FW.OLD

   Old firmware present on device allows compromise of data sent to
   device, poisoning of data sent to service

2.3.2.  THREAT.DEV.ROGUE

   Rogue or simulated device emulates a real device, allows compromise
   of data sent to the device, or poisoning of data sent to service

2.3.3.  REQ.SEC.FW.MEASURE

   To enable devices to report their current software version and
   related data securely, devices SHOULD support a support a mechanism
   to securely measure their firmware.  This allows an IoT network to
   restrict access by non-compliant devices.

2.3.4.  Technologies to implement REQ.SEC.FW.MEASURE

   The technology used for securely measuring and reporting the firmware
   of a device is typically called remote attestation.  A protocol is
   under development for conveying remote attestation measurements in a
   trustworthy way in [I-D.ietf-rats-architecture].  Likewise, document
   format is under development in [I-D.ietf-rats-eat].

2.4.  Threat: Vulnerable Firmware

   Devices with old firmware might have a known vulnerability.  This
   could allow a threat actor to take over the device.

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

2.4.1.  THREAT.FW.KNOWN.VULNERABILITY

   If old firmware with known vulnerability cannot be altered.  This
   allows exploit of known a vulnerability.

2.4.2.  REQ.SEC.FW.REMOTE.UPDATE

   Software on unattended devices must be remotely-updatable.

2.4.3.  THREAT.UPDATE.COMPROMISE

   Compromise of the update system is fundamentally equivalent to
   persistent remote code execution.  A threat actor that gains firmware
   update capability has extensive power over the device.

2.4.4.  REQ.SEC.UPDATE.SECURITY

   Software update mechanism must be secured (see RFC9124)

2.4.5.  Technologies to implement REQ.SEC.UPDATE.SECURITY

   To enable devices to be updated securely in the field, they can
   support a remote update protocol such as [I-D.ietf-suit-manifest].
   For securely deploying software to Trusted Execution Environments,
   the a secure Trusted Application delivery protocol should be used,
   such as [I-D.ietf-teep-architecture].

2.5.  Threat: Supply Chain Attacks

   Software of unknown origin may be used in a device.  If an threat
   actor can gain control over the software supply chain, they may be
   able to sneak their code onto a device.

2.5.1.  RISK.SW.SUPPLY

   Software of unknown origin may be used in a device

2.5.2.  THREAT.SW.SUPPLY

   If software origin is not verified, a threat actor may deliberately
   and secretly seed the software supply chain with vulnerable code,
   enabling further compromise.

2.5.3.  REQ.SEC.SW.BOM

   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,

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

2.5.4.  Technologies to implement REQ.SEC.UPDATE.SECURITY

   In order to enable a device to prove provenance of its software, it
   or its network can use a software identifier such as
   [I-D.ietf-sacm-coswid].  Optionally, this software idenifier can be
   encapsulated in a manifest that includes hardware properties as well,
   such as [I-D.birkholz-rats-corim].

2.6.  Risk: Verification Information Supply Chain

   Correct values for attestation results may not be known by Verifiers,
   causing them to log values, but not limit them.

2.6.1.  RISK.VERIFIER.DEFAULTS

   Without access to a source of verification information such as
   expected attestation results, a verifier may not be able to make
   correct decisions about the trustworthiness of a device.

2.6.2.  THREAT.TRUST.ELEVATION

   A threat actor deploys compromised software to devices; this is
   detected by monitoring systems, but not identified as an attack.  If
   a threat actor can cause an attestation system to trust a device more
   than it should, this forms a new class of elevation of privilege:
   elevation of trust.

2.6.3.  REQ.SEC.VERIFIER.DATA

   Monitoring systems must know the expected values in Attestation
   results.

2.6.4.  Technologies to implement REQ.SEC.VERIFIER.DATA

   To enable a Relying Party of the Remote Attestation to correctly
   evaluate the Attestation Report, the SBoM (such as
   [I-D.ietf-sacm-coswid]) can contain expected values for the
   Attestation Report.  In addition, the expected information for
   hardware properties can be contained in another manifest, such as
   [I-D.birkholz-rats-corim].

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

   NOTE: Remote attestation terminology is fluid on this topic.  A
   "Verifier" can be any system that appraises Evidence in remote
   attestation.  It is expected that "appraisal" will be spread across
   at least two systems to maintain confidentiality and separation of
   responsibility: 1) a Verifier that ensures that the attestation
   Evidence is produced by genuine hardware, not tampered with, and not
   signed by revoked keys and 2) a monitoring system taking on the role
   of Verifier and Relying Party that appraises whether a device has the
   correct software versions and initiates remediation if not.

2.7.  Threat: Spurious Network Capabilites

   Devices may have additional, unneeded capabilites that are
   detrimental to network security.  While the best option is to disable
   this functionality in software, this is not always practical

2.7.1.  THREAT.NET.SPURIOUS.FUNCTIONS

   Devices may contain intentional or accidental capabilities to make
   networks vulnerable or launch attacks on other networks.  These
   capabilities are extremely costly to discover by inspection or audit.
   Requirement: Devices (or their supply chains) must advertise their
   network access requirements and networks must enforce that devices
   adhere to their stated network access requirements.

2.7.2.  REQ.SEC.NET.ACL

   To ensure that network infrastructure is configured discern the
   difference between authentic traffic and anomalous traffic, network
   infrastructure can implement fine-grained access control over how a
   device can use a network

2.7.3.  THREAT.NET.BAD.ACL

   If a service hosting network access requirements documents is
   compromised, it can be used to enable malicious devices to mount
   attacks.

2.7.4.  REQ.SEC.NET.ACL.SIGNATURE

   Network access ACL documents should be signed.  Best practice is to
   use offline keys for signing.

Moran                    Expires 13 January 2023                [Page 9]
Internet-Draft     IoT networking security guidelines          July 2022

2.7.5.  THREAT.NET.WRONG.ACL

   If devices are permitted to self-report ACLs without authentication
   by a trusted party, they can report any ACL recognised by the
   network.  A device can mis-advertise its network access requirements,
   pretending to be a different, but recognised and more privileged
   device (potentially cloning MAC addresses, keys, etc.)

2.7.6.  REQ.SEC.NET.ACL.TRUST

   Network Access Requirements documents must be secured against
   tampering and misreporting

2.7.7.  RISK.NET.ACL.CONFLATION

   Network Access Requirements documents embedded in or referenced from
   device certificates conflate two capabilities for network operators:
   network access requirement authorship (potentially delegated) and
   network access requirement audit.  While network operators should
   audit network access requirements, authoring those requirements
   should be done by the authors of the device behavior.

   Failure to separate these capabilities has the potential to lead to
   failed device behaviour due to wrong Network Access Requirements
   descriptions, leading to disabling of the network ACL system in the
   name of expediency.

2.7.8.  REQ.SEC.NET.ACL.SEPARATION

   Requirement: If Network Access Requirements are embedded in or
   referenced by device certificates, the responsibility for network
   access requirement authorship should be delegated to the device
   application authors.  Alternatively, this can be done explicitly by
   tying device application authorship to device network access
   requirements authorship.

2.7.9.  Technologies to Mitigate Spurious Network Capabilities

   1.  THREAT.NET.SPURIOUS.FUNCTIONS can be mitigated by use of
       [RFC8520] Manufacturer Usage Descriptions (MUDs) and a MUD
       Controller which accepts MUD files in order to automatically
       program rules into the network infrastructure.

   2.  THREAT.NET.BAD.ACL To prevent a threat actor from distributing
       their own MUD files via a MUD server, these can be signed,
       preferably with an offline key as described in [RFC8520].

Moran                    Expires 13 January 2023               [Page 10]
Internet-Draft     IoT networking security guidelines          July 2022

   3.  THREAT.NET.WRONG.ACL can be mitigated by using 802.1X, or SUIT to
       contain a MUD file or MUD file reference and integrity check.
       Alternatively, the device's RATS attestation results can be
       compared to a known list of device profiles and a MUD can be
       applied as a result without intervention from the remote device.

   4.  REQ.SEC.NET.ACL.SEPARATION can be mitigated either through key
       delegation or through the use of SUIT encapsulation of the MUD
       file.  A third option is to use a third-party ACL provider, such
       as iotopia.

2.8.  Risk: DoS of ACL server

2.8.1.  RISK.NET.ACL.UPDATE

   Recently updated devices may incur latency penalties when a new
   network access requirements reference must be resolved and verified.

2.8.2.  THREAT.NET.ACL.DOS

   A threat actor may block access to a distributor of network access
   requirements documents, thus disabling all devices referencing the
   network access requirements documents it hosts, without any network
   intrusion necessary against target networks.

2.8.3.  REQ.SEC.NET.ACL.LOCAL

   Network access requirements documents should be distributed in
   advance of use by any device because they constitute a non-local
   software dependency

2.8.4.  Technologies to Implement REQ.SEC.NET.ACL.LOCAL

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

   This allows local infrastructure to delay installation of a firmware
   update until a new MUD file can be fetched and audited.

2.9.  Threat: Delays in ACL Remediation

   If an ACL is wrong, network operators need it to be fixed quickly.

Moran                    Expires 13 January 2023               [Page 11]
Internet-Draft     IoT networking security guidelines          July 2022

2.9.1.  THREAT.NET.ACL.BROAD

   A network access requirements document grants permissions to a device
   that are too broad, but the provider of firmware updates is slow to
   respond, meaning that MUD file delivery in SUIT will take too long.

2.9.2.  REQ.SEC.NET.ACL.DYNAMIC

   It must be possible to distribute reduced permissions to network
   access controllers to mitigate a wrong ACL.  To enable rapid response
   to evolving threats, the MUD controller SHOULD also support dynamic
   update of MUD files.

2.9.3.  Technologies that implement REQ.SEC.NET.ACL.DYNAMIC

   If a MUD file is delivered by SUIT rather than via a remote server,
   then a secondary delivery channel can be used.  This can include
   manually overriding the ACL in the network infrastructure.  It can
   also include using SUIT to deliver the key that is used to verify
   signed MUD files from a specific URL, however in this scenario,
   THREAT.NET.ACL.DOS remains unmitigated.

2.10.  Threat: Vulnerable Devices

   If a vulnerable device is connected to the network, it could be a
   risk to the whole network.

2.10.1.  THREAT.NET.VULNERABLE.DEVICE

   Old firmware with known vulnerability allows exploit until it is
   updated.

2.10.2.  REQ.SEC.NET.DMZ

   Network infrastructure can 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.

2.10.3.  Technologies to Implement REQ.SEC.NET.DMZ

   Using MUD and RATS, a network operator can force a device onto a DMZ
   network containing only attestation and SUIT update services until it
   successfully attests a correct firmware version.

3.  Normative References

Moran                    Expires 13 January 2023               [Page 12]
Internet-Draft     IoT networking security guidelines          July 2022

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

   [I-D.birkholz-rats-corim]
              Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and
              W. Pan, "Concise Reference Integrity Manifest", Work in
              Progress, Internet-Draft, draft-birkholz-rats-corim-03, 11
              July 2022, <https://www.ietf.org/archive/id/draft-
              birkholz-rats-corim-03.txt>.

   [I-D.ietf-rats-architecture]
              Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
              W. Pan, "Remote Attestation Procedures Architecture", Work
              in Progress, Internet-Draft, draft-ietf-rats-architecture-
              18, 14 June 2022, <https://www.ietf.org/archive/id/draft-
              ietf-rats-architecture-18.txt>.

   [I-D.ietf-rats-eat]
              Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity
              Attestation Token (EAT)", Work in Progress, Internet-
              Draft, draft-ietf-rats-eat-14, 10 July 2022,
              <https://www.ietf.org/archive/id/draft-ietf-rats-eat-
              14.txt>.

   [I-D.ietf-sacm-coswid]
              Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
              Waltermire, "Concise Software Identification Tags", Work
              in Progress, Internet-Draft, draft-ietf-sacm-coswid-21, 7
              March 2022, <https://www.ietf.org/archive/id/draft-ietf-
              sacm-coswid-21.txt>.

   [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", Work in Progress, Internet-
              Draft, draft-ietf-suit-manifest-18, 11 July 2022,
              <https://www.ietf.org/archive/id/draft-ietf-suit-manifest-
              18.txt>.

   [I-D.ietf-teep-architecture]
              Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
              "Trusted Execution Environment Provisioning (TEEP)
              Architecture", Work in Progress, Internet-Draft, draft-
              ietf-teep-architecture-18, 11 July 2022,
              <https://www.ietf.org/archive/id/draft-ietf-teep-
              architecture-18.txt>.

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

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

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/info/rfc7030>.

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

   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
              May 2021, <https://www.rfc-editor.org/info/rfc8995>.

   [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 13 January 2023               [Page 14]