Internet-Draft Abbreviated Title March 2023
Sudarsan, et al. Expires 8 September 2023 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-vattaparambil-oauth-poa-grant-type-00
Published:
Intended Status:
Informational
Expires:
Authors:
S. V. Sudarsan
Lulea University of Technology
O. Schelen
Lulea University of Technology
U. Bodin
Lulea University of Technology

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.

▲

Table of Contents

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:

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:

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.

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.

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 |
            |         |
            +---------+
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.
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.
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.

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.

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, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.

3.2. Informative References

[OAuth]
Internet Engineering Task Force, "The OAuth 2.0 authorization framework", .
[PoAlibrary]
TestPyPI, "https://test.pypi.org/project/poalib-srevat/0.0.1/", .
[rfc3552]
Internet Engineering Task Force, "Guidelines for Writing RFC Text on Security Considerations", .

Contributors

Thanks to all of the contributors.

Authors' Addresses

Sreelakshmi Vattaparambil Sudarsan
Lulea University of Technology
SE-97187 Lulea
Sweden
Olov Schelen
Lulea University of Technology
SE-97187 Lulea
Sweden
Ulf Bodin
Lulea University of Technology
SE-97187 Lulea
Sweden