]> The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework RISE AB
Isafjordsgatan 22 Kista 164 40 Kista Sweden marco.tiloca@ri.se
RISE AB
Isafjordsgatan 22 Kista 164 40 Kista Sweden rikard.hoglund@ri.se
Ericsson AB
Torshamnsgatan 23 Kista 164 40 Kista Sweden francesca.palombini@ericsson.com
Security ACE Working Group Internet-Draft This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) to provide communication security between a client and one or multiple resource servers that are members of an OSCORE group. The profile securely binds an OAuth 2.0 access token to the public key of the client associated with the private key used by that client in the OSCORE group. The profile uses Group OSCORE to achieve server authentication and proof of possession of the client's private key. Also, it provides proof of the client's membership to the OSCORE group by binding the access token to information that pertains to the Group OSCORE Security Context, thus allowing the resource server(s) to verify the client's membership upon receiving the access token. Effectively, the profile enables fine-grained access control paired with secure group communication, in accordance with the Zero Trust principles. Discussion Venues Discussion of this document takes place on the Authentication and Authorization for Constrained Environments Working Group mailing list (ace@ietf.org), which is archived at . 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 hosted at multiple servers at once, e.g., over IP multicast. Typical examples include switching of luminaires, control of actuators, 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 could be acceptable to enforce access control in a straightforward fashion. That is, any client authorized to join the group, hence to obtain the group keying material, can also be implicitly authorized to perform any action at any resource hosted at any server in the group. An example of an application where such implicit authorization might serve well is a simple lighting scenario, where the lightbulbs are the servers and 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 the status of any light. 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 hosted at other group members. For instance, enforcing access control in accordance with a more fine-grained approach is required in the two following use cases. As a first case, an application provides control of smart locks acting as servers in the group, where: a first type of client, e.g., a user account of a child, is allowed to only query the status of the smart locks; while a second type of client, e.g., a user account of a parent, is allowed to both query and change the status of the smart locks. Further similar applications concern the enforcement of different sets of permissions in groups with sensor/actuator devices, e.g., thermostats acting as servers. Also, some group members may even be intended as servers only. Hence, they must be prevented from acting as clients altogether and from accessing resources at other servers in the group, 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 levels 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, 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 that are otherwise allowed also to C1 clients. Given the different maximum authority of different clients, fine-grained access control would effectively limit the execution of high- and emergency-priority commands only to devices that are in fact authorized to perform such actions. Besides, it would prevent a misconfigured or compromised device from initiating a high-priority command and lock out normal control. In the cases above, being a legitimate group member and storing the group keying material is not meant to imply any particular access rights. Instead, access control to the secure group communication channel and access control to the resource space provided by servers in the group should remain logically separated domains. This is aligned with the Zero Trust paradigm , which focuses on resource protection and builds on the premise that trust is never granted implicitly, but must be continually evaluated. In particular, Zero Trust protections involve "minimizing access to resources (such as data and compute resources and applications/services) to only those subjects and assets identified as needing access as well as continually authenticating and authorizing the identity and security posture of each access request." Furthermore, highlights how the Zero Trust goal is to "prevent unauthorized access to data and services coupled with making the access control enforcement as granular as possible", in order to "enforce least privileges needed to perform the action in the request." As a step in this direction, one can be tempted to introduce a different security group for each different set of access rights. However, this inconveniently results in additional keying material to distribute and manage. In particular, if there is a change in the access rights pertaining to a node, this requires evicting the node from the group, after which the node has to join a different group aligned with its new access rights. Moreover, the keying material of both groups would have to be renewed for their current members. Overall, this would have a non-negligible impact on operations and performance. Instead, a fine-grained yet flexible access control model can be enforced within the same group, by using the Authentication and Authorization for Constrained Environments (ACE) framework . That is, a client has to first obtain authorization credentials in the form of an access token and then upload it to the intended resource server(s) in the group, before accessing the target resources hosted at such resource server(s). The ACE framework delegates to separate profile documents how to secure communications between the client and the resource servers. However, each of the current profiles of ACE defined in relies on a security protocol that cannot be used to protect one-to-many group messages, for example sent over IP multicast. This document specifies the "coap_group_oscore" profile of the ACE framework, according to which a client uses the Constrained Application Protocol (CoAP) to communicate with one or multiple resource servers that are members of an application group and share a common set of resources. The security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) is used to protect messages exchanged between the client and the resource servers. This requires that both the client and the resource servers have joined the same OSCORE group. This profile describes how access control is enforced for a client that has joined an OSCORE group, to access resources hosted by other members in that group. The client needs to join the OSCORE group before requesting an access token that indicates the client's authorization and access rights related to such resources in the group. The process for joining the OSCORE group through the respective Group Manager takes place separately from the process described in this document, and it is out of the scope of this profile. The client proves its authorization and access rights to the resource server(s) by using an access token that is bound to the client's public key used in the OSCORE group (the proof-of-possession key). This profile uses Group OSCORE to achieve server authentication and proof of possession of the client's private key used in the OSCORE group in question. Note that proof of possession is not achieved through a dedicated protocol element. Instead, it is achieved when the resource server receives from the client a message protected with Group OSCORE and successfully verifies source authentication of such message through the client's public key bound to the access token. Furthermore, this profile provides proof of the client's membership to the OSCORE group, by binding the access token to information that pertains to the Group OSCORE Security Context, as well as to the client's authentication credential used in the group and including the client's public key. This allows the resource server(s) in the group to verify the client's group membership upon receiving the access token. Object Security for Constrained RESTful Environments (OSCORE) specifies how to use CBOR Object Signing and Encryption (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 the protected message (when using the group mode); or by protecting a message with pairwise keying material derived from the asymmetric keys of the two peers exchanging the message (when using the pairwise mode).
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 Concise Binary Object Representation (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 within the group. As per , an authentication credential provides the public key as well as a comprehensive set of information related to the public key algorithm, including, e.g., the elliptic curve used (when applicable).
Readers are also 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 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. The CoAP definition, which is "[a]n entity participating in the CoAP protocol" , is not used in this document. Additionally, this document makes use of the following terminology.
  • Pairwise-only group: an OSCORE group that uses only the pairwise mode of Group OSCORE (see ).
Notations Examples throughout this document are expressed in CBOR diagnostic notation as defined in and . Diagnostic notation comments are often used to provide a textual representation of the parameters' keys and values. In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDDL model shown in of . For example, {e'context_id_param': h'abcd0000', e'salt_input_param': h'00'} stands for {71: h'abcd0000', 72: h'00'}. Note to RFC Editor: Please delete the paragraph immediately preceding this note. Also, in the CBOR diagnostic notation used in this document, please replace the constructs of the form e'SOME_NAME' with the value assigned to SOME_NAME in the CDDL model shown in of . Finally, please delete this note.
Protocol Overview This section provides an overview of this profile, i.e., of how to use the ACE framework for authentication and authorization when communications between a client and one or more resource servers are secured using Group OSCORE . In this profile, access control is enforced for a client that has joined an OSCORE group, to access resources hosted by resource servers that are also members in the same group. After the client has joined the OSCORE group and as long as it is a member of that group, the client can send to the authorization server (AS) an access token request for issuing an access token that indicates the client's authorization and access rights related to such resources in the group. If the request is granted, the AS replies to the client with a successful response. Also, the AS can provide the access token to the client by including it in the response, or instead upload the access token directly to the RS as per the alternative workflow defined in . The latter option is not detailed further in this document. In the case that the client has obtained an access token from the AS, the client uploads the access token to the RS, using the authz-info endpoint and mechanisms specified in . When using this profile, the communication with the authz-info endpoint is not protected. If the access token is valid, the RS relies on information in the access token and on the assistance of the Group Manager responsible for the group to verify the client's group membership in the group. If all verifications succeed, the RS replies to the client with a 2.01 (Created) response. Then, the RS associates the access token with the Recipient Context pertaining to the client, within the Group OSCORE Security Context used in the group. After that, when the RS receives and successfully verifies a request from the client protected with Group OSCORE, the RS performs access rights verification per the access token associated with the Recipient Context pertaining to the client, which was used to verify the request and is included in the Group OSCORE Security Context used in the group. The process for joining the OSCORE group through the respective Group Manager takes place separately from the process described in this document, and it is out of the scope of this profile. For applications that intend to use this profile, it is RECOMMENDED that the realization of Group Manager used is the one based on the ACE framework and defined in . An overview of the protocol flow for this profile is shown by the example in , where it is assumed that both the resource servers RS1 and RS2 are associated with the same AS. It is also assumed that the client C as well as RS1 and RS2 have previously joined an OSCORE group with Group Identifier (Gid) 0xabcd0000, and that they got assigned Sender ID (Sid) 0x00, 0x01, and 0x02 in the group, respectively. The names of messages coincide with those of when applicable. Messages in square brackets are optional.
Protocol Overview C RS1 RS2 AS [ Resource Request ] [ AS Request ] Creation Hints POST /token (aud: "RS1", Sid: 0x00, Gid: 0xabcd0000, ...) Access token T1 + Access Information POST /authz-info (access_token: T1) 2.01 Created POST /token (aud: "RS2", Sid: 0x00, Gid: 0xabcd0000, ...) Access token T2 + Access Information POST /authz-info (access_token: T2) 2.01 Created Group OSCORE Request (kid: 0x00, Gid: 0xabcd0000) | / Authentication of C / | | / Proof of possession / Group OSCORE Response (kid: 0x01) / Authentication of RS1 / Group OSCORE Response (kid: 0x02) / Authentication of RS2 / ... ] | | | | | | | | [<------ AS Request -------] | | | | Creation Hints | | | | | | | +-------- POST /token ----------------------------------------------->| | (aud: "RS1", Sid: 0x00, | | | | Gid: 0xabcd0000, ...) | | | | | | | |<---------------------------------------------- Access token T1 -----+ | | + Access Information | | | | | +----- POST /authz-info ------>| | | | (access_token: T1) | | | | | | | |<------- 2.01 Created --------+ | | | | | | +-------- POST /token ----------------------------------------------->| | (aud: "RS2", Sid: 0x00, | | | | Gid: 0xabcd0000, ...) | | | | | | | |<---------------------------------------------- Access token T2 -----+ | | + Access Information | | | | | +----- POST /authz-info ------------------>| | | (access_token: T2) | | | | | | | |<------ 2.01 Created ---------------------+ | | | | | +-- Group OSCORE Request --+-->| | | | (kid: 0x00, \ | | | | Gid: 0xabcd0000) \ | | | | `----------->| | | | | | | / Authentication of C / | | | | | | / Proof of possession / | | | | | |<--- Group OSCORE Response ---+ | | | (kid: 0x01) | | | | | | | / Authentication of RS1 / | | | | | | | |<--- Group OSCORE Response ---------------+ | | (kid: 0x02) | | | | | | | / Authentication of RS2 / | | | | | | | | ... | | | | | | | ]]>
As long as the client is a member of the OSCORE group and the access token previously uploaded at the RS is still valid, the client can contact the AS to ask for updating its access rights, through a process more efficient than that used for the first access token. To this end, the client can send to the AS an access token request similar to the initial one mentioned above that was sent when asking for the first access token. This latest access token request also includes a "token series identifier" provided by the AS in the response to the initial access token request, which allows the AS to retrieve the data that it previously shared with the client. The token series identifier is assigned by the AS and used to identify a series of access tokens, called a "token series" (see ). After the new issued access token is successfully uploaded at the RS and thus the client's access rights are updated accordingly, the new issued access token effectively becomes the latest in its token series also for the RS, but the token series identifier remains the same. When the latest access token of a token series becomes invalid (e.g., when it expires or gets revoked), that token series ends.
Pre-Conditions Using Group OSCORE to protect message exchanges between the client and the resource servers (RSs) requires that the client and the RSs have joined the same OSCORE group. This especially includes the derivation of the Group OSCORE Security Context and the assignment of unique Sender IDs to use in the group. Nodes can join the OSCORE group through the respective Group Manager, e.g., as specified in . The client needs to join the OSCORE group before requesting an access token that indicates the client's authorization and access rights in the group. After the client and RSs have joined the group, this profile enforces access control for the client to access resources on those RSs, by securely communicating with Group OSCORE. 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 .
Requesting an Access Token This profile requires that the client requests an access token from the AS for the resource(s) that it wants to access at the RS(s), by using the token endpoint as specified in . In general, different RSs can be associated with different authorization servers, even if the RSs are members of the same OSCORE group. However, assuming proper configurations and trust relationships, it is possible for multiple RSs associated with the same AS to be part of a single audience (i.e., a group-audience, see ). In such a case, the client can request a single access token intended for the group-audience, hence to all the RSs included therein. A particular group-audience might be defined as including all the RSs in the OSCORE group. When requesting the first access token of a token series, the client MUST include in the access token request to the AS the Group Identifier of the OSCORE group, together with its own Sender ID and authentication credential used in that group. The AS MUST include these pieces of information in the access token issued for the client. In such an access token request, the client can also include a proof-of-possession (PoP) evidence to prove possession of the private key corresponding to its own authentication credential to the AS. The PoP evidence is computed over a PoP input uniquely related to the secure communication association between the client and the AS. Including the PoP evidence is OPTIONAL under particular circumstances and is REQUIRED otherwise (see ). If the request from the client is granted, then the AS can include the issued access token in the access token response to the client, or instead upload the access token directly to the RS as per the Short Distribution Chain (SDC) workflow defined in . This document focuses on the former option (also shown in the example in ), while the latter option is not detailed further here. The access token request and response exchanged between the client and the AS MUST be confidentiality-protected and MUST ensure authenticity. In this profile, it is RECOMMENDED to use OSCORE between the client and the AS, to reduce the number of libraries that the client has to support. Other protocols fulfilling the security requirements defined in Sections and of MAY alternatively be used, such as TLS or DTLS .
Access Token Uploading After having obtained the access token from the AS, the client uploads the access token to the RS, by sending a POST request to the authz-info endpoint and using the mechanisms specified in . When using this profile, the communication that C has with the authz-info endpoint is not protected. When verifying the first access token of a token series (see ), the RS joins the pertaining OSCORE group if it has not already (see for further details). If the access token is valid, the RS replies to the POST request with a 2.01 (Created) response. Also, the RS associates the access token with the Recipient Context pertaining to the client, within the Group OSCORE Security Context used in the OSCORE group. In practice, the RS maintains a collection of Security Contexts with associated authorization information, for all the clients that it is currently communicating with. The authorization information is a policy that is used as input when processing requests from those clients to access resources at the RS. After that, the RS associates the access token with the following pieces of information: i) the identifier of the token series which the access token belongs to; ii) the target audience for which the access token is issued; and iii) the authentication credential of the client in the OSCORE group (see ). Such pieces of information are specified by corresponding elements of the access token (see ). The above has considered an access token intended for a single RS. However, as discussed in , an access token can be intended for a group-audience including multiple RSs in the OSCORE group. In such a case, the client could efficiently upload the access token to many or all of those RSs at once (e.g., over IP multicast), after which each RS individually performs the same steps described above.
Secure Communication The client can send a CoAP request protected with Group OSCORE to the RS. This can be a unicast request targeting the RS , or a one-to-many group request (e.g., over IP multicast) targeting the OSCORE group where the RS is also a member. To this end, the client uses the Group OSCORE Security Context already established upon joining the OSCORE group, unless it has a more recent Security Context that has been established in the group as a result of a group rekeying (see ). When the client sends to the RS a request protected with the Group OSCORE Security Context and the RS successfully verifies the request, the RS authenticates the client as a legitimate member of the OSCORE group. After that, if the target resource requires authorization, the RS performs access rights verification as per the access token associated with the Recipient Context pertaining to the client, which was used to verify the request and is included in the Group OSCORE Security Context used in the group. The RS may send a response back to the client, also protecting it with Group OSCORE.
Client-AS Communication This section details the access token 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 (PoP) key, which is included in the client's authentication credential specified in the access token.
Preliminary Operations The following considers a client that is a member of an OSCORE group G with GID* as current Group Identifier (Gid), within which the client currently has SID* as Sender ID and uses a public authentication credential AUTH_CRED_C that specifies the PoP key K. The client MUST perform the following steps, before requesting an access token to be bound to AUTH_CRED_C (hence to the PoP key K) and to be associated with the client's membership in group G through the values GID* and SID*.
  1. The client checks whether it is a member of any two OSCORE groups G1 and G2 such that all the following conditions hold.
    • Both groups have GID* as current Gid.
    • The client uses SID* as Sender ID in both groups.
    • The client uses the same AUTH_CRED_C in both groups.
  2. If such two groups G1 and G2 are found at Step 1, then the client moves to Step 3. Otherwise, the client terminates this algorithm and proceeds with requesting the access token as defined in .
  3. The client can choose to terminate this algorithm and perform it again later on. Alternatively, the client can alter its current group memberships, in order to ensure that two groups like G1 and G2 cannot be determined. To this end, the client has two available options.
    • The client leaves some of the OSCORE groups that could be determined as groups like G1 and G2, e.g., as specified in .
    • The client obtains a new Sender ID in some of the OSCORE groups that could be determined as groups like G1 and G2. To this end, the client can request a new Sender ID in a group to the Group Manager responsible for that group, e.g., as specified in . Alternatively, the client can re-join a group, thereby obtaining a new Sender ID in that group.
    Finally, the client moves to Step 1.
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 (see ). When requesting the first access token of a token series, 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 Gid (i.e., the ID Context) of an OSCORE group whose intended members are both the client and the RS(s) in the audience for which the access token is asked to be issued. In particular, the client wishes to communicate with the RS(s) in that audience using the Group OSCORE Security Context associated with that OSCORE group.
  • 'salt_input', defined in 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 and its inner confirmation value specifies the authentication credential AUTH_CRED_C that the client uses in the OSCORE group. The public key included in the authentication credential will be used as the PoP key bound to the access token. The inner confirmation value of the 'req_cnf' parameter MUST specify AUTH_CRED_C as transported by value. At the time of writing this specification, acceptable formats of authentication credentials in Group OSCORE are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) , X.509 certificates , and C509 certificates . Further formats may be available in the future and would be acceptable to use as long as they comply with the criteria compiled in . In particular, an authentication credential has to explicitly include the public key as well as a comprehensive set of information related to the public key algorithm, including, e.g., the elliptic curve used (when applicable). Note that C might have previously uploaded AUTH_CRED_C to the Group Manager as provided within a chain or a bag (e.g., as the end-entity certificate in a chain of certificates). For example, such uploading can rely on the 'client_cred' parameter of a Join Request or of an Authentication Credential Update Request sent to the Group Manager as specified in Sections and of . In such a case, the inner confirmation value of the 'req_cnf' parameter MUST specify AUTH_CRED_C as provided within the same chain or bag. [ As to CWTs and CCSs, the CWT Confirmation Methods 'kcwt' and 'kccs' are under pending registration requested by draft-ietf-ace-edhoc-oscore-profile. ] [ As to X.509 certificates, the CWT Confirmation Methods 'x5bag' and '5chain' are under pending registration requested by draft-ietf-ace-edhoc-oscore-profile. ] [ As to C509 certificates, the CWT Confirmation Methods 'c5b' and 'c5c' are under pending registration requested by draft-ietf-ace-edhoc-oscore-profile. ]
Furthermore, the payload of the request can include exactly one of the two following parameters, specifying a proof-of-possession (PoP) evidence computed by the client.
  • 'client_cred_verify', defined in of this document, specifying the client's PoP evidence as a signature, which is computed as defined later in this section. This parameter MUST NOT be included if the OSCORE group is 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 later in this section. This parameter MUST NOT be included if the OSCORE group is not a pairwise-only group.
The PoP evidence can be used by the AS to achieve proof of possession of the client's private key, i.e., to verify that the client indeed owns the private key associated with the public key within AUTH_CRED_C. When preparing the POST request, the client might know that the AS has previously achieved proof of possession of the private key in question. In such a case, it is OPTIONAL for the client to compute the PoP evidence and to specify it in the 'client_cred_verify' or 'client_cred_verify_mac' parameter of the POST request. If the client believes that the AS has not previously achieved proof of possession of the private key in question or that such proof was achieved but does not hold anymore, then the client MUST compute the PoP evidence as defined below and MUST specify it in the 'client_cred_verify' or 'client_cred_verify_mac' parameter of the POST request. In order to compute the PoP evidence, the client MUST use as PoP input the byte representation of an information that uniquely represents the secure communication association between the client and the AS. It is RECOMMENDED that the client uses the following as PoP input.
  • If the client and the AS communicate over TLS 1.2 or DTLS 1.2 , the PoP input is an exporter value computed as defined in , using the following inputs:
    • The exporter label "EXPORTER-ACE-PoP-Input-Client-AS" registered in of this document.
    • The empty 'context value', i.e., a 'context value' of zero-length.
    • 32 as length value in bytes.
  • If the client and the AS communicate over TLS 1.3 or DTLS 1.3 , the PoP input is an exporter value computed as defined in , using the following inputs:
    • The exporter label "EXPORTER-ACE-PoP-Input-Client-AS" registered in of this document.
    • The empty 'context_value', i.e., a 'context_value' of zero-length.
    • 32 as 'key_length' in bytes.
  • If the client and the AS communicate over OSCORE , the PoP input is the output PRK of an HKDF-Extract step , i.e., PRK = HMAC-Hash(salt, IKM). In particular, given the OSCORE Security Context CTX shared between the client and the AS, then the following applies.
    • 'salt' takes (x1 | x2), where | denotes byte string concatenation, while x1 and x2 are defined as follows.
      • x1 is the binary representation of a CBOR data item. If CTX does not specify an OSCORE ID Context, the CBOR data item is the CBOR simple value null (0xf6). Otherwise, the CBOR data item is a CBOR byte string, with value the OSCORE ID Context specified in CTX.
      • x2 is the binary representation of a CBOR byte string. The value of the CBOR byte string is the OSCORE Sender ID of the client, which the client stores in its Sender Context of CTX and the AS stores in its Recipient Context of CTX.
    • 'IKM' is the OSCORE Master Secret specified in CTX.
    • The used HKDF is the HKDF Algorithm specified in CTX.
    The following shows an example of input to the HMAC-Hash() function. On the client side, the OSCORE Security Context shared with the AS includes: Then, the following holds.
It is up to applications or future specifications to define what is used as PoP input in further alternative settings. After that, the client computes the PoP evidence as follows.
  • If the OSCORE group is not a pairwise-only group, the PoP evidence MUST be a signature. The client computes the signature over the PoP input, by using the same private key and signature algorithm that it uses for signing messages in the OSCORE group. The client's private key is the one associated with the client's authentication credential used in the OSCORE group and specified in the 'req_cnf' parameter above.
  • If the OSCORE group is a pairwise-only group, the PoP evidence MUST be a MAC computed as follows, by using the HKDF Algorithm HKDF SHA-256, which consists of composing the HKDF-Extract and HKDF-Expand steps . 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 the ECDH algorithm that is used as Pairwise Key Agreement Algorithm in the OSCORE group. The client uses its own Diffie-Hellman private key and the Diffie-Hellman public key of the AS. For X25519 and X448, the procedure is described in . The client's private key is the one associated with the client's authentication credential used in the OSCORE group and specified in the 'req_cnf' parameter above. The client may obtain the Diffie-Hellman public key of the AS during its registration process at the AS.
    • info takes as value the PoP input.
    • L is equal to 8, i.e., the size of the MAC, in bytes.
An example of the POST request is shown in .
Example C-to-AS POST /token Request for an Access Token Bound to an Asymmetric Key
In the example above, the client specifies that its authentication credential in the OSCORE group is the CCS shown in .
Example of client Authentication Credential as CWT Claims Set (CCS)
Later on, the client might want to update its access rights with respect to the same target audience for which the first access token was issued. As long as the client is a member of the OSCORE group and the latest access token of a token series is still valid, the client can contact the AS to ask for updating its access rights, through a process more efficient than that used for the first access token of the token series. When doing so, the POST request sent to the token endpoint is like the one defined above, with the differences compiled below. An example of such a request is shown in .
  • The request MUST include the 'token_series_id' parameter defined in . The 'token_series_id' parameter encodes a token series identifier that is assigned by the AS as discussed in and identifies an ongoing token series associated with the pair (AUTH_CRED_C, Aud). That is, previous access tokens in that series were issued by the AS to the client, as bound to AUTH_CRED_C and intended for the target audience Aud (see ). Note that the same 'token_series_id' value might identify multiple ongoing token series, e.g., if those are associated with the same client but different audiences. Therefore, the AS uses the 'token_series_id' value together with other information such as the targeted audience and the authenticated identity of the client, in order to determine the exact token series to which the new requested access token has to be added.
  • The 'audience' parameter MUST be included in the POST request, if it was included in the POST request that the client previously sent to the AS for requesting the first access token in the token series to which the new requested access token has to be added. If the 'audience' parameter is included in the present POST request, its value MUST be the same value of the 'audience' parameter in that previous POST request.
  • The request MUST NOT include any of the following parameters: 'context_id', 'salt_input', 'client_cred_verify', 'client_cred_verify_mac', and 'req_cnf'.
If the access token request specifies the 'token_series_id' parameter together with any of the parameters 'context_id', 'salt_input', 'client_cred_verify', 'client_cred_verify_mac', and 'req_cnf', the Client-to-AS request MUST be declined with the error code "invalid_request" as defined in . The AS MUST verify that the received 'token_series_id' identifies a token series to which a still valid access token belongs, such that the access token is issued to the client and is intended for the audience specified by the 'audience' parameter of the POST request, if present therein, or for the default audience associated with the client otherwise. If that is not the case, the Client-to-AS request MUST be declined with the error code "invalid_request" as defined in .
Example C-to-AS POST /token Request for Updating Access Rights to an Access Token.
'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 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.
Token Series This document refers to "token series" as a series of access tokens that are sorted in chronological order of release and are characterized by the following properties:
  • Issued by the same AS.
  • Issued to the same client C and associated with the same authentication credential of C, namely AUTH_CRED_C.
  • Issued for the same target audience.
Upon a successful update of access rights (see ), the new issued access token becomes the latest in its token series. When the latest access token of a token series becomes invalid (e.g., due to its expiration or revocation), the token series it belongs to ends. In this profile, a token series comprises access tokens that are used between a given client C and target audience, are bound to the same authentication credential AUTH_CRED_C of C, and specify the same token series identifier, e.g., as value of the 'tokens_series_id' claim (see ). The AS assigns the token series identifier when issuing the first access token of a new series. That token series identifier remains fixed throughout the series lifetime. When assigning the token series identifier, the AS MUST ensure that, irrespective of the profile of ACE used, such value was not used in a previous series whose access tokens share both the following properties with the access tokens of the new series:
  • Issued to the same client C, irrespective of the specific AUTH_CRED_C bound to the access token; and
  • Issued for the same RS as identified by the targeted audience.
If the access token is issued for a group-audience (see ), the token series is associated with all the resource servers in the group-audience. In such case, what is defined above applies, with the difference that the resource servers as identified by the targeted group-audience are collectively considered.
AS-to-C: Response After having verified the POST access token request to the token endpoint and that the client is authorized to obtain an access token aligned with the request, the AS proceeds as defined below. In the following, an authentication credential is denoted as "confirmed" if and only if the AS has achieved proof of possession of the private key associated with the public key of that authentication credential and such proof still holds. Otherwise, an authentication credential is denoted as "non confirmed". If the access token request specifies none of the parameters 'token_series_id', 'client_cred_verify', and 'client_cred_verify_mac', then the AS performs the following steps.
  • The AS considers the authentication credential AUTH_CRED_C specified in the 'req_cnf' parameter of the access token request.
  • If the AS currently knows AUTH_CRED_C as "confirmed", then the AS considers proof of possession of the client's private key to be achieved and it takes no further actions in this respect. The AS might already have achieved proof of possession when establishing a secure communication association with the client, or when processing a previous access token request conveying the same AUTH_CRED_C. Alternatively, a further entity in a trust relationship with the AS might have already achieved proof of possession of the private key and informed the AS about that. Building on that trust relationship, the AS considered AUTH_CRED_C to be "confirmed" from then on.
  • If the AS does not currently know AUTH_CRED_C as "confirmed", then the AS MUST consider the access token request to be invalid.
If both the 'client_cred_verify' and 'client_cred_verify_mac' parameters are present, then the AS MUST consider the access token request to be invalid. If the access token request specifies either the 'client_cred_verify' parameter or the 'client_cred_verify_mac' parameter, then the AS MUST verify the proof-of-possession (PoP) evidence specified therein. In particular, the AS proceeds as follows.
  • As PoP input, the AS uses the same value that the client used (see ).
  • As public key of the client, the AS uses the one included in the authentication credential AUTH_CRED_C that is specified in the 'req_cnf' parameter of the access token request. This requires the AS to support the format of AUTH_CRED_C, i.e., the format of authentication credential that is used in the OSCORE group where the client uses that authentication credential. Practically, this is not an issue, since the same format is used by RSs in that group and an RS supporting this profile is expected to be registered only at an AS that supports the formats of authentication credential that the RS supports.
  • If the access token request includes the 'client_cred_verify' parameter, this specifies the PoP evidence as a signature. Then, the AS verifies the signature by using the public key of the client. This requires the AS to support the signature algorithm and curve (when applicable) that are used in the OSCORE group where the client uses the authentication credential AUTH_CRED_C that is specified in the 'req_cnf' parameter of the access token request. Practically, this is not an issue, since the same algorithm and curve (when applicable) are used by RSs in that group and an RS supporting this profile is expected to be registered only at an AS that supports the signature algorithms and curves (when applicable) that the RS supports.
  • If the access token request includes the 'client_cred_verify_mac' parameter, this specifies the PoP evidence as a Message Authentication Code (MAC). Then, the AS recomputes the MAC through the same process taken by the client when preparing the value of the 'client_cred_verify_mac' parameter for the access token request (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. This requires the AS to support the ECDH algorithm that is used as Pairwise Key Agreement Algorithm in the OSCORE group where the client uses the authentication credential AUTH_CRED_C that is specified in the 'req_cnf' parameter of the access token request. Practically, this is not an issue, since the same ECDH algorithm is used by RSs in that group and an RS supporting this profile is expected to be registered only at an AS that supports the ECDH algorithms that the RS supports.
If the verification of the PoP evidence succeeds, then the AS considers AUTH_CRED_C to be "confirmed" from then on. Instead, if the verification of the PoP evidence fails, then the AS MUST consider the access token request to be invalid. Also, the AS MUST consider AUTH_CRED_C to be "non confirmed" from then on, until the AS again achieves proof of possession of the client's private key. If the access token request was invalid or not authorized, then the AS MUST reply to the client with an error response as described in . Instead, if all verifications are successful, the AS replies to the client with an access token response as defined in . In particular:
  • The AS can signal that the use of Group OSCORE as per this profile is REQUIRED for the issued 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, when accessing protected resources at those resource servers according to the authorization information indicated in the access token. 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 'cnf' parameter in the access token response.
  • The AS MUST NOT include the 'rs_cnf' parameter defined in in the access token response. In general, the AS is not aware of the authentication credentials (and public keys included thereof) that the RSs use in the OSCORE group. Instead, 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, e.g., as specified in Sections and of .
  • If the issued access token is the first one of a token series, the AS MUST include the 'token_series_id' parameter defined in in the access token response, specifying the identifier of the token series which the access token belongs to.
  • If the issued access token is not the first one of a token series, the AS MUST NOT include the 'token_series_id' parameter in the access token response.
According to this document, the AS includes the 'access_token' parameter in the access token response, specifying the issued access token. The alternative Short Distribution Chain (SDC) workflow where the access token is uploaded by the AS directly to the RS is described in . shows an example of access token response, where the access token has been truncated for readability.
Example AS-to-C Access Token Response with the Group OSCORE Profile
Access Token The use of CBOR web tokens (CWTs) as specified in is RECOMMENDED. When issuing any access token of a token series, the AS MUST include the following information as metadata of the issued access token.
  • The profile "coap_group_oscore". If the access token is a CWT, this is specified in the 'ace_profile' claim of the access token, as per .
  • The audience targeted by the access token. If the access token is a CWT, this is specified in the 'aud' claim of the access token.
  • The identifier of the token series which the access token belongs to. If the access token is a CWT, this is specified in the 'token_series_id' claim of the access token, as per .
  • The client's authentication credential AUTH_CRED_C that the client uses in the OSCORE group, which was specified in the 'req_cnf' parameter of the initial access token request that the client sent to ask for the first access token of the token series (see ). If the issued access token is the first one of a token series, AUTH_CRED_C MUST be specified as transported by value, like it was specified in the initial access token request mentioned above. Otherwise, AUTH_CRED_C can be specified as transported by value or identified by reference. If the access token is a CWT, the client's authentication credential MUST be specified in the 'cnf' claim, which follows the syntax from .
If the issued access token is the first one of a token series, the AS MUST include the following information as metadata of the access token. Otherwise, the following information MUST NOT be included within the access token.
  • The Context ID input specified in the 'context_id' parameter of the access token request. If the access token is a CWT, the content of the 'context_id' parameter is specified in the 'context_id' claim of the access token, which is defined in of this document.
  • The salt input specified in the 'salt_input' parameter of the access token request. If the access token is a CWT, the content of the 'salt_input' parameter is specified in the 'salt_input' claim of the access token, which is defined in of this document.
shows an example CWT Claims Set, containing the client's public key in the group (as PoP key), as specified by the inner confirmation value in the 'cnf' claim.
Example CWT Claims Set
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. Editor's note: it should be checked (and in case fixed) that the values used below (which are not yet registered) are the final values registered by IANA.
Example CWT Claims Set Using CBOR Encoding
Update of Access Rights As long as the client is a member of the OSCORE group and the latest access token of a token series is still valid, the client can contact the AS to ask for updating its access rights, through a process more efficient than that used for the first access token of the token series. If the request is granted, then the AS generates a new access token as the latest one of the token series. The access token specifies the identifier of the token series which it belongs to. The access token is uploaded at the RS(s) in the target audience either by the client as specified in this document, or directly as described in . In either case, the access token response from the AS to the client MUST NOT include any of the parameters 'token_series_id', 'cnf', and 'rs_cnf'.
'context_id' Claim The 'context_id' claim provides a value that the client requesting the access token wishes to use with the RS, as a hint for a security context. This claim specifies the value of the Context ID input, encoded as a CBOR byte string.
'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 claim specifies the value of the salt 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' public key either when verifying the signature of the response (if protected with the group mode), or when verifying the response as integrity-protected with pairwise keying material derived from the two peers' authentication credentials and asymmetric keys (if protected with the pairwise mode). In either case, the client also authenticates the RS. Mutual authentication is only achieved after the client has successfully verified the protected response from the RS. Therefore, an attacker using a stolen access token cannot generate a valid Group OSCORE message as protected through the client's private key, and thus cannot prove possession of the PoP key bound to the access token. Also, if a client legitimately owns an access token but has not joined the OSCORE group, it cannot generate a valid Group OSCORE message, as it does not store the necessary keying material shared among the group members. Furthermore, a client C1 is supposed to obtain a valid access token from the AS, as specifying the client's authentication credential (and the public key included thereof) associated with the client's private key used in the OSCORE group, together with the client's Sender ID in that OSCORE group (see ). This allows the RS receiving the access token to verify with the Group Manager of that OSCORE group whether such a client indeed has that Sender ID and uses that authentication credential in the OSCORE group. As a consequence, a different client C2, also member of the same OSCORE group, is not able to impersonate C1 by: i) getting a valid access token, specifying the Sender ID of C1 and a different (made-up) authentication credential; ii) successfully uploading the access token to the RS; and then iii) attempting to communicate using Group OSCORE and impersonating C1, while also blaming C1 for the consequences of the interaction with the RS.
C-to-RS POST to authz-info Endpoint The client uploads the access token to the authz-info endpoint of the RS, as defined in .
RS-to-C: 2.01 (Created) The RS MUST verify the validity of the uploaded access token T_NEW as defined in , with the following additions. The RS retrieves from T_NEW the pieces of information (SeriesId_NEW, Aud_NEW, AuthCred_NEW), where: SeriesId_NEW is the identifier of the token series which the access token belongs to; Aud_NEW is the audience targeted by the access token; and AuthCred_NEW is the client's authentication credential AUTH_CRED_C, specified by value or by reference. The RS checks whether it is storing an access token T_OLD that is associated with the analogous pieces of information (SeriesId_OLD, Aud_OLD, AuthCred_OLD) such that: SeriesId_NEW is equal to SeriesId_OLD; Aud_NEW is equal to Aud_OLD; and AuthCred_NEW is equal to or is a valid reference to AuthCred_OLD as AUTH_CRED_C specified by value. If the RS finds such an access token T_OLD, the RS performs the actions specified in . Otherwise, the RS performs the steps specified below. The following refers to the access token T_NEW and assumes it to be a CWT.
  • The RS checks that the claims 'context_id', 'salt_input', and 'cnf' are included in the access token. In particular, the RS checks that the 'cnf' claim specifies the client's authentication credential as transported by value. If any of these claims are missing, malformed, or non-conformant, the RS MUST consider the access token invalid and MUST reply with a 4.00 (Bad Request) error response. Otherwise, the RS retrieves from the access token:
    • GID* as the Gid of the OSCORE group, which is specified in the 'context_id' claim.
    • SID* as the Sender ID that the client has in the OSCORE group, which is specified in the 'salt_input' claim.
    • AUTH_CRED_C* as the authentication credential that the client uses in the OSCORE group, which is specified in the inner confirmation value of the 'cnf' claim.
  • The RS joins the pertaining OSCORE group identified by GID*, if it is not already a member. If the RS is intended to be a member of multiple groups and different Group Managers are responsible for those groups, the RS needs to perform the above through all such Group Managers under which there is a group identified by GID*. By performing the operation specified in for the realization of Group Manager defined in that document, the RS can rely on GID* to retrieve from the Group Manager the group name and the URI of the group-membership resource at the Group Manager for joining the group. Note that, due to the RS joining the group, the Group Manager performs a group rekeying if required by the application (see ). This results in changing the Gid used in the group, which is handled as defined later below. Irrespective of what is indicated by the access token, the process by which the RS joins OSCORE groups has to be aligned and consistent with the set of groups that the RS intends to be a member of and is authorized to join at the responsible Group Manager. If the RS attempts and fails to join the OSCORE group identified by GID*, the RS MUST reply with a 5.00 (Internal Server Error) error response.
  • Based on the OSCORE Security Contexts that it stores, the RS builds GROUPS as the set of OSCORE groups such that all the following conditions hold, for each group G in the set.
    • The RS is a member of the group G.
    • The audience targeted by the access token is consistent with using the group G for accessing protected resources hosted by the RS.
    • The group G has GID' as current Gid. In particular, GID' is determined as below.
      • If, following the early verification of the access token, the RS has joined the group G as identified by GID* (see above), GID' is the Gid that the Group Manager has provided to the RS as a result of the group joining. In this case, GID' might be different from GID*, if the Group Manager has performed a group rekeying due to the RS joining the group.
      • If, following the early verification of the access token, the RS has retrieved from the Group Manager updated keying material associated with the group G as identified by GID* (e.g., as specified in ), GID' is the Gid that the Group Manager has provided to the RS. In this case, GID' might be different from GID*, if the Group Manager previously performed a group rekeying process that the RS had missed.
      • If none of the above applies, GID' is equal to GID*
    If no such group is found, the RS MUST consider the access token invalid and MUST reply with a 4.00 (Bad Request) error response. Otherwise, for each of the N >= 1 groups G in the set GROUPS, the RS MUST request to the corresponding Group Manager the authentication credential that the client uses in G, specifying SID* in the request sent to the Group Manager, e.g., as specified in . When receiving a successful response from each of the Group Managers, the RS MUST check whether the client's authentication credential AUTH_CRED_C retrieved from the Group Manager is equal to AUTH_CRED_C* retrieved from the access token. In the case that AUTH_CRED_C* is provided within a chain or a bag, but AUTH_CRED_C is not provided within the same chain or bag, then the RS MUST NOT determine AUTH_CRED_C* and AUTH_CRED_C to be equal. If any of the following conditions holds, the RS MUST consider the access token invalid and MUST reply to the client with a 5.03 (Service Unavailable) error response.
    • None or more than one of the Group Managers provide the RS with a successful response where the conveyed AUTH_CRED_C is equal to AUTH_CRED_C*.
    • After having performed a maximum, pre-configured number of attempts or after a maximum, pre-configured amount of time has elapsed, less than N Group Managers have sent a successful response to the RS.
    The process above is successful if and only if the RS receives a successful response from all the N Group Managers, and exactly one of such responses conveys AUTH_CRED_C equal to AUTH_CRED_C*. This ensures that there is only one OSCORE group G* such that: the client and the RS are both its members; it has GID' as current Gid; and the client uses SID* as Sender ID in the group. In turn, this will ensure that the RS can bound the access token to such single OSCORE group G*.
If the operations above are successful, the access token is valid, and further checks on its content are successful, then the RS proceeds as follows.
  • The RS considers the Group OSCORE Security Context identified by GID' and used in the OSCORE group G* determined above.
  • If the Group OSCORE Security Context is not including a Recipient Context pertaining to the client (i.e., with Recipient ID equal to SID* and authentication credential equal to AUTH_CRED_C*), then the RS derives such Recipient Context and adds it to the Group OSCORE Security Context.
  • The RS associates the access token with the Recipient Context pertaining to the client, within the Group OSCORE Security Context used in the OSCORE group G*.
  • The RS associates the access token with the tuple (SeriesId, Aud, AuthCred), where:
    • SeriesId is the identifier of the token series which the access token belongs to, as indicated by the 'token_series_id' claim of the access token.
    • Aud is the target audience, as indicated by the 'aud' claim of the access token.
    • AuthCred is the authentication credential that the client uses in G*, i.e., AUTH_CRED_C*.
Finally, the RS MUST send a 2.01 (Created) response to the client, as defined in . As defined in , a possible change of the client's authentication credential requires the client to upload to the RS a new access token bound to the new authentication credential.
Client-RS Secure Communication As members of the OSCORE group, both the client and the RS have established the related Group OSCORE Security Context to securely communicate in the group. Therefore, they can simply start to securely communicate using Group OSCORE, without deriving any additional keying material or security association. It can happen that the client or the RS deletes an access token, e.g., when the access token has expired or has been revoked. If the RS deletes an access token, this MUST NOT result in the RS deleting the associated Recipient Context pertaining to the client from the Group OSCORE Security Context used in the OSCORE group. If the client deletes an access token, this MUST NOT result in the client deleting the associated Group OSCORE Security Context used in the OSCORE group. The client MAY request a new access token from the AS, to be uploaded to the RS for re-enabling access to protected resources.
Client Side After having received the 2.01 (Created) response from the RS, following the POST request to the authz-info endpoint, the client communicates with the RS, e.g., by sending to the RS a request protected with Group OSCORE . When communicating with the RS to access the resources as specified by the authorization information in the access token, the client MUST use the Group OSCORE Security Context that is used in the OSCORE group pertaining to the access token, i.e., the group that the client referred to when requesting the access token to the AS (see ).
Resource Server Side After successful validation of the access token as defined in and after having sent the 2.01 (Created) response, the RS communicates with the client using Group OSCORE . For every incoming request, if Group OSCORE verification succeeds, the verification of access rights is performed as described in . In the case that the RS receives a request protected with a Group OSCORE Security Context CTX, it successfully verifies the request, and the target resource requires authorization, then the RS checks whether it stores a valid access token associated with the Recipient Context pertaining to the client that is included within CTX and was used to verify the request. If the RS does not store such an access token, the RS MUST reply with a 4.01 (Unauthorized) error response protected with CTX. Given a Recipient Context within a Group OSCORE Security Context, the RS MUST delete every access token associated with that Recipient Context if any of the following occurs:
  • The RS deletes that Recipient Context.
  • The RS updates the client's authentication credential in that Recipient Context, i.e., in the case that the client has changed its authentication credential in the OSCORE group.
Update of Access Rights With reference to the stored access token T_OLD and the latest uploaded access token T_NEW considered in , the RS proceeds as follows.
  • The RS associates T_NEW with the same tuple (SeriesId, Aud, AuthCred) with which T_OLD was associated.
  • The RS associates T_NEW with the Recipient Context pertaining to the client that is included within the Group OSCORE Security Context used in the OSCORE group pertaining to T_NEW, i.e., the same Recipient Context with which T_OLD was associated.
  • The RS supersedes T_OLD with T_NEW.
Finally, the RS MUST reply with a 2.01 (Created) response, as defined in .
Access Rights Verification The RS MUST follow the procedures defined in . If an RS receives a request protected with Group OSCORE from a client, the RS processes the request according to , using the Recipient Context pertaining to the client that is included within the Group OSCORE Security Context used in the group. 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 Recipient Context used to verify the request. Then, the RS MUST verify that the action requested on the resource is authorized. If the RS has no valid access token for the client, the RS MUST reject the request and MUST reply to the client with a 4.01 (Unauthorized) error response. If the RS has an access token for the client but no actions are authorized on the target resource, the RS MUST reject the request and MUST reply to the client with a 4.03 (Forbidden) error response. If the RS has an access token for the client but the requested action is not authorized, the RS MUST reject the request and MUST reply to the client with a 4.05 (Method Not Allowed) error response.
Storing Multiple Access Tokens per PoP Key According to , an RS is recommended to store only one access token per proof-of-possession (PoP) key and to supersede such an access token when receiving and successfully validating a new one bound to the same PoP key. However, when using the profile specified in this document, an RS might practically have to deviate from that recommendation and store multiple access tokens bound to the same PoP key, i.e., to the same public authentication credential of a client. For example, this can occur in the following cases.
  • The RS is the single RS associated with an audience AUD1 and also belongs to a group-audience AUD2 (see ). A client C with public authentication credential AUTH_CRED_C can request two access tokens T1 and T2 from the AS, such that:
    • T1 targets AUD1 and has scope SCOPE1; and
    • T2 targets AUD2 and has scope SCOPE2 different from SCOPE1.
    Both T1 and T2 are going to be bound to the same PoP key specified by AUTH_CRED_C. In fact, if the AS issues access tokens targeting a group-audience, then the above can possibly be the case when using any transport profile of ACE that supports asymmetric PoP keys. If so, the RS should be ready to store at minimum one access token per PoP key per audience it belongs to.
  • The RS is a member of two OSCORE groups G1 and G2. In particular, the same format of public authentication credentials is used in both OSCORE groups. A client C with public authentication credential AUTH_CRED_C of such format, also member of the two OSCORE groups G1 and G2, can conveniently use AUTH_CRED_C as its public authentication credential in both those groups. Therefore, C can request two access tokens T1 and T2 from the AS, such that:
    • T1 targets RS and reflects the membership of C in G1, as per its claims "context_id" and "salt_input"; and
    • T2 targets RS and reflects the membership of C in G2, as per its claims "context_id" and "salt_input".
    Both T1 and T2 are going to be bound to the same PoP key specified by AUTH_CRED_C. When using the profile specified in this document, the RS should be ready to store at minimum one access token per PoP key per OSCORE group it is (going to be) a member of (although, per the previous point, even this can still be limiting).
  • The RS uses both the profile specified in this document and a different transport profile of ACE that also relies on asymmetric PoP keys, e.g., the EDHOC and OSCORE profile defined in . In such a case, a client C with public authentication credential AUTH_CRED_C can request two access tokens T1 and T2 from the AS, such that:
    • T1 targets RS and is meant to be used according to the Group OSCORE profile defined in this document; and
    • T2 targets RS and is meant to be used according to the EDHOC and OSCORE profile defined in .
    Both T1 and T2 are going to be bound to the same PoP key specified by AUTH_CRED_C. When using multiple transport profiles of ACE that rely on asymmetric PoP keys, it is reasonable that the RS is capable to store at minimum one access token per PoP key per used profile (although, per the previous points, even this can still be limiting).
In order to keep the same spirit of the recommendation in without impeding cases such as those outlined in the examples above, the following defines more fine-grained recommendations for the storage of access tokens at an RS when this profile is used.
  • As to access tokens issued in accordance with this profile (i.e., specifying the profile "coap_group_oscore"), it is RECOMMENDED that an RS stores only one access token that:
    • is bound to a specific PoP key;
    • targets a specific audience; and
    • is related to a specific OSCORE group.
  • As to access tokens issued in accordance with a different profile P that an RS may use in parallel with the profile defined in this document, it is RECOMMENDED that an RS stores only one access token that:
    • is issued in accordance with the profile P;
    • is bound to a specific PoP key;
    • targets a specific audience; and
    • is related to a specific secure association used by the client to protect communications with the RS.
In accordance with these recommendations, if an access token T_NEW does not differ in any of the respects above from an existing access token T_OLD stored at the RS, then T_NEW ought to supersede T_OLD by replacing the corresponding authorization information. Not complying with these recommendations can additionally complicate (constrained) implementations of RSs, with respect to required storage and the validation of a protected request against the applicable, stored access tokens associated with the same client. That is, it increases the strain on an RS in determining the actual permissions of a client, e.g., if access tokens contradict each other and thus might lead the RS to enforce wrong permissions. Moreover, if one of the access tokens expires earlier than others, the resulting permissions may offer insufficient protection.
Change of Client's Authentication Credential in the Group During its membership in the OSCORE group, the client might change the authentication credential that it uses in the group. When this happens, the client uploads the new authentication credential to the Group Manager, e.g., as specified in . After that, in order to continue communicating with the RS, the client MUST perform the following actions.
  1. The client requests a new access token T_NEW from the AS, as defined in . In particular, when sending the access token request as defined in , the client specifies:
    • The current Group Identifier of the OSCORE group, as the value of the 'context_id' parameter.
    • The current Sender ID that it has in the OSCORE group, as the value of the 'salt_input' parameter.
    • The new authentication credential that it uses in the OSCORE group, as the inner confirmation value of the 'req_cnf' parameter.
    • Optionally, the proof-of-possession (PoP) evidence corresponding to the public key of the new authentication credential, as the value of the 'client_cred_verify' or 'client_cred_verify_mac' parameter. The possible omission of the PoP evidence is based on the same criteria that are defined in .
  2. After receiving the access token response from the AS (see ), the client performs with the RS the same exchanges that are defined in .
When receiving the new access token T_NEW, the RS performs the same steps defined in .
Secure Communication with the AS As specified in the ACE framework (see Sections and of ), the requesting entity (client and/or RS) and the AS communicate via the token or introspect endpoint. When using this profile, the use of CoAP and OSCORE for this communication is RECOMMENDED, in order to reduce the number of libraries that C and RS have to support. 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 token endpoint as specified in and through the introspect 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 to be so. Upon leaving the OSCORE group, the client or RS also discards the Group OSCORE Security Context. Consequently:
  • The RS MUST delete every access token that is associated with a Recipient Context in the Group OSCORE Security Context.
  • The client MUST delete every access token that is associated with the Group OSCORE Security Context.
The client or RS can obtain a new Group OSCORE Security Context by re-joining the OSCORE group. In such a case, the client requests a new access token to be uploaded to the RS. Note that a Group OSCORE Security Context CTX_OLD can be renewed by the Group Manager through a group rekeying process (see ), establishing a Group OSCORE Security Context CTX_NEW that supersedes CTX_OLD. In such case:
  • The RS considers the associations that stored access tokens have with Recipient Contexts within CTX_OLD, and it updates those associations to be with the corresponding, renewed Recipient Contexts in CTX_NEW.
  • The client considers the associations that stored access tokens have with CTX_OLD, and it updates those associations to be with CTX_NEW.
Guidelines on Using Multiple Profiles When using the profile defined in this document, access tokens are to be bound to a Recipient Context within a Group OSCORE Security Context, which is used to protect communications between the client and the RS(s) in the targeted audience by using the security protocol Group OSCORE. After having obtained an access token T1 for this profile and uploaded it to the RS (RSs) pertaining to the targeted audience, the client might want to establish a separate, pairwise OSCORE association with that RS (with one RS among those RSs). In order to do that, the client can ask the AS for a different access token T2 intended for that RS (for one RS among those RSs), as per the OSCORE profile defined in . Since the ACE framework does not allow the client to negotiate with the AS the profile to use, the client has instead to choose the use of the OSCORE profile, and to explicitly indicate it to the AS when requesting T2. To this end, the client could indicate its wish for an access token aligned with the Group OSCORE profile or with the OSCORE profile, by specifying one of two different audiences in the 'audience' parameter of the access token request to the AS. Assuming a proper configuration of the access policies at the AS, this is still conducive to a consistent evaluation of what is specified in the 'scope' parameter of the access token request against the access policies at the AS. For example, an RS registered as "rs1" at the AS can be associated with two audiences:
  • "rs1_gp_osc", which the client can use to request an access token for the Group OSCORE profile and targeting (also) that RS. That is, the client specifies this audience when requesting the access token T1.
  • "rs1_osc", which the client can use to request an access token for the OSCORE profile and targeting only that RS. That is, the client specifies this audience when requesting the access token T2.
Alternatively, the client could provide the AS with an explicit indication of the profile to use, according to which the AS is requested to issue an access token. For example, the client can rely on the 'ace_profile' parameter of the access token request, according to its revised semantics as specified in . Note that an RS has to be able to store at least one access token per PoP key. When specifically considering the Group OSCORE profile and the OSCORE profile, the RS can always store both corresponding access tokens T1 and T2, since they are always bound to different PoP keys. That is:
  • In the Group OSCORE profile, the PoP key is the client's public key, which is included in the client's authentication credential specified in the 'cnf' claim of the access token (when CWTs are used).
  • In the OSCORE profile, the PoP key is fundamentally an OSCORE Master Secret, which is specified within the OSCORE_Input_Material object of the 'cnf' claim of the access token (when CWTs are used).
The same approaches discussed above can be used in the case that the profile used for the access token T2 is instead the EDHOC and OSCORE profile defined in . In such a case, the same PoP key might be bound to both T1 and T2, i.e., if the client's public key is included both in the authentication credential that the client uses in the OSCORE group and in the authentication credential that the client uses as CRED_I (CRED_R) when running the EDHOC protocol in the forward (reverse) message flow (see ). provides considerations and recommendations on storing multiple access tokens per PoP key when using the Group OSCORE profile, also in parallel with alternative profiles.
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
Parameter name CBOR Key Value Type
context_id TBD byte string
salt_input TBD byte string
client_cred_verify TBD byte string
client_cred_verify_mac TBD byte string
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
Claim name CBOR Key Value Type
context_id TBD byte string
salt_input TBD byte string
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 included in the authentication credential that the client uses in the OSCORE group. This means that the same shared secret is never used as a PoP key with possible multiple RSs. Therefore, it is possible and safe for the AS to issue an access token for an audience that includes multiple RSs (i.e., a group-audience, see ). 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 group-audience has to correctly identify all the RSs that are intended recipients of the access token and for which the single scope specified in the access token applies. As a particular case, the audience can refer to the OSCORE group as a whole, if the access token is intended for 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. 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 that is embedded in the protected message. The group mode can be used to protect messages sent to multiple recipients (e.g., over IP multicast) or to a single recipient. When protecting an outgoing message in pairwise mode, the sender uses a pairwise symmetric key that is derived from the asymmetric keys of the two peers exchanging the message. The pairwise mode can be used to protect only messages intended for a single recipient.
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. Note to RFC Editor: Please replace "[RFC-XXXX]" with the RFC number of this document and delete this paragraph.
ACE Profiles Registry IANA is asked to add the following entry to the "ACE Profiles" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.
  • Name: coap_group_oscore
  • Description: Profile to secure communications between constrained nodes using the Authentication and Authorization for Constrained Environments framework, by enabling authentication and fine-grained authorization of members of an OSCORE group that use a pre-established Group OSCORE Security Context to communicate with Group OSCORE.
  • CBOR Value: TBD (value between 1 and 23)
  • Reference: [RFC-XXXX]
OAuth Parameters Registry IANA is asked to add the following entries to the "OAuth Parameters" registry within the "OAuth Parameters" registry group.
  • Name: context_id
  • Parameter Usage Location: token request
  • Change Controller: IETF
  • Reference: [RFC-XXXX, ]

  • Name: salt_input
  • Parameter Usage Location: token request
  • Change Controller: IETF
  • Reference: [RFC-XXXX, ]

  • Name: client_cred_verify
  • Parameter Usage Location: token request
  • Change Controller: IETF
  • Reference: [RFC-XXXX, ]

  • Name: client_cred_verify_mac
  • Parameter Usage Location: token request
  • Change Controller: IETF
  • Reference: [RFC-XXXX, ]
OAuth Parameters CBOR Mappings Registry IANA is asked to add the following entries to the "OAuth Parameters CBOR Mappings" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group, following the procedure specified in .
  • Name: context_id
  • CBOR Key: TBD (value between 1 and 255)
  • Value Type: byte string
  • Reference: [RFC-XXXX, ]
  • Original Specification: [RFC-XXXX]

  • Name: salt_input
  • CBOR Key: TBD (value between 1 and 255)
  • Value Type: byte string
  • Reference: [RFC-XXXX, ]
  • Original Specification: [RFC-XXXX]

  • Name: client_cred_verify
  • CBOR Key: TBD (value between 1 and 255)
  • Value Type: byte string
  • Reference: [RFC-XXXX, ]
  • Original Specification: [RFC-XXXX]

  • Name: client_cred_verify_mac
  • CBOR Key: TBD (value between 1 and 255)
  • Value Type: byte string
  • Reference: [RFC-XXXX, ]
  • Original Specification: [RFC-XXXX]
JSON Web Token Claims Registry IANA is asked to add the following entries to the "JSON Web Token Claims" registry within the "JSON Web Token (JWT)" registry group, following the procedure specified in .
  • Claim Name: context_id
  • Claim Description: Client provided Context ID
  • Change Controller: IETF
  • Reference: [RFC-XXXX]

  • Claim Name: salt_input
  • Claim Description: Client provided salt input
  • Change Controller: IETF
  • Reference: [RFC-XXXX]
CBOR Web Token (CWT) Claims Registry IANA is asked to add the following entries to the "CBOR Web Token (CWT) Claims" registry within the "CBOR Web Token (CWT) Claims" registry group, following the procedure specified in .
  • Claim Name: context_id
  • Claim Description: Client provided Context ID
  • JWT Claim Name: N/A
  • Claim Key: TBD (value between 1 and 255)
  • Claim Value Type: byte string
  • Change Controller: IETF
  • Reference: [RFC-XXXX, ]

  • Claim Name: salt_input
  • Claim Description: Client provided salt input
  • JWT Claim Name: N/A
  • Claim Key: TBD (value between 1 and 255)
  • Claim Value Type: byte string
  • Change Controller: IETF
  • Reference: [RFC-XXXX, ]
TLS Exporter Label Registry IANA is asked to register the following entry in the "TLS Exporter Labels" registry within the "Transport Layer Security (TLS) Parameters" registry group, which is defined in and updated in .
  • Value: EXPORTER-ACE-PoP-Input-Client-AS
  • DTLS-OK: Y
  • Recommended: N
  • Reference: [RFC-XXXX, ]
References Normative References Group Communication for the Constrained Application Protocol (CoAP) IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of 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 and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. Group Object Security for Constrained RESTful Environments (Group OSCORE) RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol 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 each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE) RISE AB Ericsson AB This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to request and provision keying material in group communication scenarios that are based on the Constrained Application Protocol (CoAP) and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, which 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 of a key owned by the Client and bound to an OAuth 2.0 access token. Short Distribution Chain (SDC) Workflow and New OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework RISE AB Ericsson AB This document updates the Authentication and Authorization for Constrained Environments framework (ACE, RFC 9200) as follows. (1) It defines the Short Distribution Chain (SDC) workflow that the authorization server (AS) can use for uploading an access token to a resource server on behalf of the client. (2) For the OAuth 2.0 token endpoint, it defines new parameters and encodings and it extends the semantics of the "ace_profile" parameter. (3) For the OAuth 2.0 authz-info endpoint, it defines a new parameter and its encoding. (4) It defines how the client and the AS can coordinate on the exchange of the client's and resource server's public authentication credentials, when those can be transported by value or identified by reference; this extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint, thus updating RFC 9201. (5) It extends the error handling at the AS, for which it defines a new error code. (6) It deprecates the original payload format of error responses conveying an error code, when CBOR is used to encode message payloads. For those responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles defined in RFC 9202, RFC 9203, and RFC 9431. (7) It amends two of the requirements on profiles of the framework. The Transport Layer Security (TLS) Protocol Version 1.2 This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] Keying Material Exporters for Transport Layer Security (TLS) 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] HMAC-based Extract-and-Expand Key Derivation Function (HKDF) 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. Datagram Transport Layer Security Version 1.2 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] The OAuth 2.0 Authorization Framework 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) 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. JSON Web Token (JWT) JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. Elliptic Curves for Security 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. CBOR Web Token (CWT) 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. Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Object Security for Constrained RESTful Environments (OSCORE) 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. IANA Registry Updates for TLS and DTLS 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. Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) 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). Concise Binary Object Representation (CBOR) 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. CBOR Object Signing and Encryption (COSE): Structures and Process Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services 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 RFC 9053, obsoletes RFC 8152. CBOR Object Signing and Encryption (COSE): Initial Algorithms Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services 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 9052). This document, along with RFC 9052, obsoletes RFC 8152. Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth) 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. Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE) 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 (PoP) key the client wishes to use, the PoP key that the authorization server has selected, and the PoP key the resource server uses to authenticate to the client. The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework 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. Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography - NIST Special Publication 800-56A, Revision 3 ACE Profiles IANA OAuth Parameters IANA OAuth Parameters CBOR Mappings IANA JSON Web Token Claims IANA CBOR Web Token (CWT) Claims IANA TLS Exporter Labels IANA Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Informative References Discovery of OSCORE Groups with the CoRE Resource Directory RISE AB 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 defines 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 can be used to protect communications in 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. CBOR Encoded X.509 Certificates (C509 Certificates) Ericsson AB Ericsson AB University of Glasgow RISE AB IN Groupe NIO 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 common certificate profiles, and it is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is computed over the CBOR encoding instead of the DER encoding, thereby avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 while providing comparable size reduction. This document also specifies CBOR-encoded data structures for certification requests and certification request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698 by extending the TLSA selectors registry to include C509 certificates. Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) Ericsson Ericsson RISE RISE This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth client and resource server, and it binds an authentication credential of the client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications between the client and resource server when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The Transport Layer Security (TLS) Protocol Version 1.3 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. The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 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 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. Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) This specification defines a profile of the Authentication and Authorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 or later 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. Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework to enable authorization in a publish-subscribe messaging system based on Message Queuing Telemetry Transport (MQTT). Proof-of-Possession keys, bound to OAuth 2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication. Ephemeral Diffie-Hellman Over COSE (EDHOC) This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. Zero Trust Architecture - NIST Special Publication 800-207
Profile Requirements This appendix lists the specifications of this profile based on the requirements of the ACE framework, as requested in .
  • Optionally, define new methods for the client to discover the necessary permissions and AS for accessing a resource, different from the one proposed in : Not specified.
  • Optionally, specify new grant types: Not specified.
  • Optionally, define the use of client certificates as client credential type: Not specified.
  • Specify the communication protocol the client and RS must use: CoAP.
  • Specify the security protocol the client and RS must use to protect their communication: Group OSCORE, by using a pre-established Group OSCORE Security Context.
  • Specify 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 mutual authentication is only achieved after the client has successfully verified a response from the RS protected with Group OSCORE, using the shared Group OSCORE Security Context.
  • Specify the proof-of-possession protocol(s) and how to select one, if several are available. Also specify which key types (e.g., symmetric/asymmetric) are supported by a specific proof-of- possession protocol: Group OSCORE algorithms; asymmetric keys verified and distributed by a Group Manager.
  • Specify a unique ace_profile identifier: coap_group_oscore.
  • If introspection is supported, specify the communication and security protocol for introspection: HTTP/CoAP (+ TLS/DTLS/OSCORE).
  • Specify the communication and security protocol for interactions between the client and AS: HTTP/CoAP (+ TLS/DTLS/OSCORE).
  • Specify if/how the authz-info endpoint is protected, including how error responses are protected: Not protected.
  • Optionally, define other methods of token transport than the authz-info endpoint: Not defined.
CDDL Model
CDDL model
Document Updates
Version -06 to -07
  • It is RECOMMENDED to use the OSCORE Group Manager defined in draft-ietf-ace-key-groupcomm-oscore.
  • Major simplification in associating the access token with other information.
  • Defined dynamic update of access rights through token series.
  • Clarifications:
    • Processing of the access token at the RS.
    • The RS binds the access token to a specific Recipient Context.
    • Achieving proof of possession.
    • Details on proof of group membership.
    • Timing and consistency of group joining.
    • Latest group joining for the RS.
  • Moved overview text about enforced access control to the appropriate subsection.
  • Added references to IANA registries.
  • Editorial improvements.
Version -05 to -06
  • Replaced "GID" with "Gid".
  • Mentioned revised semantics of the 'ace_profile' parameter.
  • Added registrations to the "JSON Web Token Claims" IANA registry.
  • Minor clarifications and editorial improvements.
Version -04 to -05
  • Consistent mentioning of the optional presence of the PoP evidence in the access token request.
  • Guidelines on updating the quartet (GID, SaltInput, AuthCred, AuthCredGM) at the RS when a client obtains a new Sender ID.
  • Clarifications and editorial improvements.
Version -03 to -04
  • Required that 'cnf' in the access token includes exactly what C uploaded to the Group Manager.
  • Made the PoP evidence in the access token request optional.
  • Better example value for audience, when indicating the profile to use.
  • Placeholder: possible use of the 'ace_profile' parameter with extended semantics, for C to select the right profile.
  • Suggested value ranges for codepoints to register.
  • Aligned CBOR abbreviations to those used in other documents.
  • Editorial fixes and improvements.
Version -02 to -03
  • Lowercase "client", "resource server", "authorization server", and "access token".
  • Consistent update of section numbers for external references.
  • Mentioned that this profile can also use the ACE alternative workflow.
  • Clarified that the client may ask for a new access token after the old one becomes invalid.
  • Enforced uniqueness pre-requirements on the client's group membership before requesting an access token.
  • Added checks on uniqueness of clients' group membership at the RS.
  • Clarified the process of access right verification.
  • Added fine-grained recommendations on storing multiple access tokens bound to the same PoP key.
  • Added guidelines on using multiple profiles.
  • Fixes in the IANA considerations.
  • Editorial fixes and improvements.
Version -01 to -02
  • CBOR diagnostic notation uses placeholders from a CDDL model.
  • Renamed the claim 'contextId_input' to 'context_id'.
  • Revised examples.
  • Placeholders and early direction for dynamic update of access rights.
  • Added text on storing multiple access tokens per PoP key on the RS.
  • Fixes in the IANA considerations.
  • Editorial fixes and improvements.
Version -00 to -01
  • Deleting an access token does not delete the Group OSCORE Security Context.
  • Distinct computation of the PoP input when C and the AS use (D)TLS 1.2 or 1.3.
  • Revised computation of the PoP input when C and the AS use OSCORE.
  • Revised computation of the PoP evidence when the OSCORE group is a pairwise-only group.
  • Clarified requirements on the AS for verifying the PoP evidence.
  • Renamed the TLS Exporter Label for computing the PoP input.
  • Editorial fixes and improvements.
Acknowledgments contributed as a co-author of initial versions of this document. The authors sincerely thank , , , , , , and for their comments and feedback. The work on this document has been partly supported by the Sweden's Innovation Agency VINNOVA and the Celtic-Next projects CRITISEC and CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).