Skip to main content

Delegation based Device Onboarding using PoA Authorization
draft-vattaparambil-iotops-poa-based-onboarding-02

Document Type Active Internet-Draft (individual)
Authors Sreelakshmi Vattaparambil Sudarsan , Olov Schelen , Ulf Bodin
Last updated 2023-10-20
RFC 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-vattaparambil-iotops-poa-based-onboarding-02
IOTOPS                                                       Sreelakshmi
Internet-Draft                                                      Olov
Intended status: Informational                                       Ulf
Expires: 22 April 2024                    Lulea University of Technology
                                                         20 October 2023

       Delegation based Device Onboarding using PoA Authorization
           draft-vattaparambil-iotops-poa-based-onboarding-02

Abstract

   Industrial network layer onboarding demands a technique that is
   efficient, scalable, and secure.  In this document, we propose a
   delegation-based device onboarding technique using Power of Attorney
   (PoA) based authorization.  This enables manufacturers to send the
   device to the right device owner manage the ownership transfer
   through the supply chain and eventually resell the device to a new
   owner.

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 22 April 2024.

Copyright Notice

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

Sreelakshmi, et al.       Expires 22 April 2024                 [Page 1]
Internet-Draft              Abbreviated Title               October 2023

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Onboarding basics . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  State of the art  . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Problem description . . . . . . . . . . . . . . . . . . .   4
   3.  Delegation based Onboarding . . . . . . . . . . . . . . . . .   4
   4.  PoA-Delegation Voucher Structure  . . . . . . . . . . . . . .   6
   5.  Ownership Transfer using PoA based Delegation . . . . . . . .   7
   6.  Power of Attorney based authorization . . . . . . . . . . . .   9
   7.  Related Works . . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     8.1.  Attacks out of scope  . . . . . . . . . . . . . . . . . .  12
     8.2.  Attacks in scope  . . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Onboarding devices in industrial setting must be efficient, scalable,
   and secure.  NIST guidelines on network layer onboarding [NIST]
   explain essential features required by an ideal onboarding model.
   Many zero-touch onboarding models require the manufacturer to build
   and configure devices with specific onboarding features based on the
   destination network.  It is complex to gather the onboarding
   requirements from multiple parties involved based on a centralized
   infrastructure, which makes it expensive and inefficient.

   There are different onboarding features that are established as part
   of the existing onboarding standards and there are different missing
   features that can improve the current onboarding technique.  In this
   draft, we discuss different important onboarding features that can be
   obtained using delegation-based device onboarding.  This can secure
   the device with unique onboarding credentials during deployment
   rather than at the time of manufacture (late binding).  This approach

Sreelakshmi, et al.       Expires 22 April 2024                 [Page 2]
Internet-Draft              Abbreviated Title               October 2023

   is based on subgranting or delegation-based authorization, in which
   power or delegation can be granted to another entity for a limited
   time.  This can be used between different parties in the supply chain
   and with integrators for ultimate onboarding in at the customer site.
   It can also be used in typical industrial subcontractor use cases
   where devices owned by subcontractors must/should temporarily (ie.,
   for a limited time) be onboarded to an industrial site while the
   formal ownership is retained by the subcontractor.  In the proposed
   model, we establish a trust chain between the manufacturer, device,
   device owner, and the onboarding controller for the automatic
   onboarding of devices using the power of attorney based authorization
   technique.  This draft defines the protocol flow of the proposed
   onboarding technique defining the different entities part of the
   onboarding, mutual authorization between them, late binding,
   onboarding of devices without connectivity, transfer of ownership,
   and the sub-problem of reselling the device.  With the use of CBOR
   and CoAP instead of JSON-based token formats, the proposed technique
   is suitable for use in constrained environments.

   Note that in this document we focus on the onboarding case using PoA
   while indeed PoA is completely generic and can be used in various
   other subgranting, and data sharing use cases, not covered in this
   document.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Onboarding basics

2.1.  State of the art

   Device onboarding can be defined as an automated process of securely
   provisioning the device at the destination network from the
   manufacturer’s site via the supply chain.  One aspect of onboarding
   is providing the device with network access [nordmark-iotops].  There
   are different definitions for onboarding; Intel zero-touch onboarding
   [Intel] refers it as an ”Automated service that enables a device to
   be drop-shipped and powered on to dynamically provision to a
   customer’s IoT platform of choice in seconds”. According to Amazon
   Web Services (AWS), ”IoT device onboarding or provisioning refers to
   the process of configuring devices with unique identities,
   registering these identities with their IoT endpoint, and associating
   required permissions”. NIST guidelines are also referred by IETF

