Skip to main content

OAuth-PoA Grant Type
draft-vattaparambil-oauth-poa-grant-type-01

Document Type Active Internet-Draft (individual)
Authors Sreelakshmi Vattaparambil Sudarsan , Olov Schelen , Ulf Bodin
Last updated 2023-10-18
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-vattaparambil-oauth-poa-grant-type-01
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]