Internet DRAFT - draft-vattaparambil-iotops-poa-based-onboarding
draft-vattaparambil-iotops-poa-based-onboarding
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]
