Internet DRAFT - draft-vattaparambil-ace-poa-based-device-reg
draft-vattaparambil-ace-poa-based-device-reg
ace Sreelakshmi
Internet-Draft Olov
Intended status: Informational Ulf
Expires: 4 January 2024 Lulea University of Technology
3 July 2023
PoA based Device Registration in ACE framework
draft-vattaparambil-ace-poa-based-device-reg-00
Abstract
This draft proposes an extension to the ACE framework with the Power
of Attorney (PoA) based authorization. This is proposed following
the identification of mutual authorization problem between the client
and the AS in the ACE framework, which demands secure registration of
the client to the AS and a mechanism for the client to validate the
AS. The proposed system adds a new entity referred as the Device
Owner to the ACE framework that delegates the client device and
provides information (in a PoA) regarding the AS to which the client
is intended to communicate with.
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 4 January 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
Sreelakshmi, et al. Expires 4 January 2024 [Page 1]
Internet-Draft Abbreviated Title July 2023
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Problem Identification . . . . . . . . . . . . . . . . . . . 3
3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5
4. Further Use of PoA . . . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Normative References . . . . . . . . . . . . . . . . . . 7
5.2. Informative References . . . . . . . . . . . . . . . . . 8
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
In ACE framework, the client and the Authorization Server (AS)
requires a mechanism to share the keying materials for the secure
channel establishment between them. This problem can be seen as the
registration, enrolling or onboarding issue in the ACE framework.
Following this, there is a need for (1) the client to register and
authorize with the Authorization Server (AS) and (2) the client to
validate the AS. PoA based authorization in its base form provides
subgranting/delegation based authorization, that enables the Device
Owner (principal) to delegate its limited authority to its trusted
client (device/agent), so that the client can work on behalf of the
Device Owner (DO).
Using PoA based authorization, the client obtains information on the
AS from a trusted party (Device Owner) so that it can compare the AS
identification (obtained from the Resource Server (RS)) with the one
provided by the DO before sending the access token request. With a
proper client registration and validation model, the client can
authorize the AS when it receives the AS URI from the Resource Server
(RS) and ensure that the client is registering to the right AS, which
is in charge of the resource hosted at the RS and share the
credentials over the secure channel. In this draft, we integrate PoA
based authorization with the ACE framework to register the client
with the AS. Following are the different entities part of the
proposed system:
* Device Owner: The owner of the client (device) who generates the
PoA for the client. This entity is same as the Principal entity
in the PoA based authorization.
Sreelakshmi, et al. Expires 4 January 2024 [Page 2]
Internet-Draft Abbreviated Title July 2023
* Client: Client is the device that requests resources from the RS
through AS.
* Authorization Server : AS is the entity that generates access
tokens for the client.
* Resource Server : RS hosts resources and provides them upon client
request using access tokens from the AS.
This document defines the use of PoA based authorization for the
Client Registration in ACE framework. More information on PoA based
authorization can be found in this link:
https://datatracker.ietf.org/doc/draft-vattaparambil-positioning-of-
poa/
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.
2. Problem Identification
RFC 9200 [ACE] defines the ACE framework used for authorization in
constrained environments. The main entities involved in this
framework are the Client, AS, and the RS, where the Client and RS can
be of large numbers and may be resource constrained. There are
things that are considered out of the scope of this specification and
are deliberately left open for future extensions. In this document,
we focus on the Client Registration and the AS Validation issues,
that are left open in the ACE framework.
In section 3.1 of RFC 9202, communication between the client and the
AS is defined. Here, it is defined that the client and the AS MUST
establish a secure communication channel between them and ensure the
security requirements as explained in section 6.5 (C-AS) in RFC 9200.
DTLS profile assumes that the keying material to establish the secure
communication channel is either obtained by manual configuration or
through an automated provisioning process. It mentions that the
client is expected to register with the AS before requesting the
access token. According to RFC 9200 (Section 4), this can be seen as
Client Registration process (bootstrapping, onboarding, or enrolling)
where the client and the AS exchange credentials and configuration
parameters. This means that both the client and AS requires a secure
model to exchange the keying material and credentials that is
required for the secure channel establishment between them. Later in
Sreelakshmi, et al. Expires 4 January 2024 [Page 3]
Internet-Draft Abbreviated Title July 2023
Section 5.8.2, it is mentioned that the AS requires prior knowledge
of the client as well as the RS, which can be achieved for example
with the Dynamic Client Registration Protocol Exchange
[registration]. This problem can be referred as the (1) Client
Registration Problem.
The importance of this can be shown using the example scenario of the
access token request from the client to the AS in Raw Public Key
(RPK) mode from Section 3.2.2 of RFC 9202. Here, the client uses the
req_cnf parameter that specifies its raw public key or a unique
identifier for a public key. In the access token provided by the AS,
the rs_cnf parameter specifies the public key of the resource server
that the client uses to set up a DTLS channel with the RS. Here, if
the client does not have the keying material belonging to the public
key, the client can send an access token request to the AS, with its
RPK in the req_cnf. If the AS specifies a public key in response
that the client does not have, the client should re-register with the
AS, and this is considered out of scope in the specification.
The basic protocol flow diagram of ACE framework begins with the
client requesting an access token from the AS. However, there is
another step done by the client before requesting the access token,
which is explained in section 5.1 of RFC 9200. In this step the
client sends an unauthorized resource request message to the RS to
obtain information about the AS to request an access token in later
steps. Upon receiving the Unauthorized resource request message from
the client, the RS provides AS URI to the client. The client uses
the AS URI to identify the AS that it is intended to communicate with
and request an access token (in step A) Token request). This is
later explained in the CoAP-DTLS profile for the ACE framework [DTLS]
as part of the protocol flow (Section 2). Complementing to this, in
the ACE pub-sub profile it is mentioned that the broker MAY send the
address of the AS in the “AS” parameter as a response to the
unauthorized resource request message.
However, there is no mechanism for the client to validate the AS
authorization; which means the client MUST be able to determine if
the AS is authorized to issue access tokens for a specific RS. In
Section 5.1 of RFC 9200, it is mentioned that this can be solved by
the Client asking its owner if this AS is authorized for this RS or
querying a secure service provided by the client owner. In
Section 6.5 of RFC 9200, it is mentioned that it can be done through
preconfigured lists or using an online lookup mechanism. This
problem can be referred as (2) AS Validation Problem.
Sreelakshmi, et al. Expires 4 January 2024 [Page 4]
Internet-Draft Abbreviated Title July 2023
3. Proposed Solution
This document proposes an extension to the ACE framework based on the
PoA based authorization technique. PoA based authorization is a
delegation based authorization technique that enables the users
(principals) to delegate or subgrant their authority to their trusted
devices (agents) for a limited period of time. This enables the
devices to work/act on behalf of the user, even if the user is
offline. The different entities part of the proposed model based on
PoA based authorization are the Client, RS, AS, and the DO. DO is
the new entity added to the ACE framework as part of this solution.
It is assumed that there is a pre-established trust (e.g., using TLS
certificates) between the DO and the AS. A motivation for this is
that the DO has large number of devices and typically an AS also
supports a large number of RSs. The main properties of DO are:
* DO is a different entity and not same as RS or RO in OAuth.
* Generates the PoA with information regarding the DO, client, and
the AS (see Section (PoA Structure)).
* Send the PoA to the client thus delegating the client to act/work
on behalf of the DO.
This document defines the integration of PoA based authorization
framework with the ACE framework to address the above-identified
problems, which are:
* (1) Client Registration Problem
* (2) AS Validation Problem
Extension of ACE with PoA based authorization shows how the client
can be registered to the AS using the PoA. Protocol flow diagram for
the extended ACE framework with the PoA based authorization is shown
in Figure 1.
Sreelakshmi, et al. Expires 4 January 2024 [Page 5]
Internet-Draft Abbreviated Title July 2023
DO Client AS RS
| | | |
| | | |
+----------------+ | | |
|1.PoA Generation| | | |
+----------------+ | | |
| 2.PoA | | |
|------------>| | |
| | | |
| | 3.Unauth. Initial Req. |
| |------------------------------->|
| | | |
| | 4.AS URI |
| |<-------------------------------|
| | | |
| +---------------+ | |
| |5.AS Validation| | |
| +---------------+ | |
| | | |
| | 6.PoA + reg.req| |
| |--------------->| |
| | | |
| | +---------------------+ |
| | |7.Client Registration| |
| | +---------------------+ |
| | | |
| | 8.Client Secret| |
| |<---------------| |
| | | |
| |9.Sec.ChannelEst| |
| |<-------------->| |
| | | |
Figure 1: Protocol flow of PoA based ACE Extension
The protocol flow begins with the new entity DO generating the PoA.
The PoA is the core part of the PoA based authorization. PoA
contains identification data about the DO, Client, and the AS along
with other metadata. This can be public keys or other identifiers
that can uniquely identify the different entities that are involved
in the authorization process. The important information that is part
of PoA which is given focus in this document is the AS identification
information. The DO includes information regarding the trusted AS in
the PoA, that can be used by the client to register itself to the AS
in the future steps. In this case, the PoA is a CBOR token that is
signed using the private key of the DO and is sent to the client.
Detailed structure of the PoA is in Section (PoA Structure).
Sreelakshmi, et al. Expires 4 January 2024 [Page 6]
Internet-Draft Abbreviated Title July 2023
Once the PoA is issued for the Client for the Client Registration
Process, it can be used to validate the AS and determine if the AS is
authorized to provide access tokens for the specific RS using the
information carried in the PoA. This can be addressed in two
different ways:
* Client sends Unauthorized Resource Request (Section 5.2 of RFC
9200) to the RS and obtains AS URI. Compare the AS URI with
information regarding AS received from the DO inside the PoA.
After successful validation of the AS info, connect (register)
with the AS.
* Use the AS info in the PoA received from the DO to connect with
the AS. Unauthorized Resource Request Step is not required in
this case.
According to the first case, upon receiving the PoA from the DO, the
client connect with the RS by sending an initial unauthorized
resource request as explained in Section 5.2 of RFC 9200. RS denies
the request and respond back with the address of its AS. Client
validates the AS by fetching the AS info from the PoA and comparing
it with the AS URI received from the RS.
Upon successful AS identification, the client sends a client
registration request to the AS along with the PoA. AS responds back
with the client credentials response that includes:
* Client Secret that uniquely identifies the client.
* Client credentials generated as part of the client registration
process.
Protection of the communication flow in the proposed model can be
done using DTLS or OSCORE over CoAP.
4. Further Use of PoA
If we consider AS as a constrained device, there can be n number of
ASs in the authorization system. PoA can be used in this situation
to delegate the authority of the Authorization Server Owner (ASO) to
a single AS. Here, ASO is an entity that owns the AS devices and is
up in the hierarchy same as the DO.
5. References
5.1. Normative References
Sreelakshmi, et al. Expires 4 January 2024 [Page 7]
Internet-Draft Abbreviated Title July 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>.
5.2. Informative References
[ACE] Internet Engineering Task Force, "Authentication and
Authorization for Constrained Environments Using the OAuth
2.0 Framework (ACE-OAuth)", 2022.
[DTLS] Internet Engineering Task Force, "Datagram Transport Layer
Security (DTLS) Profile for Authentication and
Authorization for Constrained Environments (ACE)", 2022.
[registration]
Internet Engineering Task Force, "OAuth 2.0 Dynamic Client
Registration Protocol", 2015.
Contributors
Thanks to all of the contributors.
Authors' Addresses
Sreelakshmi
Lulea University of Technology
SE-97187 Lulea
Sweden
Email: srevat@ltu.se
Olov
Lulea University of Technology
SE-97187 Lulea
Sweden
Email: olov.schelen@ltu.se
Ulf
Lulea University of Technology
SE-97187 Lulea
Sweden
Email: ulf.bodin@ltu.se
Sreelakshmi, et al. Expires 4 January 2024 [Page 8]
