]> Lulea University of Technology

Lulea 97187 Sweden srevat@ltu.se

Lulea University of Technology

Lulea 97187 Sweden olov.schelen@ltu.se

Lulea University of Technology

Lulea 97187 Sweden ulf.bodin@ltu.se

General ace authorization registration constrained devices 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.

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:

• 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/

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 when, and only when, they appear in all capitals, as shown here.

Problem Identification RFC 9200 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) 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 . 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 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.

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 (see Section (PoA Structure)).
• Send the PoA to the client thus delegating the client to act/work on behalf of the DO.

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.

Protocol flow of PoA based ACE Extension | | | | | | | | | 3.Unauth. Initial Req. | | |------------------------------->| | | | | | | 4.AS URI | | |<-------------------------------| | | | | | +---------------+ | | | |5.AS Validation| | | | +---------------+ | | | | | | | | 6.PoA + reg.req| | | |--------------->| | | | | | | | +---------------------+ | | | |7.Client Registration| | | | +---------------------+ | | | | | | | 8.Client Secret| | | |<---------------| | | | | | | |9.Sec.ChannelEst| | | |<-------------->| | | | | | ]]>

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. Detailed structure of the PoA is in Section (PoA Structure). 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.

Further Use of PoA If we consider AS as a constrained device, there can be n number of ASs in the authorization system. PoA can be used in this situation to delegate the authority of the Authorization Server Owner (ASO) to a single AS. Here, ASO is an entity that owns the AS devices and is up in the hierarchy same as the DO.

References Normative References Informative References Internet Engineering Task Force Internet Engineering Task Force Internet Engineering Task Force

Contributors Thanks to all of the contributors.