idnits 2.17.1 draft-ietf-core-oscore-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 (June 28, 2018) is 2126 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 (-16) exists of draft-ietf-core-object-security-13 ** Downref: Normative reference to an Informational RFC: RFC 8032 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-03 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-12 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-01 == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-01 == Outdated reference: A later version (-02) exists of draft-palombini-ace-key-groupcomm-01 == Outdated reference: A later version (-05) exists of draft-tiloca-ace-oscoap-joining-03 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group M. Tiloca 3 Internet-Draft RISE SICS 4 Intended status: Standards Track G. Selander 5 Expires: December 30, 2018 F. Palombini 6 Ericsson AB 7 J. Park 8 Universitaet Duisburg-Essen 9 June 28, 2018 11 Secure group communication for CoAP 12 draft-ietf-core-oscore-groupcomm-02 14 Abstract 16 This document describes a mode for protecting group communication 17 over the Constrained Application Protocol (CoAP). The proposed mode 18 relies on Object Security for Constrained RESTful Environments 19 (OSCORE) and the CBOR Object Signing and Encryption (COSE) format. 20 In particular, it is defined how OSCORE should be used in a group 21 communication setting, while fulfilling the same security 22 requirements for request messages and related response messages. 23 Source authentication of all messages exchanged within the group is 24 ensured, by means of digital signatures produced through private keys 25 of sender endpoints and embedded in the protected CoAP messages. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 30, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. OSCORE Security Context . . . . . . . . . . . . . . . . . . . 5 64 2.1. Management of Group Keying Material . . . . . . . . . . . 7 65 3. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1. Example: Request . . . . . . . . . . . . . . . . . . . . 9 67 3.2. Example: Response . . . . . . . . . . . . . . . . . . . . 10 68 4. Message Processing . . . . . . . . . . . . . . . . . . . . . 10 69 4.1. Protecting the Request . . . . . . . . . . . . . . . . . 10 70 4.2. Verifying the Request . . . . . . . . . . . . . . . . . . 11 71 4.3. Protecting the Response . . . . . . . . . . . . . . . . . 11 72 4.4. Verifying the Response . . . . . . . . . . . . . . . . . 11 73 5. Synchronization of Sequence Numbers . . . . . . . . . . . . . 12 74 6. Responsibilities of the Group Manager . . . . . . . . . . . . 12 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 7.1. Group-level Security . . . . . . . . . . . . . . . . . . 14 77 7.2. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 14 78 7.3. Collision of Group Identifiers . . . . . . . . . . . . . 14 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 10.2. Informative References . . . . . . . . . . . . . . . . . 16 84 Appendix A. Assumptions and Security Objectives . . . . . . . . 18 85 A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 18 86 A.2. Security Objectives . . . . . . . . . . . . . . . . . . . 20 87 Appendix B. List of Use Cases . . . . . . . . . . . . . . . . . 21 88 Appendix C. Example of Group Identifier Format . . . . . . . . . 23 89 Appendix D. Set-up of New Endpoints . . . . . . . . . . . . . . 24 90 D.1. Join Process . . . . . . . . . . . . . . . . . . . . . . 24 91 D.2. Provisioning and Retrieval of Public Keys . . . . . . . . 27 92 D.3. Group Joining Based on the ACE Framework . . . . . . . . 29 93 Appendix E. Examples of Synchronization Approaches . . . . . . . 29 94 E.1. Best-Effort Synchronization . . . . . . . . . . . . . . . 29 95 E.2. Baseline Synchronization . . . . . . . . . . . . . . . . 30 96 E.3. Challenge-Response Synchronization . . . . . . . . . . . 30 98 Appendix F. No Verification of Signatures . . . . . . . . . . . 32 99 Appendix G. Document Updates . . . . . . . . . . . . . . . . . . 32 100 G.1. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 32 101 G.2. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 33 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 104 1. Introduction 106 The Constrained Application Protocol (CoAP) [RFC7252] is a web 107 transfer protocol specifically designed for constrained devices and 108 networks [RFC7228]. 110 Group communication for CoAP [RFC7390] addresses use cases where 111 deployed devices benefit from a group communication model, for 112 example to reduce latencies and improve performance. Use cases 113 include lighting control, integrated building control, software and 114 firmware updates, parameter and configuration updates, commissioning 115 of constrained networks, and emergency multicast (see Appendix B). 116 Furthermore, [RFC7390] recognizes the importance to introduce a 117 secure mode for CoAP group communication. This specification defines 118 such a mode. 120 Object Security for Constrained RESTful Environments 121 (OSCORE)[I-D.ietf-core-object-security] describes a security protocol 122 based on the exchange of protected CoAP messages. OSCORE builds on 123 CBOR Object Signing and Encryption (COSE) [RFC8152] and provides end- 124 to-end encryption, integrity, and replay protection between a sending 125 endpoint and a receiving endpoint possibly involving intermediary 126 endpoints. To this end, a CoAP message is protected by including its 127 payload (if any), certain options, and header fields in a COSE 128 object, which finally replaces the authenticated and encrypted fields 129 in the protected message. 131 This document describes group OSCORE, providing end-to-end security 132 of CoAP messages exchanged between members of a group. In 133 particular, the described approach defines how OSCORE should be used 134 in a group communication setting, so that end-to-end security is 135 assured by using the same security method. That is, end-to-end 136 security is assured for (multicast) CoAP requests sent by client 137 endpoints to the group and for related CoAP responses sent as reply 138 by multiple server endpoints. Group OSCORE provides source 139 authentication of all CoAP messages exchanged within the group, by 140 means of digital signatures produced through private keys of sender 141 devices and embedded in the protected CoAP messages. As in OSCORE, 142 it is still possible to simultaneously rely on DTLS to protect hop- 143 by-hop communication between a sender endpoint and a proxy (and vice 144 versa), and between a proxy and a recipient endpoint (and vice 145 versa). 147 1.1. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 Readers are expected to be familiar with the terms and concepts 156 described in CoAP [RFC7252] including "endpoint", "client", "server", 157 "sender" and "recipient"; group communication for CoAP [RFC7390]; 158 COSE and counter signatures [RFC8152]. 160 Readers are also expected to be familiar with the terms and concepts 161 for protection and processing of CoAP messages through OSCORE, such 162 as "Security Context" and "Master Secret", defined in 163 [I-D.ietf-core-object-security]. 165 Terminology for constrained environments, such as "constrained 166 device", "constrained-node network", is defined in [RFC7228]. 168 This document refers also to the following terminology. 170 o Keying material: data that is necessary to establish and maintain 171 secure communication among endpoints. This includes, for 172 instance, keys and IVs [RFC4949]. 174 o Group: a set of endpoints that share group keying material and 175 parameters (Common Context of the group's Security Context, see 176 Section 2). That is, the term group used in this specification 177 refers to a "security group", not to be confused with network/ 178 multicast groups or application groups. 180 o Group Manager (GM): entity responsible for a set of OSCORE groups. 181 Each endpoint in a group securely communicates with the respective 182 GM, which is not required to be an actual group member and to take 183 part in the group communication. The full list of 184 responsibilities of the Group Manager is provided in Section 6. 186 o Silent server: member of a group that never replies back after 187 receiving request messages. 189 o Group ID: group identifier assigned to the group. Group IDs are 190 unique within the set of groups of a same Group Manager. 192 o Endpoint ID: Sender ID of the endpoint, as defined in 193 [I-D.ietf-core-object-security]. An Endpoint ID is provided to an 194 endpoint upon joining a group, is valid only within that group, 195 and is unique within the same group. Endpoints which are 196 configured only as silent servers do not have an Endpoint ID. 198 o Group request: CoAP request message sent by a client endpoint in 199 the group to all server endpoints in that group. 201 o Source authentication: evidence that a received message in the 202 group originated from a specifically identified group member. 203 This also provides assurances that the message was not tampered 204 with by a different group member or by a non-group member. 206 2. OSCORE Security Context 208 To support group communication secured with OSCORE, each endpoint 209 registered as member of a group maintains a Security Context as 210 defined in Section 3 of [I-D.ietf-core-object-security]. Each 211 endpoint in a group stores: 213 1. one Common Context, shared by all the endpoints in the group. In 214 particular: 216 * All the endpoints in the group agree on the same COSE AEAD 217 algorithm. 219 * The ID Context parameter stores the Group ID of the group, 220 which is used to retrieve the Security Context for processing 221 messages intended to the group's endpoints (see Section 4). 222 The choice of the Group ID for a given group's Security 223 Context is application specific. An example of specific 224 formatting of the Group ID that would follow this 225 specification is given in Appendix C. It is the role of the 226 application to specify how to handle possible collisions. 228 * A new parameter Counter Signature Algorithm is included, and 229 its value identifies the algorithm used for source 230 authenticating messages sent within the group, by means of a 231 counter signature (see Section 4.5 of [RFC8152]). Its value 232 is immutable once the Common Context is established. All the 233 endpoints in the group agree on the same counter signature 234 algorithm. The list of supported signature algorithms is part 235 of the group communication policy and MUST include the EdDSA 236 signature algorithm ed25519 [RFC8032]. 238 2. one Sender Context, unless the endpoint is configured exclusively 239 as silent server. The Sender Context is used to secure outgoing 240 group messages and is initialized according to Section 3 of 241 [I-D.ietf-core-object-security], once the endpoint has joined the 242 group. In practice, the symmetric keying material in the Sender 243 Context of the sender endpoint is shared with all the recipient 244 endpoints that have received group messages from that same sender 245 endpoint. Besides, in addition to what is defined in 246 [I-D.ietf-core-object-security], the Sender Context stores also 247 the endpoint's public-private key pair. 249 3. one Recipient Context for each distinct endpoint from which group 250 messages are received, used to process such incoming messages. 251 The recipient endpoint creates a new Recipient Context upon 252 receiving an incoming message from another endpoint in the group 253 for the first time (see Section 4.2 and Section 4.4). In 254 practice, the symmetric keying material in a given Recipient 255 Context of the recipient endpoint is shared with the associated 256 sender endpoint from which group messages are received. Besides, 257 in addition to what is defined in 258 [I-D.ietf-core-object-security], each Recipient Context stores 259 also the public key of the associated other endpoint from which 260 group messages are received. 262 The table in Figure 1 overviews the new information included in the 263 OSCORE Security Context, with respect to what defined in Section 3 of 264 [I-D.ietf-core-object-security]. 266 +---------------------------+-----------------------------+ 267 | Context portion | New information | 268 +---------------------------+-----------------------------+ 269 | | | 270 | Common Context | Counter signature algorithm | 271 | | | 272 | Sender Context | Endpoint's own private key | 273 | | | 274 | Sender Context | Endpoint's own public key | 275 | | | 276 | Each Recipient Context | Public key of the | 277 | | associated other endpoint | 278 | | | 279 +---------------------------+-----------------------------+ 281 Figure 1: Additions to the OSCORE Security Context 283 Upon receiving a secure CoAP message, a recipient endpoint relies on 284 the sender endpoint's public key, in order to verify the counter 285 signature conveyed in the COSE Object. 287 If not already stored in the Recipient Context associated to the 288 sender endpoint, the recipient endpoint retrieves the public key from 289 a trusted key repository. In such a case, the correct binding 290 between the sender endpoint and the retrieved public key must be 291 assured, for instance by means of public key certificates. Further 292 discussion about how public keys can be handled and retrieved in the 293 group is provided in Appendix D.2. 295 The Sender Key/IV stored in the Sender Context and the Recipient 296 Keys/IVs stored in the Recipient Contexts are derived according to 297 the same scheme defined in Section 3.2 of 298 [I-D.ietf-core-object-security]. 300 2.1. Management of Group Keying Material 302 The approach described in this specification should take into account 303 the risk of compromise of group members. In particular, the adoption 304 of key management schemes for secure revocation and renewal of 305 Security Contexts and group keying material should be considered. 307 Consistently with the security assumptions in Appendix A.1, it is 308 RECOMMENDED to adopt a group key management scheme, and securely 309 distribute a new value for the Master Secret parameter of the group's 310 Security Context, before a new joining endpoint is added to the group 311 or after a currently present endpoint leaves the group. This is 312 necessary in order to preserve backward security and forward security 313 in the group. 315 In particular, a new Group Identifier (Gid) for that group and a new 316 value for the Master Secret parameter must also be distributed. An 317 example of Group Identifier format supporting this operation is 318 provided in Appendix C. Then, each group member re-derives the 319 keying material stored in its own Sender Context and Recipient 320 Contexts as described in Section 2, using the updated Group 321 Identifier. 323 Especially in dynamic, large-scale, groups where endpoints can join 324 and leave at any time, it is important that the considered group key 325 management scheme is efficient and highly scalable with the group 326 size, in order to limit the impact on performance due to the Security 327 Context and keying material update. 329 3. The COSE Object 331 When creating a protected CoAP message, an endpoint in the group 332 computes the COSE object using the untagged COSE_Encrypt0 structure 333 [RFC8152] as defined in Section 5 of [I-D.ietf-core-object-security], 334 with the following modifications. 336 o The value of the 'kid' parameter in the 'unprotected' field of 337 response messagess SHALL be set to the Endpoint ID of the endpoint 338 transmitting the message, i.e. the Sender ID. 340 o The 'unprotected' field SHALL additionally include the following 341 parameter: 343 * CounterSignature0 : its value is set to the counter signature 344 of the COSE object, computed by the endpoint by means of its 345 own private key as described in Section 4.5 of [RFC8152]. The 346 presence of this parameter is explicitly signaled, by using the 347 reserved sixth least significant bit of the first byte of flag 348 bits in the value of the OSCORE Option (see Section 6.1 of 349 [I-D.ietf-core-object-security]). 351 o The Additional Authenticated Data (AAD) considered to compute the 352 COSE object is extended with the counter signature algorithm used 353 to protect group messages. In particular, with reference to 354 Section 5.4 of [I-D.ietf-core-object-security], the 'algorithms' 355 array in the external_aad SHALL also include 'alg_countersign', 356 which contains the Counter Signature Algorithm from the Common 357 Context (see Section 2). 359 external_aad = [ 360 ... 361 algorithms : [alg_aead : int / tstr , alg_countersign : int / tstr], 362 ... 363 ] 365 o The OSCORE compression defined in Section 6 of 366 [I-D.ietf-core-object-security] is used, with the following 367 additions for the encoding of the OSCORE Option. 369 * The fourth least significant bit of the first byte of flag bits 370 SHALL be set to 1, to indicate the presence of the 'kid' 371 parameter for both group requests and responses. 373 * The fifth least significant bit of the first byte of flag bits 374 MUST be set to 1 for group requests, to indicate the presence 375 of the 'kid context' parameter in the OSCORE payload. The kid 376 context flag MAY be set to 1 for responses. 378 * The sixth least significant bit of the first byte of flag bits 379 is originally marked as reserved in 380 [I-D.ietf-core-object-security] and its usage is defined in 381 this specification. This bit is set to 1 if the 382 'CounterSignature0' parameter is present, or to 0 otherwise. 383 In order to ensure source authentication of group messages as 384 described in this specification, this bit SHALL be set to 1. 386 * The 'kid context' value encodes the Group Identifier value 387 (Gid) of the group's Security Context. 389 * The following q bytes (q given by the Counter Signature 390 Algorithm specified in the Security Context) encode the value 391 of the 'CounterSignature0' parameter including the counter 392 signature of the COSE object. 394 * The remaining bytes in the OSCORE Option value encode the value 395 of the 'kid' parameter, which is always present both in group 396 requests and in responses. 398 0 1 2 3 4 5 6 7 <----------- n bytes -----------> <-- 1 byte --> 399 +-+-+-+-+-+-+-+-+---------------------------------+--------------+ 400 |0 0|1|h|1| n | Partial IV (if any) | s (if any) | 401 +-+-+-+-+-+-+-+-+---------------------------------+--------------+ 403 <------ s bytes ------> <--------- q bytes ---------> 404 -----------------------+-----------------------------+-----------+ 405 kid context = Gid | CounterSignature0 | kid | 406 -----------------------+-----------------------------+-----------+ 408 Figure 2: OSCORE Option Value 410 3.1. Example: Request 412 Request with kid = 0x25, Partial IV = 5 and kid context = 0x44616c, 413 assuming the label for the new kid context defined in 414 [I-D.ietf-core-object-security] has value 10. COUNTERSIGN is the 415 CounterSignature0 byte string as described in Section 3 and is 64 416 bytes long in this example. The ciphertext in this example is 14 417 bytes long. 419 Before compression (96 bytes): 421 [ 422 h'', 423 { 4:h'25', 6:h'05', 10:h'44616c', 9:COUNTERSIGN }, 424 h'aea0155667924dff8a24e4cb35b9' 425 ] 427 After compression (85 bytes): 429 Flag byte: 0b00111001 = 0x39 431 Option Value: 39 05 03 44 61 6c COUNTERSIGN 25 (7 bytes + size of 432 COUNTERSIGN) 434 Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes) 436 3.2. Example: Response 438 Response with kid = 0x52. COUNTERSIGN is the CounterSignature0 byte 439 string as described in Section 3 and is 64 bytes long in this 440 example. The ciphertext in this example is 14 bytes long. 442 Before compression (88 bytes): 444 [ 445 h'', 446 { 4:h'52', 9:COUNTERSIGN }, 447 h'60b035059d9ef5667c5a0710823b' 448 ] 450 After compression (80 bytes): 452 Flag byte: 0b00101000 = 0x28 454 Option Value: 28 COUNTERSIGN 52 (2 bytes + size of COUNTERSIGN) 456 Payload: 60 b0 35 05 9d 9e f5 66 7c 5a 07 10 82 3b (14 bytes) 458 4. Message Processing 460 Each request message and response message is protected and processed 461 as specified in [I-D.ietf-core-object-security], with the 462 modifications described in the following sections. The following 463 security objectives are fulfilled, as further discussed in 464 Appendix A.2: data replay protection, group-level data 465 confidentiality, source authentication, message integrity, and 466 message ordering. 468 Furthermore, endpoints in the group locally perform error handling 469 and processing of invalid messages according to the same principles 470 adopted in [I-D.ietf-core-object-security]. However, a receiver 471 endpoint MUST stop processing and silently reject any message which 472 is malformed and does not follow the format specified in Section 3, 473 without sending back any error message. This prevents servers from 474 replying with multiple error messages to a client sending a group 475 request, so avoiding the risk of flooding and possibly congesting the 476 group. 478 4.1. Protecting the Request 480 A client transmits a secure group request as described in Section 8.1 481 of [I-D.ietf-core-object-security], with the following modifications. 483 o In step 2, the 'algorithms' array in the Additional Authenticated 484 Data is modified as described in Section 3. 486 o In step 4, the encoding of the compressed COSE object is modified 487 as described in Section 3. 489 4.2. Verifying the Request 491 Upon receiving a secure group request, a server proceeds as described 492 in Section 8.2 of [I-D.ietf-core-object-security], with the following 493 modifications. 495 o In step 2, the decoding of the compressed COSE object is modified 496 as described in Section 3. If the received Recipient ID ('kid') 497 does not match with any Recipient Context for the retrieved Group 498 ID ('kid context'), then the server creates a new Recipient 499 Context, initializes it according to Section 3 of 500 [I-D.ietf-core-object-security], and includes the client's public 501 key. 503 o In step 4, the 'algorithms' array in the Additional Authenticated 504 Data is modified as described in Section 3. 506 o In step 6, the server also verifies the counter signature using 507 the public key of the client from the associated Recipient 508 Context. 510 4.3. Protecting the Response 512 A server that has received a secure group request may reply with a 513 secure response, which is protected as described in Section 8.3 of 514 [I-D.ietf-core-object-security], with the following modifications. 516 o In step 2, the 'algorithms' array in the Additional Authenticated 517 Data is modified as described in Section 3. 519 o In step 4, the encoding of the compressed COSE object is modified 520 as described in Section 3. 522 4.4. Verifying the Response 524 Upon receiving a secure response message, the client proceeds as 525 described in Section 8.4 of [I-D.ietf-core-object-security], with the 526 following modifications. 528 o In step 2, the decoding of the compressed COSE object is modified 529 as described in Section 3. If the received Recipient ID ('kid') 530 does not match with any Recipient Context for the retrieved Group 531 ID ('kid context'), then the client creates a new Recipient 532 Context, initializes it according to Section 3 of 533 [I-D.ietf-core-object-security], and includes the server's public 534 key. 536 o In step 3, the 'algorithms' array in the Additional Authenticated 537 Data is modified as described in Section 3. 539 o In step 5, the client also verifies the counter signature using 540 the public key of the server from the associated Recipient 541 Context. 543 5. Synchronization of Sequence Numbers 545 Upon joining the group, new servers are not aware of the sequence 546 number values currently used by different clients to transmit group 547 requests. This means that, when such servers receive a secure group 548 request from a given client for the first time, they are not able to 549 verify if that request is fresh and has not been replayed. The same 550 holds when a server loses synchronization with sequence numbers of 551 clients, for instance after a device reboot. 553 The exact way to address this issue depends on the specific use case 554 and its synchronization requirements. The list of methods to handle 555 synchronization of sequence numbers is part of the group 556 communication policy, and different servers can use different 557 methods. Appendix E describes three possible approaches that can be 558 considered. 560 6. Responsibilities of the Group Manager 562 The Group Manager is responsible for performing the following tasks: 564 o Creating and managing OSCORE groups. This includes the assignment 565 of a Group ID to every newly created group, as well as ensuring 566 uniqueness of Group IDs within the set of its OSCORE groups. 568 o Defining policies for authorizing the joining of its OSCORE 569 groups. Such policies can be enforced by a third party, which is 570 in a trust relation with the Group Manager and enforces join 571 policies on behalf of the Group Manager. 573 o Driving the join process to add new endpoints as group members. 575 o Establishing Security Common Contexts and providing them to 576 authorized group members during the join process, together with a 577 corresponding Security Sender Context. 579 o Generating and managing Endpoint IDs within its OSCORE groups, as 580 well as assigning and providing them to new endpoints during the 581 join process. This includes ensuring uniqueness of Endpoints IDs 582 within each of its OSCORE groups. 584 o Defining a set of supported signature algorithms as part of the 585 communication policy of each of its OSCORE groups, and signalling 586 it to new endpoints during the join process. 588 o Defining the methods to handle loss of synchronization with 589 sequence numbers as part of the communication policy of each of 590 its OSCORE groups, and signaling the one(s) to use to new 591 endpoints during the join process. 593 o Renewing the Security Context of an OSCORE group upon membership 594 change, by revoking and renewing common security parameters and 595 keying material (rekeying). 597 o Providing the management keying material that a new endpoint 598 requires to participate in the rekeying process, consistently with 599 the key management scheme used in the group joined by the new 600 endpoint. 602 o Updating the Group ID of its OSCORE groups, upon renewing the 603 respective Security Context. 605 The Group Manager may additionally be responsible for the following 606 tasks: 608 o Acting as trusted key repository, in order to store the public 609 keys of the members of its OSCORE groups, and provide such public 610 keys to other members of the same group upon request. This 611 specification recommends that the Group Manager is entrusted to 612 perform this task. 614 o Acting as network router device where endpoints register to 615 correctly receive group messages sent to the multicast IP address 616 of that group. 618 o Autonomously and locally enforcing access policies to authorize 619 new endpoints to join its OSCORE groups. 621 7. Security Considerations 623 The same security considerations from OSCORE (Section 11 of 624 [I-D.ietf-core-object-security]) apply to this specification. 625 Additional security aspects to be taken into account are discussed 626 below. 628 7.1. Group-level Security 630 The approach described in this document relies on commonly shared 631 group keying material to protect communication within a group. This 632 means that messages are encrypted at a group level (group-level data 633 confidentiality), i.e. they can be decrypted by any member of the 634 group, but not by an external adversary or other external entities. 636 In addition, it is required that all group members are trusted, i.e. 637 they do not forward the content of group messages to unauthorized 638 entities. However, in many use cases, the devices in the group 639 belong to a common authority and are configured by a commissioner 640 (see Appendix B). 642 7.2. Uniqueness of (key, nonce) 644 The proof for uniqueness of (key, nonce) pairs in Appendix D.3 of 645 [I-D.ietf-core-object-security] is also valid in group communication 646 scenarios. That is, given an OSCORE group: 648 o Uniqueness of Sender IDs within the group is enforced by the Group 649 Manager. 651 o Case A is limited to requests, and same considerations hold. 653 o Case B applies to all responses, and same considerations hold. 655 It follows that each message encrypted/decrypted with the same Sender 656 Key is processed by using a different (ID_PIV, PIV) pair. This means 657 that nonces used by any fixed encrypting endpoint are unique. Thus, 658 each message is processed with a different (key, nonce) pair. 660 7.3. Collision of Group Identifiers 662 In case endpoints are deployed in multiple groups managed by 663 different non-synchronized Group Managers, it is possible for Group 664 Identifiers of different groups to coincide. However, this does not 665 impair the security of the AEAD algorithm. 667 In fact, as long as the Master Secret is different for different 668 groups and this condition holds over time, and as long as the Sender 669 IDs within a group are unique, it follows that AEAD keys and nonces 670 are different among different groups. 672 8. IANA Considerations 674 This document has no actions for IANA. 676 9. Acknowledgments 678 The authors sincerely thank Stefan Beck, Rolf Blom, Carsten Bormann, 679 Esko Dijk, Klaus Hartke, Richard Kelsey, John Mattsson, Jim Schaad, 680 Ludwig Seitz and Peter van der Stok for their feedback and comments. 682 The work on this document has been partly supported by the EIT- 683 Digital High Impact Initiative ACTIVE. 685 10. References 687 10.1. Normative References 689 [I-D.ietf-core-object-security] 690 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 691 "Object Security for Constrained RESTful Environments 692 (OSCORE)", draft-ietf-core-object-security-13 (work in 693 progress), June 2018. 695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 696 Requirement Levels", BCP 14, RFC 2119, 697 DOI 10.17487/RFC2119, March 1997, 698 . 700 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 701 Application Protocol (CoAP)", RFC 7252, 702 DOI 10.17487/RFC7252, June 2014, 703 . 705 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 706 Signature Algorithm (EdDSA)", RFC 8032, 707 DOI 10.17487/RFC8032, January 2017, 708 . 710 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 711 RFC 8152, DOI 10.17487/RFC8152, July 2017, 712 . 714 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 715 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 716 May 2017, . 718 10.2. Informative References 720 [I-D.ietf-ace-dtls-authorize] 721 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 722 L. Seitz, "Datagram Transport Layer Security (DTLS) 723 Profile for Authentication and Authorization for 724 Constrained Environments (ACE)", draft-ietf-ace-dtls- 725 authorize-03 (work in progress), March 2018. 727 [I-D.ietf-ace-oauth-authz] 728 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 729 H. Tschofenig, "Authentication and Authorization for 730 Constrained Environments (ACE) using the OAuth 2.0 731 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-12 732 (work in progress), May 2018. 734 [I-D.ietf-ace-oscore-profile] 735 Seitz, L., Palombini, F., Gunnarsson, M., and G. Selander, 736 "OSCORE profile of the Authentication and Authorization 737 for Constrained Environments Framework", draft-ietf-ace- 738 oscore-profile-01 (work in progress), March 2018. 740 [I-D.ietf-core-echo-request-tag] 741 Amsuess, C., Mattsson, J., and G. Selander, "Echo and 742 Request-Tag", draft-ietf-core-echo-request-tag-01 (work in 743 progress), March 2018. 745 [I-D.palombini-ace-key-groupcomm] 746 Palombini, F. and M. Tiloca, "Key Provisioning for Group 747 Communication using ACE", draft-palombini-ace-key- 748 groupcomm-01 (work in progress), June 2018. 750 [I-D.somaraju-ace-multicast] 751 Somaraju, A., Kumar, S., Tschofenig, H., and W. Werner, 752 "Security for Low-Latency Group Communication", draft- 753 somaraju-ace-multicast-02 (work in progress), October 754 2016. 756 [I-D.tiloca-ace-oscoap-joining] 757 Tiloca, M. and J. Park, "Joining OSCORE groups in ACE", 758 draft-tiloca-ace-oscoap-joining-03 (work in progress), 759 March 2018. 761 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 762 Protocol (GKMP) Specification", RFC 2093, 763 DOI 10.17487/RFC2093, July 1997, 764 . 766 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 767 Protocol (GKMP) Architecture", RFC 2094, 768 DOI 10.17487/RFC2094, July 1997, 769 . 771 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 772 Multicast: Issues and Architectures", RFC 2627, 773 DOI 10.17487/RFC2627, June 1999, 774 . 776 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 777 Thyagarajan, "Internet Group Management Protocol, Version 778 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 779 . 781 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 782 Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004, 783 . 785 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 786 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 787 DOI 10.17487/RFC3810, June 2004, 788 . 790 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 791 "Multicast Security (MSEC) Group Key Management 792 Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, 793 . 795 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 796 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 797 December 2005, . 799 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 800 "GSAKMP: Group Secure Association Key Management 801 Protocol", RFC 4535, DOI 10.17487/RFC4535, June 2006, 802 . 804 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 805 "Transmission of IPv6 Packets over IEEE 802.15.4 806 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 807 . 809 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 810 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 811 . 813 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 814 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 815 DOI 10.17487/RFC6282, September 2011, 816 . 818 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 819 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 820 January 2012, . 822 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 823 RFC 6749, DOI 10.17487/RFC6749, October 2012, 824 . 826 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 827 Constrained-Node Networks", RFC 7228, 828 DOI 10.17487/RFC7228, May 2014, 829 . 831 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 832 the Constrained Application Protocol (CoAP)", RFC 7390, 833 DOI 10.17487/RFC7390, October 2014, 834 . 836 Appendix A. Assumptions and Security Objectives 838 This section presents a set of assumptions and security objectives 839 for the approach described in this document. 841 A.1. Assumptions 843 The following assumptions are assumed to be already addressed and are 844 out of the scope of this document. 846 o Multicast communication topology: this document considers both 847 1-to-N (one sender and multiple recipients) and M-to-N (multiple 848 senders and multiple recipients) communication topologies. The 849 1-to-N communication topology is the simplest group communication 850 scenario that would serve the needs of a typical low-power and 851 lossy network (LLN). Examples of use cases that benefit from 852 secure group communication are provided in Appendix B. 854 In a 1-to-N communication model, only a single client transmits 855 data to the group, in the form of request messages; in an M-to-N 856 communication model (where M and N do not necessarily have the 857 same value), M group members are clients. According to [RFC7390], 858 any possible proxy entity is supposed to know about the clients in 859 the group and to not perform aggregation of response messages from 860 multiple servers. Also, every client expects and is able to 861 handle multiple response messages associated to a same request 862 sent to the group. 864 o Group size: security solutions for group communication should be 865 able to adequately support different and possibly large groups. 866 The group size is the current number of members in a group. In 867 the use cases mentioned in this document, the number of clients 868 (normally the controlling devices) is expected to be much smaller 869 than the number of servers (i.e. the controlled devices). A 870 security solution for group communication that supports 1 to 50 871 clients would be able to properly cover the group sizes required 872 for most use cases that are relevant for this document. The 873 maximum group size is expected to be in the range of 2 to 100 874 devices. Groups larger than that should be divided into smaller 875 independent groups, e.g. by grouping lights in a building on a per 876 floor basis. 878 o Communication with the Group Manager: an endpoint must use a 879 secure dedicated channel when communicating with the Group 880 Manager, even when not registered as group member. In particular, 881 communications with the Group Manager occuring during the join 882 process to become a group member must also be secured. 884 o Establishment and management of Security Contexts: an OSCORE 885 Security Context must be established among the group members. In 886 particular, a Common Context must be provided to a new joining 887 endpoint together with a corresponding Sender Context. On the 888 other hand, Recipient Contexts are locally and individually 889 derived by each group member. A secure mechanism must be used to 890 generate, revoke and (re-)distribute keying material, multicast 891 security policies and security parameters in the group. The 892 actual establishment and management of the Security Context is out 893 of the scope of this document, and it is anticipated that an 894 activity in IETF dedicated to the design of a generic key 895 management scheme will include this feature, preferably based on 896 [RFC3740][RFC4046][RFC4535]. 898 o Multicast data security ciphersuite: all group members must agree 899 on a ciphersuite to provide authenticity, integrity and 900 confidentiality of messages in the group. The ciphersuite is 901 specified as part of the Security Context. 903 o Backward security: a new device joining the group should not have 904 access to any old Security Contexts used before its joining. This 905 ensures that a new group member is not able to decrypt 906 confidential data sent before it has joined the group. The 907 adopted key management scheme should ensure that the Security 908 Context is updated to ensure backward confidentiality. The actual 909 mechanism to update the Security Context and renew the group 910 keying material upon a group member's joining has to be defined as 911 part of the group key management scheme. 913 o Forward security: entities that leave the group should not have 914 access to any future Security Contexts or message exchanged within 915 the group after their leaving. This ensures that a former group 916 member is not able to decrypt confidential data sent within the 917 group anymore. Also, it ensures that a former member is not able 918 to send encrypted and/or integrity protected messages to the group 919 anymore. The actual mechanism to update the Security Context and 920 renew the group keying material upon a group member's leaving has 921 to be defined as part of the group key management scheme. 923 A.2. Security Objectives 925 The approach described in this document aims at fulfilling the 926 following security objectives: 928 o Data replay protection: replayed group request messages or 929 response messages must be detected. 931 o Group-level data confidentiality: messages sent within the group 932 shall be encrypted if privacy sensitive data is exchanged within 933 the group. This document considers group-level data 934 confidentiality since messages are encrypted at a group level, 935 i.e. in such a way that they can be decrypted by any member of the 936 group, but not by an external adversary or other external 937 entities. 939 o Source authentication: messages sent within the group shall be 940 authenticated. That is, it is essential to ensure that a message 941 is originated by a member of the group in the first place, and in 942 particular by a specific member of the group. 944 o Message integrity: messages sent within the group shall be 945 integrity protected. That is, it is essential to ensure that a 946 message has not been tampered with by an external adversary or 947 other external entities which are not group members. 949 o Message ordering: it must be possible to determine the ordering of 950 messages coming from a single sender endpoint. In accordance with 951 OSCORE [I-D.ietf-core-object-security], this results in providing 952 relative freshness of group requests and absolute freshness of 953 responses. It is not required to determine ordering of messages 954 from different sender endpoints. 956 Appendix B. List of Use Cases 958 Group Communication for CoAP [RFC7390] provides the necessary 959 background for multicast-based CoAP communication, with particular 960 reference to low-power and lossy networks (LLNs) and resource 961 constrained environments. The interested reader is encouraged to 962 first read [RFC7390] to understand the non-security related details. 963 This section discusses a number of use cases that benefit from secure 964 group communication. Specific security requirements for these use 965 cases are discussed in Appendix A. 967 o Lighting control: consider a building equipped with IP-connected 968 lighting devices, switches, and border routers. The devices are 969 organized into groups according to their physical location in the 970 building. For instance, lighting devices and switches in a room 971 or corridor can be configured as members of a single group. 972 Switches are then used to control the lighting devices by sending 973 on/off/dimming commands to all lighting devices in a group, while 974 border routers connected to an IP network backbone (which is also 975 multicast-enabled) can be used to interconnect routers in the 976 building. Consequently, this would also enable logical groups to 977 be formed even if devices in the lighting group may be physically 978 in different subnets (e.g. on wired and wireless networks). 979 Connectivity between lighting devices may be realized, for 980 instance, by means of IPv6 and (border) routers supporting 6LoWPAN 981 [RFC4944][RFC6282]. Group communication enables synchronous 982 operation of a group of connected lights, ensuring that the light 983 preset (e.g. dimming level or color) of a large group of 984 luminaires are changed at the same perceived time. This is 985 especially useful for providing a visual synchronicity of light 986 effects to the user. As a practical guideline, events within a 987 200 ms interval are perceived as simultaneous by humans, which is 988 necessary to ensure in many setups. Devices may reply back to the 989 switches that issue on/off/dimming commands, in order to report 990 about the execution of the requested operation (e.g. OK, failure, 991 error) and their current operational status. In a typical 992 lighting control scenario, a single switch is the only entity 993 responsible for sending commands to a group of lighting devices. 994 In more advanced lighting control use cases, a M-to-N 995 communication topology would be required, for instance in case 996 multiple sensors (presence or day-light) are responsible to 997 trigger events to a group of lighting devices. Especially in 998 professional lighting scenarios, the roles of client and server 999 are configured by the lighting commissioner, and devices strictly 1000 follow those roles. 1002 o Integrated building control: enabling Building Automation and 1003 Control Systems (BACSs) to control multiple heating, ventilation 1004 and air-conditioning units to pre-defined presets. Controlled 1005 units can be organized into groups in order to reflect their 1006 physical position in the building, e.g. devices in the same room 1007 can be configured as members of a single group. As a practical 1008 guideline, events within intervals of seconds are typically 1009 acceptable. Controlled units are expected to possibly reply back 1010 to the BACS issuing control commands, in order to report about the 1011 execution of the requested operation (e.g. OK, failure, error) 1012 and their current operational status. 1014 o Software and firmware updates: software and firmware updates often 1015 comprise quite a large amount of data. This can overload a LLN 1016 that is otherwise typically used to deal with only small amounts 1017 of data, on an infrequent base. Rather than sending software and 1018 firmware updates as unicast messages to each individual device, 1019 multicasting such updated data to a larger group of devices at 1020 once displays a number of benefits. For instance, it can 1021 significantly reduce the network load and decrease the overall 1022 time latency for propagating this data to all devices. Even if 1023 the complete whole update process itself is secured, securing the 1024 individual messages is important, in case updates consist of 1025 relatively large amounts of data. In fact, checking individual 1026 received data piecemeal for tampering avoids that devices store 1027 large amounts of partially corrupted data and that they detect 1028 tampering hereof only after all data has been received. Devices 1029 receiving software and firmware updates are expected to possibly 1030 reply back, in order to provide a feedback about the execution of 1031 the update operation (e.g. OK, failure, error) and their current 1032 operational status. 1034 o Parameter and configuration update: by means of multicast 1035 communication, it is possible to update the settings of a group of 1036 similar devices, both simultaneously and efficiently. Possible 1037 parameters are related, for instance, to network load management 1038 or network access controls. Devices receiving parameter and 1039 configuration updates are expected to possibly reply back, to 1040 provide a feedback about the execution of the update operation 1041 (e.g. OK, failure, error) and their current operational status. 1043 o Commissioning of LLNs systems: a commissioning device is 1044 responsible for querying all devices in the local network or a 1045 selected subset of them, in order to discover their presence, and 1046 be aware of their capabilities, default configuration, and 1047 operating conditions. Queried devices displaying similarities in 1048 their capabilities and features, or sharing a common physical 1049 location can be configured as members of a single group. Queried 1050 devices are expected to reply back to the commissioning device, in 1051 order to notify their presence, and provide the requested 1052 information and their current operational status. 1054 o Emergency multicast: a particular emergency related information 1055 (e.g. natural disaster) is generated and multicast by an emergency 1056 notifier, and relayed to multiple devices. The latters may reply 1057 back to the emergency notifier, in order to provide their feedback 1058 and local information related to the ongoing emergency. This kind 1059 of setups should additionally rely on a fault tolerance multicast 1060 algorithm, such as MPL. 1062 Appendix C. Example of Group Identifier Format 1064 This section provides an example of how the Group Identifier (Gid) 1065 can be specifically formatted. That is, the Gid can be composed of 1066 two parts, namely a Group Prefix and a Group Epoch. 1068 The Group Prefix is constant over time and is uniquely defined in the 1069 set of all the groups associated to the same Group Manager. The 1070 choice of the Group Prefix for a given group's Security Context is 1071 application specific. The size of the Group Prefix directly impact 1072 on the maximum number of distinct groups under the same Group 1073 Manager. 1075 The Group Epoch is set to 0 upon the group's initialization, and is 1076 incremented by 1 upon completing each renewal of the Security Context 1077 and keying material in the group (see Section 2.1). In particular, 1078 once a new Master Secret has been distributed to the group, all the 1079 group members increment by 1 the Group Epoch in the Group Identifier 1080 of that group. 1082 As an example, a 3-byte Group Identifier can be composed of: i) a 1083 1-byte Group Prefix '0xb1' interpreted as a raw byte string; and ii) 1084 a 2-byte Group Epoch interpreted as an unsigned integer ranging from 1085 0 to 65535. Then, after having established the Security Common 1086 Context 61532 times in the group, its Group Identifier will assume 1087 value '0xb1f05c'. 1089 As discussed in Section 7.3, if endpoints are deployed in multiple 1090 groups managed by different non-synchronized Group Managers, it is 1091 possible that Group Identifiers of different groups coincide at some 1092 point in time. In this case, a recipient endpoint has to handle 1093 coinciding Group Identifiers, and has to try using different OSCORE 1094 Security Contexts to process an incoming message, until the right one 1095 is found and the message is correctly verified. Therefore, it is 1096 favourable that Group Idenfiers from different Group Managers have a 1097 size that result in a small probability of collision. How small this 1098 probability should be is up to system designers. 1100 Appendix D. Set-up of New Endpoints 1102 An endpoint joins a group by explicitly interacting with the 1103 responsible Group Manager. Communications between a joining endpoint 1104 and the Group Manager rely on the CoAP protocol and must be secured. 1105 Specific details on how to secure communications between joining 1106 endpoints and a Group Manager are out of scope. 1108 In order to receive multicast messages sent to the group, a joining 1109 endpoint has to register with a network router device 1110 [RFC3376][RFC3810], signaling its intent to receive packets sent to 1111 the multicast IP address of that group. As a particular case, the 1112 Group Manager can also act as such a network router device. Upon 1113 joining the group, endpoints are not required to know how many and 1114 what endpoints are active in the same group. 1116 Furthermore, in order to participate in the secure group 1117 communication, an endpoint needs to be properly initialized upon 1118 joining the group. In particular, the Group Manager provides keying 1119 material and parameters to a joining endpoint, which can then 1120 initialize its own Security Context (see Section 2). 1122 The following Appendix D.1 provides an example describing how such 1123 information can be provided to an endpoint upon joining a group 1124 through the responsible Group Manager. Then, Appendix D.2 discusses 1125 how public keys of group members can be handled and made available to 1126 group members. Finally, Appendix D.3 overviews how the ACE framework 1127 for Authentication and Authorization in constrained environments 1128 [I-D.ietf-ace-oauth-authz] can be possibly used to support such a 1129 join process. 1131 D.1. Join Process 1133 An endpoint requests to join a group by sending a confirmable CoAP 1134 POST request to the Group Manager responsible for that group. This 1135 join request can reflect the format of the Key Distribution Request 1136 message defined in Section 4.1 of [I-D.palombini-ace-key-groupcomm]. 1137 Besides, it can be addressed to a CoAP resource associated to that 1138 group and carries the following information. 1140 o Group identifier: the Group Identifier (Gid) of the group, as 1141 known to the joining endpoint at this point in time. This may not 1142 fully coincide with the Gid currently associated to the group, 1143 e.g. if it includes a dynamic component. This information can be 1144 mapped to the first element of the 'scope' parameter of the Key 1145 Distribution Request message defined in Section 4.1 of 1146 [I-D.palombini-ace-key-groupcomm]. 1148 o Role: the exact role of the joining endpoint in the group. 1149 Possible values are: "client", "server", "silent server", "client 1150 and server", or "client and silent server". This information can 1151 be mapped to the second element of the 'scope' parameter of the 1152 Key Distribution Request message defined in Section 4.1 of 1153 [I-D.palombini-ace-key-groupcomm]. 1155 o Retrieval flag: indication of interest to receive the public keys 1156 of the endpoints currently in the group, as included in the 1157 following join response. This flag must not be present if the 1158 Group Manager is not configured to store the public keys of group 1159 members, or if the joining endpoint is configured exclusively as 1160 silent server for the group to join. This information can be 1161 mapped to the 'get_pub_keys' parameter of the Key Distribution 1162 Request message defined in Section 4.1 of 1163 [I-D.palombini-ace-key-groupcomm]. 1165 o Identity credentials: information elements to enforce source 1166 authentication of group messages from the joining endpoint, such 1167 as its public key. The exact content depends on whether the Group 1168 Manager is configured to store the public keys of group members. 1169 If this is the case, this information is omitted if it has been 1170 provided to the same Group Manager upon previously joining the 1171 same or a different group under its control. This information is 1172 also omitted if the joining endpoint is configured exclusively as 1173 silent server for the joined group. Appendix D.2 discusses 1174 additional details on provisioning of public keys and other 1175 information to enforce source authentication of joining 1176 endpoints's messages. This information can be mapped to the 1177 'client_cred' parameter of the Key Distribution Request message 1178 defined in Section 4.1 of [I-D.palombini-ace-key-groupcomm]. 1180 The Group Manager must be able to verify that the joining endpoint is 1181 authorized to become a member of the group. To this end, the Group 1182 Manager can directly authorize the joining endpoint, or expect it to 1183 provide authorization evidence previously obtained from a trusted 1184 entity. Appendix D.3 describes how this can be achieved by 1185 leveraging the ACE framework for Authentication and Authorization in 1186 constrained environments [I-D.ietf-ace-oauth-authz]. 1188 In case of successful authorization check, the Group Manager 1189 generates an Endpoint ID assigned to the joining endpoint, before 1190 proceeding with the rest of the join process. Instead, in case the 1191 authorization check fails, the Group Manager aborts the join process. 1192 Further details about the authorization of joining endpoint are out 1193 of scope. 1195 As discussed in Section 2.1, it is recommended that the Security 1196 Context is renewed before the joining endpoint receives the group 1197 keying material and becomes a new active member of the group. This 1198 is achieved by securely distributing a new Master Secret and a new 1199 Group Identifier to the endpoints currently present in the same 1200 group. 1202 Once renewed the Security Context in the group, the Group Manager 1203 replies to the joining endpoint with a CoAP response carrying the 1204 following information. This join response can reflect the format of 1205 the Key Distribution Response message defined in Section 4.2 of 1206 [I-D.palombini-ace-key-groupcomm]. 1208 o Security Common Context: the OSCORE Security Common Context 1209 associated to the joined group (see Section 2). This information 1210 can be mapped to the 'key' parameter of the Key Distribution 1211 Response message defined in Section 4.2 of 1212 [I-D.palombini-ace-key-groupcomm]. 1214 o Endpoint ID: the Endpoint ID associated to the joining endpoint. 1215 This information is not included in case 'Role' in the join 1216 request is equal to "silent server". This information can be 1217 mapped to the 'clientID' parameter within the 'key' parameter of 1218 the Key Distribution Response message defined in Section 4.2 of 1219 [I-D.palombini-ace-key-groupcomm]. 1221 o Member public keys: the public keys of the endpoints currently 1222 present in the group. This includes: the public keys of the non- 1223 silent servers currently in the group, if the joining endpoint is 1224 configured (also) as client; and the public keys of the clients 1225 currently in the group, if the joining endpoint is configured 1226 (also) as server or silent server. This information is omitted in 1227 case the Group Manager is not configured to store the public keys 1228 of group members or if the 'Retrieval flag' was not present in the 1229 join request. Appendix D.2 discusses additional details on 1230 provisioning public keys upon joining the group and on retrieving 1231 public keys of group members. This information can be mapped to 1232 the 'pub_keys' parameter of the Key Distribution Response message 1233 defined in Section 4.2 of [I-D.palombini-ace-key-groupcomm]. 1235 o Group policies: a list of key words indicating the particular 1236 policies enforced in the group. This includes, for instance, the 1237 method to achieve synchronization of sequence numbers among group 1238 members (see Appendix E), as well as the rekeying protocol used to 1239 renew the keying material in the group (see Section 2.1). This 1240 information can be mapped to the 'group_policies' parameter of the 1241 Key Distribution Response message defined in Section 4.2 of 1242 [I-D.palombini-ace-key-groupcomm]. 1244 o Management keying material: the set of administrative keying 1245 material used to participate in the group rekeying process run by 1246 the Group Manager (see Section 2.1). The specific elements of 1247 this management keying material depend on the group rekeying 1248 protocol used in the group. For instance, this can simply consist 1249 in a group key encryption key and a pairwise symmetric key shared 1250 between the joining endpoint and the Group Manager, in case GKMP 1251 [RFC2093][RFC2094] is used. Instead, if key-tree based rekeying 1252 protocols like LKH [RFC2627] are used, it can consist in the set 1253 of symmetric keys associated to the key-tree leaf representing the 1254 group member up to the key-tree root representing the group key 1255 encryption key. This information can be mapped to the 1256 'mgt_key_material' parameter of the Key Distribution Response 1257 message defined in Section 4.2 of 1258 [I-D.palombini-ace-key-groupcomm]. 1260 D.2. Provisioning and Retrieval of Public Keys 1262 As mentioned in Section 6, it is recommended that the Group Manager 1263 acts as trusted key repository, so storing public keys of group 1264 members and providing them to other members of the same group upon 1265 request. In such a case, a joining endpoint provides its own public 1266 key to the Group Manager, as 'Identity credentials' of the join 1267 request, when joining the group (see Appendix D.1). 1269 After that, the Group Manager should verify that the joining endpoint 1270 actually owns the associated private key, for instance by performing 1271 a proof-of-possession challenge-response, whose details are out of 1272 scope. In case of failure, the Group Manager performs up to a pre- 1273 defined maximum number of retries, after which it aborts the join 1274 process. 1276 In case of successful challenge-response, the Group Manager stores 1277 the received public key as associated to the joining endpoint and its 1278 Endpoint ID. From then on, that public key will be available for 1279 secure and trusted delivery to other endpoints in the group. A 1280 possible approach for a group member to retrieve the public key of 1281 other group members is described in Section 7 of 1282 [I-D.palombini-ace-key-groupcomm]. 1284 Finally, the Group Manager sends the join response to the joining 1285 endpoint, as described in Appendix D.1. 1287 The joining endpoint does not have to provide its own public key if 1288 that already occurred upon previously joining the same or a different 1289 group under the same Group Manager. However, separately for each 1290 group under its control, the Group Manager maintains an updated list 1291 of active Endpoint IDs associated to the respective endpoint's public 1292 key. 1294 Instead, in case the Group Manager does not act as trusted key 1295 repository, the following exchange with the Group Manager can occur 1296 during the join process. 1298 1. The joining endpoint signs its own certificate by using its own 1299 private key. The certificate includes also the identifier of the 1300 issuer Certification Authority (CA). There is no restriction on 1301 the Certificate Subject included in the joining endpoint's 1302 certificate. 1304 2. The joining endpoint specifies the signed certificate as 1305 'Identity credentials' in the join request (Appendix D.1). The 1306 joining endpoint can optionally specify also a list of public key 1307 repositories storing its own certificate. In such a case, this 1308 information can be mapped to the 'pub_keys_repos' parameter of 1309 the Key Distribution Request message defined in Section 4.1 of 1310 [I-D.palombini-ace-key-groupcomm]. 1312 3. When processing the join request, the Group Manager first 1313 validates the certificate by verifying the signature of the 1314 issuer CA, and then verifies the signature of the joining 1315 endpoint. 1317 4. The Group Manager stores the association between the Certificate 1318 Subject of the joining endpoint's certificate and the pair {Group 1319 ID, Endpoint ID of the joining endpoint}. If received from the 1320 joining endpoint, the Group Manager also stores the list of 1321 public key repositories storing the certificate of the joining 1322 endpoint. 1324 When a group member X wants to retrieve the public key of another 1325 group member Y in the same group, the endpoint X proceeds as follows. 1327 1. The endpoint X contacts the Group Manager, specifying the pair 1328 {Group ID, Endpoint ID of the endpoint Y}. 1330 2. The Group Manager provides the endpoint X with the Certificate 1331 Subject CS from the certificate of endpoint Y. If available, the 1332 Group Manager provides the endpoint X also with the list of 1333 public key repositories storing the certificate of the endpoint 1334 Y. 1336 3. The endpoint X retrieves the certificate of the endpoint X from a 1337 key repository storing it, by using the Certificate Subject CS. 1339 D.3. Group Joining Based on the ACE Framework 1341 The join process to register an endpoint as a new member of a group 1342 can be based on the ACE framework for Authentication and 1343 Authorization in constrained environments [I-D.ietf-ace-oauth-authz], 1344 built on re-use of OAuth 2.0 [RFC6749]. 1346 In particular, the approach described in 1347 [I-D.tiloca-ace-oscoap-joining] uses the ACE framework to delegate 1348 the authentication and authorization of joining endpoints to an 1349 Authorization Server in a trust relation with the Group Manager. At 1350 the same time, it allows a joining endpoint to establish a secure 1351 channel with the Group Manager, by leveraging protocol-specific 1352 profiles of ACE, such as [I-D.ietf-ace-oscore-profile] and 1353 [I-D.ietf-ace-dtls-authorize], to achieve communication security, 1354 proof-of-possession and server authentication. 1356 More specifically and with reference to the terminology defined in 1357 OAuth 2.0: 1359 o The joining endpoint acts as ACE Client; 1361 o The Group Manager acts as ACE Resource Server, with different CoAP 1362 resources for different groups it is responsible for; 1364 o An Authorization Server enables and enforces authorized access of 1365 the joining endpoint to the Group Manager and its CoAP resources 1366 paired with groups to join. 1368 Messages exchanged among the participants follow the formats defined 1369 in [I-D.palombini-ace-key-groupcomm]. Both the joining endpoint and 1370 the Group Manager have to adopt secure communication also for any 1371 message exchange with the Authorization Server. To this end, 1372 different alternatives are possible, such as OSCORE, DTLS [RFC6347] 1373 or IPsec [RFC4301]. 1375 Appendix E. Examples of Synchronization Approaches 1377 This section describes three possible approaches that can be 1378 considered by server endpoints to synchronize with sequence numbers 1379 of client endpoints sending group requests. 1381 E.1. Best-Effort Synchronization 1383 Upon receiving a group request from a client, a server does not take 1384 any action to synchonize with the sequence number of that client. 1385 This provides no assurance at all as to message freshness, which can 1386 be acceptable in non-critical use cases. 1388 E.2. Baseline Synchronization 1390 Upon receiving a group request from a given client for the first 1391 time, a server initializes its last-seen sequence number in its 1392 Recipient Context associated to that client. However, the server 1393 drops the group request without delivering it to the application 1394 layer. This provides a reference point to identify if future group 1395 requests from the same client are fresher than the last one received. 1397 A replay time interval exists, between when a possibly replayed 1398 message is originally transmitted by a given client and the first 1399 authentic fresh message from that same client is received. This can 1400 be acceptable for use cases where servers admit such a trade-off 1401 between performance and assurance of message freshness. 1403 E.3. Challenge-Response Synchronization 1405 A server performs a challenge-response exchange with a client, by 1406 using the Echo Option for CoAP described in Section 2 of 1407 [I-D.ietf-core-echo-request-tag] and consistently with what specified 1408 in Section 7.5.2 of [I-D.ietf-core-object-security]. 1410 That is, upon receiving a group request from a particular client for 1411 the first time, the server processes the message as described in 1412 Section 4.2 of this specification, but, even if valid, does not 1413 deliver it to the application. Instead, the server replies to the 1414 client with a 4.03 Forbidden response message including an Echo 1415 Option, and stores the option value included therein. 1417 Upon receiving a 4.03 Forbidden response that includes an Echo Option 1418 and originates from a verified group member, a client sends a request 1419 as a unicast message addressed to the same server, echoing the Echo 1420 Option value. In particular, the client does not necessarily resend 1421 the same group request, but can instead send a more recent one, if 1422 the application permits it. This makes it possible for the client to 1423 not retain previously sent group requests for full retransmission, 1424 unless the application explicitly requires otherwise. In either 1425 case, the client uses the sequence number value currently stored in 1426 its own Sender Context. If the client stores group requests for 1427 possible retransmission with the Echo Option, it should not store a 1428 given request for longer than a pre-configured time interval. Note 1429 that the unicast request echoing the Echo Option is correctly treated 1430 and processed as a group message, since the 'kid context' field 1431 including the Group Identifier of the OSCORE group is still present 1432 in the OSCORE Option as part of the COSE object (see Section 3). 1434 Upon receiving the unicast request including the Echo Option, the 1435 server verifies that the option value equals the stored and 1436 previously sent value; otherwise, the request is silently discarded. 1437 Then, the server verifies that the unicast request has been received 1438 within a pre-configured time interval, as described in 1439 [I-D.ietf-core-echo-request-tag]. In such a case, the request is 1440 further processed and verified; otherwise, it is silently discarded. 1441 Finally, the server updates the Recipient Context associated to that 1442 client, by setting the Replay Window according to the Sequence Number 1443 from the unicast request conveying the Echo Option. The server 1444 either delivers the request to the application if it is an actual 1445 retransmission of the original one, or discards it otherwise. 1446 Mechanisms to signal whether the resent request is a full 1447 retransmission of the original one are out of the scope of this 1448 specification. 1450 In case it does not receive a valid unicast request including the 1451 Echo Option within the configured time interval, the server endpoint 1452 should perform the same challenge-response upon receiving the next 1453 group request from that same client. 1455 A server should not deliver group requests from a given client to the 1456 application until one valid request from that same client has been 1457 verified as fresh, as conveying an echoed Echo Option 1458 [I-D.ietf-core-echo-request-tag]. Also, a server may perform the 1459 challenge-response described above at any time, if synchronization 1460 with sequence numbers of clients is (believed to be) lost, for 1461 instance after a device reboot. It is the role of the application to 1462 define under what circumstances sequence numbers lose 1463 synchronization. This can include a minimum gap between the sequence 1464 number of the latest accepted group request from a client and the 1465 sequence number of a group request just received from the same 1466 client. A client has to be always ready to perform the challenge- 1467 response based on the Echo Option in case a server starts it. 1469 Note that endpoints configured as silent servers are not able to 1470 perform the challenge-response described above, as they do not store 1471 a Sender Context to secure the 4.03 Forbidden response to the client. 1472 Therefore, silent servers should adopt alternative approaches to 1473 achieve and maintain synchronization with sequence numbers of 1474 clients. 1476 This approach provides an assurance of absolute message freshness. 1477 However, it can result in an impact on performance which is 1478 undesirable or unbearable, especially in large groups where many 1479 endpoints at the same time might join as new members or lose 1480 synchronization. 1482 Appendix F. No Verification of Signatures 1484 There are some application scenarios using group communication that 1485 have particularly strict requirements. One example of this is the 1486 requirement of low message latency in non-emergency lighting 1487 applications [I-D.somaraju-ace-multicast]. For those applications 1488 which have tight performance constraints and relaxed security 1489 requirements, it can be inconvenient for some endpoints to verify 1490 digital signatures in order to assert source authenticity of received 1491 group messages. In other cases, the signature verification can be 1492 deferred or only checked for specific actions. For instance, a 1493 command to turn a bulb on where the bulb is already on does not need 1494 the signature to be checked. In such situations, the counter 1495 signature needs to be included anyway as part of the group message, 1496 so that an endpoint that needs to validate the signature for any 1497 reason has the ability to do so. 1499 In this specification, it is NOT RECOMMENDED that endpoints do not 1500 verify the counter signature of received group messages. However, it 1501 is recognized that there may be situations where it is not always 1502 required. The consequence of not doing the signature validation is 1503 that security in the group is based only on the group-authenticity of 1504 the shared keying material used for encryption. That is, endpoints 1505 in the group have evidence that a received message has been 1506 originated by a group member, although not specifically identifiable 1507 in a secure way. This can violate a number of security requirements, 1508 as the compromise of any element in the group means that the attacker 1509 has the ability to control the entire group. Even worse, the group 1510 may not be limited in scope, and hence the same keying material might 1511 be used not only for light bulbs but for locks as well. Therefore, 1512 extreme care must be taken in situations where the security 1513 requirements are relaxed, so that deployment of the system will 1514 always be done safely. 1516 Appendix G. Document Updates 1518 RFC EDITOR: PLEASE REMOVE THIS SECTION. 1520 G.1. Version -01 to -02 1522 o Terminology has been made more aligned with RFC7252 and draft- 1523 ietf-core-object-security: i) "client" and "server" replace the 1524 old "multicaster" and "listener", respectively; ii) "silent 1525 server" replaces the old "pure listener". 1527 o Section 2 has been updated to have the Group Identifier stored in 1528 the 'ID Context' parameter defined in draft-ietf-core-object- 1529 security. 1531 o Section 3 has been updated with the new format of the Additional 1532 Authenticated Data. 1534 o Major rewriting of Section 4 to better highlight the differences 1535 with the message processing in draft-ietf-core-object-security. 1537 o Added Sections 7.2 and 7.3 discussing security considerations 1538 about uniqueness of (key, nonce) and collision of group 1539 identifiers, respectively. 1541 o Minor updates to Appendix A.1 about assumptions on multicast 1542 communication topology and group size. 1544 o Updated Appendix C on format of group identifiers, with practical 1545 implications of possible collisions of group identifiers. 1547 o Updated Appendix D.2, adding a pointer to draft-palombini-ace-key- 1548 groupcomm about retrieval of nodes' public keys through the Group 1549 Manager. 1551 o Minor updates to Appendix E.3 about Challenge-Response 1552 synchronization of sequence numbers based on the Echo option from 1553 draft-ietf-core-echo-request-tag. 1555 G.2. Version -00 to -01 1557 o Section 1.1 has been updated with the definition of group as 1558 "security group". 1560 o Section 2 has been updated with: 1562 * Clarifications on etablishment/derivation of security contexts. 1564 * A table summarizing the the additional context elements 1565 compared to OSCORE. 1567 o Section 3 has been updated with: 1569 * Examples of request and response messages. 1571 * Use of CounterSignature0 rather than CounterSignature. 1573 * Additional Authenticated Data including also the signature 1574 algorithm, while not including the Group Identifier any longer. 1576 o Added Section 6, listing the responsibilities of the Group 1577 Manager. 1579 o Added Appendix A (former section), including assumptions and 1580 security objectives. 1582 o Appendix B has been updated with more details on the use cases. 1584 o Added Appendix C, providing an example of Group Identifier format. 1586 o Appendix D has been updated to be aligned with draft-palombini- 1587 ace-key-groupcomm. 1589 Authors' Addresses 1591 Marco Tiloca 1592 RISE SICS 1593 Isafjordsgatan 22 1594 Kista SE-16440 Stockholm 1595 Sweden 1597 Email: marco.tiloca@ri.se 1599 Goeran Selander 1600 Ericsson AB 1601 Torshamnsgatan 23 1602 Kista SE-16440 Stockholm 1603 Sweden 1605 Email: goran.selander@ericsson.com 1607 Francesca Palombini 1608 Ericsson AB 1609 Torshamnsgatan 23 1610 Kista SE-16440 Stockholm 1611 Sweden 1613 Email: francesca.palombini@ericsson.com 1615 Jiye Park 1616 Universitaet Duisburg-Essen 1617 Schuetzenbahn 70 1618 Essen 45127 1619 Germany 1621 Email: ji-ye.park@uni-due.de