| Internet-Draft | Abbreviated Title | October 2022 |
| Sreelakshmi, et al. | Expires 7 April 2023 | [Page] |
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.¶
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 (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of 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.¶
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.¶
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.¶
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.¶
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:¶
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.¶
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 prominent delegation-based authorization models are as follows:¶
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].¶
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.¶
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 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:¶
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.¶
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.¶
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:¶
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)--| |
+---------+ +-----------+ +-----+
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.¶
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:¶
[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.¶
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.¶
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.¶
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:¶
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.¶
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]¶
Thanks to all of the contributors.¶