idnits 2.17.1 draft-tiloca-core-multicast-oscoap-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2017) is 2372 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) == Unused Reference: 'I-D.ietf-ace-dtls-authorize' is defined on line 740, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-06 ** 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 (-01) exists of draft-aragon-ace-ipsec-profile-00 == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-01 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-08 == Outdated reference: A later version (-05) exists of draft-tiloca-ace-oscoap-joining-00 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 7 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: April 30, 2018 F. Palombini 6 Ericsson AB 7 J. Park 8 Universitaet Duisburg-Essen 9 October 27, 2017 11 Secure group communication for CoAP 12 draft-tiloca-core-multicast-oscoap-04 14 Abstract 16 This document describes a method for protecting group communication 17 over the Constrained Application Protocol (CoAP). The proposed 18 approach relies on Object Security for Constrained RESTful 19 Environments (OSCORE) and the CBOR Object Signing and Encryption 20 (COSE) format. All security requirements fulfilled by OSCORE are 21 maintained for multicast OSCORE request messages and related OSCORE 22 response messages. Source authentication of all messages exchanged 23 within the group is ensured, by means of digital signatures produced 24 through private keys of sender devices and embedded in the protected 25 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 http://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 April 30, 2018. 44 Copyright Notice 46 Copyright (c) 2017 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 (http://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. Assumptions and Security Objectives . . . . . . . . . . . . . 5 64 2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. Security Objectives . . . . . . . . . . . . . . . . . . . 7 66 3. OSCORE Security Context . . . . . . . . . . . . . . . . . . . 7 67 3.1. Management of Group Keying Material . . . . . . . . . . . 9 68 4. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 10 69 5. Message Processing . . . . . . . . . . . . . . . . . . . . . 12 70 5.1. Protecting the Request . . . . . . . . . . . . . . . . . 12 71 5.2. Verifying the Request . . . . . . . . . . . . . . . . . . 13 72 5.3. Protecting the Response . . . . . . . . . . . . . . . . . 13 73 5.4. Verifying the Response . . . . . . . . . . . . . . . . . 13 74 6. Synchronization of Sequence Numbers . . . . . . . . . . . . . 14 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 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. List of Use Cases . . . . . . . . . . . . . . . . . 18 83 Appendix B. Example of Group Identifier Format . . . . . . . . . 20 84 Appendix C. Set-up of New Endpoints . . . . . . . . . . . . . . 21 85 C.1. Join Process . . . . . . . . . . . . . . . . . . . . . . 21 86 C.2. Provisioning and Retrieval of Public Keys . . . . . . . . 23 87 C.3. Group Joining Based on the ACE Framework . . . . . . . . 24 88 Appendix D. Examples of Synchronization Approaches . . . . . . . 25 89 D.1. Best-Effort Synchronization . . . . . . . . . . . . . . . 25 90 D.2. Baseline Synchronization . . . . . . . . . . . . . . . . 25 91 D.3. Challenge-Response Synchronization . . . . . . . . . . . 26 92 Appendix E. No Verification of Signatures . . . . . . . . . . . 27 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 95 1. Introduction 97 The Constrained Application Protocol (CoAP) [RFC7252] is a web 98 transfer protocol specifically designed for constrained devices and 99 networks [RFC7228]. 101 Group communication for CoAP [RFC7390] addresses use cases where 102 deployed devices benefit from a group communication model, for 103 example to reduce latencies and improve performance. Use cases 104 include lighting control, integrated building control, software and 105 firmware updates, parameter and configuration updates, commissioning 106 of constrained networks, and emergency multicast (see Appendix A). 107 Furthermore, [RFC7390] recognizes the importance to introduce a 108 secure mode for CoAP group communication. This specification defines 109 such a mode. 111 Object Security for Constrained RESTful Environments 112 (OSCORE)[I-D.ietf-core-object-security] describes a security protocol 113 based on the exchange of protected CoAP messages. OSCORE builds on 114 CBOR Object Signing and Encryption (COSE) [RFC8152] and provides end- 115 to-end encryption, integrity, and replay protection between a sending 116 endpoint and a receiving endpoint across intermediary nodes. To this 117 end, a CoAP message is protected by including payload (if any), 118 certain options, and header fields in a COSE object, which finally 119 replaces the authenticated and encrypted fields in the protected 120 message. 122 This document describes multicast OSCORE, providing end-to-end 123 security of CoAP messages exchanged between members of a multicast 124 group. In particular, the described approach defines how OSCORE 125 should be used in a group communication context, while fulfilling the 126 same security requirements. That is, end-to-end security is assured 127 for multicast CoAP requests sent by multicaster nodes to the group 128 and for related CoAP responses sent as reply by multiple listener 129 nodes. Multicast OSCORE provides source authentication of all CoAP 130 messages exchanged within the group, by means of digital signatures 131 produced through private keys of sender devices and embedded in the 132 protected CoAP messages. As in OSCORE, it is still possible to 133 simultaneously rely on DTLS to protect hop-by-hop communication 134 between a multicaster node and a proxy (and vice versa), and between 135 a proxy and a listener node (and vice versa). 137 1.1. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119][RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 Readers are expected to be familiar with the terms and concepts 146 described in CoAP [RFC7252]; group communication for CoAP [RFC7390]; 147 COSE and counter signatures [RFC8152]. 149 Readers are also expected to be familiar with the terms and concepts 150 for protection and processing of CoAP messages through OSCORE, such 151 as "Security Context", "Master Secret" and "Master Salt", defined in 152 [I-D.ietf-core-object-security]. 154 Terminology for constrained environments, such as "constrained 155 device", "constrained-node network", is defined in [RFC7228]. 157 This document refers also to the following terminology. 159 o Keying material: data that is necessary to establish and maintain 160 secure communication among member of a multicast group. This 161 includes, for instance, keys and IVs [RFC4949]. 163 o Group Manager (GM): entity responsible for creating a multicast 164 group, establishing and provisioning Security Contexts among 165 authorized group members, as well as managing the joining of new 166 group members and the leaving of current group members. A GM can 167 be responsible for multiple multicast groups. Besides, a GM is 168 not required to be an actual group member and to take part in the 169 group communication. The GM is also responsible for renewing/ 170 updating Security Contexts and related keying material in the 171 multicast groups of its competence. Each endpoint in a multicast 172 group securely communicates with the respective GM. 174 o Multicaster: member of a multicast group that sends multicast CoAP 175 messages intended for all members of the group. In a 1-to-N 176 multicast group, only a single multicaster transmits data to the 177 group; in an M-to-N multicast group (where M and N do not 178 necessarily have the same value), M group members are 179 multicasters. According to [RFC7390], any possible proxy entity 180 is supposed to know about the multicasters in the group and to not 181 perform aggregation of response messages. Also, every multicaster 182 expects and is able to handle multiple response messages 183 associated to a given multicast request message that it has 184 previously sent to the group. 186 o Listener: member of a multicast group that receives multicast CoAP 187 messages when listening to the multicast IP address associated to 188 the multicast group. A listener may reply back, by sending a 189 response message to the multicaster which has sent the multicast 190 message. 192 o Pure listener: member of a multicast group that is configured as 193 listener and never replies back to multicasters after receiving 194 multicast messages. 196 o Endpoint ID: identifier assigned by the Group Manager to an 197 endpoint upon joining the group as a new member, unless configured 198 exclusively as pure listener. The Group Manager generates and 199 manages Endpoint IDs in order to ensure their uniqueness within a 200 same multicast group. That is, within a single multicast group, 201 the same Endpoint ID cannot be associated to more endpoints at the 202 same time. Endpoint IDs are not necessarily related to any 203 protocol-relevant identifiers, such as IP addresses. 205 o Group request: multicast CoAP request message sent by a 206 multicaster in the group to all listeners in the group through 207 multicast IP, unless otherwise specified. 209 o Source authentication: evidence that a received message in the 210 group originated from a specifically identified group member. 211 This also provides assurances that the message was not tampered 212 with either by a different group member or by a non-group member. 214 2. Assumptions and Security Objectives 216 This section presents a set of assumptions and security objectives 217 for the approach described in this document. 219 2.1. Assumptions 221 The following assumptions are assumed to be already addressed and are 222 out of the scope of this document. 224 o Multicast communication topology: this document considers both 225 1-to-N (one multicaster and multiple listeners) and M-to-N 226 (multiple multicasters and multiple listeners) communication 227 topologies. The 1-to-N communication topology is the simplest 228 group communication scenario that would serve the needs of a 229 typical low-power and lossy network (LLN). For instance, in a 230 typical lighting control use case, a single switch is the only 231 entity responsible for sending commands to a group of lighting 232 devices. In more advanced lighting control use cases, a M-to-N 233 communication topology would be required, for instance in case 234 multiple sensors (presence or day-light) are responsible to 235 trigger events to a group of lighting devices. 237 o Multicast group size: security solutions for group communication 238 should be able to adequately support different, possibly large, 239 group sizes. Group size is the combination of the number of 240 multicasters and listeners in a multicast group, with possible 241 overlap (i.e. a multicaster may also be a listener at the same 242 time). In the use cases mentioned in this document, the number of 243 multicasters (normally the controlling devices) is expected to be 244 much smaller than the number of listeners (i.e. the controlled 245 devices). A security solution for group communication that 246 supports 1 to 50 multicasters would be able to properly cover the 247 group sizes required for most use cases that are relevant for this 248 document. The total number of group members is expected to be in 249 the range of 2 to 100 devices. Groups larger than that should be 250 divided into smaller independent multicast groups, e.g. by 251 grouping lights in a building on a per floor basis. 253 o Establishment and management of Security Contexts: a Security 254 Context must be established among the group members by the Group 255 Manager which manages the multicast group. A secure mechanism 256 must be used to generate, revoke and (re-)distribute keying 257 material, multicast security policies and security parameters in 258 the multicast group. The actual establishment and management of 259 the Security Context is out of the scope of this document, and it 260 is anticipated that an activity in IETF dedicated to the design of 261 a generic key management scheme will include this feature, 262 preferably based on [RFC3740][RFC4046][RFC4535]. 264 o Multicast data security ciphersuite: all group members MUST agree 265 on a ciphersuite to provide authenticity, integrity and 266 confidentiality of messages in the multicast group. The 267 ciphersuite is specified as part of the Security Context. 269 o Backward security: a new device joining the multicast group should 270 not have access to any old Security Contexts used before its 271 joining. This ensures that a new group member is not able to 272 decrypt confidential data sent before it has joined the group. 273 The adopted key management scheme should ensure that the Security 274 Context is updated to ensure backward confidentiality. The actual 275 mechanism to update the Security Context and renew the group 276 keying material upon a group member's joining has to be defined as 277 part of the group key management scheme. 279 o Forward security: entities that leave the multicast group should 280 not have access to any future Security Contexts or message 281 exchanged within the group after their leaving. This ensures that 282 a former group member is not able to decrypt confidential data 283 sent within the group anymore. Also, it ensures that a former 284 member is not able to send encrypted and/or integrity protected 285 messages to the group anymore. The actual mechanism to update the 286 Security Context and renew the group keying material upon a group 287 member's leaving has to be defined as part of the group key 288 management scheme. 290 2.2. Security Objectives 292 The approach described in this document aims at fulfilling the 293 following security objectives: 295 o Data replay protection: replayed group request messages or 296 response messages MUST be detected. 298 o Group-level data confidentiality: messages sent within the 299 multicast group SHALL be encrypted if privacy sensitive data is 300 exchanged within the group. In fact, some control commands and/or 301 associated responses could pose unforeseen security and privacy 302 risks to the system users, when sent as plaintext. This document 303 considers group-level data confidentiality since messages are 304 encrypted at a group level, i.e. in such a way that they can be 305 decrypted by any member of the multicast group, but not by an 306 external adversary or other external entities. 308 o Source authentication: messages sent within the multicast group 309 SHALL be authenticated. That is, it is essential to ensure that a 310 message is originated by a member of the group in the first place 311 (group authentication), and in particular by a specific member of 312 the group (source authentication). 314 o Message integrity: messages sent within the multicast group SHALL 315 be integrity protected. That is, it is essential to ensure that a 316 message has not been tampered with by an external adversary or 317 other external entities which are not group members. 319 o Message ordering: it MUST be possible to determine the ordering of 320 messages coming from a single sender endpoint. In accordance with 321 OSCORE [I-D.ietf-core-object-security], this results in providing 322 relative freshness of group requests and absolute freshness of 323 responses. It is not required to determine ordering of messages 324 from different sender endpoints. 326 3. OSCORE Security Context 328 To support multicast communication secured with OSCORE, each endpoint 329 registered as member of a multicast group maintains a Security 330 Context as defined in Section 3 of [I-D.ietf-core-object-security]. 331 In particular, each endpoint in a group stores: 333 1. one Common Context, received from the Group Manager upon joining 334 the multicast group and shared by all the endpoints in the group. 335 All the endpoints in the group agree on the same COSE AEAD 336 algorithm. In addition to what is defined in Section 3 of 337 [I-D.ietf-core-object-security], the Common Context includes the 338 following information. 340 * Group Identifier (Gid). Variable length byte string 341 identifying the Security Context and used as Master Salt 342 parameter in the derivation of keying material. The Gid is 343 used together with the multicast IP address of the group to 344 retrieve the Security Context, upon receiving a secure 345 multicast request message (see Section 5.2). The Gid 346 associated to a multicast group is determined by the 347 responsible Group Manager. The choice of the Gid for a given 348 group's Security Context is application specific. However, a 349 Gid MUST be random as well as long enough, in order to achieve 350 a negligible probability of collisions between Group 351 Identifiers from different Group Managers. It is the role of 352 the application to specify how to handle possible collisions. 353 An example of specific formatting of the Group Identifier that 354 would follow this specification is given in Appendix B. 356 * Counter signature algorithm. Value identifying the algorithm 357 used for source authenticating messages sent within the group, 358 by means of a counter signature (see Section 4.5 of 359 [RFC8152]). Its value is immutable once the Security Context 360 is established. All the endpoints in the group agree on the 361 same counter signature algorithm. The Group Manager MUST 362 define a list of supported signature algorithms as part of the 363 group communication policy. Such a list MUST include the 364 EdDSA signature algorithm ed25519 [RFC8032]. 366 2. one Sender Context, unless the endpoint is configured exclusively 367 as pure listener. The Sender Context is used to secure outgoing 368 messages and is initialized according to Section 3 of 369 [I-D.ietf-core-object-security], once the endpoint has joined the 370 multicast group. In practice, the sender endpoint shares the 371 same symmetric keying material stored in the Sender Context with 372 all the recipient endpoints receiving its outgoing OSCORE 373 messages. The Sender ID in the Sender Context coincides with the 374 Endpoint ID received upon joining the group. It is 375 responsibility of the Group Manager to assign Endpoint IDs to new 376 joining endpoints in such a way that uniquess is ensured within 377 the multicast group. Besides, in addition to what is defined in 378 [I-D.ietf-core-object-security], the Sender Context stores also 379 the endpoint's public-private key pair. 381 3. one Recipient Context for each distinct endpoint from which 382 messages are received, used to process such incoming secure 383 messages. The endpoint creates a new Recipient Context upon 384 receiving an incoming message from another endpoint in the group 385 for the first time. In practice, the recipient endpoint shares 386 the symmetric keying material stored in the Recipient Context 387 with the associated other endpoint from which secure messages are 388 received. Besides, in addition to what is defined in 389 [I-D.ietf-core-object-security], each Recipient Context stores 390 also the public key of the associated other endpoint from which 391 secure messages are received. 393 Upon receiving a secure CoAP message, a recipient endpoint relies on 394 the sender endpoint's public key, in order to verify the counter 395 signature conveyed in the COSE Object. 397 If not already stored in the Recipient Context associated to the 398 sender endpoint, the recipient endpoint retrieves the public key from 399 a trusted key repository. In such a case, the correct binding 400 between the sender endpoint and the retrieved public key MUST be 401 assured, for instance by means of public key certificates. 403 It is RECOMMENDED that the Group Manager acts as trusted key 404 repository, and hence is configured to store public keys of group 405 members and provide them to other members of the same group upon 406 request. Possible approaches to provision public keys upon joining 407 the group and to retrieve public keys of group members are discussed 408 in Appendix C.2. 410 The Sender Key/IV stored in the Sender Context and the Recipient 411 Keys/IVs stored in the Recipient Contexts are derived according to 412 the same scheme defined in Section 3.2 of 413 [I-D.ietf-core-object-security]. 415 3.1. Management of Group Keying Material 417 The approach described in this specification should take into account 418 the risk of compromise of group members. Such a risk is reduced when 419 multicast groups are deployed in physically secured locations, like 420 lighting inside office buildings. Nevertheless, the adoption of key 421 management schemes for secure revocation and renewal of Security 422 Contexts and group keying material should be considered. 424 Consistently with the security assumptions in Section 2, it is 425 RECOMMENDED to adopt a group key management scheme, and securely 426 distribute a new value for the Master Secret parameter of the group's 427 Security Context, before a new joining endpoint is added to the group 428 or after a currently present endpoint leaves the group. This is 429 necessary in order to preserve backward security and forward security 430 in the multicast group. The Group Manager responsible for the group 431 is entrusted with such a task. 433 In particular, the Group Manager MUST distribute also a new Group 434 Identifier (Gid) for that group, together with a new value for the 435 Master Secret parameter. An example of how this can be done is 436 provided in Appendix B. Then, each group member re-derives the 437 keying material stored in its own Sender Context and Recipient 438 Contexts as described in Section 3, using the updated Group 439 Identifier. 441 Especially in dynamic, large-scale, multicast groups where endpoints 442 can join and leave at any time, it is important that the considered 443 group key management scheme is efficient and highly scalable with the 444 group size, in order to limit the impact on performance due to the 445 Security Context and keying material update. 447 4. The COSE Object 449 When creating a protected CoAP message, an endpoint in the group 450 computes the COSE object using the untagged COSE_Encrypt0 structure 451 [RFC8152] as defined in Section 5 of [I-D.ietf-core-object-security], 452 with the following modifications. 454 o The value of the "kid" parameter in the "unprotected" field of 455 responses SHALL be set to the Sender ID of the endpoint 456 transmitting the group message. 458 o The "unprotected" field of the "Headers" field SHALL additionally 459 include the following parameters: 461 * gid : its value is set to the Group Identifier (Gid) of the 462 group's Security Context. This parameter MAY be omitted if the 463 message is a CoAP response. 465 * countersign : its value is set to the counter signature of the 466 COSE object (Appendix C.3.3 of [RFC8152]), computed by the 467 endpoint by means of its own private key as described in 468 Section 4.5 of [RFC8152]. 470 In particular, "gid" is included as COSE header parameter as defined 471 in Figure 1. 473 +------+-------+------------+----------------+-------------------+ 474 | name | label | value type | value registry | description | 475 +------+-------+------------+----------------+-------------------+ 476 | gid | TBD | bstr | | Identifies the | 477 | | | | | OSCORE group | 478 | | | | | Security Context | 479 +------+-------+------------+----------------+-------------------+ 481 Figure 1: Additional common header parameter for the COSE object 483 o The Additional Authenticated Data (AAD) considered to compute the 484 COSE object is extended, in order to include also the Group 485 Identifier (Gid) of the Security Context used to protect the 486 request message. In particular, the "external_aad" in Section 5.3 487 of [I-D.ietf-core-object-security] SHALL include also gid as 488 follows: 490 external_aad = [ 491 version : uint, 492 alg : int, 493 request_kid : bstr, 494 request_piv : bstr, 495 gid : bstr, 496 options : bstr 497 ] 499 o The OSCORE compression defined in Section 8 of 500 [I-D.ietf-core-object-security] is used, with the following 501 additions for the encoding of the object-security option. 503 * The fourth least significant bit of the first byte of the 504 object-security option value SHALL be set to 1, to indicate the 505 presence of the "kid" parameter for both multicast requests and 506 responses. 508 * The fifth least significant bit of the first byte MUST be set 509 to 1 for multicast requests, to indicate the presence of the 510 Context Hint in the OSCORE payload. The Context Hint flag MAY 511 be set to 1 for responses. 513 * The sixth least significant bit of the first byte is set to 1 514 if the "countersign" parameter is present, or to 0 otherwise. 515 In order to ensure source authentication of group messages as 516 described in this specification, this bit SHALL be set to 1. 518 * The Context Hint value encodes the Group Identifier value (Gid) 519 of the group's Security Context. 521 * The following q bytes (q given by the counter signature 522 algorithm specified in the Security Context) encode the value 523 of the "countersign" parameter including the counter signature 524 of the COSE object. 526 * The remaining bytes in the Object-Security value encode the 527 value of the "kid" parameter, which is always present both in 528 multicast requests and in responses. 530 0 1 2 3 4 5 6 7 <----------- n bytes -----------> <-- 1 byte --> 531 +-+-+-+-+-+-+-+-+---------------------------------+--------------+ 532 |0 0|1|h|1| n | Partial IV (if any) | s (if any) | 533 +-+-+-+-+-+-+-+-+---------------------------------+--------------+ 535 <------ s bytes ------> <--------- q bytes ---------> 536 -----------------------+-----------------------------+-----------+ 537 Gid (if any) | countersign | kid | 538 -----------------------+-----------------------------+-----------+ 540 Figure 2: Object-Security Value 542 5. Message Processing 544 Each multicast request message and response message is protected and 545 processed as specified in [I-D.ietf-core-object-security], with the 546 modifications described in the following sections. 548 Furthermore, endpoints in the multicast group locally perform error 549 handling and processing of invalid messages according to the same 550 principles adopted in [I-D.ietf-core-object-security]. However, a 551 receiver endpoint MUST stop processing and silently reject any 552 message which is malformed and does not follow the format specified 553 in Section 4, without sending back any error message. This prevents 554 listener endpoints from sending multiple error messages to a 555 multicaster endpoint, so avoiding the risk of flooding the multicast 556 group. 558 5.1. Protecting the Request 560 A multicaster endpoint transmits a secure multicast request message 561 as described in Section 7.1 of [I-D.ietf-core-object-security], with 562 the following modifications. 564 1. The multicaster endpoint stores the association Token - Group 565 Identifier. That is, it SHALL be able to find the correct 566 Security Context used to protect the multicast request and verify 567 the response(s) by using the CoAP Token used in the message 568 exchange. 570 2. The multicaster computes the COSE object as defined in Section 4 571 of this specification. 573 5.2. Verifying the Request 575 Upon receiving a secure multicast request message, a listener 576 endpoint proceeds as described in Section 7.2 of 577 [I-D.ietf-core-object-security], with the following modifications. 579 1. The listener endpoint retrieves the Group Identifier from the 580 "gid" parameter of the received COSE object. Then, it uses the 581 Group Identifier together with the destination IP address of the 582 multicast request message to identify the correct group's 583 Security Context. 585 2. The listener endpoint retrieves the Sender ID from the "kid" 586 parameter of the received COSE object. Then, the Sender ID is 587 used to retrieve the correct Recipient Context associated to the 588 multicaster endpoint and used to process the request message. 589 When receiving a secure multicast CoAP request message from that 590 multicaster endpoint for the first time, the listener endpoint 591 creates a new Recipient Context, initializes it according to 592 Section 3 of [I-D.ietf-core-object-security], and includes the 593 multicaster endpoint's public key. 595 3. The listener endpoint retrieves the corresponding public key of 596 the multicaster endpoint from the associated Recipient Context. 597 Then, it verifies the counter signature and decrypts the request 598 message. 600 5.3. Protecting the Response 602 A listener endpoint that has received a multicast request message may 603 reply with a secure response message, which is protected as described 604 in Section 7.3 of [I-D.ietf-core-object-security], with the following 605 modifications. 607 1. The listener endpoint computes the COSE object as defined in 608 Section 4 of this specification. 610 5.4. Verifying the Response 612 Upon receiving a secure response message, a multicaster endpoint 613 proceeds as described in Section 7.4 of 614 [I-D.ietf-core-object-security], with the following modifications. 616 1. The multicaster endpoint retrieves the Security Context by using 617 the Token of the received response message. 619 2. The multicaster endpoint retrieves the Sender ID from the "kid" 620 parameter of the received COSE object. Then, the Sender ID is 621 used to retrieve the correct Recipient Context associated to the 622 listener endpoint and used to process the response message. When 623 receiving a secure CoAP response message from that listener 624 endpoint for the first time, the multicaster endpoint creates a 625 new Recipient Context, initializes it according to Section 3 of 626 [I-D.ietf-core-object-security], and includes the listener 627 endpoint's public key. 629 3. The multicaster endpoint retrieves the corresponding public key 630 of the listener endpoint from the associated Recipient Context. 631 Then, it verifies the counter signature and decrypts the response 632 message. 634 The mapping between response messages from listener endpoints and the 635 associated multicast request message from a multicaster endpoint 636 relies on the 3-tuple (Group ID, Sender ID, Partial IV) associated to 637 the secure multicast request message. This is used by listener 638 endpoints as part of the Additional Authenticated Data when 639 protecting their own response message, as described in Section 4. 641 6. Synchronization of Sequence Numbers 643 Upon joining the multicast group, new listeners are not aware of the 644 sequence number values currently used by different multicasters to 645 transmit multicast request messages. This means that, when such 646 listeners receive a secure multicast request from a given multicaster 647 for the first time, they are not able to verify if that request is 648 fresh and has not been replayed. The same applies when a listener 649 endpoint loses synchronization with sequence numbers of multicasters, 650 for instance after a device reboot. 652 The exact way to address this issue depends on the specific use case 653 and its synchronization requirements. The Group Manager should 654 define also how to handle synchronization of sequence numbers, as 655 part of the policies enforced in the multicast group. In particular, 656 the Group Manager can suggest to single specific listener endpoints 657 how they can exceptionally behave in order to synchronize with 658 sequence numbers of multicasters. Appendix D describes three 659 possible approaches that can be considered. 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 multicast 672 group. This means that messages are encrypted at a group level 673 (group-level data confidentiality), i.e. they can be decrypted by any 674 member of the multicast group, but not by an external adversary or 675 other external entities. 677 In addition, it is required that all group members are trusted, i.e. 678 they do not forward the content of group messages to unauthorized 679 entities. However, in many use cases, the devices in the multicast 680 group belong to a common authority and are configured by a 681 commissioner. For instance, in a professional lighting scenario, the 682 roles of multicaster and listener are configured by the lighting 683 commissioner, and devices strictly follow those roles. 685 8. IANA Considerations 687 TBD. Header parameter 'gid'. 689 9. Acknowledgments 691 The authors sincerely thank Stefan Beck, Rolf Blom, Carsten Bormann, 692 Klaus Hartke, Richard Kelsey, John Mattsson, Jim Schaad and Ludwig 693 Seitz for their feedback and comments. 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-06 (work in 703 progress), October 2017. 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, . 710 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 711 Application Protocol (CoAP)", RFC 7252, 712 DOI 10.17487/RFC7252, June 2014, . 715 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 716 Signature Algorithm (EdDSA)", RFC 8032, 717 DOI 10.17487/RFC8032, January 2017, . 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.amsuess-core-repeat-request-tag] 731 Amsuess, C., Mattsson, J., and G. Selander, "Repeat And 732 Request-Tag", draft-amsuess-core-repeat-request-tag-00 733 (work in progress), July 2017. 735 [I-D.aragon-ace-ipsec-profile] 736 Aragon, S., Tiloca, M., and S. Raza, "IPsec profile of 737 ACE", draft-aragon-ace-ipsec-profile-00 (work in 738 progress), July 2017. 740 [I-D.ietf-ace-dtls-authorize] 741 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 742 L. Seitz, "Datagram Transport Layer Security (DTLS) 743 Profile for Authentication and Authorization for 744 Constrained Environments (ACE)", draft-ietf-ace-dtls- 745 authorize-01 (work in progress), July 2017. 747 [I-D.ietf-ace-oauth-authz] 748 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 749 H. Tschofenig, "Authentication and Authorization for 750 Constrained Environments (ACE)", draft-ietf-ace-oauth- 751 authz-08 (work in progress), October 2017. 753 [I-D.seitz-ace-oscoap-profile] 754 Seitz, L., Palombini, F., and M. Gunnarsson, "OSCORE 755 profile of the Authentication and Authorization for 756 Constrained Environments Framework", draft-seitz-ace- 757 oscoap-profile-06 (work in progress), October 2017. 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 OSCOAP multicast 767 groups in ACE", draft-tiloca-ace-oscoap-joining-00 (work 768 in progress), July 2017. 770 [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management 771 Protocol (GKMP) Specification", RFC 2093, 772 DOI 10.17487/RFC2093, July 1997, . 775 [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management 776 Protocol (GKMP) Architecture", RFC 2094, 777 DOI 10.17487/RFC2094, July 1997, . 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, . 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, . 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, . 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, . 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, . 845 Appendix A. List of Use Cases 847 Group Communication for CoAP [RFC7390] provides the necessary 848 background for multicast-based CoAP communication, with particular 849 reference to low-power and lossy networks (LLNs) and resource 850 constrained environments. The interested reader is encouraged to 851 first read [RFC7390] to understand the non-security related details. 852 This section discusses a number of use cases that benefit from secure 853 group communication. Specific security requirements for these use 854 cases are discussed in Section 2. 856 o Lighting control: consider a building equipped with IP-connected 857 lighting devices, switches, and border routers. The devices are 858 organized into groups according to their physical location in the 859 building. For instance, lighting devices and switches in a room 860 or corridor can be configured as members of a single multicast 861 group. Switches are then used to control the lighting devices by 862 sending on/off/dimming commands to all lighting devices in a 863 group, while border routers connected to an IP network backbone 864 (which is also multicast-enabled) can be used to interconnect 865 routers in the building. Consequently, this would also enable 866 logical multicast groups to be formed even if devices in the 867 lighting group may be physically in different subnets (e.g. on 868 wired and wireless networks). Connectivity between ligthing 869 devices may be realized, for instance, by means of IPv6 and 870 (border) routers supporting 6LoWPAN [RFC4944][RFC6282]. Group 871 communication enables synchronous operation of a group of 872 connected lights, ensuring that the light preset (e.g. dimming 873 level or color) of a large group of luminaires are changed at the 874 same perceived time. This is especially useful for providing a 875 visual synchronicity of light effects to the user. Devices may 876 reply back to the switches that issue on/off/dimming commands, in 877 order to report about the execution of the requested operation 878 (e.g. OK, failure, error) and their current operational status. 880 o Integrated building control: enabling Building Automation and 881 Control Systems (BACSs) to control multiple heating, ventilation 882 and air-conditioning units to pre-defined presets. Controlled 883 units can be organized into multicast groups in order to reflect 884 their physical position in the building, e.g. devices in the same 885 room can be configured as members of a single multicast group. 886 Furthermore, controlled units are expected to possibly reply back 887 to the BACS issuing control commands, in order to report about the 888 execution of the requested operation (e.g. OK, failure, error) 889 and their current operational status. 891 o Software and firmware updates: software and firmware updates often 892 comprise quite a large amount of data. This can overload a LLN 893 that is otherwise typically used to deal with only small amounts 894 of data, on an infrequent base. Rather than sending software and 895 firmware updates as unicast messages to each individual device, 896 multicasting such updated data to a larger group of devices at 897 once displays a number of benefits. For instance, it can 898 significantly reduce the network load and decrease the overall 899 time latency for propagating this data to all devices. Even if 900 the complete whole update process itself is secured, securing the 901 individual messages is important, in case updates consist of 902 relatively large amounts of data. In fact, checking individual 903 received data piecemeal for tampering avoids that devices store 904 large amounts of partially corrupted data and that they detect 905 tampering hereof only after all data has been received. Devices 906 receiving software and firmware updates are expected to possibly 907 reply back, in order to provide a feedback about the execution of 908 the update operation (e.g. OK, failure, error) and their current 909 operational status. 911 o Parameter and configuration update: by means of multicast 912 communication, it is possible to update the settings of a group of 913 similar devices, both simultaneously and efficiently. Possible 914 parameters are related, for instance, to network load management 915 or network access controls. Devices receiving parameter and 916 configuration updates are expected to possibly reply back, to 917 provide a feedback about the execution of the update operation 918 (e.g. OK, failure, error) and their current operational status. 920 o Commissioning of LLNs systems: a commissioning device is 921 responsible for querying all devices in the local network or a 922 selected subset of them, in order to discover their presence, and 923 be aware of their capabilities, default configuration, and 924 operating conditions. Queried devices displaying similarities in 925 their capabilities and features, or sharing a common physical 926 location can be configured as members of a single multicast group. 927 Queried devices are expected to reply back to the commissioning 928 device, in order to notify their presence, and provide the 929 requested information and their current operational status. 931 o Emergency multicast: a particular emergency related information 932 (e.g. natural disaster) is generated and multicast by an emergency 933 notifier, and relayed to multiple devices. The latters may reply 934 back to the emergency notifier, in order to provide their feedback 935 and local information related to the ongoing emergency. 937 Appendix B. Example of Group Identifier Format 939 This section provides an example of how the Group Identifier (Gid) 940 can be specifically formatted. That is, the Gid can be composed of 941 two parts, namely a Group Prefix and a Group Epoch. 943 The Group Prefix is uniquely defined in the set of all the multicast 944 groups associated to the same Group Manager. The choice of the Group 945 Prefix for a given group's Security Context is application specific. 946 Group Prefixes are random as well as long enough, in order to achieve 947 a negligible probability of collisions between Group Identifiers from 948 different Group Managers. 950 The Group Epoch is set to 0 upon the group's initialization, and is 951 incremented by 1 upon completing each renewal of the Security Context 952 and keying material in the group (see Section 3.1). In particular, 953 once a new Master Secret has been distributed to the group, all the 954 group members increment by 1 the Group Epoch in the Group Identifier 955 of that group (see Section 3). 957 Appendix C. Set-up of New Endpoints 959 An endpoint joins a multicast group by explicitly interacting with 960 the responsible Group Manager. All communications between a joining 961 endpoint and the Group Manager rely on the CoAP protocol and MUST be 962 secured. Specific details on how to secure communications between 963 joining endpoints and a Group Manager are out of the scope of this 964 specification. 966 In order to receive multicast messages sent to the group, a joining 967 endpoint has to register with a network router device 968 [RFC3376][RFC3810], signaling its intent to receive packets sent to 969 the multicast IP address of that group. As a particular case, the 970 Group Manager can also act as such a network router device. Upon 971 joining the group, endpoints are not required to know how many and 972 what endpoints are active in the same group. 974 Furthermore, in order to participate in the secure group 975 communication, an endpoint needs to maintain a number of information 976 elements stored in its own Security Context (see Section 3). The 977 following Appendix C.1 describes which of this information is 978 provided to an endpoint upon joining a multicast group through the 979 responsible Group Manager. 981 C.1. Join Process 983 An endpoint requests to join a multicast group by sending a 984 confirmable CoAP POST request to the Group Manager responsible for 985 that group. The join request is addressed to a CoAP resource 986 associated to that group and carries the following information. 988 o Role: the exact role of the joining endpoint in the multicast 989 group. Possible values are: "multicaster", "listener", "pure 990 listener", "multicaster and listener", or "multicaster and pure 991 listener". 993 o Identity credentials: information elements to enforce source 994 authentication of group messages from the joining endpoint, such 995 as its public key. The exact content depends on whether the Group 996 Manager is configured to store the public keys of group members. 997 If this is the case, this information is omitted if it has been 998 provided to the same Group Manager upon previously joining the 999 same or a different multicast group under its control. This 1000 information is also omitted if the joining endpoint is configured 1001 exclusively as pure listener for the joined group. Appendix C.2 1002 discusses additional details on provisioning of public keys and 1003 other information to enforce source authentication of joining 1004 node's messages. 1006 o Retrieval flag: indication of interest to receive the public keys 1007 of the endpoints currently in the multicast group, as included in 1008 the following join response. This flag MUST be set to false if 1009 the Group Manager is not configured to store the public keys of 1010 group members, or if the joining endpoint is configured 1011 exclusively as pure listener for the joined group. 1013 The Group Manager MUST be able to verify that the joining enpoint is 1014 authorized to become a member of the multicast group. To this end, 1015 the Group Manager can directly authorize the joining endpoint, or 1016 expect it to provide authorization evidence previously obtained from 1017 a trusted entity. Appendix C.3 describes how this can be achieved by 1018 leveraging the ACE framework for Authentication and Authorization in 1019 constrained environments [I-D.ietf-ace-oauth-authz]. 1021 In case of successful authorization check, the Group Manager 1022 generates an Endpoint ID assigned to the joining node, before 1023 proceeding with the rest of the join process. Instead, in case the 1024 authorization check fails, the Group Manager MUST abort the join 1025 process. Further details about the authorization of joining endpoint 1026 are out of the scope of this specification. 1028 As discussed in Section 3.1, it is then RECOMMENDED that the Security 1029 Context is renewed before the joining endpoint becomes a new active 1030 member of the multicast group. This is achieved by securely 1031 distributing a new Master Secret and a new Group Identifier to the 1032 endpoints currently present in the same group. 1034 Once renewed the Security Context in the multicast group, the Group 1035 Manager replies to the joining endpoint with a CoAP response carrying 1036 the following information. 1038 o Security Common Context: the OSCORE Security Common Context 1039 associated to the joined multicast group (see Section 3). 1041 o Endpoint ID: the Endpoint ID associated to the joining node. This 1042 information is not included in case "Role" in the join request is 1043 equal to "pure listener". 1045 o Management keying material: the set of administrative keying 1046 material used to participate in the group rekeying process run by 1047 the Group Manager (see Section 3.1). The specific elements of 1048 this management keying material depend on the group rekeying 1049 protocol used in the group. For instance, this can simply consist 1050 in a group key encryption key and a pairwise symmetric key shared 1051 between the joining node and the Group Manager, in case GKMP 1052 [RFC2093][RFC2094] is used. Instead, if key-tree based rekeying 1053 protocols like LKH [RFC2627] are used, it can consist in the set 1054 of symmetric keys associated to the key-tree leaf representing the 1055 group member up to the key-tree root representing the group key 1056 encryption key. 1058 o Member public keys: the public keys of the endpoints currently 1059 present in the multicast group. This includes: the public keys of 1060 the non-pure listeners currently in the group, if the joining 1061 endpoint is configured (also) as multicaster; and the public keys 1062 of the multicasters currently in the group, if the joining 1063 endpoint is configured (also) as listener or pure listener. This 1064 information is omitted in case the Group Manager is not configured 1065 to store the public keys of group members or if the "Retrieval 1066 flag" was set to false in the join request. Appendix C.2 1067 discusses additional details on provisioning public keys upon 1068 joining the group and on retrieving public keys of group members. 1070 C.2. Provisioning and Retrieval of Public Keys 1072 As mentioned in Section 3, it is RECOMMENDED that the Group Manager 1073 acts as trusted key repository, stores public keys of group members 1074 and provide them to other members of the same group upon request. In 1075 such a case, a joining endpoint provides its own public key to the 1076 Group Manager, as "Identity credentials" of the join request, when 1077 joining the multicast group (see Appendix C.1). 1079 After that, the Group Manager MUST verify that the joining endpoint 1080 actually owns the associated private key, for instance by performing 1081 a proof-of-possession challenge-response. In case of success, the 1082 Group Manager stores the received public key as associated to the 1083 joining endpoint and its Endpoint ID, before sending the join 1084 response and continuing with the rest of the join process. From then 1085 on, that public key will be available for secure and trusted delivery 1086 to other endpoints in the multicast group. 1088 The joining node does not have to provide its own public key if that 1089 already occurred upon previously joining the same or a different 1090 multicast group under the same Group Manager. However, separately 1091 for each multicast group under its control, the Group Manager 1092 maintains an updated list of active Endpoint IDs associated to a same 1093 endpoint's public key. 1095 Instead, in case the Group Manager does not act as trusted key 1096 repository, the following information is exchanged with the Group 1097 Manager during the join process. 1099 1. The joining endpoint signs its own certificate by using its own 1100 private key. There is no restriction on the Certificate Subject 1101 included in the joining node's certificate. 1103 2. The joining endpoint includes the following information as 1104 "Identity credentials" in the join request (Appendix C.1): the 1105 signed certificate; and the identifier of the Certification 1106 Authority that issued the certificate. The joining endpoint can 1107 optionally specify also a list of public key repositories storing 1108 its own certificate. 1110 3. When processing the join request, the Group Manager first 1111 validates the certificate by verifying the signature of the 1112 issuer CA, and then verifies the signature of the joining node. 1114 4. The Group Manager stores the association between the Certificate 1115 Subject of the joining node's certificate and the pair {Group ID, 1116 Endpoint ID of the joining node}. If received from the joining 1117 endpoint, the Group Manager also stores the list of public key 1118 repositories storing the certificate of the joining endpoint. 1120 When a group member X wants to retrieve the public key of another 1121 group member Y in the same multicast group, the endpoint X proceeds 1122 as follows. 1124 1. The endpoint X contacts the Group Manager, specifying the pair 1125 {Group ID, Endpoint ID of the endpoint Y}. 1127 2. The Group Manager provides the endpoint X with the Certificate 1128 Subject CS from the certificate of endpoint Y. If available, the 1129 Group Manager provides the endpoint X also with the list of 1130 public key repositories storing the certificate of the endpoint 1131 Y. 1133 3. The endpoint X retrieves the certificate of the endpoint X from a 1134 key repository storing it, by using the Certificate Subject CS. 1136 C.3. Group Joining Based on the ACE Framework 1138 The join process to register an endpoint as a new member of a 1139 multicast group can be based on the ACE framework for Authentication 1140 and Authorization in constrained environments 1141 [I-D.ietf-ace-oauth-authz], built on re-use of OAuth 2.0 [RFC6749]. 1143 In particular, the approach described in 1144 [I-D.tiloca-ace-oscoap-joining] uses the ACE framework to delegate 1145 the authentication and authorization of joining endpoints to an 1146 Authorization Server in a trust relation with the Group Manager. At 1147 the same time, it allows a joining endpoint to establish a secure 1148 channel with the Group Manager, by leveraging protocol-specific 1149 profiles of ACE [I-D.seitz-ace-oscoap-profile][I-D.ietf-ace-dtls-auth 1150 orize][I-D.aragon-ace-ipsec-profile] to achieve communication 1151 security, proof-of-possession and server authentication. 1153 More specifically and with reference to the terminology defined in 1154 OAuth 2.0: 1156 o The joining endpoint acts as Client; 1158 o The Group Manager acts as Resource Server, with different CoAP 1159 resources for different multicast groups it is responsible for; 1161 o An Authorization Server enables and enforces authorized access of 1162 the joining endpoint to the Group Manager and its CoAP resources 1163 paired with multicast groups to join. 1165 Both the joining endpoint and the Group Manager MUST adopt secure 1166 communication also for any message exchange with the Authorization 1167 Server. To this end, different alternatives are possible, such as 1168 OSCORE, DTLS [RFC6347] or IPsec [RFC4301]. 1170 Appendix D. Examples of Synchronization Approaches 1172 This section describes three possible approaches that can be 1173 considered by listener endpoints to synchronize with sequence numbers 1174 of multicasters. 1176 D.1. Best-Effort Synchronization 1178 Upon receiving a multicast request from a multicaster, a listener 1179 endpoint does not take any action to synchonize with the sequence 1180 number of that multicaster. This provides no assurance at all as to 1181 message freshness, which can be acceptable in non-critical use cases. 1183 D.2. Baseline Synchronization 1185 Upon receiving a multicast request from a given multicaster for the 1186 first time, a listener endpoint initializes its last-seen sequence 1187 number in its Recipient Context associated to that multicaster. 1188 However, the listener drops the multicast request without delivering 1189 it to the application layer. This provides a reference point to 1190 identify if future multicast requests from the same multicaster are 1191 fresher than the last one received. 1193 A replay time interval exists, between when a possibly replayed 1194 message is originally transmitted by a given multicaster and the 1195 first authentic fresh message from that same multicaster is received. 1196 This can be acceptable for use cases where listener endpoints admit 1197 such a trade-off between performance and assurance of message 1198 freshness. 1200 D.3. Challenge-Response Synchronization 1202 A listener endpoint performs a challenge-response exchange with a 1203 multicaster, by using the Repeat Option for CoAP described in 1204 Section 2 of [I-D.amsuess-core-repeat-request-tag]. 1206 That is, upon receiving a multicast request from a particular 1207 multicaster for the first time, the listener processes the message as 1208 described in Section 5.2 of this specification, but, even if valid, 1209 does not deliver it to the application. Instead, the listener 1210 replies to the multicaster with a 4.03 Forbidden response message 1211 including a Repeat Option, and stores the option value included 1212 therein. 1214 Upon receiving a 4.03 Forbidden response that includes a Repeat 1215 Option and originates from a verified group member, a multicaster 1216 MUST send a group request as a unicast message addressed to the same 1217 listener, echoing the Repeat Option value. In particular, the 1218 multicaster does not necessarily resend the same group request, but 1219 can instead send a more recent one, if the application permits it. 1220 This makes it possible for the multicaster to not retain previously 1221 sent group requests for full retransmission, unless the application 1222 explicitly requires otherwise. In either case, the multicaster uses 1223 the sequence number value currently stored in its own Sender Context. 1224 If the multicaster stores group requests for possible retransmission 1225 with the Repeat Option, it should not store a given request for 1226 longer than a pre-configured time interval. Note that the unicast 1227 request echoing the Repeat Option is correctly treated and processed 1228 as a group message, since the "gid" field including the Group 1229 Identifier of the OSCORE group is still present in the Object- 1230 Security Option as part of the COSE object (see Section 4). 1232 Upon receiving the unicast group request including the Repeat Option, 1233 the listener verifies that the option value equals the stored and 1234 previously sent value; otherwise, the request is silently discarded. 1235 Then, the listener verifies that the unicast group request has been 1236 received within a pre-configured time interval, as described in 1237 [I-D.amsuess-core-repeat-request-tag]. In such a case, the request 1238 is further processed and verified; otherwise, it is silently 1239 discarded. Finally, the listener updates the Recipient Context 1240 associated to that multicaster, by setting the Replay Window 1241 according to the Sequence Number from the unicast group request 1242 conveying the Repeat Option. The listener either delivers the 1243 request to the application if it is an actual retransmission of the 1244 original one, or discard it otherwise. Mechanisms to signal whether 1245 the resent request is a full retransmission of the original one are 1246 out of the scope of this specification. 1248 In case it does not receive a valid group request including the 1249 Repeat Option within the configured time interval, the listener node 1250 SHOULD perform the same challenge-response upon receiving the next 1251 multicast request from that same multicaster. 1253 A listener SHOULD NOT deliver group request messages from a given 1254 multicaster to the application until one valid group request from 1255 that same multicaster has been verified as fresh, as conveying an 1256 echoed Repeat Option [I-D.amsuess-core-repeat-request-tag]. Also, a 1257 listener MAY perform the challenge-response described above at any 1258 time, if synchronization with sequence numbers of multicasters is 1259 (believed to be) lost, for instance after a device reboot. It is the 1260 role of the application to define under what circumstances sequence 1261 numbers lose synchronization. This can include a minimum gap between 1262 the sequence number of the latest accepted group request from a 1263 multicaster and the sequence number of a group request just received 1264 from the same multicaster. A multicaster MUST always be ready to 1265 perform the challenge-response based on the Repeat Option in case a 1266 listener starts it. 1268 Note that endpoints configured as pure listeners are not able to 1269 perform the challenge-response described above, as they do not store 1270 a Sender Context to secure the 4.03 Forbidden response to the 1271 multicaster. Therefore, pure listeners should adopt alternative 1272 approaches to achieve and maintain synchronization with sequence 1273 numbers of multicasters. 1275 This approach provides an assurance of absolute message freshness. 1276 However, it can result in an impact on performance which is 1277 undesirable or unbearable, especially in large multicast groups where 1278 many nodes at the same time might join as new members or lose 1279 synchronization. 1281 Appendix E. No Verification of Signatures 1283 There are some application scenarios using group communications that 1284 have particularly strict requirements. One example of this is the 1285 requirement of low message latency in non-emergency lighting 1286 applications [I-D.somaraju-ace-multicast]. For those applications 1287 which have tight performance constraints and relaxed security 1288 requirements, it can be inconvenient for some endpoints to verify 1289 digital signatures in order to assert source authenticity of received 1290 group messages. In other cases, the signature verification can be 1291 deferred or only checked for specific actions. For instance, a 1292 command to turn a bulb on where the bulb is already on does not need 1293 the signature to be checked. In such situations, the counter 1294 signature needs to be included anyway as part of the group message, 1295 so that an endpoint that needs to validate the signature for any 1296 reason has the ability to do so. 1298 In this specification, it is NOT RECOMMENDED that endpoints do not 1299 verify the counter signature of received group messages. However, it 1300 is recognized that there may be situations where it is not always 1301 required. The consequence of not doing the signature validation is 1302 that security in the group is based only on the group-authenticity of 1303 the shared keying material used for encryption. That is, endpoints 1304 in the multicast group have evidence that a received message has been 1305 originated by a group member, although not specifically identifiable 1306 in a secure way. This can violate a number of security requirements, 1307 as the compromise of any element in the group means that the attacker 1308 has the ability to control the entire group. Even worse, the group 1309 may not be limited in scope, and hence the same keying material might 1310 be used not only for light bulbs but for locks as well. Therefore, 1311 extreme care must be taken in situations where the security 1312 requirements are relaxed, so that deployment of the system will 1313 always be done safely. 1315 Authors' Addresses 1317 Marco Tiloca 1318 RISE SICS AB 1319 Isafjordsgatan 22 1320 Kista SE-16440 Stockholm 1321 Sweden 1323 Email: marco.tiloca@ri.se 1325 Goeran Selander 1326 Ericsson AB 1327 Torshamnsgatan 23 1328 Kista SE-16440 Stockholm 1329 Sweden 1331 Email: goran.selander@ericsson.com 1332 Francesca Palombini 1333 Ericsson AB 1334 Torshamnsgatan 23 1335 Kista SE-16440 Stockholm 1336 Sweden 1338 Email: francesca.palombini@ericsson.com 1340 Jiye Park 1341 Universitaet Duisburg-Essen 1342 Schuetzenbahn 70 1343 Essen 45127 1344 Germany 1346 Email: ji-ye.park@uni-due.de