idnits 2.17.1 draft-tiloca-ace-group-oscore-profile-02.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 : ---------------------------------------------------------------------------- ** There are 81 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 09, 2020) is 1481 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-05 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-33 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-12 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-10 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-07 ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-09 == Outdated reference: A later version (-17) exists of draft-ietf-ace-mqtt-tls-profile-04 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-37 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-05 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 3 errors (**), 0 flaws (~~), 10 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: September 10, 2020 L. Seitz 6 Combitech 7 F. Palombini 8 Ericsson AB 9 March 09, 2020 11 Group OSCORE Profile of the Authentication and Authorization for 12 Constrained Environments Framework 13 draft-tiloca-ace-group-oscore-profile-02 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 public 25 key. Also, it provides proof of Client's membership to the correct 26 OSCORE group, by binding the Access Token to information from the 27 Group OSCORE Security Context, thus allowing the Resource Server(s) 28 to verify the Client's membership upon receiving a message protected 29 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 September 10, 2020. 48 Copyright Notice 50 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . 8 70 2.3. Access Token Posting . . . . . . . . . . . . . . . . . . 9 71 2.4. Secure Communication . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . 16 80 4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 16 81 4.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . . . 17 82 4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 17 83 4.3. Client-RS Secure Communication . . . . . . . . . . . . . 18 84 4.3.1. Client Side . . . . . . . . . . . . . . . . . . . . . 18 85 4.3.2. Resource Server Side . . . . . . . . . . . . . . . . 18 86 4.4. Access Rights Verification . . . . . . . . . . . . . . . 19 87 5. Secure Communication with the AS . . . . . . . . . . . . . . 19 88 6. Discarding the Security Context . . . . . . . . . . . . . . . 19 89 7. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . . . 20 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 91 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 93 10.1. ACE Profile Registry . . . . . . . . . . . . . . . . . . 21 94 10.2. OAuth Parameters Registry . . . . . . . . . . . . . . . 22 95 10.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . 23 96 10.4. CBOR Web Token Claims Registry . . . . . . . . . . . . . 23 97 10.5. TLS Exporter Label Registry . . . . . . . . . . . . . . 25 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 99 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 100 11.2. Informative References . . . . . . . . . . . . . . . . . 27 101 Appendix A. Dual Mode (Group OSCORE & OSCORE) . . . . . . . . . 28 102 A.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 29 103 A.1.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . 31 104 A.1.2. Access Token Posting . . . . . . . . . . . . . . . . 31 105 A.1.3. Setup of the Pairwise OSCORE Security Context . . . . 31 106 A.1.4. Secure Communication . . . . . . . . . . . . . . . . 32 107 A.2. Client-AS Communication . . . . . . . . . . . . . . . . . 33 108 A.2.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . 33 109 A.2.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . 36 110 A.3. Client-RS Communication . . . . . . . . . . . . . . . . . 43 111 A.3.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . 44 112 A.3.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . 44 113 A.3.3. OSCORE Setup - Client Side . . . . . . . . . . . . . 45 114 A.3.4. OSCORE Setup - Resource Server Side . . . . . . . . . 47 115 A.3.5. Access Rights Verification . . . . . . . . . . . . . 49 116 A.4. Secure Communication with the AS . . . . . . . . . . . . 49 117 A.5. Discarding the Security Context . . . . . . . . . . . . . 50 118 A.6. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . 50 119 A.7. Security Considerations . . . . . . . . . . . . . . . . . 50 120 A.8. Privacy Considerations . . . . . . . . . . . . . . . . . 51 121 Appendix B. Profile Requirements . . . . . . . . . . . . . . . . 51 122 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 52 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 125 1. Introduction 127 A number of applications rely on a group communication model, where a 128 Client can access a resource shared by multiple Resource Servers at 129 once, e.g. over IP multicast. Typical examples are switching of 130 luminaries, actuators control, and distribution of software updates. 131 Secure communication in the group can be achieved by sharing a set of 132 key material, which is typically provided upon joining the group. 134 For some instances of such applications, it may be just fine to 135 enforce access control in a straightforward and plain fashion. That 136 is, it is assumed that any Client authorized to join the group and to 137 get the group key material, is also implicitly authorized as a group 138 member to perform any action at any resource of any Server in the 139 group. An example of an application where such implicit 140 authorization might be used is a lighting scenario, where the 141 lightbulbs are the Servers, while the user account on an app on the 142 user's phone is the Client. In this case, it might be fine to not 143 require additional authorization evidence from any user account, if 144 it is acceptable that any current group member is also authorized to 145 switch on and off any light, or to check their status. 147 However, in different instances of such applications, the approach 148 above is not desirable, as different group members are intended to 149 have different access rights to resources of other group members. 150 For instance, a more fine-grained authorization approach is required 151 in the two following use cases. 153 As a first case, an application provides control of smart locks 154 acting as Servers in the group, where: a first type of Client, e.g. a 155 user account of a child, is allowed to only query the status of the 156 smart locks; while a second type of Client, e.g. a user account of a 157 parent, is allowed to both query and change the status of the smart 158 locks. Further similar applications concern the enforcement of 159 different sets of permissions in groups with sensor/actuator devices, 160 e.g. thermostats, acting as Servers. Also, some group members may 161 even be intended as Servers only. Hence, they must be prevented from 162 acting as Clients altogether and from accessing resources at other 163 Servers, especially when attempting to perform non-safe operations. 165 As a second case, building automation scenarios often rely on Servers 166 that, under different circumstances, enforce different level of 167 priority for processing received commands. For instance, BACnet 168 deployments consider multiple classes of Clients, e.g. a normal light 169 switch (C1) and an emergency fire panel (C2). Then, a C1 Client is 170 not allowed to override a command from a C2 Client, until the latter 171 relinquishes control at its higher priority. That is: i) only C2 172 Clients should be able to adjust the minimum required level of 173 priority on the Servers, so rightly locking out C1 Clients if needed; 174 and ii) when a Server is set to accept only high-priority commands, 175 only C2 Clients should be able to perform such commands otherwise 176 allowed also to C1 Clients. Given the different maximum authority of 177 different Clients, fine-grained access control would effectively 178 limit the execution of high- and emergency-priority commands only to 179 devices that are in fact authorized to do so. Besides, it would 180 prevent a misconfigured or compromised device from initiating a high- 181 priority command and lock out normal control. 183 Hence, in the cases discussed above, being a legitimate group member 184 and having obtained the group key material is not supposed to imply 185 any particular access rights. Also, introducing a different security 186 group for each different set of access rights would result in 187 additional key material to distribute and manage. In particular, if 188 the access rights for a single node change, this would require to 189 evict that node from the current group, followed by that node joining 190 a different group aligned with its new access rights. Moreover, the 191 key material of both groups would have to be renewed for their 192 current members. Overall, this would have a non negligible impact on 193 operations and performance in the system. 195 A fine-grained access control model can be rather enforced within a 196 same group, by using the Authentication and Authorization for 197 Constrained Environments (ACE) framework [I-D.ietf-ace-oauth-authz]. 198 That is, a Client has to first obtain authorization credentials in 199 the form of an Access Token, and post it to the Resource Server(s) in 200 the group before accessing the intended resources. 202 The ACE framework delegates to separate profile documents how to 203 secure communications between the Client and the Resource Server. 204 However each of the current profiles of ACE defined in 205 [I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-dtls-authorize] 206 [I-D.ietf-ace-mqtt-tls-profile] admits a single security protocol 207 that cannot be used to protect group messages sent over IP multicast. 209 This document specifies a profile of ACE, where a Client uses CoAP 210 [RFC7252] or CoAP over IP multicast [I-D.dijk-core-groupcomm-bis] to 211 communicate to one or multiple Resource Servers, which are members of 212 an application group and share a common set of resources. This 213 profile uses Group OSCORE [I-D.ietf-core-oscore-groupcomm] as the 214 security protocol to protect messages exchanged between the Client a 215 the Resource Servers. Hence, it requires that both the Client and 216 the Resource Servers have previously joined the same OSCORE group. 218 That is, this profile describes how access control is enforced for a 219 Client after it has joined an OSCORE group, to access resources at 220 other members in that group. The process for joining the OSCORE 221 group through the respective Group Manager as defined in 222 [I-D.ietf-ace-key-groupcomm-oscore] takes place before the process 223 described in this document, and is out of the scope of this profile. 225 The Client authorizes its access to the Resource Server by using an 226 Access Token, which is bound to a key (the proof-of-possession key). 227 This profile uses Group OSCORE to achieve server authentication, as 228 well as proof-of-possession for the Client public key associated to 229 the signing private key used in an OSCORE group. Furthermore, this 230 profile provides proof of Client's membership to the correct OSCORE 231 group, by binding the Access Token to the Client public key and 232 information from the pre-established Group OSCORE Security Context, 233 thus allowing the Resource Server to verify this upon reception of a 234 messages protected with Group OSCORE from the Client. 236 OSCORE [RFC8613] specifies how to use COSE [RFC8152] to secure CoAP 237 messages. Group OSCORE builds on OSCORE to provide secure group 238 communication, and ensures source authentication by means of digital 239 countersignatures embedded in protected messages. 241 1.1. Terminology 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 245 "OPTIONAL" in this document are to be interpreted as described in BCP 246 14 [RFC2119] [RFC8174] when, and only when, they appear in all 247 capitals, as shown here. 249 Readers are expected to be familiar with the terms and concepts 250 related to the CoAP protocol [RFC7252], as well as related to the 251 protection and processing of CoAP messages in OSCORE [RFC8613] and 252 Group OSCORE [I-D.ietf-core-oscore-groupcomm]. These include the 253 concept of Group Manager, as the entity responsible for a set of 254 groups where communications among members are secured with Group 255 OSCORE. 257 Readers are expected to be familiar with the terms and concepts 258 described in the ACE framework for authentication and authorization 259 [I-D.ietf-ace-oauth-authz], as well as in the OSCORE profile of ACE 260 [I-D.ietf-ace-oscore-profile]. The terminology for entities in the 261 considered architecture is defined in OAuth 2.0 [RFC6749]. In 262 particular, this includes Client (C), Resource Server (RS), and 263 Authorization Server (AS). 265 Note that, unless otherwise indicated, the term "endpoint" is used 266 here following its OAuth definition, aimed at denoting resources such 267 as /token and /introspect at the AS, and /authz-info at the RS. This 268 document does not use the CoAP definition of "endpoint", which is "An 269 entity participating in the CoAP protocol". 271 2. Protocol Overview 273 This section provides an overview of this profile, i.e. on how to use 274 the ACE framework for authentication and authorization 275 [I-D.ietf-ace-oauth-authz] to secure communications between a Client 276 and a (set of) Resource Server(s) using Group OSCORE 277 [I-D.ietf-core-oscore-groupcomm]. 279 Note that this profile of ACE describes how access control can be 280 enforced for a node after it has joined an OSCORE group, to access 281 resources at other members in that group. 283 In particular, the process for joining the OSCORE group through the 284 respective Group Manager as defined in 285 [I-D.ietf-ace-key-groupcomm-oscore] must take place before the 286 process described in this document, and is out of the scope of this 287 profile. 289 An overview of the protocol flow for this profile is shown in 290 Figure 1. In the figure, it is assumed that both RS1 and RS2 are 291 associated with the same AS. It is also assumed that C, RS1 and RS2 292 have previously joined an OSCORE group with Group Identifier (gid) 293 "abcd0000", and got assigned Sender ID (sid) "0", "1" and "2" in the 294 group, respectively. 296 C RS1 RS2 AS 297 | [--- Resource Request --->] | | | 298 | | | | 299 | [<--- AS Information -----] | | | 300 | | | | 301 |-------- POST /token -------------------------------------------------->| 302 | (aud: RS1, sid: 0, gid: abcd0000, ... ) | | 303 | | | | 304 |<---------------------------------- Access Token + RS Information ------| 305 | | (aud: RS1, sid: 0, gid: abcd0000, ... ) | 306 |---- POST /authz-info ------>| | | 307 | (access_token) | | | 308 | | | | 309 |<--- 2.01 Created ------| | | 310 | | | | 311 |-------- POST /token -------------------------------------------------->| 312 | (aud: RS2, sid: 0, gid: abcd0000, ... ) | | 313 | | | | 314 |<---------------------------------- Access Token + RS Information ------| 315 | | (aud: RS2, sid: 0, gid: abcd0000, ... ) | 316 | | | | 317 |----- POST /authz-info ------------------->| | 318 | (access_token) | | | 319 | | | | 320 |<--- 2.01 Created -------------------| | 321 | | | | 322 |-- Group OSCORE Request --+-->| | | 323 | (kid: 0, gid: abcd0000) \--------------->| | 324 | | | | 325 |<--- Group OSCORE Response ---| | | 326 | (kid: 1) | | | 327 | | | | 328 |<--- Group OSCORE Response ----------------| | 329 | (kid: 2) | | | 330 | ... | | | 332 Figure 1: Protocol Overview. 334 2.1. Pre-Conditions 336 Using Group OSCORE and this profile requires both the Client and the 337 Resource Servers to have previously joined an OSCORE group. This 338 especially includes the derivation of the Group OSCORE Security 339 Context and the assignment of unique Sender IDs to use in the group. 340 Nodes may join the OSCORE group through the respective Group Manager 341 by using the approach defined in [I-D.ietf-ace-key-groupcomm-oscore], 342 which is also based on ACE. 344 After the Client and Resource Servers have joined the group, this 345 profile provides access control for accessing resources on those 346 Resource Servers, by securely communicating with Group OSCORE. 348 As a pre-requisite for this profile, the Client has to have 349 successfully joined the OSCORE group where also the Resource Servers 350 (RSs) are members. Depending on the limited information initially 351 available, the Client may have to first discover the exact OSCORE 352 group used by the RSs for the resources of interest, e.g. by using 353 the approach defined in [I-D.tiloca-core-oscore-discovery]. 355 2.2. Access Token Retrieval 357 This profile requires that the Client retrieves an Access Token from 358 the AS for the resource(s) it wants to access on each of the RSs, 359 using the /token endpoint, as specified in Section 5.6 of 360 [I-D.ietf-ace-oauth-authz]. In a general case, it can be assumed 361 that different RSs are associated to different ASs, even if the RSs 362 are members of a same OSCORE group. 364 In the Access Token request to the AS, the Client MUST include the 365 Group Identifier of the OSCORE group and its own Sender ID in that 366 group. The AS MUST specify these pieces of information in the Access 367 Token, included in the Access Token response to the Client. 369 Furthermore, in the Access Token request to the AS, the Client MUST 370 also include: its own public key, associated to the private signing 371 key used in the OSCORE group; and a signature computed with such 372 private key, over a quantity uniquely related to the secure 373 communication association between the Client and the AS. The AS MUST 374 include also the public key indicated by the client in the Access 375 Token. 377 To gain knowledge of the AS in charge of a resource hosted at a RS, 378 the Client MAY first send an initial Unauthorized Resource Request 379 message to that RS. Then, the RS denies the request and replies to 380 the Client by specifying the address of its AS, as defined in 381 Section 5.1 of [I-D.ietf-ace-oauth-authz]. The Access Token request 382 and response MUST be confidentiality-protected and ensure 383 authenticity. This profile RECOMMENDS the use of OSCORE between the 384 Client and the AS, but TLS [RFC5246][RFC8446] or DTLS 385 [RFC6347][I-D.ietf-tls-dtls13] MAY be used additionally or instead. 387 2.3. Access Token Posting 389 After having retrieved the Access Token from the AS, the Client posts 390 the Access Token to the RS, using the /authz-info endpoint and 391 mechanisms specified in Section 5.8 of [I-D.ietf-ace-oauth-authz] and 392 Content-Format = application/ace+cbor. 394 If the Access Token is valid, the RS replies to this POST request 395 with a 2.01 (Created) response with Content-Format = application/ 396 ace+cbor. Also, the RS associates the received Access Token with the 397 Group OSCORE Security Context identified by the Group Identifier 398 specified in the Access Token, following Section 3.2 of [RFC8613]. 399 In practice, the RS maintains a collection of Security Contexts with 400 associated authorization information, for all the clients that it is 401 currently communicating with, and the authorization information is a 402 policy used as input when processing requests from those clients. 404 Finally, the RS stores the association between i) the authorization 405 information from the Access Token; and ii) the Group Identifier of 406 the OSCORE group together with the Sender ID and the public key of 407 the Client in that group. This binds the Access Token with the Group 408 OSCORE Security Context of the OSCORE group. 410 Finally, when the Client communicates with the RS using the Group 411 OSCORE Security Context, the RS verifies that the Client is a 412 legitimate member of the OSCORE group and especially the exact group 413 member with the same Sender ID associated to the Access Token. This 414 occurs when verifying a request protected with Group OSCORE, since it 415 embeds a countersignature computed also over the Client's Sender ID 416 included in the message. 418 2.4. Secure Communication 420 The Client can send a request protected with Group OSCORE 421 [I-D.ietf-core-oscore-groupcomm] to the RS. This can be a unicast 422 request addressed to the RS, or a multicast request addressed to the 423 OSCORE group where the RS is also a member. To this end, the Client 424 uses the Group OSCORE Security Context already established upon 425 joining the OSCORE group, e.g. by using the approach defined in 426 [I-D.ietf-ace-key-groupcomm-oscore]. The RS may send a response back 427 to the Client, protecting it by means of the same Group OSCORE 428 Security Context. 430 3. Client-AS Communication 432 This section details the Access Token POST Request that the Client 433 sends to the /token endpoint of the AS, as well as the related Access 434 Token response. 436 The Access Token MUST be bound to the public key of the client as 437 proof-of-possession key (pop-key), by means of the 'cnf' claim. 439 3.1. C-to-AS: POST to Token Endpoint 441 The Client-to-AS request is specified in Section 5.6.1 of 442 [I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request 443 to the /token endpoint over a secure channel that guarantees 444 authentication, message integrity and confidentiality. 446 The POST request is formatted as the analogous Client-to-AS request 447 in the OSCORE profile of ACE (see Section 3.1 of 448 [I-D.ietf-ace-oscore-profile]), with the following additional 449 parameters that MUST be included in the payload. 451 o 'context_id', defined in Section 3.1.1 of this specification. 452 This parameter specifies the Group Identifier (GID), i.e. the Id 453 Context of an OSCORE group where the Client and the RS are 454 currently members. In particular, the Client wishes to 455 communicate with the RS using the Group OSCORE Security Context 456 associated to that OSCORE group. 458 o 'salt_input', defined in Section 3.1.2 of this specification. 459 This parameter includes the Sender ID that the Client has in the 460 OSCORE group whose GID is specified in the 'context_id' parameter 461 above. 463 o 'req_cnf', defined in Section 3.1 of [I-D.ietf-ace-oauth-params]. 464 This parameter includes the public key associated to the signing 465 private key that the Client uses in the OSCORE group whose GID is 466 specified in the 'context_id' parameter above. This public key 467 will be used as the pop-key bound to the Access Token. 469 o 'client_cred_verify', defined in Section 3.1.3 of this 470 specification. This parameter includes a signature computed by 471 the Client, by using the private key associated to the public key 472 in the 'req_cnf' parameter above. This allows the AS to verify 473 that the Client indeed owns the private key associated to that 474 public key, as its alleged identity credential within the OSCORE 475 group. The information to be signed MUST be the byte 476 representation of a quantity that uniquely represents the secure 477 communication association between the Client and the AS. It is 478 RECOMMENDED that the Client considers the following as information 479 to sign. 481 * If the Client and the AS communicate over (D)TLS, the 482 information to sign is an exporter value computed as defined in 483 Section 7.5 of [RFC8446]. In particular, the exporter label 484 MUST be 'EXPORTER-ACE-Sign-Challenge-Client-AS' defined in 485 Section 10.5 of this specification, together with an empty 486 'context_value', and 32 bytes as 'key_length'. 488 * If the Client and the AS communicate over OSCORE, the 489 information to sign is the output PRK of a HKDF-Extract step 490 [RFC5869], i.e. PRK = HMAC-Hash(salt, IKM). In particular, 491 'salt' takes (x1 | x2), where x1 is the ID Context of the 492 OSCORE Security Context between the Client and the AS, x2 is 493 the Sender ID of the Client in that Context, and | denotes byte 494 string concatenation. Also, 'IKM' is the OSCORE Master Secret 495 of the OSCORE Security Context between the Client and the AS. 496 The HKDF MUST be one of the HMAC-based HKDF [RFC5869] 497 algorithms defined for COSE [RFC8152]. HKDF SHA-256 is 498 mandatory to implement. 500 An example of such a request, with payload in CBOR diagnostic 501 notation without the tag and value abbreviations is reported in 502 Figure 2. 504 Header: POST (Code=0.02) 505 Uri-Host: "as.example.com" 506 Uri-Path: "token" 507 Content-Format: "application/ace+cbor" 508 Payload: 509 { 510 "audience" : "tempSensor4711", 511 "scope" : "read", 512 "context_id" : h'abcd0000', 513 "salt_input" : h'00', 514 "req_cnf" : { 515 "COSE_Key" : { 516 "kty" : EC2, 517 "crv" : P-256, 518 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 519 27c9e354089bbe13', 520 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 521 731e79a3b4e47120' 522 } 523 }, 524 "client_cred_verify" : h'...' 525 (signature content omitted for brevity), 526 } 528 Figure 2: Example C-to-AS POST /token request for an Access Token 529 bound to an asymmetric key. 531 3.1.1. 'context_id' Parameter 533 The 'context_id' parameter is an OPTIONAL parameter of the Access 534 Token request message defined in Section 5.6.1. of 535 [I-D.ietf-ace-oauth-authz]. This parameter provides a value that the 536 Client wishes to use with the RS as a hint for a security context. 537 Its exact content is profile specific. 539 3.1.2. 'salt_input' Parameter 541 The 'salt_input' parameter is an OPTIONAL parameter of the Access 542 Token request message defined in Section 5.6.1. of 543 [I-D.ietf-ace-oauth-authz]. This parameter provides a value that the 544 Client wishes to use as part of a salt with the RS, for deriving 545 cryptographic key material. Its exact content is profile specific. 547 3.1.3. 'client_cred_verify' Parameter 549 The 'client_cred_verify' parameter is an OPTIONAL parameter of the 550 Access Token request message defined in Section 5.6.1. of 551 [I-D.ietf-ace-oauth-authz]. This parameter provides a signature 552 computed by the Client to prove the possession of its own private 553 key. 555 3.2. AS-to-C: Access Token 557 After having verified the POST request to the /token endpoint and 558 that the Client is authorized to obtain an Access Token corresponding 559 to its Access Token request, the AS MUST verify the signature in the 560 'client_cred_verify' parameter, by using the public key specified in 561 the 'req_cnf' parameter. If the verification fails, the AS considers 562 the Client request invalid. 564 If all verifications are successful, the AS responds as defined in 565 Section 5.6.2 of [I-D.ietf-ace-oauth-authz]. If the Client request 566 was invalid, or not authorized, the AS returns an error response as 567 described in Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. 569 The AS can signal that the use of Group OSCORE is REQUIRED for a 570 specific Access Token by including the 'profile' parameter with the 571 value "coap_group_oscore" in the Access Token response. The Client 572 MUST use Group OSCORE towards all the Resource Servers for which this 573 Access Token is valid. Usually, it is assumed that constrained 574 devices will be pre-configured with the necessary profile, so that 575 this kind of profile negotiation can be omitted. 577 The AS MUST include the following information as metadata of the 578 issued Access Token. This profile RECOMMENDS the use of CBOR web 579 tokens (CWT) as specified in [RFC8392]. The Access Token MUST be 580 encrypted, since it will be transferred from the Client to the RS 581 over an unprotected channel. 583 o The same parameter 'profile' included in the Token Response to the 584 Client. 586 o The salt input specified in the 'salt_input' parameter of the 587 Token Request. If the Access Token is a CWT, the content of the 588 'salt_input' parameter MUST be placed in the 'salt_input' claim of 589 the Access Token, defined in Section 3.2.1 of this specification. 591 o The Context Id input specified in the 'context_id' parameter of 592 the Token Request. If the Access Token is a CWT, the content of 593 the 'context_id' parameter MUST be placed in the 'contextId_input' 594 claim of the Access Token, defined in Section 3.2.2 of this 595 specification. 597 o The public key that the client uses in the OSCORE group and 598 specified in the 'req_cnf' parameter of the Token request. If the 599 Access Token is a CWT, the public key MUST be specified in the 600 'cnf' claim, which follows the syntax from Section 3.1 of 601 [I-D.ietf-ace-cwt-proof-of-possession] when including Value Type 602 "COSE_Key" (1) and specifying an asymmetric key. Alternative 603 Value Types defined in future specifications are fine to consider 604 if indicating a non-encrypted asymmetric key. 606 Figure 3 shows an example of such an AS response, with payload in 607 CBOR diagnostic notation without the tag and value abbreviations. 609 Header: Created (Code=2.01) 610 Content-Type: "application/ace+cbor" 611 Payload: 612 { 613 "access_token" : h'a5037674656d7053656e73 ...' 614 (remainder of CWT omitted for brevity), 615 "profile" : "coap_group_oscore", 616 "expires_in" : 3600, 617 } 619 Figure 3: Example AS-to-C Access Token response with the Group OSCORE 620 profile. 622 Figure 4 shows an example CWT, containing the client's public key in 623 the group (as pop-key) in the 'cnf' claim, in CBOR diagnostic 624 notation without tag and value abbreviations. 626 { 627 "aud" : "tempSensorInLivingRoom", 628 "iat" : "1360189224", 629 "exp" : "1360289224", 630 "scope" : "temperature_g firmware_p", 631 "cnf" : { 632 "COSE_Key" : { 633 "kty" : EC2, 634 "crv" : P-256, 635 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 636 27c9e354089bbe13', 637 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 638 731e79a3b4e47120' 639 }, 640 "salt_input" : h'00', 641 "contextId_input" : h'abcd0000' 642 } 644 Figure 4: Example CWT with OSCORE parameters (CBOR diagnostic 645 notation). 647 The same CWT as in Figure 4 and encoded in CBOR is shown in Figure 5, 648 using the value abbreviations defined in [I-D.ietf-ace-oauth-authz] 649 and [I-D.ietf-ace-cwt-proof-of-possession]. 651 NOTE: it should be checked (and in case fixed) that the values used 652 below (which are not yet registered) are the final values registered 653 in IANA. 655 A7 # map(7) 656 03 # unsigned(3) 657 76 # text(22) 658 74656D7053656E736F72496E4C6976696E67526F6F6D 659 06 # unsigned(6) 660 1A 5112D728 # unsigned(1360189224) 661 04 # unsigned(4) 662 1A 51145DC8 # unsigned(1360289224) 663 09 # unsigned(9) 664 78 18 # text(24) 665 74656D70657261747572655F67206669726D776172655F70 666 08 # unsigned(8) 667 A1 # map(1) 668 01 # unsigned(1) 669 A4 # map(4) 670 01 # unsigned(1) 671 02 # unsigned(2) 672 20 # negative(0) 673 01 # unsigned(1) 674 21 # negative(1) 675 58 20 # bytes(32) 676 D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9 677 E354089BBE13 678 22 # negative(2) 679 58 20 # bytes(32) 680 F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E515D020731E 681 79A3B4E47120 682 18 3C # unsigned(60) 683 41 # bytes(1) 684 00 685 18 3D # unsigned(61) 686 44 # bytes(4) 687 ABCD0000 689 Figure 5: Example CWT with OSCORE parameters. 691 3.2.1. Salt Input Claim 693 The 'salt_input' claim provides a value that the Client requesting 694 the Access Token wishes to use as a part of a salt with the RS, e.g. 695 for deriving cryptographic material. 697 This parameter specifies the value of the salt input, encoded as a 698 CBOR byte string. 700 3.2.2. Context ID Input Claim 702 The 'contextId_input' claim provides a value that the Client 703 requesting the Access Token wishes to use with the RS, as a hint for 704 a security context. 706 This parameter specifies the value of the context ID input, encoded 707 as a CBOR byte string. 709 4. Client-RS Communication 711 This section details the POST request and response to the /authz-info 712 endpoint between the Client and the RS. 714 The proof-of-possession required to bind the Access Token to the 715 Client is explicitly performed when the RS receives a message 716 protected with Group OSCORE from the Client. In particular, the RS 717 verifies the countersignature embedded in the message by using the 718 Client's public key bound to the Access Token, hence also 719 authenticating the Client. Similarly, when receiving a protected 720 response message from the RS, the Client verifies the 721 countersignature embedded in the message by using the RS's public 722 key, hence authenticating the RS. 724 Therefore, an attacker using a stolen Access Token cannot generate a 725 valid Group OSCORE message signed with the Client's private key, and 726 thus cannot prove possession of the pop-key bound to the Access 727 Token. Also, if a Client legitimately owns an Access Token but has 728 not joined the OSCORE group, it cannot generate a valid Group OSCORE 729 message, as it does not own the necessary key material shared among 730 the group members. 732 Furthermore, a Client C1 is supposed to obtain a valid Access Token 733 from the AS, as including the public key associated to its own 734 signing key used in the OSCORE group, together with its own Sender ID 735 in that OSCORE group (see Section 3.1). This makes it possible for 736 the RS receiving an Access Token to verify with the Group Manager of 737 that OSCORE group whether such a Client has indeed that Sender ID and 738 that public key in the OSCORE group. 740 As a consequence, a different Client C2, also member of the same 741 OSCORE group, is not able to impersonate C1, by: i) getting a valid 742 Access Token, specifying the Sender ID of C1 and a different (made- 743 up) public key; ii) successfully posting the Access Token to RS; and 744 then iii) attempting to communicate using Group OSCORE impersonating 745 C1, while blaming C1 for the consequences. 747 4.1. C-to-RS POST to authz-info Endpoint 749 The Client posts the Access Token to the /authz-info endpoint of the 750 RS, as defined in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 752 4.2. RS-to-C: 2.01 (Created) 754 The RS MUST verify the validity of the Access Token as defined in 755 Section 5.8.1 of [I-D.ietf-ace-oauth-authz], with the following 756 additions. 758 o The RS checks that the 'salt_input' claim is included in the 759 Access Token. 761 o The RS checks that the 'contextId_input' claim is included in the 762 Access Token. 764 o The RS checks that the 'cnf' claim is included in the Access 765 Token. 767 o The RS considers the content of the 'cnf' claim as the public key 768 associated to the signing private key of the Client in the OSCORE 769 group, whose GID is specified in the 'contextId_input' claim 770 above. If it does not already store that public key, the RS MUST 771 request it to the Group Manager of the OSCORE group as described 772 in [I-D.ietf-ace-key-groupcomm-oscore], specifying the Sender ID 773 of that Client in the OSCORE group, i.e. the value of the 774 'salt_input' claim above. The RS MUST check that the key 775 retrieved from the Group Manager matches the one retrieved from 776 the 'cnf' claim. When doing so, the 'kid' parameter of the 777 COSE_Key, if present, MUST NOT be considered for the comparison. 779 If any of the checks above fails, the RS MUST consider the Access 780 Token non valid, and MUST respond to the Client with an error 781 response code equivalent to the CoAP code 4.00 (Bad Request). 783 If the Access Token is valid and further checks on its content are 784 successful, the RS associates the authorization information from the 785 Access Token with the Group OSCORE Security Context. 787 In particular, the RS associates the authorization information from 788 the Access Token with the tuple (GID, SaltInput, PubKey), where GID 789 is the Group Identifier of the OSCORE Group, while SaltInput and 790 PubKey are the Sender ID and the public key that the Client uses in 791 that OSCORE group, respectively. These can be retrieved from the 792 'contextId_input', 'salt_input' and 'cnf' claims of the Access Token, 793 respectively. The RS MUST keep this association up-to-date over 794 time. 796 Finally, the RS MUST send a 2.01 (Created) response to the Client, as 797 defined in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 799 4.3. Client-RS Secure Communication 801 When previously joining the OSCORE group, both the Client and RS have 802 already established the related Group OSCORE Security Context to 803 communicate as group members. Therefore, they can simply start to 804 securely communicate using Group OSCORE, without deriving any 805 additional key material or security association. 807 4.3.1. Client Side 809 After having received the 2.01 (Created) response from the RS, 810 following the POST request to the authz-info endpoint, the Client can 811 start to communicate with the RS using Group OSCORE 812 [I-D.ietf-core-oscore-groupcomm]. 814 When communicating with the RS to access the resources as specified 815 by the authorization information, the Client MUST use the Group 816 OSCORE Security Context of the OSCORE group, whose GID was specified 817 in the 'context_id' parameter of the Token request. 819 4.3.2. Resource Server Side 821 After successful validation of the Access Token as defined in 822 Section 4.2 and after having sent the 2.01 (Created) response, the RS 823 can start to communicate with the Client using Group OSCORE 824 [I-D.ietf-core-oscore-groupcomm]. Additionally, for every incoming 825 request, if Group OSCORE verification succeeds, the verification of 826 access rights is performed as described in Section 4.4. 828 After the expiration of the Access Token related to a Group OSCORE 829 Security Context, if the Client uses the Group OSCORE Security 830 Context to send a request for any resource intended for OSCORE group 831 members and that requires an active Access Token, the RS MUST respond 832 with a 4.01 (Unauthorized) error message protected with the Group 833 OSCORE Security Context. 835 4.4. Access Rights Verification 837 The RS MUST follow the procedures defined in Section 5.8.2 of 838 [I-D.ietf-ace-oauth-authz]. If an RS receives a Group OSCORE- 839 protected request from a Client, the RS processes it according to 840 [I-D.ietf-core-oscore-groupcomm]. 842 If the Group OSCORE verification succeeds, and the target resource 843 requires authorization, the RS retrieves the authorization 844 information from the Access Token associated to the Group OSCORE 845 Security Context. Then, the RS MUST verify that the action requested 846 on the resource is authorized. 848 The response code MUST be 4.01 (Unauthorized) in case the Client has 849 not used the Group OSCORE Security Context associated with the Access 850 Token, or if the RS has no valid Access Token for the Client. If the 851 RS has an Access Token for the Client but no actions are authorized 852 on the target resource, the RS MUST reject the request with a 4.03 853 (Forbidden). If the RS has an Access Token for the Client but the 854 requested action is not authorized, the RS MUST reject the request 855 with a 4.05 (Method Not Allowed). 857 5. Secure Communication with the AS 859 As specified in the ACE framework (Section 5.7 of 860 [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or Client) 861 and the AS communicate via the /introspection or /token endpoint. 862 The use of CoAP and OSCORE for this communication is RECOMMENDED in 863 this profile. Other protocols (such as HTTP and DTLS or TLS) MAY be 864 used instead. 866 If OSCORE is used, the requesting entity and the AS are expected to 867 have pre-established security contexts in place. How these security 868 contexts are established is out of the scope of this profile. 869 Furthermore the requesting entity and the AS communicate using OSCORE 870 ([RFC8613]) through the /introspection endpoint as specified in 871 Section 5.7 of [I-D.ietf-ace-oauth-authz], and through the /token 872 endpoint as specified in Section 5.6 of [I-D.ietf-ace-oauth-authz]. 874 6. Discarding the Security Context 876 As members of an OSCORE Group, the Client and the RS may 877 independently leave the group or be forced to, e.g. if compromised or 878 suspected so. Upon leaving the OSCORE group, the Client or RS also 879 discards the Group OSCORE Security Context, which may anyway be 880 renewed by the Group Manager through a group rekeying process (see 881 Section 2.4 of [I-D.ietf-core-oscore-groupcomm]). 883 The Client or RS can acquire a new Group OSCORE Security Context, by 884 re-joining the OSCORE group, e.g. by using the approach defined in 885 [I-D.ietf-ace-key-groupcomm-oscore]. In such a case, the Client 886 SHOULD request a new Access Token and post it to the RS. 888 7. CBOR Mappings 890 The new parameters defined in this document MUST be mapped to CBOR 891 types as specified in Figure 6, using the given integer abbreviation 892 for the map key. 894 /--------------------+----------+------------\ 895 | Parameter name | CBOR Key | Value Type | 896 |--------------------+----------+------------| 897 | context_id | TBD1 | bstr | 898 | salt_input | TBD2 | bstr | 899 | client_cred_verify | TBD3 | bstr | 900 \--------------------+----------+------------/ 902 Figure 6: CBOR mappings for new parameters. 904 The new claims defined in this document MUST be mapped to CBOR types 905 as specified in Figure 7, using the given integer abbreviation for 906 the map key. 908 /-----------------+----------+------------\ 909 | Claim name | CBOR Key | Value Type | 910 |-----------------+----------+------------| 911 | salt_input | TBD4 | bstr | 912 | contextId_input | TBD5 | bstr | 913 \-----------------+----------+------------/ 915 Figure 7: CBOR mappings for new claims. 917 8. Security Considerations 919 This document specifies a profile for the Authentication and 920 Authorization for Constrained Environments (ACE) framework 921 [I-D.ietf-ace-oauth-authz]. Thus the general security considerations 922 from the ACE framework also apply to this profile. 924 This specification inherits the general security considerations about 925 Group OSCORE [I-D.ietf-core-oscore-groupcomm], as to the specific use 926 of Group OSCORE according to this profile. 928 Group OSCORE is designed to secure point-to-point as well as point- 929 to-multipoint communications, providing a secure binding between a 930 single request and multiple corresponding responses. In particular, 931 Group OSCORE fulfills the same security requirements of OSCORE, for 932 group requests and responses. To ensure source authentication of 933 messages, Group OSCORE uses digital countersignatures that group 934 members embed in their own transmitted messages. 936 9. Privacy Considerations 938 This document specifies a profile for the Authentication and 939 Authorization for Constrained Environments (ACE) framework 940 [I-D.ietf-ace-oauth-authz]. Thus the general privacy considerations 941 from the ACE framework also apply to this profile. 943 As this profile uses Group OSCORE, the privacy considerations from 944 [I-D.ietf-core-oscore-groupcomm] apply to this document as well. 946 An unprotected response to an unauthorized request may disclose 947 information about the RS and/or its existing relationship with the 948 Client. It is advisable to include as little information as possible 949 in an unencrypted response. However, since both the Client and the 950 RS share a Group OSCORE Security Context, unauthorized, yet protected 951 requests are followed by protected responses, which can thus include 952 more detailed information. 954 Although encrypted, the Access Token is sent in the clear to the 955 /authz-info endpoint at the RS. Thus, if the Client uses the same 956 single Access Token from multiple locations with multiple Resource 957 Servers, it can risk being tracked through the Access Token's value. 959 Note that, even though communications are protected with Group 960 OSCORE, some information might still leak, due to the observable 961 size, source address and destination address of exchanged messages. 963 10. IANA Considerations 965 This document has the following actions for IANA. 967 10.1. ACE Profile Registry 969 IANA is asked to enter the following value into the "ACE Profile" 970 Registry defined in Section 8.7 of [I-D.ietf-ace-oauth-authz]. 972 o Profile name: coap_group_oscore 974 o Profile Description: Profile to secure communications between 975 constrained nodes using the Authentication and Authorization for 976 Constrained Environments framework, by enabling authentication and 977 fine-grained authorization of members of an OSCORE group, that use 978 a pre-established Group OSCORE Security Context to communicate 979 with Group OSCORE. Optionally, the dual mode defined in 980 Appendix A additionally establishes a Pairwise OSCORE Security 981 Context, and thus also enables OSCORE communication between two 982 members of the OSCORE group. 984 o Profile ID: TBD (value between 1 and 255) 986 o Change Controller: IESG 988 o Specification Document(s): [[this document]] 990 10.2. OAuth Parameters Registry 992 IANA is asked to enter the following values into the "OAuth 993 Parameters" Registry defined in Section 11.2 of [RFC6749]. 995 o Name: "context_id" 997 o Parameter Usage Location: token request 999 o Change Controller: IESG 1001 o Reference: Section 3.1.1 of [[this document]] 1003 o Name: "salt_input" 1005 o Parameter Usage Location: token request 1007 o Change Controller: IESG 1009 o Reference: Section 3.1.2 of [[this document]] 1011 o Name: "client_cred_verify" 1013 o Parameter Usage Location: token request 1015 o Change Controller: IESG 1017 o Reference: Section 3.1.3 of [[this document]] 1019 o Name: "client_cred" 1021 o Parameter Usage Location: token request 1023 o Change Controller: IESG 1024 o Reference: Appendix A.2.1.1 of [[this document]] 1026 10.3. OAuth Parameters CBOR Mappings Registry 1028 IANA is asked to enter the following values into the "OAuth 1029 Parameters CBOR Mappings" Registry defined in Section 8.9 of 1030 [I-D.ietf-ace-oauth-authz]. 1032 o Name: "context_id" 1034 o CBOR Key: TBD1 1036 o Change Controller: IESG 1038 o Reference: Section 3.1.1 of [[this document]] 1040 o Name: "salt_input" 1042 o CBOR Key: TBD2 1044 o Change Controller: IESG 1046 o Reference: Section 3.1.2 of [[this document]] 1048 o Name: "client_cred_verify" 1050 o CBOR Key: TBD3 1052 o Change Controller: IESG 1054 o Reference: Section 3.1.3 of [[this document]] 1056 o Name: "client_cred" 1058 o CBOR Key: TBD6 1060 o Change Controller: IESG 1062 o Reference: Appendix A.2.1.1 of [[this document]] 1064 10.4. CBOR Web Token Claims Registry 1066 IANA is asked to enter the following values into the "CBOR Web Token 1067 Claims" Registry defined in Section 9.1 of [RFC8392]. 1069 o Claim Name: "salt_input" 1071 o Claim Description: Client provided salt input 1073 o JWT Claim Name: "N/A" 1075 o Claim Key: TBD4 1077 o Claim Value Type(s): bstr 1079 o Change Controller: IESG 1081 o Specification Document(s): Section 3.2.1 of [[this document]] 1083 o Claim Name: "contextId_input" 1085 o Claim Description: Client context id input 1087 o JWT Claim Name: "N/A" 1089 o Claim Key: TBD5 1091 o Claim Value Type(s): bstr 1093 o Change Controller: IESG 1095 o Specification Document(s): Section 3.2.2 of [[this document]] 1097 o Claim Name: "client_cred" 1099 o Claim Description: Client Credential 1101 o JWT Claim Name: "N/A" 1103 o Claim Key: TBD7 1105 o Claim Value Type(s): map 1107 o Change Controller: IESG 1109 o Specification Document(s): Appendix A.2.2.2 of [[this document]] 1111 10.5. TLS Exporter Label Registry 1113 IANA is asked to register the following entry in the "TLS Exporter 1114 Label" Registry defined in Section 6 of [RFC5705] and updated in 1115 Section 12 of [RFC8447]. 1117 o Value: EXPORTER-ACE-Sign-Challenge-Client-AS 1119 o DTLS-OK: Y 1121 o Recommended: N 1123 o Reference: [[this document]] (Section 3.1) 1125 11. References 1127 11.1. Normative References 1129 [I-D.dijk-core-groupcomm-bis] 1130 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1131 for the Constrained Application Protocol (CoAP)", draft- 1132 dijk-core-groupcomm-bis-03 (work in progress), March 1133 2020. 1135 [I-D.ietf-ace-cwt-proof-of-possession] 1136 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1137 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1138 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 1139 possession-11 (work in progress), October 2019. 1141 [I-D.ietf-ace-key-groupcomm-oscore] 1142 Tiloca, M., Park, J., and F. Palombini, "Key Management 1143 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1144 oscore-05 (work in progress), March 2020. 1146 [I-D.ietf-ace-oauth-authz] 1147 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1148 H. Tschofenig, "Authentication and Authorization for 1149 Constrained Environments (ACE) using the OAuth 2.0 1150 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 1151 (work in progress), February 2020. 1153 [I-D.ietf-ace-oauth-params] 1154 Seitz, L., "Additional OAuth Parameters for Authorization 1155 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 1156 params-12 (work in progress), February 2020. 1158 [I-D.ietf-ace-oscore-profile] 1159 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1160 "OSCORE profile of the Authentication and Authorization 1161 for Constrained Environments Framework", draft-ietf-ace- 1162 oscore-profile-10 (work in progress), March 2020. 1164 [I-D.ietf-core-oscore-groupcomm] 1165 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1166 "Group OSCORE - Secure Group Communication for CoAP", 1167 draft-ietf-core-oscore-groupcomm-07 (work in progress), 1168 March 2020. 1170 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1171 Requirement Levels", BCP 14, RFC 2119, 1172 DOI 10.17487/RFC2119, March 1997, 1173 . 1175 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1176 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1177 March 2010, . 1179 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1180 Key Derivation Function (HKDF)", RFC 5869, 1181 DOI 10.17487/RFC5869, May 2010, 1182 . 1184 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1185 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1186 . 1188 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1189 Keranen, A., and P. Hallam-Baker, "Naming Things with 1190 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1191 . 1193 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1194 Application Protocol (CoAP)", RFC 7252, 1195 DOI 10.17487/RFC7252, June 2014, 1196 . 1198 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1199 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1200 . 1202 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1203 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1204 May 2017, . 1206 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1207 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1208 May 2018, . 1210 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1211 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1212 . 1214 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1215 Definition Language (CDDL): A Notational Convention to 1216 Express Concise Binary Object Representation (CBOR) and 1217 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1218 June 2019, . 1220 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1221 "Object Security for Constrained RESTful Environments 1222 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1223 . 1225 11.2. Informative References 1227 [I-D.ietf-ace-dtls-authorize] 1228 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1229 L. Seitz, "Datagram Transport Layer Security (DTLS) 1230 Profile for Authentication and Authorization for 1231 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1232 authorize-09 (work in progress), December 2019. 1234 [I-D.ietf-ace-mqtt-tls-profile] 1235 Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile 1236 of ACE", draft-ietf-ace-mqtt-tls-profile-04 (work in 1237 progress), March 2020. 1239 [I-D.ietf-tls-dtls13] 1240 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1241 Datagram Transport Layer Security (DTLS) Protocol Version 1242 1.3", draft-ietf-tls-dtls13-37 (work in progress), 1243 March 2020. 1245 [I-D.tiloca-core-oscore-discovery] 1246 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1247 Groups with the CoRE Resource Directory", draft-tiloca- 1248 core-oscore-discovery-05 (work in progress), March 1249 2020. 1251 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1252 (TLS) Protocol Version 1.2", RFC 5246, 1253 DOI 10.17487/RFC5246, August 2008, 1254 . 1256 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1257 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1258 January 2012, . 1260 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1261 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1262 . 1264 Appendix A. Dual Mode (Group OSCORE & OSCORE) 1266 This appendix defines the dual mode of this profile, which allows 1267 using both OSCORE [RFC8613] and Group OSCORE 1268 [I-D.ietf-core-oscore-groupcomm] as security protocols, by still 1269 relying on a single Access Token. 1271 That is, the dual mode of this profile specifies how a Client uses 1272 CoAP [RFC7252] to communicate to a single Resource Server, or CoAP 1273 over IP multicast [I-D.dijk-core-groupcomm-bis] to communicate to 1274 multiple Resource Servers that are members of a group and share a 1275 common set of resources. 1277 In particular, the dual mode of this profile uses two complementary 1278 security protocols to provide secure communication between the Client 1279 and the Resource Server(s). That is, it defines the use of either 1280 OSCORE or Group OSCORE to protect unicast requests addressed to a 1281 single Resource Server, as well as possible responses. Additionally, 1282 it defines the use of Group OSCORE to protect multicast requests sent 1283 to a group of Resource Servers, as well as possible individual 1284 responses. As for the main mode of this profile, the Client and the 1285 Resource Servers need to have already joined an OSCORE group, for 1286 instance by using the approach defined in 1287 [I-D.ietf-ace-key-groupcomm-oscore], which is also based on ACE. 1289 The Client authorizes its access to the Resource Server by using an 1290 Access Token, which is bound to a key (the proof-of-possession key). 1291 This profile mode uses OSCORE to achieve proof of possession, and 1292 OSCORE or Group OSCORE to achieve server authentication. 1294 Unlike in the main mode of this profile, where a public key is used 1295 as pop-key, this dual mode uses OSCORE-related, symmetric key 1296 material as pop-key instead. Furthermore, this dual mode provides 1297 proof of Client's membership to the correct OSCORE group, by securely 1298 binding the pre-established Group OSCORE Security Context to the 1299 pairwise OSCORE Security Context newly established between the Client 1300 and the Resource Server. 1302 In addition to the terminology used for the main mode of this 1303 profile, the rest of this appendix refers also to "pairwise OSCORE 1304 Security Context" as to an OSCORE Security Context established 1305 between only one Client and one Resource Server, and used to 1306 communicate with OSCORE [RFC8613]. 1308 A.1. Protocol Overview 1310 This section provides an overview on how to use the ACE framework for 1311 authentication and authorization [I-D.ietf-ace-oauth-authz] to secure 1312 communications between a Client and a (set of) Resource Server(s) 1313 using OSCORE [RFC8613] and/or Group OSCORE 1314 [I-D.ietf-core-oscore-groupcomm]. 1316 Just as for main mode of this profile overviewed in Section 2, the 1317 process for joining the OSCORE group through the respective Group 1318 Manager as defined in [I-D.ietf-ace-key-groupcomm-oscore] must take 1319 place before the process described in the rest of this section, and 1320 is out of the scope of this profile. 1322 An overview of the protocol flow for the dual mode of this profile is 1323 shown in Figure 8. In the figure, it is assumed that both RS1 and 1324 RS2 are associated with the same AS. It is also assumed that C, RS1 1325 and RS2 have previously joined an OSCORE group with Group Identifier 1326 (gid) "abcd0000", and got assigned Sender ID (sid) "0", "1" and "2" 1327 in the group, respectively. 1329 C RS1 RS2 AS 1330 | [--- Resource Request --->] | | | 1331 | | | | 1332 | [<--- AS Information -----] | | | 1333 | | | | 1334 |-------- POST /token -------------------------------------------------->| 1335 | (aud: RS1, sid: 0, gid: abcd0000, ... ) | | 1336 | | | | 1337 |<---------------------------------- Access Token + RS Information ------| 1338 | | (aud: RS1, sid: 0, gid: abcd0000, ... ) | 1339 |---- POST /authz-info ------>| | | 1340 | (access_token, N1) | | | 1341 | | | | 1342 |<--- 2.01 Created (N2) ------| | | 1343 | | | | 1344 /Pairwise OSCORE Sec /Pairwise OSCORE Sec | | 1345 Context Derivation/ Context Derivation/ | | 1346 | | | | 1347 |-------- POST /token -------------------------------------------------->| 1348 | (aud: RS2, sid: 0, gid: abcd0000, ... ) | | 1349 | | | | 1350 |<---------------------------------- Access Token + RS Information ------| 1351 | | (aud: RS2, sid: 0, gid: abcd0000, ... ) | 1352 | | | | 1353 |----- POST /authz-info ------------------->| | 1354 | (access_token, N1') | | | 1355 | | | | 1356 |<--- 2.01 Created (N2') -------------------| | 1357 | | | | 1358 /Pairwise OSCORE Sec | /Pairwise OSCORE Sec | 1359 Context Derivation/ | Context Derivation/ | 1360 | | | | 1361 |------ OSCORE Request ------->| | | 1362 | ?(abcd0000, N1, N2) | | | 1363 | | | | 1364 |<----- OSCORE Response -------| | | 1365 | | | | 1366 |-- Group OSCORE Request --+-->| | | 1367 | (kid: 0, gid: abcd0000) \--------------->| | 1368 | | | | 1369 |<--- Group OSCORE Response ---| | | 1370 | (kid: 1) | | | 1371 | | | | 1372 |<--- Group OSCORE Response ----------------| | 1373 | (kid: 2) | | | 1374 | ... | | | 1376 Figure 8: Protocol Overview. 1378 A.1.1. Pre-Conditions 1380 The same pre-conditions for the main mode of this profile (see 1381 Section 2.1) hold for the dual mode described in this appendix. 1383 A.1.2. Access Token Posting 1385 After having retrieved the Access Token from the AS, the Client 1386 generates a nonce N1 and posts both the Access Token and N1 to the 1387 RS, using the /authz-info endpoint and mechanisms specified in 1388 Section 5.8 of [I-D.ietf-ace-oauth-authz] and Content-Format = 1389 application/ace+cbor. 1391 If the Access Token is valid, the RS replies to this POST request 1392 with a 2.01 (Created) response with Content-Format = application/ 1393 ace+cbor, which contains a nonce N2 in a CBOR map. 1395 A.1.3. Setup of the Pairwise OSCORE Security Context 1397 After sending the 2.01 (Created) response, the RS sets the ID Context 1398 of the pairwise OSCORE Security Context (see Section 3 of [RFC8613]) 1399 to the Group Identifier of the OSCORE group specified in the Access 1400 Token, concatenated with N1, concatenated with N2, concatenated with 1401 the value in the contextId parameter of the OSCORE_Security_Context 1402 object provided in the 'cnf' claim of the Access Token. 1404 Then, the RS derives the complete pairwise OSCORE Security Context 1405 associated with the received Access Token, following Section 3.2 of 1406 [RFC8613]. In practice, the RS maintains a collection of Security 1407 Contexts with associated authorization information, for all the 1408 clients that it is currently communicating with, and the 1409 authorization information is a policy used as input when processing 1410 requests from those clients. 1412 During the derivation process, the RS uses the ID Context above, the 1413 nonces N1 and N2, and the parameters in the Access Token. The 1414 derivation process uses also the Master Secret of the OSCORE group, 1415 that the RS knows as a group member, as well as the Sender ID of the 1416 Client in the OSCORE group, which is specified in the Access Token. 1417 This ensures that the pairwise OSCORE Security Context is securely 1418 bound to the Group OSCORE Security Context of the OSCORE group. 1420 Finally, the RS stores the association between i) the authorization 1421 information from the Access Token; and ii) the Group Identifier of 1422 the OSCORE group together with the Sender ID and the public key of 1423 the Client in that group. 1425 After having received the nonce N2, the Client sets the ID Context in 1426 its pairwise OSCORE Security Context (see Section 3 of [RFC8613]) to 1427 the Group Identifier of the OSCORE group concatenated with N1 1428 concatenated with N2, concatenated with the value in the contextId 1429 parameter of the OSCORE_Security_Context object provided in the 'cnf' 1430 parameter of the Access Token response from the AS. Then, the Client 1431 derives the complete pairwise OSCORE Security Context, following 1432 Section 3.2 of [RFC8613]. During the derivation process, the Client 1433 uses the ID Context above, the nonces N1 and N2, plus the parameters 1434 received from the AS. The derivation process uses also the Master 1435 Secret of the OSCORE group, that the Client knows as a group member, 1436 as well as its own Sender ID in the OSCORE group. 1438 When the Client communicates with the RS using the pairwise OSCORE 1439 Security Context, the RS achieves proof-of-possession of the 1440 credentials bound to the Access Token. Also, the RS verifies that 1441 the Client is a legitimate member of the OSCORE group. 1443 A.1.4. Secure Communication 1445 The Client can send a request protected with OSCORE to the RS. This 1446 message may contain the ID Context value of the pairwise OSCORE 1447 Context, whose generation is described in Appendix A.1.3. 1449 If the request is correctly verified, then the RS stores the pairwise 1450 OSCORE Security Context, and uses it to protect the possible 1451 response, as well as further communications with the Client, until 1452 the Access Token expires. This pairwise OSCORE Security Context is 1453 discarded if the same Access Token is re-used to successfully derive 1454 a new pairwise OSCORE Security Context. Once the Client has received 1455 a valid secure response, it does not continue to include the ID 1456 Context value in following requests. 1458 As discussed in Section 2 of [I-D.ietf-ace-oscore-profile], the use 1459 of random nonces N1 and N2 during the exchange between the Client and 1460 the RS prevents the reuse of AEAD nonces and keys with different 1461 messages, in case of re-derivation of the pairwise OSCORE Security 1462 Context both for Clients and Resource Servers from an old non-expired 1463 Access Token, e.g. in case of reboot of either the Client or the RS. 1465 Additionally, just as per the main mode of this profile (see 1466 Section 4.3), the Client and RS can also securely communicate by 1467 protecting messages with Group OSCORE, using the Group OSCORE 1468 Security Context already established upon joining the OSCORE group. 1470 A.2. Client-AS Communication 1472 This section details the Access Token POST Request that the Client 1473 sends to the /token endpoint of the AS, as well as the related Access 1474 Token response. 1476 Section 3.2 of [RFC8613] defines how to derive a pairwise OSCORE 1477 Security Context based on a shared Master Secret and a set of other 1478 parameters, established between the OSCORE client and server. 1480 The Client receives these pieces of information from the AS during 1481 the exchange described in this section. In particular, the proof-of- 1482 possession key (pop-key) provisioned by the AS MUST be used to build 1483 the Master Secret in OSCORE (see Appendix A.3.3 and Appendix A.3.4). 1485 A.2.1. C-to-AS: POST to Token Endpoint 1487 The Client-to-AS request is specified in Section 5.6.1 of 1488 [I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request 1489 to the /token endpoint over a secure channel that guarantees 1490 authentication, message integrity and confidentiality. 1492 The POST request is formatted as the analogous Client-to-AS request 1493 in the main mode of this profile (see Section 3.1), with the 1494 following modifications. 1496 o The parameter 'req_cnf' MUST NOT be included in the payload. 1498 o The parameter 'client_cred', defined in Appendix A.2.1.1 of this 1499 specification, MUST be included in the payload. This parameter 1500 includes the public key associated to the signing private key that 1501 the Client uses in the OSCORE group, whose identifier is indicated 1502 in the 'context_id' parameter. 1504 o The signature included in the parameter 'client_cred_verify' is 1505 computed by using the private key associated to the public key in 1506 the 'client_cred' parameter above. 1508 An example of such a request, with payload in CBOR diagnostic 1509 notation without the tag and value abbreviations is reported in 1510 Figure 9. 1512 Header: POST (Code=0.02) 1513 Uri-Host: "as.example.com" 1514 Uri-Path: "token" 1515 Content-Format: "application/ace+cbor" 1516 Payload: 1517 { 1518 "audience" : "tempSensor4711", 1519 "scope" : "read", 1520 "context_id" : h'abcd0000', 1521 "salt_input" : h'00', 1522 "client_cred" : { 1523 "COSE_Key" : { 1524 "kty" : EC2, 1525 "crv" : P-256, 1526 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 1527 27c9e354089bbe13', 1528 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 1529 731e79a3b4e47120' 1530 } 1531 }, 1532 "client_cred_verify" : h'...' 1533 (signature content omitted for brevity), 1534 } 1536 Figure 9: Example C-to-AS POST /token request for an Access Token 1537 bound to a symmetric key. 1539 Later on, the Client may want to update its current access rights, 1540 without changing the existing pairwise OSCORE Security Context with 1541 the RS. In this case, the Client MUST include in its POST request to 1542 the /token endpoint a 'req_cnf' parameter, defined in Section 3.1 of 1543 [I-D.ietf-ace-oauth-params], which MUST include a 'kid' field, as 1544 defined in Section 3.1 of [I-D.ietf-ace-cwt-proof-of-possession]. 1545 The 'kid' field has as value a CBOR byte string encoding a CBOR 1546 array, which includes: 1548 o As first element, the value of the 'clientId' parameter in the 1549 OSCORE_Security_Context object specified in the 'cnf' parameter, 1550 in the original AS-to-C Access Token response (see 1551 Appendix A.2.2). 1553 o Optionally, as second element, the value of the 'contextId' 1554 parameter in the OSCORE_Security_Context object specified in the 1555 'cnf' parameter, in the original AS-to-C Access Token response 1556 (see Appendix A.2.2). 1558 The CBOR array is defined in Figure 10, and follows the notation of 1559 [RFC8610]. 1561 These identifiers, together with other information such as audience, 1562 can be used by the AS to determine the shared secret bound to the 1563 proof-of-possession Access Token, and therefore MUST identify a 1564 symmetric key that was previously generated by the AS as a shared 1565 secret for the communication between the Client and the RS. The AS 1566 MUST verify that the received value identifies a proof-of-possession 1567 key that has previously been issued to the requesting client. If 1568 that is not the case, the Client-to-AS request MUST be declined with 1569 the error code 'invalid_request' as defined in Section 5.6.3 of 1570 [I-D.ietf-ace-oauth-authz]. 1572 This POST request for updating the rights of an Access Token MUST NOT 1573 include the parameters 'salt_input', 'context_id', 'client_cred' and 1574 'client_cred_verify'. 1576 kid_arr = [ 1577 clientId, 1578 ?IdContext 1579 ] 1581 kid = bstr .cbor kid_arr 1583 Figure 10: CDDL Notation of kid for Update of Access Rights 1585 An example of such a request, with payload in CBOR diagnostic 1586 notation without the tag and value abbreviations is reported in 1587 Figure 11. In particular: '<< X >>' denotes a CBOR byte string with 1588 string value X; "myclient" stands for the value of the 'clientId' 1589 parameter mentioned above; and "contextid" stands for the value of 1590 the 'contextId' parameter mentioned above. 1592 Header: POST (Code=0.02) 1593 Uri-Host: "as.example.com" 1594 Uri-Path: "token" 1595 Content-Format: "application/ace+cbor" 1596 Payload: 1597 { 1598 "audience" : "tempSensor4711", 1599 "scope" : "read", 1600 "req_cnf" : { 1601 "kid" : << ["myclient","contextid"] >> 1602 } 1603 } 1605 Figure 11: Example C-to-AS POST /token request for updating rights to 1606 an Access Token bound to a symmetric key. 1608 A.2.1.1. 'client_cred' Parameter 1610 The 'client_cred' parameter is an OPTIONAL parameter of the Access 1611 Token request message defined in Section 5.6.1. of 1612 [I-D.ietf-ace-oauth-authz]. This parameter provides an asymmetric 1613 key that the Client wishes to use as its own public key, but which is 1614 not used as proof-of-possession key. 1616 This parameter follows the syntax of the 'cnf' claim from Section 3.1 1617 of [I-D.ietf-ace-cwt-proof-of-possession] when including Value Type 1618 "COSE_Key" (1) and specifying an asymmetric key. Alternative Value 1619 Types defined in future specifications are fine to consider if 1620 indicating a non-encrypted asymmetric key. 1622 A.2.2. AS-to-C: Access Token 1624 After having verified the POST request to the /token endpoint and 1625 that the Client is authorized to obtain an Access Token corresponding 1626 to its Access Token request, the AS MUST verify the signature in the 1627 'client_cred_verify' parameter, by using the public key specified in 1628 the 'client_cred' parameter. If the verification fails, the AS 1629 considers the Client request invalid. The AS does not perform this 1630 operation when asked to update a previously released Access Token. 1632 If all verifications are successful, the AS responds as defined in 1633 Section 5.6.2 of [I-D.ietf-ace-oauth-authz]. If the Client request 1634 was invalid, or not authorized, the AS returns an error response as 1635 described in Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. 1637 The AS can signal that the use of OSCORE and Group OSCORE is REQUIRED 1638 for a specific Access Token by including the 'profile' parameter with 1639 the value "coap_group_oscore" in the Access Token response. This 1640 means that the Client MUST use OSCORE and/or Group OSCORE towards all 1641 the Resource Servers for which this Access Token is valid. 1643 In particular, the Client MUST follow Appendix A.3.3 to derive the 1644 pairwise OSCORE Security Context to use for communications with the 1645 RS. Instead, the Client has already established the related Group 1646 OSCORE Security Context to communicate with members of the OSCORE 1647 group, upon previously joining that group. 1649 Usually, it is assumed that constrained devices will be pre- 1650 configured with the necessary profile, so that this kind of profile 1651 negotiation can be omitted. 1653 In contrast with the main mode of this profile, the Access Token 1654 response to the Client is analogous to the one in the OSCORE profile 1655 of ACE, as described in Section 3.2 of [I-D.ietf-ace-oscore-profile]. 1657 In particular, the AS provides an OSCORE_Security_Context object, 1658 which is defined in Section 3.2.1 of [I-D.ietf-ace-oscore-profile] 1659 and included in the 'cnf' parameter (see Section 3.2 of 1660 [I-D.ietf-ace-oauth-params]) of the Access Token response. 1662 In the issued Access Token, the AS MUST include as metadata the same 1663 information as defined in the main mode of this profile (see 1664 Section 3.2) with the following modifications. 1666 o The public key that the client uses in the OSCORE group and 1667 specified in the 'client_cred' parameter of the Token request (see 1668 Appendix A.2.1) MUST also be included in the Access Token. If the 1669 Access Token is a CWT, the AS MUST include it in the 'client_cred' 1670 claim of the Access Token, defined in Appendix A.2.2.2 of this 1671 specification. 1673 o The OSCORE_Security_Context object specified in the 'cnf' 1674 parameter of the Access Token response MUST also be included in 1675 the Access Token. If the Access Token is a CWT, the same 1676 OSCORE_Security_Context object included in the 'cnf' parameter of 1677 the Access Token response MUST be included in the 'osc' field (see 1678 Section 9.3 of [I-D.ietf-ace-oscore-profile]) of the 'cnf' claim 1679 of the Access Token. 1681 Figure 12 shows an example of such an AS response, with payload in 1682 CBOR diagnostic notation without the tag and value abbreviations. 1684 Header: Created (Code=2.01) 1685 Content-Type: "application/ace+cbor" 1686 Payload: 1687 { 1688 "access_token" : h'a5037674656d7053656e73 ...' 1689 (remainder of CWT omitted for brevity), 1690 "profile" : "coap_group_oscore", 1691 "expires_in" : 3600, 1692 "cnf" : { 1693 "osc" : { 1694 "alg" : "AES-CCM-16-64-128", 1695 "clientId" : h'a8', 1696 "serverId" : h'42', 1697 "ms" : h'f9af838368e353e78888e1426bd94e6f', 1698 "salt" : h'1122', 1699 "contextId" : h'99' 1700 } 1701 } 1702 } 1704 Figure 12: Example AS-to-C Access Token response with the Group 1705 OSCORE profile. 1707 Figure 13 shows an example CWT, containing the necessary OSCORE 1708 parameters in the 'cnf' claim, in CBOR diagnostic notation without 1709 tag and value abbreviations. 1711 { 1712 "aud" : "tempSensorInLivingRoom", 1713 "iat" : "1360189224", 1714 "exp" : "1360289224", 1715 "scope" : "temperature_g firmware_p", 1716 "cnf" : { 1717 "osc" : { 1718 "alg" : "AES-CCM-16-64-128", 1719 "clientId" : h'00', 1720 "serverId" : h'01', 1721 "ms" : h'f9af838368e353e78888e1426bd94e6f', 1722 "salt" : h'1122', 1723 "contextId" : h'99' 1724 }, 1725 "salt_input" : h'00', 1726 "contextId_input" : h'abcd0000', 1727 "client_cred" : { 1728 "COSE_Key" : { 1729 "kty" : EC2, 1730 "crv" : P-256, 1731 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 1732 27c9e354089bbe13', 1733 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 1734 731e79a3b4e47120' 1735 } 1736 } 1737 } 1739 Figure 13: Example CWT with OSCORE parameters (CBOR diagnostic 1740 notation). 1742 The same CWT as in Figure 13 and encoded in CBOR is shown in 1743 Figure 14, using the value abbreviations defined in 1744 [I-D.ietf-ace-oauth-authz] and 1745 [I-D.ietf-ace-cwt-proof-of-possession], and with 12 as value 1746 abbreviation for the 'client_cred' claim. 1748 NOTE: it should be checked (and in case fixed) that the values used 1749 below (which are not yet registered) are the final values registered 1750 in IANA. 1752 A8 # map(8) 1753 03 # unsigned(3) 1754 76 # text(22) 1755 74656D7053656E736F72496E4C6976696E67526F6F6D 1756 06 # unsigned(6) 1757 1A 5112D728 # unsigned(1360189224) 1758 04 # unsigned(4) 1759 1A 51145DC8 # unsigned(1360289224) 1760 09 # unsigned(9) 1761 78 18 # text(24) 1762 74656D70657261747572655F67206669726D776172655F70 1763 08 # unsigned(8) 1764 A1 # map(1) 1765 04 # unsigned(4) 1766 A6 # map(6) 1767 05 # unsigned(5) 1768 0A # unsigned(10) 1769 02 # unsigned(2) 1770 41 # bytes(1) 1771 00 1772 03 # unsigned(3) 1773 41 # bytes(1) 1774 01 1775 01 # unsigned(1) 1776 50 # bytes(16) 1777 F9AF838368E353E78888E1426BD94E6F 1778 06 # unsigned(6) 1779 42 # bytes(2) 1780 1122 1781 07 # unsigned(7) 1782 41 # bytes(1) 1783 99 1784 18 3C # unsigned(60) 1785 41 # bytes(1) 1786 00 1787 18 3D # unsigned(61) 1788 44 # bytes(4) 1789 ABCD0000 1790 18 3E # unsigned(62) 1791 A1 # map(1) 1792 01 # unsigned(1) 1793 A4 # map(4) 1794 01 # unsigned(1) 1795 02 # unsigned(2) 1796 20 # negative(0) 1797 01 # unsigned(1) 1798 21 # negative(1) 1799 58 20 # bytes(32) 1800 D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9 1801 E354089BBE13 1802 22 # negative(2) 1803 58 20 # bytes(32) 1804 F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E515D020731E 1805 79A3B4E47120 1807 Figure 14: Example CWT with OSCORE parameters. 1809 If the client has requested an update to its access rights using the 1810 same pairwise OSCORE Security Context, which is valid and authorized, 1811 the AS MUST omit the 'cnf' parameter in the response to the client. 1813 Instead, the updated Access Token conveyed in the AS-to-C response 1814 MUST include a 'cnf' claim specifying a 'kid' field, as defined in 1815 Section 3.1 of [I-D.ietf-ace-cwt-proof-of-possession]. The 'kid' 1816 field has as value a CBOR byte string, with value the same value of 1817 the 'req_cnf' parameter from the C-to-AS request for updating rights 1818 to the Access Token (see Figure 11). This information, i.e. the 1819 value of the 'clientId' and 'contextId' parameters in Figure 11, 1820 needs to be included in the Access Token, in order for the RS to 1821 identify the previously generated pairwise OSCORE Security Context. 1823 Figure 15 shows an example of such an AS response, with payload in 1824 CBOR diagnostic notation without the tag and value abbreviations. 1825 The access token has been truncated for readability. 1827 Header: Created (Code=2.01) 1828 Content-Type: "application/ace+cbor" 1829 Payload: 1830 { 1831 "access_token" : h'a5037674656d7053656e73 ...' 1832 (remainder of CWT omitted for brevity), 1833 "profile" : "coap_group_oscore", 1834 "expires_in" : 3600 1835 } 1837 Figure 15: Example AS-to-C Access Token response with the Group 1838 OSCORE profile, for update of access rights. 1840 Figure 16 shows an example CWT, containing the necessary OSCORE 1841 parameters in the 'cnf' claim for update of access rights, in CBOR 1842 diagnostic notation without tag and value abbreviations. 1844 { 1845 "aud" : "tempSensorInLivingRoom", 1846 "iat" : "1360189224", 1847 "exp" : "1360289224", 1848 "scope" : "temperature_h", 1849 "cnf" : { 1850 "kid" : h'458241004199' 1851 } 1852 } 1854 Figure 16: Example CWT with OSCORE parameters for update of access 1855 rights. 1857 A.2.2.1. Public Key Hash as Client Credential 1859 As a possible optimization to limit the size of the Access Token, the 1860 AS may specify as value of the 'client_cred' claim simply the hash of 1861 the Client's public key. The specifically used hash-function MUST be 1862 collision-resistant on byte-strings, and MUST be selected from the 1863 "Named Information Hash Algorithm" Registry defined in Section 9.4 of 1864 [RFC6920]. 1866 In particular, the AS provides the Client with an Access Token as 1867 defined in Appendix A.2.2, with the following differences. 1869 The AS prepares INPUT_HASH as follows, with | denoting byte string 1870 concatenation. 1872 o If the public key has COSE Key Type OKP, INPUT_HASH = i, where 'i' 1873 is the x-parameter of the COSE_Key specified in the 'client_cred' 1874 parameter of the Token request. 1876 o If the public key has COSE Key Type EC2, INPUT_HASH = (i_1 | i_2), 1877 where 'i_1' and 'i_2' are the x-parameter and y-parameter of the 1878 COSE_Key specified in the 'client_cred' parameter of the Token 1879 request, respectively. 1881 o If the public key has COSE Key Type RSA, INPUT_HASH = (i_1 | i_2), 1882 where 'i_1' and 'i_2' are the n-parameter and e-parameter of the 1883 COSE_Key specified in the 'client_cred' parameter of the Token 1884 request. 1886 Then, the AS hashes INPUT_HASH according to the procedure described 1887 in [RFC6920], with the output OUTPUT_HASH in binary format, as 1888 described in Section 6 of [RFC6920]. 1890 Finally, the AS includes a single entry within the 'client_cred' 1891 claim of the Access Token. This entry has label "kid" (3) defined in 1892 Section 3.1 of [I-D.ietf-ace-cwt-proof-of-possession], and has 1893 OUTPUT_HASH as value, encoded as CBOR byte string. 1895 Upon receiving the Access Token, the RS processes it according to 1896 Appendix A.3.2, with the following differences. 1898 The RS considers the content of the 'client_cred' claim as the hash 1899 of the public key associated to the signing private key that the 1900 Client uses in the OSCORE group, which is identified by the 1901 'context_id' parameter. 1903 The RS MAY additionally request the Group Manager of the OSCORE group 1904 for the public key of that Client, as described in 1905 [I-D.ietf-ace-key-groupcomm-oscore], specifying as Sender ID of that 1906 Client in the OSCORE group the value of the 'salt_input' claim 1907 included in the Access Token. 1909 In such a case, the RS MUST check that the hash of the key retrieved 1910 from the Group Manager matches the hash retrieved from the 1911 'client_cred' claim of the Access Token. The RS MUST calculate the 1912 hash using the same method as the AS, described above, and using the 1913 same hash function. The hash function used can be determined from 1914 the information conveyed in the 'client_cred' claim, as the procedure 1915 described in [RFC6920] also encodes the used hash function as 1916 metadata of the hash value. 1918 A.2.2.2. Client Credential Claim 1920 The 'client_cred' claim provides an asymmetric key that the Client 1921 owning the Access Token wishes to use as its own public key, but 1922 which is not used as proof-of-possession key. 1924 This parameter follows the syntax of the 'cnf' claim from Section 3.1 1925 of [I-D.ietf-ace-cwt-proof-of-possession] when including Value Type 1926 "COSE_Key" (1) and specifying an asymmetric key. Alternative Value 1927 Types defined in future specifications are fine to consider if 1928 indicating a non-encrypted asymmetric key. 1930 A.3. Client-RS Communication 1932 This section details the POST request and response to the /authz-info 1933 endpoint between the Client and the RS. With respect to the 1934 exchanged messages and their content, the Client and the RS perform 1935 as defined in Section 4 of the OSCORE profile of ACE 1936 [I-D.ietf-ace-oscore-profile]. 1938 That is, the Client generates a nonce N1 and posts it to the RS, 1939 together with the Access Token that includes the material provisioned 1940 by the AS. Then, the RS generates a nonce N2, and derives a pairwise 1941 OSCORE Security Context as described Section 3.2 of [RFC8613]. In 1942 particular, it uses the two nonces established with the Client and 1943 two shared secrets, together with additional pieces of information 1944 specified in the Access Token. 1946 The proof-of-possession required to bind the Access Token to the 1947 Client is implicitly performed by generating the pairwise OSCORE 1948 Security Context using the pop-key as part of the OSCORE Master 1949 Secret, for both the Client and the RS. In addition, the derivation 1950 of the pairwise OSCORE Security Context takes as input also 1951 information related to the OSCORE group, i.e. the Master Secret and 1952 Group Identifier of the group, as well as the Sender ID of the Client 1953 in the group. Hence, the derived pairwise OSCORE Security Context is 1954 also securely bound to the Group OSCORE Security Context of the 1955 OSCORE Group. 1957 Therefore, an attacker using a stolen Access Token cannot generate a 1958 valid pairwise OSCORE Security Context and thus cannot prove 1959 possession of the pop-key. Also, if a Client legitimately owns an 1960 Access Token but has not joined the OSCORE group, that Client cannot 1961 generate a valid pairwise OSCORE Security Context either, since it 1962 lacks the Master Secret used in the OSCORE group. 1964 Besides, just as in the main mode (see Section 4), the RS is able to 1965 verify whether the Client has indeed the claimed Sender ID and public 1966 key in the OSCORE group. 1968 A.3.1. C-to-RS POST to authz-info Endpoint 1970 The Client MUST generate a nonce N1 and post it to the /authz-info 1971 endpoint of the RS together with the Access Token, as defined in 1972 Section 4.1 of the OSCORE profile of ACE 1973 [I-D.ietf-ace-oscore-profile]. 1975 The same recommendations, considerations and behaviors defined in 1976 Section 4.1 of [I-D.ietf-ace-oscore-profile] hold. 1978 A.3.2. RS-to-C: 2.01 (Created) 1980 The RS MUST verify the validity of the Access Token as defined in 1981 Section 4.2, with the following modifications. 1983 o The RS checks that the 'cnf' claim is included in the Access Token 1984 and that it contains an OSCORE_Security_Context object. 1986 o The RS checks that the 'client_cred' claim is included in the 1987 Access Token. 1989 o The RS considers the content of the 'client_cred' claim as the 1990 public key associated to the signing private key of the Client in 1991 the OSCORE group, whose GID is specified in the 'contextId_input' 1992 claim. The RS can compare this public key with the public key of 1993 the claimed Client retrieved from the Group Manager (see 1994 Section 4.2). 1996 If any of the checks fails, the RS MUST consider the Access Token non 1997 valid, and MUST respond to the Client with an error response code 1998 equivalent to the CoAP code 4.00 (Bad Request). 2000 If the Access Token is valid and further checks on its content are 2001 successful, the RS MUST generate a nonce N2 and include it in the 2002 2.01 (Created) response to the Client, as defined in Section 4.2 of 2003 the OSCORE profile of ACE [I-D.ietf-ace-oscore-profile]. 2005 Further recommendations, considerations and behaviors defined in 2006 Section 4.2 of [I-D.ietf-ace-oscore-profile] hold for this 2007 specification. 2009 A.3.3. OSCORE Setup - Client Side 2011 Once having received the 2.01 (Created) response from the RS, 2012 following the POST request to the authz-info endpoint, the Client 2013 MUST extract the nonce N2 from the 'cnonce' parameter and the client 2014 identifier from the 'clientId' parameter (if present) in the CBOR map 2015 in the payload of the response. 2017 Note that, if present in the 2.01 (Created) response, the 'clientId' 2018 parameter supersedes the analogous parameter possibly provided by the 2019 AS to C in Appendix A.2.2. Also, note that this identifier is used 2020 by C as Sender ID in the pairwise OSCORE Security Context to be 2021 established with the RS, and is different as well as unrelated to the 2022 Sender ID of C in the OSCORE group. 2024 Then, the Client performs the following actions, in order to set up 2025 and fully derive the pairwise OSCORE Security Context for 2026 communicating with the RS. 2028 o The Client MUST set the ID Context of the pairwise OSCORE Security 2029 Context as the concatenation of: i) GID, i.e. the Group Identifier 2030 of the OSCORE group, as specified by the Client in the 2031 'context_id' parameter of the Client-to-AS request; ii) the nonce 2032 N1; iii) the nonce N2; and iv) CID, i.e. the value in the 2033 contextId parameter of the OSCORE_Security_Context object provided 2034 in the 'cnf' parameter of the Access Token response from the AS. 2035 The concatenation occurs in this order: ID Context = GID | N1 | 2036 N2 | CID, where | denotes byte string concatenation. 2038 Note that, if the Client wishes to update its access rights as 2039 defined in Appendix A.2.1, the 'kid_arr' in Figure 10 for the C- 2040 to-AS request MUST be built as follows. The 'IdContext' element 2041 has as value the value of the 'contextId' parameter of the 2042 OSCORE_Security_Context object, as specified in the 'cnf' 2043 parameter of the original Access Token response from the AS. 2044 Since the client is aware of the sizes of N1, N2 and GID, it can 2045 retrieve this value as the CID component from the ID Context of 2046 the pairwise OSCORE Security Context as defined above, i.e. by 2047 considering only the appropriate amount of bytes from the end. 2049 o The Client MUST set the updated Master Salt of the pairwise OSCORE 2050 Security Context as the concatenation of SaltInput, MSalt, the 2051 nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the 2052 Sender ID that the Client has in the OSCORE group, which is known 2053 to the Client as a member of the OSCORE group; ii) MSalt is the 2054 (optional) Master Salt in the pairwise OSCORE Security Context; 2055 and iii) GMSalt is the (optional) Master Salt in the Group OSCORE 2056 Security Context, which is known to the Client as a member of the 2057 OSCORE group. The concatenation occurs in this order: Master Salt 2058 = SaltInput | MSalt | N1 | N2 | GMSalt, where | denotes byte 2059 string concatenation. Optional values, if not specified, are not 2060 included in the concatenation. 2062 o The Client MUST set the Master Secret of the pairwise OSCORE 2063 Security Context to the concatenation of MSec and GMSec, where: i) 2064 MSec is the value of the 'ms' parameter in the 2065 OSCORE_Security_Context object of the 'cnf' parameter, received 2066 from the AS in Appendix A.2.2; while ii) GMSec is the Master 2067 Secret of the Group OSCORE Security Context, which is known to the 2068 Client as a member of the OSCORE group. 2070 o The Client MUST set the Recipient ID as indicated in the 2071 corresponding parameter received from the AS in Appendix A.2.2, 2072 i.e. to the value of the 'serverId' parameter in the 2073 OSCORE_Security_Context object of the 'cnf' parameter. 2075 o The Client MUST set the AEAD Algorithm, HKDF, and Replay Window as 2076 indicated in the corresponding parameters received from the AS in 2077 Appendix A.2.2, if present in the OSCORE_Security_Context object 2078 of the 'cnf' parameter. In case these parameters are omitted, the 2079 default values are used as described in Section 3.2 of [RFC8613]. 2081 o The client MUST set the Sender ID as indicated in the response 2082 from the AS in Appendix A.2.2, i.e. to the value of the 'clientId' 2083 parameter in the OSCORE_Security_Context object of the 'cnf' 2084 parameter. 2086 Finally, the client MUST derive the complete pairwise OSCORE Security 2087 Context following Section 3.2.1 of [RFC8613]. 2089 From then on, when communicating with the RS to access the resources 2090 as specified by the authorization information, the Client MUST use 2091 the newly established pairwise OSCORE Security Context or the Group 2092 OSCORE Security Context of the OSCORE Group where both the Client and 2093 the RS are members. 2095 If any of the expected parameters is missing (e.g. any of the 2096 mandatory parameters from the AS, or 'clientId' both from the AS and 2097 in the 2.01 (Created) response from the RS), the Client MUST stop the 2098 exchange, and MUST NOT derive the pairwise OSCORE Security Context. 2099 The Client MAY restart the exchange, to get the correct security 2100 material. 2102 Then, the Client uses this pairwise OSCORE Security Context to send 2103 requests to RS protected with OSCORE. In the first request sent to 2104 the RS, the Client MAY include the kid context if the application 2105 needs to, with value the ID Context of the pairwise OSCORE Context as 2106 described above. Besides, the Client uses the Group OSCORE Security 2107 Context for protecting unicast requests to the RS, or multicast 2108 requests to the OSCORE group including also the RS. 2110 A.3.4. OSCORE Setup - Resource Server Side 2112 After validation of the Access Token as defined in Appendix A.3.2 and 2113 after sending the 2.01 (Created) response, the RS performs the 2114 following actions, in order to set up and fully derive the pairwise 2115 OSCORE Security Context created to communicate with the Client. 2117 o The RS MUST set the ID Context of the pairwise OSCORE Security 2118 Context as the concatenation of: i) GID, i.e. the Group Identifier 2119 of the OSCORE group, as specified in the 'contextId' parameter of 2120 the OSCORE_Security_Context object, in the 'cnf' claim of the 2121 Access Token received from the Client (see Appendix A.3.1); ii) 2122 the nonce N1; iii) the nonce N2; and iv) CID which is the value in 2123 the contextId parameter of the OSCORE_Security_Context object 2124 provided in the 'cnf' claim of the Access Token. The 2125 concatenation occurs in this order: ID Context = GID | N1 | N2 | 2126 CID, where | denotes byte string concatenation. 2128 o The RS MUST set the new Master Salt of the pairwise OSCORE 2129 Security Context as the concatenation of SaltInput, MSalt, the 2130 nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the 2131 Sender ID that the Client has in the OSCORE group, as specified in 2132 the 'salt_input' claim included in the Access Token received from 2133 the Client (see Appendix A.3.1); ii) MSalt is the (optional) 2134 Master Salt in the pairwise OSCORE Security Context as specified 2135 in the 'salt' parameter in the OSCORE_Security_Context object of 2136 the 'cnf' claim, included in the Access Token received from the 2137 Client; and iii) GMSalt is the (optional) Master Salt in the Group 2138 OSCORE Security Context, which is known to the RS as a member of 2139 the OSCORE group. The concatenation occurs in this order: Master 2140 Salt = SaltInput | MSalt | N1 | N2 | GMSalt, where | denotes byte 2141 string concatenation. Optional values, if not specified, are not 2142 included in the concatenation. 2144 o The RS MUST set the Master Secret of the pairwise OSCORE Security 2145 Context to the concatenation of MSec and GMSec, where: i) MSec is 2146 the value of the 'ms' parameter in the OSCORE_Security_Context 2147 object of the 'cnf' claim, included in the Access Token received 2148 from the Client (see Appendix A.3.1); while ii) GMSec is the 2149 Master Secret of the Group OSCORE Security Context, which is known 2150 to the RS as a member of the OSCORE group. 2152 o The RS MUST set the Sender ID of the pairwise OSCORE Security 2153 Context from the corresponding parameter received from the Client 2154 in the Access Token (see Appendix A.3.1), i.e. to the value of the 2155 'serverId' parameter in the OSCORE_Security_Context object of the 2156 'cnf' claim. 2158 o The RS MUST set the Recipient ID of the pairwise OSCORE Security 2159 Context to what indicated in the corresponding parameter received 2160 from the Client in the Access Token (see Appendix A.3.1), i.e. to 2161 the value of the 'clientId' parameter in the 2162 OSCORE_Security_Context object of the 'cnf' claim. 2164 o The RS MUST set the AEAD Algorithm, HKDF, and Replay Window from 2165 the corresponding parameters received from the Client in the 2166 Access Token (see Appendix A.3.1), if present in the 2167 OSCORE_Security_Context object of the 'cnf' claim. In case these 2168 parameters are omitted, the default values are used as described 2169 in Section 3.2 of [RFC8613]. 2171 Finally, the RS MUST derive the complete pairwise OSCORE Security 2172 Context following Section 3.2.1 of [RFC8613]. 2174 Once having completed the derivation above, the RS MUST associate the 2175 authorization information from the Access Token with the just 2176 established pairwise OSCORE Security Context. Furthermore, as 2177 defined in Section 4.2, the RS MUST associate the authorization 2178 information from the Access Token with the Group OSCORE Security 2179 Context. 2181 Then, the RS uses this pairwise OSCORE Security Context to verify 2182 requests from and send responses to the Client protected with OSCORE, 2183 when this Security Context is used. If OSCORE verification fails, 2184 error responses are used, as specified in Section 8 of [RFC8613]. 2185 Besides, the RS uses the Group OSCORE Security Context to verify 2186 (multicast) requests from and send responses to the Client protected 2187 with Group OSCORE. If Group OSCORE verification fails, error 2188 responses are used, as specified in Section 7 of 2189 [I-D.ietf-core-oscore-groupcomm]. Additionally, for every incoming 2190 request, if OSCORE or Group OSCORE verification succeeds, the 2191 verification of access rights is performed as described in 2192 Appendix A.3.5. 2194 After the expiration of the Access Token related to a pairwise OSCORE 2195 Security Context and to a Group OSCORE Security Context, the RS MUST 2196 NOT use the pairwise OSCORE Security Context and MUST respond with an 2197 unprotected 4.01 (Unauthorized) error message to received requests 2198 that correspond to a security context with an expired token. Also, 2199 if the Client uses the Group OSCORE Security Context to send a 2200 request for any resource intended for OSCORE group members and that 2201 requires an active Access Token, the RS MUST respond with a 4.01 2202 (Unauthorized) error message protected with the Group OSCORE Security 2203 Context. 2205 A.3.5. Access Rights Verification 2207 The RS MUST follow the procedures defined in Section 4.4. 2209 Additionally, if the RS receives an OSCORE-protected request from a 2210 Client, the RS processes it according to [RFC8613]. 2212 If the OSCORE verification succeeds, and the target resource requires 2213 authorization, the RS retrieves the authorization information from 2214 the Access Token associated to the pairwise OSCORE Security Context 2215 and to the Group OSCORE Security Context. Then, the RS MUST verify 2216 that the action requested on the resource is authorized. 2218 The response code MUST be 4.01 (Unauthorized) in case the Client has 2219 not used either of the two Security Contexts associated with the 2220 Access Token, or if the RS has no valid Access Token for the Client. 2222 A.4. Secure Communication with the AS 2224 The same considerations for secure communication with the AS as 2225 defined in Section 5 hold. 2227 A.5. Discarding the Security Context 2229 The Client and the RS MUST follow what is defined in Section 6 of 2230 [I-D.ietf-ace-oscore-profile] about discarding the pairwise OSCORE 2231 Security Context. 2233 Additionally, they MUST follow what is defined in the main mode of 2234 the profile (see Section 6), with respect to the Group OSCORE 2235 Security Context. 2237 The Client or RS can acquire a new Group OSCORE Security Context, by 2238 re-joining the OSCORE group, e.g. by using the approach defined in 2239 [I-D.ietf-ace-key-groupcomm-oscore]. In such a case, the Client 2240 SHOULD request a new Access Token and post it to the RS, in order to 2241 establish a new pairwise OSCORE Security Context and bind it to the 2242 Group OSCORE Security Context obtained upon re-joining the group. 2244 A.6. CBOR Mappings 2246 The new parameters defined in this document MUST be mapped to CBOR 2247 types as specified in Figure 6, with the following addition, using 2248 the given integer abbreviation for the map key. 2250 /----------------+----------+------------\ 2251 | Parameter name | CBOR Key | Value Type | 2252 |----------------+----------+------------| 2253 | client_cred | TBD5 | map | 2254 \----------------+----------+------------/ 2256 Figure 17: CBOR mappings for new parameters. 2258 The new claims defined in this document MUST be mapped to CBOR types 2259 as specified in Figure 7, with the following addition, using the 2260 given integer abbreviation for the map key. 2262 /--------------+----------+------------\ 2263 | Claim name | CBOR Key | Value Type | 2264 |--------------+----------+------------| 2265 | client_cred | TBD5 | map | 2266 \--------------+----------+------------/ 2268 Figure 18: CBOR mappings for new claims. 2270 A.7. Security Considerations 2272 The dual mode of this profile inherits the security considerations 2273 from the main mode (see Section 8), as well as from the security 2274 considerations of the OSCORE profile of ACE 2276 [I-D.ietf-ace-oscore-profile]. Also, the security considerations 2277 about OSCORE [RFC8613] hold for the dual mode of this profile, as to 2278 the specific use of OSCORE. 2280 A.8. Privacy Considerations 2282 The same privacy considerations as defined in the main mode of this 2283 profile apply (see Section 9). 2285 In addition, as this profile mode also uses OSCORE, the privacy 2286 considerations from [RFC8613] apply as well, as to the specific use 2287 of OSCORE. 2289 Furthermore, this profile mode inherits the privacy considerations 2290 from the OSCORE profile of ACE [I-D.ietf-ace-oscore-profile]. 2292 Appendix B. Profile Requirements 2294 This appendix lists the specifications on this profile based on the 2295 requirements of the ACE framework, as requested in Appendix C of 2296 [I-D.ietf-ace-oauth-authz]. 2298 o (Optional) discovery process of how the Client finds the right AS 2299 for an RS it wants to send a request to: Not specified. 2301 o Communication protocol the Client and the RS must use: CoAP. 2303 o Security protocol(s) the Client and RS must use: Group OSCORE, 2304 i.e. exchange of secure messages by using a pre-established Group 2305 OSCORE Security Context. The optional dual mode defined in 2306 Appendix A additionally uses OSCORE, i.e. establishment of a 2307 pairwise OSCORE Security Context and exchange of secure messages. 2309 o How the Client and the RS mutually authenticate: Explicitly, by 2310 possession of a common Group OSCORE Security Context and usage of 2311 digital countersignatures, embedded in messages protected with 2312 Group OSCORE. In the optional dual mode defined in Appendix A, 2313 this may also happen implicitly, by possession of a common OSCORE 2314 Security Context (when using OSCORE). 2316 o Content-format of the protocol messages: "application/ace+cbor". 2318 o Proof-of-Possession protocol(s) and how to select one; which key 2319 types (e.g. symmetric/asymmetric) supported: Group OSCORE 2320 algorithms; distributed and verified asymmetric keys. In the 2321 optional dual mode defined in Appendix A: OSCORE algorithms; pre- 2322 established symmetric keys 2324 o profile identifier: coap_group_oscore 2326 o (Optional) how the RS talks to the AS for introspection: HTTP/CoAP 2327 (+ TLS/DTLS/OSCORE). 2329 o How the client talks to the AS for requesting a token: HTTP/CoAP 2330 (+ TLS/DTLS/OSCORE). 2332 o How/if the authz-info endpoint is protected: Not protected. 2334 o (Optional) other methods of token transport than the authz-info 2335 endpoint: Not specified. 2337 Acknowledgments 2339 The authors sincerely thank Benjamin Kaduk, John Mattsson, Dave 2340 Robin, Jim Schaad and Goeran Selander for their comments and 2341 feedback. 2343 The work on this document has been partly supported by VINNOVA and 2344 the Celtic-Next project CRITISEC. 2346 Authors' Addresses 2348 Marco Tiloca 2349 RISE AB 2350 Isafjordsgatan 22 2351 Kista SE-16440 Stockholm 2352 Sweden 2354 Email: marco.tiloca@ri.se 2356 Rikard Hoeglund 2357 RISE AB 2358 Isafjordsgatan 22 2359 Kista SE-16440 Stockholm 2360 Sweden 2362 Email: rikard.hoglund@ri.se 2363 Ludwig Seitz 2364 Combitech 2365 Djaeknegatan 31 2366 Malmoe SE-21135 Malmoe 2367 Sweden 2369 Email: ludwig.seitz@combitech.se 2371 Francesca Palombini 2372 Ericsson AB 2373 Torshamnsgatan 23 2374 Kista SE-16440 Stockholm 2375 Sweden 2377 Email: francesca.palombini@ericsson.com