Group OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework

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 [I-D.ietf-ace-oauth-authz]. 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 [I-D.ietf-ace-oauth-authz]. 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 [I-D.ietf-ace-oauth-authz]. 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 [I-D.ietf-ace-oauth-authz]. This parameter provides a Message Authentication Code (MAC) computed by the Client to prove the possession of its own private key.¶

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

3.2.2. Context ID Input Claim

The 'contextId_input' 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.¶

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 OSCORE group, whose GID was specified in the 'context_id' parameter of the 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 public key of the Client only the public key specified in the stored Access Token. As defined in Section 4.5, a possible change of public key requires the Client to upload to the RS a new Access Token bound to the new public key.¶

Additionally, for every incoming request, if Group OSCORE verification succeeds, the verification of access rights is performed as described in Section 4.4.¶

After the expiration of the Access Token related to a Group OSCORE Security Context, if the Client uses the Group OSCORE Security Context to send a request for any resource intended for OSCORE group members and that requires an active Access Token, the RS MUST respond with a 4.01 (Unauthorized) error message protected with the Group OSCORE Security Context.¶

A.1.1. Pre-Conditions

The same pre-conditions for the main mode of this profile (see Section 2.1) hold for the dual mode described in this appendix.¶

A.1.2. Access Token Posting

After having retrieved the Access Token from the AS, the Client generates a nonce N1 and an identifier ID1 unique in the sets of its own Recipient IDs from its pairwise OSCORE Security Contexts. The client then posts both the Access Token, N1 and its chosen ID to the RS, using the /authz-info endpoint and mechanisms specified in Section 5.10 of [I-D.ietf-ace-oauth-authz] and Content-Format = application/ace+cbor.¶

When using the dual mode of this profile, the communication with the authz-info endpoint is not protected, except for update of access rights. Note that, when using the dual mode, this request can alternatively be protected with Group OSCORE, using the Group OSCORE Security Context paired with the pairwise OSCORE Security Context originally established with the first Access Token posting.¶

If the Access Token is valid, the RS replies to this POST request with a 2.01 (Created) response with Content-Format = application/ace+cbor, which in a CBOR map contains a nonce N2 and an identifier ID2 unique in the sets of its own Recipient IDs from its pairwise OSCORE Security Contexts.¶

A.1.3. Setup of the Pairwise OSCORE Security Context

After sending the 2.01 (Created) response, the RS sets the ID Context of the pairwise OSCORE Security Context (see Section 3 of [RFC8613]) to the Group Identifier of the OSCORE group specified in the Access Token, concatenated with N1, concatenated with N2, concatenated with the value in the contextId parameter of the OSCORE_Input_Material provided in the 'cnf' claim of the Access Token.¶

Then, the RS derives the complete pairwise OSCORE Security Context associated with the received 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, and the authorization information is a policy used as input when processing requests from those clients.¶

During the derivation process, the RS uses: the ID Context above; the exchanged nonces N1 and N2; the identifier ID1 received from the Client, set as its own OSCORE Sender ID; the identifier ID2 provided to the Client, set as its Recipient ID for the Client; and the parameters in the Access Token. The derivation process uses also the Master Secret of the OSCORE group, that the RS knows as a group member, as well as the Sender ID of the Client in the OSCORE group, which is specified in the Access Token. This ensures that the pairwise OSCORE Security Context is securely bound to the Group OSCORE Security Context of the OSCORE group.¶

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 public key of the Client in that group.¶

After having received the nonce N2, the Client sets the ID Context in its pairwise OSCORE Security Context (see Section 3 of [RFC8613]) to the Group Identifier of the OSCORE group, concatenated with N1, concatenated with N2, concatenated with the value in the contextId parameter of the OSCORE_Input_Material provided in the 'cnf' parameter of the Access Token response from the AS. Then, the Client derives the complete pairwise OSCORE Security Context, following Section 3.2 of [RFC8613].¶

