]> RISE AB

Isafjordsgatan 22 Kista 16440 Stockholm Sweden marco.tiloca@ri.se

RISE AB

Isafjordsgatan 22 Kista 16440 Stockholm Sweden rikard.hoglund@ri.se

Combitech

Djäknegatan 31 Malmö 21135 Malmö Sweden ludwig.seitz@combitech.com

Ericsson AB

Torshamnsgatan 23 Kista 16440 Stockholm Sweden francesca.palombini@ericsson.com

Internet ACE Working Group Internet-Draft This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group OSCORE to provide communication security between a Client and a (set of) Resource Server(s) as members of an OSCORE Group. The profile securely binds an OAuth 2.0 Access Token with the public key of the Client associated with the private key used 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 correct 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. Discussion Venues Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (ace@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction A number of applications rely on a group communication model, where a Client can access a resource shared 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 get 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 be used 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 to have different access rights to resources of other group members. That is, 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. For instance, 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 do so. 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. Also, introducing a different security group for each different set of access rights would result in additional keying material to distribute and manage. In particular, if the access rights for a single node change, this would require to evict that node from the current group, followed by that node joining 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 in the system. A fine-grained access control model can be rather enforced within a same group, by using the Authentication and Authorization for Constrained Environments (ACE) framework . That is, a Client has to first obtain authorization credentials in the form of an Access Token, and post 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 Server. However each of the current profiles of ACE defined in admits a single security protocol that cannot be used to protect group messages sent over IP multicast. This document specifies the "coap_group_oscore" profile of the ACE framework, where a Client uses CoAP or CoAP over IP multicast to communicate to one or multiple Resource Servers, which are members of an application group and share a common set of resources. This profile uses Group OSCORE 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 at other members in that group. The process for joining the OSCORE group through the respective Group Manager as defined in 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 by using an Access Token, which is bound to a key (the proof-of-possession key). This profile uses Group OSCORE to achieve server authentication, as well as proof-of-possession for the Client's public key used in the OSCORE group in question. Note that the proof of possession is not done by a dedicated protocol element, but rather occurs after the first Group OSCORE exchange. Furthermore, this profile provides proof of the Client's membership to the correct OSCORE group, by binding the Access Token to the Client's authentication credential used in the group and including the Client's public public key, as well as to information from the pre-established Group OSCORE Security Context. This allows the Resource Server to verify the Client's group membership upon reception of a message protected with Group OSCORE from that Client. OSCORE specifies how to use COSE 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 protected messages (in group mode); or by protecting messages with pairwise keying material derived from the asymmetric keys of the two peers exchanging the message (in pairwise mode).

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 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 , COSE , CoAP , OSCORE and Group OSCORE . 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) , X.509 certificates and C509 certificates . Members of an OSCORE group have an associated authentication credential in the format used in the group. As per , 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 , as well as in the OSCORE profile of ACE . The terminology for entities in the considered architecture is defined in OAuth 2.0 . In particular, this includes Client (C), Resource Server (RS), and Authorization Server (AS). Note that, unless otherwise indicated, the term "endpoint" is used here following its OAuth definition, aimed at denoting resources such as /token and /introspect at the AS, and /authz-info at the RS. This document does not use the CoAP definition of "endpoint", which is "An entity participating in the CoAP protocol". Additionally, this document makes use of the following terminology.

• Equivalent COSE Key: a COSE Key built from an authentication credential used in the OSCORE group. The equivalent COSE Key preserves all the main information elements from the authentication credential, in particular the key coordinates and the comprehensive set of information related to the public key algorithm, including, e.g., the used elliptic curve (when applicable).
• Pairwise-only group: an OSCORE group that uses only the pairwise mode (see ).

Examples throughout this document are expressed in CBOR diagnostic notation, without the tag and value abbreviations.

Protocol Overview This section provides an overview of this profile, i.e., on how to use the ACE framework for authentication and authorization to secure communications between a Client and a (set of) Resource Server(s) using Group OSCORE . 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 at other members in that group. In particular, the process for joining the OSCORE group through the respective Group Manager as defined in 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 . In the figure, it is assumed that both RS1 and RS2 are associated with the same AS. It is also assumed that C, RS1 and RS2 have previously joined an OSCORE group with Group Identifier (gid) "abcd0000", and got assigned Sender ID (sid) "0", "1" and "2" in the group, respectively. The names of messages coincide with those of when applicable.

