Internet-Draft Group OSCORE Profile of ACE July 2024
Tiloca, et al. Expires 9 January 2025 [Page]
Workgroup:
ACE Working Group
Internet-Draft:
draft-ietf-ace-group-oscore-profile-02
Published:
Intended Status:
Standards Track
Expires:
Authors:
M. Tiloca
RISE AB
R. Höglund
RISE AB
F. Palombini
Ericsson AB

The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework

Abstract

This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) to provide communication security between a Client and one or multiple Resource Servers that are members of an OSCORE group. The profile securely binds an OAuth 2.0 Access Token to the public key of the Client associated with the private key used by that Client in the OSCORE group. The profile uses Group OSCORE to achieve server authentication, as well as proof-of-possession for the Client's public key. Also, it provides proof of the Client's membership to the OSCORE group by binding the Access Token to information from the Group OSCORE Security Context, thus allowing the Resource Server(s) to verify the Client's membership upon receiving a message protected with Group OSCORE from the Client. Effectively, the profile enables fine-grained access control paired with secure group communication, in accordance with the Zero Trust principles.

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://github.com/ace-wg/ace-group-oscore-profile.

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 9 January 2025.

Table of Contents

1. Introduction

A number of applications rely on a group communication model where a Client can access a resource hosted by multiple Resource Servers at once, e.g., over IP multicast. Typical examples are switching of luminaries, actuators control, and distribution of software updates. Secure communication in the group can be achieved by sharing a set of keying material, which is typically provided upon joining the group.

For some of such applications, it may be just fine to enforce access control in a straightforward fashion. That is, any Client authorized to join the group, hence to obtain the group keying material, can be also implicitly authorized to perform any action at any resource of any Server in the group. An example of application where such implicit authorization might serve well is a simple lighting scenario, where the lightbulbs are the Servers, while the user account on an app on the user's phone is the Client. In this case, it might be fine to not require additional authorization evidence from any user account, if it is acceptable that any current group member is also authorized to switch on and off any light, or to check their status.

However, in different instances of such applications, the approach above is not desirable, as different group members are intended for have different access rights to resources of other group members. For instance, enforcing access control in accordance with a more fine-grained approach is required in the two following use cases.

As a first case, an application provides control of smart locks acting as Servers in the group, where: a first type of Client, e.g., a user account of a child, is allowed to only query the status of the smart locks; while a second type of Client, e.g., a user account of a parent, is allowed to both query and change the status of the smart locks. Further similar applications concern the enforcement of different sets of permissions in groups with sensor/actuator devices, e.g., thermostats acting as Servers. Also, some group members may even be intended as Servers only. Hence, they must be prevented from acting as Clients altogether and from accessing resources at other Servers, especially when attempting to perform non-safe operations.

As a second case, building automation scenarios often rely on Servers that, under different circumstances, enforce different level of priority for processing received commands. For instance, BACnet deployments consider multiple classes of Clients, e.g., a normal light switch (C1) and an emergency fire panel (C2). Then, a C1 Client is not allowed to override a command from a C2 Client, until the latter relinquishes control at its higher priority. That is: i) only C2 Clients should be able to adjust the minimum required level of priority on the Servers, so rightly locking out C1 Clients if needed; and ii) when a Server is set to accept only high-priority commands, only C2 Clients should be able to perform such commands otherwise allowed also to C1 Clients. Given the different maximum authority of different Clients, fine-grained access control would effectively limit the execution of high- and emergency-priority commands only to devices that are in fact authorized to perform such actions. Besides, it would prevent a misconfigured or compromised device from initiating a high-priority command and lock out normal control.

In the cases above, being a legitimate group member and storing the group keying material is not supposed to imply any particular access rights. Instead, access control to the secure group communication channel and access control to the resource space provided by Servers in the group should remain logically separated domains.

This is aligned with the Zero Trust paradigm [NIST-800-207], which focuses on resource protection and builds on the premise that trust is never granted implicitly, but must be continually evaluated. In particular, Zero Trust protections involve "minimizing access to resources (such as data and compute resources and applications/services) to only those subjects and assets identified as needing access as well as continually authenticating and authorizing the identity and security posture of each access request."

Furthermore, [NIST-800-207] highlights how the Zero Trust goal is to "prevent unauthorized access to data and services coupled with making the access control enforcement as granular as possible", to "enforce least privileges needed to perform the action in the request."

As a step in this direction, one can be tempted to introduce a different security group for each different set of access rights. However, this inconveniently results in additional keying material to distribute and manage. In particular, if the access rights pertaining to a node change, this requires to evict the node from the group, after which the node has to join a different group aligned with its new access rights. Moreover, the keying material of both groups would have to be renewed for their current members. Overall, this would have a non negligible impact on operations and performance.

Instead, a fine-grained yet flexible access control model can be enforced within the same group, by using the Authentication and Authorization for Constrained Environments (ACE) framework [RFC9200]. That is, a Client has to first obtain authorization credentials in the form of an Access Token, and upload it to the Resource Server(s) in the group before accessing the intended resources.

The ACE framework delegates to separate profile documents how to secure communications between the Client and the Resource Servers. However each of the current profiles of ACE defined in [RFC9202][RFC9203][RFC9431][I-D.ietf-ace-edhoc-oscore-profile] relies on a security protocol that cannot be used to protect one-to-many group messages, for example sent over IP multicast.

This document specifies the "coap_group_oscore" profile of the ACE framework, where a Client uses the Constrained Application Protocol (CoAP) [RFC7252][I-D.ietf-core-groupcomm-bis] to communicate with one or multiple Resource Servers that are members of an application group and share a common set of resources. This profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) [I-D.ietf-core-oscore-groupcomm] as the security protocol to protect messages exchanged between the Client and the Resource Servers. Hence, it requires that both the Client and the Resource Servers have previously joined the same OSCORE group.

That is, this profile describes how access control is enforced for a Client after it has joined an OSCORE group, to access resources hosted by other members in that group. The process for joining the OSCORE group through the respective Group Manager as defined in [I-D.ietf-ace-key-groupcomm-oscore] takes place before the process described in this document, and is out of the scope of this profile.

The Client proves its access to be authorized to the Resource Server(s) by using an Access Token bound to a key (the proof-of-possession key). This profile uses Group OSCORE to achieve server authentication and proof-of-possession for the Client's public key used in the OSCORE group in question. Note that proof-of-possession is not achieved through a dedicated protocol element, but instead after the first message exchange protected with Group OSCORE.

Furthermore, this profile provides proof of the Client's membership to the OSCORE group, by binding the Access Token to information from the pre-established Group OSCORE Security Context, as well as to the Client's authentication credential used in the group and including the Client's public key. This allows the Resource Server(s) to verify the Client's group membership upon reception of a message protected with Group OSCORE from that Client.

OSCORE [RFC8613] specifies how to use COSE [RFC9052][RFC9053] to secure CoAP messages. Group OSCORE builds on OSCORE to provide secure group communication, and ensures source authentication: by means of digital signatures embedded in the protected message (when using the group mode); or by protecting a message with pairwise keying material derived from the asymmetric keys of the two peers exchanging the message (when using the pairwise mode).

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 related to CBOR [RFC8949], COSE [RFC9052][RFC9053], CoAP [RFC7252], OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. These especially include:

  • Group Manager, as the entity responsible for a set of groups where communications among members are secured with Group OSCORE.

  • Authentication credential, as the set of information associated with an entity, including that entity's public key and parameters associated with the public key. Examples of authentication credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC5280], and C509 certificates [I-D.ietf-cose-cbor-encoded-cert].

    Members of an OSCORE group have an associated authentication credential in the format used within the group. As per Section 2.4 of [I-D.ietf-core-oscore-groupcomm], an authentication credential provides the public key as well as the comprehensive set of information related to the public key algorithm, including, e.g., the used elliptic curve (when applicable).