Sreelakshmi, et al.       Expires 22 April 2024                 [Page 3]
Internet-Draft              Abbreviated Title               October 2023

   [t2trg], ”Onboarding is sometimes used as a synonym for bootstrapping
   and at other times is defined as a subprocess of bootstrapping”.
   According to the guidelines provided by NIST, onboarding can be
   performed in two different layers:

   *  Network layer onboarding

   *  Application layer onboarding.

   The network layer onboarding may ensure device integrity and
   authorized ownership throughout the initial phases of onboarding.
   The information gathered during network layer onboarding is passed to
   application layer onboarding to make the device operational in the
   application layer.

2.2.  Problem description

   The main issues in a device lifecycle are device ownership transfer,
   management of the device after bootstrapping such as installing the
   required software, its maintenance, and disposition of the device
   when transitioning to a new owner.  Because of the large number of
   external devices and the security issues caused by their
   communication, device onboarding is considered as an important
   process.  Multiple entities, transportation methods, sensitive data
   sharing, and other factors make the onboarding process difficult,
   necessitating automation and security.  Hence, there is a need for an
   efficient onboarding procedure that secures devices with unique
   onboarding credentials during deployment rather than at the time of
   manufacture.

3.  Delegation based Onboarding

   This document considers the network layer onboarding and subgranting
   the power to onboard from one entity to another in the bootstrapping
   stage.  The different roles are:

   *  Manufacturer: The entity who built the device and is considered
      the very first owner of the device.

   *  Device: The device to be onboarded.

   *  Device Owner: The owner of the device, who is the last entry in
      the ownership voucher.

   *  Onboarding Controller: Part of the target network that provides
      network onboarding credentials to the device.

   Figure 1 shows the Protocol flow diagram of the proposed model.

Sreelakshmi, et al.       Expires 22 April 2024                 [Page 4]
Internet-Draft              Abbreviated Title               October 2023

             +------+          +------+         +------+
             |      |  voucher |      |  voucher|      |
             |  I0  |--------->|  I1  |  ....   |  In  |
             +------+          +------+         +------+
                ^                                   |
                |                                   |voucher
                | voucher                           |
                |                                   v
           +---------+                          +---------+
           |         |                          |         |
           |  Manufa-|                          |         |
           |  cturer |                          |  Device |
           |  (DO0)  |                          |  Owner  |
           |         |                          |         |
           +---------+                          +---------+
                |                                   ^
                |1.Device onboarding                |
                |credentials + hash                 |
                v    2.Mutual handshake with voucher|
           +---------+    + device identification   |     +----------+
           |         |<------------------------------     |          |
           |         |  3. PoA + Device onboarding cred.  |          |
           | Device  |----------------------------------->|Onboarding|
           |         |    4.Network onboarding cred.      |Controller|
           |         |<-----------------------------------|          |
           +---------+                                    +----------+

           Figure 1: Protocol flow of Delegation based onboarding

   *  1) Manufacturer includes the device onboarding credentials to the
      device.  This includes device ID, target network identifier
      (onboarding controller identifier), and device owner identifier,
      which can be in different forms such as certificates, pre-shared
      keys, and passwords.

   *  Parallel to step 1, the manufacturer sends the PoA-delegation
      voucher signed by the manufacturer to the first entity in the
      supply chain (this can be an integrator, retailer, etc).  This PoA
      is transferred through the supply chain until it reaches the
      Device Owner entity.  See section 5 for more details.

   *  2) The device and the device owner are mutually authenticated and
      authorized by sharing the PoA-delegation voucher and device
      identification with each other.  The device owner sends in the
      PoA-delegation voucher with the device identification details
      (device onboarding credentials hash) in it.  The device matches
      the device onboarding credentials hash in the PoA-delegation
      voucher with the one it possesses.  In addition, device verifies