Protocol Overview. ] | | | | | | | | [<---- AS Request ------] | | | | Creation Hints | | | | | | | |-------- POST /token ----------------------------------------------->| | (aud: RS1, sid: 0, gid: abcd0000, ...) | | | | | | | | | | |<-------------------------------- Access Token + RS Information -----| | | (aud: RS1, sid: 0, gid: abcd0000, ...) | | | | | |---- POST /authz-info ----->| | | | (access_token) | | | | | | | |<--- 2.01 Created ----------| | | | | | | |-------- POST /token ----------------------------------------------->| | (aud: RS2, sid: 0, gid: abcd0000, ...) | | | | | | | | | | | | | | |<-------------------------------- Access Token + RS Information -----| | | (aud: RS2, sid: 0, gid: abcd0000, ...) | | | | | |----- POST /authz-info ----------------->| | | (access_token) | | | | | | | | | | | |<--- 2.01 Created -----------------------| | | | | | |-- Group OSCORE Request -+->| | | | (kid: 0, gid: abcd0000) \-------------->| | | | | | | /proof-of-possession/ | | | | | | | | | |<-- Group OSCORE Response --| | | | (kid: 1) | | | | | | | /proof-of-possession/ | | | | | | | /Mutual authentication | | | between C and RS1/ | | | | | | | | | | | |<-- Group OSCORE Response ---------------| | | (kid: 2) | | | | | | | /proof-of-possession/ | | | | | | | /Mutual authentication | | | between C and RS2/ | | | | | | | | ... | | | ]]>

Pre-Conditions Using Group OSCORE and this profile requires both the Client and the Resource Servers to 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 may join the OSCORE group through the respective Group Manager by using the approach defined in , 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 .

Access Token Retrieval This profile requires that the Client retrieves an Access Token from the AS for the resource(s) it wants to access on each of the RSs, using the /token endpoint, as specified in . In a general case, it can be assumed that different RSs are associated with different ASs, even if the RSs are members of a same 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, included in the Access Token response to the Client. Furthermore, in the Access Token request to the AS, the Client MUST also include: its own public key used in the OSCORE group; and a proof-of-possession (PoP) evidence to proof 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 public key indicated by the Client in the Access Token. The Access Token request and response MUST be confidentiality-protected and ensure authenticity. This profile RECOMMENDS the use of OSCORE 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 and of MAY alternatively be used, such as TLS or DTLS .

Access Token Posting After having retrieved the Access Token from the AS, the Client posts the Access Token to the RS, using the /authz-info endpoint and mechanisms specified in , as well as Content-Format = application/ace+cbor. When using this profile, the communication with the /authz-info endpoint is not protected. 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. 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 . 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. 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 with 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).

Secure Communication The Client can send a request protected with Group OSCORE to the RS. This can be a unicast request addressed to the RS, or a multicast request addressed to 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 . The RS may send a response back to the Client, protecting it by means of the same Group OSCORE Security Context.

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), by means of the 'cnf' claim.

C-to-AS: POST to Token Endpoint The Client-to-AS request is specified in . 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 ), with the following additional parameters that MUST be included in the payload.

• 'context_id', defined in of this document. This parameter specifies the Group Identifier (GID), i.e., the Id Context of an OSCORE group where the Client and the RS are currently members. In particular, the Client wishes to communicate with the RS using the Group OSCORE Security Context associated with that OSCORE group.
• 'salt_input', defined in 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 . This parameter follows the syntax from when including Value Type "COSE_Key" (1) and specifying an asymmetric key. In particular, the specified public key is the COSE Key equivalent to the authentication credential that the Client uses in the OSCORE group. The specified public key will be used as the pop-key bound to the Access Token. Alternative Value Types defined in future specifications are fine to consider, if indicating a non-encrypted asymmetric key or full-fledged autentication credential.

In addition, the Client computes its proof-of-possession (PoP) evidence, in order to prove possession of its own private key used in the OSCORE group to the AS. This allows the AS to verify that the Client indeed owns the private key associated with that public key, as its alleged identity credential within the OSCORE group. To this end, the Client MUST use as PoP input the byte representation of a quantity that uniquely represents the secure communication association between the Client and the AS. It is RECOMMENDED that the Client considers the following as PoP input.

• If the Client and the AS communicate over (D)TLS, the PoP input is an exporter value computed as defined in . In particular, the exporter label MUST be 'EXPORTER-ACE-Sign-Challenge-Client-AS' defined in of this document, together with an empty 'context_value', and 32 bytes as 'key_length'.
• If the Client and the AS communicate over OSCORE, the PoP input is the output PRK of a HKDF-Extract step , i.e., PRK = HMAC-Hash(salt, IKM). In particular, 'salt' takes (x1 | x2), where x1 is the ID Context of the OSCORE Security Context between the Client and the AS, x2 is the Sender ID of the Client in that Security Context, and | denotes byte string concatenation. Also, 'IKM' is the OSCORE Master Secret of the OSCORE Security Context between the Client and the AS. The HKDF MUST be one of the HMAC-based HKDF algorithms defined for COSE . The Client and AS may agree on the HKDF algorithm to use during the Client's registration at the AS. HKDF SHA-256 is mandatory to implement.

Then, 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 private key corresponds to the authentication credential used in the OSCORE group, for which the equivalent COSE Key is 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 . 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 , using an ECDH algorithm pre-agreed between Client and AS. 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 . The Client's private key corresponds to the Client's authentication credential used in the OSCORE group, for which the equivalent COSE Key is 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. The Client and AS may agree on the ECDH algorithm to use during the Client's registration at the AS. The ECDH-SS + HKDF-256 algorithm specified in is mandatory to implement.
  • 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 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 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 .