During the derivation process, the Client uses: the ID Context above, the exchanged nonces N1 and N2; the identifier ID1 provided to the RS, set as its own Recipient ID for the RS; the identifier ID2 received from the RS, set as its own OSCORE Sender ID; and the parameters received from the AS. The derivation process uses also the Master Secret of the OSCORE group, that the Client knows as a group member, as well as its own Sender ID in the OSCORE group.¶

When the Client communicates with the RS using the pairwise OSCORE Security Context, the RS achieves proof-of-possession of the credentials bound to the Access Token. Also, the RS verifies that the Client is a legitimate member of the OSCORE group.¶

A.1.4. Secure Communication

Other than starting the communication with the RS using Group OSCORE as described in Section 4.3, the Client can send to the RS a request protected with OSCORE, using the pairwise OSCORE Security Context.¶

If the request is successfully verified, then the RS stores the pairwise OSCORE Security Context, and uses it to protect the possible response, as well as further communications with the Client, until the Access Token is deleted, due to, for example, expiration. This pairwise OSCORE Security Context is discarded when an Access Token (whether the same or different) is used to successfully derive a new pairwise OSCORE Security Context.¶

As discussed in Section 7 of [I-D.ietf-ace-oscore-profile], the use of random nonces N1 and N2 during the exchange between the Client and the RS prevents the reuse of an Authenticated Encryption with Associated Data (AEAD) nonce/key pair for two different messages. Reuse might otherwise occur when Client and RS derive a new pairwise OSCORE Security Context from an existing (non-expired) Access Token, e.g., in case of reboot of either the Client or the RS, and might lead to loss of both confidentiality and integrity.¶

Additionally, just as per the main mode of this profile (see Section 4.3), the Client and RS can also securely communicate by protecting messages with Group OSCORE, using the Group OSCORE Security Context already established upon joining the OSCORE group.¶

A.2.1. C-to-AS: POST to Token Endpoint

The Client-to-AS request is specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 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 main mode of this profile (see Section 3.1), with the following modifications.¶

• The parameter 'req_cnf' MUST NOT be included in the payload.¶
• The parameter 'client_cred', defined in Appendix A.2.1.1 of this document, MUST be included in the payload. This parameter specifies the public key that the Client uses in the OSCORE group, whose identifier is indicated in the 'context_id' parameter. In particular, the specified public key is the COSE Key equivalent to the full-fledged public key that the Client uses in the OSCORE group.¶
• The proof-of-possession (PoP) evidence included in the 'client_cred_verify' or 'client_cred_verify_mac' parameter is computed by using the Client's private key associated to the public key in the 'client_cred' parameter above.¶

An example of such a request is shown in Figure 9.¶

     Header: POST (Code=0.02)
     Uri-Host: "as.example.com"
     Uri-Path: "token"
     Content-Format: "application/ace+cbor"
     Payload:
     {
       "audience" : "tempSensor4711",
       "scope" : "read",
       "context_id" : h'abcd0000',
       "salt_input" : h'00',
       "client_cred" : {
         "COSE_Key" : {
           "kty" : EC2,
           "crv" : P-256,
           "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa
                   27c9e354089bbe13',
           "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020
                   731e79a3b4e47120'
         }
       },
       "client_cred_verify" : h'...'
       (signature content omitted for brevity),
     }

Later on, the Client may want to update its current access rights, without changing the existing pairwise OSCORE Security Context with the RS. In this case, the Client MUST include in its POST request to the /token endpoint a 'req_cnf' parameter, defined in Section 3.1 of [I-D.ietf-ace-oauth-params], which MUST include a 'kid' field, as defined in Section 3.1 of [RFC8747]. The 'kid' field has as value a CBOR byte string containing the OSCORE_Input_Material Identifier (assigned as discussed in Appendix A.2.2).¶

This identifier, together with other information such as audience, can be used by the AS to determine the shared secret bound to the proof-of-possession Access Token and therefore MUST identify a symmetric key that was previously generated by the AS as a shared secret for the communication between the Client and the RS. The AS MUST verify that the received value identifies a proof-of-possession key that has previously been issued to the requesting Client. If that is not the case, the Client-to-AS request MUST be declined with the error code "invalid_request" as defined in Section 5.8.3 of [I-D.ietf-ace-oauth-authz].¶