Sreelakshmi, et al.       Expires 22 April 2024                 [Page 5]
Internet-Draft              Abbreviated Title               October 2023

      the signature on the PoA-delegation voucher using the device owner
      public key in its PoA-delegation voucher, to identify the right
      owner.  Similarly, the device sends in the device identification
      details to the device owner, which is verified by the device
      owner.

   *  3) The device sends the PoA-delegation voucher and the device
      onboarding credentials to the onboarding controller to obtain the
      credentials to onboard the device.

   *  4) The onboarding controller provides the network onboarding
      credentials to the device on successful verification of the PoA-
      delegation voucher and other credentials.  The network onboarding
      credentials include information required to bootstrap with the
      target network.  Here, we assume that the network onboarding
      controller and the device owner have a pre-established trust
      relation.

   The revocation of the PoA-delegation voucher can be accomplished by
   setting a low expiration time depending on the use case.  In that
   case, the PoA-delegation voucher must be reissued periodically.

   Once the device obtains the network bootstrapping credentials, it can
   start communicating with the local cloud.  This model for onboarding
   enables the subcontractor to onboard devices by subgranting his/her
   power to the device to act on behalf of the subcontractor.  A proof
   of concept of the proposed model can be found at
   "https://github.com/sreelakshmivs/PoAimplementationinJava" under the
   MIT license.

4.  PoA-Delegation Voucher Structure

   They are self-contained tokens that are structured in the compressed
   binary format CBOR.  The entire voucher is first signed by the
   manufacturer using his/her private key.  The various parameters
   included in a PoA-Delegation Voucher are the following:

   Manufacturer Public Key
      REQUIRED.  The public key uniquely identifies the manufacturer who
      generates the PoA-delegation voucher.  We assume that the public
      key is generated using a secure public-key algorithm by the
      principal.  With this parameter, the authorization server can
      identify the person who generated the PoA-delegation voucher.

   Manufacturer Name
      OPTIONAL.  The human-readable name of the manufacturer, which is
      additional information about the manufacturer.

Sreelakshmi, et al.       Expires 22 April 2024                 [Page 6]
Internet-Draft              Abbreviated Title               October 2023

   Agent Public Key
      REQUIRED.  The public key, which uniquely identifies the agent or
      intermediate entity (Io, I1,.., In).  This field is changed
      throughout the supply chain while transferring the voucher to the
      next agent in the supply chain.

   Device Owner ID
      REQUIRED.  The unique identifier or the public key of the device
      owner.

   Device Onboarding Credentials Hash
      REQUIRED.  The copy of the hash that is sent to the device by the
      manufacturer.

   Signing Algorithm
      OPTIONAL.  The name of the signature algorithm used by the
      principal to digitally sign the PoA-delegation voucher.

   Transferable
      REQUIRED.  It is a positive integer defining how many steps the
      PoA-delegation voucher can be transferred.  The default is 0,
      which means that it is not transferable.  A PoA-delegation voucher
      can be transferred by including it in another PoA-delegation
      voucher, i.e., it is signed in several delegation steps (where the
      number is decreased by one in each step).

   iat (Issued at)
      REQUIRED.  The time at which the PoA-delegation voucher is issued
      by the principal to the agent.

   eat (Expires at)
      REQUIRED.  The time at which the PoA-delegation voucher expires.
      This parameter is predefined by the manufacturer in the PoA-
      delegation voucher and it will be invalid after eat.

   Metadata
      OPTIONAL.  The metadata is associated with the bootstrapping
      process if any.  This parameter includes different sub- parameters
      that add specific information to the voucher.

5.  Ownership Transfer using PoA based Delegation

   There are multiple ways of ownership transfer, and each of them has
   their strengths and limitations.  In this draft, we define the
   transfer of owenrship based on delegation using the PoA based
   authorization technique.  Here, the manufacturer is the first owner
   or DO0 of the device.  The manufacturer signs the PoA-delegation
   voucher and sends it to the first entity in the supply chain.  The

