idnits 2.17.1 draft-ietf-ace-key-groupcomm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 05, 2019) is 1758 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-24 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-05 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-05 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-03) exists of draft-dijk-core-groupcomm-bis-00 == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-08 == Outdated reference: A later version (-17) exists of draft-ietf-ace-mqtt-tls-profile-00 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-07 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-08 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group F. Palombini 3 Internet-Draft Ericsson AB 4 Intended status: Standards Track M. Tiloca 5 Expires: January 6, 2020 RISE AB 6 July 05, 2019 8 Key Provisioning for Group Communication using ACE 9 draft-ietf-ace-key-groupcomm-02 11 Abstract 13 This document defines message formats and procedures for requesting 14 and distributing group keying material using the ACE framework, to 15 protect communications between group members. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 6, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 6 55 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 7 56 3.2. Authorization Response . . . . . . . . . . . . . . . . . 7 57 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 8 58 4. Key Distribution . . . . . . . . . . . . . . . . . . . . . . 11 59 4.1. Key Distribution Request . . . . . . . . . . . . . . . . 12 60 4.2. Key Distribution Response . . . . . . . . . . . . . . . . 13 61 5. Removal of a Node from the Group . . . . . . . . . . . . . . 16 62 5.1. Expired Authorization . . . . . . . . . . . . . . . . . . 16 63 5.2. Request to Leave the Group . . . . . . . . . . . . . . . 16 64 6. Retrieval of New or Updated Keying Material . . . . . . . . . 17 65 6.1. Key Re-Distribution Request . . . . . . . . . . . . . . . 18 66 6.2. Key Re-Distribution Response . . . . . . . . . . . . . . 19 67 7. Retrieval of Public Keys for Group Members . . . . . . . . . 19 68 7.1. Public Key Request . . . . . . . . . . . . . . . . . . . 20 69 7.2. Public Key Response . . . . . . . . . . . . . . . . . . . 20 70 8. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 21 71 9. ACE Groupcomm Request Type . . . . . . . . . . . . . . . . . 22 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 73 10.1. Update of Keying Material . . . . . . . . . . . . . . . 24 74 10.2. Block-Wise Considerations . . . . . . . . . . . . . . . 24 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 76 11.1. ACE Authorization Server Request Creation Hints Registry 25 77 11.2. ACE Public Key Encoding Registry . . . . . . . . . . . . 25 78 11.3. ACE Groupcomm Parameters Registry . . . . . . . . . . . 26 79 11.4. Ace Groupcomm Request Type Registry . . . . . . . . . . 26 80 11.5. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 27 81 11.6. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 28 82 11.7. ACE Groupcomm Policy Registry . . . . . . . . . . . . . 28 83 11.8. Sequence Number Synchronization Method Registry . . . . 29 84 11.9. Expert Review Instructions . . . . . . . . . . . . . . . 29 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 87 12.2. Informative References . . . . . . . . . . . . . . . . . 31 88 Appendix A. Requirements on Application Profiles . . . . . . . . 33 89 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 33 90 B.1. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 34 91 B.2. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 34 92 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 95 1. Introduction 97 This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to 98 define the format of messages used to request, distribute and renew 99 the keying material in a group communication scenario, e.g. based on 100 multicast [RFC7390][I-D.dijk-core-groupcomm-bis] or on publishing- 101 subscribing [I-D.ietf-core-coap-pubsub]. The ACE framework is based 102 on CBOR [RFC7049], so CBOR is the format used in this specification. 103 However, using JSON [RFC8259] instead of CBOR is possible, using the 104 conversion method specified in Sections 4.1 and 4.2 of [RFC7049]. 106 Profiles that use group communication can build on this document to 107 specify the selection of the message parameters defined in this 108 document to use and their values. Known applications that can 109 benefit from this document would be, for example, those addressing 110 group communication based on multicast 111 [RFC7390][I-D.dijk-core-groupcomm-bis] or publishing/subscribing 112 [I-D.ietf-core-coap-pubsub] in ACE. 114 If the application requires backward and forward security, updated 115 keying material is generated and distributed to the group members 116 (rekeying), when membership changes. A key management scheme 117 performs the actual distribution of the updated keying material to 118 the group. In particular, the key management scheme rekeys the 119 current group members when a new node joins the group, and the 120 remaining group members when a node leaves the group. This document 121 provides a message format for group rekeying that allows to fulfill 122 these requirements. Rekeying mechanisms can be based on [RFC2093], 123 [RFC2094] and [RFC2627]. 125 1.1. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. These 130 words may also appear in this document in lowercase, absent their 131 normative meanings. 133 Readers are expected to be familiar with the terms and concepts 134 described in [I-D.ietf-ace-oauth-authz] and [RFC8152], such as 135 Authorization Server (AS) and Resource Server (RS). 137 This document additionally uses the following terminology: 139 o Transport profile, to indicate a profile of ACE as per 140 Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]. That is, a 141 transport profile specifies the communication protocol and 142 communication security protocol between an ACE Client and Resource 143 Server, as well as proof-of-possession methods, if it supports 144 proof-of-possession access tokens. Tranport profiles of ACE 145 include, for instance, [I-D.ietf-ace-oscore-profile], 146 [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile]. 148 o Application profile, to indicate a profile of ACE that defines how 149 applications enforce and use supporting security services they 150 require. These services include, for instance, provisioning, 151 revocation and (re-)distribution of keying material. An 152 application profile may define specific procedures and message 153 formats. 155 2. Overview 157 +------------+ +-----------+ 158 | AS | | KDC | 159 | | .-------->| | 160 +------------+ / +-----------+ 161 ^ / 162 | / 163 v / +-----------+ 164 +------------+ / +------------+ |+-----------+ 165 | Client |<-' | Dispatcher | ||+-----------+ 166 | |<-------->| (RS) |<------->|| Group | 167 +------------+ +------------+ +| members | 168 +-----------+ 170 Figure 1: Key Distribution Participants 172 The following participants (see Figure 1) take part in the 173 authorization and key distribution. 175 o Client (C): node that wants to join the group communication. It 176 can request write and/or read rights. 178 o Authorization Server (AS): same as AS in the ACE Framework; it 179 enforces access policies, and knows if a node is allowed to join 180 the group with write and/or read rights. 182 o Key Distribution Center (KDC): maintains the keying material to 183 protect group communications, and provides it to Clients 184 authorized to join the group. During the first part of the 185 exchange (Section 3), it takes the role of the RS in the ACE 186 Framework. During the second part (Section 4), which is not based 187 on the ACE Framework, it distributes the keying material. In 188 addition, it provides the latest keying material to group members 189 when requested. If required by the application, the KDC renews 190 and re-distributes the keying material in the group when 191 membership changes. 193 o Dispatcher: entity through which the Clients communicate with the 194 group and which distributes messages to the group members. 195 Examples of dispatchers are: the Broker node in a pub-sub setting; 196 a relayer node for group communication that delivers group 197 messages as multiple unicast messages to all group members; an 198 implicit entity as in a multicast communication setting, where 199 messages are transmitted to a multicast IP address and delivered 200 on the transport channel. 202 This document specifies the message flows and formats for: 204 o Authorizing a new node to join the group (Section 3), and 205 providing it with the group keying material to communicate with 206 the other group members (Section 4). 208 o Removing of a current member from the group (Section 5). 210 o Retrieving keying material as a current group member (Section 6 211 and Section 7). 213 o Renewing and re-distributing the group keying material (rekeying) 214 upon a membership change in the group (Section 4.2 and Section 5). 216 Figure 2 provides a high level overview of the message flow for a 217 node joining a group communication setting. 219 C AS KDC Dispatcher Group 220 | | | | Member 221 | | | | \ | 222 | Authorization Request | | | | Defined | 223 |----------------------------->| | | | in the ACE | 224 | | | | | framework | 225 | Authorization Response | | | | | 226 |<-----------------------------| | | | | 227 | | | | | | 228 |--------- Token Post ---------------->| | / | 229 | | | | 230 |---- Key Distribution Request ------->| | | 231 | | | | 232 |<--- Key Distribution Response ------ | --- Group Rekeying ----->| 233 | | | 234 |<================== Protected communication ===|================>| 235 | | | 237 Figure 2: Message Flow Upon New Node's Joining 239 The exchange of Authorization Request and Authorization Response 240 between Client and AS MUST be secured, as specified by the transport 241 profile of ACE used between Client and KDC. 243 The exchange of Key Distribution Request and Key Distribution 244 Response between Client and KDC MUST be secured, as a result of the 245 transport profile of ACE used between Client and KDC. 247 All further communications between the Client and the KDC MUST be 248 secured, for instance with the same security mechanism used for the 249 Key Distribution exchange. 251 All communications between a Client and the other group members MUST 252 be secured using the keying material provided in Section 4. 254 3. Authorization to Join a Group 256 This section describes in detail the format of messages exchanged by 257 the participants when a node requests access to a group. The first 258 part of the exchange is based on ACE [I-D.ietf-ace-oauth-authz]. 260 As defined in [I-D.ietf-ace-oauth-authz], the Client requests from 261 the AS an authorization to join the group through the KDC (see 262 Section 3.1). If the request is approved and authorization is 263 granted, the AS provides the Client with a proof-of-possession access 264 token and parameters to securely communicate with the KDC (see 265 Section 3.2). Communications between the Client and the AS MUST be 266 secured, according to the transport profile of ACE used. The 267 Content-Format used in the messages is the one specified by the used 268 transport profile of ACE (e.g. application/ace+cbor for the first two 269 messages and application/cwt for the third message, depending on the 270 format of the access token). 272 Figure 3 gives an overview of the exchange described above. 274 Client AS KDC 275 | | | 276 |---- Authorization Request: POST /token ------>| | 277 | | | 278 |<--- Authorization Response: 2.01 (Created) ---| | 279 | | | 280 |----- POST Token: POST /authz-info --------------->| 281 | | 283 Figure 3: Message Flow of Join Authorization 285 3.1. Authorization Request 287 The Authorization Request sent from the Client to the AS is as 288 defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MUST 289 contain the following parameters: 291 o 'grant_type', with value "client_credentials". 293 Additionally, the Authorization Request MAY contain the following 294 parameters, which, if included, MUST have the corresponding values: 296 o 'scope', containing the identifier of the specific group (or topic 297 in the case of pub-sub) that the Client wishes to access, and 298 optionally the role(s) that the Client wishes to take. This value 299 is a CBOR array encoded as a byte string, which contains: 301 * As first element, the identifier of the specific group or 302 topic. 304 * Optionally, as second element, the role (or CBOR array of 305 roles) the Client wishes to take in the group. 307 The encoding of the group or topic identifier and of the role 308 identifiers is application specific. 310 o 'audience', with an identifier of a KDC. 312 o 'req_cnf', as defined in Section 3.1 of 313 [I-D.ietf-ace-oauth-params], optionally containing the public key 314 or a reference to the public key of the Client, if it wishes to 315 communicate that to the AS. 317 o Other additional parameters as defined in 318 [I-D.ietf-ace-oauth-authz], if necessary. 320 3.2. Authorization Response 322 The Authorization Response sent from the AS to the Client is as 323 defined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST 324 contain the following parameters: 326 o 'access_token', containing the proof-of-possession access token. 328 o 'cnf' if symmetric keys are used, not present if asymmetric keys 329 are used. This parameter is defined in Section 3.2 of 330 [I-D.ietf-ace-oauth-params] and contains the symmetric proof-of- 331 possession key that the Client is supposed to use with the KDC. 333 o 'rs_cnf' if asymmetric keys are used, not present if symmetric 334 keys are used. This parameter is as defined in Section 3.2 of 335 [I-D.ietf-ace-oauth-params] and contains information about the 336 public key of the KDC. 338 o 'exp', contains the lifetime in seconds of the access token. This 339 parameter MAY be omitted if the application defines how the 340 expiration time is communicated to the Client via other means, or 341 if it establishes a default value. 343 Additionally, the Authorization Response MAY contain the following 344 parameters, which, if included, MUST have the corresponding values: 346 o 'scope', which mirrors the 'scope' parameter in the Authorization 347 Request (see Section 3.1). Its value is a CBOR array encoded as a 348 byte string, containing: 350 * As first element, the identifier of the specific group or topic 351 the Client is authorized to access. 353 * Optionally, as second element, the role (or CBOR array of 354 roles) the Client is authorized to take in the group. 356 The encoding of the group or topic identifier and of the role 357 identifiers is application specific. 359 o Other additional parameters as defined in 360 [I-D.ietf-ace-oauth-authz], if necessary. 362 The access token MUST contain all the parameters defined above 363 (including the same 'scope' as in this message, if present, or the 364 'scope' of the Authorization Request otherwise), and additionally 365 other optional parameters that the transport profile of ACE requires. 367 When receiving an Authorization Request from a Client that was 368 previously authorized, and which still owns a valid non expired 369 access token, the AS replies with an Authorization Response with a 370 new access token. 372 3.3. Token Post 374 The Client sends a CoAP POST request including the access token to 375 the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. 376 If the specific transport profile of ACE defines it, the Client MAY 377 use a different endpoint than /authz-info at the KDC to post the 378 access token to. 380 Optionally, the Client might need to request necessary information 381 concerning the public keys in the group, as well as concerning the 382 algorithm and related parameters for computing signatures in the 383 group. In such a case, the joining node MAY ask for that information 384 to the KDC in this same request. To this end, it sends the CoAP POST 385 request to the /authz-info endpoint using the Content-Format 386 "application/ace+cbor" defined in Section 8.14 of 387 [I-D.ietf-ace-oauth-authz], and includes also the following 388 parameters: 390 o 'sign_info' defined in Section 3.3.1, encoding the CBOR simple 391 value Null, to require information and parameters on the signature 392 algorithm and on the public keys used in the group. 394 o 'pub_key_enc' defined in Section 3.3.2, encoding the CBOR simple 395 value Null, to require information on the exact encoding of public 396 keys used in the group. 398 The CDDL notation of the 'sign_info' and 'pub_key_enc' parameters 399 formatted as in the request is given below. 401 sign_info_req = nil 403 pub_key_enc_req = nil 405 Alternatively, the joining node may retrieve this information by 406 other means. 408 After successful verification, the Client is authorized to receive 409 the group keying material from the KDC and join the group. In 410 particular, the KDC replies to the Client with a 2.01 (Created) 411 response, using Content-Format "application/ace+cbor" defined in 412 Section 8.14 of [I-D.ietf-ace-oauth-authz]. 414 The payload of the 2.01 response is a CBOR map, which MUST include a 415 nonce N generated by the KDC. The Client may use this nonce for 416 proving the possession of its own private key (see the 417 'client_cred_verify' parameter in Section 4). 419 Optionally, if they were included in the request, the AS MAY include 420 the 'sign_info' parameter as well as the 'pub_key_enc' parameter 421 defined in Section 3.3.1 and Section 3.3.2 of this specification, 422 respectively. 424 The 'sign_info' parameter MUST be present if the POST request 425 included the 'sign_info' parameter with value Null. If present, the 426 'sign_info' parameter of the 2.01 (Created) response is a CBOR array 427 formatted as follows. 429 o The first element 'sign_alg' is an integer or a text string, 430 indicating the signature algorithm used in the group. It is 431 required of the application profiles to define specific values for 432 this parameter. 434 o The second element 'sign_parameters' indicates the parameters of 435 the signature algorithm. Its structure depends on the value of 436 'sign_alg'. It is required of the application profiles to define 437 specific values for this parameter. If no parameters of the 438 signature algorithm are specified, 'sign_parameters' MUST be 439 encoding the CBOR simple value Null. 441 o The third element 'sign_key_parameters' indicates the parameters 442 of the key used with the signature algorithm. Its structure 443 depends on the value of 'sign_alg'. It is required of the 444 application profiles to define specific values for this parameter. 445 If no parameters of the key used with the signature algorithm are 446 specified, 'sign_key_parameters' MUST be encoding the CBOR simple 447 value Null. 449 The 'pub_key_enc' parameter MUST be present if the POST request 450 included the 'pub_key_enc' parameter with value Null. If present, 451 the 'pub_key_enc' parameter of the 2.01 (Created) response is a CBOR 452 integer, indicating the encoding of public keys used in the group. 453 The values of this field are registered in the "ACE Public Key 454 Encoding" Registry, defined in Section 11.2. It is required of the 455 application profiles to define specific values to use for this 456 parameter. 458 The CDDL notation of the 'sign_info' and 'pub_key_enc' parameters 459 formatted as in the response is given below. 461 sign_info_res = [ 462 sign_alg : int / tstr, 463 sign_parameters : any / nil, 464 sign_key_parameters : any / nil 465 ] 467 pub_key_enc_res = int 469 Note that the CBOR map specified as payload of the 2.01 (Created) 470 response may include further parameters, e.g. according to the 471 signalled transport profile of ACE. 473 Note that this step could be merged with the following message from 474 the Client to the KDC, namely Key Distribution Request. 476 3.3.1. 'sign_info' Parameter 478 The 'sign_info' parameter is an OPTIONAL parameter of the AS Request 479 Creation Hints message defined in Section 5.1.2. of 480 [I-D.ietf-ace-oauth-authz]. This parameter contains information and 481 parameters about the signature algorithm and the public keys to be 482 used between the Client and the RS. Its exact content is application 483 specific. 485 3.3.2. 'pub_key_enc' Parameter 487 The 'pub_key_enc' parameter is an OPTIONAL parameter of the AS 488 Request Creation Hints message defined in Section 5.1.2. of 489 [I-D.ietf-ace-oauth-authz]. This parameter contains information 490 about the exact encoding of public keys to be used between the Client 491 and the RS. Its exact content is application specific. 493 4. Key Distribution 495 This section defines how the keying material used for group 496 communication is distributed from the KDC to the Client, when joining 497 the group as a new member. 499 If not previously established, the Client and the KDC MUST first 500 establish a pairwise secure communication channel using ACE. The 501 exchange of Key Distribution Request-Response MUST occur over that 502 secure channel. The Client and the KDC MAY use that same secure 503 channel to protect further pairwise communications, that MUST be 504 secured. 506 During this exchange, the Client sends a request to the AS, 507 specifying the group it wishes to join (see Section 4.1). Then, the 508 KDC verifies the access token and that the Client is authorized to 509 join that group; if so, it provides the Client with the keying 510 material to securely communicate with the member of the group (see 511 Section 4.2). The Content-Format used in the messages is set to 512 application/cbor. 514 Figure 4 gives an overview of the exchange described above. 516 Client KDC 517 | | 518 |---- Key Distribution Request: POST /group-id --->| 519 | | 520 |<--- Key Distribution Response: 2.01 (Created) ---| 521 | | 523 Figure 4: Message Flow of Key Distribution to a New Group Member 525 The same set of message can also be used for the following cases, 526 when the Client is already a group member: 528 o The Client wishes to (re-)get the current keying material, for 529 cases such as expiration, loss or suspected mismatch, due to e.g. 530 reboot or missed group rekeying. This is further discussed in 531 Section 6. 533 o The Client wishes to (re-)get the public keys of other group 534 members, e.g. if it is aware of new nodes joining the group after 535 itself. This is further discussed in Section 7. 537 Additionally, the format of the payload of the Key Distribution 538 Response (Section 4.2) can be reused for messages sent by the KDC to 539 distribute updated group keying material, in case of a new node 540 joining the group or of a current member leaving the group. The key 541 management scheme used to send such messages could rely on, e.g., 542 multicast in case of a new node joining or unicast in case of a node 543 leaving the group. 545 Note that proof-of-possession to bind the access token to the Client 546 is performed by using the proof-of-possession key bound to the access 547 token for establishing secure communication between the Client and 548 the KDC. 550 If the application requires backward security, the KDC SHALL generate 551 new group keying material and securely distribute it to all the 552 current group members, using the message format defined in this 553 section. Application profiles may define alternative message 554 formats. 556 4.1. Key Distribution Request 558 The Client sends a Key Distribution Request to the KDC. This 559 corresponds to a CoAP POST request to the endpoint in the KDC 560 associated to the group to join. The endpoint in the KDC is 561 associated to the 'scope' value of the Authorization Request/ 562 Response. The payload of this request is a CBOR map which MUST 563 contain the following fields: 565 o 'type', encoded as a CBOR int, with value 1 ("key distribution"). 567 Additionally, the CBOR map in the payload MAY contain the following 568 fields, which, if included, MUST have the corresponding values: 570 o 'scope', with value the specific resource that the Client is 571 authorized to access (i.e. group or topic identifier) and role(s), 572 encoded as in Section 3.1. 574 o 'get_pub_keys', if the Client wishes to receive the public keys of 575 the other nodes in the group from the KDC. The value is an empty 576 CBOR array. This parameter may be present if the KDC stores the 577 public keys of the nodes in the group and distributes them to the 578 Client; it is useless to have here if the set of public keys of 579 the members of the group is known in another way, e.g. it was 580 provided by the AS. 582 o 'client_cred', with value the public key or certificate of the 583 Client, encoded as a CBOR byte string. If the KDC is managing 584 (collecting from/distributing to the Client) the public keys of 585 the group members, this field contains the public key of the 586 Client. The default encoding for public keys is COSE Keys. 587 Alternative specific encodings of this parameter MAY be defined in 588 applications of this specification. 590 o 'client_cred_verify', encoded as a CBOR byte string. This 591 parameter contains a signature computed by the Client over the 592 nonce N received from the KDC in the 2.01 (Created) response to 593 the token POST request (see Section 3.3). The Client computes the 594 signature by using its own private key, whose corresponding public 595 key is either directly specified in the 'client_cred' parameter or 596 included in the certificate specified in the 'client_cred' 597 parameter. This parameter MUST be present if the 'client_cred' 598 parameter is present. 600 o 'pub_keys_repos', can be present if a certificate is present in 601 the 'client_cred' field, with value a list of public key 602 repositories storing the certificate of the Client. This 603 parameter is encoded as a CBOR array of CBOR text strings, each of 604 which specifies the URI of a key repository. 606 4.2. Key Distribution Response 608 The KDC verifies that the 'scope' received in the Key Distribution 609 Request, if present, is a subset of the 'scope' stored in the access 610 token associated to this client. If verification fails, the KDC MUST 611 respond with a 4.01 (Unauthorized) error message. 613 If the Key Distribution Request is not formatted correctly (e.g. no 614 'scope' field present while expected, or unknown fields present), the 615 KDC MUST respond with 4.00 (Bad Request) error message. 617 If verification succeeds, the KDC sends a Key Distribution success 618 Response to the Client. The Key Distribution success Response 619 corresponds to a 2.01 Created message. The payload of this response 620 is a CBOR map, which MUST contain: 622 o 'kty', identifying the key type of the 'key' parameter. The set 623 of values can be found in the "Key Type" column of the "ACE 624 Groupcomm Key" Registry. Implementations MUST verify that the key 625 type matches the application profile being used, if present, as 626 registered in the "ACE Groupcomm Key" registry. 628 o 'key', containing the keying material for the group communication, 629 or information required to derive it. 631 The exact format of the 'key' value MUST be defined in applications 632 of this specification. Additionally, documents specifying the key 633 format MUST register it in the "ACE Groupcomm Key" registry, 634 including its name, type and application profile to be used with, as 635 defined in the "ACE Groupcomm Key" registry, defined in Section 11.5. 637 +----------+----------------+---------+-------------------------+ 638 | Name | Key Type Value | Profile | Description | 639 +----------+----------------+---------+-------------------------+ 640 | Reserved | 0 | | This value is reserved | 641 +----------+----------------+---------+-------------------------+ 643 Figure 5: Key Type Values 645 Optionally, the Key Distribution Response MAY contain the following 646 parameters, which, if included, MUST have the corresponding values: 648 o 'profile', with value a CBOR integer that MUST be used to uniquely 649 identify the application profile for group communication. The 650 value MUST be registered in the "ACE Groupcomm Profile" Registry. 652 o 'exp', with value the expiration time of the keying material for 653 the group communication, encoded as a CBOR unsigned integer or 654 floating-point number. This field contains a numeric value 655 representing the number of seconds from 1970-01-01T00:00:00Z UTC 656 until the specified UTC date/time, ignoring leap seconds, 657 analogous to what specified in Section 2 of [RFC7519]. 659 o 'pub_keys', may only be present if 'get_pub_keys' was present in 660 the Key Distribution Request. This parameter is a CBOR byte 661 string, which encodes the public keys of all the group members 662 paired with the respective member identifiers. The default 663 encoding for public keys is COSE Keys, so the default encoding for 664 'pub_keys' is a CBOR byte string wrapping a COSE_KeySet (see 665 [RFC8152]), which contains the public keys of all the members of 666 the group. In particular, each COSE Key in the COSE_KeySet 667 includes the identifier of the corresponding group member as value 668 of its 'kid' key parameter. Alternative specific encodings of 669 this parameter MAY be defined in applications of this 670 specification. 672 o 'group_policies', with value a CBOR map, whose entries specify how 673 the group handles specific management aspects. These include, for 674 instance, approaches to achieve synchronization of sequence 675 numbers among group members. The elements of this field are 676 registered in the "ACE Groupcomm Policy" Registry. This 677 specification defines the two elements "Sequence Number 678 Synchronization Method" and "Key Update Check Interval", which are 679 summarized in Figure 6. Application profiles that build on this 680 document MUST specify the exact content format of included map 681 entries. 683 +-----------------+-------+----------|--------------------|------------+ 684 | Name | CBOR | CBOR | Description | Reference | 685 | | label | type | | | 686 |-----------------+-------+----------|--------------------|------------| 687 | Sequence Number | TBD1 | tstr/int | Method for a re- | [[this | 688 | Synchronization | | | cipient node to | document]] | 689 | Method | | | synchronize with | | 690 | | | | sequence numbers | | 691 | | | | of a sender node. | | 692 | | | | Its value is taken | | 693 | | | | from the 'Value' | | 694 | | | | column of the | | 695 | | | | Sequence Number | | 696 | | | | Synchronization | | 697 | | | | Method registry | | 698 | | | | | | 699 | Key Update | TBD2 | int | Polling interval | [[this | 700 | Check Interval | | | in seconds, to | document]] | 701 | | | | check for new | | 702 | | | | keying material at | | 703 | | | | the KDC | | 704 +-----------------+-------+----------|--------------------|------------+ 706 Figure 6: ACE Groupcomm Policies 708 o 'mgt_key_material', encoded as a CBOR byte string and containing 709 the administrative keying material to participate in the group 710 rekeying performed by the KDC. The exact format and content 711 depend on the specific rekeying scheme used in the group, which 712 may be specified in the application profile. 714 Specific application profiles that build on this document need to 715 specify how exactly the keying material is used to protect the group 716 communication. 718 5. Removal of a Node from the Group 720 This section describes at a high level how a node can be removed from 721 the group. 723 If the application requires forward security, the KDC SHALL generate 724 new group keying material and securely distribute it to all the 725 current group members but the leaving node, using the message format 726 defined in Section 4.2. Application profiles may define alternative 727 message formats. 729 5.1. Expired Authorization 731 If the AS provides Token introspection (see Section 5.7 of 732 [I-D.ietf-ace-oauth-authz]), the KDC can optionally use and check 733 whether: 735 o the node is not authorized anymore; 737 o the access token is still valid, upon its expiration. 739 Either case, once aware that a node is not authorized anymore, the 740 KDC has to remove the unauthorized node from the list of group 741 members, if the KDC keeps track of that. 743 5.2. Request to Leave the Group 745 A node can actively request to leave the group. In this case, the 746 Client can send a request formatted as follows to the KDC, to abandon 747 the group. The client MUST use the protected channel established 748 with ACE, mentioned in Section 4. 750 To request to leave a group, the client MUST send a CoAP POST request 751 to the endpoint in the KDC associated to the group to leave (same 752 endpoint used in Section 4.1 for Key Distribution requests). The 753 payload of this Leave Request is a CBOR map which MUST contain: 755 o 'type', encoded as a CBOR int, with value 2 ("leave"). 757 o 'scope', with value the specific resource that the Client is 758 authorized to access (i.e. group or topic identifier) and wants to 759 leave, encoded as in Section 3.1. The 'role' field is omitted. 761 Note that the 'role' field is omitted since such a request should 762 only be used to leave a group altogether. If the leaving node wants 763 to be part of a group with fewer roles, it does not need to 764 communicate that to the KDC, and can simply stop acting according to 765 such roles. 767 If the Leave Request is such that the KDC cannot extract all the 768 necessary information to understand and process it correctly (e.g. no 769 'scope' field present), the KDC MUST respond with a 4.00 (Bad 770 Request) error message. Otherwise, the KDC MUST remove the leaving 771 node from the list of group members, if the KDC keeps track of that. 773 Note that, after having left the group, a node may wish to join it 774 again. Then, as long as the node is still authorized to join the 775 group, i.e. it has a still valid access token, it can re-request to 776 join the group directly to the KDC without needing to retrieve a new 777 access token from the AS. This means that the KDC needs to keep 778 track of nodes with valid access tokens, before deleting all 779 information about the leaving node. 781 6. Retrieval of New or Updated Keying Material 783 A node stops using the group keying material upon its expiration, 784 according to the 'exp' parameter specified in the retained COSE Key. 785 Then, if it wants to continue participating in the group 786 communication, the node has to request new updated keying material to 787 the KDC. In this case, and depending on what part of the keying 788 material is expired, the client may need to communicate to the KDC 789 its need for that part to be renewed: for example, if the Client uses 790 an individual key to protect outgoing traffic and has to renew it, 791 the node may request a new one, or new input material to derive it, 792 without renewing the whole group keying material. 794 The Client may perform the same request to the KDC also upon 795 receiving messages from other group members without being able to 796 retrieve the material to correctly decrypt them. This may be due to 797 a previous update of the group keying material (rekeying) triggered 798 by the KDC, that the Client was not able to receive or decrypt. 800 Note that policies can be set up so that the Client sends a request 801 to the KDC only after a given number of unsuccessfully decrypted 802 incoming messages. It is application dependent and pertaining to the 803 particular message exchange (e.g. [I-D.ietf-core-oscore-groupcomm]) 804 to set up policies that instruct clients to retain unsuccessfully 805 decrypted messages and for how long, so that they can be decrypted 806 after getting updated keying material, rather than just considered 807 non valid messages to discard right away. 809 The same request could also be sent by the client without being 810 triggered by a failed decryption of a message, if the client wants to 811 confirm that it has the latest group keying material. If that is the 812 case, the client will receive from the KDC the same group keying 813 material it has in memory. 815 Note that the difference between the keying material renewal request 816 and the keying material update request is that the first one triggers 817 the KDC to produce new keying material for that node, while the 818 second one only triggers distribution (the renewal might have 819 happened independently, because of expiration). Once a node receives 820 new individual keying material, other group members may need to use 821 the update keying material request to retrieve it. 823 Alternatively, the re-distribution of keying material can be 824 initiated by the KDC, which e.g.: 826 o Can maintain an Observable resource to send notifications to 827 Clients when the keying material is updated. Such a notification 828 would have the same payload as the Key Re-Distribution Response 829 defined in Section 6.2. 831 o Can send the payload of the Key Re-Distribution Response as one or 832 multiple multicast requests to the members of the group, using 833 secure rekeying schemes such as [RFC2093][RFC2094][RFC2627]. 835 o Can send unicast requests to each Client over a secure channel, 836 with the Key Re-Distribution Response as payload. 838 o Can act as a publisher in a pub-sub scenario, and update the 839 keying material by publishing on a specific topic on a broker, 840 which all the members of the group are subscribed to. 842 Note that these methods of KDC-initiated key re-distribution have 843 different security properties and require different security 844 associations. 846 6.1. Key Re-Distribution Request 848 To request a re-distribution of keying material, the Client sends a 849 shortened Key Distribution Request to the KDC (Section 4.1), 850 formatted as follows. The payload MUST contain the following fields: 852 o 'type', encoded as a CBOR int, with value 3 ("update key") if the 853 request is intended to retrieve updated group keying material, and 854 4 ("new") if the request is intended for the KDC to produce and 855 provide new individual keying material for the Client. 857 o 'scope', which contains only the identifier of the specific group 858 or topic, encoded as in Section 3.1. That is, the role field is 859 not present. 861 6.2. Key Re-Distribution Response 863 The KDC receiving a Key Re-Distribution Request MUST check that it is 864 storing a valid access token from that client for that scope. 866 If that is not the case, i.e. it does not store the token or the 867 token is not valid for that client for the scope requested, the KDC 868 MUST respond with a 4.01 (Unauthorized) error message. Analogously 869 to Section 4.2, if the Key Re-Distribution Request is not formatted 870 correctly (e.g. no 'scope' field present, or unknown fields present), 871 the KDC MUST respond with a 4.00 (Bad Request) error message. 873 Otherwise, the KDC replies to the Client with a Key Distribution 874 Response, which MUST include the 'kty', 'key' and 'exp' parameters 875 specified in Section 4.2. The Key Distribution Response MAY also 876 include the 'profile', 'group_policies' and 'mgt_key_material' 877 parameters specified in Section 4.2. 879 Note that this response might simply re-provide the same keying 880 material currently owned by the Client, if it has not been renewed. 882 7. Retrieval of Public Keys for Group Members 884 In case the KDC maintains the public keys of group members, a node in 885 the group can contact the KDC to request public keys of either all 886 group members or a specified subset, using the messages defined 887 below. 889 Figure 7 gives an overview of the exchange described above. 891 Client KDC 892 | | 893 |---- Public Key Request: POST /group-id --->| 894 | | 895 |<--- Public Key Response: 2.01 (Created) ---| 896 | | 898 Figure 7: Message Flow of Public Key Request-Response 900 Note that these messages can be combined with the Key Re-Distribution 901 messages in Section 6, to request at the same time the keying 902 material and the public keys. In this case, either a new endpoint at 903 the KDC may be used, or additional information needs to be sent in 904 the request payload, to distinguish these combined messages from the 905 Public Key messages described below, since they would be identical 906 otherwise. 908 7.1. Public Key Request 910 To request public keys, the Client sends a shortened Key Distribution 911 Request to the KDC (Section 4.1), formatted as follows. The payload 912 of this request MUST contain the following fields: 914 o 'type', encoded as a CBOR int, with value 5 ("pub keys"). 916 o 'get_pub_keys', which has as value a CBOR array including either: 918 * no elements, i.e. an empty array, in order to request the 919 public key of all current group members; or 921 * N elements, each of which is the identifier of a group member 922 encoded as a CBOR byte string, in order to request the public 923 key of the specified nodes. 925 o 'scope', which contains only the identifier of the specific group 926 or topic, encoded as in Section 3.1. That is, the role field is 927 not present. 929 7.2. Public Key Response 931 The KDC replies to the Client with a Key Distribution Response 932 containing only the 'pub_keys' parameter, as specified in 933 Section 4.2. The payload of this response contains the following 934 field: 936 o 'pub_keys', which contains either: 938 * the public keys of all the members of the group, if the 939 'get_pub_keys' parameter of the Public Key request was an empty 940 array; or 942 * the public keys of the group members with the identifiers 943 specified in the 'get_pub_keys' parameter of the Public Key 944 request. 946 The KDC may enforce one of the following policies, in order to handle 947 possible identifiers that are included in the 'get_pub_keys' 948 parameter of the Public Key request but are not associated to any 949 current group member. 951 o The KDC silently ignores those identifiers. 953 o The KDC retains public keys of group members for a given amount of 954 time after their leaving, before discarding them. As long as such 955 public keys are retained, the KDC provides them to a requesting 956 Client. 958 Either case, a node that has left the group should not expect any of 959 its outgoing messages to be successfully processed, if received after 960 its leaving, due to a possible group rekeying occurred before the 961 message reception. 963 8. ACE Groupcomm Parameters 965 This specification defines a number of fields used during the message 966 exchange. The table below summarizes them, and specifies the CBOR 967 key to use instead of the full descriptive name. 969 +--------------+----------+---------------+ 970 | Name | CBOR Key | CBOR Type | 971 +--------------+----------+---------------+ 972 | scope | TBD | array | 973 +--------------+----------+---------------+ 974 | get_pub_keys | TBD | array | 975 +--------------+----------+---------------+ 976 | client_cred | TBD | byte string | 977 +--------------+----------+---------------+ 978 | client_cred_ | TBD | byte string | 979 | verify | | | 980 +--------------+----------+---------------+ 981 | pub_keys_ | TBD | array | 982 | repos | | | 983 +--------------+----------+---------------+ 984 | kty | TBD | int / byte | 985 | | | string | 986 +--------------+----------+---------------+ 987 | key | TBD | see "ACE | 988 | | | Groupcomm | 989 | | | Key" Registry | 990 +--------------+----------+---------------+ 991 | profile | TBD | int | 992 +--------------+----------+---------------+ 993 | exp | TBD | int / float | 994 +--------------+----------+---------------+ 995 | pub_keys | TBD | byte string | 996 +--------------+----------+---------------+ 997 | group_ | TBD | map | 998 | policies | | | 999 +--------------+----------+---------------+ 1000 | mgt_key_ | TBD | byte string | 1001 | material | | | 1002 +--------------+----------+---------------+ 1003 | type | TBD | int | 1004 +--------------+----------+---------------+ 1006 9. ACE Groupcomm Request Type 1008 This specification defines a number of types of requests. The table 1009 below summarizes them. 1011 +------------------+----------+ 1012 | Name | Value | 1013 +------------------+----------+ 1014 | key distribution | 1 | 1015 +------------------+----------+ 1016 | leave | 2 | 1017 +------------------+----------+ 1018 | update key | 3 | 1019 +------------------+----------+ 1020 | new | 4 | 1021 +------------------+----------+ 1022 | pub keys | 5 | 1023 +------------------+----------+ 1025 10. Security Considerations 1027 When a Client receives a message from a sender for the first time, it 1028 needs to have a mechanism in place to avoid replay, e.g. 1029 Appendix B.2 of [I-D.ietf-core-object-security]. 1031 The KDC must renew the group keying material upon its expiration. 1033 The KDC should renew the keying material upon group membership 1034 change, and should provide it to the current group members through 1035 the rekeying scheme used in the group. 1037 The KDC may enforce a rekeying policy that takes into account the 1038 overall time required to rekey the group, as well as the expected 1039 rate of changes in the group membership. 1041 That is, the KDC may not rekey the group at every membership change, 1042 for instance if members' joining and leaving occur frequently and 1043 performing a group rekeying takes too long. Instead, the KDC may 1044 rekey the group after a minum number of group members have joined or 1045 left within a given time interval, or during predictable network 1046 inactivity periods. 1048 However, this would result in the KDC not constantly preserving 1049 backward and forward security. In fact, newly joining group members 1050 could be able to access the keying material used before their 1051 joining, and thus could access past group communications. Also, 1052 until the KDC performs a group rekeying, the newly leaving nodes 1053 would still be able to access upcoming group communications that are 1054 protected with the keying material that has not yet been updated. 1056 10.1. Update of Keying Material 1058 A group member can receive a message shortly after the group has been 1059 rekeyed, and new keying material has been distributed by the KDC. In 1060 the following two cases, this may result in misaligned keying 1061 material between the group members. 1063 In the first case, the sender protects a message using the old keying 1064 material. However, the recipient receives the message after having 1065 received the new keying material, hence not being able to correctly 1066 process it. A possible way to ameliorate this issue is to preserve 1067 the old, recent, keying material for a maximum amount of time defined 1068 by the application. By doing so, the recipient can still try to 1069 process the received message using the old retained keying material 1070 as second attempt. Note that a former (compromised) group member can 1071 take advantage of this by sending messages protected with the old 1072 retained keying material. Therefore, a conservative application 1073 policy should not admit the storage of old keying material. 1075 In the second case, the sender protects a message using the new 1076 keying material, but the recipient receives that request before 1077 having received the new keying material. Therefore, the recipient 1078 would not be able to correctly process the request and hence discards 1079 it. If the recipient receives the new keying material shortly after 1080 that and the sender endpoint uses CoAP retransmissions, the former 1081 will still be able to receive and correctly process the message. In 1082 any case, the recipient should actively ask the KDC for an updated 1083 keying material according to an application-defined policy, for 1084 instance after a given number of unsuccessfully decrypted incoming 1085 messages. 1087 10.2. Block-Wise Considerations 1089 If the block-wise options [RFC7959] are used, and the keying material 1090 is updated in the middle of a block-wise transfer, the sender of the 1091 blocks just changes the keying material to the updated one and 1092 continues the transfer. As long as both sides get the new keying 1093 material, updating the keying material in the middle of a transfer 1094 will not cause any issue. Otherwise, the sender will have to 1095 transmit the message again, when receiving an error message from the 1096 recipient. 1098 Compared to a scenario where the transfer does not use block-wise, 1099 depending on how fast the keying material is changed, the nodes might 1100 consume a larger amount of the network resending the blocks again and 1101 again, which might be problematic. 1103 11. IANA Considerations 1105 This document has the following actions for IANA. 1107 11.1. ACE Authorization Server Request Creation Hints Registry 1109 IANA is asked to register the following entries in the "ACE 1110 Authorization Server Request Creation Hints" Registry defined in 1111 Section 8.1 of [I-D.ietf-ace-oauth-authz]. 1113 o Name: sign_info 1115 o CBOR Key: TBD (range -256 to 255) 1117 o Value Type: any 1119 o Reference: [[This specification]] 1121 o Name: pub_key_enc 1123 o CBOR Key: TBD (range -256 to 255) 1125 o Value Type: integer 1127 o Reference: [[This specification]] 1129 11.2. ACE Public Key Encoding Registry 1131 This specification establishes the "ACE Public Key Encoding" IANA 1132 Registry. The Registry has been created to use the "Expert Review 1133 Required" registration procedure [RFC8126]. Expert review guidelines 1134 are provided in Section 11.9. It should be noted that, in addition 1135 to the expert review, some portions of the Registry require a 1136 specification, potentially a Standards Track RFC, be supplied as 1137 well. 1139 The columns of this Registry are: 1141 o Name: This is a descriptive name that enables easier reference to 1142 the item. The name MUST be unique. It is not used in the 1143 encoding. 1145 o Value: The value to be used to identify this public key encoding. 1146 This value MUST be unique. The value can be a positive or a 1147 negative integer. Integer values between 0 and 255 are designated 1148 as Standards Track Document required. Integer values from 256 to 1149 65535 are designated as Specification Required. Integer values of 1150 greater than 65535 are designated as expert review. Integer 1151 values less than -65536 are marked as private use. 1153 o Description: This field contains a brief description for this 1154 public key encoding. 1156 o Reference: This field contains a pointer to the public 1157 specification providing the public key encoding, if one exists. 1159 The value 0 is to be marked as "Reserved". 1161 11.3. ACE Groupcomm Parameters Registry 1163 This specification establishes the "ACE Groupcomm Parameters" IANA 1164 Registry. The Registry has been created to use the "Expert Review 1165 Required" registration procedure [RFC8126]. Expert review guidelines 1166 are provided in Section 11.9. 1168 The columns of this Registry are: 1170 o Name: This is a descriptive name that enables easier reference to 1171 the item. The name MUST be unique. It is not used in the 1172 encoding. 1174 o CBOR Key: This is the value used as CBOR key of the item. These 1175 values MUST be unique. The value can be a positive integer, a 1176 negative integer, or a string. 1178 o CBOR Type: This contains the CBOR type of the item, or a pointer 1179 to the registry that defines its type, when that depends on 1180 another item. 1182 o Reference: This contains a pointer to the public specification for 1183 the format of the item, if one exists. 1185 This Registry has been initially populated by the values in 1186 Section 8. The specification column for all of these entries will be 1187 this document. 1189 11.4. Ace Groupcomm Request Type Registry 1191 This specification establishes the "ACE Groupcomm Request Type" IANA 1192 Registry. The Registry has been created to use the "Expert Review 1193 Required" registration procedure [RFC8126]. Expert review guidelines 1194 are provided in Section 11.9. 1196 The columns of this Registry are: 1198 o Name: This is a descriptive name that enables easier reference to 1199 the item. The name MUST be unique. It is not used in the 1200 encoding. 1202 o Value: This is the value used to identify the request. These 1203 values MUST be unique. The value must be a positive integer. 1205 o Reference: This contains a pointer to the public specification for 1206 the format of the item, if one exists. 1208 This Registry has been initially populated by the values in 1209 Section 9. The reference column for all of these entries will be 1210 this document. The value 0 is to be marked as "Reserved". 1212 11.5. ACE Groupcomm Key Registry 1214 This specification establishes the "ACE Groupcomm Key" IANA Registry. 1215 The Registry has been created to use the "Expert Review Required" 1216 registration procedure [RFC8126]. Expert review guidelines are 1217 provided in Section 11.9. 1219 The columns of this Registry are: 1221 o Name: This is a descriptive name that enables easier reference to 1222 the item. The name MUST be unique. It is not used in the 1223 encoding. 1225 o Key Type Value: This is the value used to identify the keying 1226 material. These values MUST be unique. The value can be a 1227 positive integer, a negative integer, or a string. 1229 o Profile: This field may contain one or more descriptive strings of 1230 application profiles to be used with this item. The values should 1231 be taken from the Name column of the "ACE Groupcomm Profile" 1232 Registry. 1234 o Description: This field contains a brief description of the keying 1235 material. 1237 o References: This contains a pointer to the public specification 1238 for the format of the keying material, if one exists. 1240 This Registry has been initially populated by the values in Figure 5. 1241 The specification column for all of these entries will be this 1242 document. 1244 11.6. ACE Groupcomm Profile Registry 1246 This specification establishes the "ACE Groupcomm Profile" IANA 1247 Registry. The Registry has been created to use the "Expert Review 1248 Required" registration procedure [RFC8126]. Expert review guidelines 1249 are provided in Section 11.9. It should be noted that, in addition 1250 to the expert review, some portions of the Registry require a 1251 specification, potentially a Standards Track RFC, be supplied as 1252 well. 1254 The columns of this Registry are: 1256 o Name: The name of the application profile, to be used as value of 1257 the profile attribute. 1259 o Description: Text giving an overview of the application profile 1260 and the context it is developed for. 1262 o CBOR Value: CBOR abbreviation for the name of this application 1263 profile. Different ranges of values use different registration 1264 policies [RFC8126]. Integer values from -256 to 255 are 1265 designated as Standards Action. Integer values from -65536 to 1266 -257 and from 256 to 65535 are designated as Specification 1267 Required. Integer values greater than 65535 are designated as 1268 Expert Review. Integer values less than -65536 are marked as 1269 Private Use. 1271 o Reference: This contains a pointer to the public specification of 1272 the abbreviation for this application profile, if one exists. 1274 11.7. ACE Groupcomm Policy Registry 1276 This specification establishes the "ACE Groupcomm Policy" IANA 1277 Registry. The Registry has been created to use the "Expert Review 1278 Required" registration procedure [RFC8126]. Expert review guidelines 1279 are provided in Section 11.9. It should be noted that, in addition 1280 to the expert review, some portions of the Registry require a 1281 specification, potentially a Standards Track RFC, be supplied as 1282 well. 1284 The columns of this Registry are: 1286 o Name: The name of the group communication policy. 1288 o CBOR label: The value to be used to identify this group 1289 communication policy. Key map labels MUST be unique. The label 1290 can be a positive integer, a negative integer or a string. 1291 Integer values between 0 and 255 and strings of length 1 are 1292 designated as Standards Track Document required. Integer values 1293 from 256 to 65535 and strings of length 2 are designated as 1294 Specification Required. Integer values of greater than 65535 and 1295 strings of length greater than 2 are designated as expert review. 1296 Integer values less than -65536 are marked as private use. 1298 o CBOR type: the CBOR type used to encode the value of this group 1299 communication policy. 1301 o Description: This field contains a brief description for this 1302 group communication policy. 1304 o Reference: This field contains a pointer to the public 1305 specification providing the format of the group communication 1306 policy, if one exists. 1308 This registry will be initially populated by the values in Figure 6. 1310 11.8. Sequence Number Synchronization Method Registry 1312 This specification establishes the "Sequence Number Synchronization 1313 Method" IANA Registry. The Registry has been created to use the 1314 "Expert Review Required" registration procedure [RFC8126]. Expert 1315 review guidelines are provided in Section 11.9. It should be noted 1316 that, in addition to the expert review, some portions of the Registry 1317 require a specification, potentially a Standards Track RFC, be 1318 supplied as well. 1320 The columns of this Registry are: 1322 o Name: The name of the sequence number synchronization method. 1324 o Value: The value to be used to identify this sequence number 1325 synchronization method. 1327 o Description: This field contains a brief description for this 1328 sequence number synchronization method. 1330 o Reference: This field contains a pointer to the public 1331 specification describing the sequence number synchronization 1332 method. 1334 11.9. Expert Review Instructions 1336 The IANA Registries established in this document are defined as 1337 expert review. This section gives some general guidelines for what 1338 the experts should be looking for, but they are being designated as 1339 experts for a reason so they should be given substantial latitude. 1341 Expert reviewers should take into consideration the following points: 1343 o Point squatting should be discouraged. Reviewers are encouraged 1344 to get sufficient information for registration requests to ensure 1345 that the usage is not going to duplicate one that is already 1346 registered and that the point is likely to be used in deployments. 1347 The zones tagged as private use are intended for testing purposes 1348 and closed environments, code points in other ranges should not be 1349 assigned for testing. 1351 o Specifications are required for the standards track range of point 1352 assignment. Specifications should exist for specification 1353 required ranges, but early assignment before a specification is 1354 available is considered to be permissible. Specifications are 1355 needed for the first-come, first-serve range if they are expected 1356 to be used outside of closed environments in an interoperable way. 1357 When specifications are not provided, the description provided 1358 needs to have sufficient information to identify what the point is 1359 being used for. 1361 o Experts should take into account the expected usage of fields when 1362 approving point assignment. The fact that there is a range for 1363 standards track documents does not mean that a standards track 1364 document cannot have points assigned outside of that range. The 1365 length of the encoded value should be weighed against how many 1366 code points of that length are left, the size of device it will be 1367 used on, and the number of code points left that encode to that 1368 size. 1370 12. References 1372 12.1. Normative References 1374 [I-D.ietf-ace-oauth-authz] 1375 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1376 H. Tschofenig, "Authentication and Authorization for 1377 Constrained Environments (ACE) using the OAuth 2.0 1378 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 1379 (work in progress), March 2019. 1381 [I-D.ietf-ace-oauth-params] 1382 Seitz, L., "Additional OAuth Parameters for Authorization 1383 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 1384 params-05 (work in progress), March 2019. 1386 [I-D.ietf-core-oscore-groupcomm] 1387 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1388 "Group OSCORE - Secure Group Communication for CoAP", 1389 draft-ietf-core-oscore-groupcomm-05 (work in progress), 1390 July 2019. 1392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1393 Requirement Levels", BCP 14, RFC 2119, 1394 DOI 10.17487/RFC2119, March 1997, 1395 . 1397 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1398 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1399 October 2013, . 1401 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1402 Writing an IANA Considerations Section in RFCs", BCP 26, 1403 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1404 . 1406 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1407 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1408 . 1410 12.2. Informative References 1412 [I-D.dijk-core-groupcomm-bis] 1413 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1414 for the Constrained Application Protocol (CoAP)", draft- 1415 dijk-core-groupcomm-bis-00 (work in progress), March 2019. 1417 [I-D.ietf-ace-dtls-authorize] 1418 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1419 L. Seitz, "Datagram Transport Layer Security (DTLS) 1420 Profile for Authentication and Authorization for 1421 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1422 authorize-08 (work in progress), April 2019. 1424 [I-D.ietf-ace-mqtt-tls-profile] 1425 Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile 1426 of ACE", draft-ietf-ace-mqtt-tls-profile-00 (work in 1427 progress), May 2019. 1429 [I-D.ietf-ace-oscore-profile] 1430 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1431 "OSCORE profile of the Authentication and Authorization 1432 for Constrained Environments Framework", draft-ietf-ace- 1433 oscore-profile-07 (work in progress), February 2019. 1435 [I-D.ietf-core-coap-pubsub] 1436 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1437 Subscribe Broker for the Constrained Application Protocol 1438 (CoAP)", draft-ietf-core-coap-pubsub-08 (work in 1439 progress), March 2019. 1441 [I-D.ietf-core-object-security] 1442 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1443 "Object Security for Constrained RESTful Environments 1444 (OSCORE)", draft-ietf-core-object-security-16 (work in 1445 progress), March 2019. 1447 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 1448 Protocol (GKMP) Specification", RFC 2093, 1449 DOI 10.17487/RFC2093, July 1997, 1450 . 1452 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 1453 Protocol (GKMP) Architecture", RFC 2094, 1454 DOI 10.17487/RFC2094, July 1997, 1455 . 1457 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 1458 Multicast: Issues and Architectures", RFC 2627, 1459 DOI 10.17487/RFC2627, June 1999, 1460 . 1462 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 1463 the Constrained Application Protocol (CoAP)", RFC 7390, 1464 DOI 10.17487/RFC7390, October 2014, 1465 . 1467 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1468 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1469 . 1471 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1472 the Constrained Application Protocol (CoAP)", RFC 7959, 1473 DOI 10.17487/RFC7959, August 2016, 1474 . 1476 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1477 Interchange Format", STD 90, RFC 8259, 1478 DOI 10.17487/RFC8259, December 2017, 1479 . 1481 Appendix A. Requirements on Application Profiles 1483 This section lists the requirements on application profiles of this 1484 specification,for the convenience of application profile designers. 1486 o Specify the communication protocol the members of the group must 1487 use (e.g., multicast CoAP). 1489 o Specify the security protocol the group members must use to 1490 protect their communication (e.g., group OSCORE). This must 1491 provide encryption, integrity and replay protection. 1493 o Specify the encoding and value of the identifier of group or topic 1494 and role of 'scope' (see Section 3.1). 1496 o Specify and register the application profile identifier (see 1497 Section 4.1). 1499 o Specify the acceptable values of 'kty' (see Section 4.2). 1501 o Specify the format and content of 'group_policies' entries (see 1502 Section 4.2). 1504 o Optionally, specify the format and content of 'mgt_key_material' 1505 (see Section 4.2). 1507 o Optionally, specify tranport profile of ACE 1508 [I-D.ietf-ace-oauth-authz] to use between Client and KDC. 1510 o Optionally, specify the encoding of public keys, of 'client_cred', 1511 and of 'pub_keys' if COSE_Keys are not used (see Section 4.2). 1513 o Optionally, specify the acceptable values for parameters related 1514 to signature algorithm and signature keys: 'sign_alg', 1515 'sign_parameters', 'sign_key_parameters', 'pub_key_enc' (see 1516 Section 3.3). 1518 o Optionally, specify the negotiation of parameter values for 1519 signature algorithm and signature keys, if 'sign_info' and 1520 'pub_key_enc' are not used (see Section 3.3). 1522 Appendix B. Document Updates 1524 RFC EDITOR: PLEASE REMOVE THIS SECTION. 1526 B.1. Version -01 to -02 1528 o Editorial fixes. 1530 o Distinction between transport profile and application profile 1531 (Section 1.1). 1533 o New parameters 'sign_info' and 'pub_key_enc' to negotiate 1534 parameter values for signature algorithm and signature keys 1535 (Section 3.3). 1537 o New parameter 'type' to distinguish different Key Distribution 1538 Request messages (Section 4.1). 1540 o New parameter 'client_cred_verify' in the Key Distribution Request 1541 to convey a Client signature (Section 4.1). 1543 o Encoding of 'pub_keys_repos' (Section 4.1). 1545 o Encoding of 'mgt_key_material' (Section 4.1). 1547 o Improved description on retrieval of new or updated keying 1548 material (Section 6). 1550 o Encoding of 'get_pub_keys' in Public Key Request (Section 7.1). 1552 o Extended security considerations (Sections 10.1 and 10.2). 1554 o New "ACE Public Key Encoding" IANA Registry (Section 11.2). 1556 o New "ACE Groupcomm Parameters" IANA Registry (Section 11.3), 1557 populated with the entries in Section 8. 1559 o New "Ace Groupcomm Request Type" IANA Registry (Section 11.4), 1560 populated with the values in Section 9. 1562 o New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated 1563 with two entries "Sequence Number Synchronization Method" and "Key 1564 Update Check Interval" (Section 4.2). 1566 o Improved list of requirements for application profiles 1567 (Appendix A). 1569 B.2. Version -00 to -01 1571 o Changed name of 'req_aud' to 'audience' in the Authorization 1572 Request (Section 3.1). 1574 o Defined error handling on the KDC (Sections 4.2 and 6.2). 1576 o Updated format of the Key Distribution Response as a whole 1577 (Section 4.2). 1579 o Generalized format of 'pub_keys' in the Key Distribution Response 1580 (Section 4.2). 1582 o Defined format for the message to request leaving the group 1583 (Section 5.2). 1585 o Renewal of individual keying material and methods for group 1586 rekeying initiated by the KDC (Section 6). 1588 o CBOR type for node identifiers in 'get_pub_keys' (Section 7.1). 1590 o Added section on parameter identifiers and their CBOR keys 1591 (Section 8). 1593 o Added request types for requests to a Join Response (Section 9). 1595 o Extended security considerations (Section 10). 1597 o New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm 1598 Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence 1599 Number Synchronization Method Registry" (Section 11). 1601 o Added appendix about requirements for application profiles of ACE 1602 on group communication (Appendix A). 1604 Acknowledgments 1606 The following individuals were helpful in shaping this document: Ben 1607 Kaduk, John Mattsson, Jim Schaad, Ludwig Seitz, Goeran Selander and 1608 Peter van der Stok. 1610 The work on this document has been partly supported by VINNOVA and 1611 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 1612 Initiative ACTIVE. 1614 Authors' Addresses 1615 Francesca Palombini 1616 Ericsson AB 1617 Torshamnsgatan 23 1618 Kista SE-16440 Stockholm 1619 Sweden 1621 Email: francesca.palombini@ericsson.com 1623 Marco Tiloca 1624 RISE AB 1625 Isafjordsgatan 22 1626 Kista SE-16440 Stockholm 1627 Sweden 1629 Email: marco.tiloca@ri.se