This POST request for updating the access rights of an Access Token SHOULD NOT include the parameters 'salt_input', 'context_id', 'client_cred' and 'client_cred_verify'. An exception is the case defined in Appendix A.3.6, where the Client, following a change of public key in the OSCORE group, requests a new Access Token associated to the new public key, while still without changing the existing pairwise OSCORE Security Context with the RS.¶

An example of such a request is shown in Figure 10.¶

     Header: POST (Code=0.02)
     Uri-Host: "as.example.com"
     Uri-Path: "token"
     Content-Format: "application/ace+cbor"
     Payload:
     {
       "audience" : "tempSensor4711",
       "scope" : "read",
       "req_cnf" : {
         "kid" : h'01'
       }
     }

A.2.2. AS-to-C: Access Token

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 defined in Section 3.2, with the difference that it uses the public key specified in the 'client_cred' parameter as public key of the Client.¶

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. The AS does not perform this operation when asked to update a previously released Access Token.¶

If all verifications are successful, the AS responds as defined in Section 5.8.2 of [I-D.ietf-ace-oauth-authz]. If the Client request was invalid, or not authorized, the AS returns an error response as described in Section 5.8.3 of [I-D.ietf-ace-oauth-authz].¶

The AS can signal that the use of OSCORE and 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. This means that the Client MUST use OSCORE and/or Group OSCORE towards all the Resource Servers for which this Access Token is valid.¶

In particular, the Client MUST follow Appendix A.3.3 to derive the pairwise OSCORE Security Context to use for communications with the RS. Instead, the Client has already established the related Group OSCORE Security Context to communicate with members of the OSCORE group, upon previously joining that group.¶

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

In contrast with the main mode of this profile, the Access Token response to the Client is analogous to the one in the OSCORE profile of ACE, as described in Section 3.2 of [I-D.ietf-ace-oscore-profile]. In particular, the AS provides an OSCORE_Input_Material object, which is defined in Section 3.2.1 of [I-D.ietf-ace-oscore-profile] and included in the 'cnf' parameter (see Section 3.2 of [I-D.ietf-ace-oauth-params]) of the Access Token response.¶

The AS MUST send different OSCORE_Input_Material (and therefore different Access Tokens) to different authorized clients, in order for the RS to differentiate between clients.¶

In the issued Access Token, the AS MUST include as metadata the same information as defined in the main mode of this profile (see Section 3.2) with the following modifications.¶

• The public key that the client uses in the OSCORE group and specified in the 'client_cred' parameter of the Token request (see Appendix A.2.1) MUST also be included in the Access Token.¶

  If the Access Token is a CWT, the AS MUST include it in the 'client_cred' claim of the Access Token, defined in Appendix A.2.2.2 of this document. In particular, the 'client_cred' claim includes the same COSE Key specified in the 'client_cred' parameter of the Token Request, i.e., the COSE Key equivalent to the full-fledged public key that the Client uses in the OSCORE group.¶

• The OSCORE_Input_Material specified in the 'cnf' parameter of the Access Token response MUST also be included in the Access Token. If the Access Token is a CWT, the same OSCORE_Input_Material included in the 'cnf' parameter of the Access Token response MUST be included in the 'osc' field of the 'cnf' claim of the Access Token (see Section 3.2 of [I-D.ietf-ace-oscore-profile]).¶

Figure 11 shows an example of such an AS response. The access token has been truncated for readability.¶

     Header: Created (Code=2.01)
     Content-Type: "application/ace+cbor"
     Payload:
     {
       "access_token" : h'8343a1010aa2044c53 ...'
        (remainder of CWT omitted for brevity),
       "ace_profile" : "coap_group_oscore",
       "expires_in" : 3600,
       "cnf" : {
         "osc" : {
           "alg" : AES-CCM-16-64-128,
           "id"  : h'01',
           "ms" : h'f9af838368e353e78888e1426bd94e6f',
           "salt" : h'1122',
           "contextId" : h'99'
         }
       }
     }

