Internet Engineering Task Force S. V. Sudarsan Internet-Draft O. Schelen Intended status: Informational U. Bodin Expires: 8 September 2023 Lulea University of Technology 7 March 2023 draft-vattaparambil-oauth-poa-grant-type-00 draft-vattaparambil-oauth-poa-grant-type-00 Abstract This draft proposes a new grant type for OAuth based on PoA-based authorization, that introduces a new role "principal" who controls the client, and enables the client to access resources owned by the resource owner via OAuth authorization server, on behalf of the principal, even if the principal is not online. 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 8 September 2023. 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 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. Sudarsan, et al. Expires 8 September 2023 [Page 1] Internet-Draft Abbreviated Title March 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 4 2.1. PoA based authorization . . . . . . . . . . . . . . . . . 5 2.1.1. PoA generation for the client/agent . . . . . . . . . 6 2.2. Security considerations . . . . . . . . . . . . . . . . . 9 2.2.1. Spoofing . . . . . . . . . . . . . . . . . . . . . . 9 2.2.2. Sniffing/eavesdropping the PoA and MITM . . . . . . . 9 2.2.3. Denial of Service . . . . . . . . . . . . . . . . . . 9 2.2.4. Cross Site Scripting (XSS) or Code Injection . . . . 10 3. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Normative References . . . . . . . . . . . . . . . . . . 10 3.2. Informative References . . . . . . . . . . . . . . . . . 10 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction This OAuth 2.0 [OAuth] protocol grant type extension makes the OAuth applicable in a scenario where a principal (e.g., a user) who controls the OAuth client delegates their power to the client which allows the client to access resources from the resource owner on behalf of the user. The subgranting of power from the principal to the client is made possible using the self-contained PoA-based authorization. PoA-based authorization is a generic authorization technique used to authorize devices to access protected resources on behalf of the principal (user). Here, the client includes autonomous/semi-autonomous devices with sufficient resources to take part in the authorization process. PoA adds the following critical properties to OAuth: * The client can work on behalf of the principal, even if the principal is not online. * A possible separation of the principal and the resource owner. * The client can send the PoA to another client using the multi- level authorization feature of PoA-based authorization. Sudarsan, et al. Expires 8 September 2023 [Page 2] Internet-Draft Abbreviated Title March 2023 For example, consider a scenario where a user is occupied with some other tasks and requires data/resources from a third-party web server (resource owner). The user who owns an autonomous/semi-autonomous CPS/IoT device (client) can authorize/delegate their power to their trusted device. This allows the device to request the required resources and act/work on behalf of the principal. This can be achieved with the extension of OAuth grant types with the decentralized PoA-based authorization. The feature of multi-level authorization allows the agent to transfer the PoA to another agent. The parameter transferable in the PoA indicates the allowed number of transfers of the PoA. The first agent sends a different PoA with the root PoA inside to the second agent, by signing the secondary PoA with its private key. The signing along with the generation of secondary PoAs continues with the number of agents in the trust chain. The secondary PoAs can be traced back to the root PoA, which allows the resource owner to identify different agents in the trust chain. The operational assumptions for using this authorization grant type are: * There is established mutual trust between the principal and the client (i.e., PoAs are only assigned to trusted parties). * The client is an autonomous or semi-autonomous device with sufficient resources to perform authorization. * The identity of the principal and client must be possible to verify. Whether this is based on a strong identity or only on public-private key challenges depend on the application. While other approaches use lightweight messages, the PoA is an immutable signed message and assumes that the clients are typically not resource-constrained. A detailed explanation of PoA-based authorization and its differences between OAuth and other similar authorization standards can be found here (add information draft link here). 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. Sudarsan, et al. Expires 8 September 2023 [Page 3] Internet-Draft Abbreviated Title March 2023 1.2. Roles There are five roles in the proposed grant type. The role principal is an addition to the existing roles of OAuth protocol. resource owner An entity capable of granting access to a protected resource. When a resource owner is a person, it is referred to as an end- user. resource server The server hosting the protected resources, is capable of accepting and responding to protected resource requests using access tokens. client or Agent An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices). It receives the PoA from the principal and requests the protected resources from the resource owner via the authorization server on behalf of the principal. authorization server The server issues access tokens to the client/agent after successfully authenticating the resource owner and obtaining authorization. principal An entity that generates, signs, and sends the PoA to the client/ agent. It may or may not be the same as the resource owner. In many PoA cases, it is considered to be a different entity. 2. Obtaining Authorization OAuth defines four grant types: authorization code, implicit, resource owner password credentials, and client credentials. It also provides an extension mechanism for defining additional grant types. The proposed newer grant type is PoA-based authorization. Sudarsan, et al. Expires 8 September 2023 [Page 4] Internet-Draft Abbreviated Title March 2023 2.1. PoA based authorization PoA-based authorization is used in a scenario, where the principal (user) requires its trusted client/agent to access resources owned by the resource owner (may be different from the principal, based on already established trust relation between the principal and the resource owner) on behalf of the principal, even if the principal is not online. PoA-based authorization adds the principal role to the OAuth protocol [OAuth]. Figure 1 shows the PoA-based OAuth grant type. +---------+ | | |Principal| | | +---------+ | ^ | | (A) (H) | | v | +---------+ +--------------+ | | | | | | | | | |--(B)--PoA,Authentication->| Resource | | | | Owner | | |<-(C)-Agent/client code----| | | | | | | Client | +--------------+ | or | +--------------+ | Agent | | | | |--(D)-Agent/client code--->| | | | |Authorization | | |<-(E)----Access token------| Server | | | | | +---------+ +--------------+ | ^ | | (F) (G) | | v | +---------+ | | | Resource| | Server | | | +---------+ Sudarsan, et al. Expires 8 September 2023 [Page 5] Internet-Draft Abbreviated Title March 2023 Figure 1: Protocol flow of PoA based OAuth grant type The flow illustrated in Figure 1 includes the following steps: (A) PoA is generated by the Principal and is sent to his/her trusted client. This allows the client to act/work on behalf of the principal. The structure of the PoA is detailed in section Section 2.1.1.1 (B) Client requests the authorization code from the resource owner by providing the PoA from the principal. (C) Resource owner issues the authorization code upon verification to the client. This assumes that mutual trust has been established between the resource owner and the principal. (D) The client requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step. (E) The authorization server authenticates the client and validates the authorization code. If valid, the authorization server responds with an access token and, optionally, a refresh token. (F) Client sends the access token to the resource server to obtain the protected resources on behalf of the principal. (G) Resource server verifies the access token and provides the protected resources to the client. (H) Client may or may not send a report (e.g., log details) on the work back to the principal. 2.1.1. PoA generation for the client/agent 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. PoA can be sent in clear text format or compressed binary format (to be defined). 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. Sudarsan, et al. Expires 8 September 2023 [Page 6] Internet-Draft Abbreviated Title March 2023 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. 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. Sudarsan, et al. Expires 8 September 2023 [Page 7] Internet-Draft Abbreviated Title March 2023 2.1.1.2. PoA interpretation PoA is interpreted whenever the recipient receives the PoA. This can be done using a third-party centralized server, where the interpretation can be performed, which is a similar approach to a public key certificate authority. Another approach is to enable PoA interpretation at every entity point in the PoA-based authorization. This can be achieved by downloading a common library [PoAlibrary] to encode and decode the PoA. This is a similar approach to for example PGP. 2.1.1.3. Authorization Request This specification adds a new OAuth endpoint: the client authorization endpoint. This is different from the OAuth authorization endpoint defined in [OAuth]. Here, the client constructs the request URI by including the "poa" parameter along with the other parameters as defined in OAuth specification to the query component of the authorization endpoint URI using the "application/x-www-form-urlencoded". response_type REQUIRED. Value MUST be set to "code". client_id REQUIRED. The client identifier. poa REQUIRED. The poa as described in the previous section Section 2.1.1.1 redirect_uri OPTIONAL. As described in OAuth spec. scope OPTIONAL. The scope of the access request. state RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server validates the request including the "poa", to ensure that all required parameters are present and valid. If the request is valid, the authorization server authenticates the resource owner and obtains an authorization decision (e.g., by asking the resource owner or by establishing approval via other means). 2.1.1.4. Authorization Response If the resource owner grants the access request, the authorization server issues an authorization code and delivers it to the client same as the OAuth specification. Sudarsan, et al. Expires 8 September 2023 [Page 8] Internet-Draft Abbreviated Title March 2023 2.1.1.4.1. Error Response If the request fails due to a missing parameter in the PoA, invalid time, or any suspicious parameters in the PoA, the client can reject the PoA and send an error response back to the principal. In the case of multi-level authorization, the agent in the trust chain can send the error response back to the principal as well as to the agent before. If the resource owner fails to verify the PoA, the resource owner can inform and ask the agent or principal for more data for verification. 2.1.1.5. Access Token Request and response Access token request and response between the roles authorization server and the client is done according to the Oauth specification. 2.1.1.6. Send a report back to principal This is an optional step, where the client can send a report (e.g., log details) to the principal on the work done. 2.2. Security considerations 2.2.1. Spoofing Spoofing is not a threat in the proposed model. This is because the PoA is digitally signed using a standard public key approach and there are public keys inside the PoA to identify the principals and agents. Hence, even when the attacker sends a poa signed with his/ her private key, the agent checks the public key and rejects the poa because it is not part of the agent's trusted public keys. 2.2.2. Sniffing/eavesdropping the PoA and MITM The PoA that is sent from principal to agent can be eavesdropped on. Even though the data inside the PoA may not be sensitive, it's recommended to use TLS for better security and to eliminate privacy attacks. This is the same for the Man-In-The-Middle (MITM) attack. 2.2.3. Denial of Service An external agent interrupts the data flowing across the trust boundary in either direction. DoS is mitigated or can decrease the impact by making the attacker consume more of his resources than yours to launch the attack. Make the attacker reply using information from previous message exchanges, to prove they can receive data from you [rfc3552]. Individual targeted DoS attacks is difficult to prevent in this design. Sudarsan, et al. Expires 8 September 2023 [Page 9] Internet-Draft Abbreviated Title March 2023 2.2.4. Cross Site Scripting (XSS) or Code Injection While downloading the public library to generate or validate the PoA, the entity might download a malicious one instead of the legitimate lib. This could be prevented with input sanitization or filtering techniques. 3. References 3.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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 3.2. Informative References [OAuth] Internet Engineering Task Force, "The OAuth 2.0 authorization framework", 2012. [PoAlibrary] TestPyPI, "https://test.pypi.org/project/poalib-srevat/0.0.1/", 2022. [rfc3552] Internet Engineering Task Force, "Guidelines for Writing RFC Text on Security Considerations", 2003. Contributors Thanks to all of the contributors. Authors' Addresses Sreelakshmi Vattaparambil Sudarsan Lulea University of Technology SE-97187 Lulea Sweden Email: srevat@ltu.se Sudarsan, et al. Expires 8 September 2023 [Page 10] Internet-Draft Abbreviated Title March 2023 Olov Schelen Lulea University of Technology SE-97187 Lulea Sweden Email: olov.schelen@ltu.se Ulf Bodin Lulea University of Technology SE-97187 Lulea Sweden Email: ulf.bodin@ltu.se Sudarsan, et al. Expires 8 September 2023 [Page 11]