Readers are expected to be familiar with the terms and concepts described in the ACE framework for authentication and authorization [RFC9200], as well as in the OSCORE profile of ACE [RFC9203]. 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).

Note that the term "endpoint" is used here following its OAuth definition [RFC6749], 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".

Additionally, this document makes use of the following terminology.

Examples throughout this document are expressed in CBOR diagnostic notation as defined in Section 8 of [RFC8949] and Appendix G of [RFC8610]. Diagnostic notation comments are often used to provide a textual representation of the numeric parameter names and values.

In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDDL model shown in Figure 7 of Appendix B. For example, {e'context_id_param': h'abcd0000', e'salt_input_param': h'00} stands for {71: h'abcd0000', 72: h'00}.

Note to RFC Editor: Please delete the paragraph immediately preceding this note. Also, in the CBOR diagnostic notation used in this document, please replace the constructs of the form e'SOME_NAME' with the value assigned to SOME_NAME in the CDDL model shown in Figure 7 of Appendix B. Finally, please delete this note.

2. Protocol Overview

This section provides an overview of this profile, i.e., of how to use the ACE framework for authentication and authorization [RFC9200] to secure communications between a Client and one or more Resource Servers using Group OSCORE [I-D.ietf-core-oscore-groupcomm].

Note that this profile of ACE describes how access control can be enforced for a node after it has joined an OSCORE group, to access resources hosted by other members in that group.

In particular, the process of joining the OSCORE group through the respective Group Manager as defined in [I-D.ietf-ace-key-groupcomm-oscore] must take place before the process described in this document, and is out of the scope of this profile.

An overview of the protocol flow for this profile is shown in Figure 1, where it is assumed that both the Resource Servers RS1 and RS2 are associated with the same Authorization Server AS. It is also assumed that the Client C, as well as RS1 and RS2 have previously joined an OSCORE group with Group Identifier (gid) 0xabcd0000, and that they got assigned Sender ID (sid) 0x00, 0x01, and 0x02 in the group, respectively. The names of messages coincide with those of [RFC9200] when applicable, and messages in square brackets are optional.

C RS1 RS2 AS [ Resource Request ] [ AS Request ] Creation Hints POST /token (aud: "RS1", sid: 0x00, gid: 0xabcd0000, ...) Access Token T1 + Access Information POST /authz-info (access_token: T1) 2.01 Created POST /token (aud: "RS2", sid: 0x00, gid: 0xabcd0000, ...) Access Token T2 + Access Information POST /authz-info (access_token: T2) 2.01 Created Group OSCORE Request (kid: 0x00, gid: 0xabcd0000) | /proof-of-possession/ Group OSCORE Response (kid: 0x01) /proof-of-possession/ /Mutual authentication between C and RS1/ Group OSCORE Response (kid: 0x02) /proof-of-possession/ /Mutual authentication between C and RS2/ ...
Figure 1: Protocol Overview.

2.1. Pre-Conditions

Using Group OSCORE and this profile requires that both the Client and the Resource Servers have previously joined the same OSCORE group. This especially includes the derivation of the Group OSCORE Security Context and the assignment of unique Sender IDs to use in the group. Nodes can join the OSCORE group through the respective Group Manager by using the approach defined in [I-D.ietf-ace-key-groupcomm-oscore], which is also based on ACE.

After the Client and Resource Servers have joined the group, this profile provides access control for accessing resources on those Resource Servers, by securely communicating with Group OSCORE.

As a pre-requisite for this profile, the Client has to have successfully joined the OSCORE group where also the Resource Servers (RSs) are members. Depending on the limited information initially available, the Client may have to first discover the exact OSCORE group used by the RSs for the resources of interest, e.g., by using the approach defined in [I-D.tiloca-core-oscore-discovery].

2.2. Access Token Retrieval

This profile requires that the Client retrieves an Access Token from the AS for the resource(s) that it wants to access at the RS(s), by using the /token endpoint as specified in Section 5.8 of [RFC9200].

In general, different RSs can be associated with different ASs, even if the RSs are members of the same OSCORE group. However, assuming proper configurations and trust relations, it is possible for multiple RSs associated with the same AS to be part of a single audience (i.e., a group-audience, see Section 6.9 of [RFC9200]). In such a case, the Client can request a single Access Token intended for the group-audience, hence to all the RSs included therein. A particular group-audience might be defined as including all the RSs in the OSCORE group.

In the Access Token Request to the AS, the Client MUST include the Group Identifier of the OSCORE group and its own Sender ID in that group. The AS MUST specify these pieces of information in the Access Token.

Furthermore, in the Access Token Request to the AS, the Client MUST also include: its own authentication credential used in the OSCORE group; and a proof-of-possession (PoP) evidence to prove possession of the corresponding private key. The PoP evidence is computed over a PoP input uniquely related to the secure communication association between the Client and the AS. The AS MUST include also the authentication credential specified by the Client in the Access Token.

The Access Token Request and Response MUST be confidentiality-protected and ensure authenticity. In this profile, it is RECOMMENDED to use OSCORE [RFC8613] between the Client and the AS, to reduce the number of libraries the client has to support. Other protocols fulfilling the security requirements defined in Sections 5 and 6 of [RFC9200] MAY alternatively be used, such as TLS [RFC8446] or DTLS [RFC9147].

2.3. Access Token Uploading

After having retrieved the Access Token from the AS, the Client uploads the Access Token to the RS, by sending a POST request to the /authz-info endpoint and using the mechanisms specified in Section 5.10 of [RFC9200]. When using this profile, the communication that C has with the /authz-info endpoint is not protected.

If the Access Token is valid, the RS replies to the POST request with a 2.01 (Created) response. Also, the RS associates the received Access Token with the Group OSCORE Security Context identified by the Group Identifier specified in the Access Token, following Section 3.2 of [RFC8613]. In practice, the RS maintains a collection of Security Contexts with associated authorization information, for all the clients that it is currently communicating with. The authorization information is a policy that is used as input when processing requests from those clients.

Finally, the RS stores the association between i) the authorization information from the Access Token; and ii) the Group Identifier of the OSCORE group together with the Sender ID and the authentication credential of the Client in that group. This binds the Access Token to the Group OSCORE Security Context of the OSCORE group.

Finally, when the Client communicates with the RS using the Group OSCORE Security Context, the RS verifies that the Client is a legitimate member of the OSCORE group and especially the exact group member with the same Sender ID associated with the Access Token. This occurs when verifying a request protected with Group OSCORE, since the request includes the Client's Sender ID and either it embeds a signature computed also over that Sender ID (if protected with the group mode), or it is protected by means of pairwise symmetric keying material derived from the asymmetric keys of the two peers (if protected with the pairwise mode).

The above has considered an Access Token intended for a single RS. However, as discussed in Section 2.2, an Access Token can be intended for a group-audience including multiple RSs in the OSCORE group. In such a case, the Client could efficiently upload the Access Token to many or all of those RSs at once (e.g., over IP multicast), after which each RS individually performs the same steps described above.

2.4. Secure Communication

The Client can send a request protected with Group OSCORE [I-D.ietf-core-oscore-groupcomm] to the RS. This can be a unicast request targeting the RS, or a one-to-many group request (e.g., over IP multicast) targeting the OSCORE group where the RS is also a member. To this end, the Client uses the Group OSCORE Security Context already established upon joining the OSCORE group, e.g., by using the approach defined in [I-D.ietf-ace-key-groupcomm-oscore]. The RS may send a response back to the Client, protecting it by means of the same Group OSCORE Security Context.

3. Client-AS Communication

This section details the Access Token POST Request that the Client sends to the /token endpoint of the AS, as well as the related Access Token Response.

