ACE Working Group M. Tiloca Internet-Draft RISE AB Updates: 9200 (if approved) G. Selander Intended status: Standards Track Ericsson AB Expires: 11 January 2024 10 July 2023 Alternative Workflow and OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework draft-tiloca-ace-workflow-and-params-00 Abstract This document updates the Authentication and Authorization for Constrained Environments Framework (ACE, RFC 9200) as follows. First, it defines a new, alternative workflow that the Authorization Server can use for uploading an access token to a Resource Server on behalf of the Client. Second, it defines new parameters and encodings for the OAuth 2.0 token endpoint at the Authorization Server. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Authentication and Authorization for Constrained Environments Working Group mailing list (ace@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ace/. Source for this draft and an issue tracker can be found at https://gitlab.com/crimson84/draft-tiloca-ace-workflow-and-params. 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." Tiloca & Selander Expires 11 January 2024 [Page 1] Internet-Draft Alternative ACE Workflow and Parameters July 2023 This Internet-Draft will expire on 11 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. New ACE Workflow . . . . . . . . . . . . . . . . . . . . . . 4 3. New ACE Parameters . . . . . . . . . . . . . . . . . . . . . 7 3.1. token_uploaded . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . 8 3.2. rs_cnf2 and subject_ids . . . . . . . . . . . . . . . . . 9 3.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5.1. OAuth Parameters Registry . . . . . . . . . . . . . . . . 12 5.2. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Benefits for ACE Transport Profiles . . . . . . . . 16 A.1. DTLS Profile . . . . . . . . . . . . . . . . . . . . . . 16 A.2. EDHOC and OSCORE Profile . . . . . . . . . . . . . . . . 16 Appendix B. Open Points . . . . . . . . . . . . . . . . . . . . 16 B.1. New Workflow . . . . . . . . . . . . . . . . . . . . . . 16 B.1.1. Allow the Dynamic Update of Access Rights . . . . . . 17 B.1.2. Allow the Re-uploading of the Access Token . . . . . 19 B.1.3. Ensure Applicability to Any ACE Profile . . . . . . . 19 B.2. New Parameters . . . . . . . . . . . . . . . . . . . . . 20 B.2.1. token_uploaded . . . . . . . . . . . . . . . . . . . 20 B.2.2. Further New Parameters to Consider . . . . . . . . . 20 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Tiloca & Selander Expires 11 January 2024 [Page 2] Internet-Draft Alternative ACE Workflow and Parameters July 2023 1. Introduction The Authentication and Authorization for Constrained Environments (ACE) framework [RFC9200] defines an architecture to enforce access control for constrained devices. A Client (C) requests an assertion of granted permissions from an Authorization Server (AS) in the form of an access token, then uploads the access token to the target Resource Server (RS), and finally accesses protected resources at the RS according to the permissions specified in the access token. The framework has as main building blocks the OAuth 2.0 framework [RFC6749], the Constrained Application Protocol (CoAP) [RFC7252] for message transfer, CBOR [RFC8949] for compact encoding, and COSE [RFC9052][RFC9053] for self-contained protection of access tokens. In addition, separate profile documents define in detail how the participants in the ACE architecture communicate, especially as to the security protocols that they use. This document updates [RFC9200] as follows. * It defines a new, alternative protocol workflow for the ACE framework (see Section 2), according to which the AS uploads the access token to the RS on behalf of C, and then informs C about the outcome. The new workflow is especially convenient in deployments where the communication leg between C and the RS is constrained, but the communication leg between the AS and the RS is not. The new workflow has no ambition to replace the original workflow. The AS can use one workflow or the other depending, for example, on the specific RS for which an access token has been issued and the nature of the communication leg with that RS. * It defines additional parameters and encodings for the OAuth 2.0 token endpoint at the AS (see Section 3). These include: - "token_uploaded", used by the AS to inform C about the outcome of the token uploading to the RS, as per the new ACE workflow. - "rs_cnf2", used by the AS to provide C with the public keys of the RSs in the group-audience for which the access token is issued (see Section 6.9 of [RFC9200]). - "subject_ids", used by the AS together with the parameter "rs_cnf2", to provide C with the identifiers of the RSs that are associated with the public keys specified in the parameter "rs_cnf2". Tiloca & Selander Expires 11 January 2024 [Page 3] Internet-Draft Alternative ACE Workflow and Parameters July 2023 1.1. Terminology 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. Readers are expected to be familiar with the terms and concepts described in the ACE framework for Authentication and Authorization [RFC9200][RFC9201], as well as with terms and concepts related to CBOR Web Tokens (CWTs) [RFC8392] and CWT Confirmation Methods [RFC8747]. The terminology for entities in the considered architecture is defined in OAuth 2.0 [RFC6749]. In particular, this includes Client (C), Resource Server (RS), and Authorization Server (AS). Readers are also expected to be familiar with the terms and concepts related to the CoAP protocol [RFC7252], CBOR [RFC8949], and COSE [RFC9052][RFC9053]. Note that, unless otherwise indicated, the term "endpoint" is used here following its OAuth definition, aimed at denoting resources such as /token and /introspect at the AS, and /authz-info at the RS. This document does not use the CoAP definition of "endpoint", which is "An entity participating in the CoAP protocol." Examples throughout this document are expressed in CBOR diagnostic notation without the tag and value abbreviations. 2. New ACE Workflow As defined in Section 4 of [RFC9200], the ACE framework considers what is shown in Figure 1 as its basic protocol workflow. That is, the Client first sends an access token request to the token endpoint at the AS (step A), specifying permissions that it seeks to obtain for accessing protected resources at the RS, possibly together with information on its own credentials. Then, if the request has been successfully verified, authenticated, and authorized, the AS replies to the Client (step B), providing an access token and possibly additional parameters as access information including the actually granted permissions. Tiloca & Selander Expires 11 January 2024 [Page 4] Internet-Draft Alternative ACE Workflow and Parameters July 2023 Finally, the Client uploads the access token to the RS and, consistently with the permissions granted according to the access token, accesses a resource at the RS (step C), which replies with the result of the resource access (step F). Details about what protocol the Client and RS use to establish a secure association, mutually authenticate and secure their communications are defined in the specifically used profile of ACE, e.g., [RFC9202][RFC9203][I-D.ietf-a ce-edhoc-oscore-profile][I-D.tiloca-ace-group-oscore-profile]. Further interactions are possible between the AS and RS, i.e., the exchange of an introspection request and response where the AS validates a previously issued access token for RS (steps D and E). +--------+ +---------------+ | |---(A)-- Token Request ------->| | | | | Authorization | | |<--(B)-- Access Token ---------| Server | | | + Access Information | | | | + Refresh Token (optional) +---------------+ | | ^ | | | Introspection Request (D)| | | Client | Response | |(E) | | (optional exchange) | | | | | v | | +--------------+ | |---(C)-- Token + Request ----->| | | | | Resource | | |<--(F)-- Protected Resource ---| Server | | | | | +--------+ +--------------+ Figure 1: ACE Basic Protocol Workflow This section defines a new, alternative protocol workflow shown in Figure 2, which MAY be supported by the AS. Unlike in the original protocol workflow, the AS uploads the access token to the RS on behalf of the Client, and then informs the Client about the outcome. If the token uploading has been successfully completed, the AS does not provide the access token to the Client altogether. Instead, the Client simply establishes a secure association with the RS (if that has not happened already), and then accesses protected resources at the RS according to the permissions granted per the access token and specified by the AS as access information. Tiloca & Selander Expires 11 January 2024 [Page 5] Internet-Draft Alternative ACE Workflow and Parameters July 2023 +--------+ +----------------------------+ | |---(A)-- Token Request ------->| | | | | Authorization | | |<--(B)-- Token Response -------| Server | | | + Access Information | | | | + Access Token (optional) +----------------------------+ | | + Refresh Token (optional) ^ | | ^ | | | | | | Token-Upload | | Introspection Request (D)| | (A1)| | Request | Client | Response | |(E) | |(A2) Response | | (optional exchange) | | | | | | | v v | | | +----------------------------+ | |---(C1)-- Token (Optional) --->| | | | | | | |---(C2)-- Protected Request -->| Resource | | | | Server | | |<--(F)--- Protected Resource --| | | | | | +--------+ +----------------------------+ Figure 2: ACE Alternative Protocol Workflow More specifically, the new workflow consists of the following steps. * Step A - This step is as in the original workflow, with the Client sending an Access Token Request to the token endpoint at the AS. * Step A1 - This new step consists of the AS uploading the access token to the RS, typically at the authz-info endpoint, just like the Client does in the original workflow. * Step A2 - This new step consists of the RS replying to the AS, following the uploading of the access token at step A1. * Step B - In the Access Token Response, the AS tells the Client that it has attempted to upload the access token to the RS, specifying the outcome of the token uploading based on the reply received from the RS at step A2. As defined in Section 3.1, this information is conveyed by the "token_uploaded" parameter. If the token uploading has succeeded, the AS does not provide the Client with the access token. Otherwise, the AS provides the Client with the access token. Tiloca & Selander Expires 11 January 2024 [Page 6] Internet-Draft Alternative ACE Workflow and Parameters July 2023 * Step C1 - This step occurs only if the token uploading from the AS has failed, and the AS has provided the Client with the access token at step B. In such a case, the Client uploads the access token to the RS just like at step C of the original workflow. * Step C2 - The Client attempts to access a protected resource at the RS, according to the permissions granted per the access token and specified by the AS as access information at step B. * Steps D, E and F are as in the original workflow. The new workflow has no ambition to replace the original workflow defined in [RFC9200]. The AS can use one workflow or the other depending, for example, on the specific RS for which the access token has been issued and the nature of the communication leg with that RS. 3. New ACE Parameters The rest of this section defines a number of additional parameters and encodings for the OAuth 2.0 token endpoint at the AS. 3.1. token_uploaded This section defines the additional parameter "token_uploaded" for an Access Token Response, sent by the AS in reply to a request to the token endpoint from C. The parameter "token_uploaded" is REQUIRED in a successful Access Token Response with response code 2.01 (Created), if the AS has issued an access token and has attempted to upload it to the RS on behalf of C as per the ACE alternative protocol workflow defined in Section 2, irrespective of the result of the token upload. Otherwise, the parameter "token_uploaded" MUST NOT be present. If present, the parameter "token_uploaded" MUST encode the CBOR simple value "true" (0xf5) if the token upload at the RS was successful, or the CBOR simple value "false" (0xf4) otherwise. If the parameter "token_upload" encodes the CBOR simple value "true", the access token MUST NOT be included in the Access Token response. Otherwise, the access token MUST be included. Tiloca & Selander Expires 11 January 2024 [Page 7] Internet-Draft Alternative ACE Workflow and Parameters July 2023 3.1.1. Examples Figure 3 shows an example of Access Token Response from the AS to C, following the issue of an access token bound to a symmetric PoP key. The Access Token Response specifies the parameter "token_uploaded" with value "true", which indicates that the AS has successfully uploaded the access token to the RS on behalf of C. Consistently, the Access Token Response does not include the access token, while it still includes the parameter "cnf" specifying the symmetric PoP key bound to the access token. 2.01 Created Content-Format: application/ace+cbor Max-Age: 3560 Payload: { "token_uploaded" : true, "expires_in" : 3600, "cnf" : { "COSE_Key" : { "kty" : 1, "kid" : h'3d027833fc6267ce', "k" : h'73657373696f6e6b6579' } } } Figure 3: Example of Access Token Response, including the parameter "token_uploaded" but not the access token, which is bound to a symmetric key and was uploaded to the RS by the AS Figure 4 shows another example of Access Token Response from the AS to C, also following the issue of an access token bound to a symmetric PoP key. In this example, the Access Token Response includes the parameter "token_uploaded" with value "false", which indicates that the AS has failed to upload the access token to the RS on behalf of C. The Access Token Response also includes the access token and the parameter "cnf" specifying the symmetric PoP key bound to the access token. Note that, even though the AS has failed to upload the access token to the RS, the response code 2.01 (Created) is used when replying to C, since the Access Token Request as such has been successfully processed at the AS, with the following issue of the access token. Tiloca & Selander Expires 11 January 2024 [Page 8] Internet-Draft Alternative ACE Workflow and Parameters July 2023 2.01 Created Content-Format: application/ace+cbor Max-Age: 3560 Payload: { "access_token" : h'd08343a1'/... (remainder of CWT omitted for brevity; CWT contains the symmetric PoP key in the "cnf" claim)/, "token_uploaded" : false, "expires_in" : 3600, "cnf" : { "COSE_Key" : { "kty" : 1, "kid" : h'3d027833fc6267ce', "k" : h'73657373696f6e6b6579' } } } Figure 4: Example of Access Token Response, including the parameter "token_uploaded" together with the access token, which is bound to a symmetric key and which the AS failed to upload to the RS 3.2. rs_cnf2 and subject_ids This section defines the additional parameters "rs_cnf2" and "subject_ids" for an Access Token Response, sent by the AS in reply to a request to the token endpoint from C. * The parameter "rs_cnf2" is OPTIONAL if the token type is "pop", asymmetric keys are used, and the access token is issued for an audience that includes multiple RSs (i.e., a group-audience, see Section 6.9 of [RFC9200]). Otherwise, the parameter "rs_cnf2" MUST NOT be present. This parameter specifies information about the public keys used by the RSs of a group-audience for authenticating themselves to C, and is used in case the binding between the public keys and the corresponding RS identities are not established through other means. If this parameter is absent, either the RSs in the group- audience do not use a public key, or the AS knows that the RSs can authenticate themselves to C without additional information. Tiloca & Selander Expires 11 January 2024 [Page 9] Internet-Draft Alternative ACE Workflow and Parameters July 2023 If present, this parameter MUST encode a non-empty CBOR array. Each element of the CBOR array specifies the public key of one RS in the group-audience, and MUST follow the syntax and semantics of the "cnf" claim either from Section 3.1 of [RFC8747] for CBOR- based interactions, or from Section 3.1 of [RFC7800] for JSON- based interactions. It is not required that all the elements of the CBOR array rely on the same confirmation method. Each of the public keys may contain parameters specifying information such as the public key algorithm and use (e.g., by means of the parameters "alg" or "key_ops" in a COSE_Key structure). If such information is specified, a Client MUST NOT use a public key that is incompatible with the profile or PoP algorithm according to that information. An RS MUST reject a proof of possession using such a key with a response code equivalent to the CoAP code 4.00 (Bad Request). * The parameter "subject_ids" is REQUIRED if the parameter "rs_cnf2" is present. Otherwise, the parameter "subject_ids" MUST NOT be present. This parameter specifies the identifiers of the RSs in the group- audience for which the access token is issued. If present, this parameter MUST encode a non-empty CBOR array, with the same size of the CBOR array in the "rs_cnf2" parameter. The i-th element of the CBOR array in the "subject_ids" parameter MUST be the identifier of the RS whose public key is specified as the i-th element of the CBOR array in the "rs_cnf2" parameter. Each element of the CBOR array in the "subject_ids" parameter MUST be either: - A CBOR text string, with value an absolute URI [RFC3986] without path component, query component or fragment identifier; or - A CBOR array, as an absolute CRI reference [I-D.ietf-core-href] without path component, query component or fragment identifier. In either case, C is responsible for resolving these identifiers into network addresses for communicating with the respective RS. Tiloca & Selander Expires 11 January 2024 [Page 10] Internet-Draft Alternative ACE Workflow and Parameters July 2023 3.2.1. Example Figure 5 shows an example of Access Token Response from the AS to C, following the issue of an access token bound to C's public key as asymmetric PoP key. The Access Token Response includes the access token, as well as the parameters "rs_cnf2" and "subject_ids". These specify the public key of two RSs as intended recipients of the access token and the URIs identifying those two RSs, respectively. 2.01 Created Content-Format: application/ace+cbor Max-Age: 3600 Payload: { "access_token" : b64'SlAV32hk'/... (remainder of CWT omitted for brevity; CWT contains the client's RPK in the "cnf" claim)/, "expires_in" : 3600, "rs_cnf2" : [ { "COSE_Key" : { "kty" : 2, "crv" : 1, "x" : h'bbc34960526ea4d32e940cad2a234148 ddc21791a12afbcbac93622046dd44f0', "y" : h'4519e257236b2a0ce2023f0931f1f386 ca7afda64fcde0108c224c51eabf6072' } }, { "COSE_Key" : { "kty" : 2, "crv" : 1, "x" : h'ac75e9ece3e50bfc8ed6039988952240 5c47bf16df96660a41298cb4307f7eb6', "y" : h'6e5de611388a4b8a8211334ac7d37ecb 52a387d257e6db3c2a93df21ff3affc8' } } ], "subject_ids" : [ "coaps://rs1.example.com", "coaps://rs2.example.com" ] } Tiloca & Selander Expires 11 January 2024 [Page 11] Internet-Draft Alternative ACE Workflow and Parameters July 2023 Figure 5: Example of Access Token Response with an access token bound to an asymmetric key, using the parameters "rs_cnf2" and "subject_ids" 4. Security Considerations TBD 5. IANA Considerations This document has the following actions for IANA. 5.1. OAuth Parameters Registry IANA is asked to add the following entries to the "OAuth Parameters" registry. * Name: "token_uploaded" * Parameter Usage Location: token response * Change Controller: IESG * Reference: [RFC-XXXX] * Name: "rs_cnf2" * Parameter Usage Location: token response * Change Controller: IESG * Reference: [RFC-XXXX] * Name: "subject_ids" * Parameter Usage Location: token response * Change Controller: IESG * Reference: [RFC-XXXX] 5.2. OAuth Parameters CBOR Mappings Registry IANA is asked to add the following entries to the "OAuth Parameters CBOR Mappings" following the procedure specified in [RFC9200]. Tiloca & Selander Expires 11 January 2024 [Page 12] Internet-Draft Alternative ACE Workflow and Parameters July 2023 * Name: "token_uploaded" * CBOR Key: TBD * Value Type: simple value "true" / simple type "false" * Reference: [RFC-XXXX] * Name: "rs_cnf2" * CBOR Key: TBD * Value Type: array * Reference: [RFC-XXXX] * Name: "subject_ids" * CBOR Key: TBD * Value Type: array * Reference: [RFC-XXXX] 6. References 6.1. Normative References [I-D.ietf-ace-edhoc-oscore-profile] Selander, G., Mattsson, J. P., Tiloca, M., and R. Höglund, "Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-edhoc-oscore-profile-02, 7 July 2023, . [I-D.ietf-core-href] Bormann, C. and H. Birkholz, "Constrained Resource Identifiers", Work in Progress, Internet-Draft, draft- ietf-core-href-12, 6 March 2023, . Tiloca & Selander Expires 11 January 2024 [Page 13] Internet-Draft Alternative ACE Workflow and Parameters July 2023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . Tiloca & Selander Expires 11 January 2024 [Page 14] Internet-Draft Alternative ACE Workflow and Parameters July 2023 [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, . [RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022, . [RFC9201] Seitz, L., "Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE)", RFC 9201, DOI 10.17487/RFC9201, August 2022, . 6.2. Informative References [I-D.ietf-ace-revoked-token-notification] Tiloca, M., Palombini, F., Echeverria, S., and G. Lewis, "Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework", Work in Progress, Internet- Draft, draft-ietf-ace-revoked-token-notification-06, 2 June 2023, . [I-D.ietf-lake-edhoc] Selander, G., Mattsson, J. P., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in Progress, Internet-Draft, draft-ietf-lake-edhoc-20, 7 July 2023, . [I-D.tiloca-ace-group-oscore-profile] Tiloca, M., Höglund, R., Seitz, L., and F. Palombini, "The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework", Work in Progress, Internet-Draft, draft- tiloca-ace-group-oscore-profile-10, 8 March 2023, . Tiloca & Selander Expires 11 January 2024 [Page 15] Internet-Draft Alternative ACE Workflow and Parameters July 2023 [RFC9202] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and L. Seitz, "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", RFC 9202, DOI 10.17487/RFC9202, August 2022, . [RFC9203] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework", RFC 9203, DOI 10.17487/RFC9203, August 2022, . Appendix A. Benefits for ACE Transport Profiles For any transport profile of ACE, the following holds. * The new ACE workflow defined in Section 2 is effectively possible to use. This is beneficial for deployments where the communication leg between C and the RS is constrained, but the communication leg between the AS and RS is not. * When the new ACE workflow is used, the parameter "token_uploaded" defined in Section 3.1 is used to inform C that the AS has attempted to upload the access token to the RS, specifying whether the uploading has succeeded or failed. A.1. DTLS Profile When the RPK mode of the DTLS profile is used (see Section 3.2 of [RFC9202]), the parameters "rs_cnf2" and "subject_ids" defined in Section 3.2 enable the effective issue of an access token intended to an audience that includes multiple RSs. A.2. EDHOC and OSCORE Profile When the EDHOC and OSCORE profile is used [I-D.ietf-ace-edhoc-oscore-profile], the parameters "rs_cnf2" and "subject_ids" defined in Section 3.2 enable the effective issue of an access token intended to an audience that includes multiple RSs. Appendix B. Open Points B.1. New Workflow The following discusses open points related to the use of the new ACE workflow defined in Section 2. Tiloca & Selander Expires 11 January 2024 [Page 16] Internet-Draft Alternative ACE Workflow and Parameters July 2023 B.1.1. Allow the Dynamic Update of Access Rights In some profiles of ACE, C can request a new access token to update its access rights, while preserving the same secure association with the RS. The new access token supersedes the current one stored at the RS, as they are both part of the same "token series". A token series comprises all the access tokens issued by the same AS for the same pair (Client, Resource Server). Specific profiles can provide a more specialized definition, e.g., by further taking into account the public authentication credentials of C and the RS. When using the original ACE workflow, C uploads the new access token to the RS by protecting the message exchange through the secure association with the RS. This allows the RS to determine that the upload of such access token is for updating the access rights of C. When using the new ACE workflow, the AS uploads the new access token to the RS also when an update of access rights for C is to be performed. This message exchange would be protected through the secure association between the AS and RS. However, this secure association does not help the RS retrieve the stored access token to supersede, as that is rather bound to the secure association with C. In order for the new ACE workflow to also allow the dynamic update of access rights, it is required that the new access token updating the access rights of C includes an explicit indication for the RS. Such an indication can point the RS to the token series in question (hence to the current access token to supersede), irrespective of the secure association used to protect the token uploading. In some profiles of ACE, such an indication is in fact already present in issued access tokens: * In the PSK mode of the DTLS profile [RFC9202], the token series is indicated by the parameter "kid" within the claim "cnf" of the new access token. This has the same value of the parameter "kid" in the COSE_Key within the claim "cnf" from the first access token of the token series. * In the OSCORE profile [RFC9203], the token series is indicated by the parameter "kid" within the claim "cnf" of the new access token. This has the same value of the parameter "id" in the OSCORE_Input_Material object within the claim "cnf" from the first access token of the token series. Tiloca & Selander Expires 11 January 2024 [Page 17] Internet-Draft Alternative ACE Workflow and Parameters July 2023 * In the EDHOC and OSCORE profile [I-D.ietf-ace-edhoc-oscore-profile], the token series is indicated by the parameter "kid" within the claim "cnf" of the new access token. This has the same value of the parameter "id" in the EDHOC_Information object within the claim "cnf" from the first access token of the token series. Note: version -01 of the EDHOC and OSCORE profile says that an update of access rights is not possible when using the new workflow. However, it is actually possible as discussed above. In the three cases above, the update of access rights is possible because there is a value used as de facto "token series ID". This value does not change throughout the lifetime of a token series, and it is used to associate the new access token with the previous one in the same series to be superseded. Such a token series ID is required to have a unique value from a namespace/pool that the AS exclusively control. This is in fact what happens in the profiles of ACE above, where the AS is the entity creating the mentioned objects or COSE Key included in the first access token of a token series. However, this may generally not hold and it is not what happens in other known cases, i.e., the DTLS profile in RPK mode [RFC9203] and the Group OSCORE profile [I-D.tiloca-ace-group-oscore-profile]. At the moment, the dynamic update of access rights is not possible for those, _neither in the original nor in the new ACE workflow_. In order to make the update of access rights possible also for such cases, as well as both in the original and in the new ACE workflow, those cases can rely on a new parameter and claim "token_series_id" (see Appendix B.2.2), which specifies a unique identifier of the token series which an access token belongs to. As to existing profiles of ACE, the above has no intention to change the current behavior when the update of access rights occurs, irrespective of the used ACE workflow and especially when using the original workflow. If future profiles rely on a construction where the AS creates the object or key included in the claim "cnf" of the first access token in a token series, and a unique ID generated by the AS is included in such object or key, then that ID must be used as de facto "token series ID", rather than the new parameter "token_series_id". Tiloca & Selander Expires 11 January 2024 [Page 18] Internet-Draft Alternative ACE Workflow and Parameters July 2023 B.1.2. Allow the Re-uploading of the Access Token After the AS has successfully uploaded the access token to the RS when using the new ACE workflow, C does not obtain the access token altogether. It follows that C cannot re-upload the Access Token to the RS by itself, e.g., in order to perform a key update like defined for the OSCORE profile [RFC9203]. Even in such a case, the token re-uploading can be allowed by relying on a new parameter "token_hash", which the AS provides to C and specifies the hash of the access token (see Appendix B.2.2). Then, C can practically "re-upload" the access token to the RS, by sending a request to the authz-info endpoint that includes the parameter "token_hash" instead of the parameter "access_token". Such a request may include further parameters, depending on what is defined for the used transport profile. If the RS still stores the access token in question, then the RS can identify it by means of the received token hash, and take the same actions that would have been taken in case the full access token was re-uploaded to the authz-info endpoint. B.1.3. Ensure Applicability to Any ACE Profile Some profiles of ACE require that C and the RS generate information to be exchanged when uploading the access token. For example: * In the OSCORE profile [RFC9203], C and RS are required to exchange the nonces N1 and N2, when uploading to the RS the first access token of a token series, as well as when re-uploading any access token (e.g., in order to perform a key update). * In the EDHOC and OSCORE profile [I-D.ietf-ace-edhoc-oscore-profile], C and the RS are required to exchange the nonces N1 and N2, when re-uploading any access token in order to perform a key update through the function EDHOC_KeyUpdate (see Appendix I of [I-D.ietf-lake-edhoc]). Evidently, using the new ACE workflow prevents C and the RS from directly performing the required exchanges above, since the uploading of the access token does not rely on a direct interaction between C and RS like in the original ACE workflow. For some profiles of ACE, this may prevent the use of the new ACE workflow altogether. This issue can be solved by having the AS acting as intermediary also for the exchange of C- and RS-generated information, by relying on two new parameters "to_rs" and "from_rs" (see Appendix B.2.2). In Tiloca & Selander Expires 11 January 2024 [Page 19] Internet-Draft Alternative ACE Workflow and Parameters July 2023 particular, C can use "to_rs" for providing the AS with C-generated information, to be relayed to the RS when uploading the access token. Also, the RS can use "from_rs" for providing the AS with RS-generated information when replying to the token uploading, and to be relayed to C. With reference to the two cases mentioned above, "to_rs" can specify the nonce N1 generated by C, while "from_rs" can specify the nonce N2 generated by RS. B.2. New Parameters B.2.1. token_uploaded The parameter "token_uploaded" defined in Section 3.1 builds on the assumption that C can operate in the presence of the alternative ACE workflow defined in Section 2. In particular, it assumes that C accepts as valid an Access Token Response that includes the parameter "token_uploaded" encoding the CBOR simple value "true" but not the access token, and that, in such a case, C continues by sending a protected request to the RS. In turn, this assumes that the AS knows that C can operate in the presence of the alternative ACE workflow. This can be part of the information that C provided to the AS at its registration. An alternative design choice would instead require C to opt-in when sending the Access Token Request to the AS. That is, C can include the parameter "token_uploaded" in the Access Token Request, encoding the CBOR simple value "true", hence explicitly signaling its understanding of the alternative workflow. Only if the AS supports the alternative workflow and the Access Token Request includes the parameter "token_uploaded" encoding the CBOR simple value "true", can the AS attempt to upload the access token to the RS on behalf of C as per the alternative workflow. B.2.2. Further New Parameters to Consider The following discusses possible, further new parameters that can be defined for addressing the open points raised earlier in Appendix B. * "token_series_id" - This parameter specifies the unique identifier of a token series, thus ensuring that C can dynamically update its access rights, irrespective of the used ACE workflow (see Appendix B.1.1). Tiloca & Selander Expires 11 January 2024 [Page 20] Internet-Draft Alternative ACE Workflow and Parameters July 2023 When issuing the first access token of a token series, the AS specifies this parameter in the Access Token Response to C, with value TS_ID. Also, the AS includes a claim "token_series_id" with the same value in the access token. When C requests a new access token in the same tokes series for dynamically updating its access rights, C specifies the value TS_ID as "kid" within the parameter "req_cnf" of the Access Token Request (see Section 3.1 of [RFC9201]). The AS specifies the same value as "kid" within the claim "cnf" of the new access token. * "token_hash" - This parameter specifies the hash of an access token that the AS has successfully issued and uploaded to the RS as per the new ACE workflow, and thus that the AS does not provide to C (see Appendix B.1.1). The AS specifies this parameter in a successful Access Token Response, in case the parameter "token_uploaded" is also specified as encoding the CBOR simple value "true" (see Section 3.1). The parameter value is the hash computed over the value that the parameter "access_token" would have had in that same response message, if it was included therein specifying the access token. C specifies this parameter in the request sent to the authz-info endpoint at the RS for "re-uploading" the same access token, e.g., in order to perform a key update (see Appendix B.1.2). This parameter also allows C to seamlessly use the method defined in [I-D.ietf-ace-revoked-token-notification] for learning of revoked access tokens, even when the new ACE workflow is used and C does not obtain the access token, which makes it impossible for C to compute the token hash by itself. * "to_rs" - When using the new ACE workflow, this parameter specifies C-generated information that, according to the used profile of ACE, C has to provide to the RS together with the access token if using the original ACE workflow. This allows the AS to relay such information to the RS upon uploading the access token on behalf of C (see Appendix B.1.3). First, C specifies this parameter in the Access Token Request sent to the AS. Then, the AS specifies this parameter in the request to the RS sent for uploading the access token on behalf of C, by simply relaying the value received from C. The used profile of ACE has to define the detailed content and semantics of the information specified in the parameter value. Tiloca & Selander Expires 11 January 2024 [Page 21] Internet-Draft Alternative ACE Workflow and Parameters July 2023 * "from_rs" - When using the new ACE workflow, this parameter specifies RS-generated information that, according to the used profile of ACE, the RS has to provide to C after the uploading of an access token if using the original ACE workflow. This allows the AS to relay such information to C after having uploaded the access token on behalf of C (see Appendix B.1.3). First, the RS specifies this parameter in the response sent to the AS, after the upload of an access token through a request from the AS. Then, the AS specifies this parameter in the Access Token Response to C, by simply relaying the value received from the RS. The used profile of ACE has to define the detailed content and semantics of the information specified in the parameter value. Acknowledgments The author sincerely thanks Rikard Höglund for his comments and feedback. The work on this document has been partly supported by the H2020 project SIFIS-Home (Grant agreement 952652). Authors' Addresses Marco Tiloca RISE AB Isafjordsgatan 22 SE-16440 Kista Sweden Email: marco.tiloca@ri.se Göran Selander Ericsson AB Torshamnsgatan 23 SE-16440 Stockholm Kista Sweden Email: goran.selander@ericsson.com Tiloca & Selander Expires 11 January 2024 [Page 22]