idnits 2.17.1 draft-tiloca-ace-group-oscore-profile-07.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 914 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-12 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-45 == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-05 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-13 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-800-56A' ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Downref: Normative reference to an Informational RFC: RFC 7748 == Outdated reference: A later version (-17) exists of draft-ietf-ace-mqtt-tls-profile-13 == Outdated reference: A later version (-09) exists of draft-ietf-cose-cbor-encoded-cert-02 == Outdated reference: A later version (-09) exists of draft-ietf-rats-uccs-01 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-10 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group M. Tiloca 3 Internet-Draft R. Höglund 4 Intended status: Standards Track RISE AB 5 Expires: 28 April 2022 L. Seitz 6 Combitech 7 F. Palombini 8 Ericsson AB 9 25 October 2021 11 Group OSCORE Profile of the Authentication and Authorization for 12 Constrained Environments Framework 13 draft-tiloca-ace-group-oscore-profile-07 15 Abstract 17 This document specifies a profile for the Authentication and 18 Authorization for Constrained Environments (ACE) framework. The 19 profile uses Group OSCORE to provide communication security between a 20 Client and a (set of) Resource Server(s) as members of an OSCORE 21 Group. The profile securely binds an OAuth 2.0 Access Token with the 22 public key of the Client associated to the private key used in the 23 OSCORE group. The profile uses Group OSCORE to achieve server 24 authentication, as well as proof-of-possession for the Client's 25 public key. Also, it provides proof of the Client's membership to 26 the correct OSCORE group, by binding the Access Token to information 27 from the Group OSCORE Security Context, thus allowing the Resource 28 Server(s) to verify the Client's membership upon receiving a message 29 protected with Group OSCORE from the Client. 31 Discussion Venues 33 This note is to be removed before publishing as an RFC. 35 Discussion of this document takes place on the Constrained RESTful 36 Environments Working Group mailing list (ace@ietf.org), which is 37 archived at https://mailarchive.ietf.org/arch/browse/ace/. 39 Source for this draft and an issue tracker can be found at 40 https://gitlab.com/crimson84/draft-tiloca-ace-group-oscore-profile. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on 28 April 2022. 59 Copyright Notice 61 Copyright (c) 2021 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 66 license-info) in effect on the date of publication of this document. 67 Please review these documents carefully, as they describe your rights 68 and restrictions with respect to this document. Code Components 69 extracted from this document must include Simplified BSD License text 70 as described in Section 4.e of the Trust Legal Provisions and are 71 provided without warranty as described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 77 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 78 2.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . 9 79 2.2. Access Token Retrieval . . . . . . . . . . . . . . . . . 10 80 2.3. Access Token Posting . . . . . . . . . . . . . . . . . . 10 81 2.4. Secure Communication . . . . . . . . . . . . . . . . . . 11 82 3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 11 83 3.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . . . 11 84 3.1.1. 'context_id' Parameter . . . . . . . . . . . . . . . 15 85 3.1.2. 'salt_input' Parameter . . . . . . . . . . . . . . . 15 86 3.1.3. 'client_cred_verify' Parameter . . . . . . . . . . . 15 87 3.1.4. 'client_cred_verify_mac' Parameter . . . . . . . . . 15 88 3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 15 89 3.2.1. Salt Input Claim . . . . . . . . . . . . . . . . . . 19 90 3.2.2. Context ID Input Claim . . . . . . . . . . . . . . . 20 91 4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 20 92 4.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . . . 21 93 4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 21 94 4.3. Client-RS Secure Communication . . . . . . . . . . . . . 22 95 4.3.1. Client Side . . . . . . . . . . . . . . . . . . . . . 23 96 4.3.2. Resource Server Side . . . . . . . . . . . . . . . . 23 97 4.4. Access Rights Verification . . . . . . . . . . . . . . . 23 98 4.5. Change of Client's Public Key in the Group . . . . . . . 24 99 5. Secure Communication with the AS . . . . . . . . . . . . . . 25 100 6. Discarding the Security Context . . . . . . . . . . . . . . . 25 101 7. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . . . 25 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 103 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 104 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 105 10.1. ACE Profile Registry . . . . . . . . . . . . . . . . . . 28 106 10.2. OAuth Parameters Registry . . . . . . . . . . . . . . . 28 107 10.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . 29 108 10.4. CBOR Web Token Claims Registry . . . . . . . . . . . . . 30 109 10.5. TLS Exporter Label Registry . . . . . . . . . . . . . . 31 110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 111 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 112 11.2. Informative References . . . . . . . . . . . . . . . . . 34 113 Appendix A. Dual Mode (Group OSCORE & OSCORE) . . . . . . . . . 36 114 A.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 37 115 A.1.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . 39 116 A.1.2. Access Token Posting . . . . . . . . . . . . . . . . 39 117 A.1.3. Setup of the Pairwise OSCORE Security Context . . . . 39 118 A.1.4. Secure Communication . . . . . . . . . . . . . . . . 40 119 A.2. Client-AS Communication . . . . . . . . . . . . . . . . . 41 120 A.2.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . 41 121 A.2.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . 44 122 A.3. Client-RS Communication . . . . . . . . . . . . . . . . . 52 123 A.3.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . 53 124 A.3.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . 53 125 A.3.3. OSCORE Setup - Client Side . . . . . . . . . . . . . 55 126 A.3.4. OSCORE Setup - Resource Server Side . . . . . . . . . 57 127 A.3.5. Access Rights Verification . . . . . . . . . . . . . 60 128 A.3.6. Change of Client's Public Key in the Group . . . . . 60 129 A.4. Secure Communication with the AS . . . . . . . . . . . . 61 130 A.5. Discarding the Security Context . . . . . . . . . . . . . 61 131 A.6. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . 61 132 A.7. Security Considerations . . . . . . . . . . . . . . . . . 62 133 A.8. Privacy Considerations . . . . . . . . . . . . . . . . . 62 134 Appendix B. Profile Requirements . . . . . . . . . . . . . . . . 63 135 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 64 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 138 1. Introduction 140 A number of applications rely on a group communication model, where a 141 Client can access a resource shared by multiple Resource Servers at 142 once, e.g., over IP multicast. Typical examples are switching of 143 luminaries, actuators control, and distribution of software updates. 144 Secure communication in the group can be achieved by sharing a set of 145 keying material, which is typically provided upon joining the group. 147 For some of such applications, it may be just fine to enforce access 148 control in a straightforward fashion. That is, any Client authorized 149 to join the group, hence to get the group keying material, can be 150 also implicitly authorized to perform any action at any resource of 151 any Server in the group. An example of application where such 152 implicit authorization might be used is a simple lighting scenario, 153 where the lightbulbs are the Servers, while the user account on an 154 app on the user's phone is the Client. In this case, it might be 155 fine to not require additional authorization evidence from any user 156 account, if it is acceptable that any current group member is also 157 authorized to switch on and off any light, or to check their status. 159 However, in different instances of such applications, the approach 160 above is not desirable, as different group members are intended to 161 have different access rights to resources of other group members. 162 That is, access control to the secure group communication channel and 163 access control to the resource space provided by servers in the group 164 should remain logically separated domains. For instance, a more 165 fine-grained approach is required in the two following use cases. 167 As a first case, an application provides control of smart locks 168 acting as Servers in the group, where: a first type of Client, e.g., 169 a user account of a child, is allowed to only query the status of the 170 smart locks; while a second type of Client, e.g., a user account of a 171 parent, is allowed to both query and change the status of the smart 172 locks. Further similar applications concern the enforcement of 173 different sets of permissions in groups with sensor/actuator devices, 174 e.g., thermostats, acting as Servers. Also, some group members may 175 even be intended as Servers only. Hence, they must be prevented from 176 acting as Clients altogether and from accessing resources at other 177 Servers, especially when attempting to perform non-safe operations. 179 As a second case, building automation scenarios often rely on Servers 180 that, under different circumstances, enforce different level of 181 priority for processing received commands. For instance, BACnet 182 deployments consider multiple classes of Clients, e.g., a normal 183 light switch (C1) and an emergency fire panel (C2). Then, a C1 184 Client is not allowed to override a command from a C2 Client, until 185 the latter relinquishes control at its higher priority. That is: i) 186 only C2 Clients should be able to adjust the minimum required level 187 of priority on the Servers, so rightly locking out C1 Clients if 188 needed; and ii) when a Server is set to accept only high-priority 189 commands, only C2 Clients should be able to perform such commands 190 otherwise allowed also to C1 Clients. Given the different maximum 191 authority of different Clients, fine-grained access control would 192 effectively limit the execution of high- and emergency-priority 193 commands only to devices that are in fact authorized to do so. 194 Besides, it would prevent a misconfigured or compromised device from 195 initiating a high-priority command and lock out normal control. 197 In the cases above, being a legitimate group member and owning the 198 group keying material is not supposed to imply any particular access 199 rights. Also, introducing a different security group for each 200 different set of access rights would result in additional keying 201 material to distribute and manage. In particular, if the access 202 rights for a single node change, this would require to evict that 203 node from the current group, followed by that node joining a 204 different group aligned with its new access rights. Moreover, the 205 keying material of both groups would have to be renewed for their 206 current members. Overall, this would have a non negligible impact on 207 operations and performance in the system. 209 A fine-grained access control model can be rather enforced within a 210 same group, by using the Authentication and Authorization for 211 Constrained Environments (ACE) framework [I-D.ietf-ace-oauth-authz]. 212 That is, a Client has to first obtain authorization credentials in 213 the form of an Access Token, and post it to the Resource Server(s) in 214 the group before accessing the intended resources. 216 The ACE framework delegates to separate profile documents how to 217 secure communications between the Client and the Resource Server. 218 However each of the current profiles of ACE defined in 219 [I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-dtls-authorize] 220 [I-D.ietf-ace-mqtt-tls-profile] admits a single security protocol 221 that cannot be used to protect group messages sent over IP multicast. 223 This document specifies the "coap_group_oscore" profile of the ACE 224 framework, where a Client uses CoAP [RFC7252] or CoAP over IP 225 multicast [I-D.ietf-core-groupcomm-bis] to communicate to one or 226 multiple Resource Servers, which are members of an application group 227 and share a common set of resources. This profile uses Group OSCORE 228 [I-D.ietf-core-oscore-groupcomm] as the security protocol to protect 229 messages exchanged between the Client and the Resource Servers. 230 Hence, it requires that both the Client and the Resource Servers have 231 previously joined the same OSCORE group. 233 That is, this profile describes how access control is enforced for a 234 Client after it has joined an OSCORE group, to access resources at 235 other members in that group. The process for joining the OSCORE 236 group through the respective Group Manager as defined in 237 [I-D.ietf-ace-key-groupcomm-oscore] takes place before the process 238 described in this document, and is out of the scope of this profile. 240 The Client proves its access to be authorized to the Resource Server 241 by using an Access Token, which is bound to a key (the proof-of- 242 possession key). This profile uses Group OSCORE to achieve server 243 authentication, as well as proof-of-possession for the Client's 244 public key used in the OSCORE group in question. Note that the proof 245 of possession is not done by a dedicated protocol element, but rather 246 occurs after the first Group OSCORE exchange. Furthermore, this 247 profile provides proof of the Client's membership to the correct 248 OSCORE group, by binding the Access Token to the Client's public key 249 and information from the pre-established Group OSCORE Security 250 Context, thus allowing the Resource Server to verify this upon 251 reception of a message protected with Group OSCORE from the Client. 253 OSCORE [RFC8613] specifies how to use COSE 254 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] to 255 secure CoAP messages. Group OSCORE builds on OSCORE to provide 256 secure group communication, and ensures source authentication: by 257 means of digital signatures embedded in protected messages (in group 258 mode); or by protecting messages with pairwise keying material 259 derived from the asymmetric keys of the two peers exchanging the 260 message (in pairwise mode). 262 1.1. Terminology 264 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 265 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 266 "OPTIONAL" in this document are to be interpreted as described in BCP 267 14 [RFC2119] [RFC8174] when, and only when, they appear in all 268 capitals, as shown here. 270 Readers are expected to be familiar with the terms and concepts 271 related to CBOR [RFC8949], COSE 272 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs], 273 CoAP [RFC7252], OSCORE [RFC8613] and Group OSCORE 274 [I-D.ietf-core-oscore-groupcomm]. These include the concept of Group 275 Manager, as the entity responsible for a set of groups where 276 communications among members are secured with Group OSCORE. 278 Readers are expected to be familiar with the terms and concepts 279 described in the ACE framework for authentication and authorization 280 [I-D.ietf-ace-oauth-authz], as well as in the OSCORE profile of ACE 282 [I-D.ietf-ace-oscore-profile]. The terminology for entities in the 283 considered architecture is defined in OAuth 2.0 [RFC6749]. In 284 particular, this includes Client (C), Resource Server (RS), and 285 Authorization Server (AS). 287 Note that, unless otherwise indicated, the term "endpoint" is used 288 here following its OAuth definition, aimed at denoting resources such 289 as /token and /introspect at the AS, and /authz-info at the RS. This 290 document does not use the CoAP definition of "endpoint", which is "An 291 entity participating in the CoAP protocol". 293 Additionally, this document makes use of the following terminology. 295 * Full-fledged public key: a public key used in the OSCORE group, in 296 its original binary representation and according to the encoding 297 format used in the group. Encoding formats include, e.g., CWTs 298 [RFC8392], unprotected CWT claim sets [I-D.ietf-rats-uccs], X.509 299 certificates [RFC7925] and C509 certificates 300 [I-D.ietf-cose-cbor-encoded-cert]. As per Section 2.3 of 301 [I-D.ietf-core-oscore-groupcomm], a full-fledged public key 302 provides the full set of information related to the public key 303 algorithm, including, e.g., the used elliptic curve (when 304 applicable). 306 * Equivalent COSE Key: a COSE Key which is built from a full-fledged 307 public key used in the OSCORE group. The equivalent COSE Key 308 preserves all the main information elements from the full-fledged 309 public key, in particular the key coordinates and the full set of 310 information related to the public key algorithm, including, e.g., 311 the used elliptic curve (when applicable). 313 * Pairwise-only group: an OSCORE group that uses only the pairwise 314 mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). 316 Examples throughout this document are expressed in CBOR diagnostic 317 notation, without the tag and value abbreviations. 319 2. Protocol Overview 321 This section provides an overview of this profile, i.e., on how to 322 use the ACE framework for authentication and authorization 323 [I-D.ietf-ace-oauth-authz] to secure communications between a Client 324 and a (set of) Resource Server(s) using Group OSCORE 325 [I-D.ietf-core-oscore-groupcomm]. 327 Note that this profile of ACE describes how access control can be 328 enforced for a node after it has joined an OSCORE group, to access 329 resources at other members in that group. 331 In particular, the process for joining the OSCORE group through the 332 respective Group Manager as defined in 333 [I-D.ietf-ace-key-groupcomm-oscore] must take place before the 334 process described in this document, and is out of the scope of this 335 profile. 337 An overview of the protocol flow for this profile is shown in 338 Figure 1. In the figure, it is assumed that both RS1 and RS2 are 339 associated with the same AS. It is also assumed that C, RS1 and RS2 340 have previously joined an OSCORE group with Group Identifier (gid) 341 "abcd0000", and got assigned Sender ID (sid) "0", "1" and "2" in the 342 group, respectively. The names of messages coincide with those of 343 [I-D.ietf-ace-oauth-authz] when applicable. 345 C RS1 RS2 AS 346 | [--- Resource Request -->] | | | 347 | | | | 348 | [<---- AS Request ------] | | | 349 | Creation Hints | | | 350 | | | | 351 |-------- POST /token ----------------------------------------------->| 352 | (aud: RS1, sid: 0, gid: abcd0000, ...) | | 353 | | | | 354 |<-------------------------------- Access Token + RS Information -----| 355 | | (aud: RS1, sid: 0, gid: abcd0000, ...) | 356 | | | | 357 |---- POST /authz-info ----->| | | 358 | (access_token) | | | 359 | | | | 360 |<--- 2.01 Created ----------| | | 361 | | | | 362 | | | | 363 |-------- POST /token ----------------------------------------------->| 364 | (aud: RS2, sid: 0, gid: abcd0000, ...) | | 365 | | | | 366 |<-------------------------------- Access Token + RS Information -----| 367 | | (aud: RS2, sid: 0, gid: abcd0000, ...) | 368 | | | | 369 |----- POST /authz-info ----------------->| | 370 | (access_token) | | | 371 | | | | 373 | | | | 374 |<--- 2.01 Created -----------------------| | 375 | | | | 376 |-- Group OSCORE Request -+->| | | 377 | (kid: 0, gid: abcd0000) \-------------->| | 378 | | | | 379 | /proof-of-possession/ | 380 | | | | 381 | | | | 382 |<-- Group OSCORE Response --| | | 383 | (kid: 1) | | | 384 | | | | 385 /proof-of-possession/ | | | 386 | | | | 387 /Mutual authentication | | | 388 between C and RS1/ | | | 389 | | | | 390 | | | | 391 |<-- Group OSCORE Response ---------------| | 392 | (kid: 2) | | | 393 | | | | 394 /proof-of-possession/ | | | 395 | | | | 396 /Mutual authentication | | | 397 between C and RS2/ | | | 398 | | | | 399 | ... | | | 401 Figure 1: Protocol Overview. 403 2.1. Pre-Conditions 405 Using Group OSCORE and this profile requires both the Client and the 406 Resource Servers to have previously joined the same OSCORE group. 407 This especially includes the derivation of the Group OSCORE Security 408 Context and the assignment of unique Sender IDs to use in the group. 409 Nodes may join the OSCORE group through the respective Group Manager 410 by using the approach defined in [I-D.ietf-ace-key-groupcomm-oscore], 411 which is also based on ACE. 413 After the Client and Resource Servers have joined the group, this 414 profile provides access control for accessing resources on those 415 Resource Servers, by securely communicating with Group OSCORE. 417 As a pre-requisite for this profile, the Client has to have 418 successfully joined the OSCORE group where also the Resource Servers 419 (RSs) are members. Depending on the limited information initially 420 available, the Client may have to first discover the exact OSCORE 421 group used by the RSs for the resources of interest, e.g., by using 422 the approach defined in [I-D.tiloca-core-oscore-discovery]. 424 2.2. Access Token Retrieval 426 This profile requires that the Client retrieves an Access Token from 427 the AS for the resource(s) it wants to access on each of the RSs, 428 using the /token endpoint, as specified in Section 5.8 of 429 [I-D.ietf-ace-oauth-authz]. In a general case, it can be assumed 430 that different RSs are associated to different ASs, even if the RSs 431 are members of a same OSCORE group. 433 In the Access Token request to the AS, the Client MUST include the 434 Group Identifier of the OSCORE group and its own Sender ID in that 435 group. The AS MUST specify these pieces of information in the Access 436 Token, included in the Access Token response to the Client. 438 Furthermore, in the Access Token request to the AS, the Client MUST 439 also include: its own public key used in the OSCORE group; and a 440 proof-of-possession (PoP) evidence to proof possession of the 441 corresponding private key. The PoP evidence is computed over a PoP 442 input uniquely related to the secure communication association 443 between the Client and the AS. The AS MUST include also the public 444 key indicated by the Client in the Access Token. 446 The Access Token request and response MUST be confidentiality- 447 protected and ensure authenticity. This profile RECOMMENDS the use 448 of OSCORE between the Client and the AS, to reduce the number of 449 libraries the client has to support. Other protocols fulfilling the 450 security requirements defined in Sections 5 and 6 of 451 [I-D.ietf-ace-oauth-authz] MAY alternatively be used, such as TLS 452 [RFC8446] or DTLS [RFC6347][I-D.ietf-tls-dtls13]. 454 2.3. Access Token Posting 456 After having retrieved the Access Token from the AS, the Client posts 457 the Access Token to the RS, using the /authz-info endpoint and 458 mechanisms specified in Section 5.10 of [I-D.ietf-ace-oauth-authz], 459 as well as Content-Format = application/ace+cbor. When using this 460 profile, the communication with the /authz-info endpoint is not 461 protected. 463 If the Access Token is valid, the RS replies to this POST request 464 with a 2.01 (Created) response with Content-Format = application/ 465 ace+cbor. Also, the RS associates the received Access Token with the 466 Group OSCORE Security Context identified by the Group Identifier 467 specified in the Access Token, following Section 3.2 of [RFC8613]. 468 In practice, the RS maintains a collection of Security Contexts with 469 associated authorization information, for all the clients that it is 470 currently communicating with, and the authorization information is a 471 policy used as input when processing requests from those clients. 473 Finally, the RS stores the association between i) the authorization 474 information from the Access Token; and ii) the Group Identifier of 475 the OSCORE group together with the Sender ID and the public key of 476 the Client in that group. This binds the Access Token with the Group 477 OSCORE Security Context of the OSCORE group. 479 Finally, when the Client communicates with the RS using the Group 480 OSCORE Security Context, the RS verifies that the Client is a 481 legitimate member of the OSCORE group and especially the exact group 482 member with the same Sender ID associated to the Access Token. This 483 occurs when verifying a request protected with Group OSCORE, since 484 the request includes the Client's Sender ID and either it embeds a 485 signature computed also over that Sender ID (if protected with the 486 group mode), or it is protected by means of pairwise symmetric keying 487 material derived from the asymmetric keys of the two peers (if 488 protected with the pairwise mode). 490 2.4. Secure Communication 492 The Client can send a request protected with Group OSCORE 493 [I-D.ietf-core-oscore-groupcomm] to the RS. This can be a unicast 494 request addressed to the RS, or a multicast request addressed to the 495 OSCORE group where the RS is also a member. To this end, the Client 496 uses the Group OSCORE Security Context already established upon 497 joining the OSCORE group, e.g., by using the approach defined in 498 [I-D.ietf-ace-key-groupcomm-oscore]. The RS may send a response back 499 to the Client, protecting it by means of the same Group OSCORE 500 Security Context. 502 3. Client-AS Communication 504 This section details the Access Token POST Request that the Client 505 sends to the /token endpoint of the AS, as well as the related Access 506 Token response. 508 The Access Token MUST be bound to the public key of the client as 509 proof-of-possession key (pop-key), by means of the 'cnf' claim. 511 3.1. C-to-AS: POST to Token Endpoint 513 The Client-to-AS request is specified in Section 5.8.1 of 514 [I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request 515 to the /token endpoint over a secure channel that guarantees 516 authentication, message integrity and confidentiality. 518 The POST request is formatted as the analogous Client-to-AS request 519 in the OSCORE profile of ACE (see Section 3.1 of 520 [I-D.ietf-ace-oscore-profile]), with the following additional 521 parameters that MUST be included in the payload. 523 * 'context_id', defined in Section 3.1.1 of this document. This 524 parameter specifies the Group Identifier (GID), i.e., the Id 525 Context of an OSCORE group where the Client and the RS are 526 currently members. In particular, the Client wishes to 527 communicate with the RS using the Group OSCORE Security Context 528 associated to that OSCORE group. 530 * 'salt_input', defined in Section 3.1.2 of this document. This 531 parameter includes the Sender ID that the Client has in the OSCORE 532 group whose GID is specified in the 'context_id' parameter above. 534 * 'req_cnf', defined in Section 3.1 of [I-D.ietf-ace-oauth-params]. 535 This parameter follows the syntax from Section 3.1 of [RFC8747] 536 when including Value Type "COSE_Key" (1) and specifying an 537 asymmetric key. In particular, the specified public key is the 538 COSE Key equivalent to the full-fledged public key that the Client 539 uses in the OSCORE group. The specified public key will be used 540 as the pop-key bound to the Access Token. 542 Alternative Value Types defined in future specifications are fine 543 to consider if indicating a non-encrypted asymmetric key. 545 In addition, the Client computes its proof-of-possession (PoP) 546 evidence, in order to prove possession of its own private key used in 547 the OSCORE group to the AS. This allows the AS to verify that the 548 Client indeed owns the private key associated to that public key, as 549 its alleged identity credential within the OSCORE group. 551 To this end, the Client MUST use as PoP input the byte representation 552 of a quantity that uniquely represents the secure communication 553 association between the Client and the AS. It is RECOMMENDED that 554 the Client considers the following as PoP input. 556 * If the Client and the AS communicate over (D)TLS, the PoP input is 557 an exporter value computed as defined in Section 7.5 of [RFC8446]. 558 In particular, the exporter label MUST be 'EXPORTER-ACE-Sign- 559 Challenge-Client-AS' defined in Section 10.5 of this document, 560 together with an empty 'context_value', and 32 bytes as 561 'key_length'. 563 * If the Client and the AS communicate over OSCORE, the PoP input is 564 the output PRK of a HKDF-Extract step [RFC5869], i.e., PRK = HMAC- 565 Hash(salt, IKM). In particular, 'salt' takes (x1 | x2), where x1 566 is the ID Context of the OSCORE Security Context between the 567 Client and the AS, x2 is the Sender ID of the Client in that 568 Security Context, and | denotes byte string concatenation. Also, 569 'IKM' is the OSCORE Master Secret of the OSCORE Security Context 570 between the Client and the AS. 572 The HKDF MUST be one of the HMAC-based HKDF [RFC5869] algorithms 573 defined for COSE [I-D.ietf-cose-rfc8152bis-algs]. The Client and 574 AS may agree on the HKDF algorithm to use during the Client's 575 registration at the AS. HKDF SHA-256 is mandatory to implement. 577 Then, the Client computes the PoP evidence as follows. 579 * If the OSCORE group is not a pairwise-only group, the PoP evidence 580 MUST be a signature. The Client computes the signature by using 581 the same private key and signature algorithm it uses for signing 582 messages in the OSCORE group. The private key corresponds to the 583 public key used in the OSCORE group, for which the equivalent COSE 584 Key is specified in the 'req_cnf' parameter above. 586 * If the OSCORE group is a pairwise-only group, the PoP evidence 587 MUST be a MAC computed as follows, by using the HKDF Algorithm 588 HKDF SHA-256, which consists of composing the HKDF-Extract and 589 HKDF-Expand steps [RFC5869]. 591 MAC = HKDF(salt, IKM, info, L) 593 The input parameters of HKDF are as follows. 595 - salt takes as value the empty byte string. 597 - IKM is computed as a cofactor Diffie-Hellman shared secret, see 598 Section 5.7.1.2 of [NIST-800-56A], using an ECDH algorithm pre- 599 agreed between Client and AS. The Client uses its own Diffie- 600 Hellman private key and the Diffie-Hellman public key of the 601 AS. For X25519 and X448, the procedure is described in 602 Section 5 of [RFC7748]. 604 The Client's private key corresponds to the Client's public key 605 used in the OSCORE group, for which the equivalent COSE Key is 606 specified in the 'req_cnf' parameter above. The Client may 607 obtain the Diffie-Hellman public key of the AS during its 608 registration process at the AS. 610 The Client and AS may agree on the ECDH algorithm to use during 611 the Client's registration at the AS. The ECDH-SS + HKDF-256 612 algorithm specified in Section 6.3.1 of 613 [I-D.ietf-cose-rfc8152bis-algs] is mandatory to implement. 615 - info takes as value the PoP input. 617 - L is equal to 8, i.e., the size of the MAC, in bytes. 619 Finally, the Client MUST include one of the two following parameters 620 in the payload of the POST request to the AS. 622 * 'client_cred_verify', defined in Section 3.1.3 of this document, 623 specifying the Client's PoP evidence as a signature, which is 624 computed as defined above. This parameter MUST be included if and 625 only if the OSCORE group is not a pairwise-only group. 627 * 'client_cred_verify_mac', defined in Section 3.1.4 of this 628 document, specifying the Client's PoP evidence as a MAC, which is 629 computed as defined above. This parameter MUST be included if and 630 only if the OSCORE group is a pairwise-only group. 632 An example of such a request is shown in Figure 2. 634 Header: POST (Code=0.02) 635 Uri-Host: "as.example.com" 636 Uri-Path: "token" 637 Content-Format: "application/ace+cbor" 638 Payload: 639 { 640 "audience" : "tempSensor4711", 641 "scope" : "read", 642 "context_id" : h'abcd0000', 643 "salt_input" : h'00', 644 "req_cnf" : { 645 "COSE_Key" : { 646 "kty" : EC2, 647 "crv" : P-256, 648 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 649 27c9e354089bbe13', 650 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 651 731e79a3b4e47120' 652 } 653 }, 654 "client_cred_verify" : h'...' 655 (signature content omitted for brevity) 656 } 658 Figure 2: Example C-to-AS POST /token request for an Access Token 659 bound to an asymmetric key. 661 3.1.1. 'context_id' Parameter 663 The 'context_id' parameter is an OPTIONAL parameter of the Access 664 Token request message defined in Section 5.8.1 of 665 [I-D.ietf-ace-oauth-authz]. This parameter provides a value that the 666 Client wishes to use with the RS as a hint for a security context. 667 Its exact content is profile specific. 669 3.1.2. 'salt_input' Parameter 671 The 'salt_input' parameter is an OPTIONAL parameter of the Access 672 Token request message defined in Section 5.8.1 of 673 [I-D.ietf-ace-oauth-authz]. This parameter provides a value that the 674 Client wishes to use as part of a salt with the RS, for deriving 675 cryptographic keying material. Its exact content is profile 676 specific. 678 3.1.3. 'client_cred_verify' Parameter 680 The 'client_cred_verify' parameter is an OPTIONAL parameter of the 681 Access Token request message defined in Section 5.8.1. of 682 [I-D.ietf-ace-oauth-authz]. This parameter provides a signature 683 computed by the Client to prove the possession of its own private 684 key. 686 3.1.4. 'client_cred_verify_mac' Parameter 688 The 'client_cred_verify_mac' parameter is an OPTIONAL parameter of 689 the Access Token request message defined in Section 5.8.1. of 690 [I-D.ietf-ace-oauth-authz]. This parameter provides a Message 691 Authentication Code (MAC) computed by the Client to prove the 692 possession of its own private key. 694 3.2. AS-to-C: Access Token 696 After having verified the POST request to the /token endpoint and 697 that the Client is authorized to obtain an Access Token corresponding 698 to its Access Token request, the AS MUST verify the proof-of- 699 possession (PoP) evidence. In particular, the AS proceeds as 700 follows. 702 * As PoP input, the AS uses the same value considered by the Client 703 in Section 3.1. 705 * As public key of the Client, the AS uses the one specified in the 706 'req_cnf' parameter of the Access Token request. 708 * If the Access Token request includes the 'client_cred_verify' 709 parameter, this specifies the PoP evidence as a signature. Then, 710 the AS verifies the signature by using the public key of the 711 Client. 713 * If the Access Token request includes the 'client_cred_verify_mac' 714 parameter, this specifies the PoP evidence as a Message 715 Authentication Code (MAC). 717 Then, the AS recomputes the MAC through the same process taken by 718 the Client when preparing the value of the 719 'client_cred_verify_mac' parameter for the Access Token (see 720 Section 3.1), with the difference that the AS uses its own Diffie- 721 Hellman private key and the Diffie-Hellman public key of the 722 Client. The verification succeeds if and only if the recomputed 723 MAC is equal to the MAC conveyed as PoP evidence in the Access 724 Token request. 726 If both the 'client_cred_verify' and 'client_cred_verify_mac' 727 parameters are present, or if the verification of the PoP evidence 728 fails, the AS considers the Client request invalid. 730 If the Client request was invalid, or not authorized, the AS returns 731 an error response as described in Section 5.8.3 of 732 [I-D.ietf-ace-oauth-authz]. 734 If all verifications are successful, the AS responds as defined in 735 Section 5.8.2 of [I-D.ietf-ace-oauth-authz]. In particular: 737 * The AS can signal that the use of Group OSCORE is REQUIRED for a 738 specific Access Token by including the 'ace_profile' parameter 739 with the value "coap_group_oscore" in the Access Token response. 740 The Client MUST use Group OSCORE towards all the Resource Servers 741 for which this Access Token is valid. Usually, it is assumed that 742 constrained devices will be pre-configured with the necessary 743 profile, so that this kind of profile signaling can be omitted. 745 * The AS MUST NOT include the 'rs_cnf' parameter defined in 746 [I-D.ietf-ace-oauth-params]. In general, the AS may not be aware 747 of the public keys that the RSs use in the OSCORE group. Also, 748 the Client is able to retrieve the public keys of other group 749 members from the responsible Group Manager, both upon joining the 750 group or later on as a group member, as defined in 751 [I-D.ietf-ace-key-groupcomm-oscore]. 753 The AS MUST include the following information as metadata of the 754 issued Access Token. The use of CBOR web tokens (CWT) as specified 755 in [RFC8392] is RECOMMENDED. 757 * The profile "coap_group_oscore". If the Access Token is a CWT, 758 this is placed in the 'ace_profile' claim of the Access Token, as 759 per Section 5.10 of [I-D.ietf-ace-oauth-authz]. 761 * The salt input specified in the 'salt_input' parameter of the 762 Token Request. If the Access Token is a CWT, the content of the 763 'salt_input' parameter MUST be placed in the 'salt_input' claim of 764 the Access Token, defined in Section 3.2.1 of this document. 766 * The Context Id input specified in the 'context_id' parameter of 767 the Token Request. If the Access Token is a CWT, the content of 768 the 'context_id' parameter MUST be placed in the 'contextId_input' 769 claim of the Access Token, defined in Section 3.2.2 of this 770 document. 772 * The public key that the client uses in the OSCORE group and 773 specified in the 'req_cnf' parameter of the Token request. 775 If the Access Token is a CWT, the public key MUST be specified in 776 the 'cnf' claim, which follows the syntax from Section 3.1 of 777 [RFC8747] when including Value Type "COSE_Key" (1) and specifying 778 an asymmetric key. In particular, the 'cnf' claim includes the 779 same COSE Key specified in the 'req_cnf' parameter of the Token 780 Request, i.e., the COSE Key equivalent to the full-fledged public 781 key that the Client uses in the OSCORE group. 783 Alternative Value Types defined in future specifications are fine 784 to consider if indicating a non-encrypted asymmetric key. 786 Figure 3 shows an example of such an AS response. The access token 787 has been truncated for readability. 789 Header: Created (Code=2.01) 790 Content-Type: "application/ace+cbor" 791 Payload: 792 { 793 "access_token" : h'8343a1010aa2044c53 ...' 794 (remainder of CWT omitted for brevity), 795 "ace_profile" : "coap_group_oscore", 796 "expires_in" : 3600 797 } 799 Figure 3: Example AS-to-C Access Token response with the Group 800 OSCORE profile. 802 Figure 4 shows an example CWT Claims Set, containing the Client's 803 public key in the group (as pop-key) in the 'cnf' claim. 805 { 806 "aud" : "tempSensorInLivingRoom", 807 "iat" : "1360189224", 808 "exp" : "1360289224", 809 "scope" : "temperature_g firmware_p", 810 "cnf" : { 811 "COSE_Key" : { 812 "kty" : EC2, 813 "crv" : P-256, 814 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 815 27c9e354089bbe13', 816 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 817 731e79a3b4e47120' 818 }, 819 "salt_input" : h'00', 820 "contextId_input" : h'abcd0000' 821 } 823 Figure 4: Example CWT Claims Set with OSCORE parameters. 825 The same CWT Claims Set as in Figure 4 and encoded in CBOR is shown 826 in Figure 5, using the value abbreviations defined in 827 [I-D.ietf-ace-oauth-authz] and [RFC8747]. The bytes in hexadecimal 828 are reported in the first column, while their corresponding CBOR 829 meaning is reported after the "#" sign on the second column, for 830 easiness of readability. 832 NOTE: it should be checked (and in case fixed) that the values used 833 below (which are not yet registered) are the final values registered 834 by IANA. 836 A7 # map(7) 837 03 # unsigned(3) 838 76 # text(22) 839 74656D7053656E736F72496E4C6976696E67526F6F6D 840 06 # unsigned(6) 841 1A 5112D728 # unsigned(1360189224) 842 04 # unsigned(4) 843 1A 51145DC8 # unsigned(1360289224) 844 09 # unsigned(9) 845 78 18 # text(24) 846 74656D70657261747572655F67206669726D776172655F70 847 08 # unsigned(8) 848 A1 # map(1) 849 01 # unsigned(1) 850 A4 # map(4) 851 01 # unsigned(1) 852 02 # unsigned(2) 853 20 # negative(0) 854 01 # unsigned(1) 855 21 # negative(1) 856 58 20 # bytes(32) 857 D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9 858 E354089BBE13 859 22 # negative(2) 860 58 20 # bytes(32) 861 F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E515D020731E 862 79A3B4E47120 863 18 3C # unsigned(60) 864 41 # bytes(1) 865 00 866 18 3D # unsigned(61) 867 44 # bytes(4) 868 ABCD0000 870 Figure 5: Example CWT Claims Set with OSCORE parameters, CBOR 871 encoded. 873 3.2.1. Salt Input Claim 875 The 'salt_input' claim provides a value that the Client requesting 876 the Access Token wishes to use as a part of a salt with the RS, e.g., 877 for deriving cryptographic material. 879 This parameter specifies the value of the salt input, encoded as a 880 CBOR byte string. 882 3.2.2. Context ID Input Claim 884 The 'contextId_input' claim provides a value that the Client 885 requesting the Access Token wishes to use with the RS, as a hint for 886 a security context. 888 This parameter specifies the value of the Context ID input, encoded 889 as a CBOR byte string. 891 4. Client-RS Communication 893 This section details the POST request and response to the /authz-info 894 endpoint between the Client and the RS. 896 The proof-of-possession required to bind the Access Token to the 897 Client is explicitly performed when the RS receives and verifies a 898 request from the Client protected with Group OSCORE, either with the 899 group mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]) or 900 with the pairwise mode (see Section 9 of 901 [I-D.ietf-core-oscore-groupcomm]). 903 In particular, the RS uses the Client's public key bound to the 904 Access Token, either when verifying the signature of the request (if 905 protected with the group mode), or when verifying the request as 906 integrity-protected with pairwise keying material derived from the 907 two peers' asymmetric keys (if protected with the pairwise mode). In 908 either case, the RS also authenticates the Client. 910 Similarly, when receiving a protected response from the RS, the 911 Client uses the RS's public key either when verifying the signature 912 of the response (if protected with the group mode), or when verifying 913 the response as integrity-protected with pairwise keying material 914 derived from the two peers' asymmetric keys (if protected with the 915 pairwise mode). In either case, the Client also authenticates the 916 RS. Mutual authentication is only achieved after the client has 917 successfully verified the protected response from the RS. 919 Therefore, an attacker using a stolen Access Token cannot generate a 920 valid Group OSCORE message as protected through the Client's private 921 key, and thus cannot prove possession of the pop-key bound to the 922 Access Token. Also, if a Client legitimately owns an Access Token 923 but has not joined the OSCORE group, it cannot generate a valid Group 924 OSCORE message, as it does not own the necessary keying material 925 shared among the group members. 927 Furthermore, a Client C1 is supposed to obtain a valid Access Token 928 from the AS, as including the public key associated to its own key 929 used in the OSCORE group, together with its own Sender ID in that 930 OSCORE group (see Section 3.1). This makes it possible for the RS 931 receiving an Access Token to verify with the Group Manager of that 932 OSCORE group whether such a Client has indeed that Sender ID and that 933 public key in the OSCORE group. 935 As a consequence, a different Client C2, also member of the same 936 OSCORE group, is not able to impersonate C1, by: i) getting a valid 937 Access Token, specifying the Sender ID of C1 and a different (made- 938 up) public key; ii) successfully posting the Access Token to RS; and 939 then iii) attempting to communicate using Group OSCORE impersonating 940 C1, while blaming C1 for the consequences. 942 4.1. C-to-RS POST to authz-info Endpoint 944 The Client posts the Access Token to the /authz-info endpoint of the 945 RS, as defined in Section 5.10.1 of [I-D.ietf-ace-oauth-authz]. 947 4.2. RS-to-C: 2.01 (Created) 949 The RS MUST verify the validity of the Access Token as defined in 950 Section 5.10.1 of [I-D.ietf-ace-oauth-authz], with the following 951 additions. 953 * The RS MUST check that the claims 'salt_input', 'contextId_input' 954 and 'cnf' are included in the Access Token. 956 * The RS considers: the content of the 'contextId_input' claim as 957 the GID of the OSCORE group; the content of the 'salt_input' claim 958 as the Sender ID that the Client has in the group; and the content 959 of the 'cnf' claim as the COSE Key equivalent to the full-fledged 960 public key that the Client uses in the group. 962 The RS MUST check whether it already stores a public key 963 associated to the pair (GID, Sender ID) above, such that the COSE 964 Key specified in the 'cnf' claim is its equivalent COSE Key. 966 If this is not the case, the RS MUST request the Client's public 967 key to the Group Manager of the OSCORE group as described in 968 Section 12 of [I-D.ietf-ace-key-groupcomm-oscore], specifying the 969 Client's Sender ID in the OSCORE group, i.e., the value of the 970 'salt_input' claim. Then, the RS performs the following actions. 972 - The RS MUST check whether the Client's public key retrieved 973 from the Group Manager is such that the COSE Key specified in 974 the 'cnf' claim of the Access Token is its equivalent COSE Key. 976 - The RS MUST check that the Client's Sender ID provided by the 977 Group Manager together with the Client's public key matches the 978 one retrieved from the 'salt_input' claim of the Access Token. 980 If any of the checks above fails, the RS MUST consider the Access 981 Token non valid, and MUST respond to the Client with an error 982 response code equivalent to the CoAP code 4.00 (Bad Request). 984 If the Access Token is valid and further checks on its content are 985 successful, the RS associates the authorization information from the 986 Access Token with the Group OSCORE Security Context. 988 In particular, the RS associates the authorization information from 989 the Access Token with the 3-tuple (GID, SaltInput, PubKey), where GID 990 is the Group Identifier of the OSCORE Group, while SaltInput and 991 PubKey are the Sender ID and the public key that the Client uses in 992 that OSCORE group, respectively. 994 The RS MUST keep this association up-to-date over time, as the 995 3-tuple (GID, SaltInput, PubKey) associated to the Access Token might 996 change. In particular: 998 * If the OSCORE group is rekeyed (see Section 3.2 of 999 [I-D.ietf-core-oscore-groupcomm] and Section 20 of 1000 [I-D.ietf-ace-key-groupcomm-oscore]), the Group Identifier also 1001 changes in the group, and the new one replaces the current 'GID' 1002 value in the 3-tuple. 1004 * If the Client requests and obtains a new OSCORE Sender ID from the 1005 Group Manager (see Section 2.5.3.1 of 1006 [I-D.ietf-core-oscore-groupcomm] and Section 9 of 1007 [I-D.ietf-ace-key-groupcomm-oscore]), the new Sender ID replaces 1008 the current 'SaltInput' value in the 3-tuple. 1010 Finally, the RS MUST send a 2.01 (Created) response to the Client, as 1011 defined in Section 5.10.1 of [I-D.ietf-ace-oauth-authz]. 1013 4.3. Client-RS Secure Communication 1015 When previously joining the OSCORE group, both the Client and RS have 1016 already established the related Group OSCORE Security Context to 1017 communicate as group members. Therefore, they can simply start to 1018 securely communicate using Group OSCORE, without deriving any 1019 additional keying material or security association. 1021 4.3.1. Client Side 1023 After having received the 2.01 (Created) response from the RS, 1024 following the POST request to the authz-info endpoint, the Client 1025 starts the communication with the RS, by sending a request protected 1026 with Group OSCORE using the Group OSCORE Security Context 1027 [I-D.ietf-core-oscore-groupcomm]. 1029 When communicating with the RS to access the resources as specified 1030 by the authorization information, the Client MUST use the Group 1031 OSCORE Security Context of the OSCORE group, whose GID was specified 1032 in the 'context_id' parameter of the Token request. 1034 4.3.2. Resource Server Side 1036 After successful validation of the Access Token as defined in 1037 Section 4.2 and after having sent the 2.01 (Created) response, the RS 1038 can start to communicate with the Client using Group OSCORE 1039 [I-D.ietf-core-oscore-groupcomm]. 1041 When processing an incoming request protected with Group OSCORE, the 1042 RS MUST consider as valid public key of the Client only the public 1043 key specified in the stored Access Token. As defined in Section 4.5, 1044 a possible change of public key requires the Client to upload to the 1045 RS a new Access Token bound to the new public key. 1047 Additionally, for every incoming request, if Group OSCORE 1048 verification succeeds, the verification of access rights is performed 1049 as described in Section 4.4. 1051 After the expiration of the Access Token related to a Group OSCORE 1052 Security Context, if the Client uses the Group OSCORE Security 1053 Context to send a request for any resource intended for OSCORE group 1054 members and that requires an active Access Token, the RS MUST respond 1055 with a 4.01 (Unauthorized) error message protected with the Group 1056 OSCORE Security Context. 1058 4.4. Access Rights Verification 1060 The RS MUST follow the procedures defined in Section 5.10.2 of 1061 [I-D.ietf-ace-oauth-authz]. If an RS receives a Group OSCORE- 1062 protected request from a Client, the RS processes it according to 1063 [I-D.ietf-core-oscore-groupcomm]. 1065 If the Group OSCORE verification succeeds, and the target resource 1066 requires authorization, the RS retrieves the authorization 1067 information from the Access Token associated to the Group OSCORE 1068 Security Context. Then, the RS MUST verify that the action requested 1069 on the resource is authorized. 1071 The response code MUST be 4.01 (Unauthorized) if the RS has no valid 1072 Access Token for the Client. If the RS has an Access Token for the 1073 Client but no actions are authorized on the target resource, the RS 1074 MUST reject the request with a 4.03 (Forbidden). If the RS has an 1075 Access Token for the Client but the requested action is not 1076 authorized, the RS MUST reject the request with a 4.05 (Method Not 1077 Allowed). 1079 4.5. Change of Client's Public Key in the Group 1081 During its membership in the OSCORE group, the client might change 1082 the public key it uses in the group. When this happens, the Client 1083 uploads the new public key to the Group Manager, as defined in 1084 Section 11 of [I-D.ietf-ace-key-groupcomm-oscore]. 1086 After that, and in order to continue communicating with the RS, the 1087 Client MUST perform the following actions. 1089 1. The Client requests a new Access Token to the AS, as defined in 1090 Section 3. In particular, when sending the POST request as 1091 defined in Section 3.1, the Client indicates: 1093 * The current Group Identifier of the OSCORE group, as value of 1094 the 'context_id' parameter. 1096 * The current Sender ID it has in the OSCORE group, as value of 1097 the 'salt_input' parameter. 1099 * The new public key it uses in the OSCORE group, as value of 1100 the 'req_cnf' parameter. In particular, the specified public 1101 key is the COSE Key equivalent to the new full-fledged public 1102 key that the Client uses in the OSCORE group. 1104 * The proof-of-possession (PoP) evidence corresponding to the 1105 new public key, as value of the 'client_cred_verify' or 1106 'client_cred_verify_mac' parameter. 1108 2. After receiving the response from the AS (see Section 3.2), the 1109 Client performs the same exchanges with the RS as defined in 1110 Section 4. 1112 When receiving the new Access Token, the RS performs the same steps 1113 defined in Section 4.2, with the following addition, in case the new 1114 Access Token is successfully verified and stored. The RS also 1115 deletes the old Access Token, i.e., the one whose associated 3-tuple 1116 has the same GID and SaltInput values as in the 3-tuple including the 1117 new public key of the Client and associated to the new Access Token. 1119 5. Secure Communication with the AS 1121 As specified in the ACE framework (see Sections 5.8 and 5.9 of 1122 [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or Client) 1123 and the AS communicate via the /token or /introspection endpoint. 1124 The use of CoAP and OSCORE [RFC8613] for this communication is 1125 RECOMMENDED in this profile. Other protocols fulfilling the security 1126 requirements defined in Sections 5 and 6 of 1127 [I-D.ietf-ace-oauth-authz] (such as HTTP and DTLS or TLS) MAY be used 1128 instead. 1130 If OSCORE [RFC8613] is used, the requesting entity and the AS are 1131 expected to have a pre-established Security Context in place. How 1132 this Security Context is established is out of the scope of this 1133 profile. Furthermore, the requesting entity and the AS communicate 1134 using OSCORE through the /introspection endpoint as specified in 1135 Section 5.9 of [I-D.ietf-ace-oauth-authz], and through the /token 1136 endpoint as specified in Section 5.8 of [I-D.ietf-ace-oauth-authz]. 1138 6. Discarding the Security Context 1140 As members of an OSCORE group, the Client and the RS may 1141 independently leave the group or be forced to, e.g., if compromised 1142 or suspected so. Upon leaving the OSCORE group, the Client or RS 1143 also discards the Group OSCORE Security Context, which may anyway be 1144 renewed by the Group Manager through a group rekeying process (see 1145 Section 3.2 of [I-D.ietf-core-oscore-groupcomm]). 1147 The Client or RS can acquire a new Group OSCORE Security Context, by 1148 re-joining the OSCORE group, e.g., by using the approach defined in 1149 [I-D.ietf-ace-key-groupcomm-oscore]. In such a case, the Client 1150 SHOULD request a new Access Token and post it to the RS. 1152 7. CBOR Mappings 1154 The new parameters defined in this document MUST be mapped to CBOR 1155 types as specified in Figure 6, using the given integer abbreviation 1156 for the map key. 1158 /------------------------+----------+------------\ 1159 | Parameter name | CBOR Key | Value Type | 1160 |------------------------+----------+------------| 1161 | context_id | TBD | bstr | 1162 | salt_input | TBD | bstr | 1163 | client_cred_verify | TBD | bstr | 1164 | client_cred_verify_mac | TBD | bstr | 1165 \------------------------+----------+------------/ 1167 Figure 6: CBOR mappings for new parameters. 1169 The new claims defined in this document MUST be mapped to CBOR types 1170 as specified in Figure 7, using the given integer abbreviation for 1171 the map key. 1173 /-----------------+----------+------------\ 1174 | Claim name | CBOR Key | Value Type | 1175 |-----------------+----------+------------| 1176 | salt_input | TBD | bstr | 1177 | contextId_input | TBD | bstr | 1178 \-----------------+----------+------------/ 1180 Figure 7: CBOR mappings for new claims. 1182 8. Security Considerations 1184 This document specifies a profile for the Authentication and 1185 Authorization for Constrained Environments (ACE) framework 1186 [I-D.ietf-ace-oauth-authz]. Thus, the general security 1187 considerations from the ACE framework also apply to this profile. 1189 The proof-of-possession (PoP) key bound to an Access Token is always 1190 an asymmetric key, i.e., the public key that the Client uses in the 1191 OSCORE group. This means that there is never a same shared secret 1192 used as PoP key with possible multiple RSs. Therefore, it is 1193 possible and safe for the AS to issue an Access Token whose audience 1194 comprises multiple RSs. 1196 In such a case, as per Section 6.1 of [I-D.ietf-ace-oauth-authz], the 1197 AS has to ensure the integrity protection of the Access Token by 1198 protecting it through an asymmetric signature. In addition, the used 1199 audience has to correctly identify all the RSs that are intended 1200 recipients of the Access Token. As a particular case, the audience 1201 can be the name of the OSCORE group, if the Access Token is intended 1202 to all the RSs in that group. 1204 Furthermore, this document inherits the general security 1205 considerations about Group OSCORE [I-D.ietf-core-oscore-groupcomm], 1206 as to the specific use of Group OSCORE according to this profile. 1208 Group OSCORE is designed to secure point-to-point as well as point- 1209 to-multipoint communications, providing a secure binding between a 1210 single request and multiple corresponding responses. In particular, 1211 Group OSCORE fulfills the same security requirements of OSCORE, for 1212 group requests and responses. 1214 Group OSCORE ensures source authentication of messages both in group 1215 mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]) and in 1216 pairwise mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). 1218 When protecting an outgoing message in group mode, the sender uses 1219 its private key to compute a digital signature, which is embedded in 1220 the protected message. The group mode can be used to protect 1221 messages sent over multicast to multiple recipients, or sent over 1222 unicast to one recipient. 1224 When protecting an outgoing message in pairwise mode, the sender uses 1225 a pairwise symmetric key, as derived from the asymmetric keys of the 1226 two peers exchanging the message. The pairwise mode can be used to 1227 protect only messages intended to one recipient. 1229 9. Privacy Considerations 1231 This document specifies a profile for the Authentication and 1232 Authorization for Constrained Environments (ACE) framework 1233 [I-D.ietf-ace-oauth-authz]. Thus the general privacy considerations 1234 from the ACE framework also apply to this profile. 1236 As this profile uses Group OSCORE, the privacy considerations from 1237 [I-D.ietf-core-oscore-groupcomm] apply to this document as well. 1239 An unprotected response to an unauthorized request may disclose 1240 information about the RS and/or its existing relationship with the 1241 Client. It is advisable to include as little information as possible 1242 in an unencrypted response. However, since both the Client and the 1243 RS share a Group OSCORE Security Context, unauthorized, yet protected 1244 requests are followed by protected responses, which can thus include 1245 more detailed information. 1247 Although it may be encrypted, the Access Token is sent in the clear 1248 to the /authz-info endpoint at the RS. Thus, if the Client uses the 1249 same single Access Token from multiple locations with multiple 1250 Resource Servers, it can risk being tracked through the Access 1251 Token's value. 1253 Note that, even though communications are protected with Group 1254 OSCORE, some information might still leak, due to the observable 1255 size, source address and destination address of exchanged messages. 1257 10. IANA Considerations 1259 This document has the following actions for IANA. 1261 10.1. ACE Profile Registry 1263 IANA is asked to add the following entry to the "ACE Profile" 1264 registry defined in Section 8.8 of [I-D.ietf-ace-oauth-authz]. 1266 * Name: coap_group_oscore 1268 * Description: Profile to secure communications between constrained 1269 nodes using the Authentication and Authorization for Constrained 1270 Environments framework, by enabling authentication and fine- 1271 grained authorization of members of an OSCORE group, that use a 1272 pre-established Group OSCORE Security Context to communicate with 1273 Group OSCORE. Optionally, the dual mode defined in Appendix A 1274 additionally establishes a pairwise OSCORE Security Context, and 1275 thus also enables OSCORE communication between two members of the 1276 OSCORE group. 1278 * CBOR Value: TBD (value between 1 and 255) 1280 * Reference: [[this document]] 1282 10.2. OAuth Parameters Registry 1284 IANA is asked to add the following entries to the "OAuth Parameters" 1285 registry. 1287 * Name: "context_id" 1289 * Parameter Usage Location: token request 1291 * Change Controller: IESG 1293 * Specification Document(s): Section 3.1.1 of [[this document]] 1295 * Name: "salt_input" 1297 * Parameter Usage Location: token request 1299 * Change Controller: IESG 1300 * Specification Document(s): Section 3.1.2 of [[this document]] 1302 * Name: "client_cred_verify" 1304 * Parameter Usage Location: token request 1306 * Change Controller: IESG 1308 * Specification Document(s): Section 3.1.3 of [[this document]] 1310 * Name: "client_cred_verify_mac" 1312 * Parameter Usage Location: token request 1314 * Change Controller: IESG 1316 * Specification Document(s): Section 3.1.4 of [[this document]] 1318 * Name: "client_cred" 1320 * Parameter Usage Location: token request 1322 * Change Controller: IESG 1324 * Specification Document(s): Appendix A.2.1.1 of [[this document]] 1326 10.3. OAuth Parameters CBOR Mappings Registry 1328 IANA is asked to add the following entries to the "OAuth Parameters 1329 CBOR Mappings" registry defined in Section 8.10 of 1330 [I-D.ietf-ace-oauth-authz]. 1332 * Name: "context_id" 1334 * CBOR Key: TBD 1336 * Value Type: bstr 1338 * Reference: Section 3.1.1 of [[this document]] 1340 * Name: "salt_input" 1342 * CBOR Key: TBD 1343 * Value Type: bstr 1345 * Reference: Section 3.1.2 of [[this document]] 1347 * Name: "client_cred_verify" 1349 * CBOR Key: TBD 1351 * Value Type: bstr 1353 * Reference: Section 3.1.3 of [[this document]] 1355 * Name: "client_cred_verify_mac" 1357 * CBOR Key: TBD 1359 * Value Type: bstr 1361 * Reference: Section 3.1.4 of [[this document]] 1363 * Name: "client_cred" 1365 * CBOR Key: TBD 1367 * Value Type: bstr 1369 * Reference: Appendix A.2.1.1 of [[this document]] 1371 10.4. CBOR Web Token Claims Registry 1373 IANA is asked to add the following entries to the "CBOR Web Token 1374 Claims" registry. 1376 * Claim Name: "salt_input" 1378 * Claim Description: Client provided salt input 1380 * JWT Claim Name: "N/A" 1382 * Claim Key: TBD 1384 * Claim Value Type(s): bstr 1386 * Change Controller: IESG 1387 * Specification Document(s): Section 3.2.1 of [[this document]] 1389 * Claim Name: "contextId_input" 1391 * Claim Description: Client context id input 1393 * JWT Claim Name: "N/A" 1395 * Claim Key: TBD 1397 * Claim Value Type(s): bstr 1399 * Change Controller: IESG 1401 * Specification Document(s): Section 3.2.2 of [[this document]] 1403 * Claim Name: "client_cred" 1405 * Claim Description: Client Credential 1407 * JWT Claim Name: "N/A" 1409 * Claim Key: TBD 1411 * Claim Value Type(s): map 1413 * Change Controller: IESG 1415 * Specification Document(s): Appendix A.2.2.2 of [[this document]] 1417 10.5. TLS Exporter Label Registry 1419 IANA is asked to add the following entry to the "TLS Exporter Label" 1420 registry defined in Section 6 of [RFC5705] and updated in Section 12 1421 of [RFC8447]. 1423 * Value: EXPORTER-ACE-Sign-Challenge-Client-AS 1425 * DTLS-OK: Y 1427 * Recommended: N 1429 * Reference: [[this document]] (Section 3.1) 1431 11. References 1432 11.1. Normative References 1434 [I-D.ietf-ace-key-groupcomm-oscore] 1435 Tiloca, M., Park, J., and F. Palombini, "Key Management 1436 for OSCORE Groups in ACE", Work in Progress, Internet- 1437 Draft, draft-ietf-ace-key-groupcomm-oscore-12, 25 October 1438 2021, . 1441 [I-D.ietf-ace-oauth-authz] 1442 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1443 H. Tschofenig, "Authentication and Authorization for 1444 Constrained Environments (ACE) using the OAuth 2.0 1445 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 1446 draft-ietf-ace-oauth-authz-45, 29 August 2021, 1447 . 1450 [I-D.ietf-ace-oauth-params] 1451 Seitz, L., "Additional OAuth Parameters for Authorization 1452 in Constrained Environments (ACE)", Work in Progress, 1453 Internet-Draft, draft-ietf-ace-oauth-params-16, 7 1454 September 2021, . 1457 [I-D.ietf-ace-oscore-profile] 1458 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1459 "OSCORE Profile of the Authentication and Authorization 1460 for Constrained Environments Framework", Work in Progress, 1461 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 1462 2021, . 1465 [I-D.ietf-core-groupcomm-bis] 1466 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1467 for the Constrained Application Protocol (CoAP)", Work in 1468 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 1469 05, 25 October 2021, . 1472 [I-D.ietf-core-oscore-groupcomm] 1473 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 1474 and J. Park, "Group OSCORE - Secure Group Communication 1475 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 1476 core-oscore-groupcomm-13, 25 October 2021, 1477 . 1480 [I-D.ietf-cose-rfc8152bis-algs] 1481 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1482 Initial Algorithms", Work in Progress, Internet-Draft, 1483 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 1484 . 1487 [I-D.ietf-cose-rfc8152bis-struct] 1488 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1489 Structures and Process", Work in Progress, Internet-Draft, 1490 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 1491 . 1494 [NIST-800-56A] 1495 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 1496 Davis, "Recommendation for Pair-Wise Key-Establishment 1497 Schemes Using Discrete Logarithm Cryptography - NIST 1498 Special Publication 800-56A, Revision 3", April 2018, 1499 . 1502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1503 Requirement Levels", BCP 14, RFC 2119, 1504 DOI 10.17487/RFC2119, March 1997, 1505 . 1507 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1508 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1509 March 2010, . 1511 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1512 Key Derivation Function (HKDF)", RFC 5869, 1513 DOI 10.17487/RFC5869, May 2010, 1514 . 1516 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1517 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1518 . 1520 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1521 Keranen, A., and P. Hallam-Baker, "Naming Things with 1522 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1523 . 1525 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1526 Application Protocol (CoAP)", RFC 7252, 1527 DOI 10.17487/RFC7252, June 2014, 1528 . 1530 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1531 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1532 2016, . 1534 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1535 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1536 May 2017, . 1538 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1539 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1540 May 2018, . 1542 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1543 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1544 . 1546 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1547 "Object Security for Constrained RESTful Environments 1548 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1549 . 1551 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1552 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1553 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 1554 2020, . 1556 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1557 Representation (CBOR)", STD 94, RFC 8949, 1558 DOI 10.17487/RFC8949, December 2020, 1559 . 1561 11.2. Informative References 1563 [I-D.ietf-ace-dtls-authorize] 1564 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1565 L. Seitz, "Datagram Transport Layer Security (DTLS) 1566 Profile for Authentication and Authorization for 1567 Constrained Environments (ACE)", Work in Progress, 1568 Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June 1569 2021, . 1572 [I-D.ietf-ace-mqtt-tls-profile] 1573 Sengul, C. and A. Kirby, "Message Queuing Telemetry 1574 Transport (MQTT)-TLS profile of Authentication and 1575 Authorization for Constrained Environments (ACE) 1576 Framework", Work in Progress, Internet-Draft, draft-ietf- 1577 ace-mqtt-tls-profile-13, 23 October 2021, 1578 . 1581 [I-D.ietf-cose-cbor-encoded-cert] 1582 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 1583 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 1584 Certificates)", Work in Progress, Internet-Draft, draft- 1585 ietf-cose-cbor-encoded-cert-02, 12 July 2021, 1586 . 1589 [I-D.ietf-rats-uccs] 1590 Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. 1591 Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", 1592 Work in Progress, Internet-Draft, draft-ietf-rats-uccs-01, 1593 12 July 2021, . 1596 [I-D.ietf-tls-dtls13] 1597 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1598 Datagram Transport Layer Security (DTLS) Protocol Version 1599 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1600 dtls13-43, 30 April 2021, . 1603 [I-D.tiloca-core-oscore-discovery] 1604 Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of 1605 OSCORE Groups with the CoRE Resource Directory", Work in 1606 Progress, Internet-Draft, draft-tiloca-core-oscore- 1607 discovery-10, 25 October 2021, 1608 . 1611 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1612 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1613 January 2012, . 1615 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1616 Security (TLS) / Datagram Transport Layer Security (DTLS) 1617 Profiles for the Internet of Things", RFC 7925, 1618 DOI 10.17487/RFC7925, July 2016, 1619 . 1621 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1622 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1623 . 1625 Appendix A. Dual Mode (Group OSCORE & OSCORE) 1627 This appendix defines the dual mode of this profile, which allows 1628 using both OSCORE [RFC8613] and Group OSCORE 1629 [I-D.ietf-core-oscore-groupcomm] as security protocols, by still 1630 relying on a single Access Token. 1632 That is, the dual mode of this profile specifies how a Client uses 1633 CoAP [RFC7252] to communicate to a single Resource Server, or CoAP 1634 over IP multicast [I-D.ietf-core-groupcomm-bis] to communicate to 1635 multiple Resource Servers that are members of a group and share a 1636 common set of resources. 1638 In particular, the dual mode of this profile uses two complementary 1639 security protocols to provide secure communication between the Client 1640 and the Resource Server(s). That is, it defines the use of either 1641 OSCORE or Group OSCORE to protect unicast requests addressed to a 1642 single Resource Server, as well as possible responses. Additionally, 1643 it defines the use of Group OSCORE to protect multicast requests sent 1644 to a group of Resource Servers, as well as possible individual 1645 responses. Like in the main mode of this profile, the Client and the 1646 Resource Servers need to have already joined the same OSCORE group, 1647 for instance by using the approach defined in 1648 [I-D.ietf-ace-key-groupcomm-oscore], which is also based on ACE. 1650 The Client proves its access to be authorized to the Resource Server 1651 by using an Access Token, which is bound to a key (the proof-of- 1652 possession key). This profile mode uses OSCORE to achieve proof of 1653 possession, and OSCORE or Group OSCORE to achieve server 1654 authentication. 1656 Unlike in the main mode of this profile, where a public key is used 1657 as pop-key, this dual mode uses OSCORE-related, symmetric keying 1658 material as pop-key instead. Furthermore, this dual mode provides 1659 proof of Client's membership to the correct OSCORE group, by securely 1660 binding the pre-established Group OSCORE Security Context to the 1661 pairwise OSCORE Security Context newly established between the Client 1662 and the Resource Server. 1664 In addition to the terminology used for the main mode of this 1665 profile, the rest of this appendix refers also to "pairwise OSCORE 1666 Security Context" as to an OSCORE Security Context established 1667 between only one Client and one Resource Server, and used to 1668 communicate with OSCORE [RFC8613]. 1670 A.1. Protocol Overview 1672 This section provides an overview on how to use the ACE framework for 1673 authentication and authorization [I-D.ietf-ace-oauth-authz] to secure 1674 communications between a Client and a (set of) Resource Server(s) 1675 using OSCORE [RFC8613] and/or Group OSCORE 1676 [I-D.ietf-core-oscore-groupcomm]. 1678 Just as for main mode of this profile overviewed in Section 2, the 1679 process for joining the OSCORE group through the respective Group 1680 Manager as defined in [I-D.ietf-ace-key-groupcomm-oscore] must take 1681 place before the process described in the rest of this section, and 1682 is out of the scope of this profile. 1684 An overview of the protocol flow for the dual mode of this profile is 1685 shown in Figure 8. In the figure, it is assumed that both RS1 and 1686 RS2 are associated with the same AS. It is also assumed that C, RS1 1687 and RS2 have previously joined an OSCORE group with Group Identifier 1688 (gid) "abcd0000", and got assigned Sender ID (sid) "0", "1" and "2" 1689 in the group, respectively. The names of messages coincide with 1690 those of [I-D.ietf-ace-oauth-authz] when applicable. 1692 C RS1 RS2 AS 1693 | [--- Resource Request -->] | | | 1694 | | | | 1695 | [<---- AS Request ------] | | | 1696 | Creation Hints | | | 1697 | | | | 1698 |-------- POST /token ----------------------------------------------->| 1699 | (aud: RS1, sid: 0, gid: abcd0000, ...) | | 1700 | | | | 1701 |<-------------------------------- Access Token + RS Information -----| 1702 | | (aud: RS1, sid: 0, gid: abcd0000, ...) | 1703 | | | | 1704 |---- POST /authz-info ----->| | | 1705 | (access_token, N1, ID1) | | | 1706 | | | | 1707 |<-- 2.01 Created (N2, ID2) -| | | 1708 | | | | 1709 /Pairwise /Pairwise | | 1710 Security Context Security Context | | 1711 Derivation/ Derivation/ | | 1712 | | | | 1713 |-------- POST /token ----------------------------------------------->| 1714 | (aud: RS2, sid: 0, gid: abcd0000, ...) | | 1715 | | | | 1716 |<-------------------------------- Access Token + RS Information -----| 1717 | | (aud: RS2, sid: 0, gid: abcd0000, ...) | 1718 | | | | 1719 |---- POST /authz-info ------------------>| | 1720 | (access_token, N1', ID1') | | | 1721 | | | | 1722 |<-- 2.01 Created (N2', ID2')-------------| | 1723 | | | | 1724 /Pairwise Security | /Pairwise Security | 1725 Context Derivation/ | Context Derivation/ | 1726 | | | | 1727 |----- OSCORE Request ------>| | | 1728 | (kid: ID2) | | | 1729 | | | | 1730 | /Proof-of-possession; | | 1731 | Pairwise Security | | 1732 | Context storage/ | | 1733 | | | | 1734 |<---- OSCORE Response ------| | | 1735 | | | | 1736 /Proof-of-possession; | | | 1737 Pairwise Security | | | 1738 Context storage/ | | | 1739 | | | | 1740 /Mutual authentication | | | 1741 between C and RS1 | | | 1742 (as OSCORE peers)/ | | | 1743 | | | | 1744 | | | | 1745 |- Group OSCORE Request -+-->| | | 1746 | (kid: 0, gid: abcd0000) \-------------->| | 1747 | | | | 1748 |<-- Group OSCORE Response --| | | 1749 | (kid: 1) | | | 1750 | | | | 1751 /Mutual authentication | | | 1752 between C and RS1 | | | 1753 (as group members)/ | | | 1754 | | | | 1755 |<-- Group OSCORE Response ---------------| | 1756 | (kid: 2) | | | 1757 | | | | 1758 /Mutual authentication | | | 1759 between C and RS2 | | | 1760 (as group members)/ | | | 1761 | | | | 1762 | ... | | | 1764 Figure 8: Protocol Overview. 1766 A.1.1. Pre-Conditions 1768 The same pre-conditions for the main mode of this profile (see 1769 Section 2.1) hold for the dual mode described in this appendix. 1771 A.1.2. Access Token Posting 1773 After having retrieved the Access Token from the AS, the Client 1774 generates a nonce N1 and an identifier ID1 unique in the sets of its 1775 own Recipient IDs from its pairwise OSCORE Security Contexts. The 1776 client then posts both the Access Token, N1 and its chosen ID to the 1777 RS, using the /authz-info endpoint and mechanisms specified in 1778 Section 5.10 of [I-D.ietf-ace-oauth-authz] and Content-Format = 1779 application/ace+cbor. 1781 When using the dual mode of this profile, the communication with the 1782 authz-info endpoint is not protected, except for update of access 1783 rights. Note that, when using the dual mode, this request can 1784 alternatively be protected with Group OSCORE, using the Group OSCORE 1785 Security Context paired with the pairwise OSCORE Security Context 1786 originally established with the first Access Token posting. 1788 If the Access Token is valid, the RS replies to this POST request 1789 with a 2.01 (Created) response with Content-Format = application/ 1790 ace+cbor, which in a CBOR map contains a nonce N2 and an identifier 1791 ID2 unique in the sets of its own Recipient IDs from its pairwise 1792 OSCORE Security Contexts. 1794 A.1.3. Setup of the Pairwise OSCORE Security Context 1796 After sending the 2.01 (Created) response, the RS sets the ID Context 1797 of the pairwise OSCORE Security Context (see Section 3 of [RFC8613]) 1798 to the Group Identifier of the OSCORE group specified in the Access 1799 Token, concatenated with N1, concatenated with N2, concatenated with 1800 the value in the contextId parameter of the OSCORE_Input_Material 1801 provided in the 'cnf' claim of the Access Token. 1803 Then, the RS derives the complete pairwise OSCORE Security Context 1804 associated with the received Access Token, following Section 3.2 of 1805 [RFC8613]. In practice, the RS maintains a collection of Security 1806 Contexts with associated authorization information, for all the 1807 clients that it is currently communicating with, and the 1808 authorization information is a policy used as input when processing 1809 requests from those clients. 1811 During the derivation process, the RS uses: the ID Context above; the 1812 exchanged nonces N1 and N2; the identifier ID1 received from the 1813 Client, set as its own OSCORE Sender ID; the identifier ID2 provided 1814 to the Client, set as its Recipient ID for the Client; and the 1815 parameters in the Access Token. The derivation process uses also the 1816 Master Secret of the OSCORE group, that the RS knows as a group 1817 member, as well as the Sender ID of the Client in the OSCORE group, 1818 which is specified in the Access Token. This ensures that the 1819 pairwise OSCORE Security Context is securely bound to the Group 1820 OSCORE Security Context of the OSCORE group. 1822 Finally, the RS stores the association between i) the authorization 1823 information from the Access Token; and ii) the Group Identifier of 1824 the OSCORE group together with the Sender ID and the public key of 1825 the Client in that group. 1827 After having received the nonce N2, the Client sets the ID Context in 1828 its pairwise OSCORE Security Context (see Section 3 of [RFC8613]) to 1829 the Group Identifier of the OSCORE group, concatenated with N1, 1830 concatenated with N2, concatenated with the value in the contextId 1831 parameter of the OSCORE_Input_Material provided in the 'cnf' 1832 parameter of the Access Token response from the AS. Then, the Client 1833 derives the complete pairwise OSCORE Security Context, following 1834 Section 3.2 of [RFC8613]. 1836 During the derivation process, the Client uses: the ID Context above, 1837 the exchanged nonces N1 and N2; the identifier ID1 provided to the 1838 RS, set as its own Recipient ID for the RS; the identifier ID2 1839 received from the RS, set as its own OSCORE Sender ID; and the 1840 parameters received from the AS. The derivation process uses also 1841 the Master Secret of the OSCORE group, that the Client knows as a 1842 group member, as well as its own Sender ID in the OSCORE group. 1844 When the Client communicates with the RS using the pairwise OSCORE 1845 Security Context, the RS achieves proof-of-possession of the 1846 credentials bound to the Access Token. Also, the RS verifies that 1847 the Client is a legitimate member of the OSCORE group. 1849 A.1.4. Secure Communication 1851 Other than starting the communication with the RS using Group OSCORE 1852 as described in Section 4.3, the Client can send to the RS a request 1853 protected with OSCORE, using the pairwise OSCORE Security Context. 1855 If the request is successfully verified, then the RS stores the 1856 pairwise OSCORE Security Context, and uses it to protect the possible 1857 response, as well as further communications with the Client, until 1858 the Access Token is deleted, due to, for example, expiration. This 1859 pairwise OSCORE Security Context is discarded when an Access Token 1860 (whether the same or different) is used to successfully derive a new 1861 pairwise OSCORE Security Context. 1863 As discussed in Section 7 of [I-D.ietf-ace-oscore-profile], the use 1864 of random nonces N1 and N2 during the exchange between the Client and 1865 the RS prevents the reuse of an Authenticated Encryption with 1866 Associated Data (AEAD) nonce/key pair for two different messages. 1867 Reuse might otherwise occur when Client and RS derive a new pairwise 1868 OSCORE Security Context from an existing (non-expired) Access Token, 1869 e.g., in case of reboot of either the Client or the RS, and might 1870 lead to loss of both confidentiality and integrity. 1872 Additionally, just as per the main mode of this profile (see 1873 Section 4.3), the Client and RS can also securely communicate by 1874 protecting messages with Group OSCORE, using the Group OSCORE 1875 Security Context already established upon joining the OSCORE group. 1877 A.2. Client-AS Communication 1879 This section details the Access Token POST Request that the Client 1880 sends to the /token endpoint of the AS, as well as the related Access 1881 Token response. 1883 Section 3.2 of [RFC8613] defines how to derive a pairwise OSCORE 1884 Security Context based on a shared Master Secret and a set of other 1885 parameters, established between the OSCORE client and server, which 1886 the client receives from the AS in this exchange. 1888 The proof-of-possession key (pop-key) received from the AS in this 1889 exchange MUST be used to build the Master Secret in OSCORE (see 1890 Appendix A.3.3 and Appendix A.3.4). 1892 A.2.1. C-to-AS: POST to Token Endpoint 1894 The Client-to-AS request is specified in Section 5.8.1 of 1895 [I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request 1896 to the /token endpoint over a secure channel that guarantees 1897 authentication, message integrity and confidentiality. 1899 The POST request is formatted as the analogous Client-to-AS request 1900 in the main mode of this profile (see Section 3.1), with the 1901 following modifications. 1903 * The parameter 'req_cnf' MUST NOT be included in the payload. 1905 * The parameter 'client_cred', defined in Appendix A.2.1.1 of this 1906 document, MUST be included in the payload. This parameter 1907 specifies the public key that the Client uses in the OSCORE group, 1908 whose identifier is indicated in the 'context_id' parameter. In 1909 particular, the specified public key is the COSE Key equivalent to 1910 the full-fledged public key that the Client uses in the OSCORE 1911 group. 1913 * The proof-of-possession (PoP) evidence included in the 1914 'client_cred_verify' or 'client_cred_verify_mac' parameter is 1915 computed by using the Client's private key associated to the 1916 public key in the 'client_cred' parameter above. 1918 An example of such a request is shown in Figure 9. 1920 Header: POST (Code=0.02) 1921 Uri-Host: "as.example.com" 1922 Uri-Path: "token" 1923 Content-Format: "application/ace+cbor" 1924 Payload: 1925 { 1926 "audience" : "tempSensor4711", 1927 "scope" : "read", 1928 "context_id" : h'abcd0000', 1929 "salt_input" : h'00', 1930 "client_cred" : { 1931 "COSE_Key" : { 1932 "kty" : EC2, 1933 "crv" : P-256, 1934 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 1935 27c9e354089bbe13', 1936 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 1937 731e79a3b4e47120' 1938 } 1939 }, 1940 "client_cred_verify" : h'...' 1941 (signature content omitted for brevity), 1942 } 1944 Figure 9: Example C-to-AS POST /token request for an Access Token 1945 bound to a symmetric key. 1947 Later on, the Client may want to update its current access rights, 1948 without changing the existing pairwise OSCORE Security Context with 1949 the RS. In this case, the Client MUST include in its POST request to 1950 the /token endpoint a 'req_cnf' parameter, defined in Section 3.1 of 1951 [I-D.ietf-ace-oauth-params], which MUST include a 'kid' field, as 1952 defined in Section 3.1 of [RFC8747]. The 'kid' field has as value a 1953 CBOR byte string containing the OSCORE_Input_Material Identifier 1954 (assigned as discussed in Appendix A.2.2). 1956 This identifier, together with other information such as audience, 1957 can be used by the AS to determine the shared secret bound to the 1958 proof-of-possession Access Token and therefore MUST identify a 1959 symmetric key that was previously generated by the AS as a shared 1960 secret for the communication between the Client and the RS. The AS 1961 MUST verify that the received value identifies a proof-of-possession 1962 key that has previously been issued to the requesting Client. If 1963 that is not the case, the Client-to-AS request MUST be declined with 1964 the error code "invalid_request" as defined in Section 5.8.3 of 1965 [I-D.ietf-ace-oauth-authz]. 1967 This POST request for updating the access rights of an Access Token 1968 SHOULD NOT include the parameters 'salt_input', 'context_id', 1969 'client_cred' and 'client_cred_verify'. An exception is the case 1970 defined in Appendix A.3.6, where the Client, following a change of 1971 public key in the OSCORE group, requests a new Access Token 1972 associated to the new public key, while still without changing the 1973 existing pairwise OSCORE Security Context with the RS. 1975 An example of such a request is shown in Figure 10. 1977 Header: POST (Code=0.02) 1978 Uri-Host: "as.example.com" 1979 Uri-Path: "token" 1980 Content-Format: "application/ace+cbor" 1981 Payload: 1982 { 1983 "audience" : "tempSensor4711", 1984 "scope" : "read", 1985 "req_cnf" : { 1986 "kid" : h'01' 1987 } 1988 } 1990 Figure 10: Example C-to-AS POST /token request for updating 1991 rights to an Access Token bound to a symmetric key. 1993 A.2.1.1. 'client_cred' Parameter 1995 The 'client_cred' parameter is an OPTIONAL parameter of the Access 1996 Token request message defined in Section 5.8.1. of 1997 [I-D.ietf-ace-oauth-authz]. This parameter provides an asymmetric 1998 key that the Client wishes to use as its own public key, but which is 1999 not used as proof-of-possession key. 2001 This parameter follows the syntax of the 'cnf' claim from Section 3.1 2002 of [RFC8747] when including Value Type "COSE_Key" (1) and specifying 2003 an asymmetric key. Alternative Value Types defined in future 2004 specifications are fine to consider if indicating a non-encrypted 2005 asymmetric key. 2007 A.2.2. AS-to-C: Access Token 2009 After having verified the POST request to the /token endpoint and 2010 that the Client is authorized to obtain an Access Token corresponding 2011 to its Access Token request, the AS MUST verify the proof-of- 2012 possession (PoP) evidence. 2014 In particular, the AS proceeds as defined in Section 3.2, with the 2015 difference that it uses the public key specified in the 'client_cred' 2016 parameter as public key of the Client. 2018 If both the 'client_cred_verify' and 'client_cred_verify_mac' 2019 parameters are present, or if the verification of the PoP evidence 2020 fails, the AS considers the Client request invalid. The AS does not 2021 perform this operation when asked to update a previously released 2022 Access Token. 2024 If all verifications are successful, the AS responds as defined in 2025 Section 5.8.2 of [I-D.ietf-ace-oauth-authz]. If the Client request 2026 was invalid, or not authorized, the AS returns an error response as 2027 described in Section 5.8.3 of [I-D.ietf-ace-oauth-authz]. 2029 The AS can signal that the use of OSCORE and Group OSCORE is REQUIRED 2030 for a specific Access Token by including the "ace_profile" parameter 2031 with the value "coap_group_oscore" in the Access Token response. 2032 This means that the Client MUST use OSCORE and/or Group OSCORE 2033 towards all the Resource Servers for which this Access Token is 2034 valid. 2036 In particular, the Client MUST follow Appendix A.3.3 to derive the 2037 pairwise OSCORE Security Context to use for communications with the 2038 RS. Instead, the Client has already established the related Group 2039 OSCORE Security Context to communicate with members of the OSCORE 2040 group, upon previously joining that group. 2042 Usually, it is assumed that constrained devices will be pre- 2043 configured with the necessary profile, so that this kind of profile 2044 signaling can be omitted. 2046 In contrast with the main mode of this profile, the Access Token 2047 response to the Client is analogous to the one in the OSCORE profile 2048 of ACE, as described in Section 3.2 of [I-D.ietf-ace-oscore-profile]. 2049 In particular, the AS provides an OSCORE_Input_Material object, which 2050 is defined in Section 3.2.1 of [I-D.ietf-ace-oscore-profile] and 2051 included in the 'cnf' parameter (see Section 3.2 of 2052 [I-D.ietf-ace-oauth-params]) of the Access Token response. 2054 The AS MUST send different OSCORE_Input_Material (and therefore 2055 different Access Tokens) to different authorized clients, in order 2056 for the RS to differentiate between clients. 2058 In the issued Access Token, the AS MUST include as metadata the same 2059 information as defined in the main mode of this profile (see 2060 Section 3.2) with the following modifications. 2062 * The public key that the client uses in the OSCORE group and 2063 specified in the 'client_cred' parameter of the Token request (see 2064 Appendix A.2.1) MUST also be included in the Access Token. 2066 If the Access Token is a CWT, the AS MUST include it in the 2067 'client_cred' claim of the Access Token, defined in 2068 Appendix A.2.2.2 of this document. In particular, the 2069 'client_cred' claim includes the same COSE Key specified in the 2070 'client_cred' parameter of the Token Request, i.e., the COSE Key 2071 equivalent to the full-fledged public key that the Client uses in 2072 the OSCORE group. 2074 * The OSCORE_Input_Material specified in the 'cnf' parameter of the 2075 Access Token response MUST also be included in the Access Token. 2076 If the Access Token is a CWT, the same OSCORE_Input_Material 2077 included in the 'cnf' parameter of the Access Token response MUST 2078 be included in the 'osc' field of the 'cnf' claim of the Access 2079 Token (see Section 3.2 of [I-D.ietf-ace-oscore-profile]). 2081 Figure 11 shows an example of such an AS response. The access token 2082 has been truncated for readability. 2084 Header: Created (Code=2.01) 2085 Content-Type: "application/ace+cbor" 2086 Payload: 2087 { 2088 "access_token" : h'8343a1010aa2044c53 ...' 2089 (remainder of CWT omitted for brevity), 2090 "ace_profile" : "coap_group_oscore", 2091 "expires_in" : 3600, 2092 "cnf" : { 2093 "osc" : { 2094 "alg" : AES-CCM-16-64-128, 2095 "id" : h'01', 2096 "ms" : h'f9af838368e353e78888e1426bd94e6f', 2097 "salt" : h'1122', 2098 "contextId" : h'99' 2099 } 2100 } 2101 } 2103 Figure 11: Example AS-to-C Access Token response with the Group 2104 OSCORE profile. 2106 Figure 12 shows an example CWT, containing the necessary OSCORE 2107 parameters in the 'cnf' claim. 2109 { 2110 "aud" : "tempSensorInLivingRoom", 2111 "iat" : 1360189224, 2112 "exp" : 1360289224, 2113 "scope" : "temperature_g firmware_p", 2114 "cnf" : { 2115 "osc" : { 2116 "alg" : AES-CCM-16-64-128, 2117 "id" : h'01', 2118 "ms" : h'f9af838368e353e78888e1426bd94e6f', 2119 "salt" : h'1122', 2120 "contextId" : h'99' 2121 }, 2122 "salt_input" : h'00', 2123 "contextId_input" : h'abcd0000', 2124 "client_cred" : { 2125 "COSE_Key" : { 2126 "kty" : EC2, 2127 "crv" : P-256, 2128 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 2129 27c9e354089bbe13', 2130 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 2131 731e79a3b4e47120' 2132 } 2133 } 2134 } 2136 Figure 12: Example CWT with OSCORE parameters. 2138 The same CWT as in Figure 12 and encoded in CBOR is shown in 2139 Figure 13, using the value abbreviations defined in 2140 [I-D.ietf-ace-oauth-authz] and [RFC8747]. 2142 NOTE: it should be checked (and in case fixed) that the values used 2143 below (which are not yet registered) are the final values registered 2144 in IANA. 2146 A8 # map(8) 2147 03 # unsigned(3) 2148 76 # text(22) 2149 74656D7053656E736F72496E4C6976696E67526F6F6D 2150 06 # unsigned(6) 2151 1A 5112D728 # unsigned(1360189224) 2152 04 # unsigned(4) 2153 1A 51145DC8 # unsigned(1360289224) 2154 09 # unsigned(9) 2155 78 18 # text(24) 2156 74656D70657261747572655F67206669726D776172655F70 2158 08 # unsigned(8) 2159 A1 # map(1) 2160 04 # unsigned(4) 2161 A5 # map(5) 2162 04 # unsigned(4) 2163 0A # unsigned(10) 2164 00 # unsigned(0) 2165 41 # bytes(1) 2166 01 # "\x01" 2167 02 # unsigned(2) 2168 50 # bytes(16) 2169 F9AF838368E353E78888E1426BD94E6F 2170 05 # unsigned(5) 2171 42 # bytes(2) 2172 1122 # "\x11\"" 2173 06 # unsigned(6) 2174 41 # bytes(1) 2175 99 # "\x99" 2176 18 3C # unsigned(60) 2177 41 # bytes(1) 2178 00 2179 18 3D # unsigned(61) 2180 44 # bytes(4) 2181 ABCD0000 2182 18 3E # unsigned(62) 2183 A1 # map(1) 2184 01 # unsigned(1) 2185 A4 # map(4) 2186 01 # unsigned(1) 2187 02 # unsigned(2) 2188 20 # negative(0) 2189 01 # unsigned(1) 2190 21 # negative(1) 2191 58 20 # bytes(32) 2192 D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9 2193 E354089BBE13 2194 22 # negative(2) 2195 58 20 # bytes(32) 2196 F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E515D020731E 2197 79A3B4E47120 2199 Figure 13: Example CWT with OSCORE parameters. 2201 If the Client has requested an update to its access rights using the 2202 same pairwise OSCORE Security Context, which is valid and authorized, 2203 the AS MUST omit the 'cnf' parameter in the response to the client. 2205 Instead, the updated Access Token conveyed in the AS-to-C response 2206 MUST include a 'cnf' claim specifying a 'kid' field, as defined in 2207 Section 3.1 of [RFC8747]. The response from the AS MUST carry the 2208 OSCORE Input Material identifier in the 'kid' field within the 'cnf' 2209 claim of the Access Token. That is, the 'kid' field is a CBOR byte 2210 string, with value the same value of the 'kid' field of the 'req_cnf' 2211 parameter from the C-to-AS request for updating rights to the Access 2212 Token (see Figure 10). This information needs to be included in the 2213 Access Token, in order for the RS to identify the previously 2214 generated pairwise OSCORE Security Context. 2216 Figure 14 shows an example of such an AS response. The Access Token 2217 has been truncated for readability. 2219 Header: Created (Code=2.01) 2220 Content-Type: "application/ace+cbor" 2221 Payload: 2222 { 2223 "access_token" : h'8343a1010aa2044c53 ...' 2224 (remainder of CWT omitted for brevity), 2225 "profile" : "coap_group_oscore", 2226 "expires_in" : 3600 2227 } 2229 Figure 14: Example AS-to-C Access Token response with the Group 2230 OSCORE profile, for update of access rights. 2232 Figure 15 shows an example CWT, containing the necessary OSCORE 2233 parameters in the 'cnf' claim for update of access rights. 2235 { 2236 "aud" : "tempSensorInLivingRoom", 2237 "iat" : 1360189224, 2238 "exp" : 1360289224, 2239 "scope" : "temperature_h", 2240 "cnf" : { 2241 "kid" : h'01' 2242 } 2243 } 2245 Figure 15: Example CWT with OSCORE parameters for update of 2246 access rights. 2248 A.2.2.1. Public Key Hash as Client Credential 2250 As a possible optimization to limit the size of the Access Token, the 2251 AS may specify as value of the 'client_cred' claim simply the hash of 2252 the Client's public key, i.e., the hash of the COSE Key K equivalent 2253 to the full-fledged public key that the Client uses in the OSCORE 2254 group. 2256 The specifically used hash-function MUST be collision-resistant on 2257 byte-strings, and MUST be selected from the "Named Information Hash 2258 Algorithm" Registry defined in Section 9.4 of [RFC6920]. 2260 In particular, the AS provides the Client with an Access Token as 2261 defined in Appendix A.2.2, with the following differences. 2263 The AS prepares INPUT_HASH as follows, with | denoting byte string 2264 concatenation. 2266 * If the equivalent COSE Key K has COSE Key Type OKP, INPUT_HASH = 2267 i, where 'i' is the x-parameter of the COSE_Key specified in the 2268 'client_cred' parameter of the Token request, encoded as a CBOR 2269 byte string. 2271 * If the equivalent COSE Key K has COSE Key Type EC2, INPUT_HASH = 2272 (i_1 | i_2), where 'i_1' and 'i_2' are the x-parameter and 2273 y-parameter of the COSE_Key specified in the 'client_cred' 2274 parameter of the Token request, respectively, each encoded as a 2275 CBOR byte string. 2277 * If the equivalent COSE Key K has COSE Key Type RSA, INPUT_HASH = 2278 (i_1 | i_2), where 'i_1' and 'i_2' are the n-parameter and 2279 e-parameter of the COSE_Key specified in the 'client_cred' 2280 parameter of the Token request, respectively, each encoded as a 2281 CBOR byte string. 2283 Then, the AS hashes INPUT_HASH according to the procedure described 2284 in [RFC6920], with the output OUTPUT_HASH in binary format, as 2285 described in Section 6 of [RFC6920]. 2287 Finally, the AS includes a single entry within the 'client_cred' 2288 claim of the Access Token. This entry has label "kid" (3) defined in 2289 Section 3.1 of [RFC8747], and value a CBOR byte string wrapping 2290 OUTPUT_HASH. 2292 Upon receiving the Access Token, the RS processes it according to 2293 Appendix A.3.2, with the following differences. 2295 Then, the RS considers: the content of the 'contextId_input' claim as 2296 the GID of the OSCORE group; the content of the 'salt_input' claim as 2297 the Sender ID that the Client has in the group; and the content of 2298 the 'client_cred' claim as the hash RECEIVED_HASH of a COSE Key 2299 equivalent to the full-fledged public key that the Client uses in the 2300 group. 2302 The RS MUST check whether it already stores a public key associated 2303 to the pair (GID, Sender ID) above, such that the recomputed hash 2304 NEW_HASH of its equivalent COSE Key matches with RECEIVED_HASH from 2305 the 'client_cred' claim. 2307 If this is not the case, the RS MUST request the Client's public key 2308 to the Group Manager of the OSCORE group as described in Section 10 2309 of [I-D.ietf-ace-key-groupcomm-oscore], specifying the Client's 2310 Sender ID in the OSCORE group, i.e., the value of the 'salt_input' 2311 claim. Then, the RS performs the following actions. 2313 * The RS MUST check whether RECEIVED_HASH matches with the 2314 recomputed hash NEW_HASH of a COSE Key equivalent to the Client's 2315 public key retrieved from the Group Manager. 2317 * The RS MUST check that the Client's Sender ID provided by the 2318 Group Manager together with the Client's public key matches the 2319 one retrieved from the 'salt_input' claim of the Access Token. 2321 The RS MUST calculate NEW_HASH using the same method used by the AS 2322 described above, and using the same hash function. The hash function 2323 to use can be determined from the information conveyed in the 2324 'client_cred' claim, as the procedure described in [RFC6920] also 2325 encodes the used hash function as metadata of the hash value. 2327 A.2.2.2. Client Credential Claim 2329 The 'client_cred' claim provides an asymmetric key that the Client 2330 owning the Access Token wishes to use as its own public key, but 2331 which is not used as proof-of-possession key. 2333 This parameter follows the syntax of the 'cnf' claim from Section 3.1 2334 of [RFC8747] when including Value Type "COSE_Key" (1) and specifying 2335 an asymmetric key. Alternative Value Types defined in future 2336 specifications are fine to consider if indicating a non-encrypted 2337 asymmetric key. 2339 A.3. Client-RS Communication 2341 This section details the POST request and response to the /authz-info 2342 endpoint between the Client and the RS. With respect to the 2343 exchanged messages and their content, the Client and the RS perform 2344 as defined in the OSCORE profile of ACE (see Section 4 of 2345 [I-D.ietf-ace-oscore-profile]). 2347 That is, the Client generates a nonce N1 and posts it to the RS, 2348 together with: an identifier ID1 unique in the sets of its own 2349 Recipient IDs from its pairwise OSCORE Security Contexts; and the 2350 Access Token that includes the material provisioned by the AS. 2352 Then, the RS generates a nonce N2, and an identifier ID2 unique in 2353 the sets of its own Recipient IDs from its pairwise OSCORE Security 2354 Contexts. After that, the RS derives a pairwise OSCORE Security 2355 Context as described in Section 3.2 of [RFC8613]. In particular, it 2356 uses the two exchanged nonces and the two identifiers established 2357 with the Client, as well as two shared secrets together with 2358 additional pieces of information specified in the Access Token. 2360 Both the client and the RS generate the pairwise OSCORE Security 2361 Context using the pop-key as part of the OSCORE Master Secret. In 2362 addition, the derivation of the pairwise OSCORE Security Context 2363 takes as input also information related to the OSCORE group, i.e., 2364 the Master Secret and Group Identifier of the group, as well as the 2365 Sender ID of the Client in the group. Hence, the derived pairwise 2366 OSCORE Security Context is also securely bound to the Group OSCORE 2367 Security Context of the OSCORE Group. Thus, the proof-of-possession 2368 required to bind the Access Token to the Client occurs after the 2369 first OSCORE message exchange. 2371 Therefore, an attacker using a stolen Access Token cannot generate a 2372 valid pairwise OSCORE Security Context and thus cannot prove 2373 possession of the pop-key. Also, if a Client legitimately owns an 2374 Access Token but has not joined the OSCORE group, that Client cannot 2375 generate a valid pairwise OSCORE Security Context either, since it 2376 lacks the Master Secret used in the OSCORE group. 2378 Besides, just as in the main mode (see Section 4), the RS is able to 2379 verify whether the Client has indeed the claimed Sender ID and public 2380 key in the OSCORE group. 2382 A.3.1. C-to-RS POST to authz-info Endpoint 2384 The Client MUST generate a nonce N1, an OSCORE Recipient ID (ID1), 2385 and post them to the /authz-info endpoint of the RS together with the 2386 Access Token, as defined in the OSCORE profile of ACE (see 2387 Section 4.1 of [I-D.ietf-ace-oscore-profile]). 2389 The same recommendations, considerations and behaviors defined in 2390 Section 4.1 of [I-D.ietf-ace-oscore-profile] hold. 2392 If the Client has already posted a valid Access Token, has already 2393 established a pairwise OSCORE Security Context with the RS, and wants 2394 to update its access rights, the Client can do so by posting the new 2395 Access Token (retrieved from the AS and specifying the updated set of 2396 access rights) to the /authz-info endpoint. 2398 The Client MUST protect the request using either the pairwise OSCORE 2399 Security Context established during the first Access Token exchange, 2400 or the Group OSCORE Security Context associated to that pairwise 2401 OSCORE Security Context. 2403 In either case, the Client MUST only send the Access Token in the 2404 payload, i.e., no nonce or identifier are sent. After proper 2405 verification (see Section 4.2 of [I-D.ietf-ace-oscore-profile]), the 2406 new Access Token will supersede the old one at the RS, by replacing 2407 the corresponding authorization information. At the same time, the 2408 RS will maintain the same pairwise OSCORE Security Context and Group 2409 OSCORE Security Context, as now both associated to the new Access 2410 Token. 2412 A.3.2. RS-to-C: 2.01 (Created) 2414 The RS MUST verify the validity of the Access Token as defined in 2415 Section 4.2, with the following modifications. 2417 * If the POST request to /authz-info is not protected, the RS checks 2418 that the 'cnf' claim is included in the Access Token and that it 2419 contains an OSCORE_Input_Material object. Also, the RS checks 2420 that the 'salt_input', 'client_cred' and 'contextId_input' claims 2421 are included in the Access Token. 2423 * If the POST request to /authz-info is protected with the pairwise 2424 OSCORE Security Context shared with the Client or with the Group 2425 OSCORE Security Context of the OSCORE group, i.e., the Client is 2426 requesting an update of access rights, the RS checks that the 2427 'cnf' claim is included in the Access Token and that it contains 2428 only the 'kid' field. 2430 * If the 'salt_input', 'client_cred' and 'contextId_input' claims 2431 are included in the Access Token, the RS extracts the content of 2432 'client_cred'. Then, the RS considers that content as the COSE 2433 Key equivalent to the full-fledged public key that the Client uses 2434 in the group, whose GID is specified in the 'contextId_input' 2435 claim. The RS can compare this public key with the public key of 2436 the claimed Client retrieved from its local storage or from the 2437 Group Manager (see Section 4.2). 2439 If any of the checks fails, the RS MUST consider the Access Token non 2440 valid, and MUST respond to the Client with an error response code 2441 equivalent to the CoAP code 4.00 (Bad Request). 2443 If the Access Token is valid and further checks on its content are 2444 successful, the RS proceeds as follows. 2446 In case the POST request to /authz-info was not protected, the RS 2447 MUST generate a nonce N2, an OSCORE Recipient ID (ID2), and include 2448 them in the 2.01 (Created) response to the Client, as defined in the 2449 OSCORE profile of ACE (see Section 4.2 of 2450 [I-D.ietf-ace-oscore-profile]). 2452 Instead, in case the POST request to /authz-info was protected, the 2453 RS MUST ignore any nonce and identifiers in the request, if any was 2454 sent. Then, the RS MUST check that the 'kid' field of the 'cnf' 2455 claim in the new Access Token matches the identifier of the OSCORE 2456 Input Material of a pairwise OSCORE Security Context such that: 2458 * The pairwise OSCORE Security Context was used to protect the 2459 request, if this was protected with OSCORE; or 2461 * The pairwise OSCORE Security Context is bound to the Group OSCORE 2462 Security Context used to protect the request, if this was 2463 protected with Group OSCORE. 2465 If either verification is successful, the new Access Token supersedes 2466 the old one at the RS. Besides, the RS associates the new Access 2467 Token to the same pairwise OSCORE Security Context identified above, 2468 as also bound to a Group OSCORE Security Context. The RS MUST 2469 respond with a 2.01 (Created) response with no payload, protected 2470 with the same Security Context used to protect the request. In 2471 particular, no new pairwise OSCORE Security Context is established 2472 between the Client and the RS. If any verification fails, the RS 2473 MUST respond with a 4.01 (Unauthorized) error response. 2475 Further recommendations, considerations and behaviors defined in 2476 Section 4.2 of [I-D.ietf-ace-oscore-profile] hold for this document. 2478 A.3.3. OSCORE Setup - Client Side 2480 Once having received the 2.01 (Created) response from the RS, 2481 following an unprotected POST request to the /authz-info endpoint, 2482 the Client MUST extract the nonce N2 from the 'nonce2' parameter, and 2483 the Client identifier from the 'ace_server_recipientid' parameter in 2484 the CBOR map of the response payload. Note that this identifier is 2485 used by C as Sender ID in the pairwise OSCORE Security Context to be 2486 established with the RS, and is different as well as unrelated to the 2487 Sender ID of C in the OSCORE group. 2489 Then, the Client performs the following actions, in order to set up 2490 and fully derive the pairwise OSCORE Security Context for 2491 communicating with the RS. 2493 * The Client MUST set the ID Context of the pairwise OSCORE Security 2494 Context as the concatenation of: i) GID, i.e., the Group 2495 Identifier of the OSCORE group, as specified by the Client in the 2496 'context_id' parameter of the Client-to-AS request; ii) the nonce 2497 N1; iii) the nonce N2; and iv) CID, i.e., the value in the 2498 contextId parameter of the OSCORE_Input_Material provided in the 2499 'cnf' parameter of the Access Token response from the AS. The 2500 concatenation occurs in this order: ID Context = GID | N1 | N2 | 2501 CID, where | denotes byte string concatenation. 2503 * The Client MUST set the updated Master Salt of the pairwise OSCORE 2504 Security Context as the concatenation of SaltInput, MSalt, the 2505 nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the 2506 Sender ID that the Client has in the OSCORE group, which is known 2507 to the Client as a member of the OSCORE group; ii) MSalt is the 2508 (optional) Master Salt in the pairwise OSCORE Security Context 2509 (received from the AS in the Token); and iii) GMSalt is the 2510 (optional) Master Salt in the Group OSCORE Security Context, which 2511 is known to the Client as a member of the OSCORE group. The 2512 concatenation occurs in this order: Master Salt = SaltInput | 2513 MSalt | N1 | N2 | GMSalt, where | denotes byte string 2514 concatenation. Optional values, if not specified, are not 2515 included in the concatenation. The five parameters SaltInput, 2516 MSalt, N1, N2 and GMSalt are to be concatenated as encoded CBOR 2517 byte strings. An example of Master Salt construction using CBOR 2518 encoding is given in Figure 16. 2520 SaltInput, MSalt, N1, N2 and GMSalt, in CBOR diagnostic notation: 2521 SaltInput = h'00' 2522 MSalt = h'f9af838368e353e78888e1426bd94e6f' 2523 N1 = h'018a278f7faab55a' 2524 N2 = h'25a8991cd700ac01' 2525 GMSalt = h'99' 2527 SaltInput, MSalt, N1, N2 and GMSalt, as CBOR encoded byte strings: 2528 SaltInput = 0x4100 2529 MSalt = 0x50f9af838368e353e78888e1426bd94e6f 2530 N1 = 0x48018a278f7faab55a 2531 N2 = 0x4825a8991cd700ac01 2532 GMSalt = 0x4199 2534 Master Salt = 0x41 00 2535 50 f9af838368e353e78888e1426bd94e6f 2536 48 018a278f7faab55a 2537 48 25a8991cd700ac01 2538 41 99 2540 Figure 16: Example of Master Salt construction using CBOR encoding. 2542 * The Client MUST set the Master Secret of the pairwise OSCORE 2543 Security Context to the concatenation of MSec and GMSec, where: i) 2544 MSec is the value of the 'ms' parameter in the 2545 OSCORE_Input_Material of the 'cnf' parameter, received from the AS 2546 in Appendix A.2.2; while ii) GMSec is the Master Secret of the 2547 Group OSCORE Security Context, which is known to the Client as a 2548 member of the OSCORE group. 2550 * The Client MUST set the Recipient ID as ace_client_recipientid, 2551 sent as described in Appendix A.3.1. 2553 * The Client MUST set the Sender ID as ace_server_recipientid, 2554 received as described in Appendix A.3.1. 2556 * The Client MUST set the AEAD Algorithm, ID Context, HKDF, and 2557 OSCORE Version as indicated in the corresponding parameters 2558 received from the AS in Appendix A.2.2, if present in the 2559 OSCORE_Input_Material of the 'cnf' parameter. In case these 2560 parameters are omitted, the default values SHALL be used as 2561 described in Sections 3.2 and 5.4 of [RFC8613]. 2563 Finally, the client MUST derive the complete pairwise OSCORE Security 2564 Context following Section 3.2.1 of [RFC8613]. 2566 From then on, when communicating with the RS to access the resources 2567 as specified by the authorization information, the Client MUST use 2568 the newly established pairwise OSCORE Security Context or the Group 2569 OSCORE Security Context of the OSCORE Group where both the Client and 2570 the RS are members. 2572 If any of the expected parameters is missing (e.g., any of the 2573 mandatory parameters from the AS or the RS), or if 2574 ace_client_recipientid equals ace_server_recipientid (and as a 2575 consequence the Sender and Recipient Keys derived would be equal, see 2576 Section 3.3 of [RFC8613]), then the client MUST stop the exchange, 2577 and MUST NOT derive the pairwise OSCORE Security Context. The Client 2578 MAY restart the exchange, to get the correct security input material. 2580 The Client can use this pairwise OSCORE Security Context to send 2581 requests to the RS protected with OSCORE. Besides, the Client can 2582 use the Group OSCORE Security Context for protecting unicast requests 2583 to the RS, or multicast requests to the OSCORE group including also 2584 the RS. Mutual authentication as group members is only achieved 2585 after the client has successfully verified the Group OSCORE protected 2586 response from the RS. Similarly, mutual authentication as OSCORE 2587 peers is only achieved after the client has successfully verified the 2588 OSCORE protected response from the RS, using the pairwise OSCORE 2589 Security Context. 2591 Note that the ID Context of the pairwise OSCORE Security Context can 2592 be assigned by the AS, communicated and set in both the RS and Client 2593 after the exchange specified in this profile is executed. 2594 Subsequently, the Client and RS can update their ID Context by 2595 running a mechanism such as the one defined in Appendix B.2 of 2596 [RFC8613] if they both support it and are configured to do so. In 2597 that case, the ID Context in the pairwise OSCORE Security Context 2598 will not match the "contextId" parameter of the corresponding 2599 OSCORE_Input_Material. Running the procedure in Appendix B.2 of 2600 [RFC8613] results in the keying material in the pairwise OSCORE 2601 Security Contexts of the Client and RS being updated. The Client can 2602 achieve the same result by re-posting the Access Token to the 2603 unprotected /authz-info endpoint at the RS, as described in 2604 Section 4.1 of [I-D.ietf-ace-oscore-profile], although without 2605 updating the ID Context. 2607 A.3.4. OSCORE Setup - Resource Server Side 2609 After validation of the Access Token as defined in Appendix A.3.2 and 2610 after sending the 2.01 (Created) response to an unprotected POST 2611 request to the /authz-info endpoint, the RS performs the following 2612 actions, in order to set up and fully derive the pairwise OSCORE 2613 Security Context created to communicate with the Client. 2615 * The RS MUST set the ID Context of the pairwise OSCORE Security 2616 Context as the concatenation of: i) GID, i.e., the Group 2617 Identifier of the OSCORE group, as specified in the 'contextId' 2618 parameter of the OSCORE_Input_Material, in the 'cnf' claim of the 2619 Access Token received from the Client (see Appendix A.3.1); ii) 2620 the nonce N1; iii) the nonce N2; and iv) CID which is the value in 2621 the contextId parameter of the OSCORE_Input_Material provided in 2622 the 'cnf' claim of the Access Token. The concatenation occurs in 2623 this order: ID Context = GID | N1 | N2 | CID, where | denotes byte 2624 string concatenation. 2626 * The RS MUST set the new Master Salt of the pairwise OSCORE 2627 Security Context as the concatenation of SaltInput, MSalt, the 2628 nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the 2629 Sender ID that the Client has in the OSCORE group, as specified in 2630 the 'salt_input' claim included in the Access Token received from 2631 the Client (see Appendix A.3.1); ii) MSalt is the (optional) 2632 Master Salt in the pairwise OSCORE Security Context as specified 2633 in the 'salt' parameter in the OSCORE_Input_Material of the 'cnf' 2634 claim, included in the Access Token received from the Client; and 2635 iii) GMSalt is the (optional) Master Salt in the Group OSCORE 2636 Security Context, which is known to the RS as a member of the 2637 OSCORE group. The concatenation occurs in this order: Master Salt 2638 = SaltInput | MSalt | N1 | N2 | GMSalt, where | denotes byte 2639 string concatenation. Optional values, if not specified, are not 2640 included in the concatenation. The same considerations for 2641 building the Master Salt, considering the inputs as encoded CBOR 2642 byte strings as in Figure 16, hold also for the RS. 2644 * The RS MUST set the Master Secret of the pairwise OSCORE Security 2645 Context to the concatenation of MSec and GMSec, where: i) MSec is 2646 the value of the 'ms' parameter in the OSCORE_Input_Material of 2647 the 'cnf' claim, included in the Access Token received from the 2648 Client (see Appendix A.3.1); while ii) GMSec is the Master Secret 2649 of the Group OSCORE Security Context, which is known to the RS as 2650 a member of the OSCORE group. 2652 * The RS MUST set the Recipient ID as ace_server_recipientid, sent 2653 as described in Appendix A.3.2. 2655 * The RS MUST set the Sender ID as ace_client_recipientid, received 2656 as described in Appendix A.3.2. 2658 * The RS MUST set the AEAD Algorithm, ID Context, HKDF, and OSCORE 2659 Version from the corresponding parameters received from the Client 2660 in the Access Token (see Appendix A.3.1), if present in the 2661 OSCORE_Input_Material of the 'cnf' claim. In case these 2662 parameters are omitted, the default values SHALL be used as 2663 described in Sections 3.2 and 5.4 of [RFC8613]. 2665 Finally, the RS MUST derive the complete pairwise OSCORE Security 2666 Context following Section 3.2.1 of [RFC8613]. 2668 Once having completed the derivation above, the RS MUST associate the 2669 authorization information from the Access Token with the just 2670 established pairwise OSCORE Security Context. Furthermore, as 2671 defined in Section 4.2, the RS MUST associate the authorization 2672 information from the Access Token with the Group OSCORE Security 2673 Context. 2675 Then, the RS uses this pairwise OSCORE Security Context to verify 2676 requests from and send responses to the Client protected with OSCORE, 2677 when this Security Context is used. If OSCORE verification fails, 2678 error responses are used, as specified in Section 8 of [RFC8613]. 2680 Besides, the RS uses the Group OSCORE Security Context to verify 2681 (multicast) requests from and send responses to the Client protected 2682 with Group OSCORE. When processing an incoming request protected 2683 with Group OSCORE, the RS MUST consider as valid public key of the 2684 Client only the public key associated to the stored Access Token. As 2685 defined in Appendix A.3.6, a change of public key in the group 2686 requires the Client to upload to the RS a new Access Token, where the 2687 'client_cred' claim specifies a COSE Key equivalent to the new full- 2688 fledged public key that the Client has in the group. 2690 If Group OSCORE verification fails, error responses are used, as 2691 specified in Sections 8 and 9 of [I-D.ietf-core-oscore-groupcomm]. 2692 Additionally, for every incoming request, if OSCORE or Group OSCORE 2693 verification succeeds, the verification of access rights is performed 2694 as described in Appendix A.3.5. 2696 After the deletion of the Access Token related to a pairwise OSCORE 2697 Security Context and to a Group OSCORE Security Context, due to, for 2698 example, expiration, the RS MUST NOT use the pairwise OSCORE Security 2699 Context. The RS MUST respond with an unprotected 4.01 (Unauthorized) 2700 error message to received requests that correspond to a pairwise 2701 OSCORE Security Context with a deleted Access Token. Also, if the 2702 Client uses the Group OSCORE Security Context to send a request for 2703 any resource intended for OSCORE group members and that requires an 2704 active Access Token, the RS MUST respond with a 4.01 (Unauthorized) 2705 error message protected with the Group OSCORE Security Context. 2707 The same considerations, related to the value of the ID Context 2708 changing, as in Appendix A.3.3 hold also for the RS. 2710 A.3.5. Access Rights Verification 2712 The RS MUST follow the procedures defined in Section 4.4. 2714 Additionally, if the RS receives an OSCORE-protected request from a 2715 Client, the RS processes it according to [RFC8613]. 2717 If the OSCORE verification succeeds, and the target resource requires 2718 authorization, the RS retrieves the authorization information from 2719 the Access Token associated to the pairwise OSCORE Security Context 2720 and to the Group OSCORE Security Context. Then, the RS MUST verify 2721 that the action requested on the resource is authorized. 2723 The response code MUST be 4.01 (Unauthorized) if the RS has no valid 2724 Access Token for the Client. 2726 A.3.6. Change of Client's Public Key in the Group 2728 During its membership in the OSCORE group, the client might change 2729 the public key it uses in the group. When this happens, the Client 2730 uploads the new public key to the Group Manager, as defined in 2731 Section 11 of [I-D.ietf-ace-key-groupcomm-oscore]. 2733 After that, the Client may still have an Access Token previously 2734 uploaded to the RS, which is not expired yet and still valid to the 2735 best of the Client's knowledge. Then, in order to continue 2736 communicating with the RS, the Client MUST perform the following 2737 actions. 2739 1. The Client requests a new Access Token to the AS, as defined in 2740 Appendix A.2.1 for the update of access rights, i.e., with the 2741 'req_cnf' parameter including only a 'kid' field. In particular, 2742 when sending the POST request to the AS, the Client indicates: 2744 * The current Group Identifier of the OSCORE group, as value of 2745 the 'context_id' parameter. 2747 * The current Sender ID it has in the OSCORE group, as value of 2748 the 'salt_input' parameter. 2750 * The new public key it uses in the OSCORE group, as value of 2751 the 'client_cred' parameter. In particular, the specified 2752 public key is the COSE Key equivalent to the new full-fledged 2753 public key that the Client uses in the OSCORE group. 2755 * The proof-of-possession (PoP) evidence corresponding to the 2756 new public key, as value of the 'client_cred_verify' or 2757 'client_cred_verify_mac' parameter. 2759 * The same current or instead new set of access rights, as value 2760 of the 'scope' parameter. 2762 2. After receiving the response from the AS (see Appendix A.2.2), 2763 the Client performs the same exchanges with the RS as defined in 2764 Appendix A.3, with the following difference: the POST request to 2765 /authz-info for uploading the new Access Token MUST be protected 2766 with the pairwise OSCORE Security Context shared with the RS. 2768 When receiving the new Access Token, the RS performs the same steps 2769 defined in Appendix A.3.2. In particular, no new pairwise OSCORE 2770 Security Context is established between the Client and the RS. 2772 A.4. Secure Communication with the AS 2774 The same considerations for secure communication with the AS as 2775 defined in Section 5 hold. 2777 A.5. Discarding the Security Context 2779 The Client and the RS MUST follow what is defined in Section 6 of 2780 [I-D.ietf-ace-oscore-profile] about discarding the pairwise OSCORE 2781 Security Context. 2783 Additionally, they MUST follow what is defined in the main mode of 2784 the profile (see Section 6), with respect to the Group OSCORE 2785 Security Context. 2787 The Client or RS can acquire a new Group OSCORE Security Context, by 2788 re-joining the OSCORE group, e.g., by using the approach defined in 2789 [I-D.ietf-ace-key-groupcomm-oscore]. In such a case, the Client 2790 SHOULD request a new Access Token and post it to the RS, in order to 2791 establish a new pairwise OSCORE Security Context and bind it to the 2792 Group OSCORE Security Context obtained upon re-joining the group. 2794 A.6. CBOR Mappings 2796 The new parameters defined in this document MUST be mapped to CBOR 2797 types as specified in Figure 6, with the following addition, using 2798 the given integer abbreviation for the map key. 2800 /----------------+----------+------------\ 2801 | Parameter name | CBOR Key | Value Type | 2802 |----------------+----------+------------| 2803 | client_cred | TBD | map | 2804 \----------------+----------+------------/ 2806 Figure 17: CBOR mappings for new parameters. 2808 The new claims defined in this document MUST be mapped to CBOR types 2809 as specified in Figure 7, with the following addition, using the 2810 given integer abbreviation for the map key. 2812 /--------------+----------+------------\ 2813 | Claim name | CBOR Key | Value Type | 2814 |--------------+----------+------------| 2815 | client_cred | TBD | map | 2816 \--------------+----------+------------/ 2818 Figure 18: CBOR mappings for new claims. 2820 A.7. Security Considerations 2822 The dual mode of this profile inherits the security considerations 2823 from the main mode (see Section 8), as well as from the security 2824 considerations of the OSCORE profile of ACE 2825 [I-D.ietf-ace-oscore-profile]. Also, the security considerations 2826 about OSCORE [RFC8613] hold for the dual mode of this profile, as to 2827 the specific use of OSCORE. 2829 Unlike the main mode and consistently with Section 6.1 of 2830 [I-D.ietf-ace-oauth-authz], the dual mode of this profile cannot be 2831 used to issue an Access Token for an audience that comprises multiple 2832 RSs. This is because the proof-of-possession key bound to an Access 2833 Token is the OSCORE Master Secret included in the 2834 OSCORE_Input_Material object of the 'cnf' claim, and it has to be 2835 shared only between the Client and one RS. 2837 A.8. Privacy Considerations 2839 The same privacy considerations as defined in the main mode of this 2840 profile apply (see Section 9). 2842 In addition, as this profile mode also uses OSCORE, the privacy 2843 considerations from [RFC8613] apply as well, as to the specific use 2844 of OSCORE. 2846 Furthermore, this profile mode inherits the privacy considerations 2847 from the OSCORE profile of ACE [I-D.ietf-ace-oscore-profile]. 2849 Appendix B. Profile Requirements 2851 This appendix lists the specifications on this profile based on the 2852 requirements of the ACE framework, as requested in Appendix C of 2853 [I-D.ietf-ace-oauth-authz]. 2855 * (Optional) discovery process of how the Client finds the right AS 2856 for an RS it wants to send a request to: Not specified. 2858 * Communication protocol the Client and the RS must use: CoAP. 2860 * Security protocol(s) the Client and RS must use: Group OSCORE, 2861 i.e., exchange of secure messages by using a pre-established Group 2862 OSCORE Security Context. The optional dual mode defined in 2863 Appendix A additionally uses OSCORE, i.e., establishment of a 2864 pairwise OSCORE Security Context and exchange of secure messages. 2866 * How the Client and the RS mutually authenticate: Explicitly, by 2867 possession of a common Group OSCORE Security Context, and by 2868 either: usage of digital signatures embedded in messages, if 2869 protected with the group mode of Group OSCORE; or protection of 2870 messages with the pairwise mode of Group OSCORE, by using pairwise 2871 symmetric keys, derived from the asymmetric keys of the two peers 2872 exchanging the message. Note that the mutual authentication is 2873 not completed before the Client has verified an OSCORE or a Group 2874 OSCORE response using the corresponding security context. 2876 * Content-format of the protocol messages: "application/ace+cbor". 2878 * Proof-of-Possession protocol(s) and how to select one; which key 2879 types (e.g., symmetric/asymmetric) supported: Group OSCORE 2880 algorithms; distributed and verified asymmetric keys. In the 2881 optional dual mode defined in Appendix A: OSCORE algorithms; pre- 2882 established symmetric keys. 2884 * profile identifier: coap_group_oscore 2886 * (Optional) how the RS talks to the AS for introspection: HTTP/CoAP 2887 (+ TLS/DTLS/OSCORE). 2889 * How the client talks to the AS for requesting a token: HTTP/CoAP 2890 (+ TLS/DTLS/OSCORE). 2892 * How/if the authz-info endpoint is protected: Not protected. 2894 * (Optional) other methods of token transport than the authz-info 2895 endpoint: Not specified. 2897 Acknowledgments 2899 The authors sincerely thank Benjamin Kaduk, John Mattsson, Dave 2900 Robin, Jim Schaad and Goeran Selander for their comments and 2901 feedback. 2903 The work on this document has been partly supported by VINNOVA and 2904 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 2905 (Grant agreement 952652). 2907 Authors' Addresses 2909 Marco Tiloca 2910 RISE AB 2911 Isafjordsgatan 22 2912 SE-16440 Stockholm Kista 2913 Sweden 2915 Email: marco.tiloca@ri.se 2917 Rikard Höglund 2918 RISE AB 2919 Isafjordsgatan 22 2920 SE-16440 Stockholm Kista 2921 Sweden 2923 Email: rikard.hoglund@ri.se 2925 Ludwig Seitz 2926 Combitech 2927 Djäknegatan 31 2928 SE-21135 Malmö Malmö 2929 Sweden 2931 Email: ludwig.seitz@combitech.com 2933 Francesca Palombini 2934 Ericsson AB 2935 Torshamnsgatan 23 2936 SE-16440 Stockholm Kista 2937 Sweden 2939 Email: francesca.palombini@ericsson.com