The Access Token MUST be bound to the public key of the Client as proof-of-possession key (pop-key), which is included in the Client's authentication credential specified in the 'cnf' claim of the Access Token.

3.1. C-to-AS: POST to Token Endpoint

The Client-to-AS request is specified in Section 5.8.1 of [RFC9200]. The Client MUST send this POST request to the /token endpoint over a secure channel that guarantees authentication, message integrity, and confidentiality.

The POST request is formatted as the analogous Client-to-AS request in the OSCORE profile of ACE (see Section 3.1 of [RFC9203]), with the following additional parameters that MUST be included in the payload.

  • 'context_id', defined in Section 3.1.1 of this document. This parameter specifies the Group Identifier (GID), i.e., the ID Context of an OSCORE group that includes as members both the Client and the RS(s) in the audience for which the Access Token is asked to be issued. In particular, the Client wishes to communicate with the RS(s) in that audience using the Group OSCORE Security Context associated with that OSCORE group.

  • 'salt_input', defined in Section 3.1.2 of this document. This parameter includes the Sender ID that the Client has in the OSCORE group whose GID is specified in the 'context_id' parameter above.

  • 'req_cnf', defined in Section 3.1 of [RFC9201]. This parameter follows the syntax from Section 3.1 of [RFC8747], and its inner confirmation value specifies the authentication credential that the Client uses in the OSCORE group. The public key included in the authentication credential will be used as the pop-key bound to the Access Token.

    At the time of writing this specification, acceptable formats of authentication credentials in Group OSCORE are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC5280], and C509 certificates [I-D.ietf-cose-cbor-encoded-cert].

    Further formats may be available in the future, and would be acceptable to use as long as they comply with the criteria compiled in Section 2.4 of [I-D.ietf-core-oscore-groupcomm]. In particular, an authentication credential has to explicitly include the public key as well as the comprehensive set of information related to the public key algorithm, including, e.g., the used elliptic curve (when applicable).

    [ As to CWTs and CCSs, the CWT Confirmation Methods 'kcwt' and 'kccs' are under pending registration requested by draft-ietf-ace-edhoc-oscore-profile. ]

    [ As to X.509 certificates, the CWT Confirmation Methods 'x5bag' and '5chain' are under pending registration requested by draft-ietf-ace-edhoc-oscore-profile. ]

    [ As to C509 certificates, the CWT Confirmation Methods 'c5b'and 'c5c' are under pending registration requested by draft-ietf-ace-edhoc-oscore-profile. ]

In addition, the Client computes its proof-of-possession (PoP) evidence, in order to prove to the AS the possession of its own private key used in the OSCORE group. This allows the AS to verify that the Client indeed owns the private key associated with the public key of the authentication credential that the Client allegedly uses in the OSCORE group.

To this end, the Client MUST use as PoP input the byte representation of an information that uniquely represents the secure communication association between the Client and the AS. It is RECOMMENDED that the Client uses the following as PoP input.

  • If the Client and the AS communicate over TLS 1.2 [RFC5246] or DTLS 1.2 [RFC6347], the PoP input is an exporter value computed as defined in Section 4 of [RFC5705], using the following inputs:

    • The exporter label "EXPORTER-ACE-PoP-Input-Client-AS", defined in Section 11.5 of this document.

    • The empty 'context value', i.e., a 'context value' of zero-length.

    • 32 as length value in bytes.

  • If the Client and the AS communicate over TLS 1.3 [RFC8446] or DTLS 1.3 [RFC9147], the PoP input is an exporter value computed as defined in Section 7.5 of [RFC8446], using the following inputs:

    • The exporter label "EXPORTER-ACE-PoP-Input-Client-AS", defined in Section 11.5 of this document.

    • The empty 'context_value', i.e., a 'context_value' of zero-length.

    • 32 as 'key_length' in bytes.

  • If the Client and the AS communicate over OSCORE [RFC8613], the PoP input is the output PRK of an HKDF-Extract step [RFC5869], i.e., PRK = HMAC-Hash(salt, IKM).

    In particular, given the OSCORE Security Context CTX shared between the Client and the AS, then the following applies.

    • 'salt' takes (x1 | x2), where | denotes byte string concatenation, while x1 and x2 are defined as follows.

      • x1 is the binary serialization of a CBOR data item. If CTX does not specify an OSCORE ID Context, the CBOR data item is the CBOR simple value null (0xf6). Otherwise, the CBOR data item is a CBOR byte string, with value the OSCORE ID Context specified in CTX.

      • x2 is the binary serialization of a CBOR byte string. The value of the CBOR byte string is the OSCORE Sender ID of the Client, which the Client stores in its Sender Context of CTX and the AS stores in its Recipient Context of CTX.

    • 'IKM' is the OSCORE Master Secret specified in CTX.

    • The used HKDF is the HKDF Algorithm specified in CTX.

    The following shows an example of input to the HMAC-Hash() function.

    On the Client side, the OSCORE Security Context shared with the AS includes:

    ID Context: 0x37cbf3210017a2d3 (8 bytes)
    
    Sender ID: 0x01 (1 byte)
    
    Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
    

    Then, the following holds.

    x1 (Raw value) (8 bytes)
    0x37cbf3210017a2d3
    
    x1 (CBOR Data Item) (9 bytes)
    0x4837cbf3210017a2d3
    
    x2 (Raw value) (1 bytes)
    0x01
    
    x2 (CBOR Data Item) (2 bytes)
    0x4101
    
    salt (11 bytes)
    0x4837cbf3210017a2d34101
    
    IKM (16 bytes)
    0x0102030405060708090a0b0c0d0e0f10
    

After that, the Client computes the PoP evidence as follows.

  • If the OSCORE group is not a pairwise-only group, the PoP evidence MUST be a signature. The Client computes the signature by using the same private key and signature algorithm it uses for signing messages in the OSCORE group. The Client's private key is the one associated with the Client's authentication credential used in the OSCORE group and specified in the 'req_cnf' parameter above.

  • If the OSCORE group is a pairwise-only group, the PoP evidence MUST be a MAC computed as follows, by using the HKDF Algorithm HKDF SHA-256, which consists of composing the HKDF-Extract and HKDF-Expand steps [RFC5869].

    MAC = HKDF(salt, IKM, info, L)

    The input parameters of HKDF are as follows.

    • salt takes as value the empty byte string.

    • IKM is computed as a cofactor Diffie-Hellman shared secret (see Section 5.7.1.2 of [NIST-800-56A]), using the ECDH algorithm that is used as Pairwise Key Agreement Algorithm in the OSCORE group. The Client uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the AS. For X25519 and X448, the procedure is described in Section 5 of [RFC7748].

      The Client's private key is the one associated with the Client's authentication credential used in the OSCORE group and specified in the 'req_cnf' parameter above. The Client may obtain the Diffie-Hellman public key of the AS during its registration process at the AS.

    • info takes as value the PoP input.

    • L is equal to 8, i.e., the size of the MAC, in bytes.

Finally, the Client MUST include one of the two following parameters in the payload of the POST request to the AS.

  • 'client_cred_verify', defined in Section 3.1.3 of this document, specifying the Client's PoP evidence as a signature, which is computed as defined above. This parameter MUST be included if and only if the OSCORE group is not a pairwise-only group.

  • 'client_cred_verify_mac', defined in Section 3.1.4 of this document, specifying the Client's PoP evidence as a MAC, which is computed as defined above. This parameter MUST be included if and only if the OSCORE group is a pairwise-only group.