Figure 12 shows an example CWT, containing the necessary OSCORE parameters in the 'cnf' claim.¶

     {
       "aud" : "tempSensorInLivingRoom",
       "iat" : 1360189224,
       "exp" : 1360289224,
       "scope" :  "temperature_g firmware_p",
       "cnf" : {
         "osc" : {
           "alg" : AES-CCM-16-64-128,
           "id"  : h'01',
           "ms" : h'f9af838368e353e78888e1426bd94e6f',
           "salt" : h'1122',
           "contextId" : h'99'
       },
       "salt_input" : h'00',
       "contextId_input" : h'abcd0000',
       "client_cred" : {
         "COSE_Key" : {
           "kty" : EC2,
           "crv" : P-256,
           "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa
                   27c9e354089bbe13',
           "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020
                   731e79a3b4e47120'
         }
       }
     }

The same CWT as in Figure 12 and encoded in CBOR is shown in Figure 13, using the value abbreviations defined in [I-D.ietf-ace-oauth-authz] and [RFC8747].¶

NOTE: it should be checked (and in case fixed) that the values used below (which are not yet registered) are the final values registered in IANA.¶

A8                                      # map(8)
   03                                   # unsigned(3)
   76                                   # text(22)
      74656D7053656E736F72496E4C6976696E67526F6F6D
   06                                   # unsigned(6)
   1A 5112D728                          # unsigned(1360189224)
   04                                   # unsigned(4)
   1A 51145DC8                          # unsigned(1360289224)
   09                                   # unsigned(9)
   78 18                                # text(24)
      74656D70657261747572655F67206669726D776172655F70
   08                                   # unsigned(8)
   A1                                   # map(1)
      04                                # unsigned(4)
      A5                                # map(5)
         04                             # unsigned(4)
         0A                             # unsigned(10)
         00                             # unsigned(0)
         41                             # bytes(1)
            01                          # "\x01"
         02                             # unsigned(2)
         50                             # bytes(16)
            F9AF838368E353E78888E1426BD94E6F
         05                             # unsigned(5)
         42                             # bytes(2)
            1122                        # "\x11\""
         06                             # unsigned(6)
         41                             # bytes(1)
            99                          # "\x99"
   18 3C                                # unsigned(60)
   41                                   # bytes(1)
      00
   18 3D                                # unsigned(61)
   44                                   # bytes(4)
      ABCD0000
   18 3E                                # unsigned(62)
   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)
            D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9
            E354089BBE13
         22                             # negative(2)
         58 20                          # bytes(32)
            F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E515D020731E
            79A3B4E47120

If the Client has requested an update to its access rights using the same pairwise OSCORE Security Context, which is valid and authorized, the AS MUST omit the 'cnf' parameter in the response to the client.¶

Instead, the updated Access Token conveyed in the AS-to-C response MUST include a 'cnf' claim specifying a 'kid' field, as defined in Section 3.1 of [RFC8747]. The response from the AS MUST carry the OSCORE Input Material identifier in the 'kid' field within the 'cnf' claim of the Access Token. That is, the 'kid' field is a CBOR byte string, with value the same value of the 'kid' field of the 'req_cnf' parameter from the C-to-AS request for updating rights to the Access Token (see Figure 10). This information needs to be included in the Access Token, in order for the RS to identify the previously generated pairwise OSCORE Security Context.¶

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

     Header: Created (Code=2.01)
     Content-Type: "application/ace+cbor"
     Payload:
     {
       "access_token" : h'8343a1010aa2044c53 ...'
        (remainder of CWT omitted for brevity),
       "profile" : "coap_group_oscore",
       "expires_in" : 3600
     }

Figure 15 shows an example CWT, containing the necessary OSCORE parameters in the 'cnf' claim for update of access rights.¶

     {
       "aud" : "tempSensorInLivingRoom",
       "iat" : 1360189224,
       "exp" : 1360289224,
       "scope" :  "temperature_h",
       "cnf" : {
         "kid" : h'01'
       }
     }

A.3.1. C-to-RS POST to authz-info Endpoint