Example C-to-AS POST /token request for an Access Token bound to an asymmetric key.

'context_id' Parameter The 'context_id' parameter is an OPTIONAL parameter of the Access Token request message defined in . 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.

'salt_input' Parameter The 'salt_input' parameter is an OPTIONAL parameter of the Access Token request message defined in . 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.

'client_cred_verify' Parameter The 'client_cred_verify' parameter is an OPTIONAL parameter of the Access Token request message defined in . This parameter provides a signature computed by the Client to prove the possession of its own private key.

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

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

• As PoP input, the AS uses the same value considered by the Client in .
• As public key of the Client, the AS uses the one specified in the 'req_cnf' parameter of the Access Token request.
• 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.
• 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 ), 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.

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 . If all verifications are successful, the AS responds as defined in . 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 . 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 .

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

• The profile "coap_group_oscore". If the Access Token is a CWT, this is placed in the 'ace_profile' claim of the Access Token, as per .
• The salt input specified in the 'salt_input' parameter of the Token Request. If the Access Token is a CWT, the content of the 'salt_input' parameter MUST be placed in the 'salt_input' claim of the Access Token, defined in of this document.
• The Context Id input specified in the 'context_id' parameter of the Token Request. If the Access Token is a CWT, the content of the 'context_id' parameter MUST be placed in the 'contextId_input' claim of the Access Token, defined in of this document.
• The public key that the client uses in the OSCORE group and specified in the 'req_cnf' parameter of the Token request. If the Access Token is a CWT, the public key MUST be specified in the 'cnf' claim, which follows the syntax from when including Value Type "COSE_Key" (1) and specifying an asymmetric key. In particular, the 'cnf' claim includes the same COSE Key specified in the 'req_cnf' parameter of the Token Request, i.e., the COSE Key equivalent to the authentication credential that the Client uses in the OSCORE group. Alternative Value Types defined in future specifications are fine to consider, if indicating a non-encrypted asymmetric key or full-fledged autentication credential.

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

Example AS-to-C Access Token response with the Group OSCORE profile.

shows an example CWT Claims Set, containing the Client's public key in the group (as pop-key) in the 'cnf' claim.

Example CWT Claims Set with OSCORE parameters.

The same CWT Claims Set as in and encoded in CBOR is shown in , using the value abbreviations defined in and . 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. 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.

Example CWT Claims Set with OSCORE parameters, CBOR encoded.

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.

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.

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 ) or with the pairwise mode (see ). 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 including the public key associated with its own private key used in the OSCORE group, together with its own Sender ID in that OSCORE group (see ). This allows the RS receiving an Access Token to verify with the Group Manager of that OSCORE group whether such a Client has indeed that Sender ID and an authentication credential including that public key 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) public key; ii) successfully posting the Access Token to RS; and then iii) attempting to communicate using Group OSCORE impersonating C1, while blaming C1 for the consequences.

C-to-RS POST to authz-info Endpoint The Client posts the Access Token to the /authz-info endpoint of the RS, as defined in .

RS-to-C: 2.01 (Created) The RS MUST verify the validity of the Access Token as defined in , with the following additions.

• The RS MUST check that the claims 'salt_input', 'contextId_input' and 'cnf' are included in the Access Token.
• The RS considers: the content of the 'contextId_input' 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 content of the 'cnf' claim as the COSE Key equivalent to the authentication credential that the Client uses in the group. The RS MUST check whether it already stores an authentication credential associated with the pair (GID, Sender ID) above, such that the COSE Key specified in the 'cnf' claim is its equivalent COSE Key. 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 , 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 is such that the COSE Key specified in the 'cnf' claim of the Access Token is its equivalent COSE Key.
  • The RS MUST check that 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 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 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 3-tuple (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 3-tuple (GID, SaltInput, AuthCred) associated with the Access Token might change. In particular:

• If the OSCORE group is rekeyed (see and ), the Group Identifier also changes in the group, and the new one replaces the current 'GID' value in the 3-tuple.
• If the Client requests and obtains a new OSCORE Sender ID from the Group Manager (see and ), the new Sender ID replaces the current 'SaltInput' value in the 3-tuple.

Finally, the RS MUST send a 2.01 (Created) response to the Client, as defined in .

Client-RS Secure Communication When previously joining the OSCORE group, both the Client and 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.

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

Resource Server Side After successful validation of the Access Token as defined in and after having sent the 2.01 (Created) response, the RS can start to communicate with the Client using Group OSCORE . When processing an incoming request protected with Group OSCORE, the RS MUST consider as valid Client's authentication credential only the one associated to the stored Access Token. As defined in , a possible change of authentication credential requires the Client to upload to the RS a new Access Token bound to the new authentication credential. Additionally, for every incoming request, if Group OSCORE verification succeeds, the verification of access rights is performed as described in . 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.

Access Rights Verification The RS MUST follow the procedures defined in . If an RS receives a Group OSCORE-protected request from a Client, the RS processes it according to . 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. The response code MUST be 4.01 (Unauthorized) if the RS has no valid Access Token for the Client. 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 with a 4.03 (Forbidden). If the RS has an Access Token for the Client but the requested action is not authorized, the RS MUST reject the request with a 4.05 (Method Not Allowed).

Change of Client's Authentication Credential in the Group During its membership in the OSCORE group, the client might change the authentication credential it uses in the group. When this happens, the Client uploads the new authentication credential to the Group Manager, as defined in . 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 . In particular, when sending the POST request as defined in , 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 public key of the new authentication credential it uses in the OSCORE group, as value of the 'req_cnf' parameter. In particular, the specified public key is the COSE Key equivalent to the new authentication credential that the Client uses in the OSCORE group.
   • 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 response from the AS (see ), the Client performs the same exchanges with the RS as defined in .

When receiving the new Access Token, the RS performs the same steps defined in , with the following addition, in case the new Access Token is successfully verified and stored. The RS also deletes the old Access Token, i.e., the one whose associated 3-tuple has the same GID and SaltInput values as in the 3-tuple including the new authentication credential of the Client and associated with the new Access Token.

Secure Communication with the AS As specified in the ACE framework (see Sections and of ), the requesting entity (RS and/or Client) and the AS communicate via the /token or /introspection endpoint. The use of CoAP and OSCORE for this communication is RECOMMENDED in this profile. Other protocols fulfilling the security requirements defined in Sections and of (such as HTTP and DTLS or TLS) MAY be used instead. If OSCORE 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 /introspection endpoint as specified in , and through the /token endpoint as specified in .

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 ). 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 . In such a case, the Client SHOULD request a new Access Token and post it to the RS.

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