An example of such a request is shown in Figure 2.

Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: application/ace+cbor
Payload:
{
  / audience /        5 : "tempSensor4711",
  / scope /           9 : "read",
    e'context_id_param' : h'abcd0000',
    e'salt_input_param' : h'00',
  e'client_cred_verify' : h'c5a6...f100' / elided for brevity /,
  / req_cnf /         4 : {
    e'kccs' : {
      / sub / 2 : "42-50-31-FF-EF-37-32-39",
      / cnf / 8 : {
        / COSE_Key / 1 : {
          / kty /  1 : 2 / EC2 /,
          / crv / -1 : 1 / P-256 /,
          / x /   -2 : h'd7cc072de2205bdc1537a543d53c60a6
                         acb62eccd890c7fa27c9e354089bbe13',
          / y /   -3 : h'f95e1d4b851a2cc80fff87d8e23f22af
                         b725d535e515d020731e79a3b4e47120'
        }
      }
    }
  }
}
Figure 2: Example C-to-AS POST /token Request for an Access Token Bound to an Asymmetric Key.

In the example above, the Client specifies that its authentication credential in the OSCORE group is the CCS shown in Figure 3.

{
  / sub / 2 : "42-50-31-FF-EF-37-32-39",
  / cnf / 8 : {
    / COSE_Key / 1 : {
      / kty /  1 : 2 / EC2 /,
      / crv / -1 : 1 / P-256 /,
      / x /   -2 : h'd7cc072de2205bdc1537a543d53c60a6
                     acb62eccd890c7fa27c9e354089bbe13',
      / y /   -3 : h'f95e1d4b851a2cc80fff87d8e23f22af
                     b725d535e515d020731e79a3b4e47120'
    }
  }
}
Figure 3: Example of Client Authentication Credential as CWT Claims Set (CCS).

[

TODO: Specify how C requests a new Access Token that dynamically updates its access rights. (See Section 3.2.1 for pre-requirements and a high-level direction)

]

3.1.1. 'context_id' Parameter

The 'context_id' parameter is an OPTIONAL parameter of the Access Token Request message defined in Section 5.8.1 of [RFC9200]. This parameter provides a value that the Client wishes to use with the RS as a hint for a security context. Its exact content is profile specific.

3.1.2. 'salt_input' Parameter

The 'salt_input' parameter is an OPTIONAL parameter of the Access Token Request message defined in Section 5.8.1 of [RFC9200]. This parameter provides a value that the Client wishes to use as part of a salt with the RS, for deriving cryptographic keying material. Its exact content is profile specific.

3.1.3. 'client_cred_verify' Parameter

The 'client_cred_verify' parameter is an OPTIONAL parameter of the Access Token Request message defined in Section 5.8.1. of [RFC9200]. This parameter provides a signature computed by the Client to prove the possession of its own private key.

3.1.4. 'client_cred_verify_mac' Parameter

The 'client_cred_verify_mac' parameter is an OPTIONAL parameter of the Access Token Request message defined in Section 5.8.1. of [RFC9200]. This parameter provides a Message Authentication Code (MAC) computed by the Client to prove the possession of its own private key.

3.2. AS-to-C: Response

After having verified the POST request to the /token endpoint and that the Client is authorized to obtain an Access Token corresponding to its Access Token Request, the AS MUST verify the proof-of-possession (PoP) evidence. In particular, the AS proceeds as follows.

  • As PoP input, the AS uses the same value used by the Client in Section 3.1.

  • As public key of the Client, the AS uses the one included in the authentication credential specified in the 'req_cnf' parameter of the Access Token Request.

    This requires the AS to support the format of the authentication credential specified in the 'req_cnf' parameter, i.e., the format of authentication credential that is used in the OSCORE group where the Client uses that authentication credential. Practically, this is not an issue, since an RS supporting this profile is expected to be registered only at an AS that supports the formats of authentication credential that the RS supports.

  • If the Access Token Request includes the 'client_cred_verify' parameter, this specifies the PoP evidence as a signature. Then, the AS verifies the signature by using the public key of the Client.

    This requires the AS to support the signature algorithm and curve (when applicable) that are used in the OSCORE group where the Client uses the authentication credential specified in the 'req_cnf' parameter of the Access Token Request. Practically, this is not an issue, since an RS supporting this profile is expected to be registered only at an AS that supports the signature algorithms and curves (when applicable) that the RS supports.

  • If the Access Token Request includes the 'client_cred_verify_mac' parameter, this specifies the PoP evidence as a Message Authentication Code (MAC).

    Then, the AS recomputes the MAC through the same process taken by the Client when preparing the value of the 'client_cred_verify_mac' parameter for the Access Token (see Section 3.1), with the difference that the AS uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the Client. The verification succeeds if and only if the recomputed MAC is equal to the MAC conveyed as PoP evidence in the Access Token Request.

    This requires the AS to support the ECDH algorithm that is used as Pairwise Key Agreement Algorithm in the OSCORE group where the Client uses the authentication credential specified in the 'req_cnf' parameter of the Access Token Request. Practically, this is not an issue, since an RS supporting this profile is expected to be registered only at an AS that supports the ECDH algorithms that the RS supports.

If both the 'client_cred_verify' and 'client_cred_verify_mac' parameters are present, or if the verification of the PoP evidence fails, the AS considers the Client request invalid.

If the Client request was invalid or not authorized, the AS returns an error response as described in Section 5.8.3 of [RFC9200].

If all verifications are successful, the AS responds as defined in Section 5.8.2 of [RFC9200]. In particular:

  • The AS can signal that the use of Group OSCORE is REQUIRED for a specific Access Token by including the 'ace_profile' parameter with the value "coap_group_oscore" in the Access Token Response. The Client MUST use Group OSCORE towards all the Resource Servers for which this Access Token is valid. Usually, it is assumed that constrained devices will be pre-configured with the necessary profile, so that this kind of profile signaling can be omitted.

  • The AS MUST NOT include the 'rs_cnf' parameter defined in [RFC9201]. In general, the AS may not be aware of the authentication credentials (and public keys included thereof) that the RSs use in the OSCORE group. Also, the Client is able to retrieve the authentication credentials of other group members from the responsible Group Manager, both upon joining the group or later on as a group member, as defined in [I-D.ietf-ace-key-groupcomm-oscore].

The AS MUST include the following information as metadata of the issued Access Token. The use of CBOR web tokens (CWT) as specified in [RFC8392] is RECOMMENDED.

  • The profile "coap_group_oscore". If the Access Token is a CWT, this is specified in the 'ace_profile' claim of the Access Token, as per Section 5.10 of [RFC9200].

  • The salt input specified in the 'salt_input' parameter of the Access Token Request. If the Access Token is a CWT, the content of the 'salt_input' parameter MUST be specified in the 'salt_input' claim of the Access Token, defined in Section 3.2.3 of this document.

  • The Context ID input specified in the 'context_id' parameter of the Access Token Request. If the Access Token is a CWT, the content of the 'context_id' parameter MUST be specified in the 'context_id' claim of the Access Token, defined in Section 3.2.2 of this document.

  • The authentication credential that the client uses in the OSCORE group and specified in the 'req_cnf' parameter of the Access Token Request.

    If the Access Token is a CWT, the Client's authentication credential MUST be specified in the 'cnf' claim, which follows the syntax from Section 3.1 of [RFC8747]. In particular, the 'cnf' claim includes the same authentication credential specified in the 'req_cnf' parameter of the Access Token Request (see Section 3.1).

Figure 4 shows an example of such an AS response. The Access Token has been truncated for readability.

Header: Created (Code=2.01)
Content-Format: application/ace+cbor
Payload:
{
  / access_token / 1 : h'8343a1010aa2044c...00', / elided for brevity /
  / ace_profile / 38 : e'coap_group_oscore',
  / expires_in /   2 : 3600
}
Figure 4: Example AS-to-C Access Token Response with the Group OSCORE Profile.

Figure 5 shows an example CWT Claims Set, containing the Client's public key in the group (as pop-key), as specified by the inner confirmation value in the 'cnf' claim.

