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

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 also 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.¶

• Pairwise-only group: an OSCORE group that uses only the pairwise mode of Group OSCORE (see Section 8 of [I-D.ietf-core-oscore-groupcomm]).¶

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 parameters' keys 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.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. Requesting an Access Token

This profile requires that the client requests 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 to the AS. 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.¶

If the request from the client is granted, then the AS can send back the issued access token in the Access Token Response to the client, or instead upload the access token directly to the RS as described in the alternative workflow defined in [I-D.ietf-ace-workflow-and-params]. This document focuses on the former option (also shown in the example in Figure 1), while the latter option is not detailed further here.¶

The Access Token Request and Response exchanged between the client and the AS 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 that 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 (see Section 2.1.3 of [I-D.ietf-core-oscore-groupcomm]). 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 (see Section 2 of [I-D.ietf-core-oscore-groupcomm]). 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.1. Preliminary Operations

The following considers a client that is a member of an OSCORE group G with GID* as current Group Identifier (GID), within which the client currently has SID* as Sender ID and uses a public authentication credential AUTH_CRED_C that specifies the PoP key K.¶

The client MUST perform the following steps, before requesting an access token to be bound to AUTH_CRED_C (hence to the PoP key K) and to be associated with the client's membership in group G through the values GID* and SID*.¶

1. The client checks whether it is a member of any two OSCORE groups G1 and G2 such that all the following conditions hold.¶

   • Both groups have GID* as current GID.¶

   • The client uses SID* as Sender ID in both groups.¶

   • The client uses the same AUTH_CRED_C in both groups.¶

2. If such two groups G1 and G2 are found at Step 2, then the client moves to Step 3. Otherwise, the client terminates this algorithm and proceeds with requesting the access token as defined in Section 3.2.¶

3. The client can choose to terminate this algorithm and perform it again later on.¶

   Alternatively, the client can alter its current group memberships, in order to ensure that two groups like G1 and G2 cannot be determined. To this end, the client has two available options.¶

   • The client leaves some of the OSCORE groups that could be determined as groups like G1 and G2 (see Section 9.11 of [I-D.ietf-ace-key-groupcomm-oscore]).¶

   • The client obtains a new Sender ID in some of the OSCORE groups that could be determined as groups like G1 and G2. To this end, the client can request a new Sender ID in a group to the Group Manager responsible for that group (see Section 9.2 of [I-D.ietf-ace-key-groupcomm-oscore]), or re-join a group thereby obtaining a new Sender ID in that group (see Section 6 of [I-D.ietf-ace-key-groupcomm-oscore]).¶

   Finally, the client moves to Step 1.¶

3.2. 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.2.1 of this document. This parameter specifies the 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.2.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 12.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 12.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 representation 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 representation 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.2.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.2.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: 19 (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'
        }
      }
    }
  }
}

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'
    }
  }
}

[¶

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

]¶

3.3. 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.2.¶

• 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.2), 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].¶

• According to this document, the AS includes the 'access_token' parameter specifying the issued access token in the Access Token Response. An alternative workflow where the access token is uploaded by the AS directly to the RS is described in [I-D.ietf-ace-workflow-and-params].¶

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.3.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.3.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.2).¶

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: 19 (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 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'
        }
      }
    }
  }
}

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

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 checks that the claims 'context_id', 'salt_input', and 'cnf' are included in the access token.¶

  If any of these claims are missing or malformed, 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).¶

  Otherwise, the RS retrieves:¶

  • GID* as the GID of the OSCORE group, specified in the 'context_id' claim.¶

  • SID* as the Sender ID that the client has in the OSCORE group, specified in the 'salt_input' claim.¶

  • AUTH_CRED_C* as the authentication credential that the client uses in the OSCORE group, specified in the inner confirmation value of the 'cnf' claim.¶