The Client MUST generate a nonce N1, an OSCORE Recipient ID (ID1), and post them to the /authz-info endpoint of the RS together with the Access Token, as defined in the OSCORE profile of ACE (see Section 4.1 of [I-D.ietf-ace-oscore-profile]).¶

The same recommendations, considerations and behaviors defined in Section 4.1 of [I-D.ietf-ace-oscore-profile] hold.¶

If the Client has already posted a valid Access Token, has already established a pairwise OSCORE Security Context with the RS, and wants to update its access rights, the Client can do so by posting the new Access Token (retrieved from the AS and specifying the updated set of access rights) to the /authz-info endpoint.¶

The Client MUST protect the request using either the pairwise OSCORE Security Context established during the first Access Token exchange, or the Group OSCORE Security Context associated to that pairwise OSCORE Security Context.¶

In either case, the Client MUST only send the Access Token in the payload, i.e., no nonce or identifier are sent. After proper verification (see Section 4.2 of [I-D.ietf-ace-oscore-profile]), the new Access Token will supersede the old one at the RS, by replacing the corresponding authorization information. At the same time, the RS will maintain the same pairwise OSCORE Security Context and Group OSCORE Security Context, as now both associated to the new Access Token.¶

A.3.2. RS-to-C: 2.01 (Created)

The RS MUST verify the validity of the Access Token as defined in Section 4.2, with the following modifications.¶

• If the POST request to /authz-info is not protected, the RS checks that the 'cnf' claim is included in the Access Token and that it contains an OSCORE_Input_Material object. Also, the RS checks that the 'salt_input', 'client_cred' and 'contextId_input' claims are included in the Access Token.¶
• If the POST request to /authz-info is protected with the pairwise OSCORE Security Context shared with the Client or with the Group OSCORE Security Context of the OSCORE group, i.e., the Client is requesting an update of access rights, the RS checks that the 'cnf' claim is included in the Access Token and that it contains only the 'kid' field.¶
• If the 'salt_input', 'client_cred' and 'contextId_input' claims are included in the Access Token, the RS extracts the content of 'client_cred'. Then, the RS considers that content as the COSE Key equivalent to the full-fledged public key that the Client uses in the group, whose GID is specified in the 'contextId_input' claim. The RS can compare this public key with the public key of the claimed Client retrieved from its local storage or from the Group Manager (see Section 4.2).¶

If any of the checks fails, the RS MUST consider the Access Token non valid, and MUST respond 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 proceeds as follows.¶

In case the POST request to /authz-info was not protected, the RS MUST generate a nonce N2, an OSCORE Recipient ID (ID2), and include them in the 2.01 (Created) response to the Client, as defined in the OSCORE profile of ACE (see Section 4.2 of [I-D.ietf-ace-oscore-profile]).¶

Instead, in case the POST request to /authz-info was protected, the RS MUST ignore any nonce and identifiers in the request, if any was sent. Then, the RS MUST check that the 'kid' field of the 'cnf' claim in the new Access Token matches the identifier of the OSCORE Input Material of a pairwise OSCORE Security Context such that:¶

• The pairwise OSCORE Security Context was used to protect the request, if this was protected with OSCORE; or¶
• The pairwise OSCORE Security Context is bound to the Group OSCORE Security Context used to protect the request, if this was protected with Group OSCORE.¶

If either verification is successful, the new Access Token supersedes the old one at the RS. Besides, the RS associates the new Access Token to the same pairwise OSCORE Security Context identified above, as also bound to a Group OSCORE Security Context. The RS MUST respond with a 2.01 (Created) response with no payload, protected with the same Security Context used to protect the request. In particular, no new pairwise OSCORE Security Context is established between the Client and the RS. If any verification fails, the RS MUST respond with a 4.01 (Unauthorized) error response.¶

Further recommendations, considerations and behaviors defined in Section 4.2 of [I-D.ietf-ace-oscore-profile] hold for this document.¶

A.3.3. OSCORE Setup - Client Side

Once having received the 2.01 (Created) response from the RS, following an unprotected POST request to the /authz-info endpoint, the Client MUST extract the nonce N2 from the 'nonce2' parameter, and the Client identifier from the 'ace_server_recipientid' parameter in the CBOR map of the response payload. Note that this identifier is used by C as Sender ID in the pairwise OSCORE Security Context to be established with the RS, and is different as well as unrelated to the Sender ID of C in the OSCORE group.¶

