idnits 2.17.1 draft-tiloca-ace-group-oscore-profile-04.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 (November 02, 2020) is 1268 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-09 == 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-13 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cbor-7049bis' == Outdated reference: A later version (-10) exists of draft-ietf-core-groupcomm-bis-02 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-10 ** 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-14 -- 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-14 == Outdated reference: A later version (-17) exists of draft-ietf-ace-mqtt-tls-profile-08 == 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-07 -- 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 (~~), 12 warnings (==), 5 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: May 6, 2021 L. Seitz 6 Combitech 7 F. Palombini 8 Ericsson AB 9 November 02, 2020 11 Group OSCORE Profile of the Authentication and Authorization for 12 Constrained Environments Framework 13 draft-tiloca-ace-group-oscore-profile-04 15 Abstract 17 This document specifies a profile for the Authentication and 18 Authorization for Constrained Environments (ACE) framework. The 19 profile uses Group OSCORE to provide communication security between a 20 Client and a (set of) Resource Server(s) as members of an OSCORE 21 Group. The profile securely binds an OAuth 2.0 Access Token with the 22 public key of the Client associated to the signing private key used 23 in the OSCORE group. The profile uses Group OSCORE to achieve server 24 authentication, as well as proof-of-possession for the Client's 25 public key. Also, it provides proof of the Client's membership to 26 the correct OSCORE group, by binding the Access Token to information 27 from the Group OSCORE Security Context, thus allowing the Resource 28 Server(s) to verify the Client's membership upon receiving a message 29 protected with Group OSCORE from the Client. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 6, 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 . . . . . . . . . . . . . . . . . . . . . 9 69 2.2. Access Token Retrieval . . . . . . . . . . . . . . . . . 9 70 2.3. Access Token Posting . . . . . . . . . . . . . . . . . . 10 71 2.4. Secure Communication . . . . . . . . . . . . . . . . . . 10 72 3. Client-AS Communication . . . . . . . . . . . . . . . . . . . 11 73 3.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . . . 11 74 3.1.1. 'context_id' Parameter . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . 14 78 3.2.1. Salt Input Claim . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . 21 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 . . . . 33 106 A.1.4. Secure Communication . . . . . . . . . . . . . . . . 34 107 A.2. Client-AS Communication . . . . . . . . . . . . . . . . . 34 108 A.2.1. C-to-AS: POST to Token Endpoint . . . . . . . . . . . 35 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) . . . . . . . . . . . . . . . 46 113 A.3.3. OSCORE Setup - Client Side . . . . . . . . . . . . . 46 114 A.3.4. OSCORE Setup - Resource Server Side . . . . . . . . . 49 115 A.3.5. Access Rights Verification . . . . . . . . . . . . . 51 116 A.4. Secure Communication with the AS . . . . . . . . . . . . 51 117 A.5. Discarding the Security Context . . . . . . . . . . . . . 51 118 A.6. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . 52 119 A.7. Security Considerations . . . . . . . . . . . . . . . . . 52 120 A.8. Privacy Considerations . . . . . . . . . . . . . . . . . 52 121 Appendix B. Profile Requirements . . . . . . . . . . . . . . . . 53 122 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 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 domains. For instance, a more 152 fine-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 216 and the Resource Servers. Hence, it requires that both the Client 217 and the Resource Servers have previously joined the same OSCORE 218 group. 220 That is, this profile describes how access control is enforced for a 221 Client after it has joined an OSCORE group, to access resources at 222 other members in that group. The process for joining the OSCORE 223 group through the respective Group Manager as defined in 224 [I-D.ietf-ace-key-groupcomm-oscore] takes place before the process 225 described in this document, and is out of the scope of this profile. 227 The Client proves its access to be authorized to the Resource Server 228 by using an Access Token, which is bound to a key (the proof-of- 229 possession key). This profile uses Group OSCORE to achieve server 230 authentication, as well as proof-of-possession for the Client's 231 public key associated to the signing private key used in an OSCORE 232 group. Note that the proof of possession is not done by a dedicated 233 protocol element, but rather occurs after the first Group OSCORE 234 exchange. Furthermore, this profile provides proof of the Client's 235 membership to the correct OSCORE group, by binding the Access Token 236 to the Client's public key and information from the pre-established 237 Group OSCORE Security Context, thus allowing the Resource Server to 238 verify this upon reception of a messages protected with Group OSCORE 239 from the Client. 241 OSCORE [RFC8613] specifies how to use COSE 242 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] to 243 secure CoAP messages. Group OSCORE builds on OSCORE to provide 244 secure group communication, and ensures source authentication either: 245 by means of digital counter signatures embedded in protected messages 246 (in group mode); by protecting messages with pairwise key material 247 derived from the asymmetric keys of the two peers exchanging the 248 message (in pairwise mode). 250 1.1. Terminology 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 254 "OPTIONAL" in this document are to be interpreted as described in BCP 255 14 [RFC2119] [RFC8174] when, and only when, they appear in all 256 capitals, as shown here. 258 Readers are expected to be familiar with the terms and concepts 259 related to CBOR [I-D.ietf-cbor-7049bis], COSE 260 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs], 261 CoAP [RFC7252], OSCORE [RFC8613] and Group OSCORE 262 [I-D.ietf-core-oscore-groupcomm]. These include the concept of Group 263 Manager, as the entity responsible for a set of groups where 264 communications among members are secured with Group OSCORE. 266 Readers are expected to be familiar with the terms and concepts 267 described in the ACE framework for authentication and authorization 268 [I-D.ietf-ace-oauth-authz], as well as in the OSCORE profile of ACE 269 [I-D.ietf-ace-oscore-profile]. The terminology for entities in the 270 considered architecture is defined in OAuth 2.0 [RFC6749]. In 271 particular, this includes Client (C), Resource Server (RS), and 272 Authorization Server (AS). 274 Note that, unless otherwise indicated, the term "endpoint" is used 275 here following its OAuth definition, aimed at denoting resources such 276 as /token and /introspect at the AS, and /authz-info at the RS. This 277 document does not use the CoAP definition of "endpoint", which is "An 278 entity participating in the CoAP protocol". 280 2. Protocol Overview 282 This section provides an overview of this profile, i.e. on how to use 283 the ACE framework for authentication and authorization 284 [I-D.ietf-ace-oauth-authz] to secure communications between a Client 285 and a (set of) Resource Server(s) using Group OSCORE 286 [I-D.ietf-core-oscore-groupcomm]. 288 Note that this profile of ACE describes how access control can be 289 enforced for a node after it has joined an OSCORE group, to access 290 resources at other members in that group. 292 In particular, the process for joining the OSCORE group through the 293 respective Group Manager as defined in 294 [I-D.ietf-ace-key-groupcomm-oscore] must take place before the 295 process described in this document, and is out of the scope of this 296 profile. 298 An overview of the protocol flow for this profile is shown in 299 Figure 1. In the figure, it is assumed that both RS1 and RS2 are 300 associated with the same AS. It is also assumed that C, RS1 and RS2 301 have previously joined an OSCORE group with Group Identifier (gid) 302 "abcd0000", and got assigned Sender ID (sid) "0", "1" and "2" in the 303 group, respectively. The names of messages coincide with those of 304 [I-D.ietf-ace-oauth-authz] when applicable. 306 C RS1 RS2 AS 307 | [--- Resource Request --->] | | | 308 | | | | 309 | [<---- AS Request ------] | | | 310 | Creation Hints | | | 311 | | | | 312 |-------- POST /token ------------------------------------------------>| 313 | (aud: RS1, sid: 0, gid: abcd0000, ...) | | 314 | | | | 315 |<--------------------------------- Access Token + RS Information -----| 316 | | (aud: RS1, sid: 0, gid: abcd0000, ...) | 317 | | | | 318 |---- POST /authz-info ------>| | | 319 | (access_token) | | | 320 | | | | 321 |<--- 2.01 Created -----------| | | 322 | | | | 323 |-------- POST /token ------------------------------------------------>| 324 | (aud: RS2, sid: 0, gid: abcd0000, ...) | | 325 | | | | 326 |<--------------------------------- Access Token + RS Information -----| 327 | | (aud: RS2, sid: 0, gid: abcd0000, ...) | 328 | | | | 329 |----- POST /authz-info ------------------>| | 330 | (access_token) | | | 331 | | | | 332 |<--- 2.01 Created ------------------------| | 333 | | | | 334 |-- Group OSCORE Request -+-->| | | 335 | (kid: 0, gid: abcd0000) \-------------->| | 336 | | | | 337 | /proof-of-possession/ | 338 | | | | 339 |<--- Group OSCORE Response --| | | 340 | (kid: 1) | | | 341 | | | | 342 /proof-of-possession/ | | | 343 | | | | 344 |<--- Group OSCORE Response ---------------| | 345 | (kid: 2) | | | 346 | | | | 347 /proof-of-possession/ | | | 348 | ... | | | 350 Figure 1: Protocol Overview. 352 2.1. Pre-Conditions 354 Using Group OSCORE and this profile requires both the Client and the 355 Resource Servers to have previously joined the same OSCORE group. 356 This especially includes the derivation of the Group OSCORE Security 357 Context and the assignment of unique Sender IDs to use in the group. 358 Nodes may join the OSCORE group through the respective Group Manager 359 by using the approach defined in [I-D.ietf-ace-key-groupcomm-oscore], 360 which is also based on ACE. 362 After the Client and Resource Servers have joined the group, this 363 profile provides access control for accessing resources on those 364 Resource Servers, by securely communicating with Group OSCORE. 366 As a pre-requisite for this profile, the Client has to have 367 successfully joined the OSCORE group where also the Resource Servers 368 (RSs) are members. Depending on the limited information initially 369 available, the Client may have to first discover the exact OSCORE 370 group used by the RSs for the resources of interest, e.g. by using 371 the approach defined in [I-D.tiloca-core-oscore-discovery]. 373 2.2. Access Token Retrieval 375 This profile requires that the Client retrieves an Access Token from 376 the AS for the resource(s) it wants to access on each of the RSs, 377 using the /token endpoint, as specified in Section 5.6 of 378 [I-D.ietf-ace-oauth-authz]. In a general case, it can be assumed 379 that different RSs are associated to different ASs, even if the RSs 380 are members of a same OSCORE group. 382 In the Access Token request to the AS, the Client MUST include the 383 Group Identifier of the OSCORE group and its own Sender ID in that 384 group. The AS MUST specify these pieces of information in the Access 385 Token, included in the Access Token response to the Client. 387 Furthermore, in the Access Token request to the AS, the Client MUST 388 also include: its own public key, associated to the private signing 389 key used in the OSCORE group; and a signature computed with such 390 private key, over a quantity uniquely related to the secure 391 communication association between the Client and the AS. The AS MUST 392 include also the public key indicated by the Client in the Access 393 Token. 395 The Access Token request and response MUST be confidentiality- 396 protected and ensure authenticity. This profile RECOMMENDS the use 397 of OSCORE between the Client and the AS, but TLS [RFC5246][RFC8446] 398 or DTLS [RFC6347][I-D.ietf-tls-dtls13] MAY be used additionally or 399 instead. 401 2.3. Access Token Posting 403 After having retrieved the Access Token from the AS, the Client posts 404 the Access Token to the RS, using the /authz-info endpoint and 405 mechanisms specified in Section 5.8 of [I-D.ietf-ace-oauth-authz], as 406 well as Content-Format = application/ace+cbor. When using this 407 profile, the communication with the /authz-info endpoint is not 408 protected. 410 If the Access Token is valid, the RS replies to this POST request 411 with a 2.01 (Created) response with Content-Format = application/ 412 ace+cbor. Also, the RS associates the received Access Token with the 413 Group OSCORE Security Context identified by the Group Identifier 414 specified in the Access Token, following Section 3.2 of [RFC8613]. 415 In practice, the RS maintains a collection of Security Contexts with 416 associated authorization information, for all the clients that it is 417 currently communicating with, and the authorization information is a 418 policy used as input when processing requests from those clients. 420 Finally, the RS stores the association between i) the authorization 421 information from the Access Token; and ii) the Group Identifier of 422 the OSCORE group together with the Sender ID and the public key of 423 the Client in that group. This binds the Access Token with the Group 424 OSCORE Security Context of the OSCORE group. 426 Finally, when the Client communicates with the RS using the Group 427 OSCORE Security Context, the RS verifies that the Client is a 428 legitimate member of the OSCORE group and especially the exact group 429 member with the same Sender ID associated to the Access Token. This 430 occurs when verifying a request protected with Group OSCORE, since it 431 embeds a counter signature computed also over the Client's Sender ID 432 included in the message. 434 2.4. Secure Communication 436 The Client can send a request protected with Group OSCORE 437 [I-D.ietf-core-oscore-groupcomm] to the RS. This can be a unicast 438 request addressed to the RS, or a multicast request addressed to the 439 OSCORE group where the RS is also a member. To this end, the Client 440 uses the Group OSCORE Security Context already established upon 441 joining the OSCORE group, e.g. by using the approach defined in 442 [I-D.ietf-ace-key-groupcomm-oscore]. The RS may send a response back 443 to the Client, protecting it by means of the same Group OSCORE 444 Security Context. 446 3. Client-AS Communication 448 This section details the Access Token POST Request that the Client 449 sends to the /token endpoint of the AS, as well as the related Access 450 Token response. 452 The Access Token MUST be bound to the public key of the client as 453 proof-of-possession key (pop-key), by means of the 'cnf' claim. 455 3.1. C-to-AS: POST to Token Endpoint 457 The Client-to-AS request is specified in Section 5.6.1 of 458 [I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request 459 to the /token endpoint over a secure channel that guarantees 460 authentication, message integrity and confidentiality. 462 The POST request is formatted as the analogous Client-to-AS request 463 in the OSCORE profile of ACE (see Section 3.1 of 464 [I-D.ietf-ace-oscore-profile]), with the following additional 465 parameters that MUST be included in the payload. 467 o 'context_id', defined in Section 3.1.1 of this specification. 468 This parameter specifies the Group Identifier (GID), i.e. the Id 469 Context of an OSCORE group where the Client and the RS are 470 currently members. In particular, the Client wishes to 471 communicate with the RS using the Group OSCORE Security Context 472 associated to that OSCORE group. 474 o 'salt_input', defined in Section 3.1.2 of this specification. 475 This parameter includes the Sender ID that the Client has in the 476 OSCORE group whose GID is specified in the 'context_id' parameter 477 above. 479 o 'req_cnf', defined in Section 3.1 of [I-D.ietf-ace-oauth-params]. 480 This parameter includes the public key associated to the signing 481 private key that the Client uses in the OSCORE group whose GID is 482 specified in the 'context_id' parameter above. This public key 483 will be used as the pop-key bound to the Access Token. 485 o 'client_cred_verify', defined in Section 3.1.3 of this 486 specification. This parameter includes a signature computed by 487 the Client, by using the private key associated to the public key 488 in the 'req_cnf' parameter above. This allows the AS to verify 489 that the Client indeed owns the private key associated to that 490 public key, as its alleged identity credential within the OSCORE 491 group. The information to be signed MUST be the byte 492 representation of a quantity that uniquely represents the secure 493 communication association between the Client and the AS. It is 494 RECOMMENDED that the Client considers the following as information 495 to sign. 497 * If the Client and the AS communicate over (D)TLS, the 498 information to sign is an exporter value computed as defined in 499 Section 7.5 of [RFC8446]. In particular, the exporter label 500 MUST be 'EXPORTER-ACE-Sign-Challenge-Client-AS' defined in 501 Section 10.5 of this specification, together with an empty 502 'context_value', and 32 bytes as 'key_length'. 504 * If the Client and the AS communicate over OSCORE, the 505 information to sign is the output PRK of a HKDF-Extract step 506 [RFC5869], i.e. PRK = HMAC-Hash(salt, IKM). In particular, 507 'salt' takes (x1 | x2), where x1 is the ID Context of the 508 OSCORE Security Context between the Client and the AS, x2 is 509 the Sender ID of the Client in that Context, and | denotes byte 510 string concatenation. Also, 'IKM' is the OSCORE Master Secret 511 of the OSCORE Security Context between the Client and the AS. 512 The HKDF MUST be one of the HMAC-based HKDF [RFC5869] 513 algorithms defined for COSE [I-D.ietf-cose-rfc8152bis-algs]. 514 HKDF SHA-256 is mandatory to implement. 516 An example of such a request, with payload in CBOR diagnostic 517 notation without the tag and value abbreviations is reported in 518 Figure 2. 520 Header: POST (Code=0.02) 521 Uri-Host: "as.example.com" 522 Uri-Path: "token" 523 Content-Format: "application/ace+cbor" 524 Payload: 525 { 526 "audience" : "tempSensor4711", 527 "scope" : "read", 528 "context_id" : h'abcd0000', 529 "salt_input" : h'00', 530 "req_cnf" : { 531 "COSE_Key" : { 532 "kty" : EC2, 533 "crv" : P-256, 534 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 535 27c9e354089bbe13', 536 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 537 731e79a3b4e47120' 538 } 539 }, 540 "client_cred_verify" : h'...' 541 (signature content omitted for brevity) 542 } 544 Figure 2: Example C-to-AS POST /token request for an Access Token 545 bound to an asymmetric key. 547 3.1.1. 'context_id' Parameter 549 The 'context_id' parameter is an OPTIONAL parameter of the Access 550 Token request message defined in Section 5.6.1. of 551 [I-D.ietf-ace-oauth-authz]. This parameter provides a value that the 552 Client wishes to use with the RS as a hint for a security context. 553 Its exact content is profile specific. 555 3.1.2. 'salt_input' Parameter 557 The 'salt_input' parameter is an OPTIONAL parameter of the Access 558 Token request message defined in Section 5.6.1. of 559 [I-D.ietf-ace-oauth-authz]. This parameter provides a value that the 560 Client wishes to use as part of a salt with the RS, for deriving 561 cryptographic key material. Its exact content is profile specific. 563 3.1.3. 'client_cred_verify' Parameter 565 The 'client_cred_verify' parameter is an OPTIONAL parameter of the 566 Access Token request message defined in Section 5.6.1. of 567 [I-D.ietf-ace-oauth-authz]. This parameter provides a signature 568 computed by the Client to prove the possession of its own private 569 key. 571 3.2. AS-to-C: Access Token 573 After having verified the POST request to the /token endpoint and 574 that the Client is authorized to obtain an Access Token corresponding 575 to its Access Token request, the AS MUST verify the signature in the 576 'client_cred_verify' parameter, by using the public key specified in 577 the 'req_cnf' parameter. If the verification fails, the AS considers 578 the Client request invalid. 580 If all verifications are successful, the AS responds as defined in 581 Section 5.6.2 of [I-D.ietf-ace-oauth-authz]. If the Client request 582 was invalid, or not authorized, the AS returns an error response as 583 described in Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. 585 The AS can signal that the use of Group OSCORE is REQUIRED for a 586 specific Access Token by including the 'profile' parameter with the 587 value "coap_group_oscore" in the Access Token response. The Client 588 MUST use Group OSCORE towards all the Resource Servers for which this 589 Access Token is valid. Usually, it is assumed that constrained 590 devices will be pre-configured with the necessary profile, so that 591 this kind of profile negotiation can be omitted. 593 The AS MUST include the following information as metadata of the 594 issued Access Token. The use of CBOR web tokens (CWT) as specified 595 in [RFC8392] is RECOMMENDED. 597 o The same parameter 'profile' included in the Token Response to the 598 Client. 600 o The salt input specified in the 'salt_input' parameter of the 601 Token Request. If the Access Token is a CWT, the content of the 602 'salt_input' parameter MUST be placed in the 'salt_input' claim of 603 the Access Token, defined in Section 3.2.1 of this specification. 605 o The Context Id input specified in the 'context_id' parameter of 606 the Token Request. If the Access Token is a CWT, the content of 607 the 'context_id' parameter MUST be placed in the 'contextId_input' 608 claim of the Access Token, defined in Section 3.2.2 of this 609 specification. 611 o The public key that the client uses in the OSCORE group and 612 specified in the 'req_cnf' parameter of the Token request. If the 613 Access Token is a CWT, the public key MUST be specified in the 614 'cnf' claim, which follows the syntax from Section 3.1 of 615 [RFC8747] when including Value Type "COSE_Key" (1) and specifying 616 an asymmetric key. Alternative Value Types defined in future 617 specifications are fine to consider if indicating a non-encrypted 618 asymmetric key. 620 Figure 3 shows an example of such an AS response, with payload in 621 CBOR diagnostic notation without the tag and value abbreviations. 623 Header: Created (Code=2.01) 624 Content-Type: "application/ace+cbor" 625 Payload: 626 { 627 "access_token" : h'8343a1010aa2044c53 ...' 628 (remainder of CWT omitted for brevity), 629 "profile" : "coap_group_oscore", 630 "expires_in" : 3600 631 } 633 Figure 3: Example AS-to-C Access Token response with the Group OSCORE 634 profile. 636 Figure 4 shows an example CWT Claims Set, containing the Client's 637 public key in the group (as pop-key) in the 'cnf' claim, in CBOR 638 diagnostic notation without tag and value abbreviations. 640 { 641 "aud" : "tempSensorInLivingRoom", 642 "iat" : "1360189224", 643 "exp" : "1360289224", 644 "scope" : "temperature_g firmware_p", 645 "cnf" : { 646 "COSE_Key" : { 647 "kty" : EC2, 648 "crv" : P-256, 649 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 650 27c9e354089bbe13', 651 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 652 731e79a3b4e47120' 653 }, 654 "salt_input" : h'00', 655 "contextId_input" : h'abcd0000' 656 } 658 Figure 4: Example CWT Claims Set with OSCORE parameters (CBOR 659 diagnostic notation). 661 The same CWT Claims Set as in Figure 4 and encoded in CBOR is shown 662 in Figure 5, using the value abbreviations defined in 663 [I-D.ietf-ace-oauth-authz] and [RFC8747]. The bytes in hexadecimal 664 are reported in the first column, while their corresponding CBOR 665 meaning is reported after the '#' sign on the second column, for 666 easiness of readability. 668 NOTE: it should be checked (and in case fixed) that the values used 669 below (which are not yet registered) are the final values registered 670 in IANA. 672 A7 # map(7) 673 03 # unsigned(3) 674 76 # text(22) 675 74656D7053656E736F72496E4C6976696E67526F6F6D 676 06 # unsigned(6) 677 1A 5112D728 # unsigned(1360189224) 678 04 # unsigned(4) 679 1A 51145DC8 # unsigned(1360289224) 680 09 # unsigned(9) 681 78 18 # text(24) 682 74656D70657261747572655F67206669726D776172655F70 683 08 # unsigned(8) 684 A1 # map(1) 685 01 # unsigned(1) 686 A4 # map(4) 687 01 # unsigned(1) 688 02 # unsigned(2) 689 20 # negative(0) 690 01 # unsigned(1) 691 21 # negative(1) 692 58 20 # bytes(32) 693 D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9 694 E354089BBE13 695 22 # negative(2) 696 58 20 # bytes(32) 697 F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E515D020731E 698 79A3B4E47120 699 18 3C # unsigned(60) 700 41 # bytes(1) 701 00 702 18 3D # unsigned(61) 703 44 # bytes(4) 704 ABCD0000 706 Figure 5: Example CWT Claims Set with OSCORE parameters, CBOR 707 encoded. 709 3.2.1. Salt Input Claim 711 The 'salt_input' claim provides a value that the Client requesting 712 the Access Token wishes to use as a part of a salt with the RS, e.g. 713 for deriving cryptographic material. 715 This parameter specifies the value of the salt input, encoded as a 716 CBOR byte string. 718 3.2.2. Context ID Input Claim 720 The 'contextId_input' claim provides a value that the Client 721 requesting the Access Token wishes to use with the RS, as a hint for 722 a security context. 724 This parameter specifies the value of the Context ID input, encoded 725 as a CBOR byte string. 727 4. Client-RS Communication 729 This section details the POST request and response to the /authz-info 730 endpoint between the Client and the RS. 732 The proof-of-possession required to bind the Access Token to the 733 Client is explicitly performed when the RS receives and verifies a 734 request from the Client protected with Group OSCORE, either with the 735 group mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]) or 736 with the pairwise mode (see Section 9 of 737 [I-D.ietf-core-oscore-groupcomm]). 739 In particular, the RS uses the Client's public key bound to the 740 Access Token, either when verifying the counter signature of the 741 request (if protected with the group mode), or when verifying the 742 request as integrity-protected with pairwise key material derived 743 from the two peers' asymmetric keys (if protected with the pairwise 744 mode). In either case, the RS also authenticates the Client. 746 Similarly, when receiving a protected response from the RS, the 747 Client uses the RS's public key either when verifying the counter 748 signature of the response (if protected with the group mode), or when 749 verifying the response as integrity-protected with pairwise key 750 material derived from the two peers' asymmetric keys (if protected 751 with the pairwise mode). In either case, the Client also 752 authenticates the RS. Mutual authentication is only achieved after 753 the client has successfully verified the Group OSCORE protected 754 response from the RS. 756 Therefore, an attacker using a stolen Access Token cannot generate a 757 valid Group OSCORE message signed with the Client's private key, and 758 thus cannot prove possession of the pop-key bound to the Access 759 Token. Also, if a Client legitimately owns an Access Token but has 760 not joined the OSCORE group, it cannot generate a valid Group OSCORE 761 message, as it does not own the necessary key material shared among 762 the group members. 764 Furthermore, a Client C1 is supposed to obtain a valid Access Token 765 from the AS, as including the public key associated to its own 766 signing key used in the OSCORE group, together with its own Sender ID 767 in that OSCORE group (see Section 3.1). This makes it possible for 768 the RS receiving an Access Token to verify with the Group Manager of 769 that OSCORE group whether such a Client has indeed that Sender ID and 770 that public key in the OSCORE group. 772 As a consequence, a different Client C2, also member of the same 773 OSCORE group, is not able to impersonate C1, by: i) getting a valid 774 Access Token, specifying the Sender ID of C1 and a different (made- 775 up) public key; ii) successfully posting the Access Token to RS; and 776 then iii) attempting to communicate using Group OSCORE impersonating 777 C1, while blaming C1 for the consequences. 779 4.1. C-to-RS POST to authz-info Endpoint 781 The Client posts the Access Token to the /authz-info endpoint of the 782 RS, as defined in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 784 4.2. RS-to-C: 2.01 (Created) 786 The RS MUST verify the validity of the Access Token as defined in 787 Section 5.8.1 of [I-D.ietf-ace-oauth-authz], with the following 788 additions. 790 o The RS checks that the claims 'salt_input', 'contextId_input' and 791 'cnf' are included in the Access Token. 793 o The RS considers the content of the 'cnf' claim as the public key 794 associated to the signing private key of the Client in the OSCORE 795 group, whose GID is specified in the 'contextId_input' claim 796 above. If it does not already store that public key, the RS MUST 797 request it to the Group Manager of the OSCORE group as described 798 in [I-D.ietf-ace-key-groupcomm-oscore], specifying the Sender ID 799 of that Client in the OSCORE group, i.e. the value of the 800 'salt_input' claim above. The RS MUST check that the key 801 retrieved from the Group Manager matches the one retrieved from 802 the 'cnf' claim. When doing so, the 'kid' parameter of the 803 COSE_Key, if present, MUST NOT be considered for the comparison. 805 If any of the checks above fails, the RS MUST consider the Access 806 Token non valid, and MUST respond to the Client with an error 807 response code equivalent to the CoAP code 4.00 (Bad Request). 809 If the Access Token is valid and further checks on its content are 810 successful, the RS associates the authorization information from the 811 Access Token with the Group OSCORE Security Context. 813 In particular, the RS associates the authorization information from 814 the Access Token with the tuple (GID, SaltInput, PubKey), where GID 815 is the Group Identifier of the OSCORE Group, while SaltInput and 816 PubKey are the Sender ID and the public key that the Client uses in 817 that OSCORE group, respectively. These can be retrieved from the 818 'contextId_input', 'salt_input' and 'cnf' claims of the Access Token, 819 respectively. The RS MUST keep this association up-to-date over 820 time. 822 Finally, the RS MUST send a 2.01 (Created) response to the Client, as 823 defined in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 825 4.3. Client-RS Secure Communication 827 When previously joining the OSCORE group, both the Client and RS have 828 already established the related Group OSCORE Security Context to 829 communicate as group members. Therefore, they can simply start to 830 securely communicate using Group OSCORE, without deriving any 831 additional key material or security association. 833 4.3.1. Client Side 835 After having received the 2.01 (Created) response from the RS, 836 following the POST request to the authz-info endpoint, the Client can 837 start to communicate with the RS using Group OSCORE 838 [I-D.ietf-core-oscore-groupcomm]. 840 When communicating with the RS to access the resources as specified 841 by the authorization information, the Client MUST use the Group 842 OSCORE Security Context of the OSCORE group, whose GID was specified 843 in the 'context_id' parameter of the Token request. 845 4.3.2. Resource Server Side 847 After successful validation of the Access Token as defined in 848 Section 4.2 and after having sent the 2.01 (Created) response, the RS 849 can start to communicate with the Client using Group OSCORE 850 [I-D.ietf-core-oscore-groupcomm]. Additionally, for every incoming 851 request, if Group OSCORE verification succeeds, the verification of 852 access rights is performed as described in Section 4.4. 854 After the expiration of the Access Token related to a Group OSCORE 855 Security Context, if the Client uses the Group OSCORE Security 856 Context to send a request for any resource intended for OSCORE group 857 members and that requires an active Access Token, the RS MUST respond 858 with a 4.01 (Unauthorized) error message protected with the Group 859 OSCORE Security Context. 861 4.4. Access Rights Verification 863 The RS MUST follow the procedures defined in Section 5.8.2 of 864 [I-D.ietf-ace-oauth-authz]. If an RS receives a Group OSCORE- 865 protected request from a Client, the RS processes it according to 866 [I-D.ietf-core-oscore-groupcomm]. 868 If the Group OSCORE verification succeeds, and the target resource 869 requires authorization, the RS retrieves the authorization 870 information from the Access Token associated to the Group OSCORE 871 Security Context. Then, the RS MUST verify that the action requested 872 on the resource is authorized. 874 The response code MUST be 4.01 (Unauthorized) if the RS has no valid 875 Access Token for the Client. If the RS has an Access Token for the 876 Client but no actions are authorized on the target resource, the RS 877 MUST reject the request with a 4.03 (Forbidden). If the RS has an 878 Access Token for the Client but the requested action is not 879 authorized, the RS MUST reject the request with a 4.05 (Method Not 880 Allowed). 882 5. Secure Communication with the AS 884 As specified in the ACE framework (Section 5.7 of 885 [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or Client) 886 and the AS communicate via the /introspection or /token endpoint. 887 The use of CoAP and OSCORE for this communication is RECOMMENDED in 888 this profile. Other protocols (such as HTTP and DTLS or TLS) MAY be 889 used instead. 891 If OSCORE [RFC8613] is used, the requesting entity and the AS are 892 expected to have a pre-established Security Context in place. How 893 this Security Context is established is out of the scope of this 894 profile. Furthermore, the requesting entity and the AS communicate 895 using OSCORE through the /introspection endpoint as specified in 896 Section 5.7 of [I-D.ietf-ace-oauth-authz], and through the /token 897 endpoint as specified in Section 5.6 of [I-D.ietf-ace-oauth-authz]. 899 6. Discarding the Security Context 901 As members of an OSCORE group, the Client and the RS may 902 independently leave the group or be forced to, e.g. if compromised or 903 suspected so. Upon leaving the OSCORE group, the Client or RS also 904 discards the Group OSCORE Security Context, which may anyway be 905 renewed by the Group Manager through a group rekeying process (see 906 Section 3.1 of [I-D.ietf-core-oscore-groupcomm]). 908 The Client or RS can acquire a new Group OSCORE Security Context, by 909 re-joining the OSCORE group, e.g. by using the approach defined in 910 [I-D.ietf-ace-key-groupcomm-oscore]. In such a case, the Client 911 SHOULD request a new Access Token and post it to the RS. 913 7. CBOR Mappings 915 The new parameters defined in this document MUST be mapped to CBOR 916 types as specified in Figure 6, using the given integer abbreviation 917 for the map key. 919 /--------------------+----------+------------\ 920 | Parameter name | CBOR Key | Value Type | 921 |--------------------+----------+------------| 922 | context_id | TBD1 | bstr | 923 | salt_input | TBD2 | bstr | 924 | client_cred_verify | TBD3 | bstr | 925 \--------------------+----------+------------/ 927 Figure 6: CBOR mappings for new parameters. 929 The new claims defined in this document MUST be mapped to CBOR types 930 as specified in Figure 7, using the given integer abbreviation for 931 the map key. 933 /-----------------+----------+------------\ 934 | Claim name | CBOR Key | Value Type | 935 |-----------------+----------+------------| 936 | salt_input | TBD4 | bstr | 937 | contextId_input | TBD5 | bstr | 938 \-----------------+----------+------------/ 940 Figure 7: CBOR mappings for new claims. 942 8. Security Considerations 944 This document specifies a profile for the Authentication and 945 Authorization for Constrained Environments (ACE) framework 947 [I-D.ietf-ace-oauth-authz]. Thus, the general security 948 considerations from the ACE framework also apply to this profile. 950 This specification inherits the general security considerations about 951 Group OSCORE [I-D.ietf-core-oscore-groupcomm], as to the specific use 952 of Group OSCORE according to this profile. 954 Group OSCORE is designed to secure point-to-point as well as point- 955 to-multipoint communications, providing a secure binding between a 956 single request and multiple corresponding responses. In particular, 957 Group OSCORE fulfills the same security requirements of OSCORE, for 958 group requests and responses. 960 Group OSCORE ensures source authentication of messages both in group 961 mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]) and in 962 pairwise mode (see Section 9 of [I-D.ietf-core-oscore-groupcomm]). 964 When protecting an outgoing message in group mode, the sender uses 965 its private key to compute a digital counter signature, which is 966 embedded in the protected message. The group mode can be used to 967 protect messages sent over multicast to multiple recipients, or sent 968 over unicast to one recipient. 970 When protecting an outgoing message in pairwise mode, the sender uses 971 a pairwise symmetric key, as derived from the asymmetric keys of the 972 two peers exchanging the message. The pairwise mode can be used to 973 protect only messages sent over unicast to one recipient. 975 9. Privacy Considerations 977 This document specifies a profile for the Authentication and 978 Authorization for Constrained Environments (ACE) framework 979 [I-D.ietf-ace-oauth-authz]. Thus the general privacy considerations 980 from the ACE framework also apply to this profile. 982 As this profile uses Group OSCORE, the privacy considerations from 983 [I-D.ietf-core-oscore-groupcomm] apply to this document as well. 985 An unprotected response to an unauthorized request may disclose 986 information about the RS and/or its existing relationship with the 987 Client. It is advisable to include as little information as possible 988 in an unencrypted response. However, since both the Client and the 989 RS share a Group OSCORE Security Context, unauthorized, yet protected 990 requests are followed by protected responses, which can thus include 991 more detailed information. 993 Although it may be encrypted, the Access Token is sent in the clear 994 to the /authz-info endpoint at the RS. Thus, if the Client uses the 995 same single Access Token from multiple locations with multiple 996 Resource Servers, it can risk being tracked through the Access 997 Token's value. 999 Note that, even though communications are protected with Group 1000 OSCORE, some information might still leak, due to the observable 1001 size, source address and destination address of exchanged messages. 1003 10. IANA Considerations 1005 This document has the following actions for IANA. 1007 10.1. ACE Profile Registry 1009 IANA is asked to enter the following value into the "ACE Profile" 1010 Registry defined in Section 8.8 of [I-D.ietf-ace-oauth-authz]. 1012 o Name: coap_group_oscore 1014 o Description: Profile to secure communications between constrained 1015 nodes using the Authentication and Authorization for Constrained 1016 Environments framework, by enabling authentication and fine- 1017 grained authorization of members of an OSCORE group, that use a 1018 pre-established Group OSCORE Security Context to communicate with 1019 Group OSCORE. Optionally, the dual mode defined in Appendix A 1020 additionally establishes a pairwise OSCORE Security Context, and 1021 thus also enables OSCORE communication between two members of the 1022 OSCORE group. 1024 o CBOR Value: TBD (value between 1 and 255) 1026 o Reference: [[this document]] 1028 10.2. OAuth Parameters Registry 1030 IANA is asked to enter the following values into the "OAuth 1031 Parameters" Registry defined in Section 11.2 of [RFC6749]. 1033 o Name: "context_id" 1035 o Parameter Usage Location: token request 1037 o Change Controller: IESG 1039 o Specification Document(s): Section 3.1.1 of [[this document]] 1041 o Name: "salt_input" 1042 o Parameter Usage Location: token request 1044 o Change Controller: IESG 1046 o Specification Document(s): Section 3.1.2 of [[this document]] 1048 o Name: "client_cred_verify" 1050 o Parameter Usage Location: token request 1052 o Change Controller: IESG 1054 o Specification Document(s): Section 3.1.3 of [[this document]] 1056 o Name: "client_cred" 1058 o Parameter Usage Location: token request 1060 o Change Controller: IESG 1062 o Specification Document(s): Appendix A.2.1.1 of [[this document]] 1064 10.3. OAuth Parameters CBOR Mappings Registry 1066 IANA is asked to enter the following values into the "OAuth 1067 Parameters CBOR Mappings" Registry defined in Section 8.10 of 1068 [I-D.ietf-ace-oauth-authz]. 1070 o Name: "context_id" 1072 o CBOR Key: TBD1 1074 o Value Type: bstr 1076 o Reference: Section 3.1.1 of [[this document]] 1078 o Name: "salt_input" 1080 o CBOR Key: TBD2 1082 o Value Type: bstr 1084 o Reference: Section 3.1.2 of [[this document]] 1085 o Name: "client_cred_verify" 1087 o CBOR Key: TBD3 1089 o Value Type: bstr 1091 o Reference: Section 3.1.3 of [[this document]] 1093 o Name: "client_cred" 1095 o CBOR Key: TBD6 1097 o Value Type: bstr 1099 o Reference: Appendix A.2.1.1 of [[this document]] 1101 10.4. CBOR Web Token Claims Registry 1103 IANA is asked to enter the following values into the "CBOR Web Token 1104 Claims" Registry defined in Section 9.1 of [RFC8392]. 1106 o Claim Name: "salt_input" 1108 o Claim Description: Client provided salt input 1110 o JWT Claim Name: "N/A" 1112 o Claim Key: TBD4 1114 o Claim Value Type(s): bstr 1116 o Change Controller: IESG 1118 o Specification Document(s): Section 3.2.1 of [[this document]] 1120 o Claim Name: "contextId_input" 1122 o Claim Description: Client context id input 1124 o JWT Claim Name: "N/A" 1126 o Claim Key: TBD5 1128 o Claim Value Type(s): bstr 1130 o Change Controller: IESG 1131 o Specification Document(s): Section 3.2.2 of [[this document]] 1133 o Claim Name: "client_cred" 1135 o Claim Description: Client Credential 1137 o JWT Claim Name: "N/A" 1139 o Claim Key: TBD7 1141 o Claim Value Type(s): map 1143 o Change Controller: IESG 1145 o Specification Document(s): Appendix A.2.2.2 of [[this document]] 1147 10.5. TLS Exporter Label Registry 1149 IANA is asked to register the following entry in the "TLS Exporter 1150 Label" Registry defined in Section 6 of [RFC5705] and updated in 1151 Section 12 of [RFC8447]. 1153 o Value: EXPORTER-ACE-Sign-Challenge-Client-AS 1155 o DTLS-OK: Y 1157 o Recommended: N 1159 o Reference: [[this document]] (Section 3.1) 1161 11. References 1163 11.1. Normative References 1165 [I-D.ietf-ace-key-groupcomm-oscore] 1166 Tiloca, M., Park, J., and F. Palombini, "Key Management 1167 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1168 oscore-09 (work in progress), November 2020. 1170 [I-D.ietf-ace-oauth-authz] 1171 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1172 H. Tschofenig, "Authentication and Authorization for 1173 Constrained Environments (ACE) using the OAuth 2.0 1174 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 1175 (work in progress), June 2020. 1177 [I-D.ietf-ace-oauth-params] 1178 Seitz, L., "Additional OAuth Parameters for Authorization 1179 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 1180 params-13 (work in progress), April 2020. 1182 [I-D.ietf-ace-oscore-profile] 1183 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1184 "OSCORE Profile of the Authentication and Authorization 1185 for Constrained Environments Framework", draft-ietf-ace- 1186 oscore-profile-13 (work in progress), October 2020. 1188 [I-D.ietf-cbor-7049bis] 1189 Bormann, C. and P. Hoffman, "Concise Binary Object 1190 Representation (CBOR)", draft-ietf-cbor-7049bis-16 (work 1191 in progress), September 2020. 1193 [I-D.ietf-core-groupcomm-bis] 1194 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1195 for the Constrained Application Protocol (CoAP)", draft- 1196 ietf-core-groupcomm-bis-02 (work in progress), November 1197 2020. 1199 [I-D.ietf-core-oscore-groupcomm] 1200 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1201 "Group OSCORE - Secure Group Communication for CoAP", 1202 draft-ietf-core-oscore-groupcomm-10 (work in progress), 1203 November 2020. 1205 [I-D.ietf-cose-rfc8152bis-algs] 1206 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1207 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12 1208 (work in progress), September 2020. 1210 [I-D.ietf-cose-rfc8152bis-struct] 1211 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1212 Structures and Process", draft-ietf-cose-rfc8152bis- 1213 struct-14 (work in progress), September 2020. 1215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1216 Requirement Levels", BCP 14, RFC 2119, 1217 DOI 10.17487/RFC2119, March 1997, 1218 . 1220 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1221 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1222 March 2010, . 1224 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1225 Key Derivation Function (HKDF)", RFC 5869, 1226 DOI 10.17487/RFC5869, May 2010, 1227 . 1229 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1230 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1231 . 1233 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1234 Keranen, A., and P. Hallam-Baker, "Naming Things with 1235 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1236 . 1238 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1239 Application Protocol (CoAP)", RFC 7252, 1240 DOI 10.17487/RFC7252, June 2014, 1241 . 1243 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1244 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1245 May 2017, . 1247 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1248 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1249 May 2018, . 1251 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1252 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1253 . 1255 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1256 "Object Security for Constrained RESTful Environments 1257 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1258 . 1260 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1261 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1262 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 1263 2020, . 1265 11.2. Informative References 1267 [I-D.ietf-ace-dtls-authorize] 1268 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1269 L. Seitz, "Datagram Transport Layer Security (DTLS) 1270 Profile for Authentication and Authorization for 1271 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1272 authorize-14 (work in progress), October 2020. 1274 [I-D.ietf-ace-mqtt-tls-profile] 1275 Sengul, C. and A. Kirby, "Message Queuing Telemetry 1276 Transport (MQTT)-TLS profile of Authentication and 1277 Authorization for Constrained Environments (ACE) 1278 Framework", draft-ietf-ace-mqtt-tls-profile-08 (work in 1279 progress), November 2020. 1281 [I-D.ietf-tls-dtls13] 1282 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1283 Datagram Transport Layer Security (DTLS) Protocol Version 1284 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 1285 2020. 1287 [I-D.tiloca-core-oscore-discovery] 1288 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1289 Groups with the CoRE Resource Directory", draft-tiloca- 1290 core-oscore-discovery-07 (work in progress), November 1291 2020. 1293 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1294 (TLS) Protocol Version 1.2", RFC 5246, 1295 DOI 10.17487/RFC5246, August 2008, 1296 . 1298 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1299 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1300 January 2012, . 1302 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1303 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1304 . 1306 Appendix A. Dual Mode (Group OSCORE & OSCORE) 1308 This appendix defines the dual mode of this profile, which allows 1309 using both OSCORE [RFC8613] and Group OSCORE 1310 [I-D.ietf-core-oscore-groupcomm] as security protocols, by still 1311 relying on a single Access Token. 1313 That is, the dual mode of this profile specifies how a Client uses 1314 CoAP [RFC7252] to communicate to a single Resource Server, or CoAP 1315 over IP multicast [I-D.ietf-core-groupcomm-bis] to communicate to 1316 multiple Resource Servers that are members of a group and share a 1317 common set of resources. 1319 In particular, the dual mode of this profile uses two complementary 1320 security protocols to provide secure communication between the Client 1321 and the Resource Server(s). That is, it defines the use of either 1322 OSCORE or Group OSCORE to protect unicast requests addressed to a 1323 single Resource Server, as well as possible responses. Additionally, 1324 it defines the use of Group OSCORE to protect multicast requests sent 1325 to a group of Resource Servers, as well as possible individual 1326 responses. Like in the main mode of this profile, the Client and the 1327 Resource Servers need to have already joined the same OSCORE group, 1328 for instance by using the approach defined in 1329 [I-D.ietf-ace-key-groupcomm-oscore], which is also based on ACE. 1331 The Client proves its access to be authorized to the Resource Server 1332 by using an Access Token, which is bound to a key (the proof-of- 1333 possession key). This profile mode uses OSCORE to achieve proof of 1334 possession, and OSCORE or Group OSCORE to achieve server 1335 authentication. 1337 Unlike in the main mode of this profile, where a public key is used 1338 as pop-key, this dual mode uses OSCORE-related, symmetric key 1339 material as pop-key instead. Furthermore, this dual mode provides 1340 proof of Client's membership to the correct OSCORE group, by securely 1341 binding the pre-established Group OSCORE Security Context to the 1342 pairwise OSCORE Security Context newly established between the Client 1343 and the Resource Server. 1345 In addition to the terminology used for the main mode of this 1346 profile, the rest of this appendix refers also to "pairwise OSCORE 1347 Security Context" as to an OSCORE Security Context established 1348 between only one Client and one Resource Server, and used to 1349 communicate with OSCORE [RFC8613]. 1351 A.1. Protocol Overview 1353 This section provides an overview on how to use the ACE framework for 1354 authentication and authorization [I-D.ietf-ace-oauth-authz] to secure 1355 communications between a Client and a (set of) Resource Server(s) 1356 using OSCORE [RFC8613] and/or Group OSCORE 1357 [I-D.ietf-core-oscore-groupcomm]. 1359 Just as for main mode of this profile overviewed in Section 2, the 1360 process for joining the OSCORE group through the respective Group 1361 Manager as defined in [I-D.ietf-ace-key-groupcomm-oscore] must take 1362 place before the process described in the rest of this section, and 1363 is out of the scope of this profile. 1365 An overview of the protocol flow for the dual mode of this profile is 1366 shown in Figure 8. In the figure, it is assumed that both RS1 and 1367 RS2 are associated with the same AS. It is also assumed that C, RS1 1368 and RS2 have previously joined an OSCORE group with Group Identifier 1369 (gid) "abcd0000", and got assigned Sender ID (sid) "0", "1" and "2" 1370 in the group, respectively. The names of messages coincide with 1371 those of [I-D.ietf-ace-oauth-authz] when applicable. 1373 C RS1 RS2 AS 1374 | [--- Resource Request --->] | | | 1375 | | | | 1376 | [<---- AS Request ------] | | | 1377 | Creation Hints | | | 1378 | | | | 1379 |-------- POST /token ------------------------------------------------>| 1380 | (aud: RS1, sid: 0, gid: abcd0000, ...) | | 1381 | | | | 1382 |<--------------------------------- Access Token + RS Information -----| 1383 | | (aud: RS1, sid: 0, gid: abcd0000, ...) | 1384 | | | | 1385 |---- POST /authz-info ------>| | | 1386 | (access_token, N1, ID1) | | | 1387 | | | | 1388 |<-- 2.01 Created (N2, ID2) --| | | 1389 | | | | 1390 /Pairwise OSCORE Sec /Pairwise OSCORE Sec | | 1391 Context Derivation/ Context Derivation/ | | 1392 | | | | 1393 |-------- POST /token ------------------------------------------------>| 1394 | (aud: RS2, sid: 0, gid: abcd0000, ...) | | 1395 | | | | 1396 |<--------------------------------- Access Token + RS Information -----| 1397 | | (aud: RS2, sid: 0, gid: abcd0000, ...) | 1398 | | | | 1399 |----- POST /authz-info ------------------>| | 1400 | (access_token, N1', ID1') | | | 1401 | | | | 1402 |<-- 2.01 Created (N2', ID2')--------------| | 1403 | | | | 1404 /Pairwise OSCORE Sec | /Pairwise OSCORE Sec | 1405 Context Derivation/ | Context Derivation/ | 1406 | | | | 1407 |------ OSCORE Request ------>| | | 1408 | (kid: ID2) | | | 1409 | | | | 1410 | /proof-of-possession | | 1411 | Sec Context storage/ | | 1412 | | | | 1413 |<----- OSCORE Response ------| | | 1414 | | | | 1415 /proof-of-possession | | | 1416 Sec Context storage/ | | | 1417 | | | | 1418 |-- Group OSCORE Request -+-->| | | 1419 | (kid: 0, gid: abcd0000) \-------------->| | 1420 | | | | 1421 |<--- Group OSCORE Response --| | | 1422 | (kid: 1) | | | 1423 | | | | 1424 |<--- Group OSCORE Response ---------------| | 1425 | (kid: 2) | | | 1426 | ... | | | 1428 Figure 8: Protocol Overview. 1430 A.1.1. Pre-Conditions 1432 The same pre-conditions for the main mode of this profile (see 1433 Section 2.1) hold for the dual mode described in this appendix. 1435 A.1.2. Access Token Posting 1437 After having retrieved the Access Token from the AS, the Client 1438 generates a nonce N1 and an identifier ID1 unique in the sets of its 1439 own Recipient IDs from its pairwise OSCORE Security Contexts. The 1440 client then posts both the Access Token, N1 and its chosen ID to the 1441 RS, using the /authz-info endpoint and mechanisms specified in 1442 Section 5.8 of [I-D.ietf-ace-oauth-authz] and Content-Format = 1443 application/ace+cbor. When using the dual mode of this profile, the 1444 communication with the authz-info endpoint is not protected, except 1445 for update of access rights. Note that, when using the dual mode, 1446 this request can alternatively be protected with Group OSCORE, using 1447 the Group OSCORE Security Context paired with the pairwise OSCORE 1448 Security Context originally established with the first Access Token 1449 posting. 1451 If the Access Token is valid, the RS replies to this POST request 1452 with a 2.01 (Created) response with Content-Format = application/ 1453 ace+cbor, which in a CBOR map contains a nonce N2 and an identifier 1454 ID2 unique in the sets of its own Recipient IDs from its pairwise 1455 OSCORE Security Contexts. 1457 A.1.3. Setup of the Pairwise OSCORE Security Context 1459 After sending the 2.01 (Created) response, the RS sets the ID Context 1460 of the pairwise OSCORE Security Context (see Section 3 of [RFC8613]) 1461 to the Group Identifier of the OSCORE group specified in the Access 1462 Token, concatenated with N1, concatenated with N2, concatenated with 1463 the value in the contextId parameter of the OSCORE_Input_Material 1464 provided in the 'cnf' claim of the Access Token. 1466 Then, the RS derives the complete pairwise OSCORE Security Context 1467 associated with the received Access Token, following Section 3.2 of 1468 [RFC8613]. In practice, the RS maintains a collection of Security 1469 Contexts with associated authorization information, for all the 1470 clients that it is currently communicating with, and the 1471 authorization information is a policy used as input when processing 1472 requests from those clients. 1474 During the derivation process, the RS uses: the ID Context above; the 1475 nonces N1 and N2; the identifier ID1 received from the Client, set as 1476 its own OSCORE Sender ID; the identifier ID2 provided to the Client, 1477 set as its Recipient ID for the Client; and the parameters in the 1478 Access Token. The derivation process uses also the Master Secret of 1479 the OSCORE group, that the RS knows as a group member, as well as the 1480 Sender ID of the Client in the OSCORE group, which is specified in 1481 the Access Token. This ensures that the pairwise OSCORE Security 1482 Context is securely bound to the Group OSCORE Security Context of the 1483 OSCORE group. 1485 Finally, the RS stores the association between i) the authorization 1486 information from the Access Token; and ii) the Group Identifier of 1487 the OSCORE group together with the Sender ID and the public key of 1488 the Client in that group. 1490 After having received the nonce N2, the Client sets the ID Context in 1491 its pairwise OSCORE Security Context (see Section 3 of [RFC8613]) to 1492 the Group Identifier of the OSCORE group, concatenated with N1, 1493 concatenated with N2, concatenated with the value in the contextId 1494 parameter of the OSCORE_Input_Material provided in the 'cnf' 1495 parameter of the Access Token response from the AS. Then, the Client 1496 derives the complete pairwise OSCORE Security Context, following 1497 Section 3.2 of [RFC8613]. 1499 During the derivation process, the Client uses: the ID Context above, 1500 the nonces N1 and N2; the identifier ID1 provided to the RS, set as 1501 its own Recipient ID for the RS; the identifier ID2 received from the 1502 RS, set as its own OSCORE Sender ID; and the parameters received from 1503 the AS. The derivation process uses also the Master Secret of the 1504 OSCORE group, that the Client knows as a group member, as well as its 1505 own Sender ID in the OSCORE group. 1507 When the Client communicates with the RS using the pairwise OSCORE 1508 Security Context, the RS achieves proof-of-possession of the 1509 credentials bound to the Access Token. Also, the RS verifies that 1510 the Client is a legitimate member of the OSCORE group. 1512 A.1.4. Secure Communication 1514 The Client can send a request protected with OSCORE to the RS. 1516 If the request is correctly verified, then the RS stores the pairwise 1517 OSCORE Security Context, and uses it to protect the possible 1518 response, as well as further communications with the Client, until 1519 the Access Token expires. This pairwise OSCORE Security Context is 1520 discarded when an Access Token (whether the same or different) is 1521 used to successfully derive a new pairwise OSCORE Security Context. 1523 As discussed in Section 2 of [I-D.ietf-ace-oscore-profile], the use 1524 of random nonces N1 and N2 during the exchange between the Client and 1525 the RS prevents the reuse of AEAD nonces and keys with different 1526 messages including the possibility of two-time pads, in case of re- 1527 derivation of the pairwise OSCORE Security Context both for Clients 1528 and Resource Servers from an old non-expired Access Token, e.g. in 1529 case of reboot of either the Client or the RS. 1531 Additionally, just as per the main mode of this profile (see 1532 Section 4.3), the Client and RS can also securely communicate by 1533 protecting messages with Group OSCORE, using the Group OSCORE 1534 Security Context already established upon joining the OSCORE group. 1536 A.2. Client-AS Communication 1538 This section details the Access Token POST Request that the Client 1539 sends to the /token endpoint of the AS, as well as the related Access 1540 Token response. 1542 Section 3.2 of [RFC8613] defines how to derive a pairwise OSCORE 1543 Security Context based on a shared Master Secret and a set of other 1544 parameters, established between the OSCORE client and server, which 1545 the client receives from the AS in this exchange. 1547 The proof-of-possession key (pop-key) received from the AS in this 1548 exchange MUST be used to build the Master Secret in OSCORE (see 1549 Appendix A.3.3 and Appendix A.3.4). 1551 A.2.1. C-to-AS: POST to Token Endpoint 1553 The Client-to-AS request is specified in Section 5.6.1 of 1554 [I-D.ietf-ace-oauth-authz]. The Client MUST send this POST request 1555 to the /token endpoint over a secure channel that guarantees 1556 authentication, message integrity and confidentiality. 1558 The POST request is formatted as the analogous Client-to-AS request 1559 in the main mode of this profile (see Section 3.1), with the 1560 following modifications. 1562 o The parameter 'req_cnf' MUST NOT be included in the payload. 1564 o The parameter 'client_cred', defined in Appendix A.2.1.1 of this 1565 specification, MUST be included in the payload. This parameter 1566 includes the public key associated to the signing private key that 1567 the Client uses in the OSCORE group, whose identifier is indicated 1568 in the 'context_id' parameter. 1570 o The signature included in the parameter 'client_cred_verify' is 1571 computed by using the private key associated to the public key in 1572 the 'client_cred' parameter above. 1574 An example of such a request, with payload in CBOR diagnostic 1575 notation without the tag and value abbreviations is reported in 1576 Figure 9. 1578 Header: POST (Code=0.02) 1579 Uri-Host: "as.example.com" 1580 Uri-Path: "token" 1581 Content-Format: "application/ace+cbor" 1582 Payload: 1583 { 1584 "audience" : "tempSensor4711", 1585 "scope" : "read", 1586 "context_id" : h'abcd0000', 1587 "salt_input" : h'00', 1588 "client_cred" : { 1589 "COSE_Key" : { 1590 "kty" : EC2, 1591 "crv" : P-256, 1592 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 1593 27c9e354089bbe13', 1594 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 1595 731e79a3b4e47120' 1596 } 1597 }, 1598 "client_cred_verify" : h'...' 1599 (signature content omitted for brevity), 1600 } 1602 Figure 9: Example C-to-AS POST /token request for an Access Token 1603 bound to a symmetric key. 1605 Later on, the Client may want to update its current access rights, 1606 without changing the existing pairwise OSCORE Security Context with 1607 the RS. In this case, the Client MUST include in its POST request to 1608 the /token endpoint a 'req_cnf' parameter, defined in Section 3.1 of 1609 [I-D.ietf-ace-oauth-params], which MUST include a 'kid' field, as 1610 defined in Section 3.1 of [RFC8747]. The 'kid' field has as value a 1611 CBOR byte string containing the OSCORE_Input_Material Identifier 1612 (assigned as discussed in Appendix A.2.2). 1614 This identifier, together with other information such as audience, 1615 can be used by the AS to determine the shared secret bound to the 1616 proof-of-possession Access Token and therefore MUST identify a 1617 symmetric key that was previously generated by the AS as a shared 1618 secret for the communication between the Client and the RS. The AS 1619 MUST verify that the received value identifies a proof-of-possession 1620 key that has previously been issued to the requesting Client. If 1621 that is not the case, the Client-to-AS request MUST be declined with 1622 the error code 'invalid_request' as defined in Section 5.6.3 of 1623 [I-D.ietf-ace-oauth-authz]. 1625 This POST request for updating the rights of an Access Token MUST NOT 1626 include the parameters 'salt_input', 'context_id', 'client_cred' and 1627 'client_cred_verify'. 1629 An example of such a request, with payload in CBOR diagnostic 1630 notation without the tag and value abbreviations is reported in 1631 Figure 10. 1633 Header: POST (Code=0.02) 1634 Uri-Host: "as.example.com" 1635 Uri-Path: "token" 1636 Content-Format: "application/ace+cbor" 1637 Payload: 1638 { 1639 "audience" : "tempSensor4711", 1640 "scope" : "read", 1641 "req_cnf" : { 1642 "kid" : h'01' 1643 } 1644 } 1646 Figure 10: Example C-to-AS POST /token request for updating rights to 1647 an Access Token bound to a symmetric key. 1649 A.2.1.1. 'client_cred' Parameter 1651 The 'client_cred' parameter is an OPTIONAL parameter of the Access 1652 Token request message defined in Section 5.6.1. of 1653 [I-D.ietf-ace-oauth-authz]. This parameter provides an asymmetric 1654 key that the Client wishes to use as its own public key, but which is 1655 not used as proof-of-possession key. 1657 This parameter follows the syntax of the 'cnf' claim from Section 3.1 1658 of [RFC8747] when including Value Type "COSE_Key" (1) and specifying 1659 an asymmetric key. Alternative Value Types defined in future 1660 specifications are fine to consider if indicating a non-encrypted 1661 asymmetric key. 1663 A.2.2. AS-to-C: Access Token 1665 After having verified the POST request to the /token endpoint and 1666 that the Client is authorized to obtain an Access Token corresponding 1667 to its Access Token request, the AS MUST verify the signature in the 1668 'client_cred_verify' parameter, by using the public key specified in 1669 the 'client_cred' parameter. If the verification fails, the AS 1670 considers the Client request invalid. The AS does not perform this 1671 operation when asked to update a previously released Access Token. 1673 If all verifications are successful, the AS responds as defined in 1674 Section 5.6.2 of [I-D.ietf-ace-oauth-authz]. If the Client request 1675 was invalid, or not authorized, the AS returns an error response as 1676 described in Section 5.6.3 of [I-D.ietf-ace-oauth-authz]. 1678 The AS can signal that the use of OSCORE and Group OSCORE is REQUIRED 1679 for a specific Access Token by including the 'profile' parameter with 1680 the value "coap_group_oscore" in the Access Token response. This 1681 means that the Client MUST use OSCORE and/or Group OSCORE towards all 1682 the Resource Servers for which this Access Token is valid. 1684 In particular, the Client MUST follow Appendix A.3.3 to derive the 1685 pairwise OSCORE Security Context to use for communications with the 1686 RS. Instead, the Client has already established the related Group 1687 OSCORE Security Context to communicate with members of the OSCORE 1688 group, upon previously joining that group. 1690 Usually, it is assumed that constrained devices will be pre- 1691 configured with the necessary profile, so that this kind of profile 1692 negotiation can be omitted. 1694 In contrast with the main mode of this profile, the Access Token 1695 response to the Client is analogous to the one in the OSCORE profile 1696 of ACE, as described in Section 3.2 of [I-D.ietf-ace-oscore-profile]. 1697 In particular, the AS provides an OSCORE_Input_Material object, which 1698 is defined in Section 3.2.1 of [I-D.ietf-ace-oscore-profile] and 1699 included in the 'cnf' parameter (see Section 3.2 of 1700 [I-D.ietf-ace-oauth-params]) of the Access Token response. 1702 The AS MUST send different OSCORE_Input_Material (and therefore 1703 different Access Tokens) to different authorized clients, in order 1704 for the RS to differentiate between clients. 1706 In the issued Access Token, the AS MUST include as metadata the same 1707 information as defined in the main mode of this profile (see 1708 Section 3.2) with the following modifications. 1710 o The public key that the client uses in the OSCORE group and 1711 specified in the 'client_cred' parameter of the Token request (see 1712 Appendix A.2.1) MUST also be included in the Access Token. If the 1713 Access Token is a CWT, the AS MUST include it in the 'client_cred' 1714 claim of the Access Token, defined in Appendix A.2.2.2 of this 1715 specification. 1717 o The OSCORE_Input_Material specified in the 'cnf' parameter of the 1718 Access Token response MUST also be included in the Access Token. 1719 If the Access Token is a CWT, the same OSCORE_Input_Material 1720 included in the 'cnf' parameter of the Access Token response MUST 1721 be included in the 'osc' field (see Section 9.5 of 1722 [I-D.ietf-ace-oscore-profile]) of the 'cnf' claim of the Access 1723 Token. 1725 Figure 11 shows an example of such an AS response, with payload in 1726 CBOR diagnostic notation without the tag and value abbreviations. 1728 Header: Created (Code=2.01) 1729 Content-Type: "application/ace+cbor" 1730 Payload: 1731 { 1732 "access_token" : h'8343a1010aa2044c53 ...' 1733 (remainder of CWT omitted for brevity), 1734 "profile" : "coap_group_oscore", 1735 "expires_in" : 3600, 1736 "cnf" : { 1737 "osc" : { 1738 "alg" : "AES-CCM-16-64-128", 1739 "id" : h'01', 1740 "ms" : h'f9af838368e353e78888e1426bd94e6f', 1741 "salt" : h'1122', 1742 "contextId" : h'99' 1743 } 1744 } 1745 } 1747 Figure 11: Example AS-to-C Access Token response with the Group 1748 OSCORE profile. 1750 Figure 12 shows an example CWT, containing the necessary OSCORE 1751 parameters in the 'cnf' claim, in CBOR diagnostic notation without 1752 tag and value abbreviations. 1754 { 1755 "aud" : "tempSensorInLivingRoom", 1756 "iat" : "1360189224", 1757 "exp" : "1360289224", 1758 "scope" : "temperature_g firmware_p", 1759 "cnf" : { 1760 "osc" : { 1761 "alg" : "AES-CCM-16-64-128", 1762 "id" : h'01', 1763 "ms" : h'f9af838368e353e78888e1426bd94e6f', 1764 "salt" : h'1122', 1765 "contextId" : h'99' 1766 }, 1767 "salt_input" : h'00', 1768 "contextId_input" : h'abcd0000', 1769 "client_cred" : { 1770 "COSE_Key" : { 1771 "kty" : EC2, 1772 "crv" : P-256, 1773 "x" : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa 1774 27c9e354089bbe13', 1775 "y" : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020 1776 731e79a3b4e47120' 1777 } 1778 } 1779 } 1781 Figure 12: Example CWT with OSCORE parameters (CBOR diagnostic 1782 notation). 1784 The same CWT as in Figure 12 and encoded in CBOR is shown in 1785 Figure 13, using the value abbreviations defined in 1786 [I-D.ietf-ace-oauth-authz] and [RFC8747]. 1788 NOTE: it should be checked (and in case fixed) that the values used 1789 below (which are not yet registered) are the final values registered 1790 in IANA. 1792 A8 # map(8) 1793 03 # unsigned(3) 1794 76 # text(22) 1795 74656D7053656E736F72496E4C6976696E67526F6F6D 1796 06 # unsigned(6) 1797 1A 5112D728 # unsigned(1360189224) 1798 04 # unsigned(4) 1799 1A 51145DC8 # unsigned(1360289224) 1800 09 # unsigned(9) 1801 78 18 # text(24) 1802 74656D70657261747572655F67206669726D776172655F70 1803 08 # unsigned(8) 1804 A1 # map(1) 1805 04 # unsigned(4) 1806 A5 # map(5) 1807 04 # unsigned(4) 1808 0A # unsigned(10) 1809 02 # unsigned(2) 1810 41 # bytes(1) 1811 01 # "\x01" 1812 01 # unsigned(1) 1813 50 # bytes(16) 1814 F9AF838368E353E78888E1426BD94E6F 1815 05 # unsigned(5) 1816 42 # bytes(2) 1817 1122 # "\x11\"" 1818 06 # unsigned(6) 1819 41 # bytes(1) 1820 99 # "\x99" 1821 18 3C # unsigned(60) 1822 41 # bytes(1) 1823 00 1824 18 3D # unsigned(61) 1825 44 # bytes(4) 1826 ABCD0000 1827 18 3E # unsigned(62) 1828 A1 # map(1) 1829 01 # unsigned(1) 1830 A4 # map(4) 1831 01 # unsigned(1) 1832 02 # unsigned(2) 1833 20 # negative(0) 1834 01 # unsigned(1) 1835 21 # negative(1) 1836 58 20 # bytes(32) 1837 D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9 1838 E354089BBE13 1839 22 # negative(2) 1840 58 20 # bytes(32) 1841 F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E515D020731E 1842 79A3B4E47120 1844 Figure 13: Example CWT with OSCORE parameters. 1846 If the Client has requested an update to its access rights using the 1847 same pairwise OSCORE Security Context, which is valid and authorized, 1848 the AS MUST omit the 'cnf' parameter in the response to the client. 1850 Instead, the updated Access Token conveyed in the AS-to-C response 1851 MUST include a 'cnf' claim specifying a 'kid' field, as defined in 1852 Section 3.1 of [RFC8747]. The response from the AS MUST carry the 1853 OSCORE Input Material identifier in the 'kid' field within the 'cnf' 1854 claim of the Access Token. That is, the 'kid' field is a CBOR byte 1855 string, with value the same value of the 'kid' field of the 'req_cnf' 1856 parameter from the C-to-AS request for updating rights to the Access 1857 Token (see Figure 10). This information needs to be included in the 1858 Access Token, in order for the RS to identify the previously 1859 generated pairwise OSCORE Security Context. 1861 Figure 14 shows an example of such an AS response, with payload in 1862 CBOR diagnostic notation without the tag and value abbreviations. 1863 The Access Token has been truncated for readability. 1865 Header: Created (Code=2.01) 1866 Content-Type: "application/ace+cbor" 1867 Payload: 1868 { 1869 "access_token" : h'8343a1010aa2044c53 ...' 1870 (remainder of CWT omitted for brevity), 1871 "profile" : "coap_group_oscore", 1872 "expires_in" : 3600 1873 } 1875 Figure 14: Example AS-to-C Access Token response with the Group 1876 OSCORE profile, for update of access rights. 1878 Figure 15 shows an example CWT, containing the necessary OSCORE 1879 parameters in the 'cnf' claim for update of access rights, in CBOR 1880 diagnostic notation without tag and value abbreviations. 1882 { 1883 "aud" : "tempSensorInLivingRoom", 1884 "iat" : "1360189224", 1885 "exp" : "1360289224", 1886 "scope" : "temperature_h", 1887 "cnf" : { 1888 "kid" : h'01' 1889 } 1890 } 1892 Figure 15: Example CWT with OSCORE parameters for update of access 1893 rights. 1895 A.2.2.1. Public Key Hash as Client Credential 1897 As a possible optimization to limit the size of the Access Token, the 1898 AS may specify as value of the 'client_cred' claim simply the hash of 1899 the Client's public key. The specifically used hash-function MUST be 1900 collision-resistant on byte-strings, and MUST be selected from the 1901 "Named Information Hash Algorithm" Registry defined in Section 9.4 of 1902 [RFC6920]. 1904 In particular, the AS provides the Client with an Access Token as 1905 defined in Appendix A.2.2, with the following differences. 1907 The AS prepares INPUT_HASH as follows, with | denoting byte string 1908 concatenation. 1910 o If the public key has COSE Key Type OKP, INPUT_HASH = i, where 'i' 1911 is the x-parameter of the COSE_Key specified in the 'client_cred' 1912 parameter of the Token request, encoded as a CBOR byte string. 1914 o If the public key has COSE Key Type EC2, INPUT_HASH = (i_1 | i_2), 1915 where 'i_1' and 'i_2' are the x-parameter and y-parameter of the 1916 COSE_Key specified in the 'client_cred' parameter of the Token 1917 request, respectively, each encoded as a CBOR byte string. 1919 o If the public key has COSE Key Type RSA, INPUT_HASH = (i_1 | i_2), 1920 where 'i_1' and 'i_2' are the n-parameter and e-parameter of the 1921 COSE_Key specified in the 'client_cred' parameter of the Token 1922 request, respectively, each encoded as a CBOR byte string. 1924 Then, the AS hashes INPUT_HASH according to the procedure described 1925 in [RFC6920], with the output OUTPUT_HASH in binary format, as 1926 described in Section 6 of [RFC6920]. 1928 Finally, the AS includes a single entry within the 'client_cred' 1929 claim of the Access Token. This entry has label "kid" (3) defined in 1930 Section 3.1 of [RFC8747], and value a CBOR byte string wrapping 1931 OUTPUT_HASH. 1933 Upon receiving the Access Token, the RS processes it according to 1934 Appendix A.3.2, with the following differences. 1936 The RS considers the content of the 'client_cred' claim as the hash 1937 of the public key associated to the signing private key that the 1938 Client uses in the OSCORE group, which is identified by the 1939 'context_id' parameter. 1941 The RS MAY additionally request the Group Manager of the OSCORE group 1942 for the public key of that Client, as described in 1944 [I-D.ietf-ace-key-groupcomm-oscore], specifying as Sender ID of that 1945 Client in the OSCORE group the value of the 'salt_input' claim 1946 included in the Access Token. 1948 In such a case, the RS MUST check that the hash of the key retrieved 1949 from the Group Manager matches the hash retrieved from the 1950 'client_cred' claim of the Access Token. The RS MUST calculate the 1951 hash using the same method as the AS described above, and using the 1952 same hash function. The hash function used can be determined from 1953 the information conveyed in the 'client_cred' claim, as the procedure 1954 described in [RFC6920] also encodes the used hash function as 1955 metadata of the hash value. 1957 A.2.2.2. Client Credential Claim 1959 The 'client_cred' claim provides an asymmetric key that the Client 1960 owning the Access Token wishes to use as its own public key, but 1961 which is not used as proof-of-possession key. 1963 This parameter follows the syntax of the 'cnf' claim from Section 3.1 1964 of [RFC8747] when including Value Type "COSE_Key" (1) and specifying 1965 an asymmetric key. Alternative Value Types defined in future 1966 specifications are fine to consider if indicating a non-encrypted 1967 asymmetric key. 1969 A.3. Client-RS Communication 1971 This section details the POST request and response to the /authz-info 1972 endpoint between the Client and the RS. With respect to the 1973 exchanged messages and their content, the Client and the RS perform 1974 as defined in Section 4 of the OSCORE profile of ACE 1975 [I-D.ietf-ace-oscore-profile]. 1977 That is, the Client generates a nonce N1 and posts it to the RS, 1978 together with: an identifier ID1 unique in the sets of its own 1979 Recipient IDs from its pairwise OSCORE Security Contexts; and the 1980 Access Token that includes the material provisioned by the AS. 1982 Then, the RS generates a nonce N2, and an identifier ID2 unique in 1983 the sets of its own Recipient IDs from its pairwise OSCORE Security 1984 Contexts. After that, the RS derives a pairwise OSCORE Security 1985 Context as described in Section 3.2 of [RFC8613]. In particular, it 1986 uses the two nonces and the two identifiers established with the 1987 Client, as well as two shared secrets together with additional pieces 1988 of information specified in the Access Token. 1990 Both the client and the RS generate the pairwise OSCORE Security 1991 Context using the pop-key as part of the OSCORE Master Secret. In 1992 addition, the derivation of the pairwise OSCORE Security Context 1993 takes as input also information related to the OSCORE group, i.e. the 1994 Master Secret and Group Identifier of the group, as well as the 1995 Sender ID of the Client in the group. Hence, the derived pairwise 1996 OSCORE Security Context is also securely bound to the Group OSCORE 1997 Security Context of the OSCORE Group. Thus, the proof-of-possession 1998 required to bind the Access Token to the Client occurs after the 1999 first OSCORE message exchange. 2001 Therefore, an attacker using a stolen Access Token cannot generate a 2002 valid pairwise OSCORE Security Context and thus cannot prove 2003 possession of the pop-key. Also, if a Client legitimately owns an 2004 Access Token but has not joined the OSCORE group, that Client cannot 2005 generate a valid pairwise OSCORE Security Context either, since it 2006 lacks the Master Secret used in the OSCORE group. 2008 Besides, just as in the main mode (see Section 4), the RS is able to 2009 verify whether the Client has indeed the claimed Sender ID and public 2010 key in the OSCORE group. 2012 A.3.1. C-to-RS POST to authz-info Endpoint 2014 The Client MUST generate a nonce N1, an OSCORE Recipient ID (ID1), 2015 and post them to the /authz-info endpoint of the RS together with the 2016 Access Token, as defined in Section 4.1 of the OSCORE profile of ACE 2017 [I-D.ietf-ace-oscore-profile]. 2019 The same recommendations, considerations and behaviors defined in 2020 Section 4.1 of [I-D.ietf-ace-oscore-profile] hold. 2022 If the Client has already posted a valid Access Token, has already 2023 established a pairwise OSCORE Security Context with the RS, and wants 2024 to update its access rights, the Client can do so by posting the new 2025 Access Token (retrieved from the AS and specifying the updated set of 2026 access rights) to the /authz-info endpoint. 2028 The Client MUST protect the request using either the pairwise OSCORE 2029 Security Context established during the first Access Token exchange, 2030 or the Group OSCORE Security Context associated to that pairwise 2031 OSCORE Security Context. 2033 In either case, the Client MUST only send the Access Token in the 2034 payload, i.e. no nonce or identifier are sent. After proper 2035 verification (see Section 4.2 of [I-D.ietf-ace-oscore-profile]), the 2036 RS will replace the old Access Token with the new one, maintaining 2037 the same pairwise OSCORE Security Context and Group OSCORE Security 2038 Context. 2040 A.3.2. RS-to-C: 2.01 (Created) 2042 The RS MUST verify the validity of the Access Token as defined in 2043 Section 4.2, with the following modifications. 2045 o The RS checks that the 'cnf' claim is included in the Access Token 2046 and that it contains an OSCORE_Input_Material object. 2048 o The RS checks that the 'client_cred' claim is included in the 2049 Access Token. 2051 o The RS considers the content of the 'client_cred' claim as the 2052 public key associated to the signing private key of the Client in 2053 the OSCORE group, whose GID is specified in the 'contextId_input' 2054 claim. The RS can compare this public key with the public key of 2055 the claimed Client retrieved from the Group Manager (see 2056 Section 4.2). 2058 If any of the checks fails, the RS MUST consider the Access Token non 2059 valid, and MUST respond to the Client with an error response code 2060 equivalent to the CoAP code 4.00 (Bad Request). 2062 If the Access Token is valid and further checks on its content are 2063 successful, the RS MUST generate a nonce N2, an OSCORE Recipient ID 2064 (ID2), and include them in the 2.01 (Created) response to the Client, 2065 as defined in Section 4.2 of the OSCORE profile of ACE 2066 [I-D.ietf-ace-oscore-profile]. 2068 Further recommendations, considerations and behaviors defined in 2069 Section 4.2 of [I-D.ietf-ace-oscore-profile] hold for this 2070 specification. 2072 A.3.3. OSCORE Setup - Client Side 2074 Once having received the 2.01 (Created) response from the RS, 2075 following the POST request to the authz-info endpoint, the Client 2076 MUST extract the nonce N2 from the 'nonce2' parameter, and the Client 2077 identifier from the 'ace_server_recipientid' parameter in the CBOR 2078 map of the response payload. Note that this identifier is used by C 2079 as Sender ID in the pairwise OSCORE Security Context to be 2080 established with the RS, and is different as well as unrelated to the 2081 Sender ID of C in the OSCORE group. 2083 Then, the Client performs the following actions, in order to set up 2084 and fully derive the pairwise OSCORE Security Context for 2085 communicating with the RS. 2087 o The Client MUST set the ID Context of the pairwise OSCORE Security 2088 Context as the concatenation of: i) GID, i.e. the Group Identifier 2089 of the OSCORE group, as specified by the Client in the 2090 'context_id' parameter of the Client-to-AS request; ii) the nonce 2091 N1; iii) the nonce N2; and iv) CID, i.e. the value in the 2092 contextId parameter of the OSCORE_Input_Material provided in the 2093 'cnf' parameter of the Access Token response from the AS. The 2094 concatenation occurs in this order: ID Context = GID | N1 | N2 | 2095 CID, where | denotes byte string concatenation. 2097 o The Client MUST set the updated Master Salt of the pairwise OSCORE 2098 Security Context as the concatenation of SaltInput, MSalt, the 2099 nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the 2100 Sender ID that the Client has in the OSCORE group, which is known 2101 to the Client as a member of the OSCORE group; ii) MSalt is the 2102 (optional) Master Salt in the pairwise OSCORE Security Context 2103 (received from the AS in the Token); and iii) GMSalt is the 2104 (optional) Master Salt in the Group OSCORE Security Context, which 2105 is known to the Client as a member of the OSCORE group. The 2106 concatenation occurs in this order: Master Salt = SaltInput | 2107 MSalt | N1 | N2 | GMSalt, where | denotes byte string 2108 concatenation. Optional values, if not specified, are not 2109 included in the concatenation. The five parameters SaltInput, 2110 MSalt, N1, N2 and GMSalt are to be concatenated as encoded CBOR 2111 byte strings. An example of Master Salt construction using CBOR 2112 encoding is given in Figure 16. 2114 SaltInput, MSalt, N1, N2 and GMSalt, in CBOR diagnostic notation: 2115 SaltInput = h'00' 2116 MSalt = h'f9af838368e353e78888e1426bd94e6f' 2117 N1 = h'018a278f7faab55a' 2118 N2 = h'25a8991cd700ac01' 2119 GMSalt = h'99' 2121 SaltInput, MSalt, N1, N2 and GMSalt, as CBOR encoded byte strings: 2122 SaltInput = 0x4100 2123 MSalt = 0x50f9af838368e353e78888e1426bd94e6f 2124 N1 = 0x48018a278f7faab55a 2125 N2 = 0x4825a8991cd700ac01 2126 GMSalt = 0x4199 2128 Master Salt = 0x41 00 2129 50 f9af838368e353e78888e1426bd94e6f 2130 48 018a278f7faab55a 2131 48 25a8991cd700ac01 2132 41 99 2134 Figure 16: Example of Master Salt construction using CBOR encoding. 2136 o The Client MUST set the Master Secret of the pairwise OSCORE 2137 Security Context to the concatenation of MSec and GMSec, where: i) 2138 MSec is the value of the 'ms' parameter in the 2139 OSCORE_Input_Material of the 'cnf' parameter, received from the AS 2140 in Appendix A.2.2; while ii) GMSec is the Master Secret of the 2141 Group OSCORE Security Context, which is known to the Client as a 2142 member of the OSCORE group. 2144 o The Client MUST set the Recipient ID as ace_client_recipientid, 2145 sent as described in Appendix A.3.1. 2147 o The Client MUST set the Sender ID as ace_server_recipientid, 2148 received as described in Appendix A.3.1. 2150 o The Client MUST set the AEAD Algorithm, ID Context, HKDF, and 2151 OSCORE Version as indicated in the corresponding parameters 2152 received from the AS in Appendix A.2.2, if present in the 2153 OSCORE_Input_Material of the 'cnf' parameter. In case these 2154 parameters are omitted, the default values SHALL be used as 2155 described in Section 3.2 and 5.4 of [RFC8613]. 2157 Finally, the client MUST derive the complete pairwise OSCORE Security 2158 Context following Section 3.2.1 of [RFC8613]. 2160 From then on, when communicating with the RS to access the resources 2161 as specified by the authorization information, the Client MUST use 2162 the newly established pairwise OSCORE Security Context or the Group 2163 OSCORE Security Context of the OSCORE Group where both the Client and 2164 the RS are members. 2166 If any of the expected parameters is missing (e.g., any of the 2167 mandatory parameters from the AS or the RS), or if 2168 ace_client_recipientid equals ace_server_recipientid, then the client 2169 MUST stop the exchange, and MUST NOT derive the pairwise OSCORE 2170 Security Context. The Client MAY restart the exchange, to get the 2171 correct security material. 2173 The Client can use this pairwise OSCORE Security Context to send 2174 requests to the RS protected with OSCORE. Besides, the Client can 2175 use the Group OSCORE Security Context for protecting unicast requests 2176 to the RS, or multicast requests to the OSCORE group including also 2177 the RS. 2179 Note that the ID Context of the pairwise OSCORE Security Context can 2180 be assigned by the AS, communicated and set in both the RS and Client 2181 after the exchange specified in this profile is executed. 2182 Subsequently, the Client and RS can update their ID Context by 2183 running a mechanism such as the one defined in Appendix B.2 of 2185 [RFC8613] if they both support it and are configured to do so. In 2186 that case, the ID Context in the pairwise OSCORE Security Context 2187 will not match the "contextId" parameter of the corresponding 2188 OSCORE_Input_Material. Running the procedure in Appendix B.2 of 2189 [RFC8613] results in the keying material in the pairwise OSCORE 2190 Security Contexts of the Client and RS being updated. The Client can 2191 achieve the same result by re-posting the Access Token as described 2192 in Section 4.1 of [I-D.ietf-ace-oscore-profile], although without 2193 updating the ID Context. 2195 A.3.4. OSCORE Setup - Resource Server Side 2197 After validation of the Access Token as defined in Appendix A.3.2 and 2198 after sending the 2.01 (Created) response, the RS performs the 2199 following actions, in order to set up and fully derive the pairwise 2200 OSCORE Security Context created to communicate with the Client. 2202 o The RS MUST set the ID Context of the pairwise OSCORE Security 2203 Context as the concatenation of: i) GID, i.e. the Group Identifier 2204 of the OSCORE group, as specified in the 'contextId' parameter of 2205 the OSCORE_Input_Material, in the 'cnf' claim of the Access Token 2206 received from the Client (see Appendix A.3.1); ii) the nonce N1; 2207 iii) the nonce N2; and iv) CID which is the value in the contextId 2208 parameter of the OSCORE_Input_Material provided in the 'cnf' claim 2209 of the Access Token. The concatenation occurs in this order: ID 2210 Context = GID | N1 | N2 | CID, where | denotes byte string 2211 concatenation. 2213 o The RS MUST set the new Master Salt of the pairwise OSCORE 2214 Security Context as the concatenation of SaltInput, MSalt, the 2215 nonce N1, the nonce N2 and GMSalt, where: i) SaltInput is the 2216 Sender ID that the Client has in the OSCORE group, as specified in 2217 the 'salt_input' claim included in the Access Token received from 2218 the Client (see Appendix A.3.1); ii) MSalt is the (optional) 2219 Master Salt in the pairwise OSCORE Security Context as specified 2220 in the 'salt' parameter in the OSCORE_Input_Material of the 'cnf' 2221 claim, included in the Access Token received from the Client; and 2222 iii) GMSalt is the (optional) Master Salt in the Group OSCORE 2223 Security Context, which is known to the RS as a member of the 2224 OSCORE group. The concatenation occurs in this order: Master Salt 2225 = SaltInput | MSalt | N1 | N2 | GMSalt, where | denotes byte 2226 string concatenation. Optional values, if not specified, are not 2227 included in the concatenation. The same considerations for 2228 building the Master Salt, considering the inputs as encoded CBOR 2229 byte strings as in Figure 16, hold also for the RS. 2231 o The RS MUST set the Master Secret of the pairwise OSCORE Security 2232 Context to the concatenation of MSec and GMSec, where: i) MSec is 2233 the value of the 'ms' parameter in the OSCORE_Input_Material of 2234 the 'cnf' claim, included in the Access Token received from the 2235 Client (see Appendix A.3.1); while ii) GMSec is the Master Secret 2236 of the Group OSCORE Security Context, which is known to the RS as 2237 a member of the OSCORE group. 2239 o The RS MUST set the Recipient ID as ace_server_recipientid, sent 2240 as described in Appendix A.3.2. 2242 o The RS MUST set the Sender ID as ace_client_recipientid, received 2243 as described in Appendix A.3.2. 2245 o The RS MUST set the AEAD Algorithm, ID Context, HKDF, and OSCORE 2246 Version from the corresponding parameters received from the Client 2247 in the Access Token (see Appendix A.3.1), if present in the 2248 OSCORE_Input_Material of the 'cnf' claim. In case these 2249 parameters are omitted, the default values SHALL be used as 2250 described in Section 3.2 and 5.4 of [RFC8613]. 2252 Finally, the RS MUST derive the complete pairwise OSCORE Security 2253 Context following Section 3.2.1 of [RFC8613]. 2255 Once having completed the derivation above, the RS MUST associate the 2256 authorization information from the Access Token with the just 2257 established pairwise OSCORE Security Context. Furthermore, as 2258 defined in Section 4.2, the RS MUST associate the authorization 2259 information from the Access Token with the Group OSCORE Security 2260 Context. 2262 Then, the RS uses this pairwise OSCORE Security Context to verify 2263 requests from and send responses to the Client protected with OSCORE, 2264 when this Security Context is used. If OSCORE verification fails, 2265 error responses are used, as specified in Section 8 of [RFC8613]. 2266 Besides, the RS uses the Group OSCORE Security Context to verify 2267 (multicast) requests from and send responses to the Client protected 2268 with Group OSCORE. If Group OSCORE verification fails, error 2269 responses are used, as specified in Section 8 and Section 9 of 2270 [I-D.ietf-core-oscore-groupcomm]. Additionally, for every incoming 2271 request, if OSCORE or Group OSCORE verification succeeds, the 2272 verification of access rights is performed as described in 2273 Appendix A.3.5. 2275 After the expiration of the Access Token related to a pairwise OSCORE 2276 Security Context and to a Group OSCORE Security Context, the RS MUST 2277 NOT use the pairwise OSCORE Security Context and MUST respond with an 2278 unprotected 4.01 (Unauthorized) error message to received requests 2279 that correspond to a security context with an expired Access Token. 2280 Also, if the Client uses the Group OSCORE Security Context to send a 2281 request for any resource intended for OSCORE group members and that 2282 requires an active Access Token, the RS MUST respond with a 4.01 2283 (Unauthorized) error message protected with the Group OSCORE Security 2284 Context. 2286 The same considerations, related to the value of the ID Context 2287 changing, as in Appendix A.3.3 hold also for the RS. 2289 A.3.5. Access Rights Verification 2291 The RS MUST follow the procedures defined in Section 4.4. 2293 Additionally, if the RS receives an OSCORE-protected request from a 2294 Client, the RS processes it according to [RFC8613]. 2296 If the OSCORE verification succeeds, and the target resource requires 2297 authorization, the RS retrieves the authorization information from 2298 the Access Token associated to the pairwise OSCORE Security Context 2299 and to the Group OSCORE Security Context. Then, the RS MUST verify 2300 that the action requested on the resource is authorized. 2302 The response code MUST be 4.01 (Unauthorized) if the RS has no valid 2303 Access Token for the Client. 2305 A.4. Secure Communication with the AS 2307 The same considerations for secure communication with the AS as 2308 defined in Section 5 hold. 2310 A.5. Discarding the Security Context 2312 The Client and the RS MUST follow what is defined in Section 6 of 2313 [I-D.ietf-ace-oscore-profile] about discarding the pairwise OSCORE 2314 Security Context. 2316 Additionally, they MUST follow what is defined in the main mode of 2317 the profile (see Section 6), with respect to the Group OSCORE 2318 Security Context. 2320 The Client or RS can acquire a new Group OSCORE Security Context, by 2321 re-joining the OSCORE group, e.g. by using the approach defined in 2322 [I-D.ietf-ace-key-groupcomm-oscore]. In such a case, the Client 2323 SHOULD request a new Access Token and post it to the RS, in order to 2324 establish a new pairwise OSCORE Security Context and bind it to the 2325 Group OSCORE Security Context obtained upon re-joining the group. 2327 A.6. CBOR Mappings 2329 The new parameters defined in this document MUST be mapped to CBOR 2330 types as specified in Figure 6, with the following addition, using 2331 the given integer abbreviation for the map key. 2333 /----------------+----------+------------\ 2334 | Parameter name | CBOR Key | Value Type | 2335 |----------------+----------+------------| 2336 | client_cred | TBD6 | map | 2337 \----------------+----------+------------/ 2339 Figure 17: CBOR mappings for new parameters. 2341 The new claims defined in this document MUST be mapped to CBOR types 2342 as specified in Figure 7, with the following addition, using the 2343 given integer abbreviation for the map key. 2345 /--------------+----------+------------\ 2346 | Claim name | CBOR Key | Value Type | 2347 |--------------+----------+------------| 2348 | client_cred | TBD7 | map | 2349 \--------------+----------+------------/ 2351 Figure 18: CBOR mappings for new claims. 2353 A.7. Security Considerations 2355 The dual mode of this profile inherits the security considerations 2356 from the main mode (see Section 8), as well as from the security 2357 considerations of the OSCORE profile of ACE 2358 [I-D.ietf-ace-oscore-profile]. Also, the security considerations 2359 about OSCORE [RFC8613] hold for the dual mode of this profile, as to 2360 the specific use of OSCORE. 2362 A.8. Privacy Considerations 2364 The same privacy considerations as defined in the main mode of this 2365 profile apply (see Section 9). 2367 In addition, as this profile mode also uses OSCORE, the privacy 2368 considerations from [RFC8613] apply as well, as to the specific use 2369 of OSCORE. 2371 Furthermore, this profile mode inherits the privacy considerations 2372 from the OSCORE profile of ACE [I-D.ietf-ace-oscore-profile]. 2374 Appendix B. Profile Requirements 2376 This appendix lists the specifications on this profile based on the 2377 requirements of the ACE framework, as requested in Appendix C of 2378 [I-D.ietf-ace-oauth-authz]. 2380 o (Optional) discovery process of how the Client finds the right AS 2381 for an RS it wants to send a request to: Not specified. 2383 o Communication protocol the Client and the RS must use: CoAP. 2385 o Security protocol(s) the Client and RS must use: Group OSCORE, 2386 i.e. exchange of secure messages by using a pre-established Group 2387 OSCORE Security Context. The optional dual mode defined in 2388 Appendix A additionally uses OSCORE, i.e. establishment of a 2389 pairwise OSCORE Security Context and exchange of secure messages. 2391 o How the Client and the RS mutually authenticate: Explicitly, by 2392 possession of a common Group OSCORE Security Context, and by 2393 either: usage of digital counter signatures embedded in messages, 2394 if protected with the group mode of Group OSCORE; or protection of 2395 messages with the pairwise mode of Group OSCORE, by using pairwise 2396 symmetric keys, derived from the asymmetric keys of the two peers 2397 exchanging the message. Note that the mutual authentication is 2398 not completed before the Client has verified an OSCORE or a Group 2399 OSCORE response using the corresponding security context. 2401 o Content-format of the protocol messages: "application/ace+cbor". 2403 o Proof-of-Possession protocol(s) and how to select one; which key 2404 types (e.g. symmetric/asymmetric) supported: Group OSCORE 2405 algorithms; distributed and verified asymmetric keys. In the 2406 optional dual mode defined in Appendix A: OSCORE algorithms; pre- 2407 established symmetric keys. 2409 o profile identifier: coap_group_oscore 2411 o (Optional) how the RS talks to the AS for introspection: HTTP/CoAP 2412 (+ TLS/DTLS/OSCORE). 2414 o How the client talks to the AS for requesting a token: HTTP/CoAP 2415 (+ TLS/DTLS/OSCORE). 2417 o How/if the authz-info endpoint is protected: Not protected. 2419 o (Optional) other methods of token transport than the authz-info 2420 endpoint: Not specified. 2422 Acknowledgments 2424 The authors sincerely thank Benjamin Kaduk, John Mattsson, Dave 2425 Robin, Jim Schaad and Goeran Selander for their comments and 2426 feedback. 2428 The work on this document has been partly supported by VINNOVA and 2429 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 2430 (Grant agreement 952652). 2432 Authors' Addresses 2434 Marco Tiloca 2435 RISE AB 2436 Isafjordsgatan 22 2437 Kista SE-16440 Stockholm 2438 Sweden 2440 Email: marco.tiloca@ri.se 2442 Rikard Hoeglund 2443 RISE AB 2444 Isafjordsgatan 22 2445 Kista SE-16440 Stockholm 2446 Sweden 2448 Email: rikard.hoglund@ri.se 2450 Ludwig Seitz 2451 Combitech 2452 Djaeknegatan 31 2453 Malmoe SE-21135 Malmoe 2454 Sweden 2456 Email: ludwig.seitz@combitech.se 2458 Francesca Palombini 2459 Ericsson AB 2460 Torshamnsgatan 23 2461 Kista SE-16440 Stockholm 2462 Sweden 2464 Email: francesca.palombini@ericsson.com