]> 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 Internet Engineering Task Force PoA based authorization OAuth 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.

Introduction This OAuth 2.0 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.

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

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.

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

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.

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.

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 . Figure 1 shows the PoA-based OAuth grant type.

Protocol flow of PoA based OAuth grant type | Resource | | | | Owner | | |<-(C)-Agent/client code----| | | | | | | Client | +--------------+ | or | +--------------+ | Agent | | | | |--(D)-Agent/client code--->| | | | |Authorization | | |<-(E)----Access token------| Server | | | | | +---------+ +--------------+ | ^ | | (F) (G) | | v | +---------+ | | | Resource| | Server | | | +---------+ ]]>

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

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

PoA generation for the client/agent

The PoAs are self-contained tokens that are structured in JWT format. The PoA can be in both JSON or CBOR form and 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.

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 to encode and decode the PoA. This is a similar approach to for example PGP.

Authorization Request This specification adds a new OAuth endpoint: the client authorization endpoint. This is different from the OAuth authorization endpoint defined in . 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

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

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.

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.

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.

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.

Security considerations

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.

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.

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 . Individual targeted DoS attacks is difficult to prevent in this design.

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.

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

Contributors Thanks to all of the contributors.