Sreelakshmi, et al.       Expires 22 April 2024                 [Page 7]
Internet-Draft              Abbreviated Title               October 2023

   existing ownership voucher techniques consider the intermediate
   parties between the manufacturer and the final device owner, that are
   part of the supply chain as device owners.  In this technique, these
   intermediate entities are delegated to work on the device for a
   limited time or the PoA-delegation voucher allows them to work on
   behalf of the DO0 (manufacturer).  The first voucher is signed by the
   manufacturer and the agent public key parameter is set to the public
   key or identification of the first entity (I0) in the supply chain.
   When I0 finish its task on the device, this field is changed to the
   public key of the next entity in the supply chain and the whole
   voucher is signed using the private key of I0.  This process
   continues through the supply chain until it reaches the device owner,
   which is identified using the Device Owner Public Key parameter in
   the voucher.  At this point, the PoA-delegation voucher would be
   signed with the private key of the last entity (In) in the supply
   chain.

   With each transfer of the ownership voucher (PoA-delegation voucher),
   the transferable parameter value is decremented.  So, when it reaches
   the final device owner, the value of transferable in the voucher is
   0.  When the current owner resells the device in the future, they can
   set the transferable parameter value to an integer equal to the
   number of intermediate entities.

   With this approach, the intermediate entities such as integrators and
   retailers are not considered as device owners with full ownership of
   the device.  Instead, they are delegated by the manufacturer, which
   allows them to work on the device for the time being.

   Here, the intermediate entities can be the trusted parties of the
   manufacturer or they can be also considered trustworthy from the
   other direction; which means they can be trusted parties of the
   device owner side.  Either direction of the trust chain could be
   possible.

   With this approach, the reselling of the device can be done by
   transferring the PoA from the DO to the new owner without bothering
   the manufacturer.  The current device owner issues a new PoA-
   delegation voucher to the new device owner by changing the device
   owner's public key parameter to the public key of the new owner.  The
   device is fully reset without deleting the device onboarding
   credentials and adds the copy of the PoA-delegation voucher issued to
   the new owner, by the current owner of the device who sells the
   device.

Sreelakshmi, et al.       Expires 22 April 2024                 [Page 8]
Internet-Draft              Abbreviated Title               October 2023

6.  Power of Attorney based authorization

   PoA-based authorization is a generic authorization technique used to
   authorize devices to access protected resources on behalf of the
   user, who owns the device (principal), even if the user is not
   online.  The PoA model in its base form is completely decentralized
   (like for example Pretty Good Privacy (PGP)), where the user
   subgrants their power in the form of a self- contained PoA that
   contains public information such as public keys and a specific set of
   permissions for a predefined time.  It is a decentralized
   authorization technique, where the different entities involved can
   access and verify the PoA using a downloadable image or library
   similar to PGP.  Some centralization can be added by optional
   signatory registers and/or traditional Certificate Authorities (CA).
   The entities involved in PoA based authorization system are:

   *  Principal: The entity that generates and sends the PoA to the
      agent.

   *  Agent: The device that receives the PoA to sign on behalf of the
      principal with limited features for a pre-defined time.

   *  Resource server: The third party with a server that stores the
      information and credentials entitled to the principal.  It serves
      agents according to subgrants defined in PoAs.

   *  Signatory registry: A database system where PoAs and system-
      related metadata are stored.  It can serve as a trusted third
      party in certifying and verifying PoA.  This component is
      optional.

   The principal generates the PoA in advance to entitle an agent to
   autonomously execute tasks in the absence of the principal.  The PoA
   is digitally signed by the principal and the agent uses the limited
   features of the principal’s account to execute tasks allowed by the
   PoA.

7.  Related Works

   Fast IDentity Online Alliance (FIDO) [fidospec] defines an automatic
   onboarding protocol for IoT devices.  With the late binding feature
   of this protocol, the IoT platform for the IoT device doesn't need to
   be selected in the early stage of its life cycle and reduces the cost
   and complexity in the supply chain.  FIDO uses a rendezvous server
   for device registration and to find the device owner's location, by
   assuming that the device has an IP connectivity to the rendezvous
   server.  An important feature of FIDO is the tracking of the transfer
   of ownership and the device's late-bound owner throughout the supply

