Internet DRAFT - draft-vattaparambil-oauth-poa-grant-type
draft-vattaparambil-oauth-poa-grant-type
Internet Engineering Task Force S. V. Sudarsan
Internet-Draft O. Schelen
Intended status: Informational U. Bodin
Expires: 20 April 2024 Lulea University of Technology
18 October 2023
OAuth-PoA Grant Type
draft-vattaparambil-oauth-poa-grant-type-01
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 20 April 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
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 20 April 2024 [Page 1]
Internet-Draft Abbreviated Title October 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 . . . . . . . . . . . . . . . . . 4
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 . . . . 9
3. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Normative References . . . . . . . . . . . . . . . . . . 9
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 20 April 2024 [Page 2]
Internet-Draft Abbreviated Title October 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 20 April 2024 [Page 3]
Internet-Draft Abbreviated Title October 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
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
Sudarsan, et al. Expires 20 April 2024 [Page 4]
Internet-Draft Abbreviated Title October 2023
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
Sudarsan, et al. Expires 20 April 2024 [Page 5]
Internet-Draft Abbreviated Title October 2023
(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 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.
Sudarsan, et al. Expires 20 April 2024 [Page 6]
Internet-Draft Abbreviated Title October 2023
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.
Sudarsan, et al. Expires 20 April 2024 [Page 7]
Internet-Draft Abbreviated Title October 2023
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.
Sudarsan, et al. Expires 20 April 2024 [Page 8]
Internet-Draft Abbreviated Title October 2023
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
Sudarsan, et al. Expires 20 April 2024 [Page 9]
Internet-Draft Abbreviated Title October 2023
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <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, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
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
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 20 April 2024 [Page 10]