{
  / aud /           3 : "tempSensorInLivingRoom",
  / iat /           6 : 1719820800,
  / exp /           4 : 2035353600,
  / scope /         9 : "temperature_g firmware_p",
  e'context_id_claim' : h'abcd0000',
  e'salt_input_claim' : h'00',
  / cnf /           8 : {
    e'kccs' : {
      / sub / 2 : "42-50-31-FF-EF-37-32-39",
      / cnf / 8 : {
        / COSE_Key / 1 : {
          / kty /  1 : 2 / EC2 /,
          / crv / -1 : 1 / P-256 /,
          / x /   -2 : h'd7cc072de2205bdc1537a543d53c60a6
                         acb62eccd890c7fa27c9e354089bbe13',
          / y /   -3 : h'f95e1d4b851a2cc80fff87d8e23f22af
                         b725d535e515d020731e79a3b4e47120'
        }
      }
    }
  }
}
Figure 5: Example CWT Claims Set.

The same CWT Claims Set as in Figure 5 and encoded in CBOR is shown in Figure 6, using the value abbreviations defined in [RFC9200] and [RFC8747]. The bytes in hexadecimal are reported in the first column, while their corresponding CBOR meaning is reported after the "#" sign on the second column, for easiness of readability.

Editor's note: it should be checked (and in case fixed) that the values used below (which are not yet registered) are the final values registered by IANA.

A7                                      # map(7)
   03                                   # unsigned(3)
   76                                   # text(22)
      74656D7053656E736F72496E4C6976696E67526F6F6D
      # "tempSensorInLivingRoom"
   06                                   # unsigned(6)
   1A 66826200                          # unsigned(1719820800)
   04                                   # unsigned(4)
   1A 79510800                          # unsigned(2035353600)
   09                                   # unsigned(9)
   78 18                                # text(24)
      74656D70657261747572655F67206669726D776172655F70
      # "temperature_g firmware_p"
   18 33                                # unsigned(51)
   44                                   # bytes(4)
      ABCD0000
   18 34                                # unsigned(52)
   41                                   # bytes(1)
      00
   08                                   # unsigned(8)
   A1                                   # map(1)
      0E                                # unsigned(14)
      A2                                # map(2)
         02                             # unsigned(2)
         77                             # text(23)
            34322D35302D33312D46462D45462D33372D33322D3339
            # "42-50-31-FF-EF-37-32-39"
         08                             # unsigned(8)
         A1                             # map(1)
            01                          # unsigned(1)
            A4                          # map(4)
               01                       # unsigned(1)
               02                       # unsigned(2)
               20                       # negative(0)
               01                       # unsigned(1)
               21                       # negative(1)
               58 20                    # bytes(32)
                  D7CC072DE2205BDC1537A543D53C60A6
                  ACB62ECCD890C7FA27C9E354089BBE13
               22                       # negative(2)
               58 20                    # bytes(32)
                  F95E1D4B851A2CC80FFF87D8E23F22AF
                  B725D535E515D020731E79A3B4E47120
Figure 6: Example CWT Claims Set Using CBOR Encoding.

3.2.1. Update of Access Rights

[

TODO: Specify how the AS issues an Access Token that dynamically updates the access rights of C. (See below for pre-requirements and a high-level direction)

(This should be specified with content in the present section, as well as in Section 3.1 and Section 4.4).

At the moment, this profile does not support the dynamic update of access rights for the Client like other transport profiles of ACE do.

This can be enabled by building on concepts defined in [I-D.ietf-ace-workflow-and-params]:

  • "Token series" - In this profile, it would be specialized as a set of consecutive Access Tokens issued by the AS for the pair (C, AUD), where C is the Client whose public authentication credential is bound to those Access Tokens, while AUD is the audience for which C requests those Access Tokens.

  • "token_series_id" - At the time of writing, [I-D.ietf-ace-workflow-and-params] describes the intended direction for defining this new prospective parameter, to be used in the Access Token Request/Response exchange between C and the AS.

    This parameter is meant to specify the unique identifier of a token series. In parallel, it is planned to define a new, corresponding claim to include into Access Tokens.

At a high-level, the above can enable the dynamic update of access rights as follows:

  • Each Access Token in a token series includes the claim "token_series_id", with value the identifier of the token series that the Access Token belongs to.

  • When issuing the first Access Token in a token series, the AS includes the parameter "token_series_id" in the Access Token Response to the Client, with value the identifier of the token series that the Access Token belongs to.

  • When C requests from the AS an Access Token that dynamically updates its current access rights to access protected resources at the same audience, C sends to the AS an Access Token Request such that:

    • It includes the parameter "token_series_id", with value the identifier of the token series for which the new Access Token is requested.

    • It does not include the parameters "context_id", "salt_input", and "client_cred_verify" or "client_cred_verify_mac".

  • If the AS issues the new Access Token that dynamically updated the access rights of C, then the Access Token includes the claim "token_series_id", with value the identifier of the same token series for which the Access Token has been issued.

When receiving the new Access Token, the RS uses the value of the claim "token_series_id", and identifies the stored old Access Token that has to be superseded by the new one, as both belonging to the same token series.

]

3.2.2. 'context_id' Claim

The 'context_id' claim provides a value that the Client requesting the Access Token wishes to use with the RS, as a hint for a security context.

This parameter specifies the value of the Context ID input, encoded as a CBOR byte string.

3.2.3. 'salt_input' Claim

The 'salt_input' claim provides a value that the Client requesting the Access Token wishes to use as a part of a salt with the RS, e.g., for deriving cryptographic material.

This parameter specifies the value of the salt input, encoded as a CBOR byte string.

4. Client-RS Communication

This section details the POST request and response to the /authz-info endpoint between the Client and the RS.

The proof-of-possession required to bind the Access Token to the Client is explicitly performed when the RS receives and verifies a request from the Client protected with Group OSCORE, either with the group mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]) or with the pairwise mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]).

In particular, the RS uses the Client's public key bound to the Access Token, either when verifying the signature of the request (if protected with the group mode), or when verifying the request as integrity-protected with pairwise keying material derived from the two peers' authentication credentials and asymmetric keys (if protected with the pairwise mode). In either case, the RS also authenticates the Client.

Similarly, when receiving a protected response from the RS, the Client uses the RS's public key either when verifying the signature of the response (if protected with the group mode), or when verifying the response as integrity-protected with pairwise keying material derived from the two peers' authentication credentials and asymmetric keys (if protected with the pairwise mode). In either case, the Client also authenticates the RS. Mutual authentication is only achieved after the client has successfully verified the protected response from the RS.

Therefore, an attacker using a stolen Access Token cannot generate a valid Group OSCORE message as protected through the Client's private key, and thus cannot prove possession of the pop-key bound to the Access Token. Also, if a Client legitimately owns an Access Token but has not joined the OSCORE group, it cannot generate a valid Group OSCORE message, as it does not store the necessary keying material shared among the group members.

Furthermore, a Client C1 is supposed to obtain a valid Access Token from the AS, as specifying its own authentication credential (and the public key included thereof) associated with the its own private key used in the OSCORE group, together with its own Sender ID in that OSCORE group (see Section 3.1). This allows the RS receiving the Access Token to verify with the Group Manager of that OSCORE group whether such a Client indeed has that Sender ID and uses that authentication credential in the OSCORE group.

As a consequence, a different Client C2, also member of the same OSCORE group, is not able to impersonate C1, by: i) getting a valid Access Token, specifying the Sender ID of C1 and a different (made-up) authentication credential; ii) successfully posting the Access Token to the RS; and then iii) attempting to communicate using Group OSCORE impersonating C1, while blaming C1 for the consequences.

4.1. C-to-RS POST to authz-info Endpoint

The Client uploads the Access Token to the /authz-info endpoint of the RS, as defined in Section 5.10.1 of [RFC9200].

4.2. RS-to-C: 2.01 (Created)

