| Internet-Draft | Abbreviated Title | October 2023 |
| Sreelakshmi, et al. | Expires 22 April 2024 | [Page] |
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.¶
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 (c) 2023 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.¶
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 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.¶
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.¶
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 [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.¶
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.¶
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:¶
Figure 1 shows the Protocol flow diagram of the proposed model.¶
+------+ +------+ +------+
| | 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|
| |<-----------------------------------| |
+---------+ +----------+
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.¶
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:¶
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 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.¶
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:¶
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.¶
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 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.¶
[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.¶
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 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 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.¶