idnits 2.17.1 draft-tiloca-core-multicast-oscoap-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 13, 2017) is 2600 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-01 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-05 == Outdated reference: A later version (-06) exists of draft-seitz-ace-oscoap-profile-01 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-04 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 5 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 14, 2017 F. Palombini 6 Ericsson AB 7 March 13, 2017 9 Secure group communication for CoAP 10 draft-tiloca-core-multicast-oscoap-01 12 Abstract 14 This document describes a method for application layer protection of 15 messages exchanged with the Constrained Application Protocol (CoAP) 16 in a group communication context. The proposed approach relies on 17 Object Security of CoAP (OSCOAP) and the CBOR Object Signing and 18 Encryption (COSE) format. All security requirements fulfilled by 19 OSCOAP are maintained for multicast CoAP request messages and related 20 unicast CoAP response messages. Source authentication of all 21 messages exchanged within the group is ensured, by means of digital 22 signatures produced through asymmetric private keys of sender devices 23 and embedded in the protected CoAP messages. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 14, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Scope Description . . . . . . . . . . . . . . . . . . . . . . 7 63 4. Security Context . . . . . . . . . . . . . . . . . . . . . . 8 64 5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 9 65 6. Message Processing . . . . . . . . . . . . . . . . . . . . . 10 66 6.1. Protecting the Request . . . . . . . . . . . . . . . . . 10 67 6.2. Verifying the Request . . . . . . . . . . . . . . . . . . 10 68 6.3. Protecting the Response . . . . . . . . . . . . . . . . . 11 69 6.4. Verifying the Response . . . . . . . . . . . . . . . . . 11 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 7.1. Group-level Security . . . . . . . . . . . . . . . . . . 12 72 7.2. Management of Group Keying Material . . . . . . . . . . . 12 73 7.3. Late Joining Endpoints . . . . . . . . . . . . . . . . . 13 74 7.4. Provisioning of Public Keys . . . . . . . . . . . . . . . 13 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 79 10.2. Informative References . . . . . . . . . . . . . . . . . 15 80 Appendix A. Group Joining Based on the ACE Framework . . . . . . 16 81 Appendix B. List of Use Cases . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 The Constrained Application Protocol (CoAP) [RFC7252] is a web 87 transfer protocol specifically designed for constrained devices and 88 networks. 90 [RFC7390] enables group communication for CoAP, addressing use cases 91 where deployed devices benefit from a group communication model for 92 example to limit latencies and improve performance. Use cases 93 include lighting control, integrated building control, software and 94 firmware updates, parameter and configuration updates, commissioning 95 of constrained networks, and emergency multicast. [RFC7390] 96 recognizes the importance to introduce a secure mode for CoAP group 97 communication. This specification defines such a mode. 99 Object Security of CoAP (OSCOAP)[I-D.ietf-core-object-security] 100 describes a security protocol based on the exchange of protected CoAP 101 messages. OSCOAP builds on CBOR Object Signing and Encryption (COSE) 102 [I-D.ietf-cose-msg] and provides end-to-end encryption, integrity, 103 and replay protection across intermediate modes. To this end, a CoAP 104 message is protected by including payload (if any), certain options, 105 and header fields in a COSE object, which finally replaces the 106 authenticated and encrypted fields in the protected message. 108 This document describes multicast OSCOAP, providing end-to-end 109 security of CoAP messages exchanged between members of a multicast 110 group. In particular, the described approach defines how OSCOAP 111 should be used in a group communication context, while fulfilling the 112 same security requirements. That is, end-to-end security is assured 113 for multicast CoAP requests sent by multicaster nodes to the group 114 and for related unicast CoAP responses sent as reply by multiple 115 listener nodes. Multicast OSCOAP provides source authentication of 116 all CoAP messages exchanged within the group, by means of digital 117 signatures produced through asymmetric private keys of sender devices 118 and embedded in the protected CoAP messages. As in OSCOAP, it is 119 still possible to simultaneously rely on DTLS to protect hop-by-hop 120 communication between a multicaster node and a proxy (and vice 121 versa), and between a proxy and a listener node (and vice versa). 123 1.1. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. These 128 words may also appear in this document in lowercase, absent their 129 normative meanings. 131 Readers are expected to be familiar with the terms and concepts 132 described in [RFC7252], [RFC7390] and [RFC7641]. 134 Terminology for constrained environments, such as "constrained 135 device", "constrained-node network", is defined in [RFC7228]. 137 Terminology for protection and processing of CoAP messages through 138 OSCOAP, such as "Security Context", "Master Secret", "Master Salt", 139 is defined in [I-D.ietf-core-object-security]. 141 This document refers also to the following terminology. 143 o Keying material: data that is necessary to establish and maintain 144 secure communication among member of a multicast group. This 145 includes, for instance, keys, key pairs, and IVs [RFC4949]. 147 o Group Manager (GM): entity responsible for creating a multicast 148 group, establishing and provisioning security contexts among 149 authorized group members, and managing the joining of new group 150 members. A GM can be responsible for multiple multicast groups, 151 while it is not required to be an actual group member and to take 152 part in the group communication. The GM may also be responsible 153 for renewing/updating security contexts and related keying 154 material. Any message exchange with the GM MUST be secured and 155 based on different secure channels for different endpoints. 157 o Multicaster: member of a multicast group that sends multicast CoAP 158 messagges intended for all members of the group. In a 1-to-N 159 multicast group, only a single multicaster transmits data to the 160 group; in an M-to-N multicast group (where M and N do not 161 necessarily have the same value), M group members are 162 multicasters. 164 o Listener: member of a multicast group that receives multicast CoAP 165 messages when listening to the multicast IP address associated to 166 the multicast group. A listener MAY reply back, by sending a 167 unicast response message to the multicaster which has sent the 168 multicast message. 170 o Group request: multicast CoAP request message sent by a 171 multicaster in the group to all listeners in the group through 172 multicast IP. 174 o Group response: unicast CoAP response message sent back by a 175 listener in the group as a response to a group request received 176 from a multicaster. 178 o Source authentication: evidence that a received message in the 179 group originated from a specifically identified group member. 180 This also provides assurances that the message was not tampered 181 with by any other group member or an adversary outside the group. 183 2. Requirements 185 The following security requirements are out of the scope of this 186 document and are assumed to be already fulfilled. 188 o Establishment and management of a security context: a security 189 context must be established among the group members by the Group 190 Manager which manages the multicast group. A secure mechanism 191 must be used to generate, revoke and (re-)distribute keying 192 material, multicast security policies and security parameters in 193 the multicast group. The actual establishment and management of 194 the security context is out of the scope of this document, and it 195 is anticipated that an activity in IETF dedicated to the design of 196 a generic key management scheme will include this feature, 197 preferably based on [RFC3740][RFC4046][RFC4535]. 199 o Multicast data security ciphersuite: all group members MUST agree 200 on a ciphersuite to provide authenticity, integrity and 201 confidentiality of messages in the multicast group. The 202 ciphersuite is specified as part of the security context. 204 o Backward security: a new device joining the multicast group should 205 not have access to any old security contexts used before its 206 joining. This ensures that a new group member is not able to 207 decrypt confidential data sent before it has joined the group. 208 The adopted key management scheme should ensure that the security 209 context is updated to ensure backward confidentiality. The actual 210 mechanism to update the security context and renew the group 211 keying material upon a group member's joining has to be defined as 212 part of the group key management scheme. 214 o Forward security: entities that leave the multicast group should 215 not have access to any future security contexts or message 216 exchanged within the group after their leaving. This ensures that 217 a former group member is not able to decrypt confidential data 218 sent within the group anymore. Also, it ensures that a former 219 member is not able to send encrypted and/or integrity protected 220 messages to the group anymore. The actual mechanism to update the 221 security context and renew the group keying material upon a group 222 member's leaving has to be defined as part of the group key 223 management scheme. 225 The following security requirements need to be fulfilled by the 226 approach described in this document: 228 o Multicast communication topology: this document considers both 229 1-to-N (one multicaster and multiple listeners) and M-to-N 230 (multiple multicasters and multiple listeners) communication 231 topologies. The 1-to-N communication topology is the simplest 232 group communication scenario that would serve the needs of a 233 typical LLN. For instance, in the lighting control use case, 234 switches are the only entities responsible for sending commands to 235 a group of lighting devices. In more advanced lighting control 236 use cases, a M-to-N communication topology would be required, for 237 instance in case multiple sensors (presence or day-light) are 238 responsible to trigger events to a group of lighting devices. 240 o Multicast group size: security solutions for group communication 241 SHOULD be able to adequately support different, possibly large, 242 group sizes. Group size is the combination of the number of 243 multicasters and listeners in a multicast group, with possible 244 overlap (i.e. a multicaster MAY also be a listener at the same 245 time). In the use cases mentioned in this document, the number of 246 multicasters (normally the controlling devices) is expected to be 247 much smaller than the number of listeners (i.e. the controlled 248 devices). A security solution for group communication that 249 supports 1 to 50 multicasters would be able to properly cover the 250 group sizes required for most use cases that are relevant for this 251 document. The total number of group members is expected to be in 252 the range of 2 to 100 devices. Groups larger than that SHOULD be 253 divided into smaller independent multicast groups, e.g. by 254 grouping lights in a building on a per floor basis. 256 o Data replay protection: it MUST NOT be possible to replay a group 257 request message or a group response message, which would disrupt 258 the correct communication in the group and the activity of group 259 members. 261 o Group-level data confidentiality: messages sent within the 262 multicast group SHALL be encrypted. In fact, some control 263 commands and/or associated responses could pose unforeseen 264 security and privacy risks to the system users, when sent as 265 plaintext. In particular, data confidentiality MAY be required if 266 privacy sensitive data is exchanged in the group. This document 267 considers group-level data confidentiality since messages are 268 encrypted at a group level, i.e. in such a way that they can be 269 decrypted by any member of the multicast group, but not by an 270 external adversary or other external entities. 272 o Source authentication: messages sent within the multicast group 273 SHALL be authenticated. That is, it is essential to ensure that a 274 message is originated by a member of the group in the first place 275 (group authentication), and in particular by a specific member of 276 the group (source authentication). The approach proposed in this 277 document provides both group authentication and source 278 authentication, both for group requests originated by multicasters 279 and group responses originated by listeners. In order to provide 280 source authentication, outgoing messages are signed by the 281 respective originator group member by means of its own asymmetric 282 private key. The resulting signature is included in the COSE 283 object. 285 o Message integrity: messages sent within the multicast group SHOULD 286 be integrity protected. That is, it is essential to ensure that a 287 message has not been tampered with by an external adversary or 288 other external entities which are not group members. Message 289 integrity is provided through the same means used to provide 290 source authentication. 292 3. Scope Description 294 An endpoint joins a multicast group by explicitly interacting with 295 the responsible Group Manager. The actual join process MAY be based 296 on the ACE framework [I-D.ietf-ace-oauth-authz] and the OSCOAP 297 profile of ACE [I-D.seitz-ace-oscoap-profile], as discussed in 298 Appendix A. 300 An endpoint registered as member of a group can behave as a 301 multicaster and/or as a listener. As a multicaster, it can transmit 302 multicast request messages to the group. As a listener, it receives 303 multicast request messages from any multicaster in the group, and 304 possibly replies by transmitting unicast response messages. A number 305 of use cases that benefit from secure group communication are 306 discussed in Appendix B. Upon joining the group, endpoints are not 307 required to know how many and what endpoints are active in the same 308 group. 310 An endpoint which is registered as member of a group is identified by 311 an endpoint ID, which is not necessarily related to any protocol- 312 relevant identifiers, such as IP addresses. The Group Manager 313 generates and manages endpoint IDs in order to ensure their 314 uniqueness within a same multicast group. That is, there cannot be 315 multiple endpoints that belong to the same group and are associated 316 to a same endpoint ID. 318 In order to participate in the secure group communication, an 319 endpoint needs to maintain additional information elements, stored in 320 its own security context. Those include keying material used to 321 protect and verify group messages, as well as the public keys of 322 other endpoints in the groups, in order to verify digital signatures 323 of secure messages and ensure their source authenticity. These 324 pieces of information are provided by the Group Manager through out- 325 of-band means or other pre-established secure channels. Further 326 details about establishment, revocation and renewal of the security 327 context and keying material are out of the scope of this document. 329 According to [RFC7390], any possible proxy entity is supposed to know 330 about the multicasters in the group and to not perform aggregation of 331 response messages. Also, every multicaster expects and is able to 332 handle multiple unicast response messages associated to a given 333 multicast request message. 335 4. Security Context 337 To support multicast communication secured with OSCOAP, each endpoint 338 registered as member of a multicast group maintains a Security 339 Context as defined in Section 3 of [I-D.ietf-core-object-security]. 340 In particular, each endpoint in a group stores: 342 1. one Common Context, received from the Group Manager upon joining 343 the multicast group and shared by all the endpoints in the group. 344 The Common Context contains the COSE AEAD algorithm, the Master 345 Secret and, optionally, the Master Salt used to derive endpoint- 346 based keying material (see Section 3.2 of 347 [I-D.ietf-core-object-security]). All the endpoints in the group 348 agree on the same COSE AEAD algorithm. Besides, in addition to 349 what is defined in [I-D.ietf-core-object-security], the Common 350 Context stores the following parameters: 352 * Context Identifier (Cid). Variable length byte string that 353 identifies the Security Context. The Cid used in a multicast 354 group is determined by the responsible Group Manager and does 355 not change over time. A Cid MUST be unique in the sets of all 356 the multicast groups associated to the same Group Manager. 357 The choice of the Cid for a given group's Security Context is 358 application specific, but it is RECOMMENDED to use 64-bit long 359 pseudo-random Cids, in order to have globally unique Context 360 Identifiers. It is the role of the application to specify how 361 to handle possible collisions. 363 * Counter signature algorithm. Value that identifies the 364 algorithm used for source authenticating messages sent within 365 the group. Its value is immutable once the security context 366 is established. All the endpoints in the group agree on the 367 same counter signature algorithm. 369 2. one Sender Context, used to secure outgoing messages. In 370 particular, the Sender Context is initialized according to 371 Section 3 of [I-D.ietf-core-object-security], once the endpoint 372 has joined the multicast group. Besides, in addition to what is 373 defined in [I-D.ietf-core-object-security], the Sender Context 374 stores also the endpoint's asymmetric public-private key pair; 376 3. one Recipient Context for each distinct endpoint from which 377 messages are received, used to process such incoming secure 378 messages. The endpoint creates a new Recipient Context upon 379 receiving an incoming message from another endpoint in the group 380 for the first time. Besides, in addition to what is defined in 381 [I-D.ietf-core-object-security], each Recipient Context stores 382 also the public key of the associated other endpoint from which 383 secure messages are received. Possible approaches to provision 384 and retrieve public keys of group members are discussed in 385 Section 7.4. 387 The Sender Key/IV stored in the Sender Context and the Recipient 388 Keys/IVs stored in the Recipient Contexts are derived according to 389 the same scheme defined in Section 3.2 of 390 [I-D.ietf-core-object-security]. 392 The 3-tuple (Cid, Sender ID, Partial IV) is called Transaction 393 Identifier (Tid), and SHALL be unique for each Master Secret. The 394 Tid is used as a unique challenge in the COSE object of the protected 395 CoAP request. The Tid is part of the Additional Authenticated Data 396 (AAD, see Section of 5.2 of [I-D.ietf-core-object-security]) of the 397 protected CoAP response message, which is how unicast responses are 398 bound to multicast requests. 400 5. The COSE Object 402 When creating a protected CoAP message, an endpoint in the group 403 computes the COSE object as defined in Section 5 of 404 [I-D.ietf-core-object-security], with the following modifications. 406 1. The value of the "Partial IV" parameter in the "protected" field 407 is set to the Sequence Number and SHALL be present in both 408 multicast requests and unicast responses. Specifically, a 409 multicaster endpoint sets the value of "Partial IV" to the 410 Sequence Number from its own Sender Context, upon sending a 411 multicast request message. Similarly, a listener endpoint sets 412 the value of "Partial IV" to the Sequence Number from its own 413 Sender Context, upon sending a unicast response message. 415 2. The value of the "kid" parameter in the "protected" field is set 416 to the Sender ID of the endpoint and SHALL be present in both 417 multicast requests and unicast responses. 419 3. The "protected" field of the "Headers" field SHALL include also 420 the following parameter: 422 * gid : its value is set to the Context Identifier (Cid) of the 423 group's Security Context. This parameter is optional if the 424 message is a CoAP response. 426 4. The Additional Authenticated Data (AAD) considered to compute the 427 COSE object is extended. In particular, the "external_aad" 428 considered for secure response messages SHALL include also the 429 following parameter: 431 * cid : bstr, contains the Context Idenfier (Cid) of the 432 Security Context considered to protect the request message 433 (which is same as the Cid considered to protect the response 434 message). 436 5. Before transmitting any secure CoAP message, the sender endpoint 437 uses its own private key to create a counter signature of the 438 COSE_Encrypt0 object (Appendix C.4 of [I-D.ietf-cose-msg]). 439 Then, the counter signature is included in the Header of the COSE 440 object in its "unprotected" field. 442 6. Message Processing 444 Each multicast request message and unicast response message is 445 protected and processed as specified in 446 [I-D.ietf-core-object-security], with the modifications described in 447 the following sections. Furthermore, error handling and processing 448 of invalid messages are performed according to the same principles 449 adopted in [I-D.ietf-core-object-security]. 451 6.1. Protecting the Request 453 A multicaster endpoint transmits a secure multicast request message 454 as described in Section 7.1 of [I-D.ietf-core-object-security], with 455 the following modifications: 457 1. The multicaster endpoint stores the association Token - Cid. That 458 is, it SHALL be able to find the correct Security Context used to 459 protect the multicast request and verify the unicast response(s) 460 by using the CoAP Token considered in the message exchange. 462 2. The multicaster endpoint computes the COSE object as defined in 463 Section 5 of this specification. 465 6.2. Verifying the Request 467 Upon receiving a secure multicast request message, a listener 468 endpoint proceeds as described in Section 7.2 of 469 [I-D.ietf-core-object-security], with the following modifications: 471 1. The listener endpoint retrieves the Context Identifier from the 472 "gid" parameter of the received COSE object, and uses it to 473 identify the correct group's Security Context. 475 2. The listener endpoint retrieves the Sender ID from the header of 476 the COSE object. Then, the Sender ID is used to retrieve the 477 correct Recipient Context associated to the multicaster endpoint 478 and used to process the request message. When receiving a secure 479 multicast CoAP request message from that multicaster endpoint for 480 the first time, the listener endpoint creates a new Recipient 481 Context, initializes it according to Section 3 of 482 [I-D.ietf-core-object-security], and includes the multicaster 483 endpoint's public key. 485 3. The listener endpoint retrieves the corresponding public key of 486 the multicaster endpoint from the associated Recipient Context 487 and uses it to verify the counter signature, before proceeding 488 with the verification and decryption of the secure request 489 message. 491 6.3. Protecting the Response 493 A listener endpoint that has received a multicast request message MAY 494 reply with a secure unicast response message, which is protected as 495 described in Section 7.3 of [I-D.ietf-core-object-security], with the 496 following modifications: 498 1. The listener endpoint considers the Transaction Identifier (Tid) 499 as defined in Section 4 of this specification. 501 2. The listener endpoint computes the COSE object as defined in 502 Section 5 of this specification. 504 6.4. Verifying the Response 506 Upon receiving a secure unicast response message, a multicaster 507 endpoint proceeds as described in Section 7.4 of 508 [I-D.ietf-core-object-security], with the following modifications: 510 1. The multicaster endpoint considers the Security Context 511 identified by the Token of the received response message. 513 2. The multicaster endpoint retrieves the Sender ID from the header 514 of the COSE object. Then, the Sender ID is used to retrieve the 515 correct Recipient Context associated to the listener endpoint and 516 used to process the response message. When receiving a secure 517 CoAP response message from that listener endpoint for the first 518 time, the multicaster endpoint creates a new Recipient Context, 519 initializes it according to Section 3 of 520 [I-D.ietf-core-object-security], and includes the listener 521 endpoint's public key. 523 3. The multicaster endpoint retrieves the corresponding public key 524 of the listener endpoint from the associated Recipient Context 525 and uses it to verify the counter signature, before proceeding 526 with the verification and decryption of the secure response 527 message. 529 The mapping between unicast response messages from listener endpoints 530 and the associated multicast request message from a multicaster 531 endpoint relies on the same principle adopted in 532 [I-D.ietf-core-object-security]. That is, it is based on the 533 Transaction Identifier (Tid) associated to the secure multicast 534 request message, which is considered by listener endpoints as part of 535 the Additional Authenticated Data when protecting their own response 536 message. 538 7. Security Considerations 540 Specific security aspects to be taken into account are discussed 541 below. 543 7.1. Group-level Security 545 The approach described in this document relies on commonly shared 546 group keying material to protect communication within a multicast 547 group. This means that messages are encrypted at a group level 548 (group-level data confidentiality), i.e. they can be decrypted by any 549 member of the multicast group, but not by an external adversary or 550 other external entities. 552 In addition, it is required that all group members are trusted, i.e. 553 they do not forward the content of group messages to unauthorized 554 entities. However, in many use cases, the devices in the multicast 555 group belong to a common authority and are configured by a 556 commissioner. For instance, in a professional lighting scenario, the 557 roles of multicaster and listener are configured by the lighting 558 commissioner, and devices strictly follow those roles. 560 Furthermore, the presented approach SHOULD take into consideration 561 the risk of compromise of group members. Such a risk is reduced when 562 multicast groups are deployed in physically secured locations, like 563 lighting inside office buildings. The adoption of key management 564 schemes for secure revocation and renewal of security contexts group 565 keying material SHOULD be considered. 567 7.2. Management of Group Keying Material 569 As stated in Section 2, it is important to adopt a group key 570 management scheme that SHOULD update the security context and keying 571 material in the group, before a new endpoint joins the group or after 572 a currently present endpoint leaves the group. This is necessary in 573 order to preserve backward confidentiality and forward 574 confidentiality in the multicast group. 576 Especially in dynamic, large-scale, multicast groups where endpoints 577 can join and leave at any time, it is important that the considered 578 group key management scheme is efficient and highly scalable with the 579 group size, in order to limit the impact on performance due to the 580 security context and keying material update. 582 7.3. Late Joining Endpoints 584 Upon joining the multicast group when the system is fully operative, 585 listeners are not aware of the current sequence number values used by 586 different multicasters to transmit multicast request messages. This 587 means that, when such listeners receive a secure multicast message 588 from a multicaster, they are not able to verify if that message is 589 fresh and has not been replayed. 591 In order to address this issue, upon receiving a multicast message 592 from a particular multicaster for the first time, late joining 593 listeners can initialize their last-seen sequence number in their 594 Recipient Context associated to that multicaster. However, after 595 that they drop the message, without delivering it to the application 596 layer. This provides a reference point to identify if future 597 multicast messages from the same multicaster are fresher than the 598 last one seen. As an alternative, a late joining listener can 599 directly contact the multicaster, and explicitly request a 600 confirmation of the sequence number in the first received multicast 601 message. 603 A possible different approach considers the GM as an additional 604 listener in the multicast group. Then, the GM can maintain the 605 sequence number values of each multicaster in the group. When late 606 joiners send a request to the GM to join the group, the GM can 607 provide them with the list of sequence number values to be stored in 608 the Recipient Contexts associated to the appropriate multicasters. 610 7.4. Provisioning of Public Keys 612 Upon receiving a secure CoAP message, a recipient endpoint relies on 613 the sender endpoint's public key, in order to verify the counter 614 signature conveyed in the COSE Object. 616 If not already stored in the Recipient Context associated to the 617 sender endpoint, the recipient endpoint retrieves the public key from 618 a trusted key repository. In such a case, the correct binding 619 between the sender endpoint and the retrieved public key MUST be 620 assured, for instance by means of public key certificates. Further 621 details about how this requirement can be fulfilled are out of the 622 scope of this document. 624 Alternatively, the Group Manager can be configured to store public 625 keys of group members and provide them upon request. In such a case, 626 upon joining a multicast group, an endpoint provides the Group 627 Manager with its own public key, by means of the same secure channel 628 used to carry out the join procedure. After that, the Group Manager 629 MUST perform a proof-of-possession challenge-response with the 630 joining endpoint, in order to verify that it actually owns the 631 associated private key. In case of success, the Group Manager stores 632 the received public key as associated to the joining endpoint and its 633 endpoint ID. From then on, that public key will be available for 634 secure and trusted delivery to other endpoints in the multicast 635 group. 637 Note that in simple, less dynamic, multicast groups, it can be 638 convenient for the Group Manager to provide an endpoint upon its 639 joining with the public keys associated to all endpoints currently 640 present in the group. 642 8. IANA Considerations 644 This document has no actions for IANA. 646 9. Acknowledgments 648 The authors sincerely thank Rolf Blom, Carsten Bormann, John Mattsson 649 and Jim Schaad for their feedback and comments. 651 10. References 653 10.1. Normative References 655 [I-D.ietf-core-object-security] 656 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 657 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 658 object-security-01 (work in progress), December 2016. 660 [I-D.ietf-cose-msg] 661 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 662 draft-ietf-cose-msg-24 (work in progress), November 2016. 664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 665 Requirement Levels", BCP 14, RFC 2119, 666 DOI 10.17487/RFC2119, March 1997, 667 . 669 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 670 Application Protocol (CoAP)", RFC 7252, 671 DOI 10.17487/RFC7252, June 2014, 672 . 674 [RFC7641] Hartke, K., "Observing Resources in the Constrained 675 Application Protocol (CoAP)", RFC 7641, 676 DOI 10.17487/RFC7641, September 2015, 677 . 679 10.2. Informative References 681 [I-D.ietf-ace-oauth-authz] 682 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 683 H. Tschofenig, "Authentication and Authorization for 684 Constrained Environments (ACE)", draft-ietf-ace-oauth- 685 authz-05 (work in progress), February 2017. 687 [I-D.seitz-ace-oscoap-profile] 688 Seitz, L. and F. Palombini, "OSCOAP profile of ACE", 689 draft-seitz-ace-oscoap-profile-01 (work in progress), 690 October 2016. 692 [I-D.selander-ace-cose-ecdhe] 693 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 694 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 695 cose-ecdhe-04 (work in progress), October 2016. 697 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 698 Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004, 699 . 701 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 702 "Multicast Security (MSEC) Group Key Management 703 Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, 704 . 706 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 707 "GSAKMP: Group Secure Association Key Management 708 Protocol", RFC 4535, DOI 10.17487/RFC4535, June 2006, 709 . 711 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 712 "Transmission of IPv6 Packets over IEEE 802.15.4 713 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 714 . 716 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 717 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 718 . 720 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 721 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 722 DOI 10.17487/RFC6282, September 2011, 723 . 725 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 726 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 727 January 2012, . 729 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 730 RFC 6749, DOI 10.17487/RFC6749, October 2012, 731 . 733 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 734 Constrained-Node Networks", RFC 7228, 735 DOI 10.17487/RFC7228, May 2014, 736 . 738 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 739 the Constrained Application Protocol (CoAP)", RFC 7390, 740 DOI 10.17487/RFC7390, October 2014, 741 . 743 Appendix A. Group Joining Based on the ACE Framework 745 The join process to register an endpoint as a new member of a 746 multicast group MAY be based on the ACE framework 747 [I-D.ietf-ace-oauth-authz] and the OSCOAP profile of ACE 748 [I-D.seitz-ace-oscoap-profile]. With reference to the terminology 749 defined in OAuth 2.0 [RFC6749]: 751 o The joining endpoint acts as Client; 753 o The Group Manager acts as Resource Server, exporting one join- 754 resource for each multicast group it is responsible for; 756 o An Authorization Server enables and enforces authorized access of 757 the joining endpoint to the Group Manager and its join-resources. 759 Then, in accordance with [I-D.seitz-ace-oscoap-profile], the joining 760 endpoint and the Group Manager rely on OSCOAP 761 [I-D.ietf-core-object-security] for secure communication and consider 762 Ephemeral Diffie-Hellman Over COSE (EDHOC) 764 [I-D.selander-ace-cose-ecdhe] as a possible method to establish key 765 material. 767 The joining endpoint sends to the Group Manager an OSCOAP request to 768 access the join-resource associated to the multicast group to join. 769 The Group Manager replies with an OSCOAP response including the 770 Common Context associated to that group (see Section 4). In case the 771 Group Manager is configured to store the public keys of group 772 members, the joining endpoint additionally provides the Group Manager 773 with its own public key, and MAY request from the Group Manager the 774 public keys of the endpoints currently present in the group (see 775 Section 7.4). 777 Both the joining endpoint and the Group Manager MUST adopt secure 778 communication also for any message exchange with the Authorization 779 Server. To this end, different alternatives are possible, including 780 OSCOAP and DTLS [RFC6347]. 782 Appendix B. List of Use Cases 784 Group Communication for CoAP [RFC7390] provides the necessary 785 background for multicast-based CoAP communication, with particular 786 reference to low-power and lossy networks (LLNs) and resource 787 constrained environments. The interested reader is encouraged to 788 first read [RFC7390] to understand the non-security related details. 789 This section discusses a number of use cases that benefit from secure 790 group communication. Specific security requirements for these use 791 cases are discussed in Section 2. 793 o Lighting control: consider a building equipped with IP-connected 794 lighting devices, switches, and border routers. The devices are 795 organized into groups according to their physical location in the 796 building. For instance, lighting devices and switches in a room 797 or corridor can be configured as members of a single multicast 798 group. Switches are then used to control the lighting devices by 799 sending on/off/dimming commands to all lighting devices in a 800 group, while border routers connected to an IP network backbone 801 (which is also multicast-enabled) can be used to interconnect 802 routers in the building. Consequently, this would also enable 803 logical multicast groups to be formed even if devices in the 804 lighting group may be physically in different subnets (e.g. on 805 wired and wireless networks). Connectivity between ligthing 806 devices may be realized, for instance, by means of IPv6 and 807 (border) routers supporting 6LoWPAN [RFC4944][RFC6282]. Group 808 communication enables synchronous operation of a group of 809 connected lights, ensuring that the light preset (e.g. dimming 810 level or color) of a large group of luminaires are changed at the 811 same perceived time. This is especially useful for providing a 812 visual synchronicity of light effects to the user. Devices may 813 reply back to the switches that issue on/off/dimming commands, in 814 order to report about the execution of the requested operation 815 (e.g. OK, failure, error) and their current operational status. 817 o Integrated building control: enabling Building Automation and 818 Control Systems (BACSs) to control multiple heating, ventilation 819 and air-conditioning units to pre-defined presets. Controlled 820 units can be organized into multicast groups in order to reflect 821 their physical position in the building, e.g. devices in the same 822 room can be configured as members of a single multicast group. 823 Furthermore, controlled units are expected to possibly reply back 824 to the BACS issuing control commands, in order to report about the 825 execution of the requested operation (e.g. OK, failure, error) 826 and their current operational status. 828 o Software and firmware updates: software and firmware updates often 829 comprise quite a large amount of data. Therefore, it can overload 830 a LLN that is otherwise typically used to deal with only small 831 amounts of data, on an infrequent base. Rather than sending 832 software and firmware updates as unicast messages to each 833 individual device, multicasting such updated data to a larger 834 group of devices at once displays a number of benefits. For 835 instance, it can significantly reduce the network load and 836 decrease the overall time latency for propagating this data to all 837 devices. Even if the complete whole update process itself is 838 secured, securing the individual messages is important, in case 839 updates consist of relatively large amounts of data. In fact, 840 checking individual received data piecemeal for tampering avoids 841 that devices store large amounts of partially corrupted data and 842 that they detect tampering hereof only after all data has been 843 received. Devices receiving software and firmware updates are 844 expected to possibly reply back, in order to provide a feedback 845 about the execution of the update operation (e.g. OK, failure, 846 error) and their current operational status. 848 o Parameter and configuration update: by means of multicast 849 communication, it is possible to update the settings of a group of 850 similar devices, both simultaneously and efficiently. Possible 851 parameters are related, for instance, to network load management 852 or network access controls. Devices receiving parameter and 853 configuration updates are expected to possibly reply back, to 854 provide a feedback about the execution of the update operation 855 (e.g. OK, failure, error) and their current operational status. 857 o Commissioning of LLNs systems: a commissioning device is 858 responsible for querying all devices in the local network or a 859 selected subset of them, in order to discover their presence, and 860 be aware of their capabilities, default configuration, and 861 operating conditions. Queried devices displaying similarities in 862 their capabilities and features, or sharing a common physical 863 location can be configured as members of a single multicast group. 864 Queried devices are expected to reply back to the commissioning 865 device, in order to notify their presence, and provide the 866 requested information and their current operational status. 868 o Emergency multicast: a particular emergency related information 869 (e.g. natural disaster) is generated and multicast by an emergency 870 notifier, and relayed to multiple devices. The latters may reply 871 back to the emergency notifier, in order to provide their feedback 872 and local information related to the ongoing emergency. 874 Authors' Addresses 876 Marco Tiloca 877 RISE SICS AB 878 Isafjordsgatan 22 879 Kista SE-16440 Stockholm 880 Sweden 882 Email: marco.tiloca@ri.se 884 Goeran Selander 885 Ericsson AB 886 Farogatan 6 887 Kista SE-16480 Stockholm 888 Sweden 890 Email: goran.selander@ericsson.com 892 Francesca Palombini 893 Ericsson AB 894 Farogatan 6 895 Kista SE-16480 Stockholm 896 Sweden 898 Email: francesca.palombini@ericsson.com