Then, the Client performs the following actions, in order to set up and fully derive the pairwise OSCORE Security Context for communicating with the RS.¶

• The Client MUST set the ID Context of the pairwise OSCORE Security Context as the concatenation of: i) GID, i.e., the Group Identifier of the OSCORE group, as specified by the Client in the 'context_id' parameter of the Client-to-AS request; ii) the nonce N1; iii) the nonce N2; and iv) CID, i.e., the value in the contextId parameter of the OSCORE_Input_Material provided in the 'cnf' parameter of the Access Token response from the AS. The concatenation occurs in this order: ID Context = GID | N1 | N2 | CID, where | denotes byte string concatenation.¶
• The Client MUST set the updated Master Salt of the pairwise OSCORE Security Context as the concatenation of SaltInput, MSalt, the nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the Sender ID that the Client has in the OSCORE group, which is known to the Client as a member of the OSCORE group; ii) MSalt is the (optional) Master Salt in the pairwise OSCORE Security Context (received from the AS in the Token); and iii) GMSalt is the (optional) Master Salt in the Group OSCORE Security Context, which is known to the Client as a member of the OSCORE group. The concatenation occurs in this order: Master Salt = SaltInput | MSalt | N1 | N2 | GMSalt, where | denotes byte string concatenation. Optional values, if not specified, are not included in the concatenation. The five parameters SaltInput, MSalt, N1, N2 and GMSalt are to be concatenated as encoded CBOR byte strings. An example of Master Salt construction using CBOR encoding is given in Figure 16.¶

SaltInput, MSalt, N1, N2 and GMSalt, in CBOR diagnostic notation:
      SaltInput = h'00'
      MSalt = h'f9af838368e353e78888e1426bd94e6f'
      N1 = h'018a278f7faab55a'
      N2 = h'25a8991cd700ac01'
      GMSalt = h'99'

SaltInput, MSalt, N1, N2 and GMSalt, as CBOR encoded byte strings:
      SaltInput = 0x4100
      MSalt = 0x50f9af838368e353e78888e1426bd94e6f
      N1 = 0x48018a278f7faab55a
      N2 = 0x4825a8991cd700ac01
      GMSalt = 0x4199

Master Salt = 0x41 00
                50 f9af838368e353e78888e1426bd94e6f
                48 018a278f7faab55a
                48 25a8991cd700ac01
                41 99

• The Client MUST set the Master Secret of the pairwise OSCORE Security Context to the concatenation of MSec and GMSec, where: i) MSec is the value of the 'ms' parameter in the OSCORE_Input_Material of the 'cnf' parameter, received from the AS in Appendix A.2.2; while ii) GMSec is the Master Secret of the Group OSCORE Security Context, which is known to the Client as a member of the OSCORE group.¶
• The Client MUST set the Recipient ID as ace_client_recipientid, sent as described in Appendix A.3.1.¶
• The Client MUST set the Sender ID as ace_server_recipientid, received as described in Appendix A.3.1.¶
• The Client MUST set the AEAD Algorithm, ID Context, HKDF, and OSCORE Version as indicated in the corresponding parameters received from the AS in Appendix A.2.2, if present in the OSCORE_Input_Material of the 'cnf' parameter. In case these parameters are omitted, the default values SHALL be used as described in Sections 3.2 and 5.4 of [RFC8613].¶

Finally, the client MUST derive the complete pairwise OSCORE Security Context following Section 3.2.1 of [RFC8613].¶

From then on, when communicating with the RS to access the resources as specified by the authorization information, the Client MUST use the newly established pairwise OSCORE Security Context or the Group OSCORE Security Context of the OSCORE Group where both the Client and the RS are members.¶

If any of the expected parameters is missing (e.g., any of the mandatory parameters from the AS or the RS), or if ace_client_recipientid equals ace_server_recipientid (and as a consequence the Sender and Recipient Keys derived would be equal, see Section 3.3 of [RFC8613]), then the client MUST stop the exchange, and MUST NOT derive the pairwise OSCORE Security Context. The Client MAY restart the exchange, to get the correct security input material.¶

