ace Sreelakshmi Internet-Draft Olov Intended status: Informational Ulf Expires: 7 January 2024 Lulea University of Technology 6 July 2023 PoA based Device Registration in ACE framework draft-vattaparambil-ace-wg-poa-device-reg-00 Abstract This draft proposes an extension to the ACE framework with the Power of Attorney (PoA) based authorization. This is proposed following the identification of mutual authorization problem between the client and the AS in the ACE framework, which demands secure registration of the client to the AS and a mechanism for the client to validate the AS. The proposed system adds a new entity referred as the Device Owner to the ACE framework that delegates the client device and provides information (in a PoA) regarding the AS to which the client is intended to communicate with. 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 January 2024. Copyright Notice 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 Sreelakshmi, et al. Expires 7 January 2024 [Page 1] Internet-Draft Abbreviated Title July 2023 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. Problem Identification . . . . . . . . . . . . . . . . . . . 3 3. Usecase Scenario . . . . . . . . . . . . . . . . . . . . . . 5 4. List of solutions . . . . . . . . . . . . . . . . . . . . . . 5 4.1. (1) Client Registration Problem - Solutions . . . . . . . 5 4.2. (2) AS Validation Problem - Solutions . . . . . . . . . . 5 5. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6 6. Further Use of PoA . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction In ACE framework, the client and the Authorization Server (AS) requires a mechanism to share the keying materials for the secure channel establishment between them. This problem can be seen as the registration, enrolling or onboarding issue in the ACE framework. Following this, there is a need for (1) the client to register and authorize with the Authorization Server (AS) and (2) the client to validate the AS. PoA based authorization in its base form provides subgranting/delegation based authorization, that enables the Device Owner (principal) to delegate its limited authority to its trusted client (device/agent), so that the client can work on behalf of the Device Owner (DO). Using PoA based authorization, the client obtains information on the AS from a trusted party (Device Owner) so that it can compare the AS identification (obtained from the Resource Server (RS)) with the one provided by the DO before sending the access token request. With a proper client registration and validation model, the client can authorize the AS when it receives the AS URI from the Resource Server (RS) and ensure that the client is registering to the right AS, which is in charge of the resource hosted at the RS and share the credentials over the secure channel. In this draft, we integrate PoA based authorization with the ACE framework to register the client with the AS. Following are the different entities part of the proposed system: Sreelakshmi, et al. Expires 7 January 2024 [Page 2] Internet-Draft Abbreviated Title July 2023 * Device Owner: The owner of the client (device) who generates the PoA for the client. This entity is same as the Principal entity in the PoA based authorization. * Client: Client is the device that requests resources from the RS through AS. * Authorization Server : AS is the entity that generates access tokens for the client. * Resource Server : RS hosts resources and provides them upon client request using access tokens from the AS. This document defines the use of PoA based authorization for the Client Registration in ACE framework. More information on PoA based authorization can be found in this link: https://datatracker.ietf.org/doc/draft-vattaparambil-positioning-of- poa/ 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. Problem Identification RFC 9200 [ACE] defines the ACE framework used for authorization in constrained environments. The main entities involved in this framework are the Client, AS, and the RS, where the Client and RS can be of large numbers and may be resource constrained. There are things that are considered out of the scope of this specification and are deliberately left open for future extensions. In this document, we focus on the Client Registration and the AS Validation issues, that are left open in the ACE framework. In section 3.1 of RFC 9202, communication between the client and the AS is defined. Here, it is defined that the client and the AS MUST establish a secure communication channel between them and ensure the security requirements as explained in section 6.5 (C-AS) in RFC 9200. DTLS profile assumes that the keying material to establish the secure communication channel is either obtained by manual configuration or through an automated provisioning process. It mentions that the client is expected to register with the AS before requesting the access token. According to RFC 9200 (Section 4), this can be seen as Client Registration process (bootstrapping, onboarding, or enrolling) Sreelakshmi, et al. Expires 7 January 2024 [Page 3] Internet-Draft Abbreviated Title July 2023 where the client and the AS exchange credentials and configuration parameters. This means that both the client and AS requires a secure model to exchange the keying material and credentials that is required for the secure channel establishment between them. Later in Section 5.8.2, it is mentioned that the AS requires prior knowledge of the client as well as the RS, which can be achieved for example with the Dynamic Client Registration Protocol Exchange [registration]. This problem can be referred as the (1) Client Registration Problem. The importance of this can be shown using the example scenario of the access token request from the client to the AS in Raw Public Key (RPK) mode from Section 3.2.2 of RFC 9202. Here, the client uses the req_cnf parameter that specifies its raw public key or a unique identifier for a public key. In the access token provided by the AS, the rs_cnf parameter specifies the public key of the resource server that the client uses to set up a DTLS channel with the RS. Here, if the client does not have the keying material belonging to the public key, the client can send an access token request to the AS, with its RPK in the req_cnf. If the AS specifies a public key in response that the client does not have, the client should re-register with the AS, and this is considered out of scope in the specification. The basic protocol flow diagram of ACE framework begins with the client requesting an access token from the AS. However, there is another step done by the client before requesting the access token, which is explained in section 5.1 of RFC 9200. In this step the client sends an unauthorized resource request message to the RS to obtain information about the AS to request an access token in later steps. Upon receiving the Unauthorized resource request message from the client, the RS provides AS URI to the client. The client uses the AS URI to identify the AS that it is intended to communicate with and request an access token (in step A) Token request). This is later explained in the CoAP-DTLS profile for the ACE framework [DTLS] as part of the protocol flow (Section 2). Complementing to this, in the ACE pub-sub profile it is mentioned that the broker MAY send the address of the AS in the “AS” parameter as a response to the unauthorized resource request message. However, there is no mechanism for the client to validate the AS authorization; which means the client MUST be able to determine if the AS is authorized to issue access tokens for a specific RS. In Section 5.1 of RFC 9200, it is mentioned that this can be solved by the Client asking its owner if this AS is authorized for this RS or querying a secure service provided by the client owner. In Section 6.5 of RFC 9200, it is mentioned that it can be done through preconfigured lists or using an online lookup mechanism. This problem can be referred as (2) AS Validation Problem. Sreelakshmi, et al. Expires 7 January 2024 [Page 4] Internet-Draft Abbreviated Title July 2023 3. Usecase Scenario The two different problems can be explained in the context of a real world scenario. Consider the mining station usecase, where Alice is a trusted subcontractor and owner smart trucks that she wants to use for accessing mining related data from the mining station. Here, Alice is the DO, smart truck is the client, mining station is the RS. Problem (1) can be detailed as the truck and the AS has to exchange keying materials or credentials to establish a secure communication channel between them. This raises the AS registration problem. With the proper registration of the smart truck with the AS, the AS can identify the truck for further communication. For the truck to identify the right AS, it can send an initial resource request message to the mining station (RS), to obtain the AS URI from the RS. However, how the truck validates and connect to the right AS is not yet defined and raises the (2) AS validation problem. 4. List of solutions The following are the multiple existing IETF solutions that could potentially address the problems: 4.1. (1) Client Registration Problem - Solutions * Dynamic Client Registration: Client device can be registered to the AS using the Dynamic Client Registration Approach [registration] used in OAuth. Here, the client submits its credentials to the AS. Following this, the AS registers the client and send back client secret and other metadata to the client. * Delegation of Access Rights: Here, the DO delegated the client to access resources on behalf of the DO by providing the client with the credentials needed for the client registration process. The DO can send the client credentials in a token to the client by assuming that there is a pre-established trust between the client and the AS [OAuth]. 4.2. (2) AS Validation Problem - Solutions * Client asking the DO: Upon receiving the AS identification (AS URI) from the RS, client asks its owner if this AS is authorized for this RS. Here, the DO can provide the identity of the right AS using the Delegation of Access Rights approach that is used for the Client registration (mentioned in the above subsection). * Online lookup mechanism: This refers to querying a secure service provided by the DO to validate the AS URI provided by the RS. Sreelakshmi, et al. Expires 7 January 2024 [Page 5] Internet-Draft Abbreviated Title July 2023 However, all of these solutions requires that the RS and client can query another online entity when connecting with each other. 5. Proposed Solution This document proposes an extension to the ACE framework based on the PoA based authorization technique. PoA based authorization is a delegation based authorization technique that enables the users (principals) to delegate or subgrant their authority to their trusted devices (agents) for a limited period of time. This enables the devices to work/act on behalf of the user, even if the user is offline. The different entities part of the proposed model based on PoA based authorization are the Client, RS, AS, and the DO. DO is the new entity added to the ACE framework as part of this solution. It is assumed that there is a pre-established trust (e.g., using TLS certificates) between the DO and the AS. A motivation for this is that the DO has large number of devices and typically an AS also supports a large number of RSs. The main properties of DO are: * DO is a different entity and not same as RS or RO in OAuth. * Generates the PoA with information regarding the DO, client, and the AS. * Send the PoA to the client thus delegating the client to act/work on behalf of the DO. * Similar to the requesting party in UMA [UMA] . This document defines the integration of PoA based authorization framework with the ACE framework to address the above-identified problems, which are: * (1) Client Registration Problem * (2) AS Validation Problem Extension of ACE with PoA based authorization shows how the client can be registered to the AS using the PoA. Protocol flow diagram for the extended ACE framework with the PoA based authorization is shown in Figure 1. Sreelakshmi, et al. Expires 7 January 2024 [Page 6] Internet-Draft Abbreviated Title July 2023 DO Client AS RS | | | | | | | | +----------------+ | | | |1.PoA Generation| | | | +----------------+ | | | | 2.PoA | | | |------------>| | | | | | | | | 3.Unauth. Initial Req. | | |------------------------------->| | | | | | | 4.AS URI | | |<-------------------------------| | | | | | +---------------+ | | | |5.AS Validation| | | | +---------------+ | | | | | | | | 6.PoA + reg.req| | | |--------------->| | | | | | | | +---------------------+ | | | |7.Client Registration| | | | +---------------------+ | | | | | | | 8.Client Secret| | | |<---------------| | | | | | | |9.Sec.ChannelEst| | | |<-------------->| | | | | | Figure 1: Protocol flow of PoA based ACE Extension The protocol flow begins with the new entity DO generating the PoA. The PoA is the core part of the PoA based authorization. PoA contains identification data about the DO, Client, and the AS along with other metadata. This can be public keys or other identifiers that can uniquely identify the different entities that are involved in the authorization process. The important information that is part of PoA which is given focus in this document is the AS identification information. The DO includes information regarding the trusted AS in the PoA, that can be used by the client to register itself to the AS in the future steps. In this case, the PoA is a CBOR token that is signed using the private key of the DO and is sent to the client. Sreelakshmi, et al. Expires 7 January 2024 [Page 7] Internet-Draft Abbreviated Title July 2023 Once the PoA is issued for the Client for the Client Registration Process, it can be used to validate the AS and determine if the AS is authorized to provide access tokens for the specific RS using the information carried in the PoA. This can be addressed in two different ways: * Client sends Unauthorized Resource Request (Section 5.2 of RFC 9200) to the RS and obtains AS URI. Compare the AS URI with information regarding AS received from the DO inside the PoA. After successful validation of the AS info, connect (register) with the AS. * Use the AS info in the PoA received from the DO to connect with the AS. Unauthorized Resource Request Step is not required in this case. According to the first case, upon receiving the PoA from the DO, the client connect with the RS by sending an initial unauthorized resource request as explained in Section 5.2 of RFC 9200. RS denies the request and respond back with the address of its AS. Client validates the AS by fetching the AS info from the PoA and comparing it with the AS URI received from the RS. Upon successful AS identification, the client sends a client registration request to the AS along with the PoA. AS responds back with the client credentials response that includes: * Client Secret that uniquely identifies the client. * Client credentials generated as part of the client registration process. Protection of the communication flow in the proposed model can be done using DTLS or OSCORE over CoAP. 6. Further Use of PoA If we consider there can be n number of ASs in the authorization system. There may be an AS owner (ASO) governing several ASs. PoA can be used in this situation to delegate some authority from the ASO to each AS. Since the ASO is an entity that owns the AS devices it resembles the hierarchy we have between DO and C. So based on a pre- established trust relation between DO and ASO, multiple Cs and ASes can be handled by PoA in a scalable way. 7. References 7.1. Normative References Sreelakshmi, et al. Expires 7 January 2024 [Page 8] Internet-Draft Abbreviated Title July 2023 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 7.2. Informative References [ACE] Internet Engineering Task Force, "Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)", 2022. [DTLS] Internet Engineering Task Force, "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", 2022. [registration] Internet Engineering Task Force, "OAuth 2.0 Dynamic Client Registration Protocol", 2015. [OAuth] Internet Engineering Task Force, "The OAuth 2.0 authorization framework", 2012. [UMA] Internet Engineering Task Force, "User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization-12", 2019. 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 Sreelakshmi, et al. Expires 7 January 2024 [Page 9] Internet-Draft Abbreviated Title July 2023 Ulf Lulea University of Technology SE-97187 Lulea Sweden Email: ulf.bodin@ltu.se Sreelakshmi, et al. Expires 7 January 2024 [Page 10]