The RS MUST verify the validity of the Access Token as defined in Section 5.10.1 of [RFC9200], with the following additions.

  • The RS MUST check that the claims 'salt_input', 'context_id', and 'cnf' are included in the Access Token.

  • The RS considers: the content of the 'context_id' claim as the GID of the OSCORE group; the content of the 'salt_input' claim as the Sender ID that the Client has in the group; and the inner confirmation value of the 'cnf' claim as the authentication credential that the Client uses in the group.

    The RS MUST check whether it already stores the authentication credential specified in the inner confirmation value of the 'cnf' claim as associated with the pair (GID, Sender ID) above.

    If this is not the case, the RS MUST request the Client's authentication credential to the Group Manager of the OSCORE group as described in Section 9.3 of [I-D.ietf-ace-key-groupcomm-oscore], specifying the Client's Sender ID in the OSCORE group, i.e., the value of the 'salt_input' claim. Then, the RS performs the following actions.

    • The RS MUST check whether the Client's authentication credential retrieved from the Group Manager matches the one retrieved from the inner confirmation value of the 'cnf' claim of the Access Token.

    • The RS MUST check whether the Client's Sender ID provided by the Group Manager together with the Client's authentication credential matches the one retrieved from the 'salt_input' claim of the Access Token.

If any of the checks above fails, the RS MUST consider the Access Token invalid, and MUST reply to the Client with an error response code equivalent to the CoAP code 4.00 (Bad Request).

If the Access Token is valid and further checks on its content are successful, the RS associates the authorization information from the Access Token with the Group OSCORE Security Context.

In particular, the RS associates the authorization information from the Access Token with the triple (GID, SaltInput, AuthCred), where GID is the Group Identifier of the OSCORE group, while SaltInput and AuthCred are the Sender ID and the authentication credential that the Client uses in that OSCORE group, respectively.

The RS MUST keep this association up-to-date over time, as the triple (GID, SaltInput, AuthCred) associated with the Access Token might change. In particular:

As defined in Section 5, a possible change of the Client's authentication credential requires the Client to upload to the RS a new Access Token bound to the new authentication credential.

Finally, the RS MUST send a 2.01 (Created) response to the Client, as defined in Section 5.10.1 of [RFC9200].

4.3. Client-RS Secure Communication

When previously joining the OSCORE group, both the Client and the RS have already established the related Group OSCORE Security Context to communicate as group members. Therefore, they can simply start to securely communicate using Group OSCORE, without deriving any additional keying material or security association.

If the Client or the RS delete an Access Token (e.g., when the Access Token has expired or has been revoked), it MUST NOT delete the related Group OSCORE Security Context.

4.3.1. Client Side

After having received the 2.01 (Created) response from the RS, following the POST request to the /authz-info endpoint, the Client starts the communication with the RS, by sending a request protected with Group OSCORE using the Group OSCORE Security Context [I-D.ietf-core-oscore-groupcomm].

When communicating with the RS to access the resources as specified by the authorization information, the Client MUST use the Group OSCORE Security Context of the pertinent OSCORE group, whose GID was specified in the 'context_id' parameter of the Access Token Request.

4.3.2. Resource Server Side

After successful validation of the Access Token as defined in Section 4.2 and after having sent the 2.01 (Created) response, the RS can start to communicate with the Client using Group OSCORE [I-D.ietf-core-oscore-groupcomm].

When processing an incoming request protected with Group OSCORE, the RS MUST consider as valid Client's authentication credential only the one associated with the stored Access Token. As defined in Section 5, a possible change of the Client's authentication credential requires the Client to upload to the RS a new Access Token bound to the new authentication credential.

For every incoming request, if Group OSCORE verification succeeds, the verification of access rights is performed as described in Section 4.5.

If the RS receives a request protected with a Group OSCORE Security Context CTX, the target resource requires authorization, and the RS does not store a valid Access Token related to CTX, then the RS MUST reply with a 4.01 (Unauthorized) error response protected with CTX.

4.4. Update of Access Rights

[

TODO: Specify the processing on the RS when receiving an Access Token that dynamically updates the access rights of C. (See Section 3.2.1 for pre-requirements and a high-level direction)

]

4.5. Access Rights Verification

The RS MUST follow the procedures defined in Section 5.10.2 of [RFC9200]. If an RS receives a request protected with Group OSCORE from a Client, the RS processes the request according to [I-D.ietf-core-oscore-groupcomm].

If the Group OSCORE verification succeeds and the target resource requires authorization, the RS retrieves the authorization information from the Access Token associated with the Group OSCORE Security Context. Then, the RS MUST verify that the action requested on the resource is authorized.

If the RS has no valid Access Token for the Client, the RS MUST reject the request and MUST reply to the Client with a 4.01 (Unauthorized) error response.

If the RS has an Access Token for the Client but no actions are authorized on the target resource, the RS MUST reject the request and MUST reply to the Client with a 4.03 (Forbidden) error response.

If the RS has an Access Token for the Client but the requested action is not authorized, the RS MUST reject the request and MUST reply to the Client with a 4.05 (Method Not Allowed) error response.

4.6. Storing Multiple Access Tokens per PoP-Key

According to Section 5.10.1 of [RFC9200], an RS is recommended to store only one Access Token per proof-of-possession key (pop-key), and to supersede such an Access Token when receiving and successfully validating a new one bound to the same pop-key.

However, when using the profile specified in this document, an RS might practically have to deviate from that recommendation and store multiple Access Tokens bound to the same pop-key, i.e., to the same public authentication credential of a Client.

For example, this can occur in the following cases.

  • The RS is the single RS associated with an audience AUD1, and also belongs to a group-audience AUD2 (see Section 6.9 of [RFC9200]).

    A Client C with public authentication credential AUTH_CRED_C can request two Access Tokens T1 and T2 from the AS, such that:

    • T1 targets AUD1 and has scope SCOPE1;

    • T2 targets AUD2 and has scope SCOPE2 different from SCOPE1.

    Both T1 and T2 are going to be bound to the same pop-key specified by AUTH_CRED_C.

    In fact, if the AS issues Access Tokens targeting a group-audience, then the above can possibly be the case when using any transport profile of ACE that supports asymmetric pop-keys. If so, the RS should be ready to store at minimum one Access Token per pop-key per audience it belongs to.

  • The RS is a member of two OSCORE groups G1 and G2. In particular, both the same format of public authentication credentials is used in both OSCORE groups.

    A Client C with public authentication credential AUTH_CRED_C of such format, also member of the two OSCORE group G1 and G2, can conveniently use AUTH_CRED_C as its public authentication credential in both those groups. Therefore, C can request two Access Tokens T1 and T2 from the AS, such that:

    • T1 targets RS and reflects the membership of C in G1, as per its claims "context_id" and "salt_input";

    • T2 targets RS and reflects the membership of C in G2, as per its claims "context_id" and "salt_input".

    Both T1 and T2 are going to be bound to the same pop-key specified by AUTH_CRED_C.

    When using the profile specified in this document, the RS should be ready to store at minimum one Access Token per pop-key per OSCORE group it is a member of (although, per the previous point, even this can be limiting).

  • The RS uses both the profile specified in this document and a different transport profile of ACE that also relies on asymmetric pop-keys, e.g., the EDHOC and OSCORE profile defined in [I-D.ietf-ace-edhoc-oscore-profile].

    In such a case, a Client C with public authentication credential AUTH_CRED_C can request two Access Tokens T1 and T2 from the AS, such that:

    • T1 targets RS and is meant to be used according to the Group OSCORE profile defined in this document;

    • T2 targets RS and is meant to be used according to the EDHOC and OSCORE profile defined in [I-D.ietf-ace-edhoc-oscore-profile].

    Both T1 and T2 are going to be bound to the same pop-key specified by AUTH_CRED_C.

    When using multiple transport profiles of ACE that rely on asymmetric pop-keys, it is reasonable that the RS is capable to store at minimum one Access Token per pop-key per used profile (although, per the previous points, even this can be limiting).

