idnits 2.17.1 draft-ietf-ace-key-groupcomm-oscore-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 05, 2019) is 1751 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-02 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-24 == 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-05 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-03) exists of draft-dijk-core-groupcomm-bis-00 == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-08 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-08 == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-05 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-02 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 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: January 6, 2020 Universitaet Duisburg-Essen 6 F. Palombini 7 Ericsson AB 8 July 05, 2019 10 Key Management for OSCORE Groups in ACE 11 draft-ietf-ace-key-groupcomm-oscore-02 13 Abstract 15 This document describes a method to request and provision keying 16 material in group communication scenarios where the group 17 communication is based on CoAP and secured with Object Security for 18 Constrained RESTful Environments (OSCORE). The proposed method 19 delegates the authentication and authorization of new client nodes 20 that join an OSCORE group through a Group Manager server. This 21 approach builds on the ACE framework for Authentication and 22 Authorization, and leverages protocol-specific transport profiles of 23 ACE to achieve communication security, proof-of-possession and server 24 authentication. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 6, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Relation to Other Documents . . . . . . . . . . . . . . . 5 63 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 64 2.1. Overview of the Join Process . . . . . . . . . . . . . . 7 65 2.2. Overview of the Group Rekeying Process . . . . . . . . . 8 66 3. Joining Node to Authorization Server . . . . . . . . . . . . 9 67 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 9 68 3.2. Authorization Response . . . . . . . . . . . . . . . . . 10 69 4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 11 70 4.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 11 71 4.2. Join Request . . . . . . . . . . . . . . . . . . . . . . 12 72 4.3. Join Response . . . . . . . . . . . . . . . . . . . . . . 13 73 5. Leaving of a Group Member . . . . . . . . . . . . . . . . . . 17 74 6. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 18 75 7. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 20 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 78 9.1. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 22 79 9.2. OSCORE Security Context Parameters Registry . . . . . . . 23 80 9.3. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 24 81 9.4. Sequence Number Synchronization Method Registry . . . . . 24 82 9.5. ACE Public Key Encoding Registry . . . . . . . . . . . . 25 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 85 10.2. Informative References . . . . . . . . . . . . . . . . . 26 86 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 27 87 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 28 88 B.1. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 28 89 B.2. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 29 90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 93 1. Introduction 95 Object Security for Constrained RESTful Environments (OSCORE) 96 [I-D.ietf-core-object-security] is a method for application-layer 97 protection of the Constrained Application Protocol (CoAP) [RFC7252], 98 using CBOR Object Signing and Encryption (COSE) [RFC8152] and 99 enabling end-to-end security of CoAP payload and options. 101 As described in [I-D.ietf-core-oscore-groupcomm], OSCORE may be used 102 to protect CoAP group communication over IP multicast 103 [RFC7390][I-D.dijk-core-groupcomm-bis]. This relies on a Group 104 Manager, which is responsible for managing an OSCORE group, where 105 members exchange CoAP messages secured with OSCORE. The Group 106 Manager can be responsible for multiple groups, coordinates the join 107 process of new group members, and is entrusted with the distribution 108 and renewal of group keying material. 110 This specification builds on the ACE framework for Authentication and 111 Authorization [I-D.ietf-ace-oauth-authz] and defines a method to: 113 o Authorize a node to join an OSCORE group, and provide it with the 114 group keying material to communicate with other group members. 116 o Provide updated keying material to group members upon request. 118 o Renew the group keying material and distribute it to the OSCORE 119 group (rekeying) upon changes in the group membership. 121 A client node joins an OSCORE group through a resource server acting 122 as Group Manager for that group. The join process relies on an 123 Access Token, which is bound to a proof-of-possession key and 124 authorizes the client to access a specific join resource at the Group 125 Manager. 127 Messages exchanged among the participants follow the formats defined 128 in [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying 129 material in group communication scenarios. 131 In order to achieve communication security, proof-of-possession and 132 server authentication, the client and the Group Manager leverage 133 protocol-specific transport profiles of ACE. These include also 134 possible forthcoming transport profiles that comply with the 135 requirements in Appendix C of [I-D.ietf-ace-oauth-authz]. 137 1.1. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119][RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 Readers are expected to be familiar with the terms and concepts 146 described in the ACE framework for authentication and authorization 147 [I-D.ietf-ace-oauth-authz]. The terminology for entities in the 148 considered architecture is defined in OAuth 2.0 [RFC6749]. In 149 particular, this includes Client (C), Resource Server (RS), and 150 Authorization Server (AS). 152 Readers are expected to be familiar with the terms and concepts 153 related to the CoAP protocol described in 154 [RFC7252][RFC7390][I-D.dijk-core-groupcomm-bis]. Note that, unless 155 otherwise indicated, the term "endpoint" is used here following its 156 OAuth definition, aimed at denoting resources such as /token and 157 /introspect at the AS and /authz-info at the RS. This document does 158 not use the CoAP definition of "endpoint", which is "An entity 159 participating in the CoAP protocol". 161 Readers are expected to be familiar with the terms and concepts for 162 protection and processing of CoAP messages through OSCORE 163 [I-D.ietf-core-object-security] also in group communication scenarios 164 [I-D.ietf-core-oscore-groupcomm]. These include the concept of Group 165 Manager, as the entity responsible for a set of groups where 166 communications are secured with OSCORE. In this specification, the 167 Group Manager acts as Resource Server. 169 This document refers also to the following terminology. 171 o Joining node: a network node intending to join an OSCORE group, 172 where communication is based on CoAP 173 [RFC7390][I-D.dijk-core-groupcomm-bis] and secured with OSCORE as 174 described in [I-D.ietf-core-oscore-groupcomm]. 176 o Join process: the process through which a joining node becomes a 177 member of an OSCORE group. The join process is enforced and 178 assisted by the Group Manager responsible for that group. 180 o Join resource: a resource hosted by the Group Manager, associated 181 to an OSCORE group under that Group Manager. A join resource is 182 identifiable with the Group Identifier (Gid) of the respective 183 group. A joining node accesses a join resource to start the join 184 process and become a member of that group. The URI of a join 185 resource is fixed. 187 o Join endpoint: an endpoint at the Group Manager associated to a 188 join resource. 190 o Requester: member of an OSCORE group that sends request messages 191 to other members of the group. 193 o Responder: member of an OSCORE group that receives request 194 messages from other members of the group. A responder may reply 195 back, by sending a response message to the requester which has 196 sent the request message. 198 o Monitor: member of a group that is configured as responder and 199 never replies back to requesters after receiving request messages. 200 This corresponds to the term "silent server" used in 201 [I-D.ietf-core-oscore-groupcomm]. 203 o Group rekeying process: the process through which the Group 204 Manager renews the security parameters and group keying material, 205 and (re-)distributes them to the OSCORE group members. 207 1.2. Relation to Other Documents 209 Figure 1 overviews the main documents related to this specification. 210 Arrows and asterisk-arrows denote normative references and 211 informative refences, respectively. 213 +---------------------------------------+ 214 | | 215 +----------------|--------------+ | 216 | | | | 217 | v v Key Management 218 Pub-sub ---> Key Groupcomm ---> ACE Framework <--- for OSCORE Groups 219 profile * [[WG]] [[WG]] [[This document]] 220 | * * ^ ^ | | 221 | * * * * | | 222 | * * * *************** | | 223 | *********** * * * | | 224 | * * * * +--------------+ | 225 ACE | * * * * | | 226 -----|-*--------------*--------------*-*-|--------------------|------- 227 CoRE | * * * * | | 228 v v v * * v v 229 CoRE CoRE OSCORE -------------> OSCORE 230 Pubsub Groupcomm <*** Groupcomm <************* [[WG]] 231 [[WG]] [[RFC7390]] [[WG]] 233 Figure 1: Related Documents 235 2. Protocol Overview 237 Group communication for CoAP over IP multicast has been enabled in 238 [RFC7390][I-D.dijk-core-groupcomm-bis] and can be secured with Object 239 Security for Constrained RESTful Environments (OSCORE) 240 [I-D.ietf-core-object-security] as described in 241 [I-D.ietf-core-oscore-groupcomm]. A network node joins an OSCORE 242 group by interacting with the responsible Group Manager. Once 243 registered in the group, the new node can securely exchange messages 244 with other group members. 246 This specification describes how to use the ACE framework for 247 authentication and authorization [I-D.ietf-ace-oauth-authz] to: 249 o Enable a node to join an OSCORE group through the Group Manager 250 and receive the security parameters and keying material to 251 communicate with the other members of the gorup. 253 o Enable members of OSCORE groups to retrieve updated group keying 254 material from the Group Manager. 256 o Enable the Group Manager to renew the security parameters and 257 group keying material, and to (re-)distribute them to the members 258 of the OSCORE group (rekeying). 260 With reference to the ACE framework and the terminology defined in 261 OAuth 2.0 [RFC6749]: 263 o The Group Manager acts as Resource Server (RS), and hosts one join 264 resource for each OSCORE group it manages. Each join resource is 265 exported by a distinct join endpoint. During the join process, 266 the Group Manager provides joining nodes with the parameters and 267 keying material for taking part to secure communications in the 268 OSCORE group. The Group Manager also maintains the group keying 269 material and performs the group rekeying process to distribute 270 updated keying material to the group members. 272 o The joining node acts as Client (C), and requests to join an 273 OSCORE group by accessing the related join endpoint at the Group 274 Manager. 276 o The Authorization Server (AS) authorizes joining nodes to join 277 OSCORE groups under their respective Group Manager. Multiple 278 Group Managers can be associated to the same AS. The AS MAY 279 release Access Tokens for other purposes than joining OSCORE 280 groups under registered Group Managers. For example, the AS may 281 also release Access Tokens for accessing resources hosted by 282 members of OSCORE groups. 284 All communications between the involved entities rely on the CoAP 285 protocol and MUST be secured. 287 In particular, communications between the joining node and the Group 288 Manager leverage protocol-specific transport profiles of ACE to 289 achieve communication security, proof-of-possession and server 290 authentication. To this end, the AS must signal the specific 291 transport profile to use, consistently with requirements and 292 assumptions defined in the ACE framework [I-D.ietf-ace-oauth-authz]. 294 With reference to the AS, communications between the joining node and 295 the AS (/token endpoint) as well as between the Group Manager and the 296 AS (/introspect endpoint) can be secured by different means, for 297 instance using DTLS [RFC6347] or OSCORE 298 [I-D.ietf-core-object-security]. Further details on how the AS 299 secures communications (with the joining node and the Group Manager) 300 depend on the specifically used transport profile of ACE, and are out 301 of the scope of this specification. 303 2.1. Overview of the Join Process 305 A node performs the following steps in order to join an OSCORE group. 306 Messages exchanged among the participants follow the formats defined 307 in [I-D.ietf-ace-key-groupcomm], and are further specified in 308 Section 3 and Section 4 of this document. The Group Manager acts as 309 the Key Distribution Center (KDC) defined in 310 [I-D.ietf-ace-key-groupcomm]. 312 1. The joining node requests an Access Token from the AS, in order 313 to access a join resource on the Group Manager and hence join the 314 associated OSCORE group (see Section 3). The joining node will 315 start or continue using a secure communication channel with the 316 Group Manager, according to the response from the AS. 318 2. The joining node transfers authentication and authorization 319 information to the Group Manager by posting the obtained Access 320 Token (see Section 4). After that, a joining node must have a 321 secure communication channel established with the Group Manager, 322 before starting to join an OSCORE group under that Group Manager 323 (see Section 4). Possible ways to provide a secure communication 324 channel are DTLS [RFC6347] and OSCORE 325 [I-D.ietf-core-object-security]. 327 3. The joining node starts the join process to become a member of 328 the OSCORE group, by accessing the related join resource hosted 329 by the Group Manager (see Section 4). 331 4. At the end of the join process, the joining node has received 332 from the Group Manager the parameters and keying material to 333 securely communicate with the other members of the OSCORE group. 335 5. The joining node and the Group Manager maintain the secure 336 channel, to support possible future communications. 338 All further communications between the joining node and the Group 339 Manager MUST be secured, for instance with the same secure channel 340 mentioned in step 2. 342 2.2. Overview of the Group Rekeying Process 344 If the application requires backward and forward security, the Group 345 Manager MUST generate new security parameters and group keying 346 material, and distribute them to the group (rekeying) upon membership 347 changes. 349 That is, the group is rekeyed when a node joins the group as a new 350 member, or after a current member leaves the group. By doing so, a 351 joining node cannot access communications in the group prior its 352 joining, while a leaving node cannot access communications in the 353 group after its leaving. 355 Parameters and keying material include a new Group Identifier (Gid) 356 for the group and a new Master Secret for the OSCORE Common Security 357 Context of that group (see Section 2 of 358 [I-D.ietf-core-oscore-groupcomm]). 360 The Group Manager MUST support the Group Rekeying Process described 361 in Section 7. Future application profiles may define alternative 362 message formats and distribution schemes to perform group rekeying. 364 3. Joining Node to Authorization Server 366 This section describes how the joining node interacts with the AS in 367 order to be authorized to join an OSCORE group under a given Group 368 Manager. In particular, it considers a joining node that intends to 369 contact that Group Manager for the first time. 371 The message exchange between the joining node and the AS consists of 372 the messages Authorization Request and Authorization Response defined 373 in Section 3 of [I-D.ietf-ace-key-groupcomm]. 375 In case the specific AS associated to the Group Manager is unknown to 376 the joining node, the latter can rely on mechanisms like the 377 Unauthorized Resource Request message described in Section 5.1.1 of 378 [I-D.ietf-ace-oauth-authz] to discover the correct AS to contact. 380 3.1. Authorization Request 382 The joining node contacts the AS, in order to request an Access Token 383 for accessing the join resource hosted by the Group Manager and 384 associated to the OSCORE group. The Access Token request sent to the 385 /token endpoint follows the format of the Authorization Request 386 message defined in Section 3.1 of [I-D.ietf-ace-key-groupcomm]. In 387 particular: 389 o The 'scope' parameter MUST be present and MUST include: 391 * in the first element, either the Group Identifier (Gid) of the 392 group to join under the Group Manager, or a value from which 393 the Group Manager can derive the Gid of the group to join. It 394 is up to the application to define how the Group Manager 395 possibly performs the derivation of the full Gid. Appendix C of 396 [I-D.ietf-core-oscore-groupcomm] provides an example of 397 structured Gid, composed of a fixed part, namely Group Prefix, 398 and a variable part, namely Group Epoch. 400 * in the second element, the role (encoded as a text string) or 401 CBOR array of roles that the joining node intends to have in 402 the group it intends to join. Accepted values of roles are: 404 "requester", "responder", and "monitor". Possible combinations 405 are: ["requester" , "responder"]; ["requester" , "monitor"]. 407 o The 'audience' parameter MUST be present and is set to the 408 identifier of the Group Manager. 410 3.2. Authorization Response 412 The AS is responsible for authorizing the joining node to join 413 specific OSCORE groups, according to join policies enforced on behalf 414 of the respective Group Manager. 416 In case of successful authorization, the AS releases an Access Token 417 bound to a proof-of-possession key associated to the joining node. 419 Then, the AS provides the joining node with the Access Token as part 420 of an Access Token response, which follows the format of the 421 Authorization Response message defined in Section 3.2 of 422 [I-D.ietf-ace-key-groupcomm]. 424 The 'exp' parameter MUST be present. Other means for the AS to 425 specify the lifetime of Access Tokens are out of the scope of this 426 specification. 428 The AS must include the 'scope' parameter in the response when the 429 value included in the Access Token differs from the one specified by 430 the joining node in the request. In such a case, the second element 431 of 'scope' MUST be present and includes the role or CBOR array of 432 roles that the joining node is actually authorized to take in the 433 group, encoded as specified in Section 3.1 of this document. 435 Also, the 'profile' parameter indicates the specific transport 436 profile of ACE to use for securing communications between the joining 437 node and the Group Manager (see Section 5.6.4.3 of 438 [I-D.ietf-ace-oauth-authz]). 440 In particular, if symmetric keys are used, the AS generates a proof- 441 of-possession key, binds it to the Access Token, and provides it to 442 the joining node in the 'cnf' parameter of the Access Token response. 443 Instead, if asymmetric keys are used, the joining node provides its 444 own public key to the AS in the 'req_cnf' parameter of the Access 445 Token request. Then, the AS uses it as proof-of-possession key bound 446 to the Access Token, and provides the joining node with the Group 447 Manager's public key in the 'rs_cnf' parameter of the Access Token 448 response. 450 4. Joining Node to Group Manager 452 The following subsections describe the interactions between the 453 joining node and the Group Manager, i.e. the Access Token post and 454 the Request-Response exchange to join the OSCORE group. 456 4.1. Token Post 458 The joining node posts the Access Token to the /authz-info endpoint 459 at the Group Manager, according to the Token post defined in 460 Section 3.3 of [I-D.ietf-ace-key-groupcomm]. 462 At this point in time, the joining node might not have all the 463 necessary information concerning the public keys in the OSCORE group, 464 as well as concerning the algorithm and related parameters for 465 computing countersignatures in the OSCORE group. In such a case, the 466 joining node MAY use the 'sign_info' and 'pub_key_enc' parameters 467 defined in Section 3.3 of [I-D.ietf-ace-key-groupcomm] to ask for 468 such information. 470 Alternatively, the joining node may retrieve this information by 471 other means, e.g. by using the approach described in 472 [I-D.tiloca-core-oscore-discovery]. 474 If the Access Token is valid, the Group Manager responds to the POST 475 request with a 2.01 (Created) response, according to what is 476 specified in the signalled transport profile of ACE. The Group 477 Manager MUST use the Content-Format "application/ace+cbor" defined in 478 Section 8.14 of [I-D.ietf-ace-oauth-authz]. 480 The payload of the 2.01 (Created) response is a CBOR map, which MUST 481 include the 'cnonce' parameter defined in section 5.1.2 of 482 [I-D.ietf-ace-oauth-authz], and MAY include the 'sign_info' parameter 483 as well as the 'pub_key_enc' parameter. 485 The 'cnonce' parameter includes a nonce N generated by the Group 486 Manager. The joining node may use this nonce in order to prove the 487 possession of its own private key, upon joining the group (see 488 Section 4.2). 490 If present in the response: 492 o 'sign_alg', i.e. the first element of the 'sign_info' parameter, 493 takes value from Tables 5 and 6 of [RFC8152]. 495 o 'sign_parameters', i.e. the second element of the 'sign_info' 496 parameter, takes values from the "Counter Signature Parameters" 497 Registry (see Section 9.1 of [I-D.ietf-core-oscore-groupcomm]). 499 Its structure depends on the value of 'sign_alg'. If no 500 parameters of the counter signature algorithm are specified, 501 'sign_parameters' MUST be encoding the CBOR simple value Null. 503 o 'sign_key_parameters', i.e. the third element of the 'sign_info' 504 parameter, takes values from the "Counter Signature Key 505 Parameters" Registry (see Section 9.2 of 506 [I-D.ietf-core-oscore-groupcomm]). Its structure depends on the 507 value of 'sign_alg'. If no parameters of the key used with the 508 counter signature algorithm are specified, 'sign_key_parameters' 509 MUST be encoding the CBOR simple value Null. 511 o 'pub_key_enc' takes value from Figure 2, as a public key encoding 512 in the "ACE Public Key Encoding" Registry (see Section 11.2 of 513 [I-D.ietf-ace-key-groupcomm]). 515 +----------+-------+--------------------------------+-------------+ 516 | Name | Value | Description | Reference | 517 +----------+-------+--------------------------------+-------------+ 518 | COSE_Key | 1 | Public key encoded as COSE Key | {{RFC8152}} | 519 +----------+-------+--------------------------------+-------------+ 521 Figure 2: ACE Public Key Encoding Values 523 Note that the CBOR map specified as payload of the 2.01 (Created) 524 response may include further parameters, e.g. according to the 525 signalled transport profile of ACE. 527 Finally, the joining node establishes a secure channel with the Group 528 Manager, according to what is specified in the Access Token response 529 and the signalled transport profile of ACE. 531 4.2. Join Request 533 Once a secure communication channel with the Group Manager has been 534 established, the joining node requests to join the OSCORE group, by 535 accessing the related join resource at the Group Manager. 537 In particular, the joining node sends to the Group Manager a 538 confirmable CoAP request, using the method POST and targeting the 539 join endpoint associated to that group. This Join Request follows 540 the format and processing of the Key Distribution Request message 541 defined in Section 4.1 of [I-D.ietf-ace-key-groupcomm]. In 542 particular: 544 o The 'type' parameter is set to 1 ("key distribution"). 546 o The 'get_pub_keys' parameter is present only if the joining node 547 wants to retrieve the public keys of the group members from the 548 Group Manager during the join process (see Section 6). Otherwise, 549 this parameter MUST NOT be present. 551 o The 'client_cred' parameter, if present, includes the public key 552 of the joining node. In case the joining node knows the encoding 553 of public keys in the OSCORE group, as well as the 554 countersignature algorithm and possible associated parameters used 555 in the OSCORE group, the included public key MUST be in a 556 consistent format. This parameter MAY be omitted if: i) the 557 joining node is asking to access the group exclusively as monitor; 558 or ii) the Group Manager already acquired this information, for 559 instance during a past join process. In any other case, this 560 parameter MUST be present. 562 Furthermore, the CBOR map specified as payload of the Join Request 563 MAY also include the following additional parameter, which MUST be 564 present if the 'client_cred' parameter is present. 566 o The 'client_cred_verify' parameter, which is encoded as a CBOR 567 byte string and contains a signature computed by the joining node, 568 in order to prove possession of its own private key. The 569 signature is computed over the nonce N received in the 2.01 570 (Created) response to the Token POST (see Section 4.1). In 571 particular, the joining node MUST use the COSE_CounterSignature0 572 object [RFC8152], with the Sig_structure containing the nonce N as 573 payload; and an empty external_aad. The joining node computes the 574 signature by using the same private key and countersignature 575 algorithm it intends to use for signing messages in the OSCORE 576 group. 578 4.3. Join Response 580 The Group Manager processes the Join Request according to 581 [I-D.ietf-ace-oauth-authz] and Section 4.2 of 582 [I-D.ietf-ace-key-groupcomm]. Also, the Group Manager MUST return a 583 4.00 (Bad Request) response in case the Join Request includes the 584 'client_cred' parameter but does not include the 'client_cred_verify' 585 parameter. 587 If the request processing yields a positive outcome, the Group 588 Manager performs the further following checks. 590 o In case the Join Request includes the 'client_cred' parameter, the 591 Group Manager checks that the public key of the joining node has 592 an accepted format. That is, the public key has to be encoded as 593 expected in the OSCORE group, and has to be consistent with the 594 counter signature algorithm and possible associated parameters 595 used in the OSCORE group. The join process fails if the public 596 key of the joining node does not have an accepted format. 598 o In case the Join Request does not include the 'client_cred' 599 parameter, the Group Manager checks whether it is storing a public 600 key for the joining node, which is consistent with the encoding, 601 counter signature algorithm and possible associated parameters 602 used in the OSCORE group. The join process fails if the Group 603 Manager either: i) does not store a public key with an accepted 604 format for the joining node; or ii) stores multiple public keys 605 with an accepted format for the joining node. 607 o In case the Join Request includes the 'client_cred_verify' 608 parameter, the Group Manager verifies the signature contained in 609 the parameter. To this end, it considers: i) as signed value, the 610 nonce N previously provided in the 2.01 (Created) response to the 611 Token POST (see Section 4.1); ii) the countersignature algorithm 612 used in the OSCORE group; and iii) the public key of the joining 613 node, either retrieved from the 'client_cred' parameter, or as 614 stored from a past join process. The join process fails if the 615 Group Manager does not successfully verify the signature. 617 If the join process has failed, the Group Manager MUST reply to the 618 joining node with a 4.00 (Bad Request) response. The payload of this 619 response is a CBOR map, which includes a 'sign_info' parameter and a 620 'pub_key_enc' parameter, formatted as in the Token POST response in 621 Section 4.1. 623 Upon receiving this response, the joining node SHOULD send a new Join 624 Request to the Group Manager, which contains: 626 o The 'client_cred' parameter, including a public key in a format 627 consistent with the encoding, countersignature algorithm and 628 possible associated parameters indicated by the Group Manager. 630 o The 'client_cred_verify' parameter, including a signature computed 631 as described in Section 4.2, by using the public key indicated in 632 the current 'client_cred' parameter, with the countersignature 633 algorithm and possible associated parameters indicated by the 634 Group Manager. 636 Otherwise, in case of success, the Group Manager updates the group 637 membership by registering the joining node as a new member of the 638 OSCORE group. 640 Then, the Group Manager replies to the joining node providing the 641 updated security parameters and keying meterial necessary to 642 participate in the group communication. This Join Response follows 643 the format and processing of the Key Distribution success Response 644 message defined in Section 4.2 of [I-D.ietf-ace-key-groupcomm]. In 645 particular: 647 o The 'kty' parameter identifies a key of type 648 "Group_OSCORE_Security_Context object", defined in Section 9.1 of 649 this specification. 651 o The 'key' parameter includes what the joining node needs in order 652 to set up the OSCORE Security Context as per Section 2 of 653 [I-D.ietf-core-oscore-groupcomm]. This parameter has as value a 654 Group_OSCORE_Security_Context object, which is defined in this 655 specification and extends the OSCORE_Security_Context object 656 encoded in CBOR as defined in Section 3.2.1 of 657 [I-D.ietf-ace-oscore-profile]. In particular, it contains the 658 additional parameters 'cs_alg', 'cs_params', 'cs_key_params' and 659 'cs_key_enc' defined in Section 9.2 of this specification. More 660 specifically, the 'key' parameter is composed as follows. 662 * The 'ms' parameter MUST be present and includes the OSCORE 663 Master Secret value. 665 * The 'clientId' parameter, if present, has as value the OSCORE 666 Sender ID assigned to the joining node by the Group Manager. 667 This parameter is not present if the node joins the group 668 exclusively as monitor, according to what specified in the 669 Access Token (see Section 3.2). In any other case, this 670 parameter MUST be present. 672 * The 'hkdf' parameter, if present, has as value the KDF 673 algorithm used in the group. 675 * The 'alg' parameter, if present, has as value the AEAD 676 algorithm used in the group. 678 * The 'salt' parameter, if present, has as value the OSCORE 679 Master Salt. 681 * The 'contextId' parameter MUST be present and has as value the 682 Group Identifier (Gid) associated to the OSCORE group. 684 * The 'rpl' parameter, if present, specifies the OSCORE Replay 685 Window Size and Type value. 687 * The 'cs_alg' parameter MUST be present and specifies the 688 algorithm used to countersign messages in the group. This 689 parameter takes values from Tables 5 and 6 of [RFC8152]. 691 * The 'cs_params' parameter MAY be present and specifies the 692 additional parameters for the counter signature algorithm. 693 This parameter is a CBOR map whose content depends on the 694 counter signature algorithm, as specified in Section 2 and 695 Section 9.1 of [I-D.ietf-core-oscore-groupcomm]. 697 * The 'cs_key_params' parameter MAY be present and specifies the 698 additional parameters for the key used with the counter 699 signature algorithm. This parameter is a CBOR map whose 700 content depends on the counter signature algorithm, as 701 specified in Section 2 and Section 9.2 of 702 [I-D.ietf-core-oscore-groupcomm]. 704 * The 'cs_key_enc' parameter MAY be present and specifies the 705 encoding of the public keys of the group members. This 706 parameter is a CBOR integer, whose value is taken from 707 Figure 2, as a public key encoding in the "ACE Public Key 708 Encoding" Registry (see Section 11.2 of 709 [I-D.ietf-ace-key-groupcomm]). If this parameter is not 710 present, COSE_Key (1) MUST be assumed as default value. 712 o The 'profile' parameter MUST be present and has value 713 coap_group_oscore_app (TBD), which is defined in Section 9.3 of 714 this specification. 716 o The 'exp' parameter MUST be present and specifies the expiration 717 time in seconds after which the OSCORE Security Context derived 718 from the 'key' parameter is not valid anymore. 720 o The 'pub_keys' parameter is present only if the 'get_pub_keys' 721 parameter was present in the Join Request. If present, this 722 parameter includes the public keys of the group members that are 723 relevant to the joining node. That is, it includes: i) the public 724 keys of the responders currently in the group, in case the joining 725 node is configured (also) as requester; and ii) the public keys of 726 the requesters currently in the group, in case the joining node is 727 configured (also) as responder or monitor. 729 o The 'group_policies' parameter SHOULD be present and includes a 730 list of parameters indicating particular policies enforced in the 731 group. For instance, its field "Sequence Number Synchronization 732 Method" can indicate the method to achieve synchronization of 733 sequence numbers among group members (see Appendix E of 734 [I-D.ietf-core-oscore-groupcomm]), as indicated by the 735 corresponding value from the "Sequence Number Synchronization 736 Method" Registry defined in Section 11.8 of 737 [I-D.ietf-ace-key-groupcomm]. 739 Finally, the joining node uses the information received in the Join 740 Response to set up the OSCORE Security Context, as described in 741 Section 2 of [I-D.ietf-core-oscore-groupcomm]. From then on, the 742 joining node can exchange group messages secured with OSCORE as 743 described in [I-D.ietf-core-oscore-groupcomm]. 745 If the application requires backward security, the Group Manager 746 SHALL generate updated security parameters and group keying material, 747 and provide it to all the current group members (see Section 7). 749 When the OSCORE Security Context expires, as specified by the 'exp' 750 parameter of the Join Response, the node considers it invalid and to 751 be renewed. Then, the node retrieves updated security parameters and 752 keying material, by exchanging with the Group Manager a shortened 753 Join Request sent to the same Join Resource with the 'type' parameter 754 set to 3 ("update key") and a shortened Join Response message, 755 according to the approach defined in Section 6 of 756 [I-D.ietf-ace-key-groupcomm]. Finally, the node uses the updated 757 security parameters and keying material to set up the new OSCORE 758 Security Context as described in Section 2 of 759 [I-D.ietf-core-oscore-groupcomm]. 761 Furthermore, as discussed in Section 2.2 of 762 [I-D.ietf-core-oscore-groupcomm], the node may at some point 763 experience a wrap-around of its own Sender Sequence Number in the 764 group. When this happens, the node MUST send to the Group Manager a 765 shortened Join Request message to the same Join Resource, with the 766 'type' parameter set to 4 ("new"). Upon receiving this request 767 message, the Group Manager either rekeys the whole OSCORE group as 768 discussed in Section 7, or generates a new Sender ID for that node 769 and replies with a shortened Join Response message where: 771 o Only the parameters 'type', 'kty', 'key', 'profile' and 'exp' are 772 present. 774 o The 'clientId' parameter of the 'key' parameter specifies the new 775 Sender ID of the node. 777 5. Leaving of a Group Member 779 A node may be removed from the OSCORE group, due to expired or 780 revoked authorization, or after its own request to the Group Manager. 782 If the application requires forward security, the Group Manager SHALL 783 generate updated security parameters and group keying material, and 784 provide it to the remaining group members (see Section 7). The 785 leaving node must not be able to acquire the new security parameters 786 and group keying material distributed after its leaving. 788 Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm] 789 apply here as well, considering the Group Manager acting as KDC. In 790 particular, a node requests to leave the OSCORE group as described in 791 Section 5.2 of [I-D.ietf-ace-key-groupcomm], i.e. by sending to the 792 Group Manager a request to the same Join Resource with the 'type' 793 parameter set to 2 ("leave"). 795 6. Public Keys of Joining Nodes 797 Source authentication of OSCORE messages exchanged within the group 798 is ensured by means of digital counter signatures (see Sections 2 and 799 3 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members 800 must be able to retrieve each other's public key from a trusted key 801 repository, in order to verify source authenticity of incoming group 802 messages. 804 As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group 805 Manager acts as trusted repository of the public keys of the group 806 members, and provides those public keys to group members if requested 807 to. Upon joining an OSCORE group, a joining node is thus expected to 808 provide its own public key to the Group Manager. 810 In particular, one of the following four cases can occur when a new 811 node joins an OSCORE group. 813 o The joining node is going to join the group exclusively as 814 monitor. That is, it is not going to send messages to the group, 815 and hence to produce signatures with its own private key. In this 816 case, the joining node is not required to provide its own public 817 key to the Group Manager, which thus does not have to perform any 818 check related to the public key encoding, or to a countersignature 819 algorithm and possible associated parameters for that joining 820 node. 822 o The Group Manager already acquired the public key of the joining 823 node during a past join process. In this case, the joining node 824 MAY not provide again its own public key to the Group Manager, in 825 order to limit the size of the Join Request. The joining node 826 MUST provide its own public key again if it has provided the Group 827 Manager with multiple public keys during past join processes, 828 intended for different OSCORE groups. If the joining node 829 provides its own public key, the Group Manager performs 830 consistency checks as in Section 4.3 and, in case of success, 831 considers it as the public key associated to the joining node in 832 the OSCORE group. 834 o The joining node and the Group Manager use an asymmetric proof-of- 835 possession key to establish a secure communication channel. Then, 836 two cases can occur. 838 1. The proof-of-possession key is consistent with the encoding as 839 well as with the counter signature algorithm and possible 840 associated parameters used in the OSCORE group. Then, the 841 Group Manager considers the proof-of-possession key as the 842 public key associated to the joining node in the OSCORE group. 843 If the joining node is aware that the proof-of-possession key 844 is also valid for the OSCORE group, it MAY not provide it 845 again as its own public key to the Group Manager. The joining 846 node MUST provide its own public key again if it has provided 847 the Group Manager with multiple public keys during past join 848 processes, intended for different OSCORE groups. If the 849 joining node provides its own public key in the 'client_cred' 850 parameter of the Join Request (see Section 4.2), the Group 851 Manager performs consistency checks as in Section 4.3 and, in 852 case of success, considers it as the public key associated to 853 the joining node in the OSCORE group. 855 2. The proof-of-possession key is not consistent with the 856 encoding or with the counter signature algorithm and possible 857 associated parameters used in the OSCORE group. In this case, 858 the joining node MUST provide a different consistent public 859 key to the Group Manager in the 'client_cred' parameter of the 860 Join Request (see Section 4.2). Then, the Group Manager 861 performs consistency checks on this latest provided public key 862 as in Section 4.3 and, in case of success, considers it as the 863 public key associated to the joining node in the OSCORE group. 865 o The joining node and the Group Manager use a symmetric proof-of- 866 possession key to establish a secure communication channel. In 867 this case, upon performing a join process with that Group Manager 868 for the first time, the joining node specifies its own public key 869 in the 'client_cred' parameter of the Join Request targeting the 870 join endpoint (see Section 4.2). 872 Furthermore, as described in Section 4.2, the joining node may have 873 explicitly requested the Group Manager to retrieve the public keys of 874 the current group members, i.e. by including the 'get_pub_keys' 875 parameter in the Join Request. In this case, the Group Manager 876 includes also such public keys in the 'pub_keys' parameter of the 877 Join Response (see Section 4.3). 879 Later on as a group member, the node may need to retrieve the public 880 keys of other group members. The node can do that by exchanging with 881 the Group Manager a shortened Join Request sent to the same Join 882 Resource with the 'type' parameter set to 5 ("pub keys") and a 883 shortened Join Response, according to the approach defined in 884 Section 7 of [I-D.ietf-ace-key-groupcomm]. 886 7. Group Rekeying Process 888 In order to rekey the OSCORE group, the Group Manager distributes a 889 new Group ID of the group and a new OSCORE Master Secret for that 890 group. When doing so, the Group Manager MAY take a best effort to 891 preserve the same unchanged Sender IDs for all group members. This 892 avoids affecting the retrieval of public keys from the Group Manager 893 as well as the verification of message countersignatures. 895 The Group Manager MUST support at least the following group rekeying 896 scheme. Future application profiles may define alternative message 897 formats and distribution schemes. 899 The Group Manager uses the same format of the Join Response message 900 in Section 4.3. In particular: 902 o Only the parameters 'type', 'kty', 'key', 'profile' and 'exp' are 903 present. 905 o The 'ms' parameter of the 'key' parameter specifies the new OSCORE 906 Master Secret value. 908 o The 'contextId' parameter of the 'key' parameter specifies the new 909 Group ID. 911 The Group Manager separately sends a group rekeying message to each 912 group member to be rekeyed. Each rekeying message MUST be secured 913 with the pairwise secure communication channel between the Group 914 Manager and the group member used during the join process. 916 This approach requires group members to act (also) as servers, in 917 order to correctly handle unsolicited group rekeying messages from 918 the Group Manager. In particular, if a group member and the Group 919 Manager use OSCORE [I-D.ietf-core-object-security] to secure their 920 pairwise communications, the group member MUST create a Replay Window 921 in its own Recipient Context upon establishing the OSCORE Security 922 Context with the Group Manager, e.g. by means of the OSCORE profile 923 of ACE [I-D.ietf-ace-oscore-profile]. 925 Group members and the Group Manager SHOULD additionally support 926 alternative rekeying approaches that do not require group members to 927 act (also) as servers. A number of such approaches are defined in 928 Section 6 of [I-D.ietf-ace-key-groupcomm], and are based on the 929 following rationale: 931 o A group member queries the Group Manager for updated group keying 932 material, by sending a dedicated request to the same Join Resource 933 targeted when joining the group. Like for the case discussed in 934 Section 4.3 where the OSCORE Security Context expires, the group 935 member exchanges with the Group Manager a shortened Join Request 936 sent to the same Join Resource with the 'type' parameter set to 3 937 ("update key") and a shortened Join Response message, according to 938 the approach defined in Section 6 of [I-D.ietf-ace-key-groupcomm]. 940 o A group member subscribes for updates to the join resource and its 941 associated group keying material on the Group Manager. This can 942 rely on CoAP Observe [RFC7641] or on a full-fledged Pub-Sub model 943 [I-D.ietf-core-coap-pubsub] with the Group Manager acting as 944 Broker. 946 Either case, the Group Manager provides the (updated) group keying 947 material as specified above in this section. 949 8. Security Considerations 951 The method described in this document leverages the following 952 management aspects related to OSCORE groups and discussed in the 953 sections of [I-D.ietf-core-oscore-groupcomm] referred below. 955 o Management of group keying material (see Section 2.1 of 956 [I-D.ietf-core-oscore-groupcomm]). The Group Manager is 957 responsible for the renewal and re-distribution of the keying 958 material in the groups of its competence (rekeying). According to 959 the specific application requirements, this can include rekeying 960 the group upon changes in its membership. In particular, renewing 961 the keying material is required upon a new node's joining or a 962 current node's leaving, in case backward security and forward 963 security have to be preserved, respectively. 965 o Provisioning and retrieval of public keys (see Section 2 of 966 [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key 967 repository of public keys of group members, and provides them upon 968 request. 970 o Synchronization of sequence numbers (see Section 5 of 971 [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder 972 node that has just joined an OSCORE group can synchronize with the 973 sequence number of requesters in the same group. 975 Before sending the Join Response, the Group Manager MUST verify that 976 the joining node actually owns the associated private key. To this 977 end, the Group Manager can rely on the proof-of-possession challenge- 978 response defined in Section 4. Alternatively, the joining node can 979 use its own public key as asymmetric proof-of-possession key to 980 establish a secure channel with the Group Manager, e.g. as in 981 Section 3.2 of [I-D.ietf-ace-dtls-authorize]. However, this requires 982 such proof-of-possession key to be consistent with the encoding as 983 well as with the countersignature algorithm and possible associated 984 parameters used in the OSCORE group. 986 A node may have joined multiple OSCORE groups under different non- 987 synchronized Group Managers. Therefore, it can happen that those 988 OSCORE groups have the same Group Identifier (Gid). It follows that, 989 upon receiving a Group OSCORE message addressed to one of those 990 groups, the node would have multiple Security Contexts matching with 991 the Gid in the incoming message. It is up to the application to 992 decide how to handle such collisions of Group Identifiers, e.g. by 993 trying to process the incoming message using one Security Context at 994 the time until the right one is found. 996 Further security considerations are inherited from 997 [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication 998 and Authorization [I-D.ietf-ace-oauth-authz], and the specific 999 transport profile of ACE signalled by the AS, such as 1000 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 1002 9. IANA Considerations 1004 Note to RFC Editor: Please replace all occurrences of "[[This 1005 specification]]" with the RFC number of this specification and delete 1006 this paragraph. 1008 This document has the following actions for IANA. 1010 9.1. ACE Groupcomm Key Registry 1012 IANA is asked to register the following entry in the "ACE Groupcomm 1013 Key" Registry defined in Section 11.5 of 1014 [I-D.ietf-ace-key-groupcomm]. 1016 o Name: Group_OSCORE_Security_Context object 1018 o Key Type Value: TBD 1020 o Profile: "coap_group_oscore_app", defined in Section 9.3 of this 1021 specification. 1023 o Description: A Group_OSCORE_Security_Context object encoded as 1024 described in Section 4.3 of this specification. 1026 o Reference: [[This specification]] 1028 9.2. OSCORE Security Context Parameters Registry 1030 IANA is asked to register the following entries in the "OSCORE 1031 Security Context Parameters" Registry defined in Section 9.2 of 1032 [I-D.ietf-ace-oscore-profile]. 1034 o Name: cs_alg 1036 o CBOR Label: TBD 1038 o CBOR Type: tstr / int 1040 o Registry: COSE Algorithm Values (ECDSA, EdDSA) 1042 o Description: OSCORE Counter Signature Algorithm Value 1044 o Reference: [[This specification]] 1046 o Name: cs_params 1048 o CBOR Label: TBD 1050 o CBOR Type: map 1052 o Registry: Counter Signatures Parameters 1054 o Description: OSCORE Counter Signature Algorithm Additional 1055 Parameters 1057 o Reference: [[This specification]] 1059 o Name: cs_key_params 1061 o CBOR Label: TBD 1063 o CBOR Type: map 1065 o Registry: Counter Signatures Key Parameters 1067 o Description: OSCORE Counter Signature Key Additional Parameters 1069 o Reference: [[This specification]] 1071 o Name: cs_key_enc 1073 o CBOR Label: TBD 1075 o CBOR Type: integer 1076 o Registry: ACE Public Key Encoding 1078 o Description: Encoding of Public Keys to be used with the OSCORE 1079 Counter Signature Algorithm 1081 o Reference: [[This specification]] 1083 9.3. ACE Groupcomm Profile Registry 1085 IANA is asked to register the following entry in the "ACE Groupcomm 1086 Profile" Registry defined in Section 11.6 of 1087 [I-D.ietf-ace-key-groupcomm]. 1089 o Name: coap_group_oscore_app 1091 o Description: Application profile to provision keying material for 1092 participating in group communication protected with Group OSCORE 1093 as per [I-D.ietf-core-oscore-groupcomm]. 1095 o CBOR Value: TBD 1097 o Reference: [[This specification]] 1099 9.4. Sequence Number Synchronization Method Registry 1101 IANA is asked to register the following entries in the "Sequence 1102 Number Synchronization Method" Registry defined in Section 11.8 of 1103 [I-D.ietf-ace-key-groupcomm]. 1105 o Name: Best effort 1107 o Value: 1 1109 o Description: No action is taken. 1111 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1). 1113 o Name: Baseline 1115 o Value: 2 1117 o Description: The first received request sets the baseline 1118 reference point, and is discarded with no delivery to the 1119 application. 1121 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.2). 1123 o Name: Echo challenge-response 1124 o Value: 3 1126 o Description: Challenge response using the Echo Option for CoAP 1127 from [I-D.ietf-core-echo-request-tag]. 1129 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3). 1131 9.5. ACE Public Key Encoding Registry 1133 This specification registers the value defined in Figure 2 in the 1134 "ACE Public Key Encoding" IANA Registry. 1136 10. References 1138 10.1. Normative References 1140 [I-D.ietf-ace-key-groupcomm] 1141 Palombini, F. and M. Tiloca, "Key Provisioning for Group 1142 Communication using ACE", draft-ietf-ace-key-groupcomm-02 1143 (work in progress), July 2019. 1145 [I-D.ietf-ace-oauth-authz] 1146 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1147 H. Tschofenig, "Authentication and Authorization for 1148 Constrained Environments (ACE) using the OAuth 2.0 1149 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 1150 (work in progress), March 2019. 1152 [I-D.ietf-ace-oscore-profile] 1153 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1154 "OSCORE profile of the Authentication and Authorization 1155 for Constrained Environments Framework", draft-ietf-ace- 1156 oscore-profile-07 (work in progress), February 2019. 1158 [I-D.ietf-core-object-security] 1159 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1160 "Object Security for Constrained RESTful Environments 1161 (OSCORE)", draft-ietf-core-object-security-16 (work in 1162 progress), March 2019. 1164 [I-D.ietf-core-oscore-groupcomm] 1165 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1166 "Group OSCORE - Secure Group Communication for CoAP", 1167 draft-ietf-core-oscore-groupcomm-05 (work in progress), 1168 July 2019. 1170 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1171 Requirement Levels", BCP 14, RFC 2119, 1172 DOI 10.17487/RFC2119, March 1997, 1173 . 1175 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1176 Application Protocol (CoAP)", RFC 7252, 1177 DOI 10.17487/RFC7252, June 2014, 1178 . 1180 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1181 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1182 . 1184 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1185 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1186 May 2017, . 1188 10.2. Informative References 1190 [I-D.dijk-core-groupcomm-bis] 1191 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1192 for the Constrained Application Protocol (CoAP)", draft- 1193 dijk-core-groupcomm-bis-00 (work in progress), March 2019. 1195 [I-D.ietf-ace-dtls-authorize] 1196 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1197 L. Seitz, "Datagram Transport Layer Security (DTLS) 1198 Profile for Authentication and Authorization for 1199 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1200 authorize-08 (work in progress), April 2019. 1202 [I-D.ietf-core-coap-pubsub] 1203 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1204 Subscribe Broker for the Constrained Application Protocol 1205 (CoAP)", draft-ietf-core-coap-pubsub-08 (work in 1206 progress), March 2019. 1208 [I-D.ietf-core-echo-request-tag] 1209 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 1210 Request-Tag, and Token Processing", draft-ietf-core-echo- 1211 request-tag-05 (work in progress), May 2019. 1213 [I-D.tiloca-core-oscore-discovery] 1214 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1215 Groups with the CoRE Resource Directory", draft-tiloca- 1216 core-oscore-discovery-02 (work in progress), March 2019. 1218 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1219 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1220 January 2012, . 1222 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1223 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1224 . 1226 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 1227 the Constrained Application Protocol (CoAP)", RFC 7390, 1228 DOI 10.17487/RFC7390, October 2014, 1229 . 1231 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1232 Application Protocol (CoAP)", RFC 7641, 1233 DOI 10.17487/RFC7641, September 2015, 1234 . 1236 Appendix A. Profile Requirements 1238 This appendix lists the specifications on this application profile of 1239 ACE, based on the requiremens defined in Appendix A of 1240 [I-D.ietf-ace-key-groupcomm]. 1242 o Communication protocol that the members of the group must use: 1243 CoAP, possibly over IP multicast. 1245 o Security protocols that the group members must use to protect 1246 their communication: Group OSCORE. 1248 o Specify the encoding and value of the identifier of group and role 1249 of 'scope': see Section 3.1. 1251 o Profile identifier: coap_group_oscore_app 1253 o Acceptable values of 'kty': Group_OSCORE_Security_Context object 1255 o Specify the format and content of 'group_policies' entries: three 1256 values are defined and registered, as content of the entry 1257 "Sequence Number Synchronization Method" (see Section 9.4). 1259 o (Optional) specify the format and content of 'mgt_key_material': 1260 no. 1262 o (Optional) specify the transport profile of ACE 1263 [I-D.ietf-ace-oauth-authz] to use between Client and Group 1264 Manager: any transport profile of ACE that complies with the 1265 requirements in Appendix C of [I-D.ietf-ace-oauth-authz]. 1267 o (Optional) specify the encoding of public keys, of 'client_cred', 1268 and of 'pub_keys' if COSE_Keys are not used: no. 1270 o (Optional) specify the acceptable values for parameters related to 1271 signature algorithm and signature keys: 'sign_alg' takes value 1272 from Tables 5 and 6 of [RFC8152]; 'sign_parameters' takes values 1273 from the "Counter Signature Parameters" Registry (see Section 9.1 1274 of [I-D.ietf-core-oscore-groupcomm]); 'sign_key_parameters' takes 1275 values from the "Counter Signature Key Parameters" Registry (see 1276 Section 9.2 of [I-D.ietf-core-oscore-groupcomm]); 'pub_key_enc' 1277 takes value from Figure 2 in Section 4.1. 1279 o (Optional) specify the negotiation of parameter values for 1280 signature algorithm and signature keys, if 'sign_info' and 1281 'pub_key_enc' are not used: pre-knowledge by using the approach 1282 based on the CoRE Resource Directory described in 1283 [I-D.tiloca-core-oscore-discovery]. 1285 Appendix B. Document Updates 1287 RFC EDITOR: PLEASE REMOVE THIS SECTION. 1289 B.1. Version -01 to -02 1291 o Editorial fixes. 1293 o Changed: "listener" to "responder"; "pure listener" to "monitor". 1295 o Changed profile name to "coap_group_oscore_app", to reflect it is 1296 an application profile. 1298 o Added the 'type' parameter for all requests to a Join Resource. 1300 o Added parameters to indicate the encoding of public keys. 1302 o Challenge-response for proof-of-possession of signature keys 1303 (Section 4). 1305 o Renamed 'key_info' parameter to 'sign_info'; updated its format; 1306 extended to include also parameters of the countersignature key 1307 (Section 4.1). 1309 o Code 4.00 (Bad request), in responses to joining nodes providing 1310 an invalid public key (Section 4.3). 1312 o Clarifications on provisioning and checking of public keys 1313 (Sections 4 and 6). 1315 o Extended discussion on group rekeying and possible different 1316 approaches (Section 7). 1318 o Extended security considerations: proof-of-possession of signature 1319 keys; collision of OSCORE Group Identifiers (Section 8). 1321 o Registered three entries in the IANA Registry "Sequence Number 1322 Synchronization Method Registry" (Section 9). 1324 o Registered one public key encoding in the "ACE Public Key 1325 Encoding" IANA Registry (Section 9). 1327 B.2. Version -00 to -01 1329 o Changed name of 'req_aud' to 'audience' in the Authorization 1330 Request (Section 3.1). 1332 o Added negotiation of countersignature algorithm/parameters between 1333 Client and Group Manager (Section 4). 1335 o Updated format of the Key Distribution Response as a whole 1336 (Section 4.3). 1338 o Added parameter 'cs_params' in the 'key' parameter of the Key 1339 Distribution Response (Section 4.3). 1341 o New IANA registrations in the "ACE Authorization Server Request 1342 Creation Hints" Registry, "ACE Groupcomm Key" Registry, "OSCORE 1343 Security Context Parameters" Registry and "ACE Groupcomm Profile" 1344 Registry (Section 9). 1346 Acknowledgments 1348 The authors sincerely thank Santiago Aragon, Stefan Beck, Martin 1349 Gunnarsson, Rikard Hoeglund, Jim Schaad, Ludwig Seitz, Goeran 1350 Selander and Peter van der Stok for their comments and feedback. 1352 The work on this document has been partly supported by VINNOVA and 1353 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 1354 Initiative ACTIVE. 1356 Authors' Addresses 1357 Marco Tiloca 1358 RISE AB 1359 Isafjordsgatan 22 1360 Kista SE-164 29 Stockholm 1361 Sweden 1363 Email: marco.tiloca@ri.se 1365 Jiye Park 1366 Universitaet Duisburg-Essen 1367 Schuetzenbahn 70 1368 Essen 45127 1369 Germany 1371 Email: ji-ye.park@uni-due.de 1373 Francesca Palombini 1374 Ericsson AB 1375 Torshamnsgatan 23 1376 Kista SE-16440 Stockholm 1377 Sweden 1379 Email: francesca.palombini@ericsson.com