• The RS builds GROUPS as the set of OSCORE groups such that all the following conditions hold, for each group G in the set.¶

  • The RS is a member of the group G.¶

  • The group G has GID* as current GID.¶

  • The audience targeted by the access token is consistent with using the group G for accessing protected resources hosted by the RS.¶

  If no such group is found, 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).¶

  Otherwise, for each of the N >= 1 groups G in the set GROUPS, the RS MUST request to the corresponding Group Manager the authentication credential that the client uses in G, specifying SID* in the request sent to the Group Manager (see Section 9.3 of [I-D.ietf-ace-key-groupcomm-oscore]).¶

  When receiving a successful response from each of the Group Managers, the RS MUST check whether the client's authentication credential AUTH_CRED_C retrieved from the Group Manager is equal to AUTH_CRED_C* retrieved from the access token.¶

  If any of the following conditions hold, the RS MUST consider the access token invalid, and MUST reply to the client with an error response code equivalent to the CoAP code 5.03 (Service Unavailable).¶

  • None or more than one of the Group Managers provide the RS with a successful response where the conveyed AUTH_CRED_C is equal to AUTH_CRED_C*.¶

  • After having performed a maximum, pre-configured amount of attempts, or after a maximum, pre-configured amount of time has elapsed, less than N Group Managers have sent a successful response to the RS.¶

  The process above is successful if and only if the RS receives a successful response from all the N Group Managers, and exactly one of such responses conveys AUTH_CRED_C equal to AUTH_CRED_C*. This ensures that there is only one OSCORE group G* such that: the client and the RS are both its members; it has GID* as current GID; and the client uses SID* as Sender ID in the group. In turn, this will ensure that the RS can bound the access token to such single OSCORE group G*.¶

If the operations above are successful, the access token is valid, and further checks on its content are successful, then the RS associates the authorization information from the access token with the Group OSCORE Security Context of the OSCORE group G*.¶

In particular, the RS associates the authorization information from the access token with the quartet (GID, SaltInput, AuthCred, AuthCredGM), where:¶

• GID is the Group Identifier of G* (i.e., GID*).¶

• SaltInput is the Sender ID that the client uses in G* (i.e., SID*).¶

• AuthCred is the authentication credential that the client uses in G* (i.e., AUTH_CRED_C*).¶

• AuthCredGM is the authentication credential of the Group Manager responsible for G* (see Section 2.1.6 of [I-D.ietf-core-oscore-groupcomm]).¶

The RS MUST keep this association up-to-date over time, as the quartet (GID, SaltInput, AuthCred, AuthCredGM) associated with the access token might change. In particular:¶

• If the OSCORE group is rekeyed (see Section 12.2 of [I-D.ietf-core-oscore-groupcomm] and Section 11 of [I-D.ietf-ace-key-groupcomm-oscore]), the Group Identifier also changes in the group, and the new one replaces the current 'GID' value in the quartet (GID, SaltInput, AuthCred, AuthCredGM).¶

• If the client requests and obtains a new OSCORE Sender ID from the Group Manager (see Section 2.6.3.1 of [I-D.ietf-core-oscore-groupcomm] and Section 9.2 of [I-D.ietf-ace-key-groupcomm-oscore]), the new Sender ID replaces the current 'SaltInput' value in the quartet (GID, SaltInput, AuthCred, AuthCredGM).¶

• If the Group Manager of the OSCORE group changes its authentication credential, the new authentication credential of the Group Manager replaces the current 'AuthCredGM' value in the quartet (GID, SaltInput, AuthCred, AuthCredGM).¶

  In order to obtain the latest authentication credential of the Group Manager, the RS can re-join the group (see Section 6 of [I-D.ietf-ace-key-groupcomm-oscore]) or send a dedicated request to the Group Manager (see Section 9.3 of [I-D.ietf-ace-key-groupcomm-oscore]).¶

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 either of the client or the RS deletes 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. The client MAY request a new access token from the AS, to be uploaded to the RS for re-enabling access to protected resources for the client.¶

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.3.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.¶

In particular, the RS retrieves the access token associated with the quartet (GID, SaltInput, AuthCred, AuthCredGM), where:¶

• GID is the Group Identifier of the OSCORE group, which is specified in the 'kid context' parameter of the CoAP OSCORE option in the received request. The RS maintains GID in its Common Context within the Group OSCORE Security Context associated with the OSCORE group (see Section 2 of [I-D.ietf-core-oscore-groupcomm]).¶

• SaltInput is the Sender ID that the client has in the OSCORE group, which is specified in the 'kid' parameter of the CoAP OSCORE option in the received request. The RS maintains SaltInput in its Recipient Context associated with the client, within the Group OSCORE Security Context associated with the OSCORE group (see Section 2 of [I-D.ietf-core-oscore-groupcomm]).¶

• AuthCred is the authentication credential that the client uses in the OSCORE group. The RS maintains AuthCred in its Recipient Context associated with the client, within the Group OSCORE Security Context associated with the OSCORE group (see Section 2 of [I-D.ietf-core-oscore-groupcomm]).¶