Sreelakshmi, et al.       Expires 22 April 2024                 [Page 9]
Internet-Draft              Abbreviated Title               October 2023

   chain using the ownership voucher.  FIDO Device Onboard-enabled
   Device is configured with required software and hardware along with a
   Restricted Operating Environment (ROE) and a Management Agent, that
   manages the device ownership voucher using the onboarding protocols.
   Another important parameter is the device credentials, it does not
   permanently identify the user and is only used for the purpose of the
   ownership transfer.  FIDO expects that both the manufacturer and the
   owner will change their keys frequently.  The main protocols in FIDO
   onboarding are the Device initialization protocol (DI), Transfer
   Ownership Protocol (TO0), TO1, and TO2.  The function of DI is to
   insert FIDO Device Onboard credentials into the device during the
   manufacturing process.  TO0 is used by the owner to identify itself
   to the rendezvous server, and similarly, TO1 is used by the device to
   identify itself and to interact with the rendezvous server using the
   device ROE.  TO2 is used by the device ROE to contact and interact
   with the owner or device onboarding service.  After TO2 successfully
   completed, the device onboarding credentials except the attestation
   key are replaced by the owner onboarding service.

   [delgation-voucher] approach is similar to the PoA transferable
   parameter approach.  A problem with the extended artifact approach is
   that the pledge should store all the previous delegation vouchers and
   they should attach them during the voucher request step.  If modified
   using the PoA transferable approach, this could be a solution to the
   reselling problem of bootstrapping.

   [t2trg] provides a survey on different standards and protocols for
   onboarding.  Onboarding is referred to by different names as part of
   the initial security setup of devices.  This list of names includes
   bootstrapping, provisioning, enrollment, commissioning,
   initialization, and configuration.  Most approaches rely on an
   external anchor such as a rendezvous server, bootstrap server, chip,
   or QR code.

   The communication protocol [mobileIP] uses a home agent and a foreign
   agent to facilitate mobility.  The home agent provides an anchor
   point for connectivity, while a mobile node can register with a
   foreign agent to get seamless connectivity at the visited network.
   This allows the user to move between different networks while having
   both the home and visitor IP addresses.  However, this is primarily
   to obtain internet access, not to onboard a local realm.

Sreelakshmi, et al.       Expires 22 April 2024                [Page 10]
Internet-Draft              Abbreviated Title               October 2023

   [nordmark-iotops] recognizes the need for an effective onboarding
   system in both network and application layers.  This approach doesn't
   require much dependency on the manufacturer and the manufacturer's
   certificates.  They define the flexibility of devices that are not
   resource-constrained such as Raspberry Pi and larger.  The use of
   large smart devices enables executing functions that are not
   envisioned during their manufacturing.

   PoA based authorization can be added as a new grant type for OAuth
   protocol, which introduces a new role "principal" who controls the
   client, and enables the client to access resources through the OAuth
   authorization server on behalf of the principal, even if the
   principal is not available online [poa-oauth-grant-type].

   PoA-based authorization is an industrial authorization technique for
   CPS devices that is designed with different cryptographic algorithms
   and is similar work as the proxy signature with warrant
   [proxy-signature].  The proxy signature is a significant security
   cryptographic algorithm that strengthens its security by patching
   newer security loopholes.  The main differences are seen in the
   applicability of the technique and the design methodology.  In proxy
   signature, the agent or proxy signer is required to perform several
   cryptographic calculations to sign a message, as described in the
   warrant on behalf of the principal.  PoA can be seen as a more
   industry-oriented technique, where the device acts/works on behalf of
   the principal as described in the PoA.  Here, the agent is only
   required to verify and forward the PoA (received from the principal)
   to the resource owner and provide its strong identity, to obtain the
   resources on behalf of the principal.

   The different techniques mentioned above use a delegation-based
   authorization model for security, which relies on centralized servers
   or complex cryptographic algorithms, limiting their flexibility in
   the onboarding process.  The PoA-based authorization technique, which
   does not rely on a centralized server and employs an industry-
   friendly PoA structure, enables a reliable and flexible onboarding
   process.

8.  Security Considerations

   The security of the entire onboarding process relies on issues with
   security in different phases such as manufacturing, supply chain,
   bootstrapping, and application.  The characteristics of these phases
   differ depending on the onboarding approach.  The following are the
   different approaches:

Sreelakshmi, et al.       Expires 22 April 2024                [Page 11]
Internet-Draft              Abbreviated Title               October 2023

   *  Use hardware manufacturer certificates.  Using the manufacturing
      certificate, this method authenticates the device.  However, there
      is no option to authorize the target network, which prevents the
      device from being onboarded to fraudulent networks.

   *  Tracking ownership transfers throughout the supply chain.  This
      secure late binding to the management system/controller allows the
      controller to trust the device and ensure that it is not
      compromised during the supply chain transmission.

   *  Imprinting/configuring for/by the owner of the device.  This
      approach configures the device for its future owner/controller by
      imprinting the future owner's identity.  This method enables the
      device to only onboard to the trusted owner/controller.  However,
      it requires the manufacturer to build devices with customized
      features based on their future owner/controller.

   *  PoA based onboarding.  This decentralized approach employs the
      subgranting-based authorization technique, which enables the
      controller to grant authorization to the subcontractor (principal)
      and the device to obtain authorization from the subcontractor.
      The PoA approach compliments the above three approaches with the
      use of digitally signed PoAs that enable mutual authorization
      between the device and the controller, and the use of PoA to keep
      track of the ownership transfer, which is submitted to the
      controller on demand.

