Internet DRAFT - draft-vattaparambil-irtf-dinrg-poa
draft-vattaparambil-irtf-dinrg-poa
Internet Engineering Task Force Sreelakshmi
Internet-Draft Olov
Intended status: Informational Ulf
Expires: 7 April 2023 Lulea University of Technology
4 October 2022
draft-vattaparambil-irtf-dinrg-poa-00
draft-vattaparambil-irtf-dinrg-poa-00
Abstract
Power of Attorney (PoA) based authorization is a generic and
decentralized subgranting based authorization technique. In this, a
principal can grant limited credibilities for an agent to act on its
behalf for some limited time and context. This can be used for
example with semi autonomous devices to have them act on behalf. PoA
is a self-contained document that a principal sign and directs to an
agent, thereby providing it the power to execute user actions on
behalf of the principal for a predefined time. As an example in this
document we explain Power of Attorney based authorization technique
as a decentralized solution for onboarding devices. Industrial
network layer onboarding demands a technique that is efficient,
scalable, and secure. PoA based onboarding enables users such as
integrators and subcontractors to onboard devices permanently or
temporarily according to terms and requirements set in the PoAs.
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 7 April 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sreelakshmi, et al. Expires 7 April 2023 [Page 1]
Internet-Draft Abbreviated Title October 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Power of Attorney based authorization . . . . . . . . . . . . 4
3. State of the art . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Delegation based authorization techniques . . . . . . . . 4
3.1.1. OAuth . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Proxy signature . . . . . . . . . . . . . . . . . . . 5
3.2. Onboarding basics . . . . . . . . . . . . . . . . . . . . 5
3.3. Problem description . . . . . . . . . . . . . . . . . . . 6
4. Power of Attorney based Onboarding . . . . . . . . . . . . . 6
5. PoA Structure . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Related works . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7.1. Attacks out of scope . . . . . . . . . . . . . . . . . . 12
7.2. Attacks in scope . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Power of Attorney (PoA) based authorization is a completely generic
and decentralized delegation or subgranting authorization technique.
It can be used in situations where the user needs to use a trusted
device to act/work on his/her behalf. This will enable the user to
subgrant their power to the trusted device and enable it to work for
the user especially when he/she is not available. This authorization
technique is based on the traditional legal PoA document, which is
used by people to transfer control of assets to trusted users.
We bring the idea of the legal PoA document into the age of Cyber
Physical Systems (CPS), where humans can instruct their trusted CPS
devices to act on their behalf for a limited time.
Sreelakshmi, et al. Expires 7 April 2023 [Page 2]
Internet-Draft Abbreviated Title October 2022
PoA-based authorization can be used in a wide range of applications,
from day-to-day activities to industrial applications. Some
important properties includes that the model is decentralized, and
the PoA is self-contained. PoAs can be issued in advance and don't
require the principal to be online during the action of the agent.
Also the PoA is time limited and may allow further subgranting in a
maximum number of steps.
In this draft, we use the device onboarding industrial usecase to
demonstrate the features and benefits of PoA based authorization.
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.
PoA based onboarding can secure the device with unique onboarding
credentials during deployment rather than at the time of manufacture.
This authorization technique 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 usecases where devices owned by subcontractors must/
should temporarily (ie., for limited time) be onboarded to an
industrial site while the formal ownership is retained by the
subcontractor. The PoA also ensures the mutual authorization and
authentication between the device and the industrial site onboarding
controller, which ultimately approves the onboarding based on
certificates. In the presented usecase, we establish a trust chain
between the subcontractor, device, and the onboarding component for
automatic onboarding of devices using power of attorney based
authorization technique.
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.
Sreelakshmi, et al. Expires 7 April 2023 [Page 3]
Internet-Draft Abbreviated Title October 2022
2. 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). 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, signs, and sends the PoA to
the agent.
* Agent: The device which receives the PoA to act on behalf of the
principal with limited credentials 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.
3. State of the art
3.1. Delegation based authorization techniques
There are different delegation based authorization techniques that
are important to discuss in relation to PoA based authorization.
Most of them are centralized methods that rely on a trusted
authorization server. Although PoA-based authorization does not rely
on a centralized server, it also does not use distributed ledger
technology. PoA based authorization uses the state of art techniques
as a foundation and builds an authorization technique that will be
useful in a subgranting situation in an industrial ecosystem. Two
Sreelakshmi, et al. Expires 7 April 2023 [Page 4]
Internet-Draft Abbreviated Title October 2022
prominent delegation-based authorization models are as follows:
3.1.1. OAuth
OAuth is a delegation-based authorization technique, which uses a
centralized authorization server that issues access tokens to the
client. This authorizes the client to access protected resources on
behalf of the resource owner. The major tokens used in OAuth are the
authorization grant token and the access token. The authorization
grant represents the resource owner's authorization, it is generated
by the resource owner and provided to the client. The client uses
the authorization grant to obtain the access token from the
authorization server. The access token is used by the client to
communicate with the resource server to obtain the required
resources. The OAuth specification is open for extensions to resolve
challenges. It supports one step of delegation, not fully able to
separate the resource owner (the main operator) from the contractors,
and the devices in an arbitrary number of delegation levels. This
means OAuth includes only the resource owner entity and does not
include the principal (contractor) entity. This means, in OAuth the
person who provides access privileges is the same as the resource
owner (person who owns the resources), there is no separate entity
called the principal (contractor) who uses the agent/client to
request the resources owned by the resource owner [OAuth].
3.1.2. Proxy signature
It is a traditional cryptographic technique that allows a proxy
signer to sign on behalf of the original signer. Here, the original
signer delegates the proxy signer by providing certain credentials,
using which the proxy signer generates a proxy signature to sign on
behalf of the original signer. Original signer can provide the
delegation in different ways such as full delegation, partial
delegation, and delegation by warrant [proxy-signature]. The proxy
signature is a significant security cryptographic algorithm.
However, it has not been adapted to industry oriented technique,
where the device acts/works on behalf of the principal (contractor)
for some limited time. More details are provided in Section 6.
3.2. Onboarding basics
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 supplychain in a short span of time. One
important aspect of onboarding is providing the device with internet
access [nordmark-iotops]. It is defined with different definitions
by different people. Intel zero touch onboarding [Intel] refers it
as an "Automated service that enables a device to be drop-shipped and
Sreelakshmi, et al. Expires 7 April 2023 [Page 5]
Internet-Draft Abbreviated Title October 2022
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". According to NIST guidelines referring the IETF
[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.
3.3. Problem description
Multiple entities, transportation methods, sensitive data sharing,
and other factors make the onboarding process difficult,
necessitating automation and security. Because of the large number
of external devices and the security issues caused by their
communication, device onboarding is considered as an important
process. The main issues in a device lifecycle device onboarding are
device ownership transfer, management of the device after
bootstrapping such as installing required software, its maintenance,
and disposition of the device when transitioning to a new owner.
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.
4. Power of Attorney based Onboarding
This document consider the network layer onboarding and subgranting
the power to onboard from one entity to another in the bootstrapping
stage. The different roles are:
* Subcontractor (Principal): The subcontractor is the device owner,
who obtains the device from the supplychain.
* Device (Agent): The device to be onboarded
Sreelakshmi, et al. Expires 7 April 2023 [Page 6]
Internet-Draft Abbreviated Title October 2022
* Gateway: We assume that all the communication between the IoT
device, subcontractor, and the onboarding controller is through a
secure gateway for better security.
* Onboarding component: Onboards the device to the destination
network
* Certificate Authority (CA): It provides the local cloud compliant
certificate to the device for onboarding.
Figure 1 shows the Protocol flow diagram of the proposed model.
+---------+ +--------+ +-----------+ +-----+
| |---B)->| |-Ca,b)->| | | |
| Subcon | | Device | | Onboarding|---D)->| |
| tractor | |(Agent) |<--F)---| Component | | CA |
| (Princi | +--------+ | | | |
| pal) |<-----------A)-----------| |<--E)--| |
+---------+ +-----------+ +-----+
Figure 1: Protocol flow of PoA based onboarding
* A) Onboarding component sends the PoA1 (PoA generated by the
onboarding component) to the subcontractor through the gateway.
By this, the onboarding component grants authorization to a
specific subcontractor to bootstrap any trusted devices. Before
this step, both entities should be mutually authenticated using
public key certificates.
* B) Subcontractor generates PoA2 and sends it to his/her specific
trusted device. This enables the device to work on behalf of the
subcontractor. This means, the onboarding component that trusts
the subcontractor (through PoA1) implicitly trusts the device. In
this step, the subcontractor may add the complete ownership of the
device's proof-of-chain information to PoA2, if so required (e.g.,
as specified in PoA1).
* Ca) The device sends the PoA2, device hash, and device
bootstrapping credentials to the onboarding component through the
gateway. The device bootstrapping credentials can includes device
identifier (e.g., X.509 certificate-DevID, Device Identifier
Composition Engine [DICE] Compound Device Identifier [CDI], public
key), device private key or csr, Wi-Fi channel that the device
will use (optional), communications protocols (optional) etc.
* Cb) Secure channel establishment using Mutual TLS (MTLS).
Sreelakshmi, et al. Expires 7 April 2023 [Page 7]
Internet-Draft Abbreviated Title October 2022
* D) Onboarding component authorizes the device by verifying the
PoA2 and sends a certificate request using device private key or
csr to the local cloud CA.
* E) The local cloud CA verifies the submitted documents and
generates the a local cloud compliant device certificate and sends
it to the onboarding component.
* F) The network bootstrapping credentials are sent to the device by
the onboarding component via the gateway. This can include
network identifier (e.g., X.509 certificate, Service Set
Identifier [SSID]). The device validates the network by comparing
the network details in the network bootstrapping credentials to
the network details in the digitally signed PoA2. This helps the
device to determine if the target network is authorized to onboard
the device.
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.
5. PoA Structure
The PoAs are self-contained tokens that are structured in JWT format.
The entire PoA in the JWT form is digitally signed by the principal
using his/her private key. The various parameters included in a PoA
are the following:
Principal Public Key
REQUIRED. The public key, which uniquely identifies the principal
who generates the PoA. 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.
Principal Name
OPTIONAL. The human-readable name of the principal, which is
additional information about the principal.
Resource Owner ID
REQUIRED. The unique identifier or the public key of the resource
owner from where the protected resources are granted.
Sreelakshmi, et al. Expires 7 April 2023 [Page 8]
Internet-Draft Abbreviated Title October 2022
Agent Public Key
REQUIRED. The public key, which uniquely identifies the agent who
receives the PoA from the principal. We assume that the agent
public key is generated using a secure public-key algorithm by the
owner. This parameter helps the trusted server to identify the
agent and check whether it is genuine or not.
Agent Name
OPTIONAL. The human-readable name of the agent, which is
additional information about the agent.
Signing Algorithm
OPTIONAL. The name of the signature algorithm used by the
principal to digitally sign the PoA.
Transferable
REQUIRED. It is a positive integer defining how many steps the
PoA can be transferred. Default is 0, which means that it is not
transferable. A PoA can be transferred by including it in another
PoA, 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 is issued by the principal to
the agent.
eat (Expires at)
REQUIRED. The time at which the PoA expires. This parameter is
predefined by the principal in the PoA and the PoA will be invalid
after eat.
Metadata
OPTIONAL. The metadata is associated with the specific
application use-case. This parameter includes different sub-
parameters that add application-specific information to the PoA.
6. Related works
[nordmark-iotops] recognize 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
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.
Sreelakshmi, et al. Expires 7 April 2023 [Page 9]
Internet-Draft Abbreviated Title October 2022
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 supplychain. FIDO uses a rendezvous
server for device registration and to find the device owner location,
by assuming that the device has an IP connectivity to the rendezvous
server. An important feature of FIDO is the tracking of transfer of
ownership and the device's late-bound owner throughout the
supplychain using the ownership voucher.
[t2trg] provides a survey on different standards and protocols for
onboarding. Onboarding is referred using different names as part of
the initial security setup of devices. This list of names include
bootstrapping, provisioning, enrollment, commissioning,
initialization, and configuration. Most approaches rely on an
external anchor such as 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.
PoA-based authorization is an industrial authorization technique for
CPS devices that is designed with different cryptographic algorithms,
is a 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.
Sreelakshmi, et al. Expires 7 April 2023 [Page 10]
Internet-Draft Abbreviated Title October 2022
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, that
does not rely on a centralized server and employs an industry-
friendly PoA structure, enables for a reliable and flexible
onboarding process.
7. 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:
* 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 methods enables the
device to only onboard to the trusted owner/controller. However,
it requires the manufacture to build devices with customized
features based on their future owner/controller.
* PoA based onboarding. This decentralized approach employs the
subgranting based authorization technique, that enables the
controller to grant authorization to the subcontractor (principal)
and the device to obtain authorization from the subcontractor.
PoA approach compliments the above three approaches with the use
of digitally signed PoAs that enables 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.
Sreelakshmi, et al. Expires 7 April 2023 [Page 11]
Internet-Draft Abbreviated Title October 2022
7.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.
7.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 an 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 for proving 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
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]
8. References
8.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>.
8.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.
Sreelakshmi, et al. Expires 7 April 2023 [Page 12]
Internet-Draft Abbreviated Title October 2022
[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.
[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.
[OAuth] Internet Engineering Task Force, "The OAuth 2.0
authorization framework", 2012.
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
Sreelakshmi, et al. Expires 7 April 2023 [Page 13]
Internet-Draft Abbreviated Title October 2022
Email: olov.schelen@ltu.se
Ulf
Lulea University of Technology
SE-97187 Lulea
Sweden
Email: ulf.bodin@ltu.se
Sreelakshmi, et al. Expires 7 April 2023 [Page 14]