CBOR mappings for new parameters.

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

CBOR mappings for new claims.

Security Considerations This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework . 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 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 whose audience comprises multiple RSs. In such a case, as per , the AS has to ensure the integrity protection of the Access Token by protecting it through an asymmetric signature. In addition, the used audience has to correctly identify all the RSs that are intended recipients of the Access Token. As a particular case, the audience can be the name of the OSCORE group, if the Access Token is intended to all the RSs in that group. Furthermore, this document inherits the general security considerations about Group OSCORE , 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, for group requests and responses. Group OSCORE ensures source authentication of messages both in group mode (see ) and in pairwise mode (see ). 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 over multicast to multiple recipients, or sent over unicast to one 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 to one recipient.

Privacy Considerations This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework . Thus the general privacy considerations from the ACE framework also apply to this profile. As this profile uses Group OSCORE, the privacy considerations from 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.

IANA Considerations This document has the following actions for IANA.

ACE Profile Registry IANA is asked to add the following entry to the "ACE Profile" registry defined in .

• 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. Optionally, the dual mode defined in additionally establishes a pairwise OSCORE Security Context, and thus also enables OSCORE communication between two members of the OSCORE group.
• CBOR Value: TBD (value between 1 and 255)
• Reference: [[this document]]

OAuth Parameters Registry IANA is asked to add the following entries to the "OAuth Parameters" registry.

• Name: "context_id"
• Parameter Usage Location: token request
• Change Controller: IESG
• Specification Document(s): of [[this document]]

 

• Name: "salt_input"
• Parameter Usage Location: token request
• Change Controller: IESG
• Specification Document(s): of [[this document]]

 

• Name: "client_cred_verify"
• Parameter Usage Location: token request
• Change Controller: IESG
• Specification Document(s): of [[this document]]

 

• Name: "client_cred_verify_mac"
• Parameter Usage Location: token request
• Change Controller: IESG
• Specification Document(s): of [[this document]]

 

• Name: "client_cred"
• Parameter Usage Location: token request
• Change Controller: IESG
• Specification Document(s): of [[this document]]

OAuth Parameters CBOR Mappings Registry IANA is asked to add the following entries to the "OAuth Parameters CBOR Mappings" registry defined in .

• Name: "context_id"
• CBOR Key: TBD
• Value Type: bstr
• Reference: of [[this document]]

 

• Name: "salt_input"
• CBOR Key: TBD
• Value Type: bstr
• Reference: of [[this document]]

 

• Name: "client_cred_verify"
• CBOR Key: TBD
• Value Type: bstr
• Reference: of [[this document]]

 

• Name: "client_cred_verify_mac"
• CBOR Key: TBD
• Value Type: bstr
• Reference: of [[this document]]

 

• Name: "client_cred"
• CBOR Key: TBD
• Value Type: bstr
• Reference: of [[this document]]

CBOR Web Token Claims Registry IANA is asked to add the following entries to the "CBOR Web Token Claims" registry.

• Claim Name: "salt_input"
• Claim Description: Client provided salt input
• JWT Claim Name: "N/A"
• Claim Key: TBD
• Claim Value Type(s): bstr
• Change Controller: IESG
• Specification Document(s): of [[this document]]

 

• Claim Name: "contextId_input"
• Claim Description: Client context id input
• JWT Claim Name: "N/A"
• Claim Key: TBD
• Claim Value Type(s): bstr
• Change Controller: IESG
• Specification Document(s): of [[this document]]

 

