idnits 2.17.1 draft-tiloca-ace-group-oscore-profile-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1383 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-08 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-35 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-13 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-11 == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-00 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-09 == Outdated reference: A later version (-12) exists of draft-ietf-cose-rfc8152bis-algs-11 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') == Outdated reference: A later version (-15) exists of draft-ietf-cose-rfc8152bis-struct-11 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' ** Downref: Normative reference to an Informational RFC: RFC 5869 == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-12 == Outdated reference: A later version (-17) exists of draft-ietf-ace-mqtt-tls-profile-05 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-38 == 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: 2 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group M. Tiloca 3 Internet-Draft R. Hoeglund 4 Intended status: Standards Track RISE AB 5 Expires: January 14, 2021 L. Seitz 6 Combitech 7 F. Palombini 8 Ericsson AB 9 July 13, 2020 11 Group OSCORE Profile of the Authentication and Authorization for 12 Constrained Environments Framework 13 draft-tiloca-ace-group-oscore-profile-03 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 January 14, 2021. 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 . . . . . . . . . . . . . . . . . 9 70 2.3. Access Token Posting . . . . . . . . . . . . . . . . . . 9 71 2.4. Secure Communication . . . . . . . . . . . . . . . . . . 10 72 3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 10 73 3.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . . . 11 74 3.1.1. 'context_id' Parameter . . . . . . . . . . . . . . . 12 75 3.1.2. 'salt_input' Parameter . . . . . . . . . . . . . . . 13 76 3.1.3. 'client_cred_verify' Parameter . . . . . . . . . . . 13 77 3.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . . . 13 78 3.2.1. Salt Input Claim . . . . . . . . . . . . . . . . . . 16 79 3.2.2. Context ID Input Claim . . . . . . . . . . . . . . . 17 80 4. Client-RS Communication . . . . . . . . . . . . . . . . . . . 17 81 4.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . . . 18 82 4.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . . 18 83 4.3. Client-RS Secure Communication . . . . . . . . . . . . . 19 84 4.3.1. Client Side . . . . . . . . . . . . . . . . . . . . . 19 85 4.3.2. Resource Server Side . . . . . . . . . . . . . . . . 19 86 4.4. Access Rights Verification . . . . . . . . . . . . . . . 20 87 5. Secure Communication with the AS . . . . . . . . . . . . . . 20 88 6. Discarding the Security Context . . . . . . . . . . . . . . . 20 89 7. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . . . 21 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 91 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 93 10.1. ACE Profile Registry . . . . . . . . . . . . . . . . . . 23 94 10.2. OAuth Parameters Registry . . . . . . . . . . . . . . . 23 95 10.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . 24 96 10.4. CBOR Web Token Claims Registry . . . . . . . . . . . . . 25 97 10.5. TLS Exporter Label Registry . . . . . . . . . . . . . . 26 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 100 11.2. Informative References . . . . . . . . . . . . . . . . . 28 101 Appendix A. Dual Mode (Group OSCORE & OSCORE) . . . . . . . . . 29 102 A.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 30 103 A.1.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . 32 104 A.1.2. Access Token Posting . . . . . . . . . . . . . . . . 32 105 A.1.3. Setup of the Pairwise OSCORE Security Context . . . . 32 106 A.1.4. Secure Communication . . . . . . . . . . . . . . . . 33 107 A.2. Client-AS Communication . . . . . . . . . . . . . . . . . 34 108 A.2.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . 34 109 A.2.2. AS-to-C: Access Token . . . . . . . . . . . . . . . . 37 110 A.3. Client-RS Communication . . . . . . . . . . . . . . . . . 44 111 A.3.1. C-to-RS POST to authz-info Endpoint . . . . . . . . . 45 112 A.3.2. RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . 45 113 A.3.3. OSCORE Setup - Client Side . . . . . . . . . . . . . 46 114 A.3.4. OSCORE Setup - Resource Server Side . . . . . . . . . 48 115 A.3.5. Access Rights Verification . . . . . . . . . . . . . 50 116 A.4. Secure Communication with the AS . . . . . . . . . . . . 50 117 A.5. Discarding the Security Context . . . . . . . . . . . . . 50 118 A.6. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . 51 119 A.7. Security Considerations . . . . . . . . . . . . . . . . . 51 120 A.8. Privacy Considerations . . . . . . . . . . . . . . . . . 51 121 Appendix B. Profile Requirements . . . . . . . . . . . . . . . . 52 122 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 53 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 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 of such applications, it may be just fine to enforce access 135 control in a straightforward fashion. That is, any Client authorized 136 to join the group, hence to get the group key material, can be also 137 implicitly authorized to perform any action at any resource of any 138 Server in the group. An example of application where such implicit 139 authorization might be used is a simple lighting scenario, where the 140 lightbulbs are the Servers, while the user account on an app on the 141 user's phone is the Client. In this case, it might be fine to not 142 require additional authorization evidence from any user account, if 143 it is acceptable that any current group member is also authorized to 144 switch on and off any light, or to check their status. 146 However, in different instances of such applications, the approach 147 above is not desirable, as different group members are intended to 148 have different access rights to resources of other group members. 149 That is, access control to the secure group communication channel and 150 access control to the resource space provided by servers in the group 151 should remain logically separated layers. For instance, a more fine- 152 grained approach is required in the two following use cases. 154 As a first case, an application provides control of smart locks 155 acting as Servers in the group, where: a first type of Client, e.g. a 156 user account of a child, is allowed to only query the status of the 157 smart locks; while a second type of Client, e.g. a user account of a 158 parent, is allowed to both query and change the status of the smart 159 locks. Further similar applications concern the enforcement of 160 different sets of permissions in groups with sensor/actuator devices, 161 e.g. thermostats, acting as Servers. Also, some group members may 162 even be intended as Servers only. Hence, they must be prevented from 163 acting as Clients altogether and from accessing resources at other 164 Servers, especially when attempting to perform non-safe operations. 166 As a second case, building automation scenarios often rely on Servers 167 that, under different circumstances, enforce different level of 168 priority for processing received commands. For instance, BACnet 169 deployments consider multiple classes of Clients, e.g. a normal light 170 switch (C1) and an emergency fire panel (C2). Then, a C1 Client is 171 not allowed to override a command from a C2 Client, until the latter 172 relinquishes control at its higher priority. That is: i) only C2 173 Clients should be able to adjust the minimum required level of 174 priority on the Servers, so rightly locking out C1 Clients if needed; 175 and ii) when a Server is set to accept only high-priority commands, 176 only C2 Clients should be able to perform such commands otherwise 177 allowed also to C1 Clients. Given the different maximum authority of 178 different Clients, fine-grained access control would effectively 179 limit the execution of high- and emergency-priority commands only to 180 devices that are in fact authorized to do so. Besides, it would 181 prevent a misconfigured or compromised device from initiating a high- 182 priority command and lock out normal control. 184 In the cases above, being a legitimate group member and owning the 185 group key material is not supposed to imply any particular access 186 rights. Also, introducing a different security group for each 187 different set of access rights would result in additional key 188 material to distribute and manage. In particular, if the access 189 rights for a single node change, this would require to evict that 190 node from the current group, followed by that node joining a 191 different group aligned with its new access rights. Moreover, the 192 key material of both groups would have to be renewed for their 193 current members. Overall, this would have a non negligible impact on 194 operations and performance in the system. 196 A fine-grained access control model can be rather enforced within a 197 same group, by using the Authentication and Authorization for 198 Constrained Environments (ACE) framework [I-D.ietf-ace-oauth-authz]. 199 That is, a Client has to first obtain authorization credentials in 200 the form of an Access Token, and post it to the Resource Server(s) in 201 the group before accessing the intended resources. 203 The ACE framework delegates to separate profile documents how to 204 secure communications between the Client and the Resource Server. 205 However each of the current profiles of ACE defined in 206 [I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-dtls-authorize] 207 [I-D.ietf-ace-mqtt-tls-profile] admits a single security protocol 208 that cannot be used to protect group messages sent over IP multicast. 210 This document specifies a profile of ACE, where a Client uses CoAP 211 [RFC7252] or CoAP over IP multicast [I-D.ietf-core-groupcomm-bis] to 212 communicate to one or multiple Resource Servers, which are members of 213 an application group and share a common set of resources. This 214 profile uses Group OSCORE [I-D.ietf-core-oscore-groupcomm] as the 215 security protocol to protect messages exchanged between the Client a 216 the Resource Servers. Hence, it requires that both the Client and 217 the Resource Servers have previously joined the same OSCORE group. 219 That is, this profile describes how access control is enforced for a 220 Client after it has joined an OSCORE group, to access resources at 221 other members in that group. The process for joining the OSCORE 222 group through the respective Group Manager as defined in 223 [I-D.ietf-ace-key-groupcomm-oscore] takes place before the process 224 described in this document, and is out of the scope of this profile. 226 The Client authorizes its access to the Resource Server by using an 227 Access Token, which is bound to a key (the proof-of-possession key). 228 This profile uses Group OSCORE to achieve server authentication, as 229 well as proof-of-possession for the Client public key associated to 230 the signing private key used in an OSCORE group. Furthermore, this 231 profile provides proof of Client's membership to the correct OSCORE 232 group, by binding the Access Token to the Client public key and 233 information from the pre-established Group OSCORE Security Context, 234 thus allowing the Resource Server to verify this upon reception of a 235 messages protected with Group OSCORE from the Client. 237 OSCORE [RFC8613] specifies how to use COSE 238 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] to 239 secure CoAP messages. Group OSCORE builds on OSCORE to provide 240 secure group communication, and ensures source authentication either: 241 by means of digital countersignatures embedded in protected messages 242 (in group mode); by protecting messages with pairwise key material 243 derived from the asymmetric keys of the two peers exchanging the 244 message (in pairwise mode). 246 1.1. Terminology 248 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 249 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 250 "OPTIONAL" in this document are to be interpreted as described in BCP 251 14 [RFC2119] [RFC8174] when, and only when, they appear in all 252 capitals, as shown here. 254 Readers are expected to be familiar with the terms and concepts 255 related to the CoAP protocol [RFC7252], as well as related to the 256 protection and processing of CoAP messages in OSCORE [RFC8613] and 257 Group OSCORE [I-D.ietf-core-oscore-groupcomm]. These include the 258 concept of Group Manager, as the entity responsible for a set of 259 groups where communications among members are secured with Group 260 OSCORE. 262 Readers are expected to be familiar with the terms and concepts 263 described in the ACE framework for authentication and authorization 264 [I-D.ietf-ace-oauth-authz], as well as in the OSCORE profile of ACE 265 [I-D.ietf-ace-oscore-profile]. The terminology for entities in the 266 considered architecture is defined in OAuth 2.0 [RFC6749]. In 267 particular, this includes Client (C), Resource Server (RS), and 268 Authorization Server (AS). 270 Note that, unless otherwise indicated, the term "endpoint" is used 271 here following its OAuth definition, aimed at denoting resources such 272 as /token and /introspect at the AS, and /authz-info at the RS. This 273 document does not use the CoAP definition of "endpoint", which is "An 274 entity participating in the CoAP protocol". 276 2. Protocol Overview 278 This section provides an overview of this profile, i.e. on how to use 279 the ACE framework for authentication and authorization 280 [I-D.ietf-ace-oauth-authz] to secure communications between a Client 281 and a (set of) Resource Server(s) using Group OSCORE 282 [I-D.ietf-core-oscore-groupcomm]. 284 Note that this profile of ACE describes how access control can be 285 enforced for a node after it has joined an OSCORE group, to access 286 resources at other members in that group. 288 In particular, the process for joining the OSCORE group through the 289 respective Group Manager as defined in 290 [I-D.ietf-ace-key-groupcomm-oscore] must take place before the 291 process described in this document, and is out of the scope of this 292 profile. 294 An overview of the protocol flow for this profile is shown in 295 Figure 1. In the figure, it is assumed that both RS1 and RS2 are 296 associated with the same AS. It is also assumed that C, RS1 and RS2 297 have previously joined an OSCORE group with Group Identifier (gid) 298 "abcd0000", and got assigned Sender ID (sid) "0", "1" and "2" in the 299 group, respectively. 301 C RS1 RS2 AS 302 | [--- Resource Request --->] | | | 303 | | | | 304 | [<--- AS Information -----] | | | 305 | | | | 306 |-------- POST /token ------------------------------------------------>| 307 | (aud: RS1, sid: 0, gid: abcd0000, ...) | | 308 | | | | 309 |<--------------------------------- Access Token + RS Information -----| 310 | | (aud: RS1, sid: 0, gid: abcd0000, ...) | 311 |---- POST /authz-info ------>| | | 312 | (access_token) | | | 313 | | | | 314 |<--- 2.01 Created -----------| | | 315 | | | | 316 |-------- POST /token ------------------------------------------------>| 317 | (aud: RS2, sid: 0, gid: abcd0000, ...) | | 318 | | | | 319 |<--------------------------------- Access Token + RS Information -----| 320 | | (aud: RS2, sid: 0, gid: abcd0000, ...) | 321 | | | | 322 |----- POST /authz-info ------------------>| | 323 | (access_token) | | | 324 | | | | 325 |<--- 2.01 Created ------------------------| | 326 | | | | 327 |-- Group OSCORE Request -+-->| | | 328 | (kid: 0, gid: abcd0000) \-------------->| | 329 | | | | 330 |<--- Group OSCORE Response --| | | 331 | (kid: 1) | | | 332 | | | | 333 |<--- Group OSCORE Response ---------------| | 334 | (kid: 2) | | | 335 | ... | | | 337 Figure 1: Protocol Overview. 339 2.1. Pre-Conditions 341 Using Group OSCORE and this profile requires both the Client and the 342 Resource Servers to have previously joined an OSCORE group. This 343 especially includes the derivation of the Group OSCORE Security 344 Context and the assignment of unique Sender IDs to use in the group. 345 Nodes may join the OSCORE group through the respective Group Manager 346 by using the approach defined in [I-D.ietf-ace-key-groupcomm-oscore], 347 which is also based on ACE. 349 After the Client and Resource Servers have joined the group, this 350 profile provides access control for accessing resources on those 351 Resource Servers, by securely communicating with Group OSCORE. 353 As a pre-requisite for this profile, the Client has to have 354 successfully joined the OSCORE group where also the Resource Servers 355 (RSs) are members. Depending on the limited information initially 356 available, the Client may have to first discover the exact OSCORE 357 group used by the RSs for the resources of interest, e.g. by using 358 the approach defined in [I-D.tiloca-core-oscore-discovery]. 360 2.2. Access Token Retrieval 362 This profile requires that the Client retrieves an Access Token from 363 the AS for the resource(s) it wants to access on each of the RSs, 364 using the /token endpoint, as specified in Section 5.6 of 365 [I-D.ietf-ace-oauth-authz]. In a general case, it can be assumed 366 that different RSs are associated to different ASs, even if the RSs 367 are members of a same OSCORE group. 369 In the Access Token request to the AS, the Client MUST include the 370 Group Identifier of the OSCORE group and its own Sender ID in that 371 group. The AS MUST specify these pieces of information in the Access 372 Token, included in the Access Token response to the Client. 374 Furthermore, in the Access Token request to the AS, the Client MUST 375 also include: its own public key, associated to the private signing 376 key used in the OSCORE group; and a signature computed with such 377 private key, over a quantity uniquely related to the secure 378 communication association between the Client and the AS. The AS MUST 379 include also the public key indicated by the client in the Access 380 Token. 382 To gain knowledge of the AS in charge of a resource hosted at a RS, 383 the Client MAY first send an initial Unauthorized Resource Request 384 message to that RS. Then, the RS denies the request and replies to 385 the Client by specifying the address of its AS, as defined in 386 Section 5.1 of [I-D.ietf-ace-oauth-authz]. The Access Token request 387 and response MUST be confidentiality-protected and ensure 388 authenticity. This profile RECOMMENDS the use of OSCORE between the 389 Client and the AS, but TLS [RFC5246][RFC8446] or DTLS 390 [RFC6347][I-D.ietf-tls-dtls13] MAY be used additionally or instead. 392 2.3. Access Token Posting 394 After having retrieved the Access Token from the AS, the Client posts 395 the Access Token to the RS, using the /authz-info endpoint and 396 mechanisms specified in Section 5.8 of [I-D.ietf-ace-oauth-authz] and 397 Content-Format = application/ace+cbor. 399 If the Access Token is valid, the RS replies to this POST request 400 with a 2.01 (Created) response with Content-Format = application/ 401 ace+cbor. Also, the RS associates the received Access Token with the 402 Group OSCORE Security Context identified by the Group Identifier 403 specified in the Access Token, following Section 3.2 of [RFC8613]. 404 In practice, the RS maintains a collection of Security Contexts with 405 associated authorization information, for all the clients that it is 406 currently communicating with, and the authorization information is a 407 policy used as input when processing requests from those clients. 409 Finally, the RS stores the association between i) the authorization 410 information from the Access Token; and ii) the Group Identifier of 411 the OSCORE group together with the Sender ID and the public key of 412 the Client in that group. This binds the Access Token with the Group 413 OSCORE Security Context of the OSCORE group. 415 Finally, when the Client communicates with the RS using the Group 416 OSCORE Security Context, the RS verifies that the Client is a 417 legitimate member of the OSCORE group and especially the exact group 418 member with the same Sender ID associated to the Access Token. This 419 occurs when verifying a request protected with Group OSCORE, since it 420 embeds a countersignature computed also over the Client's Sender ID 421 included in the message. 423 2.4. Secure Communication 425 The Client can send a request protected with Group OSCORE 426 [I-D.ietf-core-oscore-groupcomm] to the RS. This can be a unicast 427 request addressed to the RS, or a multicast request addressed to the 428 OSCORE group where the RS is also a member. To this end, the Client 429 uses the Group OSCORE Security Context already established upon 430 joining the OSCORE group, e.g. by using the approach defined in 431 [I-D.ietf-ace-key-groupcomm-oscore]. The RS may send a response back 432 to the Client, protecting it by means of the same Group OSCORE 433 Security Context. 435 3. Client-AS Communication 437 This section details the Access Token POST Request that the Client 438 sends to the /token endpoint of the AS, as well as the related Access 439 Token response. 441 The Access Token MUST be bound to the public key of the client as 442 proof-of-possession key (pop-key), by means of the 'cnf' claim. 444 3.1. C-to-AS: POST to Token Endpoint 446 The Client-to-AS request is specified in Section 5.6.1 of 447 [I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request 448 to the /token endpoint over a secure channel that guarantees 449 authentication, message integrity and confidentiality. 451 The POST request is formatted as the analogous Client-to-AS request 452 in the OSCORE profile of ACE (see Section 3.1 of 453 [I-D.ietf-ace-oscore-profile]), with the following additional 454 parameters that MUST be included in the payload. 456 o 'context_id', defined in Section 3.1.1 of this specification. 457 This parameter specifies the Group Identifier (GID), i.e. the Id 458 Context of an OSCORE group where the Client and the RS are 459 currently members. In particular, the Client wishes to 460 communicate with the RS using the Group OSCORE Security Context 461 associated to that OSCORE group. 463 o 'salt_input', defined in Section 3.1.2 of this specification. 464 This parameter includes the Sender ID that the Client has in the 465 OSCORE group whose GID is specified in the 'context_id' parameter 466 above. 468 o 'req_cnf', defined in Section 3.1 of [I-D.ietf-ace-oauth-params]. 469 This parameter includes the public key associated to the signing 470 private key that the Client uses in the OSCORE group whose GID is 471 specified in the 'context_id' parameter above. This public key 472 will be used as the pop-key bound to the Access Token. 474 o 'client_cred_verify', defined in Section 3.1.3 of this 475 specification. This parameter includes a signature computed by 476 the Client, by using the private key associated to the public key 477 in the 'req_cnf' parameter above. This allows the AS to verify 478 that the Client indeed owns the private key associated to that 479 public key, as its alleged identity credential within the OSCORE 480 group. The information to be signed MUST be the byte 481 representation of a quantity that uniquely represents the secure 482 communication association between the Client and the AS. It is 483 RECOMMENDED that the Client considers the following as information 484 to sign. 486 * If the Client and the AS communicate over (D)TLS, the 487 information to sign is an exporter value computed as defined in 488 Section 7.5 of [RFC8446]. In particular, the exporter label 489 MUST be 'EXPORTER-ACE-Sign-Challenge-Client-AS' defined in 490 Section 10.5 of this specification, together with an empty 491 'context_value', and 32 bytes as 'key_length'. 493 * If the Client and the AS communicate over OSCORE, the 494 information to sign is the output PRK of a HKDF-Extract step 495 [RFC5869], i.e. PRK = HMAC-Hash(salt, IKM). In particular, 496 'salt' takes (x1 | x2), where x1 is the ID Context of the 497 OSCORE Security Context between the Client and the AS, x2 is 498 the Sender ID of the Client in that Context, and | denotes byte 499 string concatenation. Also, 'IKM' is the OSCORE Master Secret 500 of the OSCORE Security Context between the Client and the AS. 501 The HKDF MUST be one of the HMAC-based HKDF [RFC5869] 502 algorithms defined for COSE [I-D.ietf-cose-rfc8152bis-algs]. 503 HKDF SHA-256 is mandatory to implement. 505 An example of such a request, with payload in CBOR diagnostic 506 notation without the tag and value abbreviations is reported in 507 Figure 2. 509 Header: POST (Code=0.02) 510 Uri-Host: "as.example.com" 511 Uri-Path: "token" 512 Content-Format: "application/ace+cbor" 513 Payload: 514 { 515 "audience" : "tempSensor4711", 516 "scope" : "read", 517 "context_id" : h'abcd0000', 518 "salt_input" : h'00', 519 "req_cnf" : { 520 "COSE_Key" : { 521 "kty" : EC2, 522 "crv" : P-256, 523 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 524 27c9e354089bbe13', 525 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 526 731e79a3b4e47120' 527 } 528 }, 529 "client_cred_verify" : h'...' 530 (signature content omitted for brevity), 531 } 533 Figure 2: Example C-to-AS POST /token request for an Access Token 534 bound to an asymmetric key. 536 3.1.1. 'context_id' Parameter 538 The 'context_id' parameter is an OPTIONAL parameter of the Access 539 Token request message defined in Section 5.6.1. of 540 [I-D.ietf-ace-oauth-authz]. This parameter provides a value that the 541 Client wishes to use with the RS as a hint for a security context. 542 Its exact content is profile specific. 544 3.1.2. 'salt_input' Parameter 546 The 'salt_input' parameter is an OPTIONAL parameter of the Access 547 Token request message defined in Section 5.6.1. of 548 [I-D.ietf-ace-oauth-authz]. This parameter provides a value that the 549 Client wishes to use as part of a salt with the RS, for deriving 550 cryptographic key material. Its exact content is profile specific. 552 3.1.3. 'client_cred_verify' Parameter 554 The 'client_cred_verify' parameter is an OPTIONAL parameter of the 555 Access Token request message defined in Section 5.6.1. of 556 [I-D.ietf-ace-oauth-authz]. This parameter provides a signature 557 computed by the Client to prove the possession of its own private 558 key. 560 3.2. AS-to-C: Access Token 562 After having verified the POST request to the /token endpoint and 563 that the Client is authorized to obtain an Access Token corresponding 564 to its Access Token request, the AS MUST verify the signature in the 565 'client_cred_verify' parameter, by using the public key specified in 566 the 'req_cnf' parameter. If the verification fails, the AS considers 567 the Client request invalid. 569 If all verifications are successful, the AS responds as defined in 570 Section 5.6.2 of [I-D.ietf-ace-oauth-authz]. If the Client request 571 was invalid, or not authorized, the AS returns an error response as 572 described in Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. 574 The AS can signal that the use of Group OSCORE is REQUIRED for a 575 specific Access Token by including the 'profile' parameter with the 576 value "coap_group_oscore" in the Access Token response. The Client 577 MUST use Group OSCORE towards all the Resource Servers for which this 578 Access Token is valid. Usually, it is assumed that constrained 579 devices will be pre-configured with the necessary profile, so that 580 this kind of profile negotiation can be omitted. 582 The AS MUST include the following information as metadata of the 583 issued Access Token. This profile RECOMMENDS the use of CBOR web 584 tokens (CWT) as specified in [RFC8392]. The Access Token MUST be 585 encrypted, since it will be transferred from the Client to the RS 586 over an unprotected channel. 588 o The same parameter 'profile' included in the Token Response to the 589 Client. 591 o The salt input specified in the 'salt_input' parameter of the 592 Token Request. If the Access Token is a CWT, the content of the 593 'salt_input' parameter MUST be placed in the 'salt_input' claim of 594 the Access Token, defined in Section 3.2.1 of this specification. 596 o The Context Id input specified in the 'context_id' parameter of 597 the Token Request. If the Access Token is a CWT, the content of 598 the 'context_id' parameter MUST be placed in the 'contextId_input' 599 claim of the Access Token, defined in Section 3.2.2 of this 600 specification. 602 o The public key that the client uses in the OSCORE group and 603 specified in the 'req_cnf' parameter of the Token request. If the 604 Access Token is a CWT, the public key MUST be specified in the 605 'cnf' claim, which follows the syntax from Section 3.1 of 606 [RFC8747] when including Value Type "COSE_Key" (1) and specifying 607 an asymmetric key. Alternative Value Types defined in future 608 specifications are fine to consider if indicating a non-encrypted 609 asymmetric key. 611 Figure 3 shows an example of such an AS response, with payload in 612 CBOR diagnostic notation without the tag and value abbreviations. 614 Header: Created (Code=2.01) 615 Content-Type: "application/ace+cbor" 616 Payload: 617 { 618 "access_token" : h'a5037674656d7053656e73 ...' 619 (remainder of CWT omitted for brevity), 620 "profile" : "coap_group_oscore", 621 "expires_in" : 3600, 622 } 624 Figure 3: Example AS-to-C Access Token response with the Group OSCORE 625 profile. 627 Figure 4 shows an example CWT, containing the client's public key in 628 the group (as pop-key) in the 'cnf' claim, in CBOR diagnostic 629 notation without tag and value abbreviations. 631 { 632 "aud" : "tempSensorInLivingRoom", 633 "iat" : "1360189224", 634 "exp" : "1360289224", 635 "scope" : "temperature_g firmware_p", 636 "cnf" : { 637 "COSE_Key" : { 638 "kty" : EC2, 639 "crv" : P-256, 640 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 641 27c9e354089bbe13', 642 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 643 731e79a3b4e47120' 644 }, 645 "salt_input" : h'00', 646 "contextId_input" : h'abcd0000' 647 } 649 Figure 4: Example CWT with OSCORE parameters (CBOR diagnostic 650 notation). 652 The same CWT as in Figure 4 and encoded in CBOR is shown in Figure 5, 653 using the value abbreviations defined in [I-D.ietf-ace-oauth-authz] 654 and [RFC8747]. 656 NOTE: it should be checked (and in case fixed) that the values used 657 below (which are not yet registered) are the final values registered 658 in IANA. 660 A7 # map(7) 661 03 # unsigned(3) 662 76 # text(22) 663 74656D7053656E736F72496E4C6976696E67526F6F6D 664 06 # unsigned(6) 665 1A 5112D728 # unsigned(1360189224) 666 04 # unsigned(4) 667 1A 51145DC8 # unsigned(1360289224) 668 09 # unsigned(9) 669 78 18 # text(24) 670 74656D70657261747572655F67206669726D776172655F70 671 08 # unsigned(8) 672 A1 # map(1) 673 01 # unsigned(1) 674 A4 # map(4) 675 01 # unsigned(1) 676 02 # unsigned(2) 677 20 # negative(0) 678 01 # unsigned(1) 679 21 # negative(1) 680 58 20 # bytes(32) 681 D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9 682 E354089BBE13 683 22 # negative(2) 684 58 20 # bytes(32) 685 F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E515D020731E 686 79A3B4E47120 687 18 3C # unsigned(60) 688 41 # bytes(1) 689 00 690 18 3D # unsigned(61) 691 44 # bytes(4) 692 ABCD0000 694 Figure 5: Example CWT with OSCORE parameters. 696 3.2.1. Salt Input Claim 698 The 'salt_input' claim provides a value that the Client requesting 699 the Access Token wishes to use as a part of a salt with the RS, e.g. 700 for deriving cryptographic material. 702 This parameter specifies the value of the salt input, encoded as a 703 CBOR byte string. 705 3.2.2. Context ID Input Claim 707 The 'contextId_input' claim provides a value that the Client 708 requesting the Access Token wishes to use with the RS, as a hint for 709 a security context. 711 This parameter specifies the value of the context ID input, encoded 712 as a CBOR byte string. 714 4. Client-RS Communication 716 This section details the POST request and response to the /authz-info 717 endpoint between the Client and the RS. 719 The proof-of-possession required to bind the Access Token to the 720 Client is explicitly performed when the RS receives and verifies a 721 request from the Client protected with Group OSCORE, either with the 722 group mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]) or 723 with the pairwise mode (see Section 9 of 724 [I-D.ietf-core-oscore-groupcomm]). 726 In particular, the RS uses the Client's public key bound to the 727 Access Token, either when verifying the countersignature of the 728 request (if protected with the group mode), or when verifying the 729 request as integrity-protected with pairwise key material derived 730 from the two peers' asymmetric keys (if protected with the pairwise 731 mode). In either case, the RS also authenticates the Client. 733 Similarly, when receiving a protected response from the RS, the 734 Client uses the RS's public key either when verifying the 735 countersignature of the response (if protected with the group mode), 736 or when verifying the response as integrity-protected with pairwise 737 key material derived from the two peers' asymmetric keys (if 738 protected with the pairwise mode). In either case, the Client also 739 authenticates the RS. 741 Therefore, an attacker using a stolen Access Token cannot generate a 742 valid Group OSCORE message signed with the Client's private key, and 743 thus cannot prove possession of the pop-key bound to the Access 744 Token. Also, if a Client legitimately owns an Access Token but has 745 not joined the OSCORE group, it cannot generate a valid Group OSCORE 746 message, as it does not own the necessary key material shared among 747 the group members. 749 Furthermore, a Client C1 is supposed to obtain a valid Access Token 750 from the AS, as including the public key associated to its own 751 signing key used in the OSCORE group, together with its own Sender ID 752 in that OSCORE group (see Section 3.1). This makes it possible for 753 the RS receiving an Access Token to verify with the Group Manager of 754 that OSCORE group whether such a Client has indeed that Sender ID and 755 that public key in the OSCORE group. 757 As a consequence, a different Client C2, also member of the same 758 OSCORE group, is not able to impersonate C1, by: i) getting a valid 759 Access Token, specifying the Sender ID of C1 and a different (made- 760 up) public key; ii) successfully posting the Access Token to RS; and 761 then iii) attempting to communicate using Group OSCORE impersonating 762 C1, while blaming C1 for the consequences. 764 4.1. C-to-RS POST to authz-info Endpoint 766 The Client posts the Access Token to the /authz-info endpoint of the 767 RS, as defined in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 769 4.2. RS-to-C: 2.01 (Created) 771 The RS MUST verify the validity of the Access Token as defined in 772 Section 5.8.1 of [I-D.ietf-ace-oauth-authz], with the following 773 additions. 775 o The RS checks that the 'salt_input' claim is included in the 776 Access Token. 778 o The RS checks that the 'contextId_input' claim is included in the 779 Access Token. 781 o The RS checks that the 'cnf' claim is included in the Access 782 Token. 784 o The RS considers the content of the 'cnf' claim as the public key 785 associated to the signing private key of the Client in the OSCORE 786 group, whose GID is specified in the 'contextId_input' claim 787 above. If it does not already store that public key, the RS MUST 788 request it to the Group Manager of the OSCORE group as described 789 in [I-D.ietf-ace-key-groupcomm-oscore], specifying the Sender ID 790 of that Client in the OSCORE group, i.e. the value of the 791 'salt_input' claim above. The RS MUST check that the key 792 retrieved from the Group Manager matches the one retrieved from 793 the 'cnf' claim. When doing so, the 'kid' parameter of the 794 COSE_Key, if present, MUST NOT be considered for the comparison. 796 If any of the checks above fails, the RS MUST consider the Access 797 Token non valid, and MUST respond to the Client with an error 798 response code equivalent to the CoAP code 4.00 (Bad Request). 800 If the Access Token is valid and further checks on its content are 801 successful, the RS associates the authorization information from the 802 Access Token with the Group OSCORE Security Context. 804 In particular, the RS associates the authorization information from 805 the Access Token with the tuple (GID, SaltInput, PubKey), where GID 806 is the Group Identifier of the OSCORE Group, while SaltInput and 807 PubKey are the Sender ID and the public key that the Client uses in 808 that OSCORE group, respectively. These can be retrieved from the 809 'contextId_input', 'salt_input' and 'cnf' claims of the Access Token, 810 respectively. The RS MUST keep this association up-to-date over 811 time. 813 Finally, the RS MUST send a 2.01 (Created) response to the Client, as 814 defined in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 816 4.3. Client-RS Secure Communication 818 When previously joining the OSCORE group, both the Client and RS have 819 already established the related Group OSCORE Security Context to 820 communicate as group members. Therefore, they can simply start to 821 securely communicate using Group OSCORE, without deriving any 822 additional key material or security association. 824 4.3.1. Client Side 826 After having received the 2.01 (Created) response from the RS, 827 following the POST request to the authz-info endpoint, the Client can 828 start to communicate with the RS using Group OSCORE 829 [I-D.ietf-core-oscore-groupcomm]. 831 When communicating with the RS to access the resources as specified 832 by the authorization information, the Client MUST use the Group 833 OSCORE Security Context of the OSCORE group, whose GID was specified 834 in the 'context_id' parameter of the Token request. 836 4.3.2. Resource Server Side 838 After successful validation of the Access Token as defined in 839 Section 4.2 and after having sent the 2.01 (Created) response, the RS 840 can start to communicate with the Client using Group OSCORE 841 [I-D.ietf-core-oscore-groupcomm]. Additionally, for every incoming 842 request, if Group OSCORE verification succeeds, the verification of 843 access rights is performed as described in Section 4.4. 845 After the expiration of the Access Token related to a Group OSCORE 846 Security Context, if the Client uses the Group OSCORE Security 847 Context to send a request for any resource intended for OSCORE group 848 members and that requires an active Access Token, the RS MUST respond 849 with a 4.01 (Unauthorized) error message protected with the Group 850 OSCORE Security Context. 852 4.4. Access Rights Verification 854 The RS MUST follow the procedures defined in Section 5.8.2 of 855 [I-D.ietf-ace-oauth-authz]. If an RS receives a Group OSCORE- 856 protected request from a Client, the RS processes it according to 857 [I-D.ietf-core-oscore-groupcomm]. 859 If the Group OSCORE verification succeeds, and the target resource 860 requires authorization, the RS retrieves the authorization 861 information from the Access Token associated to the Group OSCORE 862 Security Context. Then, the RS MUST verify that the action requested 863 on the resource is authorized. 865 The response code MUST be 4.01 (Unauthorized) in case the Client has 866 not used the Group OSCORE Security Context associated with the Access 867 Token, or if the RS has no valid Access Token for the Client. If the 868 RS has an Access Token for the Client but no actions are authorized 869 on the target resource, the RS MUST reject the request with a 4.03 870 (Forbidden). If the RS has an Access Token for the Client but the 871 requested action is not authorized, the RS MUST reject the request 872 with a 4.05 (Method Not Allowed). 874 5. Secure Communication with the AS 876 As specified in the ACE framework (Section 5.7 of 877 [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or Client) 878 and the AS communicate via the /introspection or /token endpoint. 879 The use of CoAP and OSCORE for this communication is RECOMMENDED in 880 this profile. Other protocols (such as HTTP and DTLS or TLS) MAY be 881 used instead. 883 If OSCORE is used, the requesting entity and the AS are expected to 884 have pre-established security contexts in place. How these security 885 contexts are established is out of the scope of this profile. 886 Furthermore the requesting entity and the AS communicate using OSCORE 887 ([RFC8613]) through the /introspection endpoint as specified in 888 Section 5.7 of [I-D.ietf-ace-oauth-authz], and through the /token 889 endpoint as specified in Section 5.6 of [I-D.ietf-ace-oauth-authz]. 891 6. Discarding the Security Context 893 As members of an OSCORE Group, the Client and the RS may 894 independently leave the group or be forced to, e.g. if compromised or 895 suspected so. Upon leaving the OSCORE group, the Client or RS also 896 discards the Group OSCORE Security Context, which may anyway be 897 renewed by the Group Manager through a group rekeying process (see 898 Section 3.1 of [I-D.ietf-core-oscore-groupcomm]). 900 The Client or RS can acquire a new Group OSCORE Security Context, by 901 re-joining the OSCORE group, e.g. by using the approach defined in 902 [I-D.ietf-ace-key-groupcomm-oscore]. In such a case, the Client 903 SHOULD request a new Access Token and post it to the RS. 905 7. CBOR Mappings 907 The new parameters defined in this document MUST be mapped to CBOR 908 types as specified in Figure 6, using the given integer abbreviation 909 for the map key. 911 /--------------------+----------+------------\ 912 | Parameter name | CBOR Key | Value Type | 913 |--------------------+----------+------------| 914 | context_id | TBD1 | bstr | 915 | salt_input | TBD2 | bstr | 916 | client_cred_verify | TBD3 | bstr | 917 \--------------------+----------+------------/ 919 Figure 6: CBOR mappings for new parameters. 921 The new claims defined in this document MUST be mapped to CBOR types 922 as specified in Figure 7, using the given integer abbreviation for 923 the map key. 925 /-----------------+----------+------------\ 926 | Claim name | CBOR Key | Value Type | 927 |-----------------+----------+------------| 928 | salt_input | TBD4 | bstr | 929 | contextId_input | TBD5 | bstr | 930 \-----------------+----------+------------/ 932 Figure 7: CBOR mappings for new claims. 934 8. Security Considerations 936 This document specifies a profile for the Authentication and 937 Authorization for Constrained Environments (ACE) framework 938 [I-D.ietf-ace-oauth-authz]. Thus the general security considerations 939 from the ACE framework also apply to this profile. 941 This specification inherits the general security considerations about 942 Group OSCORE [I-D.ietf-core-oscore-groupcomm], as to the specific use 943 of Group OSCORE according to this profile. 945 Group OSCORE is designed to secure point-to-point as well as point- 946 to-multipoint communications, providing a secure binding between a 947 single request and multiple corresponding responses. In particular, 948 Group OSCORE fulfills the same security requirements of OSCORE, for 949 group requests and responses. 951 Group OSCORE ensures source authentication of messages both in group 952 mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]) and in 953 pairwise mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). 955 When protecting an outgoing message in group mode, the sender uses 956 its private key to compute a digital countersignature, which is 957 embedded in the protected message. The group mode can be used to 958 protect messages sent over multicast to multiple recipients, or sent 959 over unicast to one recipient. 961 When protecting an outgoing message in pairwise mode, the sender uses 962 a pairwise symmetric key, as derived from the asymmetric keys of the 963 two peers exchanging the message. The pairwise mode can be used to 964 protect only messages sent over unicast to one recipient. 966 9. Privacy Considerations 968 This document specifies a profile for the Authentication and 969 Authorization for Constrained Environments (ACE) framework 970 [I-D.ietf-ace-oauth-authz]. Thus the general privacy considerations 971 from the ACE framework also apply to this profile. 973 As this profile uses Group OSCORE, the privacy considerations from 974 [I-D.ietf-core-oscore-groupcomm] apply to this document as well. 976 An unprotected response to an unauthorized request may disclose 977 information about the RS and/or its existing relationship with the 978 Client. It is advisable to include as little information as possible 979 in an unencrypted response. However, since both the Client and the 980 RS share a Group OSCORE Security Context, unauthorized, yet protected 981 requests are followed by protected responses, which can thus include 982 more detailed information. 984 Although encrypted, the Access Token is sent in the clear to the 985 /authz-info endpoint at the RS. Thus, if the Client uses the same 986 single Access Token from multiple locations with multiple Resource 987 Servers, it can risk being tracked through the Access Token's value. 989 Note that, even though communications are protected with Group 990 OSCORE, some information might still leak, due to the observable 991 size, source address and destination address of exchanged messages. 993 10. IANA Considerations 995 This document has the following actions for IANA. 997 10.1. ACE Profile Registry 999 IANA is asked to enter the following value into the "ACE Profile" 1000 Registry defined in Section 8.8 of [I-D.ietf-ace-oauth-authz]. 1002 o Profile name: coap_group_oscore 1004 o Profile Description: Profile to secure communications between 1005 constrained nodes using the Authentication and Authorization for 1006 Constrained Environments framework, by enabling authentication and 1007 fine-grained authorization of members of an OSCORE group, that use 1008 a pre-established Group OSCORE Security Context to communicate 1009 with Group OSCORE. Optionally, the dual mode defined in 1010 Appendix A additionally establishes a Pairwise OSCORE Security 1011 Context, and thus also enables OSCORE communication between two 1012 members of the OSCORE group. 1014 o Profile ID: TBD (value between 1 and 255) 1016 o Change Controller: IESG 1018 o Specification Document(s): [[this document]] 1020 10.2. OAuth Parameters Registry 1022 IANA is asked to enter the following values into the "OAuth 1023 Parameters" Registry defined in Section 11.2 of [RFC6749]. 1025 o Name: "context_id" 1027 o Parameter Usage Location: token request 1029 o Change Controller: IESG 1031 o Reference: Section 3.1.1 of [[this document]] 1033 o Name: "salt_input" 1035 o Parameter Usage Location: token request 1037 o Change Controller: IESG 1039 o Reference: Section 3.1.2 of [[this document]] 1040 o Name: "client_cred_verify" 1042 o Parameter Usage Location: token request 1044 o Change Controller: IESG 1046 o Reference: Section 3.1.3 of [[this document]] 1048 o Name: "client_cred" 1050 o Parameter Usage Location: token request 1052 o Change Controller: IESG 1054 o Reference: Appendix A.2.1.1 of [[this document]] 1056 10.3. OAuth Parameters CBOR Mappings Registry 1058 IANA is asked to enter the following values into the "OAuth 1059 Parameters CBOR Mappings" Registry defined in Section 8.10 of 1060 [I-D.ietf-ace-oauth-authz]. 1062 o Name: "context_id" 1064 o CBOR Key: TBD1 1066 o Change Controller: IESG 1068 o Reference: Section 3.1.1 of [[this document]] 1070 o Name: "salt_input" 1072 o CBOR Key: TBD2 1074 o Change Controller: IESG 1076 o Reference: Section 3.1.2 of [[this document]] 1078 o Name: "client_cred_verify" 1080 o CBOR Key: TBD3 1082 o Change Controller: IESG 1084 o Reference: Section 3.1.3 of [[this document]] 1085 o Name: "client_cred" 1087 o CBOR Key: TBD6 1089 o Change Controller: IESG 1091 o Reference: Appendix A.2.1.1 of [[this document]] 1093 10.4. CBOR Web Token Claims Registry 1095 IANA is asked to enter the following values into the "CBOR Web Token 1096 Claims" Registry defined in Section 9.1 of [RFC8392]. 1098 o Claim Name: "salt_input" 1100 o Claim Description: Client provided salt input 1102 o JWT Claim Name: "N/A" 1104 o Claim Key: TBD4 1106 o Claim Value Type(s): bstr 1108 o Change Controller: IESG 1110 o Specification Document(s): Section 3.2.1 of [[this document]] 1112 o Claim Name: "contextId_input" 1114 o Claim Description: Client context id input 1116 o JWT Claim Name: "N/A" 1118 o Claim Key: TBD5 1120 o Claim Value Type(s): bstr 1122 o Change Controller: IESG 1124 o Specification Document(s): Section 3.2.2 of [[this document]] 1126 o Claim Name: "client_cred" 1128 o Claim Description: Client Credential 1130 o JWT Claim Name: "N/A" 1131 o Claim Key: TBD7 1133 o Claim Value Type(s): map 1135 o Change Controller: IESG 1137 o Specification Document(s): Appendix A.2.2.2 of [[this document]] 1139 10.5. TLS Exporter Label Registry 1141 IANA is asked to register the following entry in the "TLS Exporter 1142 Label" Registry defined in Section 6 of [RFC5705] and updated in 1143 Section 12 of [RFC8447]. 1145 o Value: EXPORTER-ACE-Sign-Challenge-Client-AS 1147 o DTLS-OK: Y 1149 o Recommended: N 1151 o Reference: [[this document]] (Section 3.1) 1153 11. References 1155 11.1. Normative References 1157 [I-D.ietf-ace-key-groupcomm-oscore] 1158 Tiloca, M., Park, J., and F. Palombini, "Key Management 1159 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1160 oscore-08 (work in progress), July 2020. 1162 [I-D.ietf-ace-oauth-authz] 1163 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1164 H. Tschofenig, "Authentication and Authorization for 1165 Constrained Environments (ACE) using the OAuth 2.0 1166 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 1167 (work in progress), June 2020. 1169 [I-D.ietf-ace-oauth-params] 1170 Seitz, L., "Additional OAuth Parameters for Authorization 1171 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 1172 params-13 (work in progress), April 2020. 1174 [I-D.ietf-ace-oscore-profile] 1175 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1176 "OSCORE profile of the Authentication and Authorization 1177 for Constrained Environments Framework", draft-ietf-ace- 1178 oscore-profile-11 (work in progress), June 2020. 1180 [I-D.ietf-core-groupcomm-bis] 1181 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1182 for the Constrained Application Protocol (CoAP)", draft- 1183 ietf-core-groupcomm-bis-00 (work in progress), March 2020. 1185 [I-D.ietf-core-oscore-groupcomm] 1186 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1187 "Group OSCORE - Secure Group Communication for CoAP", 1188 draft-ietf-core-oscore-groupcomm-09 (work in progress), 1189 June 2020. 1191 [I-D.ietf-cose-rfc8152bis-algs] 1192 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1193 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-11 1194 (work in progress), July 2020. 1196 [I-D.ietf-cose-rfc8152bis-struct] 1197 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1198 Structures and Process", draft-ietf-cose-rfc8152bis- 1199 struct-11 (work in progress), July 2020. 1201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1202 Requirement Levels", BCP 14, RFC 2119, 1203 DOI 10.17487/RFC2119, March 1997, 1204 . 1206 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1207 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1208 March 2010, . 1210 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1211 Key Derivation Function (HKDF)", RFC 5869, 1212 DOI 10.17487/RFC5869, May 2010, 1213 . 1215 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1216 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1217 . 1219 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1220 Keranen, A., and P. Hallam-Baker, "Naming Things with 1221 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1222 . 1224 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1225 Application Protocol (CoAP)", RFC 7252, 1226 DOI 10.17487/RFC7252, June 2014, 1227 . 1229 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1230 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1231 May 2017, . 1233 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1234 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1235 May 2018, . 1237 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1238 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1239 . 1241 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1242 Definition Language (CDDL): A Notational Convention to 1243 Express Concise Binary Object Representation (CBOR) and 1244 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1245 June 2019, . 1247 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1248 "Object Security for Constrained RESTful Environments 1249 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1250 . 1252 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1253 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1254 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 1255 2020, . 1257 11.2. Informative References 1259 [I-D.ietf-ace-dtls-authorize] 1260 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1261 L. Seitz, "Datagram Transport Layer Security (DTLS) 1262 Profile for Authentication and Authorization for 1263 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1264 authorize-12 (work in progress), July 2020. 1266 [I-D.ietf-ace-mqtt-tls-profile] 1267 Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile 1268 of ACE", draft-ietf-ace-mqtt-tls-profile-05 (work in 1269 progress), May 2020. 1271 [I-D.ietf-tls-dtls13] 1272 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1273 Datagram Transport Layer Security (DTLS) Protocol Version 1274 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 1275 2020. 1277 [I-D.tiloca-core-oscore-discovery] 1278 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1279 Groups with the CoRE Resource Directory", draft-tiloca- 1280 core-oscore-discovery-05 (work in progress), March 2020. 1282 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1283 (TLS) Protocol Version 1.2", RFC 5246, 1284 DOI 10.17487/RFC5246, August 2008, 1285 . 1287 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1288 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1289 January 2012, . 1291 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1292 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1293 . 1295 Appendix A. Dual Mode (Group OSCORE & OSCORE) 1297 This appendix defines the dual mode of this profile, which allows 1298 using both OSCORE [RFC8613] and Group OSCORE 1299 [I-D.ietf-core-oscore-groupcomm] as security protocols, by still 1300 relying on a single Access Token. 1302 That is, the dual mode of this profile specifies how a Client uses 1303 CoAP [RFC7252] to communicate to a single Resource Server, or CoAP 1304 over IP multicast [I-D.ietf-core-groupcomm-bis] to communicate to 1305 multiple Resource Servers that are members of a group and share a 1306 common set of resources. 1308 In particular, the dual mode of this profile uses two complementary 1309 security protocols to provide secure communication between the Client 1310 and the Resource Server(s). That is, it defines the use of either 1311 OSCORE or Group OSCORE to protect unicast requests addressed to a 1312 single Resource Server, as well as possible responses. Additionally, 1313 it defines the use of Group OSCORE to protect multicast requests sent 1314 to a group of Resource Servers, as well as possible individual 1315 responses. As for the main mode of this profile, the Client and the 1316 Resource Servers need to have already joined an OSCORE group, for 1317 instance by using the approach defined in 1318 [I-D.ietf-ace-key-groupcomm-oscore], which is also based on ACE. 1320 The Client authorizes its access to the Resource Server by using an 1321 Access Token, which is bound to a key (the proof-of-possession key). 1322 This profile mode uses OSCORE to achieve proof of possession, and 1323 OSCORE or Group OSCORE to achieve server authentication. 1325 Unlike in the main mode of this profile, where a public key is used 1326 as pop-key, this dual mode uses OSCORE-related, symmetric key 1327 material as pop-key instead. Furthermore, this dual mode provides 1328 proof of Client's membership to the correct OSCORE group, by securely 1329 binding the pre-established Group OSCORE Security Context to the 1330 pairwise OSCORE Security Context newly established between the Client 1331 and the Resource Server. 1333 In addition to the terminology used for the main mode of this 1334 profile, the rest of this appendix refers also to "pairwise OSCORE 1335 Security Context" as to an OSCORE Security Context established 1336 between only one Client and one Resource Server, and used to 1337 communicate with OSCORE [RFC8613]. 1339 A.1. Protocol Overview 1341 This section provides an overview on how to use the ACE framework for 1342 authentication and authorization [I-D.ietf-ace-oauth-authz] to secure 1343 communications between a Client and a (set of) Resource Server(s) 1344 using OSCORE [RFC8613] and/or Group OSCORE 1345 [I-D.ietf-core-oscore-groupcomm]. 1347 Just as for main mode of this profile overviewed in Section 2, the 1348 process for joining the OSCORE group through the respective Group 1349 Manager as defined in [I-D.ietf-ace-key-groupcomm-oscore] must take 1350 place before the process described in the rest of this section, and 1351 is out of the scope of this profile. 1353 An overview of the protocol flow for the dual mode of this profile is 1354 shown in Figure 8. In the figure, it is assumed that both RS1 and 1355 RS2 are associated with the same AS. It is also assumed that C, RS1 1356 and RS2 have previously joined an OSCORE group with Group Identifier 1357 (gid) "abcd0000", and got assigned Sender ID (sid) "0", "1" and "2" 1358 in the group, respectively. 1360 C RS1 RS2 AS 1361 | [--- Resource Request --->] | | | 1362 | | | | 1363 | [<--- AS Information -----] | | | 1364 | | | | 1365 |-------- POST /token ------------------------------------------------>| 1366 | (aud: RS1, sid: 0, gid: abcd0000, ...) | | 1367 | | | | 1368 |<--------------------------------- Access Token + RS Information -----| 1369 | | (aud: RS1, sid: 0, gid: abcd0000, ...) | 1370 |---- POST /authz-info ------>| | | 1371 | (access_token, N1) | | | 1372 | | | | 1373 |<--- 2.01 Created (N2) ------| | | 1374 | | | | 1375 /Pairwise OSCORE Sec /Pairwise OSCORE Sec | | 1376 Context Derivation/ Context Derivation/ | | 1377 | | | | 1378 |-------- POST /token ------------------------------------------------>| 1379 | (aud: RS2, sid: 0, gid: abcd0000, ...) | | 1380 | | | | 1381 |<--------------------------------- Access Token + RS Information -----| 1382 | | (aud: RS2, sid: 0, gid: abcd0000, ...) | 1383 | | | | 1384 |----- POST /authz-info ------------------>| | 1385 | (access_token, N1') | | | 1386 | | | | 1387 |<--- 2.01 Created (N2') ------------------| | 1388 | | | | 1389 /Pairwise OSCORE Sec | /Pairwise OSCORE Sec | 1390 Context Derivation/ | Context Derivation/ | 1391 | | | | 1392 |------ OSCORE Request ------>| | | 1393 | ?(abcd0000, N1, N2) | | | 1394 | | | | 1395 |<----- OSCORE Response ------| | | 1396 | | | | 1397 |-- Group OSCORE Request -+-->| | | 1398 | (kid: 0, gid: abcd0000) \-------------->| | 1399 | | | | 1400 |<--- Group OSCORE Response --| | | 1401 | (kid: 1) | | | 1402 | | | | 1403 |<--- Group OSCORE Response ---------------| | 1404 | (kid: 2) | | | 1405 | ... | | | 1407 Figure 8: Protocol Overview. 1409 A.1.1. Pre-Conditions 1411 The same pre-conditions for the main mode of this profile (see 1412 Section 2.1) hold for the dual mode described in this appendix. 1414 A.1.2. Access Token Posting 1416 After having retrieved the Access Token from the AS, the Client 1417 generates a nonce N1 and posts both the Access Token and N1 to the 1418 RS, using the /authz-info endpoint and mechanisms specified in 1419 Section 5.8 of [I-D.ietf-ace-oauth-authz] and Content-Format = 1420 application/ace+cbor. 1422 If the Access Token is valid, the RS replies to this POST request 1423 with a 2.01 (Created) response with Content-Format = application/ 1424 ace+cbor, which contains a nonce N2 in a CBOR map. 1426 A.1.3. Setup of the Pairwise OSCORE Security Context 1428 After sending the 2.01 (Created) response, the RS sets the ID Context 1429 of the pairwise OSCORE Security Context (see Section 3 of [RFC8613]) 1430 to the Group Identifier of the OSCORE group specified in the Access 1431 Token, concatenated with N1, concatenated with N2, concatenated with 1432 the value in the contextId parameter of the OSCORE_Security_Context 1433 object provided in the 'cnf' claim of the Access Token. 1435 Then, the RS derives the complete pairwise OSCORE Security Context 1436 associated with the received Access Token, following Section 3.2 of 1437 [RFC8613]. In practice, the RS maintains a collection of Security 1438 Contexts with associated authorization information, for all the 1439 clients that it is currently communicating with, and the 1440 authorization information is a policy used as input when processing 1441 requests from those clients. 1443 During the derivation process, the RS uses the ID Context above, the 1444 nonces N1 and N2, and the parameters in the Access Token. The 1445 derivation process uses also the Master Secret of the OSCORE group, 1446 that the RS knows as a group member, as well as the Sender ID of the 1447 Client in the OSCORE group, which is specified in the Access Token. 1448 This ensures that the pairwise OSCORE Security Context is securely 1449 bound to the Group OSCORE Security Context of the OSCORE group. 1451 Finally, the RS stores the association between i) the authorization 1452 information from the Access Token; and ii) the Group Identifier of 1453 the OSCORE group together with the Sender ID and the public key of 1454 the Client in that group. 1456 After having received the nonce N2, the Client sets the ID Context in 1457 its pairwise OSCORE Security Context (see Section 3 of [RFC8613]) to 1458 the Group Identifier of the OSCORE group concatenated with N1 1459 concatenated with N2, concatenated with the value in the contextId 1460 parameter of the OSCORE_Security_Context object provided in the 'cnf' 1461 parameter of the Access Token response from the AS. Then, the Client 1462 derives the complete pairwise OSCORE Security Context, following 1463 Section 3.2 of [RFC8613]. During the derivation process, the Client 1464 uses the ID Context above, the nonces N1 and N2, plus the parameters 1465 received from the AS. The derivation process uses also the Master 1466 Secret of the OSCORE group, that the Client knows as a group member, 1467 as well as its own Sender ID in the OSCORE group. 1469 When the Client communicates with the RS using the pairwise OSCORE 1470 Security Context, the RS achieves proof-of-possession of the 1471 credentials bound to the Access Token. Also, the RS verifies that 1472 the Client is a legitimate member of the OSCORE group. 1474 A.1.4. Secure Communication 1476 The Client can send a request protected with OSCORE to the RS. This 1477 message may contain the ID Context value of the pairwise OSCORE 1478 Context, whose generation is described in Appendix A.1.3. 1480 If the request is correctly verified, then the RS stores the pairwise 1481 OSCORE Security Context, and uses it to protect the possible 1482 response, as well as further communications with the Client, until 1483 the Access Token expires. This pairwise OSCORE Security Context is 1484 discarded if the same Access Token is re-used to successfully derive 1485 a new pairwise OSCORE Security Context. Once the Client has received 1486 a valid secure response, it does not continue to include the ID 1487 Context value in following requests. 1489 As discussed in Section 2 of [I-D.ietf-ace-oscore-profile], the use 1490 of random nonces N1 and N2 during the exchange between the Client and 1491 the RS prevents the reuse of AEAD nonces and keys with different 1492 messages, in case of re-derivation of the pairwise OSCORE Security 1493 Context both for Clients and Resource Servers from an old non-expired 1494 Access Token, e.g. in case of reboot of either the Client or the RS. 1496 Additionally, just as per the main mode of this profile (see 1497 Section 4.3), the Client and RS can also securely communicate by 1498 protecting messages with Group OSCORE, using the Group OSCORE 1499 Security Context already established upon joining the OSCORE group. 1501 A.2. Client-AS Communication 1503 This section details the Access Token POST Request that the Client 1504 sends to the /token endpoint of the AS, as well as the related Access 1505 Token response. 1507 Section 3.2 of [RFC8613] defines how to derive a pairwise OSCORE 1508 Security Context based on a shared Master Secret and a set of other 1509 parameters, established between the OSCORE client and server. 1511 The Client receives these pieces of information from the AS during 1512 the exchange described in this section. In particular, the proof-of- 1513 possession key (pop-key) provisioned by the AS MUST be used to build 1514 the Master Secret in OSCORE (see Appendix A.3.3 and Appendix A.3.4). 1516 A.2.1. C-to-AS: POST to Token Endpoint 1518 The Client-to-AS request is specified in Section 5.6.1 of 1519 [I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request 1520 to the /token endpoint over a secure channel that guarantees 1521 authentication, message integrity and confidentiality. 1523 The POST request is formatted as the analogous Client-to-AS request 1524 in the main mode of this profile (see Section 3.1), with the 1525 following modifications. 1527 o The parameter 'req_cnf' MUST NOT be included in the payload. 1529 o The parameter 'client_cred', defined in Appendix A.2.1.1 of this 1530 specification, MUST be included in the payload. This parameter 1531 includes the public key associated to the signing private key that 1532 the Client uses in the OSCORE group, whose identifier is indicated 1533 in the 'context_id' parameter. 1535 o The signature included in the parameter 'client_cred_verify' is 1536 computed by using the private key associated to the public key in 1537 the 'client_cred' parameter above. 1539 An example of such a request, with payload in CBOR diagnostic 1540 notation without the tag and value abbreviations is reported in 1541 Figure 9. 1543 Header: POST (Code=0.02) 1544 Uri-Host: "as.example.com" 1545 Uri-Path: "token" 1546 Content-Format: "application/ace+cbor" 1547 Payload: 1548 { 1549 "audience" : "tempSensor4711", 1550 "scope" : "read", 1551 "context_id" : h'abcd0000', 1552 "salt_input" : h'00', 1553 "client_cred" : { 1554 "COSE_Key" : { 1555 "kty" : EC2, 1556 "crv" : P-256, 1557 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 1558 27c9e354089bbe13', 1559 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 1560 731e79a3b4e47120' 1561 } 1562 }, 1563 "client_cred_verify" : h'...' 1564 (signature content omitted for brevity), 1565 } 1567 Figure 9: Example C-to-AS POST /token request for an Access Token 1568 bound to a symmetric key. 1570 Later on, the Client may want to update its current access rights, 1571 without changing the existing pairwise OSCORE Security Context with 1572 the RS. In this case, the Client MUST include in its POST request to 1573 the /token endpoint a 'req_cnf' parameter, defined in Section 3.1 of 1574 [I-D.ietf-ace-oauth-params], which MUST include a 'kid' field, as 1575 defined in Section 3.1 of [RFC8747]. The 'kid' field has as value a 1576 CBOR byte string encoding a CBOR array, which includes: 1578 o As first element, the value of the 'clientId' parameter in the 1579 OSCORE_Security_Context object specified in the 'cnf' parameter, 1580 in the original AS-to-C Access Token response (see 1581 Appendix A.2.2). 1583 o Optionally, as second element, the value of the 'contextId' 1584 parameter in the OSCORE_Security_Context object specified in the 1585 'cnf' parameter, in the original AS-to-C Access Token response 1586 (see Appendix A.2.2). 1588 The CBOR array is defined in Figure 10, and follows the notation of 1589 [RFC8610]. 1591 These identifiers, together with other information such as audience, 1592 can be used by the AS to determine the shared secret bound to the 1593 proof-of-possession Access Token, and therefore MUST identify a 1594 symmetric key that was previously generated by the AS as a shared 1595 secret for the communication between the Client and the RS. The AS 1596 MUST verify that the received value identifies a proof-of-possession 1597 key that has previously been issued to the requesting client. If 1598 that is not the case, the Client-to-AS request MUST be declined with 1599 the error code 'invalid_request' as defined in Section 5.6.3 of 1600 [I-D.ietf-ace-oauth-authz]. 1602 This POST request for updating the rights of an Access Token MUST NOT 1603 include the parameters 'salt_input', 'context_id', 'client_cred' and 1604 'client_cred_verify'. 1606 kid_arr = [ 1607 clientId, 1608 ?IdContext 1609 ] 1611 kid = bstr .cbor kid_arr 1613 Figure 10: CDDL Notation of kid for Update of Access Rights 1615 An example of such a request, with payload in CBOR diagnostic 1616 notation without the tag and value abbreviations is reported in 1617 Figure 11. In particular: '<< X >>' denotes a CBOR byte string with 1618 string value X; "myclient" stands for the value of the 'clientId' 1619 parameter mentioned above; and "contextid" stands for the value of 1620 the 'contextId' parameter mentioned above. 1622 Header: POST (Code=0.02) 1623 Uri-Host: "as.example.com" 1624 Uri-Path: "token" 1625 Content-Format: "application/ace+cbor" 1626 Payload: 1627 { 1628 "audience" : "tempSensor4711", 1629 "scope" : "read", 1630 "req_cnf" : { 1631 "kid" : << ["myclient","contextid"] >> 1632 } 1633 } 1635 Figure 11: Example C-to-AS POST /token request for updating rights to 1636 an Access Token bound to a symmetric key. 1638 A.2.1.1. 'client_cred' Parameter 1640 The 'client_cred' parameter is an OPTIONAL parameter of the Access 1641 Token request message defined in Section 5.6.1. of 1642 [I-D.ietf-ace-oauth-authz]. This parameter provides an asymmetric 1643 key that the Client wishes to use as its own public key, but which is 1644 not used as proof-of-possession key. 1646 This parameter follows the syntax of the 'cnf' claim from Section 3.1 1647 of [RFC8747] when including Value Type "COSE_Key" (1) and specifying 1648 an asymmetric key. Alternative Value Types defined in future 1649 specifications are fine to consider if indicating a non-encrypted 1650 asymmetric key. 1652 A.2.2. AS-to-C: Access Token 1654 After having verified the POST request to the /token endpoint and 1655 that the Client is authorized to obtain an Access Token corresponding 1656 to its Access Token request, the AS MUST verify the signature in the 1657 'client_cred_verify' parameter, by using the public key specified in 1658 the 'client_cred' parameter. If the verification fails, the AS 1659 considers the Client request invalid. The AS does not perform this 1660 operation when asked to update a previously released Access Token. 1662 If all verifications are successful, the AS responds as defined in 1663 Section 5.6.2 of [I-D.ietf-ace-oauth-authz]. If the Client request 1664 was invalid, or not authorized, the AS returns an error response as 1665 described in Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. 1667 The AS can signal that the use of OSCORE and Group OSCORE is REQUIRED 1668 for a specific Access Token by including the 'profile' parameter with 1669 the value "coap_group_oscore" in the Access Token response. This 1670 means that the Client MUST use OSCORE and/or Group OSCORE towards all 1671 the Resource Servers for which this Access Token is valid. 1673 In particular, the Client MUST follow Appendix A.3.3 to derive the 1674 pairwise OSCORE Security Context to use for communications with the 1675 RS. Instead, the Client has already established the related Group 1676 OSCORE Security Context to communicate with members of the OSCORE 1677 group, upon previously joining that group. 1679 Usually, it is assumed that constrained devices will be pre- 1680 configured with the necessary profile, so that this kind of profile 1681 negotiation can be omitted. 1683 In contrast with the main mode of this profile, the Access Token 1684 response to the Client is analogous to the one in the OSCORE profile 1685 of ACE, as described in Section 3.2 of [I-D.ietf-ace-oscore-profile]. 1687 In particular, the AS provides an OSCORE_Security_Context object, 1688 which is defined in Section 3.2.1 of [I-D.ietf-ace-oscore-profile] 1689 and included in the 'cnf' parameter (see Section 3.2 of 1690 [I-D.ietf-ace-oauth-params]) of the Access Token response. 1692 In the issued Access Token, the AS MUST include as metadata the same 1693 information as defined in the main mode of this profile (see 1694 Section 3.2) with the following modifications. 1696 o The public key that the client uses in the OSCORE group and 1697 specified in the 'client_cred' parameter of the Token request (see 1698 Appendix A.2.1) MUST also be included in the Access Token. If the 1699 Access Token is a CWT, the AS MUST include it in the 'client_cred' 1700 claim of the Access Token, defined in Appendix A.2.2.2 of this 1701 specification. 1703 o The OSCORE_Security_Context object specified in the 'cnf' 1704 parameter of the Access Token response MUST also be included in 1705 the Access Token. If the Access Token is a CWT, the same 1706 OSCORE_Security_Context object included in the 'cnf' parameter of 1707 the Access Token response MUST be included in the 'osc' field (see 1708 Section 9.5 of [I-D.ietf-ace-oscore-profile]) of the 'cnf' claim 1709 of the Access Token. 1711 Figure 12 shows an example of such an AS response, with payload in 1712 CBOR diagnostic notation without the tag and value abbreviations. 1714 Header: Created (Code=2.01) 1715 Content-Type: "application/ace+cbor" 1716 Payload: 1717 { 1718 "access_token" : h'a5037674656d7053656e73 ...' 1719 (remainder of CWT omitted for brevity), 1720 "profile" : "coap_group_oscore", 1721 "expires_in" : 3600, 1722 "cnf" : { 1723 "osc" : { 1724 "alg" : "AES-CCM-16-64-128", 1725 "clientId" : h'a8', 1726 "serverId" : h'42', 1727 "ms" : h'f9af838368e353e78888e1426bd94e6f', 1728 "salt" : h'1122', 1729 "contextId" : h'99' 1730 } 1731 } 1732 } 1734 Figure 12: Example AS-to-C Access Token response with the Group 1735 OSCORE profile. 1737 Figure 13 shows an example CWT, containing the necessary OSCORE 1738 parameters in the 'cnf' claim, in CBOR diagnostic notation without 1739 tag and value abbreviations. 1741 { 1742 "aud" : "tempSensorInLivingRoom", 1743 "iat" : "1360189224", 1744 "exp" : "1360289224", 1745 "scope" : "temperature_g firmware_p", 1746 "cnf" : { 1747 "osc" : { 1748 "alg" : "AES-CCM-16-64-128", 1749 "clientId" : h'00', 1750 "serverId" : h'01', 1751 "ms" : h'f9af838368e353e78888e1426bd94e6f', 1752 "salt" : h'1122', 1753 "contextId" : h'99' 1754 }, 1755 "salt_input" : h'00', 1756 "contextId_input" : h'abcd0000', 1757 "client_cred" : { 1758 "COSE_Key" : { 1759 "kty" : EC2, 1760 "crv" : P-256, 1761 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 1762 27c9e354089bbe13', 1763 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 1764 731e79a3b4e47120' 1765 } 1766 } 1767 } 1769 Figure 13: Example CWT with OSCORE parameters (CBOR diagnostic 1770 notation). 1772 The same CWT as in Figure 13 and encoded in CBOR is shown in 1773 Figure 14, using the value abbreviations defined in 1774 [I-D.ietf-ace-oauth-authz] and [RFC8747], and with 12 as value 1775 abbreviation for the 'client_cred' claim. 1777 NOTE: it should be checked (and in case fixed) that the values used 1778 below (which are not yet registered) are the final values registered 1779 in IANA. 1781 A8 # map(8) 1782 03 # unsigned(3) 1783 76 # text(22) 1784 74656D7053656E736F72496E4C6976696E67526F6F6D 1785 06 # unsigned(6) 1786 1A 5112D728 # unsigned(1360189224) 1787 04 # unsigned(4) 1788 1A 51145DC8 # unsigned(1360289224) 1789 09 # unsigned(9) 1790 78 18 # text(24) 1791 74656D70657261747572655F67206669726D776172655F70 1792 08 # unsigned(8) 1793 A1 # map(1) 1794 04 # unsigned(4) 1795 A6 # map(6) 1796 05 # unsigned(5) 1797 0A # unsigned(10) 1798 02 # unsigned(2) 1799 41 # bytes(1) 1800 00 1801 03 # unsigned(3) 1802 41 # bytes(1) 1803 01 1804 01 # unsigned(1) 1805 50 # bytes(16) 1806 F9AF838368E353E78888E1426BD94E6F 1807 06 # unsigned(6) 1808 42 # bytes(2) 1809 1122 1810 07 # unsigned(7) 1811 41 # bytes(1) 1812 99 1813 18 3C # unsigned(60) 1814 41 # bytes(1) 1815 00 1816 18 3D # unsigned(61) 1817 44 # bytes(4) 1818 ABCD0000 1819 18 3E # unsigned(62) 1820 A1 # map(1) 1821 01 # unsigned(1) 1822 A4 # map(4) 1823 01 # unsigned(1) 1824 02 # unsigned(2) 1825 20 # negative(0) 1826 01 # unsigned(1) 1827 21 # negative(1) 1828 58 20 # bytes(32) 1829 D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9 1830 E354089BBE13 1831 22 # negative(2) 1832 58 20 # bytes(32) 1833 F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E515D020731E 1834 79A3B4E47120 1836 Figure 14: Example CWT with OSCORE parameters. 1838 If the client has requested an update to its access rights using the 1839 same pairwise OSCORE Security Context, which is valid and authorized, 1840 the AS MUST omit the 'cnf' parameter in the response to the client. 1842 Instead, the updated Access Token conveyed in the AS-to-C response 1843 MUST include a 'cnf' claim specifying a 'kid' field, as defined in 1844 Section 3.1 of [RFC8747]. The 'kid' field has as value a CBOR byte 1845 string, with value the same value of the 'req_cnf' parameter from the 1846 C-to-AS request for updating rights to the Access Token (see 1847 Figure 11). This information, i.e. the value of the 'clientId' and 1848 'contextId' parameters in Figure 11, needs to be included in the 1849 Access Token, in order for the RS to identify the previously 1850 generated pairwise OSCORE Security Context. 1852 Figure 15 shows an example of such an AS response, with payload in 1853 CBOR diagnostic notation without the tag and value abbreviations. 1854 The access token has been truncated for readability. 1856 Header: Created (Code=2.01) 1857 Content-Type: "application/ace+cbor" 1858 Payload: 1859 { 1860 "access_token" : h'a5037674656d7053656e73 ...' 1861 (remainder of CWT omitted for brevity), 1862 "profile" : "coap_group_oscore", 1863 "expires_in" : 3600 1864 } 1866 Figure 15: Example AS-to-C Access Token response with the Group 1867 OSCORE profile, for update of access rights. 1869 Figure 16 shows an example CWT, containing the necessary OSCORE 1870 parameters in the 'cnf' claim for update of access rights, in CBOR 1871 diagnostic notation without tag and value abbreviations. 1873 { 1874 "aud" : "tempSensorInLivingRoom", 1875 "iat" : "1360189224", 1876 "exp" : "1360289224", 1877 "scope" : "temperature_h", 1878 "cnf" : { 1879 "kid" : h'458241004199' 1880 } 1881 } 1883 Figure 16: Example CWT with OSCORE parameters for update of access 1884 rights. 1886 A.2.2.1. Public Key Hash as Client Credential 1888 As a possible optimization to limit the size of the Access Token, the 1889 AS may specify as value of the 'client_cred' claim simply the hash of 1890 the Client's public key. The specifically used hash-function MUST be 1891 collision-resistant on byte-strings, and MUST be selected from the 1892 "Named Information Hash Algorithm" Registry defined in Section 9.4 of 1893 [RFC6920]. 1895 In particular, the AS provides the Client with an Access Token as 1896 defined in Appendix A.2.2, with the following differences. 1898 The AS prepares INPUT_HASH as follows, with | denoting byte string 1899 concatenation. 1901 o If the public key has COSE Key Type OKP, INPUT_HASH = i, where 'i' 1902 is the x-parameter of the COSE_Key specified in the 'client_cred' 1903 parameter of the Token request. 1905 o If the public key has COSE Key Type EC2, INPUT_HASH = (i_1 | i_2), 1906 where 'i_1' and 'i_2' are the x-parameter and y-parameter of the 1907 COSE_Key specified in the 'client_cred' parameter of the Token 1908 request, respectively. 1910 o If the public key has COSE Key Type RSA, INPUT_HASH = (i_1 | i_2), 1911 where 'i_1' and 'i_2' are the n-parameter and e-parameter of the 1912 COSE_Key specified in the 'client_cred' parameter of the Token 1913 request. 1915 Then, the AS hashes INPUT_HASH according to the procedure described 1916 in [RFC6920], with the output OUTPUT_HASH in binary format, as 1917 described in Section 6 of [RFC6920]. 1919 Finally, the AS includes a single entry within the 'client_cred' 1920 claim of the Access Token. This entry has label "kid" (3) defined in 1921 Section 3.1 of [RFC8747], and has OUTPUT_HASH as value, encoded as 1922 CBOR byte string. 1924 Upon receiving the Access Token, the RS processes it according to 1925 Appendix A.3.2, with the following differences. 1927 The RS considers the content of the 'client_cred' claim as the hash 1928 of the public key associated to the signing private key that the 1929 Client uses in the OSCORE group, which is identified by the 1930 'context_id' parameter. 1932 The RS MAY additionally request the Group Manager of the OSCORE group 1933 for the public key of that Client, as described in 1935 [I-D.ietf-ace-key-groupcomm-oscore], specifying as Sender ID of that 1936 Client in the OSCORE group the value of the 'salt_input' claim 1937 included in the Access Token. 1939 In such a case, the RS MUST check that the hash of the key retrieved 1940 from the Group Manager matches the hash retrieved from the 1941 'client_cred' claim of the Access Token. The RS MUST calculate the 1942 hash using the same method as the AS, described above, and using the 1943 same hash function. The hash function used can be determined from 1944 the information conveyed in the 'client_cred' claim, as the procedure 1945 described in [RFC6920] also encodes the used hash function as 1946 metadata of the hash value. 1948 A.2.2.2. Client Credential Claim 1950 The 'client_cred' claim provides an asymmetric key that the Client 1951 owning the Access Token wishes to use as its own public key, but 1952 which is not used as proof-of-possession key. 1954 This parameter follows the syntax of the 'cnf' claim from Section 3.1 1955 of [RFC8747] when including Value Type "COSE_Key" (1) and specifying 1956 an asymmetric key. Alternative Value Types defined in future 1957 specifications are fine to consider if indicating a non-encrypted 1958 asymmetric key. 1960 A.3. Client-RS Communication 1962 This section details the POST request and response to the /authz-info 1963 endpoint between the Client and the RS. With respect to the 1964 exchanged messages and their content, the Client and the RS perform 1965 as defined in Section 4 of the OSCORE profile of ACE 1966 [I-D.ietf-ace-oscore-profile]. 1968 That is, the Client generates a nonce N1 and posts it to the RS, 1969 together with the Access Token that includes the material provisioned 1970 by the AS. Then, the RS generates a nonce N2, and derives a pairwise 1971 OSCORE Security Context as described Section 3.2 of [RFC8613]. In 1972 particular, it uses the two nonces established with the Client and 1973 two shared secrets, together with additional pieces of information 1974 specified in the Access Token. 1976 The proof-of-possession required to bind the Access Token to the 1977 Client is implicitly performed by generating the pairwise OSCORE 1978 Security Context using the pop-key as part of the OSCORE Master 1979 Secret, for both the Client and the RS. In addition, the derivation 1980 of the pairwise OSCORE Security Context takes as input also 1981 information related to the OSCORE group, i.e. the Master Secret and 1982 Group Identifier of the group, as well as the Sender ID of the Client 1983 in the group. Hence, the derived pairwise OSCORE Security Context is 1984 also securely bound to the Group OSCORE Security Context of the 1985 OSCORE Group. 1987 Therefore, an attacker using a stolen Access Token cannot generate a 1988 valid pairwise OSCORE Security Context and thus cannot prove 1989 possession of the pop-key. Also, if a Client legitimately owns an 1990 Access Token but has not joined the OSCORE group, that Client cannot 1991 generate a valid pairwise OSCORE Security Context either, since it 1992 lacks the Master Secret used in the OSCORE group. 1994 Besides, just as in the main mode (see Section 4), the RS is able to 1995 verify whether the Client has indeed the claimed Sender ID and public 1996 key in the OSCORE group. 1998 A.3.1. C-to-RS POST to authz-info Endpoint 2000 The Client MUST generate a nonce N1 and post it to the /authz-info 2001 endpoint of the RS together with the Access Token, as defined in 2002 Section 4.1 of the OSCORE profile of ACE 2003 [I-D.ietf-ace-oscore-profile]. 2005 The same recommendations, considerations and behaviors defined in 2006 Section 4.1 of [I-D.ietf-ace-oscore-profile] hold. 2008 A.3.2. RS-to-C: 2.01 (Created) 2010 The RS MUST verify the validity of the Access Token as defined in 2011 Section 4.2, with the following modifications. 2013 o The RS checks that the 'cnf' claim is included in the Access Token 2014 and that it contains an OSCORE_Security_Context object. 2016 o The RS checks that the 'client_cred' claim is included in the 2017 Access Token. 2019 o The RS considers the content of the 'client_cred' claim as the 2020 public key associated to the signing private key of the Client in 2021 the OSCORE group, whose GID is specified in the 'contextId_input' 2022 claim. The RS can compare this public key with the public key of 2023 the claimed Client retrieved from the Group Manager (see 2024 Section 4.2). 2026 If any of the checks fails, the RS MUST consider the Access Token non 2027 valid, and MUST respond to the Client with an error response code 2028 equivalent to the CoAP code 4.00 (Bad Request). 2030 If the Access Token is valid and further checks on its content are 2031 successful, the RS MUST generate a nonce N2 and include it in the 2032 2.01 (Created) response to the Client, as defined in Section 4.2 of 2033 the OSCORE profile of ACE [I-D.ietf-ace-oscore-profile]. 2035 Further recommendations, considerations and behaviors defined in 2036 Section 4.2 of [I-D.ietf-ace-oscore-profile] hold for this 2037 specification. 2039 A.3.3. OSCORE Setup - Client Side 2041 Once having received the 2.01 (Created) response from the RS, 2042 following the POST request to the authz-info endpoint, the Client 2043 MUST extract the nonce N2 from the 'nonce2' parameter and the client 2044 identifier from the 'clientId' parameter (if present) in the CBOR map 2045 in the payload of the response. 2047 Note that, if present in the 2.01 (Created) response, the 'clientId' 2048 parameter supersedes the analogous parameter possibly provided by the 2049 AS to C in Appendix A.2.2. Also, note that this identifier is used 2050 by C as Sender ID in the pairwise OSCORE Security Context to be 2051 established with the RS, and is different as well as unrelated to the 2052 Sender ID of C in the OSCORE group. 2054 Then, the Client performs the following actions, in order to set up 2055 and fully derive the pairwise OSCORE Security Context for 2056 communicating with the RS. 2058 o The Client MUST set the ID Context of the pairwise OSCORE Security 2059 Context as the concatenation of: i) GID, i.e. the Group Identifier 2060 of the OSCORE group, as specified by the Client in the 2061 'context_id' parameter of the Client-to-AS request; ii) the nonce 2062 N1; iii) the nonce N2; and iv) CID, i.e. the value in the 2063 contextId parameter of the OSCORE_Security_Context object provided 2064 in the 'cnf' parameter of the Access Token response from the AS. 2065 The concatenation occurs in this order: ID Context = GID | N1 | 2066 N2 | CID, where | denotes byte string concatenation. 2068 Note that, if the Client wishes to update its access rights as 2069 defined in Appendix A.2.1, the 'kid_arr' in Figure 10 for the C- 2070 to-AS request MUST be built as follows. The 'IdContext' element 2071 has as value the value of the 'contextId' parameter of the 2072 OSCORE_Security_Context object, as specified in the 'cnf' 2073 parameter of the original Access Token response from the AS. 2074 Since the client is aware of the sizes of N1, N2 and GID, it can 2075 retrieve this value as the CID component from the ID Context of 2076 the pairwise OSCORE Security Context as defined above, i.e. by 2077 considering only the appropriate amount of bytes from the end. 2079 o The Client MUST set the updated Master Salt of the pairwise OSCORE 2080 Security Context as the concatenation of SaltInput, MSalt, the 2081 nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the 2082 Sender ID that the Client has in the OSCORE group, which is known 2083 to the Client as a member of the OSCORE group; ii) MSalt is the 2084 (optional) Master Salt in the pairwise OSCORE Security Context; 2085 and iii) GMSalt is the (optional) Master Salt in the Group OSCORE 2086 Security Context, which is known to the Client as a member of the 2087 OSCORE group. The concatenation occurs in this order: Master Salt 2088 = SaltInput | MSalt | N1 | N2 | GMSalt, where | denotes byte 2089 string concatenation. Optional values, if not specified, are not 2090 included in the concatenation. 2092 o The Client MUST set the Master Secret of the pairwise OSCORE 2093 Security Context to the concatenation of MSec and GMSec, where: i) 2094 MSec is the value of the 'ms' parameter in the 2095 OSCORE_Security_Context object of the 'cnf' parameter, received 2096 from the AS in Appendix A.2.2; while ii) GMSec is the Master 2097 Secret of the Group OSCORE Security Context, which is known to the 2098 Client as a member of the OSCORE group. 2100 o The Client MUST set the Recipient ID as indicated in the 2101 corresponding parameter received from the AS in Appendix A.2.2, 2102 i.e. to the value of the 'serverId' parameter in the 2103 OSCORE_Security_Context object of the 'cnf' parameter. 2105 o The Client MUST set the AEAD Algorithm, HKDF, and Replay Window as 2106 indicated in the corresponding parameters received from the AS in 2107 Appendix A.2.2, if present in the OSCORE_Security_Context object 2108 of the 'cnf' parameter. In case these parameters are omitted, the 2109 default values are used as described in Section 3.2 of [RFC8613]. 2111 o The client MUST set the Sender ID as indicated in the response 2112 from the AS in Appendix A.2.2, i.e. to the value of the 'clientId' 2113 parameter in the OSCORE_Security_Context object of the 'cnf' 2114 parameter. 2116 Finally, the client MUST derive the complete pairwise OSCORE Security 2117 Context following Section 3.2.1 of [RFC8613]. 2119 From then on, when communicating with the RS to access the resources 2120 as specified by the authorization information, the Client MUST use 2121 the newly established pairwise OSCORE Security Context or the Group 2122 OSCORE Security Context of the OSCORE Group where both the Client and 2123 the RS are members. 2125 If any of the expected parameters is missing (e.g. any of the 2126 mandatory parameters from the AS, or 'clientId' both from the AS and 2127 in the 2.01 (Created) response from the RS), the Client MUST stop the 2128 exchange, and MUST NOT derive the pairwise OSCORE Security Context. 2129 The Client MAY restart the exchange, to get the correct security 2130 material. 2132 Then, the Client uses this pairwise OSCORE Security Context to send 2133 requests to RS protected with OSCORE. In the first request sent to 2134 the RS, the Client MAY include the kid context if the application 2135 needs to, with value the ID Context of the pairwise OSCORE Context as 2136 described above. Besides, the Client uses the Group OSCORE Security 2137 Context for protecting unicast requests to the RS, or multicast 2138 requests to the OSCORE group including also the RS. 2140 A.3.4. OSCORE Setup - Resource Server Side 2142 After validation of the Access Token as defined in Appendix A.3.2 and 2143 after sending the 2.01 (Created) response, the RS performs the 2144 following actions, in order to set up and fully derive the pairwise 2145 OSCORE Security Context created to communicate with the Client. 2147 o The RS MUST set the ID Context of the pairwise OSCORE Security 2148 Context as the concatenation of: i) GID, i.e. the Group Identifier 2149 of the OSCORE group, as specified in the 'contextId' parameter of 2150 the OSCORE_Security_Context object, in the 'cnf' claim of the 2151 Access Token received from the Client (see Appendix A.3.1); ii) 2152 the nonce N1; iii) the nonce N2; and iv) CID which is the value in 2153 the contextId parameter of the OSCORE_Security_Context object 2154 provided in the 'cnf' claim of the Access Token. The 2155 concatenation occurs in this order: ID Context = GID | N1 | N2 | 2156 CID, where | denotes byte string concatenation. 2158 o The RS MUST set the new Master Salt of the pairwise OSCORE 2159 Security Context as the concatenation of SaltInput, MSalt, the 2160 nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the 2161 Sender ID that the Client has in the OSCORE group, as specified in 2162 the 'salt_input' claim included in the Access Token received from 2163 the Client (see Appendix A.3.1); ii) MSalt is the (optional) 2164 Master Salt in the pairwise OSCORE Security Context as specified 2165 in the 'salt' parameter in the OSCORE_Security_Context object of 2166 the 'cnf' claim, included in the Access Token received from the 2167 Client; and iii) GMSalt is the (optional) Master Salt in the Group 2168 OSCORE Security Context, which is known to the RS as a member of 2169 the OSCORE group. The concatenation occurs in this order: Master 2170 Salt = SaltInput | MSalt | N1 | N2 | GMSalt, where | denotes byte 2171 string concatenation. Optional values, if not specified, are not 2172 included in the concatenation. 2174 o The RS MUST set the Master Secret of the pairwise OSCORE Security 2175 Context to the concatenation of MSec and GMSec, where: i) MSec is 2176 the value of the 'ms' parameter in the OSCORE_Security_Context 2177 object of the 'cnf' claim, included in the Access Token received 2178 from the Client (see Appendix A.3.1); while ii) GMSec is the 2179 Master Secret of the Group OSCORE Security Context, which is known 2180 to the RS as a member of the OSCORE group. 2182 o The RS MUST set the Sender ID of the pairwise OSCORE Security 2183 Context from the corresponding parameter received from the Client 2184 in the Access Token (see Appendix A.3.1), i.e. to the value of the 2185 'serverId' parameter in the OSCORE_Security_Context object of the 2186 'cnf' claim. 2188 o The RS MUST set the Recipient ID of the pairwise OSCORE Security 2189 Context to what indicated in the corresponding parameter received 2190 from the Client in the Access Token (see Appendix A.3.1), i.e. to 2191 the value of the 'clientId' parameter in the 2192 OSCORE_Security_Context object of the 'cnf' claim. 2194 o The RS MUST set the AEAD Algorithm, HKDF, and Replay Window from 2195 the corresponding parameters received from the Client in the 2196 Access Token (see Appendix A.3.1), if present in the 2197 OSCORE_Security_Context object of the 'cnf' claim. In case these 2198 parameters are omitted, the default values are used as described 2199 in Section 3.2 of [RFC8613]. 2201 Finally, the RS MUST derive the complete pairwise OSCORE Security 2202 Context following Section 3.2.1 of [RFC8613]. 2204 Once having completed the derivation above, the RS MUST associate the 2205 authorization information from the Access Token with the just 2206 established pairwise OSCORE Security Context. Furthermore, as 2207 defined in Section 4.2, the RS MUST associate the authorization 2208 information from the Access Token with the Group OSCORE Security 2209 Context. 2211 Then, the RS uses this pairwise OSCORE Security Context to verify 2212 requests from and send responses to the Client protected with OSCORE, 2213 when this Security Context is used. If OSCORE verification fails, 2214 error responses are used, as specified in Section 8 of [RFC8613]. 2215 Besides, the RS uses the Group OSCORE Security Context to verify 2216 (multicast) requests from and send responses to the Client protected 2217 with Group OSCORE. If Group OSCORE verification fails, error 2218 responses are used, as specified in Section 8 and Section 9 of 2219 [I-D.ietf-core-oscore-groupcomm]. Additionally, for every incoming 2220 request, if OSCORE or Group OSCORE verification succeeds, the 2221 verification of access rights is performed as described in 2222 Appendix A.3.5. 2224 After the expiration of the Access Token related to a pairwise OSCORE 2225 Security Context and to a Group OSCORE Security Context, the RS MUST 2226 NOT use the pairwise OSCORE Security Context and MUST respond with an 2227 unprotected 4.01 (Unauthorized) error message to received requests 2228 that correspond to a security context with an expired token. Also, 2229 if the Client uses the Group OSCORE Security Context to send a 2230 request for any resource intended for OSCORE group members and that 2231 requires an active Access Token, the RS MUST respond with a 4.01 2232 (Unauthorized) error message protected with the Group OSCORE Security 2233 Context. 2235 A.3.5. Access Rights Verification 2237 The RS MUST follow the procedures defined in Section 4.4. 2239 Additionally, if the RS receives an OSCORE-protected request from a 2240 Client, the RS processes it according to [RFC8613]. 2242 If the OSCORE verification succeeds, and the target resource requires 2243 authorization, the RS retrieves the authorization information from 2244 the Access Token associated to the pairwise OSCORE Security Context 2245 and to the Group OSCORE Security Context. Then, the RS MUST verify 2246 that the action requested on the resource is authorized. 2248 The response code MUST be 4.01 (Unauthorized) in case the Client has 2249 not used either of the two Security Contexts associated with the 2250 Access Token, or if the RS has no valid Access Token for the Client. 2252 A.4. Secure Communication with the AS 2254 The same considerations for secure communication with the AS as 2255 defined in Section 5 hold. 2257 A.5. Discarding the Security Context 2259 The Client and the RS MUST follow what is defined in Section 6 of 2260 [I-D.ietf-ace-oscore-profile] about discarding the pairwise OSCORE 2261 Security Context. 2263 Additionally, they MUST follow what is defined in the main mode of 2264 the profile (see Section 6), with respect to the Group OSCORE 2265 Security Context. 2267 The Client or RS can acquire a new Group OSCORE Security Context, by 2268 re-joining the OSCORE group, e.g. by using the approach defined in 2270 [I-D.ietf-ace-key-groupcomm-oscore]. In such a case, the Client 2271 SHOULD request a new Access Token and post it to the RS, in order to 2272 establish a new pairwise OSCORE Security Context and bind it to the 2273 Group OSCORE Security Context obtained upon re-joining the group. 2275 A.6. CBOR Mappings 2277 The new parameters defined in this document MUST be mapped to CBOR 2278 types as specified in Figure 6, with the following addition, using 2279 the given integer abbreviation for the map key. 2281 /----------------+----------+------------\ 2282 | Parameter name | CBOR Key | Value Type | 2283 |----------------+----------+------------| 2284 | client_cred | TBD5 | map | 2285 \----------------+----------+------------/ 2287 Figure 17: CBOR mappings for new parameters. 2289 The new claims defined in this document MUST be mapped to CBOR types 2290 as specified in Figure 7, with the following addition, using the 2291 given integer abbreviation for the map key. 2293 /--------------+----------+------------\ 2294 | Claim name | CBOR Key | Value Type | 2295 |--------------+----------+------------| 2296 | client_cred | TBD5 | map | 2297 \--------------+----------+------------/ 2299 Figure 18: CBOR mappings for new claims. 2301 A.7. Security Considerations 2303 The dual mode of this profile inherits the security considerations 2304 from the main mode (see Section 8), as well as from the security 2305 considerations of the OSCORE profile of ACE 2306 [I-D.ietf-ace-oscore-profile]. Also, the security considerations 2307 about OSCORE [RFC8613] hold for the dual mode of this profile, as to 2308 the specific use of OSCORE. 2310 A.8. Privacy Considerations 2312 The same privacy considerations as defined in the main mode of this 2313 profile apply (see Section 9). 2315 In addition, as this profile mode also uses OSCORE, the privacy 2316 considerations from [RFC8613] apply as well, as to the specific use 2317 of OSCORE. 2319 Furthermore, this profile mode inherits the privacy considerations 2320 from the OSCORE profile of ACE [I-D.ietf-ace-oscore-profile]. 2322 Appendix B. Profile Requirements 2324 This appendix lists the specifications on this profile based on the 2325 requirements of the ACE framework, as requested in Appendix C of 2326 [I-D.ietf-ace-oauth-authz]. 2328 o (Optional) discovery process of how the Client finds the right AS 2329 for an RS it wants to send a request to: Not specified. 2331 o Communication protocol the Client and the RS must use: CoAP. 2333 o Security protocol(s) the Client and RS must use: Group OSCORE, 2334 i.e. exchange of secure messages by using a pre-established Group 2335 OSCORE Security Context. The optional dual mode defined in 2336 Appendix A additionally uses OSCORE, i.e. establishment of a 2337 pairwise OSCORE Security Context and exchange of secure messages. 2339 o How the Client and the RS mutually authenticate: Explicitly, by 2340 possession of a common Group OSCORE Security Context, and by 2341 either: usage of digital countersignatures embedded in messages, 2342 if protected with the group mode of Group OSCORE; or protection of 2343 messages with the pairwise mode of Group OSCORE, by using pairwise 2344 symmetric keys, derived from the asymmetric keys of the two peers 2345 exchanging the message. In the optional dual mode defined in 2346 Appendix A, this may also happen implicitly, by possession of a 2347 common OSCORE Security Context (when using OSCORE). 2349 o Content-format of the protocol messages: "application/ace+cbor". 2351 o Proof-of-Possession protocol(s) and how to select one; which key 2352 types (e.g. symmetric/asymmetric) supported: Group OSCORE 2353 algorithms; distributed and verified asymmetric keys. In the 2354 optional dual mode defined in Appendix A: OSCORE algorithms; pre- 2355 established symmetric keys 2357 o profile identifier: coap_group_oscore 2359 o (Optional) how the RS talks to the AS for introspection: HTTP/CoAP 2360 (+ TLS/DTLS/OSCORE). 2362 o How the client talks to the AS for requesting a token: HTTP/CoAP 2363 (+ TLS/DTLS/OSCORE). 2365 o How/if the authz-info endpoint is protected: Not protected. 2367 o (Optional) other methods of token transport than the authz-info 2368 endpoint: Not specified. 2370 Acknowledgments 2372 The authors sincerely thank Benjamin Kaduk, John Mattsson, Dave 2373 Robin, Jim Schaad and Goeran Selander for their comments and 2374 feedback. 2376 The work on this document has been partly supported by VINNOVA and 2377 the Celtic-Next project CRITISEC. 2379 Authors' Addresses 2381 Marco Tiloca 2382 RISE AB 2383 Isafjordsgatan 22 2384 Kista SE-16440 Stockholm 2385 Sweden 2387 Email: marco.tiloca@ri.se 2389 Rikard Hoeglund 2390 RISE AB 2391 Isafjordsgatan 22 2392 Kista SE-16440 Stockholm 2393 Sweden 2395 Email: rikard.hoglund@ri.se 2397 Ludwig Seitz 2398 Combitech 2399 Djaeknegatan 31 2400 Malmoe SE-21135 Malmoe 2401 Sweden 2403 Email: ludwig.seitz@combitech.se 2405 Francesca Palombini 2406 Ericsson AB 2407 Torshamnsgatan 23 2408 Kista SE-16440 Stockholm 2409 Sweden 2411 Email: francesca.palombini@ericsson.com