idnits 2.17.1 draft-ietf-ace-key-groupcomm-oscore-01.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 (March 08, 2019) is 1870 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 (-18) exists of draft-ietf-ace-key-groupcomm-00 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-22 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-07 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-03 == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-06 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-01 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group M. Tiloca 3 Internet-Draft RISE AB 4 Intended status: Standards Track J. Park 5 Expires: September 9, 2019 Universitaet Duisburg-Essen 6 F. Palombini 7 Ericsson AB 8 March 08, 2019 10 Key Management for OSCORE Groups in ACE 11 draft-ietf-ace-key-groupcomm-oscore-01 13 Abstract 15 This document describes a method to request and provision keying 16 material in group communication scenarios where communications are 17 based on CoAP and secured with Object Security for Constrained 18 RESTful Environments (OSCORE). The proposed method delegates the 19 authentication and authorization of new client nodes that join an 20 OSCORE group through a Group Manager server. This approach builds on 21 the ACE framework for Authentication and Authorization, and leverages 22 protocol-specific profiles of ACE to achieve communication security, 23 proof-of-possession and server authentication. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 9, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Relation to Other Documents . . . . . . . . . . . . . . . 5 62 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 63 2.1. Overview of the Join Process . . . . . . . . . . . . . . 7 64 2.2. Overview of the Group Rekeying Process . . . . . . . . . 8 65 3. Joining Node to Authorization Server . . . . . . . . . . . . 8 66 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 8 67 3.2. Authorization Response . . . . . . . . . . . . . . . . . 9 68 4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 10 69 4.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.1.1. 'key info' Parameter . . . . . . . . . . . . . . . . 11 71 4.2. Join Request . . . . . . . . . . . . . . . . . . . . . . 11 72 4.3. Join Response . . . . . . . . . . . . . . . . . . . . . . 12 73 5. Leaving of a Group Member . . . . . . . . . . . . . . . . . . 14 74 6. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 15 75 7. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 16 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 78 9.1. ACE Authorization Server Request Creation Hints Registry 17 79 9.2. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 17 80 9.3. OSCORE Security Context Parameters Registry . . . . . . . 18 81 9.4. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 18 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 84 10.2. Informative References . . . . . . . . . . . . . . . . . 20 85 Appendix A. Document Updates . . . . . . . . . . . . . . . . . . 20 86 A.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 21 87 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 90 1. Introduction 92 Object Security for Constrained RESTful Environments (OSCORE) 93 [I-D.ietf-core-object-security] is a method for application-layer 94 protection of the Constrained Application Protocol (CoAP) [RFC7252], 95 using CBOR Object Signing and Encryption (COSE) [RFC8152] and 96 enabling end-to-end security of CoAP payload and options. 98 As described in [I-D.ietf-core-oscore-groupcomm], OSCORE may be used 99 to protect CoAP group communication over IP multicast [RFC7390]. 100 This relies on a Group Manager, which is responsible for managing an 101 OSCORE group, where members exchange CoAP messages secured with 102 OSCORE. The Group Manager can be responsible for multiple groups, 103 coordinates the join process of new group members, and is entrusted 104 with the distribution and renewal of group keying material. 106 This specification builds on the ACE framework for Authentication and 107 Authorization [I-D.ietf-ace-oauth-authz] and defines a method to: 109 o Authorize a node to join an OSCORE group, and provide it with the 110 group keying material to communicate with other group members. 112 o Provide updated keying material to group members upon request. 114 o Renew the group keying material and distribute it to the OSCORE 115 group (rekeying) upon changes in the group membership. 117 A client node joins an OSCORE group through a resource server acting 118 as Group Manager for that group. The join process relies on an 119 Access Token, which is bound to a proof-of-possession key and 120 authorizes the client to access a specific join resource at the Group 121 Manager. 123 Messages exchanged among the participants follow the formats defined 124 in [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying 125 material in group communication scenarios. 127 In order to achieve communication security, proof-of-possession and 128 server authentication, the client and the Group Manager leverage 129 protocol-specific profiles of ACE. These include also possible 130 forthcoming profiles that comply with the requirements in Appendix C 131 of [I-D.ietf-ace-oauth-authz]. 133 1.1. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119][RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 Readers are expected to be familiar with the terms and concepts 142 described in the ACE framework for authentication and authorization 143 [I-D.ietf-ace-oauth-authz]. The terminology for entities in the 144 considered architecture is defined in OAuth 2.0 [RFC6749]. In 145 particular, this includes Client (C), Resource Server (RS), and 146 Authorization Server (AS). 148 Readers are expected to be familiar with the terms and concepts 149 related to the CoAP protocol described in [RFC7252][RFC7390]. Note 150 that, unless otherwise indicated, the term "endpoint" is used here 151 following its OAuth definition, aimed at denoting resources such as 152 /token and /introspect at the AS and /authz-info at the RS. This 153 document does not use the CoAP definition of "endpoint", which is "An 154 entity participating in the CoAP protocol". 156 Readers are expected to be familiar with the terms and concepts for 157 protection and processing of CoAP messages through OSCORE 158 [I-D.ietf-core-object-security] also in group communication scenarios 159 [I-D.ietf-core-oscore-groupcomm]. These include the concept of Group 160 Manager, as the entity responsible for a set of groups where 161 communications are secured with OSCORE. In this specification, the 162 Group Manager acts as Resource Server. 164 This document refers also to the following terminology. 166 o Joining node: a network node intending to join an OSCORE group, 167 where communication is based on CoAP [RFC7390] and secured with 168 OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. 170 o Join process: the process through which a joining node becomes a 171 member of an OSCORE group. The join process is enforced and 172 assisted by the Group Manager responsible for that group. 174 o Join resource: a resource hosted by the Group Manager, associated 175 to an OSCORE group under that Group Manager. A join resource is 176 identifiable with the Group Identifier (Gid) of the respective 177 group. A joining node accesses a join resource to start the join 178 process and become a member of that group. 180 o Join endpoint: an endpoint at the Group Manager associated to a 181 join resource. 183 o Requester: member of an OSCORE group that sends request messages 184 to other members of the group. 186 o Listener: member of an OSCORE group that receives request messages 187 from other members of the group. A listener may reply back, by 188 sending a response message to the requester which has sent the 189 request message. 191 o Pure listener: member of a group that is configured as listener 192 and never replies back to requesters after receiving request 193 messages. This corresponds to the term "silent server" used in 194 [I-D.ietf-core-oscore-groupcomm]. 196 o Group rekeying process: the process through which the Group 197 Manager renews the security parameters and group keying material, 198 and (re-)distributes them to the OSCORE group members. 200 1.2. Relation to Other Documents 202 Figure 1 overviews the main documents related to this specification. 203 Arrows and asterisk-arrows denote normative references and 204 informative refences, respectively. 206 +---------------------------------------+ 207 | | 208 +----------------|--------------+ | 209 | | | | 210 | v v Key Management 211 Pub-sub ---> Key Groupcomm ---> ACE Framework <--- for OSCORE Groups 212 profile * [[WG]] [[WG]] [[This document]] 213 | * * ^ ^ | | 214 | * * * * | | 215 | * * * *************** | | 216 | *********** * * * | | 217 | * * * * +--------------+ | 218 ACE | * * * * | | 219 -----|-*--------------*--------------*-*-|--------------------|------- 220 CoRE | * * * * | | 221 v v v * * v v 222 CoRE CoRE OSCORE -------------> OSCORE 223 Pubsub Groupcomm <*** Groupcomm <************* [[WG]] 224 [[WG]] [[RFC7390]] [[WG]] 226 Figure 1: Related Documents 228 2. Protocol Overview 230 Group communication for CoAP over IP multicast has been enabled in 231 [RFC7390] and can be secured with Object Security for Constrained 232 RESTful Environments (OSCORE) [I-D.ietf-core-object-security] as 233 described in [I-D.ietf-core-oscore-groupcomm]. A network node joins 234 an OSCORE group by interacting with the responsible Group Manager. 235 Once registered in the group, the new node can securely exchange 236 messages with other group members. 238 This specification describes how to use the ACE framework for 239 authentication and authorization [I-D.ietf-ace-oauth-authz] to: 241 o Enable a node to join an OSCORE group through the Group Manager 242 and receive the security parameters and keying material to 243 communicate with the other members of the gorup. 245 o Enable members of OSCORE groups to retrieve updated group keying 246 material from the Group Manager. 248 o Enable the Group Manager to renew the security parameters and 249 group keying material, and to (re-)distribute them to the members 250 of the OSCORE group (rekeying). 252 With reference to the ACE framework and the terminology defined in 253 OAuth 2.0 [RFC6749]: 255 o The Group Manager acts as Resource Server (RS), and hosts one join 256 resource for each OSCORE group it manages. Each join resource is 257 exported by a distinct join endpoint. During the join process, 258 the Group Manager provides joining nodes with the parameters and 259 keying material for taking part to secure communications in the 260 OSCORE group. The Group Manager also maintains the group keying 261 material and performs the group rekeying process to distribute 262 updated keying material to the group members. 264 o The joining node acts as Client (C), and requests to join an 265 OSCORE group by accessing the related join endpoint at the Group 266 Manager. 268 o The Authorization Server (AS) authorizes joining nodes to join 269 OSCORE groups under their respective Group Manager. Multiple 270 Group Managers can be associated to the same AS. The AS MAY 271 release Access Tokens for other purposes than joining OSCORE 272 groups under registered Group Managers. For example, the AS may 273 also release Access Tokens for accessing resources hosted by 274 members of OSCORE groups. 276 All communications between the involved entities rely on the CoAP 277 protocol and MUST be secured. 279 In particular, communications between the joining node and the Group 280 Manager leverage protocol-specific profiles of ACE to achieve 281 communication security, proof-of-possession and server 282 authentication. To this end, the AS must signal the specific profile 283 to use, consistently with requirements and assumptions defined in the 284 ACE framework [I-D.ietf-ace-oauth-authz]. 286 With reference to the AS, communications between the joining node and 287 the AS (/token endpoint) as well as between the Group Manager and the 288 AS (/introspect endpoint) can be secured by different means, for 289 instance using DTLS [RFC6347] or OSCORE 290 [I-D.ietf-core-object-security]. Further details on how the AS 291 secures communications (with the joining node and the Group Manager) 292 depend on the specifically used profile of ACE, and are out of the 293 scope of this specification. 295 2.1. Overview of the Join Process 297 A node performs the following steps in order to join an OSCORE group. 298 Messages exchanged among the participants follow the formats defined 299 in [I-D.ietf-ace-key-groupcomm], and are further specified in 300 Section 3 and Section 4 of this document. The Group Manager acts as 301 the Key Distribution Center (KDC) defined in 302 [I-D.ietf-ace-key-groupcomm]. 304 1. The joining node requests an Access Token from the AS, in order 305 to access a join resource on the Group Manager and hence join the 306 associated OSCORE group (see Section 3). The joining node will 307 start or continue using a secure communication channel with the 308 Group Manager, according to the response from the AS. 310 2. The joining node transfers authentication and authorization 311 information to the Group Manager by posting the obtained Access 312 Token (see Section 4). After that, a joining node must have a 313 secure communication channel established with the Group Manager, 314 before starting to join an OSCORE group under that Group Manager 315 (see Section 4). Possible ways to provide a secure communication 316 channel are DTLS [RFC6347] and OSCORE 317 [I-D.ietf-core-object-security]. 319 3. The joining node starts the join process to become a member of 320 the OSCORE group, by accessing the related join resource hosted 321 by the Group Manager (see Section 4). 323 4. At the end of the join process, the joining node has received 324 from the Group Manager the parameters and keying material to 325 securely communicate with the other members of the OSCORE group. 327 5. The joining node and the Group Manager maintain the secure 328 channel, to support possible future communications. 330 All further communications between the joining node and the Group 331 Manager MUST be secured, for instance with the same secure channel 332 mentioned in step 2. 334 2.2. Overview of the Group Rekeying Process 336 If the application requires backward and forward security, the Group 337 Manager MUST generate new security parameters and group keying 338 material, and distribute them to the group (rekeying) upon membership 339 changes. 341 That is, the group is rekeyed when a node joins the group as a new 342 member, or after a current member leaves the group. By doing so, a 343 joining node cannot access communications in the group prior its 344 joining, while a leaving node cannot access communications in the 345 group after its leaving. 347 Parameters and keying material include a new Group Identifier (Gid) 348 for the group and a new Master Secret for the OSCORE Common Security 349 Context of that group (see Section 2 of 350 [I-D.ietf-core-oscore-groupcomm]). 352 The Group Manager MUST support the Group Rekeying Process described 353 in Section 7. Future application profiles may define alternative 354 message formats and distribution schemes to perform group rekeying. 356 3. Joining Node to Authorization Server 358 This section describes how the joining node interacts with the AS in 359 order to be authorized to join an OSCORE group under a given Group 360 Manager. In particular, it considers a joining node that intends to 361 contact that Group Manager for the first time. 363 The message exchange between the joining node and the AS consists of 364 the messages Authorization Request and Authorization Response defined 365 in Section 3 of [I-D.ietf-ace-key-groupcomm]. 367 In case the specific AS associated to the Group Manager is unknown to 368 the joining node, the latter can rely on mechanisms like the 369 Unauthorized Resource Request message described in Section 5.1.1 of 370 [I-D.ietf-ace-oauth-authz] to discover the correct AS to contact. 372 3.1. Authorization Request 374 The joining node contacts the AS, in order to request an Access Token 375 for accessing the join resource hosted by the Group Manager and 376 associated to the OSCORE group. The Access Token request sent to the 377 /token endpoint follows the format of the Authorization Request 378 message defined in Section 3.1 of [I-D.ietf-ace-key-groupcomm]. In 379 particular: 381 o The 'scope' parameter MUST be present and MUST include: 383 * in the first element, either the Group Identifier (Gid) of the 384 group to join under the Group Manager, or a value from which 385 the Group Manager can derive the Gid of the group to join. It 386 is up to the application to define how the Group Manager 387 possibly performs the derivation of the full Gid. Appendix C of 388 [I-D.ietf-core-oscore-groupcomm] provides an example of 389 structured Gid, composed of a fixed part, namely Group Prefix, 390 and a variable part, namely Group Epoch. 392 * in the second element, the role(s) that the joining node 393 intends to have in the group it intends to join. Possible 394 values are: "requester"; "listener"; and "pure listener". 395 Possible combinations are: ["requester" , "listener"]; 396 ["requester" , "pure listener"]. 398 o The 'audience' parameter MUST be present and is set to the 399 identifier of the Group Manager. 401 3.2. Authorization Response 403 The AS is responsible for authorizing the joining node to join 404 specific OSCORE groups, according to join policies enforced on behalf 405 of the respective Group Manager. 407 In case of successful authorization, the AS releases an Access Token 408 bound to a proof-of-possession key associated to the joining node. 410 Then, the AS provides the joining node with the Access Token as part 411 of an Access Token response, which follows the format of the 412 Authorization Response message defined in Section 3.2 of 413 [I-D.ietf-ace-key-groupcomm]. 415 The 'exp' parameter MUST be present. Other means for the AS to 416 specify the lifetime of Access Tokens are out of the scope of this 417 specification. 419 The AS must include the 'scope' parameter in the response when the 420 value included in the Access Token differs from the one specified by 421 the joining node in the request. In such a case, the second element 422 of 'scope' MUST be present and includes the role(s) that the joining 423 node is actually authorized to take in the group, encoded as 424 specified in Section 3.1 of this document. 426 Also, the 'profile' parameter indicates the specific profile of ACE 427 to use for securing communications between the joining node and the 428 Group Manager (see Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]). 430 In particular, if symmetric keys are used, the AS generates a proof- 431 of-possession key, binds it to the Access Token, and provides it to 432 the joining node in the 'cnf' parameter of the Access Token response. 433 Instead, if asymmetric keys are used, the joining node provides its 434 own public key to the AS in the 'req_cnf' parameter of the Access 435 Token request. Then, the AS uses it as proof-of-possession key bound 436 to the Access Token, and provides the joining node with the Group 437 Manager's public key in the 'rs_cnf' parameter of the Access Token 438 response. 440 4. Joining Node to Group Manager 442 The following subsections describe the interactions between the 443 joining node and the Group Manager, i.e. the Access Token post and 444 the Request-Response exchange to join the OSCORE group. 446 4.1. Token Post 448 The joining node posts the Access Token to the /authz-info endpoint 449 at the Group Manager, according to the Token post defined in 450 Section 3.3 of [I-D.ietf-ace-key-groupcomm]. 452 If the joining node is not aware of the countersignature algorithm 453 and related parameters used in the OSCORE group, it may want to get 454 that information from the Group Manager. In such a case, the CoAP 455 POST request uses the Content-Format "application/ace+cbor" defined 456 in Section 8.14 of [I-D.ietf-ace-oauth-authz], and includes also the 457 parameter 'key info' defined in Section 4.1.1 and registered in 458 Section 9.1, encoding the CBOR simple value Null. Alternatively, the 459 joining node may retrieve that information by other means, e.g. by 460 using the approach described in [I-D.tiloca-core-oscore-discovery]. 462 If the Access Token is valid, the Group Manager responds to the POST 463 request with a 2.01 (Created) response, according to what is 464 specified in the signalled profile of ACE. 466 The payload of the 2.01 (Created) response MAY be a CBOR map 467 including a 'key info' parameter, which MUST be present if the POST 468 request included the 'key info' parameter with value Null. If 469 present, the 'key info' parameter of the 2.01 (Created) response is a 470 CBOR array formatted as follows: 472 o The first element is an integer or a text string, indicating the 473 counter signature algorithm used in the OSCORE group. This 474 parameter takes values from Tables 5 and 6 of [RFC8152]. 476 o The second element indicates the parameters of the counter 477 signature algorithm. Its structure depends on the value of the 478 first element, and is defined in the Counter Signature Parameters 479 Registry (see Section 9.1 of [I-D.ietf-core-oscore-groupcomm]). 480 This parameter MUST be omitted if there are no parameters for that 481 algorithm value. 483 The CDDL notation of the 'key info' parameter is given below. 485 key_info = [ 486 sign_alg : int / tstr, 487 ? sign_parameters : any 488 ] 490 Finally, the joining node establishes a secure channel with the Group 491 Manager, according to what is specified in the Access Token response 492 and the signalled profile of ACE. 494 4.1.1. 'key info' Parameter 496 The 'key info' parameter is an OPTIONAL parameter of the AS Request 497 Creation Hints message defined in Section 5.1.2. of 498 [I-D.ietf-ace-oauth-authz]. This parameter contains information 499 about the key to be used in the security association between the 500 Client and the RS. Its format is application specific. 502 4.2. Join Request 504 Once a secure communication channel with the Group Manager has been 505 established, the joining node requests to join the OSCORE group, by 506 accessing the related join resource at the Group Manager. 508 In particular, the joining node sends to the Group Manager a 509 confirmable CoAP request, using the method POST and targeting the 510 join endpoint associated to that group. This join request follows 511 the format and processing of the Key Distribution Request message 512 defined in Section 4.1 of [I-D.ietf-ace-key-groupcomm]. In 513 particular: 515 o The 'get_pub_keys' parameter is present only if the joining node 516 wants to retrieve the public keys of the group members from the 517 Group Manager during the join process (see Section 6). Otherwise, 518 this parameter MUST NOT be present. 520 o The 'client_cred' parameter, if present, includes the public key 521 of the joining node. In case the joining node knows the 522 countersignature algorithm and possible associated parameters used 523 in the OSCORE group, the included public key MUST be in a 524 consistent format. This parameter MAY be omitted if: i) the 525 joining node is asking to access the group exclusively as pure 526 listener; or ii) the Group Manager already acquired this 527 information, for instance during a previous join process. In any 528 other case, this parameter MUST be present. 530 4.3. Join Response 532 The Group Manager processes the request according to 533 [I-D.ietf-ace-oauth-authz] and Section 4.2 of 534 [I-D.ietf-ace-key-groupcomm]. If this yields a positive outcome, the 535 Group Manager performs the following check. In case the Join Request 536 included the 'client_cred' parameter, the Group Manager checks that 537 the public key of the joining node is consistent with the counter 538 signature algorithm and possible associated parameters used in the 539 OSCORE group. 541 If the public key of the joining node does not have an accepted 542 format, the Group Manager MUST reply to the joining node with a 2.01 543 (Created) response. The payload of this response is a CBOR map, 544 which includes a 'key info' parameter formatted as in the Token POST 545 response in Section 4.1. Upon receiving this response, the joining 546 node SHOULD send a new Join Request to the Group Manager, with the 547 'client_cred' parameter including its own public key in a format 548 consistent with the countersignature algorithm and possible 549 associated parameters indicated by the Group Manager. 551 Otherwise, the Group Manager updates the group membership by 552 registering the joining node as a new member of the OSCORE group. 554 Then, the Group Manager replies to the joining node providing the 555 updated security parameters and keying meterial necessary to 556 participate in the group communication. This join response follows 557 the format and processing of the Key Distribution success Response 558 message defined in Section 4.2 of [I-D.ietf-ace-key-groupcomm]. In 559 particular: 561 o The 'kty' parameter identifies a key of type 562 "Group_OSCORE_Security_Context object", defined in Section 9.2 of 563 this specification. 565 o The 'key' parameter includes what the joining node needs in order 566 to set up the OSCORE Security Context as per Section 2 of 567 [I-D.ietf-core-oscore-groupcomm]. This parameter includes a 568 Group_OSCORE_Security_Context object, which is defined in this 569 specification and extends the OSCORE_Security_Context object 570 encoded in CBOR as defined in Section 3.2.1 of 571 [I-D.ietf-ace-oscore-profile]. In particular, it contains the 572 additional parameters 'cs_alg' and 'cs_params' defined in 573 Section 9.3 of this specification. More specifically, the 'key' 574 parameter is composed as follows. 576 * The 'ms' parameter MUST be present and includes the OSCORE 577 Master Secret value. 579 * The 'clientId' parameter, if present, has as value the OSCORE 580 Sender ID assigned to the joining node by the Group Manager. 581 This parameter is not present if the node joins the group 582 exclusively as pure listener, according to what specified in 583 the Access Token (see Section 3.2). In any other case, this 584 parameter MUST be present. 586 * The 'hkdf' parameter, if present, has as value the KDF 587 algorithm used in the group. 589 * The 'alg' parameter, if present, has as value the AEAD 590 algorithm used in the group. 592 * The 'salt' parameter, if present, has as value the OSCORE 593 Master Salt. 595 * The 'contextId' parameter MUST be present and has as value the 596 Group Identifier (Gid) associated to the OSCORE group. 598 * The 'rpl' parameter, if present, specifies the OSCORE Replay 599 Window Size and Type value. 601 * The 'cs_alg' parameter MUST be present and specifies the 602 algorithm used to countersign messages in the group. This 603 parameter takes values from Tables 5 and 6 of [RFC8152]. 605 * The 'cs_params' parameter MAY be present and specifies the 606 additional parameters for the counter signature algorithm. 607 This parameter is encoded as specified in Section 2 of 608 [I-D.ietf-core-oscore-groupcomm]. 610 o The 'profile' parameter MUST be present and has value 611 "coap_group_oscore", which is defined in Section 9.4 of this 612 specification. 614 o The 'exp' parameter MUST be present and specifies the expiration 615 time in seconds after which the OSCORE Security Context derived 616 from the 'key' parameter is not valid anymore. 618 o The 'pub_keys' parameter is present only if the 'get_pub_keys' 619 parameter was present in the join request. If present, this 620 parameter includes the public keys of the group members that are 621 relevant to the joining node. That is, it includes: i) the public 622 keys of the non-pure listeners currently in the group, in case the 623 joining node is configured (also) as requester; and ii) the public 624 keys of the requesters currently in the group, in case the joining 625 node is configured (also) as listener or pure listener. 627 o The 'group_policies' parameter SHOULD be present and includes a 628 list of parameters indicating particular policies enforced in the 629 group. For instance, it can indicate the method to achieve 630 synchronization of sequence numbers among group members (see 631 Appendix E of [I-D.ietf-core-oscore-groupcomm]). 633 Finally, the joining node uses the information received in the join 634 response to set up the OSCORE Security Context, as described in 635 Section 2 of [I-D.ietf-core-oscore-groupcomm]. From then on, the 636 joining node can exchange group messages secured with OSCORE as 637 described in [I-D.ietf-core-oscore-groupcomm]. 639 If the application requires backward security, the Group Manager 640 SHALL generate updated security parameters and group keying material, 641 and provide it to all the current group members (see Section 7). 643 When the OSCORE Security Context expires, as specified by the 'exp' 644 parameter of the join response, the node considers it invalid and to 645 be renewed. Then, the node retrieves updated security parameters and 646 keying material, by exchanging shortened Join Request and Join 647 Response messages with the Group Manager, according to the approach 648 defined in Section 6 of [I-D.ietf-ace-key-groupcomm]. Finally, the 649 node uses the updated security parameters and keying material to set 650 up the new OSCORE Security Context as described in Section 2 of 651 [I-D.ietf-core-oscore-groupcomm]. 653 5. Leaving of a Group Member 655 A node may be removed from the OSCORE group, due to expired or 656 revoked authorization, or after its own request to the Group Manager. 658 If the application requires forward security, the Group Manager SHALL 659 generate updated security parameters and group keying material, and 660 provide it to the remaining group members (see Section 7). The 661 leaving node must not be able to acquire the new security parameters 662 and group keying material distributed after its leaving. 664 Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm] 665 apply here as well, considering the Group Manager acting as KDC. In 666 particular, a node requests to leave the OSCORE group as described in 667 Section 5.2 of [I-D.ietf-ace-key-groupcomm]. 669 6. Public Keys of Joining Nodes 671 Source authentication of OSCORE messages exchanged within the group 672 is ensured by means of digital counter signatures (see Sections 2 and 673 3 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members 674 must be able to retrieve each other's public key from a trusted key 675 repository, in order to verify source authenticity of incoming group 676 messages. 678 As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group 679 Manager acts as trusted repository of the public keys of the group 680 members, and provides those public keys to group members if requested 681 to. Upon joining an OSCORE group, a joining node is thus expected to 682 provide its own public key to the Group Manager. 684 In particular, four cases can occur when a new node joins a group. 686 o The joining node is going to join the group exclusively as pure 687 listener. That is, it is not going to send messages to the group, 688 and hence to produce signatures with its own private key. In this 689 case, the joining node is not required to provide its own public 690 key to the Group Manager upon joining the group. 692 o The Group Manager already acquired the public key of the joining 693 node during a previous join process. In this case, the joining 694 node may not provide again its own public key to the Group 695 Manager, in order to limit the size of the join request. 697 o The joining node and the Group Manager use an asymmetric proof-of- 698 possession key to establish a secure communication channel. In 699 this case, the Group Manager stores the proof-of-possession key 700 conveyed in the Access Token as the public key of the joining 701 node. 703 o The joining node and the Group Manager use a symmetric proof-of- 704 possession key to establish a secure communication channel. In 705 this case, upon performing a join process with that Group Manager 706 for the first time, the joining node specifies its own public key 707 in the 'client_cred' parameter of the join request targeting the 708 join endpoint (see Section 4.2). 710 Furthermore, as described in Section 4.2, the joining node may have 711 explicitly requested the Group Manager to retrieve the public keys of 712 the current group members, i.e. through the 'get_pub_keys' parameter 713 in the join request. In this case, the Group Manager includes also 714 such public keys in the 'pub_keys' parameter of the join response 715 (see Section 4.3). 717 Later on as a group member, the node may need to retrieve the public 718 keys of other group members. The node can do that by exchanging 719 shortened Join Request and Join Response messages with the Group 720 Manager, according to the approach defined in Section 7 of 721 [I-D.ietf-ace-key-groupcomm]. 723 7. Group Rekeying Process 725 In order to rekey the OSCORE group, the Group Manager distributes a 726 new Group ID of the group and a new OSCORE Master Secret for that 727 group. To this end, the Group Manager MUST support at least the 728 following group rekeying scheme. Future application profiles may 729 define alternative message formats and distribution schemes. 731 The Group Manager uses the same format of the Join Response message 732 in Section 4.3. In particular: 734 o Only the parameters 'kty', 'key', 'profile' and 'exp' are present. 736 o The 'ms' parameter of the 'key' parameter specifies the new OSCORE 737 Master Secret value. 739 o The 'contextId' parameter of the 'key' parameter specifies the new 740 Group ID. 742 The Group Manager separately sends a group rekeying message to each 743 group member to be rekeyed. Each rekeying message MUST be secured 744 with the pairwise secure communication channel between the Group 745 Manager and the group member used during the join process. 747 8. Security Considerations 749 The method described in this document leverages the following 750 management aspects related to OSCORE groups and discussed in the 751 sections of [I-D.ietf-core-oscore-groupcomm] referred below. 753 o Management of group keying material (see Section 2.1 of 754 [I-D.ietf-core-oscore-groupcomm]). The Group Manager is 755 responsible for the renewal and re-distribution of the keying 756 material in the groups of its competence (rekeying). According to 757 the specific application requirements, this can include rekeying 758 the group upon changes in its membership. In particular, renewing 759 the keying material is required upon a new node's joining or a 760 current node's leaving, in case backward security and forward 761 security have to be preserved, respectively. 763 o Provisioning and retrieval of public keys (see Section 2 of 764 [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key 765 repository of public keys of group members, and provides them upon 766 request. 768 o Synchronization of sequence numbers (see Section 5 of 769 [I-D.ietf-core-oscore-groupcomm]). This concerns how a listener 770 node that has just joined an OSCORE group can synchronize with the 771 sequence number of requesters in the same group. 773 Before sending the join response, the Group Manager should verify 774 that the joining node actually owns the associated private key, for 775 instance by performing a proof-of-possession challenge-response, 776 whose details are out of the scope of this specification. 778 Further security considerations are inherited from 779 [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication 780 and Authorization [I-D.ietf-ace-oauth-authz], and the specific 781 profile of ACE signalled by the AS, such as 782 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 784 9. IANA Considerations 786 Note to RFC Editor: Please replace all occurrences of "[[This 787 specification]]" with the RFC number of this specification and delete 788 this paragraph. 790 This document has the following actions for IANA. 792 9.1. ACE Authorization Server Request Creation Hints Registry 794 IANA is asked to register the following entry in the "ACE 795 Authorization Server Request Creation Hints" Registry defined in 796 Section 8.1 of [I-D.ietf-ace-oauth-authz]. 798 o Name: key info 800 o CBOR Key: TBD (range -256 to 255) 802 o Value Type: any 804 o Reference: [[This specification]] 806 9.2. ACE Groupcomm Key Registry 808 IANA is asked to register the following entry in the "ACE Groupcomm 809 Key" Registry defined in Section 9.1 of [I-D.ietf-ace-key-groupcomm]. 811 o Name: Group_OSCORE_Security_Context object 812 o Key Type Value: TBD 814 o Profile: "coap_group_oscore", defined in Section 9.4 of this 815 specification. 817 o Description: A Group_OSCORE_Security_Context object encoded as 818 described in Section 4.3 of this specification. 820 o Reference: [[This specification]] 822 9.3. OSCORE Security Context Parameters Registry 824 IANA is asked to register the following entries in the "OSCORE 825 Security Context Parameters" Registry defined in Section 9.2 of 826 [I-D.ietf-ace-oscore-profile]. 828 o Name: cs_alg 830 o CBOR Label: TBD 832 o CBOR Type: tstr / int 834 o Registry: COSE Algorithm Values (ECDSA, EdDSA) 836 o Description: OSCORE Counter Signature Algorithm Value 838 o Reference: [[This specification]] 840 o Name: cs_params 842 o CBOR Label: TBD 844 o CBOR Type: bstr 846 o Registry: Counter Signatures Parameters 848 o Description: OSCORE Counter Signature Algorithm Additional 849 Parameters 851 o Reference: [[This specification]] 853 9.4. ACE Groupcomm Profile Registry 855 IANA is asked to register the following entry in the "ACE Groupcomm 856 Profile" Registry defined in Section 9.2 of 857 [I-D.ietf-ace-key-groupcomm]. 859 o Name: coap_group_oscore 860 o Description: Profile to provision keying material for 861 participating in group communication protected with Group OSCORE 862 as per [I-D.ietf-core-oscore-groupcomm]. 864 o CBOR Value: TBD 866 o Reference: [[This specification]] 868 10. References 870 10.1. Normative References 872 [I-D.ietf-ace-key-groupcomm] 873 Palombini, F. and M. Tiloca, "Key Provisioning for Group 874 Communication using ACE", draft-ietf-ace-key-groupcomm-00 875 (work in progress), December 2018. 877 [I-D.ietf-ace-oauth-authz] 878 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 879 H. Tschofenig, "Authentication and Authorization for 880 Constrained Environments (ACE) using the OAuth 2.0 881 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22 882 (work in progress), March 2019. 884 [I-D.ietf-ace-oscore-profile] 885 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 886 "OSCORE profile of the Authentication and Authorization 887 for Constrained Environments Framework", draft-ietf-ace- 888 oscore-profile-07 (work in progress), February 2019. 890 [I-D.ietf-core-object-security] 891 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 892 "Object Security for Constrained RESTful Environments 893 (OSCORE)", draft-ietf-core-object-security-16 (work in 894 progress), March 2019. 896 [I-D.ietf-core-oscore-groupcomm] 897 Tiloca, M., Selander, G., Palombini, F., and J. Park, 898 "Group OSCORE - Secure Group Communication for CoAP", 899 draft-ietf-core-oscore-groupcomm-03 (work in progress), 900 October 2018. 902 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 903 Requirement Levels", BCP 14, RFC 2119, 904 DOI 10.17487/RFC2119, March 1997, 905 . 907 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 908 Application Protocol (CoAP)", RFC 7252, 909 DOI 10.17487/RFC7252, June 2014, 910 . 912 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 913 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 914 May 2017, . 916 10.2. Informative References 918 [I-D.ietf-ace-dtls-authorize] 919 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 920 L. Seitz, "Datagram Transport Layer Security (DTLS) 921 Profile for Authentication and Authorization for 922 Constrained Environments (ACE)", draft-ietf-ace-dtls- 923 authorize-06 (work in progress), February 2019. 925 [I-D.tiloca-core-oscore-discovery] 926 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 927 Groups with the CoRE Resource Directory", draft-tiloca- 928 core-oscore-discovery-01 (work in progress), January 2019. 930 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 931 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 932 January 2012, . 934 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 935 RFC 6749, DOI 10.17487/RFC6749, October 2012, 936 . 938 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 939 the Constrained Application Protocol (CoAP)", RFC 7390, 940 DOI 10.17487/RFC7390, October 2014, 941 . 943 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 944 RFC 8152, DOI 10.17487/RFC8152, July 2017, 945 . 947 Appendix A. Document Updates 949 RFC EDITOR: PLEASE REMOVE THIS SECTION. 951 A.1. Version -00 to -01 953 o Changed name of 'req_aud' to 'audience' in the Authorization 954 Request (Section 3.1). 956 o Added negotiation of countersignature algorithm/parameters between 957 Client and Group Manager (Section 4). 959 o Updated format of the Key Distribution Response as a whole 960 (Section 4.3). 962 o Added parameter 'cs_params' in the 'key' parameter of the Key 963 Distribution Response (Section 4.3). 965 o New IANA registrations in the "ACE Authorization Server Request 966 Creation Hints" Registry, "ACE Groupcomm Key" Registry, "OSCORE 967 Security Context Parameters" Registry and "ACE Groupcomm Profile" 968 Registry (Section 9). 970 Acknowledgments 972 The authors sincerely thank Santiago Aragon, Stefan Beck, Martin 973 Gunnarsson, Rikard Hoeglund, Jim Schaad, Ludwig Seitz, Goeran 974 Selander and Peter van der Stok for their comments and feedback. 976 The work on this document has been partly supported by VINNOVA and 977 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 978 Initiative ACTIVE. 980 Authors' Addresses 982 Marco Tiloca 983 RISE AB 984 Isafjordsgatan 22 985 Kista SE-164 29 Stockholm 986 Sweden 988 Email: marco.tiloca@ri.se 990 Jiye Park 991 Universitaet Duisburg-Essen 992 Schuetzenbahn 70 993 Essen 45127 994 Germany 996 Email: ji-ye.park@uni-due.de 997 Francesca Palombini 998 Ericsson AB 999 Torshamnsgatan 23 1000 Kista SE-16440 Stockholm 1001 Sweden 1003 Email: francesca.palombini@ericsson.com