• Claim Name: "client_cred"
• Claim Description: Client Credential
• JWT Claim Name: "N/A"
• Claim Key: TBD
• Claim Value Type(s): map
• Change Controller: IESG
• Specification Document(s): of [[this document]]

TLS Exporter Label Registry IANA is asked to add the following entry to the "TLS Exporter Label" registry defined in and updated in .

• Value: EXPORTER-ACE-Sign-Challenge-Client-AS
• DTLS-OK: Y
• Recommended: N
• Reference: [[this document]] ()

References Normative References IoTconsultancy.nl InterDigital RISE AB This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces RFC 7390, while it updates RFC 7252 and RFC 7641. RISE AB Ericsson AB Ericsson AB Ericsson AB Universitaet Duisburg-Essen This document defines Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g., sent over IP multicast. In particular, the described approach defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with any other member of the group for pairwise OSCORE communication. Combitech Ericsson Spotify AB Arm Ltd. This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. Ericsson AB Combitech Ericsson AB RISE This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. Combitech This specification defines new parameters and encodings for the OAuth 2.0 token and introspection endpoints when used with the framework for authentication and authorization for constrained environments (ACE). These are used to express the proof-of-possession key the client wishes to use, the proof-of-possession key that the Authorization Server has selected, and the key the Resource Server uses to authenticate to the client. RISE AB Universitaet Duisburg-Essen Ericsson AB This document defines an application profile of the ACE framework for Authentication and Authorization, to request and provision keying material in group communication scenarios that are based on CoAP and secured with Group Object Security for Constrained RESTful Environments (OSCORE). This application profile delegates the authentication and authorization of Clients that join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication and proof-of-possession for a key owned by the Client and bound to an OAuth 2.0 Access Token. August Cellars Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes RFC8152. August Cellars Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. THis document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol RFC XXXX. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK] This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols. This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Informative References Universität Bremen TZI Universität Bremen TZI Universität Bremen TZI Ericsson AB Combitech This specification defines a profile of the ACE framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource- constrained server can use this protocol to delegate management of authorization information to a trusted host with less severe limitations regarding processing power and memory. This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection/non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. RISE AB Consultant Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. Brunel University Oxbotica This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) framework to enable authorization in a Message Queuing Telemetry Transport (MQTT)-based publish-subscribe messaging system. Proof-of-possession keys, bound to OAuth2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (broker) authentication. Ericsson AB Ericsson AB RISE AB RISE AB Nexus Group This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50%. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 COSE headers, a C509 TLS certificate type, and a C509 file format. This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments. This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.

Dual Mode (Group OSCORE & OSCORE) This appendix defines the dual mode of this profile, which allows using both OSCORE and Group OSCORE as security protocols, by still relying on a single Access Token. That is, the dual mode of this profile specifies how a Client uses CoAP to communicate to a single Resource Server, or CoAP over IP multicast to communicate to multiple Resource Servers that are members of a group and share a common set of resources. In particular, the dual mode of this profile uses two complementary security protocols to provide secure communication between the Client and the Resource Server(s). That is, it defines the use of either OSCORE or Group OSCORE to protect unicast requests addressed to a single Resource Server, as well as possible responses. Additionally, it defines the use of Group OSCORE to protect multicast requests sent to a group of Resource Servers, as well as possible individual responses. Like in the main mode of this profile, the Client and the Resource Servers need to have already joined the same OSCORE group, for instance by using the approach defined in , which is also based on ACE. The Client proves its access to be authorized to the Resource Server by using an Access Token, which is bound to a key (the proof-of-possession key). This profile mode uses OSCORE to achieve proof of possession, and OSCORE or Group OSCORE to achieve server authentication. Unlike in the main mode of this profile, where a public key is used as pop-key, this dual mode uses OSCORE-related, symmetric keying material as pop-key instead. Furthermore, this dual mode provides proof of Client's membership to the correct OSCORE group, by securely binding the pre-established Group OSCORE Security Context to the pairwise OSCORE Security Context newly established between the Client and the Resource Server. In addition to the terminology used for the main mode of this profile, the rest of this appendix refers also to "pairwise OSCORE Security Context" as to an OSCORE Security Context established between only one Client and one Resource Server, and used to communicate with OSCORE .

Protocol Overview This section provides an overview on how to use the ACE framework for authentication and authorization to secure communications between a Client and a (set of) Resource Server(s) using OSCORE and/or Group OSCORE . Just as for main mode of this profile overviewed in , the process for joining the OSCORE group through the respective Group Manager as defined in must take place before the process described in the rest of this section, and is out of the scope of this profile. An overview of the protocol flow for the dual mode of this profile is shown in . In the figure, it is assumed that both RS1 and RS2 are associated with the same AS. It is also assumed that C, RS1 and RS2 have previously joined an OSCORE group with Group Identifier (gid) "abcd0000", and got assigned Sender ID (sid) "0", "1" and "2" in the group, respectively. The names of messages coincide with those of when applicable.