5. Change of Client's Authentication Credential in the Group

During its membership in the OSCORE group, the Client might change the authentication credential that it uses in the group. When this happens, the Client uploads the new authentication credential to the Group Manager, as defined in Section 9.4 of [I-D.ietf-ace-key-groupcomm-oscore].

After that, and in order to continue communicating with the RS, the Client MUST perform the following actions.

  1. The Client requests a new Access Token to the AS, as defined in Section 3. In particular, when sending the Access Token Request as defined in Section 3.1, the Client specifies:

    • The current Group Identifier of the OSCORE group, as value of the 'context_id' parameter.

    • The current Sender ID that it has in the OSCORE group, as value of the 'salt_input' parameter.

    • The new authentication credential that it uses in the OSCORE group, as inner confirmation value of the 'req_cnf' parameter.

    • The proof-of-possession (PoP) evidence corresponding to the public key of the new authentication credential, as value of the 'client_cred_verify' or 'client_cred_verify_mac' parameter.

  2. After receiving the Access Token Response from the AS (see Section 3.2), the Client performs the same exchanges with the RS as defined in Section 4.

When receiving the new Access Token, the RS performs the same steps defined in Section 4.2, with the following addition in case the new Access Token is successfully verified and stored:

6. Secure Communication with the AS

As specified in the ACE framework (see Sections 5.8 and 5.9 of [RFC9200]), the requesting entity (Client and/or RS) and the AS communicate via the /token or /introspection endpoint. The use of CoAP and OSCORE [RFC8613] for this communication is RECOMMENDED in this profile. Other protocols fulfilling the security requirements defined in Sections 5 and 6 of [RFC9200] (such as HTTP and DTLS or TLS) MAY be used instead.

If OSCORE [RFC8613] is used, the requesting entity and the AS are expected to have a pre-established Security Context in place. How this Security Context is established is out of the scope of this profile. Furthermore, the requesting entity and the AS communicate using OSCORE through the /token endpoint as specified in Section 5.8 of [RFC9200], and through the /introspection endpoint as specified in Section 5.9 of [RFC9200].

7. Discarding the Security Context

As members of an OSCORE group, the Client and the RS may independently leave the group or be forced to, e.g., if compromised or suspected so. Upon leaving the OSCORE group, the Client or RS also discards the Group OSCORE Security Context, which may anyway be renewed by the Group Manager through a group rekeying process (see Section 3.2 of [I-D.ietf-core-oscore-groupcomm]).

The Client or RS can acquire a new Group OSCORE Security Context, by re-joining the OSCORE group, e.g., by using the approach defined in [I-D.ietf-ace-key-groupcomm-oscore]. In such a case, the Client SHOULD request a new Access Token to be uploaded to the RS.

8. CBOR Mappings

The new parameters defined in this document MUST be mapped to CBOR types as specified in Table 1, using the given integer abbreviation for the map key.

Table 1: CBOR Mappings for New Parameters.
Parameter name CBOR Key Value Type
context_id TBD bstr
salt_input TBD bstr
client_cred_verify TBD bstr
client_cred_verify_mac TBD bstr

The new claims defined in this document MUST be mapped to CBOR types as specified in Table 2, using the given integer abbreviation for the map key.

Table 2: CBOR Mappings for New Claims.
Claim name CBOR Key Value Type
context_id TBD bstr
salt_input TBD bstr

9. Security Considerations

This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework [RFC9200]. Thus, the general security considerations from the ACE framework also apply to this profile.

The proof-of-possession (PoP) key bound to an Access Token is always an asymmetric key, i.e., the public key included in the authentication credential that the Client uses in the OSCORE group. This means that there is never a same shared secret used as PoP key with possible multiple RSs. Therefore, it is possible and safe for the AS to issue an Access Token for an audience that includes multiple RSs (i.e., a group-audience, see Section 6.9 of [RFC9200]).

In such a case, as per Section 6.1 of [RFC9200], the AS has to ensure the integrity protection of the Access Token by protecting it through an asymmetric signature. In addition, the used group-audience has to correctly identify all the RSs that are intended recipients of the Access Token, and for which the single scope specified in the Access Token applies. As a particular case, the audience can be the name of the OSCORE group, if the Access Token is intended for all the RSs in that group.

Furthermore, this document inherits the general security considerations about Group OSCORE [I-D.ietf-core-oscore-groupcomm], as to the specific use of Group OSCORE according to this profile.

Group OSCORE is designed to secure point-to-point as well as point-to-multipoint communications, providing a secure binding between a single request and multiple corresponding responses. In particular, Group OSCORE fulfills the same security requirements of OSCORE.

Group OSCORE ensures source authentication of messages both in group mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]) and in pairwise mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]).

When protecting an outgoing message in group mode, the sender uses its private key to compute a digital signature, which is embedded in the protected message. The group mode can be used to protect messages sent to multiple recipients (e.g., over IP multicast) or to a single recipient.

When protecting an outgoing message in pairwise mode, the sender uses a pairwise symmetric key, as derived from the asymmetric keys of the two peers exchanging the message. The pairwise mode can be used to protect only messages intended for a single recipient.

10. Privacy Considerations

This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework [RFC9200]. Thus the general privacy considerations from the ACE framework also apply to this profile.

As this profile uses Group OSCORE, the privacy considerations from [I-D.ietf-core-oscore-groupcomm] apply to this document as well.

An unprotected response to an unauthorized request may disclose information about the RS and/or its existing relationship with the Client. It is advisable to include as little information as possible in an unencrypted response. However, since both the Client and the RS share a Group OSCORE Security Context, unauthorized, yet protected requests are followed by protected responses, which can thus include more detailed information.

Although it may be encrypted, the Access Token is sent in the clear to the /authz-info endpoint at the RS. Thus, if the Client uses the same single Access Token from multiple locations with multiple Resource Servers, it can risk being tracked through the Access Token's value.

Note that, even though communications are protected with Group OSCORE, some information might still leak, due to the observable size, source address, and destination address of exchanged messages.

11. IANA Considerations

This document has the following actions for IANA.

Note to RFC Editor: Please replace "[RFC-XXXX]" with the RFC number of this document and delete this paragraph.

11.1. ACE Profiles Registry

IANA is asked to add the following entry to the "ACE Profiles" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group, following the procedure specified in Section 8.8 of [RFC9200].

  • Name: coap_group_oscore

  • Description: Profile to secure communications between constrained nodes using the Authentication and Authorization for Constrained Environments framework, by enabling authentication and fine-grained authorization of members of an OSCORE group that use a pre-established Group OSCORE Security Context to communicate with Group OSCORE.

  • CBOR Value: TBD (value between 1 and 255)

  • Reference: [RFC-XXXX]

11.2. OAuth Parameters Registry

IANA is asked to add the following entries to the "OAuth Parameters" registry, following the procedure specified in Section 11.2 of [RFC6749].

  • Name: "context_id"

  • Parameter Usage Location: token request

  • Change Controller: IETF

  • Reference: Section 3.1.1 of [RFC-XXXX]


  • Name: "salt_input"

  • Parameter Usage Location: token request

  • Change Controller: IETF

  • Reference: Section 3.1.2 of [RFC-XXXX]


  • Name: "client_cred_verify"

  • Parameter Usage Location: token request

  • Change Controller: IETF

  • Reference: Section 3.1.3 of [RFC-XXXX]


  • Name: "client_cred_verify_mac"

  • Parameter Usage Location: token request

  • Change Controller: IETF

  • Reference: Section 3.1.4 of [RFC-XXXX]

11.3. OAuth Parameters CBOR Mappings Registry