• AuthCredGM is the authentication credential of the Group Manager responsible for the OSCORE group. The RS maintains AuthCredGM in its Common Context within the Group OSCORE Security Context associated with the OSCORE group (see Section 2 of [I-D.ietf-core-oscore-groupcomm]).¶

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 (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, 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).¶

In order to keep the same spirit of the recommendation in Section 5.10.1 of [RFC9200] without impeding cases such as those outlined in the examples above, the following defines a more fine-grained recommendations for the storage of access tokens at an RS when this profile is used.¶

• As to access tokens issued in accordance with this profile (i.e., specifying the profile "coap_group_oscore"), it is RECOMMENDED that an RS stores only one access token that:¶

  • is bound to a specific PoP key; and¶

  • targets a specific audience; and¶

  • is related to a specific OSCORE group.¶

• As to access tokens issued in accordance with a different profile P that an RS may use in parallel with the profile defined in this document, it is RECOMMENDED that an RS stores only one access token that:¶

  • is issued in accordance with the profile P; and¶

  • is bound to a specific PoP key; and¶

  • targets a specific audience; and¶

  • is related to a specific secure association used by the client to protect communications with the RS.¶

In accordance with these recommendations, if an access token T_NEW does not differ in any of the respects above from an existing access token T_OLD stored at the RS, then T_NEW will supersede T_OLD by replacing the corresponding authorization information.¶

Not complying with these recommendations can additionally complicate (constrained) implementations of RSs, with respect to required storage and the validation of a protected request against the applicable, stored access tokens associated with the same client. That is, it increases the strain on an RS in determining the actual permissions of a client, e.g., if access tokens contradict each other and thus might lead the RS to enforce wrong permissions. Moreover, if one of the access tokens expires earlier than others, the resulting permissions may offer insufficient protection.¶

12.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]¶

12.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.2.1 of [RFC-XXXX]¶

• Name: salt_input¶

• Parameter Usage Location: token request¶

• Change Controller: IETF¶

• Reference: Section 3.2.2 of [RFC-XXXX]¶

• Name: client_cred_verify¶

• Parameter Usage Location: token request¶

• Change Controller: IETF¶

• Reference: Section 3.2.3 of [RFC-XXXX]¶

• Name: client_cred_verify_mac¶

• Parameter Usage Location: token request¶

• Change Controller: IETF¶

• Reference: Section 3.2.4 of [RFC-XXXX]¶

12.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: context_id¶

• CBOR Key: TBD¶

• Value Type: byte string¶

• Reference: Section 3.2.1 of [RFC-XXXX]¶

• Original Specification: [RFC-XXXX]¶

• Name: salt_input¶

• CBOR Key: TBD¶

• Value Type: byte string¶

• Reference: Section 3.2.2 of [RFC-XXXX]¶

• Original Specification: [RFC-XXXX]¶

• Name: client_cred_verify¶

• CBOR Key: TBD¶

• Value Type: byte string¶

• Reference: Section 3.2.3 of [RFC-XXXX]¶

• Original Specification: [RFC-XXXX]¶

• Name: client_cred_verify_mac¶

• CBOR Key: TBD¶

• Value Type: byte string¶

• Reference: Section 3.2.4 of [RFC-XXXX]¶

• Original Specification: [RFC-XXXX]¶

12.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: byte string¶

• Change Controller: IETF¶

• Reference: Section 3.3.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: byte string¶

• Change Controller: IETF¶

• Reference: Section 3.3.3 of [RFC-XXXX]¶

12.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.2 of [RFC-XXXX]¶

C.1. Version -02 to -03

• Lowercase "client", "resource server", "authorization server", and "access token".¶

• Consistent update of section numbers for external references.¶

• Mentioned that this profile can also use the ACE alternative workflow.¶

• Clarified that the client may ask for a new access token after the old one becomes invalid.¶

• Enforced uniqueness pre-requirements on the client's group membership before requesting an access token.¶

• Added checks on uniqueness of clients' group membership at the RS.¶

• Clarified the process of access right verification.¶

• Added fine-grained recommendations on storing multiple access tokens bound to the same PoP key.¶

• Added guidelines on using multiple profiles.¶

• Fixes in the IANA considerations.¶

• Editorial fixes and improvements.¶

C.2. 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.3. 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.¶