Protocol Overview. ] | | | | | | | | [<---- AS Request ------] | | | | Creation Hints | | | | | | | |-------- POST /token ----------------------------------------------->| | (aud: RS1, sid: 0, gid: abcd0000, ...) | | | | | | |<-------------------------------- Access Token + RS Information -----| | | (aud: RS1, sid: 0, gid: abcd0000, ...) | | | | | |---- POST /authz-info ----->| | | | (access_token, N1, ID1) | | | | | | | |<-- 2.01 Created (N2, ID2) -| | | | | | | /Pairwise /Pairwise | | Security Context Security Context | | Derivation/ Derivation/ | | | | | | |-------- POST /token ----------------------------------------------->| | (aud: RS2, sid: 0, gid: abcd0000, ...) | | | | | | |<-------------------------------- Access Token + RS Information -----| | | (aud: RS2, sid: 0, gid: abcd0000, ...) | | | | | |---- POST /authz-info ------------------>| | | (access_token, N1', ID1') | | | | | | | |<-- 2.01 Created (N2', ID2')-------------| | | | | | /Pairwise Security | /Pairwise Security | Context Derivation/ | Context Derivation/ | | | | | |----- OSCORE Request ------>| | | | (kid: ID2) | | | | | | | | | | | | | | | | | | | | /Proof-of-possession; | | | Pairwise Security | | | Context storage/ | | | | | | |<---- OSCORE Response ------| | | | | | | /Proof-of-possession; | | | Pairwise Security | | | Context storage/ | | | | | | | /Mutual authentication | | | between C and RS1 | | | (as OSCORE peers)/ | | | | | | | | | | | |- Group OSCORE Request -+-->| | | | (kid: 0, gid: abcd0000) \-------------->| | | | | | |<-- Group OSCORE Response --| | | | (kid: 1) | | | | | | | /Mutual authentication | | | between C and RS1 | | | (as group members)/ | | | | | | | |<-- Group OSCORE Response ---------------| | | (kid: 2) | | | | | | | /Mutual authentication | | | between C and RS2 | | | (as group members)/ | | | | | | | | ... | | | ]]>

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

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

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 ) 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 . 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 authentication credential 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 ) 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 . 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.

Secure Communication Other than starting the communication with the RS using Group OSCORE as described in , 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 , 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 ), 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.

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. defines how to derive a pairwise OSCORE Security Context based on a shared Master Secret and a set of other parameters, established between the OSCORE client and server, which the client receives from the AS in this exchange. The proof-of-possession key (pop-key) received from the AS in this exchange MUST be used to build the Master Secret in OSCORE (see and ).

C-to-AS: POST to Token Endpoint The Client-to-AS request is specified in . 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 ), with the following modifications.

• The parameter 'req_cnf' MUST NOT be included in the payload.
• The parameter 'client_cred', defined in 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 authentication credential 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 with the public key in the 'client_cred' parameter above.

An example of such a request is shown in .

Example C-to-AS POST /token request for an Access Token bound to a symmetric key.

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 , which MUST include a 'kid' field, as defined in . The 'kid' field has as value a CBOR byte string containing the OSCORE_Input_Material Identifier (assigned as discussed in ). 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 . 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 , where the Client, following a change of authentication credential in the OSCORE group, requests a new Access Token associated with the public key of the new authentication credential, while still without changing the existing pairwise OSCORE Security Context with the RS. An example of such a request is shown in .

Example C-to-AS POST /token request for updating rights to an Access Token bound to a symmetric key.

'client_cred' Parameter The 'client_cred' parameter is an OPTIONAL parameter of the Access Token request message defined in . This parameter provides an asymmetric key that the Client wishes to use as its own public key, but which is not used as proof-of-possession key. This parameter follows the syntax of the 'cnf' claim from when including Value Type "COSE_Key" (1) and specifying an asymmetric key. Alternative Value Types defined in future specifications are fine to consider if indicating a non-encrypted asymmetric key.

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 , 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 . If the Client request was invalid, or not authorized, the AS returns an error response as described in . 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 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 . In particular, the AS provides an OSCORE_Input_Material object, which is defined in and included in the 'cnf' parameter (see ) 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 ) 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 ) 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 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 authentication credential 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 ).

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

Example AS-to-C Access Token response with the Group OSCORE profile.

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

Example CWT with OSCORE parameters.

The same CWT as in and encoded in CBOR is shown in , using the value abbreviations defined in and . 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.

Example CWT with OSCORE parameters.

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 . 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 ). This information needs to be included in the Access Token, in order for the RS to identify the previously generated pairwise OSCORE Security Context. shows an example of such an AS response. The Access Token has been truncated for readability.

Example AS-to-C Access Token response with the Group OSCORE profile, for update of access rights.

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

Example CWT with OSCORE parameters for update of access rights.

Public Key Hash as Client Credential As a possible optimization to limit the size of the Access Token, the AS may specify as value of the 'client_cred' claim simply the hash of the Client's public key, i.e., the hash of the COSE Key K equivalent to the authentication credential that the Client uses in the OSCORE group. The specifically used hash-function MUST be collision-resistant on byte-strings, and MUST be selected from the "Named Information Hash Algorithm" Registry defined in . In particular, the AS provides the Client with an Access Token as defined in , with the following differences. The AS prepares INPUT_HASH as follows, with | denoting byte string concatenation.

