idnits 2.17.1 draft-ietf-core-oscore-groupcomm-01.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 (March 05, 2018) is 2243 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-08 ** 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-02 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-10 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-00 == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-00 == Outdated reference: A later version (-02) exists of draft-palombini-ace-key-groupcomm-00 == Outdated reference: A later version (-05) exists of draft-tiloca-ace-oscoap-joining-02 -- 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 AB 4 Intended status: Standards Track G. Selander 5 Expires: September 6, 2018 F. Palombini 6 Ericsson AB 7 J. Park 8 Universitaet Duisburg-Essen 9 March 05, 2018 11 Secure group communication for CoAP 12 draft-ietf-core-oscore-groupcomm-01 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 September 6, 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 . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. OSCORE Security Context . . . . . . . . . . . . . . . . . . . 5 64 2.1. Management of Group Keying Material . . . . . . . . . . . 7 65 3. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.1. Example: Request . . . . . . . . . . . . . . . . . . . . 10 67 3.2. Example: Response . . . . . . . . . . . . . . . . . . . . 10 68 4. Message Processing . . . . . . . . . . . . . . . . . . . . . 11 69 4.1. Protecting the Request . . . . . . . . . . . . . . . . . 11 70 4.2. Verifying the Request . . . . . . . . . . . . . . . . . . 12 71 4.3. Protecting the Response . . . . . . . . . . . . . . . . . 12 72 4.4. Verifying the Response . . . . . . . . . . . . . . . . . 12 73 5. Synchronization of Sequence Numbers . . . . . . . . . . . . . 13 74 6. Responsibilities of the Group Manager . . . . . . . . . . . . 13 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 7.1. Group-level Security . . . . . . . . . . . . . . . . . . 15 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 81 10.2. Informative References . . . . . . . . . . . . . . . . . 16 82 Appendix A. Assumptions and Security Objectives . . . . . . . . 19 83 A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 19 84 A.2. Security Objectives . . . . . . . . . . . . . . . . . . . 20 85 Appendix B. List of Use Cases . . . . . . . . . . . . . . . . . 21 86 Appendix C. Example of Group Identifier Format . . . . . . . . . 23 87 Appendix D. Set-up of New Endpoints . . . . . . . . . . . . . . 24 88 D.1. Join Process . . . . . . . . . . . . . . . . . . . . . . 24 89 D.2. Provisioning and Retrieval of Public Keys . . . . . . . . 27 90 D.3. Group Joining Based on the ACE Framework . . . . . . . . 29 91 Appendix E. Examples of Synchronization Approaches . . . . . . . 29 92 E.1. Best-Effort Synchronization . . . . . . . . . . . . . . . 30 93 E.2. Baseline Synchronization . . . . . . . . . . . . . . . . 30 94 E.3. Challenge-Response Synchronization . . . . . . . . . . . 30 95 Appendix F. No Verification of Signatures . . . . . . . . . . . 32 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 98 1. Introduction 100 The Constrained Application Protocol (CoAP) [RFC7252] is a web 101 transfer protocol specifically designed for constrained devices and 102 networks [RFC7228]. 104 Group communication for CoAP [RFC7390] addresses use cases where 105 deployed devices benefit from a group communication model, for 106 example to reduce latencies and improve performance. Use cases 107 include lighting control, integrated building control, software and 108 firmware updates, parameter and configuration updates, commissioning 109 of constrained networks, and emergency multicast (see Appendix B). 110 Furthermore, [RFC7390] recognizes the importance to introduce a 111 secure mode for CoAP group communication. This specification defines 112 such a mode. 114 Object Security for Constrained RESTful Environments 115 (OSCORE)[I-D.ietf-core-object-security] describes a security protocol 116 based on the exchange of protected CoAP messages. OSCORE builds on 117 CBOR Object Signing and Encryption (COSE) [RFC8152] and provides end- 118 to-end encryption, integrity, and replay protection between a sending 119 endpoint and a receiving endpoint possibly involving intermediary 120 endpoints. To this end, a CoAP message is protected by including its 121 payload (if any), certain options, and header fields in a COSE 122 object, which finally replaces the authenticated and encrypted fields 123 in the protected message. 125 This document describes group OSCORE, providing end-to-end security 126 of CoAP messages exchanged between members of a group. In 127 particular, the described approach defines how OSCORE should be used 128 in a group communication setting, so that end-to-end security is 129 assured by using the same security method. That is, end-to-end 130 security is assured for multicast CoAP requests sent by multicaster 131 endpoints to the group and for related CoAP responses sent as reply 132 by multiple listener endpoints. Group OSCORE provides source 133 authentication of all CoAP messages exchanged within the group, by 134 means of digital signatures produced through private keys of sender 135 devices and embedded in the protected CoAP messages. As in OSCORE, 136 it is still possible to simultaneously rely on DTLS to protect hop- 137 by-hop communication between a multicaster endpoint and a proxy (and 138 vice versa), and between a proxy and a listener endpoint (and vice 139 versa). 141 1.1. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 Readers are expected to be familiar with the terms and concepts 150 described in CoAP [RFC7252] including "endpoint", "sender" and 151 "recipient"; group communication for CoAP [RFC7390]; COSE and counter 152 signatures [RFC8152]. 154 Readers are also expected to be familiar with the terms and concepts 155 for protection and processing of CoAP messages through OSCORE, such 156 as "Security Context", "Master Secret" and "Master Salt", defined in 157 [I-D.ietf-core-object-security]. 159 Terminology for constrained environments, such as "constrained 160 device", "constrained-node network", is defined in [RFC7228]. 162 This document refers also to the following terminology. 164 o Keying material: data that is necessary to establish and maintain 165 secure communication among endpoints. This includes, for 166 instance, keys and IVs [RFC4949]. 168 o Group: a set of endpoints that share group keying material and 169 parameters (Common Context of the group's Security Context, see 170 Section 2). That is, the term group used in this specification 171 refers to a "security group", not to be confused with network/ 172 multicast groups or application groups. 174 o Group Manager (GM): entity responsible for a set of OSCORE groups. 175 Each endpoint in a group securely communicates with the respective 176 GM, which is not required to be an actual group member and to take 177 part in the group communication. The full list of 178 responsibilities of the Group Manager is provided in Section 6. 180 o Multicaster: member of a group that sends multicast CoAP request 181 messages intended for all members of the group. In a 1-to-N 182 communication model, only a single multicaster transmits data to 183 the group; in an M-to-N communication model (where M and N do not 184 necessarily have the same value), M group members are 185 multicasters. According to [RFC7390], any possible proxy entity 186 is supposed to know about the multicasters in the group and to not 187 perform aggregation of response messages. Also, every multicaster 188 expects and is able to handle multiple response messages 189 associated to a given multicast request message that it has 190 previously sent to the group. 192 o Listener: member of a group that receives multicast CoAP request 193 messages when listening to the multicast IP address associated to 194 the group. A listener may reply back, by sending a response 195 message to the multicaster which has sent the request message. 197 o Pure listener: member of a group that is configured as listener 198 and never replies back to multicasters after receiving request 199 messages. 201 o Group ID: group identifier assigned to the group. Group IDs are 202 unique within the set of groups of a same Group Manager. 204 o Endpoint ID: Sender ID of the endpoint, as defined in 205 [I-D.ietf-core-object-security]. An Endpoint ID is provided to an 206 endpoint upon joining a group, is valid only within that group, 207 and is unique within the same group. Endpoints which are 208 configured only as pure listeners do not have an Endpoint ID. 210 o Group request: multicast CoAP request message sent by a 211 multicaster in the group to all listeners in the group through 212 multicast IP, unless otherwise specified. 214 o Source authentication: evidence that a received message in the 215 group originated from a specifically identified group member. 216 This also provides assurances that the message was not tampered 217 with by a different group member or by a non-group member. 219 2. OSCORE Security Context 221 To support group communication secured with OSCORE, each endpoint 222 registered as member of a group maintains a Security Context as 223 defined in Section 3 of [I-D.ietf-core-object-security]. In 224 particular, each endpoint in a group stores: 226 1. one Common Context, shared by all the endpoints in the group. 227 All the endpoints in the group agree on the same COSE AEAD 228 algorithm. In addition to what is defined in Section 3 of 229 [I-D.ietf-core-object-security], the Common Context includes the 230 following information. 232 * Group Identifier (Gid). Variable length byte string 233 identifying the Security Context. A Gid MUST have a random 234 component and be long enough, in order to achieve a negligible 235 probability of collisions between Group Identifiers from 236 different Group Managers. A Group ID is used i) alone or 237 together with other parameters, such as the multicast IP 238 address of the group, to retrieve the OSCORE Security Context 239 of the associated group (see Section 4); and ii) as OSCORE 240 Master Salt (see Section 3.1 of 241 [I-D.ietf-core-object-security]). The choice of the Gid for a 242 given group's Security Context is application specific. It is 243 the role of the application to specify how to handle possible 244 collisions. An example of specific formatting of the Group 245 Identifier that would follow this specification is given in 246 Appendix C. 248 * Counter Signature Algorithm. Value identifying the algorithm 249 used for source authenticating messages sent within the group, 250 by means of a counter signature (see Section 4.5 of 251 [RFC8152]). Its value is immutable once the Common Context is 252 established. All the endpoints in the group agree on the same 253 counter signature algorithm. The list of supported signature 254 algorithms is part of the group communication policy and MUST 255 include the EdDSA signature algorithm ed25519 [RFC8032]. 257 2. one Sender Context, unless the endpoint is configured exclusively 258 as pure listener. The Sender Context is used to secure outgoing 259 group messages and is initialized according to Section 3 of 260 [I-D.ietf-core-object-security], once the endpoint has joined the 261 group. In practice, the symmetric keying material in the Sender 262 Context of the sender endpoint is shared with all the recipient 263 endpoints that have received group messages from that same sender 264 endpoint. Besides, in addition to what is defined in 265 [I-D.ietf-core-object-security], the Sender Context stores also 266 the endpoint's public-private key pair. 268 3. one Recipient Context for each distinct endpoint from which group 269 messages are received, used to process such incoming messages. 270 The recipient endpoint creates a new Recipient Context upon 271 receiving an incoming message from another endpoint in the group 272 for the first time (see Section 4.2 and Section 4.4). In 273 practice, the symmetric keying material in a given Recipient 274 Context of the recipient endpoint is shared with the associated 275 sender endpoint from which group messages are received. Besides, 276 in addition to what is defined in 277 [I-D.ietf-core-object-security], each Recipient Context stores 278 also the public key of the associated other endpoint from which 279 group messages are received. 281 The table in Figure 1 overviews the new information included in the 282 OSCORE Security Context, with respect to what defined in Section 3 of 283 [I-D.ietf-core-object-security]. 285 +---------------------------+-----------------------------+ 286 | Context portion | New information | 287 +---------------------------+-----------------------------+ 288 | | | 289 | Common Context | Group Identifier (Gid) | 290 | | | 291 | Common Context | Counter signature algorithm | 292 | | | 293 | Sender Context | Endpoint's private key | 294 | | | 295 | Sender Context | Endpoint's public key | 296 | | | 297 | Each Recipient Context | Public key of the | 298 | | associated other endpoint | 299 | | | 300 +---------------------------+-----------------------------+ 302 Figure 1: Additions to the OSCORE Security Context 304 Upon receiving a secure CoAP message, a recipient endpoint relies on 305 the sender endpoint's public key, in order to verify the counter 306 signature conveyed in the COSE Object. 308 If not already stored in the Recipient Context associated to the 309 sender endpoint, the recipient endpoint retrieves the public key from 310 a trusted key repository. In such a case, the correct binding 311 between the sender endpoint and the retrieved public key must be 312 assured, for instance by means of public key certificates. Further 313 discussion about how public keys can be handled and retrieved in the 314 group is provided in Appendix D.2. 316 The Sender Key/IV stored in the Sender Context and the Recipient 317 Keys/IVs stored in the Recipient Contexts are derived according to 318 the same scheme defined in Section 3.2 of 319 [I-D.ietf-core-object-security]. 321 2.1. Management of Group Keying Material 323 The approach described in this specification should take into account 324 the risk of compromise of group members. In particular, the adoption 325 of key management schemes for secure revocation and renewal of 326 Security Contexts and group keying material should be considered. 328 Consistently with the security assumptions in Appendix A.1, it is 329 RECOMMENDED to adopt a group key management scheme, and securely 330 distribute a new value for the Master Secret parameter of the group's 331 Security Context, before a new joining endpoint is added to the group 332 or after a currently present endpoint leaves the group. This is 333 necessary in order to preserve backward security and forward security 334 in the group. 336 In particular, a new Group Identifier (Gid) for that group and a new 337 value for the Master Secret parameter must also be distributed. An 338 example of Group Identifier format supporting this operation is 339 provided in Appendix C. Then, each group member re-derives the 340 keying material stored in its own Sender Context and Recipient 341 Contexts as described in Section 2, using the updated Group 342 Identifier. 344 Especially in dynamic, large-scale, groups where endpoints can join 345 and leave at any time, it is important that the considered group key 346 management scheme is efficient and highly scalable with the group 347 size, in order to limit the impact on performance due to the Security 348 Context and keying material update. 350 3. The COSE Object 352 When creating a protected CoAP message, an endpoint in the group 353 computes the COSE object using the untagged COSE_Encrypt0 structure 354 [RFC8152] as defined in Section 5 of [I-D.ietf-core-object-security], 355 with the following modifications. 357 o The value of the "kid" parameter in the "unprotected" field of 358 response messagess SHALL be set to the Endpoint ID of the endpoint 359 transmitting the message, i.e. the Sender ID. 361 o The "unprotected" field of the "Headers" field SHALL additionally 362 include the following parameter: 364 * CounterSignature0 : its value is set to the counter signature 365 of the COSE object, computed by the endpoint by means of its 366 own private key as described in Section 4.5 of [RFC8152]. The 367 presence of this parameter is explicitly signaled, by using the 368 reserved sixth least significant bit of the first byte of flag 369 bits in the value of the Object-Security option (see 370 Section 6.1 of [I-D.ietf-core-object-security]). 372 o The Additional Authenticated Data (AAD) considered to compute the 373 COSE object is extended, by adding the countersignature algorithm 374 used to protect group messages. In particular, the "external_aad" 375 defined in Section 5.4 of [I-D.ietf-core-object-security] SHALL 376 also include "alg_countersign", which contains the Counter 377 Signature Algorithm from the Common Context (see Section 2). 379 external_aad = [ 380 oscore_version : uint, 381 [alg_aead : int / tstr , alg_countersign : int / tstr], 382 request_kid : bstr, 383 request_piv : bstr, 384 options : bstr 385 ] 387 o The OSCORE compression defined in Section 6 of 388 [I-D.ietf-core-object-security] is used, with the following 389 additions for the encoding of the Object-Security option. 391 * The fourth least significant bit of the first byte of flag bits 392 SHALL be set to 1, to indicate the presence of the "kid" 393 parameter for both group requests and responses. 395 * The fifth least significant bit of the first byte of flag bits 396 MUST be set to 1 for group requests, to indicate the presence 397 of the kid context in the OSCORE payload. The kid context flag 398 MAY be set to 1 for responses. 400 * The sixth least significant bit of the first byte of flag bits 401 is originally marked as reserved in 402 [I-D.ietf-core-object-security] and its usage is defined in 403 this specification. This bit is set to 1 if the 404 "CounterSignature0" parameter is present, or to 0 otherwise. 405 In order to ensure source authentication of group messages as 406 described in this specification, this bit SHALL be set to 1. 408 * The 'kid context' value encodes the Group Identifier value 409 (Gid) of the group's Security Context. 411 * The following q bytes (q given by the Counter Signature 412 Algorithm specified in the Security Context) encode the value 413 of the "CounterSignature0" parameter including the counter 414 signature of the COSE object. 416 * The remaining bytes in the Object-Security value encode the 417 value of the "kid" parameter, which is always present both in 418 group requests and in responses. 420 0 1 2 3 4 5 6 7 <----------- n bytes -----------> <-- 1 byte --> 421 +-+-+-+-+-+-+-+-+---------------------------------+--------------+ 422 |0 0|1|h|1| n | Partial IV (if any) | s (if any) | 423 +-+-+-+-+-+-+-+-+---------------------------------+--------------+ 425 <------ s bytes ------> <--------- q bytes ---------> 426 -----------------------+-----------------------------+-----------+ 427 kid context = Gid | CounterSignature0 | kid | 428 -----------------------+-----------------------------+-----------+ 430 Figure 2: Object-Security Value 432 3.1. Example: Request 434 Request with kid = 0x25, Partial IV = 5 and kid context = 0x44616c, 435 assuming the label for the new kid context defined in 436 [I-D.ietf-core-object-security] has value 10. COUNTERSIGN is the 437 CounterSignature0 byte string as described in Section 3 and is 64 438 bytes long in this example. The ciphertext in this example is 14 439 bytes long. 441 Before compression (96 bytes): 443 [ 444 h'', 445 { 4:h'25', 6:h'05', 10:h'44616c', 9:COUNTERSIGN }, 446 h'aea0155667924dff8a24e4cb35b9' 447 ] 449 After compression (85 bytes): 451 Flag byte: 0b00111001 = 0x39 453 Option Value: 39 05 03 44 61 6c COUNTERSIGN 25 (7 bytes + size of 454 COUNTERSIGN) 456 Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes) 458 3.2. Example: Response 460 Response with kid = 0x52. COUNTERSIGN is the CounterSignature0 byte 461 string as described in Section 3 and is 64 bytes long in this 462 example. The ciphertext in this example is 14 bytes long. 464 Before compression (88 bytes): 466 [ 467 h'', 468 { 4:h'52', 9:COUNTERSIGN }, 469 h'60b035059d9ef5667c5a0710823b' 470 ] 472 After compression (80 bytes): 474 Flag byte: 0b00101000 = 0x28 476 Option Value: 28 COUNTERSIGN 52 (2 bytes + size of COUNTERSIGN) 478 Payload: 60 b0 35 05 9d 9e f5 66 7c 5a 07 10 82 3b (14 bytes) 480 4. Message Processing 482 Each request message and response message is protected and processed 483 as specified in [I-D.ietf-core-object-security], with the 484 modifications described in the following sections. The following 485 security objectives are fulfilled, as further discussed in 486 Appendix A.2: data replay protection, group-level data 487 confidentiality, source authentication, message integrity, and 488 message ordering. 490 Furthermore, endpoints in the group locally perform error handling 491 and processing of invalid messages according to the same principles 492 adopted in [I-D.ietf-core-object-security]. However, a receiver 493 endpoint MUST stop processing and silently reject any message which 494 is malformed and does not follow the format specified in Section 3, 495 without sending back any error message. This prevents listener 496 endpoints from sending multiple error messages to a multicaster 497 endpoint, so avoiding the risk of flooding and possibly congesting 498 the group. 500 4.1. Protecting the Request 502 A multicaster endpoint transmits a secure group request as described 503 in Section 8.1 of [I-D.ietf-core-object-security], with the following 504 modifications. 506 1. The multicaster endpoint stores the association Token - Group 507 Identifier. That is, it SHALL be able to find the correct 508 Security Context used to protect the group request and verify the 509 response(s) by using the CoAP Token used in the message exchange. 511 2. The multicaster computes the COSE object as defined in Section 3 512 of this specification. 514 4.2. Verifying the Request 516 Upon receiving a secure group request, a listener endpoint proceeds 517 as described in Section 8.2 of [I-D.ietf-core-object-security], with 518 the following modifications. 520 1. The listener endpoint retrieves the Group Identifier from the 521 'kid context' parameter of the received COSE object. Then, it 522 uses the Group Identifier together with the destination IP 523 address of the group request to identify the correct group's 524 Security Context. 526 2. The listener endpoint retrieves the Sender ID from the "kid" 527 parameter of the received COSE object. Then, the Sender ID is 528 used to retrieve the correct Recipient Context associated to the 529 multicaster endpoint and used to process the group request. When 530 receiving a secure group request message from that multicaster 531 endpoint for the first time, the listener endpoint creates a new 532 Recipient Context, initializes it according to Section 3 of 533 [I-D.ietf-core-object-security], and includes the multicaster 534 endpoint's public key. 536 3. The listener endpoint retrieves the corresponding public key of 537 the multicaster endpoint from the associated Recipient Context. 538 Then, it verifies the counter signature and decrypts the group 539 request. 541 4.3. Protecting the Response 543 A listener endpoint that has received a secure group request may 544 reply with a secure response, which is protected as described in 545 Section 8.3 of [I-D.ietf-core-object-security], with the following 546 modifications. 548 1. The listener endpoint computes the COSE object as defined in 549 Section 3 of this specification. 551 4.4. Verifying the Response 553 Upon receiving a secure response message, a multicaster endpoint 554 proceeds as described in Section 8.4 of 555 [I-D.ietf-core-object-security], with the following modifications. 557 1. The multicaster endpoint retrieves the Security Context by using 558 the Token of the received response message. 560 2. The multicaster endpoint retrieves the Sender ID from the "kid" 561 parameter of the received COSE object. Then, the Sender ID is 562 used to retrieve the correct Recipient Context associated to the 563 listener endpoint and used to process the response message. When 564 receiving a secure response message from that listener endpoint 565 for the first time, the multicaster endpoint creates a new 566 Recipient Context, initializes it according to Section 3 of 567 [I-D.ietf-core-object-security], and includes the listener 568 endpoint's public key. 570 3. The multicaster endpoint retrieves the corresponding public key 571 of the listener endpoint from the associated Recipient Context. 572 Then, it verifies the counter signature and decrypts the response 573 message. 575 The mapping between response messages from listener endpoints and the 576 associated group request from a multicaster endpoint relies on the 577 pair (Sender ID, Partial IV) associated to the secure group request. 578 This is used by listener endpoints as part of the Additional 579 Authenticated Data when protecting their own response message, as 580 described in Section 3. 582 5. Synchronization of Sequence Numbers 584 Upon joining the group, new listeners are not aware of the sequence 585 number values currently used by different multicasters to transmit 586 group requests. This means that, when such listeners receive a 587 secure group request from a given multicaster for the first time, 588 they are not able to verify if that request is fresh and has not been 589 replayed. The same holds when a listener endpoint loses 590 synchronization with sequence numbers of multicasters, for instance 591 after a device reboot. 593 The exact way to address this issue depends on the specific use case 594 and its synchronization requirements. The list of methods to handle 595 synchronization of sequence numbers is part of the group 596 communication policy, and different listener endpoints can use 597 different methods. Appendix E describes three possible approaches 598 that can be considered. 600 6. Responsibilities of the Group Manager 602 The Group Manager is responsible for performing the following tasks: 604 o Creating and managing OSCORE groups. This includes the assignment 605 of a Group ID to every newly created group, as well as ensuring 606 uniqueness of Group IDs within the set of its OSCORE groups. 608 o Defining policies for authorizing the joining of its OSCORE 609 groups. Such policies can be enforced by a third party, which is 610 in a trust relation with the Group Manager and enforces join 611 policies on behalf of the Group Manager. 613 o Driving the join process to add new endpoints as group members. 615 o Establishing Security Common Contexts and providing them to 616 authorized group members during the join process, together with a 617 corresponding Security Sender Context. 619 o Generating and managing Endpoint IDs within its OSCORE groups, as 620 well as assigning and providing them to new endpoints during the 621 join process. This includes ensuring uniqueness of Endpoints IDs 622 within each of its OSCORE groups. 624 o Defining a set of supported signature algorithms as part of the 625 communication policy of each of its OSCORE groups, and signalling 626 it to new endpoints during the join process. 628 o Defining the methods to handle loss of synchronization with 629 sequence numbers as part of the communication policy of each of 630 its OSCORE groups, and signaling the one(s) to use to new 631 endpoints during the join process. 633 o Renewing the Security Context of an OSCORE group upon membership 634 change, by revoking and renewing common security parameters and 635 keying material (rekeying). 637 o Providing the management keying material that a new endpoint 638 requires to participate in the rekeying process, consistently with 639 the key management scheme used in the group joined by the new 640 endpoint. 642 o Updating the Group ID of its OSCORE groups, upon renewing the 643 respective Security Context. 645 The Group Manager may additionally be responsible for the following 646 tasks: 648 o Acting as trusted key repository, in order to store the public 649 keys of the members of its OSCORE groups, and provide such public 650 keys to other members of the same group upon request. This 651 specification recommends that the Group Manager is entrusted to 652 perform this task. 654 o Acting as network router device where endpoints register to 655 correctly receive group messages sent to the multicast IP address 656 of that group. 658 o Autonomously and locally enforcing access policies to authorize 659 new endpoints to join its OSCORE groups. 661 7. Security Considerations 663 The same security considerations from OSCORE (Section 11 of 664 [I-D.ietf-core-object-security]) apply to this specification. 665 Additional security aspects to be taken into account are discussed 666 below. 668 7.1. Group-level Security 670 The approach described in this document relies on commonly shared 671 group keying material to protect communication within a group. This 672 means that messages are encrypted at a group level (group-level data 673 confidentiality), i.e. they can be decrypted by any member of the 674 group, but not by an external adversary or other external entities. 676 In addition, it is required that all group members are trusted, i.e. 677 they do not forward the content of group messages to unauthorized 678 entities. However, in many use cases, the devices in the group 679 belong to a common authority and are configured by a commissioner 680 (see Appendix B). 682 8. IANA Considerations 684 This document has no actions for IANA. 686 9. Acknowledgments 688 The authors sincerely thank Stefan Beck, Rolf Blom, Carsten Bormann, 689 Esko Dijk, Klaus Hartke, Richard Kelsey, John Mattsson, Jim Schaad, 690 Ludwig Seitz and Peter van der Stok for their feedback and comments. 692 The work on this document has been partly supported by the EIT- 693 Digital High Impact Initiative ACTIVE. 695 10. References 697 10.1. Normative References 699 [I-D.ietf-core-object-security] 700 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 701 "Object Security for Constrained RESTful Environments 702 (OSCORE)", draft-ietf-core-object-security-08 (work in 703 progress), January 2018. 705 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 706 Requirement Levels", BCP 14, RFC 2119, 707 DOI 10.17487/RFC2119, March 1997, 708 . 710 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 711 Application Protocol (CoAP)", RFC 7252, 712 DOI 10.17487/RFC7252, June 2014, 713 . 715 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 716 Signature Algorithm (EdDSA)", RFC 8032, 717 DOI 10.17487/RFC8032, January 2017, 718 . 720 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 721 RFC 8152, DOI 10.17487/RFC8152, July 2017, 722 . 724 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 725 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 726 May 2017, . 728 10.2. Informative References 730 [I-D.ietf-ace-dtls-authorize] 731 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 732 L. Seitz, "Datagram Transport Layer Security (DTLS) 733 Profiles for Authentication and Authorization for 734 Constrained Environments (ACE)", draft-ietf-ace-dtls- 735 authorize-02 (work in progress), October 2017. 737 [I-D.ietf-ace-oauth-authz] 738 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 739 H. Tschofenig, "Authentication and Authorization for 740 Constrained Environments (ACE)", draft-ietf-ace-oauth- 741 authz-10 (work in progress), February 2018. 743 [I-D.ietf-ace-oscore-profile] 744 Seitz, L., Palombini, F., and M. Gunnarsson, "OSCORE 745 profile of the Authentication and Authorization for 746 Constrained Environments Framework", draft-ietf-ace- 747 oscore-profile-00 (work in progress), December 2017. 749 [I-D.ietf-core-echo-request-tag] 750 Amsuess, C., Mattsson, J., and G. Selander, "Echo and 751 Request-Tag", draft-ietf-core-echo-request-tag-00 (work in 752 progress), October 2017. 754 [I-D.palombini-ace-key-groupcomm] 755 Palombini, F. and M. Tiloca, "Key Provisioning for Group 756 Communication using ACE", draft-palombini-ace-key- 757 groupcomm-00 (work in progress), March 2018. 759 [I-D.somaraju-ace-multicast] 760 Somaraju, A., Kumar, S., Tschofenig, H., and W. Werner, 761 "Security for Low-Latency Group Communication", draft- 762 somaraju-ace-multicast-02 (work in progress), October 763 2016. 765 [I-D.tiloca-ace-oscoap-joining] 766 Tiloca, M. and J. Park, "Joining of OSCORE multicast 767 groups in ACE", draft-tiloca-ace-oscoap-joining-02 (work 768 in progress), October 2017. 770 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 771 Protocol (GKMP) Specification", RFC 2093, 772 DOI 10.17487/RFC2093, July 1997, 773 . 775 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 776 Protocol (GKMP) Architecture", RFC 2094, 777 DOI 10.17487/RFC2094, July 1997, 778 . 780 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 781 Multicast: Issues and Architectures", RFC 2627, 782 DOI 10.17487/RFC2627, June 1999, 783 . 785 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 786 Thyagarajan, "Internet Group Management Protocol, Version 787 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 788 . 790 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 791 Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004, 792 . 794 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 795 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 796 DOI 10.17487/RFC3810, June 2004, 797 . 799 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 800 "Multicast Security (MSEC) Group Key Management 801 Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, 802 . 804 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 805 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 806 December 2005, . 808 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 809 "GSAKMP: Group Secure Association Key Management 810 Protocol", RFC 4535, DOI 10.17487/RFC4535, June 2006, 811 . 813 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 814 "Transmission of IPv6 Packets over IEEE 802.15.4 815 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 816 . 818 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 819 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 820 . 822 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 823 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 824 DOI 10.17487/RFC6282, September 2011, 825 . 827 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 828 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 829 January 2012, . 831 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 832 RFC 6749, DOI 10.17487/RFC6749, October 2012, 833 . 835 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 836 Constrained-Node Networks", RFC 7228, 837 DOI 10.17487/RFC7228, May 2014, 838 . 840 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 841 the Constrained Application Protocol (CoAP)", RFC 7390, 842 DOI 10.17487/RFC7390, October 2014, 843 . 845 Appendix A. Assumptions and Security Objectives 847 This section presents a set of assumptions and security objectives 848 for the approach described in this document. 850 A.1. Assumptions 852 The following assumptions are assumed to be already addressed and are 853 out of the scope of this document. 855 o Multicast communication topology: this document considers both 856 1-to-N (one multicaster and multiple listeners) and M-to-N 857 (multiple multicasters and multiple listeners) communication 858 topologies. The 1-to-N communication topology is the simplest 859 group communication scenario that would serve the needs of a 860 typical low-power and lossy network (LLN). Examples of use cases 861 that benefit from secure group communication are provided in 862 Appendix B. 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 868 multicasters (normally the controlling devices) is expected to be 869 much smaller than the number of listeners (i.e. the controlled 870 devices). A security solution for group communication that 871 supports 1 to 50 multicasters would be able to properly cover the 872 group sizes required for most use cases that are relevant for this 873 document. The maximum group size is expected to be in the range 874 of 2 to 100 devices. Groups larger than that should be divided 875 into smaller independent groups, e.g. by grouping lights in a 876 building on a per 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 multicaster and 999 listener are configured by the lighting commissioner, and devices 1000 strictly 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 uniquely defined in the set of all the groups 1069 associated to the same Group Manager. The choice of the Group Prefix 1070 for a given group's Security Context is application specific. A 1071 Group Prefix is random, constant over time, and long enough to 1072 achieve a negligible probability of collisions between Group 1073 Identifiers from different Group Managers. The size of the Group 1074 Prefix directly impact on the maximum number of distinct groups under 1075 the same Group Manager. 1077 The Group Epoch is set to 0 upon the group's initialization, and is 1078 incremented by 1 upon completing each renewal of the Security Context 1079 and keying material in the group (see Section 2.1). In particular, 1080 once a new Master Secret has been distributed to the group, all the 1081 group members increment by 1 the Group Epoch in the Group Identifier 1082 of that group. 1084 As an example, a 3-byte Group Identifier can be composed of: i) a 1085 1-byte Group Prefix '0xb1' interpreted as a raw byte string; and ii) 1086 a 2-byte Group Epoch interpreted as an unsigned integer ranging from 1087 0 to 65535. Then, after having established the Security Common 1088 Context 61532 times in the group, its Group Identifier will assume 1089 value '0xb1f05c'. 1091 Appendix D. Set-up of New Endpoints 1093 An endpoint joins a group by explicitly interacting with the 1094 responsible Group Manager. Communications between a joining endpoint 1095 and the Group Manager rely on the CoAP protocol and must be secured. 1096 Specific details on how to secure communications between joining 1097 endpoints and a Group Manager are out of scope. 1099 In order to receive multicast messages sent to the group, a joining 1100 endpoint has to register with a network router device 1101 [RFC3376][RFC3810], signaling its intent to receive packets sent to 1102 the multicast IP address of that group. As a particular case, the 1103 Group Manager can also act as such a network router device. Upon 1104 joining the group, endpoints are not required to know how many and 1105 what endpoints are active in the same group. 1107 Furthermore, in order to participate in the secure group 1108 communication, an endpoint needs to be properly initialized upon 1109 joining the group. In particular, the Group Manager provides keying 1110 material and parameters to a joining endpoint, which can then 1111 initialize its own Security Context (see Section 2). 1113 The following Appendix D.1 provides an example describing how such 1114 information can be provided to an endpoint upon joining a group 1115 through the responsible Group Manager. Then, Appendix D.2 discusses 1116 how public keys of group members can be handled and made available to 1117 group members. Finally, Appendix D.3 overviews how the ACE framework 1118 for Authentication and Authorization in constrained environments 1119 [I-D.ietf-ace-oauth-authz] can be possibly used to support such a 1120 join process. 1122 D.1. Join Process 1124 An endpoint requests to join a group by sending a confirmable CoAP 1125 POST request to the Group Manager responsible for that group. This 1126 join request can reflect the format of the Key Distribution Request 1127 message defined in Section 4.1 of [I-D.palombini-ace-key-groupcomm]. 1128 Besides, it can be addressed to a CoAP resource associated to that 1129 group and carries the following information. 1131 o Group identifier: the Group Identifier (Gid) of the group, as 1132 known to the joining endpoint at this point in time. This may not 1133 fully coincide with the Gid currently associated to the group, 1134 e.g. if it includes a dynamic component. This information can be 1135 mapped to the first element of the "scope" parameter of the Key 1136 Distribution Request message defined in Section 4.1 of 1137 [I-D.palombini-ace-key-groupcomm]. 1139 o Role: the exact role of the joining endpoint in the group. 1140 Possible values are: "multicaster", "listener", "pure listener", 1141 "multicaster and listener", or "multicaster and pure listener". 1142 This information can be mapped to the second element of the 1143 "scope" parameter of the Key Distribution Request message defined 1144 in Section 4.1 of [I-D.palombini-ace-key-groupcomm]. 1146 o Retrieval flag: indication of interest to receive the public keys 1147 of the endpoints currently in the group, as included in the 1148 following join response. This flag must not be present if the 1149 Group Manager is not configured to store the public keys of group 1150 members, or if the joining endpoint is configured exclusively as 1151 pure listener for the group to join. This information can be 1152 mapped to the "get_pub_keys" parameter of the Key Distribution 1153 Request message defined in Section 4.1 of 1154 [I-D.palombini-ace-key-groupcomm]. 1156 o Identity credentials: information elements to enforce source 1157 authentication of group messages from the joining endpoint, such 1158 as its public key. The exact content depends on whether the Group 1159 Manager is configured to store the public keys of group members. 1160 If this is the case, this information is omitted if it has been 1161 provided to the same Group Manager upon previously joining the 1162 same or a different group under its control. This information is 1163 also omitted if the joining endpoint is configured exclusively as 1164 pure listener for the joined group. Appendix D.2 discusses 1165 additional details on provisioning of public keys and other 1166 information to enforce source authentication of joining 1167 endpoints's messages. This information can be mapped to the 1168 "client_cred" parameter of the Key Distribution Request message 1169 defined in Section 4.1 of [I-D.palombini-ace-key-groupcomm]. 1171 The Group Manager must be able to verify that the joining endpoint is 1172 authorized to become a member of the group. To this end, the Group 1173 Manager can directly authorize the joining endpoint, or expect it to 1174 provide authorization evidence previously obtained from a trusted 1175 entity. Appendix D.3 describes how this can be achieved by 1176 leveraging the ACE framework for Authentication and Authorization in 1177 constrained environments [I-D.ietf-ace-oauth-authz]. 1179 In case of successful authorization check, the Group Manager 1180 generates an Endpoint ID assigned to the joining endpoint, before 1181 proceeding with the rest of the join process. Instead, in case the 1182 authorization check fails, the Group Manager aborts the join process. 1183 Further details about the authorization of joining endpoint are out 1184 of scope. 1186 As discussed in Section 2.1, it is recommended that the Security 1187 Context is renewed before the joining endpoint receives the group 1188 keying material and becomes a new active member of the group. This 1189 is achieved by securely distributing a new Master Secret and a new 1190 Group Identifier to the endpoints currently present in the same 1191 group. 1193 Once renewed the Security Context in the group, the Group Manager 1194 replies to the joining endpoint with a CoAP response carrying the 1195 following information. This join response can reflect the format of 1196 the Key Distribution Response message defined in Section 4.2 of 1197 [I-D.palombini-ace-key-groupcomm]. 1199 o Security Common Context: the OSCORE Security Common Context 1200 associated to the joined group (see Section 2). This information 1201 can be mapped to the "key" parameter of the Key Distribution 1202 Response message defined in Section 4.2 of 1203 [I-D.palombini-ace-key-groupcomm]. 1205 o Endpoint ID: the Endpoint ID associated to the joining endpoint. 1206 This information is not included in case "Role" in the join 1207 request is equal to "pure listener". This information can be 1208 mapped to the "clientID" parameter within the "key" parameter of 1209 the Key Distribution Response message defined in Section 4.2 of 1210 [I-D.palombini-ace-key-groupcomm]. 1212 o Member public keys: the public keys of the endpoints currently 1213 present in the group. This includes: the public keys of the non- 1214 pure listeners currently in the group, if the joining endpoint is 1215 configured (also) as multicaster; and the public keys of the 1216 multicasters currently in the group, if the joining endpoint is 1217 configured (also) as listener or pure listener. This information 1218 is omitted in case the Group Manager is not configured to store 1219 the public keys of group members or if the "Retrieval flag" was 1220 not present in the join request. Appendix D.2 discusses 1221 additional details on provisioning public keys upon joining the 1222 group and on retrieving public keys of group members. This 1223 information can be mapped to the "pub_keys" parameter of the Key 1224 Distribution Response message defined in Section 4.2 of 1225 [I-D.palombini-ace-key-groupcomm]. 1227 o Group policies: a list of key words indicating the particular 1228 policies enforced in the group. This includes, for instance, the 1229 list of supported signature algorithms and the method to achieve 1230 synchronization of sequence numbers among group members (see 1231 Appendix E). This information can be mapped to the 1232 "group_policies" parameter of the Key Distribution Response 1233 message defined in Section 4.2 of 1234 [I-D.palombini-ace-key-groupcomm]. 1236 o Management keying material: the set of administrative keying 1237 material used to participate in the group rekeying process run by 1238 the Group Manager (see Section 2.1). The specific elements of 1239 this management keying material depend on the group rekeying 1240 protocol used in the group. For instance, this can simply consist 1241 in a group key encryption key and a pairwise symmetric key shared 1242 between the joining endpoint and the Group Manager, in case GKMP 1243 [RFC2093][RFC2094] is used. Instead, if key-tree based rekeying 1244 protocols like LKH [RFC2627] are used, it can consist in the set 1245 of symmetric keys associated to the key-tree leaf representing the 1246 group member up to the key-tree root representing the group key 1247 encryption key. This information can be mapped to the 1248 "mgt_key_material" parameter of the Key Distribution Response 1249 message defined in Section 4.2 of 1250 [I-D.palombini-ace-key-groupcomm]. 1252 D.2. Provisioning and Retrieval of Public Keys 1254 As mentioned in Section 6, it is recommended that the Group Manager 1255 acts as trusted key repository, so storing public keys of group 1256 members and providing them to other members of the same group upon 1257 request. In such a case, a joining endpoint provides its own public 1258 key to the Group Manager, as "Identity credentials" of the join 1259 request, when joining the group (see Appendix D.1). 1261 After that, the Group Manager should verify that the joining endpoint 1262 actually owns the associated private key, for instance by performing 1263 a proof-of-possession challenge-response, whose details are out of 1264 scope. In case of failure, the Group Manager performs up to a pre- 1265 defined maximum number of retries, after which it aborts the join 1266 process. 1268 In case of successful challenge-response, the Group Manager stores 1269 the received public key as associated to the joining endpoint and its 1270 Endpoint ID. From then on, that public key will be available for 1271 secure and trusted delivery to other endpoints in the group. 1272 Finally, the Group Manager sends the join response to the joining 1273 endpoint, as described in Appendix D.1. 1275 The joining endpoint does not have to provide its own public key if 1276 that already occurred upon previously joining the same or a different 1277 group under the same Group Manager. However, separately for each 1278 group under its control, the Group Manager maintains an updated list 1279 of active Endpoint IDs associated to the respective endpoint's public 1280 key. 1282 Instead, in case the Group Manager does not act as trusted key 1283 repository, the following exchange with the Group Manager can occur 1284 during the join process. 1286 1. The joining endpoint signs its own certificate by using its own 1287 private key. The certificate includes also the identifier of the 1288 issuer Certification Authority (CA). There is no restriction on 1289 the Certificate Subject included in the joining endpoint's 1290 certificate. 1292 2. The joining endpoint specifies the signed certificate as 1293 "Identity credentials" in the join request (Appendix D.1). The 1294 joining endpoint can optionally specify also a list of public key 1295 repositories storing its own certificate. In such a case, this 1296 information can be mapped to the "pub_keys_repos" parameter of 1297 the Key Distribution Request message defined in Section 4.1 of 1298 [I-D.palombini-ace-key-groupcomm]. 1300 3. When processing the join request, the Group Manager first 1301 validates the certificate by verifying the signature of the 1302 issuer CA, and then verifies the signature of the joining 1303 endpoint. 1305 4. The Group Manager stores the association between the Certificate 1306 Subject of the joining endpoint's certificate and the pair {Group 1307 ID, Endpoint ID of the joining endpoint}. If received from the 1308 joining endpoint, the Group Manager also stores the list of 1309 public key repositories storing the certificate of the joining 1310 endpoint. 1312 When a group member X wants to retrieve the public key of another 1313 group member Y in the same group, the endpoint X proceeds as follows. 1315 1. The endpoint X contacts the Group Manager, specifying the pair 1316 {Group ID, Endpoint ID of the endpoint Y}. 1318 2. The Group Manager provides the endpoint X with the Certificate 1319 Subject CS from the certificate of endpoint Y. If available, the 1320 Group Manager provides the endpoint X also with the list of 1321 public key repositories storing the certificate of the endpoint 1322 Y. 1324 3. The endpoint X retrieves the certificate of the endpoint X from a 1325 key repository storing it, by using the Certificate Subject CS. 1327 D.3. Group Joining Based on the ACE Framework 1329 The join process to register an endpoint as a new member of a group 1330 can be based on the ACE framework for Authentication and 1331 Authorization in constrained environments [I-D.ietf-ace-oauth-authz], 1332 built on re-use of OAuth 2.0 [RFC6749]. 1334 In particular, the approach described in 1335 [I-D.tiloca-ace-oscoap-joining] uses the ACE framework to delegate 1336 the authentication and authorization of joining endpoints to an 1337 Authorization Server in a trust relation with the Group Manager. At 1338 the same time, it allows a joining endpoint to establish a secure 1339 channel with the Group Manager, by leveraging protocol-specific 1340 profiles of ACE, such as [I-D.ietf-ace-oscore-profile] and 1341 [I-D.ietf-ace-dtls-authorize], to achieve communication security, 1342 proof-of-possession and server authentication. 1344 More specifically and with reference to the terminology defined in 1345 OAuth 2.0: 1347 o The joining endpoint acts as Client; 1349 o The Group Manager acts as Resource Server, with different CoAP 1350 resources for different groups it is responsible for; 1352 o An Authorization Server enables and enforces authorized access of 1353 the joining endpoint to the Group Manager and its CoAP resources 1354 paired with groups to join. 1356 Messages exchanged among the participants follow the formats defined 1357 in [I-D.palombini-ace-key-groupcomm]. Both the joining endpoint and 1358 the Group Manager have to adopt secure communication also for any 1359 message exchange with the Authorization Server. To this end, 1360 different alternatives are possible, such as OSCORE, DTLS [RFC6347] 1361 or IPsec [RFC4301]. 1363 Appendix E. Examples of Synchronization Approaches 1365 This section describes three possible approaches that can be 1366 considered by listener endpoints to synchronize with sequence numbers 1367 of multicasters. 1369 E.1. Best-Effort Synchronization 1371 Upon receiving a multicast request from a multicaster, a listener 1372 endpoint does not take any action to synchonize with the sequence 1373 number of that multicaster. This provides no assurance at all as to 1374 message freshness, which can be acceptable in non-critical use cases. 1376 E.2. Baseline Synchronization 1378 Upon receiving a multicast request from a given multicaster for the 1379 first time, a listener endpoint initializes its last-seen sequence 1380 number in its Recipient Context associated to that multicaster. 1381 However, the listener drops the multicast request without delivering 1382 it to the application layer. This provides a reference point to 1383 identify if future group requests from the same multicaster are 1384 fresher than the last one received. 1386 A replay time interval exists, between when a possibly replayed 1387 message is originally transmitted by a given multicaster and the 1388 first authentic fresh message from that same multicaster is received. 1389 This can be acceptable for use cases where listener endpoints admit 1390 such a trade-off between performance and assurance of message 1391 freshness. 1393 E.3. Challenge-Response Synchronization 1395 A listener endpoint performs a challenge-response exchange with a 1396 multicaster, by using the Repeat Option for CoAP described in 1397 Section 2 of [I-D.ietf-core-echo-request-tag]. 1399 That is, upon receiving a group request from a particular multicaster 1400 for the first time, the listener processes the message as described 1401 in Section 4.2 of this specification, but, even if valid, does not 1402 deliver it to the application. Instead, the listener replies to the 1403 multicaster with a 4.03 Forbidden response message including a Repeat 1404 Option, and stores the option value included therein. 1406 Upon receiving a 4.03 Forbidden response that includes a Repeat 1407 Option and originates from a verified group member, a multicaster 1408 sends a request as a unicast message addressed to the same listener, 1409 echoing the Repeat Option value. In particular, the multicaster does 1410 not necessarily resend the same group request, but can instead send a 1411 more recent one, if the application permits it. This makes it 1412 possible for the multicaster to not retain previously sent group 1413 requests for full retransmission, unless the application explicitly 1414 requires otherwise. In either case, the multicaster uses the 1415 sequence number value currently stored in its own Sender Context. If 1416 the multicaster stores group requests for possible retransmission 1417 with the Repeat Option, it should not store a given request for 1418 longer than a pre-configured time interval. Note that the unicast 1419 request echoing the Repeat Option is correctly treated and processed 1420 as a group message, since the 'kid context' field including the Group 1421 Identifier of the OSCORE group is still present in the Object- 1422 Security Option as part of the COSE object (see Section 3). 1424 Upon receiving the unicast request including the Repeat Option, the 1425 listener verifies that the option value equals the stored and 1426 previously sent value; otherwise, the request is silently discarded. 1427 Then, the listener verifies that the unicast request has been 1428 received within a pre-configured time interval, as described in 1429 [I-D.ietf-core-echo-request-tag]. In such a case, the request is 1430 further processed and verified; otherwise, it is silently discarded. 1431 Finally, the listener updates the Recipient Context associated to 1432 that multicaster, by setting the Replay Window according to the 1433 Sequence Number from the unicast request conveying the Repeat Option. 1434 The listener either delivers the request to the application if it is 1435 an actual retransmission of the original one, or discards it 1436 otherwise. Mechanisms to signal whether the resent request is a full 1437 retransmission of the original one are out of the scope of this 1438 specification. 1440 In case it does not receive a valid unicast request including the 1441 Repeat Option within the configured time interval, the listener 1442 endpoint should perform the same challenge-response upon receiving 1443 the next multicast request from that same multicaster. 1445 A listener should not deliver group requests from a given multicaster 1446 to the application until one valid request from that same multicaster 1447 has been verified as fresh, as conveying an echoed Repeat Option 1448 [I-D.ietf-core-echo-request-tag]. Also, a listener may perform the 1449 challenge-response described above at any time, if synchronization 1450 with sequence numbers of multicasters is (believed to be) lost, for 1451 instance after a device reboot. It is the role of the application to 1452 define under what circumstances sequence numbers lose 1453 synchronization. This can include a minimum gap between the sequence 1454 number of the latest accepted group request from a multicaster and 1455 the sequence number of a group request just received from the same 1456 multicaster. A multicaster has to be always ready to perform the 1457 challenge-response based on the Repeat Option in case a listener 1458 starts it. 1460 Note that endpoints configured as pure listeners are not able to 1461 perform the challenge-response described above, as they do not store 1462 a Sender Context to secure the 4.03 Forbidden response to the 1463 multicaster. Therefore, pure listeners should adopt alternative 1464 approaches to achieve and maintain synchronization with sequence 1465 numbers of multicasters. 1467 This approach provides an assurance of absolute message freshness. 1468 However, it can result in an impact on performance which is 1469 undesirable or unbearable, especially in large groups where many 1470 endpoints at the same time might join as new members or lose 1471 synchronization. 1473 Appendix F. No Verification of Signatures 1475 There are some application scenarios using group communication that 1476 have particularly strict requirements. One example of this is the 1477 requirement of low message latency in non-emergency lighting 1478 applications [I-D.somaraju-ace-multicast]. For those applications 1479 which have tight performance constraints and relaxed security 1480 requirements, it can be inconvenient for some endpoints to verify 1481 digital signatures in order to assert source authenticity of received 1482 group messages. In other cases, the signature verification can be 1483 deferred or only checked for specific actions. For instance, a 1484 command to turn a bulb on where the bulb is already on does not need 1485 the signature to be checked. In such situations, the counter 1486 signature needs to be included anyway as part of the group message, 1487 so that an endpoint that needs to validate the signature for any 1488 reason has the ability to do so. 1490 In this specification, it is NOT RECOMMENDED that endpoints do not 1491 verify the counter signature of received group messages. However, it 1492 is recognized that there may be situations where it is not always 1493 required. The consequence of not doing the signature validation is 1494 that security in the group is based only on the group-authenticity of 1495 the shared keying material used for encryption. That is, endpoints 1496 in the group have evidence that a received message has been 1497 originated by a group member, although not specifically identifiable 1498 in a secure way. This can violate a number of security requirements, 1499 as the compromise of any element in the group means that the attacker 1500 has the ability to control the entire group. Even worse, the group 1501 may not be limited in scope, and hence the same keying material might 1502 be used not only for light bulbs but for locks as well. Therefore, 1503 extreme care must be taken in situations where the security 1504 requirements are relaxed, so that deployment of the system will 1505 always be done safely. 1507 Authors' Addresses 1508 Marco Tiloca 1509 RISE SICS AB 1510 Isafjordsgatan 22 1511 Kista SE-16440 Stockholm 1512 Sweden 1514 Email: marco.tiloca@ri.se 1516 Goeran Selander 1517 Ericsson AB 1518 Torshamnsgatan 23 1519 Kista SE-16440 Stockholm 1520 Sweden 1522 Email: goran.selander@ericsson.com 1524 Francesca Palombini 1525 Ericsson AB 1526 Torshamnsgatan 23 1527 Kista SE-16440 Stockholm 1528 Sweden 1530 Email: francesca.palombini@ericsson.com 1532 Jiye Park 1533 Universitaet Duisburg-Essen 1534 Schuetzenbahn 70 1535 Essen 45127 1536 Germany 1538 Email: ji-ye.park@uni-due.de