8.1.  Attacks out of scope

   The payload data in the form of PoAs is immutable and protected by
   cryptographic signatures.  Therefore, integrity threats like replay,
   message insertion, modification, and man in the middle are out of
   scope.

8.2.  Attacks in scope

   Confidentiality threats like eavesdropping exist when PoAs are sent
   as clear data.  However, this can be resolved by e2e encryption.  For
   authentication, the PoAs rely on strong unique identities, e.g., the
   identity of a must be verified when it turns up with a PoA where it
   obtains some authorized credentials based on its public key.  In some
   cases, a private key can serve to prove identity, but it should be
   noted that a private key can be stolen (Identity theft).  This can be
   resolved by coupling the identity uniquely to the device, e.g., a
   device hash, X.509 certificate–DevID, Device Identifier Composition
   Engine [DICE], Compound Device Identifier [CDI], public key.  The
   protocol interface for receiving and processing PoAs is susceptible
   to denial-of-service attacks, where potential overload attacks using

Sreelakshmi, et al.       Expires 22 April 2024                [Page 12]
Internet-Draft              Abbreviated Title               October 2023

   meaningless or unacceptable PoAs could be issued.  Possible
   resolutions to this threat will be addressed in future versions of
   this draft.

   We will conform to prefer industry standards e.g., as described in
   [draft-moran-iot-nets-01]

9.  References

9.1.  Normative References

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

9.2.  Informative References

   [NIST]     National Institute of Standards and Technology, "Trusted
              Internet of Things (IoT) device network-layer onboarding
              and lifecycle management (draft) No. NIST CSWP 16 ipd",
              2020.

   [Intel]    INTEL, "Intel® secure device onboard,” More secure,
              automated IoT device onboarding in seconds, pp. 1–4",
              2017.

   [t2trg]    Internet Engineering Task Force, "draft-irtf-t2trg-secure-
              bootstrapping-02", 2022.

   [nordmark-iotops]
              Internet Engineering Task Force, "draft-nordmark-iotops-
              onboarding-00", 2021.

   [fidospec] Fido Alliance, "Fast Identity Online Alliance, "FIDO
              Device Onboard Specification"", 2021,
              <https://fidoalliance.org/specifications/download-iot-
              specifications/>.

   [mobileIP] "IP mobility support. No. rfc2002", 1996.

Sreelakshmi, et al.       Expires 22 April 2024                [Page 13]
Internet-Draft              Abbreviated Title               October 2023

   [proxy-signature]
              "Proxy signatures: Delegation of the power to sign
              messages,” IEICE transactions on fundamentals of
              electronics, communications and computer sciences, vol.
              79, no. 9, pp.  1338–1354", 1996.

   [draft-moran-iot-nets-01]
              Internet Engineering Task Force, "A summary of security-
              enabling technologies for IoT devices", 12062022.

   [poa-oauth-grant-type]
              Internet Engineering Task Force, "draft-vattaparambil-
              oauth-poa-grant-type-00", 11032023.

   [eap-onboarding]
              Internet Engineering Task Force, "draft-richardson-emu-
              eap-onboarding-02", 4022023.

   [delgation-voucher]
              Internet Engineering Task Force, "draft-ietf-anima-
              voucher-delegation-02", 7072023.

Contributors

   Thanks to all of the contributors.

Authors' Addresses

   Sreelakshmi
   Lulea University of Technology
   SE-97187 Lulea
   Sweden
   Email: srevat@ltu.se

   Olov
   Lulea University of Technology
   SE-97187 Lulea
   Sweden
   Email: olov.schelen@ltu.se

   Ulf
   Lulea University of Technology
   SE-97187 Lulea
   Sweden
   Email: ulf.bodin@ltu.se

Sreelakshmi, et al.       Expires 22 April 2024                [Page 14]