idnits 2.17.1 draft-tiloca-ace-oscoap-joining-05.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 (October 22, 2018) is 2013 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 (-46) exists of draft-ietf-ace-oauth-authz-16 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-04 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-15 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-02 == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-05 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group M. Tiloca 3 Internet-Draft RISE AB 4 Intended status: Standards Track J. Park 5 Expires: April 25, 2019 Universitaet Duisburg-Essen 6 F. Palombini 7 Ericsson AB 8 October 22, 2018 10 Key Management for OSCORE Groups in ACE 11 draft-tiloca-ace-oscoap-joining-05 13 Abstract 15 This document describes a method to request and provision keying 16 material in group communication scenarios where communications are 17 based on CoAP and secured with Object Security for Constrained 18 RESTful Environments (OSCORE). The proposed method delegates the 19 authentication and authorization of new client nodes that join an 20 OSCORE group through a Group Manager server. This approach builds on 21 the ACE framework for Authentication and Authorization, and leverages 22 protocol-specific profiles of ACE to achieve communication security, 23 proof-of-possession and server authentication. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 25, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Relation to Other Documents . . . . . . . . . . . . . . . 5 62 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 63 2.1. Overview of the Join Process . . . . . . . . . . . . . . 7 64 2.2. Overview of the Group Rekeying Process . . . . . . . . . 7 65 3. Joining Node to Authorization Server . . . . . . . . . . . . 8 66 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 8 67 3.2. Authorization Response . . . . . . . . . . . . . . . . . 9 68 4. Joining Node to Group Manager . . . . . . . . . . . . . . . . 10 69 4.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 10 70 4.2. Join Response . . . . . . . . . . . . . . . . . . . . . . 10 71 5. Leaving of a Group Member . . . . . . . . . . . . . . . . . . 12 72 6. Public Keys of Joining Nodes . . . . . . . . . . . . . . . . 12 73 7. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 14 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 10.2. Informative References . . . . . . . . . . . . . . . . . 16 79 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 Object Security for Constrained RESTful Environments (OSCORE) 85 [I-D.ietf-core-object-security] is a method for application-layer 86 protection of the Constrained Application Protocol (CoAP) [RFC7252], 87 using CBOR Object Signing and Encryption (COSE) [RFC8152] and 88 enabling end-to-end security of CoAP payload and options. 90 As described in [I-D.ietf-core-oscore-groupcomm], OSCORE may be used 91 to protect CoAP group communication over IP multicast [RFC7390]. 92 This relies on a Group Manager, which is responsible for managing an 93 OSCORE group, where members exchange CoAP messages secured with 94 OSCORE. The Group Manager can be responsible for multiple groups, 95 coordinates the join process of new group members, and is entrusted 96 with the distribution and renewal of group keying material. 98 This specification builds on the ACE framework for Authentication and 99 Authorization [I-D.ietf-ace-oauth-authz] and defines a method to: 101 o Authorize a node to join an OSCORE group, and provide it with the 102 group keying material to communicate with other group members. 104 o Provide updated keying material to group members upon request. 106 o Renew the group keying material and distribute it to the OSCORE 107 group (rekeying) upon changes in the group membership. 109 A client node joins an OSCORE group through a resource server acting 110 as Group Manager for that group. The join process relies on an 111 Access Token, which is bound to a proof-of-possession key and 112 authorizes the client to access a specific join resource at the Group 113 Manager. 115 Messages exchanged among the participants follow the formats defined 116 in [I-D.palombini-ace-key-groupcomm] for provisioning and renewing 117 keying material in group communication scenarios. 119 In order to achieve communication security, proof-of-possession and 120 server authentication, the client and the Group Manager leverage 121 protocol-specific profiles of ACE. These include also possible 122 forthcoming profiles that comply with the requirements in Appendix C 123 of [I-D.ietf-ace-oauth-authz]. 125 1.1. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119][RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 Readers are expected to be familiar with the terms and concepts 134 described in the ACE framework for authentication and authorization 135 [I-D.ietf-ace-oauth-authz]. The terminology for entities in the 136 considered architecture is defined in OAuth 2.0 [RFC6749]. In 137 particular, this includes Client (C), Resource Server (RS), and 138 Authorization Server (AS). 140 Readers are expected to be familiar with the terms and concepts 141 related to the CoAP protocol described in [RFC7252][RFC7390]. Note 142 that, unless otherwise indicated, the term "endpoint" is used here 143 following its OAuth definition, aimed at denoting resources such as 144 /token and /introspect at the AS and /authz-info at the RS. This 145 document does not use the CoAP definition of "endpoint", which is "An 146 entity participating in the CoAP protocol". 148 Readers are expected to be familiar with the terms and concepts for 149 protection and processing of CoAP messages through OSCORE 150 [I-D.ietf-core-object-security] also in group communication scenarios 151 [I-D.ietf-core-oscore-groupcomm]. These include the concept of Group 152 Manager, as the entity responsible for a set of groups where 153 communications are secured with OSCORE. In this specification, the 154 Group Manager acts as Resource Server. 156 This document refers also to the following terminology. 158 o Joining node: a network node intending to join an OSCORE group, 159 where communication is based on CoAP [RFC7390] and secured with 160 OSCORE as described in [I-D.ietf-core-oscore-groupcomm]. 162 o Join process: the process through which a joining node becomes a 163 member of an OSCORE group. The join process is enforced and 164 assisted by the Group Manager responsible for that group. 166 o Join resource: a resource hosted by the Group Manager, associated 167 to an OSCORE group under that Group Manager. A join resource is 168 identifiable with the Group Identifier (Gid) of the respective 169 group. A joining node accesses a join resource to start the join 170 process and become a member of that group. 172 o Join endpoint: an endpoint at the Group Manager associated to a 173 join resource. 175 o Requester: member of an OSCORE group that sends request messages 176 to other members of the group. 178 o Listener: member of an OSCORE group that receives request messages 179 from other members of the group. A listener may reply back, by 180 sending a response message to the requester which has sent the 181 request message. 183 o Pure listener: member of a group that is configured as listener 184 and never replies back to requesters after receiving request 185 messages. This corresponds to the term "silent server" used in 186 [I-D.ietf-core-oscore-groupcomm]. 188 o Group rekeying process: the process through which the Group 189 Manager renews the security parameters and group keying material, 190 and (re-)distributes them to the OSCORE group members. 192 1.2. Relation to Other Documents 194 Figure 1 overviews the main documents related to this specification. 195 Arrows and asterisk-arrows denote normative references and 196 informative refences, respectively. 198 +---------------------------------------+ 199 | | 200 +----------------|--------------+ | 201 | | | | 202 | v v Key Management 203 Pub-sub ---> Key Groupcomm ---> ACE Framework <--- for OSCORE Groups 204 profile * * [[WG]] [[This document]] 205 | * * ^ ^ | | 206 | * * * * | | 207 | * * * *************** | | 208 | ************ * * * | | 209 | * * * * +--------------+ | 210 ACE | * * * * | | 211 -----|-*--------------*--------------*-*-|--------------------|------- 212 CoRE | * * * * | | 213 v v v * * v v 214 CoRE CoRE OSCORE -------------> OSCORE 215 Pubsub Groupcomm <*** Groupcomm <************* [[WG]] 216 [[WG]] [[RFC7390]] [[WG]] 218 Figure 1: Related Documents 220 2. Protocol Overview 222 Group communication for CoAP over IP multicast has been enabled in 223 [RFC7390] and can be secured with Object Security for Constrained 224 RESTful Environments (OSCORE) [I-D.ietf-core-object-security] as 225 described in [I-D.ietf-core-oscore-groupcomm]. A network node joins 226 an OSCORE group by interacting with the responsible Group Manager. 227 Once registered in the group, the new node can securely exchange 228 messages with other group members. 230 This specification describes how to use the ACE framework for 231 authentication and authorization [I-D.ietf-ace-oauth-authz] to: 233 o Enable a node to join an OSCORE group through the Group Manager 234 and receive the security parameters and keying material to 235 communicate with the other members of the gorup. 237 o Enable members of OSCORE groups to retrieve updated group keying 238 material from the Group Manager. 240 o Enable the Group Manager to renew the security parameters and 241 group keying material, and to (re-)distribute them to the members 242 of the OSCORE group (rekeying). 244 With reference to the ACE framework and the terminology defined in 245 OAuth 2.0 [RFC6749]: 247 o The Group Manager acts as Resource Server (RS), and hosts one join 248 resource for each OSCORE group it manages. Each join resource is 249 exported by a distinct join endpoint. During the join process, 250 the Group Manager provides joining nodes with the parameters and 251 keying material for taking part to secure communications in the 252 OSCORE group. The Group Manager also maintains the group keying 253 material and performs the group rekeying process to distribute 254 updated keying material to the group members. 256 o The joining node acts as Client (C), and requests to join an 257 OSCORE group by accessing the related join endpoint at the Group 258 Manager. 260 o The Authorization Server (AS) authorizes joining nodes to join 261 OSCORE groups under their respective Group Manager. Multiple 262 Group Managers can be associated to the same AS. The AS MAY 263 release Access Tokens for other purposes than joining OSCORE 264 groups under registered Group Managers. For example, the AS may 265 also release Access Tokens for accessing resources hosted by 266 members of OSCORE groups. 268 All communications between the involved entities rely on the CoAP 269 protocol and MUST be secured. 271 In particular, communications between the joining node and the Group 272 Manager leverage protocol-specific profiles of ACE to achieve 273 communication security, proof-of-possession and server 274 authentication. To this end, the AS must signal the specific profile 275 to use, consistently with requirements and assumptions defined in the 276 ACE framework [I-D.ietf-ace-oauth-authz]. 278 With reference to the AS, communications between the joining node and 279 the AS (/token endpoint) as well as between the Group Manager and the 280 AS (/introspect endpoint) can be secured by different means, for 281 instance using DTLS [RFC6347] or OSCORE 282 [I-D.ietf-core-object-security]. Further details on how the AS 283 secures communications (with the joining node and the Group Manager) 284 depend on the specifically used profile of ACE, and are out of the 285 scope of this specification. 287 2.1. Overview of the Join Process 289 A node performs the following steps in order to join an OSCORE group. 290 Messages exchanged among the participants follow the formats defined 291 in [I-D.palombini-ace-key-groupcomm], and are further specified in 292 Section 3 and Section 4 of this document. The Group Manager acts as 293 the Key Distribution Center (KDC) defined in 294 [I-D.palombini-ace-key-groupcomm]. 296 1. The joining node requests an Access Token from the AS, in order 297 to access a join resource on the Group Manager and hence join the 298 associated OSCORE group (see Section 3). The joining node will 299 start or continue using a secure communication channel with the 300 Group Manager, according to the response from the AS. 302 2. The joining node transfers authentication and authorization 303 information to the Group Manager by posting the obtained Access 304 Token (see Section 4). After that, a joining node must have a 305 secure communication channel established with the Group Manager, 306 before starting to join an OSCORE group under that Group Manager 307 (see Section 4). Possible ways to provide a secure communication 308 channel are DTLS [RFC6347] and OSCORE 309 [I-D.ietf-core-object-security]. 311 3. The joining node starts the join process to become a member of 312 the OSCORE group, by accessing the related join resource hosted 313 by the Group Manager (see Section 4). 315 4. At the end of the join process, the joining node has received 316 from the Group Manager the parameters and keying material to 317 securely communicate with the other members of the OSCORE group. 319 5. The joining node and the Group Manager maintain the secure 320 channel, to support possible future communications. 322 All further communications between the joining node and the Group 323 Manager MUST be secured, for instance with the same secure channel 324 mentioned in step 2. 326 2.2. Overview of the Group Rekeying Process 328 If the application requires backward and forward security, the Group 329 Manager MUST generate new security parameters and group keying 330 material, and distribute them to the group (rekeying) upon membership 331 changes. 333 That is, the group is rekeyed when a node joins the group as a new 334 member, or after a current member leaves the group. By doing so, a 335 joining node cannot access communications in the group prior its 336 joining, while a leaving node cannot access communications in the 337 group after its leaving. 339 Parameters and keying material include a new Group Identifier (Gid) 340 for the group and a new Master Secret for the OSCORE Common Security 341 Context of that group (see Section 2 of 342 [I-D.ietf-core-oscore-groupcomm]). 344 The Group Manager MUST support the Group Rekeying Process described 345 in Section 7. Future application profiles may define alternative 346 message formats and distribution schemes to perform group rekeying. 348 3. Joining Node to Authorization Server 350 This section describes how the joining node interacts with the AS in 351 order to be authorized to join an OSCORE group under a given Group 352 Manager. In particular, it considers a joining node that intends to 353 contact that Group Manager for the first time. 355 The message exchange between the joining node and the AS consists of 356 the messages Authorization Request and Authorization Response defined 357 in Section 3 of [I-D.palombini-ace-key-groupcomm]. 359 In case the specific AS associated to the Group Manager is unknown to 360 the joining node, the latter can rely on mechanisms like the 361 Unauthorized Resource Request message described in Section 5.1.1 of 362 [I-D.ietf-ace-oauth-authz] to discover the correct AS to contact. 364 3.1. Authorization Request 366 The joining node contacts the AS, in order to request an Access Token 367 for accessing the join resource hosted by the Group Manager and 368 associated to the OSCORE group. The Access Token request sent to the 369 /token endpoint follows the format of the Authorization Request 370 message defined in Section 3.1 of [I-D.palombini-ace-key-groupcomm]. 371 In particular: 373 o The 'scope' parameter MUST be present and MUST include: 375 * in the first element, either the Group Identifier (Gid) of the 376 group to join under the Group Manager, or a value from which 377 the Group Manager can derive the Gid of the group to join. It 378 is up to the application to define how the Group Manager 379 possibly performs the derivation of the full Gid. Appendix C of 380 [I-D.ietf-core-oscore-groupcomm] provides an example of 381 structured Gid, composed of a fixed part, namely Group Prefix, 382 and a variable part, namely Group Epoch. 384 * in the second element, the role(s) that the joining node 385 intends to have in the group it intends to join. Possible 386 values are: "requester"; "listener"; and "pure listener". 387 Possible combinations are: ["requester" , "listener"]; 388 ["requester" , "pure listener"]. 390 o The 'req_aud' parameter MUST be present and is set to the 391 identifier of the Group Manager. 393 3.2. Authorization Response 395 The AS is responsible for authorizing the joining node to join 396 specific OSCORE groups, according to join policies enforced on behalf 397 of the respective Group Manager. 399 In case of successful authorization, the AS releases an Access Token 400 bound to a proof-of-possession key associated to the joining node. 402 Then, the AS provides the joining node with the Access Token as part 403 of an Access Token response, which follows the format of the 404 Authorization Response message defined in Section 3.2 of 405 [I-D.palombini-ace-key-groupcomm]. 407 The 'exp' parameter MUST be present. Other means for the AS to 408 specify the lifetime of Access Tokens are out of the scope of this 409 specification. 411 The AS must include the 'scope' parameter in the response when the 412 value included in the Access Token differs from the one specified by 413 the joining node in the request. In such a case, the second element 414 of 'scope' MUST be present and includes the role(s) that the joining 415 node is actually authorized to take in the group, encoded as 416 specified in Section 3.1 of this document. 418 Also, the 'profile' parameter indicates the specific profile of ACE 419 to use for securing communications between the joining node and the 420 Group Manager (see Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]). 422 In particular, if symmetric keys are used, the AS generates a proof- 423 of-possession key, binds it to the Access Token, and provides it to 424 the joining node in the 'cnf' parameter of the Access Token response. 425 Instead, if asymmetric keys are used, the joining node provides its 426 own public key to the AS in the 'req_cnf' parameter of the Access 427 Token request. Then, the AS uses it as proof-of-possession key bound 428 to the Access Token, and provides the joining node with the Group 429 Manager's public key in the 'rs_cnf' parameter of the Access Token 430 response. 432 4. Joining Node to Group Manager 434 First, the joining node posts the Access Token to the /authz-info 435 endpoint at the Group Manager, in accordance with the Token post 436 defined in Section 3.3 of [I-D.palombini-ace-key-groupcomm]. Then, 437 the joining node establishes a secure channel with the Group Manager, 438 according to what is specified in the Access Token response and to 439 the signalled profile of ACE. 441 4.1. Join Request 443 Once a secure communication channel with the Group Manager has been 444 established, the joining node requests to join the OSCORE group, by 445 accessing the related join resource at the Group Manager. 447 In particular, the joining node sends to the Group Manager a 448 confirmable CoAP request, using the method POST and targeting the 449 join endpoint associated to that group. This join request follows 450 the format and processing of the Key Distribution Request message 451 defined in Section 4.1 of [I-D.palombini-ace-key-groupcomm]. In 452 particular: 454 o The 'get_pub_keys' parameter is present only if the joining node 455 wants to retrieve the public keys of the group members from the 456 Group Manager during the join process (see Section 6). Otherwise, 457 this parameter MUST NOT be present. 459 o The 'client_cred' parameter, if present, includes the public key 460 of the joining node. This parameter MAY be omitted if: i) public 461 keys are used as proof-of-possession keys between the joining node 462 and the Group Manager; or ii) the joining node is asking to access 463 the group exclusively as pure listener; or iii) the Group Manager 464 already acquired this information during a previous join process. 465 In any other case, this parameter MUST be present. 467 4.2. Join Response 469 The Group Manager processes the request according to 470 [I-D.ietf-ace-oauth-authz]. If this yields a positive outcome, the 471 Group Manager updates the group membership by registering the joining 472 node as a new member of the OSCORE group. 474 The Group Manager replies to the joining node providing the updated 475 security parameters and keying meterial necessary to participate in 476 the group communication. This join response follows the format and 477 processing of the Key Distribution success Response message defined 478 in Section 4.2 of [I-D.palombini-ace-key-groupcomm]. In particular: 480 o The 'key' parameter includes what the joining node needs in order 481 to set up the OSCORE Security Context as per Section 2 of 482 [I-D.ietf-core-oscore-groupcomm]. In particular: 484 * The 'kty' parameter has value "Symmetric". 486 * The 'k' parameter includes the OSCORE Master Secret. 488 * The 'exp' parameter specifies when the OSCORE Security Context 489 derived from these parameters expires. 491 * The 'alg' parameter, if present, has as value the AEAD 492 algorithm used in the group. 494 * The 'kid' parameter, if present, has as value the identifier of 495 the key in the parameter 'k'. 497 * The 'base IV' parameter, if present, has as value the OSCORE 498 Common IV. 500 * The 'clientID' parameter, if present, has as value the OSCORE 501 Sender ID assigned to the joining node by the Group Manager. 502 This parameter is not present if the node joins the group 503 exclusively as pure listener, according to what specified in 504 the Access Token (see Section 3.2). In any other case, this 505 parameter MUST be present. 507 * The 'serverID' parameter MUST be present and has as value the 508 Group Identifier (Gid) associated to the group. 510 * The 'kdf' parameter, if present, has as value the KDF algorithm 511 used in the group. 513 * The 'slt' parameter, if present, has as value the OSCORE Master 514 Salt. 516 * The 'cs_alg' parameter MUST be present and has as value the 517 countersignature algorithm used in the group. 519 o The 'pub_keys' parameter is present only if the 'get_pub_keys' 520 parameter was present in the join request. If present, this 521 parameter includes the public keys of the group members that are 522 relevant to the joining node. That is, it includes: i) the public 523 keys of the non-pure listeners currently in the group, in case the 524 joining node is configured (also) as requester; and ii) the public 525 keys of the requesters currently in the group, in case the joining 526 node is configured (also) as listener or pure listener. 528 o The 'group_policies' parameter SHOULD be present and includes a 529 list of parameters indicating particular policies enforced in the 530 group. For instance, it can indicate the method to achieve 531 synchronization of sequence numbers among group members (see 532 Appendix E of [I-D.ietf-core-oscore-groupcomm]). 534 Finally, the joining node uses the information received in the join 535 response to set up the OSCORE Security Context, as described in 536 Section 2 of [I-D.ietf-core-oscore-groupcomm]. From then on, the 537 joining node can exchange group messages secured with OSCORE as 538 described in [I-D.ietf-core-oscore-groupcomm]. 540 If the application requires backward security, the Group Manager 541 SHALL generate updated security parameters and group keying material, 542 and provide it to all the current group members (see Section 7). 544 When the OSCORE Master Secret expires, as specified by 'exp' in the 545 'key' parameter of the join response, the node considers the OSCORE 546 Security Context also invalid and to be renewed. Then, the node 547 retrieves updated security parameters and keying material, by 548 exchanging shortened Join Request and Join Response messages with the 549 Group Manager, according to the approach defined in Section 6 of 550 [I-D.palombini-ace-key-groupcomm]. Finally, the node uses the 551 updated security parameters and keying material to set up the new 552 OSCORE Security Context as described in Section 2 of 553 [I-D.ietf-core-oscore-groupcomm]. 555 5. Leaving of a Group Member 557 A node may be removed from the OSCORE group, due to expired or 558 revoked authorization, or after its own request to the Group Manager. 560 If the application requires forward security, the Group Manager SHALL 561 generate updated security parameters and group keying material, and 562 provide it to the remaining group members (see Section 7). The 563 leaving node must not be able to acquire the new security parameters 564 and group keying material distributed after its leaving. 566 Same considerations in Section 5 of [I-D.palombini-ace-key-groupcomm] 567 apply here as well, considering the Group Manager acting as KDC. In 568 particular, a node requests to leave the OSCORE group as described in 569 Section 5.2 of [I-D.palombini-ace-key-groupcomm]. 571 6. Public Keys of Joining Nodes 573 Source authentication of OSCORE messages exchanged within the group 574 is ensured by means of digital counter signatures (see Sections 2 and 575 3 of [I-D.ietf-core-oscore-groupcomm]). Therefore, group members 576 must be able to retrieve each other's public key from a trusted key 577 repository, in order to verify source authenticity of incoming group 578 messages. 580 As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group 581 Manager acts as trusted repository of the public keys of the group 582 members, and provides those public keys to group members if requested 583 to. Upon joining an OSCORE group, a joining node is thus expected to 584 provide its own public key to the Group Manager. 586 In particular, four cases can occur when a new node joins a group. 588 o The joining node is going to join the group exclusively as pure 589 listener. That is, it is not going to send messages to the group, 590 and hence to produce signatures with its own private key. In this 591 case, the joining node is not required to provide its own public 592 key to the Group Manager upon joining the group. 594 o The Group Manager already acquired the public key of the joining 595 node during a previous join process. In this case, the joining 596 node may not provide again its own public key to the Group 597 Manager, in order to limit the size of the join request. 599 o The joining node and the Group Manager use an asymmetric proof-of- 600 possession key to establish a secure communication channel. In 601 this case, the Group Manager stores the proof-of-possession key 602 conveyed in the Access Token as the public key of the joining 603 node. 605 o The joining node and the Group Manager use a symmetric proof-of- 606 possession key to establish a secure communication channel. In 607 this case, upon performing a join process with that Group Manager 608 for the first time, the joining node specifies its own public key 609 in the 'client_cred' parameter of the join request targeting the 610 join endpoint (see Section 4.1). 612 Furthermore, as described in Section 4.1, the joining node may have 613 explicitly requested the Group Manager to retrieve the public keys of 614 the current group members, i.e. through the 'get_pub_keys' parameter 615 in the join request. In this case, the Group Manager includes also 616 such public keys in the 'pub_keys' parameter of the join response 617 (see Section 4.2). 619 Later on as a group member, the node may need to retrieve the public 620 keys of other group members. The node can do that by exchanging 621 shortened Join Request and Join Response messages with the Group 622 Manager, according to the approach defined in Section 7 of 623 [I-D.palombini-ace-key-groupcomm]. 625 7. Group Rekeying Process 627 In order to rekey the OSCORE group, the Group Manager distributes a 628 new Group ID of the group and a new OSCORE Master Secret for that 629 group. To this end, the Group Manager MUST support at least the 630 following group rekeying scheme. Future application profiles may 631 define alternative message formats and distribution schemes. 633 The Group Manager uses the same format of the Join Response message 634 in Section 4.2. In particular: 636 o Only the 'key' parameter is present. 638 o The 'k' parameter of the 'key' parameter includes the new OSCORE 639 Master Secret. 641 o The 'serverID' parameter of the 'key' parameter includes the new 642 Group ID. 644 The Group Manager separately sends a group rekeying message to each 645 group member to be rekeyed. Each rekeying message MUST be secured 646 with the pairwise secure communication channel between the Group 647 Manager and the group member used during the join process. 649 8. Security Considerations 651 The method described in this document leverages the following 652 management aspects related to OSCORE groups and discussed in the 653 sections of [I-D.ietf-core-oscore-groupcomm] referred below. 655 o Management of group keying material (see Section 2.1 of 656 [I-D.ietf-core-oscore-groupcomm]). The Group Manager is 657 responsible for the renewal and re-distribution of the keying 658 material in the groups of its competence (rekeying). According to 659 the specific application requirements, this can include rekeying 660 the group upon changes in its membership. In particular, renewing 661 the keying material is required upon a new node's joining or a 662 current node's leaving, in case backward security and forward 663 security have to be preserved, respectively. 665 o Provisioning and retrieval of public keys (see Section 2 of 666 [I-D.ietf-core-oscore-groupcomm]). The Group Manager acts as key 667 repository of public keys of group members, and provides them upon 668 request. 670 o Synchronization of sequence numbers (see Section 5 of 671 [I-D.ietf-core-oscore-groupcomm]). This concerns how a listener 672 node that has just joined an OSCORE group can synchronize with the 673 sequence number of requesters in the same group. 675 Before sending the join response, the Group Manager should verify 676 that the joining node actually owns the associated private key, for 677 instance by performing a proof-of-possession challenge-response, 678 whose details are out of the scope of this specification. 680 Further security considerations are inherited from 681 [I-D.palombini-ace-key-groupcomm], the ACE framework for 682 Authentication and Authorization [I-D.ietf-ace-oauth-authz], and the 683 specific profile of ACE signalled by the AS, such as 684 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile]. 686 9. IANA Considerations 688 This document has no actions for IANA. 690 10. References 692 10.1. Normative References 694 [I-D.ietf-ace-oauth-authz] 695 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 696 H. Tschofenig, "Authentication and Authorization for 697 Constrained Environments (ACE) using the OAuth 2.0 698 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-16 699 (work in progress), October 2018. 701 [I-D.ietf-ace-oscore-profile] 702 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 703 "OSCORE profile of the Authentication and Authorization 704 for Constrained Environments Framework", draft-ietf-ace- 705 oscore-profile-04 (work in progress), October 2018. 707 [I-D.ietf-core-object-security] 708 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 709 "Object Security for Constrained RESTful Environments 710 (OSCORE)", draft-ietf-core-object-security-15 (work in 711 progress), August 2018. 713 [I-D.ietf-core-oscore-groupcomm] 714 Tiloca, M., Selander, G., Palombini, F., and J. Park, 715 "Secure group communication for CoAP", draft-ietf-core- 716 oscore-groupcomm-02 (work in progress), June 2018. 718 [I-D.palombini-ace-key-groupcomm] 719 Palombini, F. and M. Tiloca, "Key Provisioning for Group 720 Communication using ACE", draft-palombini-ace-key- 721 groupcomm-02 (work in progress), October 2018. 723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, 725 DOI 10.17487/RFC2119, March 1997, 726 . 728 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 729 Application Protocol (CoAP)", RFC 7252, 730 DOI 10.17487/RFC7252, June 2014, 731 . 733 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 734 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 735 May 2017, . 737 10.2. Informative References 739 [I-D.ietf-ace-dtls-authorize] 740 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 741 L. Seitz, "Datagram Transport Layer Security (DTLS) 742 Profile for Authentication and Authorization for 743 Constrained Environments (ACE)", draft-ietf-ace-dtls- 744 authorize-05 (work in progress), October 2018. 746 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 747 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 748 January 2012, . 750 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 751 RFC 6749, DOI 10.17487/RFC6749, October 2012, 752 . 754 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 755 the Constrained Application Protocol (CoAP)", RFC 7390, 756 DOI 10.17487/RFC7390, October 2014, 757 . 759 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 760 RFC 8152, DOI 10.17487/RFC8152, July 2017, 761 . 763 Acknowledgments 765 The authors sincerely thank Santiago Aragon, Stefan Beck, Martin 766 Gunnarsson, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van 767 der Stok for their comments and feedback. 769 The work on this document has been partly supported by the EIT- 770 Digital High Impact Initiative ACTIVE. 772 Authors' Addresses 774 Marco Tiloca 775 RISE AB 776 Isafjordsgatan 22 777 Kista SE-164 29 Stockholm 778 Sweden 780 Email: marco.tiloca@ri.se 782 Jiye Park 783 Universitaet Duisburg-Essen 784 Schuetzenbahn 70 785 Essen 45127 786 Germany 788 Email: ji-ye.park@uni-due.de 790 Francesca Palombini 791 Ericsson AB 792 Torshamnsgatan 23 793 Kista SE-16440 Stockholm 794 Sweden 796 Email: francesca.palombini@ericsson.com