• If the equivalent COSE Key K has COSE Key Type OKP, INPUT_HASH = i, where 'i' is the x-parameter of the COSE_Key specified in the 'client_cred' parameter of the Token request, encoded as a CBOR byte string.
• If the equivalent COSE Key K has COSE Key Type EC2, INPUT_HASH = (i_1 | i_2), where 'i_1' and 'i_2' are the x-parameter and y-parameter of the COSE_Key specified in the 'client_cred' parameter of the Token request, respectively, each encoded as a CBOR byte string.
• If the equivalent COSE Key K has COSE Key Type RSA, INPUT_HASH = (i_1 | i_2), where 'i_1' and 'i_2' are the n-parameter and e-parameter of the COSE_Key specified in the 'client_cred' parameter of the Token request, respectively, each encoded as a CBOR byte string.

Then, the AS hashes INPUT_HASH according to the procedure described in , with the output OUTPUT_HASH in binary format, as described in . Finally, the AS includes a single entry within the 'client_cred' claim of the Access Token. This entry has label "kid" (3) defined in , and value a CBOR byte string wrapping OUTPUT_HASH. Upon receiving the Access Token, the RS processes it according to , with the following differences. The RS considers: the content of the 'contextId_input' 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 content of the 'client_cred' claim as the hash RECEIVED_HASH of a COSE Key equivalent to the authentication credential that the Client uses in the group. The RS MUST check whether it already stores an authentication credential associated with the pair (GID, Sender ID) above, such that the recomputed hash NEW_HASH of its equivalent COSE Key matches with RECEIVED_HASH from the 'client_cred' claim. 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 , 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 RECEIVED_HASH matches with the recomputed hash NEW_HASH of a COSE Key equivalent to the Client's authentication credential retrieved from the Group Manager.
• The RS MUST check that 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.

The RS MUST calculate NEW_HASH using the same method used by the AS described above, and using the same hash function. The hash function to use can be determined from the information conveyed in the 'client_cred' claim, as the procedure described in also encodes the used hash function as metadata of the hash value.

Client Credential Claim The 'client_cred' claim provides an asymmetric key that the Client owning the Access Token wishes to use as its own public key, but which is not used as proof-of-possession key. This parameter follows the syntax of the 'cnf' claim from when including Value Type "COSE_Key" (1) and specifying an asymmetric key. Alternative Value Types defined in future specifications are fine to consider, if indicating a non-encrypted asymmetric key or full-fledged autentication credential.

Client-RS Communication This section details the POST request and response to the /authz-info endpoint between the Client and the RS. With respect to the exchanged messages and their content, the Client and the RS perform as defined in the OSCORE profile of ACE (see ). That is, the Client generates a nonce N1 and posts it to the RS, together with: an identifier ID1 unique in the sets of its own Recipient IDs from its pairwise OSCORE Security Contexts; and the Access Token that includes the material provisioned by the AS. Then, the RS generates a nonce N2, and an identifier ID2 unique in the sets of its own Recipient IDs from its pairwise OSCORE Security Contexts. After that, the RS derives a pairwise OSCORE Security Context as described in . In particular, it uses the two exchanged nonces and the two identifiers established with the Client, as well as two shared secrets together with additional pieces of information specified in the Access Token. Both the client and the RS generate the pairwise OSCORE Security Context using the pop-key as part of the OSCORE Master Secret. In addition, the derivation of the pairwise OSCORE Security Context takes as input also information related to the OSCORE group, i.e., the Master Secret and Group Identifier of the group, as well as the Sender ID of the Client in the group. Hence, the derived pairwise OSCORE Security Context is also securely bound to the Group OSCORE Security Context of the OSCORE Group. Thus, the proof-of-possession required to bind the Access Token to the Client occurs after the first OSCORE message exchange. Therefore, an attacker using a stolen Access Token cannot generate a valid pairwise OSCORE Security Context and thus cannot prove possession of the pop-key. Also, if a Client legitimately owns an Access Token but has not joined the OSCORE group, that Client cannot generate a valid pairwise OSCORE Security Context either, since it lacks the Master Secret used in the OSCORE group. Besides, just as in the main mode (see ), the RS is able to verify whether the Client has indeed the claimed Sender ID and authentication credential in the OSCORE group.

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 ). The same recommendations, considerations and behaviors defined in 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 with 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 ), 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 with the new Access Token.

RS-to-C: 2.01 (Created) The RS MUST verify the validity of the Access Token as defined in , 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 authentication credential 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 actual COSE Key equivalent to the authentication credential of the claimed Client, retrieved from its local storage or from the Group Manager (see ).

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 ). 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 hold for this document.

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 .

Example of Master Salt construction using CBOR encoding.

