idnits 2.17.1 draft-tiloca-ace-group-oscore-profile-08.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 (7 March 2022) is 780 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-13 == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-06 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-14 ** 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-15 == Outdated reference: A later version (-09) exists of draft-ietf-cose-cbor-encoded-cert-03 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-11 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 3 errors (**), 0 flaws (~~), 8 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: 8 September 2022 L. Seitz 6 Combitech 7 F. Palombini 8 Ericsson AB 9 7 March 2022 11 Group OSCORE Profile of the Authentication and Authorization for 12 Constrained Environments Framework 13 draft-tiloca-ace-group-oscore-profile-08 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 with 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 8 September 2022. 59 Copyright Notice 61 Copyright (c) 2022 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 Revised BSD License text as 70 described in Section 4.e of the Trust Legal Provisions and are 71 provided without warranty as described in the Revised BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 77 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 78 2.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . 9 79 2.2. Access Token Retrieval . . . . . . . . . . . . . . . . . 10 80 2.3. Access Token Posting . . . . . . . . . . . . . . . . . . 11 81 2.4. Secure Communication . . . . . . . . . . . . . . . . . . 11 82 3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 12 83 3.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . . . 12 84 3.1.1. 'context_id' Parameter . . . . . . . . . . . . . . . 15 85 3.1.2. 'salt_input' Parameter . . . . . . . . . . . . . . . 15 86 3.1.3. 'client_cred_verify' Parameter . . . . . . . . . . . 16 87 3.1.4. 'client_cred_verify_mac' Parameter . . . . . . . . . 16 88 3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 16 89 3.2.1. Salt Input Claim . . . . . . . . . . . . . . . . . . 20 90 3.2.2. Context ID Input Claim . . . . . . . . . . . . . . . 21 91 4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 21 92 4.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . . . 22 93 4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 22 94 4.3. Client-RS Secure Communication . . . . . . . . . . . . . 24 95 4.3.1. Client Side . . . . . . . . . . . . . . . . . . . . . 24 96 4.3.2. Resource Server Side . . . . . . . . . . . . . . . . 24 97 4.4. Access Rights Verification . . . . . . . . . . . . . . . 25 98 4.5. Change of Client's Authentication Credential in the 99 Group . . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 5. Secure Communication with the AS . . . . . . . . . . . . . . 26 101 6. Discarding the Security Context . . . . . . . . . . . . . . . 26 102 7. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . . . 27 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 104 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 105 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 106 10.1. ACE Profile Registry . . . . . . . . . . . . . . . . . . 29 107 10.2. OAuth Parameters Registry . . . . . . . . . . . . . . . 29 108 10.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . 31 109 10.4. CBOR Web Token Claims Registry . . . . . . . . . . . . . 32 110 10.5. TLS Exporter Label Registry . . . . . . . . . . . . . . 33 111 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 112 11.1. Normative References . . . . . . . . . . . . . . . . . . 33 113 11.2. Informative References . . . . . . . . . . . . . . . . . 36 114 Appendix A. Dual Mode (Group OSCORE & OSCORE) . . . . . . . . . 37 115 A.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 38 116 A.1.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . 40 117 A.1.2. Access Token Posting . . . . . . . . . . . . . . . . 40 118 A.1.3. Setup of the Pairwise OSCORE Security Context . . . . 41 119 A.1.4. Secure Communication . . . . . . . . . . . . . . . . 42 120 A.2. Client-AS Communication . . . . . . . . . . . . . . . . . 42 121 A.2.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . 43 122 A.2.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . 45 123 A.3. Client-RS Communication . . . . . . . . . . . . . . . . . 53 124 A.3.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . 54 125 A.3.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . 54 126 A.3.3. OSCORE Setup - Client Side . . . . . . . . . . . . . 56 127 A.3.4. OSCORE Setup - Resource Server Side . . . . . . . . . 58 128 A.3.5. Access Rights Verification . . . . . . . . . . . . . 61 129 A.3.6. Change of Client's Authentication Credential in the 130 Group . . . . . . . . . . . . . . . . . . . . . . . . 61 131 A.4. Secure Communication with the AS . . . . . . . . . . . . 62 132 A.5. Discarding the Security Context . . . . . . . . . . . . . 62 133 A.6. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . 63 134 A.7. Security Considerations . . . . . . . . . . . . . . . . . 63 135 A.8. Privacy Considerations . . . . . . . . . . . . . . . . . 64 136 Appendix B. Profile Requirements . . . . . . . . . . . . . . . . 64 137 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 65 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 140 1. Introduction 142 A number of applications rely on a group communication model, where a 143 Client can access a resource shared by multiple Resource Servers at 144 once, e.g., over IP multicast. Typical examples are switching of 145 luminaries, actuators control, and distribution of software updates. 146 Secure communication in the group can be achieved by sharing a set of 147 keying material, which is typically provided upon joining the group. 149 For some of such applications, it may be just fine to enforce access 150 control in a straightforward fashion. That is, any Client authorized 151 to join the group, hence to get the group keying material, can be 152 also implicitly authorized to perform any action at any resource of 153 any Server in the group. An example of application where such 154 implicit authorization might be used is a simple lighting scenario, 155 where the lightbulbs are the Servers, while the user account on an 156 app on the user's phone is the Client. In this case, it might be 157 fine to not require additional authorization evidence from any user 158 account, if it is acceptable that any current group member is also 159 authorized to switch on and off any light, or to check their status. 161 However, in different instances of such applications, the approach 162 above is not desirable, as different group members are intended to 163 have different access rights to resources of other group members. 164 That is, access control to the secure group communication channel and 165 access control to the resource space provided by servers in the group 166 should remain logically separated domains. For instance, a more 167 fine-grained approach is required in the two following use cases. 169 As a first case, an application provides control of smart locks 170 acting as Servers in the group, where: a first type of Client, e.g., 171 a user account of a child, is allowed to only query the status of the 172 smart locks; while a second type of Client, e.g., a user account of a 173 parent, is allowed to both query and change the status of the smart 174 locks. Further similar applications concern the enforcement of 175 different sets of permissions in groups with sensor/actuator devices, 176 e.g., thermostats, acting as Servers. Also, some group members may 177 even be intended as Servers only. Hence, they must be prevented from 178 acting as Clients altogether and from accessing resources at other 179 Servers, especially when attempting to perform non-safe operations. 181 As a second case, building automation scenarios often rely on Servers 182 that, under different circumstances, enforce different level of 183 priority for processing received commands. For instance, BACnet 184 deployments consider multiple classes of Clients, e.g., a normal 185 light switch (C1) and an emergency fire panel (C2). Then, a C1 186 Client is not allowed to override a command from a C2 Client, until 187 the latter relinquishes control at its higher priority. That is: i) 188 only C2 Clients should be able to adjust the minimum required level 189 of priority on the Servers, so rightly locking out C1 Clients if 190 needed; and ii) when a Server is set to accept only high-priority 191 commands, only C2 Clients should be able to perform such commands 192 otherwise allowed also to C1 Clients. Given the different maximum 193 authority of different Clients, fine-grained access control would 194 effectively limit the execution of high- and emergency-priority 195 commands only to devices that are in fact authorized to do so. 196 Besides, it would prevent a misconfigured or compromised device from 197 initiating a high-priority command and lock out normal control. 199 In the cases above, being a legitimate group member and storing the 200 group keying material is not supposed to imply any particular access 201 rights. Also, introducing a different security group for each 202 different set of access rights would result in additional keying 203 material to distribute and manage. In particular, if the access 204 rights for a single node change, this would require to evict that 205 node from the current group, followed by that node joining a 206 different group aligned with its new access rights. Moreover, the 207 keying material of both groups would have to be renewed for their 208 current members. Overall, this would have a non negligible impact on 209 operations and performance in the system. 211 A fine-grained access control model can be rather enforced within a 212 same group, by using the Authentication and Authorization for 213 Constrained Environments (ACE) framework [I-D.ietf-ace-oauth-authz]. 214 That is, a Client has to first obtain authorization credentials in 215 the form of an Access Token, and post it to the Resource Server(s) in 216 the group before accessing the intended resources. 218 The ACE framework delegates to separate profile documents how to 219 secure communications between the Client and the Resource Server. 220 However each of the current profiles of ACE defined in 221 [I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-dtls-authorize] 222 [I-D.ietf-ace-mqtt-tls-profile] admits a single security protocol 223 that cannot be used to protect group messages sent over IP multicast. 225 This document specifies the "coap_group_oscore" profile of the ACE 226 framework, where a Client uses CoAP [RFC7252] or CoAP over IP 227 multicast [I-D.ietf-core-groupcomm-bis] to communicate to one or 228 multiple Resource Servers, which are members of an application group 229 and share a common set of resources. This profile uses Group OSCORE 230 [I-D.ietf-core-oscore-groupcomm] as the security protocol to protect 231 messages exchanged between the Client and the Resource Servers. 232 Hence, it requires that both the Client and the Resource Servers have 233 previously joined the same OSCORE group. 235 That is, this profile describes how access control is enforced for a 236 Client after it has joined an OSCORE group, to access resources at 237 other members in that group. The process for joining the OSCORE 238 group through the respective Group Manager as defined in 239 [I-D.ietf-ace-key-groupcomm-oscore] takes place before the process 240 described in this document, and is out of the scope of this profile. 242 The Client proves its access to be authorized to the Resource Server 243 by using an Access Token, which is bound to a key (the proof-of- 244 possession key). This profile uses Group OSCORE to achieve server 245 authentication, as well as proof-of-possession for the Client's 246 public key used in the OSCORE group in question. Note that the proof 247 of possession is not done by a dedicated protocol element, but rather 248 occurs after the first Group OSCORE exchange. 250 Furthermore, this profile provides proof of the Client's membership 251 to the correct OSCORE group, by binding the Access Token to the 252 Client's authentication credential used in the group and including 253 the Client's public public key, as well as to information from the 254 pre-established Group OSCORE Security Context. This allows the 255 Resource Server to verify the Client's group membership upon 256 reception of a message protected with Group OSCORE from that Client. 258 OSCORE [RFC8613] specifies how to use COSE 259 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] to 260 secure CoAP messages. Group OSCORE builds on OSCORE to provide 261 secure group communication, and ensures source authentication: by 262 means of digital signatures embedded in protected messages (in group 263 mode); or by protecting messages with pairwise keying material 264 derived from the asymmetric keys of the two peers exchanging the 265 message (in pairwise mode). 267 1.1. Terminology 269 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 270 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 271 "OPTIONAL" in this document are to be interpreted as described in BCP 272 14 [RFC2119] [RFC8174] when, and only when, they appear in all 273 capitals, as shown here. 275 Readers are expected to be familiar with the terms and concepts 276 related to CBOR [RFC8949], COSE 277 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs], 278 CoAP [RFC7252], OSCORE [RFC8613] and Group OSCORE 279 [I-D.ietf-core-oscore-groupcomm]. These especially include: 281 * Group Manager, as the entity responsible for a set of groups where 282 communications among members are secured with Group OSCORE. 284 * Authentication credential, as the set of information associated 285 with an entity, including that entity's public key and parameters 286 associated with the public key. Examples of authentication 287 credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) 288 [RFC8392], X.509 certificates [RFC7925] and C509 certificates 289 [I-D.ietf-cose-cbor-encoded-cert]. 291 Members of an OSCORE group have an associated authentication 292 credential in the format used in the group. As per Section 2.3 of 293 [I-D.ietf-core-oscore-groupcomm], an authentication credential 294 provides the public key as well as the comprehensive set of 295 information related to the public key algorithm, including, e.g., 296 the used elliptic curve (when applicable). 298 Readers are expected to be familiar with the terms and concepts 299 described in the ACE framework for authentication and authorization 300 [I-D.ietf-ace-oauth-authz], as well as in the OSCORE profile of ACE 301 [I-D.ietf-ace-oscore-profile]. The terminology for entities in the 302 considered architecture is defined in OAuth 2.0 [RFC6749]. In 303 particular, this includes Client (C), Resource Server (RS), and 304 Authorization Server (AS). 306 Note that, unless otherwise indicated, the term "endpoint" is used 307 here following its OAuth definition, aimed at denoting resources such 308 as /token and /introspect at the AS, and /authz-info at the RS. This 309 document does not use the CoAP definition of "endpoint", which is "An 310 entity participating in the CoAP protocol". 312 Additionally, this document makes use of the following terminology. 314 * Equivalent COSE Key: a COSE Key built from an authentication 315 credential used in the OSCORE group. The equivalent COSE Key 316 preserves all the main information elements from the 317 authentication credential, in particular the key coordinates and 318 the comprehensive set of information related to the public key 319 algorithm, including, e.g., the used elliptic curve (when 320 applicable). 322 * Pairwise-only group: an OSCORE group that uses only the pairwise 323 mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). 325 Examples throughout this document are expressed in CBOR diagnostic 326 notation, without the tag and value abbreviations. 328 2. Protocol Overview 330 This section provides an overview of this profile, i.e., on how to 331 use the ACE framework for authentication and authorization 332 [I-D.ietf-ace-oauth-authz] to secure communications between a Client 333 and a (set of) Resource Server(s) using Group OSCORE 334 [I-D.ietf-core-oscore-groupcomm]. 336 Note that this profile of ACE describes how access control can be 337 enforced for a node after it has joined an OSCORE group, to access 338 resources at other members in that group. 340 In particular, the process for joining the OSCORE group through the 341 respective Group Manager as defined in 342 [I-D.ietf-ace-key-groupcomm-oscore] must take place before the 343 process described in this document, and is out of the scope of this 344 profile. 346 An overview of the protocol flow for this profile is shown in 347 Figure 1. In the figure, it is assumed that both RS1 and RS2 are 348 associated with the same AS. It is also assumed that C, RS1 and RS2 349 have previously joined an OSCORE group with Group Identifier (gid) 350 "abcd0000", and got assigned Sender ID (sid) "0", "1" and "2" in the 351 group, respectively. The names of messages coincide with those of 352 [I-D.ietf-ace-oauth-authz] when applicable. 354 C RS1 RS2 AS 355 | [--- Resource Request -->] | | | 356 | | | | 357 | [<---- AS Request ------] | | | 358 | Creation Hints | | | 359 | | | | 360 |-------- POST /token ----------------------------------------------->| 361 | (aud: RS1, sid: 0, gid: abcd0000, ...) | | 362 | | | | 363 | | | | 364 |<-------------------------------- Access Token + RS Information -----| 365 | | (aud: RS1, sid: 0, gid: abcd0000, ...) | 366 | | | | 367 |---- POST /authz-info ----->| | | 368 | (access_token) | | | 369 | | | | 370 |<--- 2.01 Created ----------| | | 371 | | | | 372 |-------- POST /token ----------------------------------------------->| 373 | (aud: RS2, sid: 0, gid: abcd0000, ...) | | 374 | | | | 375 | | | | 376 | | | | 377 |<-------------------------------- Access Token + RS Information -----| 378 | | (aud: RS2, sid: 0, gid: abcd0000, ...) | 379 | | | | 380 |----- POST /authz-info ----------------->| | 381 | (access_token) | | | 382 | | | | 383 | | | | 384 |<--- 2.01 Created -----------------------| | 385 | | | | 386 |-- Group OSCORE Request -+->| | | 387 | (kid: 0, gid: abcd0000) \-------------->| | 388 | | | | 389 | /proof-of-possession/ | 390 | | | | 391 | | | | 392 |<-- Group OSCORE Response --| | | 393 | (kid: 1) | | | 394 | | | | 395 /proof-of-possession/ | | | 396 | | | | 397 /Mutual authentication | | | 398 between C and RS1/ | | | 399 | | | | 400 | | | | 401 |<-- Group OSCORE Response ---------------| | 402 | (kid: 2) | | | 403 | | | | 404 /proof-of-possession/ | | | 405 | | | | 406 /Mutual authentication | | | 407 between C and RS2/ | | | 408 | | | | 409 | ... | | | 411 Figure 1: Protocol Overview. 413 2.1. Pre-Conditions 415 Using Group OSCORE and this profile requires both the Client and the 416 Resource Servers to have previously joined the same OSCORE group. 417 This especially includes the derivation of the Group OSCORE Security 418 Context and the assignment of unique Sender IDs to use in the group. 419 Nodes may join the OSCORE group through the respective Group Manager 420 by using the approach defined in [I-D.ietf-ace-key-groupcomm-oscore], 421 which is also based on ACE. 423 After the Client and Resource Servers have joined the group, this 424 profile provides access control for accessing resources on those 425 Resource Servers, by securely communicating with Group OSCORE. 427 As a pre-requisite for this profile, the Client has to have 428 successfully joined the OSCORE group where also the Resource Servers 429 (RSs) are members. Depending on the limited information initially 430 available, the Client may have to first discover the exact OSCORE 431 group used by the RSs for the resources of interest, e.g., by using 432 the approach defined in [I-D.tiloca-core-oscore-discovery]. 434 2.2. Access Token Retrieval 436 This profile requires that the Client retrieves an Access Token from 437 the AS for the resource(s) it wants to access on each of the RSs, 438 using the /token endpoint, as specified in Section 5.8 of 439 [I-D.ietf-ace-oauth-authz]. In a general case, it can be assumed 440 that different RSs are associated with different ASs, even if the RSs 441 are members of a same OSCORE group. 443 In the Access Token request to the AS, the Client MUST include the 444 Group Identifier of the OSCORE group and its own Sender ID in that 445 group. The AS MUST specify these pieces of information in the Access 446 Token, included in the Access Token response to the Client. 448 Furthermore, in the Access Token request to the AS, the Client MUST 449 also include: its own public key used in the OSCORE group; and a 450 proof-of-possession (PoP) evidence to proof possession of the 451 corresponding private key. The PoP evidence is computed over a PoP 452 input uniquely related to the secure communication association 453 between the Client and the AS. The AS MUST include also the public 454 key indicated by the Client in the Access Token. 456 The Access Token request and response MUST be confidentiality- 457 protected and ensure authenticity. This profile RECOMMENDS the use 458 of OSCORE between the Client and the AS, to reduce the number of 459 libraries the client has to support. Other protocols fulfilling the 460 security requirements defined in Sections 5 and 6 of 461 [I-D.ietf-ace-oauth-authz] MAY alternatively be used, such as TLS 462 [RFC8446] or DTLS [RFC6347][I-D.ietf-tls-dtls13]. 464 2.3. Access Token Posting 466 After having retrieved the Access Token from the AS, the Client posts 467 the Access Token to the RS, using the /authz-info endpoint and 468 mechanisms specified in Section 5.10 of [I-D.ietf-ace-oauth-authz], 469 as well as Content-Format = application/ace+cbor. When using this 470 profile, the communication with the /authz-info endpoint is not 471 protected. 473 If the Access Token is valid, the RS replies to this POST request 474 with a 2.01 (Created) response with Content-Format = application/ 475 ace+cbor. Also, the RS associates the received Access Token with the 476 Group OSCORE Security Context identified by the Group Identifier 477 specified in the Access Token, following Section 3.2 of [RFC8613]. 478 In practice, the RS maintains a collection of Security Contexts with 479 associated authorization information, for all the clients that it is 480 currently communicating with, and the authorization information is a 481 policy used as input when processing requests from those clients. 483 Finally, the RS stores the association between i) the authorization 484 information from the Access Token; and ii) the Group Identifier of 485 the OSCORE group together with the Sender ID and the authentication 486 credential of the Client in that group. This binds the Access Token 487 with the Group OSCORE Security Context of the OSCORE group. 489 Finally, when the Client communicates with the RS using the Group 490 OSCORE Security Context, the RS verifies that the Client is a 491 legitimate member of the OSCORE group and especially the exact group 492 member with the same Sender ID associated with the Access Token. 493 This occurs when verifying a request protected with Group OSCORE, 494 since the request includes the Client's Sender ID and either it 495 embeds a signature computed also over that Sender ID (if protected 496 with the group mode), or it is protected by means of pairwise 497 symmetric keying material derived from the asymmetric keys of the two 498 peers (if protected with the pairwise mode). 500 2.4. Secure Communication 502 The Client can send a request protected with Group OSCORE 503 [I-D.ietf-core-oscore-groupcomm] to the RS. This can be a unicast 504 request addressed to the RS, or a multicast request addressed to the 505 OSCORE group where the RS is also a member. To this end, the Client 506 uses the Group OSCORE Security Context already established upon 507 joining the OSCORE group, e.g., by using the approach defined in 508 [I-D.ietf-ace-key-groupcomm-oscore]. The RS may send a response back 509 to the Client, protecting it by means of the same Group OSCORE 510 Security Context. 512 3. Client-AS Communication 514 This section details the Access Token POST Request that the Client 515 sends to the /token endpoint of the AS, as well as the related Access 516 Token response. 518 The Access Token MUST be bound to the public key of the client as 519 proof-of-possession key (pop-key), by means of the 'cnf' claim. 521 3.1. C-to-AS: POST to Token Endpoint 523 The Client-to-AS request is specified in Section 5.8.1 of 524 [I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request 525 to the /token endpoint over a secure channel that guarantees 526 authentication, message integrity and confidentiality. 528 The POST request is formatted as the analogous Client-to-AS request 529 in the OSCORE profile of ACE (see Section 3.1 of 530 [I-D.ietf-ace-oscore-profile]), with the following additional 531 parameters that MUST be included in the payload. 533 * 'context_id', defined in Section 3.1.1 of this document. This 534 parameter specifies the Group Identifier (GID), i.e., the Id 535 Context of an OSCORE group where the Client and the RS are 536 currently members. In particular, the Client wishes to 537 communicate with the RS using the Group OSCORE Security Context 538 associated with that OSCORE group. 540 * 'salt_input', defined in Section 3.1.2 of this document. This 541 parameter includes the Sender ID that the Client has in the OSCORE 542 group whose GID is specified in the 'context_id' parameter above. 544 * 'req_cnf', defined in Section 3.1 of [I-D.ietf-ace-oauth-params]. 545 This parameter follows the syntax from Section 3.1 of [RFC8747] 546 when including Value Type "COSE_Key" (1) and specifying an 547 asymmetric key. In particular, the specified public key is the 548 COSE Key equivalent to the authentication credential that the 549 Client uses in the OSCORE group. The specified public key will be 550 used as the pop-key bound to the Access Token. 552 Alternative Value Types defined in future specifications are fine 553 to consider, if indicating a non-encrypted asymmetric key or full- 554 fledged autentication credential. 556 In addition, the Client computes its proof-of-possession (PoP) 557 evidence, in order to prove possession of its own private key used in 558 the OSCORE group to the AS. This allows the AS to verify that the 559 Client indeed owns the private key associated with that public key, 560 as its alleged identity credential within the OSCORE group. 562 To this end, the Client MUST use as PoP input the byte representation 563 of a quantity that uniquely represents the secure communication 564 association between the Client and the AS. It is RECOMMENDED that 565 the Client considers the following as PoP input. 567 * If the Client and the AS communicate over (D)TLS, the PoP input is 568 an exporter value computed as defined in Section 7.5 of [RFC8446]. 569 In particular, the exporter label MUST be 'EXPORTER-ACE-Sign- 570 Challenge-Client-AS' defined in Section 10.5 of this document, 571 together with an empty 'context_value', and 32 bytes as 572 'key_length'. 574 * If the Client and the AS communicate over OSCORE, the PoP input is 575 the output PRK of a HKDF-Extract step [RFC5869], i.e., PRK = HMAC- 576 Hash(salt, IKM). In particular, 'salt' takes (x1 | x2), where x1 577 is the ID Context of the OSCORE Security Context between the 578 Client and the AS, x2 is the Sender ID of the Client in that 579 Security Context, and | denotes byte string concatenation. Also, 580 'IKM' is the OSCORE Master Secret of the OSCORE Security Context 581 between the Client and the AS. 583 The HKDF MUST be one of the HMAC-based HKDF [RFC5869] algorithms 584 defined for COSE [I-D.ietf-cose-rfc8152bis-algs]. The Client and 585 AS may agree on the HKDF algorithm to use during the Client's 586 registration at the AS. HKDF SHA-256 is mandatory to implement. 588 Then, the Client computes the PoP evidence as follows. 590 * If the OSCORE group is not a pairwise-only group, the PoP evidence 591 MUST be a signature. The Client computes the signature by using 592 the same private key and signature algorithm it uses for signing 593 messages in the OSCORE group. The private key corresponds to the 594 authentication credential used in the OSCORE group, for which the 595 equivalent COSE Key is specified in the 'req_cnf' parameter above. 597 * If the OSCORE group is a pairwise-only group, the PoP evidence 598 MUST be a MAC computed as follows, by using the HKDF Algorithm 599 HKDF SHA-256, which consists of composing the HKDF-Extract and 600 HKDF-Expand steps [RFC5869]. 602 MAC = HKDF(salt, IKM, info, L) 603 The input parameters of HKDF are as follows. 605 - salt takes as value the empty byte string. 607 - IKM is computed as a cofactor Diffie-Hellman shared secret, see 608 Section 5.7.1.2 of [NIST-800-56A], using an ECDH algorithm pre- 609 agreed between Client and AS. The Client uses its own Diffie- 610 Hellman private key and the Diffie-Hellman public key of the 611 AS. For X25519 and X448, the procedure is described in 612 Section 5 of [RFC7748]. 614 The Client's private key corresponds to the Client's 615 authentication credential used in the OSCORE group, for which 616 the equivalent COSE Key is specified in the 'req_cnf' parameter 617 above. The Client may obtain the Diffie-Hellman public key of 618 the AS during its registration process at the AS. 620 The Client and AS may agree on the ECDH algorithm to use during 621 the Client's registration at the AS. The ECDH-SS + HKDF-256 622 algorithm specified in Section 6.3.1 of 623 [I-D.ietf-cose-rfc8152bis-algs] is mandatory to implement. 625 - info takes as value the PoP input. 627 - L is equal to 8, i.e., the size of the MAC, in bytes. 629 Finally, the Client MUST include one of the two following parameters 630 in the payload of the POST request to the AS. 632 * 'client_cred_verify', defined in Section 3.1.3 of this document, 633 specifying the Client's PoP evidence as a signature, which is 634 computed as defined above. This parameter MUST be included if and 635 only if the OSCORE group is not a pairwise-only group. 637 * 'client_cred_verify_mac', defined in Section 3.1.4 of this 638 document, specifying the Client's PoP evidence as a MAC, which is 639 computed as defined above. This parameter MUST be included if and 640 only if the OSCORE group is a pairwise-only group. 642 An example of such a request is shown in Figure 2. 644 Header: POST (Code=0.02) 645 Uri-Host: "as.example.com" 646 Uri-Path: "token" 647 Content-Format: "application/ace+cbor" 648 Payload: 649 { 650 "audience" : "tempSensor4711", 651 "scope" : "read", 652 "context_id" : h'abcd0000', 653 "salt_input" : h'00', 654 "req_cnf" : { 655 "COSE_Key" : { 656 "kty" : EC2, 657 "crv" : P-256, 658 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 659 27c9e354089bbe13', 660 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 661 731e79a3b4e47120' 662 } 663 }, 664 "client_cred_verify" : h'...' 665 (signature content omitted for brevity) 666 } 668 Figure 2: Example C-to-AS POST /token request for an Access Token 669 bound to an asymmetric key. 671 3.1.1. 'context_id' Parameter 673 The 'context_id' parameter is an OPTIONAL parameter of the Access 674 Token request message defined in Section 5.8.1 of 675 [I-D.ietf-ace-oauth-authz]. This parameter provides a value that the 676 Client wishes to use with the RS as a hint for a security context. 677 Its exact content is profile specific. 679 3.1.2. 'salt_input' Parameter 681 The 'salt_input' parameter is an OPTIONAL parameter of the Access 682 Token request message defined in Section 5.8.1 of 683 [I-D.ietf-ace-oauth-authz]. This parameter provides a value that the 684 Client wishes to use as part of a salt with the RS, for deriving 685 cryptographic keying material. Its exact content is profile 686 specific. 688 3.1.3. 'client_cred_verify' Parameter 690 The 'client_cred_verify' parameter is an OPTIONAL parameter of the 691 Access Token request message defined in Section 5.8.1. of 692 [I-D.ietf-ace-oauth-authz]. This parameter provides a signature 693 computed by the Client to prove the possession of its own private 694 key. 696 3.1.4. 'client_cred_verify_mac' Parameter 698 The 'client_cred_verify_mac' parameter is an OPTIONAL parameter of 699 the Access Token request message defined in Section 5.8.1. of 700 [I-D.ietf-ace-oauth-authz]. This parameter provides a Message 701 Authentication Code (MAC) computed by the Client to prove the 702 possession of its own private key. 704 3.2. AS-to-C: Access Token 706 After having verified the POST request to the /token endpoint and 707 that the Client is authorized to obtain an Access Token corresponding 708 to its Access Token request, the AS MUST verify the proof-of- 709 possession (PoP) evidence. In particular, the AS proceeds as 710 follows. 712 * As PoP input, the AS uses the same value considered by the Client 713 in Section 3.1. 715 * As public key of the Client, the AS uses the one specified in the 716 'req_cnf' parameter of the Access Token request. 718 * If the Access Token request includes the 'client_cred_verify' 719 parameter, this specifies the PoP evidence as a signature. Then, 720 the AS verifies the signature by using the public key of the 721 Client. 723 * If the Access Token request includes the 'client_cred_verify_mac' 724 parameter, this specifies the PoP evidence as a Message 725 Authentication Code (MAC). 727 Then, the AS recomputes the MAC through the same process taken by 728 the Client when preparing the value of the 729 'client_cred_verify_mac' parameter for the Access Token (see 730 Section 3.1), with the difference that the AS uses its own Diffie- 731 Hellman private key and the Diffie-Hellman public key of the 732 Client. The verification succeeds if and only if the recomputed 733 MAC is equal to the MAC conveyed as PoP evidence in the Access 734 Token request. 736 If both the 'client_cred_verify' and 'client_cred_verify_mac' 737 parameters are present, or if the verification of the PoP evidence 738 fails, the AS considers the Client request invalid. 740 If the Client request was invalid, or not authorized, the AS returns 741 an error response as described in Section 5.8.3 of 742 [I-D.ietf-ace-oauth-authz]. 744 If all verifications are successful, the AS responds as defined in 745 Section 5.8.2 of [I-D.ietf-ace-oauth-authz]. In particular: 747 * The AS can signal that the use of Group OSCORE is REQUIRED for a 748 specific Access Token by including the 'ace_profile' parameter 749 with the value "coap_group_oscore" in the Access Token response. 750 The Client MUST use Group OSCORE towards all the Resource Servers 751 for which this Access Token is valid. Usually, it is assumed that 752 constrained devices will be pre-configured with the necessary 753 profile, so that this kind of profile signaling can be omitted. 755 * The AS MUST NOT include the 'rs_cnf' parameter defined in 756 [I-D.ietf-ace-oauth-params]. In general, the AS may not be aware 757 of the authentication credentials (and public keys included 758 thereof) that the RSs use in the OSCORE group. Also, the Client 759 is able to retrieve the authentication credentials of other group 760 members from the responsible Group Manager, both upon joining the 761 group or later on as a group member, as defined in 762 [I-D.ietf-ace-key-groupcomm-oscore]. 764 The AS MUST include the following information as metadata of the 765 issued Access Token. The use of CBOR web tokens (CWT) as specified 766 in [RFC8392] is RECOMMENDED. 768 * The profile "coap_group_oscore". If the Access Token is a CWT, 769 this is placed in the 'ace_profile' claim of the Access Token, as 770 per Section 5.10 of [I-D.ietf-ace-oauth-authz]. 772 * The salt input specified in the 'salt_input' parameter of the 773 Token Request. If the Access Token is a CWT, the content of the 774 'salt_input' parameter MUST be placed in the 'salt_input' claim of 775 the Access Token, defined in Section 3.2.1 of this document. 777 * The Context Id input specified in the 'context_id' parameter of 778 the Token Request. If the Access Token is a CWT, the content of 779 the 'context_id' parameter MUST be placed in the 'contextId_input' 780 claim of the Access Token, defined in Section 3.2.2 of this 781 document. 783 * The public key that the client uses in the OSCORE group and 784 specified in the 'req_cnf' parameter of the Token request. 786 If the Access Token is a CWT, the public key MUST be specified in 787 the 'cnf' claim, which follows the syntax from Section 3.1 of 788 [RFC8747] when including Value Type "COSE_Key" (1) and specifying 789 an asymmetric key. In particular, the 'cnf' claim includes the 790 same COSE Key specified in the 'req_cnf' parameter of the Token 791 Request, i.e., the COSE Key equivalent to the authentication 792 credential that the Client uses in the OSCORE group. 794 Alternative Value Types defined in future specifications are fine 795 to consider, if indicating a non-encrypted asymmetric key or full- 796 fledged autentication credential. 798 Figure 3 shows an example of such an AS response. The access token 799 has been truncated for readability. 801 Header: Created (Code=2.01) 802 Content-Type: "application/ace+cbor" 803 Payload: 804 { 805 "access_token" : h'8343a1010aa2044c53 ...' 806 (remainder of CWT omitted for brevity), 807 "ace_profile" : "coap_group_oscore", 808 "expires_in" : 3600 809 } 811 Figure 3: Example AS-to-C Access Token response with the Group 812 OSCORE profile. 814 Figure 4 shows an example CWT Claims Set, containing the Client's 815 public key in the group (as pop-key) in the 'cnf' claim. 817 { 818 "aud" : "tempSensorInLivingRoom", 819 "iat" : "1360189224", 820 "exp" : "1360289224", 821 "scope" : "temperature_g firmware_p", 822 "cnf" : { 823 "COSE_Key" : { 824 "kty" : EC2, 825 "crv" : P-256, 826 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 827 27c9e354089bbe13', 828 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 829 731e79a3b4e47120' 830 }, 831 "salt_input" : h'00', 832 "contextId_input" : h'abcd0000' 833 } 835 Figure 4: Example CWT Claims Set with OSCORE parameters. 837 The same CWT Claims Set as in Figure 4 and encoded in CBOR is shown 838 in Figure 5, using the value abbreviations defined in 839 [I-D.ietf-ace-oauth-authz] and [RFC8747]. The bytes in hexadecimal 840 are reported in the first column, while their corresponding CBOR 841 meaning is reported after the "#" sign on the second column, for 842 easiness of readability. 844 NOTE: it should be checked (and in case fixed) that the values used 845 below (which are not yet registered) are the final values registered 846 by IANA. 848 A7 # map(7) 849 03 # unsigned(3) 850 76 # text(22) 851 74656D7053656E736F72496E4C6976696E67526F6F6D 852 06 # unsigned(6) 853 1A 5112D728 # unsigned(1360189224) 854 04 # unsigned(4) 855 1A 51145DC8 # unsigned(1360289224) 856 09 # unsigned(9) 857 78 18 # text(24) 858 74656D70657261747572655F67206669726D776172655F70 859 08 # unsigned(8) 860 A1 # map(1) 861 01 # unsigned(1) 862 A4 # map(4) 863 01 # unsigned(1) 864 02 # unsigned(2) 865 20 # negative(0) 866 01 # unsigned(1) 867 21 # negative(1) 868 58 20 # bytes(32) 869 D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9 870 E354089BBE13 871 22 # negative(2) 872 58 20 # bytes(32) 873 F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E515D020731E 874 79A3B4E47120 875 18 3C # unsigned(60) 876 41 # bytes(1) 877 00 878 18 3D # unsigned(61) 879 44 # bytes(4) 880 ABCD0000 882 Figure 5: Example CWT Claims Set with OSCORE parameters, CBOR 883 encoded. 885 3.2.1. Salt Input Claim 887 The 'salt_input' claim provides a value that the Client requesting 888 the Access Token wishes to use as a part of a salt with the RS, e.g., 889 for deriving cryptographic material. 891 This parameter specifies the value of the salt input, encoded as a 892 CBOR byte string. 894 3.2.2. Context ID Input Claim 896 The 'contextId_input' claim provides a value that the Client 897 requesting the Access Token wishes to use with the RS, as a hint for 898 a security context. 900 This parameter specifies the value of the Context ID input, encoded 901 as a CBOR byte string. 903 4. Client-RS Communication 905 This section details the POST request and response to the /authz-info 906 endpoint between the Client and the RS. 908 The proof-of-possession required to bind the Access Token to the 909 Client is explicitly performed when the RS receives and verifies a 910 request from the Client protected with Group OSCORE, either with the 911 group mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]) or 912 with the pairwise mode (see Section 9 of 913 [I-D.ietf-core-oscore-groupcomm]). 915 In particular, the RS uses the Client's public key bound to the 916 Access Token, either when verifying the signature of the request (if 917 protected with the group mode), or when verifying the request as 918 integrity-protected with pairwise keying material derived from the 919 two peers' authentication credentials and asymmetric keys (if 920 protected with the pairwise mode). In either case, the RS also 921 authenticates the Client. 923 Similarly, when receiving a protected response from the RS, the 924 Client uses the RS's public key either when verifying the signature 925 of the response (if protected with the group mode), or when verifying 926 the response as integrity-protected with pairwise keying material 927 derived from the two peers' authentication credentials and asymmetric 928 keys (if protected with the pairwise mode). In either case, the 929 Client also authenticates the RS. Mutual authentication is only 930 achieved after the client has successfully verified the protected 931 response from the RS. 933 Therefore, an attacker using a stolen Access Token cannot generate a 934 valid Group OSCORE message as protected through the Client's private 935 key, and thus cannot prove possession of the pop-key bound to the 936 Access Token. Also, if a Client legitimately owns an Access Token 937 but has not joined the OSCORE group, it cannot generate a valid Group 938 OSCORE message, as it does not store the necessary keying material 939 shared among the group members. 941 Furthermore, a Client C1 is supposed to obtain a valid Access Token 942 from the AS, as including the public key associated with its own 943 private key used in the OSCORE group, together with its own Sender ID 944 in that OSCORE group (see Section 3.1). This allows the RS receiving 945 an Access Token to verify with the Group Manager of that OSCORE group 946 whether such a Client has indeed that Sender ID and an authentication 947 credential including that public key in the OSCORE group. 949 As a consequence, a different Client C2, also member of the same 950 OSCORE group, is not able to impersonate C1, by: i) getting a valid 951 Access Token, specifying the Sender ID of C1 and a different (made- 952 up) public key; ii) successfully posting the Access Token to RS; and 953 then iii) attempting to communicate using Group OSCORE impersonating 954 C1, while blaming C1 for the consequences. 956 4.1. C-to-RS POST to authz-info Endpoint 958 The Client posts the Access Token to the /authz-info endpoint of the 959 RS, as defined in Section 5.10.1 of [I-D.ietf-ace-oauth-authz]. 961 4.2. RS-to-C: 2.01 (Created) 963 The RS MUST verify the validity of the Access Token as defined in 964 Section 5.10.1 of [I-D.ietf-ace-oauth-authz], with the following 965 additions. 967 * The RS MUST check that the claims 'salt_input', 'contextId_input' 968 and 'cnf' are included in the Access Token. 970 * The RS considers: the content of the 'contextId_input' claim as 971 the GID of the OSCORE group; the content of the 'salt_input' claim 972 as the Sender ID that the Client has in the group; and the content 973 of the 'cnf' claim as the COSE Key equivalent to the 974 authentication credential that the Client uses in the group. 976 The RS MUST check whether it already stores an authentication 977 credential associated with the pair (GID, Sender ID) above, such 978 that the COSE Key specified in the 'cnf' claim is its equivalent 979 COSE Key. 981 If this is not the case, the RS MUST request the Client's 982 authentication credential to the Group Manager of the OSCORE group 983 as described in Section 10 of [I-D.ietf-ace-key-groupcomm-oscore], 984 specifying the Client's Sender ID in the OSCORE group, i.e., the 985 value of the 'salt_input' claim. Then, the RS performs the 986 following actions. 988 - The RS MUST check whether the Client's authentication 989 credential retrieved from the Group Manager is such that the 990 COSE Key specified in the 'cnf' claim of the Access Token is 991 its equivalent COSE Key. 993 - The RS MUST check that the Client's Sender ID provided by the 994 Group Manager together with the Client's authentication 995 credential matches the one retrieved from the 'salt_input' 996 claim of the Access Token. 998 If any of the checks above fails, the RS MUST consider the Access 999 Token non valid, and MUST respond to the Client with an error 1000 response code equivalent to the CoAP code 4.00 (Bad Request). 1002 If the Access Token is valid and further checks on its content are 1003 successful, the RS associates the authorization information from the 1004 Access Token with the Group OSCORE Security Context. 1006 In particular, the RS associates the authorization information from 1007 the Access Token with the 3-tuple (GID, SaltInput, AuthCred), where 1008 GID is the Group Identifier of the OSCORE Group, while SaltInput and 1009 AuthCred are the Sender ID and the authentication credential that the 1010 Client uses in that OSCORE group, respectively. 1012 The RS MUST keep this association up-to-date over time, as the 1013 3-tuple (GID, SaltInput, AuthCred) associated with the Access Token 1014 might change. In particular: 1016 * If the OSCORE group is rekeyed (see Section 3.2 of 1017 [I-D.ietf-core-oscore-groupcomm] and Section 20 of 1018 [I-D.ietf-ace-key-groupcomm-oscore]), the Group Identifier also 1019 changes in the group, and the new one replaces the current 'GID' 1020 value in the 3-tuple. 1022 * If the Client requests and obtains a new OSCORE Sender ID from the 1023 Group Manager (see Section 2.5.3.1 of 1024 [I-D.ietf-core-oscore-groupcomm] and Section 9 of 1025 [I-D.ietf-ace-key-groupcomm-oscore]), the new Sender ID replaces 1026 the current 'SaltInput' value in the 3-tuple. 1028 Finally, the RS MUST send a 2.01 (Created) response to the Client, as 1029 defined in Section 5.10.1 of [I-D.ietf-ace-oauth-authz]. 1031 4.3. Client-RS Secure Communication 1033 When previously joining the OSCORE group, both the Client and RS have 1034 already established the related Group OSCORE Security Context to 1035 communicate as group members. Therefore, they can simply start to 1036 securely communicate using Group OSCORE, without deriving any 1037 additional keying material or security association. 1039 4.3.1. Client Side 1041 After having received the 2.01 (Created) response from the RS, 1042 following the POST request to the authz-info endpoint, the Client 1043 starts the communication with the RS, by sending a request protected 1044 with Group OSCORE using the Group OSCORE Security Context 1045 [I-D.ietf-core-oscore-groupcomm]. 1047 When communicating with the RS to access the resources as specified 1048 by the authorization information, the Client MUST use the Group 1049 OSCORE Security Context of the OSCORE group, whose GID was specified 1050 in the 'context_id' parameter of the Token request. 1052 4.3.2. Resource Server Side 1054 After successful validation of the Access Token as defined in 1055 Section 4.2 and after having sent the 2.01 (Created) response, the RS 1056 can start to communicate with the Client using Group OSCORE 1057 [I-D.ietf-core-oscore-groupcomm]. 1059 When processing an incoming request protected with Group OSCORE, the 1060 RS MUST consider as valid Client's authentication credential only the 1061 one associated to the stored Access Token. As defined in 1062 Section 4.5, a possible change of authentication credential requires 1063 the Client to upload to the RS a new Access Token bound to the new 1064 authentication credential. 1066 Additionally, for every incoming request, if Group OSCORE 1067 verification succeeds, the verification of access rights is performed 1068 as described in Section 4.4. 1070 After the expiration of the Access Token related to a Group OSCORE 1071 Security Context, if the Client uses the Group OSCORE Security 1072 Context to send a request for any resource intended for OSCORE group 1073 members and that requires an active Access Token, the RS MUST respond 1074 with a 4.01 (Unauthorized) error message protected with the Group 1075 OSCORE Security Context. 1077 4.4. Access Rights Verification 1079 The RS MUST follow the procedures defined in Section 5.10.2 of 1080 [I-D.ietf-ace-oauth-authz]. If an RS receives a Group OSCORE- 1081 protected request from a Client, the RS processes it according to 1082 [I-D.ietf-core-oscore-groupcomm]. 1084 If the Group OSCORE verification succeeds, and the target resource 1085 requires authorization, the RS retrieves the authorization 1086 information from the Access Token associated with the Group OSCORE 1087 Security Context. Then, the RS MUST verify that the action requested 1088 on the resource is authorized. 1090 The response code MUST be 4.01 (Unauthorized) if the RS has no valid 1091 Access Token for the Client. If the RS has an Access Token for the 1092 Client but no actions are authorized on the target resource, the RS 1093 MUST reject the request with a 4.03 (Forbidden). If the RS has an 1094 Access Token for the Client but the requested action is not 1095 authorized, the RS MUST reject the request with a 4.05 (Method Not 1096 Allowed). 1098 4.5. Change of Client's Authentication Credential in the Group 1100 During its membership in the OSCORE group, the client might change 1101 the authentication credential it uses in the group. When this 1102 happens, the Client uploads the new authentication credential to the 1103 Group Manager, as defined in Section 11 of 1104 [I-D.ietf-ace-key-groupcomm-oscore]. 1106 After that, and in order to continue communicating with the RS, the 1107 Client MUST perform the following actions. 1109 1. The Client requests a new Access Token to the AS, as defined in 1110 Section 3. In particular, when sending the POST request as 1111 defined in Section 3.1, the Client indicates: 1113 * The current Group Identifier of the OSCORE group, as value of 1114 the 'context_id' parameter. 1116 * The current Sender ID it has in the OSCORE group, as value of 1117 the 'salt_input' parameter. 1119 * The public key of the new authentication credential it uses in 1120 the OSCORE group, as value of the 'req_cnf' parameter. In 1121 particular, the specified public key is the COSE Key 1122 equivalent to the new authentication credential that the 1123 Client uses in the OSCORE group. 1125 * The proof-of-possession (PoP) evidence corresponding to the 1126 public key of the new authentication credential, as value of 1127 the 'client_cred_verify' or 'client_cred_verify_mac' 1128 parameter. 1130 2. After receiving the response from the AS (see Section 3.2), the 1131 Client performs the same exchanges with the RS as defined in 1132 Section 4. 1134 When receiving the new Access Token, the RS performs the same steps 1135 defined in Section 4.2, with the following addition, in case the new 1136 Access Token is successfully verified and stored. The RS also 1137 deletes the old Access Token, i.e., the one whose associated 3-tuple 1138 has the same GID and SaltInput values as in the 3-tuple including the 1139 new authentication credential of the Client and associated with the 1140 new Access Token. 1142 5. Secure Communication with the AS 1144 As specified in the ACE framework (see Sections 5.8 and 5.9 of 1145 [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or Client) 1146 and the AS communicate via the /token or /introspection endpoint. 1147 The use of CoAP and OSCORE [RFC8613] for this communication is 1148 RECOMMENDED in this profile. Other protocols fulfilling the security 1149 requirements defined in Sections 5 and 6 of 1150 [I-D.ietf-ace-oauth-authz] (such as HTTP and DTLS or TLS) MAY be used 1151 instead. 1153 If OSCORE [RFC8613] is used, the requesting entity and the AS are 1154 expected to have a pre-established Security Context in place. How 1155 this Security Context is established is out of the scope of this 1156 profile. Furthermore, the requesting entity and the AS communicate 1157 using OSCORE through the /introspection endpoint as specified in 1158 Section 5.9 of [I-D.ietf-ace-oauth-authz], and through the /token 1159 endpoint as specified in Section 5.8 of [I-D.ietf-ace-oauth-authz]. 1161 6. Discarding the Security Context 1163 As members of an OSCORE group, the Client and the RS may 1164 independently leave the group or be forced to, e.g., if compromised 1165 or suspected so. Upon leaving the OSCORE group, the Client or RS 1166 also discards the Group OSCORE Security Context, which may anyway be 1167 renewed by the Group Manager through a group rekeying process (see 1168 Section 3.2 of [I-D.ietf-core-oscore-groupcomm]). 1170 The Client or RS can acquire a new Group OSCORE Security Context, by 1171 re-joining the OSCORE group, e.g., by using the approach defined in 1172 [I-D.ietf-ace-key-groupcomm-oscore]. In such a case, the Client 1173 SHOULD request a new Access Token and post it to the RS. 1175 7. CBOR Mappings 1177 The new parameters defined in this document MUST be mapped to CBOR 1178 types as specified in Figure 6, using the given integer abbreviation 1179 for the map key. 1181 /------------------------+----------+------------\ 1182 | Parameter name | CBOR Key | Value Type | 1183 |------------------------+----------+------------| 1184 | context_id | TBD | bstr | 1185 | salt_input | TBD | bstr | 1186 | client_cred_verify | TBD | bstr | 1187 | client_cred_verify_mac | TBD | bstr | 1188 \------------------------+----------+------------/ 1190 Figure 6: CBOR mappings for new parameters. 1192 The new claims defined in this document MUST be mapped to CBOR types 1193 as specified in Figure 7, using the given integer abbreviation for 1194 the map key. 1196 /-----------------+----------+------------\ 1197 | Claim name | CBOR Key | Value Type | 1198 |-----------------+----------+------------| 1199 | salt_input | TBD | bstr | 1200 | contextId_input | TBD | bstr | 1201 \-----------------+----------+------------/ 1203 Figure 7: CBOR mappings for new claims. 1205 8. Security Considerations 1207 This document specifies a profile for the Authentication and 1208 Authorization for Constrained Environments (ACE) framework 1209 [I-D.ietf-ace-oauth-authz]. Thus, the general security 1210 considerations from the ACE framework also apply to this profile. 1212 The proof-of-possession (PoP) key bound to an Access Token is always 1213 an asymmetric key, i.e., the public key that the Client uses in the 1214 OSCORE group. This means that there is never a same shared secret 1215 used as PoP key with possible multiple RSs. Therefore, it is 1216 possible and safe for the AS to issue an Access Token whose audience 1217 comprises multiple RSs. 1219 In such a case, as per Section 6.1 of [I-D.ietf-ace-oauth-authz], the 1220 AS has to ensure the integrity protection of the Access Token by 1221 protecting it through an asymmetric signature. In addition, the used 1222 audience has to correctly identify all the RSs that are intended 1223 recipients of the Access Token. As a particular case, the audience 1224 can be the name of the OSCORE group, if the Access Token is intended 1225 to all the RSs in that group. 1227 Furthermore, this document inherits the general security 1228 considerations about Group OSCORE [I-D.ietf-core-oscore-groupcomm], 1229 as to the specific use of Group OSCORE according to this profile. 1231 Group OSCORE is designed to secure point-to-point as well as point- 1232 to-multipoint communications, providing a secure binding between a 1233 single request and multiple corresponding responses. In particular, 1234 Group OSCORE fulfills the same security requirements of OSCORE, for 1235 group requests and responses. 1237 Group OSCORE ensures source authentication of messages both in group 1238 mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]) and in 1239 pairwise mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). 1241 When protecting an outgoing message in group mode, the sender uses 1242 its private key to compute a digital signature, which is embedded in 1243 the protected message. The group mode can be used to protect 1244 messages sent over multicast to multiple recipients, or sent over 1245 unicast to one recipient. 1247 When protecting an outgoing message in pairwise mode, the sender uses 1248 a pairwise symmetric key, as derived from the asymmetric keys of the 1249 two peers exchanging the message. The pairwise mode can be used to 1250 protect only messages intended to one recipient. 1252 9. Privacy Considerations 1254 This document specifies a profile for the Authentication and 1255 Authorization for Constrained Environments (ACE) framework 1256 [I-D.ietf-ace-oauth-authz]. Thus the general privacy considerations 1257 from the ACE framework also apply to this profile. 1259 As this profile uses Group OSCORE, the privacy considerations from 1260 [I-D.ietf-core-oscore-groupcomm] apply to this document as well. 1262 An unprotected response to an unauthorized request may disclose 1263 information about the RS and/or its existing relationship with the 1264 Client. It is advisable to include as little information as possible 1265 in an unencrypted response. However, since both the Client and the 1266 RS share a Group OSCORE Security Context, unauthorized, yet protected 1267 requests are followed by protected responses, which can thus include 1268 more detailed information. 1270 Although it may be encrypted, the Access Token is sent in the clear 1271 to the /authz-info endpoint at the RS. Thus, if the Client uses the 1272 same single Access Token from multiple locations with multiple 1273 Resource Servers, it can risk being tracked through the Access 1274 Token's value. 1276 Note that, even though communications are protected with Group 1277 OSCORE, some information might still leak, due to the observable 1278 size, source address and destination address of exchanged messages. 1280 10. IANA Considerations 1282 This document has the following actions for IANA. 1284 10.1. ACE Profile Registry 1286 IANA is asked to add the following entry to the "ACE Profile" 1287 registry defined in Section 8.8 of [I-D.ietf-ace-oauth-authz]. 1289 * Name: coap_group_oscore 1291 * Description: Profile to secure communications between constrained 1292 nodes using the Authentication and Authorization for Constrained 1293 Environments framework, by enabling authentication and fine- 1294 grained authorization of members of an OSCORE group, that use a 1295 pre-established Group OSCORE Security Context to communicate with 1296 Group OSCORE. Optionally, the dual mode defined in Appendix A 1297 additionally establishes a pairwise OSCORE Security Context, and 1298 thus also enables OSCORE communication between two members of the 1299 OSCORE group. 1301 * CBOR Value: TBD (value between 1 and 255) 1303 * Reference: [[this document]] 1305 10.2. OAuth Parameters Registry 1307 IANA is asked to add the following entries to the "OAuth Parameters" 1308 registry. 1310 * Name: "context_id" 1312 * Parameter Usage Location: token request 1314 * Change Controller: IESG 1316 * Specification Document(s): Section 3.1.1 of [[this document]] 1318 * Name: "salt_input" 1320 * Parameter Usage Location: token request 1322 * Change Controller: IESG 1324 * Specification Document(s): Section 3.1.2 of [[this document]] 1326 * Name: "client_cred_verify" 1328 * Parameter Usage Location: token request 1330 * Change Controller: IESG 1332 * Specification Document(s): Section 3.1.3 of [[this document]] 1334 * Name: "client_cred_verify_mac" 1336 * Parameter Usage Location: token request 1338 * Change Controller: IESG 1340 * Specification Document(s): Section 3.1.4 of [[this document]] 1342 * Name: "client_cred" 1344 * Parameter Usage Location: token request 1346 * Change Controller: IESG 1348 * Specification Document(s): Appendix A.2.1.1 of [[this document]] 1350 10.3. OAuth Parameters CBOR Mappings Registry 1352 IANA is asked to add the following entries to the "OAuth Parameters 1353 CBOR Mappings" registry defined in Section 8.10 of 1354 [I-D.ietf-ace-oauth-authz]. 1356 * Name: "context_id" 1358 * CBOR Key: TBD 1360 * Value Type: bstr 1362 * Reference: Section 3.1.1 of [[this document]] 1364 * Name: "salt_input" 1366 * CBOR Key: TBD 1368 * Value Type: bstr 1370 * Reference: Section 3.1.2 of [[this document]] 1372 * Name: "client_cred_verify" 1374 * CBOR Key: TBD 1376 * Value Type: bstr 1378 * Reference: Section 3.1.3 of [[this document]] 1380 * Name: "client_cred_verify_mac" 1382 * CBOR Key: TBD 1384 * Value Type: bstr 1386 * Reference: Section 3.1.4 of [[this document]] 1388 * Name: "client_cred" 1390 * CBOR Key: TBD 1392 * Value Type: bstr 1393 * Reference: Appendix A.2.1.1 of [[this document]] 1395 10.4. CBOR Web Token Claims Registry 1397 IANA is asked to add the following entries to the "CBOR Web Token 1398 Claims" registry. 1400 * Claim Name: "salt_input" 1402 * Claim Description: Client provided salt input 1404 * JWT Claim Name: "N/A" 1406 * Claim Key: TBD 1408 * Claim Value Type(s): bstr 1410 * Change Controller: IESG 1412 * Specification Document(s): Section 3.2.1 of [[this document]] 1414 * Claim Name: "contextId_input" 1416 * Claim Description: Client context id input 1418 * JWT Claim Name: "N/A" 1420 * Claim Key: TBD 1422 * Claim Value Type(s): bstr 1424 * Change Controller: IESG 1426 * Specification Document(s): Section 3.2.2 of [[this document]] 1428 * Claim Name: "client_cred" 1430 * Claim Description: Client Credential 1432 * JWT Claim Name: "N/A" 1434 * Claim Key: TBD 1436 * Claim Value Type(s): map 1438 * Change Controller: IESG 1439 * Specification Document(s): Appendix A.2.2.2 of [[this document]] 1441 10.5. TLS Exporter Label Registry 1443 IANA is asked to add the following entry to the "TLS Exporter Label" 1444 registry defined in Section 6 of [RFC5705] and updated in Section 12 1445 of [RFC8447]. 1447 * Value: EXPORTER-ACE-Sign-Challenge-Client-AS 1449 * DTLS-OK: Y 1451 * Recommended: N 1453 * Reference: [[this document]] (Section 3.1) 1455 11. References 1457 11.1. Normative References 1459 [I-D.ietf-ace-key-groupcomm-oscore] 1460 Tiloca, M., Park, J., and F. Palombini, "Key Management 1461 for OSCORE Groups in ACE", Work in Progress, Internet- 1462 Draft, draft-ietf-ace-key-groupcomm-oscore-13, 7 March 1463 2022, . 1466 [I-D.ietf-ace-oauth-authz] 1467 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1468 H. Tschofenig, "Authentication and Authorization for 1469 Constrained Environments (ACE) using the OAuth 2.0 1470 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 1471 draft-ietf-ace-oauth-authz-46, 8 November 2021, 1472 . 1475 [I-D.ietf-ace-oauth-params] 1476 Seitz, L., "Additional OAuth Parameters for Authorization 1477 in Constrained Environments (ACE)", Work in Progress, 1478 Internet-Draft, draft-ietf-ace-oauth-params-16, 7 1479 September 2021, . 1482 [I-D.ietf-ace-oscore-profile] 1483 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1484 "OSCORE Profile of the Authentication and Authorization 1485 for Constrained Environments Framework", Work in Progress, 1486 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 1487 2021, . 1490 [I-D.ietf-core-groupcomm-bis] 1491 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1492 for the Constrained Application Protocol (CoAP)", Work in 1493 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 1494 06, 7 March 2022, . 1497 [I-D.ietf-core-oscore-groupcomm] 1498 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 1499 and J. Park, "Group OSCORE - Secure Group Communication 1500 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 1501 core-oscore-groupcomm-14, 7 March 2022, 1502 . 1505 [I-D.ietf-cose-rfc8152bis-algs] 1506 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1507 Initial Algorithms", Work in Progress, Internet-Draft, 1508 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 1509 . 1512 [I-D.ietf-cose-rfc8152bis-struct] 1513 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1514 Structures and Process", Work in Progress, Internet-Draft, 1515 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 1516 . 1519 [NIST-800-56A] 1520 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 1521 Davis, "Recommendation for Pair-Wise Key-Establishment 1522 Schemes Using Discrete Logarithm Cryptography - NIST 1523 Special Publication 800-56A, Revision 3", April 2018, 1524 . 1527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1528 Requirement Levels", BCP 14, RFC 2119, 1529 DOI 10.17487/RFC2119, March 1997, 1530 . 1532 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1533 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1534 March 2010, . 1536 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1537 Key Derivation Function (HKDF)", RFC 5869, 1538 DOI 10.17487/RFC5869, May 2010, 1539 . 1541 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1542 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1543 . 1545 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1546 Keranen, A., and P. Hallam-Baker, "Naming Things with 1547 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1548 . 1550 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1551 Application Protocol (CoAP)", RFC 7252, 1552 DOI 10.17487/RFC7252, June 2014, 1553 . 1555 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1556 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1557 2016, . 1559 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1560 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1561 May 2017, . 1563 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1564 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1565 May 2018, . 1567 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1568 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1569 . 1571 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1572 "Object Security for Constrained RESTful Environments 1573 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1574 . 1576 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1577 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1578 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 1579 2020, . 1581 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1582 Representation (CBOR)", STD 94, RFC 8949, 1583 DOI 10.17487/RFC8949, December 2020, 1584 . 1586 11.2. Informative References 1588 [I-D.ietf-ace-dtls-authorize] 1589 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1590 L. Seitz, "Datagram Transport Layer Security (DTLS) 1591 Profile for Authentication and Authorization for 1592 Constrained Environments (ACE)", Work in Progress, 1593 Internet-Draft, draft-ietf-ace-dtls-authorize-18, 4 June 1594 2021, . 1597 [I-D.ietf-ace-mqtt-tls-profile] 1598 Sengul, C. and A. Kirby, "Message Queuing Telemetry 1599 Transport (MQTT)-TLS profile of Authentication and 1600 Authorization for Constrained Environments (ACE) 1601 Framework", Work in Progress, Internet-Draft, draft-ietf- 1602 ace-mqtt-tls-profile-15, 1 March 2022, 1603 . 1606 [I-D.ietf-cose-cbor-encoded-cert] 1607 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 1608 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 1609 Certificates)", Work in Progress, Internet-Draft, draft- 1610 ietf-cose-cbor-encoded-cert-03, 10 January 2022, 1611 . 1614 [I-D.ietf-tls-dtls13] 1615 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1616 Datagram Transport Layer Security (DTLS) Protocol Version 1617 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1618 dtls13-43, 30 April 2021, . 1621 [I-D.tiloca-core-oscore-discovery] 1622 Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of 1623 OSCORE Groups with the CoRE Resource Directory", Work in 1624 Progress, Internet-Draft, draft-tiloca-core-oscore- 1625 discovery-11, 7 March 2022, 1626 . 1629 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1630 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1631 January 2012, . 1633 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1634 Security (TLS) / Datagram Transport Layer Security (DTLS) 1635 Profiles for the Internet of Things", RFC 7925, 1636 DOI 10.17487/RFC7925, July 2016, 1637 . 1639 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1640 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1641 . 1643 Appendix A. Dual Mode (Group OSCORE & OSCORE) 1645 This appendix defines the dual mode of this profile, which allows 1646 using both OSCORE [RFC8613] and Group OSCORE 1647 [I-D.ietf-core-oscore-groupcomm] as security protocols, by still 1648 relying on a single Access Token. 1650 That is, the dual mode of this profile specifies how a Client uses 1651 CoAP [RFC7252] to communicate to a single Resource Server, or CoAP 1652 over IP multicast [I-D.ietf-core-groupcomm-bis] to communicate to 1653 multiple Resource Servers that are members of a group and share a 1654 common set of resources. 1656 In particular, the dual mode of this profile uses two complementary 1657 security protocols to provide secure communication between the Client 1658 and the Resource Server(s). That is, it defines the use of either 1659 OSCORE or Group OSCORE to protect unicast requests addressed to a 1660 single Resource Server, as well as possible responses. Additionally, 1661 it defines the use of Group OSCORE to protect multicast requests sent 1662 to a group of Resource Servers, as well as possible individual 1663 responses. Like in the main mode of this profile, the Client and the 1664 Resource Servers need to have already joined the same OSCORE group, 1665 for instance by using the approach defined in 1666 [I-D.ietf-ace-key-groupcomm-oscore], which is also based on ACE. 1668 The Client proves its access to be authorized to the Resource Server 1669 by using an Access Token, which is bound to a key (the proof-of- 1670 possession key). This profile mode uses OSCORE to achieve proof of 1671 possession, and OSCORE or Group OSCORE to achieve server 1672 authentication. 1674 Unlike in the main mode of this profile, where a public key is used 1675 as pop-key, this dual mode uses OSCORE-related, symmetric keying 1676 material as pop-key instead. Furthermore, this dual mode provides 1677 proof of Client's membership to the correct OSCORE group, by securely 1678 binding the pre-established Group OSCORE Security Context to the 1679 pairwise OSCORE Security Context newly established between the Client 1680 and the Resource Server. 1682 In addition to the terminology used for the main mode of this 1683 profile, the rest of this appendix refers also to "pairwise OSCORE 1684 Security Context" as to an OSCORE Security Context established 1685 between only one Client and one Resource Server, and used to 1686 communicate with OSCORE [RFC8613]. 1688 A.1. Protocol Overview 1690 This section provides an overview on how to use the ACE framework for 1691 authentication and authorization [I-D.ietf-ace-oauth-authz] to secure 1692 communications between a Client and a (set of) Resource Server(s) 1693 using OSCORE [RFC8613] and/or Group OSCORE 1694 [I-D.ietf-core-oscore-groupcomm]. 1696 Just as for main mode of this profile overviewed in Section 2, the 1697 process for joining the OSCORE group through the respective Group 1698 Manager as defined in [I-D.ietf-ace-key-groupcomm-oscore] must take 1699 place before the process described in the rest of this section, and 1700 is out of the scope of this profile. 1702 An overview of the protocol flow for the dual mode of this profile is 1703 shown in Figure 8. In the figure, it is assumed that both RS1 and 1704 RS2 are associated with the same AS. It is also assumed that C, RS1 1705 and RS2 have previously joined an OSCORE group with Group Identifier 1706 (gid) "abcd0000", and got assigned Sender ID (sid) "0", "1" and "2" 1707 in the group, respectively. The names of messages coincide with 1708 those of [I-D.ietf-ace-oauth-authz] when applicable. 1710 C RS1 RS2 AS 1711 | [--- Resource Request -->] | | | 1712 | | | | 1713 | [<---- AS Request ------] | | | 1714 | Creation Hints | | | 1715 | | | | 1716 |-------- POST /token ----------------------------------------------->| 1717 | (aud: RS1, sid: 0, gid: abcd0000, ...) | | 1718 | | | | 1719 |<-------------------------------- Access Token + RS Information -----| 1720 | | (aud: RS1, sid: 0, gid: abcd0000, ...) | 1721 | | | | 1722 |---- POST /authz-info ----->| | | 1723 | (access_token, N1, ID1) | | | 1724 | | | | 1725 |<-- 2.01 Created (N2, ID2) -| | | 1726 | | | | 1727 /Pairwise /Pairwise | | 1728 Security Context Security Context | | 1729 Derivation/ Derivation/ | | 1730 | | | | 1731 |-------- POST /token ----------------------------------------------->| 1732 | (aud: RS2, sid: 0, gid: abcd0000, ...) | | 1733 | | | | 1734 |<-------------------------------- Access Token + RS Information -----| 1735 | | (aud: RS2, sid: 0, gid: abcd0000, ...) | 1736 | | | | 1737 |---- POST /authz-info ------------------>| | 1738 | (access_token, N1', ID1') | | | 1739 | | | | 1740 |<-- 2.01 Created (N2', ID2')-------------| | 1741 | | | | 1742 /Pairwise Security | /Pairwise Security | 1743 Context Derivation/ | Context Derivation/ | 1744 | | | | 1745 |----- OSCORE Request ------>| | | 1746 | (kid: ID2) | | | 1747 | | | | 1748 | | | | 1749 | | | | 1750 | | | | 1751 | /Proof-of-possession; | | 1752 | Pairwise Security | | 1753 | Context storage/ | | 1754 | | | | 1755 |<---- OSCORE Response ------| | | 1756 | | | | 1757 /Proof-of-possession; | | | 1758 Pairwise Security | | | 1759 Context storage/ | | | 1760 | | | | 1761 /Mutual authentication | | | 1762 between C and RS1 | | | 1763 (as OSCORE peers)/ | | | 1765 | | | | 1766 | | | | 1767 |- Group OSCORE Request -+-->| | | 1768 | (kid: 0, gid: abcd0000) \-------------->| | 1769 | | | | 1770 |<-- Group OSCORE Response --| | | 1771 | (kid: 1) | | | 1772 | | | | 1773 /Mutual authentication | | | 1774 between C and RS1 | | | 1775 (as group members)/ | | | 1776 | | | | 1777 |<-- Group OSCORE Response ---------------| | 1778 | (kid: 2) | | | 1779 | | | | 1780 /Mutual authentication | | | 1781 between C and RS2 | | | 1782 (as group members)/ | | | 1783 | | | | 1784 | ... | | | 1786 Figure 8: Protocol Overview. 1788 A.1.1. Pre-Conditions 1790 The same pre-conditions for the main mode of this profile (see 1791 Section 2.1) hold for the dual mode described in this appendix. 1793 A.1.2. Access Token Posting 1795 After having retrieved the Access Token from the AS, the Client 1796 generates a nonce N1 and an identifier ID1 unique in the sets of its 1797 own Recipient IDs from its pairwise OSCORE Security Contexts. The 1798 client then posts both the Access Token, N1 and its chosen ID to the 1799 RS, using the /authz-info endpoint and mechanisms specified in 1800 Section 5.10 of [I-D.ietf-ace-oauth-authz] and Content-Format = 1801 application/ace+cbor. 1803 When using the dual mode of this profile, the communication with the 1804 authz-info endpoint is not protected, except for update of access 1805 rights. Note that, when using the dual mode, this request can 1806 alternatively be protected with Group OSCORE, using the Group OSCORE 1807 Security Context paired with the pairwise OSCORE Security Context 1808 originally established with the first Access Token posting. 1810 If the Access Token is valid, the RS replies to this POST request 1811 with a 2.01 (Created) response with Content-Format = application/ 1812 ace+cbor, which in a CBOR map contains a nonce N2 and an identifier 1813 ID2 unique in the sets of its own Recipient IDs from its pairwise 1814 OSCORE Security Contexts. 1816 A.1.3. Setup of the Pairwise OSCORE Security Context 1818 After sending the 2.01 (Created) response, the RS sets the ID Context 1819 of the pairwise OSCORE Security Context (see Section 3 of [RFC8613]) 1820 to the Group Identifier of the OSCORE group specified in the Access 1821 Token, concatenated with N1, concatenated with N2, concatenated with 1822 the value in the contextId parameter of the OSCORE_Input_Material 1823 provided in the 'cnf' claim of the Access Token. 1825 Then, the RS derives the complete pairwise OSCORE Security Context 1826 associated with the received Access Token, following Section 3.2 of 1827 [RFC8613]. In practice, the RS maintains a collection of Security 1828 Contexts with associated authorization information, for all the 1829 clients that it is currently communicating with, and the 1830 authorization information is a policy used as input when processing 1831 requests from those clients. 1833 During the derivation process, the RS uses: the ID Context above; the 1834 exchanged nonces N1 and N2; the identifier ID1 received from the 1835 Client, set as its own OSCORE Sender ID; the identifier ID2 provided 1836 to the Client, set as its Recipient ID for the Client; and the 1837 parameters in the Access Token. The derivation process uses also the 1838 Master Secret of the OSCORE group, that the RS knows as a group 1839 member, as well as the Sender ID of the Client in the OSCORE group, 1840 which is specified in the Access Token. This ensures that the 1841 pairwise OSCORE Security Context is securely bound to the Group 1842 OSCORE Security Context of the OSCORE group. 1844 Finally, the RS stores the association between i) the authorization 1845 information from the Access Token; and ii) the Group Identifier of 1846 the OSCORE group together with the Sender ID and the authentication 1847 credential of the Client in that group. 1849 After having received the nonce N2, the Client sets the ID Context in 1850 its pairwise OSCORE Security Context (see Section 3 of [RFC8613]) to 1851 the Group Identifier of the OSCORE group, concatenated with N1, 1852 concatenated with N2, concatenated with the value in the contextId 1853 parameter of the OSCORE_Input_Material provided in the 'cnf' 1854 parameter of the Access Token response from the AS. Then, the Client 1855 derives the complete pairwise OSCORE Security Context, following 1856 Section 3.2 of [RFC8613]. 1858 During the derivation process, the Client uses: the ID Context above, 1859 the exchanged nonces N1 and N2; the identifier ID1 provided to the 1860 RS, set as its own Recipient ID for the RS; the identifier ID2 1861 received from the RS, set as its own OSCORE Sender ID; and the 1862 parameters received from the AS. The derivation process uses also 1863 the Master Secret of the OSCORE group, that the Client knows as a 1864 group member, as well as its own Sender ID in the OSCORE group. 1866 When the Client communicates with the RS using the pairwise OSCORE 1867 Security Context, the RS achieves proof-of-possession of the 1868 credentials bound to the Access Token. Also, the RS verifies that 1869 the Client is a legitimate member of the OSCORE group. 1871 A.1.4. Secure Communication 1873 Other than starting the communication with the RS using Group OSCORE 1874 as described in Section 4.3, the Client can send to the RS a request 1875 protected with OSCORE, using the pairwise OSCORE Security Context. 1877 If the request is successfully verified, then the RS stores the 1878 pairwise OSCORE Security Context, and uses it to protect the possible 1879 response, as well as further communications with the Client, until 1880 the Access Token is deleted, due to, for example, expiration. This 1881 pairwise OSCORE Security Context is discarded when an Access Token 1882 (whether the same or different) is used to successfully derive a new 1883 pairwise OSCORE Security Context. 1885 As discussed in Section 7 of [I-D.ietf-ace-oscore-profile], the use 1886 of random nonces N1 and N2 during the exchange between the Client and 1887 the RS prevents the reuse of an Authenticated Encryption with 1888 Associated Data (AEAD) nonce/key pair for two different messages. 1889 Reuse might otherwise occur when Client and RS derive a new pairwise 1890 OSCORE Security Context from an existing (non-expired) Access Token, 1891 e.g., in case of reboot of either the Client or the RS, and might 1892 lead to loss of both confidentiality and integrity. 1894 Additionally, just as per the main mode of this profile (see 1895 Section 4.3), the Client and RS can also securely communicate by 1896 protecting messages with Group OSCORE, using the Group OSCORE 1897 Security Context already established upon joining the OSCORE group. 1899 A.2. Client-AS Communication 1901 This section details the Access Token POST Request that the Client 1902 sends to the /token endpoint of the AS, as well as the related Access 1903 Token response. 1905 Section 3.2 of [RFC8613] defines how to derive a pairwise OSCORE 1906 Security Context based on a shared Master Secret and a set of other 1907 parameters, established between the OSCORE client and server, which 1908 the client receives from the AS in this exchange. 1910 The proof-of-possession key (pop-key) received from the AS in this 1911 exchange MUST be used to build the Master Secret in OSCORE (see 1912 Appendix A.3.3 and Appendix A.3.4). 1914 A.2.1. C-to-AS: POST to Token Endpoint 1916 The Client-to-AS request is specified in Section 5.8.1 of 1917 [I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request 1918 to the /token endpoint over a secure channel that guarantees 1919 authentication, message integrity and confidentiality. 1921 The POST request is formatted as the analogous Client-to-AS request 1922 in the main mode of this profile (see Section 3.1), with the 1923 following modifications. 1925 * The parameter 'req_cnf' MUST NOT be included in the payload. 1927 * The parameter 'client_cred', defined in Appendix A.2.1.1 of this 1928 document, MUST be included in the payload. This parameter 1929 specifies the public key that the Client uses in the OSCORE group, 1930 whose identifier is indicated in the 'context_id' parameter. In 1931 particular, the specified public key is the COSE Key equivalent to 1932 the authentication credential that the Client uses in the OSCORE 1933 group. 1935 * The proof-of-possession (PoP) evidence included in the 1936 'client_cred_verify' or 'client_cred_verify_mac' parameter is 1937 computed by using the Client's private key associated with the 1938 public key in the 'client_cred' parameter above. 1940 An example of such a request is shown in Figure 9. 1942 Header: POST (Code=0.02) 1943 Uri-Host: "as.example.com" 1944 Uri-Path: "token" 1945 Content-Format: "application/ace+cbor" 1946 Payload: 1947 { 1948 "audience" : "tempSensor4711", 1949 "scope" : "read", 1950 "context_id" : h'abcd0000', 1951 "salt_input" : h'00', 1952 "client_cred" : { 1953 "COSE_Key" : { 1954 "kty" : EC2, 1955 "crv" : P-256, 1956 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 1957 27c9e354089bbe13', 1958 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 1959 731e79a3b4e47120' 1960 } 1961 }, 1962 "client_cred_verify" : h'...' 1963 (signature content omitted for brevity), 1964 } 1966 Figure 9: Example C-to-AS POST /token request for an Access Token 1967 bound to a symmetric key. 1969 Later on, the Client may want to update its current access rights, 1970 without changing the existing pairwise OSCORE Security Context with 1971 the RS. In this case, the Client MUST include in its POST request to 1972 the /token endpoint a 'req_cnf' parameter, defined in Section 3.1 of 1973 [I-D.ietf-ace-oauth-params], which MUST include a 'kid' field, as 1974 defined in Section 3.1 of [RFC8747]. The 'kid' field has as value a 1975 CBOR byte string containing the OSCORE_Input_Material Identifier 1976 (assigned as discussed in Appendix A.2.2). 1978 This identifier, together with other information such as audience, 1979 can be used by the AS to determine the shared secret bound to the 1980 proof-of-possession Access Token and therefore MUST identify a 1981 symmetric key that was previously generated by the AS as a shared 1982 secret for the communication between the Client and the RS. The AS 1983 MUST verify that the received value identifies a proof-of-possession 1984 key that has previously been issued to the requesting Client. If 1985 that is not the case, the Client-to-AS request MUST be declined with 1986 the error code "invalid_request" as defined in Section 5.8.3 of 1987 [I-D.ietf-ace-oauth-authz]. 1989 This POST request for updating the access rights of an Access Token 1990 SHOULD NOT include the parameters 'salt_input', 'context_id', 1991 'client_cred' and 'client_cred_verify'. An exception is the case 1992 defined in Appendix A.3.6, where the Client, following a change of 1993 authentication credential in the OSCORE group, requests a new Access 1994 Token associated with the public key of the new authentication 1995 credential, while still without changing the existing pairwise OSCORE 1996 Security Context with the RS. 1998 An example of such a request is shown in Figure 10. 2000 Header: POST (Code=0.02) 2001 Uri-Host: "as.example.com" 2002 Uri-Path: "token" 2003 Content-Format: "application/ace+cbor" 2004 Payload: 2005 { 2006 "audience" : "tempSensor4711", 2007 "scope" : "read", 2008 "req_cnf" : { 2009 "kid" : h'01' 2010 } 2011 } 2013 Figure 10: Example C-to-AS POST /token request for updating 2014 rights to an Access Token bound to a symmetric key. 2016 A.2.1.1. 'client_cred' Parameter 2018 The 'client_cred' parameter is an OPTIONAL parameter of the Access 2019 Token request message defined in Section 5.8.1. of 2020 [I-D.ietf-ace-oauth-authz]. This parameter provides an asymmetric 2021 key that the Client wishes to use as its own public key, but which is 2022 not used as proof-of-possession key. 2024 This parameter follows the syntax of the 'cnf' claim from Section 3.1 2025 of [RFC8747] when including Value Type "COSE_Key" (1) and specifying 2026 an asymmetric key. Alternative Value Types defined in future 2027 specifications are fine to consider if indicating a non-encrypted 2028 asymmetric key. 2030 A.2.2. AS-to-C: Access Token 2032 After having verified the POST request to the /token endpoint and 2033 that the Client is authorized to obtain an Access Token corresponding 2034 to its Access Token request, the AS MUST verify the proof-of- 2035 possession (PoP) evidence. 2037 In particular, the AS proceeds as defined in Section 3.2, with the 2038 difference that it uses the public key specified in the 'client_cred' 2039 parameter as public key of the Client. 2041 If both the 'client_cred_verify' and 'client_cred_verify_mac' 2042 parameters are present, or if the verification of the PoP evidence 2043 fails, the AS considers the Client request invalid. The AS does not 2044 perform this operation when asked to update a previously released 2045 Access Token. 2047 If all verifications are successful, the AS responds as defined in 2048 Section 5.8.2 of [I-D.ietf-ace-oauth-authz]. If the Client request 2049 was invalid, or not authorized, the AS returns an error response as 2050 described in Section 5.8.3 of [I-D.ietf-ace-oauth-authz]. 2052 The AS can signal that the use of OSCORE and Group OSCORE is REQUIRED 2053 for a specific Access Token by including the "ace_profile" parameter 2054 with the value "coap_group_oscore" in the Access Token response. 2055 This means that the Client MUST use OSCORE and/or Group OSCORE 2056 towards all the Resource Servers for which this Access Token is 2057 valid. 2059 In particular, the Client MUST follow Appendix A.3.3 to derive the 2060 pairwise OSCORE Security Context to use for communications with the 2061 RS. Instead, the Client has already established the related Group 2062 OSCORE Security Context to communicate with members of the OSCORE 2063 group, upon previously joining that group. 2065 Usually, it is assumed that constrained devices will be pre- 2066 configured with the necessary profile, so that this kind of profile 2067 signaling can be omitted. 2069 In contrast with the main mode of this profile, the Access Token 2070 response to the Client is analogous to the one in the OSCORE profile 2071 of ACE, as described in Section 3.2 of [I-D.ietf-ace-oscore-profile]. 2072 In particular, the AS provides an OSCORE_Input_Material object, which 2073 is defined in Section 3.2.1 of [I-D.ietf-ace-oscore-profile] and 2074 included in the 'cnf' parameter (see Section 3.2 of 2075 [I-D.ietf-ace-oauth-params]) of the Access Token response. 2077 The AS MUST send different OSCORE_Input_Material (and therefore 2078 different Access Tokens) to different authorized clients, in order 2079 for the RS to differentiate between clients. 2081 In the issued Access Token, the AS MUST include as metadata the same 2082 information as defined in the main mode of this profile (see 2083 Section 3.2) with the following modifications. 2085 * The public key that the client uses in the OSCORE group and 2086 specified in the 'client_cred' parameter of the Token request (see 2087 Appendix A.2.1) MUST also be included in the Access Token. 2089 If the Access Token is a CWT, the AS MUST include it in the 2090 'client_cred' claim of the Access Token, defined in 2091 Appendix A.2.2.2 of this document. In particular, the 2092 'client_cred' claim includes the same COSE Key specified in the 2093 'client_cred' parameter of the Token Request, i.e., the COSE Key 2094 equivalent to the authentication credential that the Client uses 2095 in the OSCORE group. 2097 * The OSCORE_Input_Material specified in the 'cnf' parameter of the 2098 Access Token response MUST also be included in the Access Token. 2099 If the Access Token is a CWT, the same OSCORE_Input_Material 2100 included in the 'cnf' parameter of the Access Token response MUST 2101 be included in the 'osc' field of the 'cnf' claim of the Access 2102 Token (see Section 3.2 of [I-D.ietf-ace-oscore-profile]). 2104 Figure 11 shows an example of such an AS response. The access token 2105 has been truncated for readability. 2107 Header: Created (Code=2.01) 2108 Content-Type: "application/ace+cbor" 2109 Payload: 2110 { 2111 "access_token" : h'8343a1010aa2044c53 ...' 2112 (remainder of CWT omitted for brevity), 2113 "ace_profile" : "coap_group_oscore", 2114 "expires_in" : 3600, 2115 "cnf" : { 2116 "osc" : { 2117 "alg" : AES-CCM-16-64-128, 2118 "id" : h'01', 2119 "ms" : h'f9af838368e353e78888e1426bd94e6f', 2120 "salt" : h'1122', 2121 "contextId" : h'99' 2122 } 2123 } 2124 } 2126 Figure 11: Example AS-to-C Access Token response with the Group 2127 OSCORE profile. 2129 Figure 12 shows an example CWT, containing the necessary OSCORE 2130 parameters in the 'cnf' claim. 2132 { 2133 "aud" : "tempSensorInLivingRoom", 2134 "iat" : 1360189224, 2135 "exp" : 1360289224, 2136 "scope" : "temperature_g firmware_p", 2137 "cnf" : { 2138 "osc" : { 2139 "alg" : AES-CCM-16-64-128, 2140 "id" : h'01', 2141 "ms" : h'f9af838368e353e78888e1426bd94e6f', 2142 "salt" : h'1122', 2143 "contextId" : h'99' 2144 }, 2145 "salt_input" : h'00', 2146 "contextId_input" : h'abcd0000', 2147 "client_cred" : { 2148 "COSE_Key" : { 2149 "kty" : EC2, 2150 "crv" : P-256, 2151 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 2152 27c9e354089bbe13', 2153 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 2154 731e79a3b4e47120' 2155 } 2156 } 2157 } 2159 Figure 12: Example CWT with OSCORE parameters. 2161 The same CWT as in Figure 12 and encoded in CBOR is shown in 2162 Figure 13, using the value abbreviations defined in 2163 [I-D.ietf-ace-oauth-authz] and [RFC8747]. 2165 NOTE: it should be checked (and in case fixed) that the values used 2166 below (which are not yet registered) are the final values registered 2167 in IANA. 2169 A8 # map(8) 2170 03 # unsigned(3) 2171 76 # text(22) 2172 74656D7053656E736F72496E4C6976696E67526F6F6D 2173 06 # unsigned(6) 2174 1A 5112D728 # unsigned(1360189224) 2175 04 # unsigned(4) 2176 1A 51145DC8 # unsigned(1360289224) 2177 09 # unsigned(9) 2178 78 18 # text(24) 2179 74656D70657261747572655F67206669726D776172655F70 2181 08 # unsigned(8) 2182 A1 # map(1) 2183 04 # unsigned(4) 2184 A5 # map(5) 2185 04 # unsigned(4) 2186 0A # unsigned(10) 2187 00 # unsigned(0) 2188 41 # bytes(1) 2189 01 # "\x01" 2190 02 # unsigned(2) 2191 50 # bytes(16) 2192 F9AF838368E353E78888E1426BD94E6F 2193 05 # unsigned(5) 2194 42 # bytes(2) 2195 1122 # "\x11\"" 2196 06 # unsigned(6) 2197 41 # bytes(1) 2198 99 # "\x99" 2199 18 3C # unsigned(60) 2200 41 # bytes(1) 2201 00 2202 18 3D # unsigned(61) 2203 44 # bytes(4) 2204 ABCD0000 2205 18 3E # unsigned(62) 2206 A1 # map(1) 2207 01 # unsigned(1) 2208 A4 # map(4) 2209 01 # unsigned(1) 2210 02 # unsigned(2) 2211 20 # negative(0) 2212 01 # unsigned(1) 2213 21 # negative(1) 2214 58 20 # bytes(32) 2215 D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9 2216 E354089BBE13 2217 22 # negative(2) 2218 58 20 # bytes(32) 2219 F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E515D020731E 2220 79A3B4E47120 2222 Figure 13: Example CWT with OSCORE parameters. 2224 If the Client has requested an update to its access rights using the 2225 same pairwise OSCORE Security Context, which is valid and authorized, 2226 the AS MUST omit the 'cnf' parameter in the response to the client. 2228 Instead, the updated Access Token conveyed in the AS-to-C response 2229 MUST include a 'cnf' claim specifying a 'kid' field, as defined in 2230 Section 3.1 of [RFC8747]. The response from the AS MUST carry the 2231 OSCORE Input Material identifier in the 'kid' field within the 'cnf' 2232 claim of the Access Token. That is, the 'kid' field is a CBOR byte 2233 string, with value the same value of the 'kid' field of the 'req_cnf' 2234 parameter from the C-to-AS request for updating rights to the Access 2235 Token (see Figure 10). This information needs to be included in the 2236 Access Token, in order for the RS to identify the previously 2237 generated pairwise OSCORE Security Context. 2239 Figure 14 shows an example of such an AS response. The Access Token 2240 has been truncated for readability. 2242 Header: Created (Code=2.01) 2243 Content-Type: "application/ace+cbor" 2244 Payload: 2245 { 2246 "access_token" : h'8343a1010aa2044c53 ...' 2247 (remainder of CWT omitted for brevity), 2248 "profile" : "coap_group_oscore", 2249 "expires_in" : 3600 2250 } 2252 Figure 14: Example AS-to-C Access Token response with the Group 2253 OSCORE profile, for update of access rights. 2255 Figure 15 shows an example CWT, containing the necessary OSCORE 2256 parameters in the 'cnf' claim for update of access rights. 2258 { 2259 "aud" : "tempSensorInLivingRoom", 2260 "iat" : 1360189224, 2261 "exp" : 1360289224, 2262 "scope" : "temperature_h", 2263 "cnf" : { 2264 "kid" : h'01' 2265 } 2266 } 2268 Figure 15: Example CWT with OSCORE parameters for update of 2269 access rights. 2271 A.2.2.1. Public Key Hash as Client Credential 2273 As a possible optimization to limit the size of the Access Token, the 2274 AS may specify as value of the 'client_cred' claim simply the hash of 2275 the Client's public key, i.e., the hash of the COSE Key K equivalent 2276 to the authentication credential that the Client uses in the OSCORE 2277 group. 2279 The specifically used hash-function MUST be collision-resistant on 2280 byte-strings, and MUST be selected from the "Named Information Hash 2281 Algorithm" Registry defined in Section 9.4 of [RFC6920]. 2283 In particular, the AS provides the Client with an Access Token as 2284 defined in Appendix A.2.2, with the following differences. 2286 The AS prepares INPUT_HASH as follows, with | denoting byte string 2287 concatenation. 2289 * If the equivalent COSE Key K has COSE Key Type OKP, INPUT_HASH = 2290 i, where 'i' is the x-parameter of the COSE_Key specified in the 2291 'client_cred' parameter of the Token request, encoded as a CBOR 2292 byte string. 2294 * If the equivalent COSE Key K has COSE Key Type EC2, INPUT_HASH = 2295 (i_1 | i_2), where 'i_1' and 'i_2' are the x-parameter and 2296 y-parameter of the COSE_Key specified in the 'client_cred' 2297 parameter of the Token request, respectively, each encoded as a 2298 CBOR byte string. 2300 * If the equivalent COSE Key K has COSE Key Type RSA, INPUT_HASH = 2301 (i_1 | i_2), where 'i_1' and 'i_2' are the n-parameter and 2302 e-parameter of the COSE_Key specified in the 'client_cred' 2303 parameter of the Token request, respectively, each encoded as a 2304 CBOR byte string. 2306 Then, the AS hashes INPUT_HASH according to the procedure described 2307 in [RFC6920], with the output OUTPUT_HASH in binary format, as 2308 described in Section 6 of [RFC6920]. 2310 Finally, the AS includes a single entry within the 'client_cred' 2311 claim of the Access Token. This entry has label "kid" (3) defined in 2312 Section 3.1 of [RFC8747], and value a CBOR byte string wrapping 2313 OUTPUT_HASH. 2315 Upon receiving the Access Token, the RS processes it according to 2316 Appendix A.3.2, with the following differences. 2318 The RS considers: the content of the 'contextId_input' claim as the 2319 GID of the OSCORE group; the content of the 'salt_input' claim as the 2320 Sender ID that the Client has in the group; and the content of the 2321 'client_cred' claim as the hash RECEIVED_HASH of a COSE Key 2322 equivalent to the authentication credential that the Client uses in 2323 the group. 2325 The RS MUST check whether it already stores an authentication 2326 credential associated with the pair (GID, Sender ID) above, such that 2327 the recomputed hash NEW_HASH of its equivalent COSE Key matches with 2328 RECEIVED_HASH from the 'client_cred' claim. 2330 If this is not the case, the RS MUST request the Client's 2331 authentication credential to the Group Manager of the OSCORE group as 2332 described in Section 10 of [I-D.ietf-ace-key-groupcomm-oscore], 2333 specifying the Client's Sender ID in the OSCORE group, i.e., the 2334 value of the 'salt_input' claim. Then, the RS performs the following 2335 actions. 2337 * The RS MUST check whether RECEIVED_HASH matches with the 2338 recomputed hash NEW_HASH of a COSE Key equivalent to the Client's 2339 authentication credential retrieved from the Group Manager. 2341 * The RS MUST check that the Client's Sender ID provided by the 2342 Group Manager together with the Client's authentication credential 2343 matches the one retrieved from the 'salt_input' claim of the 2344 Access Token. 2346 The RS MUST calculate NEW_HASH using the same method used by the AS 2347 described above, and using the same hash function. The hash function 2348 to use can be determined from the information conveyed in the 2349 'client_cred' claim, as the procedure described in [RFC6920] also 2350 encodes the used hash function as metadata of the hash value. 2352 A.2.2.2. Client Credential Claim 2354 The 'client_cred' claim provides an asymmetric key that the Client 2355 owning the Access Token wishes to use as its own public key, but 2356 which is not used as proof-of-possession key. 2358 This parameter follows the syntax of the 'cnf' claim from Section 3.1 2359 of [RFC8747] when including Value Type "COSE_Key" (1) and specifying 2360 an asymmetric key. Alternative Value Types defined in future 2361 specifications are fine to consider, if indicating a non-encrypted 2362 asymmetric key or full-fledged autentication credential. 2364 A.3. Client-RS Communication 2366 This section details the POST request and response to the /authz-info 2367 endpoint between the Client and the RS. With respect to the 2368 exchanged messages and their content, the Client and the RS perform 2369 as defined in the OSCORE profile of ACE (see Section 4 of 2370 [I-D.ietf-ace-oscore-profile]). 2372 That is, the Client generates a nonce N1 and posts it to the RS, 2373 together with: an identifier ID1 unique in the sets of its own 2374 Recipient IDs from its pairwise OSCORE Security Contexts; and the 2375 Access Token that includes the material provisioned by the AS. 2377 Then, the RS generates a nonce N2, and an identifier ID2 unique in 2378 the sets of its own Recipient IDs from its pairwise OSCORE Security 2379 Contexts. After that, the RS derives a pairwise OSCORE Security 2380 Context as described in Section 3.2 of [RFC8613]. In particular, it 2381 uses the two exchanged nonces and the two identifiers established 2382 with the Client, as well as two shared secrets together with 2383 additional pieces of information specified in the Access Token. 2385 Both the client and the RS generate the pairwise OSCORE Security 2386 Context using the pop-key as part of the OSCORE Master Secret. In 2387 addition, the derivation of the pairwise OSCORE Security Context 2388 takes as input also information related to the OSCORE group, i.e., 2389 the Master Secret and Group Identifier of the group, as well as the 2390 Sender ID of the Client in the group. Hence, the derived pairwise 2391 OSCORE Security Context is also securely bound to the Group OSCORE 2392 Security Context of the OSCORE Group. Thus, the proof-of-possession 2393 required to bind the Access Token to the Client occurs after the 2394 first OSCORE message exchange. 2396 Therefore, an attacker using a stolen Access Token cannot generate a 2397 valid pairwise OSCORE Security Context and thus cannot prove 2398 possession of the pop-key. Also, if a Client legitimately owns an 2399 Access Token but has not joined the OSCORE group, that Client cannot 2400 generate a valid pairwise OSCORE Security Context either, since it 2401 lacks the Master Secret used in the OSCORE group. 2403 Besides, just as in the main mode (see Section 4), the RS is able to 2404 verify whether the Client has indeed the claimed Sender ID and 2405 authentication credential in the OSCORE group. 2407 A.3.1. C-to-RS POST to authz-info Endpoint 2409 The Client MUST generate a nonce N1, an OSCORE Recipient ID (ID1), 2410 and post them to the /authz-info endpoint of the RS together with the 2411 Access Token, as defined in the OSCORE profile of ACE (see 2412 Section 4.1 of [I-D.ietf-ace-oscore-profile]). 2414 The same recommendations, considerations and behaviors defined in 2415 Section 4.1 of [I-D.ietf-ace-oscore-profile] hold. 2417 If the Client has already posted a valid Access Token, has already 2418 established a pairwise OSCORE Security Context with the RS, and wants 2419 to update its access rights, the Client can do so by posting the new 2420 Access Token (retrieved from the AS and specifying the updated set of 2421 access rights) to the /authz-info endpoint. 2423 The Client MUST protect the request using either the pairwise OSCORE 2424 Security Context established during the first Access Token exchange, 2425 or the Group OSCORE Security Context associated with that pairwise 2426 OSCORE Security Context. 2428 In either case, the Client MUST only send the Access Token in the 2429 payload, i.e., no nonce or identifier are sent. After proper 2430 verification (see Section 4.2 of [I-D.ietf-ace-oscore-profile]), the 2431 new Access Token will supersede the old one at the RS, by replacing 2432 the corresponding authorization information. At the same time, the 2433 RS will maintain the same pairwise OSCORE Security Context and Group 2434 OSCORE Security Context, as now both associated with the new Access 2435 Token. 2437 A.3.2. RS-to-C: 2.01 (Created) 2439 The RS MUST verify the validity of the Access Token as defined in 2440 Section 4.2, with the following modifications. 2442 * If the POST request to /authz-info is not protected, the RS checks 2443 that the 'cnf' claim is included in the Access Token and that it 2444 contains an OSCORE_Input_Material object. Also, the RS checks 2445 that the 'salt_input', 'client_cred' and 'contextId_input' claims 2446 are included in the Access Token. 2448 * If the POST request to /authz-info is protected with the pairwise 2449 OSCORE Security Context shared with the Client or with the Group 2450 OSCORE Security Context of the OSCORE group, i.e., the Client is 2451 requesting an update of access rights, the RS checks that the 2452 'cnf' claim is included in the Access Token and that it contains 2453 only the 'kid' field. 2455 * If the 'salt_input', 'client_cred' and 'contextId_input' claims 2456 are included in the Access Token, the RS extracts the content of 2457 'client_cred'. Then, the RS considers that content as the COSE 2458 Key equivalent to the authentication credential that the Client 2459 uses in the group, whose GID is specified in the 'contextId_input' 2460 claim. The RS can compare this public key with the actual COSE 2461 Key equivalent to the authentication credential of the claimed 2462 Client, retrieved from its local storage or from the Group Manager 2463 (see Section 4.2). 2465 If any of the checks fails, the RS MUST consider the Access Token non 2466 valid, and MUST respond to the Client with an error response code 2467 equivalent to the CoAP code 4.00 (Bad Request). 2469 If the Access Token is valid and further checks on its content are 2470 successful, the RS proceeds as follows. 2472 In case the POST request to /authz-info was not protected, the RS 2473 MUST generate a nonce N2, an OSCORE Recipient ID (ID2), and include 2474 them in the 2.01 (Created) response to the Client, as defined in the 2475 OSCORE profile of ACE (see Section 4.2 of 2476 [I-D.ietf-ace-oscore-profile]). 2478 Instead, in case the POST request to /authz-info was protected, the 2479 RS MUST ignore any nonce and identifiers in the request, if any was 2480 sent. Then, the RS MUST check that the 'kid' field of the 'cnf' 2481 claim in the new Access Token matches the identifier of the OSCORE 2482 Input Material of a pairwise OSCORE Security Context such that: 2484 * The pairwise OSCORE Security Context was used to protect the 2485 request, if this was protected with OSCORE; or 2487 * The pairwise OSCORE Security Context is bound to the Group OSCORE 2488 Security Context used to protect the request, if this was 2489 protected with Group OSCORE. 2491 If either verification is successful, the new Access Token supersedes 2492 the old one at the RS. Besides, the RS associates the new Access 2493 Token to the same pairwise OSCORE Security Context identified above, 2494 as also bound to a Group OSCORE Security Context. The RS MUST 2495 respond with a 2.01 (Created) response with no payload, protected 2496 with the same Security Context used to protect the request. In 2497 particular, no new pairwise OSCORE Security Context is established 2498 between the Client and the RS. If any verification fails, the RS 2499 MUST respond with a 4.01 (Unauthorized) error response. 2501 Further recommendations, considerations and behaviors defined in 2502 Section 4.2 of [I-D.ietf-ace-oscore-profile] hold for this document. 2504 A.3.3. OSCORE Setup - Client Side 2506 Once having received the 2.01 (Created) response from the RS, 2507 following an unprotected POST request to the /authz-info endpoint, 2508 the Client MUST extract the nonce N2 from the 'nonce2' parameter, and 2509 the Client identifier from the 'ace_server_recipientid' parameter in 2510 the CBOR map of the response payload. Note that this identifier is 2511 used by C as Sender ID in the pairwise OSCORE Security Context to be 2512 established with the RS, and is different as well as unrelated to the 2513 Sender ID of C in the OSCORE group. 2515 Then, the Client performs the following actions, in order to set up 2516 and fully derive the pairwise OSCORE Security Context for 2517 communicating with the RS. 2519 * The Client MUST set the ID Context of the pairwise OSCORE Security 2520 Context as the concatenation of: i) GID, i.e., the Group 2521 Identifier of the OSCORE group, as specified by the Client in the 2522 'context_id' parameter of the Client-to-AS request; ii) the nonce 2523 N1; iii) the nonce N2; and iv) CID, i.e., the value in the 2524 contextId parameter of the OSCORE_Input_Material provided in the 2525 'cnf' parameter of the Access Token response from the AS. The 2526 concatenation occurs in this order: ID Context = GID | N1 | N2 | 2527 CID, where | denotes byte string concatenation. 2529 * The Client MUST set the updated Master Salt of the pairwise OSCORE 2530 Security Context as the concatenation of SaltInput, MSalt, the 2531 nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the 2532 Sender ID that the Client has in the OSCORE group, which is known 2533 to the Client as a member of the OSCORE group; ii) MSalt is the 2534 (optional) Master Salt in the pairwise OSCORE Security Context 2535 (received from the AS in the Token); and iii) GMSalt is the 2536 (optional) Master Salt in the Group OSCORE Security Context, which 2537 is known to the Client as a member of the OSCORE group. The 2538 concatenation occurs in this order: Master Salt = SaltInput | 2539 MSalt | N1 | N2 | GMSalt, where | denotes byte string 2540 concatenation. Optional values, if not specified, are not 2541 included in the concatenation. The five parameters SaltInput, 2542 MSalt, N1, N2 and GMSalt are to be concatenated as encoded CBOR 2543 byte strings. An example of Master Salt construction using CBOR 2544 encoding is given in Figure 16. 2546 SaltInput, MSalt, N1, N2 and GMSalt, in CBOR diagnostic notation: 2547 SaltInput = h'00' 2548 MSalt = h'f9af838368e353e78888e1426bd94e6f' 2549 N1 = h'018a278f7faab55a' 2550 N2 = h'25a8991cd700ac01' 2551 GMSalt = h'99' 2553 SaltInput, MSalt, N1, N2 and GMSalt, as CBOR encoded byte strings: 2554 SaltInput = 0x4100 2555 MSalt = 0x50f9af838368e353e78888e1426bd94e6f 2556 N1 = 0x48018a278f7faab55a 2557 N2 = 0x4825a8991cd700ac01 2558 GMSalt = 0x4199 2560 Master Salt = 0x41 00 2561 50 f9af838368e353e78888e1426bd94e6f 2562 48 018a278f7faab55a 2563 48 25a8991cd700ac01 2564 41 99 2566 Figure 16: Example of Master Salt construction using CBOR encoding. 2568 * The Client MUST set the Master Secret of the pairwise OSCORE 2569 Security Context to the concatenation of MSec and GMSec, where: i) 2570 MSec is the value of the 'ms' parameter in the 2571 OSCORE_Input_Material of the 'cnf' parameter, received from the AS 2572 in Appendix A.2.2; while ii) GMSec is the Master Secret of the 2573 Group OSCORE Security Context, which is known to the Client as a 2574 member of the OSCORE group. 2576 * The Client MUST set the Recipient ID as ace_client_recipientid, 2577 sent as described in Appendix A.3.1. 2579 * The Client MUST set the Sender ID as ace_server_recipientid, 2580 received as described in Appendix A.3.1. 2582 * The Client MUST set the AEAD Algorithm, ID Context, HKDF, and 2583 OSCORE Version as indicated in the corresponding parameters 2584 received from the AS in Appendix A.2.2, if present in the 2585 OSCORE_Input_Material of the 'cnf' parameter. In case these 2586 parameters are omitted, the default values SHALL be used as 2587 described in Sections 3.2 and 5.4 of [RFC8613]. 2589 Finally, the client MUST derive the complete pairwise OSCORE Security 2590 Context following Section 3.2.1 of [RFC8613]. 2592 From then on, when communicating with the RS to access the resources 2593 as specified by the authorization information, the Client MUST use 2594 the newly established pairwise OSCORE Security Context or the Group 2595 OSCORE Security Context of the OSCORE Group where both the Client and 2596 the RS are members. 2598 If any of the expected parameters is missing (e.g., any of the 2599 mandatory parameters from the AS or the RS), or if 2600 ace_client_recipientid equals ace_server_recipientid (and as a 2601 consequence the Sender and Recipient Keys derived would be equal, see 2602 Section 3.3 of [RFC8613]), then the client MUST stop the exchange, 2603 and MUST NOT derive the pairwise OSCORE Security Context. The Client 2604 MAY restart the exchange, to get the correct security input material. 2606 The Client can use this pairwise OSCORE Security Context to send 2607 requests to the RS protected with OSCORE. Besides, the Client can 2608 use the Group OSCORE Security Context for protecting unicast requests 2609 to the RS, or multicast requests to the OSCORE group including also 2610 the RS. Mutual authentication as group members is only achieved 2611 after the client has successfully verified the Group OSCORE protected 2612 response from the RS. Similarly, mutual authentication as OSCORE 2613 peers is only achieved after the client has successfully verified the 2614 OSCORE protected response from the RS, using the pairwise OSCORE 2615 Security Context. 2617 Note that the ID Context of the pairwise OSCORE Security Context can 2618 be assigned by the AS, communicated and set in both the RS and Client 2619 after the exchange specified in this profile is executed. 2620 Subsequently, the Client and RS can update their ID Context by 2621 running a mechanism such as the one defined in Appendix B.2 of 2622 [RFC8613] if they both support it and are configured to do so. In 2623 that case, the ID Context in the pairwise OSCORE Security Context 2624 will not match the "contextId" parameter of the corresponding 2625 OSCORE_Input_Material. Running the procedure in Appendix B.2 of 2626 [RFC8613] results in the keying material in the pairwise OSCORE 2627 Security Contexts of the Client and RS being updated. The Client can 2628 achieve the same result by re-posting the Access Token to the 2629 unprotected /authz-info endpoint at the RS, as described in 2630 Section 4.1 of [I-D.ietf-ace-oscore-profile], although without 2631 updating the ID Context. 2633 A.3.4. OSCORE Setup - Resource Server Side 2635 After validation of the Access Token as defined in Appendix A.3.2 and 2636 after sending the 2.01 (Created) response to an unprotected POST 2637 request to the /authz-info endpoint, the RS performs the following 2638 actions, in order to set up and fully derive the pairwise OSCORE 2639 Security Context created to communicate with the Client. 2641 * The RS MUST set the ID Context of the pairwise OSCORE Security 2642 Context as the concatenation of: i) GID, i.e., the Group 2643 Identifier of the OSCORE group, as specified in the 'contextId' 2644 parameter of the OSCORE_Input_Material, in the 'cnf' claim of the 2645 Access Token received from the Client (see Appendix A.3.1); ii) 2646 the nonce N1; iii) the nonce N2; and iv) CID which is the value in 2647 the contextId parameter of the OSCORE_Input_Material provided in 2648 the 'cnf' claim of the Access Token. The concatenation occurs in 2649 this order: ID Context = GID | N1 | N2 | CID, where | denotes byte 2650 string concatenation. 2652 * The RS MUST set the new Master Salt of the pairwise OSCORE 2653 Security Context as the concatenation of SaltInput, MSalt, the 2654 nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the 2655 Sender ID that the Client has in the OSCORE group, as specified in 2656 the 'salt_input' claim included in the Access Token received from 2657 the Client (see Appendix A.3.1); ii) MSalt is the (optional) 2658 Master Salt in the pairwise OSCORE Security Context as specified 2659 in the 'salt' parameter in the OSCORE_Input_Material of the 'cnf' 2660 claim, included in the Access Token received from the Client; and 2661 iii) GMSalt is the (optional) Master Salt in the Group OSCORE 2662 Security Context, which is known to the RS as a member of the 2663 OSCORE group. The concatenation occurs in this order: Master Salt 2664 = SaltInput | MSalt | N1 | N2 | GMSalt, where | denotes byte 2665 string concatenation. Optional values, if not specified, are not 2666 included in the concatenation. The same considerations for 2667 building the Master Salt, considering the inputs as encoded CBOR 2668 byte strings as in Figure 16, hold also for the RS. 2670 * The RS MUST set the Master Secret of the pairwise OSCORE Security 2671 Context to the concatenation of MSec and GMSec, where: i) MSec is 2672 the value of the 'ms' parameter in the OSCORE_Input_Material of 2673 the 'cnf' claim, included in the Access Token received from the 2674 Client (see Appendix A.3.1); while ii) GMSec is the Master Secret 2675 of the Group OSCORE Security Context, which is known to the RS as 2676 a member of the OSCORE group. 2678 * The RS MUST set the Recipient ID as ace_server_recipientid, sent 2679 as described in Appendix A.3.2. 2681 * The RS MUST set the Sender ID as ace_client_recipientid, received 2682 as described in Appendix A.3.2. 2684 * The RS MUST set the AEAD Algorithm, ID Context, HKDF, and OSCORE 2685 Version from the corresponding parameters received from the Client 2686 in the Access Token (see Appendix A.3.1), if present in the 2687 OSCORE_Input_Material of the 'cnf' claim. In case these 2688 parameters are omitted, the default values SHALL be used as 2689 described in Sections 3.2 and 5.4 of [RFC8613]. 2691 Finally, the RS MUST derive the complete pairwise OSCORE Security 2692 Context following Section 3.2.1 of [RFC8613]. 2694 Once having completed the derivation above, the RS MUST associate the 2695 authorization information from the Access Token with the just 2696 established pairwise OSCORE Security Context. Furthermore, as 2697 defined in Section 4.2, the RS MUST associate the authorization 2698 information from the Access Token with the Group OSCORE Security 2699 Context. 2701 Then, the RS uses this pairwise OSCORE Security Context to verify 2702 requests from and send responses to the Client protected with OSCORE, 2703 when this Security Context is used. If OSCORE verification fails, 2704 error responses are used, as specified in Section 8 of [RFC8613]. 2706 Besides, the RS uses the Group OSCORE Security Context to verify 2707 (multicast) requests from and send responses to the Client protected 2708 with Group OSCORE. When processing an incoming request protected 2709 with Group OSCORE, the RS MUST consider as valid authentication 2710 credential of the Client only the authentication credential 2711 associated with the stored Access Token. As defined in 2712 Appendix A.3.6, a change of authentication credential in the group 2713 requires the Client to upload to the RS a new Access Token, where the 2714 'client_cred' claim specifies a COSE Key equivalent to the new 2715 authentication credential that the Client has in the group. 2717 If Group OSCORE verification fails, error responses are used, as 2718 specified in Sections 8 and 9 of [I-D.ietf-core-oscore-groupcomm]. 2719 Additionally, for every incoming request, if OSCORE or Group OSCORE 2720 verification succeeds, the verification of access rights is performed 2721 as described in Appendix A.3.5. 2723 After the deletion of the Access Token related to a pairwise OSCORE 2724 Security Context and to a Group OSCORE Security Context, due to, for 2725 example, expiration, the RS MUST NOT use the pairwise OSCORE Security 2726 Context. The RS MUST respond with an unprotected 4.01 (Unauthorized) 2727 error message to received requests that correspond to a pairwise 2728 OSCORE Security Context with a deleted Access Token. Also, if the 2729 Client uses the Group OSCORE Security Context to send a request for 2730 any resource intended for OSCORE group members and that requires an 2731 active Access Token, the RS MUST respond with a 4.01 (Unauthorized) 2732 error message protected with the Group OSCORE Security Context. 2734 The same considerations, related to the value of the ID Context 2735 changing, as in Appendix A.3.3 hold also for the RS. 2737 A.3.5. Access Rights Verification 2739 The RS MUST follow the procedures defined in Section 4.4. 2741 Additionally, if the RS receives an OSCORE-protected request from a 2742 Client, the RS processes it according to [RFC8613]. 2744 If the OSCORE verification succeeds, and the target resource requires 2745 authorization, the RS retrieves the authorization information from 2746 the Access Token associated with the pairwise OSCORE Security Context 2747 and to the Group OSCORE Security Context. Then, the RS MUST verify 2748 that the action requested on the resource is authorized. 2750 The response code MUST be 4.01 (Unauthorized) if the RS has no valid 2751 Access Token for the Client. 2753 A.3.6. Change of Client's Authentication Credential in the Group 2755 During its membership in the OSCORE group, the client might change 2756 the authentication credential it uses in the group. When this 2757 happens, the Client uploads the new authentication credential to the 2758 Group Manager, as defined in Section 11 of 2759 [I-D.ietf-ace-key-groupcomm-oscore]. 2761 After that, the Client may still have an Access Token previously 2762 uploaded to the RS, which is not expired yet and still valid to the 2763 best of the Client's knowledge. Then, in order to continue 2764 communicating with the RS, the Client MUST perform the following 2765 actions. 2767 1. The Client requests a new Access Token to the AS, as defined in 2768 Appendix A.2.1 for the update of access rights, i.e., with the 2769 'req_cnf' parameter including only a 'kid' field. In particular, 2770 when sending the POST request to the AS, the Client indicates: 2772 * The current Group Identifier of the OSCORE group, as value of 2773 the 'context_id' parameter. 2775 * The current Sender ID it has in the OSCORE group, as value of 2776 the 'salt_input' parameter. 2778 * The public key of the new authentication credential it uses in 2779 the OSCORE group, as value of the 'client_cred' parameter. In 2780 particular, the specified public key is the COSE Key 2781 equivalent to the new authentication credential that the 2782 Client uses in the OSCORE group. 2784 * The proof-of-possession (PoP) evidence corresponding to the 2785 public key of the new authentication credential, as value of 2786 the 'client_cred_verify' or 'client_cred_verify_mac' 2787 parameter. 2789 * The same current or instead new set of access rights, as value 2790 of the 'scope' parameter. 2792 2. After receiving the response from the AS (see Appendix A.2.2), 2793 the Client performs the same exchanges with the RS as defined in 2794 Appendix A.3, with the following difference: the POST request to 2795 /authz-info for uploading the new Access Token MUST be protected 2796 with the pairwise OSCORE Security Context shared with the RS. 2798 When receiving the new Access Token, the RS performs the same steps 2799 defined in Appendix A.3.2. In particular, no new pairwise OSCORE 2800 Security Context is established between the Client and the RS. 2802 A.4. Secure Communication with the AS 2804 The same considerations for secure communication with the AS as 2805 defined in Section 5 hold. 2807 A.5. Discarding the Security Context 2809 The Client and the RS MUST follow what is defined in Section 6 of 2810 [I-D.ietf-ace-oscore-profile] about discarding the pairwise OSCORE 2811 Security Context. 2813 Additionally, they MUST follow what is defined in the main mode of 2814 the profile (see Section 6), with respect to the Group OSCORE 2815 Security Context. 2817 The Client or RS can acquire a new Group OSCORE Security Context, by 2818 re-joining the OSCORE group, e.g., by using the approach defined in 2819 [I-D.ietf-ace-key-groupcomm-oscore]. In such a case, the Client 2820 SHOULD request a new Access Token and post it to the RS, in order to 2821 establish a new pairwise OSCORE Security Context and bind it to the 2822 Group OSCORE Security Context obtained upon re-joining the group. 2824 A.6. CBOR Mappings 2826 The new parameters defined in this document MUST be mapped to CBOR 2827 types as specified in Figure 6, with the following addition, using 2828 the given integer abbreviation for the map key. 2830 /----------------+----------+------------\ 2831 | Parameter name | CBOR Key | Value Type | 2832 |----------------+----------+------------| 2833 | client_cred | TBD | map | 2834 \----------------+----------+------------/ 2836 Figure 17: CBOR mappings for new parameters. 2838 The new claims defined in this document MUST be mapped to CBOR types 2839 as specified in Figure 7, with the following addition, using the 2840 given integer abbreviation for the map key. 2842 /--------------+----------+------------\ 2843 | Claim name | CBOR Key | Value Type | 2844 |--------------+----------+------------| 2845 | client_cred | TBD | map | 2846 \--------------+----------+------------/ 2848 Figure 18: CBOR mappings for new claims. 2850 A.7. Security Considerations 2852 The dual mode of this profile inherits the security considerations 2853 from the main mode (see Section 8), as well as from the security 2854 considerations of the OSCORE profile of ACE 2855 [I-D.ietf-ace-oscore-profile]. Also, the security considerations 2856 about OSCORE [RFC8613] hold for the dual mode of this profile, as to 2857 the specific use of OSCORE. 2859 Unlike the main mode and consistently with Section 6.1 of 2860 [I-D.ietf-ace-oauth-authz], the dual mode of this profile cannot be 2861 used to issue an Access Token for an audience that comprises multiple 2862 RSs. This is because the proof-of-possession key bound to an Access 2863 Token is the OSCORE Master Secret included in the 2864 OSCORE_Input_Material object of the 'cnf' claim, and it has to be 2865 shared only between the Client and one RS. 2867 A.8. Privacy Considerations 2869 The same privacy considerations as defined in the main mode of this 2870 profile apply (see Section 9). 2872 In addition, as this profile mode also uses OSCORE, the privacy 2873 considerations from [RFC8613] apply as well, as to the specific use 2874 of OSCORE. 2876 Furthermore, this profile mode inherits the privacy considerations 2877 from the OSCORE profile of ACE [I-D.ietf-ace-oscore-profile]. 2879 Appendix B. Profile Requirements 2881 This appendix lists the specifications on this profile based on the 2882 requirements of the ACE framework, as requested in Appendix C of 2883 [I-D.ietf-ace-oauth-authz]. 2885 * (Optional) discovery process of how the Client finds the right AS 2886 for an RS it wants to send a request to: Not specified. 2888 * Communication protocol the Client and the RS must use: CoAP. 2890 * Security protocol(s) the Client and RS must use: Group OSCORE, 2891 i.e., exchange of secure messages by using a pre-established Group 2892 OSCORE Security Context. The optional dual mode defined in 2893 Appendix A additionally uses OSCORE, i.e., establishment of a 2894 pairwise OSCORE Security Context and exchange of secure messages. 2896 * How the Client and the RS mutually authenticate: Explicitly, by 2897 possession of a common Group OSCORE Security Context, and by 2898 either: usage of digital signatures embedded in messages, if 2899 protected with the group mode of Group OSCORE; or protection of 2900 messages with the pairwise mode of Group OSCORE, by using pairwise 2901 symmetric keys, derived from the asymmetric keys of the two peers 2902 exchanging the message. Note that the mutual authentication is 2903 not completed before the Client has verified an OSCORE or a Group 2904 OSCORE response using the corresponding security context. 2906 * Content-format of the protocol messages: "application/ace+cbor". 2908 * Proof-of-Possession protocol(s) and how to select one; which key 2909 types (e.g., symmetric/asymmetric) supported: Group OSCORE 2910 algorithms; distributed and verified asymmetric keys. In the 2911 optional dual mode defined in Appendix A: OSCORE algorithms; pre- 2912 established symmetric keys. 2914 * profile identifier: coap_group_oscore 2915 * (Optional) how the RS talks to the AS for introspection: HTTP/CoAP 2916 (+ TLS/DTLS/OSCORE). 2918 * How the client talks to the AS for requesting a token: HTTP/CoAP 2919 (+ TLS/DTLS/OSCORE). 2921 * How/if the authz-info endpoint is protected: Not protected. 2923 * (Optional) other methods of token transport than the authz-info 2924 endpoint: Not specified. 2926 Acknowledgments 2928 The authors sincerely thank Benjamin Kaduk, John Mattsson, Dave 2929 Robin, Jim Schaad and Goeran Selander for their comments and 2930 feedback. 2932 The work on this document has been partly supported by VINNOVA and 2933 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 2934 (Grant agreement 952652). 2936 Authors' Addresses 2938 Marco Tiloca 2939 RISE AB 2940 Isafjordsgatan 22 2941 SE-16440 Stockholm Kista 2942 Sweden 2943 Email: marco.tiloca@ri.se 2945 Rikard Höglund 2946 RISE AB 2947 Isafjordsgatan 22 2948 SE-16440 Stockholm Kista 2949 Sweden 2950 Email: rikard.hoglund@ri.se 2952 Ludwig Seitz 2953 Combitech 2954 Djäknegatan 31 2955 SE-21135 Malmö Malmö 2956 Sweden 2957 Email: ludwig.seitz@combitech.com 2958 Francesca Palombini 2959 Ericsson AB 2960 Torshamnsgatan 23 2961 SE-16440 Stockholm Kista 2962 Sweden 2963 Email: francesca.palombini@ericsson.com