idnits 2.17.1 draft-ietf-ace-key-groupcomm-oscore-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2019) is 1635 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-03 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-25 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-08 == 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-01 == 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-09 == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-08 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-03 -- 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: May 7, 2020 Universitaet Duisburg-Essen 6 F. Palombini 7 Ericsson AB 8 November 04, 2019 10 Key Management for OSCORE Groups in ACE 11 draft-ietf-ace-key-groupcomm-oscore-03 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 May 7, 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 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 63 2.1. Overview of the Joining 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 . . . . . . . . . . . . . . . . . . 9 67 3.2. Authorization Response . . . . . . . . . . . . . . . . . 9 68 4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 10 69 4.1. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.2. Joining Request . . . . . . . . . . . . . . . . . . . . . 12 71 4.3. Joining Response . . . . . . . . . . . . . . . . . . . . 13 72 5. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 17 73 6. Retrieval of Updated Keying Material . . . . . . . . . . . . 19 74 7. Retrieval of New Keying Material . . . . . . . . . . . . . . 19 75 8. Retrieval of Public Keys of Group Members . . . . . . . . . . 20 76 9. Retrieval of Group Policies . . . . . . . . . . . . . . . . . 20 77 10. Retrieval of Keying Material Version . . . . . . . . . . . . 21 78 11. Request to Leave the Group . . . . . . . . . . . . . . . . . 21 79 12. Removal of a Group Member . . . . . . . . . . . . . . . . . . 21 80 13. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 22 81 14. Security Considerations . . . . . . . . . . . . . . . . . . . 23 82 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 83 15.1. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 24 84 15.2. OSCORE Security Context Parameters Registry . . . . . . 24 85 15.3. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 26 86 15.4. Sequence Number Synchronization Method Registry . . . . 26 87 15.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . 27 88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 16.1. Normative References . . . . . . . . . . . . . . . . . . 27 90 16.2. Informative References . . . . . . . . . . . . . . . . . 28 91 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 29 92 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 31 93 B.1. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 31 94 B.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 32 95 B.3. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 32 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 100 1. Introduction 102 Object Security for Constrained RESTful Environments (OSCORE) 103 [RFC8613] is a method for application-layer protection of the 104 Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object 105 Signing and Encryption (COSE) [RFC8152] and enabling end-to-end 106 security of CoAP payload and options. 108 As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is 109 used to protect CoAP group communication over IP multicast 110 [RFC7390][I-D.dijk-core-groupcomm-bis]. This relies on a Group 111 Manager, which is responsible for managing an OSCORE group, where 112 members exchange CoAP messages secured with Group OSCORE. The Group 113 Manager can be responsible for multiple groups, coordinates the 114 joining process of new group members, and is entrusted with the 115 distribution and renewal of group keying material. 117 This specification builds on the ACE framework for Authentication and 118 Authorization [I-D.ietf-ace-oauth-authz] and defines a method to: 120 o Authorize a node to join an OSCORE group, and provide it with the 121 group keying material to communicate with other group members. 123 o Provide updated keying material to group members upon request. 125 o Renew the group keying material and distribute it to the OSCORE 126 group (rekeying) upon changes in the group membership. 128 A client node joins an OSCORE group through a resource server acting 129 as Group Manager for that group. The joining process relies on an 130 Access Token, which is bound to a proof-of-possession key and 131 authorizes the client to access a specific group-membership resource 132 at the Group Manager. 134 Message exchanges among the participants as well as message formats 135 and processing follow what specified in [I-D.ietf-ace-key-groupcomm] 136 for provisioning and renewing keying material in group communication 137 scenarios. 139 In order to achieve communication security, proof-of-possession and 140 server authentication, the client and the Group Manager leverage 141 protocol-specific transport profiles of ACE. These include also 142 possible forthcoming transport profiles that comply with the 143 requirements in Appendix C of [I-D.ietf-ace-oauth-authz]. 145 1.1. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14 [RFC2119][RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 Readers are expected to be familiar with the terms and concepts 154 described in the ACE framework for authentication and authorization 155 [I-D.ietf-ace-oauth-authz]. The terminology for entities in the 156 considered architecture is defined in OAuth 2.0 [RFC6749]. In 157 particular, this includes Client (C), Resource Server (RS), and 158 Authorization Server (AS). 160 Readers are expected to be familiar with the terms and concepts 161 related to the CoAP protocol described in 162 [RFC7252][RFC7390][I-D.dijk-core-groupcomm-bis]. Note that, unless 163 otherwise indicated, the term "endpoint" is used here following its 164 OAuth definition, aimed at denoting resources such as /token and 165 /introspect at the AS and /authz-info at the RS. This document does 166 not use the CoAP definition of "endpoint", which is "An entity 167 participating in the CoAP protocol". 169 Readers are expected to be familiar with the terms and concepts for 170 protection and processing of CoAP messages through OSCORE [RFC8613] 171 and through Group OSCORE [I-D.ietf-core-oscore-groupcomm] in group 172 communication scenarios. These include the concept of Group Manager, 173 as the entity responsible for a set of groups where communications 174 are secured with Group OSCORE. In this specification, the Group 175 Manager acts as Resource Server. 177 This document refers also to the following terminology. 179 o Joining node: a network node intending to join an OSCORE group, 180 where communication is based on CoAP 181 [RFC7390][I-D.dijk-core-groupcomm-bis] and secured with Group 182 OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. 184 o Joining process: the process through which a joining node becomes 185 a member of an OSCORE group. The joining process is enforced and 186 assisted by the Group Manager responsible for that group. 188 o Group name: stable and invariant identifier of an OSCORE group. 189 The group name MUST be unique under the same Group Manager, and 190 MUST include only characters that are valid for a url-path 191 segment, namely unreserved and pct-encoded characters [RFC3986]. 193 o Group-membership resource: a resource hosted by the Group Manager, 194 associated to an OSCORE group under that Group Manager. A group- 195 membership resource is identifiable with the name of the 196 respective OSCORE group. A joining node accesses a group- 197 membership resource to start the joining process and become a 198 member of that group. The url-path of a group-membership resource 199 is fixed, and ends with the segments /group-oscore/NAME , where 200 "NAME" is the name of the associated OSCORE group. This replaces 201 the url-path /ace-group/gid at the KDC used in 202 [I-D.ietf-ace-key-groupcomm], with "gid" indicating the group 203 identifier. The url-path /group-oscore/NAME is a default name: 204 implementations are not required to use this name, and can define 205 their own instead. 207 o Group-membership endpoint: an endpoint at the Group Manager 208 associated to a group-membership resource. 210 o Requester: member of an OSCORE group that sends request messages 211 to other members of the group. 213 o Responder: member of an OSCORE group that receives request 214 messages from other members of the group. A responder may reply 215 back, by sending a response message to the requester which has 216 sent the request message. 218 o Monitor: member of an OSCORE group that is configured as responder 219 and never replies back to requesters after receiving request 220 messages. This corresponds to the term "silent server" used in 221 [I-D.ietf-core-oscore-groupcomm]. 223 o Group rekeying process: the process through which the Group 224 Manager renews the security parameters and group keying material, 225 and (re-)distributes them to the OSCORE group members. 227 2. Protocol Overview 229 Group communication for CoAP over IP multicast has been enabled in 230 [RFC7390][I-D.dijk-core-groupcomm-bis] and can be secured with Group 231 Object Security for Constrained RESTful Environments (OSCORE) 232 [RFC8613] as described in [I-D.ietf-core-oscore-groupcomm]. A 233 network node joins an OSCORE group by interacting with the 234 responsible Group Manager. Once registered in the group, the new 235 node can securely exchange messages with other group members. 237 This specification describes how to use the ACE framework for 238 authentication and authorization [I-D.ietf-ace-oauth-authz] to: 240 o Enable a node to join an OSCORE group through the Group Manager 241 and receive the security parameters and keying material to 242 communicate with the other members of the group. 244 o Enable members of OSCORE groups to retrieve updated group keying 245 material and public key of other group members, from the Group 246 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 256 group-membership resource for each OSCORE group it manages. Each 257 group-membership resource is exported by a distinct group- 258 membership endpoint. During the joining process, the Group 259 Manager provides joining nodes with the parameters and keying 260 material for taking part to secure communications in the OSCORE 261 group. The Group Manager also maintains the group keying material 262 and performs the group rekeying process to distribute updated 263 keying material to the group members. 265 o The joining node acts as Client (C), and requests to join an 266 OSCORE group by accessing the related group-membership endpoint at 267 the Group Manager. 269 o The Authorization Server (AS) authorizes joining nodes to join 270 OSCORE groups under their respective Group Manager. Multiple 271 Group Managers can be associated to the same AS. The AS MAY 272 release Access Tokens for other purposes than joining OSCORE 273 groups under registered Group Managers. For example, the AS may 274 also release Access Tokens for accessing resources hosted by 275 members of OSCORE groups. 277 All communications between the involved entities rely on the CoAP 278 protocol and MUST be secured. 280 In particular, communications between the joining node and the Group 281 Manager leverage protocol-specific transport profiles of ACE to 282 achieve communication security, proof-of-possession and server 283 authentication. To this end, the AS MAY signal the specific 284 transport profile to use, consistently with requirements and 285 assumptions defined in the ACE framework [I-D.ietf-ace-oauth-authz]. 286 Note that in the commonly referred base-case the transport profile to 287 use is pre-configured and well-known to nodes participating in 288 constrained applications. 290 With reference to the AS, communications between the joining node and 291 the AS (/token endpoint) as well as between the Group Manager and the 292 AS (/introspect endpoint) can be secured by different means, for 293 instance using DTLS [RFC6347] or OSCORE [RFC8613]. Further details 294 on how the AS secures communications (with the joining node and the 295 Group Manager) depend on the specifically used transport profile of 296 ACE, and are out of the scope of this specification. 298 2.1. Overview of the Joining Process 300 A node performs the following steps in order to join an OSCORE group. 301 The format and processing of messages exchanged among the 302 participants follow what is defined in [I-D.ietf-ace-key-groupcomm], 303 and are further specified in Section 3 and Section 4 of this 304 document. The Group Manager acts as the Key Distribution Center 305 (KDC) defined in [I-D.ietf-ace-key-groupcomm]. 307 1. The joining node requests an Access Token from the AS, in order 308 to access a group-membership resource on the Group Manager and 309 hence join the associated OSCORE group (see Section 3). The 310 joining node will start or continue using a secure communication 311 association with the Group Manager, according to the response 312 from the AS. 314 2. The joining node transfers authentication and authorization 315 information to the Group Manager, by posting the obtained Access 316 Token to the /authz-info endpoint at the Group Manager (see 317 Section 4). After that, a joining node MUST have a secure 318 communication association established with the Group Manager, 319 before starting to join an OSCORE group under that Group Manager 320 (see Section 4). Possible ways to provide a secure communication 321 association are DTLS [RFC6347] and OSCORE [RFC8613]. 323 3. The joining node starts the joining process to become a member of 324 the OSCORE group, by accessing the related group-membership 325 resource hosted by the Group Manager (see Section 4). 327 4. At the end of the joining process, the joining node has received 328 from the Group Manager the parameters and keying material to 329 securely communicate with the other members of the OSCORE group. 331 5. The joining node and the Group Manager maintain the secure 332 association, to support possible future communications. These 333 especially include key management operations, such as retrieval 334 of updated keying material from the Group Manager or 335 participation to a group rekeying process (see Section 2.2). 337 All further communications between the joining node and the Group 338 Manager MUST be secured, for instance with the same secure 339 association mentioned in step 2. 341 2.2. Overview of the Group Rekeying Process 343 If the application requires backward and forward security, the Group 344 Manager MUST generate new security parameters and group keying 345 material, and distribute them to the group (rekeying) upon membership 346 changes. 348 That is, the group is rekeyed when a node joins the group as a new 349 member, or after a current member leaves the group. By doing so, a 350 joining node cannot access communications in the group prior its 351 joining, while a leaving node cannot access communications in the 352 group after its leaving. 354 Parameters and group keying material include a new Group Identifier 355 (Gid) for the group and a new Master Secret for the OSCORE Common 356 Security Context of that group (see Section 2 of 357 [I-D.ietf-core-oscore-groupcomm]). Once completed a group rekeying, 358 the GM MUST increment the version number of the group keying 359 material. 361 The Group Manager MUST support the Group Rekeying Process described 362 in Section 13. Future application profiles may define alternative 363 message formats and distribution schemes to perform group rekeying. 365 3. Joining Node to Authorization Server 367 This section describes how the joining node interacts with the AS in 368 order to be authorized to join an OSCORE group under a given Group 369 Manager. In particular, it considers a joining node that intends to 370 contact that Group Manager for the first time. 372 The message exchange between the joining node and the AS consists of 373 the messages Authorization Request and Authorization Response defined 374 in Section 3 of [I-D.ietf-ace-key-groupcomm]. 376 In case the specific AS associated to the Group Manager is unknown to 377 the joining node, the latter can rely on mechanisms like the 378 Unauthorized Resource Request message described in Section 5.1.1 of 379 [I-D.ietf-ace-oauth-authz] to discover the correct AS to contact. 381 3.1. Authorization Request 383 The joining node contacts the AS, in order to request an Access Token 384 for accessing the group-membership resource hosted by the Group 385 Manager and associated to the OSCORE group. The Access Token request 386 sent to the /token endpoint follows the format of the Authorization 387 Request message defined in Section 3.1 of 388 [I-D.ietf-ace-key-groupcomm]. In particular: 390 o The 'scope' parameter MUST be present and MUST include: 392 * in the first element, the name of the OSCORE group to join 393 under the Group Manager, encoded as a CBOR text string. 395 * in the second element, the role (encoded as a text string) or 396 CBOR array of roles that the joining node intends to have in 397 the group it intends to join. Accepted values of roles are: 398 "requester", "responder", and "monitor". Possible combinations 399 are: ["requester" , "responder"]; ["requester" , "monitor"]. 401 o The 'audience' parameter MUST be present and is set to the 402 identifier of the Group Manager. 404 3.2. Authorization Response 406 The AS is responsible for authorizing the joining node to join 407 specific OSCORE groups, according to join policies enforced on behalf 408 of the respective Group Manager. 410 In case of successful authorization, the AS releases an Access Token 411 bound to a proof-of-possession key associated to the joining node. 413 Then, the AS provides the joining node with the Access Token as part 414 of an Access Token response, which follows the format of the 415 Authorization Response message defined in Section 3.2 of 416 [I-D.ietf-ace-key-groupcomm]. 418 The AS MUST include the 'exp' parameter in the response to the 419 joining node. Other means for the AS to specify the lifetime of 420 Access Tokens are out of the scope of this specification. 422 The AS must include the 'scope' parameter in the response to the 423 joining node, when the value included in the Access Token differs 424 from the one specified by the joining node in the request. In such a 425 case, the second element of 'scope' MUST be present and includes the 426 role or CBOR array of roles that the joining node is actually 427 authorized to take in the group, encoded as specified in Section 3.1 428 of this document. 430 The AS MAY also include the 'profile' parameter in the response to 431 the joining node, in order to indicate the specific transport profile 432 of ACE to use for securing communications between the joining node 433 and the Group Manager (see Section 5.6.4.3 of 434 [I-D.ietf-ace-oauth-authz]). 436 In particular, if symmetric keys are used, the AS generates a proof- 437 of-possession key, binds it to the Access Token, and provides it to 438 the joining node in the 'cnf' parameter of the Access Token response. 439 Instead, if asymmetric keys are used, the joining node provides its 440 own public key to the AS in the 'req_cnf' parameter of the Access 441 Token request. Then, the AS uses it as proof-of-possession key bound 442 to the Access Token, and provides the joining node with the Group 443 Manager's public key in the 'rs_cnf' parameter of the Access Token 444 response. 446 4. Joining Node to Group Manager 448 The following subsections describe the interactions between the 449 joining node and the Group Manager, i.e. the sending of the Access 450 Token and the Request-Response exchange to join the OSCORE group. 452 4.1. Token Post 454 The joining node posts the Access Token to the /authz-info endpoint 455 at the Group Manager, according to the Token post defined in 456 Section 3.3 of [I-D.ietf-ace-key-groupcomm]. 458 At this point in time, the joining node might not have all the 459 necessary information concerning the public keys in the OSCORE group, 460 as well as concerning the algorithm and related parameters for 461 computing countersignatures in the OSCORE group. In such a case, the 462 joining node MAY use the 'sign_info' and 'pub_key_enc' parameters 463 defined in Section 3.3 of [I-D.ietf-ace-key-groupcomm] to ask for 464 such information. 466 Alternatively, the joining node may retrieve this information by 467 other means, e.g. by using the approach described in 468 [I-D.tiloca-core-oscore-discovery]. 470 If the Access Token is valid, the Group Manager responds to the POST 471 request with a 2.01 (Created) response, according to what is 472 specified in the signalled transport profile of ACE. The Group 473 Manager MUST use the Content-Format "application/ace+cbor" defined in 474 Section 8.14 of [I-D.ietf-ace-oauth-authz]. 476 The payload of the 2.01 (Created) response is a CBOR map, which MUST 477 include the 'rsnonce' parameter defined in Section 3.3.3 of 479 [I-D.ietf-ace-key-groupcomm], and MAY include the 'sign_info' 480 parameter as well as the 'pub_key_enc' parameter, defined in its 481 Sections 3.3.1 and 3.3.2, respectively. Note that this deviates from 482 the default payload format for this response message as defined in 483 the ACE framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]). 485 The 'rsnonce' parameter includes a dedicated nonce N_S generated by 486 the Group Manager. The joining node may use this nonce in order to 487 prove the possession of its own private key, upon joining the group 488 (see 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]). 498 Its structure depends on the value of 'sign_alg'. If no 499 parameters of the counter signature algorithm are specified, 500 'sign_parameters' MUST be encoding the CBOR simple value Null. 502 o 'sign_key_parameters', i.e. the third element of the 'sign_info' 503 parameter, takes values from the "Counter Signature Key 504 Parameters" Registry (see Section 9.2 of 505 [I-D.ietf-core-oscore-groupcomm]). Its structure depends on the 506 value of 'sign_alg'. If no parameters of the key used with the 507 counter signature algorithm are specified, 'sign_key_parameters' 508 MUST be encoding the CBOR simple value Null. 510 o 'pub_key_enc' takes value 1 ("COSE_Key") from the 'Confirmation 511 Key' column of the "CWT Confirmation Method" Registry defined in 512 [I-D.ietf-ace-cwt-proof-of-possession], so indicating that public 513 keys in the OSCORE group are encoded as COSE Keys [RFC8152]. 514 Future specifications may define additional values for this 515 parameter. 517 The CBOR map specified as payload of the 2.01 (Created) response may 518 include further parameters, e.g. according to the signalled transport 519 profile of ACE. 521 Finally, the joining node establishes a secure channel with the Group 522 Manager, according to what is specified in the Access Token response 523 and the signalled transport profile of ACE. 525 4.2. Joining Request 527 Once a secure communication channel with the Group Manager has been 528 established, the joining node requests to join the OSCORE group, by 529 sending a Joining Request message to the related group-membership 530 resource at the Group Manager, as per Section 4.2 of 531 [I-D.ietf-ace-key-groupcomm]. 533 In particular, the joining node sends a CoAP POST request to the 534 endpoint /group-oscore/NAME at the Group Manager, where NAME is the 535 name of the OSCORE group to join. This Joining Request is formatted 536 as defined in Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. 537 Specifically: 539 o The 'scope' parameter MUST be present. 541 o The 'get_pub_keys' parameter is present only if the joining node 542 wants to retrieve the public keys of the group members from the 543 Group Manager during the joining process (see Section 5). 544 Otherwise, this parameter MUST NOT be present. 546 o The 'client_cred' parameter, if present, includes the public key 547 of the joining node. In case the joining node knows the encoding 548 of public keys in the OSCORE group, as well as the 549 countersignature algorithm and possible associated parameters used 550 in the OSCORE group, the included public key MUST be compatible 551 with those criteria. That is, the public key MUST be encoded 552 according to the encoding of public keys in the OSCORE group, and 553 MUST be compatible with the countersignature algorithm and 554 possible associated parameters used in the OSCORE group. This 555 parameter MAY be omitted if: i) the joining node is asking to 556 access the group exclusively as monitor; or ii) the Group Manager 557 already acquired this information, for instance during a past 558 joining process. In any other case, this parameter MUST be 559 present. 561 Furthermore, if the 'client_cred' parameter is present, the CBOR map 562 specified as payload of the Joining Request MUST also include the 563 following parameters. 565 o 'cnonce', as defined in Section 5.1.2 of 566 [I-D.ietf-ace-oauth-authz], and including a dedicated nonce N_C 567 generated by the Client. 569 o The 'client_cred_verify' parameter, including a signature encoded 570 as a CBOR byte string, computed by the joining node to prove 571 possession of its own private key. The signature is computed over 572 N_S concatenated with N_C, where N_S is the nonce received in the 573 'rsnonce' parameter of the 2.01 (Created) response to the Token 574 POST (see Section 4.1), while N_C is the nonce generated by the 575 Client and specified in the 'cnonce' parameter above. The joining 576 node computes the signature by using the same private key and 577 countersignature algorithm it intends to use for signing messages 578 in the OSCORE group. 580 4.3. Joining Response 582 The Group Manager processes the Joining Request as defined in 583 Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm]. Also, the Group 584 Manager MUST return a 4.00 (Bad Request) response in case the Joining 585 Request includes the 'client_cred' parameter but does not include 586 both the 'cnonce' and 'client_cred_verify' parameters. 588 If the request processing yields a positive outcome, the Group 589 Manager performs the further following checks. 591 o In case the Joining Request includes the 'client_cred' parameter, 592 the Group Manager checks that the public key of the joining node 593 has an accepted format. That is, the public key has to be encoded 594 as expected in the OSCORE group, and has to be compatible with the 595 counter signature algorithm and possible associated parameters 596 used in the OSCORE group. The joining process fails if the public 597 key of the joining node does not have an accepted format. 599 o In case the Joining Request does not include the 'client_cred' 600 parameter, the Group Manager checks whether it is storing a public 601 key for the joining node, which is compatible with the encoding, 602 counter signature algorithm and possible associated parameters 603 used in the OSCORE group. The joining process fails if the Group 604 Manager either: i) does not store a public key with an accepted 605 format for the joining node; or ii) stores multiple public keys 606 with an accepted format for the joining node. 608 o In case the Joining Request includes the 'client_cred_verify' 609 parameter, the Group Manager verifies the signature contained in 610 the parameter. To this end, it considers: i) as signed value, N_S 611 concatenated with N_C, where N_S is the nonce previously provided 612 in the 'rsnonce' parameter of the 2.01 (Created) response to the 613 Token POST (see Section 4.1), while N_C is the nonce provided in 614 the 'cnonce' parameter of the Joining Request; ii) the 615 countersignature algorithm used in the OSCORE group, and possible 616 correponding parameters; and iii) the public key of the joining 617 node, either retrieved from the 'client_cred' parameter, or 618 already stored as acquired from previous interactions with the 619 joining node. The joining process fails if the Group Manager does 620 not successfully verify the signature. 622 If the joining process has failed, the Group Manager MUST reply to 623 the joining node with a 4.00 (Bad Request) response. The payload of 624 this response is a CBOR map, which includes a 'sign_info' parameter 625 and a 'pub_key_enc' parameter, formatted as in the Token POST 626 response in Section 4.1. 628 Upon receiving this response, the joining node SHOULD send a new 629 Joining Request to the Group Manager, which contains: 631 o The 'client_cred' parameter, including a public key compatible 632 with the encoding, countersignature algorithm and possible 633 associated parameters indicated by the Group Manager. 635 o The 'client_cred_verify' parameter, including a signature computed 636 as described in Section 4.2, by using the public key indicated in 637 the current 'client_cred' parameter, with the countersignature 638 algorithm and possible associated parameters indicated by the 639 Group Manager. 641 Otherwise, in case of success, the Group Manager updates the group 642 membership by registering the joining node as a new member of the 643 OSCORE group. If the joining node is not exclusively configured as 644 monitor, the Group Manager performs also the following actions. 646 o The Group Manager selects an available OSCORE Sender ID in the 647 OSCORE group, and exclusively assigns it to the joining node. 649 o If the 'client_cred' parameter was present in the request, the 650 Group Manager adds the specified public key of the joining node to 651 the list of public keys of the current group members. 653 o If the 'client_cred' parameter was not present in the request, the 654 Group Manager retrieves the already stored public key of the 655 joining node, as acquired from previous interactions (see also 656 Section 5). Then, the Group Manager adds the retrieved public key 657 to the list of public keys of the current group members. 659 o The Group Manager stores the association between i) the public key 660 of the joining node; and ii) the Group Identifier (Gid) associated 661 to the OSCORE group together with the OSCORE Sender ID assigned to 662 the joining node in the group. The Group Manager MUST keep this 663 association updated over time. 665 Then, the Group Manager replies to the joining node providing the 666 updated security parameters and keying meterial necessary to 667 participate in the group communication. This success Joining 668 Response is formatted as defined in Section 4.1.2.1 of 669 [I-D.ietf-ace-key-groupcomm]. In particular: 671 o The 'kty' parameter identifies a key of type 672 "Group_OSCORE_Security_Context object", defined in Section 15.1 of 673 this specification. 675 o The 'key' parameter includes what the joining node needs in order 676 to set up the OSCORE Security Context as per Section 2 of 677 [I-D.ietf-core-oscore-groupcomm]. This parameter has as value a 678 Group_OSCORE_Security_Context object, which is defined in this 679 specification and extends the OSCORE_Security_Context object 680 encoded in CBOR as defined in Section 3.2.1 of 681 [I-D.ietf-ace-oscore-profile]. In particular, it contains the 682 additional parameters 'cs_alg', 'cs_params', 'cs_key_params' and 683 'cs_key_enc' defined in Section 15.2 of this specification. More 684 specifically, the 'key' parameter is composed as follows. 686 * The 'ms' parameter MUST be present and includes the OSCORE 687 Master Secret value. 689 * The 'clientId' parameter, if present, has as value the OSCORE 690 Sender ID assigned to the joining node by the Group Manager, as 691 described above. This parameter is not present if the node 692 joins the group exclusively as monitor, according to what 693 specified in the Access Token (see Section 3.2). In any other 694 case, this parameter MUST be present. 696 * The 'hkdf' parameter, if present, has as value the KDF 697 algorithm used in the group. 699 * The 'alg' parameter, if present, has as value the AEAD 700 algorithm used in the group. 702 * The 'salt' parameter, if present, has as value the OSCORE 703 Master Salt. 705 * The 'contextId' parameter MUST be present and has as value the 706 Group Identifier (Gid) associated to the OSCORE group. 708 * The 'rpl' parameter, if present, specifies the OSCORE Replay 709 Window Size and Type value. 711 * The 'cs_alg' parameter MUST be present and specifies the 712 algorithm used to countersign messages in the group. This 713 parameter takes values from Tables 5 and 6 of [RFC8152]. 715 * The 'cs_params' parameter MAY be present and specifies the 716 additional parameters for the counter signature algorithm. 717 This parameter is a CBOR map whose content depends on the 718 counter signature algorithm, as specified in Section 2 and 719 Section 9.1 of [I-D.ietf-core-oscore-groupcomm]. 721 * The 'cs_key_params' parameter MAY be present and specifies the 722 additional parameters for the key used with the counter 723 signature algorithm. This parameter is a CBOR map whose 724 content depends on the counter signature algorithm, as 725 specified in Section 2 and Section 9.2 of 726 [I-D.ietf-core-oscore-groupcomm]. 728 * The 'cs_key_enc' parameter MAY be present and specifies the 729 encoding of the public keys of the group members. This 730 parameter is a CBOR integer, whose value is 1 ("COSE_Key") 731 taken from the 'Confirmation Key' column of the "CWT 732 Confirmation Method" Registry defined in 733 [I-D.ietf-ace-cwt-proof-of-possession], so indicating that 734 public keys in the OSCORE group are encoded as COSE Keys 735 [RFC8152]. Future specifications may define additional values 736 for this parameter. If this parameter is not present, 1 737 ("COSE_Key") MUST be assumed as default value. 739 o The 'num' parameter MUST be present and specifies the current 740 version number of the group keying material. 742 o The 'profile' parameter MUST be present and has value 743 coap_group_oscore_app (TBD), which is defined in Section 15.3 of 744 this specification. 746 o The 'exp' parameter MUST be present and specifies the expiration 747 time in seconds after which the OSCORE Security Context derived 748 from the 'key' parameter is not valid anymore. 750 o The 'pub_keys' parameter is present only if the 'get_pub_keys' 751 parameter was present in the Joining Request. If present, this 752 parameter includes the public keys of the group members that are 753 relevant to the joining node. That is, it includes: i) the public 754 keys of the responders currently in the group, in case the joining 755 node is configured (also) as requester; and ii) the public keys of 756 the requesters currently in the group, in case the joining node is 757 configured (also) as responder or monitor. If public keys are 758 encoded as COSE_Keys, each of them has as 'kid' the Sender ID that 759 the corresponding owner has in the group, thus used as group 760 member identifier. 762 o The 'group_policies' parameter SHOULD be present and includes a 763 list of parameters indicating particular policies enforced in the 764 group. In particular, if the field "Sequence Number 765 Synchronization Method" is present, it indicates the method to 766 achieve synchronization of sequence numbers among group members 767 (see Appendix E of [I-D.ietf-core-oscore-groupcomm]), by 768 specifying the corresponding value from the "Sequence Number 769 Synchronization Method" Registry defined in Section 8.6 of 770 [I-D.ietf-ace-key-groupcomm]. 772 Finally, the joining node uses the information received in the 773 Joining Response to set up the OSCORE Security Context, as described 774 in Section 2 of [I-D.ietf-core-oscore-groupcomm]. From then on, the 775 joining node can exchange group messages secured with Group OSCORE as 776 described in [I-D.ietf-core-oscore-groupcomm]. 778 If the application requires backward security, the Group Manager MUST 779 generate updated security parameters and group keying material, and 780 provide it to all the current group members (see Section 13). 782 5. Public Keys of Joining Nodes 784 Source authentication of OSCORE messages exchanged within the group 785 is ensured by means of digital counter signatures (see Sections 2 and 786 3 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members 787 must be able to retrieve each other's public key from a trusted key 788 repository, in order to verify source authenticity of incoming group 789 messages. 791 As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group 792 Manager acts as trusted repository of the public keys of the group 793 members, and provides those public keys to group members if requested 794 to. Upon joining an OSCORE group, a joining node is thus expected to 795 provide its own public key to the Group Manager. 797 In particular, one of the following four cases can occur when a new 798 node joins an OSCORE group. 800 o The joining node is going to join the group exclusively as 801 monitor. That is, it is not going to send messages to the group, 802 and hence to produce signatures with its own private key. In this 803 case, the joining node is not required to provide its own public 804 key to the Group Manager, which thus does not have to perform any 805 check related to the public key encoding, or to a countersignature 806 algorithm and possible associated parameters for that joining 807 node. 809 o The Group Manager already acquired the public key of the joining 810 node during a past joining process. In this case, the joining 811 node MAY choose not to provide again its own public key to the 812 Group Manager, in order to limit the size of the Joining Request. 813 The joining node MUST provide its own public key again if it has 814 provided the Group Manager with multiple public keys during past 815 joining processes, intended for different OSCORE groups. If the 816 joining node provides its own public key, the Group Manager 817 performs consistency checks as per Section 4.3 and, in case of 818 success, considers it as the public key associated to the joining 819 node in the OSCORE group. 821 o The joining node and the Group Manager use an asymmetric proof-of- 822 possession key to establish a secure communication channel. Then, 823 two cases can occur. 825 1. The proof-of-possession key is compatible with the encoding as 826 well as with the counter signature algorithm and possible 827 associated parameters used in the OSCORE group. Then, the 828 Group Manager considers the proof-of-possession key as the 829 public key associated to the joining node in the OSCORE group. 830 If the joining node is aware that the proof-of-possession key 831 is also valid for the OSCORE group, it MAY not provide it 832 again as its own public key to the Group Manager. The joining 833 node MUST provide its own public key again if it has provided 834 the Group Manager with multiple public keys during past 835 joining processes, intended for different OSCORE groups. If 836 the joining node provides its own public key in the 837 'client_cred' parameter of the Joining Request (see 838 Section 4.2), the Group Manager performs consistency checks as 839 per Section 4.3 and, in case of success, considers it as the 840 public key associated to the joining node in the OSCORE group. 842 2. The proof-of-possession key is not compatible with the 843 encoding or with the counter signature algorithm and possible 844 associated parameters used in the OSCORE group. In this case, 845 the joining node MUST provide a different compatible public 846 key to the Group Manager in the 'client_cred' parameter of the 847 Joining Request (see Section 4.2). Then, the Group Manager 848 performs consistency checks on this latest provided public key 849 as per Section 4.3 and, in case of success, considers it as 850 the public key associated to the joining node in the OSCORE 851 group. 853 o The joining node and the Group Manager use a symmetric proof-of- 854 possession key to establish a secure communication channel. In 855 this case, upon performing a joining process with that Group 856 Manager for the first time, the joining node specifies its own 857 public key in the 'client_cred' parameter of the Joining Request 858 targeting the group-membership endpoint (see Section 4.2). 860 6. Retrieval of Updated Keying Material 862 At some point, a group member considers the OSCORE Security Context 863 invalid and to be renewed. This happens, for instance, after a 864 number of unsuccessful security processing of incoming messages from 865 other group members, or when the Security Context expires as 866 specified by the 'exp' parameter of the Joining Response. 868 When this happens, the group member retrieves updated security 869 parameters and group keying material, by sending a Key Distribution 870 Request message to the Group Manager, as per Section 4.3 of 871 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP GET 872 request to the endpoint /group-oscore/NAME at the Group Manager, 873 where NAME is the name of the OSCORE group. The Key Distribution 874 Request is formatted as defined in Section 4.1.2.2 of 875 [I-D.ietf-ace-key-groupcomm]. 877 The Group Manager processes the Key Distribution Request according to 878 Section 4.1.2.2 of [I-D.ietf-ace-key-groupcomm]. The Key 879 Distribution Response is formatted as defined in Section 4.1.2.2 of 880 [I-D.ietf-ace-key-groupcomm]. 882 Upon receiving the Key Distribution Response, the group member 883 retrieves the updated security parameters and group keying material, 884 and use them to set up the new OSCORE Security Context as described 885 in Section 2 of [I-D.ietf-core-oscore-groupcomm]. 887 7. Retrieval of New Keying Material 889 As discussed in Section 2.2 of [I-D.ietf-core-oscore-groupcomm], a 890 group member may at some point experience a wrap-around of its own 891 Sender Sequence Number in the group. 893 When this happens, the group member MUST send a Key Renewal Request 894 message to the Group Manager, as per Section 4.4 of 895 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP GET 896 request to the endpoint /group-oscore/NAME/node at the Group Manager, 897 where NAME is the name of the OSCORE group. 899 Upon receiving the Key Renewal Request, the Group Manager processes 900 it as defined in Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm], and 901 performs one of the following actions. 903 1. The Group Manager replies to the group member with a 4.06 (Not 904 Acceptable) error response, and rekeys the whole OSCORE group as 905 discussed in Section 13. 907 2. The Group Manager generates a new Sender ID for that group member 908 and replies with a Key Renewal Response, formatted as defined in 909 Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm]. In particular, 910 the CBOR Map in the response payload includes a single parameter 911 'clientId' defined in Section 15.5 of this document, specifying 912 the new Sender ID of the group member encoded as a CBOR byte 913 string. 915 8. Retrieval of Public Keys of Group Members 917 A group member may need to retrieve the public keys of other group 918 members. To this end, the group member sends a Public Key Request 919 message to the Group Manager, as per Section 4.5 of 920 [I-D.ietf-ace-key-groupcomm]. In particular, it sends the request to 921 the endpoint /group-oscore/NAME/pub-key at the Group Manager, where 922 NAME is the name of the OSCORE group. 924 If the Public Key Request uses the method POST, the Public Key 925 Request is formatted as defined in Section 4.1.3.1 of 926 [I-D.ietf-ace-key-groupcomm]. In particular, each element of the 927 'get_pub_keys' parameter is a CBOR byte string, which encodes the 928 Sender ID of the group member for which the associated public key is 929 requested. 931 Upon receiving the Public Key Request, the Group Manager processes it 932 as per Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm], 933 depending on the request method being POST or GET, respectively. If 934 the Public Key Request uses the method POST, the Group Manager 935 silently ignores identifiers included in the 'get_pub_keys' parameter 936 of the request that are not associated to any current group member. 938 The success Public Key Response is formatted as defined in 939 Section 4.1.3.1 of [I-D.ietf-ace-key-groupcomm]. 941 9. Retrieval of Group Policies 943 A group member may request the current policies used in the OSCORE 944 group. To this end, the group member sends a Policies Request, as 945 per Section 4.6 of [I-D.ietf-ace-key-groupcomm]. In particular, it 946 sends a CoAP GET request to the endpoint /group-oscore/NAME/policies 947 at the Group Manager, where NAME is the name of the OSCORE group. 949 Upon receiving the Policies Request, the Group Manager processes it 950 as per Section 4.1.4.1 of [I-D.ietf-ace-key-groupcomm]. The success 951 Policies Response is formatted as defined in Section 4.1.4.1 of 952 [I-D.ietf-ace-key-groupcomm]. 954 10. Retrieval of Keying Material Version 956 A group member may request the current version of the keying material 957 used in the OSCORE group. To this end, the group member sends a 958 Version Request, as per Section 4.7 of [I-D.ietf-ace-key-groupcomm]. 959 In particular, it sends a CoAP GET request to the endpoint /group- 960 oscore/NAME/ctx-num at the Group Manager, where NAME is the name of 961 the OSCORE group. 963 Upon receiving the Version Request, the Group Manager processes it as 964 per Section 4.1.5.1 of [I-D.ietf-ace-key-groupcomm]. The success 965 Version Response is formatted as defined in Section 4.1.5.1 of 966 [I-D.ietf-ace-key-groupcomm]. 968 11. Request to Leave the Group 970 A group member may request to leave the OSCORE group. To this end, 971 the group member sends a Group Leaving Request, as per Section 4.8 of 972 [I-D.ietf-ace-key-groupcomm]. In particular, it sends a CoAP POST 973 request to the endpoint /group-oscore/NAME/node at the Group Manager, 974 where NAME is the name of the OSCORE group to leave. 976 The Leaving Request is formatted as defined in Section 4.1.6.1 of 977 [I-D.ietf-ace-key-groupcomm], and MUST have an empty CBOR Map as 978 payload. 980 Upon receiving the Leaving Request, the Group Manager processes it as 981 per Section 4.1.6.1 of [I-D.ietf-ace-key-groupcomm]. 983 12. Removal of a Group Member 985 Other than after a spontaneous request to the Group Manager as 986 described in Section 11, a node may be forcibly removed from the 987 OSCORE group, e.g. due to expired or revoked authorization. 989 In either case, if the leaving node is not configured exclusively as 990 monitor, the Group Manager performs the following actions. 992 o The Group Manager frees the OSCORE Sender ID value of the leaving 993 node, which becomes available for possible upcoming joining nodes. 995 o The Group Manager cancels the association between, on one hand, 996 the public key of the leaving node and, on the other hand, the 997 Group Identifier (Gid) associated to the OSCORE group together 998 with the freed OSCORE Sender ID value. The Group Manager deletes 999 the public key of the leaving node, if that public key has no 1000 remaining association with any pair (Group ID, Sender ID). 1002 If the application requires forward security, the Group Manager MUST 1003 generate updated security parameters and group keying material, and 1004 provide it to the remaining group members (see Section 13). As a 1005 consequence, the leaving node is not able to acquire the new security 1006 parameters and group keying material distributed after its leaving. 1008 Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm] 1009 apply here as well, considering the Group Manager acting as KDC. 1011 13. Group Rekeying Process 1013 In order to rekey the OSCORE group, the Group Manager distributes a 1014 new Group ID of the group and a new OSCORE Master Secret for that 1015 group. When doing so, the Group Manager MUST increment the version 1016 number of the group keying material. Also, the Group Manager MUST 1017 preserve the same unchanged Sender IDs for all group members. This 1018 avoids affecting the retrieval of public keys from the Group Manager 1019 as well as the verification of message countersignatures. 1021 The Group Manager MUST support at least the following group rekeying 1022 scheme. Future application profiles may define alternative message 1023 formats and distribution schemes. 1025 The Group Manager uses the same format of the Joining Response 1026 message in Section 4.3. In particular: 1028 o Only the parameters 'kty', 'key', 'num', 'profile' and 'exp' are 1029 present. 1031 o The 'ms' parameter of the 'key' parameter specifies the new OSCORE 1032 Master Secret value. 1034 o The 'contextId' parameter of the 'key' parameter specifies the new 1035 Group ID. 1037 The Group Manager separately sends a group rekeying message to each 1038 group member to be rekeyed. Each rekeying message MUST be secured 1039 with the pairwise secure communication channel between the Group 1040 Manager and the group member used during the joining process. 1042 This approach requires group members to act (also) as servers, in 1043 order to correctly handle unsolicited group rekeying messages from 1044 the Group Manager. In particular, if a group member and the Group 1045 Manager use OSCORE [RFC8613] to secure their pairwise communications, 1046 the group member MUST create a Replay Window in its own Recipient 1047 Context upon establishing the OSCORE Security Context with the Group 1048 Manager, e.g. by means of the OSCORE profile of ACE 1049 [I-D.ietf-ace-oscore-profile]. 1051 Group members and the Group Manager SHOULD additionally support 1052 alternative rekeying approaches that do not require group members to 1053 act (also) as servers. A number of such approaches are defined in 1054 Section 4 of [I-D.ietf-ace-key-groupcomm]. In particular, a group 1055 member may subscribe for updates to the group-membership resource of 1056 the group, at the endpoint /group-oscore/NAME of the Group Manager, 1057 where NAME is the name of the OSCORE group. This can rely on CoAP 1058 Observe [RFC7641] or on a full-fledged Pub-Sub model 1059 [I-D.ietf-core-coap-pubsub] with the Group Manager acting as Broker. 1061 14. Security Considerations 1063 The method described in this document leverages the following 1064 management aspects related to OSCORE groups and discussed in the 1065 sections of [I-D.ietf-core-oscore-groupcomm] referred below. 1067 o Management of group keying material (see Section 2.1 of 1068 [I-D.ietf-core-oscore-groupcomm]). The Group Manager is 1069 responsible for the renewal and re-distribution of the keying 1070 material in the groups of its competence (rekeying). According to 1071 the specific application requirements, this can include rekeying 1072 the group upon changes in its membership. In particular, renewing 1073 the group keying material is required upon a new node's joining or 1074 a current node's leaving, in case backward security and forward 1075 security have to be preserved, respectively. 1077 o Provisioning and retrieval of public keys (see Section 2 of 1078 [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key 1079 repository of public keys of group members, and provides them upon 1080 request. 1082 o Synchronization of sequence numbers (see Section 5 of 1083 [I-D.ietf-core-oscore-groupcomm]). This concerns how a responder 1084 node that has just joined an OSCORE group can synchronize with the 1085 sequence number of requesters in the same group. 1087 Before sending the Joining Response, the Group Manager MUST verify 1088 that the joining node actually owns the associated private key. To 1089 this end, the Group Manager can rely on the proof-of-possession 1090 challenge-response defined in Section 4. Alternatively, the joining 1091 node can use its own public key as asymmetric proof-of-possession key 1092 to establish a secure channel with the Group Manager, e.g. as in 1093 Section 3.2 of [I-D.ietf-ace-dtls-authorize]. However, this requires 1094 such proof-of-possession key to be compatible with the encoding as 1095 well as with the countersignature algorithm and possible associated 1096 parameters used in the OSCORE group. 1098 A node may have joined multiple OSCORE groups under different non- 1099 synchronized Group Managers. Therefore, it can happen that those 1100 OSCORE groups have the same Group Identifier (Gid). It follows that, 1101 upon receiving a Group OSCORE message addressed to one of those 1102 groups, the node would have multiple Security Contexts matching with 1103 the Gid in the incoming message. It is up to the application to 1104 decide how to handle such collisions of Group Identifiers, e.g. by 1105 trying to process the incoming message using one Security Context at 1106 the time until the right one is found. 1108 Further security considerations are inherited from 1109 [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication 1110 and Authorization [I-D.ietf-ace-oauth-authz], and the specific 1111 transport profile of ACE signalled by the AS, such as 1112 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 1114 15. IANA Considerations 1116 Note to RFC Editor: Please replace all occurrences of "[[This 1117 specification]]" with the RFC number of this specification and delete 1118 this paragraph. 1120 This document has the following actions for IANA. 1122 15.1. ACE Groupcomm Key Registry 1124 IANA is asked to register the following entry in the "ACE Groupcomm 1125 Key" Registry defined in Section 8.3 of [I-D.ietf-ace-key-groupcomm]. 1127 o Name: Group_OSCORE_Security_Context object 1129 o Key Type Value: TBD 1131 o Profile: "coap_group_oscore_app", defined in Section 15.3 of this 1132 specification. 1134 o Description: A Group_OSCORE_Security_Context object encoded as 1135 described in Section 4.3 of this specification. 1137 o Reference: [[This specification]] 1139 15.2. OSCORE Security Context Parameters Registry 1141 IANA is asked to register the following entries in the "OSCORE 1142 Security Context Parameters" Registry defined in Section 9.2 of 1143 [I-D.ietf-ace-oscore-profile]. 1145 o Name: cs_alg 1146 o CBOR Label: TBD 1148 o CBOR Type: tstr / int 1150 o Registry: COSE Algorithm Values (ECDSA, EdDSA) 1152 o Description: OSCORE Counter Signature Algorithm Value 1154 o Reference: [[This specification]] 1156 o Name: cs_params 1158 o CBOR Label: TBD 1160 o CBOR Type: map 1162 o Registry: Counter Signatures Parameters 1164 o Description: OSCORE Counter Signature Algorithm Additional 1165 Parameters 1167 o Reference: [[This specification]] 1169 o Name: cs_key_params 1171 o CBOR Label: TBD 1173 o CBOR Type: map 1175 o Registry: Counter Signatures Key Parameters 1177 o Description: OSCORE Counter Signature Key Additional Parameters 1179 o Reference: [[This specification]] 1181 o Name: cs_key_enc 1183 o CBOR Label: TBD 1185 o CBOR Type: integer 1187 o Registry: ACE Public Key Encoding 1189 o Description: Encoding of Public Keys to be used with the OSCORE 1190 Counter Signature Algorithm 1192 o Reference: [[This specification]] 1194 15.3. ACE Groupcomm Profile Registry 1196 IANA is asked to register the following entry in the "ACE Groupcomm 1197 Profile" Registry defined in Section 8.4 of 1198 [I-D.ietf-ace-key-groupcomm]. 1200 o Name: coap_group_oscore_app 1202 o Description: Application profile to provision keying material for 1203 participating in group communication protected with Group OSCORE 1204 as per [I-D.ietf-core-oscore-groupcomm]. 1206 o CBOR Value: TBD 1208 o Reference: [[This specification]] 1210 15.4. Sequence Number Synchronization Method Registry 1212 IANA is asked to register the following entries in the "Sequence 1213 Number Synchronization Method" Registry defined in Section 8.6 of 1214 [I-D.ietf-ace-key-groupcomm]. 1216 o Name: Best effort 1218 o Value: 1 1220 o Description: No action is taken. 1222 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1). 1224 o Name: Baseline 1226 o Value: 2 1228 o Description: The first received request sets the baseline 1229 reference point, and is discarded with no delivery to the 1230 application. 1232 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.2). 1234 o Name: Echo challenge-response 1236 o Value: 3 1238 o Description: Challenge response using the Echo Option for CoAP 1239 from [I-D.ietf-core-echo-request-tag]. 1241 o Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3). 1243 15.5. ACE Groupcomm Parameters Registry 1245 IANA is asked to register the following entry in the "ACE Groupcomm 1246 Parameters" Registry defined in Section 8.2 of 1247 [I-D.ietf-ace-key-groupcomm]. 1249 o Name: clientId 1251 o CBOR Key: TBD 1253 o CBOR Type: Byte string 1255 o Reference: [[This document]] (Section 7). 1257 16. References 1259 16.1. Normative References 1261 [I-D.ietf-ace-cwt-proof-of-possession] 1262 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1263 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1264 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 1265 possession-11 (work in progress), October 2019. 1267 [I-D.ietf-ace-key-groupcomm] 1268 Palombini, F. and M. Tiloca, "Key Provisioning for Group 1269 Communication using ACE", draft-ietf-ace-key-groupcomm-03 1270 (work in progress), November 2019. 1272 [I-D.ietf-ace-oauth-authz] 1273 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1274 H. Tschofenig, "Authentication and Authorization for 1275 Constrained Environments (ACE) using the OAuth 2.0 1276 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-25 1277 (work in progress), October 2019. 1279 [I-D.ietf-ace-oscore-profile] 1280 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1281 "OSCORE profile of the Authentication and Authorization 1282 for Constrained Environments Framework", draft-ietf-ace- 1283 oscore-profile-08 (work in progress), July 2019. 1285 [I-D.ietf-core-oscore-groupcomm] 1286 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1287 "Group OSCORE - Secure Group Communication for CoAP", 1288 draft-ietf-core-oscore-groupcomm-05 (work in progress), 1289 July 2019. 1291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1292 Requirement Levels", BCP 14, RFC 2119, 1293 DOI 10.17487/RFC2119, March 1997, 1294 . 1296 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1297 Resource Identifier (URI): Generic Syntax", STD 66, 1298 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1299 . 1301 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1302 Application Protocol (CoAP)", RFC 7252, 1303 DOI 10.17487/RFC7252, June 2014, 1304 . 1306 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1307 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1308 . 1310 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1311 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1312 May 2017, . 1314 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1315 "Object Security for Constrained RESTful Environments 1316 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1317 . 1319 16.2. Informative References 1321 [I-D.dijk-core-groupcomm-bis] 1322 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1323 for the Constrained Application Protocol (CoAP)", draft- 1324 dijk-core-groupcomm-bis-01 (work in progress), July 2019. 1326 [I-D.ietf-ace-dtls-authorize] 1327 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1328 L. Seitz, "Datagram Transport Layer Security (DTLS) 1329 Profile for Authentication and Authorization for 1330 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1331 authorize-08 (work in progress), April 2019. 1333 [I-D.ietf-core-coap-pubsub] 1334 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1335 Subscribe Broker for the Constrained Application Protocol 1336 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 1337 progress), September 2019. 1339 [I-D.ietf-core-echo-request-tag] 1340 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 1341 Request-Tag, and Token Processing", draft-ietf-core-echo- 1342 request-tag-08 (work in progress), November 2019. 1344 [I-D.tiloca-core-oscore-discovery] 1345 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1346 Groups with the CoRE Resource Directory", draft-tiloca- 1347 core-oscore-discovery-03 (work in progress), July 2019. 1349 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1350 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1351 January 2012, . 1353 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1354 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1355 . 1357 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 1358 the Constrained Application Protocol (CoAP)", RFC 7390, 1359 DOI 10.17487/RFC7390, October 2014, 1360 . 1362 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1363 Application Protocol (CoAP)", RFC 7641, 1364 DOI 10.17487/RFC7641, September 2015, 1365 . 1367 Appendix A. Profile Requirements 1369 This appendix lists the specifications on this application profile of 1370 ACE, based on the requiremens defined in Appendix A of 1371 [I-D.ietf-ace-key-groupcomm]. 1373 o REQ1 - Specify the encoding and value of the identifier of group 1374 of 'scope': see Section 3.1. 1376 o REQ2 - Specify the encoding and value of the identifier of roles 1377 of 'scope': see Section 3.1. 1379 o REQ3 (Optional) - Specify the acceptable values for 'sign_alg': 1380 values from Tables 5 and 6 of [RFC8152]. 1382 o REQ4 (Optional) - Specify the acceptable values for 1383 'sign_parameters': values from the "Counter Signature Parameters" 1384 Registry (see Section 9.1 of [I-D.ietf-core-oscore-groupcomm]). 1386 o REQ5 (Optional) - Specify the acceptable values for 1387 'sign_key_parameters': values from the "Counter Signature Key 1388 Parameters" Registry (see Section 9.2 of 1389 [I-D.ietf-core-oscore-groupcomm]). 1391 o REQ6 (Optional) - Specify the acceptable values for 'pub_key_enc': 1392 1 ("COSE_Key") from the 'Confirmation Key' column of the "CWT 1393 Confirmation Method" Registry defined in 1394 [I-D.ietf-ace-cwt-proof-of-possession]. Future specifications may 1395 define additional values for this parameter. 1397 o REQ7 - Format of the 'key' value: see Section 4.3. 1399 o REQ8 - Acceptable values of 'kty': Group_OSCORE_Security_Context 1400 object (see Section 4.3). 1402 o REQ9: Specify the format of the identifiers of group members: see 1403 Section 4.3 and Section 8. 1405 o REQ10 (Optional) - Specify the format and content of 1406 'group_policies' entries: three values are defined and registered, 1407 as content of the entry "Sequence Number Synchronization Method" 1408 (see Section 15.4). 1410 o REQ11 - Communication protocol that the members of the group must 1411 use: CoAP, possibly over IP multicast. 1413 o REQ12 - Security protocols that the group members must use to 1414 protect their communication: Group OSCORE. 1416 o REQ13 - Profile identifier: coap_group_oscore_app 1418 o REQ14 (Optional) - Specify the encoding of public keys, of 1419 'client_cred', and of 'pub_keys' if COSE_Keys are not used: no. 1421 o REQ15 - Specify policies at the KDC to handle member ids that are 1422 not included in 'get_pub_keys': see Section 8. 1424 o REQ16 - Specify the format and content of 'group_policies': see 1425 Section 4.3. 1427 o REQ17 - Specify the format of newly-generated individual keying 1428 material for group members, or of the information to derive it, 1429 and corresponding CBOR label: see Section 7. 1431 o REQ18 - Specify how the communication is secured between the 1432 Client and KDC: by means of any transport profile of ACE 1433 [I-D.ietf-ace-oauth-authz] between Client and Group Manager that 1434 complies with the requirements in Appendix C of 1435 [I-D.ietf-ace-oauth-authz]. 1437 o OPT1 (Optional) - Specify the encoding of public keys, of 1438 'client_cred', and of 'pub_keys' if COSE_Keys are not used: no. 1440 o OPT2 (Optional) - Specify the negotiation of parameter values for 1441 signature algorithm and signature keys, if 'sign_info' and 1442 'pub_key_enc' are not used: possible early discovery by using the 1443 approach based on the CoRE Resource Directory described in 1444 [I-D.tiloca-core-oscore-discovery]. 1446 o OPT3 (Optional) - Specify the format and content of 1447 'mgt_key_material': no. 1449 o OPT4 (Optional) - Specify policies that instruct clients to retain 1450 unsuccessfully decrypted messages and for how long, so that they 1451 can be decrypted after getting updated keying material: no. 1453 Appendix B. Document Updates 1455 RFC EDITOR: PLEASE REMOVE THIS SECTION. 1457 B.1. Version -02 to -03 1459 o New sections, aligned with the interface of ace-key-groupcomm . 1461 o Exchange of information on the countersignature algorithm and 1462 related parameters, during the Token POST (Section 4.1). 1464 o Nonce 'rsnonce' from the Group Manager to the Client 1465 (Section 4.1). 1467 o Client PoP signature in the Key Distribution Request upon joining 1468 (Section 4.2). 1470 o Local actions on the Group Manager, upon a new node's joining 1471 (Section 4.2). 1473 o Local actions on the Group Manager, upon a node's leaving 1474 (Section 12). 1476 o IANA registration in ACE Groupcomm Parameters Registry. 1478 o More fulfilled profile requirements (Appendix A). 1480 B.2. Version -01 to -02 1482 o Editorial fixes. 1484 o Changed: "listener" to "responder"; "pure listener" to "monitor". 1486 o Changed profile name to "coap_group_oscore_app", to reflect it is 1487 an application profile. 1489 o Added the 'type' parameter for all requests to a Join Resource. 1491 o Added parameters to indicate the encoding of public keys. 1493 o Challenge-response for proof-of-possession of signature keys 1494 (Section 4). 1496 o Renamed 'key_info' parameter to 'sign_info'; updated its format; 1497 extended to include also parameters of the countersignature key 1498 (Section 4.1). 1500 o Code 4.00 (Bad request), in responses to joining nodes providing 1501 an invalid public key (Section 4.3). 1503 o Clarifications on provisioning and checking of public keys 1504 (Sections 4 and 6). 1506 o Extended discussion on group rekeying and possible different 1507 approaches (Section 7). 1509 o Extended security considerations: proof-of-possession of signature 1510 keys; collision of OSCORE Group Identifiers (Section 8). 1512 o Registered three entries in the IANA Registry "Sequence Number 1513 Synchronization Method Registry" (Section 9). 1515 o Registered one public key encoding in the "ACE Public Key 1516 Encoding" IANA Registry (Section 9). 1518 B.3. Version -00 to -01 1520 o Changed name of 'req_aud' to 'audience' in the Authorization 1521 Request (Section 3.1). 1523 o Added negotiation of countersignature algorithm/parameters between 1524 Client and Group Manager (Section 4). 1526 o Updated format of the Key Distribution Response as a whole 1527 (Section 4.3). 1529 o Added parameter 'cs_params' in the 'key' parameter of the Key 1530 Distribution Response (Section 4.3). 1532 o New IANA registrations in the "ACE Authorization Server Request 1533 Creation Hints" Registry, "ACE Groupcomm Key" Registry, "OSCORE 1534 Security Context Parameters" Registry and "ACE Groupcomm Profile" 1535 Registry (Section 9). 1537 Acknowledgments 1539 The authors sincerely thank Santiago Aragon, Stefan Beck, Carsten 1540 Bormann, Martin Gunnarsson, Rikard Hoeglund, Daniel Migault, Jim 1541 Schaad, Ludwig Seitz, Goeran Selander and Peter van der Stok for 1542 their comments and feedback. 1544 The work on this document has been partly supported by VINNOVA and 1545 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 1546 Initiative ACTIVE. 1548 Authors' Addresses 1550 Marco Tiloca 1551 RISE AB 1552 Isafjordsgatan 22 1553 Kista SE-164 29 Stockholm 1554 Sweden 1556 Email: marco.tiloca@ri.se 1558 Jiye Park 1559 Universitaet Duisburg-Essen 1560 Schuetzenbahn 70 1561 Essen 45127 1562 Germany 1564 Email: ji-ye.park@uni-due.de 1566 Francesca Palombini 1567 Ericsson AB 1568 Torshamnsgatan 23 1569 Kista SE-16440 Stockholm 1570 Sweden 1572 Email: francesca.palombini@ericsson.com