idnits 2.17.1 draft-tiloca-ace-group-oscore-profile-05.txt: 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: ---------------------------------------------------------------------------- No issues found here. 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 (February 22, 2021) is 1157 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-10 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-37 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-13 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-16 == Outdated reference: A later version (-10) exists of draft-ietf-core-groupcomm-bis-03 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-11 ** 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' ** Downref: Normative reference to an Informational RFC: RFC 5869 == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-15 == Outdated reference: A later version (-17) exists of draft-ietf-ace-mqtt-tls-profile-10 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-41 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-08 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 3 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. Hoeglund 4 Intended status: Standards Track RISE AB 5 Expires: August 26, 2021 L. Seitz 6 Combitech 7 F. Palombini 8 Ericsson AB 9 February 22, 2021 11 Group OSCORE Profile of the Authentication and Authorization for 12 Constrained Environments Framework 13 draft-tiloca-ace-group-oscore-profile-05 15 Abstract 17 This document specifies a profile for the Authentication and 18 Authorization for Constrained Environments (ACE) framework. The 19 profile uses Group OSCORE to provide communication security between a 20 Client and a (set of) Resource Server(s) as members of an OSCORE 21 Group. The profile securely binds an OAuth 2.0 Access Token with the 22 public key of the Client associated to the signing private key used 23 in the 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 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 26, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 67 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 68 2.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . 8 69 2.2. Access Token Retrieval . . . . . . . . . . . . . . . . . 9 70 2.3. Access Token Posting . . . . . . . . . . . . . . . . . . 9 71 2.4. Secure Communication . . . . . . . . . . . . . . . . . . 10 72 3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 10 73 3.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . . . 10 74 3.1.1. 'context_id' Parameter . . . . . . . . . . . . . . . 12 75 3.1.2. 'salt_input' Parameter . . . . . . . . . . . . . . . 12 76 3.1.3. 'client_cred_verify' Parameter . . . . . . . . . . . 13 77 3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 13 78 3.2.1. Salt Input Claim . . . . . . . . . . . . . . . . . . 16 79 3.2.2. Context ID Input Claim . . . . . . . . . . . . . . . 17 80 4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 17 81 4.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . . . 18 82 4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 18 83 4.3. Client-RS Secure Communication . . . . . . . . . . . . . 19 84 4.3.1. Client Side . . . . . . . . . . . . . . . . . . . . . 19 85 4.3.2. Resource Server Side . . . . . . . . . . . . . . . . 20 86 4.4. Access Rights Verification . . . . . . . . . . . . . . . 20 87 4.5. Change of Client's Public Key in the Group . . . . . . . 21 88 5. Secure Communication with the AS . . . . . . . . . . . . . . 21 89 6. Discarding the Security Context . . . . . . . . . . . . . . . 22 90 7. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . . . 22 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 92 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 94 10.1. ACE Profile Registry . . . . . . . . . . . . . . . . . . 24 95 10.2. OAuth Parameters Registry . . . . . . . . . . . . . . . 25 96 10.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . 25 97 10.4. CBOR Web Token Claims Registry . . . . . . . . . . . . . 26 98 10.5. TLS Exporter Label Registry . . . . . . . . . . . . . . 27 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 28 101 11.2. Informative References . . . . . . . . . . . . . . . . . 30 102 Appendix A. Dual Mode (Group OSCORE & OSCORE) . . . . . . . . . 31 103 A.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 32 104 A.1.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . 34 105 A.1.2. Access Token Posting . . . . . . . . . . . . . . . . 34 106 A.1.3. Setup of the Pairwise OSCORE Security Context . . . . 34 107 A.1.4. Secure Communication . . . . . . . . . . . . . . . . 35 108 A.2. Client-AS Communication . . . . . . . . . . . . . . . . . 36 109 A.2.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . 36 110 A.2.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . 39 111 A.3. Client-RS Communication . . . . . . . . . . . . . . . . . 45 112 A.3.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . 46 113 A.3.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . 47 114 A.3.3. OSCORE Setup - Client Side . . . . . . . . . . . . . 48 115 A.3.4. OSCORE Setup - Resource Server Side . . . . . . . . . 51 116 A.3.5. Access Rights Verification . . . . . . . . . . . . . 53 117 A.3.6. Change of Client's Public Key in the Group . . . . . 53 118 A.4. Secure Communication with the AS . . . . . . . . . . . . 54 119 A.5. Discarding the Security Context . . . . . . . . . . . . . 54 120 A.6. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . 55 121 A.7. Security Considerations . . . . . . . . . . . . . . . . . 55 122 A.8. Privacy Considerations . . . . . . . . . . . . . . . . . 55 123 Appendix B. Profile Requirements . . . . . . . . . . . . . . . . 56 124 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 127 1. Introduction 129 A number of applications rely on a group communication model, where a 130 Client can access a resource shared by multiple Resource Servers at 131 once, e.g. over IP multicast. Typical examples are switching of 132 luminaries, actuators control, and distribution of software updates. 133 Secure communication in the group can be achieved by sharing a set of 134 key material, which is typically provided upon joining the group. 136 For some of such applications, it may be just fine to enforce access 137 control in a straightforward fashion. That is, any Client authorized 138 to join the group, hence to get the group key material, can be also 139 implicitly authorized to perform any action at any resource of any 140 Server in the group. An example of application where such implicit 141 authorization might be used is a simple lighting scenario, where the 142 lightbulbs are the Servers, while the user account on an app on the 143 user's phone is the Client. In this case, it might be fine to not 144 require additional authorization evidence from any user account, if 145 it is acceptable that any current group member is also authorized to 146 switch on and off any light, or to check their status. 148 However, in different instances of such applications, the approach 149 above is not desirable, as different group members are intended to 150 have different access rights to resources of other group members. 151 That is, access control to the secure group communication channel and 152 access control to the resource space provided by servers in the group 153 should remain logically separated domains. For instance, a more 154 fine-grained approach is required in the two following use cases. 156 As a first case, an application provides control of smart locks 157 acting as Servers in the group, where: a first type of Client, e.g. a 158 user account of a child, is allowed to only query the status of the 159 smart locks; while a second type of Client, e.g. a user account of a 160 parent, is allowed to both query and change the status of the smart 161 locks. Further similar applications concern the enforcement of 162 different sets of permissions in groups with sensor/actuator devices, 163 e.g. thermostats, acting as Servers. Also, some group members may 164 even be intended as Servers only. Hence, they must be prevented from 165 acting as Clients altogether and from accessing resources at other 166 Servers, especially when attempting to perform non-safe operations. 168 As a second case, building automation scenarios often rely on Servers 169 that, under different circumstances, enforce different level of 170 priority for processing received commands. For instance, BACnet 171 deployments consider multiple classes of Clients, e.g. a normal light 172 switch (C1) and an emergency fire panel (C2). Then, a C1 Client is 173 not allowed to override a command from a C2 Client, until the latter 174 relinquishes control at its higher priority. That is: i) only C2 175 Clients should be able to adjust the minimum required level of 176 priority on the Servers, so rightly locking out C1 Clients if needed; 177 and ii) when a Server is set to accept only high-priority commands, 178 only C2 Clients should be able to perform such commands otherwise 179 allowed also to C1 Clients. Given the different maximum authority of 180 different Clients, fine-grained access control would effectively 181 limit the execution of high- and emergency-priority commands only to 182 devices that are in fact authorized to do so. Besides, it would 183 prevent a misconfigured or compromised device from initiating a high- 184 priority command and lock out normal control. 186 In the cases above, being a legitimate group member and owning the 187 group key material is not supposed to imply any particular access 188 rights. Also, introducing a different security group for each 189 different set of access rights would result in additional key 190 material to distribute and manage. In particular, if the access 191 rights for a single node change, this would require to evict that 192 node from the current group, followed by that node joining a 193 different group aligned with its new access rights. Moreover, the 194 key material of both groups would have to be renewed for their 195 current members. Overall, this would have a non negligible impact on 196 operations and performance in the system. 198 A fine-grained access control model can be rather enforced within a 199 same group, by using the Authentication and Authorization for 200 Constrained Environments (ACE) framework [I-D.ietf-ace-oauth-authz]. 201 That is, a Client has to first obtain authorization credentials in 202 the form of an Access Token, and post it to the Resource Server(s) in 203 the group before accessing the intended resources. 205 The ACE framework delegates to separate profile documents how to 206 secure communications between the Client and the Resource Server. 207 However each of the current profiles of ACE defined in 208 [I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-dtls-authorize] 209 [I-D.ietf-ace-mqtt-tls-profile] admits a single security protocol 210 that cannot be used to protect group messages sent over IP multicast. 212 This document specifies a profile of ACE, where a Client uses CoAP 213 [RFC7252] or CoAP over IP multicast [I-D.ietf-core-groupcomm-bis] to 214 communicate to one or multiple Resource Servers, which are members of 215 an application group and share a common set of resources. This 216 profile uses Group OSCORE [I-D.ietf-core-oscore-groupcomm] as the 217 security protocol to protect messages exchanged between the Client 218 and the Resource Servers. Hence, it requires that both the Client 219 and the Resource Servers have previously joined the same OSCORE 220 group. 222 That is, this profile describes how access control is enforced for a 223 Client after it has joined an OSCORE group, to access resources at 224 other members in that group. The process for joining the OSCORE 225 group through the respective Group Manager as defined in 226 [I-D.ietf-ace-key-groupcomm-oscore] takes place before the process 227 described in this document, and is out of the scope of this profile. 229 The Client proves its access to be authorized to the Resource Server 230 by using an Access Token, which is bound to a key (the proof-of- 231 possession key). This profile uses Group OSCORE to achieve server 232 authentication, as well as proof-of-possession for the Client's 233 public key associated to the signing private key used in an OSCORE 234 group. Note that the proof of possession is not done by a dedicated 235 protocol element, but rather occurs after the first Group OSCORE 236 exchange. Furthermore, this profile provides proof of the Client's 237 membership to the correct OSCORE group, by binding the Access Token 238 to the Client's public key and information from the pre-established 239 Group OSCORE Security Context, thus allowing the Resource Server to 240 verify this upon reception of a messages protected with Group OSCORE 241 from the Client. 243 OSCORE [RFC8613] specifies how to use COSE 244 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] to 245 secure CoAP messages. Group OSCORE builds on OSCORE to provide 246 secure group communication, and ensures source authentication either: 247 by means of digital counter signatures embedded in protected messages 248 (in group mode); by protecting messages with pairwise key material 249 derived from the asymmetric keys of the two peers exchanging the 250 message (in pairwise mode). 252 1.1. Terminology 254 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 255 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 256 "OPTIONAL" in this document are to be interpreted as described in BCP 257 14 [RFC2119] [RFC8174] when, and only when, they appear in all 258 capitals, as shown here. 260 Readers are expected to be familiar with the terms and concepts 261 related to CBOR [RFC8949], COSE 262 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs], 263 CoAP [RFC7252], OSCORE [RFC8613] and Group OSCORE 264 [I-D.ietf-core-oscore-groupcomm]. These include the concept of Group 265 Manager, as the entity responsible for a set of groups where 266 communications among members are secured with Group OSCORE. 268 Readers are expected to be familiar with the terms and concepts 269 described in the ACE framework for authentication and authorization 270 [I-D.ietf-ace-oauth-authz], as well as in the OSCORE profile of ACE 271 [I-D.ietf-ace-oscore-profile]. The terminology for entities in the 272 considered architecture is defined in OAuth 2.0 [RFC6749]. In 273 particular, this includes Client (C), Resource Server (RS), and 274 Authorization Server (AS). 276 Note that, unless otherwise indicated, the term "endpoint" is used 277 here following its OAuth definition, aimed at denoting resources such 278 as /token and /introspect at the AS, and /authz-info at the RS. This 279 document does not use the CoAP definition of "endpoint", which is "An 280 entity participating in the CoAP protocol". 282 2. Protocol Overview 284 This section provides an overview of this profile, i.e. on how to use 285 the ACE framework for authentication and authorization 286 [I-D.ietf-ace-oauth-authz] to secure communications between a Client 287 and a (set of) Resource Server(s) using Group OSCORE 288 [I-D.ietf-core-oscore-groupcomm]. 290 Note that this profile of ACE describes how access control can be 291 enforced for a node after it has joined an OSCORE group, to access 292 resources at other members in that group. 294 In particular, the process for joining the OSCORE group through the 295 respective Group Manager as defined in 296 [I-D.ietf-ace-key-groupcomm-oscore] must take place before the 297 process described in this document, and is out of the scope of this 298 profile. 300 An overview of the protocol flow for this profile is shown in 301 Figure 1. In the figure, it is assumed that both RS1 and RS2 are 302 associated with the same AS. It is also assumed that C, RS1 and RS2 303 have previously joined an OSCORE group with Group Identifier (gid) 304 "abcd0000", and got assigned Sender ID (sid) "0", "1" and "2" in the 305 group, respectively. The names of messages coincide with those of 306 [I-D.ietf-ace-oauth-authz] when applicable. 308 C RS1 RS2 AS 309 | [--- Resource Request --->] | | | 310 | | | | 311 | [<---- AS Request ------] | | | 312 | Creation Hints | | | 313 | | | | 314 |-------- POST /token ------------------------------------------------>| 315 | (aud: RS1, sid: 0, gid: abcd0000, ...) | | 316 | | | | 317 |<--------------------------------- Access Token + RS Information -----| 318 | | (aud: RS1, sid: 0, gid: abcd0000, ...) | 319 | | | | 320 |---- POST /authz-info ------>| | | 321 | (access_token) | | | 322 | | | | 323 |<--- 2.01 Created -----------| | | 324 | | | | 325 |-------- POST /token ------------------------------------------------>| 326 | (aud: RS2, sid: 0, gid: abcd0000, ...) | | 327 | | | | 328 |<--------------------------------- Access Token + RS Information -----| 329 | | (aud: RS2, sid: 0, gid: abcd0000, ...) | 330 | | | | 331 |----- POST /authz-info ------------------>| | 332 | (access_token) | | | 333 | | | | 334 |<--- 2.01 Created ------------------------| | 335 | | | | 336 |-- Group OSCORE Request -+-->| | | 337 | (kid: 0, gid: abcd0000) \-------------->| | 338 | | | | 339 | /proof-of-possession/ | 340 | | | | 341 |<--- Group OSCORE Response --| | | 342 | (kid: 1) | | | 343 | | | | 344 /proof-of-possession/ | | | 345 | | | | 346 /Mutual authentication | | | 347 between C and RS1/ | | | 348 | | | | 349 | | | | 350 |<--- Group OSCORE Response ---------------| | 351 | (kid: 2) | | | 352 | | | | 353 /proof-of-possession/ | | | 354 | | | | 355 /Mutual authentication | | | 356 between C and RS2/ | | | 357 | | | | 358 | ... | | | 360 Figure 1: Protocol Overview. 362 2.1. Pre-Conditions 364 Using Group OSCORE and this profile requires both the Client and the 365 Resource Servers to have previously joined the same OSCORE group. 366 This especially includes the derivation of the Group OSCORE Security 367 Context and the assignment of unique Sender IDs to use in the group. 368 Nodes may join the OSCORE group through the respective Group Manager 369 by using the approach defined in [I-D.ietf-ace-key-groupcomm-oscore], 370 which is also based on ACE. 372 After the Client and Resource Servers have joined the group, this 373 profile provides access control for accessing resources on those 374 Resource Servers, by securely communicating with Group OSCORE. 376 As a pre-requisite for this profile, the Client has to have 377 successfully joined the OSCORE group where also the Resource Servers 378 (RSs) are members. Depending on the limited information initially 379 available, the Client may have to first discover the exact OSCORE 380 group used by the RSs for the resources of interest, e.g. by using 381 the approach defined in [I-D.tiloca-core-oscore-discovery]. 383 2.2. Access Token Retrieval 385 This profile requires that the Client retrieves an Access Token from 386 the AS for the resource(s) it wants to access on each of the RSs, 387 using the /token endpoint, as specified in Section 5.8 of 388 [I-D.ietf-ace-oauth-authz]. In a general case, it can be assumed 389 that different RSs are associated to different ASs, even if the RSs 390 are members of a same OSCORE group. 392 In the Access Token request to the AS, the Client MUST include the 393 Group Identifier of the OSCORE group and its own Sender ID in that 394 group. The AS MUST specify these pieces of information in the Access 395 Token, included in the Access Token response to the Client. 397 Furthermore, in the Access Token request to the AS, the Client MUST 398 also include: its own public key, associated to the private signing 399 key used in the OSCORE group; and a signature computed with such 400 private key, over a quantity uniquely related to the secure 401 communication association between the Client and the AS. The AS MUST 402 include also the public key indicated by the Client in the Access 403 Token. 405 The Access Token request and response MUST be confidentiality- 406 protected and ensure authenticity. This profile RECOMMENDS the use 407 of OSCORE between the Client and the AS, to reduce the number of 408 libraries the client has to support. Other protocols fulfilling the 409 security requirements defined in Section 5 of 410 [I-D.ietf-ace-oauth-authz] (such as TLS [RFC8446] or DTLS 411 [RFC6347][I-D.ietf-tls-dtls13]) MAY be used additionally or instead. 413 2.3. Access Token Posting 415 After having retrieved the Access Token from the AS, the Client posts 416 the Access Token to the RS, using the /authz-info endpoint and 417 mechanisms specified in Section 5.10 of [I-D.ietf-ace-oauth-authz], 418 as well as Content-Format = application/ace+cbor. When using this 419 profile, the communication with the /authz-info endpoint is not 420 protected. 422 If the Access Token is valid, the RS replies to this POST request 423 with a 2.01 (Created) response with Content-Format = application/ 424 ace+cbor. Also, the RS associates the received Access Token with the 425 Group OSCORE Security Context identified by the Group Identifier 426 specified in the Access Token, following Section 3.2 of [RFC8613]. 427 In practice, the RS maintains a collection of Security Contexts with 428 associated authorization information, for all the clients that it is 429 currently communicating with, and the authorization information is a 430 policy used as input when processing requests from those clients. 432 Finally, the RS stores the association between i) the authorization 433 information from the Access Token; and ii) the Group Identifier of 434 the OSCORE group together with the Sender ID and the public key of 435 the Client in that group. This binds the Access Token with the Group 436 OSCORE Security Context of the OSCORE group. 438 Finally, when the Client communicates with the RS using the Group 439 OSCORE Security Context, the RS verifies that the Client is a 440 legitimate member of the OSCORE group and especially the exact group 441 member with the same Sender ID associated to the Access Token. This 442 occurs when verifying a request protected with Group OSCORE, since it 443 embeds a counter signature computed also over the Client's Sender ID 444 included in the message. 446 2.4. Secure Communication 448 The Client can send a request protected with Group OSCORE 449 [I-D.ietf-core-oscore-groupcomm] to the RS. This can be a unicast 450 request addressed to the RS, or a multicast request addressed to the 451 OSCORE group where the RS is also a member. To this end, the Client 452 uses the Group OSCORE Security Context already established upon 453 joining the OSCORE group, e.g. by using the approach defined in 454 [I-D.ietf-ace-key-groupcomm-oscore]. The RS may send a response back 455 to the Client, protecting it by means of the same Group OSCORE 456 Security Context. 458 3. Client-AS Communication 460 This section details the Access Token POST Request that the Client 461 sends to the /token endpoint of the AS, as well as the related Access 462 Token response. 464 The Access Token MUST be bound to the public key of the client as 465 proof-of-possession key (pop-key), by means of the 'cnf' claim. 467 3.1. C-to-AS: POST to Token Endpoint 469 The Client-to-AS request is specified in Section 5.8.1 of 470 [I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request 471 to the /token endpoint over a secure channel that guarantees 472 authentication, message integrity and confidentiality. 474 The POST request is formatted as the analogous Client-to-AS request 475 in the OSCORE profile of ACE (see Section 3.1 of 476 [I-D.ietf-ace-oscore-profile]), with the following additional 477 parameters that MUST be included in the payload. 479 o 'context_id', defined in Section 3.1.1 of this specification. 480 This parameter specifies the Group Identifier (GID), i.e. the Id 481 Context of an OSCORE group where the Client and the RS are 482 currently members. In particular, the Client wishes to 483 communicate with the RS using the Group OSCORE Security Context 484 associated to that OSCORE group. 486 o 'salt_input', defined in Section 3.1.2 of this specification. 487 This parameter includes the Sender ID that the Client has in the 488 OSCORE group whose GID is specified in the 'context_id' parameter 489 above. 491 o 'req_cnf', defined in Section 3.1 of [I-D.ietf-ace-oauth-params]. 492 This parameter includes the public key associated to the signing 493 private key that the Client uses in the OSCORE group whose GID is 494 specified in the 'context_id' parameter above. This public key 495 will be used as the pop-key bound to the Access Token. 497 o 'client_cred_verify', defined in Section 3.1.3 of this 498 specification. This parameter includes a signature computed by 499 the Client, by using the private key associated to the public key 500 in the 'req_cnf' parameter above. This allows the AS to verify 501 that the Client indeed owns the private key associated to that 502 public key, as its alleged identity credential within the OSCORE 503 group. The information to be signed MUST be the byte 504 representation of a quantity that uniquely represents the secure 505 communication association between the Client and the AS. It is 506 RECOMMENDED that the Client considers the following as information 507 to sign. 509 * If the Client and the AS communicate over (D)TLS, the 510 information to sign is an exporter value computed as defined in 511 Section 7.5 of [RFC8446]. In particular, the exporter label 512 MUST be 'EXPORTER-ACE-Sign-Challenge-Client-AS' defined in 513 Section 10.5 of this specification, together with an empty 514 'context_value', and 32 bytes as 'key_length'. 516 * If the Client and the AS communicate over OSCORE, the 517 information to sign is the output PRK of a HKDF-Extract step 518 [RFC5869], i.e. PRK = HMAC-Hash(salt, IKM). In particular, 519 'salt' takes (x1 | x2), where x1 is the ID Context of the 520 OSCORE Security Context between the Client and the AS, x2 is 521 the Sender ID of the Client in that Context, and | denotes byte 522 string concatenation. Also, 'IKM' is the OSCORE Master Secret 523 of the OSCORE Security Context between the Client and the AS. 524 The HKDF MUST be one of the HMAC-based HKDF [RFC5869] 525 algorithms defined for COSE [I-D.ietf-cose-rfc8152bis-algs]. 526 HKDF SHA-256 is mandatory to implement. 528 An example of such a request, with payload in CBOR diagnostic 529 notation without the tag and value abbreviations is reported in 530 Figure 2. 532 Header: POST (Code=0.02) 533 Uri-Host: "as.example.com" 534 Uri-Path: "token" 535 Content-Format: "application/ace+cbor" 536 Payload: 537 { 538 "audience" : "tempSensor4711", 539 "scope" : "read", 540 "context_id" : h'abcd0000', 541 "salt_input" : h'00', 542 "req_cnf" : { 543 "COSE_Key" : { 544 "kty" : EC2, 545 "crv" : P-256, 546 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 547 27c9e354089bbe13', 548 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 549 731e79a3b4e47120' 550 } 551 }, 552 "client_cred_verify" : h'...' 553 (signature content omitted for brevity) 554 } 556 Figure 2: Example C-to-AS POST /token request for an Access Token 557 bound to an asymmetric key. 559 3.1.1. 'context_id' Parameter 561 The 'context_id' parameter is an OPTIONAL parameter of the Access 562 Token request message defined in Section 5.8.1. of 563 [I-D.ietf-ace-oauth-authz]. This parameter provides a value that the 564 Client wishes to use with the RS as a hint for a security context. 565 Its exact content is profile specific. 567 3.1.2. 'salt_input' Parameter 569 The 'salt_input' parameter is an OPTIONAL parameter of the Access 570 Token request message defined in Section 5.8.1. of 571 [I-D.ietf-ace-oauth-authz]. This parameter provides a value that the 572 Client wishes to use as part of a salt with the RS, for deriving 573 cryptographic key material. Its exact content is profile specific. 575 3.1.3. 'client_cred_verify' Parameter 577 The 'client_cred_verify' parameter is an OPTIONAL parameter of the 578 Access Token request message defined in Section 5.8.1. of 579 [I-D.ietf-ace-oauth-authz]. This parameter provides a signature 580 computed by the Client to prove the possession of its own private 581 key. 583 3.2. AS-to-C: Access Token 585 After having verified the POST request to the /token endpoint and 586 that the Client is authorized to obtain an Access Token corresponding 587 to its Access Token request, the AS MUST verify the signature in the 588 'client_cred_verify' parameter, by using the public key specified in 589 the 'req_cnf' parameter. If the verification fails, the AS considers 590 the Client request invalid. 592 If all verifications are successful, the AS responds as defined in 593 Section 5.8.2 of [I-D.ietf-ace-oauth-authz]. If the Client request 594 was invalid, or not authorized, the AS returns an error response as 595 described in Section 5.8.3 of [I-D.ietf-ace-oauth-authz]. 597 The AS can signal that the use of Group OSCORE is REQUIRED for a 598 specific Access Token by including the 'profile' parameter with the 599 value "coap_group_oscore" in the Access Token response. The Client 600 MUST use Group OSCORE towards all the Resource Servers for which this 601 Access Token is valid. Usually, it is assumed that constrained 602 devices will be pre-configured with the necessary profile, so that 603 this kind of profile signaling can be omitted. 605 The AS MUST include the following information as metadata of the 606 issued Access Token. The use of CBOR web tokens (CWT) as specified 607 in [RFC8392] is RECOMMENDED. 609 o The same parameter 'profile' included in the Token Response to the 610 Client. 612 o The salt input specified in the 'salt_input' parameter of the 613 Token Request. If the Access Token is a CWT, the content of the 614 'salt_input' parameter MUST be placed in the 'salt_input' claim of 615 the Access Token, defined in Section 3.2.1 of this specification. 617 o The Context Id input specified in the 'context_id' parameter of 618 the Token Request. If the Access Token is a CWT, the content of 619 the 'context_id' parameter MUST be placed in the 'contextId_input' 620 claim of the Access Token, defined in Section 3.2.2 of this 621 specification. 623 o The public key that the client uses in the OSCORE group and 624 specified in the 'req_cnf' parameter of the Token request. If the 625 Access Token is a CWT, the public key MUST be specified in the 626 'cnf' claim, which follows the syntax from Section 3.1 of 627 [RFC8747] when including Value Type "COSE_Key" (1) and specifying 628 an asymmetric key. Alternative Value Types defined in future 629 specifications are fine to consider if indicating a non-encrypted 630 asymmetric key. 632 Figure 3 shows an example of such an AS response, with payload in 633 CBOR diagnostic notation without the tag and value abbreviations. 635 Header: Created (Code=2.01) 636 Content-Type: "application/ace+cbor" 637 Payload: 638 { 639 "access_token" : h'8343a1010aa2044c53 ...' 640 (remainder of CWT omitted for brevity), 641 "profile" : "coap_group_oscore", 642 "expires_in" : 3600 643 } 645 Figure 3: Example AS-to-C Access Token response with the Group OSCORE 646 profile. 648 Figure 4 shows an example CWT Claims Set, containing the Client's 649 public key in the group (as pop-key) in the 'cnf' claim, in CBOR 650 diagnostic notation without tag and value abbreviations. 652 { 653 "aud" : "tempSensorInLivingRoom", 654 "iat" : "1360189224", 655 "exp" : "1360289224", 656 "scope" : "temperature_g firmware_p", 657 "cnf" : { 658 "COSE_Key" : { 659 "kty" : EC2, 660 "crv" : P-256, 661 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 662 27c9e354089bbe13', 663 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 664 731e79a3b4e47120' 665 }, 666 "salt_input" : h'00', 667 "contextId_input" : h'abcd0000' 668 } 670 Figure 4: Example CWT Claims Set with OSCORE parameters (CBOR 671 diagnostic notation). 673 The same CWT Claims Set as in Figure 4 and encoded in CBOR is shown 674 in Figure 5, using the value abbreviations defined in 675 [I-D.ietf-ace-oauth-authz] and [RFC8747]. The bytes in hexadecimal 676 are reported in the first column, while their corresponding CBOR 677 meaning is reported after the '#' sign on the second column, for 678 easiness of readability. 680 NOTE: it should be checked (and in case fixed) that the values used 681 below (which are not yet registered) are the final values registered 682 in IANA. 684 A7 # map(7) 685 03 # unsigned(3) 686 76 # text(22) 687 74656D7053656E736F72496E4C6976696E67526F6F6D 688 06 # unsigned(6) 689 1A 5112D728 # unsigned(1360189224) 690 04 # unsigned(4) 691 1A 51145DC8 # unsigned(1360289224) 692 09 # unsigned(9) 693 78 18 # text(24) 694 74656D70657261747572655F67206669726D776172655F70 695 08 # unsigned(8) 696 A1 # map(1) 697 01 # unsigned(1) 698 A4 # map(4) 699 01 # unsigned(1) 700 02 # unsigned(2) 701 20 # negative(0) 702 01 # unsigned(1) 703 21 # negative(1) 704 58 20 # bytes(32) 705 D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9 706 E354089BBE13 707 22 # negative(2) 708 58 20 # bytes(32) 709 F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E515D020731E 710 79A3B4E47120 711 18 3C # unsigned(60) 712 41 # bytes(1) 713 00 714 18 3D # unsigned(61) 715 44 # bytes(4) 716 ABCD0000 718 Figure 5: Example CWT Claims Set with OSCORE parameters, CBOR 719 encoded. 721 3.2.1. Salt Input Claim 723 The 'salt_input' claim provides a value that the Client requesting 724 the Access Token wishes to use as a part of a salt with the RS, e.g. 725 for deriving cryptographic material. 727 This parameter specifies the value of the salt input, encoded as a 728 CBOR byte string. 730 3.2.2. Context ID Input Claim 732 The 'contextId_input' claim provides a value that the Client 733 requesting the Access Token wishes to use with the RS, as a hint for 734 a security context. 736 This parameter specifies the value of the Context ID input, encoded 737 as a CBOR byte string. 739 4. Client-RS Communication 741 This section details the POST request and response to the /authz-info 742 endpoint between the Client and the RS. 744 The proof-of-possession required to bind the Access Token to the 745 Client is explicitly performed when the RS receives and verifies a 746 request from the Client protected with Group OSCORE, either with the 747 group mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]) or 748 with the pairwise mode (see Section 9 of 749 [I-D.ietf-core-oscore-groupcomm]). 751 In particular, the RS uses the Client's public key bound to the 752 Access Token, either when verifying the counter signature of the 753 request (if protected with the group mode), or when verifying the 754 request as integrity-protected with pairwise key material derived 755 from the two peers' asymmetric keys (if protected with the pairwise 756 mode). In either case, the RS also authenticates the Client. 758 Similarly, when receiving a protected response from the RS, the 759 Client uses the RS's public key either when verifying the counter 760 signature of the response (if protected with the group mode), or when 761 verifying the response as integrity-protected with pairwise key 762 material derived from the two peers' asymmetric keys (if protected 763 with the pairwise mode). In either case, the Client also 764 authenticates the RS. Mutual authentication is only achieved after 765 the client has successfully verified the Group OSCORE protected 766 response from the RS. 768 Therefore, an attacker using a stolen Access Token cannot generate a 769 valid Group OSCORE message signed with the Client's private key, and 770 thus cannot prove possession of the pop-key bound to the Access 771 Token. Also, if a Client legitimately owns an Access Token but has 772 not joined the OSCORE group, it cannot generate a valid Group OSCORE 773 message, as it does not own the necessary key material shared among 774 the group members. 776 Furthermore, a Client C1 is supposed to obtain a valid Access Token 777 from the AS, as including the public key associated to its own 778 signing key used in the OSCORE group, together with its own Sender ID 779 in that OSCORE group (see Section 3.1). This makes it possible for 780 the RS receiving an Access Token to verify with the Group Manager of 781 that OSCORE group whether such a Client has indeed that Sender ID and 782 that public key in the OSCORE group. 784 As a consequence, a different Client C2, also member of the same 785 OSCORE group, is not able to impersonate C1, by: i) getting a valid 786 Access Token, specifying the Sender ID of C1 and a different (made- 787 up) public key; ii) successfully posting the Access Token to RS; and 788 then iii) attempting to communicate using Group OSCORE impersonating 789 C1, while blaming C1 for the consequences. 791 4.1. C-to-RS POST to authz-info Endpoint 793 The Client posts the Access Token to the /authz-info endpoint of the 794 RS, as defined in Section 5.10.1 of [I-D.ietf-ace-oauth-authz]. 796 4.2. RS-to-C: 2.01 (Created) 798 The RS MUST verify the validity of the Access Token as defined in 799 Section 5.10.1 of [I-D.ietf-ace-oauth-authz], with the following 800 additions. 802 o The RS checks that the claims 'salt_input', 'contextId_input' and 803 'cnf' are included in the Access Token. 805 o The RS considers the content of the 'cnf' claim as the public key 806 associated to the signing private key of the Client in the OSCORE 807 group, whose GID is specified in the 'contextId_input' claim. 809 If it does not already store that public key, the RS MUST request 810 it to the Group Manager of the OSCORE group as described in 811 [I-D.ietf-ace-key-groupcomm-oscore], specifying the Sender ID of 812 that Client in the OSCORE group, i.e. the value of the 813 'salt_input' claim above. The RS MUST check that the key 814 retrieved from the Group Manager matches the one retrieved from 815 the 'cnf' claim. When doing so, the 'kid' parameter of the 816 COSE_Key, if present, MUST NOT be considered for the comparison. 818 If any of the checks above fails, the RS MUST consider the Access 819 Token non valid, and MUST respond to the Client with an error 820 response code equivalent to the CoAP code 4.00 (Bad Request). 822 If the Access Token is valid and further checks on its content are 823 successful, the RS associates the authorization information from the 824 Access Token with the Group OSCORE Security Context. 826 In particular, the RS associates the authorization information from 827 the Access Token with the 3-tuple (GID, SaltInput, PubKey), where GID 828 is the Group Identifier of the OSCORE Group, while SaltInput and 829 PubKey are the Sender ID and the public key that the Client uses in 830 that OSCORE group, respectively. These can be retrieved from the 831 'contextId_input', 'salt_input' and 'cnf' claims of the Access Token, 832 respectively. 834 The RS MUST keep this association up-to-date over time, as the 835 3-tuple (GID, SaltInput, PubKey) associated to the Access Token might 836 change. In particular: 838 o If the OSCORE group is rekeyed (see Section 3.1 of 839 [I-D.ietf-core-oscore-groupcomm] and Section 18 of 840 [I-D.ietf-ace-key-groupcomm-oscore]), the Group Identifier also 841 changes in the group, and the new one replaces the current 'GID' 842 value in the 3-tuple. 844 o If the Client requests and obtains a new OSCORE Sender ID from the 845 Group Manager (see Section 3.1 of [I-D.ietf-core-oscore-groupcomm] 846 and Section 9 of [I-D.ietf-ace-key-groupcomm-oscore]), the new 847 Sender ID replaces the current 'SaltInput' value in the 3-tuple. 849 Finally, the RS MUST send a 2.01 (Created) response to the Client, as 850 defined in Section 5.10.1 of [I-D.ietf-ace-oauth-authz]. 852 4.3. Client-RS Secure Communication 854 When previously joining the OSCORE group, both the Client and RS have 855 already established the related Group OSCORE Security Context to 856 communicate as group members. Therefore, they can simply start to 857 securely communicate using Group OSCORE, without deriving any 858 additional key material or security association. 860 4.3.1. Client Side 862 After having received the 2.01 (Created) response from the RS, 863 following the POST request to the authz-info endpoint, the Client 864 starts the communication with the RS, by sending a request protected 865 with Group OSCORE using the Group OSCORE Security Context 866 [I-D.ietf-core-oscore-groupcomm]. 868 When communicating with the RS to access the resources as specified 869 by the authorization information, the Client MUST use the Group 870 OSCORE Security Context of the OSCORE group, whose GID was specified 871 in the 'context_id' parameter of the Token request. 873 4.3.2. Resource Server Side 875 After successful validation of the Access Token as defined in 876 Section 4.2 and after having sent the 2.01 (Created) response, the RS 877 can start to communicate with the Client using Group OSCORE 878 [I-D.ietf-core-oscore-groupcomm]. 880 When processing an incoming request protected with Group OSCORE, the 881 RS MUST consider as valid public key of the Client only the public 882 key specified in the stored Access Token. As defined in Section 4.5, 883 a possible change of public key requires the Client to upload to the 884 RS a new Access Token bound to the new public key. 886 Additionally, for every incoming request, if Group OSCORE 887 verification succeeds, the verification of access rights is performed 888 as described in Section 4.4. 890 After the expiration of the Access Token related to a Group OSCORE 891 Security Context, if the Client uses the Group OSCORE Security 892 Context to send a request for any resource intended for OSCORE group 893 members and that requires an active Access Token, the RS MUST respond 894 with a 4.01 (Unauthorized) error message protected with the Group 895 OSCORE Security Context. 897 4.4. Access Rights Verification 899 The RS MUST follow the procedures defined in Section 5.10.2 of 900 [I-D.ietf-ace-oauth-authz]. If an RS receives a Group OSCORE- 901 protected request from a Client, the RS processes it according to 902 [I-D.ietf-core-oscore-groupcomm]. 904 If the Group OSCORE verification succeeds, and the target resource 905 requires authorization, the RS retrieves the authorization 906 information from the Access Token associated to the Group OSCORE 907 Security Context. Then, the RS MUST verify that the action requested 908 on the resource is authorized. 910 The response code MUST be 4.01 (Unauthorized) if the RS has no valid 911 Access Token for the Client. If the RS has an Access Token for the 912 Client but no actions are authorized on the target resource, the RS 913 MUST reject the request with a 4.03 (Forbidden). If the RS has an 914 Access Token for the Client but the requested action is not 915 authorized, the RS MUST reject the request with a 4.05 (Method Not 916 Allowed). 918 4.5. Change of Client's Public Key in the Group 920 During its membership in the OSCORE group, the client might change 921 the public key it uses in the group. When this happens, the Client 922 uploads the new public key to the Group Manager, as defined in 923 Section 11 of [I-D.ietf-ace-key-groupcomm-oscore]. 925 After that, and in order to continue communicating with the RS, the 926 Client MUST perform the following actions. 928 1. The Client requests a new Access Token to the AS, as defined in 929 Section 3. In particular, when sending the POST request as 930 defined in Section 3.1, the Client indicates: 932 * The current Group Identifier of the OSCORE group, as value of 933 the 'context_id' parameter. 935 * The current Sender ID it has in the OSCORE group, as value of 936 the 'salt_input' parameter. 938 * The new public key it uses in the OSCORE group, as value of 939 the 'req_cnf' parameter. 941 * The proof-of-possession signature corresponding to the new 942 public key, as value of the 'client_cred_verify' parameter. 944 2. After receiving the response from the AS (see Section 3.2), the 945 Client performs the same exchanges with the RS as defined in 946 Section 4. 948 When receiving the new Access Token, the RS performs the same steps 949 defined in Section 4.2, with the following addition, in case the new 950 Access Token is successfully verified and stored. The RS also 951 deletes the old Access Token, i.e. the one whose associated 3-tuple 952 has the same GID and SaltInput values as in the 3-tuple including the 953 new public key of the Client and associated to the new Access Token. 955 5. Secure Communication with the AS 957 As specified in the ACE framework (Sections 5.8 and 5.9 of 958 [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or Client) 959 and the AS communicate via the /introspection or /token endpoint. 960 The use of CoAP and OSCORE [RFC8613] for this communication is 961 RECOMMENDED in this profile. Other protocols fulfilling the security 962 requirements defined in Section 5 of [I-D.ietf-ace-oauth-authz] (such 963 as HTTP and DTLS or TLS) MAY be used instead. 965 If OSCORE [RFC8613] is used, the requesting entity and the AS are 966 expected to have a pre-established Security Context in place. How 967 this Security Context is established is out of the scope of this 968 profile. Furthermore, the requesting entity and the AS communicate 969 using OSCORE through the /introspection endpoint as specified in 970 Section 5.9 of [I-D.ietf-ace-oauth-authz], and through the /token 971 endpoint as specified in Section 5.8 of [I-D.ietf-ace-oauth-authz]. 973 6. Discarding the Security Context 975 As members of an OSCORE group, the Client and the RS may 976 independently leave the group or be forced to, e.g. if compromised or 977 suspected so. Upon leaving the OSCORE group, the Client or RS also 978 discards the Group OSCORE Security Context, which may anyway be 979 renewed by the Group Manager through a group rekeying process (see 980 Section 3.1 of [I-D.ietf-core-oscore-groupcomm]). 982 The Client or RS can acquire a new Group OSCORE Security Context, by 983 re-joining the OSCORE group, e.g. by using the approach defined in 984 [I-D.ietf-ace-key-groupcomm-oscore]. In such a case, the Client 985 SHOULD request a new Access Token and post it to the RS. 987 7. CBOR Mappings 989 The new parameters defined in this document MUST be mapped to CBOR 990 types as specified in Figure 6, using the given integer abbreviation 991 for the map key. 993 /--------------------+----------+------------\ 994 | Parameter name | CBOR Key | Value Type | 995 |--------------------+----------+------------| 996 | context_id | TBD1 | bstr | 997 | salt_input | TBD2 | bstr | 998 | client_cred_verify | TBD3 | bstr | 999 \--------------------+----------+------------/ 1001 Figure 6: CBOR mappings for new parameters. 1003 The new claims defined in this document MUST be mapped to CBOR types 1004 as specified in Figure 7, using the given integer abbreviation for 1005 the map key. 1007 /-----------------+----------+------------\ 1008 | Claim name | CBOR Key | Value Type | 1009 |-----------------+----------+------------| 1010 | salt_input | TBD4 | bstr | 1011 | contextId_input | TBD5 | bstr | 1012 \-----------------+----------+------------/ 1014 Figure 7: CBOR mappings for new claims. 1016 8. Security Considerations 1018 This document specifies a profile for the Authentication and 1019 Authorization for Constrained Environments (ACE) framework 1020 [I-D.ietf-ace-oauth-authz]. Thus, the general security 1021 considerations from the ACE framework also apply to this profile. 1023 This specification inherits the general security considerations about 1024 Group OSCORE [I-D.ietf-core-oscore-groupcomm], as to the specific use 1025 of Group OSCORE according to this profile. 1027 Group OSCORE is designed to secure point-to-point as well as point- 1028 to-multipoint communications, providing a secure binding between a 1029 single request and multiple corresponding responses. In particular, 1030 Group OSCORE fulfills the same security requirements of OSCORE, for 1031 group requests and responses. 1033 Group OSCORE ensures source authentication of messages both in group 1034 mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]) and in 1035 pairwise mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). 1037 When protecting an outgoing message in group mode, the sender uses 1038 its private key to compute a digital counter signature, which is 1039 embedded in the protected message. The group mode can be used to 1040 protect messages sent over multicast to multiple recipients, or sent 1041 over unicast to one recipient. 1043 When protecting an outgoing message in pairwise mode, the sender uses 1044 a pairwise symmetric key, as derived from the asymmetric keys of the 1045 two peers exchanging the message. The pairwise mode can be used to 1046 protect only messages sent over unicast to one recipient. 1048 9. Privacy Considerations 1050 This document specifies a profile for the Authentication and 1051 Authorization for Constrained Environments (ACE) framework 1052 [I-D.ietf-ace-oauth-authz]. Thus the general privacy considerations 1053 from the ACE framework also apply to this profile. 1055 As this profile uses Group OSCORE, the privacy considerations from 1056 [I-D.ietf-core-oscore-groupcomm] apply to this document as well. 1058 An unprotected response to an unauthorized request may disclose 1059 information about the RS and/or its existing relationship with the 1060 Client. It is advisable to include as little information as possible 1061 in an unencrypted response. However, since both the Client and the 1062 RS share a Group OSCORE Security Context, unauthorized, yet protected 1063 requests are followed by protected responses, which can thus include 1064 more detailed information. 1066 Although it may be encrypted, the Access Token is sent in the clear 1067 to the /authz-info endpoint at the RS. Thus, if the Client uses the 1068 same single Access Token from multiple locations with multiple 1069 Resource Servers, it can risk being tracked through the Access 1070 Token's value. 1072 Note that, even though communications are protected with Group 1073 OSCORE, some information might still leak, due to the observable 1074 size, source address and destination address of exchanged messages. 1076 10. IANA Considerations 1078 This document has the following actions for IANA. 1080 10.1. ACE Profile Registry 1082 IANA is asked to enter the following value into the "ACE Profile" 1083 Registry defined in Section 8.8 of [I-D.ietf-ace-oauth-authz]. 1085 o Name: coap_group_oscore 1087 o Description: Profile to secure communications between constrained 1088 nodes using the Authentication and Authorization for Constrained 1089 Environments framework, by enabling authentication and fine- 1090 grained authorization of members of an OSCORE group, that use a 1091 pre-established Group OSCORE Security Context to communicate with 1092 Group OSCORE. Optionally, the dual mode defined in Appendix A 1093 additionally establishes a pairwise OSCORE Security Context, and 1094 thus also enables OSCORE communication between two members of the 1095 OSCORE group. 1097 o CBOR Value: TBD (value between 1 and 255) 1099 o Reference: [[this document]] 1101 10.2. OAuth Parameters Registry 1103 IANA is asked to enter the following values into the "OAuth 1104 Parameters" Registry defined in Section 11.2 of [RFC6749]. 1106 o Name: "context_id" 1108 o Parameter Usage Location: token request 1110 o Change Controller: IESG 1112 o Specification Document(s): Section 3.1.1 of [[this document]] 1114 o Name: "salt_input" 1116 o Parameter Usage Location: token request 1118 o Change Controller: IESG 1120 o Specification Document(s): Section 3.1.2 of [[this document]] 1122 o Name: "client_cred_verify" 1124 o Parameter Usage Location: token request 1126 o Change Controller: IESG 1128 o Specification Document(s): Section 3.1.3 of [[this document]] 1130 o Name: "client_cred" 1132 o Parameter Usage Location: token request 1134 o Change Controller: IESG 1136 o Specification Document(s): Appendix A.2.1.1 of [[this document]] 1138 10.3. OAuth Parameters CBOR Mappings Registry 1140 IANA is asked to enter the following values into the "OAuth 1141 Parameters CBOR Mappings" Registry defined in Section 8.10 of 1142 [I-D.ietf-ace-oauth-authz]. 1144 o Name: "context_id" 1145 o CBOR Key: TBD1 1147 o Value Type: bstr 1149 o Reference: Section 3.1.1 of [[this document]] 1151 o Name: "salt_input" 1153 o CBOR Key: TBD2 1155 o Value Type: bstr 1157 o Reference: Section 3.1.2 of [[this document]] 1159 o Name: "client_cred_verify" 1161 o CBOR Key: TBD3 1163 o Value Type: bstr 1165 o Reference: Section 3.1.3 of [[this document]] 1167 o Name: "client_cred" 1169 o CBOR Key: TBD6 1171 o Value Type: bstr 1173 o Reference: Appendix A.2.1.1 of [[this document]] 1175 10.4. CBOR Web Token Claims Registry 1177 IANA is asked to enter the following values into the "CBOR Web Token 1178 Claims" Registry defined in Section 9.1 of [RFC8392]. 1180 o Claim Name: "salt_input" 1182 o Claim Description: Client provided salt input 1184 o JWT Claim Name: "N/A" 1186 o Claim Key: TBD4 1188 o Claim Value Type(s): bstr 1189 o Change Controller: IESG 1191 o Specification Document(s): Section 3.2.1 of [[this document]] 1193 o Claim Name: "contextId_input" 1195 o Claim Description: Client context id input 1197 o JWT Claim Name: "N/A" 1199 o Claim Key: TBD5 1201 o Claim Value Type(s): bstr 1203 o Change Controller: IESG 1205 o Specification Document(s): Section 3.2.2 of [[this document]] 1207 o Claim Name: "client_cred" 1209 o Claim Description: Client Credential 1211 o JWT Claim Name: "N/A" 1213 o Claim Key: TBD7 1215 o Claim Value Type(s): map 1217 o Change Controller: IESG 1219 o Specification Document(s): Appendix A.2.2.2 of [[this document]] 1221 10.5. TLS Exporter Label Registry 1223 IANA is asked to register the following entry in the "TLS Exporter 1224 Label" Registry defined in Section 6 of [RFC5705] and updated in 1225 Section 12 of [RFC8447]. 1227 o Value: EXPORTER-ACE-Sign-Challenge-Client-AS 1229 o DTLS-OK: Y 1231 o Recommended: N 1233 o Reference: [[this document]] (Section 3.1) 1235 11. References 1237 11.1. Normative References 1239 [I-D.ietf-ace-key-groupcomm-oscore] 1240 Tiloca, M., Park, J., and F. Palombini, "Key Management 1241 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1242 oscore-10 (work in progress), February 2021. 1244 [I-D.ietf-ace-oauth-authz] 1245 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1246 H. Tschofenig, "Authentication and Authorization for 1247 Constrained Environments (ACE) using the OAuth 2.0 1248 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-37 1249 (work in progress), February 2021. 1251 [I-D.ietf-ace-oauth-params] 1252 Seitz, L., "Additional OAuth Parameters for Authorization 1253 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 1254 params-13 (work in progress), April 2020. 1256 [I-D.ietf-ace-oscore-profile] 1257 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1258 "OSCORE Profile of the Authentication and Authorization 1259 for Constrained Environments Framework", draft-ietf-ace- 1260 oscore-profile-16 (work in progress), January 2021. 1262 [I-D.ietf-core-groupcomm-bis] 1263 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1264 for the Constrained Application Protocol (CoAP)", draft- 1265 ietf-core-groupcomm-bis-03 (work in progress), February 1266 2021. 1268 [I-D.ietf-core-oscore-groupcomm] 1269 Tiloca, M., Selander, G., Palombini, F., Mattsson, J., and 1270 J. Park, "Group OSCORE - Secure Group Communication for 1271 CoAP", draft-ietf-core-oscore-groupcomm-11 (work in 1272 progress), February 2021. 1274 [I-D.ietf-cose-rfc8152bis-algs] 1275 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1276 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12 1277 (work in progress), September 2020. 1279 [I-D.ietf-cose-rfc8152bis-struct] 1280 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1281 Structures and Process", draft-ietf-cose-rfc8152bis- 1282 struct-15 (work in progress), February 2021. 1284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1285 Requirement Levels", BCP 14, RFC 2119, 1286 DOI 10.17487/RFC2119, March 1997, 1287 . 1289 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1290 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1291 March 2010, . 1293 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1294 Key Derivation Function (HKDF)", RFC 5869, 1295 DOI 10.17487/RFC5869, May 2010, 1296 . 1298 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1299 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1300 . 1302 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1303 Keranen, A., and P. Hallam-Baker, "Naming Things with 1304 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1305 . 1307 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1308 Application Protocol (CoAP)", RFC 7252, 1309 DOI 10.17487/RFC7252, June 2014, 1310 . 1312 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1313 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1314 May 2017, . 1316 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1317 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1318 May 2018, . 1320 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1321 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1322 . 1324 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1325 "Object Security for Constrained RESTful Environments 1326 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1327 . 1329 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1330 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1331 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 1332 2020, . 1334 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1335 Representation (CBOR)", STD 94, RFC 8949, 1336 DOI 10.17487/RFC8949, December 2020, 1337 . 1339 11.2. Informative References 1341 [I-D.ietf-ace-dtls-authorize] 1342 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1343 L. Seitz, "Datagram Transport Layer Security (DTLS) 1344 Profile for Authentication and Authorization for 1345 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1346 authorize-15 (work in progress), January 2021. 1348 [I-D.ietf-ace-mqtt-tls-profile] 1349 Sengul, C. and A. Kirby, "Message Queuing Telemetry 1350 Transport (MQTT)-TLS profile of Authentication and 1351 Authorization for Constrained Environments (ACE) 1352 Framework", draft-ietf-ace-mqtt-tls-profile-10 (work in 1353 progress), December 2020. 1355 [I-D.ietf-tls-dtls13] 1356 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1357 Datagram Transport Layer Security (DTLS) Protocol Version 1358 1.3", draft-ietf-tls-dtls13-41 (work in progress), 1359 February 2021. 1361 [I-D.tiloca-core-oscore-discovery] 1362 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1363 Groups with the CoRE Resource Directory", draft-tiloca- 1364 core-oscore-discovery-08 (work in progress), February 1365 2021. 1367 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1368 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1369 January 2012, . 1371 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1372 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1373 . 1375 Appendix A. Dual Mode (Group OSCORE & OSCORE) 1377 This appendix defines the dual mode of this profile, which allows 1378 using both OSCORE [RFC8613] and Group OSCORE 1379 [I-D.ietf-core-oscore-groupcomm] as security protocols, by still 1380 relying on a single Access Token. 1382 That is, the dual mode of this profile specifies how a Client uses 1383 CoAP [RFC7252] to communicate to a single Resource Server, or CoAP 1384 over IP multicast [I-D.ietf-core-groupcomm-bis] to communicate to 1385 multiple Resource Servers that are members of a group and share a 1386 common set of resources. 1388 In particular, the dual mode of this profile uses two complementary 1389 security protocols to provide secure communication between the Client 1390 and the Resource Server(s). That is, it defines the use of either 1391 OSCORE or Group OSCORE to protect unicast requests addressed to a 1392 single Resource Server, as well as possible responses. Additionally, 1393 it defines the use of Group OSCORE to protect multicast requests sent 1394 to a group of Resource Servers, as well as possible individual 1395 responses. Like in the main mode of this profile, the Client and the 1396 Resource Servers need to have already joined the same OSCORE group, 1397 for instance by using the approach defined in 1398 [I-D.ietf-ace-key-groupcomm-oscore], which is also based on ACE. 1400 The Client proves its access to be authorized to the Resource Server 1401 by using an Access Token, which is bound to a key (the proof-of- 1402 possession key). This profile mode uses OSCORE to achieve proof of 1403 possession, and OSCORE or Group OSCORE to achieve server 1404 authentication. 1406 Unlike in the main mode of this profile, where a public key is used 1407 as pop-key, this dual mode uses OSCORE-related, symmetric key 1408 material as pop-key instead. Furthermore, this dual mode provides 1409 proof of Client's membership to the correct OSCORE group, by securely 1410 binding the pre-established Group OSCORE Security Context to the 1411 pairwise OSCORE Security Context newly established between the Client 1412 and the Resource Server. 1414 In addition to the terminology used for the main mode of this 1415 profile, the rest of this appendix refers also to "pairwise OSCORE 1416 Security Context" as to an OSCORE Security Context established 1417 between only one Client and one Resource Server, and used to 1418 communicate with OSCORE [RFC8613]. 1420 A.1. Protocol Overview 1422 This section provides an overview on how to use the ACE framework for 1423 authentication and authorization [I-D.ietf-ace-oauth-authz] to secure 1424 communications between a Client and a (set of) Resource Server(s) 1425 using OSCORE [RFC8613] and/or Group OSCORE 1426 [I-D.ietf-core-oscore-groupcomm]. 1428 Just as for main mode of this profile overviewed in Section 2, the 1429 process for joining the OSCORE group through the respective Group 1430 Manager as defined in [I-D.ietf-ace-key-groupcomm-oscore] must take 1431 place before the process described in the rest of this section, and 1432 is out of the scope of this profile. 1434 An overview of the protocol flow for the dual mode of this profile is 1435 shown in Figure 8. In the figure, it is assumed that both RS1 and 1436 RS2 are associated with the same AS. It is also assumed that C, RS1 1437 and RS2 have previously joined an OSCORE group with Group Identifier 1438 (gid) "abcd0000", and got assigned Sender ID (sid) "0", "1" and "2" 1439 in the group, respectively. The names of messages coincide with 1440 those of [I-D.ietf-ace-oauth-authz] when applicable. 1442 C RS1 RS2 AS 1443 | [--- Resource Request --->] | | | 1444 | | | | 1445 | [<---- AS Request ------] | | | 1446 | Creation Hints | | | 1447 | | | | 1448 |-------- POST /token ------------------------------------------------>| 1449 | (aud: RS1, sid: 0, gid: abcd0000, ...) | | 1450 | | | | 1451 |<--------------------------------- Access Token + RS Information -----| 1452 | | (aud: RS1, sid: 0, gid: abcd0000, ...) | 1453 | | | | 1454 |---- POST /authz-info ------>| | | 1455 | (access_token, N1, ID1) | | | 1456 | | | | 1457 |<-- 2.01 Created (N2, ID2) --| | | 1458 | | | | 1459 /Pairwise Sec /Pairwise Sec | | 1460 Context Derivation/ Context Derivation/ | | 1461 | | | | 1462 |-------- POST /token ------------------------------------------------>| 1463 | (aud: RS2, sid: 0, gid: abcd0000, ...) | | 1464 | | | | 1465 |<--------------------------------- Access Token + RS Information -----| 1466 | | (aud: RS2, sid: 0, gid: abcd0000, ...) | 1467 | | | | 1468 |----- POST /authz-info ------------------>| | 1469 | (access_token, N1', ID1') | | | 1470 | | | | 1471 |<-- 2.01 Created (N2', ID2')--------------| | 1472 | | | | 1473 /Pairwise Sec | /Pairwise Sec | 1474 Context Derivation/ | Context Derivation/ | 1475 | | | | 1476 |------ OSCORE Request ------>| | | 1477 | (kid: ID2) | | | 1478 | | | | 1479 | /Proof-of-possession; | | 1480 | Pairwise Sec Context storage/ | | 1481 | | | | 1482 |<----- OSCORE Response ------| | | 1483 | | | | 1484 /Proof-of-possession; | | | 1485 Paiwise Sec Context storage/ | | | 1486 | | | | 1487 /Mutual authentication | | | 1488 between C and RS1 | | | 1489 (as OSCORE peers)/ | | | 1490 | | | | 1491 | | | | 1492 |-- Group OSCORE Request -+-->| | | 1493 | (kid: 0, gid: abcd0000) \-------------->| | 1494 | | | | 1495 |<--- Group OSCORE Response --| | | 1496 | (kid: 1) | | | 1497 | | | | 1498 /Mutual authentication | | | 1499 between C and RS1 | | | 1500 (as group members)/ | | | 1501 | | | | 1502 |<--- Group OSCORE Response ---------------| | 1503 | (kid: 2) | | | 1504 | | | | 1505 /Mutual authentication | | | 1506 between C and RS2 | | | 1507 (as group members)/ | | | 1508 | | | | 1509 | ... | | | 1511 Figure 8: Protocol Overview. 1513 A.1.1. Pre-Conditions 1515 The same pre-conditions for the main mode of this profile (see 1516 Section 2.1) hold for the dual mode described in this appendix. 1518 A.1.2. Access Token Posting 1520 After having retrieved the Access Token from the AS, the Client 1521 generates a nonce N1 and an identifier ID1 unique in the sets of its 1522 own Recipient IDs from its pairwise OSCORE Security Contexts. The 1523 client then posts both the Access Token, N1 and its chosen ID to the 1524 RS, using the /authz-info endpoint and mechanisms specified in 1525 Section 5.10 of [I-D.ietf-ace-oauth-authz] and Content-Format = 1526 application/ace+cbor. When using the dual mode of this profile, the 1527 communication with the authz-info endpoint is not protected, except 1528 for update of access rights. Note that, when using the dual mode, 1529 this request can alternatively be protected with Group OSCORE, using 1530 the Group OSCORE Security Context paired with the pairwise OSCORE 1531 Security Context originally established with the first Access Token 1532 posting. 1534 If the Access Token is valid, the RS replies to this POST request 1535 with a 2.01 (Created) response with Content-Format = application/ 1536 ace+cbor, which in a CBOR map contains a nonce N2 and an identifier 1537 ID2 unique in the sets of its own Recipient IDs from its pairwise 1538 OSCORE Security Contexts. 1540 A.1.3. Setup of the Pairwise OSCORE Security Context 1542 After sending the 2.01 (Created) response, the RS sets the ID Context 1543 of the pairwise OSCORE Security Context (see Section 3 of [RFC8613]) 1544 to the Group Identifier of the OSCORE group specified in the Access 1545 Token, concatenated with N1, concatenated with N2, concatenated with 1546 the value in the contextId parameter of the OSCORE_Input_Material 1547 provided in the 'cnf' claim of the Access Token. 1549 Then, the RS derives the complete pairwise OSCORE Security Context 1550 associated with the received Access Token, following Section 3.2 of 1551 [RFC8613]. In practice, the RS maintains a collection of Security 1552 Contexts with associated authorization information, for all the 1553 clients that it is currently communicating with, and the 1554 authorization information is a policy used as input when processing 1555 requests from those clients. 1557 During the derivation process, the RS uses: the ID Context above; the 1558 nonces N1 and N2; the identifier ID1 received from the Client, set as 1559 its own OSCORE Sender ID; the identifier ID2 provided to the Client, 1560 set as its Recipient ID for the Client; and the parameters in the 1561 Access Token. The derivation process uses also the Master Secret of 1562 the OSCORE group, that the RS knows as a group member, as well as the 1563 Sender ID of the Client in the OSCORE group, which is specified in 1564 the Access Token. This ensures that the pairwise OSCORE Security 1565 Context is securely bound to the Group OSCORE Security Context of the 1566 OSCORE group. 1568 Finally, the RS stores the association between i) the authorization 1569 information from the Access Token; and ii) the Group Identifier of 1570 the OSCORE group together with the Sender ID and the public key of 1571 the Client in that group. 1573 After having received the nonce N2, the Client sets the ID Context in 1574 its pairwise OSCORE Security Context (see Section 3 of [RFC8613]) to 1575 the Group Identifier of the OSCORE group, concatenated with N1, 1576 concatenated with N2, concatenated with the value in the contextId 1577 parameter of the OSCORE_Input_Material provided in the 'cnf' 1578 parameter of the Access Token response from the AS. Then, the Client 1579 derives the complete pairwise OSCORE Security Context, following 1580 Section 3.2 of [RFC8613]. 1582 During the derivation process, the Client uses: the ID Context above, 1583 the nonces N1 and N2; the identifier ID1 provided to the RS, set as 1584 its own Recipient ID for the RS; the identifier ID2 received from the 1585 RS, set as its own OSCORE Sender ID; and the parameters received from 1586 the AS. The derivation process uses also the Master Secret of the 1587 OSCORE group, that the Client knows as a group member, as well as its 1588 own Sender ID in the OSCORE group. 1590 When the Client communicates with the RS using the pairwise OSCORE 1591 Security Context, the RS achieves proof-of-possession of the 1592 credentials bound to the Access Token. Also, the RS verifies that 1593 the Client is a legitimate member of the OSCORE group. 1595 A.1.4. Secure Communication 1597 Other than starting the communication with the RS using Group OSCORE 1598 as described in Section 4.3, the Client can send to the RS a request 1599 protected with OSCORE, using the pairwise OSCORE Security Context. 1601 If the request is successfully verified, then the RS stores the 1602 pairwise OSCORE Security Context, and uses it to protect the possible 1603 response, as well as further communications with the Client, until 1604 the Access Token is deleted, due to e.g. expiration. This pairwise 1605 OSCORE Security Context is discarded when an Access Token (whether 1606 the same or different) is used to successfully derive a new pairwise 1607 OSCORE Security Context. 1609 As discussed in Section 7 of [I-D.ietf-ace-oscore-profile], the use 1610 of random nonces N1 and N2 during the exchange between the Client and 1611 the RS prevents the reuse of AEAD nonces and keys with different 1612 messages. Reuse might otherwise occur when Client and RS derive a 1613 new pairwise OSCORE Security Context from an existing (non-expired) 1614 Access Token, e.g. in case of reboot of either the Client or the RS, 1615 and might lead to loss of both confidentiality and integrity. 1617 Additionally, just as per the main mode of this profile (see 1618 Section 4.3), the Client and RS can also securely communicate by 1619 protecting messages with Group OSCORE, using the Group OSCORE 1620 Security Context already established upon joining the OSCORE group. 1622 A.2. Client-AS Communication 1624 This section details the Access Token POST Request that the Client 1625 sends to the /token endpoint of the AS, as well as the related Access 1626 Token response. 1628 Section 3.2 of [RFC8613] defines how to derive a pairwise OSCORE 1629 Security Context based on a shared Master Secret and a set of other 1630 parameters, established between the OSCORE client and server, which 1631 the client receives from the AS in this exchange. 1633 The proof-of-possession key (pop-key) received from the AS in this 1634 exchange MUST be used to build the Master Secret in OSCORE (see 1635 Appendix A.3.3 and Appendix A.3.4). 1637 A.2.1. C-to-AS: POST to Token Endpoint 1639 The Client-to-AS request is specified in Section 5.8.1 of 1640 [I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request 1641 to the /token endpoint over a secure channel that guarantees 1642 authentication, message integrity and confidentiality. 1644 The POST request is formatted as the analogous Client-to-AS request 1645 in the main mode of this profile (see Section 3.1), with the 1646 following modifications. 1648 o The parameter 'req_cnf' MUST NOT be included in the payload. 1650 o The parameter 'client_cred', defined in Appendix A.2.1.1 of this 1651 specification, MUST be included in the payload. This parameter 1652 includes the public key associated to the signing private key that 1653 the Client uses in the OSCORE group, whose identifier is indicated 1654 in the 'context_id' parameter. 1656 o The signature included in the parameter 'client_cred_verify' is 1657 computed by using the private key associated to the public key in 1658 the 'client_cred' parameter above. 1660 An example of such a request, with payload in CBOR diagnostic 1661 notation without the tag and value abbreviations is reported in 1662 Figure 9. 1664 Header: POST (Code=0.02) 1665 Uri-Host: "as.example.com" 1666 Uri-Path: "token" 1667 Content-Format: "application/ace+cbor" 1668 Payload: 1669 { 1670 "audience" : "tempSensor4711", 1671 "scope" : "read", 1672 "context_id" : h'abcd0000', 1673 "salt_input" : h'00', 1674 "client_cred" : { 1675 "COSE_Key" : { 1676 "kty" : EC2, 1677 "crv" : P-256, 1678 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 1679 27c9e354089bbe13', 1680 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 1681 731e79a3b4e47120' 1682 } 1683 }, 1684 "client_cred_verify" : h'...' 1685 (signature content omitted for brevity), 1686 } 1688 Figure 9: Example C-to-AS POST /token request for an Access Token 1689 bound to a symmetric key. 1691 Later on, the Client may want to update its current access rights, 1692 without changing the existing pairwise OSCORE Security Context with 1693 the RS. In this case, the Client MUST include in its POST request to 1694 the /token endpoint a 'req_cnf' parameter, defined in Section 3.1 of 1695 [I-D.ietf-ace-oauth-params], which MUST include a 'kid' field, as 1696 defined in Section 3.1 of [RFC8747]. The 'kid' field has as value a 1697 CBOR byte string containing the OSCORE_Input_Material Identifier 1698 (assigned as discussed in Appendix A.2.2). 1700 This identifier, together with other information such as audience, 1701 can be used by the AS to determine the shared secret bound to the 1702 proof-of-possession Access Token and therefore MUST identify a 1703 symmetric key that was previously generated by the AS as a shared 1704 secret for the communication between the Client and the RS. The AS 1705 MUST verify that the received value identifies a proof-of-possession 1706 key that has previously been issued to the requesting Client. If 1707 that is not the case, the Client-to-AS request MUST be declined with 1708 the error code 'invalid_request' as defined in Section 5.8.3 of 1709 [I-D.ietf-ace-oauth-authz]. 1711 This POST request for updating the access rights of an Access Token 1712 SHOULD NOT include the parameters 'salt_input', 'context_id', 1713 'client_cred' and 'client_cred_verify'. An exception is the case 1714 defined in Appendix A.3.6, where the Client, following a change of 1715 public key in the OSCORE group, requests a new Access Token 1716 associated to the new public key, while still without changing the 1717 existing pairwise OSCORE Security Context with the RS. 1719 An example of such a request, with payload in CBOR diagnostic 1720 notation without the tag and value abbreviations is reported in 1721 Figure 10. 1723 Header: POST (Code=0.02) 1724 Uri-Host: "as.example.com" 1725 Uri-Path: "token" 1726 Content-Format: "application/ace+cbor" 1727 Payload: 1728 { 1729 "audience" : "tempSensor4711", 1730 "scope" : "read", 1731 "req_cnf" : { 1732 "kid" : h'01' 1733 } 1734 } 1736 Figure 10: Example C-to-AS POST /token request for updating rights to 1737 an Access Token bound to a symmetric key. 1739 A.2.1.1. 'client_cred' Parameter 1741 The 'client_cred' parameter is an OPTIONAL parameter of the Access 1742 Token request message defined in Section 5.8.1. of 1743 [I-D.ietf-ace-oauth-authz]. This parameter provides an asymmetric 1744 key that the Client wishes to use as its own public key, but which is 1745 not used as proof-of-possession key. 1747 This parameter follows the syntax of the 'cnf' claim from Section 3.1 1748 of [RFC8747] when including Value Type "COSE_Key" (1) and specifying 1749 an asymmetric key. Alternative Value Types defined in future 1750 specifications are fine to consider if indicating a non-encrypted 1751 asymmetric key. 1753 A.2.2. AS-to-C: Access Token 1755 After having verified the POST request to the /token endpoint and 1756 that the Client is authorized to obtain an Access Token corresponding 1757 to its Access Token request, the AS MUST verify the signature in the 1758 'client_cred_verify' parameter, by using the public key specified in 1759 the 'client_cred' parameter. If the verification fails, the AS 1760 considers the Client request invalid. The AS does not perform this 1761 operation when asked to update a previously released Access Token. 1763 If all verifications are successful, the AS responds as defined in 1764 Section 5.8.2 of [I-D.ietf-ace-oauth-authz]. If the Client request 1765 was invalid, or not authorized, the AS returns an error response as 1766 described in Section 5.8.3 of [I-D.ietf-ace-oauth-authz]. 1768 The AS can signal that the use of OSCORE and Group OSCORE is REQUIRED 1769 for a specific Access Token by including the 'profile' parameter with 1770 the value "coap_group_oscore" in the Access Token response. This 1771 means that the Client MUST use OSCORE and/or Group OSCORE towards all 1772 the Resource Servers for which this Access Token is valid. 1774 In particular, the Client MUST follow Appendix A.3.3 to derive the 1775 pairwise OSCORE Security Context to use for communications with the 1776 RS. Instead, the Client has already established the related Group 1777 OSCORE Security Context to communicate with members of the OSCORE 1778 group, upon previously joining that group. 1780 Usually, it is assumed that constrained devices will be pre- 1781 configured with the necessary profile, so that this kind of profile 1782 signaling can be omitted. 1784 In contrast with the main mode of this profile, the Access Token 1785 response to the Client is analogous to the one in the OSCORE profile 1786 of ACE, as described in Section 3.2 of [I-D.ietf-ace-oscore-profile]. 1787 In particular, the AS provides an OSCORE_Input_Material object, which 1788 is defined in Section 3.2.1 of [I-D.ietf-ace-oscore-profile] and 1789 included in the 'cnf' parameter (see Section 3.2 of 1790 [I-D.ietf-ace-oauth-params]) of the Access Token response. 1792 The AS MUST send different OSCORE_Input_Material (and therefore 1793 different Access Tokens) to different authorized clients, in order 1794 for the RS to differentiate between clients. 1796 In the issued Access Token, the AS MUST include as metadata the same 1797 information as defined in the main mode of this profile (see 1798 Section 3.2) with the following modifications. 1800 o The public key that the client uses in the OSCORE group and 1801 specified in the 'client_cred' parameter of the Token request (see 1802 Appendix A.2.1) MUST also be included in the Access Token. If the 1803 Access Token is a CWT, the AS MUST include it in the 'client_cred' 1804 claim of the Access Token, defined in Appendix A.2.2.2 of this 1805 specification. 1807 o The OSCORE_Input_Material specified in the 'cnf' parameter of the 1808 Access Token response MUST also be included in the Access Token. 1809 If the Access Token is a CWT, the same OSCORE_Input_Material 1810 included in the 'cnf' parameter of the Access Token response MUST 1811 be included in the 'osc' field (see Section 9.5 of 1812 [I-D.ietf-ace-oscore-profile]) of the 'cnf' claim of the Access 1813 Token. 1815 Figure 11 shows an example of such an AS response, with payload in 1816 CBOR diagnostic notation without the tag and value abbreviations. 1818 Header: Created (Code=2.01) 1819 Content-Type: "application/ace+cbor" 1820 Payload: 1821 { 1822 "access_token" : h'8343a1010aa2044c53 ...' 1823 (remainder of CWT omitted for brevity), 1824 "profile" : "coap_group_oscore", 1825 "expires_in" : 3600, 1826 "cnf" : { 1827 "osc" : { 1828 "alg" : AES-CCM-16-64-128, 1829 "id" : h'01', 1830 "ms" : h'f9af838368e353e78888e1426bd94e6f', 1831 "salt" : h'1122', 1832 "contextId" : h'99' 1833 } 1834 } 1835 } 1837 Figure 11: Example AS-to-C Access Token response with the Group 1838 OSCORE profile. 1840 Figure 12 shows an example CWT, containing the necessary OSCORE 1841 parameters in the 'cnf' claim, in CBOR diagnostic notation without 1842 tag and value abbreviations. 1844 { 1845 "aud" : "tempSensorInLivingRoom", 1846 "iat" : 1360189224, 1847 "exp" : 1360289224, 1848 "scope" : "temperature_g firmware_p", 1849 "cnf" : { 1850 "osc" : { 1851 "alg" : AES-CCM-16-64-128, 1852 "id" : h'01', 1853 "ms" : h'f9af838368e353e78888e1426bd94e6f', 1854 "salt" : h'1122', 1855 "contextId" : h'99' 1856 }, 1857 "salt_input" : h'00', 1858 "contextId_input" : h'abcd0000', 1859 "client_cred" : { 1860 "COSE_Key" : { 1861 "kty" : EC2, 1862 "crv" : P-256, 1863 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 1864 27c9e354089bbe13', 1865 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 1866 731e79a3b4e47120' 1867 } 1868 } 1869 } 1871 Figure 12: Example CWT with OSCORE parameters (CBOR diagnostic 1872 notation). 1874 The same CWT as in Figure 12 and encoded in CBOR is shown in 1875 Figure 13, using the value abbreviations defined in 1876 [I-D.ietf-ace-oauth-authz] and [RFC8747]. 1878 NOTE: it should be checked (and in case fixed) that the values used 1879 below (which are not yet registered) are the final values registered 1880 in IANA. 1882 A8 # map(8) 1883 03 # unsigned(3) 1884 76 # text(22) 1885 74656D7053656E736F72496E4C6976696E67526F6F6D 1886 06 # unsigned(6) 1887 1A 5112D728 # unsigned(1360189224) 1888 04 # unsigned(4) 1889 1A 51145DC8 # unsigned(1360289224) 1890 09 # unsigned(9) 1891 78 18 # text(24) 1892 74656D70657261747572655F67206669726D776172655F70 1893 08 # unsigned(8) 1894 A1 # map(1) 1895 04 # unsigned(4) 1896 A5 # map(5) 1897 04 # unsigned(4) 1898 0A # unsigned(10) 1899 00 # unsigned(0) 1900 41 # bytes(1) 1901 01 # "\x01" 1902 02 # unsigned(2) 1903 50 # bytes(16) 1904 F9AF838368E353E78888E1426BD94E6F 1905 05 # unsigned(5) 1906 42 # bytes(2) 1907 1122 # "\x11\"" 1908 06 # unsigned(6) 1909 41 # bytes(1) 1910 99 # "\x99" 1911 18 3C # unsigned(60) 1912 41 # bytes(1) 1913 00 1914 18 3D # unsigned(61) 1915 44 # bytes(4) 1916 ABCD0000 1917 18 3E # unsigned(62) 1918 A1 # map(1) 1919 01 # unsigned(1) 1920 A4 # map(4) 1921 01 # unsigned(1) 1922 02 # unsigned(2) 1923 20 # negative(0) 1924 01 # unsigned(1) 1925 21 # negative(1) 1926 58 20 # bytes(32) 1927 D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9 1928 E354089BBE13 1929 22 # negative(2) 1930 58 20 # bytes(32) 1931 F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E515D020731E 1932 79A3B4E47120 1934 Figure 13: Example CWT with OSCORE parameters. 1936 If the Client has requested an update to its access rights using the 1937 same pairwise OSCORE Security Context, which is valid and authorized, 1938 the AS MUST omit the 'cnf' parameter in the response to the client. 1940 Instead, the updated Access Token conveyed in the AS-to-C response 1941 MUST include a 'cnf' claim specifying a 'kid' field, as defined in 1942 Section 3.1 of [RFC8747]. The response from the AS MUST carry the 1943 OSCORE Input Material identifier in the 'kid' field within the 'cnf' 1944 claim of the Access Token. That is, the 'kid' field is a CBOR byte 1945 string, with value the same value of the 'kid' field of the 'req_cnf' 1946 parameter from the C-to-AS request for updating rights to the Access 1947 Token (see Figure 10). This information needs to be included in the 1948 Access Token, in order for the RS to identify the previously 1949 generated pairwise OSCORE Security Context. 1951 Figure 14 shows an example of such an AS response, with payload in 1952 CBOR diagnostic notation without the tag and value abbreviations. 1953 The Access Token has been truncated for readability. 1955 Header: Created (Code=2.01) 1956 Content-Type: "application/ace+cbor" 1957 Payload: 1958 { 1959 "access_token" : h'8343a1010aa2044c53 ...' 1960 (remainder of CWT omitted for brevity), 1961 "profile" : "coap_group_oscore", 1962 "expires_in" : 3600 1963 } 1965 Figure 14: Example AS-to-C Access Token response with the Group 1966 OSCORE profile, for update of access rights. 1968 Figure 15 shows an example CWT, containing the necessary OSCORE 1969 parameters in the 'cnf' claim for update of access rights, in CBOR 1970 diagnostic notation without tag and value abbreviations. 1972 { 1973 "aud" : "tempSensorInLivingRoom", 1974 "iat" : 1360189224, 1975 "exp" : 1360289224, 1976 "scope" : "temperature_h", 1977 "cnf" : { 1978 "kid" : h'01' 1979 } 1980 } 1982 Figure 15: Example CWT with OSCORE parameters for update of access 1983 rights. 1985 A.2.2.1. Public Key Hash as Client Credential 1987 As a possible optimization to limit the size of the Access Token, the 1988 AS may specify as value of the 'client_cred' claim simply the hash of 1989 the Client's public key. The specifically used hash-function MUST be 1990 collision-resistant on byte-strings, and MUST be selected from the 1991 "Named Information Hash Algorithm" Registry defined in Section 9.4 of 1992 [RFC6920]. 1994 In particular, the AS provides the Client with an Access Token as 1995 defined in Appendix A.2.2, with the following differences. 1997 The AS prepares INPUT_HASH as follows, with | denoting byte string 1998 concatenation. 2000 o If the public key has COSE Key Type OKP, INPUT_HASH = i, where 'i' 2001 is the x-parameter of the COSE_Key specified in the 'client_cred' 2002 parameter of the Token request, encoded as a CBOR byte string. 2004 o If the public key has COSE Key Type EC2, INPUT_HASH = (i_1 | i_2), 2005 where 'i_1' and 'i_2' are the x-parameter and y-parameter of the 2006 COSE_Key specified in the 'client_cred' parameter of the Token 2007 request, respectively, each encoded as a CBOR byte string. 2009 o If the public key has COSE Key Type RSA, INPUT_HASH = (i_1 | i_2), 2010 where 'i_1' and 'i_2' are the n-parameter and e-parameter of the 2011 COSE_Key specified in the 'client_cred' parameter of the Token 2012 request, respectively, each encoded as a CBOR byte string. 2014 Then, the AS hashes INPUT_HASH according to the procedure described 2015 in [RFC6920], with the output OUTPUT_HASH in binary format, as 2016 described in Section 6 of [RFC6920]. 2018 Finally, the AS includes a single entry within the 'client_cred' 2019 claim of the Access Token. This entry has label "kid" (3) defined in 2020 Section 3.1 of [RFC8747], and value a CBOR byte string wrapping 2021 OUTPUT_HASH. 2023 Upon receiving the Access Token, the RS processes it according to 2024 Appendix A.3.2, with the following differences. 2026 The RS considers the content of the 'client_cred' claim as the hash 2027 of the public key associated to the signing private key that the 2028 Client uses in the OSCORE group, which is identified by the 2029 'context_id' parameter. 2031 The RS MAY additionally request the Group Manager of the OSCORE group 2032 for the public key of that Client, as described in 2034 [I-D.ietf-ace-key-groupcomm-oscore], specifying as Sender ID of that 2035 Client in the OSCORE group the value of the 'salt_input' claim 2036 included in the Access Token. 2038 In such a case, the RS MUST check that the hash of the key retrieved 2039 from the Group Manager matches the hash retrieved from the 2040 'client_cred' claim of the Access Token. The RS MUST calculate the 2041 hash using the same method as the AS described above, and using the 2042 same hash function. The hash function used can be determined from 2043 the information conveyed in the 'client_cred' claim, as the procedure 2044 described in [RFC6920] also encodes the used hash function as 2045 metadata of the hash value. 2047 A.2.2.2. Client Credential Claim 2049 The 'client_cred' claim provides an asymmetric key that the Client 2050 owning the Access Token wishes to use as its own public key, but 2051 which is not used as proof-of-possession key. 2053 This parameter follows the syntax of the 'cnf' claim from Section 3.1 2054 of [RFC8747] when including Value Type "COSE_Key" (1) and specifying 2055 an asymmetric key. Alternative Value Types defined in future 2056 specifications are fine to consider if indicating a non-encrypted 2057 asymmetric key. 2059 A.3. Client-RS Communication 2061 This section details the POST request and response to the /authz-info 2062 endpoint between the Client and the RS. With respect to the 2063 exchanged messages and their content, the Client and the RS perform 2064 as defined in Section 4 of the OSCORE profile of ACE 2065 [I-D.ietf-ace-oscore-profile]. 2067 That is, the Client generates a nonce N1 and posts it to the RS, 2068 together with: an identifier ID1 unique in the sets of its own 2069 Recipient IDs from its pairwise OSCORE Security Contexts; and the 2070 Access Token that includes the material provisioned by the AS. 2072 Then, the RS generates a nonce N2, and an identifier ID2 unique in 2073 the sets of its own Recipient IDs from its pairwise OSCORE Security 2074 Contexts. After that, the RS derives a pairwise OSCORE Security 2075 Context as described in Section 3.2 of [RFC8613]. In particular, it 2076 uses the two nonces and the two identifiers established with the 2077 Client, as well as two shared secrets together with additional pieces 2078 of information specified in the Access Token. 2080 Both the client and the RS generate the pairwise OSCORE Security 2081 Context using the pop-key as part of the OSCORE Master Secret. In 2082 addition, the derivation of the pairwise OSCORE Security Context 2083 takes as input also information related to the OSCORE group, i.e. the 2084 Master Secret and Group Identifier of the group, as well as the 2085 Sender ID of the Client in the group. Hence, the derived pairwise 2086 OSCORE Security Context is also securely bound to the Group OSCORE 2087 Security Context of the OSCORE Group. Thus, the proof-of-possession 2088 required to bind the Access Token to the Client occurs after the 2089 first OSCORE message exchange. 2091 Therefore, an attacker using a stolen Access Token cannot generate a 2092 valid pairwise OSCORE Security Context and thus cannot prove 2093 possession of the pop-key. Also, if a Client legitimately owns an 2094 Access Token but has not joined the OSCORE group, that Client cannot 2095 generate a valid pairwise OSCORE Security Context either, since it 2096 lacks the Master Secret used in the OSCORE group. 2098 Besides, just as in the main mode (see Section 4), the RS is able to 2099 verify whether the Client has indeed the claimed Sender ID and public 2100 key in the OSCORE group. 2102 A.3.1. C-to-RS POST to authz-info Endpoint 2104 The Client MUST generate a nonce N1, an OSCORE Recipient ID (ID1), 2105 and post them to the /authz-info endpoint of the RS together with the 2106 Access Token, as defined in Section 4.1 of the OSCORE profile of ACE 2107 [I-D.ietf-ace-oscore-profile]. 2109 The same recommendations, considerations and behaviors defined in 2110 Section 4.1 of [I-D.ietf-ace-oscore-profile] hold. 2112 If the Client has already posted a valid Access Token, has already 2113 established a pairwise OSCORE Security Context with the RS, and wants 2114 to update its access rights, the Client can do so by posting the new 2115 Access Token (retrieved from the AS and specifying the updated set of 2116 access rights) to the /authz-info endpoint. 2118 The Client MUST protect the request using either the pairwise OSCORE 2119 Security Context established during the first Access Token exchange, 2120 or the Group OSCORE Security Context associated to that pairwise 2121 OSCORE Security Context. 2123 In either case, the Client MUST only send the Access Token in the 2124 payload, i.e. no nonce or identifier are sent. After proper 2125 verification (see Section 4.2 of [I-D.ietf-ace-oscore-profile]), the 2126 new Access Token will supersede the old one at the RS, by replacing 2127 the corresponding authorization information. At the same time, the 2128 RS will maintain the same pairwise OSCORE Security Context and Group 2129 OSCORE Security Context, as now both associated to the new Access 2130 Token. 2132 A.3.2. RS-to-C: 2.01 (Created) 2134 The RS MUST verify the validity of the Access Token as defined in 2135 Section 4.2, with the following modifications. 2137 o If the POST request to /authz-info is not protected, the RS checks 2138 that the 'cnf' claim is included in the Access Token and that it 2139 contains an OSCORE_Input_Material object. Also, the RS checks 2140 that the 'salt_input', 'client_cred' and 'contextId_input' claims 2141 are included in the Access Token. 2143 o If the POST request to /authz-info is protected with the pairwise 2144 OSCORE Security Context shared with the Client or with the Group 2145 OSCORE Security Context of the OSCORE group, i.e. the Client is 2146 requesting an update of access rights, the RS checks that the 2147 'cnf' claim is included in the Access Token and that it contains 2148 only the 'kid' field. 2150 o If the 'salt_input', 'client_cred' and 'contextId_input' claims 2151 are included in the Access Token, the RS extracts the content of 2152 'client_cred'. Then, the RS considers that content as the public 2153 key associated to the signing private key of the Client in the 2154 OSCORE group, whose GID is specified in the 'contextId_input' 2155 claim. The RS can compare this public key with the public key of 2156 the claimed Client retrieved from the Group Manager (see 2157 Section 4.2). 2159 If any of the checks fails, the RS MUST consider the Access Token non 2160 valid, and MUST respond to the Client with an error response code 2161 equivalent to the CoAP code 4.00 (Bad Request). 2163 If the Access Token is valid and further checks on its content are 2164 successful, the RS proceeds as follows. 2166 In case the POST request to /authz-info was not protected, the RS 2167 MUST generate a nonce N2, an OSCORE Recipient ID (ID2), and include 2168 them in the 2.01 (Created) response to the Client, as defined in 2169 Section 4.2 of the OSCORE profile of ACE 2170 [I-D.ietf-ace-oscore-profile]. 2172 Instead, in case the POST request to /authz-info was protected, the 2173 RS MUST ignore any nonce and identifiers in the request, if any was 2174 sent. Then, the RS MUST check that the 'kid' field of the 'cnf' 2175 claim in the new Access Token matches the identifier of the OSCORE 2176 Input Material of a pairwise OSCORE Security Context such that: 2178 o The pairwise OSCORE Security Context was used to protect the 2179 request, if this was protected with OSCORE; or 2181 o The pairwise OSCORE Security Context is bound to the Group OSCORE 2182 Security Context used to protect the request, if this was 2183 protected with Group OSCORE. 2185 If either verification is successful, the new Access Token supersedes 2186 the old one at the RS. Besides, the RS associates the new Access 2187 Token to the same pairwise OSCORE Security Context identified above, 2188 as also bound to a Group OSCORE Security Context. The RS MUST 2189 respond with a 2.01 (Created) response with no payload, protected 2190 with the same Security Context used to protect the request. In 2191 particular, no new pairwise OSCORE Security Context is established 2192 between the Client and the RS. If any verification fails, the RS 2193 MUST respond with a 4.01 (Unauthorized) error response. 2195 Further recommendations, considerations and behaviors defined in 2196 Section 4.2 of [I-D.ietf-ace-oscore-profile] hold for this 2197 specification. 2199 A.3.3. OSCORE Setup - Client Side 2201 Once having received the 2.01 (Created) response from the RS, 2202 following an unprotected POST request to the /authz-info endpoint, 2203 the Client MUST extract the nonce N2 from the 'nonce2' parameter, and 2204 the Client identifier from the 'ace_server_recipientid' parameter in 2205 the CBOR map of the response payload. Note that this identifier is 2206 used by C as Sender ID in the pairwise OSCORE Security Context to be 2207 established with the RS, and is different as well as unrelated to the 2208 Sender ID of C in the OSCORE group. 2210 Then, the Client performs the following actions, in order to set up 2211 and fully derive the pairwise OSCORE Security Context for 2212 communicating with the RS. 2214 o The Client MUST set the ID Context of the pairwise OSCORE Security 2215 Context as the concatenation of: i) GID, i.e. the Group Identifier 2216 of the OSCORE group, as specified by the Client in the 2217 'context_id' parameter of the Client-to-AS request; ii) the nonce 2218 N1; iii) the nonce N2; and iv) CID, i.e. the value in the 2219 contextId parameter of the OSCORE_Input_Material provided in the 2220 'cnf' parameter of the Access Token response from the AS. The 2221 concatenation occurs in this order: ID Context = GID | N1 | N2 | 2222 CID, where | denotes byte string concatenation. 2224 o The Client MUST set the updated Master Salt of the pairwise OSCORE 2225 Security Context as the concatenation of SaltInput, MSalt, the 2226 nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the 2227 Sender ID that the Client has in the OSCORE group, which is known 2228 to the Client as a member of the OSCORE group; ii) MSalt is the 2229 (optional) Master Salt in the pairwise OSCORE Security Context 2230 (received from the AS in the Token); and iii) GMSalt is the 2231 (optional) Master Salt in the Group OSCORE Security Context, which 2232 is known to the Client as a member of the OSCORE group. The 2233 concatenation occurs in this order: Master Salt = SaltInput | 2234 MSalt | N1 | N2 | GMSalt, where | denotes byte string 2235 concatenation. Optional values, if not specified, are not 2236 included in the concatenation. The five parameters SaltInput, 2237 MSalt, N1, N2 and GMSalt are to be concatenated as encoded CBOR 2238 byte strings. An example of Master Salt construction using CBOR 2239 encoding is given in Figure 16. 2241 SaltInput, MSalt, N1, N2 and GMSalt, in CBOR diagnostic notation: 2242 SaltInput = h'00' 2243 MSalt = h'f9af838368e353e78888e1426bd94e6f' 2244 N1 = h'018a278f7faab55a' 2245 N2 = h'25a8991cd700ac01' 2246 GMSalt = h'99' 2248 SaltInput, MSalt, N1, N2 and GMSalt, as CBOR encoded byte strings: 2249 SaltInput = 0x4100 2250 MSalt = 0x50f9af838368e353e78888e1426bd94e6f 2251 N1 = 0x48018a278f7faab55a 2252 N2 = 0x4825a8991cd700ac01 2253 GMSalt = 0x4199 2255 Master Salt = 0x41 00 2256 50 f9af838368e353e78888e1426bd94e6f 2257 48 018a278f7faab55a 2258 48 25a8991cd700ac01 2259 41 99 2261 Figure 16: Example of Master Salt construction using CBOR encoding. 2263 o The Client MUST set the Master Secret of the pairwise OSCORE 2264 Security Context to the concatenation of MSec and GMSec, where: i) 2265 MSec is the value of the 'ms' parameter in the 2266 OSCORE_Input_Material of the 'cnf' parameter, received from the AS 2267 in Appendix A.2.2; while ii) GMSec is the Master Secret of the 2268 Group OSCORE Security Context, which is known to the Client as a 2269 member of the OSCORE group. 2271 o The Client MUST set the Recipient ID as ace_client_recipientid, 2272 sent as described in Appendix A.3.1. 2274 o The Client MUST set the Sender ID as ace_server_recipientid, 2275 received as described in Appendix A.3.1. 2277 o The Client MUST set the AEAD Algorithm, ID Context, HKDF, and 2278 OSCORE Version as indicated in the corresponding parameters 2279 received from the AS in Appendix A.2.2, if present in the 2280 OSCORE_Input_Material of the 'cnf' parameter. In case these 2281 parameters are omitted, the default values SHALL be used as 2282 described in Section 3.2 and 5.4 of [RFC8613]. 2284 Finally, the client MUST derive the complete pairwise OSCORE Security 2285 Context following Section 3.2.1 of [RFC8613]. 2287 From then on, when communicating with the RS to access the resources 2288 as specified by the authorization information, the Client MUST use 2289 the newly established pairwise OSCORE Security Context or the Group 2290 OSCORE Security Context of the OSCORE Group where both the Client and 2291 the RS are members. 2293 If any of the expected parameters is missing (e.g., any of the 2294 mandatory parameters from the AS or the RS), or if 2295 ace_client_recipientid equals ace_server_recipientid (and as a 2296 consequence the Sender and Recipient Keys derived would be equal, see 2297 Section 3.3 of [RFC8613]), then the client MUST stop the exchange, 2298 and MUST NOT derive the pairwise OSCORE Security Context. The Client 2299 MAY restart the exchange, to get the correct security input material. 2301 The Client can use this pairwise OSCORE Security Context to send 2302 requests to the RS protected with OSCORE. Besides, the Client can 2303 use the Group OSCORE Security Context for protecting unicast requests 2304 to the RS, or multicast requests to the OSCORE group including also 2305 the RS. Mutual authentication as group members is only achieved 2306 after the client has successfully verified the Group OSCORE protected 2307 response from the RS. Similarly, mutual authentication as OSCORE 2308 peers is only achieved after the client has successfully verified the 2309 OSCORE protected response from the RS, using the pairwise OSCORE 2310 Security Context. 2312 Note that the ID Context of the pairwise OSCORE Security Context can 2313 be assigned by the AS, communicated and set in both the RS and Client 2314 after the exchange specified in this profile is executed. 2315 Subsequently, the Client and RS can update their ID Context by 2316 running a mechanism such as the one defined in Appendix B.2 of 2317 [RFC8613] if they both support it and are configured to do so. In 2318 that case, the ID Context in the pairwise OSCORE Security Context 2319 will not match the "contextId" parameter of the corresponding 2320 OSCORE_Input_Material. Running the procedure in Appendix B.2 of 2321 [RFC8613] results in the keying material in the pairwise OSCORE 2322 Security Contexts of the Client and RS being updated. The Client can 2323 achieve the same result by re-posting the Access Token to the 2324 unprotected /authz-info endpoint at the RS, as described in 2325 Section 4.1 of [I-D.ietf-ace-oscore-profile], although without 2326 updating the ID Context. 2328 A.3.4. OSCORE Setup - Resource Server Side 2330 After validation of the Access Token as defined in Appendix A.3.2 and 2331 after sending the 2.01 (Created) response to an unprotected POST 2332 request to the /authz-info endpoint, the RS performs the following 2333 actions, in order to set up and fully derive the pairwise OSCORE 2334 Security Context created to communicate with the Client. 2336 o The RS MUST set the ID Context of the pairwise OSCORE Security 2337 Context as the concatenation of: i) GID, i.e. the Group Identifier 2338 of the OSCORE group, as specified in the 'contextId' parameter of 2339 the OSCORE_Input_Material, in the 'cnf' claim of the Access Token 2340 received from the Client (see Appendix A.3.1); ii) the nonce N1; 2341 iii) the nonce N2; and iv) CID which is the value in the contextId 2342 parameter of the OSCORE_Input_Material provided in the 'cnf' claim 2343 of the Access Token. The concatenation occurs in this order: ID 2344 Context = GID | N1 | N2 | CID, where | denotes byte string 2345 concatenation. 2347 o The RS MUST set the new Master Salt of the pairwise OSCORE 2348 Security Context as the concatenation of SaltInput, MSalt, the 2349 nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the 2350 Sender ID that the Client has in the OSCORE group, as specified in 2351 the 'salt_input' claim included in the Access Token received from 2352 the Client (see Appendix A.3.1); ii) MSalt is the (optional) 2353 Master Salt in the pairwise OSCORE Security Context as specified 2354 in the 'salt' parameter in the OSCORE_Input_Material of the 'cnf' 2355 claim, included in the Access Token received from the Client; and 2356 iii) GMSalt is the (optional) Master Salt in the Group OSCORE 2357 Security Context, which is known to the RS as a member of the 2358 OSCORE group. The concatenation occurs in this order: Master Salt 2359 = SaltInput | MSalt | N1 | N2 | GMSalt, where | denotes byte 2360 string concatenation. Optional values, if not specified, are not 2361 included in the concatenation. The same considerations for 2362 building the Master Salt, considering the inputs as encoded CBOR 2363 byte strings as in Figure 16, hold also for the RS. 2365 o The RS MUST set the Master Secret of the pairwise OSCORE Security 2366 Context to the concatenation of MSec and GMSec, where: i) MSec is 2367 the value of the 'ms' parameter in the OSCORE_Input_Material of 2368 the 'cnf' claim, included in the Access Token received from the 2369 Client (see Appendix A.3.1); while ii) GMSec is the Master Secret 2370 of the Group OSCORE Security Context, which is known to the RS as 2371 a member of the OSCORE group. 2373 o The RS MUST set the Recipient ID as ace_server_recipientid, sent 2374 as described in Appendix A.3.2. 2376 o The RS MUST set the Sender ID as ace_client_recipientid, received 2377 as described in Appendix A.3.2. 2379 o The RS MUST set the AEAD Algorithm, ID Context, HKDF, and OSCORE 2380 Version from the corresponding parameters received from the Client 2381 in the Access Token (see Appendix A.3.1), if present in the 2382 OSCORE_Input_Material of the 'cnf' claim. In case these 2383 parameters are omitted, the default values SHALL be used as 2384 described in Section 3.2 and 5.4 of [RFC8613]. 2386 Finally, the RS MUST derive the complete pairwise OSCORE Security 2387 Context following Section 3.2.1 of [RFC8613]. 2389 Once having completed the derivation above, the RS MUST associate the 2390 authorization information from the Access Token with the just 2391 established pairwise OSCORE Security Context. Furthermore, as 2392 defined in Section 4.2, the RS MUST associate the authorization 2393 information from the Access Token with the Group OSCORE Security 2394 Context. 2396 Then, the RS uses this pairwise OSCORE Security Context to verify 2397 requests from and send responses to the Client protected with OSCORE, 2398 when this Security Context is used. If OSCORE verification fails, 2399 error responses are used, as specified in Section 8 of [RFC8613]. 2401 Besides, the RS uses the Group OSCORE Security Context to verify 2402 (multicast) requests from and send responses to the Client protected 2403 with Group OSCORE. When processing an incoming request protected 2404 with Group OSCORE, the RS MUST consider as valid public key of the 2405 Client only the public key specified in the stored Access Token. As 2406 defined in Appendix A.3.6, a change of public key in the group 2407 requires the Client to upload to the RS a new Access Token, 2408 specifying the new public key in the 'client_cred' claim. 2410 If Group OSCORE verification fails, error responses are used, as 2411 specified in Section 8 and Section 9 of 2412 [I-D.ietf-core-oscore-groupcomm]. Additionally, for every incoming 2413 request, if OSCORE or Group OSCORE verification succeeds, the 2414 verification of access rights is performed as described in 2415 Appendix A.3.5. 2417 After the deletion of the Access Token related to a pairwise OSCORE 2418 Security Context and to a Group OSCORE Security Context, due to e.g. 2419 expiration, the RS MUST NOT use the pairwise OSCORE Security Context. 2420 The RS MUST respond with an unprotected 4.01 (Unauthorized) error 2421 message to received requests that correspond to a pairwise OSCORE 2422 Security Context with a deleted Access Token. Also, if the Client 2423 uses the Group OSCORE Security Context to send a request for any 2424 resource intended for OSCORE group members and that requires an 2425 active Access Token, the RS MUST respond with a 4.01 (Unauthorized) 2426 error message protected with the Group OSCORE Security Context. 2428 The same considerations, related to the value of the ID Context 2429 changing, as in Appendix A.3.3 hold also for the RS. 2431 A.3.5. Access Rights Verification 2433 The RS MUST follow the procedures defined in Section 4.4. 2435 Additionally, if the RS receives an OSCORE-protected request from a 2436 Client, the RS processes it according to [RFC8613]. 2438 If the OSCORE verification succeeds, and the target resource requires 2439 authorization, the RS retrieves the authorization information from 2440 the Access Token associated to the pairwise OSCORE Security Context 2441 and to the Group OSCORE Security Context. Then, the RS MUST verify 2442 that the action requested on the resource is authorized. 2444 The response code MUST be 4.01 (Unauthorized) if the RS has no valid 2445 Access Token for the Client. 2447 A.3.6. Change of Client's Public Key in the Group 2449 During its membership in the OSCORE group, the client might change 2450 the public key it uses in the group. When this happens, the Client 2451 uploads the new public key to the Group Manager, as defined in 2452 Section 11 of [I-D.ietf-ace-key-groupcomm-oscore]. 2454 After that, the Client may still have an Access Token previously 2455 uploaded to the RS, which is not expired yet and still valid to the 2456 best of the Client's knowledge. Then, in order to continue 2457 communicating with the RS, the Client MUST perform the following 2458 actions. 2460 1. The Client requests a new Access Token to the AS, as defined in 2461 Appendix A.2.1 for the update of access rights, i.e. with the 2462 'req_cnf' parameter including only a 'kid' field. In particular, 2463 when sending the POST request to the AS, the Client indicates: 2465 * The current Group Identifier of the OSCORE group, as value of 2466 the 'context_id' parameter. 2468 * The current Sender ID it has in the OSCORE group, as value of 2469 the 'salt_input' parameter. 2471 * The new public key it has in the OSCORE group, as value of the 2472 'client_cred' parameter. 2474 * The proof-of-possession signature corresponding to the new 2475 public key, as value of the 'client_cred_verify' parameter. 2477 * The same current or instead new set of access rights, as value 2478 of the 'scope' parameter. 2480 2. After receiving the response from the AS (see Appendix A.2.2), 2481 the Client performs the same exchanges with the RS as defined in 2482 Appendix A.3, with the following difference: the POST request to 2483 /authz-info for uploading the new Access Token MUST be protected 2484 with the pairwise OSCORE Security Context shared with the RS. 2486 When receiving the new Access Token, the RS performs the same steps 2487 defined in Appendix A.3.2. In particular, no new pairwise OSCORE 2488 Security Context is established between the Client and the RS. 2490 A.4. Secure Communication with the AS 2492 The same considerations for secure communication with the AS as 2493 defined in Section 5 hold. 2495 A.5. Discarding the Security Context 2497 The Client and the RS MUST follow what is defined in Section 6 of 2498 [I-D.ietf-ace-oscore-profile] about discarding the pairwise OSCORE 2499 Security Context. 2501 Additionally, they MUST follow what is defined in the main mode of 2502 the profile (see Section 6), with respect to the Group OSCORE 2503 Security Context. 2505 The Client or RS can acquire a new Group OSCORE Security Context, by 2506 re-joining the OSCORE group, e.g. by using the approach defined in 2507 [I-D.ietf-ace-key-groupcomm-oscore]. In such a case, the Client 2508 SHOULD request a new Access Token and post it to the RS, in order to 2509 establish a new pairwise OSCORE Security Context and bind it to the 2510 Group OSCORE Security Context obtained upon re-joining the group. 2512 A.6. CBOR Mappings 2514 The new parameters defined in this document MUST be mapped to CBOR 2515 types as specified in Figure 6, with the following addition, using 2516 the given integer abbreviation for the map key. 2518 /----------------+----------+------------\ 2519 | Parameter name | CBOR Key | Value Type | 2520 |----------------+----------+------------| 2521 | client_cred | TBD6 | map | 2522 \----------------+----------+------------/ 2524 Figure 17: CBOR mappings for new parameters. 2526 The new claims defined in this document MUST be mapped to CBOR types 2527 as specified in Figure 7, with the following addition, using the 2528 given integer abbreviation for the map key. 2530 /--------------+----------+------------\ 2531 | Claim name | CBOR Key | Value Type | 2532 |--------------+----------+------------| 2533 | client_cred | TBD7 | map | 2534 \--------------+----------+------------/ 2536 Figure 18: CBOR mappings for new claims. 2538 A.7. Security Considerations 2540 The dual mode of this profile inherits the security considerations 2541 from the main mode (see Section 8), as well as from the security 2542 considerations of the OSCORE profile of ACE 2543 [I-D.ietf-ace-oscore-profile]. Also, the security considerations 2544 about OSCORE [RFC8613] hold for the dual mode of this profile, as to 2545 the specific use of OSCORE. 2547 A.8. Privacy Considerations 2549 The same privacy considerations as defined in the main mode of this 2550 profile apply (see Section 9). 2552 In addition, as this profile mode also uses OSCORE, the privacy 2553 considerations from [RFC8613] apply as well, as to the specific use 2554 of OSCORE. 2556 Furthermore, this profile mode inherits the privacy considerations 2557 from the OSCORE profile of ACE [I-D.ietf-ace-oscore-profile]. 2559 Appendix B. Profile Requirements 2561 This appendix lists the specifications on this profile based on the 2562 requirements of the ACE framework, as requested in Appendix C of 2563 [I-D.ietf-ace-oauth-authz]. 2565 o (Optional) discovery process of how the Client finds the right AS 2566 for an RS it wants to send a request to: Not specified. 2568 o Communication protocol the Client and the RS must use: CoAP. 2570 o Security protocol(s) the Client and RS must use: Group OSCORE, 2571 i.e. exchange of secure messages by using a pre-established Group 2572 OSCORE Security Context. The optional dual mode defined in 2573 Appendix A additionally uses OSCORE, i.e. establishment of a 2574 pairwise OSCORE Security Context and exchange of secure messages. 2576 o How the Client and the RS mutually authenticate: Explicitly, by 2577 possession of a common Group OSCORE Security Context, and by 2578 either: usage of digital counter signatures embedded in messages, 2579 if protected with the group mode of Group OSCORE; or protection of 2580 messages with the pairwise mode of Group OSCORE, by using pairwise 2581 symmetric keys, derived from the asymmetric keys of the two peers 2582 exchanging the message. Note that the mutual authentication is 2583 not completed before the Client has verified an OSCORE or a Group 2584 OSCORE response using the corresponding security context. 2586 o Content-format of the protocol messages: "application/ace+cbor". 2588 o Proof-of-Possession protocol(s) and how to select one; which key 2589 types (e.g. symmetric/asymmetric) supported: Group OSCORE 2590 algorithms; distributed and verified asymmetric keys. In the 2591 optional dual mode defined in Appendix A: OSCORE algorithms; pre- 2592 established symmetric keys. 2594 o profile identifier: coap_group_oscore 2596 o (Optional) how the RS talks to the AS for introspection: HTTP/CoAP 2597 (+ TLS/DTLS/OSCORE). 2599 o How the client talks to the AS for requesting a token: HTTP/CoAP 2600 (+ TLS/DTLS/OSCORE). 2602 o How/if the authz-info endpoint is protected: Not protected. 2604 o (Optional) other methods of token transport than the authz-info 2605 endpoint: Not specified. 2607 Acknowledgments 2609 The authors sincerely thank Benjamin Kaduk, John Mattsson, Dave 2610 Robin, Jim Schaad and Goeran Selander for their comments and 2611 feedback. 2613 The work on this document has been partly supported by VINNOVA and 2614 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 2615 (Grant agreement 952652). 2617 Authors' Addresses 2619 Marco Tiloca 2620 RISE AB 2621 Isafjordsgatan 22 2622 Kista SE-16440 Stockholm 2623 Sweden 2625 Email: marco.tiloca@ri.se 2627 Rikard Hoeglund 2628 RISE AB 2629 Isafjordsgatan 22 2630 Kista SE-16440 Stockholm 2631 Sweden 2633 Email: rikard.hoglund@ri.se 2635 Ludwig Seitz 2636 Combitech 2637 Djaeknegatan 31 2638 Malmoe SE-21135 Malmoe 2639 Sweden 2641 Email: ludwig.seitz@combitech.se 2643 Francesca Palombini 2644 Ericsson AB 2645 Torshamnsgatan 23 2646 Kista SE-16440 Stockholm 2647 Sweden 2649 Email: francesca.palombini@ericsson.com