The Client can use this pairwise OSCORE Security Context to send requests to the RS protected with OSCORE. Besides, the Client can use the Group OSCORE Security Context for protecting unicast requests to the RS, or multicast requests to the OSCORE group including also the RS. Mutual authentication as group members is only achieved after the client has successfully verified the Group OSCORE protected response from the RS. Similarly, mutual authentication as OSCORE peers is only achieved after the client has successfully verified the OSCORE protected response from the RS, using the pairwise OSCORE Security Context.¶

Note that the ID Context of the pairwise OSCORE Security Context can be assigned by the AS, communicated and set in both the RS and Client after the exchange specified in this profile is executed. Subsequently, the Client and RS can update their ID Context by running a mechanism such as the one defined in Appendix B.2 of [RFC8613] if they both support it and are configured to do so. In that case, the ID Context in the pairwise OSCORE Security Context will not match the "contextId" parameter of the corresponding OSCORE_Input_Material. Running the procedure in Appendix B.2 of [RFC8613] results in the keying material in the pairwise OSCORE Security Contexts of the Client and RS being updated. The Client can achieve the same result by re-posting the Access Token to the unprotected /authz-info endpoint at the RS, as described in Section 4.1 of [I-D.ietf-ace-oscore-profile], although without updating the ID Context.¶

A.3.4. OSCORE Setup - Resource Server Side

After validation of the Access Token as defined in Appendix A.3.2 and after sending the 2.01 (Created) response to an unprotected POST request to the /authz-info endpoint, the RS performs the following actions, in order to set up and fully derive the pairwise OSCORE Security Context created to communicate with the Client.¶

• The RS MUST set the ID Context of the pairwise OSCORE Security Context as the concatenation of: i) GID, i.e., the Group Identifier of the OSCORE group, as specified in the 'contextId' parameter of the OSCORE_Input_Material, in the 'cnf' claim of the Access Token received from the Client (see Appendix A.3.1); ii) the nonce N1; iii) the nonce N2; and iv) CID which is the value in the contextId parameter of the OSCORE_Input_Material provided in the 'cnf' claim of the Access Token. The concatenation occurs in this order: ID Context = GID | N1 | N2 | CID, where | denotes byte string concatenation.¶
• The RS MUST set the new Master Salt of the pairwise OSCORE Security Context as the concatenation of SaltInput, MSalt, the nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the Sender ID that the Client has in the OSCORE group, as specified in the 'salt_input' claim included in the Access Token received from the Client (see Appendix A.3.1); ii) MSalt is the (optional) Master Salt in the pairwise OSCORE Security Context as specified in the 'salt' parameter in the OSCORE_Input_Material of the 'cnf' claim, included in the Access Token received from the Client; and iii) GMSalt is the (optional) Master Salt in the Group OSCORE Security Context, which is known to the RS as a member of the OSCORE group. The concatenation occurs in this order: Master Salt = SaltInput | MSalt | N1 | N2 | GMSalt, where | denotes byte string concatenation. Optional values, if not specified, are not included in the concatenation. The same considerations for building the Master Salt, considering the inputs as encoded CBOR byte strings as in Figure 16, hold also for the RS.¶
• The RS MUST set the Master Secret of the pairwise OSCORE Security Context to the concatenation of MSec and GMSec, where: i) MSec is the value of the 'ms' parameter in the OSCORE_Input_Material of the 'cnf' claim, included in the Access Token received from the Client (see Appendix A.3.1); while ii) GMSec is the Master Secret of the Group OSCORE Security Context, which is known to the RS as a member of the OSCORE group.¶
• The RS MUST set the Recipient ID as ace_server_recipientid, sent as described in Appendix A.3.2.¶
• The RS MUST set the Sender ID as ace_client_recipientid, received as described in Appendix A.3.2.¶
• The RS MUST set the AEAD Algorithm, ID Context, HKDF, and OSCORE Version from the corresponding parameters received from the Client in the Access Token (see Appendix A.3.1), if present in the OSCORE_Input_Material of the 'cnf' claim. In case these parameters are omitted, the default values SHALL be used as described in Sections 3.2 and 5.4 of [RFC8613].¶