IANA is asked to add the following entries to the "OAuth Parameters CBOR Mappings" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group, following the procedure specified in Section 8.10 of [RFC9200].



  • Name: "client_cred_verify"

  • CBOR Key: TBD

  • Value Type: bstr

  • Reference: Section 3.1.3 of [RFC-XXXX]


  • Name: "client_cred_verify_mac"

  • CBOR Key: TBD

  • Value Type: bstr

  • Reference: Section 3.1.4 of [RFC-XXXX]

11.4. CBOR Web Token (CWT) Claims Registry

IANA is asked to add the following entries to the "CBOR Web Token (CWT) Claims" registry, following the procedure specified in Section 9.1 of [RFC8392].

  • Claim Name: "context_id"

  • Claim Description: Client provided Context ID

  • JWT Claim Name: "N/A"

  • Claim Key: TBD

  • Claim Value Type: bstr

  • Change Controller: IETF

  • Reference: Section 3.2.2 of [RFC-XXXX]


  • Claim Name: "salt_input"

  • Claim Description: Client provided salt input

  • JWT Claim Name: "N/A"

  • Claim Key: TBD

  • Claim Value Type: bstr

  • Change Controller: IETF

  • Reference: Section 3.2.3 of [RFC-XXXX]

11.5. TLS Exporter Label Registry

IANA is asked to add the following entry to the "TLS Exporter Label" registry within the "Transport Layer Security (TLS) Parameters" registry group, following the procedure specified in Section 6 of [RFC5705] and updated in Section 12 of [RFC8447].

  • Value: EXPORTER-ACE-PoP-Input-Client-AS

  • DTLS-OK: Y

  • Recommended: N

  • Reference: Section 3.1 of [RFC-XXXX]

12. References

12.1. Normative References

[I-D.ietf-ace-key-groupcomm-oscore]
Tiloca, M., Park, J., and F. Palombini, "Key Management for OSCORE Groups in ACE", Work in Progress, Internet-Draft, draft-ietf-ace-key-groupcomm-oscore-16, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-16>.
[I-D.ietf-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication for the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-11>.
[I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., and R. Höglund, "Group Object Security for Constrained RESTful Environments (Group OSCORE)", Work in Progress, Internet-Draft, draft-ietf-core-oscore-groupcomm-21, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-21>.
[NIST-800-56A]
Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography - NIST Special Publication 800-56A, Revision 3", , <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5246]
Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, , <https://www.rfc-editor.org/rfc/rfc5246>.
[RFC5705]
Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, , <https://www.rfc-editor.org/rfc/rfc5705>.
[RFC5869]
Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, , <https://www.rfc-editor.org/rfc/rfc5869>.
[RFC6347]
Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, , <https://www.rfc-editor.org/rfc/rfc6347>.
[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <https://www.rfc-editor.org/rfc/rfc6749>.
[RFC7252]
Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, , <https://www.rfc-editor.org/rfc/rfc7252>.
[RFC7748]
Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, , <https://www.rfc-editor.org/rfc/rfc7748>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8392]
Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, , <https://www.rfc-editor.org/rfc/rfc8392>.
[RFC8447]
Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, , <https://www.rfc-editor.org/rfc/rfc8447>.
[RFC8610]
Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, , <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC8613]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, , <https://www.rfc-editor.org/rfc/rfc8613>.
[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, , <https://www.rfc-editor.org/rfc/rfc8747>.
[RFC8949]
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/rfc/rfc8949>.
[RFC9052]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9053]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, , <https://www.rfc-editor.org/rfc/rfc9053>.
[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, , <https://www.rfc-editor.org/rfc/rfc9200>.
[RFC9201]
Seitz, L., "Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE)", RFC 9201, DOI 10.17487/RFC9201, , <https://www.rfc-editor.org/rfc/rfc9201>.
[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, , <https://www.rfc-editor.org/rfc/rfc9203>.

12.2. Informative 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-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-edhoc-oscore-profile-04>.
[I-D.ietf-ace-workflow-and-params]
Tiloca, M. and G. Selander, "Alternative Workflow and OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework", Work in Progress, Internet-Draft, draft-ietf-ace-workflow-and-params-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-workflow-and-params-02>.
[I-D.ietf-cose-cbor-encoded-cert]
Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and M. Furuhed, "CBOR Encoded X.509 Certificates (C509 Certificates)", Work in Progress, Internet-Draft, draft-ietf-cose-cbor-encoded-cert-09, , <https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-09>.
[I-D.tiloca-core-oscore-discovery]
Tiloca, M., Amsüss, C., and P. Van der Stok, "Discovery of OSCORE Groups with the CoRE Resource Directory", Work in Progress, Internet-Draft, draft-tiloca-core-oscore-discovery-15, , <https://datatracker.ietf.org/doc/html/draft-tiloca-core-oscore-discovery-15>.
[NIST-800-207]
Rose, S., Borchert, O., Mitchell, S., and S. Connelly, "Zero Trust Architecture - NIST Special Publication 800-207", , <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf>.
[RFC5280]
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/rfc/rfc5280>.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/rfc/rfc8446>.
[RFC9147]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, , <https://www.rfc-editor.org/rfc/rfc9147>.
[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, , <https://www.rfc-editor.org/rfc/rfc9202>.
[RFC9431]
Sengul, C. and A. Kirby, "Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework", RFC 9431, DOI 10.17487/RFC9431, , <https://www.rfc-editor.org/rfc/rfc9431>.

Appendix A. Profile Requirements

This appendix lists the specifications of this profile based on the requirements of the ACE framework, as requested in Appendix C of [RFC9200].

Appendix B. CDDL Model

This section is to be removed before publishing as an RFC.

; ACE Profiles
coap_group_oscore = 5

; OAuth Parameters CBOR Mappings
context_id_param = 71
salt_input_param = 72
client_cred_verify = 73
client_cred_verify_mac = 74

; CBOR Web Token (CWT) Claims
context_id_claim = 51
salt_input_claim = 52

; CWT Confirmation Methods
kccs = 14
Figure 7: CDDL model

Appendix C. Document Updates

This section is to be removed before publishing as an RFC.

C.1. Version -01 to -02

  • CBOR diagnostic notation uses placeholders from a CDDL model.

  • Renamed the claim 'contextId_input' to 'context_id'.

  • Revised examples.

  • Placeholders and early direction for dynamic update of access rights.

  • Added text on storing multiple Access Tokens per PoP-Key on the RS.

  • Fixes in the IANA considerations.

  • Editorial fixes and improvements.

C.2. Version -00 to -01

  • Deleting an Access Token does not delete the Group OSCORE Security Context.

  • Distinct computation of the PoP input when C and the AS use (D)TLS 1.2 or 1.3.

  • Revised computation of the PoP input when C and the AS use OSCORE.

  • Revised computation of the PoP evidence when the OSCORE group is a pairwise-only group.

  • Clarified requirements on the AS for verifying the PoP evidence.

  • Renamed the TLS Exporter Label for computing the PoP input.

  • Editorial fixes and improvements.

Acknowledgments

Ludwig Seitz contributed as a co-author of initial versions of this document.

The authors sincerely thank Christian Amsüss, Benjamin Kaduk, John Preuß Mattsson, Dave Robin, Jim Schaad, and Göran Selander for their comments and feedback.

The work on this document has been partly supported by the Sweden's Innovation Agency VINNOVA and the Celtic-Next projects CRITISEC and CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).

Authors' Addresses

Marco Tiloca
RISE AB
Isafjordsgatan 22
SE-16440 Stockholm Kista
Sweden
Rikard Höglund
RISE AB
Isafjordsgatan 22
SE-16440 Stockholm Kista
Sweden
Francesca Palombini
Ericsson AB
Torshamnsgatan 23
SE-16440 Stockholm Kista
Sweden