• 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 ; 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 .
• The Client MUST set the Sender ID as ace_server_recipientid, received as described in .
• The Client MUST set the AEAD Algorithm, ID Context, HKDF, and OSCORE Version as indicated in the corresponding parameters received from the AS in , 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 and of .

Finally, the client MUST derive the complete pairwise OSCORE Security Context following . 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 ), 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 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 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 , although without updating the ID Context.

OSCORE Setup - Resource Server Side After validation of the Access Token as defined in 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 ); 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 ); 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 , 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 ); 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 .
• The RS MUST set the Sender ID as ace_client_recipientid, received as described in .
• 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 ), 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 and of .

Finally, the RS MUST derive the complete pairwise OSCORE Security Context following . 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 , 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 . 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 authentication credential of the Client only the authentication credential associated with the stored Access Token. As defined in , a change of authentication credential 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 authentication credential that the Client has in the group. If Group OSCORE verification fails, error responses are used, as specified in Sections and of . Additionally, for every incoming request, if OSCORE or Group OSCORE verification succeeds, the verification of access rights is performed as described in . 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 hold also for the RS.

Access Rights Verification The RS MUST follow the procedures defined in . Additionally, if the RS receives an OSCORE-protected request from a Client, the RS processes it according to . If the OSCORE verification succeeds, and the target resource requires authorization, the RS retrieves the authorization information from the Access Token associated with 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.

Change of Client's Authentication Credential in the Group During its membership in the OSCORE group, the client might change the authentication credential it uses in the group. When this happens, the Client uploads the new authentication credential to the Group Manager, as defined in . 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 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 public key of the new authentication credential 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 authentication credential that the Client uses in the OSCORE group.
   • 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.
   • 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 ), the Client performs the same exchanges with the RS as defined in , 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 . In particular, no new pairwise OSCORE Security Context is established between the Client and the RS.

Secure Communication with the AS The same considerations for secure communication with the AS as defined in hold.

Discarding the Security Context The Client and the RS MUST follow what is defined in about discarding the pairwise OSCORE Security Context. Additionally, they MUST follow what is defined in the main mode of the profile (see ), with respect to the Group OSCORE Security Context. 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 . In such a case, the Client SHOULD request a new Access Token and post it to the RS, in order to establish a new pairwise OSCORE Security Context and bind it to the Group OSCORE Security Context obtained upon re-joining the group.

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

CBOR mappings for new parameters.

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

CBOR mappings for new claims.

Security Considerations The dual mode of this profile inherits the security considerations from the main mode (see ), as well as from the security considerations of the OSCORE profile of ACE . Also, the security considerations about OSCORE hold for the dual mode of this profile, as to the specific use of OSCORE. Unlike the main mode and consistently with , the dual mode of this profile cannot be used to issue an Access Token for an audience that comprises multiple RSs. This is because the proof-of-possession key bound to an Access Token is the OSCORE Master Secret included in the OSCORE_Input_Material object of the 'cnf' claim, and it has to be shared only between the Client and one RS.

Privacy Considerations The same privacy considerations as defined in the main mode of this profile apply (see ). In addition, as this profile mode also uses OSCORE, the privacy considerations from apply as well, as to the specific use of OSCORE. Furthermore, this profile mode inherits the privacy considerations from the OSCORE profile of ACE .

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

• (Optional) discovery process of how the Client finds the right AS for an RS it wants to send a request to: Not specified.
• Communication protocol the Client and the RS must use: CoAP.
• Security protocol(s) the Client and RS must use: Group OSCORE, i.e., exchange of secure messages by using a pre-established Group OSCORE Security Context. The optional dual mode defined in additionally uses OSCORE, i.e., establishment of a pairwise OSCORE Security Context and exchange of secure messages.
• How the Client and the RS mutually authenticate: Explicitly, by possession of a common Group OSCORE Security Context, and by either: usage of digital signatures embedded in messages, if protected with the group mode of Group OSCORE; or protection of messages with the pairwise mode of Group OSCORE, by using pairwise symmetric keys, derived from the asymmetric keys of the two peers exchanging the message. Note that the mutual authentication is not completed before the Client has verified an OSCORE or a Group OSCORE response using the corresponding security context.
• Content-format of the protocol messages: "application/ace+cbor".
• Proof-of-Possession protocol(s) and how to select one; which key types (e.g., symmetric/asymmetric) supported: Group OSCORE algorithms; distributed and verified asymmetric keys. In the optional dual mode defined in : OSCORE algorithms; pre-established symmetric keys.
• profile identifier: coap_group_oscore
• (Optional) how the RS talks to the AS for introspection: HTTP/CoAP (+ TLS/DTLS/OSCORE).
• How the client talks to the AS for requesting a token: HTTP/CoAP (+ TLS/DTLS/OSCORE).
• How/if the authz-info endpoint is protected: Not protected.
• (Optional) other methods of token transport than the authz-info endpoint: Not specified.

Acknowledgments The authors sincerely thank Benjamin Kaduk, John Mattsson, Dave Robin, Jim Schaad and Goeran Selander for their comments and feedback. The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home (Grant agreement 952652).