Finally, the RS MUST derive the complete pairwise OSCORE Security Context following Section 3.2.1 of [RFC8613].¶

Once having completed the derivation above, the RS MUST associate the authorization information from the Access Token with the just established pairwise OSCORE Security Context. Furthermore, as defined in Section 4.2, the RS MUST associate the authorization information from the Access Token with the Group OSCORE Security Context.¶

Then, the RS uses this pairwise OSCORE Security Context to verify requests from and send responses to the Client protected with OSCORE, when this Security Context is used. If OSCORE verification fails, error responses are used, as specified in Section 8 of [RFC8613].¶

Besides, the RS uses the Group OSCORE Security Context to verify (multicast) requests from and send responses to the Client protected with Group OSCORE. When processing an incoming request protected with Group OSCORE, the RS MUST consider as valid public key of the Client only the public key associated to the stored Access Token. As defined in Appendix A.3.6, a change of public key in the group requires the Client to upload to the RS a new Access Token, where the 'client_cred' claim specifies a COSE Key equivalent to the new full-fledged public key that the Client has in the group.¶

If Group OSCORE verification fails, error responses are used, as specified in Sections 8 and 9 of [I-D.ietf-core-oscore-groupcomm]. Additionally, for every incoming request, if OSCORE or Group OSCORE verification succeeds, the verification of access rights is performed as described in Appendix A.3.5.¶

After the deletion of the Access Token related to a pairwise OSCORE Security Context and to a Group OSCORE Security Context, due to, for example, expiration, the RS MUST NOT use the pairwise OSCORE Security Context. The RS MUST respond with an unprotected 4.01 (Unauthorized) error message to received requests that correspond to a pairwise OSCORE Security Context with a deleted Access Token. Also, if the Client uses the Group OSCORE Security Context to send a request for any resource intended for OSCORE group members and that requires an active Access Token, the RS MUST respond with a 4.01 (Unauthorized) error message protected with the Group OSCORE Security Context.¶

The same considerations, related to the value of the ID Context changing, as in Appendix A.3.3 hold also for the RS.¶

A.3.5. Access Rights Verification

The RS MUST follow the procedures defined in Section 4.4.¶

Additionally, if the RS receives an OSCORE-protected request from a Client, the RS processes it according to [RFC8613].¶

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

The response code MUST be 4.01 (Unauthorized) if the RS has no valid Access Token for the Client.¶

A.3.6. Change of Client's Public Key in the Group

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

After that, the Client may still have an Access Token previously uploaded to the RS, which is not expired yet and still valid to the best of the Client's knowledge. Then, 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 Appendix A.2.1 for the update of access rights, i.e., with the 'req_cnf' parameter including only a 'kid' field. In particular, when sending the POST request to the AS, the Client indicates:¶

   • The current Group Identifier of the OSCORE group, as value of the 'context_id' parameter.¶
   • The current Sender ID it has in the OSCORE group, as value of the 'salt_input' parameter.¶
   • The new public key it uses in the OSCORE group, as value of the 'client_cred' parameter. In particular, the specified public key is the COSE Key equivalent to the new full-fledged public key that the Client uses in the OSCORE group.¶
   • The proof-of-possession (PoP) evidence corresponding to the new public key, as value of the 'client_cred_verify' or 'client_cred_verify_mac' parameter.¶
   • The same current or instead new set of access rights, as value of the 'scope' parameter.¶
2. After receiving the response from the AS (see Appendix A.2.2), the Client performs the same exchanges with the RS as defined in Appendix A.3, with the following difference: the POST request to /authz-info for uploading the new Access Token MUST be protected with the pairwise OSCORE Security Context shared with the RS.¶

When receiving the new Access Token, the RS performs the same steps defined in Appendix A.3.2. In particular, no new pairwise OSCORE Security Context is established between the Client and the RS.¶