idnits 2.17.1 draft-ietf-core-oscore-groupcomm-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 09, 2020) is 1508 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) ** 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 (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group M. Tiloca 3 Internet-Draft RISE AB 4 Intended status: Standards Track G. Selander 5 Expires: September 10, 2020 F. Palombini 6 Ericsson AB 7 J. Park 8 Universitaet Duisburg-Essen 9 March 09, 2020 11 Group OSCORE - Secure Group Communication for CoAP 12 draft-ietf-core-oscore-groupcomm-07 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 September 10, 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 . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . 9 65 2.5. Wrap-Around of Partial IVs . . . . . . . . . . . . . . . 10 66 3. Pairwise Keys . . . . . . . . . . . . . . . . . . . . . . . . 11 67 3.1. Note on Implementation . . . . . . . . . . . . . . . . . 12 68 4. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.1. Counter Signature . . . . . . . . . . . . . . . . . . . . 12 70 4.2. The 'kid' and 'kid context' parameters . . . . . . . . . 13 71 4.3. external_aad . . . . . . . . . . . . . . . . . . . . . . 13 72 4.3.1. external_aad for Encryption . . . . . . . . . . . . . 13 73 4.3.2. external_aad for Signing . . . . . . . . . . . . . . 14 74 5. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 15 75 5.1. Examples of Compressed COSE Objects . . . . . . . . . . . 15 76 6. Message Binding, Sequence Numbers, Freshness and Replay 77 Protection . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 6.1. Synchronization of Sender Sequence Numbers . . . . . . . 17 79 7. Message Processing . . . . . . . . . . . . . . . . . . . . . 17 80 7.1. Protecting the Request . . . . . . . . . . . . . . . . . 18 81 7.1.1. Supporting Observe . . . . . . . . . . . . . . . . . 18 82 7.2. Verifying the Request . . . . . . . . . . . . . . . . . . 18 83 7.2.1. Supporting Observe . . . . . . . . . . . . . . . . . 19 84 7.3. Protecting the Response . . . . . . . . . . . . . . . . . 20 85 7.3.1. Supporting Observe . . . . . . . . . . . . . . . . . 20 86 7.4. Verifying the Response . . . . . . . . . . . . . . . . . 21 87 7.4.1. Supporting Observe . . . . . . . . . . . . . . . . . 22 88 8. Responsibilities of the Group Manager . . . . . . . . . . . . 22 89 9. Optimized Mode . . . . . . . . . . . . . . . . . . . . . . . 23 90 9.1. Optimized Request . . . . . . . . . . . . . . . . . . . . 23 91 9.1.1. Optimized Compressed Request . . . . . . . . . . . . 23 92 9.2. Optimized Response . . . . . . . . . . . . . . . . . . . 23 93 9.2.1. Optimized Compressed Response . . . . . . . . . . . . 24 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 95 10.1. Group-level Security . . . . . . . . . . . . . . . . . . 25 96 10.2. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 25 97 10.3. Management of Group Keying Material . . . . . . . . . . 26 98 10.4. Update of Security Context and Key Rotation . . . . . . 26 99 10.4.1. Late Update on the Sender . . . . . . . . . . . . . 27 100 10.4.2. Late Update on the Recipient . . . . . . . . . . . . 27 101 10.5. Collision of Group Identifiers . . . . . . . . . . . . . 28 102 10.6. Cross-group Message Injection . . . . . . . . . . . . . 28 103 10.7. Group OSCORE for Unicast Requests . . . . . . . . . . . 29 104 10.8. End-to-end Protection . . . . . . . . . . . . . . . . . 30 105 10.9. Security Context Establishment . . . . . . . . . . . . . 31 106 10.10. Master Secret . . . . . . . . . . . . . . . . . . . . . 31 107 10.11. Replay Protection . . . . . . . . . . . . . . . . . . . 31 108 10.12. Client Aliveness . . . . . . . . . . . . . . . . . . . . 32 109 10.13. Cryptographic Considerations . . . . . . . . . . . . . . 32 110 10.14. Message Segmentation . . . . . . . . . . . . . . . . . . 33 111 10.15. Privacy Considerations . . . . . . . . . . . . . . . . . 33 112 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 113 11.1. Counter Signature Parameters Registry . . . . . . . . . 34 114 11.2. Counter Signature Key Parameters Registry . . . . . . . 36 115 11.3. OSCORE Flag Bits Registry . . . . . . . . . . . . . . . 38 116 11.4. Expert Review Instructions . . . . . . . . . . . . . . . 38 117 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 118 12.1. Normative References . . . . . . . . . . . . . . . . . . 39 119 12.2. Informative References . . . . . . . . . . . . . . . . . 40 120 Appendix A. Assumptions and Security Objectives . . . . . . . . 42 121 A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 42 122 A.2. Security Objectives . . . . . . . . . . . . . . . . . . . 44 123 Appendix B. List of Use Cases . . . . . . . . . . . . . . . . . 45 124 Appendix C. Example of Group Identifier Format . . . . . . . . . 47 125 Appendix D. Set-up of New Endpoints . . . . . . . . . . . . . . 48 126 Appendix E. Examples of Synchronization Approaches . . . . . . . 49 127 E.1. Best-Effort Synchronization . . . . . . . . . . . . . . . 49 128 E.2. Baseline Synchronization . . . . . . . . . . . . . . . . 49 129 E.3. Challenge-Response Synchronization . . . . . . . . . . . 49 130 Appendix F. No Verification of Signatures . . . . . . . . . . . 51 131 Appendix G. Pairwise Mode . . . . . . . . . . . . . . . . . . . 52 132 G.1. Pre-Requirements . . . . . . . . . . . . . . . . . . . . 52 133 G.2. Pairwise Protected Request . . . . . . . . . . . . . . . 53 134 G.3. Pairwise Protected Response . . . . . . . . . . . . . . . 54 135 Appendix H. Document Updates . . . . . . . . . . . . . . . . . . 54 136 H.1. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 54 137 H.2. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 55 138 H.3. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 55 139 H.4. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 56 140 H.5. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 57 141 H.6. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 57 142 H.7. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 58 143 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 59 144 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 146 1. Introduction 148 The Constrained Application Protocol (CoAP) [RFC7252] is a web 149 transfer protocol specifically designed for constrained devices and 150 networks [RFC7228]. Group communication for CoAP 151 [I-D.dijk-core-groupcomm-bis] addresses use cases where deployed 152 devices benefit from a group communication model, for example to 153 reduce latencies, improve performance and reduce bandwidth 154 utilization. Use cases include lighting control, integrated building 155 control, software and firmware updates, parameter and configuration 156 updates, commissioning of constrained networks, and emergency 157 multicast (see Appendix B). This specification defines the security 158 protocol for Group communication for CoAP 159 [I-D.dijk-core-groupcomm-bis]. 161 Object Security for Constrained RESTful Environments (OSCORE) 162 [RFC8613] describes a security protocol based on the exchange of 163 protected CoAP messages. OSCORE builds on CBOR Object Signing and 164 Encryption (COSE) [RFC8152] and provides end-to-end encryption, 165 integrity, replay protection and binding of response to request 166 between a sender and a recipient, independent of transport also in 167 the presence of intermediaries. To this end, a CoAP message is 168 protected by including its payload (if any), certain options, and 169 header fields in a COSE object, which replaces the authenticated and 170 encrypted fields in the protected message. 172 This document defines Group OSCORE, providing the same end-to-end 173 security properties as OSCORE in the case where CoAP requests have 174 multiple recipients. In particular, the described approach defines 175 how OSCORE should be used in a group communication setting to provide 176 source authentication for CoAP group requests, sent by a client to 177 multiple servers, and the corresponding CoAP responses. 179 Group OSCORE provides source authentication of CoAP requests by means 180 of digital signatures produced with the private key of the client and 181 embedded in the protected CoAP messages. CoAP responses from the 182 server may be digitally signed by the private key of the server or 183 integrity protected with a symmetric key derived from a pairwise 184 security context derived from client and server asymmetric keys. 186 Just like OSCORE, Group OSCORE is independent of transport layer and 187 works wherever CoAP does. Group communication for CoAP 188 [I-D.dijk-core-groupcomm-bis] uses UDP/IP multicast as the underlying 189 data transport. 191 As with OSCORE, it is possible to combine Group OSCORE with 192 communication security on other layers. One example is the use of 193 transport layer security, such as DTLS [RFC6347], between one client 194 and one proxy (and vice versa), or between one proxy and one server 195 (and vice versa), in order to protect the routing information of 196 packets from observers. Note that DTLS cannot be used to secure 197 messages sent over IP multicast. 199 Group OSCORE defines different modes of operation: 201 o In the signature mode, Group OSCORE requests and responses are 202 digitally signed. The signature mode supports all COSE algorithms 203 as well as signature verification by intermediaries. 205 o The pairwise mode allows two group members to exchange (unicast) 206 OSCORE requests and responses protected with symmetric keys. 207 These symmetric keys are derived from Diffie-Hellman shared 208 secrets, calculated with the asymmetric keys of the two group 209 members. This allows for shorter integrity tags and therefore 210 lower message overhead. 212 o In the (hybrid) optimized mode, the CoAP requests are digitally 213 signed as in the signature mode, and the CoAP responses are 214 integrity protected with the symmetric key of the pairwise mode. 216 The signature and optimized modes are detailed in the body of this 217 document. The pairwise mode is detailed in Appendix G. Unless 218 otherwise stated, this specification refers to the signature mode. 220 1.1. Terminology 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 224 "OPTIONAL" in this document are to be interpreted as described in BCP 225 14 [RFC2119] [RFC8174] when, and only when, they appear in all 226 capitals, as shown here. 228 Readers are expected to be familiar with the terms and concepts 229 described in CoAP [RFC7252] including "endpoint", "client", "server", 230 "sender" and "recipient"; group communication for CoAP 231 [I-D.dijk-core-groupcomm-bis]; COSE and counter signatures [RFC8152]. 233 Readers are also expected to be familiar with the terms and concepts 234 for protection and processing of CoAP messages through OSCORE, such 235 as "Security Context" and "Master Secret", defined in [RFC8613]. 237 Terminology for constrained environments, such as "constrained 238 device", "constrained-node network", is defined in [RFC7228]. 240 This document refers also to the following terminology. 242 o Keying material: data that is necessary to establish and maintain 243 secure communication among endpoints. This includes, for 244 instance, keys and IVs [RFC4949]. 246 o Group: a set of endpoints that share group keying material and 247 security parameters (Common Context, see Section 2). Unless 248 specified otherwise, the term group used in this specification 249 refers thus to a "security group", not to be confused with 250 CoAP/network/multicast group or application group. 252 o Group Manager: entity responsible for a group. Each endpoint in a 253 group communicates securely with the respective Group Manager, 254 which is neither required to be an actual group member nor to take 255 part in the group communication. The full list of 256 responsibilities of the Group Manager is provided in Section 8. 258 o Silent server: member of a group that never responds to requests. 259 Note that an endpoint can implement both a silent server and a 260 client, the two roles are independent. 262 o Group Identifier (Gid): identifier assigned to the group. Group 263 Identifiers must be unique within the set of groups of a given 264 Group Manager. 266 o Group request: CoAP request message sent by a client in the group 267 to all servers in that group. 269 o Source authentication: evidence that a received message in the 270 group originated from a specific identified group member. This 271 also provides assurance that the message was not tampered with by 272 anyone, be it a different legitimate group member or an endpoint 273 which is not a group member. 275 2. Security Context 277 Each endpoint registered as member of a group maintains a Security 278 Context as defined in Section 3 of [RFC8613], extended as follows 279 (see Figure 1): 281 o One Common Context, shared by all the endpoints in the group. 282 Three new parameters are included in the Common Context: Counter 283 Signature Algorithm, Counter Signature Parameters and Counter 284 Signature Key Parameters. 286 o One Sender Context, extended with the endpoint's private key. The 287 Sender Context is omitted if the endpoint is configured 288 exclusively as silent server. 290 o One Recipient Context for each endpoint from which messages are 291 received. The Recipient Context is extended with the public key 292 of the associated endpoint. 294 +---------------------------+----------------------------------+ 295 | Context Component | New Information Elements | 296 +---------------------------+----------------------------------+ 297 | | Counter Signature Algorithm | 298 | Common Context | Counter Signature Parameters | 299 | | Counter Signature Key Parameters | 300 +---------------------------+----------------------------------+ 301 | Sender Context | Endpoint's own private key | 302 +---------------------------+----------------------------------+ 303 | Each Recipient Context | Public key of the other endpoint | 304 +---------------------------+----------------------------------+ 306 Figure 1: Additions to the OSCORE Security Context 308 2.1. Common Context 310 The ID Context parameter (see Sections 3.3 and 5.1 of [RFC8613]) in 311 the Common Context SHALL contain the Group Identifier (Gid) of the 312 group. The choice of the Gid is application specific. An example of 313 specific formatting of the Gid is given in Appendix C. The 314 application needs to specify how to handle possible collisions 315 between Gids, see Section 10.5. 317 The Counter Signature Algorithm identifies the digital signature 318 algorithm used to compute a counter signature on the COSE object (see 319 Section 4.5 of [RFC8152]). Its value is immutable once the Common 320 Context is established. The used Counter Signature Algorithm MUST be 321 selected among the signing ones defined in the COSE Algorithms 322 Registry (see section 16.4 of [RFC8152]). The EdDSA signature 323 algorithm Ed25519 [RFC8032] is mandatory to implement. If Elliptic 324 Curve Digital Signature Algorithm (ECDSA) is used, it is RECOMMENDED 325 that implementations implement "deterministic ECDSA" as specified in 326 [RFC6979]. 328 The Counter Signature Parameters identifies the parameters associated 329 to the digital signature algorithm specified in the Counter Signature 330 Algorithm. This parameter MAY be empty and is immutable once the 331 Common Context is established. The exact structure of this parameter 332 depends on the value of Counter Signature Algorithm, and is defined 333 in the Counter Signature Parameters Registry (see Section 11.1), 334 where each entry indicates a specified structure of the Counter 335 Signature Parameters. 337 The Counter Signature Key Parameters identifies the parameters 338 associated to the keys used with the digital signature algorithm 339 specified in the Counter Signature Algorithm. This parameter MAY be 340 empty and is immutable once the Common Context is established. The 341 exact structure of this parameter depends on the value of Counter 342 Signature Algorithm, and is defined in the Counter Signature Key 343 Parameters Registry (see Section 11.2), where each entry indicates a 344 specified structure of the Counter Signature Key Parameters. 346 2.2. Sender Context and Recipient Context 348 OSCORE specifies the derivation of Sender Context and Recipient 349 Context, specifically Sender/Recipient Keys and Common IV, from a set 350 of input parameters (see Section 3.2 of [RFC8613]). This derivation 351 applies also to Group OSCORE, and the mandatory-to-implement HKDF and 352 AEAD algorithms are the same as in [RFC8613]. However, for Group 353 OSCORE the Sender Context and Recipient Context additionally contain 354 asymmetric keys. 356 The Sender Context needs to be configured with the private key of the 357 endpoint. The private key is used to generate a signature (see 358 Section 4) included in the sent OSCORE message. How the private key 359 is established is out of scope for this specification. 361 Each Recipient Context needs to be configured with the public key of 362 the associated endpoint. The public key is used to verify a 363 signature (see Section 4) included in the received OSCORE message. 365 The input parameters for deriving the Recipient Context parameters 366 and the public key of the associated endpoint may be provided to the 367 recipient endpoint upon joining the group. These parameters may 368 alternatively be acquired at a later time, for example the first time 369 a message is received from this particular endpoint in the group (see 370 Section 7.2 and Section 7.4). The received message together with the 371 Common Context contains the necessary information to derive a 372 security context for verifying a message, except for the public key 373 of the associated endpoint. 375 For severely constrained devices, it may be not feasible to 376 simultaneously handle the ongoing processing of a recently received 377 message in parallel with the retrieval of the associated endpoint's 378 public key. Such devices can be configured to drop a received 379 message for which there is no Recipient Context, and instead retrieve 380 the public key in order to have it available to verify subsequent 381 messages from that endpoint. 383 Note that each Recipient Context includes a Replay Window, unless the 384 recipient acts only as client and hence processes only responses as 385 incoming messages. 387 2.3. The Group Manager 389 Endpoints communicating with Group OSCORE need, in addition to the 390 OSCORE input parameters, also to be provisioned with information 391 about the group(s) and other endpoints in the group(s). 393 The Group Manager is an entity responsible for the group, including 394 the Group Identifier (Gid), as well as Sender ID and Recipient ID of 395 the group members (see Section 8). The Group Manager records the 396 public keys of endpoints joining the group and provides information 397 about the group and its members to other members. 399 An endpoint receives the Group Identifier and OSCORE input 400 parameters, including its own Sender ID, from the Group Manager upon 401 joining the group. That Sender ID is valid only within that group, 402 and is unique within the group. Endpoints which are configured only 403 as silent servers do not have a Sender ID. 405 A group member can retrieve public keys and other information 406 associated to another group member from the Group Manager, from which 407 it can generate the Recipient Context. An application can configure 408 a group member to asynchronously retrieve information about Recipient 409 Contexts, e.g. by Observing [RFC7641] the Group Manager to get 410 updates on the group membership. 412 According to this specification, it is RECOMMENDED to use a Group 413 Manager as described in [I-D.ietf-ace-key-groupcomm-oscore], where 414 the join process is based on the ACE framework for authentication and 415 authorization in constrained environments [I-D.ietf-ace-oauth-authz]. 416 Further details about how public keys can be handled and retrieved in 417 the group is out of the scope of this document. 419 2.4. Management of Group Keying Material 421 In order to establish a new Security Context in a group, a new Group 422 Identifier (Gid) for that group and a new value for the Master Secret 423 parameter MUST be distributed. An example of Gid format supporting 424 this operation is provided in Appendix C. When distributing the new 425 Gid and Master Secret, the Group Manager MAY distribute also a new 426 value for the Master Salt parameter, and SHOULD preserve the current 427 value of the Sender ID of each group member. 429 Then, each group member re-derives the keying material stored in its 430 own Sender Context and Recipient Contexts as described in Section 2, 431 using the updated Gid and Master Secret parameter. The Master Salt 432 used for the re-derivations is the updated Master Salt parameter if 433 provided by the Group Manager, or the empty byte string otherwise. 434 From then on, each group member MUST use its latest installed Sender 435 Context to protect outgoing messages. 437 After a new Gid has been distributed, a same Recipient ID ('kid') 438 should not be considered as a persistent and reliable indicator of 439 the same group member. Such an indication can be actually achieved 440 only by verifying countersignatures of received messages. As a 441 consequence, group members may end up retaining stale Recipient 442 Contexts, that are no longer useful to verify incoming secure 443 messages. Applications may define policies to delete (long-)unused 444 Recipient Contexts and reduce the impact on storage space. 446 The distribution of a new Gid and Master Secret may result in 447 temporarily misaligned Security Contexts among group members. In 448 particular, this may result in a group member not able to process 449 messages received right after a new Gid and Master Secret have been 450 distributed. A discussion on practical consequences and possible 451 ways to address them is provided in Section 10.4. 453 If required by the application (see Appendix A.1), it is RECOMMENDED 454 to adopt a group key management scheme, and securely distribute a new 455 value for the Gid and for the Master Secret parameter of the group's 456 Security Context, before a new joining endpoint is added to the group 457 or after a currently present endpoint leaves the group. This is 458 necessary to preserve backward security and forward security in the 459 group, if the application requires it. 461 The specific approach used to distribute the new Gid and Master 462 Secret parameter to the group is out of the scope of this document. 463 However, it is RECOMMENDED that the Group Manager supports the 464 distribution of the new Gid and Master Secret parameter to the group 465 according to the Group Rekeying Process described in 466 [I-D.ietf-ace-key-groupcomm-oscore]. 468 2.5. Wrap-Around of Partial IVs 470 An endpoint can eventually experience a wrap-around of its own Sender 471 Sequence Number, which is incremented after sending each new message 472 including a Partial IV. This is the case for all group requests, all 473 Observe notifications [RFC7641] and, optionally, any other response. 475 When a wrap-around happens, the endpoint MUST NOT transmit further 476 messages for that group until it has derived a new Sender Context, in 477 order to avoid reusing nonces with the same keys. 479 Furthermore, the endpoint SHOULD inform the Group Manager, that can 480 take one of the following actions: 482 o The Group Manager renews the Security Context in the group (see 483 Section 2.4). 485 o The Group Manager provides a new Sender ID value to the endpoint 486 that has experienced the wrap-around. Then, the endpoint derives 487 a new Sender Context using the new Sender ID, as described in 488 Section 3.2 of [RFC8613]. 490 In either case, same considerations from Section 2.4 hold about 491 possible retaining of stale Recipient Contexts. 493 3. Pairwise Keys 495 Certain signature schemes, such as EdDSA and ECDSA, support a secure 496 combined signature and encryption scheme. This section specifies the 497 derivation of pairwise encryption keys for use in the pairwise and 498 optimized modes of Group OSCORE. 500 Two group members can derive a symmetric pairwise key, from their 501 Sender/Recipient Key and a static-static Diffe-Hellman shared secret. 502 The key derivation is as follows, and uses the same construction used 503 in Section 3.2.1 of [RFC8613]. 505 Pairwise key = HKDF(Sender/Recipient Key, Shared Secret, info, L) 507 where: 509 o The Sender/Recipient key is the Sender Key of the sender, i.e. the 510 Recipient Key that the recipient stores in its own Recipient 511 Context corresponding to the sender. 513 o The Shared Secret is computed as a static-static Diffie-Hellman 514 shared secret, where the sender uses its own private key and the 515 recipient's public key, while the recipient uses its own private 516 key and the senders's public key. 518 o info and L are defined as in Section 3.2.1 of [RFC8613]. 520 The security of using the same key pair for Diffie-Hellman and for 521 signing is proven in [Degabriele]. The derivation of pairwise keys 522 defined above is compatible with ECDSA and EdDSA asymmetric keys, but 523 is not compatible with RSA asymmetric keys. 525 If EdDSA asymmetric keys are used, the Edward coordinates are mapped 526 to Montgomery coordinates using the maps defined in Sections 4.1 and 527 4.2 of [RFC7748], before using the X25519 and X448 functions defined 528 in Section 5 of [RFC7748]. 530 3.1. Note on Implementation 532 In order to optimize performance, an endpoint A may derive a pairwise 533 key used with an endpoint B in the OSCORE group only once, and then 534 store it in its own Security Context for future retrieval. This can 535 work as follows. 537 Endpoint A can have a Pairwise Sender Context associated to B, within 538 its own Sender Context. This Pairwise Sender Context includes: 540 o The Recipient ID of B for A, i.e. the Sender ID of B. 542 o The Pairwise Key derived as defined in Section 3, with A acting as 543 sender and B acting as recipient. 545 More generally, A has one of such Paiwise Sender Contexts within its 546 own Sender Context, for each different intended recipient. 548 Furthermore, A can additionally store in its own Recipient Context 549 associated to B the Pairwise Key to use for incoming traffic from B. 550 That is, this Pairwise Key is derived as defined in Section 3, with A 551 acting as recipient and B acting as sender. 553 4. The COSE Object 555 Building on Section 5 of [RFC8613], this section defines how to use 556 COSE [RFC8152] to wrap and protect data in the original message. 557 OSCORE uses the untagged COSE_Encrypt0 structure with an 558 Authenticated Encryption with Associated Data (AEAD) algorithm. For 559 the signature mode of Group OSCORE the following modifications apply. 561 4.1. Counter Signature 563 The 'unprotected' field MUST additionally include the following 564 parameter: 566 o CounterSignature0 : its value is set to the counter signature of 567 the COSE object, computed by the sender as described in 568 Appendix A.2 of [RFC8152], by using its own private key and 569 according to the Counter Signature Algorithm and Counter Signature 570 Parameters in the Security Context. In particular, the 571 Sig_structure contains the external_aad as defined in 572 Section 4.3.2 and the ciphertext of the COSE_Encrypt0 object as 573 payload. 575 4.2. The 'kid' and 'kid context' parameters 577 The value of the 'kid' parameter in the 'unprotected' field of 578 response messages MUST be set to the Sender ID of the endpoint 579 transmitting the message. That is, unlike in [RFC8613], the 'kid' 580 parameter is always present in all messages, i.e. both requests and 581 responses. 583 The value of the 'kid context' parameter in the 'unprotected' field 584 of requests messages MUST be set to the ID Context, i.e. the Group 585 Identifier value (Gid) of the group's Security Context. That is, 586 unlike in [RFC8613], the 'kid context' parameter is always present in 587 requests. 589 4.3. external_aad 591 The external_aad of the Additional Authenticated Data (AAD) is built 592 differently. In particular, it has one structure used for the 593 encryption process producing the ciphertext, and one structure used 594 for the signing process producing the counter signature. 596 4.3.1. external_aad for Encryption 598 The first external_aad structure used for the encryption process 599 producing the ciphertext (see Section 5.3 of [RFC8152]) includes also 600 the counter signature algorithm and related parameters used to sign 601 messages. In particular, compared with Section 5.4 of [RFC8613], the 602 'algorithms' array in the aad_array MUST also include: 604 o 'alg_countersign', which contains the Counter Signature Algorithm 605 from the Common Context (see Section 2). This parameter has the 606 value specified in the "Value" field of the Counter Signature 607 Parameters Registry (see Section 11.1) for this counter signature 608 algorithm. 610 o 'par_countersign', which contains the Counter Signature Parameters 611 from the Common Context (see Section 2). This parameter contains 612 the counter signature parameters encoded as specified in the 613 "Parameters" field of the Counter Signature Parameters Registry 614 (see Section 11.1), for the used counter signature algorithm. If 615 the Counter Signature Parameters in the Common Context is empty, 616 'par_countersign' MUST be encoding the CBOR simple value Null. 618 o 'par_countersign_key', which contains the Counter Signature Key 619 Parameters from the Common Context (see Section 2). This 620 parameter contains the counter signature key parameters encoded as 621 specified in the "Parameters" field of the Counter Signature Key 622 Parameters Registry (see Section 11.2), for the used counter 623 signature algorithm. If the Counter Signature Key Parameters in 624 the Common Context is empty, 'par_countersign_key' MUST be 625 encoding the CBOR simple value Null. 627 Thus, the following external_aad structure is used for the encryption 628 process producing the ciphertext (see Section 5.3 of [RFC8152]). 630 external_aad = bstr .cbor aad_array 632 aad_array = [ 633 oscore_version : uint, 634 algorithms : [alg_aead : int / tstr, 635 alg_countersign : int / tstr, 636 par_countersign : any / nil, 637 par_countersign_key : any / nil], 638 request_kid : bstr, 639 request_piv : bstr, 640 options : bstr 641 ] 643 4.3.2. external_aad for Signing 645 The second external_aad structure used for the signing process 646 producing the counter signature as defined below includes also: 648 o the counter signature algorithm and related parameters used to 649 sign messages, encoded as in the external_aad structure defined in 650 Section 4.3.1; 652 o the value of the OSCORE Option included in the OSCORE message, 653 encoded as a binary string. 655 Thus, the following external_aad structure is used for the signing 656 process producing the counter signature, as defined below. 658 external_aad = bstr .cbor aad_array 660 aad_array = [ 661 oscore_version : uint, 662 algorithms : [alg_aead : int / tstr, 663 alg_countersign : int / tstr, 664 par_countersign : any / nil, 665 par_countersign_key : any / nil], 666 request_kid : bstr, 667 request_piv : bstr, 668 options : bstr, 669 OSCORE_option: bstr 670 ] 671 Note for implementation: this requires the value of the OSCORE option 672 to be fully ready, before starting the signing process. 674 5. OSCORE Header Compression 676 The OSCORE header compression defined in Section 6 of [RFC8613] is 677 used, with the following differences. 679 o The payload of the OSCORE message SHALL encode the ciphertext of 680 the COSE object concatenated with the value of the 681 CounterSignature0 of the COSE object, computed as described in 682 Section 4.1. 684 o This specification defines the usage of the sixth least 685 significant bit, namely the Pairwise Flag bit, in the first byte 686 of the OSCORE option containing the OSCORE flag bits. This flag 687 bit is registered in Section 11.3 of this specification. 689 o The Pairwise Flag bit is set to 1 if the OSCORE message is 690 protected using pairwise keying material, which is shared with a 691 single group member as single intended recipient and derived as 692 defined in Section 3. This is used, for instance, to send 693 responses with the optimized mode defined in Section 9. In any 694 other case, especially when the OSCORE message is protected as per 695 Section 7.1 and Section 7.3, this bit MUST be set to 0. 697 If any of the following conditions holds, a recipient MUST discard 698 an incoming OSCORE message with the Pairwise Flag bit set to 1: 700 * The recipient does not support this feature, i.e. it is not 701 capable or willing to process OSCORE messages protected using 702 pairwise keying material. 704 * The recipient can not retrieve a Security Context which is both 705 valid to process the message and also associated to an OSCORE 706 group. 708 5.1. Examples of Compressed COSE Objects 710 This section covers a list of OSCORE Header Compression examples for 711 group requests and responses. The examples assume that the 712 COSE_Encrypt0 object is set (which means the CoAP message and 713 cryptographic material is known). Note that the examples do not 714 include the full CoAP unprotected message or the full Security 715 Context, but only the input necessary to the compression mechanism, 716 i.e. the COSE_Encrypt0 object. The output is the compressed COSE 717 object as defined in Section 5 and divided into two parts, since the 718 object is transported in two CoAP fields: OSCORE option and payload. 720 The examples assume that the label for the new kid context defined in 721 [RFC8613] has value 10. COUNTERSIGN is the CounterSignature0 byte 722 string as described in Section 4 and is 64 bytes long. 724 1. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = 725 0x25, Partial IV = 5 and kid context = 0x44616c 727 Before compression (96 bytes): 729 [ 730 h'', 731 { 4:h'25', 6:h'05', 10:h'44616c', 9:COUNTERSIGN }, 732 h'aea0155667924dff8a24e4cb35b9' 733 ] 735 After compression (85 bytes): 737 Flag byte: 0b00011001 = 0x19 739 Option Value: 19 05 03 44 61 6c 25 (7 bytes) 741 Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 COUNTERSIGN 742 (14 bytes + size of COUNTERSIGN) 744 1. Response with ciphertext = 60b035059d9ef5667c5a0710823b, kid = 745 0x52 and no Partial IV. 747 Before compression (88 bytes): 749 [ 750 h'', 751 { 4:h'52', 9:COUNTERSIGN }, 752 h'60b035059d9ef5667c5a0710823b' 753 ] 755 After compression (80 bytes): 757 Flag byte: 0b00001000 = 0x08 759 Option Value: 08 52 (2 bytes) 761 Payload: 60 b0 35 05 9d 9e f5 66 7c 5a 07 10 82 3b COUNTERSIGN 762 (14 bytes + size of COUNTERSIGN) 764 6. Message Binding, Sequence Numbers, Freshness and Replay Protection 766 The requirements and properties described in Section 7 of [RFC8613] 767 also apply to OSCORE used in group communication. In particular, 768 group OSCORE provides message binding of responses to requests, which 769 provides relative freshness of responses, and replay protection of 770 requests. 772 6.1. Synchronization of Sender Sequence Numbers 774 Upon joining the group, new servers are not aware of the Sender 775 Sequence Number values currently used by different clients to 776 transmit group requests. This means that, when such servers receive 777 a secure group request from a given client for the first time, they 778 are not able to verify if that request is fresh and has not been 779 replayed or (purposely) delayed. The same holds when a server loses 780 synchronization with Sender Sequence Numbers of clients, for instance 781 after a device reboot. 783 The exact way to address this issue is application specific, and 784 depends on the particular use case and its synchronization 785 requirements. The list of methods to handle synchronization of 786 Sender Sequence Numbers is part of the group communication policy, 787 and different servers can use different methods. 789 Appendix E describes three possible approaches that can be considered 790 for synchronization of sequence numbers. 792 7. Message Processing 794 Each request message and response message is protected and processed 795 as specified in [RFC8613], with the modifications described in the 796 following sections. The following security objectives are fulfilled, 797 as further discussed in Appendix A.2: data replay protection, group- 798 level data confidentiality, source authentication and message 799 integrity. 801 As per [RFC7252][I-D.dijk-core-groupcomm-bis], group requests sent 802 over multicast MUST be Non-Confirmable. Thus, senders should store 803 their outgoing messages for an amount of time defined by the 804 application and sufficient to correctly handle possible 805 retransmissions. However, this does not prevent the acknowledgment 806 of Confirmable group requests in non-multicast environments. 807 Besides, according to Section 5.2.3 of [RFC7252], responses to Non- 808 Confirmable group requests SHOULD be also Non-Confirmable. However, 809 endpoints MUST be prepared to receive Confirmable responses in reply 810 to a Non-Confirmable group request. 812 Furthermore, endpoints in the group locally perform error handling 813 and processing of invalid messages according to the same principles 814 adopted in [RFC8613]. However, a recipient MUST stop processing and 815 silently reject any message which is malformed and does not follow 816 the format specified in Section 4, or which is not cryptographically 817 validated in a successful way. Either case, it is RECOMMENDED that 818 the recipient does not send back any error message. This prevents 819 servers from replying with multiple error messages to a client 820 sending a group request, so avoiding the risk of flooding and 821 possibly congesting the group. 823 7.1. Protecting the Request 825 A client transmits a secure group request as described in Section 8.1 826 of [RFC8613], with the following modifications. 828 o In step 2, the 'algorithms' array in the Additional Authenticated 829 Data is modified as described in Section 4 of this specification. 831 o In step 4, the encryption of the COSE object is modified as 832 described in Section 4 of this specification. The encoding of the 833 compressed COSE object is modified as described in Section 5 of 834 this specification. 836 o In step 5, the counter signature is computed and the format of the 837 OSCORE message is modified as described in Section 4 and Section 5 838 of this specification. In particular, the payload of the OSCORE 839 message includes also the counter signature. 841 7.1.1. Supporting Observe 843 If Observe [RFC7641] is supported, for each newly started 844 observation, the client MUST store the value of the 'kid' parameter 845 from the original Observe request. 847 The client MUST NOT update the stored value, even in case it is 848 individually rekeyed and receives a new Sender ID from the Group 849 Manager (see Section 2.5). 851 7.2. Verifying the Request 853 Upon receiving a secure group request, a server proceeds as described 854 in Section 8.2 of [RFC8613], with the following modifications. 856 o In step 2, the decoding of the compressed COSE object follows 857 Section 5 of this specification. In particular: 859 * If the Pairwise Flag bit is set to 1, and the server discards 860 the request due to not supporting this feature or not 861 retrieving a Security Context associated to the OSCORE group, 862 the server MAY respond with a 4.02 (Bad Option) error. When 863 doing so, the server MAY set an Outer Max-Age option with value 864 zero, and MAY include a descriptive string as diagnostic 865 payload. 867 * If the received Recipient ID ('kid') does not match with any 868 Recipient Context for the retrieved Gid ('kid context'), then 869 the server MAY create a new Recipient Context and initializes 870 it according to Section 3 of [RFC8613], also retrieving the 871 client's public key. Such a configuration is application 872 specific. If the application does not specify dynamic 873 derivation of new Recipient Contexts, then the server SHALL 874 stop processing the request. 876 o In step 4, the 'algorithms' array in the Additional Authenticated 877 Data is modified as described in Section 4 of this specification. 879 o In step 6, the server also verifies the counter signature using 880 the public key of the client from the associated Recipient 881 Context. If the signature verification fails, the server MAY 882 reply with a 4.00 (Bad Request) response. 884 o Additionally, if the used Recipient Context was created upon 885 receiving this group request and the message is not verified 886 successfully, the server MAY delete that Recipient Context. Such 887 a configuration, which is specified by the application, would 888 prevent attackers from overloading the server's storage and 889 creating processing overhead on the server. 891 A server SHOULD NOT process a request if the received Recipient ID 892 ('kid') is equal to its own Sender ID in its own Sender Context. 894 7.2.1. Supporting Observe 896 If Observe [RFC7641] is supported, for each newly started 897 observation, the server MUST store the value of the 'kid' parameter 898 from the original Observe request. 900 The server MUST NOT update the stored value, even in case the 901 observer client is individually rekeyed and starts using a new Sender 902 ID received from the Group Manager (see Section 2.5). 904 7.3. Protecting the Response 906 A server that has received a secure group request may reply with a 907 secure response, which is protected as described in Section 8.3 of 908 [RFC8613], with the following modifications. 910 o In step 2, the 'algorithms' array in the Additional Authenticated 911 Data is modified as described in Section 4 of this specification. 913 o In step 4, the encryption of the COSE object is modified as 914 described in Section 4 of this specification. The encoding of the 915 compressed COSE object is modified as described in Section 5 of 916 this specification. 918 o In step 5, the counter signature is computed and the format of the 919 OSCORE mesage is modified as described in Section 5 of this 920 specification. In particular, the payload of the OSCORE message 921 includes also the counter signature. 923 Note that the server MUST always protect a response by using its own 924 Sender Context from the latest owned Security Context. 926 Consistently, upon the establishment of a new Security Context, the 927 server may end up protecting a response by using a Security Context 928 different from the one used to protect the group request (see 929 Section 10.4). In such a case, the server SHOULD also: 931 o Encode the Partial IV (Sender Sequence Number in network byte 932 order), which is set to the Sender Sequence Number of the server; 933 increment the Sender Sequence Number by one; compute the AEAD 934 nonce from the Sender ID, Common IV, and Partial IV. 936 o Include in the respose the 'Partial IV' parameter, which is set to 937 the encoded Partial IV value above. 939 o Include in the response the 'kid context' parameter, which is set 940 to the ID Context of the new Security Context, i.e. the new Group 941 Identifier (Gid). 943 7.3.1. Supporting Observe 945 If Observe [RFC7641] is supported, the server may have ongoing 946 observations, started by Observe requests protected with an old 947 Security Context. 949 After completing the establishment of a new Security Context, the 950 server MUST protect the following notifications with its own Sender 951 Context from the new Security Context. 953 For each ongoing observation, the server SHOULD include in the first 954 notification protected with the new Security Context also the 'kid 955 context' parameter, which is set to the ID Context of the new 956 Security Context, i.e. the new Group Identifier (Gid). It is 957 OPTIONAL for the server to include the 'kid context' parameter, as 958 set to the new Gid, also in further following notifications for those 959 observations. 961 Furthermore, for each ongoing observation, the server MUST use the 962 stored value of the 'kid' parameter from the original Observe 963 request, as value for the 'request_kid' parameter in the two 964 external_aad structures (see Section 4.3.1 and Section 4.3.2), when 965 protecting notifications for that observation. 967 7.4. Verifying the Response 969 Upon receiving a secure response message, the client proceeds as 970 described in Section 8.4 of [RFC8613], with the following 971 modifications. 973 o In step 2, the decoding of the compressed COSE object is modified 974 as described in Section 4 of this specification. If the received 975 Recipient ID ('kid') does not match with any Recipient Context for 976 the retrieved Gid ('kid context'), then the client MAY create a 977 new Recipient Context and initializes it according to Section 3 of 978 [RFC8613], also retrieving the server's public key. If the 979 application does not specify dynamic derivation of new Recipient 980 Contexts, then the client SHALL stop processing the response. 982 o In step 3, the 'algorithms' array in the Additional Authenticated 983 Data is modified as described in Section 4 of this specification. 985 o In step 5, the client also verifies the counter signature using 986 the public key of the server from the associated Recipient 987 Context. 989 o Additionally, if the used Recipient Context was created upon 990 receiving this response and the message is not verified 991 successfully, the client MAY delete that Recipient Context. Such 992 a configuration, which is specified by the application, would 993 prevent attackers from overloading the client's storage and 994 creating processing overhead on the client. 996 Note that, as discussed in Section 10.4, a client may receive a 997 response protected with a Security Context different from the one 998 used to protect the corresponding group request. 1000 7.4.1. Supporting Observe 1002 If Observe [RFC7641] is supported, for each ongoing observation, the 1003 client MUST use the stored value of the 'kid' parameter from the 1004 original Observe request, as value for the 'request_kid' parameter in 1005 the two external_aad structures (see Section 4.3.1 and 1006 Section 4.3.2), when verifying notifications for that observation. 1008 This ensures that the client can correctly verify notifications, even 1009 in case it is individually rekeyed and starts using a new Sender ID 1010 received from the Group Manager (see Section 2.5). 1012 8. Responsibilities of the Group Manager 1014 The Group Manager is responsible for performing the following tasks: 1016 1. Creating and managing OSCORE groups. This includes the 1017 assignment of a Gid to every newly created group, as well as 1018 ensuring uniqueness of Gids within the set of its OSCORE groups. 1020 2. Defining policies for authorizing the joining of its OSCORE 1021 groups. 1023 3. Handling the join process to add new endpoints as group members. 1025 4. Establishing the Common Context part of the Security Context, 1026 and providing it to authorized group members during the join 1027 process, together with the corresponding Sender Context. 1029 5. Generating and managing Sender IDs within its OSCORE groups, as 1030 well as assigning and providing them to new endpoints during the 1031 join process. This includes ensuring uniqueness of Sender IDs 1032 within each of its OSCORE groups. 1034 6. Defining a communication policy for each of its OSCORE groups, 1035 and signalling it to new endpoints during the join process. 1037 7. Renewing the Security Context of an OSCORE group upon membership 1038 change, by revoking and renewing common security parameters and 1039 keying material (rekeying). 1041 8. Providing the management keying material that a new endpoint 1042 requires to participate in the rekeying process, consistent with 1043 the key management scheme used in the group joined by the new 1044 endpoint. 1046 9. Updating the Gid of its OSCORE groups, upon renewing the 1047 respective Security Context. 1049 10. Acting as key repository, in order to handle the public keys of 1050 the members of its OSCORE groups, and providing such public keys 1051 to other members of the same group upon request. The actual 1052 storage of public keys may be entrusted to a separate secure 1053 storage device. 1055 11. Validating that the format and parameters of public keys of 1056 group members are consistent with the countersignature algorithm 1057 and related parameters used in the respective OSCORE group. 1059 9. Optimized Mode 1061 For use cases that do not require an intermediary performing 1062 signature verification and that use a compatible signature algorithm, 1063 the optimized mode defined in this section provides significant 1064 smaller message sizes and increases the security by making responses 1065 confidential to other group members than the intended recipient. 1067 9.1. Optimized Request 1069 No changes. 1071 9.1.1. Optimized Compressed Request 1073 The OSCORE header compression defined in Section 5 is used, with the 1074 following difference: the payload of the OSCORE message SHALL encode 1075 the ciphertext without the tag, concatenated with the value of the 1076 CounterSignature0 of the COSE object computed as described in 1077 Section 4.1. 1079 The optimized compressed request is compatible with all AEAD 1080 algorithms defined in [RFC8152], but would not be compatible with 1081 AEAD algorithms that do not have a well-defined tag. 1083 9.2. Optimized Response 1085 An optimized response is protected as defined in Section 7.3, with 1086 the following differences. 1088 o The server MUST set to 1 the sixth least significant bit of the 1089 OSCORE flag bits in the OSCORE option, i.e. the Pairwise Flag. 1091 o The COSE_Encrypt0 object included in the optimized response is 1092 encrypted using a symmetric pairwise key K, that the server 1093 derives as defined in Section 3. In particular, the Sender/ 1094 Recipient Key is the Sender Key of the server from its own Sender 1095 Context, i.e. the Recipient Key that the client stores in its own 1096 Recipient Context corresponding to the server. 1098 o The Counter Signature is not computed. That is, unlike defined in 1099 Section 5, the payload of the OSCORE message terminates with the 1100 encoded ciphertext of the COSE object. 1102 Note that no changes are made to the AEAD nonce and AAD. 1104 Upon receiving a response with the Pairwise Flag set to 1, the client 1105 MUST process it as defined in Section 7.4, with the following 1106 differences. 1108 o No countersignature to verify is included. 1110 o The COSE_Encrypt0 object included in the optimized response is 1111 decrypted and verified using the same symmetric pairwise key K, 1112 that the client derives as described above for the server side and 1113 as defined in Section 3. 1115 9.2.1. Optimized Compressed Response 1117 No changes. 1119 10. Security Considerations 1121 The same threat model discussed for OSCORE in Appendix D.1 of 1122 [RFC8613] holds for Group OSCORE. In addition, source authentication 1123 of messages is explicitly ensured by means of counter signatures, as 1124 further discussed in Section 10.1. 1126 The same considerations on supporting Proxy operations discussed for 1127 OSCORE in Appendix D.2 of [RFC8613] hold for Group OSCORE. 1129 The same considerations on protected message fields for OSCORE 1130 discussed in Appendix D.3 of [RFC8613] hold for Group OSCORE. 1132 The same considerations on uniqueness of (key, nonce) pairs for 1133 OSCORE discussed in Appendix D.4 of [RFC8613] hold for Group OSCORE. 1134 This is further discussed in Section 10.2. 1136 The same considerations on unprotected message fields for OSCORE 1137 discussed in Appendix D.5 of [RFC8613] hold for Group OSCORE, with 1138 the following difference. The countersignature included in a Group 1139 OSCORE message is computed also over the value of the OSCORE option, 1140 which is part of the Additional Authenticated Data used in the 1141 signing process. This is further discussed in Section 10.6. 1143 As discussed in Section 6.2.3 of [I-D.dijk-core-groupcomm-bis], Group 1144 OSCORE addresses security attacks against CoAP listed in Sections 1145 11.2-11.6 of [RFC7252], especially when mounted over IP multicast. 1147 The rest of this section first discusses security aspects to be taken 1148 into account when using Group OSCORE. Then it goes through aspects 1149 covered in the security considerations of OSCORE (Section 12 of 1150 [RFC8613]), and discusses how they hold when Group OSCORE is used. 1152 10.1. Group-level Security 1154 The approach described in this document relies on commonly shared 1155 group keying material to protect communication within a group. This 1156 has the following implications. 1158 o Messages are encrypted at a group level (group-level data 1159 confidentiality), i.e. they can be decrypted by any member of the 1160 group, but not by an external adversary or other external 1161 entities. 1163 o The AEAD algorithm provides only group authentication, i.e. it 1164 ensures that a message sent to a group has been sent by a member 1165 of that group, but not by the alleged sender. This is why source 1166 authentication of messages sent to a group is ensured through a 1167 counter signature, which is computed by the sender using its own 1168 private key and then appended to the message payload. 1170 Note that, even if an endpoint is authorized to be a group member and 1171 to take part in group communications, there is a risk that it behaves 1172 inappropriately. For instance, it can forward the content of 1173 messages in the group to unauthorized entities. However, in many use 1174 cases, the devices in the group belong to a common authority and are 1175 configured by a commissioner (see Appendix B), which results in a 1176 practically limited risk and enables a prompt detection/reaction in 1177 case of misbehaving. 1179 10.2. Uniqueness of (key, nonce) 1181 The proof for uniqueness of (key, nonce) pairs in Appendix D.4 of 1182 [RFC8613] is also valid in group communication scenarios. That is, 1183 given an OSCORE group: 1185 o Uniqueness of Sender IDs within the group is enforced by the Group 1186 Manager. 1188 o The case A in Appendix D.4 of [RFC8613] concerns all group 1189 requests and responses including a Partial IV (e.g. Observe 1190 notifications). In this case, same considerations from [RFC8613] 1191 apply here as well. 1193 o The case B in Appendix D.4 of [RFC8613] concerns responses not 1194 including a Partial IV (e.g. single response to a group request). 1196 In this case, same considerations from [RFC8613] apply here as 1197 well. 1199 As a consequence, each message encrypted/decrypted with the same 1200 Sender Key is processed by using a different (ID_PIV, PIV) pair. 1201 This means that nonces used by any fixed encrypting endpoint are 1202 unique. Thus, each message is processed with a different (key, 1203 nonce) pair. 1205 10.3. Management of Group Keying Material 1207 The approach described in this specification should take into account 1208 the risk of compromise of group members. In particular, this 1209 document specifies that a key management scheme for secure revocation 1210 and renewal of Security Contexts and group keying material should be 1211 adopted. 1213 Especially in dynamic, large-scale, groups where endpoints can join 1214 and leave at any time, it is important that the considered group key 1215 management scheme is efficient and highly scalable with the group 1216 size, in order to limit the impact on performance due to the Security 1217 Context and keying material update. 1219 10.4. Update of Security Context and Key Rotation 1221 A group member can receive a message shortly after the group has been 1222 rekeyed, and new security parameters and keying material have been 1223 distributed by the Group Manager. 1225 This may result in a client using an old Security Context to protect 1226 a group request, and a server using a different new Security Context 1227 to protect a corresponding response. That is, clients may receive a 1228 response protected with a Security Context different from the one 1229 used to protect the corresponding group request. 1231 In particular, a server may first get a group request protected with 1232 the old Security Context, then install the new Security Context, and 1233 only after that produce a response to send back to the client. Since 1234 a sender always protects an outgoing message using the latest owned 1235 Security Context, the server discussed above protects the possible 1236 response using the new Security Context. Then, the client will 1237 process that response using the new Security Context, provided that 1238 it has installed the new security parameters and keying material 1239 before the message reception. 1241 In case block-wire transfer [RFC7959] is used, the same 1242 considerations from Section 7.2 of [I-D.ietf-ace-key-groupcomm] hold. 1244 Furthermore, as described below, a group rekeying may temporarily 1245 result in misaligned Security Contexts between the sender and 1246 recipient of a same message. 1248 10.4.1. Late Update on the Sender 1250 In this case, the sender protects a message using the old Security 1251 Context, i.e. before having installed the new Security Context. 1252 However, the recipient receives the message after having installed 1253 the new Security Context, hence not being able to correctly process 1254 it. 1256 A possible way to ameliorate this issue is to preserve the old, 1257 recent, Security Context for a maximum amount of time defined by the 1258 application. By doing so, the recipient can still try to process the 1259 received message using the old retained Security Context as second 1260 attempt. This makes particular sense when the recipient is a client, 1261 that would hence be able to process incoming responses protected with 1262 the old, recent, Security Context used to protect the associated 1263 group request. Instead, a recipient server would better and more 1264 simply discard an incoming group request which is not successfully 1265 processed with the new Security Context. 1267 This tolerance preserves the processing of secure messages throughout 1268 a long-lasting key rotation, as group rekeying processes may likely 1269 take a long time to complete, especially in large scale groups. On 1270 the other hand, a former (compromised) group member can abusively 1271 take advantage of this, and send messages protected with the old 1272 retained Security Context. Therefore, a conservative application 1273 policy should not admit the retention of old Security Contexts. 1275 10.4.2. Late Update on the Recipient 1277 In this case, the sender protects a message using the new Security 1278 Context, but the recipient receives that message before having 1279 installed the new Security Context. Therefore, the recipient would 1280 not be able to correctly process the message and hence discards it. 1282 If the recipient installs the new Security Context shortly after that 1283 and the sender endpoint uses CoAP retransmissions, the former will 1284 still be able to receive and correctly process the message. 1286 In any case, the recipient should actively ask the Group Manager for 1287 an updated Security Context according to an application-defined 1288 policy, for instance after a given number of unsuccessfully decrypted 1289 incoming messages. 1291 10.5. Collision of Group Identifiers 1293 In case endpoints are deployed in multiple groups managed by 1294 different non-synchronized Group Managers, it is possible for Group 1295 Identifiers of different groups to coincide. 1297 However, this does not impair the security of the AEAD algorithm. In 1298 fact, as long as the Master Secret is different for different groups 1299 and this condition holds over time, AEAD keys are different among 1300 different groups. 1302 10.6. Cross-group Message Injection 1304 A same endpoint is allowed to and would likely use the same signature 1305 key in multiple OSCORE groups, possibly administered by different 1306 Group Managers. Also, the same endpoint can register several times 1307 in the same group, getting multiple unique Sender IDs. This requires 1308 that, when a sender endpoint sends a message to an OSCORE group using 1309 a Sender ID, the countersignature included in the message is 1310 explicitly bound also to that group and to the used Sender ID. 1312 To this end, the countersignature of each message protected with 1313 Group OSCORE is computed also over the value of the OSCORE option, 1314 which is part of the Additional Authenticated Data used in the 1315 signing process (see Section 4.3.2). That is, the countersignature 1316 is computed also over: the ID Context (Group ID) and the Partial IV, 1317 which are always present in group requests; as well as the Sender ID 1318 of the message originator, which is always present in all group 1319 requests and responses. 1321 Since the signing process takes as input also the ciphertext of the 1322 COSE_Encrypt0 object, the countersignature is bound not only to the 1323 intended OSCORE group, hence to the triplet (Master Secret, Master 1324 Salt, ID Context), but also to a specific Sender ID in that group and 1325 to its specific symmetric key used for AEAD encryption, hence to the 1326 quartet (Master Secret, Master Salt, ID Context, Sender ID). 1328 This makes it practically infeasible to perform the attack described 1329 below, where a malicious group member injects forged messages to a 1330 different OSCORE group than the originally intended one. Let us 1331 consider: 1333 o Two OSCORE groups G1 and G2, with ID Context (Group ID) Gid1 and 1334 Gid2, respectively. Both G1 and G2 use the AEAD cipher AES-CCM- 1335 16-64-128, i.e. the MAC of the ciphertext is 8 bytes in size. 1337 o A victim endpoint V which is member of both G1 and G2, and uses 1338 the same signature key in both groups. The endpoint V has Sender 1339 ID Sid1 in G1 and Sender ID Sid2 in G2. The pairs (Sid1, Gid1) 1340 and (Sid2, Gid2) identify the same public key of V in G1 and G2, 1341 respectively. 1343 o A malicious endpoint Z is also member of both G1 and G2. Hence, Z 1344 is able to derive the symmetric keys associated to V in G1 and G2. 1346 If countersignatures were not computed also over the value of the 1347 OSCORE option as discussed above, Z can intercept a group message M1 1348 sent by V to G1, and forge a valid signed message M2 to be injected 1349 in G2, making it appear as sent by V and valid to be accepted. 1351 More in detail, Z first intercepts a message M1 sent by V in G1, and 1352 tries to forge a message M2, by changing the value of the OSCORE 1353 option from M1 as follows: the 'kid context' is changed from G1 to 1354 G2; and the 'kid' is changed from Sid1 to Sid2. 1356 If M2 is used as a request message, there is a probability equal to 1357 2^-64 that the same unchanged MAC is successfully verified by using 1358 Sid2 as 'request_kid' and the symmetric key associated to V in G2. 1359 In such a case, the same unchanged signature would be also valid. 1360 Note that Z can check offline if a performed forgery is actually 1361 valid before sending the forged message to G2. That is, this attack 1362 has a complexity of 2^64 offline calculations. 1364 If M2 is used as a response, Z can also change the response Partial 1365 IV, until the same unchanged MAC is successfully verified by using 1366 Sid2 as 'request_kid' and the symmetric key associated to V in G2. 1367 In such a case, the same unchanged signature would be also valid. 1368 Since the Partial IV is 5 bytes in size, this requires 2^40 1369 operations to test all the Partial IVs, which can be done in real- 1370 time. Also, the probability that a single given message M1 can be 1371 used to forge a response M2 for a given request is equal to 2^-24, 1372 since there are more MAC values (8 bytes in size) than Partial IV 1373 values (5 bytes in size). 1375 Note that, by changing the Partial IV as discussed above, any member 1376 of G1 would also be able to forge a valid signed response message M2 1377 to be injected in G1. 1379 10.7. Group OSCORE for Unicast Requests 1381 With reference to the processing defined in Section 7.1 and 1382 Section 9.1.1, it is NOT RECOMMENDED for a client to use Group OSCORE 1383 for securing a request sent to a single group member over unicast. 1385 If the client uses its own Sender Key to protect a unicast request to 1386 a group member, an on-path adversary can, right then or later on, 1387 redirect that request to one/many different group member(s) over 1388 unicast, or to the whole OSCORE group over multicast. By doing so, 1389 the adversary can induce the target group member(s) to perform 1390 actions intended to one group member only. Note that the adversary 1391 can be external, i.e. (s)he does not need to also be a member of the 1392 OSCORE group. 1394 This is due to the fact that the client is not able to indicate the 1395 single intended recipient in a way which is secure and possible to 1396 process for Group OSCORE on the server side. In particular, Group 1397 OSCORE does not protect network addressing information such as the IP 1398 address of the intended recipient server. It follows that the 1399 server(s) receiving the redirected request cannot assert whether that 1400 was the original intention of the client, and would thus simply 1401 assume so. 1403 The impact of such an attack depends especially on the REST method of 1404 the request, i.e. the Inner CoAP Code of the OSCORE request message. 1405 In particular, safe methods such as GET and FETCH would trigger 1406 (several) unintended responses from the targeted server(s), while not 1407 resulting in destructive behavior. On the other hand, non safe 1408 methods such as PUT, POST and PATCH/iPATCH would result in the target 1409 server(s) taking active actions on their resources and possible 1410 cyber-physical environment, with the risk of destructive consequences 1411 and possible implications for safety. 1413 Additional considerations are discussed in Appendix E.3, with respect 1414 to unicast requests including an Echo Option 1415 [I-D.ietf-core-echo-request-tag], as a challenge-response method for 1416 servers to achieve synchronization of client Sender Sequence Numbers. 1418 A client may instead use the pairwise mode defined in Appendix G.2, 1419 in order to protect a request sent to a single group member using 1420 pairwise keying material. This prevents the attack discussed above 1421 by construction, as only the intended server is able to derive the 1422 pairwise keying material used by the client to protect the request. 1424 10.8. End-to-end Protection 1426 The same considerations from Section 12.1 of [RFC8613] hold for Group 1427 OSCORE. 1429 Additionally, (D)TLS and Group OSCORE can be combined for protecting 1430 message exchanges occurring over unicast. Instead, it is not 1431 possible to combine DTLS and Group OSCORE for protecting message 1432 exchanges where messages are (also) sent over multicast. 1434 10.9. Security Context Establishment 1436 The use of COSE_Encrypt0 and AEAD to protect messages as specified in 1437 this document requires an endpoint to be a member of an OSCORE group. 1439 That is, upon joining the group, the endpoint securely receives from 1440 the Group Manager the necessary input parameters, which are used to 1441 derive the Common Context and the Sender Context (see Section 2). 1442 The Group Manager ensures uniqueness of Sender IDs in the same group. 1444 Each different Recipient Context for decrypting messages from a 1445 particular sender can be derived at runtime, at the latest upon 1446 receiving a message from that sender for the first time. 1448 Countersignatures of group messages are verified by means of the 1449 public key of the respective sender endpoint. Upon nodes' joining, 1450 the Group Manager collects such public keys and MUST verify proof-of- 1451 possession of the respective private key. Later on, a group member 1452 can request from the Group Manager the public keys of other group 1453 members. 1455 The joining process can occur, for instance, as defined in 1456 [I-D.ietf-ace-key-groupcomm-oscore]. 1458 10.10. Master Secret 1460 Group OSCORE derives the Security Context using the same construction 1461 as OSCORE, and by using the Group Identifier of a group as the 1462 related ID Context. Hence, the same required properties of the 1463 Security Context parameters discussed in Section 3.3 of [RFC8613] 1464 hold for this document. 1466 With particular reference to the OSCORE Master Secret, it has to be 1467 kept secret among the members of the respective OSCORE group and the 1468 Group Manager responsible for that group. Also, the Master Secret 1469 must have a good amount of randomness, and the Group Manager can 1470 generate it offline using a good random number generator. This 1471 includes the case where the Group Manager rekeys the group by 1472 generating and distributing a new Master Secret. Randomness 1473 requirements for security are described in [RFC4086]. 1475 10.11. Replay Protection 1477 As in OSCORE, also Group OSCORE relies on sender sequence numbers 1478 included in the COSE message field 'Partial IV' and used to build 1479 AEAD nonces. 1481 Note that the Partial IV of an endpoint does not necessarily grow 1482 monotonically. For instance, upon wrap-around of the endpoint Sender 1483 Sequence Number, the Partial IV also wraps-around, since 0 becomes 1484 the next Sender Sequence Number used as Partial IV. As discussed in 1485 Section 2.5, this results either in the endpoint being individually 1486 rekeyed and getting a new Sender ID, or in the establishment of a new 1487 Security Context in the group. Therefore, uniqueness of (key, nonce) 1488 pairs (see Section 10.2) is preserved also when a new Security 1489 Context is established. 1491 As discussed in Section 6.1, an endpoint that has just joined a group 1492 is exposed to replay attack, as it is not aware of the sender 1493 sequence numbers currently used by other group members. Appendix E 1494 describes how endpoints can synchronize with senders' sequence 1495 numbers. 1497 Unless exchanges in a group rely only on unicast messages, Group 1498 OSCORE cannot be used with reliable transport. Thus, unless only 1499 unicast messages are sent in the group, it cannot be defined that 1500 only messages with sequence numbers that are equal to the previous 1501 sequence number + 1 are accepted. 1503 The processing of response messages described in Section 7.4 also 1504 ensures that a client accepts a single valid response to a given 1505 request from each replying server, unless CoAP observation is used. 1507 10.12. Client Aliveness 1509 As discussed in Section 12.5 of [RFC8613], a server may use the Echo 1510 option [I-D.ietf-core-echo-request-tag] to verify the aliveness of 1511 the client that originated a received request. This would also allow 1512 the server to (re-)synchronize with the client's sequence number, as 1513 well as to ensure that the request is fresh and has not been replayed 1514 or (purposely) delayed, if it is the first one received from that 1515 client after having joined the group or rebooted (see Appendix E.3). 1517 10.13. Cryptographic Considerations 1519 The same considerations from Section 12.6 of [RFC8613] about the 1520 maximum Sender Sequence Number hold for Group OSCORE. 1522 As discussed in Section 2.5, an endpoint that experiences a wrap- 1523 around of its own Sender Sequence Number MUST NOT transmit further 1524 messages including a Partial IV, until it has derived a new Sender 1525 Context. This prevents the endpoint to reuse the same AEAD nonces 1526 with the same Sender key. 1528 In order to renew its own Sender Context, the endpoint SHOULD inform 1529 the Group Manager, which can either renew the whole Security Context 1530 by means of group rekeying, or provide only that endpoint with a new 1531 Sender ID value. Either case, the endpoint derives a new Sender 1532 Context, and in particular a new Sender Key. 1534 Additionally, the same considerations from Section 12.6 of [RFC8613] 1535 hold for Group OSCORE, about building the AEAD nonce and the secrecy 1536 of the Security Context parameters. 1538 10.14. Message Segmentation 1540 The same considerations from Section 12.7 of [RFC8613] hold for Group 1541 OSCORE. 1543 10.15. Privacy Considerations 1545 Group OSCORE ensures end-to-end integrity protection and encryption 1546 of the message payload and all options that are not used for proxy 1547 operations. In particular, options are processed according to the 1548 same class U/I/E that they have for OSCORE. Therefore, the same 1549 privacy considerations from Section 12.8 of [RFC8613] hold for Group 1550 OSCORE. 1552 Furthermore, the following privacy considerations hold, about the 1553 OSCORE option that may reveal information on the communicating 1554 endpoints. 1556 o The 'kid' parameter, which is intended to help a recipient 1557 endpoint to find the right Recipient Context, may reveal 1558 information about the Sender Endpoint. Since both requests and 1559 responses always include the 'kid' parameter, this may reveal 1560 information about both a client sending a group request and all 1561 the possibly replying servers sending their own individual 1562 response. 1564 o The 'kid context' parameter, which is intended to help a recipient 1565 endpoint to find the right Recipient Context, reveals information 1566 about the sender endpoint. In particular, it reveals that the 1567 sender endpoint is a member of a particular OSCORE group, whose 1568 current Group ID is indicated in the 'kid context' parameter. 1569 Moreover, this parameter explicitly relates two or more 1570 communicating endpoints, as members of the same OSCORE group. 1572 Also, using the mechanisms described in Appendix E.3 to achieve 1573 sequence number synchronization with a client may reveal when a 1574 server device goes through a reboot. This can be mitigated by the 1575 server device storing the precise state of the replay window of each 1576 known client on a clean shutdown. 1578 11. IANA Considerations 1580 Note to RFC Editor: Please replace all occurrences of "[This 1581 Document]" with the RFC number of this specification and delete this 1582 paragraph. 1584 This document has the following actions for IANA. 1586 11.1. Counter Signature Parameters Registry 1588 This specification establishes the IANA "Counter Signature 1589 Parameters" Registry. The Registry has been created to use the 1590 "Expert Review Required" registration procedure [RFC8126]. Expert 1591 review guidelines are provided in Section 11.4. 1593 This registry specifies the parameters of each admitted 1594 countersignature algorithm, as well as the possible structure they 1595 are organized into. This information is used to populate the 1596 parameter Counter Signature Parameters of the Common Context (see 1597 Section 2). 1599 The columns of this table are: 1601 o Name: A value that can be used to identify an algorithm in 1602 documents for easier comprehension. Its value is taken from the 1603 'Name' column of the "COSE Algorithms" Registry. 1605 o Value: The value to be used to identify this algorithm. Its 1606 content is taken from the 'Value' column of the "COSE Algorithms" 1607 Registry. The value MUST be the same one used in the "COSE 1608 Algorithms" Registry for the entry with the same 'Name' field. 1610 o Parameters: This indicates the CBOR encoding of the parameters (if 1611 any) for the counter signature algorithm indicated by the 'Value' 1612 field. 1614 o Description: A short description of the parameters encoded in the 1615 'Parameters' field (if any). 1617 o Reference: This contains a pointer to the public specification for 1618 the field, if one exists. 1620 Initial entries in the registry are as follows. 1622 +-------------+-------+--------------+-----------------+-----------+ 1623 | Name | Value | Parameters | Description | Reference | 1624 +-------------+-------+--------------+-----------------+-----------+ 1625 | | | | | | 1626 | EdDSA | -8 | crv : int | crv value taken | [This | 1627 | | | | from the COSE | Document] | 1628 | | | | Elliptic Curve | | 1629 | | | | Registry | | 1630 | | | | | | 1631 +-------------+-------+--------------+-----------------+-----------+ 1632 | | | | | | 1633 | ES256 | -7 | crv : int | crv value taken | [This | 1634 | | | | from the COSE | Document] | 1635 | | | | Elliptic Curve | | 1636 | | | | Registry | | 1637 | | | | | | 1638 +-------------+-------+--------------+-----------------+-----------+ 1639 | | | | | | 1640 | ES384 | -35 | crv : int | crv value taken | [This | 1641 | | | | from the COSE | Document] | 1642 | | | | Elliptic Curve | | 1643 | | | | Registry | | 1644 | | | | | | 1645 +-------------+-------+--------------+-----------------+-----------+ 1646 | | | | | | 1647 | ES512 | -36 | crv : int | crv value taken | [This | 1648 | | | | from the COSE | Document] | 1649 | | | | Elliptic Curve | | 1650 | | | | Registry | | 1651 | | | | | | 1652 +-------------+-------+--------------+-----------------+-----------+ 1653 | | | | | | 1654 | PS256 | -37 | | Parameters not | [This | 1655 | | | | present | Document] | 1656 | | | | | | 1657 +-------------+-------+--------------+-----------------+-----------+ 1658 | | | | | | 1659 | PS384 | -38 | | Parameters not | [This | 1660 | | | | present | Document] | 1661 | | | | | | 1662 +-------------+-------+--------------+-----------------+-----------+ 1663 | | | | | | 1664 | PS512 | -39 | | Parameters not | [This | 1665 | | | | present | Document] | 1666 | | | | | | 1667 +-------------+-------+--------------+-----------------+-----------+ 1669 11.2. Counter Signature Key Parameters Registry 1671 This specification establishes the IANA "Counter Signature Key 1672 Parameters" Registry. The Registry has been created to use the 1673 "Expert Review Required" registration procedure [RFC8126]. Expert 1674 review guidelines are provided in Section 11.4. 1676 This registry specifies the parameters of countersignature keys for 1677 each admitted countersignature algorithm, as well as the possible 1678 structure they are organized into. This information is used to 1679 populate the parameter Counter Signature Key Parameters of the Common 1680 Context (see Section 2). 1682 The columns of this table are: 1684 o Name: A value that can be used to identify an algorithm in 1685 documents for easier comprehension. Its value is taken from the 1686 'Name' column of the "COSE Algorithms" Registry. 1688 o Value: The value to be used to identify this algorithm. Its 1689 content is taken from the 'Value' column of the "COSE Algorithms" 1690 Registry. The value MUST be the same one used in the "COSE 1691 Algorithms" Registry for the entry with the same 'Name' field. 1693 o Parameters: This indicates the CBOR encoding of the key parameters 1694 (if any) for the counter signature algorithm indicated by the 1695 'Value' field. 1697 o Description: A short description of the parameters encoded in the 1698 'Parameters' field (if any). 1700 o Reference: This contains a pointer to the public specification for 1701 the field, if one exists. 1703 Initial entries in the registry are as follows. 1705 +-------------+-------+--------------+-------------------+-----------+ 1706 | Name | Value | Parameters | Description | Reference | 1707 +-------------+-------+--------------+-------------------+-----------+ 1708 | | | | | | 1709 | EdDSA | -8 | [kty : int , | kty value is 1, | [This | 1710 | | | | as Key Type "OKP" | Document] | 1711 | | | | from the COSE Key | | 1712 | | | | Types Registry | | 1713 | | | | | | 1714 | | | | | | 1715 | | | crv : int] | crv value taken | | 1716 | | | | from the COSE | | 1717 | | | | Elliptic Curve | | 1718 | | | | Registry | | 1719 | | | | | | 1720 +-------------+-------+--------------+-------------------+-----------+ 1721 | | | | | | 1722 | ES256 | -7 | [kty : int , | kty value is 2, | [This | 1723 | | | | as Key Type "EC2" | Document] | 1724 | | | | from the COSE Key | | 1725 | | | | Types Registry | | 1726 | | | | | | 1727 | | | | | | 1728 | | | crv : int] | crv value taken | | 1729 | | | | from the COSE | | 1730 | | | | Elliptic Curve | | 1731 | | | | Registry | | 1732 | | | | | | 1733 +-------------+-------+--------------+-------------------+-----------+ 1734 | | | | | | 1735 | ES384 | -35 | [kty : int , | kty value is 2, | [This | 1736 | | | | as Key Type "EC2" | Document] | 1737 | | | | from the COSE Key | | 1738 | | | | Types Registry | | 1739 | | | | | | 1740 | | | crv : int] | crv value taken | | 1741 | | | | from the COSE | | 1742 | | | | Elliptic Curve | | 1743 | | | | Registry | | 1744 | | | | | | 1745 +-------------+-------+--------------+-------------------+-----------+ 1746 | | | | | | 1747 | ES512 | -36 | [kty : int , | kty value is 2, | [This | 1748 | | | | as Key Type "EC2" | Document] | 1749 | | | | from the COSE Key | | 1750 | | | | Types Registry | | 1751 | | | | | | 1752 | | | crv : int] | crv value taken | | 1753 | | | | from the COSE | | 1754 | | | | Elliptic Curve | | 1755 | | | | Registry | | 1756 | | | | | | 1757 +-------------+-------+--------------+-------------------+-----------+ 1758 | | | | | | 1759 | PS256 | -37 | kty : int | kty value is 3, | [This | 1760 | | | | as Key Type "RSA" | Document] | 1761 | | | | from the COSE Key | | 1762 | | | | Types Registry | | 1763 | | | | | | 1764 +-------------+-------+--------------+-------------------+-----------+ 1765 | | | | | | 1766 | PS384 | -38 | kty : int | kty value is 3, | [This | 1767 | | | | as Key Type "RSA" | Document] | 1768 | | | | from the COSE Key | | 1769 | | | | Types Registry | | 1770 | | | | | | 1771 +-------------+-------+--------------+-------------------+-----------+ 1772 | | | | | | 1773 | PS512 | -39 | kty : int | kty value is 3, | [This | 1774 | | | | as Key Type "RSA" | Document] | 1775 | | | | from the COSE Key | | 1776 | | | | Types Registry | | 1777 | | | | | | 1778 +-------------+-------+--------------+-------------------+-----------+ 1780 11.3. OSCORE Flag Bits Registry 1782 IANA is asked to add the following value entry to the "OSCORE Flag 1783 Bits" subregistry defined in Section 13.7 of [RFC8613] as part of the 1784 "CoRE Parameters" registry. 1786 +--------------+-------------+--------------------------+-----------+ 1787 | Bit Position | Name | Description | Reference | 1788 +--------------+-------------+--------------------------+-----------+ 1789 | 2 | Pairwise | Set to 1 if the message | [This | 1790 | | Protection | is protected with | Document] | 1791 | | Flag | pairwise keying material | | 1792 +--------------+-------------+--------------------------+-----------+ 1794 11.4. Expert Review Instructions 1796 The IANA Registries established in this document are defined as 1797 "Expert Review". This section gives some general guidelines for what 1798 the experts should be looking for, but they are being designated as 1799 experts for a reason so they should be given substantial latitude. 1801 Expert reviewers should take into consideration the following points: 1803 o Clarity and correctness of registrations. Experts are expected to 1804 check the clarity of purpose and use of the requested entries. 1805 Experts should inspect the entry for the algorithm considered, to 1806 verify the conformity of the encoding proposed against the 1807 theoretical algorithm, including completeness of the 'Parameters' 1808 column. Expert needs to make sure values are taken from the right 1809 registry, when that's required. Expert should consider requesting 1810 an opinion on the correctness of registered parameters from the 1811 CBOR Object Signing and Encryption Working Group (COSE). 1813 Encodings that do not meet these objective of clarity and 1814 completeness should not be registered. 1816 o Duplicated registration and point squatting should be discouraged. 1817 Reviewers are encouraged to get sufficient information for 1818 registration requests to ensure that the usage is not going to 1819 duplicate one that is already registered and that the point is 1820 likely to be used in deployments. 1822 o Experts should take into account the expected usage of fields when 1823 approving point assignment. The length of the 'Parameters' 1824 encoding should be weighed against the usage of the entry, 1825 considering the size of device it will be used on. Additionally, 1826 the length of the encoded value should be weighed against how many 1827 code points of that length are left, the size of device it will be 1828 used on, and the number of code points left that encode to that 1829 size. 1831 o Specifications are recommended. When specifications are not 1832 provided, the description provided needs to have sufficient 1833 information to verify the points above. 1835 12. References 1837 12.1. Normative References 1839 [I-D.dijk-core-groupcomm-bis] 1840 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1841 for the Constrained Application Protocol (CoAP)", draft- 1842 dijk-core-groupcomm-bis-03 (work in progress), March 1843 2020. 1845 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1846 Requirement Levels", BCP 14, RFC 2119, 1847 DOI 10.17487/RFC2119, March 1997, 1848 . 1850 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1851 "Randomness Requirements for Security", BCP 106, RFC 4086, 1852 DOI 10.17487/RFC4086, June 2005, 1853 . 1855 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 1856 Algorithm (DSA) and Elliptic Curve Digital Signature 1857 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 1858 2013, . 1860 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1861 Application Protocol (CoAP)", RFC 7252, 1862 DOI 10.17487/RFC7252, June 2014, 1863 . 1865 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1866 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1867 2016, . 1869 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1870 Signature Algorithm (EdDSA)", RFC 8032, 1871 DOI 10.17487/RFC8032, January 2017, 1872 . 1874 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1875 Writing an IANA Considerations Section in RFCs", BCP 26, 1876 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1877 . 1879 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1880 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1881 . 1883 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1884 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1885 May 2017, . 1887 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1888 "Object Security for Constrained RESTful Environments 1889 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1890 . 1892 12.2. Informative References 1894 [Degabriele] 1895 Degabriele, J., Lehmann, A., Paterson, K., Smart, N., and 1896 M. Strefler, "On the Joint Security of Encryption and 1897 Signature in EMV", December 2011, 1898 . 1900 [I-D.ietf-ace-key-groupcomm] 1901 Palombini, F. and M. Tiloca, "Key Provisioning for Group 1902 Communication using ACE", draft-ietf-ace-key-groupcomm-05 1903 (work in progress), March 2020. 1905 [I-D.ietf-ace-key-groupcomm-oscore] 1906 Tiloca, M., Park, J., and F. Palombini, "Key Management 1907 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1908 oscore-05 (work in progress), March 2020. 1910 [I-D.ietf-ace-oauth-authz] 1911 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1912 H. Tschofenig, "Authentication and Authorization for 1913 Constrained Environments (ACE) using the OAuth 2.0 1914 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 1915 (work in progress), February 2020. 1917 [I-D.ietf-core-echo-request-tag] 1918 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 1919 Request-Tag, and Token Processing", draft-ietf-core-echo- 1920 request-tag-09 (work in progress), March 2020. 1922 [I-D.somaraju-ace-multicast] 1923 Somaraju, A., Kumar, S., Tschofenig, H., and W. Werner, 1924 "Security for Low-Latency Group Communication", draft- 1925 somaraju-ace-multicast-02 (work in progress), October 1926 2016. 1928 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1929 "Transmission of IPv6 Packets over IEEE 802.15.4 1930 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1931 . 1933 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1934 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1935 . 1937 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1938 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1939 DOI 10.17487/RFC6282, September 2011, 1940 . 1942 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1943 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1944 January 2012, . 1946 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1947 Constrained-Node Networks", RFC 7228, 1948 DOI 10.17487/RFC7228, May 2014, 1949 . 1951 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1952 Application Protocol (CoAP)", RFC 7641, 1953 DOI 10.17487/RFC7641, September 2015, 1954 . 1956 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1957 the Constrained Application Protocol (CoAP)", RFC 7959, 1958 DOI 10.17487/RFC7959, August 2016, 1959 . 1961 Appendix A. Assumptions and Security Objectives 1963 This section presents a set of assumptions and security objectives 1964 for the approach described in this document. The rest of this 1965 section refers to three types of groups: 1967 o Application group, i.e. a set of CoAP endpoints that share a 1968 common pool of resources. 1970 o Security group, as defined in Section 1.1 of this specification. 1971 There can be a one-to-one or a one-to-many relation between 1972 security groups and application groups. Any two application 1973 groups associated to the same security group do not share any same 1974 resource. 1976 o CoAP group, as defined in [I-D.dijk-core-groupcomm-bis] i.e. a set 1977 of CoAP endpoints, where each endpoint is configured to receive 1978 CoAP multicast requests that are sent to the group's associated IP 1979 multicast address and UDP port. An endpoint may be a member of 1980 multiple CoAP groups. There can be a one-to-one or a one-to-many 1981 relation between CoAP groups and application groups. Note that a 1982 device sending a CoAP request to a CoAP group is not necessarily 1983 itself a member of that group: it is a member only if it also has 1984 a CoAP server endpoint listening to requests for this CoAP group, 1985 sent to the associated IP multicast address and port. In order to 1986 provide secure group communication, all members of a CoAP group as 1987 well as all further endpoints configured only as clients sending 1988 CoAP (multicast) requests to the CoAP group have to be member of a 1989 security group. 1991 A.1. Assumptions 1993 The following assumptions are assumed to be already addressed and are 1994 out of the scope of this document. 1996 o Multicast communication topology: this document considers both 1997 1-to-N (one sender and multiple recipients) and M-to-N (multiple 1998 senders and multiple recipients) communication topologies. The 1999 1-to-N communication topology is the simplest group communication 2000 scenario that would serve the needs of a typical Low-power and 2001 Lossy Network (LLN). Examples of use cases that benefit from 2002 secure group communication are provided in Appendix B. 2004 In a 1-to-N communication model, only a single client transmits 2005 data to the CoAP group, in the form of request messages; in an 2006 M-to-N communication model (where M and N do not necessarily have 2007 the same value), M clients transmit data to the CoAP group. 2008 According to [I-D.dijk-core-groupcomm-bis], any possible proxy 2009 entity is supposed to know about the clients and to not perform 2010 aggregation of response messages from multiple servers. Also, 2011 every client expects and is able to handle multiple response 2012 messages associated to a same request sent to the CoAP group. 2014 o Group size: security solutions for group communication should be 2015 able to adequately support different and possibly large security 2016 groups. The group size is the current number of members in a 2017 security group. In the use cases mentioned in this document, the 2018 number of clients (normally the controlling devices) is expected 2019 to be much smaller than the number of servers (i.e. the controlled 2020 devices). A security solution for group communication that 2021 supports 1 to 50 clients would be able to properly cover the group 2022 sizes required for most use cases that are relevant for this 2023 document. The maximum group size is expected to be in the range 2024 of 2 to 100 devices. Security groups larger than that should be 2025 divided into smaller independent groups. 2027 o Communication with the Group Manager: an endpoint must use a 2028 secure dedicated channel when communicating with the Group 2029 Manager, also when not registered as a member of the security 2030 group. 2032 o Provisioning and management of Security Contexts: a Security 2033 Context must be established among the members of the security 2034 group. A secure mechanism must be used to generate, revoke and 2035 (re-)distribute keying material, multicast security policies and 2036 security parameters in the security group. The actual 2037 provisioning and management of the Security Context is out of the 2038 scope of this document. 2040 o Multicast data security ciphersuite: all members of a security 2041 group must agree on a ciphersuite to provide authenticity, 2042 integrity and confidentiality of messages in the group. The 2043 ciphersuite is specified as part of the Security Context. 2045 o Backward security: a new device joining the security group should 2046 not have access to any old Security Contexts used before its 2047 joining. This ensures that a new member of the security group is 2048 not able to decrypt confidential data sent before it has joined 2049 the security group. The adopted key management scheme should 2050 ensure that the Security Context is updated to ensure backward 2051 confidentiality. The actual mechanism to update the Security 2052 Context and renew the group keying material in the security group 2053 upon a new member's joining has to be defined as part of the group 2054 key management scheme. 2056 o Forward security: entities that leave the security group should 2057 not have access to any future Security Contexts or message 2058 exchanged within the security group after their leaving. This 2059 ensures that a former member of the security group is not able to 2060 decrypt confidential data sent within the security group anymore. 2061 Also, it ensures that a former member is not able to send 2062 encrypted and/or integrity protected messages to the security 2063 group anymore. The actual mechanism to update the Security 2064 Context and renew the group keying material in the security group 2065 upon a member's leaving has to be defined as part of the group key 2066 management scheme. 2068 A.2. Security Objectives 2070 The approach described in this document aims at fulfilling the 2071 following security objectives: 2073 o Data replay protection: group request messages or response 2074 messages replayed within the security group must be detected. 2076 o Group-level data confidentiality: messages sent within the 2077 security group shall be encrypted if privacy sensitive data is 2078 exchanged within the security group. This document considers 2079 group-level data confidentiality since messages are encrypted at a 2080 group level, i.e. in such a way that they can be decrypted by any 2081 member of the security group, but not by an external adversary or 2082 other external entities. 2084 o Source authentication: messages sent within the security group 2085 shall be authenticated. That is, it is essential to ensure that a 2086 message is originated by a member of the security group in the 2087 first place, and in particular by a specific member of the 2088 security group. 2090 o Message integrity: messages sent within the security group shall 2091 be integrity protected. That is, it is essential to ensure that a 2092 message has not been tampered with by an external adversary or 2093 other external entities which are not members of the security 2094 group. 2096 o Message ordering: it must be possible to determine the ordering of 2097 messages coming from a single sender. In accordance with OSCORE 2098 [RFC8613], this results in providing relative freshness of group 2099 requests and absolute freshness of responses. It is not required 2100 to determine ordering of messages from different senders. 2102 Appendix B. List of Use Cases 2104 Group Communication for CoAP [I-D.dijk-core-groupcomm-bis] provides 2105 the necessary background for multicast-based CoAP communication, with 2106 particular reference to low-power and lossy networks (LLNs) and 2107 resource constrained environments. The interested reader is 2108 encouraged to first read [I-D.dijk-core-groupcomm-bis] to understand 2109 the non-security related details. This section discusses a number of 2110 use cases that benefit from secure group communication, and refers to 2111 the three types of groups from Appendix A. Specific security 2112 requirements for these use cases are discussed in Appendix A. 2114 o Lighting control: consider a building equipped with IP-connected 2115 lighting devices, switches, and border routers. The lighting 2116 devices acting as servers are organized into application groups 2117 and CoAP groups, according to their physical location in the 2118 building. For instance, lighting devices in a room or corridor 2119 can be configured as members of a single application group and 2120 corresponding CoAP group. Those ligthing devices together with 2121 the switches acting as clients in the same room or corridor can be 2122 configured as members of the corresponding security group. 2123 Switches are then used to control the lighting devices by sending 2124 on/off/dimming commands to all lighting devices in the CoAP group, 2125 while border routers connected to an IP network backbone (which is 2126 also multicast-enabled) can be used to interconnect routers in the 2127 building. Consequently, this would also enable logical groups to 2128 be formed even if devices with a role in the lighting application 2129 may be physically in different subnets (e.g. on wired and wireless 2130 networks). Connectivity between lighting devices may be realized, 2131 for instance, by means of IPv6 and (border) routers supporting 2132 6LoWPAN [RFC4944][RFC6282]. Group communication enables 2133 synchronous operation of a set of connected lights, ensuring that 2134 the light preset (e.g. dimming level or color) of a large set of 2135 luminaires are changed at the same perceived time. This is 2136 especially useful for providing a visual synchronicity of light 2137 effects to the user. As a practical guideline, events within a 2138 200 ms interval are perceived as simultaneous by humans, which is 2139 necessary to ensure in many setups. Devices may reply back to the 2140 switches that issue on/off/dimming commands, in order to report 2141 about the execution of the requested operation (e.g. OK, failure, 2142 error) and their current operational status. In a typical 2143 lighting control scenario, a single switch is the only entity 2144 responsible for sending commands to a set of lighting devices. In 2145 more advanced lighting control use cases, a M-to-N communication 2146 topology would be required, for instance in case multiple sensors 2147 (presence or day-light) are responsible to trigger events to a set 2148 of lighting devices. Especially in professional lighting 2149 scenarios, the roles of client and server are configured by the 2150 lighting commissioner, and devices strictly follow those roles. 2152 o Integrated building control: enabling Building Automation and 2153 Control Systems (BACSs) to control multiple heating, ventilation 2154 and air-conditioning units to pre-defined presets. Controlled 2155 units can be organized into application groups and CoAP groups in 2156 order to reflect their physical position in the building, e.g. 2157 devices in the same room can be configured as members of a single 2158 application group and corresponding CoAP group. As a practical 2159 guideline, events within intervals of seconds are typically 2160 acceptable. Controlled units are expected to possibly reply back 2161 to the BACS issuing control commands, in order to report about the 2162 execution of the requested operation (e.g. OK, failure, error) 2163 and their current operational status. 2165 o Software and firmware updates: software and firmware updates often 2166 comprise quite a large amount of data. This can overload a Low- 2167 power and Lossy Network (LLN) that is otherwise typically used to 2168 deal with only small amounts of data, on an infrequent base. 2169 Rather than sending software and firmware updates as unicast 2170 messages to each individual device, multicasting such updated data 2171 to a larger set of devices at once displays a number of benefits. 2172 For instance, it can significantly reduce the network load and 2173 decrease the overall time latency for propagating this data to all 2174 devices. Even if the complete whole update process itself is 2175 secured, securing the individual messages is important, in case 2176 updates consist of relatively large amounts of data. In fact, 2177 checking individual received data piecemeal for tampering avoids 2178 that devices store large amounts of partially corrupted data and 2179 that they detect tampering hereof only after all data has been 2180 received. Devices receiving software and firmware updates are 2181 expected to possibly reply back, in order to provide a feedback 2182 about the execution of the update operation (e.g. OK, failure, 2183 error) and their current operational status. 2185 o Parameter and configuration update: by means of multicast 2186 communication, it is possible to update the settings of a set of 2187 similar devices, both simultaneously and efficiently. Possible 2188 parameters are related, for instance, to network load management 2189 or network access controls. Devices receiving parameter and 2190 configuration updates are expected to possibly reply back, to 2191 provide a feedback about the execution of the update operation 2192 (e.g. OK, failure, error) and their current operational status. 2194 o Commissioning of Low-power and Lossy Network (LLN) systems: a 2195 commissioning device is responsible for querying all devices in 2196 the local network or a selected subset of them, in order to 2197 discover their presence, and be aware of their capabilities, 2198 default configuration, and operating conditions. Queried devices 2199 displaying similarities in their capabilities and features, or 2200 sharing a common physical location can be configured as members of 2201 a single application group and corresponding CoAP group. Queried 2202 devices are expected to reply back to the commissioning device, in 2203 order to notify their presence, and provide the requested 2204 information and their current operational status. 2206 o Emergency multicast: a particular emergency related information 2207 (e.g. natural disaster) is generated and multicast by an emergency 2208 notifier, and relayed to multiple devices. The latter may reply 2209 back to the emergency notifier, in order to provide their feedback 2210 and local information related to the ongoing emergency. This kind 2211 of setups should additionally rely on a fault tolerance multicast 2212 algorithm, such as Multicast Protocol for Low-Power and Lossy 2213 Networks (MPL). 2215 Appendix C. Example of Group Identifier Format 2217 This section provides an example of how the Group Identifier (Gid) 2218 can be specifically formatted. That is, the Gid can be composed of 2219 two parts, namely a Group Prefix and a Group Epoch. 2221 For each group, the Group Prefix is constant over time and is 2222 uniquely defined in the set of all the groups associated to the same 2223 Group Manager. The choice of the Group Prefix for a given group's 2224 Security Context is application specific. The size of the Group 2225 Prefix directly impact on the maximum number of distinct groups under 2226 the same Group Manager. 2228 The Group Epoch is set to 0 upon the group's initialization, and is 2229 incremented by 1 upon completing each renewal of the Security Context 2230 and keying material in the group (see Section 2.4). In particular, 2231 once a new Master Secret has been distributed to the group, all the 2232 group members increment by 1 the Group Epoch in the Group Identifier 2233 of that group. 2235 As an example, a 3-byte Group Identifier can be composed of: i) a 2236 1-byte Group Prefix '0xb1' interpreted as a raw byte string; and ii) 2237 a 2-byte Group Epoch interpreted as an unsigned integer ranging from 2238 0 to 65535. Then, after having established the Common Context 61532 2239 times in the group, its Group Identifier will assume value 2240 '0xb1f05c'. 2242 Using an immutable Group Prefix for a group assumes that enough time 2243 elapses between two consecutive usages of the same Group Epoch value 2244 in that group. This ensures that the Gid value is temporally unique 2245 during the lifetime of a given message. Thus, the expected highest 2246 rate for addition/removal of group members and consequent group 2247 rekeying should be taken into account for a proper dimensioning of 2248 the Group Epoch size. 2250 As discussed in Section 10.5, if endpoints are deployed in multiple 2251 groups managed by different non-synchronized Group Managers, it is 2252 possible that Group Identifiers of different groups coincide at some 2253 point in time. In this case, a recipient has to handle coinciding 2254 Group Identifiers, and has to try using different Security Contexts 2255 to process an incoming message, until the right one is found and the 2256 message is correctly verified. Therefore, it is favourable that 2257 Group Identifiers from different Group Managers have a size that 2258 result in a small probability of collision. How small this 2259 probability should be is up to system designers. 2261 Appendix D. Set-up of New Endpoints 2263 An endpoint joins a group by explicitly interacting with the 2264 responsible Group Manager. When becoming members of a group, 2265 endpoints are not required to know how many and what endpoints are in 2266 the same group. 2268 Communications between a joining endpoint and the Group Manager rely 2269 on the CoAP protocol and must be secured. Specific details on how to 2270 secure communications between joining endpoints and a Group Manager 2271 are out of the scope of this document. 2273 The Group Manager must verify that the joining endpoint is authorized 2274 to join the group. To this end, the Group Manager can directly 2275 authorize the joining endpoint, or expect it to provide authorization 2276 evidence previously obtained from a trusted entity. Further details 2277 about the authorization of joining endpoints are out of scope. 2279 In case of successful authorization check, the Group Manager 2280 generates a Sender ID assigned to the joining endpoint, before 2281 proceeding with the rest of the join process. That is, the Group 2282 Manager provides the joining endpoint with the keying material and 2283 parameters to initialize the Security Context (see Section 2). The 2284 actual provisioning of keying material and parameters to the joining 2285 endpoint is out of the scope of this document. 2287 It is RECOMMENDED that the join process adopts the approach described 2288 in [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework 2289 for Authentication and Authorization in constrained environments 2290 [I-D.ietf-ace-oauth-authz]. 2292 Appendix E. Examples of Synchronization Approaches 2294 This section describes three possible approaches that can be 2295 considered by server endpoints to synchronize with sender sequence 2296 numbers of client endpoints sending group requests. 2298 E.1. Best-Effort Synchronization 2300 Upon receiving a group request from a client, a server does not take 2301 any action to synchonize with the sender sequence number of that 2302 client. This provides no assurance at all as to message freshness, 2303 which can be acceptable in non-critical use cases. 2305 E.2. Baseline Synchronization 2307 Upon receiving a group request from a given client for the first 2308 time, a server initializes its last-seen sender sequence number in 2309 its Recipient Context associated to that client. However, the server 2310 drops the group request without delivering it to the application 2311 layer. This provides a reference point to identify if future group 2312 requests from the same client are fresher than the last one received. 2314 A replay time interval exists, between when a possibly replayed or 2315 delayed message is originally transmitted by a given client and the 2316 first authentic fresh message from that same client is received. 2317 This can be acceptable for use cases where servers admit such a 2318 trade-off between performance and assurance of message freshness. 2320 E.3. Challenge-Response Synchronization 2322 A server performs a challenge-response exchange with a client, by 2323 using the Echo Option for CoAP described in Section 2 of 2324 [I-D.ietf-core-echo-request-tag] and according to Appendix B.1.2 of 2325 [RFC8613]. 2327 That is, upon receiving a group request from a particular client for 2328 the first time, the server processes the message as described in 2329 Section 7.2 of this specification, but, even if valid, does not 2330 deliver it to the application. Instead, the server replies to the 2331 client with an OSCORE protected 4.01 (Unauthorized) response message, 2332 including only the Echo Option and no diagnostic payload. The server 2333 stores the option value included therein. 2335 Upon receiving a 4.01 (Unauthorized) response that includes an Echo 2336 Option and originates from a verified group member, a client sends a 2337 request as a unicast message addressed to the same server, echoing 2338 the Echo Option value. In particular, the client does not 2339 necessarily resend the same group request, but can instead send a 2340 more recent one, if the application permits it. This makes it 2341 possible for the client to not retain previously sent group requests 2342 for full retransmission, unless the application explicitly requires 2343 otherwise. Either case, the client uses the sender sequence number 2344 value currently stored in its own Sender Context. If the client 2345 stores group requests for possible retransmission with the Echo 2346 Option, it should not store a given request for longer than a pre- 2347 configured time interval. Note that the unicast request echoing the 2348 Echo Option is correctly treated and processed as a message, since 2349 the 'kid context' field including the Group Identifier of the OSCORE 2350 group is still present in the OSCORE Option as part of the COSE 2351 object (see Section 4). 2353 Upon receiving the unicast request including the Echo Option, the 2354 server verifies that the option value equals the stored and 2355 previously sent value; otherwise, the request is silently discarded. 2356 Then, the server verifies that the unicast request has been received 2357 within a pre-configured time interval, as described in 2358 [I-D.ietf-core-echo-request-tag]. In such a case, the request is 2359 further processed and verified; otherwise, it is silently discarded. 2360 Finally, the server updates the Recipient Context associated to that 2361 client, by setting the Replay Window according to the Sequence Number 2362 from the unicast request conveying the Echo Option. The server 2363 either delivers the request to the application if it is an actual 2364 retransmission of the original one, or discards it otherwise. 2365 Mechanisms to signal whether the resent request is a full 2366 retransmission of the original one are out of the scope of this 2367 specification. 2369 In case it does not receive a valid unicast request including the 2370 Echo Option within the configured time interval, the server endpoint 2371 should perform the same challenge-response upon receiving the next 2372 group request from that same client. 2374 A server should not deliver group requests from a given client to the 2375 application until one valid request from that same client has been 2376 verified as fresh, as conveying an echoed Echo Option 2377 [I-D.ietf-core-echo-request-tag]. Also, a server may perform the 2378 challenge-response described above at any time, if synchronization 2379 with sender sequence numbers of clients is (believed to be) lost, for 2380 instance after a device reboot. It is the role of the application to 2381 define under what circumstances sender sequence numbers lose 2382 synchronization. This can include a minimum gap between the sender 2383 sequence number of the latest accepted group request from a client 2384 and the sender sequence number of a group request just received from 2385 the same client. A client has to be always ready to perform the 2386 challenge-response based on the Echo Option in case a server starts 2387 it. 2389 Note that endpoints configured as silent servers are not able to 2390 perform the challenge-response described above, as they do not store 2391 a Sender Context to secure the 4.01 (Unauthorized) response to the 2392 client. Therefore, silent servers should adopt alternative 2393 approaches to achieve and maintain synchronization with sender 2394 sequence numbers of clients. 2396 If this approach is used, it is important that all the group members 2397 acting as non-silent servers understand the elective Echo Option. 2398 This will ensure that those servers cannot be victim of the attack 2399 discussed in Section 10.7, in spite of the fact that the requests 2400 including the Echo Option are sent over unicast and secured with 2401 Group OSCORE. On the other hand, an internal on-path adversary would 2402 not be able to mix up the Echo Option value of two different unicast 2403 requests, sent by a same client to any two different servers in the 2404 group. In fact, this would require the adversary to forge the 2405 client's counter signature in both such requests. As a consequence, 2406 each of the two servers remains able to selectively accept a request 2407 with the Echo Option only if it is waiting for that exact integrity- 2408 protected Echo Option value, and is thus the intended recipient. 2410 This approach provides an assurance of absolute message freshness. 2411 However, it can result in an impact on performance which is 2412 undesirable or unbearable, especially in large groups where many 2413 endpoints at the same time might join as new members or lose 2414 synchronization. 2416 The use of pairwise keys (see Appendix G) for the unicast Echo 2417 messages reduces the message overhead. 2419 Appendix F. No Verification of Signatures 2421 There are some application scenarios using group communication that 2422 have particularly strict requirements. One example of this is the 2423 requirement of low message latency in non-emergency lighting 2424 applications [I-D.somaraju-ace-multicast]. For those applications 2425 which have tight performance constraints and relaxed security 2426 requirements, it can be inconvenient for some endpoints to verify 2427 digital signatures in order to assert source authenticity of received 2428 messages. In other cases, the signature verification can be deferred 2429 or only checked for specific actions. For instance, a command to 2430 turn a bulb on where the bulb is already on does not need the 2431 signature to be checked. In such situations, the counter signature 2432 needs to be included anyway as part of the message, so that an 2433 endpoint that needs to validate the signature for any reason has the 2434 ability to do so. 2436 In this specification, it is NOT RECOMMENDED that endpoints do not 2437 verify the counter signature of received messages. However, it is 2438 recognized that there may be situations where it is not always 2439 required. The consequence of not doing the signature validation is 2440 that security in the group is based only on the group-authenticity of 2441 the shared keying material used for encryption. That is, endpoints 2442 in the group have evidence that a received message has been 2443 originated by a group member, although not specifically identifiable 2444 in a secure way. This can violate a number of security requirements, 2445 as the compromise of any element in the group means that the attacker 2446 has the ability to control the entire group. Even worse, the group 2447 may not be limited in scope, and hence the same keying material might 2448 be used not only for light bulbs but for locks as well. Therefore, 2449 extreme care must be taken in situations where the security 2450 requirements are relaxed, so that deployment of the system will 2451 always be done safely. 2453 Appendix G. Pairwise Mode 2455 For use cases that do not require an intermediary performing 2456 signature verification and that use a compatible signature algorithm, 2457 the pairwise mode defined in this section can be used for unicast 2458 communication. 2460 This mode uses the derivation process defined in Section 3, and 2461 allows two group members to protect requests and responses exchanged 2462 with each other using pairwise keying material. Senders MUST NOT use 2463 the pairwise mode to protect a message addressed to multiple 2464 recipients or to the whole group. 2466 The pairwise mode results in the same performance and security 2467 improvements displayed by optimized responses (see Section 9.2). 2469 G.1. Pre-Requirements 2471 In order to protect an outgoing message in pairwise mode, a sender 2472 needs to know the public key and the Recipient ID for the message 2473 recipient, as stored in its own Recipient Context associated to that 2474 recipient. 2476 Furthermore, the sender needs to know the individual address of the 2477 message recipient. This information may not be known at any given 2478 point in time. For instance, right after having joined the group, a 2479 client may know the public key and Recipient ID for a given server, 2480 but not the addressing information required to reach it with an 2481 individual, one-to-one request. 2483 To make this information available, servers supporting the pairwise 2484 mode MAY provide the following service, enabling the discovery of 2485 their own addressing information to the clients in the group. 2487 o The servers host a well-known address-discovery resource with a 2488 common URI path, which can be pre-configured or provided to new 2489 group members by the Group Manager during the joining process. 2491 o A client can send a POST request to the whole group, hence 2492 protected as in Section 7.1 or Section 9.1.1, and addressed to the 2493 address-discovery resource. The request payload includes a CBOR 2494 map, specifying one Recipient ID for every specific server, from 2495 which the client wishes to retrieve individual addressing 2496 information. 2498 o Each server recognizing its own Sender ID within the request 2499 payload replies to the client. The response is protected as in 2500 Section 7.3 or Section 9.2, and its payload includes a CBOR map 2501 specifying the individual addressing information of that server. 2503 G.2. Pairwise Protected Request 2505 A request in pairwise mode is protected as defined in Section 7.1, 2506 with the following differences. 2508 o The client MUST set to 1 the sixth least significant bit of the 2509 OSCORE flag bits in the OSCORE option, i.e. the Pairwise Flag. 2511 o The COSE_Encrypt0 object included in the request is encrypted 2512 using a symmetric pairwise key K, that the client derives as 2513 defined in Section 3. In particular, the Sender/Recipient Key is 2514 the Sender Key of the client from its own Sender Context, i.e. the 2515 Recipient Key that the server stores in its own Recipient Context 2516 corresponding to the client. 2518 o The Counter Signature is not computed. That is, unlike defined in 2519 Section 5, the payload of the OSCORE message terminates with the 2520 encoded ciphertext of the COSE object. 2522 Note that no changes are made to the AEAD nonce and AAD. 2524 Upon receiving a request with the Pairwise Flag set to 1, the server 2525 MUST process it as defined in Section 7.2, with the following 2526 differences. 2528 o No countersignature to verify is included. 2530 o The COSE_Encrypt0 object included in the request is decrypted and 2531 verified using the same symmetric pairwise key K, that the server 2532 derives as described above for the client side and as defined in 2533 Section 3. 2535 G.3. Pairwise Protected Response 2537 When using the pairwise mode, the processing of a response occurs as 2538 described in Section 9.2 for an optimized response. 2540 Appendix H. Document Updates 2542 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2544 H.1. Version -06 to -07 2546 o Updated abstract and introduction. 2548 o Clarifications of what pertains a group rekeying. 2550 o Derivation of pairwise keying material. 2552 o Content re-organization for COSE Object and OSCORE header 2553 compression. 2555 o Defined the Pairwise Flag bit for the OSCORE option. 2557 o Supporting CoAP Observe for group requests and responses. 2559 o Considerations on message protection across switching to new 2560 keying material. 2562 o New optimized mode based on pairwise keying material. 2564 o More considerations on replay protection and Security Contexts 2565 upon key renewal. 2567 o Security considerations on Group OSCORE for unicast requests, also 2568 as affecting the usage of the Echo option. 2570 o Clarification on different types of groups considered 2571 (application/security/CoAP). 2573 o New pairwise mode, using pairwise keying material for both 2574 requests and responses. 2576 H.2. Version -05 to -06 2578 o Group IDs mandated to be unique under the same Group Manager. 2580 o Clarifications on parameter update upon group rekeying. 2582 o Updated external_aad structures. 2584 o Dynamic derivation of Recipient Contexts made optional and 2585 application specific. 2587 o Optional 4.00 response for failed signature verification on the 2588 server. 2590 o Removed client handling of duplicated responses to multicast 2591 requests. 2593 o Additional considerations on public key retrieval and group 2594 rekeying. 2596 o Added Group Manager responsibility on validating public keys. 2598 o Updates IANA registries. 2600 o Reference to RFC 8613. 2602 o Editorial improvements. 2604 H.3. Version -04 to -05 2606 o Added references to draft-dijk-core-groupcomm-bis. 2608 o New parameter Counter Signature Key Parameters (Section 2). 2610 o Clarification about Recipient Contexts (Section 2). 2612 o Two different external_aad for encrypting and signing 2613 (Section 3.1). 2615 o Updated response verification to handle Observe notifications 2616 (Section 6.4). 2618 o Extended Security Considerations (Section 8). 2620 o New "Counter Signature Key Parameters" IANA Registry 2621 (Section 9.2). 2623 H.4. Version -03 to -04 2625 o Added the new "Counter Signature Parameters" in the Common Context 2626 (see Section 2). 2628 o Added recommendation on using "deterministic ECDSA" if ECDSA is 2629 used as counter signature algorithm (see Section 2). 2631 o Clarified possible asynchronous retrieval of keying material from 2632 the Group Manager, in order to process incoming messages (see 2633 Section 2). 2635 o Structured Section 3 into subsections. 2637 o Added the new 'par_countersign' to the aad_array of the 2638 external_aad (see Section 3.1). 2640 o Clarified non reliability of 'kid' as identity indicator for a 2641 group member (see Section 2.1). 2643 o Described possible provisioning of new Sender ID in case of 2644 Partial IV wrap-around (see Section 2.2). 2646 o The former signature bit in the Flag Byte of the OSCORE option 2647 value is reverted to reserved (see Section 4.1). 2649 o Updated examples of compressed COSE object, now with the sixth 2650 less significant bit in the Flag Byte of the OSCORE option value 2651 set to 0 (see Section 4.3). 2653 o Relaxed statements on sending error messages (see Section 6). 2655 o Added explicit step on computing the counter signature for 2656 outgoing messages (see Setions 6.1 and 6.3). 2658 o Handling of just created Recipient Contexts in case of 2659 unsuccessful message verification (see Sections 6.2 and 6.4). 2661 o Handling of replied/repeated responses on the client (see 2662 Section 6.4). 2664 o New IANA Registry "Counter Signature Parameters" (see 2665 Section 9.1). 2667 H.5. Version -02 to -03 2669 o Revised structure and phrasing for improved readability and better 2670 alignment with draft-ietf-core-object-security. 2672 o Added discussion on wrap-Around of Partial IVs (see Section 2.2). 2674 o Separate sections for the COSE Object (Section 3) and the OSCORE 2675 Header Compression (Section 4). 2677 o The countersignature is now appended to the encrypted payload of 2678 the OSCORE message, rather than included in the OSCORE Option (see 2679 Section 4). 2681 o Extended scope of Section 5, now titled " Message Binding, 2682 Sequence Numbers, Freshness and Replay Protection". 2684 o Clarifications about Non-Confirmable messages in Section 5.1 2685 "Synchronization of Sender Sequence Numbers". 2687 o Clarifications about error handling in Section 6 "Message 2688 Processing". 2690 o Compacted list of responsibilities of the Group Manager in 2691 Section 7. 2693 o Revised and extended security considerations in Section 8. 2695 o Added IANA considerations for the OSCORE Flag Bits Registry in 2696 Section 9. 2698 o Revised Appendix D, now giving a short high-level description of a 2699 new endpoint set-up. 2701 H.6. Version -01 to -02 2703 o Terminology has been made more aligned with RFC7252 and draft- 2704 ietf-core-object-security: i) "client" and "server" replace the 2705 old "multicaster" and "listener", respectively; ii) "silent 2706 server" replaces the old "pure listener". 2708 o Section 2 has been updated to have the Group Identifier stored in 2709 the 'ID Context' parameter defined in draft-ietf-core-object- 2710 security. 2712 o Section 3 has been updated with the new format of the Additional 2713 Authenticated Data. 2715 o Major rewriting of Section 4 to better highlight the differences 2716 with the message processing in draft-ietf-core-object-security. 2718 o Added Sections 7.2 and 7.3 discussing security considerations 2719 about uniqueness of (key, nonce) and collision of group 2720 identifiers, respectively. 2722 o Minor updates to Appendix A.1 about assumptions on multicast 2723 communication topology and group size. 2725 o Updated Appendix C on format of group identifiers, with practical 2726 implications of possible collisions of group identifiers. 2728 o Updated Appendix D.2, adding a pointer to draft-palombini-ace-key- 2729 groupcomm about retrieval of nodes' public keys through the Group 2730 Manager. 2732 o Minor updates to Appendix E.3 about Challenge-Response 2733 synchronization of sequence numbers based on the Echo option from 2734 draft-ietf-core-echo-request-tag. 2736 H.7. Version -00 to -01 2738 o Section 1.1 has been updated with the definition of group as 2739 "security group". 2741 o Section 2 has been updated with: 2743 * Clarifications on etablishment/derivation of Security Contexts. 2745 * A table summarizing the the additional context elements 2746 compared to OSCORE. 2748 o Section 3 has been updated with: 2750 * Examples of request and response messages. 2752 * Use of CounterSignature0 rather than CounterSignature. 2754 * Additional Authenticated Data including also the signature 2755 algorithm, while not including the Group Identifier any longer. 2757 o Added Section 6, listing the responsibilities of the Group 2758 Manager. 2760 o Added Appendix A (former section), including assumptions and 2761 security objectives. 2763 o Appendix B has been updated with more details on the use cases. 2765 o Added Appendix C, providing an example of Group Identifier format. 2767 o Appendix D has been updated to be aligned with draft-palombini- 2768 ace-key-groupcomm. 2770 Acknowledgments 2772 The authors sincerely thank Stefan Beck, Rolf Blom, Carsten Bormann, 2773 Esko Dijk, Klaus Hartke, Rikard Hoeglund, Richard Kelsey, John 2774 Mattsson, Dave Robin, Jim Schaad, Ludwig Seitz, Peter van der Stok 2775 and Erik Thormarker for their feedback and comments. 2777 The work on this document has been partly supported by VINNOVA and 2778 the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact 2779 Initiative ACTIVE. 2781 Authors' Addresses 2783 Marco Tiloca 2784 RISE AB 2785 Isafjordsgatan 22 2786 Kista SE-16440 Stockholm 2787 Sweden 2789 Email: marco.tiloca@ri.se 2791 Goeran Selander 2792 Ericsson AB 2793 Torshamnsgatan 23 2794 Kista SE-16440 Stockholm 2795 Sweden 2797 Email: goran.selander@ericsson.com 2799 Francesca Palombini 2800 Ericsson AB 2801 Torshamnsgatan 23 2802 Kista SE-16440 Stockholm 2803 Sweden 2805 Email: francesca.palombini@ericsson.com 2806 Jiye Park 2807 Universitaet Duisburg-Essen 2808 Schuetzenbahn 70 2809 Essen 45127 2810 Germany 2812 Email: ji-ye.park@uni-due.de