idnits 2.17.1 draft-ietf-core-oscore-groupcomm-08.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 (April 06, 2020) is 1481 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 (-11) exists of draft-ietf-core-groupcomm-bis-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-800-56A' ** Downref: Normative reference to an Informational RFC: RFC 6979 ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Downref: Normative reference to an Informational RFC: RFC 8032 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-18) exists of draft-ietf-ace-key-groupcomm-05 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-05 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-33 == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-09 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 3 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 AB 4 Intended status: Standards Track G. Selander 5 Expires: October 8, 2020 F. Palombini 6 Ericsson AB 7 J. Park 8 Universitaet Duisburg-Essen 9 April 06, 2020 11 Group OSCORE - Secure Group Communication for CoAP 12 draft-ietf-core-oscore-groupcomm-08 14 Abstract 16 This document defines Group Object Security for Constrained RESTful 17 Environments (Group OSCORE), providing end-to-end security of CoAP 18 messages exchanged between members of a group, e.g. using IP 19 multicast. In particular, the described approach defines how OSCORE 20 should be used in a group communication setting to provide source 21 authentication for CoAP group requests, sent by a client to multiple 22 servers, and the corresponding CoAP responses. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 8, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 60 2. Security Context . . . . . . . . . . . . . . . . . . . . . . 7 61 2.1. Common Context . . . . . . . . . . . . . . . . . . . . . 7 62 2.2. Sender Context and Recipient Context . . . . . . . . . . 8 63 2.3. The Group Manager . . . . . . . . . . . . . . . . . . . . 9 64 2.4. Management of Group Keying Material . . . . . . . . . . . 10 65 2.5. Exhaustion of Partial IV Values . . . . . . . . . . . . . 11 66 3. Pairwise Keys . . . . . . . . . . . . . . . . . . . . . . . . 12 67 3.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . 12 68 3.2. Usage of Sequence Numbers . . . . . . . . . . . . . . . . 13 69 3.3. Note on Implementation . . . . . . . . . . . . . . . . . 13 70 4. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.1. Counter Signature . . . . . . . . . . . . . . . . . . . . 14 72 4.2. The 'kid' and 'kid context' parameters . . . . . . . . . 14 73 4.3. external_aad . . . . . . . . . . . . . . . . . . . . . . 15 74 4.3.1. external_aad for Encryption . . . . . . . . . . . . . 15 75 4.3.2. external_aad for Signing . . . . . . . . . . . . . . 16 76 5. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 17 77 5.1. Examples of Compressed COSE Objects . . . . . . . . . . . 17 78 6. Message Binding, Sequence Numbers, Freshness and Replay 79 Protection . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 6.1. Synchronization of Sender Sequence Numbers . . . . . . . 19 81 7. Message Processing . . . . . . . . . . . . . . . . . . . . . 19 82 7.1. Protecting the Request . . . . . . . . . . . . . . . . . 20 83 7.1.1. Supporting Observe . . . . . . . . . . . . . . . . . 21 84 7.2. Verifying the Request . . . . . . . . . . . . . . . . . . 21 85 7.2.1. Supporting Observe . . . . . . . . . . . . . . . . . 22 86 7.3. Protecting the Response . . . . . . . . . . . . . . . . . 22 87 7.3.1. Supporting Observe . . . . . . . . . . . . . . . . . 23 88 7.4. Verifying the Response . . . . . . . . . . . . . . . . . 23 89 7.4.1. Supporting Observe . . . . . . . . . . . . . . . . . 24 90 8. Responsibilities of the Group Manager . . . . . . . . . . . . 24 91 9. Optimized Mode . . . . . . . . . . . . . . . . . . . . . . . 25 92 9.1. Optimized Request . . . . . . . . . . . . . . . . . . . . 25 93 9.1.1. Optimized Compressed Request . . . . . . . . . . . . 25 94 9.2. Optimized Response . . . . . . . . . . . . . . . . . . . 26 95 9.2.1. Optimized Compressed Response . . . . . . . . . . . . 26 96 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 97 10.1. Group-level Security . . . . . . . . . . . . . . . . . . 27 98 10.2. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 28 99 10.3. Management of Group Keying Material . . . . . . . . . . 28 100 10.4. Update of Security Context and Key Rotation . . . . . . 29 101 10.4.1. Late Update on the Sender . . . . . . . . . . . . . 29 102 10.4.2. Late Update on the Recipient . . . . . . . . . . . . 30 103 10.5. Collision of Group Identifiers . . . . . . . . . . . . . 30 104 10.6. Cross-group Message Injection . . . . . . . . . . . . . 30 105 10.7. Group OSCORE for Unicast Requests . . . . . . . . . . . 32 106 10.8. End-to-end Protection . . . . . . . . . . . . . . . . . 33 107 10.9. Security Context Establishment . . . . . . . . . . . . . 33 108 10.10. Master Secret . . . . . . . . . . . . . . . . . . . . . 34 109 10.11. Replay Protection . . . . . . . . . . . . . . . . . . . 34 110 10.12. Client Aliveness . . . . . . . . . . . . . . . . . . . . 35 111 10.13. Cryptographic Considerations . . . . . . . . . . . . . . 35 112 10.14. Message Segmentation . . . . . . . . . . . . . . . . . . 36 113 10.15. Privacy Considerations . . . . . . . . . . . . . . . . . 36 114 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 115 11.1. Counter Signature Parameters Registry . . . . . . . . . 37 116 11.2. Counter Signature Key Parameters Registry . . . . . . . 40 117 11.3. OSCORE Flag Bits Registry . . . . . . . . . . . . . . . 42 118 11.4. Expert Review Instructions . . . . . . . . . . . . . . . 42 119 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 120 12.1. Normative References . . . . . . . . . . . . . . . . . . 43 121 12.2. Informative References . . . . . . . . . . . . . . . . . 44 122 Appendix A. Assumptions and Security Objectives . . . . . . . . 46 123 A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 47 124 A.2. Security Objectives . . . . . . . . . . . . . . . . . . . 48 125 Appendix B. List of Use Cases . . . . . . . . . . . . . . . . . 49 126 Appendix C. Example of Group Identifier Format . . . . . . . . . 51 127 Appendix D. Set-up of New Endpoints . . . . . . . . . . . . . . 52 128 Appendix E. Examples of Synchronization Approaches . . . . . . . 53 129 E.1. Best-Effort Synchronization . . . . . . . . . . . . . . . 53 130 E.2. Baseline Synchronization . . . . . . . . . . . . . . . . 53 131 E.3. Challenge-Response Synchronization . . . . . . . . . . . 54 132 Appendix F. No Verification of Signatures . . . . . . . . . . . 56 133 Appendix G. Pairwise Mode . . . . . . . . . . . . . . . . . . . 57 134 G.1. Pre-Requirements . . . . . . . . . . . . . . . . . . . . 57 135 G.2. Pairwise Protected Request . . . . . . . . . . . . . . . 57 136 G.3. Pairwise Protected Response . . . . . . . . . . . . . . . 58 137 Appendix H. Document Updates . . . . . . . . . . . . . . . . . . 58 138 H.1. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 58 139 H.2. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 60 140 H.3. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 60 141 H.4. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 61 142 H.5. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 61 143 H.6. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 62 144 H.7. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 63 145 H.8. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 64 146 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 64 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 149 1. Introduction 151 The Constrained Application Protocol (CoAP) [RFC7252] is a web 152 transfer protocol specifically designed for constrained devices and 153 networks [RFC7228]. Group communication for CoAP 154 [I-D.ietf-core-groupcomm-bis] addresses use cases where deployed 155 devices benefit from a group communication model, for example to 156 reduce latencies, improve performance and reduce bandwidth 157 utilization. Use cases include lighting control, integrated building 158 control, software and firmware updates, parameter and configuration 159 updates, commissioning of constrained networks, and emergency 160 multicast (see Appendix B). This specification defines the security 161 protocol for Group communication for CoAP 162 [I-D.ietf-core-groupcomm-bis]. 164 Object Security for Constrained RESTful Environments (OSCORE) 165 [RFC8613] describes a security protocol based on the exchange of 166 protected CoAP messages. OSCORE builds on CBOR Object Signing and 167 Encryption (COSE) [RFC8152] and provides end-to-end encryption, 168 integrity, replay protection and binding of response to request 169 between a sender and a recipient, independent of transport also in 170 the presence of intermediaries. To this end, a CoAP message is 171 protected by including its payload (if any), certain options, and 172 header fields in a COSE object, which replaces the authenticated and 173 encrypted fields in the protected message. 175 This document defines Group OSCORE, providing the same end-to-end 176 security properties as OSCORE in the case where CoAP requests have 177 multiple recipients. In particular, the described approach defines 178 how OSCORE should be used in a group communication setting to provide 179 source authentication for CoAP group requests, sent by a client to 180 multiple servers, and the corresponding CoAP responses. 182 Group OSCORE provides source authentication of CoAP messages, by 183 means of two possible methods. The first method relies on a digital 184 signature produced with the private key of the sender and embedded in 185 the protected CoAP message. The second method relies on a symmetric 186 key, which is derived from a pairwise shared secred computed from the 187 asymmetric keys of the message sender and recipient. 189 The second method is intended for one-to-one messages sent in the 190 group. These include all responses, as individually sent by servers, 191 as well as requests addressed to an individual server. For instance, 192 such requests are sent as part of an exchange using the CoAP Echo 193 option [I-D.ietf-core-echo-request-tag], or as part of a block-wise 194 transfer [RFC7959] in the group, after the first block-wise request 195 possibly targeting all servers in the group and including the CoAP 196 Block2 option (see Section 2.3.6 of [I-D.ietf-core-groupcomm-bis]). 198 Just like OSCORE, Group OSCORE is independent of transport layer and 199 works wherever CoAP does. Group communication for CoAP 200 [I-D.ietf-core-groupcomm-bis] uses UDP/IP multicast as the underlying 201 data transport. 203 As with OSCORE, it is possible to combine Group OSCORE with 204 communication security on other layers. One example is the use of 205 transport layer security, such as DTLS [RFC6347], between one client 206 and one proxy (and vice versa), or between one proxy and one server 207 (and vice versa), in order to protect the routing information of 208 packets from observers. Note that DTLS cannot be used to secure 209 messages sent over IP multicast. 211 Group OSCORE defines different modes of operation: 213 o In the signature mode, Group OSCORE requests and responses are 214 digitally signed. The signature mode supports all COSE algorithms 215 as well as signature verification by intermediaries. 217 o The pairwise mode allows two group members to exchange unicast 218 OSCORE requests and responses protected with symmetric keys. 219 These symmetric keys are derived from Diffie-Hellman shared 220 secrets, calculated with the asymmetric keys of the two group 221 members. This allows for shorter integrity tags and therefore 222 lower message overhead. 224 o In the (hybrid) optimized mode, the CoAP requests are digitally 225 signed as in the signature mode, and the CoAP responses are 226 integrity protected with the symmetric key of the pairwise mode. 228 The signature and optimized modes are detailed in the body of this 229 document. The pairwise mode is detailed in Appendix G. Unless 230 otherwise stated, this specification refers to the signature mode. 232 1.1. Terminology 234 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 235 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 236 "OPTIONAL" in this document are to be interpreted as described in BCP 237 14 [RFC2119] [RFC8174] when, and only when, they appear in all 238 capitals, as shown here. 240 Readers are expected to be familiar with the terms and concepts 241 described in CoAP [RFC7252] including "endpoint", "client", "server", 242 "sender" and "recipient"; group communication for CoAP 243 [I-D.ietf-core-groupcomm-bis]; COSE and counter signatures [RFC8152]. 245 Readers are also expected to be familiar with the terms and concepts 246 for protection and processing of CoAP messages through OSCORE, such 247 as "Security Context" and "Master Secret", defined in [RFC8613]. 249 Terminology for constrained environments, such as "constrained 250 device", "constrained-node network", is defined in [RFC7228]. 252 This document refers also to the following terminology. 254 o Keying material: data that is necessary to establish and maintain 255 secure communication among endpoints. This includes, for 256 instance, keys and IVs [RFC4949]. 258 o Group: a set of endpoints that share group keying material and 259 security parameters (Common Context, see Section 2). Unless 260 specified otherwise, the term group used in this specification 261 refers thus to a "security group", not to be confused with 262 CoAP/network/multicast group or application group. 264 o Group Manager: entity responsible for a group. Each endpoint in a 265 group communicates securely with the respective Group Manager, 266 which is neither required to be an actual group member nor to take 267 part in the group communication. The full list of 268 responsibilities of the Group Manager is provided in Section 8. 270 o Silent server: member of a group that never responds to requests. 271 Given that, for CoAP group communications, messages are normally 272 sent without requesting a confirmation, the idea of a server 273 silently acting on a message is not unreasonable. Note that an 274 endpoint can implement both a silent server and a client, the two 275 roles are independent. An endpoint implementing only a silent 276 server processes only incoming requests, and, in case it supports 277 only the signature mode, it maintains less keying material and 278 especially does not have a Sender Context for the group. 280 o Group Identifier (Gid): identifier assigned to the group. Group 281 Identifiers must be unique within the set of groups of a given 282 Group Manager. 284 o Group request: CoAP request message sent by a client in the group 285 to all servers in that group. 287 o Source authentication: evidence that a received message in the 288 group originated from a specific identified group member. This 289 also provides assurance that the message was not tampered with by 290 anyone, be it a different legitimate group member or an endpoint 291 which is not a group member. 293 2. Security Context 295 Each endpoint registered as member of a group maintains a Security 296 Context as defined in Section 3 of [RFC8613], extended as follows 297 (see Figure 1): 299 o One Common Context, shared by all the endpoints in the group. 300 Three new parameters are included in the Common Context: Counter 301 Signature Algorithm, Counter Signature Parameters and Counter 302 Signature Key Parameters. 304 o One Sender Context, extended with the endpoint's private key. The 305 Sender Context is omitted if the endpoint is configured 306 exclusively as silent server. 308 o One Recipient Context for each endpoint from which messages are 309 received. No Recipient Contexts are maintained as associated to 310 endpoints from which messages are not (expected to be) received. 311 The Recipient Context is extended with the public key of the 312 associated endpoint. 314 +---------------------------+----------------------------------+ 315 | Context Component | New Information Elements | 316 +---------------------------+----------------------------------+ 317 | | Counter Signature Algorithm | 318 | Common Context | Counter Signature Parameters | 319 | | Counter Signature Key Parameters | 320 +---------------------------+----------------------------------+ 321 | Sender Context | Endpoint's own private key | 322 +---------------------------+----------------------------------+ 323 | Each Recipient Context | Public key of the other endpoint | 324 +---------------------------+----------------------------------+ 326 Figure 1: Additions to the OSCORE Security Context 328 2.1. Common Context 330 The ID Context parameter (see Sections 3.3 and 5.1 of [RFC8613]) in 331 the Common Context SHALL contain the Group Identifier (Gid) of the 332 group. The choice of the Gid is application specific. An example of 333 specific formatting of the Gid is given in Appendix C. The 334 application needs to specify how to handle possible collisions 335 between Gids, see Section 10.5. 337 The Counter Signature Algorithm identifies the digital signature 338 algorithm used to compute a counter signature on the COSE object (see 339 Section 4.5 of [RFC8152]). Its value is immutable once the Common 340 Context is established. The used Counter Signature Algorithm MUST be 341 selected among the signing ones defined in the COSE Algorithms 342 Registry (see section 16.4 of [RFC8152]). The EdDSA signature 343 algorithm Ed25519 [RFC8032] is mandatory to implement. If Elliptic 344 Curve Digital Signature Algorithm (ECDSA) is used, it is RECOMMENDED 345 that implementations implement "deterministic ECDSA" as specified in 346 [RFC6979]. 348 The Counter Signature Parameters identifies the parameters associated 349 to the digital signature algorithm specified in the Counter Signature 350 Algorithm. This parameter MAY be empty and is immutable once the 351 Common Context is established. The exact structure of this parameter 352 depends on the value of Counter Signature Algorithm, and is defined 353 in the Counter Signature Parameters Registry (see Section 11.1), 354 where each entry indicates a specified structure of the Counter 355 Signature Parameters. 357 The Counter Signature Key Parameters identifies the parameters 358 associated to the keys used with the digital signature algorithm 359 specified in the Counter Signature Algorithm. This parameter MAY be 360 empty and is immutable once the Common Context is established. The 361 exact structure of this parameter depends on the value of Counter 362 Signature Algorithm, and is defined in the Counter Signature Key 363 Parameters Registry (see Section 11.2), where each entry indicates a 364 specified structure of the Counter Signature Key Parameters. 366 2.2. Sender Context and Recipient Context 368 OSCORE specifies the derivation of Sender Context and Recipient 369 Context, specifically Sender/Recipient Keys and Common IV, from a set 370 of input parameters (see Section 3.2 of [RFC8613]). This derivation 371 applies also to Group OSCORE, and the mandatory-to-implement HKDF and 372 AEAD algorithms are the same as in [RFC8613]. However, for Group 373 OSCORE the Sender Context and Recipient Context additionally contain 374 asymmetric keys. 376 The Sender Context needs to be configured with the private key of the 377 endpoint. The private key is used to generate a signature (see 378 Section 4) included in the sent OSCORE message. How the private key 379 is established is out of scope for this specification. 381 Each Recipient Context needs to be configured with the public key of 382 the associated endpoint. The public key is used to verify a 383 signature (see Section 4) included in the received OSCORE message. 385 The input parameters for deriving the Recipient Context parameters 386 and the public key of the associated endpoint may be provided to the 387 recipient endpoint upon joining the group. These parameters may 388 alternatively be acquired at a later time, for example the first time 389 a message is received from this particular endpoint in the group (see 390 Section 7.2 and Section 7.4). The received message together with the 391 Common Context contains the necessary information to derive a 392 security context for verifying a message, except for the public key 393 of the associated endpoint. 395 For severely constrained devices, it may be not feasible to 396 simultaneously handle the ongoing processing of a recently received 397 message in parallel with the retrieval of the associated endpoint's 398 public key. Such devices can be configured to drop a received 399 message for which there is no Recipient Context, and retrieve the 400 public key in order to have it available to verify subsequent 401 messages from that endpoint. 403 2.3. The Group Manager 405 Endpoints communicating with Group OSCORE need, in addition to the 406 OSCORE input parameters, also to be provisioned with information 407 about the group(s) and other endpoints in the group(s). 409 The Group Manager is an entity responsible for the group, including 410 the Group Identifier (Gid) used as ID Context, as well as the Sender 411 ID and Recipient ID of the group members (see Section 8). 413 The Group Manager is exclusively in control of the Gid values 414 uniquely assigned to the different groups under its control, as well 415 as of the Sender ID and Recipient ID values uniquely assigned to the 416 members of each of those groups. According to a hierarchical 417 approach, the Gid value assigned to a group is associated to a 418 dedicated space for the values of Sender ID and Recipient ID of the 419 members of that group. In addition, the Group Manager records the 420 public keys of endpoints joining a group, and provides information 421 about the group and its members to other members. 423 An endpoint receives the Group Identifier and OSCORE input 424 parameters, including its own Sender ID, from the Group Manager upon 425 joining the group. That Sender ID is valid only within that group, 426 and is unique within the group. Endpoints which are configured only 427 as silent servers do not have a Sender ID. 429 A group member can retrieve from the Group Manager the public key and 430 other information associated to another group member, with which it 431 can generate the corresponding Recipient Context. An application can 432 configure a group member to asynchronously retrieve information about 433 Recipient Contexts, e.g. by Observing [RFC7641] the Group Manager to 434 get updates on the group membership. 436 According to this specification, it is RECOMMENDED to use a Group 437 Manager as described in [I-D.ietf-ace-key-groupcomm-oscore], where 438 the join process is based on the ACE framework for authentication and 439 authorization in constrained environments [I-D.ietf-ace-oauth-authz]. 440 Further details about how public keys can be handled and retrieved in 441 the group is out of the scope of this document. 443 The Group Manager may serve additional entities acting as signature 444 checkers, e.g. intermediary gateways. These entities do not join a 445 group as members, but can retrieve public keys of group members from 446 the Group Manager, in order to verify counter signatures of group 447 messages. A signature checker is required to be authorized for 448 retrieving public keys of members in a specific group from the Group 449 Manager. To this end, the same method mentioned above and based on 450 the ACE framework can be used. 452 2.4. Management of Group Keying Material 454 In order to establish a new Security Context in a group, a new Group 455 Identifier (Gid) for that group and a new value for the Master Secret 456 parameter MUST be distributed. An example of Gid format supporting 457 this operation is provided in Appendix C. When distributing the new 458 Gid and Master Secret, the Group Manager MAY distribute also a new 459 value for the Master Salt parameter, and SHOULD preserve the current 460 value of the Sender ID of each group member. 462 Then, each group member re-derives the keying material stored in its 463 own Sender Context and Recipient Contexts as described in Section 2, 464 using the updated Gid and Master Secret parameter. The Master Salt 465 used for the re-derivations is the updated Master Salt parameter if 466 provided by the Group Manager, or the empty byte string otherwise. 467 From then on, each group member MUST use its latest installed Sender 468 Context to protect outgoing messages. 470 After a new Gid has been distributed, a same Recipient ID ('kid') 471 should not be considered as a persistent and reliable indicator of 472 the same group member. Such an indication can be actually achieved 473 only by using that members's public key. This occurs when verifying 474 countersignatures of received messages (in signature mode), or when 475 verifying messages integrity-protected with pairwise keying material 476 derived from asymmetric keys (in pairwise mode). As a consequence, 477 group members may end up retaining stale Recipient Contexts, that are 478 no longer useful to verify incoming secure messages. 480 In order to alleviate this issue, the Group Manager SHOULD NOT 481 recycle 'kid' values within a same group, especially in the short 482 term. Furthermore, applications may define policies to: i) delete 483 (long-)unused Recipient Contexts and reduce the impact on storage 484 space; as well as ii) check with the Group Manager that an owned 485 public key is currently the one associated to a 'kid' value, after a 486 number of consecutive failed verifications. 488 The distribution of a new Gid and Master Secret may result in 489 temporarily misaligned Security Contexts among group members. In 490 particular, this may result in a group member not able to process 491 messages received right after a new Gid and Master Secret have been 492 distributed. A discussion on practical consequences and possible 493 ways to address them is provided in Section 10.4. 495 If required by the application (see Appendix A.1), it is RECOMMENDED 496 to adopt a group key management scheme, and securely distribute a new 497 value for the Gid and for the Master Secret parameter of the group's 498 Security Context, before a new joining endpoint is added to the group 499 or after a currently present endpoint leaves the group. This is 500 necessary to preserve backward security and forward security in the 501 group, if the application requires it. 503 The specific approach used to distribute the new Gid and Master 504 Secret parameter to the group is out of the scope of this document. 505 However, it is RECOMMENDED that the Group Manager supports the 506 distribution of the new Gid and Master Secret parameter to the group 507 according to the Group Rekeying Process described in 508 [I-D.ietf-ace-key-groupcomm-oscore]. 510 2.5. Exhaustion of Partial IV Values 512 An endpoint can eventually exhaust its own Sender Sequence Number, 513 which is incremented after sending each new message including a 514 Partial IV. This is the case for all group requests, all Observe 515 notifications [RFC7641] and, optionally, any other response. 517 If an implementation's integers only support wrapping addition, the 518 implementation MUST detect a wrap-around of the Sender Sequence 519 Number value and treat that as exhausted instead. 521 Upon exhausting its own Sender Sequence Number, the endpoint MUST NOT 522 transmit further messages for that group until it has derived a new 523 Sender Context, in order to avoid reusing nonces with the same keys. 525 Furthermore, the endpoint SHOULD inform the Group Manager, that can 526 take one of the following actions: 528 o The Group Manager renews the Security Context in the group (see 529 Section 2.4). 531 o The Group Manager provides a new Sender ID value to the endpoint 532 that has experienced the exhaustion. Then, the endpoint derives a 533 new Sender Context using the new Sender ID, as described in 534 Section 3.2 of [RFC8613]. 536 In either case, same considerations from Section 2.4 hold about 537 possible retaining of stale Recipient Contexts. 539 3. Pairwise Keys 541 Certain signature schemes, such as EdDSA and ECDSA, support a secure 542 combined signature and encryption scheme. This section specifies the 543 derivation of pairwise encryption keys for use in the pairwise and 544 optimized modes of Group OSCORE. 546 3.1. Key Derivation 548 Two group members can derive a symmetric pairwise key, from their 549 Sender/Recipient Key and a static-static Diffe-Hellman shared secret 550 [NIST-800-56A]. The key derivation is as follows, and uses the same 551 construction used in Section 3.2.1 of [RFC8613]. 553 Pairwise key = HKDF(Sender/Recipient Key, Shared Secret, info, L) 555 where: 557 o The Sender/Recipient key is the Sender Key of the sender, i.e. the 558 Recipient Key that the recipient stores in its own Recipient 559 Context corresponding to the sender. 561 o The Shared Secret is computed as a static-static Diffie-Hellman 562 shared secret [NIST-800-56A], where the sender uses its own 563 private key and the recipient's public key, while the recipient 564 uses its own private key and the senders's public key. The Shared 565 Secret may be stored in memory, rather than recomputed each time 566 it is needed. 568 o info and L are defined as in Section 3.2.1 of [RFC8613]. 570 The security of using the same key pair for Diffie-Hellman and for 571 signing is proven in [Degabriele]. The derivation of pairwise keys 572 defined above is compatible with ECDSA and EdDSA asymmetric keys, but 573 is not compatible with RSA asymmetric keys. 575 If EdDSA asymmetric keys are used, the Edward coordinates are mapped 576 to Montgomery coordinates using the maps defined in Sections 4.1 and 577 4.2 of [RFC7748], before using the X25519 and X448 functions defined 578 in Section 5 of [RFC7748]. 580 After completing the establishment of a new Security Context (see 581 Section 2.4), every group member MUST delete all its pairwise keys. 582 Since new Sender/Recipient keys are derived from the new group keying 583 material (see Section 2.2), every group member MUST use such new 584 Sender/Recipient keys when possibly deriving new pairwise keys. 586 As long as any two group members preserve the same asymmetric keys, 587 the Diffie-Hellman shared secret does not change across updates of 588 the group keying material. 590 3.2. Usage of Sequence Numbers 592 When using any of its pairwise keys, a sender endpoint MUST use the 593 current fresh value of its own Sender Sequence Number, from its own 594 Sender Context (see Section 2.2). That is, the same Sender Sequence 595 Number space is used for all outgoing messages sent to the group and 596 protected with Group OSCORE, thus limiting both storage and 597 complexity. 599 On the other hand, when combining one-to-many and one-to-one 600 communication in the group, this may result in the Partial IV values 601 moving forward more often. Fundamentally, this is due to the fact 602 that not all the recipients receive all messages from a given sender. 603 For instance, requests sent over multicast (in signature mode) are 604 addressed to the whole group, while requests sent over unicast (in 605 signature mode or pairwise mode) are not. 607 As a consequence, replay checks may be invoked more often on the 608 recipient side, where larger replay windows should be considered. 610 3.3. Note on Implementation 612 In order to optimize performance, an endpoint A may derive a pairwise 613 key used with an endpoint B in the OSCORE group only once, and then 614 store it in its own Security Context for future retrieval. This can 615 work as follows. 617 Endpoint A can have a Pairwise Sender Context associated to B, within 618 its own Sender Context. This Pairwise Sender Context includes: 620 o The Recipient ID of B for A, i.e. the Sender ID of B. 622 o The Pairwise Key derived as defined in Section 3, with A acting as 623 sender and B acting as recipient. 625 More generally, A has one of such Paiwise Sender Contexts within its 626 own Sender Context, for each different intended recipient. 628 Furthermore, A can additionally store in its own Recipient Context 629 associated to B the Pairwise Key to use for incoming traffic from B. 630 That is, this Pairwise Key is derived as defined in Section 3, with A 631 acting as recipient and B acting as sender. 633 4. The COSE Object 635 Building on Section 5 of [RFC8613], this section defines how to use 636 COSE [RFC8152] to wrap and protect data in the original message. 637 OSCORE uses the untagged COSE_Encrypt0 structure with an 638 Authenticated Encryption with Associated Data (AEAD) algorithm. For 639 the signature mode of Group OSCORE the following modifications apply. 641 4.1. Counter Signature 643 The 'unprotected' field MUST additionally include the following 644 parameter: 646 o CounterSignature0 : its value is set to the counter signature of 647 the COSE object, computed by the sender as described in 648 Appendix A.2 of [RFC8152], by using its own private key and 649 according to the Counter Signature Algorithm and Counter Signature 650 Parameters in the Security Context. In particular, the 651 Sig_structure contains the external_aad as defined in 652 Section 4.3.2 and the ciphertext of the COSE_Encrypt0 object as 653 payload. 655 4.2. The 'kid' and 'kid context' parameters 657 The value of the 'kid' parameter in the 'unprotected' field of 658 response messages MUST be set to the Sender ID of the endpoint 659 transmitting the message. That is, unlike in [RFC8613], the 'kid' 660 parameter is always present in all messages, i.e. both requests and 661 responses. 663 The value of the 'kid context' parameter in the 'unprotected' field 664 of requests messages MUST be set to the ID Context, i.e. the Group 665 Identifier value (Gid) of the group's Security Context. That is, 666 unlike in [RFC8613], the 'kid context' parameter is always present in 667 requests. 669 4.3. external_aad 671 The external_aad of the Additional Authenticated Data (AAD) is built 672 differently. In particular, it has one structure used for the 673 encryption process producing the ciphertext, and a second structure 674 used for the signing process producing the counter signature. 676 4.3.1. external_aad for Encryption 678 The first external_aad structure used for the encryption process 679 producing the ciphertext (see Section 5.3 of [RFC8152]) includes also 680 the counter signature algorithm and related parameters used to sign 681 messages. In particular, compared with Section 5.4 of [RFC8613], the 682 'algorithms' array in the aad_array MUST also include: 684 o 'alg_countersign', which contains the Counter Signature Algorithm 685 from the Common Context (see Section 2). This parameter has the 686 value specified in the "Value" field of the Counter Signature 687 Parameters Registry (see Section 11.1) for this counter signature 688 algorithm. 690 o 'par_countersign', which contains the Counter Signature Parameters 691 from the Common Context (see Section 2). This parameter contains 692 the counter signature parameters encoded as specified in the 693 "Parameters" field of the Counter Signature Parameters Registry 694 (see Section 11.1), for the used counter signature algorithm. If 695 the Counter Signature Parameters in the Common Context is empty, 696 'par_countersign' MUST be encoding the CBOR simple value Null. 698 o 'par_countersign_key', which contains the Counter Signature Key 699 Parameters from the Common Context (see Section 2). This 700 parameter contains the counter signature key parameters encoded as 701 specified in the "Parameters" field of the Counter Signature Key 702 Parameters Registry (see Section 11.2), for the used counter 703 signature algorithm. If the Counter Signature Key Parameters in 704 the Common Context is empty, 'par_countersign_key' MUST be 705 encoding the CBOR simple value Null. 707 Thus, the following external_aad structure is used for the encryption 708 process producing the ciphertext (see Section 5.3 of [RFC8152]). 710 external_aad = bstr .cbor aad_array 712 aad_array = [ 713 oscore_version : uint, 714 algorithms : [alg_aead : int / tstr, 715 alg_countersign : int / tstr, 716 par_countersign : any / nil, 717 par_countersign_key : any / nil], 718 request_kid : bstr, 719 request_piv : bstr, 720 options : bstr 721 ] 723 4.3.2. external_aad for Signing 725 The second external_aad structure used for the signing process 726 producing the counter signature as defined below includes also: 728 o the counter signature algorithm and related parameters used to 729 sign messages, encoded as in the external_aad structure defined in 730 Section 4.3.1; 732 o the value of the OSCORE Option included in the OSCORE message, 733 encoded as a binary string. 735 Thus, the following external_aad structure is used for the signing 736 process producing the counter signature, as defined below. 738 external_aad = bstr .cbor aad_array 740 aad_array = [ 741 oscore_version : uint, 742 algorithms : [alg_aead : int / tstr, 743 alg_countersign : int / tstr, 744 par_countersign : any / nil, 745 par_countersign_key : any / nil], 746 request_kid : bstr, 747 request_piv : bstr, 748 options : bstr, 749 OSCORE_option: bstr 750 ] 752 Note for implementation: this requires the value of the OSCORE option 753 to be fully ready, before starting the signing process. Also, this 754 requires that the aad_array is long enough to contain the longest 755 possible OSCORE option. 757 5. OSCORE Header Compression 759 The OSCORE header compression defined in Section 6 of [RFC8613] is 760 used, with the following differences. 762 o The payload of the OSCORE message SHALL encode the ciphertext of 763 the COSE object. In the signature mode as well as in the 764 optimized compressed requests of the optimized mode (see 765 Section 9.1.1), the ciphertext above is concatenated with the 766 value of the CounterSignature0 of the COSE object, computed as 767 described in Section 4.1. 769 o This specification defines the usage of the sixth least 770 significant bit, namely the Pairwise Flag bit, in the first byte 771 of the OSCORE option containing the OSCORE flag bits. This flag 772 bit is registered in Section 11.3 of this specification. 774 o The Pairwise Flag bit is set to 1 if the OSCORE message is 775 protected using pairwise keying material, which is shared with a 776 single group member as single intended recipient and derived as 777 defined in Section 3. This is used, for instance, to send 778 responses with the optimized mode defined in Section 9. In any 779 other case, especially when the OSCORE message is protected as per 780 Section 7.1 and Section 7.3, this bit MUST be set to 0. 782 If any of the following conditions holds, a recipient MUST discard 783 an incoming OSCORE message with the Pairwise Flag bit set to 1: 785 * The recipient does not support this feature, i.e. it is not 786 capable or willing to process OSCORE messages protected using 787 pairwise keying material. 789 * The recipient can not retrieve a Security Context which is both 790 valid to process the message and also associated to an OSCORE 791 group. 793 5.1. Examples of Compressed COSE Objects 795 This section covers a list of OSCORE Header Compression examples for 796 group requests and responses, with Group OSCORE used in signature 797 mode. 799 The examples assume that the COSE_Encrypt0 object is set (which means 800 the CoAP message and cryptographic material is known). Note that the 801 examples do not include the full CoAP unprotected message or the full 802 Security Context, but only the input necessary to the compression 803 mechanism, i.e. the COSE_Encrypt0 object. The output is the 804 compressed COSE object as defined in Section 5 and divided into two 805 parts, since the object is transported in two CoAP fields: OSCORE 806 option and payload. 808 The examples assume that the label for the new kid context defined in 809 [RFC8613] has value 10. The examples also assume that the plaintext 810 (see Section 5.3 of [RFC8613]) is 6 bytes long, and that the AEAD tag 811 is 8 bytes long, hence resulting in a ciphertext which is 14 bytes 812 long. Finally, COUNTERSIGN is the CounterSignature0 byte string as 813 described in Section 4 and is 64 bytes long. 815 1. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = 816 0x25, Partial IV = 5 and kid context = 0x44616c 818 Before compression (96 bytes): 820 [ 821 h'', 822 { 4:h'25', 6:h'05', 10:h'44616c', 9:COUNTERSIGN }, 823 h'aea0155667924dff8a24e4cb35b9' 824 ] 826 After compression (85 bytes): 828 Flag byte: 0b00011001 = 0x19 830 Option Value: 19 05 03 44 61 6c 25 (7 bytes) 832 Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 COUNTERSIGN 833 (14 bytes + size of COUNTERSIGN) 835 1. Response with ciphertext = 0x60b035059d9ef5667c5a0710823b, kid = 836 0x52 and no Partial IV. 838 Before compression (88 bytes): 840 [ 841 h'', 842 { 4:h'52', 9:COUNTERSIGN }, 843 h'60b035059d9ef5667c5a0710823b' 844 ] 845 After compression (80 bytes): 847 Flag byte: 0b00001000 = 0x08 849 Option Value: 08 52 (2 bytes) 851 Payload: 60 b0 35 05 9d 9e f5 66 7c 5a 07 10 82 3b COUNTERSIGN 852 (14 bytes + size of COUNTERSIGN) 854 6. Message Binding, Sequence Numbers, Freshness and Replay Protection 856 The requirements and properties described in Section 7 of [RFC8613] 857 also apply to OSCORE used in group communication. In particular, 858 group OSCORE provides message binding of responses to requests, which 859 provides relative freshness of responses, and replay protection of 860 requests. 862 6.1. Synchronization of Sender Sequence Numbers 864 Upon joining the group, new servers are not aware of the Sender 865 Sequence Number values currently used by different clients to 866 transmit group requests. This means that, when such servers receive 867 a secure group request from a given client for the first time, they 868 are not able to verify if that request is fresh and has not been 869 replayed or (purposely) delayed. The same holds when a server loses 870 synchronization with Sender Sequence Numbers of clients, for instance 871 after a device reboot. 873 The exact way to address this issue is application specific, and 874 depends on the particular use case and its synchronization 875 requirements. The list of methods to handle synchronization of 876 Sender Sequence Numbers is part of the group communication policy, 877 and different servers can use different methods. 879 Appendix E describes three possible approaches that can be considered 880 for synchronization of sequence numbers. 882 7. Message Processing 884 Each request message and response message is protected and processed 885 as specified in [RFC8613], with the modifications described in the 886 following sections. In particular, the following sections refer to 887 the signature mode of Group OSCORE, while the optimized mode and the 888 pairwise mode are described in Section 9 and Appendix G, 889 respectively. 891 The following security objectives are fulfilled, as further discussed 892 in Appendix A.2: data replay protection, group-level data 893 confidentiality, source authentication and message integrity. 895 As per [RFC7252][I-D.ietf-core-groupcomm-bis], group requests sent 896 over multicast MUST be Non-Confirmable, and thus cannot be 897 retransmitted by the CoAP messaging layer. Instead, applications 898 should store such outgoing messages for a pre-defined, sufficient 899 amount of time, in order to correctly perform possible 900 retransmissions at the application layer. However, this does not 901 prevent the acknowledgment of Confirmable group requests in non- 902 multicast environments. Besides, according to Section 5.2.3 of 903 [RFC7252], responses to Non-Confirmable group requests SHOULD be also 904 Non-Confirmable. However, endpoints MUST be prepared to receive 905 Confirmable responses in reply to a Non-Confirmable group request. 907 Furthermore, endpoints in the group locally perform error handling 908 and processing of invalid messages according to the same principles 909 adopted in [RFC8613]. However, a recipient MUST stop processing and 910 silently reject any message which is malformed and does not follow 911 the format specified in Section 4, or which is not cryptographically 912 validated in a successful way. In either case, it is RECOMMENDED 913 that the recipient does not send back any error message. This 914 prevents servers from replying with multiple error messages to a 915 client sending a group request, so avoiding the risk of flooding and 916 possibly congesting the group. 918 7.1. Protecting the Request 920 A client transmits a secure group request as described in Section 8.1 921 of [RFC8613], with the following modifications. 923 o In step 2, the 'algorithms' array in the Additional Authenticated 924 Data is modified as described in Section 4 of this specification. 926 o In step 4, the encryption of the COSE object is modified as 927 described in Section 4 of this specification. The encoding of the 928 compressed COSE object is modified as described in Section 5 of 929 this specification. 931 o In step 5, the counter signature is computed and the format of the 932 OSCORE message is modified as described in Section 4 and Section 5 933 of this specification. In particular, the payload of the OSCORE 934 message includes also the counter signature. 936 7.1.1. Supporting Observe 938 If Observe [RFC7641] is supported, for each newly started 939 observation, the client MUST store the value of the 'kid' parameter 940 from the original Observe request. 942 The client MUST NOT update the stored value, even in case it is 943 individually rekeyed and receives a new Sender ID from the Group 944 Manager (see Section 2.5). 946 7.2. Verifying the Request 948 Upon receiving a secure group request, a server proceeds as described 949 in Section 8.2 of [RFC8613], with the following modifications. 951 o In step 2, the decoding of the compressed COSE object follows 952 Section 5 of this specification. In particular: 954 * If the Pairwise Flag bit is set to 1, and the server discards 955 the request due to not supporting this feature or not 956 retrieving a Security Context associated to the OSCORE group, 957 the server MAY respond with a 4.02 (Bad Option) error. When 958 doing so, the server MAY set an Outer Max-Age option with value 959 zero, and MAY include a descriptive string as diagnostic 960 payload. 962 * If the received Recipient ID ('kid') does not match with any 963 Recipient Context for the retrieved Gid ('kid context'), then 964 the server MAY create a new Recipient Context and initializes 965 it according to Section 3 of [RFC8613], also retrieving the 966 client's public key. Such a configuration is application 967 specific. If the application does not specify dynamic 968 derivation of new Recipient Contexts, then the server SHALL 969 stop processing the request. 971 o In step 4, the 'algorithms' array in the Additional Authenticated 972 Data is modified as described in Section 4 of this specification. 974 o In step 6, the server also verifies the counter signature using 975 the public key of the client from the associated Recipient 976 Context. If the signature verification fails, the server MAY 977 reply with a 4.00 (Bad Request) response. 979 o Additionally, if the used Recipient Context was created upon 980 receiving this group request and the message is not verified 981 successfully, the server MAY delete that Recipient Context. Such 982 a configuration, which is specified by the application, would 983 prevent attackers from overloading the server's storage and 984 creating processing overhead on the server. 986 A server SHOULD NOT process a request if the received Recipient ID 987 ('kid') is equal to its own Sender ID in its own Sender Context. 989 7.2.1. Supporting Observe 991 If Observe [RFC7641] is supported, for each newly started 992 observation, the server MUST store the value of the 'kid' parameter 993 from the original Observe request. 995 The server MUST NOT update the stored value, even in case the 996 observer client is individually rekeyed and starts using a new Sender 997 ID received from the Group Manager (see Section 2.5). 999 7.3. Protecting the Response 1001 A server that has received a secure group request may reply with a 1002 secure response, which is protected as described in Section 8.3 of 1003 [RFC8613], with the following modifications. 1005 o In step 2, the 'algorithms' array in the Additional Authenticated 1006 Data is modified as described in Section 4 of this specification. 1008 o In step 4, the encryption of the COSE object is modified as 1009 described in Section 4 of this specification. The encoding of the 1010 compressed COSE object is modified as described in Section 5 of 1011 this specification. 1013 o In step 5, the counter signature is computed and the format of the 1014 OSCORE mesage is modified as described in Section 5 of this 1015 specification. In particular, the payload of the OSCORE message 1016 includes also the counter signature. 1018 Note that the server MUST always protect a response by using its own 1019 Sender Context from the latest owned Security Context. 1021 Consistently, upon the establishment of a new Security Context, the 1022 server may end up protecting a response by using a Security Context 1023 different from the one used to protect the group request (see 1024 Section 10.4). In such a case: 1026 o The server MUST encode the Partial IV (Sender Sequence Number in 1027 network byte order), which is set to the Sender Sequence Number of 1028 the server; increment the Sender Sequence Number by one; compute 1029 the AEAD nonce from the Sender ID, Common IV, and Partial IV. 1031 o The server MUST include in the response the 'Partial IV' 1032 parameter, which is set to the encoded Partial IV value above. 1034 o The server SHOULD include in the response the 'kid context' 1035 parameter, which is set to the ID Context of the new Security 1036 Context, i.e. the new Group Identifier (Gid). 1038 7.3.1. Supporting Observe 1040 If Observe [RFC7641] is supported, the server may have ongoing 1041 observations, started by Observe requests protected with an old 1042 Security Context. 1044 After completing the establishment of a new Security Context, the 1045 server MUST protect the following notifications with its own Sender 1046 Context from the new Security Context. 1048 For each ongoing observation, the server SHOULD include in the first 1049 notification protected with the new Security Context also the 'kid 1050 context' parameter, which is set to the ID Context of the new 1051 Security Context, i.e. the new Group Identifier (Gid). It is 1052 OPTIONAL for the server to include the 'kid context' parameter, as 1053 set to the new Gid, also in further following notifications for those 1054 observations. 1056 Furthermore, for each ongoing observation, the server MUST use the 1057 stored value of the 'kid' parameter from the original Observe 1058 request, as value for the 'request_kid' parameter in the two 1059 external_aad structures (see Section 4.3.1 and Section 4.3.2), when 1060 protecting notifications for that observation. 1062 7.4. Verifying the Response 1064 Upon receiving a secure response message, the client proceeds as 1065 described in Section 8.4 of [RFC8613], with the following 1066 modifications. 1068 o In step 2, the decoding of the compressed COSE object is modified 1069 as described in Section 4 of this specification. If the received 1070 Recipient ID ('kid') does not match with any Recipient Context for 1071 the retrieved Gid ('kid context'), then the client MAY create a 1072 new Recipient Context and initializes it according to Section 3 of 1073 [RFC8613], also retrieving the server's public key. If the 1074 application does not specify dynamic derivation of new Recipient 1075 Contexts, then the client SHALL stop processing the response. 1077 o In step 3, the 'algorithms' array in the Additional Authenticated 1078 Data is modified as described in Section 4 of this specification. 1080 o In step 5, the client also verifies the counter signature using 1081 the public key of the server from the associated Recipient 1082 Context. 1084 o Additionally, if the used Recipient Context was created upon 1085 receiving this response and the message is not verified 1086 successfully, the client MAY delete that Recipient Context. Such 1087 a configuration, which is specified by the application, would 1088 prevent attackers from overloading the client's storage and 1089 creating processing overhead on the client. 1091 Note that, as discussed in Section 10.4, a client may receive a 1092 response protected with a Security Context different from the one 1093 used to protect the corresponding group request. 1095 7.4.1. Supporting Observe 1097 If Observe [RFC7641] is supported, for each ongoing observation, the 1098 client MUST use the stored value of the 'kid' parameter from the 1099 original Observe request, as value for the 'request_kid' parameter in 1100 the two external_aad structures (see Section 4.3.1 and 1101 Section 4.3.2), when verifying notifications for that observation. 1103 This ensures that the client can correctly verify notifications, even 1104 in case it is individually rekeyed and starts using a new Sender ID 1105 received from the Group Manager (see Section 2.5). 1107 8. Responsibilities of the Group Manager 1109 The Group Manager is responsible for performing the following tasks: 1111 1. Creating and managing OSCORE groups. This includes the 1112 assignment of a Gid to every newly created group, as well as 1113 ensuring uniqueness of Gids within the set of its OSCORE groups. 1115 2. Defining policies for authorizing the joining of its OSCORE 1116 groups. 1118 3. Handling the join process to add new endpoints as group members. 1120 4. Establishing the Common Context part of the Security Context, 1121 and providing it to authorized group members during the join 1122 process, together with the corresponding Sender Context. 1124 5. Generating and managing Sender IDs within its OSCORE groups, as 1125 well as assigning and providing them to new endpoints during the 1126 join process. This includes ensuring uniqueness of Sender IDs 1127 within each of its OSCORE groups. 1129 6. Defining a communication policy for each of its OSCORE groups, 1130 and signalling it to new endpoints during the join process. 1132 7. Renewing the Security Context of an OSCORE group upon membership 1133 change, by revoking and renewing common security parameters and 1134 keying material (rekeying). 1136 8. Providing the management keying material that a new endpoint 1137 requires to participate in the rekeying process, consistent with 1138 the key management scheme used in the group joined by the new 1139 endpoint. 1141 9. Updating the Gid of its OSCORE groups, upon renewing the 1142 respective Security Context. 1144 10. Acting as key repository, in order to handle the public keys of 1145 the members of its OSCORE groups, and providing such public keys 1146 to other members of the same group upon request. The actual 1147 storage of public keys may be entrusted to a separate secure 1148 storage device. 1150 11. Validating that the format and parameters of public keys of 1151 group members are consistent with the countersignature algorithm 1152 and related parameters used in the respective OSCORE group. 1154 9. Optimized Mode 1156 For use cases that do not require an intermediary performing 1157 signature verification and that use a compatible signature algorithm, 1158 the optimized mode defined in this section provides significant 1159 smaller message sizes and increases the security by making responses 1160 confidential to other group members than the intended recipient. 1162 9.1. Optimized Request 1164 No changes. 1166 9.1.1. Optimized Compressed Request 1168 The OSCORE header compression defined in Section 5 is used, with the 1169 following difference: the payload of the OSCORE message SHALL encode 1170 the ciphertext without the tag, concatenated with the value of the 1171 CounterSignature0 of the COSE object computed as described in 1172 Section 4.1. 1174 The optimized compressed request is compatible with all AEAD 1175 algorithms defined in [RFC8152], but would not be compatible with 1176 AEAD algorithms that do not have a well-defined tag. 1178 9.2. Optimized Response 1180 An optimized response is protected as defined in Section 7.3, with 1181 the following differences. 1183 o The server MUST set to 1 the sixth least significant bit of the 1184 OSCORE flag bits in the OSCORE option, i.e. the Pairwise Flag. 1186 o The COSE_Encrypt0 object included in the optimized response is 1187 encrypted using a symmetric pairwise key K, that the server 1188 derives as defined in Section 3. In particular, the Sender/ 1189 Recipient Key is the Sender Key of the server from its own Sender 1190 Context, i.e. the Recipient Key that the client stores in its own 1191 Recipient Context corresponding to the server. 1193 o The Counter Signature is not computed. That is, unlike defined in 1194 Section 5, the payload of the OSCORE message terminates with the 1195 encoded ciphertext of the COSE object. 1197 Note that no changes are made to the AEAD nonce and AAD. 1199 Upon receiving a response with the Pairwise Flag set to 1, the client 1200 MUST process it as defined in Section 7.4, with the following 1201 differences. 1203 o No countersignature to verify is included. 1205 o The COSE_Encrypt0 object included in the optimized response is 1206 decrypted and verified using the same symmetric pairwise key K, 1207 that the client derives as described above for the server side and 1208 as defined in Section 3. 1210 9.2.1. Optimized Compressed Response 1212 No changes. 1214 10. Security Considerations 1216 The same threat model discussed for OSCORE in Appendix D.1 of 1217 [RFC8613] holds for Group OSCORE. In addition, source authentication 1218 of messages is explicitly ensured by means of counter signatures, as 1219 discussed in Section 10.1. 1221 The same considerations on supporting Proxy operations discussed for 1222 OSCORE in Appendix D.2 of [RFC8613] hold for Group OSCORE. 1224 The same considerations on protected message fields for OSCORE 1225 discussed in Appendix D.3 of [RFC8613] hold for Group OSCORE. 1227 The same considerations on uniqueness of (key, nonce) pairs for 1228 OSCORE discussed in Appendix D.4 of [RFC8613] hold for Group OSCORE. 1229 This is further discussed in Section 10.2. 1231 The same considerations on unprotected message fields for OSCORE 1232 discussed in Appendix D.5 of [RFC8613] hold for Group OSCORE, with 1233 the following difference. The countersignature included in a Group 1234 OSCORE message is computed also over the value of the OSCORE option, 1235 which is part of the Additional Authenticated Data used in the 1236 signing process. This is further discussed in Section 10.6. 1238 As discussed in Section 6.2.3 of [I-D.ietf-core-groupcomm-bis], Group 1239 OSCORE addresses security attacks against CoAP listed in Sections 1240 11.2-11.6 of [RFC7252], especially when mounted over IP multicast. 1242 The rest of this section first discusses security aspects to be taken 1243 into account when using Group OSCORE. Then it goes through aspects 1244 covered in the security considerations of OSCORE (Section 12 of 1245 [RFC8613]), and discusses how they hold when Group OSCORE is used. 1247 10.1. Group-level Security 1249 The signature mode described in Section 7 relies on commonly shared 1250 group keying material to protect communication within a group. This 1251 has the following implications. 1253 o Messages are encrypted at a group level (group-level data 1254 confidentiality), i.e. they can be decrypted by any member of the 1255 group, but not by an external adversary or other external 1256 entities. 1258 o The AEAD algorithm provides only group authentication, i.e. it 1259 ensures that a message sent to a group has been sent by a member 1260 of that group, but not by the alleged sender. This is why source 1261 authentication of messages sent to a group is ensured through a 1262 counter signature, which is computed by the sender using its own 1263 private key and then appended to the message payload. 1265 Instead, the pairwise mode described in Appendix G protects messages 1266 by using pairwise symmetric keys, derived from the static-static 1267 Diffie-Hellman shared secret computed from the asymmetric keys of the 1268 sender and recipient endpoint (see Section 3). Therefore, in the 1269 parwise mode, the AEAD algorithm provides both pairwise data- 1270 confidentiality and source authentication of messages, without using 1271 counter signatures. 1273 Note that, even if an endpoint is authorized to be a group member and 1274 to take part in group communications, there is a risk that it behaves 1275 inappropriately. For instance, it can forward the content of 1276 messages in the group to unauthorized entities. However, in many use 1277 cases, the devices in the group belong to a common authority and are 1278 configured by a commissioner (see Appendix B), which results in a 1279 practically limited risk and enables a prompt detection/reaction in 1280 case of misbehaving. 1282 10.2. Uniqueness of (key, nonce) 1284 The proof for uniqueness of (key, nonce) pairs in Appendix D.4 of 1285 [RFC8613] is also valid in group communication scenarios. That is, 1286 given an OSCORE group: 1288 o Uniqueness of Sender IDs within the group is enforced by the Group 1289 Manager. 1291 o The case A in Appendix D.4 of [RFC8613] concerns all group 1292 requests and responses including a Partial IV (e.g. Observe 1293 notifications). In this case, same considerations from [RFC8613] 1294 apply here as well. 1296 o The case B in Appendix D.4 of [RFC8613] concerns responses not 1297 including a Partial IV (e.g. single response to a group request). 1298 In this case, same considerations from [RFC8613] apply here as 1299 well. 1301 As a consequence, each message encrypted/decrypted with the same 1302 Sender Key is processed by using a different (ID_PIV, PIV) pair. 1303 This means that nonces used by any fixed encrypting endpoint are 1304 unique. Thus, each message is processed with a different (key, 1305 nonce) pair. 1307 10.3. Management of Group Keying Material 1309 The approach described in this specification should take into account 1310 the risk of compromise of group members. In particular, this 1311 document specifies that a key management scheme for secure revocation 1312 and renewal of Security Contexts and group keying material should be 1313 adopted. 1315 Especially in dynamic, large-scale, groups where endpoints can join 1316 and leave at any time, it is important that the considered group key 1317 management scheme is efficient and highly scalable with the group 1318 size, in order to limit the impact on performance due to the Security 1319 Context and keying material update. 1321 10.4. Update of Security Context and Key Rotation 1323 A group member can receive a message shortly after the group has been 1324 rekeyed, and new security parameters and keying material have been 1325 distributed by the Group Manager. 1327 This may result in a client using an old Security Context to protect 1328 a group request, and a server using a different new Security Context 1329 to protect a corresponding response. That is, clients may receive a 1330 response protected with a Security Context different from the one 1331 used to protect the corresponding group request. 1333 In particular, a server may first get a group request protected with 1334 the old Security Context, then install the new Security Context, and 1335 only after that produce a response to send back to the client. Since 1336 a sender always protects an outgoing message using the latest owned 1337 Security Context, the server discussed above protects the possible 1338 response using the new Security Context. Then, the client will 1339 process that response using the new Security Context, provided that 1340 it has installed the new security parameters and keying material 1341 before the message reception. 1343 In case block-wise transfer [RFC7959] is used, the same 1344 considerations from Section 7.2 of [I-D.ietf-ace-key-groupcomm] hold. 1346 Furthermore, as described below, a group rekeying may temporarily 1347 result in misaligned Security Contexts between the sender and 1348 recipient of a same message. 1350 10.4.1. Late Update on the Sender 1352 In this case, the sender protects a message using the old Security 1353 Context, i.e. before having installed the new Security Context. 1354 However, the recipient receives the message after having installed 1355 the new Security Context, hence not being able to correctly process 1356 it. 1358 A possible way to ameliorate this issue is to preserve the old, 1359 recent, Security Context for a maximum amount of time defined by the 1360 application. By doing so, the recipient can still try to process the 1361 received message using the old retained Security Context as second 1362 attempt. This makes particular sense when the recipient is a client, 1363 that would hence be able to process incoming responses protected with 1364 the old, recent, Security Context used to protect the associated 1365 group request. Instead, a recipient server would better and more 1366 simply discard an incoming group request which is not successfully 1367 processed with the new Security Context. 1369 This tolerance preserves the processing of secure messages throughout 1370 a long-lasting key rotation, as group rekeying processes may likely 1371 take a long time to complete, especially in large scale groups. On 1372 the other hand, a former (compromised) group member can abusively 1373 take advantage of this, and send messages protected with the old 1374 retained Security Context. Therefore, a conservative application 1375 policy should not admit the retention of old Security Contexts. 1377 10.4.2. Late Update on the Recipient 1379 In this case, the sender protects a message using the new Security 1380 Context, but the recipient receives that message before having 1381 installed the new Security Context. Therefore, the recipient would 1382 not be able to correctly process the message and hence discards it. 1384 If the recipient installs the new Security Context shortly after that 1385 and the sender endpoint uses CoAP retransmissions, the former will 1386 still be able to receive and correctly process the message. 1388 In any case, the recipient should actively ask the Group Manager for 1389 an updated Security Context according to an application-defined 1390 policy, for instance after a given number of unsuccessfully decrypted 1391 incoming messages. 1393 10.5. Collision of Group Identifiers 1395 In case endpoints are deployed in multiple groups managed by 1396 different non-synchronized Group Managers, it is possible for Group 1397 Identifiers of different groups to coincide. 1399 This does not impair the security of the AEAD algorithm. In fact, as 1400 long as the Master Secret is different for different groups and this 1401 condition holds over time, AEAD keys are different among different 1402 groups. 1404 The entity assigning an IP multicast address may help limiting the 1405 chances to experience such collisions of Group Identifiers. In 1406 particular, it may allow the Group Managers of groups using the same 1407 IP multicast address to share their respective list of assigned Group 1408 Identifiers currently in use. 1410 10.6. Cross-group Message Injection 1412 A same endpoint is allowed to and would likely use the same signature 1413 key in multiple OSCORE groups, possibly administered by different 1414 Group Managers. Also, the same endpoint can register several times 1415 in the same group, getting multiple unique Sender IDs. This requires 1416 that, when a sender endpoint sends a message to an OSCORE group using 1417 a Sender ID, the countersignature included in the message is 1418 explicitly bound also to that group and to the used Sender ID. 1420 To this end, the countersignature of each message protected with 1421 Group OSCORE is computed also over the value of the OSCORE option, 1422 which is part of the Additional Authenticated Data used in the 1423 signing process (see Section 4.3.2). That is, the countersignature 1424 is computed also over: the ID Context (Group ID) and the Partial IV, 1425 which are always present in group requests; as well as the Sender ID 1426 of the message originator, which is always present in all group 1427 requests and responses. 1429 Since the signing process takes as input also the ciphertext of the 1430 COSE_Encrypt0 object, the countersignature is bound not only to the 1431 intended OSCORE group, hence to the triplet (Master Secret, Master 1432 Salt, ID Context), but also to a specific Sender ID in that group and 1433 to its specific symmetric key used for AEAD encryption, hence to the 1434 quartet (Master Secret, Master Salt, ID Context, Sender ID). 1436 This makes it practically infeasible to perform the attack described 1437 below, where a malicious group member injects forged messages to a 1438 different OSCORE group than the originally intended one. Let us 1439 consider: 1441 o Two OSCORE groups G1 and G2, with ID Context (Group ID) Gid1 and 1442 Gid2, respectively. Both G1 and G2 use the AEAD cipher AES-CCM- 1443 16-64-128, i.e. the MAC of the ciphertext is 8 bytes in size. 1445 o A victim endpoint V which is member of both G1 and G2, and uses 1446 the same signature key in both groups. The endpoint V has Sender 1447 ID Sid1 in G1 and Sender ID Sid2 in G2. The pairs (Sid1, Gid1) 1448 and (Sid2, Gid2) identify the same public key of V in G1 and G2, 1449 respectively. 1451 o A malicious endpoint Z is also member of both G1 and G2. Hence, Z 1452 is able to derive the symmetric keys associated to V in G1 and G2. 1454 If countersignatures were not computed also over the value of the 1455 OSCORE option as discussed above, Z can intercept a group message M1 1456 sent by V to G1, and forge a valid signed message M2 to be injected 1457 in G2, making it appear as sent by V and valid to be accepted. 1459 More in detail, Z first intercepts a message M1 sent by V in G1, and 1460 tries to forge a message M2, by changing the value of the OSCORE 1461 option from M1 as follows: the 'kid context' is changed from G1 to 1462 G2; and the 'kid' is changed from Sid1 to Sid2. 1464 If M2 is used as a request message, there is a probability equal to 1465 2^-64 that the same unchanged MAC is successfully verified by using 1466 Sid2 as 'request_kid' and the symmetric key associated to V in G2. 1467 In such a case, the same unchanged signature would be also valid. 1468 Note that Z can check offline if a performed forgery is actually 1469 valid before sending the forged message to G2. That is, this attack 1470 has a complexity of 2^64 offline calculations. 1472 If M2 is used as a response, Z can also change the response Partial 1473 IV, until the same unchanged MAC is successfully verified by using 1474 Sid2 as 'request_kid' and the symmetric key associated to V in G2. 1475 In such a case, the same unchanged signature would be also valid. 1476 Since the Partial IV is 5 bytes in size, this requires 2^40 1477 operations to test all the Partial IVs, which can be done in real- 1478 time. Also, the probability that a single given message M1 can be 1479 used to forge a response M2 for a given request is equal to 2^-24, 1480 since there are more MAC values (8 bytes in size) than Partial IV 1481 values (5 bytes in size). 1483 Note that, by changing the Partial IV as discussed above, any member 1484 of G1 would also be able to forge a valid signed response message M2 1485 to be injected in G1. 1487 10.7. Group OSCORE for Unicast Requests 1489 With reference to the processing defined in Section 7.1 for the 1490 signature mode and in Section 9.1.1 for the optimized mode, it is NOT 1491 RECOMMENDED for a client to use Group OSCORE for securing a request 1492 sent to a single group member over unicast. 1494 If the client uses its own Sender Key to protect a unicast request to 1495 a group member, an on-path adversary can, right then or later on, 1496 redirect that request to one/many different group member(s) over 1497 unicast, or to the whole OSCORE group over multicast. By doing so, 1498 the adversary can induce the target group member(s) to perform 1499 actions intended to one group member only. Note that the adversary 1500 can be external, i.e. (s)he does not need to also be a member of the 1501 OSCORE group. 1503 This is due to the fact that the client is not able to indicate the 1504 single intended recipient in a way which is secure and possible to 1505 process for Group OSCORE on the server side. In particular, Group 1506 OSCORE does not protect network addressing information such as the IP 1507 address of the intended recipient server. It follows that the 1508 server(s) receiving the redirected request cannot assert whether that 1509 was the original intention of the client, and would thus simply 1510 assume so. 1512 With particular reference to block-wise transfers [RFC7959], 1513 Section 2.3.6 of [I-D.ietf-core-groupcomm-bis] points out that, while 1514 an initial request including the CoAP Block2 option can be sent over 1515 multicast, any other request in a transfer has to occur over unicast, 1516 individually addressing the servers in the group. 1518 Additional considerations are discussed in Appendix E.3, with respect 1519 to requests including an Echo Option [I-D.ietf-core-echo-request-tag] 1520 that has to be sent over unicast, as a challenge-response method for 1521 servers to achieve synchronization of client Sender Sequence Numbers. 1523 The impact of such an attack depends especially on the REST method of 1524 the request, i.e. the Inner CoAP Code of the OSCORE request message. 1525 In particular, safe methods such as GET and FETCH would trigger 1526 (several) unintended responses from the targeted server(s), while not 1527 resulting in destructive behavior. On the other hand, non safe 1528 methods such as PUT, POST and PATCH/iPATCH would result in the target 1529 server(s) taking active actions on their resources and possible 1530 cyber-physical environment, with the risk of destructive consequences 1531 and possible implications for safety. 1533 A client may instead use the pairwise mode defined in Appendix G.2, 1534 in order to protect a request sent to a single group member by using 1535 pairwise keying material (see Section 3). This prevents the attack 1536 discussed above by construction, as only the intended server is able 1537 to derive the pairwise keying material used by the client to protect 1538 the request. A client supporting the pairwise mode SHOULD use it to 1539 protect requests sent to a single group member over unicast, instead 1540 of using the signature mode. 1542 10.8. End-to-end Protection 1544 The same considerations from Section 12.1 of [RFC8613] hold for Group 1545 OSCORE. 1547 Additionally, (D)TLS and Group OSCORE can be combined for protecting 1548 message exchanges occurring over unicast. Instead, it is not 1549 possible to combine DTLS and Group OSCORE for protecting message 1550 exchanges where messages are (also) sent over multicast. 1552 10.9. Security Context Establishment 1554 The use of COSE_Encrypt0 and AEAD to protect messages as specified in 1555 this document requires an endpoint to be a member of an OSCORE group. 1557 That is, upon joining the group, the endpoint securely receives from 1558 the Group Manager the necessary input parameters, which are used to 1559 derive the Common Context and the Sender Context (see Section 2). 1560 The Group Manager ensures uniqueness of Sender IDs in the same group. 1562 Each different Recipient Context for decrypting messages from a 1563 particular sender can be derived at runtime, at the latest upon 1564 receiving a message from that sender for the first time. 1566 Countersignatures of group messages are verified by means of the 1567 public key of the respective sender endpoint. Upon nodes' joining, 1568 the Group Manager collects such public keys and MUST verify proof-of- 1569 possession of the respective private key. Later on, a group member 1570 can request from the Group Manager the public keys of other group 1571 members. 1573 The joining process can occur, for instance, as defined in 1574 [I-D.ietf-ace-key-groupcomm-oscore]. 1576 10.10. Master Secret 1578 Group OSCORE derives the Security Context using the same construction 1579 as OSCORE, and by using the Group Identifier of a group as the 1580 related ID Context. Hence, the same required properties of the 1581 Security Context parameters discussed in Section 3.3 of [RFC8613] 1582 hold for this document. 1584 With particular reference to the OSCORE Master Secret, it has to be 1585 kept secret among the members of the respective OSCORE group and the 1586 Group Manager responsible for that group. Also, the Master Secret 1587 must have a good amount of randomness, and the Group Manager can 1588 generate it offline using a good random number generator. This 1589 includes the case where the Group Manager rekeys the group by 1590 generating and distributing a new Master Secret. Randomness 1591 requirements for security are described in [RFC4086]. 1593 10.11. Replay Protection 1595 As in OSCORE, also Group OSCORE relies on sender sequence numbers 1596 included in the COSE message field 'Partial IV' and used to build 1597 AEAD nonces. 1599 Note that the Partial IV of an endpoint does not necessarily grow 1600 monotonically. For instance, upon exhaustion of the endpoint Sender 1601 Sequence Number, the Partial IV also gets exhausted. As discussed in 1602 Section 2.5, this results either in the endpoint being individually 1603 rekeyed and getting a new Sender ID, or in the establishment of a new 1604 Security Context in the group. Therefore, uniqueness of (key, nonce) 1605 pairs (see Section 10.2) is preserved also when a new Security 1606 Context is established. 1608 As discussed in Section 6.1, an endpoint that has just joined a group 1609 is exposed to replay attack, as it is not aware of the sender 1610 sequence numbers currently used by other group members. Appendix E 1611 describes how endpoints can synchronize with senders' sequence 1612 numbers. 1614 Unless exchanges in a group rely only on unicast messages, Group 1615 OSCORE cannot be used with reliable transport. Thus, unless only 1616 unicast messages are sent in the group, it cannot be defined that 1617 only messages with sequence numbers that are equal to the previous 1618 sequence number + 1 are accepted. 1620 The processing of response messages described in Section 7.4 also 1621 ensures that a client accepts a single valid response to a given 1622 request from each replying server, unless CoAP observation is used. 1624 10.12. Client Aliveness 1626 As discussed in Section 12.5 of [RFC8613], a server may use the Echo 1627 option [I-D.ietf-core-echo-request-tag] to verify the aliveness of 1628 the client that originated a received request. This would also allow 1629 the server to (re-)synchronize with the client's sequence number, as 1630 well as to ensure that the request is fresh and has not been replayed 1631 or (purposely) delayed, if it is the first one received from that 1632 client after having joined the group or rebooted (see Appendix E.3). 1634 10.13. Cryptographic Considerations 1636 The same considerations from Section 12.6 of [RFC8613] about the 1637 maximum Sender Sequence Number hold for Group OSCORE. 1639 As discussed in Section 2.5, an endpoint that experiences a 1640 exhaustion of its own Sender Sequence Number MUST NOT transmit 1641 further messages including a Partial IV, until it has derived a new 1642 Sender Context. This prevents the endpoint to reuse the same AEAD 1643 nonces with the same Sender key. 1645 In order to renew its own Sender Context, the endpoint SHOULD inform 1646 the Group Manager, which can either renew the whole Security Context 1647 by means of group rekeying, or provide only that endpoint with a new 1648 Sender ID value. In either case, the endpoint derives a new Sender 1649 Context, and in particular a new Sender Key. 1651 Additionally, the same considerations from Section 12.6 of [RFC8613] 1652 hold for Group OSCORE, about building the AEAD nonce and the secrecy 1653 of the Security Context parameters. 1655 The EdDSA signature algorithm Ed25519 [RFC8032] is mandatory to 1656 implement. For many constrained IoT devices, it is problematic to 1657 support more than one signature algorithm or multiple whole cipher 1658 suites. This means that some deployments using, for instance, ECDSA 1659 with NIST P-256 may not support the mandatory signature algorithm. 1660 However, this is not a problem for local deployments. 1662 10.14. Message Segmentation 1664 The same considerations from Section 12.7 of [RFC8613] hold for Group 1665 OSCORE. 1667 10.15. Privacy Considerations 1669 Group OSCORE ensures end-to-end integrity protection and encryption 1670 of the message payload and all options that are not used for proxy 1671 operations. In particular, options are processed according to the 1672 same class U/I/E that they have for OSCORE. Therefore, the same 1673 privacy considerations from Section 12.8 of [RFC8613] hold for Group 1674 OSCORE. 1676 Furthermore, the following privacy considerations hold, about the 1677 OSCORE option that may reveal information on the communicating 1678 endpoints. 1680 o The 'kid' parameter, which is intended to help a recipient 1681 endpoint to find the right Recipient Context, may reveal 1682 information about the Sender Endpoint. Since both requests and 1683 responses always include the 'kid' parameter, this may reveal 1684 information about both a client sending a group request and all 1685 the possibly replying servers sending their own individual 1686 response. 1688 o The 'kid context' parameter, which is intended to help a recipient 1689 endpoint to find the right Recipient Context, reveals information 1690 about the sender endpoint. In particular, it reveals that the 1691 sender endpoint is a member of a particular OSCORE group, whose 1692 current Group ID is indicated in the 'kid context' parameter. 1693 Moreover, this parameter explicitly relates two or more 1694 communicating endpoints, as members of the same OSCORE group. 1696 Also, using the mechanisms described in Appendix E.3 to achieve 1697 sequence number synchronization with a client may reveal when a 1698 server device goes through a reboot. This can be mitigated by the 1699 server device storing the precise state of the replay window of each 1700 known client on a clean shutdown. 1702 Finally, the mechanism described in Section 10.5 to prevent 1703 collisions of Group Identifiers from different Group Managers may 1704 reveal information about events in the respective OSCORE groups. In 1705 particular, a Group Idenfier changes when the corresponding group is 1706 rekeyed. Thus, changes in the shared list of Group Identifiers may 1707 be used to infer about the rate and patterns of group membership 1708 changes triggering a group rekeying, e.g. due to newly joined members 1709 or evicted (compromised) members. In order to alleviate such privacy 1710 concerns, it should be hidden from the Group Managers which exact 1711 Group Manager has currently assigned which Group Identifiers in its 1712 OSCORE groups. 1714 11. IANA Considerations 1716 Note to RFC Editor: Please replace all occurrences of "[This 1717 Document]" with the RFC number of this specification and delete this 1718 paragraph. 1720 This document has the following actions for IANA. 1722 11.1. Counter Signature Parameters Registry 1724 This specification establishes the IANA "Counter Signature 1725 Parameters" Registry. The Registry has been created to use the 1726 "Expert Review Required" registration procedure [RFC8126]. Expert 1727 review guidelines are provided in Section 11.4. 1729 This registry specifies the parameters of each admitted 1730 countersignature algorithm, as well as the possible structure they 1731 are organized into. This information is used to populate the 1732 parameter Counter Signature Parameters of the Common Context (see 1733 Section 2). 1735 The columns of this table are: 1737 o Name: A value that can be used to identify an algorithm in 1738 documents for easier comprehension. Its value is taken from the 1739 'Name' column of the "COSE Algorithms" Registry. 1741 o Value: The value to be used to identify this algorithm. Its 1742 content is taken from the 'Value' column of the "COSE Algorithms" 1743 Registry. The value MUST be the same one used in the "COSE 1744 Algorithms" Registry for the entry with the same 'Name' field. 1746 o Parameters: This indicates the CBOR encoding of the parameters (if 1747 any) for the counter signature algorithm indicated by the 'Value' 1748 field. 1750 o Description: A short description of the parameters encoded in the 1751 'Parameters' field (if any). 1753 o Reference: This contains a pointer to the public specification for 1754 the field, if one exists. 1756 Initial entries in the registry are as follows. 1758 +-------------+-------+--------------+-----------------+-----------+ 1759 | Name | Value | Parameters | Description | Reference | 1760 +-------------+-------+--------------+-----------------+-----------+ 1761 | | | | | | 1762 | EdDSA | -8 | crv : int | crv value taken | [This | 1763 | | | | from the COSE | Document] | 1764 | | | | Elliptic Curve | | 1765 | | | | Registry | | 1766 | | | | | | 1767 +-------------+-------+--------------+-----------------+-----------+ 1768 | | | | | | 1769 | ES256 | -7 | crv : int | crv value taken | [This | 1770 | | | | from the COSE | Document] | 1771 | | | | Elliptic Curve | | 1772 | | | | Registry | | 1773 | | | | | | 1774 +-------------+-------+--------------+-----------------+-----------+ 1775 | | | | | | 1776 | ES384 | -35 | crv : int | crv value taken | [This | 1777 | | | | from the COSE | Document] | 1778 | | | | Elliptic Curve | | 1779 | | | | Registry | | 1780 | | | | | | 1781 +-------------+-------+--------------+-----------------+-----------+ 1782 | | | | | | 1783 | ES512 | -36 | crv : int | crv value taken | [This | 1784 | | | | from the COSE | Document] | 1785 | | | | Elliptic Curve | | 1786 | | | | Registry | | 1787 | | | | | | 1788 +-------------+-------+--------------+-----------------+-----------+ 1789 | | | | | | 1790 | PS256 | -37 | | Parameters not | [This | 1791 | | | | present | Document] | 1792 | | | | | | 1793 +-------------+-------+--------------+-----------------+-----------+ 1794 | | | | | | 1795 | PS384 | -38 | | Parameters not | [This | 1796 | | | | present | Document] | 1797 | | | | | | 1798 +-------------+-------+--------------+-----------------+-----------+ 1799 | | | | | | 1800 | PS512 | -39 | | Parameters not | [This | 1801 | | | | present | Document] | 1802 | | | | | | 1803 +-------------+-------+--------------+-----------------+-----------+ 1805 11.2. Counter Signature Key Parameters Registry 1807 This specification establishes the IANA "Counter Signature Key 1808 Parameters" Registry. The Registry has been created to use the 1809 "Expert Review Required" registration procedure [RFC8126]. Expert 1810 review guidelines are provided in Section 11.4. 1812 This registry specifies the parameters of countersignature keys for 1813 each admitted countersignature algorithm, as well as the possible 1814 structure they are organized into. This information is used to 1815 populate the parameter Counter Signature Key Parameters of the Common 1816 Context (see Section 2). 1818 The columns of this table are: 1820 o Name: A value that can be used to identify an algorithm in 1821 documents for easier comprehension. Its value is taken from the 1822 'Name' column of the "COSE Algorithms" Registry. 1824 o Value: The value to be used to identify this algorithm. Its 1825 content is taken from the 'Value' column of the "COSE Algorithms" 1826 Registry. The value MUST be the same one used in the "COSE 1827 Algorithms" Registry for the entry with the same 'Name' field. 1829 o Parameters: This indicates the CBOR encoding of the key parameters 1830 (if any) for the counter signature algorithm indicated by the 1831 'Value' field. 1833 o Description: A short description of the parameters encoded in the 1834 'Parameters' field (if any). 1836 o Reference: This contains a pointer to the public specification for 1837 the field, if one exists. 1839 Initial entries in the registry are as follows. 1841 +-------------+-------+--------------+-------------------+-----------+ 1842 | Name | Value | Parameters | Description | Reference | 1843 +-------------+-------+--------------+-------------------+-----------+ 1844 | | | | | | 1845 | EdDSA | -8 | [kty : int , | kty value is 1, | [This | 1846 | | | | as Key Type "OKP" | Document] | 1847 | | | | from the COSE Key | | 1848 | | | | Types Registry | | 1849 | | | | | | 1850 | | | | | | 1851 | | | crv : int] | crv value taken | | 1852 | | | | from the COSE | | 1853 | | | | Elliptic Curve | | 1854 | | | | Registry | | 1855 | | | | | | 1856 +-------------+-------+--------------+-------------------+-----------+ 1857 | | | | | | 1858 | ES256 | -7 | [kty : int , | kty value is 2, | [This | 1859 | | | | as Key Type "EC2" | Document] | 1860 | | | | from the COSE Key | | 1861 | | | | Types Registry | | 1862 | | | | | | 1863 | | | | | | 1864 | | | crv : int] | crv value taken | | 1865 | | | | from the COSE | | 1866 | | | | Elliptic Curve | | 1867 | | | | Registry | | 1868 | | | | | | 1869 +-------------+-------+--------------+-------------------+-----------+ 1870 | | | | | | 1871 | ES384 | -35 | [kty : int , | kty value is 2, | [This | 1872 | | | | as Key Type "EC2" | Document] | 1873 | | | | from the COSE Key | | 1874 | | | | Types Registry | | 1875 | | | | | | 1876 | | | crv : int] | crv value taken | | 1877 | | | | from the COSE | | 1878 | | | | Elliptic Curve | | 1879 | | | | Registry | | 1880 | | | | | | 1881 +-------------+-------+--------------+-------------------+-----------+ 1882 | | | | | | 1883 | ES512 | -36 | [kty : int , | kty value is 2, | [This | 1884 | | | | as Key Type "EC2" | Document] | 1885 | | | | from the COSE Key | | 1886 | | | | Types Registry | | 1887 | | | | | | 1888 | | | crv : int] | crv value taken | | 1889 | | | | from the COSE | | 1890 | | | | Elliptic Curve | | 1891 | | | | Registry | | 1892 | | | | | | 1893 +-------------+-------+--------------+-------------------+-----------+ 1894 | | | | | | 1895 | PS256 | -37 | kty : int | kty value is 3, | [This | 1896 | | | | as Key Type "RSA" | Document] | 1897 | | | | from the COSE Key | | 1898 | | | | Types Registry | | 1899 | | | | | | 1900 +-------------+-------+--------------+-------------------+-----------+ 1901 | | | | | | 1902 | PS384 | -38 | kty : int | kty value is 3, | [This | 1903 | | | | as Key Type "RSA" | Document] | 1904 | | | | from the COSE Key | | 1905 | | | | Types Registry | | 1906 | | | | | | 1907 +-------------+-------+--------------+-------------------+-----------+ 1908 | | | | | | 1909 | PS512 | -39 | kty : int | kty value is 3, | [This | 1910 | | | | as Key Type "RSA" | Document] | 1911 | | | | from the COSE Key | | 1912 | | | | Types Registry | | 1913 | | | | | | 1914 +-------------+-------+--------------+-------------------+-----------+ 1916 11.3. OSCORE Flag Bits Registry 1918 IANA is asked to add the following value entry to the "OSCORE Flag 1919 Bits" subregistry defined in Section 13.7 of [RFC8613] as part of the 1920 "CoRE Parameters" registry. 1922 +--------------+-------------+--------------------------+-----------+ 1923 | Bit Position | Name | Description | Reference | 1924 +--------------+-------------+--------------------------+-----------+ 1925 | 2 | Pairwise | Set to 1 if the message | [This | 1926 | | Protection | is protected with | Document] | 1927 | | Flag | pairwise keying material | | 1928 +--------------+-------------+--------------------------+-----------+ 1930 11.4. Expert Review Instructions 1932 The IANA Registries established in this document are defined as 1933 "Expert Review". This section gives some general guidelines for what 1934 the experts should be looking for, but they are being designated as 1935 experts for a reason so they should be given substantial latitude. 1937 Expert reviewers should take into consideration the following points: 1939 o Clarity and correctness of registrations. Experts are expected to 1940 check the clarity of purpose and use of the requested entries. 1941 Experts should inspect the entry for the algorithm considered, to 1942 verify the conformity of the encoding proposed against the 1943 theoretical algorithm, including completeness of the 'Parameters' 1944 column. Expert needs to make sure values are taken from the right 1945 registry, when that's required. Expert should consider requesting 1946 an opinion on the correctness of registered parameters from the 1947 CBOR Object Signing and Encryption Working Group (COSE). 1949 Encodings that do not meet these objective of clarity and 1950 completeness should not be registered. 1952 o Duplicated registration and point squatting should be discouraged. 1953 Reviewers are encouraged to get sufficient information for 1954 registration requests to ensure that the usage is not going to 1955 duplicate one that is already registered and that the point is 1956 likely to be used in deployments. 1958 o Experts should take into account the expected usage of fields when 1959 approving point assignment. The length of the 'Parameters' 1960 encoding should be weighed against the usage of the entry, 1961 considering the size of device it will be used on. Additionally, 1962 the length of the encoded value should be weighed against how many 1963 code points of that length are left, the size of device it will be 1964 used on, and the number of code points left that encode to that 1965 size. 1967 o Specifications are recommended. When specifications are not 1968 provided, the description provided needs to have sufficient 1969 information to verify the points above. 1971 12. References 1973 12.1. Normative References 1975 [I-D.ietf-core-groupcomm-bis] 1976 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1977 for the Constrained Application Protocol (CoAP)", draft- 1978 ietf-core-groupcomm-bis-00 (work in progress), March 2020. 1980 [NIST-800-56A] 1981 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 1982 Davis, "Recommendation for Pair-Wise Key-Establishment 1983 Schemes Using Discrete Logarithm Cryptography - NIST 1984 Special Publication 800-56A, Revision 3", April 2018, 1985 . 1988 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1989 Requirement Levels", BCP 14, RFC 2119, 1990 DOI 10.17487/RFC2119, March 1997, 1991 . 1993 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1994 "Randomness Requirements for Security", BCP 106, RFC 4086, 1995 DOI 10.17487/RFC4086, June 2005, 1996 . 1998 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 1999 Algorithm (DSA) and Elliptic Curve Digital Signature 2000 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2001 2013, . 2003 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2004 Application Protocol (CoAP)", RFC 7252, 2005 DOI 10.17487/RFC7252, June 2014, 2006 . 2008 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2009 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2010 2016, . 2012 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 2013 Signature Algorithm (EdDSA)", RFC 8032, 2014 DOI 10.17487/RFC8032, January 2017, 2015 . 2017 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2018 Writing an IANA Considerations Section in RFCs", BCP 26, 2019 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2020 . 2022 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 2023 RFC 8152, DOI 10.17487/RFC8152, July 2017, 2024 . 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2027 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2028 May 2017, . 2030 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2031 "Object Security for Constrained RESTful Environments 2032 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2033 . 2035 12.2. Informative References 2037 [Degabriele] 2038 Degabriele, J., Lehmann, A., Paterson, K., Smart, N., and 2039 M. Strefler, "On the Joint Security of Encryption and 2040 Signature in EMV", December 2011, 2041 . 2043 [I-D.ietf-ace-key-groupcomm] 2044 Palombini, F. and M. Tiloca, "Key Provisioning for Group 2045 Communication using ACE", draft-ietf-ace-key-groupcomm-05 2046 (work in progress), March 2020. 2048 [I-D.ietf-ace-key-groupcomm-oscore] 2049 Tiloca, M., Park, J., and F. Palombini, "Key Management 2050 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 2051 oscore-05 (work in progress), March 2020. 2053 [I-D.ietf-ace-oauth-authz] 2054 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2055 H. Tschofenig, "Authentication and Authorization for 2056 Constrained Environments (ACE) using the OAuth 2.0 2057 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 2058 (work in progress), February 2020. 2060 [I-D.ietf-core-echo-request-tag] 2061 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 2062 Request-Tag, and Token Processing", draft-ietf-core-echo- 2063 request-tag-09 (work in progress), March 2020. 2065 [I-D.somaraju-ace-multicast] 2066 Somaraju, A., Kumar, S., Tschofenig, H., and W. Werner, 2067 "Security for Low-Latency Group Communication", draft- 2068 somaraju-ace-multicast-02 (work in progress), October 2069 2016. 2071 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2072 "Transmission of IPv6 Packets over IEEE 802.15.4 2073 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2074 . 2076 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 2077 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 2078 . 2080 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2081 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2082 DOI 10.17487/RFC6282, September 2011, 2083 . 2085 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2086 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2087 January 2012, . 2089 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2090 Constrained-Node Networks", RFC 7228, 2091 DOI 10.17487/RFC7228, May 2014, 2092 . 2094 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2095 Application Protocol (CoAP)", RFC 7641, 2096 DOI 10.17487/RFC7641, September 2015, 2097 . 2099 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 2100 the Constrained Application Protocol (CoAP)", RFC 7959, 2101 DOI 10.17487/RFC7959, August 2016, 2102 . 2104 Appendix A. Assumptions and Security Objectives 2106 This section presents a set of assumptions and security objectives 2107 for the approach described in this document. The rest of this 2108 section refers to three types of groups: 2110 o Application group, i.e. a set of CoAP endpoints that share a 2111 common pool of resources. 2113 o Security group, as defined in Section 1.1 of this specification. 2114 There can be a one-to-one or a one-to-many relation between 2115 security groups and application groups. Any two application 2116 groups associated to the same security group do not share any same 2117 resource. 2119 o CoAP group, as defined in [I-D.ietf-core-groupcomm-bis] i.e. a set 2120 of CoAP endpoints, where each endpoint is configured to receive 2121 CoAP multicast requests that are sent to the group's associated IP 2122 multicast address and UDP port. An endpoint may be a member of 2123 multiple CoAP groups. There can be a one-to-one or a one-to-many 2124 relation between CoAP groups and application groups. Note that a 2125 device sending a CoAP request to a CoAP group is not necessarily 2126 itself a member of that group: it is a member only if it also has 2127 a CoAP server endpoint listening to requests for this CoAP group, 2128 sent to the associated IP multicast address and port. In order to 2129 provide secure group communication, all members of a CoAP group as 2130 well as all further endpoints configured only as clients sending 2131 CoAP (multicast) requests to the CoAP group have to be member of a 2132 security group. 2134 A.1. Assumptions 2136 The following assumptions are assumed to be already addressed and are 2137 out of the scope of this document. 2139 o Multicast communication topology: this document considers both 2140 1-to-N (one sender and multiple recipients) and M-to-N (multiple 2141 senders and multiple recipients) communication topologies. The 2142 1-to-N communication topology is the simplest group communication 2143 scenario that would serve the needs of a typical Low-power and 2144 Lossy Network (LLN). Examples of use cases that benefit from 2145 secure group communication are provided in Appendix B. 2147 In a 1-to-N communication model, only a single client transmits 2148 data to the CoAP group, in the form of request messages; in an 2149 M-to-N communication model (where M and N do not necessarily have 2150 the same value), M clients transmit data to the CoAP group. 2151 According to [I-D.ietf-core-groupcomm-bis], any possible proxy 2152 entity is supposed to know about the clients and to not perform 2153 aggregation of response messages from multiple servers. Also, 2154 every client expects and is able to handle multiple response 2155 messages associated to a same request sent to the CoAP group. 2157 o Group size: security solutions for group communication should be 2158 able to adequately support different and possibly large security 2159 groups. The group size is the current number of members in a 2160 security group. In the use cases mentioned in this document, the 2161 number of clients (normally the controlling devices) is expected 2162 to be much smaller than the number of servers (i.e. the controlled 2163 devices). A security solution for group communication that 2164 supports 1 to 50 clients would be able to properly cover the group 2165 sizes required for most use cases that are relevant for this 2166 document. The maximum group size is expected to be in the range 2167 of 2 to 100 devices. Security groups larger than that should be 2168 divided into smaller independent groups. 2170 o Communication with the Group Manager: an endpoint must use a 2171 secure dedicated channel when communicating with the Group 2172 Manager, also when not registered as a member of the security 2173 group. 2175 o Provisioning and management of Security Contexts: a Security 2176 Context must be established among the members of the security 2177 group. A secure mechanism must be used to generate, revoke and 2178 (re-)distribute keying material, multicast security policies and 2179 security parameters in the security group. The actual 2180 provisioning and management of the Security Context is out of the 2181 scope of this document. 2183 o Multicast data security ciphersuite: all members of a security 2184 group must agree on a ciphersuite to provide authenticity, 2185 integrity and confidentiality of messages in the group. The 2186 ciphersuite is specified as part of the Security Context. 2188 o Backward security: a new device joining the security group should 2189 not have access to any old Security Contexts used before its 2190 joining. This ensures that a new member of the security group is 2191 not able to decrypt confidential data sent before it has joined 2192 the security group. The adopted key management scheme should 2193 ensure that the Security Context is updated to ensure backward 2194 confidentiality. The actual mechanism to update the Security 2195 Context and renew the group keying material in the security group 2196 upon a new member's joining has to be defined as part of the group 2197 key management scheme. 2199 o Forward security: entities that leave the security group should 2200 not have access to any future Security Contexts or message 2201 exchanged within the security group after their leaving. This 2202 ensures that a former member of the security group is not able to 2203 decrypt confidential data sent within the security group anymore. 2204 Also, it ensures that a former member is not able to send 2205 encrypted and/or integrity protected messages to the security 2206 group anymore. The actual mechanism to update the Security 2207 Context and renew the group keying material in the security group 2208 upon a member's leaving has to be defined as part of the group key 2209 management scheme. 2211 A.2. Security Objectives 2213 The approach described in this document aims at fulfilling the 2214 following security objectives: 2216 o Data replay protection: group request messages or response 2217 messages replayed within the security group must be detected. 2219 o Group-level data confidentiality: messages sent within the 2220 security group shall be encrypted if privacy sensitive data is 2221 exchanged within the security group. This document considers 2222 group-level data confidentiality since messages are encrypted at a 2223 group level, i.e. in such a way that they can be decrypted by any 2224 member of the security group, but not by an external adversary or 2225 other external entities. 2227 o Source authentication: messages sent within the security group 2228 shall be authenticated. That is, it is essential to ensure that a 2229 message is originated by a member of the security group in the 2230 first place, and in particular by a specific member of the 2231 security group. 2233 o Message integrity: messages sent within the security group shall 2234 be integrity protected. That is, it is essential to ensure that a 2235 message has not been tampered with by an external adversary or 2236 other external entities which are not members of the security 2237 group. 2239 o Message ordering: it must be possible to determine the ordering of 2240 messages coming from a single sender. In accordance with OSCORE 2241 [RFC8613], this results in providing relative freshness of group 2242 requests and absolute freshness of responses. It is not required 2243 to determine ordering of messages from different senders. 2245 Appendix B. List of Use Cases 2247 Group Communication for CoAP [I-D.ietf-core-groupcomm-bis] provides 2248 the necessary background for multicast-based CoAP communication, with 2249 particular reference to low-power and lossy networks (LLNs) and 2250 resource constrained environments. The interested reader is 2251 encouraged to first read [I-D.ietf-core-groupcomm-bis] to understand 2252 the non-security related details. This section discusses a number of 2253 use cases that benefit from secure group communication, and refers to 2254 the three types of groups from Appendix A. Specific security 2255 requirements for these use cases are discussed in Appendix A. 2257 o Lighting control: consider a building equipped with IP-connected 2258 lighting devices, switches, and border routers. The lighting 2259 devices acting as servers are organized into application groups 2260 and CoAP groups, according to their physical location in the 2261 building. For instance, lighting devices in a room or corridor 2262 can be configured as members of a single application group and 2263 corresponding CoAP group. Those ligthing devices together with 2264 the switches acting as clients in the same room or corridor can be 2265 configured as members of the corresponding security group. 2266 Switches are then used to control the lighting devices by sending 2267 on/off/dimming commands to all lighting devices in the CoAP group, 2268 while border routers connected to an IP network backbone (which is 2269 also multicast-enabled) can be used to interconnect routers in the 2270 building. Consequently, this would also enable logical groups to 2271 be formed even if devices with a role in the lighting application 2272 may be physically in different subnets (e.g. on wired and wireless 2273 networks). Connectivity between lighting devices may be realized, 2274 for instance, by means of IPv6 and (border) routers supporting 2275 6LoWPAN [RFC4944][RFC6282]. Group communication enables 2276 synchronous operation of a set of connected lights, ensuring that 2277 the light preset (e.g. dimming level or color) of a large set of 2278 luminaires are changed at the same perceived time. This is 2279 especially useful for providing a visual synchronicity of light 2280 effects to the user. As a practical guideline, events within a 2281 200 ms interval are perceived as simultaneous by humans, which is 2282 necessary to ensure in many setups. Devices may reply back to the 2283 switches that issue on/off/dimming commands, in order to report 2284 about the execution of the requested operation (e.g. OK, failure, 2285 error) and their current operational status. In a typical 2286 lighting control scenario, a single switch is the only entity 2287 responsible for sending commands to a set of lighting devices. In 2288 more advanced lighting control use cases, a M-to-N communication 2289 topology would be required, for instance in case multiple sensors 2290 (presence or day-light) are responsible to trigger events to a set 2291 of lighting devices. Especially in professional lighting 2292 scenarios, the roles of client and server are configured by the 2293 lighting commissioner, and devices strictly follow those roles. 2295 o Integrated building control: enabling Building Automation and 2296 Control Systems (BACSs) to control multiple heating, ventilation 2297 and air-conditioning units to pre-defined presets. Controlled 2298 units can be organized into application groups and CoAP groups in 2299 order to reflect their physical position in the building, e.g. 2300 devices in the same room can be configured as members of a single 2301 application group and corresponding CoAP group. As a practical 2302 guideline, events within intervals of seconds are typically 2303 acceptable. Controlled units are expected to possibly reply back 2304 to the BACS issuing control commands, in order to report about the 2305 execution of the requested operation (e.g. OK, failure, error) 2306 and their current operational status. 2308 o Software and firmware updates: software and firmware updates often 2309 comprise quite a large amount of data. This can overload a Low- 2310 power and Lossy Network (LLN) that is otherwise typically used to 2311 deal with only small amounts of data, on an infrequent base. 2312 Rather than sending software and firmware updates as unicast 2313 messages to each individual device, multicasting such updated data 2314 to a larger set of devices at once displays a number of benefits. 2315 For instance, it can significantly reduce the network load and 2316 decrease the overall time latency for propagating this data to all 2317 devices. Even if the complete whole update process itself is 2318 secured, securing the individual messages is important, in case 2319 updates consist of relatively large amounts of data. In fact, 2320 checking individual received data piecemeal for tampering avoids 2321 that devices store large amounts of partially corrupted data and 2322 that they detect tampering hereof only after all data has been 2323 received. Devices receiving software and firmware updates are 2324 expected to possibly reply back, in order to provide a feedback 2325 about the execution of the update operation (e.g. OK, failure, 2326 error) and their current operational status. 2328 o Parameter and configuration update: by means of multicast 2329 communication, it is possible to update the settings of a set of 2330 similar devices, both simultaneously and efficiently. Possible 2331 parameters are related, for instance, to network load management 2332 or network access controls. Devices receiving parameter and 2333 configuration updates are expected to possibly reply back, to 2334 provide a feedback about the execution of the update operation 2335 (e.g. OK, failure, error) and their current operational status. 2337 o Commissioning of Low-power and Lossy Network (LLN) systems: a 2338 commissioning device is responsible for querying all devices in 2339 the local network or a selected subset of them, in order to 2340 discover their presence, and be aware of their capabilities, 2341 default configuration, and operating conditions. Queried devices 2342 displaying similarities in their capabilities and features, or 2343 sharing a common physical location can be configured as members of 2344 a single application group and corresponding CoAP group. Queried 2345 devices are expected to reply back to the commissioning device, in 2346 order to notify their presence, and provide the requested 2347 information and their current operational status. 2349 o Emergency multicast: a particular emergency related information 2350 (e.g. natural disaster) is generated and multicast by an emergency 2351 notifier, and relayed to multiple devices. The latter may reply 2352 back to the emergency notifier, in order to provide their feedback 2353 and local information related to the ongoing emergency. This kind 2354 of setups should additionally rely on a fault tolerance multicast 2355 algorithm, such as Multicast Protocol for Low-Power and Lossy 2356 Networks (MPL). 2358 Appendix C. Example of Group Identifier Format 2360 This section provides an example of how the Group Identifier (Gid) 2361 can be specifically formatted. That is, the Gid can be composed of 2362 two parts, namely a Group Prefix and a Group Epoch. 2364 For each group, the Group Prefix is constant over time and is 2365 uniquely defined in the set of all the groups associated to the same 2366 Group Manager. The choice of the Group Prefix for a given group's 2367 Security Context is application specific. The size of the Group 2368 Prefix directly impact on the maximum number of distinct groups under 2369 the same Group Manager. 2371 The Group Epoch is set to 0 upon the group's initialization, and is 2372 incremented by 1 upon completing each renewal of the Security Context 2373 and keying material in the group (see Section 2.4). In particular, 2374 once a new Master Secret has been distributed to the group, all the 2375 group members increment by 1 the Group Epoch in the Group Identifier 2376 of that group. 2378 As an example, a 3-byte Group Identifier can be composed of: i) a 2379 1-byte Group Prefix '0xb1' interpreted as a raw byte string; and ii) 2380 a 2-byte Group Epoch interpreted as an unsigned integer ranging from 2381 0 to 65535. Then, after having established the Common Context 61532 2382 times in the group, its Group Identifier will assume value 2383 '0xb1f05c'. 2385 Using an immutable Group Prefix for a group assumes that enough time 2386 elapses between two consecutive usages of the same Group Epoch value 2387 in that group. This ensures that the Gid value is temporally unique 2388 during the lifetime of a given message. Thus, the expected highest 2389 rate for addition/removal of group members and consequent group 2390 rekeying should be taken into account for a proper dimensioning of 2391 the Group Epoch size. 2393 As discussed in Section 10.5, if endpoints are deployed in multiple 2394 groups managed by different non-synchronized Group Managers, it is 2395 possible that Group Identifiers of different groups coincide at some 2396 point in time. In this case, a recipient has to handle coinciding 2397 Group Identifiers, and has to try using different Security Contexts 2398 to process an incoming message, until the right one is found and the 2399 message is correctly verified. Therefore, it is favourable that 2400 Group Identifiers from different Group Managers have a size that 2401 result in a small probability of collision. How small this 2402 probability should be is up to system designers. 2404 Appendix D. Set-up of New Endpoints 2406 An endpoint joins a group by explicitly interacting with the 2407 responsible Group Manager. When becoming members of a group, 2408 endpoints are not required to know how many and what endpoints are in 2409 the same group. 2411 Communications between a joining endpoint and the Group Manager rely 2412 on the CoAP protocol and must be secured. Specific details on how to 2413 secure communications between joining endpoints and a Group Manager 2414 are out of the scope of this document. 2416 The Group Manager must verify that the joining endpoint is authorized 2417 to join the group. To this end, the Group Manager can directly 2418 authorize the joining endpoint, or expect it to provide authorization 2419 evidence previously obtained from a trusted entity. Further details 2420 about the authorization of joining endpoints are out of scope. 2422 In case of successful authorization check, the Group Manager 2423 generates a Sender ID assigned to the joining endpoint, before 2424 proceeding with the rest of the join process. That is, the Group 2425 Manager provides the joining endpoint with the keying material and 2426 parameters to initialize the Security Context (see Section 2). The 2427 actual provisioning of keying material and parameters to the joining 2428 endpoint is out of the scope of this document. 2430 It is RECOMMENDED that the join process adopts the approach described 2431 in [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework 2432 for Authentication and Authorization in constrained environments 2433 [I-D.ietf-ace-oauth-authz]. 2435 Appendix E. Examples of Synchronization Approaches 2437 This section describes three possible approaches that can be 2438 considered by server endpoints to synchronize with sender sequence 2439 numbers of client endpoints sending group requests. 2441 E.1. Best-Effort Synchronization 2443 Upon receiving a group request from a client, a server does not take 2444 any action to synchonize with the sender sequence number of that 2445 client. This provides no assurance at all as to message freshness, 2446 which can be acceptable in non-critical use cases. 2448 With the notable exception of Observe notifications and responses 2449 following a group rekeying, it is optional for the server to use its 2450 own sender sequence number as Partial IV. Instead, for efficiency 2451 reasons, the server may rather use the request's Partial IV when 2452 protecting a response. 2454 Since it provides no assurance as to freshness of requests, it is 2455 thus RECOMMENDED that a server using this synchronization approach 2456 always uses its own sender sequence number as Partial IV when 2457 protecting a response. 2459 E.2. Baseline Synchronization 2461 Upon receiving a group request from a given client for the first 2462 time, a server initializes its last-seen sender sequence number in 2463 its Recipient Context associated to that client. This provides a 2464 reference point to identify if future group requests from the same 2465 client are fresher than the last one received. 2467 A replay time interval exists, between when a possibly replayed or 2468 delayed message is originally transmitted by a given client and the 2469 first authentic fresh message from that same client is received. 2471 This can be acceptable for use cases where servers admit such a 2472 trade-off between performance and assurance of message freshness. 2474 With the notable exception of Observe notifications and responses 2475 following a group rekeying, it is optional for the server to use its 2476 own sender sequence number as Partial IV. Instead, for efficiency 2477 reasons, the server may rather use the request's Partial IV when 2478 protecting a response. 2480 In case the baseline synchronization state related to a client is 2481 lost, it is RECOMMENDED that the server uses its own sender sequence 2482 number as Partial IV when protecting a response to that client, until 2483 a new baseline synchronization state for that client is established. 2485 E.3. Challenge-Response Synchronization 2487 A server performs a challenge-response exchange with a client, by 2488 using the Echo Option for CoAP described in Section 2 of 2489 [I-D.ietf-core-echo-request-tag] and according to Appendix B.1.2 of 2490 [RFC8613]. 2492 That is, upon receiving a group request from a particular client for 2493 the first time, the server processes the message as described in this 2494 specification, but, even if valid, does not deliver it to the 2495 application. Instead, the server replies to the client with an 2496 OSCORE protected 4.01 (Unauthorized) response message, including only 2497 the Echo Option and no diagnostic payload. The server stores the 2498 option value included therein. 2500 Upon receiving a 4.01 (Unauthorized) response that includes an Echo 2501 Option and originates from a verified group member, a client sends a 2502 request as a unicast message addressed to the same server, echoing 2503 the Echo Option value. In particular, the client does not 2504 necessarily resend the same group request, but can instead send a 2505 more recent one, if the application permits it. This makes it 2506 possible for the client to not retain previously sent group requests 2507 for full retransmission, unless the application explicitly requires 2508 otherwise. In either case, the client uses the sender sequence 2509 number value currently stored in its own Sender Context. If the 2510 client stores group requests for possible retransmission with the 2511 Echo Option, it should not store a given request for longer than a 2512 pre-configured time interval. Note that the unicast request echoing 2513 the Echo Option is correctly treated and processed as a message, 2514 since the 'kid context' field including the Group Identifier of the 2515 OSCORE group is still present in the OSCORE Option as part of the 2516 COSE object (see Section 4). 2518 Upon receiving the unicast request including the Echo Option, the 2519 server verifies that the option value equals the stored and 2520 previously sent value. If not, the server MUST NOT process the 2521 request further and MAY send a 4.01 (Unauthorized) response including 2522 an Echo option. 2524 In case of positive verification, the request is further processed 2525 and verified. Finally, the server updates the Recipient Context 2526 associated to that client, by setting the Replay Window according to 2527 the Sequence Number from the unicast request conveying the Echo 2528 Option. The server either delivers the request to the application if 2529 it is an actual retransmission of the original one, or discards it 2530 otherwise. Mechanisms to signal whether the resent request is a full 2531 retransmission of the original one are out of the scope of this 2532 specification. 2534 A server should not deliver group requests from a given client to the 2535 application until one valid request from that same client has been 2536 verified as fresh, as conveying an echoed Echo Option 2537 [I-D.ietf-core-echo-request-tag]. Also, a server may perform the 2538 challenge-response described above at any time, if synchronization 2539 with sender sequence numbers of clients is (believed to be) lost, for 2540 instance after a device reboot. It is the role of the application to 2541 define under what circumstances sender sequence numbers lose 2542 synchronization. This can include a minimum gap between the sender 2543 sequence number of the latest accepted group request from a client 2544 and the sender sequence number of a group request just received from 2545 the same client. A client has to be always ready to perform the 2546 challenge-response based on the Echo Option in case a server starts 2547 it. 2549 This approach provides an assurance of absolute message freshness. 2550 However, it can result in an impact on performance which is 2551 undesirable or unbearable, especially in large groups where many 2552 endpoints at the same time might join as new members or lose 2553 synchronization. 2555 Note that endpoints configured as silent servers are not able to 2556 perform the challenge-response described above, as they do not store 2557 a Sender Context to secure the 4.01 (Unauthorized) response to the 2558 client. Therefore, silent servers should adopt alternative 2559 approaches to achieve and maintain synchronization with sender 2560 sequence numbers of clients. 2562 Since requests including the Echo Option are sent over unicast, a 2563 server can be a victim of the attack discussed in Section 10.7, when 2564 such requests are protected with the signature mode of Group OSCORE, 2565 as described in Section 7.1. 2567 Instead, protecting requests with the Echo Option by using the 2568 pairwise mode of Group OSCORE as described in Appendix G.2 prevents 2569 the attack in Section 10.7. In fact, only the exact server involved 2570 in the Echo exchange is able to derive the correct pairwise key used 2571 by the client to protect the request including the Echo Option. 2573 In either case, an internal on-path adversary would not be able to 2574 mix up the Echo Option value of two different unicast requests, sent 2575 by a same client to any two different servers in the group. In fact, 2576 this would require the adversary to forge the client's counter 2577 signature in both such requests. As a consequence, each of the two 2578 servers remains able to selectively accept a request with the Echo 2579 Option only if it is waiting for that exact integrity-protected Echo 2580 Option value, and is thus the intended recipient. 2582 Appendix F. No Verification of Signatures 2584 There are some application scenarios using group communication that 2585 have particularly strict requirements. One example of this is the 2586 requirement of low message latency in non-emergency lighting 2587 applications [I-D.somaraju-ace-multicast]. For those applications 2588 which have tight performance constraints and relaxed security 2589 requirements, it can be inconvenient for some endpoints to verify 2590 digital signatures in order to assert source authenticity of received 2591 messages. In other cases, the signature verification can be deferred 2592 or only checked for specific actions. For instance, a command to 2593 turn a bulb on where the bulb is already on does not need the 2594 signature to be checked. In such situations, the counter signature 2595 needs to be included anyway as part of the message, so that an 2596 endpoint that needs to validate the signature for any reason has the 2597 ability to do so. 2599 In this specification, it is NOT RECOMMENDED that endpoints do not 2600 verify the counter signature of received messages. However, it is 2601 recognized that there may be situations where it is not always 2602 required. The consequence of not doing the signature validation is 2603 that security in the group is based only on the group-authenticity of 2604 the shared keying material used for encryption. That is, endpoints 2605 in the group have evidence that a received message has been 2606 originated by a group member, although not specifically identifiable 2607 in a secure way. This can violate a number of security requirements, 2608 as the compromise of any element in the group means that the attacker 2609 has the ability to control the entire group. Even worse, the group 2610 may not be limited in scope, and hence the same keying material might 2611 be used not only for light bulbs but for locks as well. Therefore, 2612 extreme care must be taken in situations where the security 2613 requirements are relaxed, so that deployment of the system will 2614 always be done safely. 2616 Appendix G. Pairwise Mode 2618 For use cases that do not require an intermediary performing 2619 signature verification and that use a compatible signature algorithm, 2620 the pairwise mode defined in this section can be used for unicast 2621 communication. 2623 This mode uses the derivation process defined in Section 3, and 2624 allows two group members to protect requests and responses exchanged 2625 with each other using pairwise keying material. 2627 Senders MUST NOT use the pairwise mode to protect a message addressed 2628 to multiple recipients or to the whole group. This prevents a client 2629 that wants to address one specific server from protecting a request 2630 with the pairwise key associated to that server, and then send the 2631 request over multicast. 2633 The pairwise mode results in the same performance and security 2634 improvements displayed by optimized responses (see Section 9.2). 2636 G.1. Pre-Requirements 2638 In order to protect an outgoing message in pairwise mode, a sender 2639 needs to know the public key and the Recipient ID for the message 2640 recipient, as stored in its own Recipient Context associated to that 2641 recipient. 2643 Furthermore, the sender needs to know the individual address of the 2644 message recipient. This information may not be known at any given 2645 point in time. For instance, right after having joined the group, a 2646 client may know the public key and Recipient ID for a given server, 2647 but not the addressing information required to reach it with an 2648 individual, one-to-one request. 2650 To make this information available, servers MAY provide a resource to 2651 which a client can send a request for a server identified by its 2652 'kid' value, or a set thereof. The specified set may be empty, hence 2653 identifying all the servers in the group. Further details of such an 2654 interface are out of scope for this document. 2656 G.2. Pairwise Protected Request 2658 A request in pairwise mode is protected as defined in Section 7.1, 2659 with the following differences. 2661 o The client MUST set to 1 the sixth least significant bit of the 2662 OSCORE flag bits in the OSCORE option, i.e. the Pairwise Flag. 2664 o The COSE_Encrypt0 object included in the request is encrypted 2665 using a symmetric pairwise key K, that the client derives as 2666 defined in Section 3. In particular, the Sender/Recipient Key is 2667 the Sender Key of the client from its own Sender Context, i.e. the 2668 Recipient Key that the server stores in its own Recipient Context 2669 corresponding to the client. 2671 o The Counter Signature is not computed. That is, unlike defined in 2672 Section 5, the payload of the OSCORE message terminates with the 2673 encoded ciphertext of the COSE object. 2675 Note that no changes are made to the AEAD nonce and AAD. 2677 Upon receiving a request with the Pairwise Flag set to 1, the server 2678 MUST process it as defined in Section 7.2, with the following 2679 differences. 2681 o No countersignature to verify is included. 2683 o The COSE_Encrypt0 object included in the request is decrypted and 2684 verified using the same symmetric pairwise key K, that the server 2685 derives as described above for the client side and as defined in 2686 Section 3. 2688 G.3. Pairwise Protected Response 2690 When using the pairwise mode, the processing of a response occurs as 2691 described in Section 9.2 for an optimized response. 2693 Appendix H. Document Updates 2695 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2697 H.1. Version -07 to -08 2699 o Clarified relation between pairwise mode and group communication 2700 (Section 1). 2702 o Improved definition of "silent server" (Section 1.1). 2704 o Clarified when a Recipient Context is needed (Section 2). 2706 o Signature checkers as entities supported by the Group Manager 2707 (Section 2.3). 2709 o Clarified that the Group Manager is under exclusive control of Gid 2710 and Sender ID values in a group, with Sender ID values under each 2711 Gid value (Section 2.3). 2713 o Mitigation policies in case of recycled 'kid' values 2714 (Section 2.4). 2716 o More generic exhaustion (not necessarily wrap-around) of sender 2717 sequence numbers (Sections 2.5 and 10.11). 2719 o Pairwise key considerations, as to group rekeying and Sender 2720 Sequence Numbers (Section 3). 2722 o Added reference to static-static Diffie-Hellman shared secret 2723 (Section 3). 2725 o Note for implementation about the external_aad for signing 2726 (Sectino 4.3.2). 2728 o Retransmission by the application for group requests over 2729 multicast as Non-Confirmable (Section 7). 2731 o A server MUST use its own Partial IV in a response, if protecting 2732 it with a different context than the one used for the request 2733 (Section 7.3). 2735 o Security considerations: encryption of pairwise mode as 2736 alternative to group-level security (Section 10.1). 2738 o Security considerations: added approach to reduce the chance of 2739 global collisions of Gid values from different Group Managers 2740 (Section 10.5). 2742 o Security considerations: added implications for block-wise 2743 transfers when using the signature mode for requests over unicast 2744 (Section 10.7). 2746 o Security considerations: (multiple) supported signature algorithms 2747 (Section 10.13). 2749 o Security considerations: added privacy considerations on the 2750 approach for reducing global collisions of Gid values 2751 (Section 10.15). 2753 o Updates to the methods for synchronizing with clients' sequence 2754 number (Appendix E). 2756 o Simplified text on discovery services supporting the pairwise mode 2757 (Appendix G.1). 2759 o Editorial improvements. 2761 H.2. Version -06 to -07 2763 o Updated abstract and introduction. 2765 o Clarifications of what pertains a group rekeying. 2767 o Derivation of pairwise keying material. 2769 o Content re-organization for COSE Object and OSCORE header 2770 compression. 2772 o Defined the Pairwise Flag bit for the OSCORE option. 2774 o Supporting CoAP Observe for group requests and responses. 2776 o Considerations on message protection across switching to new 2777 keying material. 2779 o New optimized mode based on pairwise keying material. 2781 o More considerations on replay protection and Security Contexts 2782 upon key renewal. 2784 o Security considerations on Group OSCORE for unicast requests, also 2785 as affecting the usage of the Echo option. 2787 o Clarification on different types of groups considered 2788 (application/security/CoAP). 2790 o New pairwise mode, using pairwise keying material for both 2791 requests and responses. 2793 H.3. Version -05 to -06 2795 o Group IDs mandated to be unique under the same Group Manager. 2797 o Clarifications on parameter update upon group rekeying. 2799 o Updated external_aad structures. 2801 o Dynamic derivation of Recipient Contexts made optional and 2802 application specific. 2804 o Optional 4.00 response for failed signature verification on the 2805 server. 2807 o Removed client handling of duplicated responses to multicast 2808 requests. 2810 o Additional considerations on public key retrieval and group 2811 rekeying. 2813 o Added Group Manager responsibility on validating public keys. 2815 o Updates IANA registries. 2817 o Reference to RFC 8613. 2819 o Editorial improvements. 2821 H.4. Version -04 to -05 2823 o Added references to draft-dijk-core-groupcomm-bis. 2825 o New parameter Counter Signature Key Parameters (Section 2). 2827 o Clarification about Recipient Contexts (Section 2). 2829 o Two different external_aad for encrypting and signing 2830 (Section 3.1). 2832 o Updated response verification to handle Observe notifications 2833 (Section 6.4). 2835 o Extended Security Considerations (Section 8). 2837 o New "Counter Signature Key Parameters" IANA Registry 2838 (Section 9.2). 2840 H.5. Version -03 to -04 2842 o Added the new "Counter Signature Parameters" in the Common Context 2843 (see Section 2). 2845 o Added recommendation on using "deterministic ECDSA" if ECDSA is 2846 used as counter signature algorithm (see Section 2). 2848 o Clarified possible asynchronous retrieval of keying material from 2849 the Group Manager, in order to process incoming messages (see 2850 Section 2). 2852 o Structured Section 3 into subsections. 2854 o Added the new 'par_countersign' to the aad_array of the 2855 external_aad (see Section 3.1). 2857 o Clarified non reliability of 'kid' as identity indicator for a 2858 group member (see Section 2.1). 2860 o Described possible provisioning of new Sender ID in case of 2861 Partial IV wrap-around (see Section 2.2). 2863 o The former signature bit in the Flag Byte of the OSCORE option 2864 value is reverted to reserved (see Section 4.1). 2866 o Updated examples of compressed COSE object, now with the sixth 2867 less significant bit in the Flag Byte of the OSCORE option value 2868 set to 0 (see Section 4.3). 2870 o Relaxed statements on sending error messages (see Section 6). 2872 o Added explicit step on computing the counter signature for 2873 outgoing messages (see Setions 6.1 and 6.3). 2875 o Handling of just created Recipient Contexts in case of 2876 unsuccessful message verification (see Sections 6.2 and 6.4). 2878 o Handling of replied/repeated responses on the client (see 2879 Section 6.4). 2881 o New IANA Registry "Counter Signature Parameters" (see 2882 Section 9.1). 2884 H.6. Version -02 to -03 2886 o Revised structure and phrasing for improved readability and better 2887 alignment with draft-ietf-core-object-security. 2889 o Added discussion on wrap-Around of Partial IVs (see Section 2.2). 2891 o Separate sections for the COSE Object (Section 3) and the OSCORE 2892 Header Compression (Section 4). 2894 o The countersignature is now appended to the encrypted payload of 2895 the OSCORE message, rather than included in the OSCORE Option (see 2896 Section 4). 2898 o Extended scope of Section 5, now titled " Message Binding, 2899 Sequence Numbers, Freshness and Replay Protection". 2901 o Clarifications about Non-Confirmable messages in Section 5.1 2902 "Synchronization of Sender Sequence Numbers". 2904 o Clarifications about error handling in Section 6 "Message 2905 Processing". 2907 o Compacted list of responsibilities of the Group Manager in 2908 Section 7. 2910 o Revised and extended security considerations in Section 8. 2912 o Added IANA considerations for the OSCORE Flag Bits Registry in 2913 Section 9. 2915 o Revised Appendix D, now giving a short high-level description of a 2916 new endpoint set-up. 2918 H.7. Version -01 to -02 2920 o Terminology has been made more aligned with RFC7252 and draft- 2921 ietf-core-object-security: i) "client" and "server" replace the 2922 old "multicaster" and "listener", respectively; ii) "silent 2923 server" replaces the old "pure listener". 2925 o Section 2 has been updated to have the Group Identifier stored in 2926 the 'ID Context' parameter defined in draft-ietf-core-object- 2927 security. 2929 o Section 3 has been updated with the new format of the Additional 2930 Authenticated Data. 2932 o Major rewriting of Section 4 to better highlight the differences 2933 with the message processing in draft-ietf-core-object-security. 2935 o Added Sections 7.2 and 7.3 discussing security considerations 2936 about uniqueness of (key, nonce) and collision of group 2937 identifiers, respectively. 2939 o Minor updates to Appendix A.1 about assumptions on multicast 2940 communication topology and group size. 2942 o Updated Appendix C on format of group identifiers, with practical 2943 implications of possible collisions of group identifiers. 2945 o Updated Appendix D.2, adding a pointer to draft-palombini-ace-key- 2946 groupcomm about retrieval of nodes' public keys through the Group 2947 Manager. 2949 o Minor updates to Appendix E.3 about Challenge-Response 2950 synchronization of sequence numbers based on the Echo option from 2951 draft-ietf-core-echo-request-tag. 2953 H.8. Version -00 to -01 2955 o Section 1.1 has been updated with the definition of group as 2956 "security group". 2958 o Section 2 has been updated with: 2960 * Clarifications on etablishment/derivation of Security Contexts. 2962 * A table summarizing the the additional context elements 2963 compared to OSCORE. 2965 o Section 3 has been updated with: 2967 * Examples of request and response messages. 2969 * Use of CounterSignature0 rather than CounterSignature. 2971 * Additional Authenticated Data including also the signature 2972 algorithm, while not including the Group Identifier any longer. 2974 o Added Section 6, listing the responsibilities of the Group 2975 Manager. 2977 o Added Appendix A (former section), including assumptions and 2978 security objectives. 2980 o Appendix B has been updated with more details on the use cases. 2982 o Added Appendix C, providing an example of Group Identifier format. 2984 o Appendix D has been updated to be aligned with draft-palombini- 2985 ace-key-groupcomm. 2987 Acknowledgments 2989 The authors sincerely thank Christian Amsuess, Stefan Beck, Rolf 2990 Blom, Carsten Bormann, Esko Dijk, Klaus Hartke, Rikard Hoeglund, 2991 Richard Kelsey, John Mattsson, Dave Robin, Jim Schaad, Ludwig Seitz, 2992 Peter van der Stok and Erik Thormarker for their feedback and 2993 comments. 2995 The work on this document has been partly supported by VINNOVA and 2996 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 2997 Initiative ACTIVE. 2999 Authors' Addresses 3001 Marco Tiloca 3002 RISE AB 3003 Isafjordsgatan 22 3004 Kista SE-16440 Stockholm 3005 Sweden 3007 Email: marco.tiloca@ri.se 3009 Goeran Selander 3010 Ericsson AB 3011 Torshamnsgatan 23 3012 Kista SE-16440 Stockholm 3013 Sweden 3015 Email: goran.selander@ericsson.com 3017 Francesca Palombini 3018 Ericsson AB 3019 Torshamnsgatan 23 3020 Kista SE-16440 Stockholm 3021 Sweden 3023 Email: francesca.palombini@ericsson.com 3025 Jiye Park 3026 Universitaet Duisburg-Essen 3027 Schuetzenbahn 70 3028 Essen 45127 3029 Germany 3031 Email: ji-ye.park@uni-due.de