idnits 2.17.1 draft-ietf-core-oscore-groupcomm-14.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: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. 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 (7 March 2022) is 774 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-core-groupcomm-bis-06 == Outdated reference: A later version (-10) exists of draft-ietf-cose-countersign-05 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-countersign' ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-800-56A' ** Downref: Normative reference to an Informational RFC: RFC 6979 ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Downref: Normative reference to an Informational RFC: RFC 8032 == Outdated reference: A later version (-08) exists of draft-amsuess-core-cachable-oscore-04 == Outdated reference: A later version (-18) exists of draft-ietf-ace-key-groupcomm-15 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-13 == Outdated reference: A later version (-08) exists of draft-ietf-core-observe-multicast-notifications-03 == Outdated reference: A later version (-09) exists of draft-ietf-cose-cbor-encoded-cert-03 == Outdated reference: A later version (-07) exists of draft-ietf-lwig-security-protocol-comparison-05 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 5 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: 8 September 2022 F. Palombini 6 J. Mattsson 7 Ericsson AB 8 J. Park 9 Universitaet Duisburg-Essen 10 7 March 2022 12 Group OSCORE - Secure Group Communication for CoAP 13 draft-ietf-core-oscore-groupcomm-14 15 Abstract 17 This document defines Group Object Security for Constrained RESTful 18 Environments (Group OSCORE), providing end-to-end security of CoAP 19 messages exchanged between members of a group, e.g., sent over IP 20 multicast. In particular, the described approach defines how OSCORE 21 is used in a group communication setting to provide source 22 authentication for CoAP group requests, sent by a client to multiple 23 servers, and for protection of the corresponding CoAP responses. 24 Group OSCORE also defines a pairwise mode where each member of the 25 group can efficiently derive a symmetric pairwise key with any other 26 member of the group for pairwise OSCORE communication. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 8 September 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 63 2. Security Context . . . . . . . . . . . . . . . . . . . . . . 8 64 2.1. Common Context . . . . . . . . . . . . . . . . . . . . . 11 65 2.1.1. AEAD Algorithm . . . . . . . . . . . . . . . . . . . 11 66 2.1.2. ID Context . . . . . . . . . . . . . . . . . . . . . 11 67 2.1.3. Group Manager Authentication Credential . . . . . . . 12 68 2.1.4. Signature Encryption Algorithm . . . . . . . . . . . 12 69 2.1.5. Signature Algorithm . . . . . . . . . . . . . . . . . 12 70 2.1.6. Group Encryption Key . . . . . . . . . . . . . . . . 12 71 2.1.7. Pairwise Key Agreement Algorithm . . . . . . . . . . 13 72 2.2. Sender Context and Recipient Context . . . . . . . . . . 13 73 2.3. Authentication Credentials . . . . . . . . . . . . . . . 14 74 2.4. Pairwise Keys . . . . . . . . . . . . . . . . . . . . . . 16 75 2.4.1. Derivation of Pairwise Keys . . . . . . . . . . . . . 16 76 2.4.2. ECDH with Montgomery Coordinates . . . . . . . . . . 18 77 2.4.3. Usage of Sequence Numbers . . . . . . . . . . . . . . 19 78 2.4.4. Security Context for Pairwise Mode . . . . . . . . . 20 79 2.5. Update of Security Context . . . . . . . . . . . . . . . 20 80 2.5.1. Loss of Mutable Security Context . . . . . . . . . . 21 81 2.5.2. Exhaustion of Sender Sequence Number . . . . . . . . 22 82 2.5.3. Retrieving New Security Context Parameters . . . . . 23 83 3. The Group Manager . . . . . . . . . . . . . . . . . . . . . . 25 84 3.1. Support for Additional Entities . . . . . . . . . . . . . 26 85 3.2. Management of Group Keying Material . . . . . . . . . . . 27 86 3.2.1. Recycling of Identifiers . . . . . . . . . . . . . . 30 87 3.3. Responsibilities of the Group Manager . . . . . . . . . . 32 88 4. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 34 89 4.1. Countersignature . . . . . . . . . . . . . . . . . . . . 34 90 4.1.1. Keystream Derivation . . . . . . . . . . . . . . . . 35 91 4.1.2. Clarifications on Using a Countersignature . . . . . 36 92 4.2. The 'kid' and 'kid context' parameters . . . . . . . . . 36 93 4.3. external_aad . . . . . . . . . . . . . . . . . . . . . . 36 94 5. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 39 95 5.1. Examples of Compressed COSE Objects . . . . . . . . . . . 40 96 5.1.1. Examples in Group Mode . . . . . . . . . . . . . . . 40 97 5.1.2. Examples in Pairwise Mode . . . . . . . . . . . . . . 41 99 6. Message Binding, Sequence Numbers, Freshness and Replay 100 Protection . . . . . . . . . . . . . . . . . . . . . . . 42 101 6.1. Supporting Observe . . . . . . . . . . . . . . . . . . . 42 102 6.2. Update of Replay Window . . . . . . . . . . . . . . . . . 42 103 6.3. Message Freshness . . . . . . . . . . . . . . . . . . . . 43 104 7. Message Reception . . . . . . . . . . . . . . . . . . . . . . 43 105 8. Message Processing in Group Mode . . . . . . . . . . . . . . 44 106 8.1. Protecting the Request . . . . . . . . . . . . . . . . . 46 107 8.1.1. Supporting Observe . . . . . . . . . . . . . . . . . 46 108 8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 47 109 8.2.1. Supporting Observe . . . . . . . . . . . . . . . . . 49 110 8.3. Protecting the Response . . . . . . . . . . . . . . . . . 49 111 8.3.1. Supporting Observe . . . . . . . . . . . . . . . . . 50 112 8.4. Verifying the Response . . . . . . . . . . . . . . . . . 51 113 8.4.1. Supporting Observe . . . . . . . . . . . . . . . . . 53 114 8.5. External Signature Checkers . . . . . . . . . . . . . . . 54 115 9. Message Processing in Pairwise Mode . . . . . . . . . . . . . 55 116 9.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . 56 117 9.2. Main Differences from OSCORE . . . . . . . . . . . . . . 56 118 9.3. Protecting the Request . . . . . . . . . . . . . . . . . 57 119 9.4. Verifying the Request . . . . . . . . . . . . . . . . . . 57 120 9.5. Protecting the Response . . . . . . . . . . . . . . . . . 57 121 9.6. Verifying the Response . . . . . . . . . . . . . . . . . 58 122 10. Challenge-Response Synchronization . . . . . . . . . . . . . 59 123 11. Implementation Compliance . . . . . . . . . . . . . . . . . . 62 124 12. Security Considerations . . . . . . . . . . . . . . . . . . . 63 125 12.1. Security of the Group Mode . . . . . . . . . . . . . . . 64 126 12.2. Security of the Pairwise Mode . . . . . . . . . . . . . 66 127 12.3. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 67 128 12.4. Management of Group Keying Material . . . . . . . . . . 67 129 12.5. Update of Security Context and Key Rotation . . . . . . 68 130 12.5.1. Late Update on the Sender . . . . . . . . . . . . . 68 131 12.5.2. Late Update on the Recipient . . . . . . . . . . . . 69 132 12.6. Collision of Group Identifiers . . . . . . . . . . . . . 69 133 12.7. Cross-group Message Injection . . . . . . . . . . . . . 70 134 12.7.1. Attack Description . . . . . . . . . . . . . . . . . 70 135 12.7.2. Attack Prevention in Group Mode . . . . . . . . . . 71 136 12.8. Prevention of Group Cloning Attack . . . . . . . . . . . 72 137 12.9. Group OSCORE for Unicast Requests . . . . . . . . . . . 73 138 12.10. End-to-end Protection . . . . . . . . . . . . . . . . . 74 139 12.11. Master Secret . . . . . . . . . . . . . . . . . . . . . 74 140 12.12. Replay Protection . . . . . . . . . . . . . . . . . . . 75 141 12.13. Message Freshness . . . . . . . . . . . . . . . . . . . 75 142 12.14. Client Aliveness . . . . . . . . . . . . . . . . . . . . 75 143 12.15. Cryptographic Considerations . . . . . . . . . . . . . . 76 144 12.16. Message Segmentation . . . . . . . . . . . . . . . . . . 77 145 12.17. Privacy Considerations . . . . . . . . . . . . . . . . . 78 146 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 147 13.1. OSCORE Flag Bits Registry . . . . . . . . . . . . . . . 79 148 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 79 149 14.1. Normative References . . . . . . . . . . . . . . . . . . 79 150 14.2. Informative References . . . . . . . . . . . . . . . . . 81 151 Appendix A. Assumptions and Security Objectives . . . . . . . . 84 152 A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 85 153 A.2. Security Objectives . . . . . . . . . . . . . . . . . . . 86 154 Appendix B. List of Use Cases . . . . . . . . . . . . . . . . . 87 155 Appendix C. Example of Group Identifier Format . . . . . . . . . 90 156 Appendix D. Set-up of New Endpoints . . . . . . . . . . . . . . 91 157 Appendix E. Document Updates . . . . . . . . . . . . . . . . . . 91 158 E.1. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 91 159 E.2. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 92 160 E.3. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 92 161 E.4. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 93 162 E.5. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 94 163 E.6. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 95 164 E.7. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 95 165 E.8. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 97 166 E.9. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 97 167 E.10. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 98 168 E.11. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 98 169 E.12. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 99 170 E.13. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 100 171 E.14. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 101 172 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 102 173 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 102 175 1. Introduction 177 The Constrained Application Protocol (CoAP) [RFC7252] is a web 178 transfer protocol specifically designed for constrained devices and 179 networks [RFC7228]. Group communication for CoAP 180 [I-D.ietf-core-groupcomm-bis] addresses use cases where deployed 181 devices benefit from a group communication model, for example to 182 reduce latencies, improve performance, and reduce bandwidth 183 utilization. Use cases include lighting control, integrated building 184 control, software and firmware updates, parameter and configuration 185 updates, commissioning of constrained networks, and emergency 186 multicast (see Appendix B). Group communication for CoAP 187 [I-D.ietf-core-groupcomm-bis] mainly uses UDP/IP multicast as the 188 underlying data transport. 190 Object Security for Constrained RESTful Environments (OSCORE) 191 [RFC8613] describes a security protocol based on the exchange of 192 protected CoAP messages. OSCORE builds on CBOR Object Signing and 193 Encryption (COSE) 194 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] and 195 provides end-to-end encryption, integrity, replay protection and 196 binding of response to request between a sender and a recipient, 197 independent of the transport layer also in the presence of 198 intermediaries. To this end, a CoAP message is protected by 199 including its payload (if any), certain options, and header fields in 200 a COSE object, which replaces the authenticated and encrypted fields 201 in the protected message. 203 This document defines Group OSCORE, a security protocol for Group 204 communication for CoAP [I-D.ietf-core-groupcomm-bis], providing the 205 same end-to-end security properties as OSCORE in the case where CoAP 206 requests have multiple recipients. In particular, the described 207 approach defines how OSCORE is used in a group communication setting 208 to provide source authentication for CoAP group requests, sent by a 209 client to multiple servers, and for protection of the corresponding 210 CoAP responses. Group OSCORE also defines a pairwise mode where each 211 member of the group can efficiently derive a symmetric pairwise key 212 with any other member of the group for pairwise OSCORE communication. 213 Just like OSCORE, Group OSCORE is independent of the transport layer 214 and works wherever CoAP does. 216 As with OSCORE, it is possible to combine Group OSCORE with 217 communication security on other layers. One example is the use of 218 transport layer security, such as DTLS 219 [RFC6347][I-D.ietf-tls-dtls13], between one client and one proxy (and 220 vice versa), or between one proxy and one server (and vice versa). 221 This prevents observers from accessing addressing information 222 conveyed in CoAP options that would not be protected by Group OSCORE, 223 but would be protected by DTLS. These options include Uri-Host, Uri- 224 Port and Proxy-Uri. Note that DTLS does not define how to secure 225 messages sent over IP multicast. 227 Group OSCORE defines two modes of operation, that can be used 228 independently or together: 230 * In the group mode, Group OSCORE requests and responses are 231 digitally signed with the private key of the sender and the 232 signature is embedded in the protected CoAP message. The group 233 mode supports all COSE signature algorithms as well as signature 234 verification by intermediaries. This mode is defined in 235 Section 8. 237 * In the pairwise mode, two group members exchange OSCORE requests 238 and responses (typically) over unicast, and the messages are 239 protected with symmetric keys. These symmetric keys are derived 240 from Diffie-Hellman shared secrets, calculated with the asymmetric 241 keys of the sender and recipient, allowing for shorter integrity 242 tags and therefore lower message overhead. This mode is defined 243 in Section 9. 245 Both modes provide source authentication of CoAP messages. The 246 application decides what mode to use, potentially on a per-message 247 basis. Such decisions can be based, for instance, on pre-configured 248 policies or dynamic assessing of the target recipient and/or 249 resource, among other things. One important case is when requests 250 are protected with the group mode, and responses with the pairwise 251 mode. Since such responses convey shorter integrity tags instead of 252 bigger, full-fledged signatures, this significantly reduces the 253 message overhead in case of many responses to one request. 255 A special deployment of Group OSCORE is to use pairwise mode only. 256 For example, consider the case of a constrained-node network 257 [RFC7228] with a large number of CoAP endpoints and the objective to 258 establish secure communication between any pair of endpoints with a 259 small provisioning effort and message overhead. Since the total 260 number of security associations that needs to be established grows 261 with the square of the number of endpoints, it is desirable to 262 restrict the amount of secret keying material provided to each 263 endpoint. Moreover, a key establishment protocol would need to be 264 executed for each security association. One solution to this is to 265 deploy Group OSCORE, with the endpoints being part of a group, and 266 use the pairwise mode. This solution assumes a trusted third party 267 called Group Manager (see Section 3). However, it has the benefit of 268 providing a single shared secret, while distributing only the public 269 keys of group members or a subset of those. After that, a CoAP 270 endpoint can locally derive the OSCORE Security Context for the other 271 endpoint in the group, and protect CoAP communications with very low 272 overhead [I-D.ietf-lwig-security-protocol-comparison]. 274 1.1. Terminology 276 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 277 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 278 "OPTIONAL" in this document are to be interpreted as described in BCP 279 14 [RFC2119] [RFC8174] when, and only when, they appear in all 280 capitals, as shown here. 282 Readers are expected to be familiar with the terms and concepts 283 described in CoAP [RFC7252] including "endpoint", "client", "server", 284 "sender" and "recipient"; group communication for CoAP 286 [I-D.ietf-core-groupcomm-bis]; CBOR [RFC8949]; COSE 287 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] and 288 related countersignatures [I-D.ietf-cose-countersign]. 290 Readers are also expected to be familiar with the terms and concepts 291 for protection and processing of CoAP messages through OSCORE, such 292 as "Security Context" and "Master Secret", defined in [RFC8613]. 294 Terminology for constrained environments, such as "constrained 295 device" and "constrained-node network", is defined in [RFC7228]. 297 This document refers also to the following terminology. 299 * Keying material: data that is necessary to establish and maintain 300 secure communication among endpoints. This includes, for 301 instance, keys and IVs [RFC4949]. 303 * Authentication credential: set of information associated with an 304 entity, including that entity's public key and parameters 305 associated with the public key. Examples of authentication 306 credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) 307 [RFC8392], X.509 certificates [RFC7925] and C509 certificates 308 [I-D.ietf-cose-cbor-encoded-cert]. Further details about 309 authentication credentials are provided in Section 2.3. 311 * Group: a set of endpoints that share group keying material and 312 security parameters (Common Context, see Section 2). That is, 313 unless otherwise specified, the term group used in this document 314 refers to a "security group" (see Section 2.1 of 315 [I-D.ietf-core-groupcomm-bis]), not to be confused with "CoAP 316 group" or "application group". 318 * Group Manager: entity responsible for a group. Each endpoint in a 319 group communicates securely with the respective Group Manager, 320 which is neither required to be an actual group member nor to take 321 part in the group communication. The full list of 322 responsibilities of the Group Manager is provided in Section 3.3. 324 * Silent server: member of a group that never sends protected 325 responses in reply to requests. For CoAP group communications, 326 requests are normally sent without necessarily expecting a 327 response. A silent server may send unprotected responses, as 328 error responses reporting an OSCORE error. Note that an endpoint 329 can implement both a silent server and a client, i.e., the two 330 roles are independent. An endpoint acting only as a silent server 331 performs only Group OSCORE processing on incoming requests. 332 Silent servers maintain less keying material and in particular do 333 not have a Sender Context for the group. Since silent servers do 334 not have a Sender ID, they cannot support the pairwise mode. 336 * Group Identifier (Gid): identifier assigned to the group, unique 337 within the set of groups of a given Group Manager. 339 * Birth Gid: with respect to a group member, the Gid obtained by 340 that group member upon (re-)joining the group. 342 * Group request: CoAP request message sent by a client in the group 343 to all servers in that group. 345 * Key Generation Number: an integer value identifying the current 346 version of the keying material used in a group. 348 * Source authentication: evidence that a received message in the 349 group originated from a specific identified group member. This 350 also provides assurance that the message was not tampered with by 351 anyone, be it a different legitimate group member or an endpoint 352 which is not a group member. 354 2. Security Context 356 As per the terminology in Section 1.1, this document refers to a 357 group as a set of endpoints sharing keying material and security 358 parameters for executing the Group OSCORE protocol. Each endpoint of 359 a group is aware of whether the group uses the group mode, or the 360 pairwise mode, or both. Then, an endpoint can use any mode it 361 supports if also used in the group. 363 All members of a group maintain a Security Context as defined in 364 Section 3 of [RFC8613] and extended as defined in this section. How 365 the Security Context is established by the group members is out of 366 scope for this document, but if there is more than one Security 367 Context applicable to a message, then the endpoints MUST be able to 368 tell which Security Context was latest established. 370 The default setting for how to manage information about the group, 371 including the Security Context, is described in terms of a Group 372 Manager (see Section 3). In particular, the Group Manager indicates 373 whether the group uses the group mode, the pairwise mode, or both of 374 them, as part of the group data provided to candidate group members 375 when joining the group. 377 The remainder of this section provides further details about the 378 Security Context of Group OSCORE. In particular, each endpoint which 379 is member of a group maintains a Security Context as defined in 380 Section 3 of [RFC8613], extended as follows (see Figure 1). 382 * One Common Context, shared by all the endpoints in the group. 383 Several new parameters are included in the Common Context. 385 If a Group Manager is used for maintaining the group, the Common 386 Context is extended with the authentication credential of the 387 Group Manager, including the Group Manager's public key. When 388 processing messages, the authentication credential of the Group 389 Manager is included in the external additional authenticated data 390 (see Section 4.3). 392 If the group uses the group mode, the Common context is extended 393 with the following new parameters. 395 - Signature Encryption Algorithm and Signature Algorithm. These 396 relate to the encryption/decryption operations and to the 397 computation/verification of countersignatures, respectively, 398 when a message is protected with the group mode (see 399 Section 8). 401 - Group Encryption Key, used to perform encryption/decryption of 402 countersignatures, when a message is protected with the group 403 mode (see Section 8). 405 If the group uses the pairwise mode, the Common Context is 406 extended with a Pairwise Key Agreement Algorithm used for 407 agreement on a static-static Diffie-Hellman shared secret, from 408 which pairwise keys are derived (see Section 2.4.1) to protect 409 messages with the pairwise mode (see Section 9). 411 * One Sender Context, extended with the endpoint's private key and 412 authentication credential including the endpoint's public key. 414 The private key is used to sign messages protected with the group 415 mode, or for deriving pairwise keys in pairwise mode (see 416 Section 2.4). The authentication credential is used for deriving 417 pairwise keys in pairwise mode, and is included in the external 418 additional authenticated data when processing outgoing messages 419 (see Section 9). 421 If the endpoint supports the pairwise mode, the Sender Context is 422 also extended with the Pairwise Sender Keys associated with the 423 other endpoints (see Section 2.4). 425 The Sender Context is omitted if the endpoint is configured 426 exclusively as silent server. 428 * One Recipient Context for each other endpoint from which messages 429 are received. It is not necessary to maintain Recipient Contexts 430 associated with endpoints from which messages are not (expected to 431 be) received. The Recipient Context is extended with the 432 authentication credential of the other endpoint, including that 433 endpoint's public key. 435 The public key is used to verify the signature of messages 436 protected with the group mode from the other endpoint and for 437 deriving the pairwise keys in pairwise mode (see Section 2.4). 438 The authentication credential is used for deriving pairwise keys 439 in pairwise mode, and is included in the external additional 440 authenticated data when processing incoming messages from the 441 other endpoint (see Section 9). 443 If the endpoint supports the pairwise mode, then the Recipient 444 Context is also extended with the Pairwise Recipient Key 445 associated with the other endpoint (see Section 2.4). 447 +-------------------+-------------------------------------------------+ 448 | Context Component | New Information Elements | 449 +-------------------+-------------------------------------------------+ 450 | Common Context | Group Manager Authentication Credential | 451 | | * Signature Encryption Algorithm | 452 | | * Signature Algorithm | 453 | | * Group Encryption Key | 454 | | ^ Pairwise Key Agreement Algorithm | 455 +-------------------+-------------------------------------------------+ 456 | Sender Context | Endpoint's own private key | 457 | | Endpoint's own authentication credential | 458 | | ^ Pairwise Sender Keys for the other endpoints | 459 +-------------------+-------------------------------------------------+ 460 | Each | Other endpoint's authentication credential | 461 | Recipient Context | ^ Pairwise Recipient Key for the other endpoint | 462 +-------------------+-------------------------------------------------+ 464 Figure 1: Additions to the OSCORE Security Context. The optional 465 elements labeled with * (with ^) are present only if the group 466 uses the group mode (the pairwise mode). 468 2.1. Common Context 470 The Common Context may be acquired from the Group Manager (see 471 Section 3). The following sections define how the Common Context is 472 extended, compared to [RFC8613]. 474 2.1.1. AEAD Algorithm 476 AEAD Algorithm identifies the COSE AEAD algorithm to use for 477 encryption, when messages are protected using the pairwise mode (see 478 Section 9). This algorithm MUST provide integrity protection. This 479 parameter is immutable once the Common Context is established, and it 480 is not relevant if the group uses only the group mode. 482 2.1.2. ID Context 484 The ID Context parameter (see Sections 3.1 and 3.3 of [RFC8613]) in 485 the Common Context SHALL contain the Group Identifier (Gid) of the 486 group. The choice of the Gid format is application specific. An 487 example of specific formatting of the Gid is given in Appendix C. 488 The application needs to specify how to handle potential collisions 489 between Gids (see Section 12.6). 491 2.1.3. Group Manager Authentication Credential 493 Group Manager Authentication Credential specifies the authentication 494 credential of the Group Manager, including the Group Manager's public 495 key. This is included in the external additional authenticated data 496 when processing messages (see Section 4.3). 498 Each group member MUST obtain the authentication credential of the 499 Group Manager with a valid proof-of-possession of the corresponding 500 private key, for instance from the Group Manager itself when joining 501 the group. Further details on the provisioning of the Group 502 Manager's authentication credential to the group members are out of 503 the scope of this document. 505 2.1.4. Signature Encryption Algorithm 507 Signature Encryption Algorithm identifies the algorithm to use for 508 encryption, when messages are protected using the group mode (see 509 Section 8). This algorithm MAY provide integrity protection. This 510 parameter is immutable once the Common Context is established. 512 This algorithm is not used to encrypt the countersignature in 513 messages protected using the group mode, for which the method defined 514 in Section 4.1 is used. 516 2.1.5. Signature Algorithm 518 Signature Algorithm identifies the digital signature algorithm used 519 to compute a countersignature on the COSE object (see Sections 3.2 520 and 3.3 of [I-D.ietf-cose-countersign]), when messages are protected 521 using the group mode (see Section 8). This parameter is immutable 522 once the Common Context is established. 524 2.1.6. Group Encryption Key 526 Group Encryption Key specifies the encryption key for deriving a 527 keystream to encrypt/decrypt a countersignature, when a message is 528 protected with the group mode (see Section 8). 530 The Group Encryption Key is derived as defined for Sender/Recipient 531 Keys in Section 3.2.1 of [RFC8613], with the following differences. 533 * The 'id' element of the 'info' array is the empty byte string. 535 * The 'alg_aead' element of the 'info' array takes the value of 536 Signature Encryption Algorithm from the Common Context (see 537 Section 2.1.5). 539 * The 'type' element of the 'info' array is "Group Encryption Key". 540 The label is an ASCII string and does not include a trailing NUL 541 byte. 543 * L and the 'L' element of the 'info' array are the size of the key 544 for the Signature Encryption Algorithm from the Common Context 545 (see Section 2.1.5), in bytes. 547 2.1.7. Pairwise Key Agreement Algorithm 549 Pairwise Key Agreement Algorithm identifies the elliptic curve 550 Diffie-Hellman algorithm used to derive a static-static Diffie- 551 Hellman shared secret, from which pairwise keys are derived (see 552 Section 2.4.1) to protect messages with the pairwise mode (see 553 Section 9). This parameter is immutable once the Common Context is 554 established. 556 2.2. Sender Context and Recipient Context 558 OSCORE specifies the derivation of Sender Context and Recipient 559 Context, specifically of Sender/Recipient Keys and Common IV, from a 560 set of input parameters (see Section 3.2 of [RFC8613]). 562 The derivation of Sender/Recipient Keys and Common IV defined in 563 OSCORE applies also to Group OSCORE, with the following extensions 564 compared to Section 3.2.1 of [RFC8613]. 566 * If the group uses (also) the group mode, the 'alg_aead' element of 567 the 'info' array takes the value of Signature Encryption Algorithm 568 from the Common Context (see Section 2.1.5). 570 * If the group uses only the pairwise mode, the 'alg_aead' element 571 of the 'info' array takes the value of AEAD Algorithm from the 572 Common Context (see Section 2.1.1). 574 The Sender ID SHALL be unique for each endpoint in a group with a 575 certain tuple (Master Secret, Master Salt, Group Identifier), see 576 Section 3.3 of [RFC8613]. 578 For Group OSCORE, the Sender Context and Recipient Context 579 additionally contain asymmetric keys, as described previously in 580 Section 2. The private key of the sender and the authentication 581 credential including the corresponding public key can, for example, 582 be generated by the endpoint or provisioned during manufacturing. 584 With the exception of the authentication credential of the sender 585 endpoint and the possibly associated pairwise keys, a receiver 586 endpoint can derive a complete Security Context from a received Group 587 OSCORE message and the Common Context. The authentication 588 credentials in the Recipient Contexts can be retrieved from the Group 589 Manager (see Section 3) upon joining the group. An authentication 590 credential can alternatively be acquired from the Group Manager at a 591 later time, for example the first time a message is received from a 592 particular endpoint in the group (see Section 8.2 and Section 8.4). 594 For severely constrained devices, it may be not feasible to 595 simultaneously handle the ongoing processing of a recently received 596 message in parallel with the retrieval of the sender endpoint's 597 authentication credential. Such devices can be configured to drop a 598 received message for which there is no (complete) Recipient Context, 599 and retrieve the sender endpoint's authentication credential in order 600 to have it available to verify subsequent messages from that 601 endpoint. 603 An endpoint admits a maximum amount of Recipient Contexts for a same 604 Security Context, e.g., due to memory limitations. After reaching 605 that limit, the creation of a new Recipient Context results in an 606 overflow. When this happens, the endpoint has to delete a current 607 Recipient Context to install the new one. It is up to the 608 application to define policies for selecting the current Recipient 609 Context to delete. If the new Recipient Context has been installed 610 after the endpoint has experienced the overflow above, then the 611 Recipient Context is initialized with an invalid Replay Window, and 612 accordingly requires the endpoint to take appropriate actions (see 613 Section 2.5.1.2). 615 2.3. Authentication Credentials 617 In a group, the following MUST hold for the authentication credential 618 of each endpoint as well as for the authentication credential of the 619 Group Manager. 621 * All authentication credentials MUST be encoded according to the 622 same format used in the group. The used format MUST provide the 623 public key as well as the comprehensive set of information related 624 to the public key algorithm, including, e.g., the used elliptic 625 curve (when applicable). 627 * All authentication credentials and the public key specified 628 therein MUST be for the public key algorithm used in the group and 629 aligned with the possible associated parameters used in the group, 630 e.g., the used elliptic curve (when applicable). 632 If the group uses (also) the group mode, the public key algorithm 633 is the Signature Algorithm used in the group. If the group uses 634 only the pairwise mode, the public key algorithm is the Pairwise 635 Key Agreement Algorithm used in the group. 637 If the authentication credentials are X.509 certificates [RFC7925] 638 or C509 certificates [I-D.ietf-cose-cbor-encoded-cert], the public 639 key algorithm is fully described by the "algorithm" field of the 640 "SubjectPublicKeyInfo" structure, and by the 641 "subjectPublicKeyAlgorithm" element, respectively. 643 If authentication credentials are CBOR Web Tokens (CWTs) or CWT 644 Claims Sets (CCSs) [RFC8392], the public key algorithm is fully 645 described by a COSE key type and its "kty" and "crv" parameters. 647 Authentication credentials are used to derive pairwise keys (see 648 Section 2.4.1) and are included in the external additional 649 authenticated data when processing messages (see Section 4.3). In 650 both these cases, an endpoint in a group MUST treat authentication 651 credentials as opaque data, i.e., by considering the same binary 652 representation made available to other endpoints in the group, 653 possibly through a designated trusted source (e.g., the Group 654 Manager). 656 For example, an X.509 certificate is provided as its direct binary 657 serialization. If C509 certificates or CWTs are used as 658 authentication credentials, each is provided as the binary 659 serialization of a (possibly tagged) CBOR array. If CCSs are used as 660 authentication credentials, each is provided as the binary 661 serialization of a CBOR map. 663 If authentication credentials are CWTs, then the untagged CWT 664 associated with an entity is stored in the Security Context and used 665 as authentication credential for that entity. 667 If authentication credentials are X.509 / C509 certificates or CWTs 668 and the authentication credential associated with an entity is 669 provided within a chain or a bag, then only the end-entity 670 certificate or end-entity untagged CWT is stored in the Security 671 Context and used as authentication credential for that entity. 673 Storing whole authentication credentials rather than only a subset of 674 those may result in a non-negligible storage overhead. On the other 675 hand, it also ensures that authentication credentials are correctly 676 used in a simple, flexible and non-error-prone way, also taking into 677 account future credential formats as entirely new or extending 678 existing ones. In particular, it is ensured that: 680 * When used to derive pairwise keys and when included in the 681 external additional authenticated data, authentication credentials 682 can also specify possible metadata and parameters related to the 683 included public key. Besides the public key algorithm, these 684 comprise other relevant pieces of information such as key usage, 685 expiration time, issuer and subject. 687 * All endpoints using another endpoint's authentication credential 688 use exactly the same binary serialization, as obtained and 689 distributed by the credential provider (e.g., the Group Manager) 690 and as originally crafted by the credential issuer. In turn, this 691 does not require to define and maintain canonical subsets of 692 authentication credentials and their corresponding encoding, and 693 spares endpoints from error-prone re-encoding operations. 695 Depending on the particular deployment and the intended group size, 696 limiting the storage overhead of endpoints in a group can be an 697 incentive for system/network administrators to prefer using a compact 698 format of authentication credentials in the first place. 700 2.4. Pairwise Keys 702 Certain signature schemes, such as EdDSA and ECDSA, support a secure 703 combined signature and encryption scheme. This section specifies the 704 derivation of "pairwise keys", for use in the pairwise mode defined 705 in Section 9. 707 Group OSCORE keys used for both signature and encryption MUST be used 708 only for purposes related to Group OSCORE. These include the 709 processing of messages with Group OSCORE, as well as performing 710 proof-of-possession of private keys, e.g., upon joining a group 711 through the Group Manager (see Section 3). 713 2.4.1. Derivation of Pairwise Keys 715 Using the Group OSCORE Security Context (see Section 2), a group 716 member can derive AEAD keys, to protect point-to-point communication 717 between itself and any other endpoint X in the group by means of the 718 AEAD Algorithm from the Common Context (see Section 2.1.1). The key 719 derivation of these so-called pairwise keys follows the same 720 construction as in Section 3.2.1 of [RFC8613]: 722 Pairwise Sender Key = HKDF(Sender Key, IKM-Sender, info, L) 723 Pairwise Recipient Key = HKDF(Recipient Key, IKM-Recipient, info, L) 725 with 727 IKM-Sender = Sender Auth Cred | Recipient Auth Cred | Shared Secret 728 IKM-Recipient = Recipient Auth Cred | Sender Auth Cred | Shared Secret 730 where: 732 * The Pairwise Sender Key is the AEAD key for processing outgoing 733 messages addressed to endpoint X. 735 * The Pairwise Recipient Key is the AEAD key for processing incoming 736 messages from endpoint X. 738 * HKDF is the OSCORE HKDF algorithm [RFC8613] from the Common 739 Context. 741 * The Sender Key from the Sender Context is used as salt in the 742 HKDF, when deriving the Pairwise Sender Key. 744 * The Recipient Key from the Recipient Context associated with 745 endpoint X is used as salt in the HKDF, when deriving the Pairwise 746 Recipient Key. 748 * Sender Auth Cred is the endpoint's own authentication credential 749 from the Sender Context. 751 * Recipient Auth Cred is the endpoint X's authentication credential 752 from the Recipient Context associated with the endpoint X. 754 * The Shared Secret is computed as a cofactor Diffie-Hellman shared 755 secret, see Section 5.7.1.2 of [NIST-800-56A], using the Pairwise 756 Key Agreement Algorithm. The endpoint uses its private key from 757 the Sender Context and the other endpoint's public key included in 758 Recipient Auth Cred. Note the requirement of validation of public 759 keys in Section 12.15. For X25519 and X448, the procedure is 760 described in Section 5 of [RFC7748] using public keys mapped to 761 Montgomery coordinates, see Section 2.4.2. 763 * IKM-Sender is the Input Keying Material (IKM) used in the HKDF for 764 the derivation of the Pairwise Sender Key. IKM-Sender is the byte 765 string concatenation of Sender Auth Cred, Recipient Auth Cred and 766 the Shared Secret. The authentication credentials Sender Auth 767 Cred and Recipient Auth Cred are binary encoded as defined in 768 Section 2.3. 770 * IKM-Recipient is the Input Keying Material (IKM) used in the HKDF 771 for the derivation of the Pairwise Recipient Key. IKM-Recipient is 772 the byte string concatenation of Recipient Auth Cred, Sender Auth 773 Cred and the Shared Secret. The authentication credentials 774 Recipient Auth Cred and Sender Auth Cred are binary encoded as 775 defined in Section 2.3. 777 * info and L are as defined in Section 3.2.1 of [RFC8613]. That is: 779 - The 'alg_aead' element of the 'info' array takes the value of 780 AEAD Algorithm from the Common Context (see Section 2.1.1). 782 - L and the 'L' element of the 'info' array are the size of the 783 key for the AEAD Algorithm from the Common Context (see 784 Section 2.1.1), in bytes. 786 If EdDSA asymmetric keys are used, the Edward coordinates are mapped 787 to Montgomery coordinates using the maps defined in Sections 4.1 and 788 4.2 of [RFC7748], before using the X25519 and X448 functions defined 789 in Section 5 of [RFC7748]. For further details, see Section 2.4.2. 790 ECC asymmetric keys in Montgomery or Weirstrass form are used 791 directly in the key agreement algorithm without coordinate mapping. 793 After establishing a partially or completely new Security Context 794 (see Section 2.5 and Section 3.2), the old pairwise keys MUST be 795 deleted. Since new Sender/Recipient Keys are derived from the new 796 group keying material (see Section 2.2), every group member MUST use 797 the new Sender/Recipient Keys when deriving new pairwise keys. 799 As long as any two group members preserve the same asymmetric keys, 800 their Diffie-Hellman shared secret does not change across updates of 801 the group keying material. 803 2.4.2. ECDH with Montgomery Coordinates 805 2.4.2.1. Curve25519 807 The y-coordinate of the other endpoint's Ed25519 public key is 808 decoded as specified in Section 5.1.3 of [RFC8032]. The Curve25519 809 u-coordinate is recovered as u = (1 + y) / (1 - y) (mod p) following 810 the map in Section 4.1 of [RFC7748]. Note that the mapping is not 811 defined for y = 1, and that y = -1 maps to u = 0 which corresponds to 812 the neutral group element and thus will result in a degenerate shared 813 secret. Therefore implementations MUST abort if the y-coordinate of 814 the other endpoint's Ed25519 public key is 1 or -1 (mod p). 816 The private signing key byte strings (= the lower 32 bytes used for 817 generating the public key, see step 1 of Section 5.1.5 of [RFC8032]) 818 are decoded the same way for signing in Ed25519 and scalar 819 multiplication in X25519. Hence, to compute the shared secret the 820 endpoint applies the X25519 function to the Ed25519 private signing 821 key byte string and the encoded u-coordinate byte string as specified 822 in Section 5 of [RFC7748]. 824 2.4.2.2. Curve448 826 The y-coordinate of the other endpoint's Ed448 public key is decoded 827 as specified in Section 5.2.3. of [RFC8032]. The Curve448 828 u-coordinate is recovered as u = y^2 * (d * y^2 - 1) / (y^2 - 1) (mod 829 p) following the map from "edwards448" in Section 4.2 of [RFC7748], 830 and also using the relation x^2 = (y^2 - 1)/(d * y^2 - 1) from the 831 curve equation. Note that the mapping is not defined for y = 1 or 832 -1. Therefore implementations MUST abort if the y-coordinate of the 833 peer endpoint's Ed448 public key is 1 or -1 (mod p). 835 The private signing key byte strings (= the lower 57 bytes used for 836 generating the public key, see step 1 of Section 5.2.5 of [RFC8032]) 837 are decoded the same way for signing in Ed448 and scalar 838 multiplication in X448. Hence, to compute the shared secret the 839 endpoint applies the X448 function to the Ed448 private signing key 840 byte string and the encoded u-coordinate byte string as specified in 841 Section 5 of [RFC7748]. 843 2.4.3. Usage of Sequence Numbers 845 When using any of its Pairwise Sender Keys, a sender endpoint 846 including the 'Partial IV' parameter in the protected message MUST 847 use the current fresh value of the Sender Sequence Number from its 848 Sender Context (see Section 2.2). That is, the same Sender Sequence 849 Number space is used for all outgoing messages protected with Group 850 OSCORE, thus limiting both storage and complexity. 852 On the other hand, when combining group and pairwise communication 853 modes, this may result in the Partial IV values moving forward more 854 often. This can happen when a client engages in frequent or long 855 sequences of one-to-one exchanges with servers in the group, by 856 sending requests over unicast. In turn, this contributes to a sooner 857 exhaustion of the Sender Sequence Number space of the client, which 858 would then require to take actions for deriving a new Sender Context 859 before resuming communications in the group (see Section 2.5.2). 861 2.4.4. Security Context for Pairwise Mode 863 If the pairwise mode is supported, the Security Context additionally 864 includes Pairwise Key Agreement Algorithm and the pairwise keys, as 865 described at the beginning of Section 2. 867 The pairwise keys as well as the shared secrets used in their 868 derivation (see Section 2.4.1) may be stored in memory or recomputed 869 every time they are needed. The shared secret changes only when a 870 public/private key pair used for its derivation changes, which 871 results in the pairwise keys also changing. Additionally, the 872 pairwise keys change if the Sender ID changes or if a new Security 873 Context is established for the group (see Section 2.5.3). In order 874 to optimize protocol performance, an endpoint may store the derived 875 pairwise keys for easy retrieval. 877 In the pairwise mode, the Sender Context includes the Pairwise Sender 878 Keys to use with the other endpoints (see Figure 1). In order to 879 identify the right key to use, the Pairwise Sender Key for endpoint X 880 may be associated with the Recipient ID of endpoint X, as defined in 881 the Recipient Context (i.e., the Sender ID from the point of view of 882 endpoint X). In this way, the Recipient ID can be used to lookup for 883 the right Pairwise Sender Key. This association may be implemented in 884 different ways, e.g., by storing the pair (Recipient ID, Pairwise 885 Sender Key) or linking a Pairwise Sender Key to a Recipient Context. 887 2.5. Update of Security Context 889 It is RECOMMENDED that the immutable part of the Security Context is 890 stored in non-volatile memory, or that it can otherwise be reliably 891 accessed throughout the operation of the group, e.g., after a device 892 reboots. However, also immutable parts of the Security Context may 893 need to be updated, for example due to scheduled key renewal, new or 894 re-joining members in the group, or the fact that the endpoint 895 changes Sender ID (see Section 2.5.3). 897 On the other hand, the mutable parts of the Security Context are 898 updated by the endpoint when executing the security protocol, but may 899 nevertheless become outdated, e.g., due to loss of the mutable 900 Security Context (see Section 2.5.1) or exhaustion of Sender Sequence 901 Numbers (see Section 2.5.2). 903 If it is not feasible or practically possible to store and maintain 904 up-to-date the mutable part in non-volatile memory (e.g., due to 905 limited number of write operations), the endpoint MUST be able to 906 detect a loss of the mutable Security Context and MUST accordingly 907 take the actions defined in Section 2.5.1. 909 2.5.1. Loss of Mutable Security Context 911 An endpoint may lose its mutable Security Context, e.g., due to a 912 reboot (see Section 2.5.1.1) or to an overflow of Recipient Contexts 913 (see Section 2.5.1.2). 915 In such a case, the endpoint needs to prevent the re-use of a nonce 916 with the same AEAD key, and to handle incoming replayed messages. 918 2.5.1.1. Reboot and Total Loss 920 In case a loss of the Sender Context and/or of the Recipient Contexts 921 is detected (e.g., following a reboot), the endpoint MUST NOT protect 922 further messages using this Security Context to avoid reusing an AEAD 923 nonce with the same AEAD key. 925 In particular, before resuming its operations in the group, the 926 endpoint MUST retrieve new Security Context parameters from the Group 927 Manager (see Section 2.5.3) and use them to derive a new Sender 928 Context (see Section 2.2). Since this includes a newly derived 929 Sender Key, a server will not reuse the same pair (key, nonce), even 930 when using the Partial IV of (old re-injected) requests to build the 931 AEAD nonce for protecting the corresponding responses. 933 From then on, the endpoint MUST use the latest installed Sender 934 Context to protect outgoing messages. Also, newly created Recipient 935 Contexts will have a Replay Window which is initialized as valid. 937 If not able to establish an updated Sender Context, e.g., because of 938 lack of connectivity with the Group Manager, the endpoint MUST NOT 939 protect further messages using the current Security Context and MUST 940 NOT accept incoming messages from other group members, as currently 941 unable to detect possible replays. 943 An adversary may leverage the above to perform a Denial of Service 944 attack and prevent some group members from communicating altogether. 945 That is, the adversary can first block the communication path between 946 the Group Manager and some individual group members. This can be 947 achieved, for instance, by injecting fake responses to DNS queries 948 for the Group Manager hostname, or by removing a network link used 949 for routing traffic towards the Group Manager. Then, the adversary 950 can induce a reboot for some endpoints in the group, e.g., by 951 triggering a short power outage. After that, such endpoints that 952 have lost their Sender Context and/or Recipient Contexts following 953 the reboot would not be able to obtain new Security Context 954 parameters from the Group Manager, as specified above. Thus, they 955 would not be able to further communicate in the group until 956 connectivity with the Group Manager is restored. 958 2.5.1.2. Overflow of Recipient Contexts 960 After reaching the maximum amount of Recipient Contexts, an endpoint 961 will experience an overflow when installing a new Recipient Context, 962 as it requires to first delete an existing one (see Section 2.2). 964 Every time this happens, the Replay Window of the new Recipient 965 Context is initialized as not valid. Therefore, the endpoint MUST 966 take the following actions, before accepting request messages from 967 the client associated with the new Recipient Context. 969 If it is not configured as silent server, the endpoint MUST either: 971 * Retrieve new Security Context parameters from the Group Manager 972 and derive a new Sender Context, as defined in Section 2.5.1.1; or 974 * When receiving a first request to process with the new Recipient 975 Context, use the approach specified in Section 10 and based on the 976 Echo Option for CoAP [RFC9175], if supported. In particular, the 977 endpoint MUST use its Partial IV when generating the AEAD nonce 978 and MUST include the Partial IV in the response message conveying 979 the Echo Option. If the endpoint supports the CoAP Echo Option, 980 it is RECOMMENDED to take this approach. 982 If it is configured exclusively as silent server, the endpoint MUST 983 wait for the next group rekeying to occur, in order to derive a new 984 Security Context and re-initialize the Replay Window of each 985 Recipient Contexts as valid. 987 2.5.2. Exhaustion of Sender Sequence Number 989 An endpoint can eventually exhaust the Sender Sequence Number, which 990 is incremented for each new outgoing message including a Partial IV. 991 This is the case for group requests, Observe notifications [RFC7641] 992 and, optionally, any other response. 994 Implementations MUST be able to detect an exhaustion of Sender 995 Sequence Number, after the endpoint has consumed the largest usable 996 value. If an implementation's integers support wrapping addition, 997 the implementation MUST treat Sender Sequence Number as exhausted 998 when a wrap-around is detected. 1000 Upon exhausting the Sender Sequence Numbers, the endpoint MUST NOT 1001 use this Security Context to protect further messages including a 1002 Partial IV. 1004 The endpoint SHOULD inform the Group Manager, retrieve new Security 1005 Context parameters from the Group Manager (see Section 2.5.3), and 1006 use them to derive a new Sender Context (see Section 2.2). 1008 From then on, the endpoint MUST use its latest installed Sender 1009 Context to protect outgoing messages. 1011 2.5.3. Retrieving New Security Context Parameters 1013 The Group Manager can assist an endpoint with an incomplete Sender 1014 Context to retrieve missing data of the Security Context and thereby 1015 become fully operational in the group again. The two main options 1016 for the Group Manager are described in this section: i) assignment of 1017 a new Sender ID to the endpoint (see Section 2.5.3.1); and ii) 1018 establishment of a new Security Context for the group (see 1019 Section 2.5.3.2). The update of the Replay Window in each of the 1020 Recipient Contexts is discussed in Section 6.2. 1022 As group membership changes, or as group members get new Sender IDs 1023 (see Section 2.5.3.1) so do the relevant Recipient IDs that the other 1024 endpoints need to keep track of. As a consequence, group members may 1025 end up retaining stale Recipient Contexts, that are no longer useful 1026 to verify incoming secure messages. 1028 The Recipient ID ('kid') SHOULD NOT be considered as a persistent and 1029 reliable identifier of a group member. Such an indication can be 1030 achieved only by using that member's public key, when verifying 1031 countersignatures of received messages (in group mode), or when 1032 verifying messages integrity-protected with pairwise keying material 1033 derived from authentication credentials and associated asymmetric 1034 keys (in pairwise mode). 1036 Furthermore, applications MAY define policies to: i) delete 1037 (long-)unused Recipient Contexts and reduce the impact on storage 1038 space; as well as ii) check with the Group Manager that an 1039 authentication credential with the public key included therein is 1040 currently the one associated with a 'kid' value, after a number of 1041 consecutive failed verifications. 1043 2.5.3.1. New Sender ID for the Endpoint 1045 The Group Manager may assign a new Sender ID to an endpoint, while 1046 leaving the Gid, Master Secret and Master Salt unchanged in the 1047 group. In this case, the Group Manager MUST assign a Sender ID that 1048 has not been used in the group since the latest time when the current 1049 Gid value was assigned to the group (see Section 3.2). 1051 Having retrieved the new Sender ID, and potentially other missing 1052 data of the immutable Security Context, the endpoint can derive a new 1053 Sender Context (see Section 2.2). When doing so, the endpoint resets 1054 the Sender Sequence Number in its Sender Context to 0, and derives a 1055 new Sender Key. This is in turn used to possibly derive new Pairwise 1056 Sender Keys. 1058 From then on, the endpoint MUST use its latest installed Sender 1059 Context to protect outgoing messages. 1061 The assignment of a new Sender ID may be the result of different 1062 processes. The endpoint may request a new Sender ID, e.g., because 1063 of exhaustion of Sender Sequence Numbers (see Section 2.5.2). An 1064 endpoint may request to re-join the group, e.g., because of losing 1065 its mutable Security Context (see Section 2.5.1), and is provided 1066 with a new Sender ID together with the latest immutable Security 1067 Context. 1069 For the other group members, the Recipient Context corresponding to 1070 the old Sender ID becomes stale (see Section 3.2). 1072 2.5.3.2. New Security Context for the Group 1074 The Group Manager may establish a new Security Context for the group 1075 (see Section 3.2). The Group Manager does not necessarily establish 1076 a new Security Context for the group if one member has an outdated 1077 Security Context (see Section 2.5.3.1), unless that was already 1078 planned or required for other reasons. 1080 All the group members need to acquire new Security Context parameters 1081 from the Group Manager. Once having acquired new Security Context 1082 parameters, each group member performs the following actions. 1084 * From then on, it MUST NOT use the current Security Context to 1085 start processing new messages for the considered group. 1087 * It completes any ongoing message processing for the considered 1088 group. 1090 * It derives and install a new Security Context. In particular: 1092 - It re-derives the keying material stored in its Sender Context 1093 and Recipient Contexts (see Section 2.2). The Master Salt used 1094 for the re-derivations is the updated Master Salt parameter if 1095 provided by the Group Manager, or the empty byte string 1096 otherwise. 1098 - It resets its Sender Sequence Number in its Sender Context to 1099 0. 1101 - It re-initializes the Replay Window of each Recipient Context. 1103 - For each ongoing observation where it is an observer client and 1104 that it wants to keep active, it resets to 0 the Notification 1105 Number of each associated server (see Section 6.1). 1107 From then on, it can resume processing new messages for the 1108 considered group. In particular: 1110 * It MUST use its latest installed Sender Context to protect 1111 outgoing messages. 1113 * It SHOULD use its latest installed Recipient Contexts to process 1114 incoming messages, unless application policies admit to 1115 temporarily retain and use the old, recent, Security Context (see 1116 Section 12.5.1). 1118 The distribution of a new Gid and Master Secret may result in 1119 temporarily misaligned Security Contexts among group members. In 1120 particular, this may result in a group member not being able to 1121 process messages received right after a new Gid and Master Secret 1122 have been distributed. A discussion on practical consequences and 1123 possible ways to address them, as well as on how to handle the old 1124 Security Context, is provided in Section 12.5. 1126 3. The Group Manager 1128 As with OSCORE, endpoints communicating with Group OSCORE need to 1129 establish the relevant Security Context. Group OSCORE endpoints need 1130 to acquire OSCORE input parameters, information about the group(s) 1131 and about other endpoints in the group(s). This document is based on 1132 the existence of an entity called Group Manager and responsible for 1133 the group, but it does not mandate how the Group Manager interacts 1134 with the group members. The list of responsibilities of the Group 1135 Manager is compiled in Section 3.3. 1137 A possible Group Manager to use is specified in 1138 [I-D.ietf-ace-key-groupcomm-oscore], where the join process is based 1139 on the ACE framework for authentication and authorization in 1140 constrained environments [I-D.ietf-ace-oauth-authz]. 1142 The Group Manager assigns an integer Key Generation Number to each of 1143 its groups, identifying the current version of the keying material 1144 used in that group. The first Key Generation Number assigned to 1145 every group MUST be 0. Separately for each group, the value of the 1146 Key Generation Number increases strictly monotonically, each time the 1147 Group Manager distributes new keying material to that group (see 1148 Section 3.2). That is, if the current Key Generation Number for a 1149 group is X, then X+1 will denote the keying material distributed and 1150 used in that group immediately after the current one. 1152 The Group Manager assigns unique Group Identifiers (Gids) to the 1153 groups under its control. Also, for each group, the Group Manager 1154 assigns unique Sender IDs (and thus Recipient IDs) to the respective 1155 group members. According to a hierarchical approach, the Gid value 1156 assigned to a group is associated with a dedicated space for the 1157 values of Sender ID and Recipient ID of the members of that group. 1158 When an endpoint (re-)joins a group, it is provided also with the 1159 current Gid to use in the group. 1161 The Group Manager maintains records of the authentication credentials 1162 of endpoints in a group, and provides information about the group and 1163 its members to other group members and to external entities with 1164 selected roles (see Section 3.1). Upon endpoints' joining, the Group 1165 Manager collects such authentication credentials and MUST verify 1166 proof-of-possession of the respective private key. 1168 An endpoint acquires group data such as the Gid and OSCORE input 1169 parameters including its own Sender ID from the Group Manager, and 1170 provides information about its authentication credential to the Group 1171 Manager, for example upon joining the group. 1173 Furthermore, when joining the group or later on as a group member, an 1174 endpoint can retrieve from the Group Manager the authentication 1175 credential of the Group Manager as well as the authentication 1176 credential and other information associated with other members of the 1177 group, with which it can derive the corresponding Recipient Context. 1178 Together with the requested authentication credentials, the Group 1179 Manager MUST provide the Sender ID of the associated group members 1180 and the current Key Generation Number in the group. An application 1181 can configure a group member to asynchronously retrieve information 1182 about Recipient Contexts, e.g., by Observing [RFC7641] a resource at 1183 the Group Manager to get updates on the group membership. 1185 3.1. Support for Additional Entities 1187 The Group Manager MAY serve additional entities acting as signature 1188 checkers, e.g., intermediary gateways. These entities do not join a 1189 group as members, but can retrieve authentication credentials of 1190 group members and other selected group data from the Group Manager, 1191 in order to solely verify countersignatures of messages protected in 1192 group mode (see Section 8.5). 1194 In order to verify countersignatures of messages in a group, a 1195 signature checker needs to retrieve the following information about 1196 that group from the Group Manager. 1198 * The current ID Context (Gid) used in the group. 1200 * The authentication credentials of the group members and the 1201 authentication credential of the Group Manager. 1203 If the signature checker is provided with a CWT for a given 1204 entity, then the authentication credential associated with that 1205 entity that the signature checker stores and uses is the untagged 1206 CWT. 1208 If the signature checker is provided with a chain or a bag of 1209 X.509 / C509 certificates or of CWTs for a given entity, then the 1210 authentication credential associated with that entity that the 1211 signature checker stores and uses is just the end-entity 1212 certificate or end-entity untagged CWT. 1214 * The current Group Encryption Key (see Section 2.1.6). 1216 * The identifiers of the algorithms used in the group (see 1217 Section 2), i.e.: i) Signature Encryption Algorithm and Signature 1218 Algorithm; and ii) AEAD Algorithm and Pairwise Key Agreement 1219 Algorithm, if the group uses also the pairwise mode. 1221 A signature checker MUST be authorized before it can retrieve such 1222 information. To this end, the same method mentioned above based on 1223 the ACE framework [I-D.ietf-ace-oauth-authz] can be used. 1225 3.2. Management of Group Keying Material 1227 In order to establish a new Security Context for a group, the Group 1228 Manager MUST generate and assign to the group a new Group Identifier 1229 (Gid) and a new value for the Master Secret parameter. When doing 1230 so, a new value for the Master Salt parameter MAY also be generated 1231 and assigned to the group. When establishing the new Security 1232 Context, the Group Manager should preserve the current value of the 1233 Sender ID of each group member. 1235 The specific group key management scheme used to distribute new 1236 keying material is out of the scope of this document. A simple group 1237 key management scheme is defined in 1238 [I-D.ietf-ace-key-groupcomm-oscore]. When possible, the delivery of 1239 rekeying messages should use a reliable transport, in order to reduce 1240 chances of group members missing a rekeying instance. 1242 The set of group members should not be assumed as fixed, i.e., the 1243 group membership is subject to changes, possibly on a frequent basis. 1245 The Group Manager MUST rekey the group when one or more endpoints 1246 leave the group. An endpoint may leave the group at own initiative, 1247 or may be evicted from the group by the Group Manager, e.g., in case 1248 an endpoint is compromised, or is suspected to be compromised. In 1249 either case, rekeying the group excludes such endpoints from future 1250 communications in the group, and thus preserves forward security. If 1251 a network node is compromised or suspected to be compromised, the 1252 Group Manager MUST evict from the group all the endpoints hosted by 1253 that node that are member of the group and rekey the group 1254 accordingly. 1256 If required by the application, the Group Manager MUST rekey the 1257 group also before one or more new joining endpoints are added to the 1258 group, thus preserving backward security. 1260 The establishment of the new Security Context for the group takes the 1261 following steps. 1263 1. The Group Manager MUST increment the Key Generation Number for 1264 the group by 1. 1266 2. The Group Manager MUST build a set of stale Sender IDs including: 1268 * The Sender IDs that, during the current Gid, were both 1269 assigned to an endpoint and subsequently relinquished (see 1270 Section 2.5.3.1). 1272 * The current Sender IDs of the group members that the upcoming 1273 group rekeying aims to exclude from future group 1274 communications, if any. 1276 3. The Group Manager rekeys the group, by distributing: 1278 * The new keying material, i.e., the new Master Secret, the new 1279 Gid and (optionally) the new Master Salt. 1281 * The new Key Generation Number from step 1. 1283 * The set of stale Sender IDs from step 2. 1285 Further information may be distributed, depending on the specific 1286 group key management scheme used in the group. 1288 When receiving the new group keying materal, a group member considers 1289 the received stale Sender IDs and performs the following actions. 1291 * The group member MUST remove every authentication credential 1292 associated with a stale Sender ID from its list of group members' 1293 authentication credentials used in the group. 1295 * The group member MUST delete each of its Recipient Contexts used 1296 in the group whose corresponding Recipient ID is a stale Sender 1297 ID. 1299 After that, the group member installs the new keying material and 1300 derives the corresponding new Security Context. 1302 A group member might miss one group rekeying or more consecutive 1303 instances. As a result, the group member will retain old group 1304 keying material with Key Generation Number GEN_OLD. Eventually, the 1305 group member can notice the discrepancy, e.g., by repeatedly failing 1306 to verify incoming messages, or by explicitly querying the Group 1307 Manager for the current Key Generation Number. Once the group member 1308 gains knowledge of having missed a group rekeying, it MUST delete the 1309 old keying material it stores. 1311 Then, the group member proceeds according to the following steps. 1313 1. The group member retrieves from the Group Manager the current 1314 group keying material, together with the current Key Generation 1315 Number GEN_NEW. The group member MUST NOT install the obtained 1316 group keying material yet. 1318 2. The group member asks the Group Manager for the set of stale 1319 Sender IDs. 1321 3. If no exact indication can be obtained from the Group Manager, 1322 the group member MUST remove all the authentication credentials 1323 from its list of group members' authentication credentials used 1324 in the group and MUST delete all its Recipient Contexts used in 1325 the group. 1327 Otherwise, the group member MUST remove every authentication 1328 credential associated with a stale Sender ID from its list of 1329 group members' authentication credentials used in the group, and 1330 MUST delete each of its Recipient Contexts used in the group 1331 whose corresponding Recipient ID is a stale Sender ID. 1333 4. The group member installs the current group keying material, and 1334 derives the corresponding new Security Context. 1336 Alternatively, the group member can re-join the group. In such a 1337 case, the group member MUST take one of the following two actions. 1339 * The group member performs steps 2 and 3 above. Then, the group 1340 member re-joins the group. 1342 * The group member re-joins the group with the same roles it 1343 currently has in the group, and, during the re-joining process, it 1344 asks the Group Manager for the authentication credentials of all 1345 the current group members. 1347 Then, given Z the set of authentication credentials received from 1348 the Group Manager, the group member removes every authentication 1349 credential which is not in Z from its list of group members' 1350 authentication credentials used in the group, and deletes each of 1351 its Recipient Contexts used in the group that does not include any 1352 of the authentication credentials in Z. 1354 By removing authentication credentials and deleting Recipient 1355 Contexts associated with stale Sender IDs, it is ensured that a 1356 recipient endpoint storing the latest group keying material does not 1357 store the authentication credentials of sender endpoints that are not 1358 current group members. This in turn allows group members to rely on 1359 stored authentication credentials to confidently assert the group 1360 membership of sender endpoints, when receiving incoming messages 1361 protected in group mode (see Section 8). 1363 3.2.1. Recycling of Identifiers 1365 This section specifies how the Group Manager handles and possibly 1366 reassigns Gid values and Sender ID values in a group. 1368 3.2.1.1. Recycling of Group Identifiers 1370 Since the Gid value changes every time a group is rekeyed, it can 1371 happen that, after several rekeying instances, the whole space of Gid 1372 values has been used for the group in question. When this happens, 1373 the Group Manager has no available Gid values to use that have never 1374 been assigned to the group during the group's lifetime. 1376 The occurrence of such an event and how long it would take to occur 1377 depend on the format and encoding of Gid values used in the group 1378 (see, e.g., Appendix C), as well as on the frequency of rekeying 1379 instances yielding a change of Gid value. Independently for each 1380 group under its control, the Group Manager can take one of the two 1381 following approaches. 1383 * The Group Manager does not reassign Gid values. That is, once the 1384 whole space of Gid values has been used for a group, the Group 1385 Manager terminates the group and may re-establish a new group. 1387 * While the Gid value changes every time a group is rekeyed, the 1388 Group Manager can reassign Gid values previously used during a 1389 group's lifetime. By doing so, the group can continue to exist 1390 even once the whole space of Gid values has been used. 1392 The Group Manager MAY support and use this approach. In such a 1393 case, the Group Manager MUST take additional actions when handling 1394 Gid values and rekeying the group, as specified below. 1396 When a node (re-)joins the group and it is provided with the 1397 current Gid to use in the group, the Group Manager considers such 1398 a Gid as the Birth Gid of that endpoint for that group. For each 1399 group member, the Group Manager MUST store the latest 1400 corresponding Birth Gid until that member leaves the group. In 1401 case the endpoint has in fact re-joined the group, the newly 1402 determined Birth Gid overwrites the one currently stored. 1404 When establishing a new Security Context for the group, the Group 1405 Manager takes the additional following step between steps 1 and 2 1406 of Section 3.2. 1408 A. The Group Manager MUST check if the new Gid to be distributed 1409 is equal to the Birth Gid of any of the current group members. If 1410 any of such "elder members" is found in the group, then: 1412 - The Group Manager MUST evict the elder members from the group. 1413 That is, the Group Manager MUST terminate their membership and 1414 MUST rekey the group in such a way that the new keying material 1415 is not provided to those evicted elder members. 1417 This ensures that an Observe notification [RFC7641] can never 1418 successfully match against the Observe requests of two 1419 different observations. In fact, the excluded elder members 1420 would eventually re-join the group, thus terminating any of 1421 their ongoing (long-lasting) observations (see Section 6.1). 1422 Therefore, it is ensured by construction that no observer 1423 client can have two different ongoing observations such that 1424 the two respective Observe requests were protected using the 1425 same Partial IV, Gid and Sender ID. 1427 - Until a further following group rekeying, the Group Manager 1428 MUST store the list of those latest-evicted elder members. If 1429 any of those endpoints re-joins the group before a further 1430 following group rekeying occurs, the Group Manager MUST NOT 1431 rekey the group upon their re-joining. When one of those 1432 endpoints re-joins the group, the Group Manager can rely, e.g., 1433 on the ongoing secure communication association to recognize 1434 the endpoint as included in the stored list. 1436 3.2.1.2. Recycling of Sender IDs 1438 From the moment when a Gid is assigned to a group until the moment a 1439 new Gid is assigned to that same group, the Group Manager MUST NOT 1440 reassign a Sender ID within the group. This prevents to reuse a 1441 Sender ID ('kid') with the same Gid, Master Secret and Master Salt. 1442 Within this restriction, the Group Manager can assign a Sender ID 1443 used under an old Gid value (including under a same, recycled Gid 1444 value), thus avoiding Sender ID values to irrecoverably grow in size. 1446 Even when an endpoint joining a group is recognized as a current 1447 member of that group, e.g., through the ongoing secure communication 1448 association, the Group Manager MUST assign a new Sender ID different 1449 than the one currently used by the endpoint in the group, unless the 1450 group is rekeyed first and a new Gid value is established. 1452 3.2.1.3. Relation between Identifiers and Keying Material 1454 Figure 2 overviews the different identifiers and keying material 1455 components, considering their relation and possible reuse across 1456 group rekeying. 1458 Components changed in lockstep 1459 upon a group rekeying 1460 +----------------------------+ * Changing a kid does not 1461 | | need changing the Group ID 1462 | Master Group |<--> kid1 1463 | Secret <---> o <---> ID | * A kid is not reassigned 1464 | ^ |<--> kid2 under the ongoing usage of 1465 | | | the current Group ID 1466 | | |<--> kid3 1467 | v | * Upon changing the Group ID, 1468 | Master Salt | ... ... every current kid should 1469 | (optional) | be preserved for efficient 1470 | | key rollover 1471 | The Key Generation Number | 1472 | is incremented by 1 | * After changing Group ID, an 1473 | | unused kid can be assigned, 1474 +----------------------------+ even if it was used before 1475 the Group ID change 1477 Figure 2: Relations among keying material components. 1479 3.3. Responsibilities of the Group Manager 1481 The Group Manager is responsible for performing the following tasks: 1483 1. Creating and managing OSCORE groups. This includes the 1484 assignment of a Gid to every newly created group, ensuring 1485 uniqueness of Gids within the set of its OSCORE groups and, 1486 optionally, the secure recycling of Gids. 1488 2. Defining policies for authorizing the joining of its OSCORE 1489 groups. 1491 3. Handling the join process to add new endpoints as group members. 1493 4. Establishing the Common Context part of the Security Context, 1494 and providing it to authorized group members during the join 1495 process, together with the corresponding Sender Context. 1497 5. Updating the Key Generation Number and the Gid of its OSCORE 1498 groups, upon renewing the respective Security Context. 1500 6. Generating and managing Sender IDs within its OSCORE groups, as 1501 well as assigning and providing them to new endpoints during the 1502 join process, or to current group members upon request of 1503 renewal or re-joining. This includes ensuring that: 1505 * Each Sender ID is unique within each of the OSCORE groups; 1507 * Each Sender ID is not reassigned within the same group since 1508 the latest time when the current Gid value was assigned to 1509 the group. That is, the Sender ID is not reassigned even to 1510 a current group member re-joining the same group, without a 1511 rekeying happening first. 1513 7. Defining communication policies for each of its OSCORE groups, 1514 and signaling them to new endpoints during the join process. 1516 8. Renewing the Security Context of an OSCORE group upon membership 1517 change, by revoking and renewing common security parameters and 1518 keying material (rekeying). 1520 9. Providing the management keying material that a new endpoint 1521 requires to participate in the rekeying process, consistently 1522 with the key management scheme used in the group joined by the 1523 new endpoint. 1525 10. Assisting a group member that has missed a group rekeying 1526 instance to understand which authentication credentials and 1527 Recipient Contexts to delete, as associated with former group 1528 members. 1530 11. Acting as key repository, in order to handle the authentication 1531 credentials of the members of its OSCORE groups, and providing 1532 such authentication credentials to other members of the same 1533 group upon request. The actual storage of authentication 1534 credentials may be entrusted to a separate secure storage device 1535 or service. 1537 12. Validating that the format and parameters of authentication 1538 credentials of group members are consistent with the public key 1539 algorithm and related parameters used in the respective OSCORE 1540 group. 1542 The Group Manager specified in [I-D.ietf-ace-key-groupcomm-oscore] 1543 provides these functionalities. 1545 4. The COSE Object 1547 Building on Section 5 of [RFC8613], this section defines how to use 1548 COSE [I-D.ietf-cose-rfc8152bis-struct] to wrap and protect data in 1549 the original message. OSCORE uses the untagged COSE_Encrypt0 1550 structure with an Authenticated Encryption with Associated Data 1551 (AEAD) algorithm. Unless otherwise specified, the following 1552 modifications apply for both the group mode and the pairwise mode of 1553 Group OSCORE. 1555 4.1. Countersignature 1557 When protecting a message in group mode, the 'unprotected' field MUST 1558 additionally include the following parameter: 1560 * COSE_CounterSignature0: its value is set to the encrypted 1561 countersignature of the COSE object, namely ENC_SIGNATURE. That 1562 is: 1564 - The countersignature of the COSE object, namely SIGNATURE, is 1565 computed by the sender as described in Sections 3.2 and 3.3 of 1566 [I-D.ietf-cose-countersign], by using its private key and 1567 according to the Signature Algorithm in the Security Context. 1569 In particular, the Countersign_structure contains the context 1570 text string "CounterSignature0", the external_aad as defined in 1571 Section 4.3 of this document, and the ciphertext of the COSE 1572 object as payload. 1574 - The encrypted countersignature, namely ENC_SIGNATURE, is 1575 computed as 1577 ENC_SIGNATURE = SIGNATURE XOR KEYSTREAM 1578 where KEYSTREAM is derived as per Section 4.1.1. 1580 4.1.1. Keystream Derivation 1582 The following defines how an endpoint derives the keystream 1583 KEYSTREAM, used to encrypt/decrypt the countersignature of an 1584 outgoing/incoming message M protected in group mode. 1586 The keystream SHALL be derived as follows, by using the HKDF 1587 Algorithm from the Common Context (see Section 3.2 of [RFC8613]), 1588 which consists of composing the HKDF-Extract and HKDF-Expand steps 1589 [RFC5869]. 1591 KEYSTREAM = HKDF(salt, IKM, info, L) 1593 The input parameters of HKDF are as follows. 1595 * salt takes as value the Partial IV (PIV) used to protect M. Note 1596 that, if M is a response, salt takes as value either: i) the fresh 1597 Partial IV generated by the server and included in the response; 1598 or ii) the same Partial IV of the request generated by the client 1599 and not included in the response. 1601 * IKM is the Group Encryption Key from the Common Context (see 1602 Section 2.1.6). 1604 * info is the serialization of a CBOR array consisting of (the 1605 notation follows [RFC8610]): 1607 info = [ 1608 id : bstr, 1609 id_context : bstr, 1610 type : bool, 1611 L: uint 1612 ] 1614 where: 1616 * id is the Sender ID of the endpoint that generated PIV. 1618 * id_context is the ID Context (Gid) used when protecting M. 1620 Note that, in case of group rekeying, a server might use a 1621 different Gid when protecting a response, compared to the Gid that 1622 it used to verify (that the client used to protect) the request, 1623 see Section 8.3. 1625 * type is the CBOR simple value "true" (0xf5) if M is a request, or 1626 the CBOR simple value "false" (0xf4) otherwise. 1628 * L is the size of the countersignature, as per Signature Algorithm 1629 from the Common Context (see Section 2.1.5), in bytes. 1631 4.1.2. Clarifications on Using a Countersignature 1633 Note that the literature commonly refers to a countersignature as a 1634 signature computed by an entity A over a document already protected 1635 by a different entity B. 1637 However, the COSE_Countersignature0 structure belongs to the set of 1638 abbreviated countersignatures defined in Sections 3.2 and 3.3 of 1639 [I-D.ietf-cose-countersign], which were designed primarily to deal 1640 with the problem of encrypted group messaging, but where it is 1641 required to know who originated the message. 1643 Since the parameters for computing or verifying the abbreviated 1644 countersignature generated by A are provided by the same context used 1645 to describe the security processing performed by B and to be 1646 countersigned, these structures are applicable also when the two 1647 entities A and B are actually the same one, like the sender of a 1648 Group OSCORE message protected in group mode. 1650 4.2. The 'kid' and 'kid context' parameters 1652 The value of the 'kid' parameter in the 'unprotected' field of 1653 response messages MUST be set to the Sender ID of the endpoint 1654 transmitting the message, if the request was protected in group mode. 1655 That is, unlike in [RFC8613], the 'kid' parameter is always present 1656 in responses to a request that was protected in group mode. 1658 The value of the 'kid context' parameter in the 'unprotected' field 1659 of requests messages MUST be set to the ID Context, i.e., the Group 1660 Identifier value (Gid) of the group. That is, unlike in [RFC8613], 1661 the 'kid context' parameter is always present in requests. 1663 4.3. external_aad 1665 The external_aad of the Additional Authenticated Data (AAD) is 1666 different compared to OSCORE [RFC8613], and is defined in this 1667 section. 1669 The same external_aad structure is used in group mode and pairwise 1670 mode for authenticated encryption/decryption (see Section 5.3 of 1671 [I-D.ietf-cose-rfc8152bis-struct]), as well as in group mode for 1672 computing and verifying the countersignature (see Section 4.4 of 1673 [I-D.ietf-cose-rfc8152bis-struct]). 1675 In particular, the external_aad includes also the Signature 1676 Algorithm, the Signature Encryption Algorithm, the Pairwise Key 1677 Agreement Algorithm, the value of the 'kid context' in the COSE 1678 object of the request, the OSCORE option of the protected message, 1679 the sender's authentication credential, and the Group Manager's 1680 authentication credential. 1682 The external_aad SHALL be a CBOR array wrapped in a bstr object as 1683 defined below, following the notation of [RFC8610]: 1685 external_aad = bstr .cbor aad_array 1687 aad_array = [ 1688 oscore_version : uint, 1689 algorithms : [alg_aead : int / tstr / null, 1690 alg_signature_enc : int / tstr / null, 1691 alg_signature : int / tstr / null, 1692 alg_pairwise_key_agreement : int / tstr / null], 1693 request_kid : bstr, 1694 request_piv : bstr, 1695 options : bstr, 1696 request_kid_context : bstr, 1697 OSCORE_option: bstr, 1698 sender_cred: bstr, 1699 gm_cred: bstr / null 1700 ] 1702 Figure 3: external_aad 1704 Compared with Section 5.4 of [RFC8613], the aad_array has the 1705 following differences. 1707 * The 'algorithms' array is extended as follows. 1709 The parameter 'alg_aead' MUST be set to the CBOR simple value 1710 "null" (0xf6) if the group does not use the pairwise mode, 1711 regardless whether the endpoint supports the pairwise mode or not. 1712 Otherwise, this parameter MUST encode the value of AEAD Algorithm 1713 from the Common Context (see Section 2.1.1), as per Section 5.4 of 1714 [RFC8613]. 1716 Furthermore, the 'algorithms' array additionally includes: 1718 - 'alg_signature_enc', which specifies Signature Encryption 1719 Algorithm from the Common Context (see Section 2.1.5). This 1720 parameter MUST be set to the CBOR simple value "null" (0xf6) if 1721 the group does not use the group mode, regardless whether the 1722 endpoint supports the group mode or not. Otherwise, this 1723 parameter MUST encode the value of Signature Encryption 1724 Algorithm as a CBOR integer or text string, consistently with 1725 the "Value" field in the "COSE Algorithms" Registry for this 1726 AEAD algorithm. 1728 - 'alg_signature', which specifies Signature Algorithm from the 1729 Common Context (see Section 2.1.5). This parameter MUST be set 1730 to the CBOR simple value "null" (0xf6) if the group does not 1731 use the group mode, regardless whether the endpoint supports 1732 the group mode or not. Otherwise, this parameter MUST encode 1733 the value of Signature Algorithm as a CBOR integer or text 1734 string, consistently with the "Value" field in the "COSE 1735 Algorithms" Registry for this signature algorithm. 1737 - 'alg_pairwise_key_agreement', which specifies Pairwise Key 1738 Agreement Algorithm from the Common Context (see 1739 Section 2.1.5). This parameter MUST be set to the CBOR simple 1740 value "null" (0xf6) if the group does not use the pairwise 1741 mode, regardless whether the endpoint supports the pairwise 1742 mode or not. Otherwise, this parameter MUST encode the value 1743 of Pairwise Key Agreement Algorithm as a CBOR integer or text 1744 string, consistently with the "Value" field in the "COSE 1745 Algorithms" Registry for this HKDF algorithm. 1747 * The new element 'request_kid_context' contains the value of the 1748 'kid context' in the COSE object of the request (see Section 4.2). 1750 In case Observe [RFC7641] is used, this enables endpoints to 1751 safely keep an observation active beyond a possible change of Gid 1752 (i.e., of ID Context), following a group rekeying (see 1753 Section 3.2). In fact, it ensures that every notification 1754 cryptographically matches with only one observation request, 1755 rather than with multiple ones that were protected with different 1756 keying material but share the same 'request_kid' and 'request_piv' 1757 values. 1759 * The new element 'OSCORE_option', containing the value of the 1760 OSCORE Option present in the protected message, encoded as a 1761 binary string. This prevents the attack described in Section 12.7 1762 when using the group mode, as further explained in Section 12.7.2. 1764 Note for implementation: this construction requires the OSCORE 1765 option of the message to be generated and finalized before 1766 computing the ciphertext of the COSE_Encrypt0 object (when using 1767 the group mode or the pairwise mode) and before calculating the 1768 countersignature (when using the group mode). Also, the aad_array 1769 needs to be large enough to contain the largest possible OSCORE 1770 option. 1772 * The new element 'sender_cred', containing the sender's 1773 authentication credential. This parameter MUST be set to a CBOR 1774 byte string, which encodes the sender's authentication credential 1775 in its original binary representation made available to other 1776 endpoints in the group (see Section 2.3). 1778 * The new element 'gm_cred', containing the Group Manager's 1779 authentication credential. If no Group Manager maintains the 1780 group, this parameter MUST encode the CBOR simple value "null" 1781 (0xf6). Otherwise, this parameter MUST be set to a CBOR byte 1782 string, which encodes the Group Manager's authentication 1783 credential in its original binary representation made available to 1784 other endpoints in the group (see Section 2.3). This prevents the 1785 attack described in Section 12.8. 1787 5. OSCORE Header Compression 1789 The OSCORE header compression defined in Section 6 of [RFC8613] is 1790 used, with the following differences. 1792 * The payload of the OSCORE message SHALL encode the ciphertext of 1793 the COSE_Encrypt0 object. In the group mode, the ciphertext above 1794 is concatenated with the value of the COSE_CounterSignature0 of 1795 the COSE object, computed as described in Section 4.1. 1797 * This document defines the usage of the sixth least significant 1798 bit, called "Group Flag", in the first byte of the OSCORE option 1799 containing the OSCORE flag bits. This flag bit is specified in 1800 Section 13.1. 1802 * The Group Flag MUST be set to 1 if the OSCORE message is protected 1803 using the group mode (see Section 8). 1805 * The Group Flag MUST be set to 0 if the OSCORE message is protected 1806 using the pairwise mode (see Section 9). The Group Flag MUST also 1807 be set to 0 for ordinary OSCORE messages processed according to 1808 [RFC8613]. 1810 5.1. Examples of Compressed COSE Objects 1812 This section covers a list of OSCORE Header Compression examples of 1813 Group OSCORE used in group mode (see Section 5.1.1) or in pairwise 1814 mode (see Section 5.1.2). 1816 The examples assume that the COSE_Encrypt0 object is set (which means 1817 the CoAP message and cryptographic material is known). Note that the 1818 examples do not include the full CoAP unprotected message or the full 1819 Security Context, but only the input necessary to the compression 1820 mechanism, i.e., the COSE_Encrypt0 object. The output is the 1821 compressed COSE object as defined in Section 5 and divided into two 1822 parts, since the object is transported in two CoAP fields: OSCORE 1823 option and payload. 1825 The examples assume that the plaintext (see Section 5.3 of [RFC8613]) 1826 is 6 bytes long, and that the AEAD tag is 8 bytes long, hence 1827 resulting in a ciphertext which is 14 bytes long. When using the 1828 group mode, the COSE_CounterSignature0 byte string as described in 1829 Section 4 is assumed to be 64 bytes long. 1831 5.1.1. Examples in Group Mode 1833 * Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = 1834 0x25, Partial IV = 5 and kid context = 0x44616c. 1836 * Before compression (96 bytes): 1838 [ 1839 h'', 1840 { 4:h'25', 6:h'05', 10:h'44616c', 11:h'de9e ... f1' }, 1841 h'aea0155667924dff8a24e4cb35b9' 1842 ] 1844 * After compression (85 bytes): 1846 Flag byte: 0b00111001 = 0x39 (1 byte) 1848 Option Value: 0x39 05 03 44 61 6c 25 (7 bytes) 1850 Payload: 0xaea0155667924dff8a24e4cb35b9 de9e ... f1 1851 (14 bytes + size of the encrypted countersignature) 1853 * Response with ciphertext = 0x60b035059d9ef5667c5a0710823b, kid = 1854 0x52 and no Partial IV. 1856 * Before compression (88 bytes): 1858 [ 1859 h'', 1860 { 4:h'52', 11:h'ca1e ... b3' }, 1861 h'60b035059d9ef5667c5a0710823b' 1862 ] 1864 * After compression (80 bytes): 1866 Flag byte: 0b00101000 = 0x28 (1 byte) 1868 Option Value: 0x28 52 (2 bytes) 1870 Payload: 0x60b035059d9ef5667c5a0710823b ca1e ... b3 1871 (14 bytes + size of the encrypted countersignature) 1873 5.1.2. Examples in Pairwise Mode 1875 * Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = 1876 0x25, Partial IV = 5 and kid context = 0x44616c. 1878 * Before compression (29 bytes): 1880 [ 1881 h'', 1882 { 4:h'25', 6:h'05', 10:h'44616c' }, 1883 h'aea0155667924dff8a24e4cb35b9' 1884 ] 1886 * After compression (21 bytes): 1888 Flag byte: 0b00011001 = 0x19 (1 byte) 1890 Option Value: 0x19 05 03 44 61 6c 25 (7 bytes) 1892 Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes) 1894 * Response with ciphertext = 0x60b035059d9ef5667c5a0710823b and no 1895 Partial IV. 1897 * Before compression (18 bytes): 1899 [ 1900 h'', 1901 {}, 1902 h'60b035059d9ef5667c5a0710823b' 1903 ] 1905 * After compression (14 bytes): 1907 Flag byte: 0b00000000 = 0x00 (1 byte) 1909 Option Value: 0x (0 bytes) 1911 Payload: 0x60b035059d9ef5667c5a0710823b (14 bytes) 1913 6. Message Binding, Sequence Numbers, Freshness and Replay Protection 1915 The requirements and properties described in Section 7 of [RFC8613] 1916 also apply to Group OSCORE. In particular, Group OSCORE provides 1917 message binding of responses to requests, which enables absolute 1918 freshness of responses that are not notifications, relative freshness 1919 of requests and notification responses, and replay protection of 1920 requests. In addition, the following holds for Group OSCORE. 1922 6.1. Supporting Observe 1924 When Observe [RFC7641] is used, a client maintains for each ongoing 1925 observation one Notification Number for each different server. Then, 1926 separately for each server, the client uses the associated 1927 Notification Number to perform ordering and replay protection of 1928 notifications received from that server (see Section 8.4.1). 1930 Group OSCORE allows to preserve an observation active indefinitely, 1931 even in case the group is rekeyed, with consequent change of ID 1932 Context, or in case the observer client obtains a new Sender ID. 1934 As defined in Section 8 when discussing support for Observe, this is 1935 achieved by the client and server(s) storing the 'kid' and 'kid 1936 context' used in the original Observe request, throughout the whole 1937 duration of the observation. 1939 Upon leaving the group or before re-joining the group, a group member 1940 MUST terminate all the ongoing observations that it has started in 1941 the group as observer client. 1943 6.2. Update of Replay Window 1945 Sender Sequence Numbers seen by a server as Partial IV values in 1946 request messages can spontaneously increase at a fast pace, for 1947 example when a client exchanges unicast messages with other servers 1948 using the Group OSCORE Security Context. As in OSCORE [RFC8613], a 1949 server always needs to accept such increases and accordingly updates 1950 the Replay Window in each of its Recipient Contexts. 1952 As discussed in Section 2.5.1, a newly created Recipient Context 1953 would have an invalid Replay Window, if its installation has required 1954 to delete another Recipient Context. Hence, the server is not able 1955 to verify if a request from the client associated with the new 1956 Recipient Context is a replay. When this happens, the server MUST 1957 validate the Replay Window of the new Recipient Context, before 1958 accepting messages from the associated client (see Section 2.5.1). 1960 Furthermore, when the Group Manager establishes a new Security 1961 Context for the group (see Section 2.5.3.2), every server re- 1962 initializes the Replay Window in each of its Recipient Contexts. 1964 6.3. Message Freshness 1966 When receiving a request from a client for the first time, the server 1967 is not synchronized with the client's Sender Sequence Number, i.e., 1968 it is not able to verify if that request is fresh. This applies to a 1969 server that has just joined the group, with respect to already 1970 present clients, and recurs as new clients are added as group 1971 members. 1973 During its operations in the group, the server may also lose 1974 synchronization with a client's Sender Sequence Number. This can 1975 happen, for instance, if the server has rebooted or has deleted its 1976 previously synchronized version of the Recipient Context for that 1977 client (see Section 2.5.1). 1979 If the application requires message freshness, e.g., according to 1980 time- or event-based policies, the server has to (re-)synchronize 1981 with a client's Sender Sequence Number before delivering request 1982 messages from that client to the application. To this end, the 1983 server can use the approach in Section 10 based on the Echo Option 1984 for CoAP [RFC9175], as a variant of the approach defined in 1985 Appendix B.1.2 of [RFC8613] applicable to Group OSCORE. 1987 7. Message Reception 1989 Upon receiving a protected message, a recipient endpoint retrieves a 1990 Security Context as in [RFC8613]. An endpoint MUST be able to 1991 distinguish between a Security Context to process OSCORE messages as 1992 in [RFC8613] and a Group OSCORE Security Context to process Group 1993 OSCORE messages as defined in this document. 1995 To this end, an endpoint can take into account the different 1996 structure of the Security Context defined in Section 2, for example 1997 based on the presence of Signature Algorithm and/or Pairwise Key 1998 Agreement Algorithm in the Common Context. Alternatively 1999 implementations can use an additional parameter in the Security 2000 Context, to explicitly signal that it is intended for processing 2001 Group OSCORE messages. 2003 If either of the following conditions holds, a recipient endpoint 2004 MUST discard the incoming protected message: 2006 * The Group Flag is set to 0, and the recipient endpoint retrieves a 2007 Security Context which is both valid to process the message and 2008 also associated with an OSCORE group, but the endpoint does not 2009 support the pairwise mode. 2011 * The Group Flag is set to 1, and the recipient endpoint retrieves a 2012 Security Context which is both valid to process the message and 2013 also associated with an OSCORE group, but the endpoint does not 2014 support the group mode. 2016 * The Group Flag is set to 1, and the recipient endpoint can not 2017 retrieve a Security Context which is both valid to process the 2018 message and also associated with an OSCORE group. 2020 As per Section 6.1 of [RFC8613], this holds also when retrieving a 2021 Security Context which is valid but not associated with an OSCORE 2022 group. Future specifications may define how to process incoming 2023 messages protected with a Security Contexts as in [RFC8613], when 2024 the Group Flag bit is set to 1. 2026 Otherwise, if a Security Context associated with an OSCORE group and 2027 valid to process the message is retrieved, the recipient endpoint 2028 processes the message with Group OSCORE, using the group mode (see 2029 Section 8) if the Group Flag is set to 1, or the pairwise mode (see 2030 Section 9) if the Group Flag is set to 0. 2032 Note that, if the Group Flag is set to 0, and the recipient endpoint 2033 retrieves a Security Context which is valid to process the message 2034 but is not associated with an OSCORE group, then the message is 2035 processed according to [RFC8613]. 2037 8. Message Processing in Group Mode 2039 When using the group mode, messages are protected and processed as 2040 specified in [RFC8613], with the modifications described in this 2041 section. The security objectives of the group mode are discussed in 2042 Appendix A.2. 2044 The Group Manager indicates that the group uses (also) the group 2045 mode, as part of the group data provided to candidate group members 2046 when joining the group. 2048 During all the steps of the message processing, an endpoint MUST use 2049 the same Security Context for the considered group. That is, an 2050 endpoint MUST NOT install a new Security Context for that group (see 2051 Section 2.5.3.2) until the message processing is completed. 2053 The group mode MUST be used to protect group requests intended for 2054 multiple recipients or for the whole group. This includes both 2055 requests directly addressed to multiple recipients, e.g., sent by the 2056 client over multicast, as well as requests sent by the client over 2057 unicast to a proxy, that forwards them to the intended recipients 2058 over multicast [I-D.ietf-core-groupcomm-bis]. For encryption and 2059 decryption operations, the Signature Encryption Algorithm from the 2060 Common Context is used. 2062 As per [RFC7252][I-D.ietf-core-groupcomm-bis], group requests sent 2063 over multicast MUST be Non-confirmable, and thus are not 2064 retransmitted by the CoAP messaging layer. Instead, applications 2065 should store such outgoing messages for a predefined, sufficient 2066 amount of time, in order to correctly perform potential 2067 retransmissions at the application layer. According to Section 5.2.3 2068 of [RFC7252], responses to Non-confirmable group requests SHOULD also 2069 be Non-confirmable, but endpoints MUST be prepared to receive 2070 Confirmable responses in reply to a Non-confirmable group request. 2071 Confirmable group requests are acknowledged when sent over non- 2072 multicast transports, as specified in [RFC7252]. 2074 Furthermore, endpoints in the group locally perform error handling 2075 and processing of invalid messages according to the same principles 2076 adopted in [RFC8613]. However, a recipient MUST stop processing and 2077 reject any message which is malformed and does not follow the format 2078 specified in Section 4 of this document, or which is not 2079 cryptographically validated in a successful way. 2081 In either case, it is RECOMMENDED that a server does not send back 2082 any error message in reply to a received request, if any of the two 2083 following conditions holds: 2085 * The server is not able to identify the received request as a group 2086 request, i.e., as sent to all servers in the group. 2088 * The server identifies the received request as a group request. 2090 This prevents servers from replying with multiple error messages to a 2091 client sending a group request, so avoiding the risk of flooding and 2092 possibly congesting the network. 2094 8.1. Protecting the Request 2096 A client transmits a secure group request as described in Section 8.1 2097 of [RFC8613], with the following modifications. 2099 * In step 2, the Additional Authenticated Data is modified as 2100 described in Section 4 of this document. 2102 * In step 4, the encryption of the COSE object is modified as 2103 described in Section 4 of this document. The encoding of the 2104 compressed COSE object is modified as described in Section 5 of 2105 this document. In particular, the Group Flag MUST be set to 1. 2106 The Signature Encryption Algorithm from the Common Context MUST be 2107 used. 2109 * In step 5, the countersignature is computed and the format of the 2110 OSCORE message is modified as described in Section 4 and Section 5 2111 of this document. In particular the payload of the OSCORE message 2112 includes also the encrypted countersignature (see Section 4.1). 2114 8.1.1. Supporting Observe 2116 If Observe [RFC7641] is supported, the following holds for each newly 2117 started observation. 2119 * If the client intends to keep the observation active beyond a 2120 possible change of Sender ID, the client MUST store the value of 2121 the 'kid' parameter from the original Observe request, and retain 2122 it for the whole duration of the observation. Even in case the 2123 client is individually rekeyed and receives a new Sender ID from 2124 the Group Manager (see Section 2.5.3.1), the client MUST NOT 2125 update the stored value associated with a particular Observe 2126 request. 2128 * If the client intends to keep the observation active beyond a 2129 possible change of ID Context following a group rekeying (see 2130 Section 3.2), then the following applies. 2132 - The client MUST store the value of the 'kid context' parameter 2133 from the original Observe request, and retain it for the whole 2134 duration of the observation. Upon establishing a new Security 2135 Context with a new Gid as ID Context (see Section 2.5.3.2), the 2136 client MUST NOT update the stored value associated with a 2137 particular Observe request. 2139 - The client MUST store an invariant identifier of the group, 2140 which is immutable even in case the Security Context of the 2141 group is re-established. For example, this invariant 2142 identifier can be the "group name" in 2143 [I-D.ietf-ace-key-groupcomm-oscore], where it is used for 2144 joining the group and retrieving the current group keying 2145 material from the Group Manager. 2147 After a group rekeying, such an invariant information makes it 2148 simpler for the observer client to retrieve the current group 2149 keying material from the Group Manager, in case the client has 2150 missed both the rekeying messages and the first observe 2151 notification protected with the new Security Context (see 2152 Section 8.3.1). 2154 8.2. Verifying the Request 2156 Upon receiving a secure group request with the Group Flag set to 1, 2157 following the procedure in Section 7, a server proceeds as described 2158 in Section 8.2 of [RFC8613], with the following modifications. 2160 * In step 2, the decoding of the compressed COSE object follows 2161 Section 5 of this document. In particular: 2163 - If the server discards the request due to not retrieving a 2164 Security Context associated with the OSCORE group, the server 2165 MAY respond with a 4.01 (Unauthorized) error message. When 2166 doing so, the server MAY set an Outer Max-Age option with value 2167 zero, and MAY include a descriptive string as diagnostic 2168 payload. 2170 - If the received 'kid context' matches an existing ID Context 2171 (Gid) but the received 'kid' does not match any Recipient ID in 2172 this Security Context, then the server MAY create a new 2173 Recipient Context for this Recipient ID and initialize it 2174 according to Section 3 of [RFC8613], and also retrieve the 2175 authentication credential associated with the Recipient ID to 2176 be stored in the new Recipient Context. Such a configuration 2177 is application specific. If the application does not specify 2178 dynamic derivation of new Recipient Contexts, then the server 2179 SHALL stop processing the request. 2181 * In step 4, the Additional Authenticated Data is modified as 2182 described in Section 4 of this document. 2184 * In step 6, the server also verifies the countersignature, by using 2185 the public key from the client's authentication credential stored 2186 in the associated Recipient Context. In particular: 2188 - If the server does not have the public key of the client yet, 2189 the server MUST stop processing the request and MAY respond 2190 with a 5.03 (Service Unavailable) response. The response MAY 2191 include a Max-Age Option, indicating to the client the number 2192 of seconds after which to retry. If the Max-Age Option is not 2193 present, a retry time of 60 seconds will be assumed by the 2194 client, as default value defined in Section 5.10.5 of 2195 [RFC7252]. 2197 - The server MUST perform signature verification before 2198 decrypting the COSE object, as defined below. Implementations 2199 that cannot perform the two steps in this order MUST ensure 2200 that no access to the plaintext is possible before a successful 2201 signature verification and MUST prevent any possible leak of 2202 time-related information that can yield side-channel attacks. 2204 - The server retrieves the encrypted countersignature 2205 ENC_SIGNATURE from the message payload, and computes the 2206 original countersignature SIGNATURE as 2208 SIGNATURE = ENC_SIGNATURE XOR KEYSTREAM 2210 where KEYSTREAM is derived as per Section 4.1.1. 2212 The server verifies the original countersignature SIGNATURE. 2214 - If the signature verification fails, the server SHALL stop 2215 processing the request, SHALL NOT update the Replay Window, and 2216 MAY respond with a 4.00 (Bad Request) response. The server MAY 2217 set an Outer Max-Age option with value zero. The diagnostic 2218 payload MAY contain a string, which, if present, MUST be 2219 "Decryption failed" as if the decryption had failed. 2221 - When decrypting the COSE object using the Recipient Key, the 2222 Signature Encryption Algorithm from the Common Context MUST be 2223 used. 2225 * Additionally, if the used Recipient Context was created upon 2226 receiving this group request and the message is not verified 2227 successfully, the server MAY delete that Recipient Context. Such 2228 a configuration, which is specified by the application, mitigates 2229 attacks that aim at overloading the server's storage. 2231 A server SHOULD NOT process a request if the received Recipient ID 2232 ('kid') is equal to its own Sender ID in its own Sender Context. For 2233 an example where this is not fulfilled, see Section 7.2.1 of 2234 [I-D.ietf-core-observe-multicast-notifications]. 2236 8.2.1. Supporting Observe 2238 If Observe [RFC7641] is supported, the following holds for each newly 2239 started observation. 2241 * The server MUST store the value of the 'kid' parameter from the 2242 original Observe request, and retain it for the whole duration of 2243 the observation. The server MUST NOT update the stored value of a 2244 'kid' parameter associated with a particular Observe request, even 2245 in case the observer client is individually rekeyed and starts 2246 using a new Sender ID received from the Group Manager (see 2247 Section 2.5.3.1). 2249 * The server MUST store the value of the 'kid context' parameter 2250 from the original Observe request, and retain it for the whole 2251 duration of the observation, beyond a possible change of ID 2252 Context following a group rekeying (see Section 3.2). That is, 2253 upon establishing a new Security Context with a new Gid as ID 2254 Context (see Section 2.5.3.2), the server MUST NOT update the 2255 stored value associated with the ongoing observation. 2257 8.3. Protecting the Response 2259 If a server generates a CoAP message in response to a Group OSCORE 2260 request, then the server SHALL follow the description in Section 8.3 2261 of [RFC8613], with the modifications described in this section. 2263 Note that the server always protects a response with the Sender 2264 Context from its latest Security Context, and that establishing a new 2265 Security Context resets the Sender Sequence Number to 0 (see 2266 Section 3.2). 2268 * In step 2, the Additional Authenticated Data is modified as 2269 described in Section 4 of this document. 2271 * In step 3, if the server is using a different Security Context for 2272 the response compared to what was used to verify the request (see 2273 Section 3.2), then the server MUST include its Sender Sequence 2274 Number as Partial IV in the response and use it to build the AEAD 2275 nonce to protect the response. This prevents the AEAD nonce from 2276 the request from being reused. 2278 * In step 4, the encryption of the COSE object is modified as 2279 described in Section 4 of this document. The encoding of the 2280 compressed COSE object is modified as described in Section 5 of 2281 this document. In particular, the Group Flag MUST be set to 1. 2282 The Signature Encryption Algorithm from the Common Context MUST be 2283 used. 2285 If the server is using a different ID Context (Gid) for the 2286 response compared to what was used to verify the request (see 2287 Section 3.2), then the new ID Context MUST be included in the 'kid 2288 context' parameter of the response. 2290 The server can obtain a new Sender ID from the Group Manager, when 2291 individually rekeyed (see Section 2.5.3.1) or when re-joining the 2292 group. In such a case, the server can help the client to 2293 synchronize, by including the 'kid' parameter in a response 2294 protected in group mode, even when the request was protected in 2295 pairwise mode (see Section 9.3). 2297 That is, when responding to a request protected in pairwise mode, 2298 the server SHOULD include the 'kid' parameter in a response 2299 protected in group mode, if it is replying to that client for the 2300 first time since the assignment of its new Sender ID. 2302 * In step 5, the countersignature is computed and the format of the 2303 OSCORE message is modified as described in Section 4 and Section 5 2304 of this document. In particular the payload of the OSCORE message 2305 includes also the encrypted countersignature (see Section 4.1). 2307 8.3.1. Supporting Observe 2309 If Observe [RFC7641] is supported, the following holds when 2310 protecting notifications for an ongoing observation. 2312 * The server MUST use the stored value of the 'kid' parameter from 2313 the original Observe request (see Section 8.2.1), as value for the 2314 'request_kid' parameter in the external_aad structure (see 2315 Section 4.3). 2317 * The server MUST use the stored value of the 'kid context' 2318 parameter from the original Observe request (see Section 8.2.1), 2319 as value for the 'request_kid_context' parameter in the 2320 external_aad structure (see Section 4.3). 2322 Furthermore, the server may have ongoing observations started by 2323 Observe requests protected with an old Security Context. After 2324 completing the establishment of a new Security Context, the server 2325 MUST protect the following notifications with the Sender Context of 2326 the new Security Context. 2328 For each ongoing observation, the server can help the client to 2329 synchronize, by including also the 'kid context' parameter in 2330 notifications following a group rekeying, with value set to the ID 2331 Context (Gid) of the new Security Context. 2333 If there is a known upper limit to the duration of a group rekeying, 2334 the server SHOULD include the 'kid context' parameter during that 2335 time. Otherwise, the server SHOULD include it until the Max-Age has 2336 expired for the last notification sent before the installation of the 2337 new Security Context. 2339 8.4. Verifying the Response 2341 Upon receiving a secure response message with the Group Flag set to 2342 1, following the procedure in Section 7, the client proceeds as 2343 described in Section 8.4 of [RFC8613], with the following 2344 modifications. 2346 Note that a client may receive a response protected with a Security 2347 Context different from the one used to protect the corresponding 2348 request, and that, upon the establishment of a new Security Context, 2349 the client re-initializes its Replay Windows in its Recipient 2350 Contexts (see Section 3.2). 2352 * In step 2, the decoding of the compressed COSE object is modified 2353 as described in Section 5 of this document. In particular, a 2354 'kid' may not be present, if the response is a reply to a request 2355 protected in pairwise mode. In such a case, the client assumes 2356 the response 'kid' to be the Recipient ID for the server to which 2357 the request protected in pairwise mode was intended for. 2359 If the response 'kid context' matches an existing ID Context (Gid) 2360 but the received/assumed 'kid' does not match any Recipient ID in 2361 this Security Context, then the client MAY create a new Recipient 2362 Context for this Recipient ID and initialize it according to 2363 Section 3 of [RFC8613], and also retrieve the authentication 2364 credential associated with the Recipient ID to be stored in the 2365 new Recipient Context. If the application does not specify 2366 dynamic derivation of new Recipient Contexts, then the client 2367 SHALL stop processing the response. 2369 * In step 3, the Additional Authenticated Data is modified as 2370 described in Section 4 of this document. 2372 * In step 5, the client also verifies the countersignature, by using 2373 the public key from the server's authentication credential stored 2374 in the associated Recipient Context. In particular: 2376 - The client MUST perform signature verification before 2377 decrypting the COSE object, as defined below. Implementations 2378 that cannot perform the two steps in this order MUST ensure 2379 that no access to the plaintext is possible before a successful 2380 signature verification and MUST prevent any possible leak of 2381 time-related information that can yield side-channel attacks. 2383 - The client retrieves the encrypted countersignature 2384 ENC_SIGNATURE from the message payload, and computes the 2385 original countersignature SIGNATURE as 2387 SIGNATURE = ENC_SIGNATURE XOR KEYSTREAM 2389 where KEYSTREAM is derived as per Section 4.1.1. 2391 The client verifies the original countersignature SIGNATURE. 2393 - If the verification of the countersignature fails, the server 2394 SHALL stop processing the response, and SHALL NOT update the 2395 Notification Number associated with the server if the response 2396 is an Observe notification [RFC7641]. 2398 - After a successful verification of the countersignature, the 2399 client performs also the following actions if the response is 2400 not an Observe notification. 2402 o In case the request was protected in pairwise mode and the 2403 'kid' parameter is present in the response, the client 2404 checks whether this received 'kid' is equal to the expected 2405 'kid', i.e., the known Recipient ID for the server to which 2406 the request was intended for. 2408 o In case the request was protected in pairwise mode and the 2409 'kid' parameter is not present in the response, the client 2410 checks whether the server that has sent the response is the 2411 same one to which the request was intended for. This can be 2412 done by checking that the public key used to verify the 2413 countersignature of the response is equal to the public key 2414 included in the authentication credential Recipient Auth 2415 Cred, which was taken as input to derive the Pairwise Sender 2416 Key used for protecting the request (see Section 2.4.1). 2418 In either case, if the client determines that the response has 2419 come from a different server than the expected one, then the 2420 client SHALL discard the response and SHALL NOT deliver it to 2421 the application. Otherwise, the client hereafter considers the 2422 received 'kid' as the current Recipient ID for the server. 2424 - When decrypting the COSE object using the Recipient Key, the 2425 Signature Encryption Algorithm from the Common Context MUST be 2426 used. 2428 * Additionally, if the used Recipient Context was created upon 2429 receiving this response and the message is not verified 2430 successfully, the client MAY delete that Recipient Context. Such 2431 a configuration, which is specified by the application, mitigates 2432 attacks that aim at overloading the client's storage. 2434 8.4.1. Supporting Observe 2436 If Observe [RFC7641] is supported, the following holds when verifying 2437 notifications for an ongoing observation. 2439 * The client MUST use the stored value of the 'kid' parameter from 2440 the original Observe request (see Section 8.1.1), as value for the 2441 'request_kid' parameter in the external_aad structure (see 2442 Section 4.3). 2444 * The client MUST use the stored value of the 'kid context' 2445 parameter from the original Observe request (see Section 8.1.1), 2446 as value for the 'request_kid_context' parameter in the 2447 external_aad structure (see Section 4.3). 2449 This ensures that the client can correctly verify notifications, even 2450 in case it is individually rekeyed and starts using a new Sender ID 2451 received from the Group Manager (see Section 2.5.3.1), as well as 2452 when it installs a new Security Context with a new ID Context (Gid) 2453 following a group rekeying (see Section 3.2). 2455 * The ordering and the replay protection of notifications received 2456 from a server are performed as per Sections 4.1.3.5.2 and 7.4.1 of 2457 [RFC8613], by using the Notification Number associated with that 2458 server for the observation in question. In addition, the client 2459 performs the following actions for each ongoing observation. 2461 - When receiving the first valid notification from a server, the 2462 client MUST store the current kid "kid1" of that server for the 2463 observation in question. If the 'kid' field is included in the 2464 OSCORE option of the notification, its value specifies "kid1". 2465 If the Observe request was protected in pairwise mode (see 2466 Section 9.3), the 'kid' field may not be present in the OSCORE 2467 option of the notification (see Section 4.2). In this case, 2468 the client assumes "kid1" to be the Recipient ID for the server 2469 to which the Observe request was intended for. 2471 - When receiving another valid notification from the same server 2472 - which can be identified and recognized through the same 2473 public key used to verify the countersignature and included in 2474 the server's authentication credential - the client determines 2475 the current kid "kid2" of the server as above for "kid1", and 2476 MUST check whether "kid2" is equal to the stored "kid1". If 2477 "kid1" and "kid2" are different, the client MUST cancel or re- 2478 register the observation in question. 2480 Note that, if "kid2" is different from "kid1" and the 'kid' 2481 field is omitted from the notification - which is possible if 2482 the Observe request was protected in pairwise mode - then the 2483 client will compute a wrong keystream to decrypt the 2484 countersignature (i.e., by using "kid1" rather than "kid2" in 2485 the 'id' field of the 'info' array in Section 4.1.1), thus 2486 subsequently failing to verify the countersignature and 2487 discarding the notification. 2489 This ensures that the client remains able to correctly perform the 2490 ordering and replay protection of notifications, even in case a 2491 server legitimately starts using a new Sender ID, as received from 2492 the Group Manager when individually rekeyed (see Section 2.5.3.1) or 2493 when re-joining the group. 2495 8.5. External Signature Checkers 2497 When receiving a message protected in group mode, a signature checker 2498 (see Section 3.1) proceeds as follows. 2500 * The signature checker retrieves the encrypted countersignature 2501 ENC_SIGNATURE from the message payload, and computes the original 2502 countersignature SIGNATURE as 2504 SIGNATURE = ENC_SIGNATURE XOR KEYSTREAM 2506 where KEYSTREAM is derived as per Section 4.1.1. 2508 * The signature checker verifies the original countersignature 2509 SIGNATURE, by using the public key of the sender endpoint as 2510 included in that endpoint's authentication credential. The 2511 signature checker determines the right authentication credential 2512 based on the ID Context (Gid) and the Sender ID of the sender 2513 endpoint. 2515 Note that the following applies when attempting to verify the 2516 countersignature of a response message. 2518 * The response may not include a Partial IV and/or an ID Context. 2519 In such a case, the signature checker considers the same values 2520 from the corresponding request, i.e., the request matching with 2521 the response by CoAP Token value. 2523 * The response may not include a Sender ID. This can happen when 2524 the response protected in group mode matches a request protected 2525 in pairwise mode (see Section 9.1), with a case in point provided 2526 by [I-D.amsuess-core-cachable-oscore]. In such a case, the 2527 signature checker needs to use other means (e.g., source 2528 addressing information of the server endpoint) to identify the 2529 correct authentication credential including the public key to use 2530 for verifying the countersignature of the response. 2532 The particular actions following a successful or unsuccessful 2533 verification of the countersignature are application specific and out 2534 of the scope of this document. 2536 9. Message Processing in Pairwise Mode 2538 When using the pairwise mode of Group OSCORE, messages are protected 2539 and processed as in [RFC8613], with the modifications described in 2540 this section. The security objectives of the pairwise mode are 2541 discussed in Appendix A.2. 2543 The pairwise mode takes advantage of an existing Security Context for 2544 the group mode to establish a Security Context shared exclusively 2545 with any other member. In order to use the pairwise mode in a group 2546 that uses also the group mode, the signature scheme of the group mode 2547 MUST support a combined signature and encryption scheme. This can 2548 be, for example, signature using ECDSA, and encryption using AES-CCM 2549 with a key derived with ECDH. For encryption and decryption 2550 operations, the AEAD Algorithm from the Common Context is used (see 2551 Section 2.1.1). 2553 The pairwise mode does not support the use of additional entities 2554 acting as verifiers of source authentication and integrity of group 2555 messages, such as intermediary gateways (see Section 3). 2557 An endpoint implementing only a silent server does not support the 2558 pairwise mode. 2560 If the signature algorithm used in the group supports ECDH (e.g., 2561 ECDSA, EdDSA), the pairwise mode MUST be supported by endpoints that 2562 use the CoAP Echo Option [RFC9175] and/or block-wise transfers 2563 [RFC7959], for instance for responses after the first block-wise 2564 request, which possibly targets all servers in the group and includes 2565 the CoAP Block2 option (see Section 3.8 of 2567 [I-D.ietf-core-groupcomm-bis]). This prevents the attack described 2568 in Section 12.9, which leverages requests sent over unicast to a 2569 single group member and protected with the group mode. 2571 Senders cannot use the pairwise mode to protect a message intended 2572 for multiple recipients. In fact, the pairwise mode is defined only 2573 between two endpoints and the keying material is thus only available 2574 to one recipient. 2576 However, a sender can use the pairwise mode to protect a message sent 2577 to (but not intended for) multiple recipients, if interested in a 2578 response from only one of them. For instance, this is useful to 2579 support the address discovery service defined in Section 9.1, when a 2580 single 'kid' value is indicated in the payload of a request sent to 2581 multiple recipients, e.g., over multicast. 2583 The Group Manager indicates that the group uses (also) the pairwise 2584 mode, as part of the group data provided to candidate group members 2585 when joining the group. 2587 9.1. Pre-Conditions 2589 In order to protect an outgoing message in pairwise mode, the sender 2590 needs to know the authentication credential and the Recipient ID for 2591 the recipient endpoint, as stored in the Recipient Context associated 2592 with that endpoint (see Section 2.4.4). 2594 Furthermore, the sender needs to know the individual address of the 2595 recipient endpoint. This information may not be known at any given 2596 point in time. For instance, right after having joined the group, a 2597 client may know the authentication credential and Recipient ID for a 2598 given server, but not the addressing information required to reach it 2599 with an individual, one-to-one request. 2601 To make addressing information of individual endpoints available, 2602 servers in the group MAY expose a resource to which a client can send 2603 a group request targeting a set of servers, identified by their 'kid' 2604 values specified in the request payload. The specified set may be 2605 empty, hence identifying all the servers in the group. Further 2606 details of such an interface are out of scope for this document. 2608 9.2. Main Differences from OSCORE 2610 The pairwise mode protects messages between two members of a group, 2611 essentially following [RFC8613], but with the following notable 2612 differences. 2614 * The 'kid' and 'kid context' parameters of the COSE object are used 2615 as defined in Section 4.2 of this document. 2617 * The external_aad defined in Section 4.3 of this document is used 2618 for the encryption process. 2620 * The Pairwise Sender/Recipient Keys used as Sender/Recipient keys 2621 are derived as defined in Section 2.4 of this document. 2623 9.3. Protecting the Request 2625 When using the pairwise mode, the request is protected as defined in 2626 Section 8.1 of [RFC8613], with the differences summarized in 2627 Section 9.2 of this document. The following difference also applies. 2629 * If Observe [RFC7641] is supported, what is defined in 2630 Section 8.1.1 of this document holds. 2632 9.4. Verifying the Request 2634 Upon receiving a request with the Group Flag set to 0, following the 2635 procedure in Section 7, the server MUST process it as defined in 2636 Section 8.2 of [RFC8613], with the differences summarized in 2637 Section 9.2 of this document. The following differences also apply. 2639 * If the server discards the request due to not retrieving a 2640 Security Context associated with the OSCORE group or to not 2641 supporting the pairwise mode, the server MAY respond with a 4.01 2642 (Unauthorized) error message or a 4.02 (Bad Option) error message, 2643 respectively. When doing so, the server MAY set an Outer Max-Age 2644 option with value zero, and MAY include a descriptive string as 2645 diagnostic payload. 2647 * If a new Recipient Context is created for this Recipient ID, new 2648 Pairwise Sender/Recipient Keys are also derived (see 2649 Section 2.4.1). The new Pairwise Sender/Recipient Keys are 2650 deleted if the Recipient Context is deleted as a result of the 2651 message not being successfully verified. 2653 * If Observe [RFC7641] is supported, what is defined in 2654 Section 8.2.1 of this document holds. 2656 9.5. Protecting the Response 2658 When using the pairwise mode, a response is protected as defined in 2659 Section 8.3 of [RFC8613], with the differences summarized in 2660 Section 9.2 of this document. The following differences also apply. 2662 * If the server is using a different Security Context for the 2663 response compared to what was used to verify the request (see 2664 Section 3.2), then the server MUST include its Sender Sequence 2665 Number as Partial IV in the response and use it to build the AEAD 2666 nonce to protect the response. This prevents the AEAD nonce from 2667 the request from being reused. 2669 * If the server is using a different ID Context (Gid) for the 2670 response compared to what was used to verify the request (see 2671 Section 3.2), then the new ID Context MUST be included in the 'kid 2672 context' parameter of the response. 2674 * The server can obtain a new Sender ID from the Group Manager, when 2675 individually rekeyed (see Section 2.5.3.1) or when re-joining the 2676 group. In such a case, the server can help the client to 2677 synchronize, by including the 'kid' parameter in a response 2678 protected in pairwise mode, even when the request was also 2679 protected in pairwise mode. 2681 That is, when responding to a request protected in pairwise mode, 2682 the server SHOULD include the 'kid' parameter in a response 2683 protected in pairwise mode, if it is replying to that client for 2684 the first time since the assignment of its new Sender ID. 2686 * If Observe [RFC7641] is supported, what is defined in 2687 Section 8.3.1 of this document holds. 2689 9.6. Verifying the Response 2691 Upon receiving a response with the Group Flag set to 0, following the 2692 procedure in Section 7, the client MUST process it as defined in 2693 Section 8.4 of [RFC8613], with the differences summarized in 2694 Section 9.2 of this document. The following differences also apply. 2696 * The client may receive a response protected with a Security 2697 Context different from the one used to protect the corresponding 2698 request. Also, upon the establishment of a new Security Context, 2699 the client re-initializes its Replay Windows in its Recipient 2700 Contexts (see Section 2.2). 2702 * The same as described in Section 8.4 holds with respect to 2703 handling the 'kid' parameter of the response, when received as a 2704 reply to a request protected in pairwise mode. The client can 2705 also in this case check whether the replying server is the 2706 expected one, by relying on the server's public key. However, 2707 since the response is protected in pairwise mode, the public key 2708 is not used for verifying a countersignature as in Section 8.4. 2709 Instead, the expected server's authentication credential - namely 2710 Recipient Auth Cred and including the server's public key - was 2711 taken as input to derive the Pairwise Recipient Key used to 2712 decrypt and verify the response (see Section 2.4.1). 2714 * If a new Recipient Context is created for this Recipient ID, new 2715 Pairwise Sender/Recipient Keys are also derived (see 2716 Section 2.4.1). The new Pairwise Sender/Recipient Keys are 2717 deleted if the Recipient Context is deleted as a result of the 2718 message not being successfully verified. 2720 * If Observe [RFC7641] is supported, what is defined in 2721 Section 8.4.1 of this document holds. The client can also in this 2722 case identify a server to be the same one across a change of 2723 Sender ID, by relying on the server's public key. As to the 2724 expected server's authentication credential, the same holds as 2725 specified above for non-notification responses. 2727 10. Challenge-Response Synchronization 2729 This section describes how a server endpoint can synchronize with 2730 Sender Sequence Numbers of client endpoints in the group. Similarly 2731 to what is defined in Appendix B.1.2 of [RFC8613], the server 2732 performs a challenge-response exchange with a client, by using the 2733 Echo Option for CoAP specified in Section 2 of [RFC9175]. 2735 Upon receiving a request from a particular client for the first time, 2736 the server processes the message as described in this document, but, 2737 even if valid, does not deliver it to the application. Instead, the 2738 server replies to the client with an OSCORE protected 4.01 2739 (Unauthorized) response message, including only the Echo Option and 2740 no diagnostic payload. The Echo option value SHOULD NOT be reused; 2741 when it is reused, it MUST be highly unlikely to have been recently 2742 used with this client. Since this response is protected with the 2743 Security Context used in the group, the client will consider the 2744 response valid upon successfully decrypting and verifying it. 2746 The server stores the Echo Option value included in the response 2747 together with the pair (gid,kid), where 'gid' is the Group Identifier 2748 of the OSCORE group and 'kid' is the Sender ID of the client in the 2749 group. These are specified in the 'kid context' and 'kid' fields of 2750 the OSCORE Option of the request, respectively. After a group 2751 rekeying has been completed and a new Security Context has been 2752 established in the group, which results also in a new Group 2753 Identifier (see Section 3.2), the server MUST delete all the stored 2754 Echo values associated with members of the group. 2756 Upon receiving a 4.01 (Unauthorized) response that includes an Echo 2757 Option and originates from a verified group member, the client sends 2758 a request as a unicast message addressed to the same server, echoing 2759 the Echo Option value. The client MUST NOT send the request 2760 including the Echo Option over multicast. 2762 If the group uses also the group mode and the used Signature 2763 Algorithm supports ECDH (e.g., ECDSA, EdDSA), the client MUST use the 2764 pairwise mode to protect the request, as per Section 9.3. Note that, 2765 as defined in Section 9, endpoints that are members of such a group 2766 and that use the Echo Option MUST support the pairwise mode. 2768 The client does not necessarily resend the same group request, but 2769 can instead send a more recent one, if the application permits it. 2770 This allows the client to not retain previously sent group requests 2771 for full retransmission, unless the application explicitly requires 2772 otherwise. In either case, the client uses a fresh Sender Sequence 2773 Number value from its own Sender Context. If the client stores group 2774 requests for possible retransmission with the Echo Option, it should 2775 not store a given request for longer than a preconfigured time 2776 interval. Note that the unicast request echoing the Echo Option is 2777 correctly treated and processed, since the 'kid context' field 2778 including the Group Identifier of the OSCORE group is still present 2779 in the OSCORE Option as part of the COSE object (see Section 4). 2781 Upon receiving the unicast request including the Echo Option, the 2782 server performs the following verifications. 2784 * If the server does not store an Echo Option value for the pair 2785 (gid,kid), it considers: i) the time t1 when it has established 2786 the Security Context used to protect the received request; and ii) 2787 the time t2 when the request has been received. Since a valid 2788 request cannot be older than the Security Context used to protect 2789 it, the server verifies that (t2 - t1) is less than the largest 2790 amount of time acceptable to consider the request fresh. 2792 * If the server stores an Echo Option value for the pair (gid,kid) 2793 associated with that same client in the same group, the server 2794 verifies that the option value equals that same stored value 2795 previously sent to that client. 2797 If the verifications above fail, the server MUST NOT process the 2798 request further and MAY send a 4.01 (Unauthorized) response including 2799 an Echo Option, hence performing a new challenge-response exchange. 2801 If the verifications above are successful, the server proceeds as 2802 follows. In case the Replay Window in the Recipient Context 2803 associated with the client has not been set yet, the server updates 2804 the Replay Window to mark the current Sender Sequence Number from the 2805 latest received request as seen (but all newer ones as new), and 2806 delivers the message as fresh to the application. Otherwise, the 2807 server discards the verification result and treats the message as 2808 fresh or as a replay, according to the existing Replay Window. 2810 A server should not deliver requests from a given client to the 2811 application until one valid request from that same client has been 2812 verified as fresh, as conveying an echoed Echo Option. A server may 2813 perform the challenge-response described above at any time, if 2814 synchronization with Sender Sequence Numbers of clients is lost, 2815 e.g., after a device reboot. A client has to be ready to perform the 2816 challenge-response based on the Echo Option if a server starts it. 2818 It is the role of the server application to define under what 2819 circumstances Sender Sequence Numbers lose synchronization. This can 2820 include experiencing a "large enough" gap D = (SN2 - SN1), between 2821 the Sender Sequence Number SN1 of the latest accepted group request 2822 from a client and the Sender Sequence Number SN2 of a group request 2823 just received from that client. However, a client may send several 2824 unicast requests to different group members as protected with the 2825 pairwise mode, which may result in the server experiencing the gap D 2826 in a relatively short time. This would induce the server to perform 2827 more challenge-response exchanges than actually needed. 2829 In order to ameliorate this, the server may rely on a trade-off 2830 between the Sender Sequence Number gap D and a time gap T = (t2 - 2831 t1), where t1 is the time when the latest group request from a client 2832 was accepted and t2 is the time when the latest group request from 2833 that client has been received, respectively. Then, the server can 2834 start a challenge-response when experiencing a time gap T larger than 2835 a given, preconfigured threshold. Also, the server can start a 2836 challenge-response when experiencing a Sender Sequence Number gap D 2837 greater than a different threshold, computed as a monotonically 2838 increasing function of the currently experienced time gap T. 2840 The challenge-response approach described in this section provides an 2841 assurance of absolute message freshness. However, it can result in 2842 an impact on performance which is undesirable or unbearable, 2843 especially in large groups where many endpoints at the same time 2844 might join as new members or lose synchronization. 2846 Endpoints configured as silent servers are not able to perform the 2847 challenge-response described above, as they do not store a Sender 2848 Context to secure the 4.01 (Unauthorized) response to the client. 2849 Thus, silent servers should adopt alternative approaches to achieve 2850 and maintain synchronization with Sender Sequence Numbers of clients. 2852 Since requests including the Echo Option are sent over unicast, a 2853 server can be victim of the attack discussed in Section 12.9, in case 2854 such requests are protected with the group mode. Instead, protecting 2855 those requests with the pairwise mode prevents the attack above. In 2856 fact, only the exact server involved in the challenge-response 2857 exchange is able to derive the pairwise key used by the client to 2858 protect the request including the Echo Option. 2860 In either case, an internal on-path adversary would not be able to 2861 mix up the Echo Option value of two different unicast requests, sent 2862 by a same client to any two different servers in the group. In fact, 2863 even if the group mode was used, this would require the adversary to 2864 forge the countersignature of both requests. As a consequence, each 2865 of the two servers remains able to selectively accept a request with 2866 the Echo Option only if it is waiting for that exact integrity- 2867 protected Echo Option value, and is thus the intended recipient. 2869 11. Implementation Compliance 2871 Like in [RFC8613], HKDF SHA-256 is the mandatory to implement HKDF. 2873 An endpoint may support only the group mode, or only the pairwise 2874 mode, or both. 2876 For endpoints that support the group mode, the following applies. 2878 * For endpoints that use authenticated encryption, the AEAD 2879 algorithm AES-CCM-16-64-128 defined in Section 4.2 of 2880 [I-D.ietf-cose-rfc8152bis-algs] is mandatory to implement as 2881 Signature Encryption Algorithm (see Section 2.1.4). 2883 * For many constrained IoT devices it is problematic to support more 2884 than one signature algorithm. Existing devices can be expected to 2885 support either EdDSA or ECDSA. In order to enable as much 2886 interoperability as we can reasonably achieve, the following 2887 applies with respect to the Signature Algorithm (see 2888 Section 2.1.5). 2890 Less constrained endpoints SHOULD implement both: the EdDSA 2891 signature algorithm together with the elliptic curve Ed25519 2892 [RFC8032]; and the ECDSA signature algorithm together with the 2893 elliptic curve P-256. 2895 Constrained endpoints SHOULD implement: the EdDSA signature 2896 algorithm together with the elliptic curve Ed25519 [RFC8032]; or 2897 the ECDSA signature algorithm together with the elliptic curve 2898 P-256. 2900 * Endpoints that implement the ECDSA signature algorithm MAY use 2901 "deterministic ECDSA" as specified in [RFC6979]. Pure 2902 deterministic elliptic-curve signature algorithms such as 2903 deterministic ECDSA and EdDSA have the advantage of not requiring 2904 access to a source of high-quality randomness. However, these 2905 signature algorithms have been shown vulnerable to some side- 2906 channel and fault injection attacks due to their determinism, 2907 which can result in extracting a device's private key. As 2908 suggested in Section 2.1.1 of [I-D.ietf-cose-rfc8152bis-algs], 2909 this can be addressed by combining both randomness and determinism 2910 [I-D.mattsson-cfrg-det-sigs-with-noise]. 2912 For endpoints that support the pairwise mode, the following applies. 2914 * The AEAD algorithm AES-CCM-16-64-128 defined in Section 4.2 of 2915 [I-D.ietf-cose-rfc8152bis-algs] is mandatory to implement as AEAD 2916 Algorithm (see Section 2.1.1). 2918 * The ECDH-SS + HKDF-256 algorithm specified in Section 6.3.1 of 2919 [I-D.ietf-cose-rfc8152bis-algs] is mandatory to implement as 2920 Pairwise Key Agreement Algorithm (see Section 2.1.7). 2922 * In order to enable as much interoperability as we can reasonably 2923 achieve in the presence of constrained devices (see above), the 2924 following applies. 2926 Less constrained endpoints SHOULD implement both the X25519 curve 2927 [RFC7748] and the P-256 curve as ECDH curves. 2929 Constrained endpoints SHOULD implement the X25519 curve [RFC7748] 2930 or the P-256 curve as ECDH curve. 2932 Constrained IoT devices may alternatively represent Montgomery curves 2933 and (twisted) Edwards curves [RFC7748] in the short-Weierstrass form 2934 Wei25519, with which the algorithms ECDSA25519 and ECDH25519 can be 2935 used for signature operations and Diffie-Hellman secret calculation, 2936 respectively [I-D.ietf-lwig-curve-representations]. 2938 12. Security Considerations 2940 The same threat model discussed for OSCORE in Appendix D.1 of 2941 [RFC8613] holds for Group OSCORE. In addition, when using the group 2942 mode, source authentication of messages is explicitly ensured by 2943 means of countersignatures, as discussed in Section 12.1. 2945 Note that, even if an endpoint is authorized to be a group member and 2946 to take part in group communications, there is a risk that it behaves 2947 inappropriately. For instance, it can forward the content of 2948 messages in the group to unauthorized entities. However, in many use 2949 cases, the devices in the group belong to a common authority and are 2950 configured by a commissioner (see Appendix B), which results in a 2951 practically limited risk and enables a prompt detection/reaction in 2952 case of misbehaving. 2954 The same considerations on supporting Proxy operations discussed for 2955 OSCORE in Appendix D.2 of [RFC8613] hold for Group OSCORE. 2957 The same considerations on protected message fields for OSCORE 2958 discussed in Appendix D.3 of [RFC8613] hold for Group OSCORE. 2960 The same considerations on uniqueness of (key, nonce) pairs for 2961 OSCORE discussed in Appendix D.4 of [RFC8613] hold for Group OSCORE. 2962 This is further discussed in Section 12.3 of this document. 2964 The same considerations on unprotected message fields for OSCORE 2965 discussed in Appendix D.5 of [RFC8613] hold for Group OSCORE, with 2966 the following differences. First, the 'kid context' of request 2967 messages is part of the Additional Authenticated Data, thus safely 2968 enabling to keep observations active beyond a possible change of ID 2969 Context (Gid), following a group rekeying (see Section 4.3). Second, 2970 the countersignature included in a Group OSCORE message protected in 2971 group mode is computed also over the value of the OSCORE option, 2972 which is also part of the Additional Authenticated Data used in the 2973 signing process. This is further discussed in Section 12.7 of this 2974 document. 2976 As discussed in Section 6.2.3 of [I-D.ietf-core-groupcomm-bis], Group 2977 OSCORE addresses security attacks against CoAP listed in Sections 2978 11.2-11.6 of [RFC7252], especially when run over IP multicast. 2980 The rest of this section first discusses security aspects to be taken 2981 into account when using Group OSCORE. Then it goes through aspects 2982 covered in the security considerations of OSCORE (see Section 12 of 2983 [RFC8613]), and discusses how they hold when Group OSCORE is used. 2985 12.1. Security of the Group Mode 2987 The group mode defined in Section 8 relies on commonly shared group 2988 keying material to protect communication within a group. Using the 2989 group mode has the implications discussed below. The following 2990 refers to group members as the endpoints in the group storing the 2991 latest version of the group keying material. 2993 * Messages are encrypted at a group level (group-level data 2994 confidentiality), i.e., they can be decrypted by any member of the 2995 group, but not by an external adversary or other external 2996 entities. 2998 * If the used encryption algorithm provides integrity protection, 2999 then it also ensures group authentication and proof of group 3000 membership, but not source authentication. That is, it ensures 3001 that a message sent to a group has been sent by a member of that 3002 group, but not necessarily by the alleged sender. In fact, any 3003 group member is able to derive the Sender Key used by the actual 3004 sender endpoint, and thus can compute a valid authentication tag. 3005 Therefore, the message content could originate from any of the 3006 current group members. 3008 Furthermore, if the used encryption algorithm does not provide 3009 integrity protection, then it does not ensure any level of message 3010 authentication or proof of group membership. 3012 On the other hand, proof of group membership is always ensured by 3013 construction through the strict management of the group keying 3014 material (see Section 3.2). That is, the group is rekeyed in case 3015 of members' leaving, and the current group members are informed of 3016 former group members. Thus, a current group member storing the 3017 latest group keying material does not store the authentication 3018 credential of any former group member. 3020 This allows a recipient endpoint to rely on the stored 3021 authentication credentials and public keys included therin, in 3022 order to always confidently assert the group membership of a 3023 sender endpoint when processing an incoming message, i.e., to 3024 assert that the sender endpoint was a group member when it signed 3025 the message. In turn, this prevents a former group member to 3026 possibly re-sign and inject in the group a stored message that was 3027 protected with old keying material. 3029 * Source authentication of messages sent to a group is ensured 3030 through a countersignature, which is computed by the sender using 3031 its own private key and then appended to the message payload. 3032 Also, the countersignature is encrypted by using a keystream 3033 derived from the group keying material (see Section 4.1). This 3034 ensures group privacy, i.e., an attacker cannot track an endpoint 3035 over two groups by linking messages between the two groups, unless 3036 being also a member of those groups. 3038 The security properties of the group mode are summarized below. 3040 1. Asymmetric source authentication, by means of a countersignature. 3042 2. Symmetric group authentication, by means of an authentication tag 3043 (only for encryption algorithms providing integrity protection). 3045 3. Symmetric group confidentiality, by means of symmetric 3046 encryption. 3048 4. Proof of group membership, by strictly managing the group keying 3049 material, as well as by means of integrity tags when using an 3050 encryption algorithm that provides also integrity protection. 3052 5. Group privacy, by encrypting the countersignature. 3054 The group mode fulfills the security properties above while also 3055 displaying the following benefits. First, the use of an encryption 3056 algorithm that does not provide integrity protection results in a 3057 minimal communication overhead, by limiting the message payload to 3058 the ciphertext and the encrypted countersignature. Second, it is 3059 possible to deploy semi-trusted entities such as signature checkers 3060 (see Section 3.1), which can break property 5, but cannot break 3061 properties 1, 2 and 3. 3063 12.2. Security of the Pairwise Mode 3065 The pairwise mode defined in Section 9 protects messages by using 3066 pairwise symmetric keys, derived from the static-static Diffie- 3067 Hellman shared secret computed from the asymmetric keys of the sender 3068 and recipient endpoint (see Section 2.4). 3070 The used encryption algorithm MUST provide integrity protection. 3071 Therefore, the pairwise mode ensures both pairwise data- 3072 confidentiality and source authentication of messages, without using 3073 countersignatures. Furthermore, the recipient endpoint achieves 3074 proof of group membership for the sender endpoint, since only current 3075 group members have the required keying material to derive a valid 3076 Pairwise Sender/Recipient Key. 3078 The long-term storing of the Diffie-Hellman shared secret is a 3079 potential security issue. In fact, if the shared secret of two group 3080 members is leaked, a third group member can exploit it to impersonate 3081 any of those two group members, by deriving and using their pairwise 3082 key. The possibility of such leakage should be contemplated, as more 3083 likely to happen than the leakage of a private key, which could be 3084 rather protected at a significantly higher level than generic memory, 3085 e.g., by using a Trusted Platform Module. Therefore, there is a 3086 trade-off between the maximum amount of time a same shared secret is 3087 stored and the frequency of its re-computing. 3089 12.3. Uniqueness of (key, nonce) 3091 The proof for uniqueness of (key, nonce) pairs in Appendix D.4 of 3092 [RFC8613] is also valid in group communication scenarios. That is, 3093 given an OSCORE group: 3095 * Uniqueness of Sender IDs within the group is enforced by the Group 3096 Manager. In fact, from the moment when a Gid is assigned to a 3097 group until the moment a new Gid is assigned to that same group, 3098 the Group Manager does not reassign a Sender ID within the group 3099 (see Section 3.2). 3101 * The case A in Appendix D.4 of [RFC8613] concerns all group 3102 requests and responses including a Partial IV (e.g., Observe 3103 notifications). In this case, same considerations from [RFC8613] 3104 apply here as well. 3106 * The case B in Appendix D.4 of [RFC8613] concerns responses not 3107 including a Partial IV (e.g., single response to a group request). 3108 In this case, same considerations from [RFC8613] apply here as 3109 well. 3111 As a consequence, each message encrypted/decrypted with the same 3112 Sender Key is processed by using a different (ID_PIV, PIV) pair. 3113 This means that nonces used by any fixed encrypting endpoint are 3114 unique. Thus, each message is processed with a different (key, 3115 nonce) pair. 3117 12.4. Management of Group Keying Material 3119 The approach described in this document should take into account the 3120 risk of compromise of group members. In particular, this document 3121 specifies that a key management scheme for secure revocation and 3122 renewal of Security Contexts and group keying material MUST be 3123 adopted. 3125 [I-D.ietf-ace-key-groupcomm-oscore] specifies a simple rekeying 3126 scheme for renewing the Security Context in a group. 3128 Alternative rekeying schemes which are more scalable with the group 3129 size may be needed in dynamic, large groups where endpoints can join 3130 and leave at any time, in order to limit the impact on performance 3131 due to the Security Context and keying material update. 3133 12.5. Update of Security Context and Key Rotation 3135 A group member can receive a message shortly after the group has been 3136 rekeyed, and new security parameters and keying material have been 3137 distributed by the Group Manager. 3139 This may result in a client using an old Security Context to protect 3140 a request, and a server using a different new Security Context to 3141 protect a corresponding response. As a consequence, clients may 3142 receive a response protected with a Security Context different from 3143 the one used to protect the corresponding request. 3145 In particular, a server may first get a request protected with the 3146 old Security Context, then install the new Security Context, and only 3147 after that produce a response to send back to the client. In such a 3148 case, as specified in Section 8.3, the server MUST protect the 3149 potential response using the new Security Context. Specifically, the 3150 server MUST include its Sender Sequence Number as Partial IV in the 3151 response and use it to build the AEAD nonce to protect the response. 3152 This prevents the AEAD nonce from the request from being reused with 3153 the new Security Context. 3155 The client will process that response using the new Security Context, 3156 provided that it has installed the new security parameters and keying 3157 material before the message processing. 3159 In case block-wise transfer [RFC7959] is used, the same 3160 considerations from Section 10.3 of [I-D.ietf-ace-key-groupcomm] 3161 hold. 3163 Furthermore, as described below, a group rekeying may temporarily 3164 result in misaligned Security Contexts between the sender and 3165 recipient of a same message. 3167 12.5.1. Late Update on the Sender 3169 In this case, the sender protects a message using the old Security 3170 Context, i.e., before having installed the new Security Context. 3171 However, the recipient receives the message after having installed 3172 the new Security Context, and is thus unable to correctly process it. 3174 A possible way to ameliorate this issue is to preserve the old, 3175 recent, Security Context for a maximum amount of time defined by the 3176 application. By doing so, the recipient can still try to process the 3177 received message using the old retained Security Context as a second 3178 attempt. This makes particular sense when the recipient is a client, 3179 that would hence be able to process incoming responses protected with 3180 the old, recent, Security Context used to protect the associated 3181 group request. Instead, a recipient server would better and more 3182 simply discard an incoming group request which is not successfully 3183 processed with the new Security Context. 3185 This tolerance preserves the processing of secure messages throughout 3186 a long-lasting key rotation, as group rekeying processes may likely 3187 take a long time to complete, especially in large groups. On the 3188 other hand, a former (compromised) group member can abusively take 3189 advantage of this, and send messages protected with the old retained 3190 Security Context. Therefore, a conservative application policy 3191 should not admit the retention of old Security Contexts. 3193 12.5.2. Late Update on the Recipient 3195 In this case, the sender protects a message using the new Security 3196 Context, but the recipient receives that message before having 3197 installed the new Security Context. Therefore, the recipient would 3198 not be able to correctly process the message and hence discards it. 3200 If the recipient installs the new Security Context shortly after that 3201 and the sender endpoint retransmits the message, the former will 3202 still be able to receive and correctly process the message. 3204 In any case, the recipient should actively ask the Group Manager for 3205 an updated Security Context according to an application-defined 3206 policy, for instance after a given number of unsuccessfully decrypted 3207 incoming messages. 3209 12.6. Collision of Group Identifiers 3211 In case endpoints are deployed in multiple groups managed by 3212 different non-synchronized Group Managers, it is possible for Group 3213 Identifiers of different groups to coincide. 3215 This does not impair the security of the AEAD algorithm. In fact, as 3216 long as the Master Secret is different for different groups and this 3217 condition holds over time, AEAD keys are different among different 3218 groups. 3220 In case multiple groups use the same IP multicast address, the entity 3221 assigning that address may help limiting the chances to experience 3222 such collisions of Group Identifiers. In particular, it may allow 3223 the Group Managers of those groups using the same IP multicast 3224 address to share their respective list of assigned Group Identifiers 3225 currently in use. 3227 12.7. Cross-group Message Injection 3229 A same endpoint is allowed to and would likely use the same pair 3230 (private key, authentication credential) in multiple OSCORE groups, 3231 possibly administered by different Group Managers. 3233 When a sender endpoint sends a message protected in pairwise mode to 3234 a recipient endpoint in an OSCORE group, a malicious group member may 3235 attempt to inject the message to a different OSCORE group also 3236 including the same endpoints (see Section 12.7.1). 3238 This practically relies on altering the content of the OSCORE option, 3239 and having the same MAC in the ciphertext still correctly validating, 3240 which has a success probability depending on the size of the MAC. 3242 As discussed in Section 12.7.2, the attack is practically infeasible 3243 if the message is protected in group mode, thanks to the 3244 countersignature also bound to the OSCORE option through the 3245 Additional Authenticated Data used in the signing process (see 3246 Section 4.3). 3248 12.7.1. Attack Description 3250 Let us consider: 3252 * Two OSCORE groups G1 and G2, with ID Context (Group ID) Gid1 and 3253 Gid2, respectively. Both G1 and G2 use the AEAD cipher AES-CCM- 3254 16-64-128, i.e., the MAC of the ciphertext is 8 bytes in size. 3256 * A sender endpoint X which is member of both G1 and G2, and uses 3257 the same pair (private key, authentication credential) in both 3258 groups. The endpoint X has Sender ID Sid1 in G1 and Sender ID 3259 Sid2 in G2. The pairs (Sid1, Gid1) and (Sid2, Gid2) identify the 3260 same authentication credential of X in G1 and G2, respectively. 3262 * A recipient endpoint Y which is member of both G1 and G2, and uses 3263 the same pair (private key, authentication credential) in both 3264 groups. The endpoint Y has Sender ID Sid3 in G1 and Sender ID 3265 Sid4 in G2. The pairs (Sid3, Gid1) and (Sid4, Gid2) identify the 3266 same authentication credential of Y in G1 and G2, respectively. 3268 * A malicious endpoint Z is also member of both G1 and G2. Hence, Z 3269 is able to derive the Sender Keys used by X in G1 and G2. 3271 When X sends a message M1 addressed to Y in G1 and protected in 3272 pairwise mode, Z can intercept M1, and attempt to forge a valid 3273 message M2 to be injected in G2, making it appear as still sent by X 3274 to Y and valid to be accepted. 3276 More in detail, Z intercepts and stops message M1, and forges a 3277 message M2 by changing the value of the OSCORE option from M1 as 3278 follows: the 'kid context' is set to G2 (rather than G1); and the 3279 'kid' is set to Sid2 (rather than Sid1). Then, Z injects message M2 3280 as addressed to Y in G2. 3282 Upon receiving M2, there is a probability equal to 2^-64 that Y 3283 successfully verifies the same unchanged MAC by using the Pairwise 3284 Recipient Key associated with X in G2. 3286 Note that Z does not know the pairwise keys of X and Y, since it does 3287 not know and is not able to compute their shared Diffie-Hellman 3288 secret. Therefore, Z is not able to check offline if a performed 3289 forgery is actually valid, before sending the forged message to G2. 3291 12.7.2. Attack Prevention in Group Mode 3293 When a Group OSCORE message is protected with the group mode, the 3294 countersignature is computed also over the value of the OSCORE 3295 option, which is part of the Additional Authenticated Data used in 3296 the signing process (see Section 4.3). 3298 That is, other than over the ciphertext, the countersignature is 3299 computed over: the ID Context (Gid) and the Partial IV, which are 3300 always present in group requests; as well as the Sender ID of the 3301 message originator, which is always present in group requests as well 3302 as in responses to requests protected in group mode. 3304 Since the signing process takes as input also the ciphertext of the 3305 COSE_Encrypt0 object, the countersignature is bound not only to the 3306 intended OSCORE group, hence to the triplet (Master Secret, Master 3307 Salt, ID Context), but also to a specific Sender ID in that group and 3308 to its specific symmetric key used for AEAD encryption, hence to the 3309 quartet (Master Secret, Master Salt, ID Context, Sender ID). 3311 This makes it practically infeasible to perform the attack described 3312 in Section 12.7.1, since it would require the adversary to 3313 additionally forge a valid countersignature that replaces the 3314 original one in the forged message M2. 3316 If, hypothetically, the countersignature did not cover the OSCORE 3317 option: 3319 * The attack described in Section 12.7.1 would still be possible 3320 against response messages protected in group mode, since the same 3321 unchanged countersignature from message M1 would be also valid in 3322 message M2. 3324 * A simplification would also be possible in performing the attack, 3325 since Z is able to derive the Sender/Recipient Keys of X and Y in 3326 G1 and G2. That is, Z can also set a convenient Partial IV in the 3327 response, until the same unchanged MAC is successfully verified by 3328 using G2 as 'request_kid_context', Sid2 as 'request_kid', and the 3329 symmetric key associated with X in G2. 3331 Since the Partial IV is 5 bytes in size, this requires 2^40 3332 operations to test all the Partial IVs, which can be done in real- 3333 time. The probability that a single given message M1 can be used 3334 to forge a response M2 for a given request would be equal to 2^- 3335 24, since there are more MAC values (8 bytes in size) than Partial 3336 IV values (5 bytes in size). 3338 Note that, by changing the Partial IV as discussed above, any 3339 member of G1 would also be able to forge a valid signed response 3340 message M2 to be injected in the same group G1. 3342 12.8. Prevention of Group Cloning Attack 3344 Both when using the group mode and the pairwise mode, the message 3345 protection covers also the Group Manager's authentication credential. 3346 This is included in the Additional Authenticated Data used in the 3347 signing process and/or in the integrity-protected encryption process 3348 (see Section 4.3). 3350 By doing so, an endpoint X member of a group G1 cannot perform the 3351 following attack. 3353 1. X sets up a group G2 where it acts as Group Manager. 3355 2. X makes G2 a "clone" of G1, i.e., G1 and G2 use the same 3356 algorithms and have the same Master Secret, Master Salt and ID 3357 Context. 3359 3. X collects a message M sent to G1 and injects it in G2. 3361 4. Members of G2 accept M and believe it to be originated in G2. 3363 The attack above is effectively prevented, since message M is 3364 protected by including the authentication credential of G1's Group 3365 Manager in the Additional Authenticated Data. Therefore, members of 3366 G2 do not successfully verify and decrypt M, since they correctly use 3367 the authentication credential of X as Group Manager of G2 when 3368 attempting to. 3370 12.9. Group OSCORE for Unicast Requests 3372 If a request is intended to be sent over unicast as addressed to a 3373 single group member, it is NOT RECOMMENDED for the client to protect 3374 the request by using the group mode as defined in Section 8.1. 3376 This does not include the case where the client sends a request over 3377 unicast to a proxy, to be forwarded to multiple intended recipients 3378 over multicast [I-D.ietf-core-groupcomm-bis]. In this case, the 3379 client MUST protect the request with the group mode, even though it 3380 is sent to the proxy over unicast (see Section 8). 3382 If the client uses the group mode with its own Sender Key to protect 3383 a unicast request to a group member, an on-path adversary can, right 3384 then or later on, redirect that request to one/many different group 3385 member(s) over unicast, or to the whole OSCORE group over multicast. 3386 By doing so, the adversary can induce the target group member(s) to 3387 perform actions intended for one group member only. Note that the 3388 adversary can be external, i.e., (s)he does not need to also be a 3389 member of the OSCORE group. 3391 This is due to the fact that the client is not able to indicate the 3392 single intended recipient in a way which is secure and possible to 3393 process for Group OSCORE on the server side. In particular, Group 3394 OSCORE does not protect network addressing information such as the IP 3395 address of the intended recipient server. It follows that the 3396 server(s) receiving the redirected request cannot assert whether that 3397 was the original intention of the client, and would thus simply 3398 assume so. 3400 The impact of such an attack depends especially on the REST method of 3401 the request, i.e., the Inner CoAP Code of the OSCORE request message. 3402 In particular, safe methods such as GET and FETCH would trigger 3403 (several) unintended responses from the targeted server(s), while not 3404 resulting in destructive behavior. On the other hand, non safe 3405 methods such as PUT, POST and PATCH/iPATCH would result in the target 3406 server(s) taking active actions on their resources and possible 3407 cyber-physical environment, with the risk of destructive consequences 3408 and possible implications for safety. 3410 A client can instead use the pairwise mode as defined in Section 9.3, 3411 in order to protect a request sent to a single group member by using 3412 pairwise keying material (see Section 2.4). This prevents the attack 3413 discussed above by construction, as only the intended server is able 3414 to derive the pairwise keying material used by the client to protect 3415 the request. A client supporting the pairwise mode SHOULD use it to 3416 protect requests sent to a single group member over unicast, instead 3417 of using the group mode. For an example where this is not fulfilled, 3418 see Section 7.2.1 of [I-D.ietf-core-observe-multicast-notifications]. 3420 With particular reference to block-wise transfers [RFC7959], 3421 Section 3.8 of [I-D.ietf-core-groupcomm-bis] points out that, while 3422 an initial request including the CoAP Block2 option can be sent over 3423 multicast, any other request in a transfer has to occur over unicast, 3424 individually addressing the servers in the group. 3426 Additional considerations are discussed in Section 10, with respect 3427 to requests including a CoAP Echo Option [RFC9175] that have to be 3428 sent over unicast, as a challenge-response method for servers to 3429 achieve synchronization of clients' Sender Sequence Number. 3431 12.10. End-to-end Protection 3433 The same considerations from Section 12.1 of [RFC8613] hold for Group 3434 OSCORE. 3436 Additionally, (D)TLS and Group OSCORE can be combined for protecting 3437 message exchanges occurring over unicast. However, it is not 3438 possible to combine (D)TLS and Group OSCORE for protecting message 3439 exchanges where messages are (also) sent over multicast. 3441 12.11. Master Secret 3443 Group OSCORE derives the Security Context using the same construction 3444 as OSCORE, and by using the Group Identifier of a group as the 3445 related ID Context. Hence, the same required properties of the 3446 Security Context parameters discussed in Section 3.3 of [RFC8613] 3447 hold for this document. 3449 With particular reference to the OSCORE Master Secret, it has to be 3450 kept secret among the members of the respective OSCORE group and the 3451 Group Manager responsible for that group. Also, the Master Secret 3452 must have a good amount of randomness, and the Group Manager can 3453 generate it offline using a good random number generator. This 3454 includes the case where the Group Manager rekeys the group by 3455 generating and distributing a new Master Secret. Randomness 3456 requirements for security are described in [RFC4086]. 3458 12.12. Replay Protection 3460 As in OSCORE [RFC8613], also Group OSCORE relies on Sender Sequence 3461 Numbers included in the COSE message field 'Partial IV' and used to 3462 build AEAD nonces. 3464 Note that the Partial IV of an endpoint does not necessarily grow 3465 monotonically. For instance, upon exhaustion of the endpoint Sender 3466 Sequence Number, the Partial IV also gets exhausted. As discussed in 3467 Section 2.5.3, this results either in the endpoint being individually 3468 rekeyed and getting a new Sender ID, or in the establishment of a new 3469 Security Context in the group. Therefore, uniqueness of (key, nonce) 3470 pairs (see Section 12.3) is preserved also when a new Security 3471 Context is established. 3473 Since one-to-many communication such as multicast usually involves 3474 unreliable transports, the simplification of the Replay Window to a 3475 size of 1 suggested in Section 7.4 of [RFC8613] is not viable with 3476 Group OSCORE, unless exchanges in the group rely only on unicast 3477 messages. 3479 As discussed in Section 6.2, a Replay Window may be initialized as 3480 not valid, following the loss of mutable Security Context 3481 Section 2.5.1. In particular, Section 2.5.1.1 and Section 2.5.1.2 3482 define measures that endpoints need to take in such a situation, 3483 before resuming to accept incoming messages from other group members. 3485 12.13. Message Freshness 3487 As discussed in Section 6.3, a server may not be able to assert 3488 whether an incoming request is fresh, in case it does not have or has 3489 lost synchronization with the client's Sender Sequence Number. 3491 If freshness is relevant for the application, the server may 3492 (re-)synchronize with the client's Sender Sequence Number at any 3493 time, by using the approach described in Section 10 and based on the 3494 CoAP Echo Option [RFC9175], as a variant of the approach defined in 3495 Appendix B.1.2 of [RFC8613] applicable to Group OSCORE. 3497 12.14. Client Aliveness 3499 Building on Section 12.5 of [RFC8613], a server may use the CoAP Echo 3500 Option [RFC9175] to verify the aliveness of the client that 3501 originated a received request, by using the approach described in 3502 Section 10 of this document. 3504 12.15. Cryptographic Considerations 3506 The same considerations from Section 12.6 of [RFC8613] about the 3507 maximum Sender Sequence Number hold for Group OSCORE. 3509 As discussed in Section 2.5.2, an endpoint that experiences an 3510 exhaustion of its own Sender Sequence Numbers MUST NOT protect 3511 further messages including a Partial IV, until it has derived a new 3512 Sender Context. This prevents the endpoint to reuse the same AEAD 3513 nonces with the same Sender Key. 3515 In order to renew its own Sender Context, the endpoint SHOULD inform 3516 the Group Manager, which can either renew the whole Security Context 3517 by means of group rekeying, or provide only that endpoint with a new 3518 Sender ID value. In either case, the endpoint derives a new Sender 3519 Context, and in particular a new Sender Key. 3521 Additionally, the same considerations from Section 12.6 of [RFC8613] 3522 hold for Group OSCORE, about building the AEAD nonce and the secrecy 3523 of the Security Context parameters. 3525 The group mode uses the "encrypt-then-sign" construction, i.e., the 3526 countersignature is computed over the COSE_Encrypt0 object (see 3527 Section 4.1). This is motivated by enabling additional entities 3528 acting as signature checkers (see Section 3.1), which do not join a 3529 group as members but are allowed to verify countersignatures of 3530 messages protected in group mode without being able to decrypt them 3531 (see Section 8.5). 3533 If the encryption algorithm used in group mode provides integrity 3534 protection, countersignatures of COSE_Encrypt0 with short 3535 authentication tags do not provide the security properties associated 3536 with the same algorithm used in COSE_Sign (see Section 6 of 3537 [I-D.ietf-cose-countersign]). To provide 128-bit security against 3538 collision attacks, the tag length MUST be at least 256-bits. A 3539 countersignature of a COSE_Encrypt0 with AES-CCM-16-64-128 provides 3540 at most 32 bits of integrity protection. 3542 The derivation of pairwise keys defined in Section 2.4.1 is 3543 compatible with ECDSA and EdDSA asymmetric keys, but is not 3544 compatible with RSA asymmetric keys. 3546 For the public key translation from Ed25519 (Ed448) to X25519 (X448) 3547 specified in Section 2.4.1, variable time methods can be used since 3548 the translation operates on public information. Any byte string of 3549 appropriate length is accepted as a public key for X25519 (X448) in 3550 [RFC7748]. It is therefore not necessary for security to validate 3551 the translated public key (assuming the translation was successful). 3553 The security of using the same key pair for Diffie-Hellman and for 3554 signing (by considering the ECDH procedure in Section 2.4 as a Key 3555 Encapsulation Mechanism (KEM)) is demonstrated in [Degabriele] and 3556 [Thormarker]. 3558 Applications using ECDH (except X25519 and X448) based KEM in 3559 Section 2.4 are assumed to verify that a peer endpoint's public key 3560 is on the expected curve and that the shared secret is not the point 3561 at infinity. The KEM in [Degabriele] checks that the shared secret 3562 is different from the point at infinity, as does the procedure in 3563 Section 5.7.1.2 of [NIST-800-56A] which is referenced in Section 2.4. 3565 Extending Theorem 2 of [Degabriele], [Thormarker] shows that the same 3566 key pair can be used with X25519 and Ed25519 (X448 and Ed448) for the 3567 KEM specified in Section 2.4. By symmetry in the KEM used in this 3568 document, both endpoints can consider themselves to have the 3569 recipient role in the KEM - as discussed in Section 7 of [Thormarker] 3570 - and rely on the mentioned proofs for the security of their key 3571 pairs. 3573 Theorem 3 in [Degabriele] shows that the same key pair can be used 3574 for an ECDH based KEM and ECDSA. The KEM uses a different KDF than 3575 in Section 2.4, but the proof only depends on that the KDF has 3576 certain required properties, which are the typical assumptions about 3577 HKDF, e.g., that output keys are pseudorandom. In order to comply 3578 with the assumptions of Theorem 3, received public keys MUST be 3579 successfully validated, see Section 5.6.2.3.4 of [NIST-800-56A]. The 3580 validation MAY be performed by a trusted Group Manager. For 3581 [Degabriele] to apply as it is written, public keys need to be in the 3582 expected subgroup. For this we rely on cofactor DH, Section 5.7.1.2 3583 of [NIST-800-56A] which is referenced in Section 2.4. 3585 HashEdDSA variants of Ed25519 and Ed448 are not used by COSE, see 3586 Section 2.2 of [I-D.ietf-cose-rfc8152bis-algs], and are not covered 3587 by the analysis in [Thormarker]. Hence, they MUST NOT be used with 3588 the public keys used to derive pairwise keys as specified in this 3589 document. 3591 12.16. Message Segmentation 3593 The same considerations from Section 12.7 of [RFC8613] hold for Group 3594 OSCORE. 3596 12.17. Privacy Considerations 3598 Group OSCORE ensures end-to-end integrity protection and encryption 3599 of the message payload and all options that are not used for proxy 3600 operations. In particular, options are processed according to the 3601 same class U/I/E that they have for OSCORE. Therefore, the same 3602 privacy considerations from Section 12.8 of [RFC8613] hold for Group 3603 OSCORE, with the following addition. 3605 * When protecting a message in group mode, the countersignature is 3606 encrypted by using a keystream derived from the group keying 3607 material (see Section 4.1 and Section 4.1.1). This ensures group 3608 privacy. That is, an attacker cannot track an endpoint over two 3609 groups by linking messages between the two groups, unless being 3610 also a member of those groups. 3612 Furthermore, the following privacy considerations hold about the 3613 OSCORE option, which may reveal information on the communicating 3614 endpoints. 3616 * The 'kid' parameter, which is intended to help a recipient 3617 endpoint to find the right Recipient Context, may reveal 3618 information about the Sender Endpoint. When both a request and 3619 the corresponding responses include the 'kid' parameter, this may 3620 reveal information about both a client sending a request and all 3621 the possibly replying servers sending their own individual 3622 response. 3624 * The 'kid context' parameter, which is intended to help a recipient 3625 endpoint to find the right Security Context, reveals information 3626 about the sender endpoint. In particular, it reveals that the 3627 sender endpoint is a member of a particular OSCORE group, whose 3628 current Group ID is indicated in the 'kid context' parameter. 3630 When receiving a group request, each of the recipient endpoints can 3631 reply with a response that includes its Sender ID as 'kid' parameter. 3632 All these responses will be matchable with the request through the 3633 Token. Thus, even if these responses do not include a 'kid context' 3634 parameter, it becomes possible to understand that the responder 3635 endpoints are in the same group of the requester endpoint. 3637 Furthermore, using the approach described in Section 10 to achieve 3638 Sender Sequence Number synchronization with a client may reveal when 3639 a server device goes through a reboot. This can be mitigated by the 3640 server device storing the precise state of the Replay Window of each 3641 known client on a clean shutdown. 3643 Finally, the approach described in Section 12.6 to prevent collisions 3644 of Group Identifiers from different Group Managers may reveal 3645 information about events in the respective OSCORE groups. In 3646 particular, a Group Identifier changes when the corresponding group 3647 is rekeyed. Thus, Group Managers might use the shared list of Group 3648 Identifiers to infer the rate and patterns of group membership 3649 changes triggering a group rekeying, e.g., due to newly joined 3650 members or evicted (compromised) members. In order to alleviate this 3651 privacy concern, it should be hidden from the Group Managers which 3652 exact Group Manager has currently assigned which Group Identifiers in 3653 its OSCORE groups. 3655 13. IANA Considerations 3657 Note to RFC Editor: Please replace "[This Document]" with the RFC 3658 number of this document and delete this paragraph. 3660 This document has the following actions for IANA. 3662 13.1. OSCORE Flag Bits Registry 3664 IANA is asked to add the following value entry to the "OSCORE Flag 3665 Bits" registry within the "Constrained RESTful Environments (CoRE) 3666 Parameters" registry group. 3668 +--------------+------------+-----------------------------+-----------+ 3669 | Bit Position | Name | Description | Reference | 3670 +--------------+------------+-----------------------------+-----------+ 3671 | 2 | Group Flag | For using a Group OSCORE | [This | 3672 | | | Security Context, set to 1 | Document] | 3673 | | | if the message is protected | | 3674 | | | with the group mode | | 3675 +--------------+------------+-----------------------------+-----------+ 3677 14. References 3679 14.1. Normative References 3681 [I-D.ietf-core-groupcomm-bis] 3682 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 3683 for the Constrained Application Protocol (CoAP)", Work in 3684 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 3685 06, 7 March 2022, . 3688 [I-D.ietf-cose-countersign] 3689 Schaad, J. and R. Housley, "CBOR Object Signing and 3690 Encryption (COSE): Countersignatures", Work in Progress, 3691 Internet-Draft, draft-ietf-cose-countersign-05, 23 June 3692 2021, . 3695 [I-D.ietf-cose-rfc8152bis-algs] 3696 Schaad, J., "CBOR Object Signing and Encryption (COSE): 3697 Initial Algorithms", Work in Progress, Internet-Draft, 3698 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 3699 . 3702 [I-D.ietf-cose-rfc8152bis-struct] 3703 Schaad, J., "CBOR Object Signing and Encryption (COSE): 3704 Structures and Process", Work in Progress, Internet-Draft, 3705 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 3706 . 3709 [NIST-800-56A] 3710 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 3711 Davis, "Recommendation for Pair-Wise Key-Establishment 3712 Schemes Using Discrete Logarithm Cryptography - NIST 3713 Special Publication 800-56A, Revision 3", April 2018, 3714 . 3717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3718 Requirement Levels", BCP 14, RFC 2119, 3719 DOI 10.17487/RFC2119, March 1997, 3720 . 3722 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3723 "Randomness Requirements for Security", BCP 106, RFC 4086, 3724 DOI 10.17487/RFC4086, June 2005, 3725 . 3727 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 3728 Algorithm (DSA) and Elliptic Curve Digital Signature 3729 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 3730 2013, . 3732 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3733 Application Protocol (CoAP)", RFC 7252, 3734 DOI 10.17487/RFC7252, June 2014, 3735 . 3737 [RFC7641] Hartke, K., "Observing Resources in the Constrained 3738 Application Protocol (CoAP)", RFC 7641, 3739 DOI 10.17487/RFC7641, September 2015, 3740 . 3742 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 3743 for Security", RFC 7748, DOI 10.17487/RFC7748, January 3744 2016, . 3746 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 3747 Signature Algorithm (EdDSA)", RFC 8032, 3748 DOI 10.17487/RFC8032, January 2017, 3749 . 3751 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3752 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3753 May 2017, . 3755 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 3756 Definition Language (CDDL): A Notational Convention to 3757 Express Concise Binary Object Representation (CBOR) and 3758 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 3759 June 2019, . 3761 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 3762 "Object Security for Constrained RESTful Environments 3763 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 3764 . 3766 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 3767 Representation (CBOR)", STD 94, RFC 8949, 3768 DOI 10.17487/RFC8949, December 2020, 3769 . 3771 [RFC9175] Amsüss, C., Preuß Mattsson, J., and G. Selander, 3772 "Constrained Application Protocol (CoAP): Echo, Request- 3773 Tag, and Token Processing", RFC 9175, 3774 DOI 10.17487/RFC9175, February 2022, 3775 . 3777 14.2. Informative References 3779 [Degabriele] 3780 Degabriele, J.P., Lehmann, A., Paterson, K.G., Smart, 3781 N.P., and M. Strefler, "On the Joint Security of 3782 Encryption and Signature in EMV", December 2011, 3783 . 3785 [I-D.amsuess-core-cachable-oscore] 3786 Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in 3787 Progress, Internet-Draft, draft-amsuess-core-cachable- 3788 oscore-04, 6 March 2022, . 3791 [I-D.ietf-ace-key-groupcomm] 3792 Palombini, F. and M. Tiloca, "Key Provisioning for Group 3793 Communication using ACE", Work in Progress, Internet- 3794 Draft, draft-ietf-ace-key-groupcomm-15, 23 December 2021, 3795 . 3798 [I-D.ietf-ace-key-groupcomm-oscore] 3799 Tiloca, M., Park, J., and F. Palombini, "Key Management 3800 for OSCORE Groups in ACE", Work in Progress, Internet- 3801 Draft, draft-ietf-ace-key-groupcomm-oscore-13, 7 March 3802 2022, . 3805 [I-D.ietf-ace-oauth-authz] 3806 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 3807 H. Tschofenig, "Authentication and Authorization for 3808 Constrained Environments (ACE) using the OAuth 2.0 3809 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 3810 draft-ietf-ace-oauth-authz-46, 8 November 2021, 3811 . 3814 [I-D.ietf-core-observe-multicast-notifications] 3815 Tiloca, M., Höglund, R., Amsüss, C., and F. Palombini, 3816 "Observe Notifications as CoAP Multicast Responses", Work 3817 in Progress, Internet-Draft, draft-ietf-core-observe- 3818 multicast-notifications-03, 7 March 2022, 3819 . 3822 [I-D.ietf-cose-cbor-encoded-cert] 3823 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 3824 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 3825 Certificates)", Work in Progress, Internet-Draft, draft- 3826 ietf-cose-cbor-encoded-cert-03, 10 January 2022, 3827 . 3830 [I-D.ietf-lwig-curve-representations] 3831 Struik, R., "Alternative Elliptic Curve Representations", 3832 Work in Progress, Internet-Draft, draft-ietf-lwig-curve- 3833 representations-23, 21 January 2022, 3834 . 3837 [I-D.ietf-lwig-security-protocol-comparison] 3838 Mattsson, J. P., Palombini, F., and M. Vucinic, 3839 "Comparison of CoAP Security Protocols", Work in Progress, 3840 Internet-Draft, draft-ietf-lwig-security-protocol- 3841 comparison-05, 2 November 2020, 3842 . 3845 [I-D.ietf-tls-dtls13] 3846 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 3847 Datagram Transport Layer Security (DTLS) Protocol Version 3848 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 3849 dtls13-43, 30 April 2021, . 3852 [I-D.mattsson-cfrg-det-sigs-with-noise] 3853 Mattsson, J. P., Thormarker, E., and S. Ruohomaa, 3854 "Deterministic ECDSA and EdDSA Signatures with Additional 3855 Randomness", Work in Progress, Internet-Draft, draft- 3856 mattsson-cfrg-det-sigs-with-noise-04, 15 February 2022, 3857 . 3860 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 3861 "Transmission of IPv6 Packets over IEEE 802.15.4 3862 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 3863 . 3865 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 3866 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 3867 . 3869 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 3870 Key Derivation Function (HKDF)", RFC 5869, 3871 DOI 10.17487/RFC5869, May 2010, 3872 . 3874 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 3875 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 3876 DOI 10.17487/RFC6282, September 2011, 3877 . 3879 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3880 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3881 January 2012, . 3883 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 3884 Constrained-Node Networks", RFC 7228, 3885 DOI 10.17487/RFC7228, May 2014, 3886 . 3888 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 3889 Security (TLS) / Datagram Transport Layer Security (DTLS) 3890 Profiles for the Internet of Things", RFC 7925, 3891 DOI 10.17487/RFC7925, July 2016, 3892 . 3894 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 3895 the Constrained Application Protocol (CoAP)", RFC 7959, 3896 DOI 10.17487/RFC7959, August 2016, 3897 . 3899 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 3900 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 3901 May 2018, . 3903 [Thormarker] 3904 Thormarker, E., "On using the same key pair for Ed25519 3905 and an X25519 based KEM", April 2021, 3906 . 3908 Appendix A. Assumptions and Security Objectives 3910 This section presents a set of assumptions and security objectives 3911 for the approach described in this document. The rest of this 3912 section refers to three types of groups: 3914 * Application group, i.e., a set of CoAP endpoints that share a 3915 common pool of resources. 3917 * Security group, as defined in Section 1.1 of this document. There 3918 can be a one-to-one or a one-to-many relation between security 3919 groups and application groups, and vice versa. 3921 * CoAP group, i.e., a set of CoAP endpoints where each endpoint is 3922 configured to receive one-to-many CoAP requests, e.g., sent to the 3923 group's associated IP multicast address and UDP port as defined in 3924 [I-D.ietf-core-groupcomm-bis]. An endpoint may be a member of 3925 multiple CoAP groups. There can be a one-to-one or a one-to-many 3926 relation between application groups and CoAP groups. Note that a 3927 device sending a CoAP request to a CoAP group is not necessarily 3928 itself a member of that group: it is a member only if it also has 3929 a CoAP server endpoint listening to requests for this CoAP group, 3930 sent to the associated IP multicast address and port. In order to 3931 provide secure group communication, all members of a CoAP group as 3932 well as all further endpoints configured only as clients sending 3933 CoAP (multicast) requests to the CoAP group have to be member of a 3934 security group. There can be a one-to-one or a one-to-many 3935 relation between security groups and CoAP groups, and vice versa. 3937 A.1. Assumptions 3939 The following points are assumed to be already addressed and are out 3940 of the scope of this document. 3942 * Multicast communication topology: this document considers both 3943 1-to-N (one sender and multiple recipients) and M-to-N (multiple 3944 senders and multiple recipients) communication topologies. The 3945 1-to-N communication topology is the simplest group communication 3946 scenario that would serve the needs of a typical Low-power and 3947 Lossy Network (LLN). Examples of use cases that benefit from 3948 secure group communication are provided in Appendix B. 3950 In a 1-to-N communication model, only a single client transmits 3951 data to the CoAP group, in the form of request messages; in an 3952 M-to-N communication model (where M and N do not necessarily have 3953 the same value), M clients transmit data to the CoAP group. 3954 According to [I-D.ietf-core-groupcomm-bis], any possible proxy 3955 entity is supposed to know about the clients. Also, every client 3956 expects and is able to handle multiple response messages 3957 associated with a same request sent to the CoAP group. 3959 * Group size: security solutions for group communication should be 3960 able to adequately support different and possibly large security 3961 groups. The group size is the current number of members in a 3962 security group. In the use cases mentioned in this document, the 3963 number of clients (normally the controlling devices) is expected 3964 to be much smaller than the number of servers (i.e., the 3965 controlled devices). A security solution for group communication 3966 that supports 1 to 50 clients would be able to properly cover the 3967 group sizes required for most use cases that are relevant for this 3968 document. The maximum group size is expected to be in the range 3969 of 2 to 100 devices. Security groups larger than that should be 3970 divided into smaller independent groups. One should not assume 3971 that the set of members of a security group remains fixed. That 3972 is, the group membership is subject to changes, possibly on a 3973 frequent basis. 3975 * Communication with the Group Manager: an endpoint must use a 3976 secure dedicated channel when communicating with the Group 3977 Manager, also when not registered as a member of the security 3978 group. 3980 * Provisioning and management of Security Contexts: a Security 3981 Context must be established among the members of the security 3982 group. A secure mechanism must be used to generate, revoke and 3983 (re-)distribute keying material, communication policies and 3984 security parameters in the security group. The actual 3985 provisioning and management of the Security Context is out of the 3986 scope of this document. 3988 * Multicast data security ciphersuite: all members of a security 3989 group must use the same ciphersuite to provide authenticity, 3990 integrity and confidentiality of messages in the group. The 3991 ciphersuite is specified as part of the Security Context. 3993 * Backward security: a new device joining the security group should 3994 not have access to any old Security Contexts used before its 3995 joining. This ensures that a new member of the security group is 3996 not able to decrypt confidential data sent before it has joined 3997 the security group. The adopted key management scheme should 3998 ensure that the Security Context is updated to ensure backward 3999 confidentiality. The actual mechanism to update the Security 4000 Context and renew the group keying material in the security group 4001 upon a new member's joining has to be defined as part of the group 4002 key management scheme. 4004 * Forward security: entities that leave the security group should 4005 not have access to any future Security Contexts or message 4006 exchanged within the security group after their leaving. This 4007 ensures that a former member of the security group is not able to 4008 decrypt confidential data sent within the security group anymore. 4009 Also, it ensures that a former member is not able to send 4010 protected messages to the security group anymore. The actual 4011 mechanism to update the Security Context and renew the group 4012 keying material in the security group upon a member's leaving has 4013 to be defined as part of the group key management scheme. 4015 A.2. Security Objectives 4017 The approach described in this document aims at fulfilling the 4018 following security objectives: 4020 * Data replay protection: group request messages or response 4021 messages replayed within the security group must be detected. 4023 * Data confidentiality: messages sent within the security group 4024 shall be encrypted. 4026 * Group-level data confidentiality: the group mode provides group- 4027 level data confidentiality since messages are encrypted at a group 4028 level, i.e., in such a way that they can be decrypted by any 4029 member of the security group, but not by an external adversary or 4030 other external entities. 4032 * Pairwise data confidentiality: the pairwise mode especially 4033 provides pairwise data confidentiality, since messages are 4034 encrypted using pairwise keying material shared between any two 4035 group members, hence they can be decrypted only by the intended 4036 single recipient. 4038 * Source message authentication: messages sent within the security 4039 group shall be authenticated. That is, it is essential to ensure 4040 that a message is originated by a member of the security group in 4041 the first place, and in particular by a specific, identifiable 4042 member of the security group. 4044 * Message integrity: messages sent within the security group shall 4045 be integrity protected. That is, it is essential to ensure that a 4046 message has not been tampered with, either by a group member, or 4047 by an external adversary or other external entities which are not 4048 members of the security group. 4050 * Message ordering: it must be possible to determine the ordering of 4051 messages coming from a single sender. In accordance with OSCORE 4052 [RFC8613], this results in providing absolute freshness of 4053 responses that are not notifications, as well as relative 4054 freshness of group requests and notification responses. It is not 4055 required to determine ordering of messages from different senders. 4057 Appendix B. List of Use Cases 4059 Group Communication for CoAP [I-D.ietf-core-groupcomm-bis] provides 4060 the necessary background for multicast-based CoAP communication, with 4061 particular reference to low-power and lossy networks (LLNs) and 4062 resource constrained environments. The interested reader is 4063 encouraged to first read [I-D.ietf-core-groupcomm-bis] to understand 4064 the non-security related details. This section discusses a number of 4065 use cases that benefit from secure group communication, and refers to 4066 the three types of groups from Appendix A. Specific security 4067 requirements for these use cases are discussed in Appendix A. 4069 * Lighting control: consider a building equipped with IP-connected 4070 lighting devices, switches, and border routers. The lighting 4071 devices acting as servers are organized into application groups 4072 and CoAP groups, according to their physical location in the 4073 building. For instance, lighting devices in a room or corridor 4074 can be configured as members of a single application group and 4075 corresponding CoAP group. Those lighting devices together with 4076 the switches acting as clients in the same room or corridor can be 4077 configured as members of the corresponding security group. 4078 Switches are then used to control the lighting devices by sending 4079 on/off/dimming commands to all lighting devices in the CoAP group, 4080 while border routers connected to an IP network backbone (which is 4081 also multicast-enabled) can be used to interconnect routers in the 4082 building. Consequently, this would also enable logical groups to 4083 be formed even if devices with a role in the lighting application 4084 may be physically in different subnets (e.g., on wired and 4085 wireless networks). Connectivity between lighting devices may be 4086 realized, for instance, by means of IPv6 and (border) routers 4087 supporting 6LoWPAN [RFC4944][RFC6282]. Group communication 4088 enables synchronous operation of a set of connected lights, 4089 ensuring that the light preset (e.g., dimming level or color) of a 4090 large set of luminaires are changed at the same perceived time. 4091 This is especially useful for providing a visual synchronicity of 4092 light effects to the user. As a practical guideline, events 4093 within a 200 ms interval are perceived as simultaneous by humans, 4094 which is necessary to ensure in many setups. Devices may reply 4095 back to the switches that issue on/off/dimming commands, in order 4096 to report about the execution of the requested operation (e.g., 4097 OK, failure, error) and their current operational status. In a 4098 typical lighting control scenario, a single switch is the only 4099 entity responsible for sending commands to a set of lighting 4100 devices. In more advanced lighting control use cases, a M-to-N 4101 communication topology would be required, for instance in case 4102 multiple sensors (presence or day-light) are responsible to 4103 trigger events to a set of lighting devices. Especially in 4104 professional lighting scenarios, the roles of client and server 4105 are configured by the lighting commissioner, and devices strictly 4106 follow those roles. 4108 * Integrated building control: enabling Building Automation and 4109 Control Systems (BACSs) to control multiple heating, ventilation 4110 and air-conditioning units to predefined presets. Controlled 4111 units can be organized into application groups and CoAP groups in 4112 order to reflect their physical position in the building, e.g., 4113 devices in the same room can be configured as members of a single 4114 application group and corresponding CoAP group. As a practical 4115 guideline, events within intervals of seconds are typically 4116 acceptable. Controlled units are expected to possibly reply back 4117 to the BACS issuing control commands, in order to report about the 4118 execution of the requested operation (e.g., OK, failure, error) 4119 and their current operational status. 4121 * Software and firmware updates: software and firmware updates often 4122 comprise quite a large amount of data. This can overload a Low- 4123 power and Lossy Network (LLN) that is otherwise typically used to 4124 deal with only small amounts of data, on an infrequent base. 4125 Rather than sending software and firmware updates as unicast 4126 messages to each individual device, multicasting such updated data 4127 to a larger set of devices at once displays a number of benefits. 4128 For instance, it can significantly reduce the network load and 4129 decrease the overall time latency for propagating this data to all 4130 devices. Even if the complete whole update process itself is 4131 secured, securing the individual messages is important, in case 4132 updates consist of relatively large amounts of data. In fact, 4133 checking individual received data piecemeal for tampering avoids 4134 that devices store large amounts of partially corrupted data and 4135 that they detect tampering hereof only after all data has been 4136 received. Devices receiving software and firmware updates are 4137 expected to possibly reply back, in order to provide a feedback 4138 about the execution of the update operation (e.g., OK, failure, 4139 error) and their current operational status. 4141 * Parameter and configuration update: by means of multicast 4142 communication, it is possible to update the settings of a set of 4143 similar devices, both simultaneously and efficiently. Possible 4144 parameters are related, for instance, to network load management 4145 or network access controls. Devices receiving parameter and 4146 configuration updates are expected to possibly reply back, to 4147 provide a feedback about the execution of the update operation 4148 (e.g., OK, failure, error) and their current operational status. 4150 * Commissioning of Low-power and Lossy Network (LLN) systems: a 4151 commissioning device is responsible for querying all devices in 4152 the local network or a selected subset of them, in order to 4153 discover their presence, and be aware of their capabilities, 4154 default configuration, and operating conditions. Queried devices 4155 displaying similarities in their capabilities and features, or 4156 sharing a common physical location can be configured as members of 4157 a single application group and corresponding CoAP group. Queried 4158 devices are expected to reply back to the commissioning device, in 4159 order to notify their presence, and provide the requested 4160 information and their current operational status. 4162 * Emergency multicast: a particular emergency related information 4163 (e.g., natural disaster) is generated and multicast by an 4164 emergency notifier, and relayed to multiple devices. The latter 4165 may reply back to the emergency notifier, in order to provide 4166 their feedback and local information related to the ongoing 4167 emergency. This kind of setups should additionally rely on a 4168 fault-tolerant multicast algorithm, such as Multicast Protocol for 4169 Low-Power and Lossy Networks (MPL). 4171 Appendix C. Example of Group Identifier Format 4173 This section provides an example of how the Group Identifier (Gid) 4174 can be specifically formatted. That is, the Gid can be composed of 4175 two parts, namely a Group Prefix and a Group Epoch. 4177 For each group, the Group Prefix is constant over time and is 4178 uniquely defined in the set of all the groups associated with the 4179 same Group Manager. The choice of the Group Prefix for a given 4180 group's Security Context is application specific. The size of the 4181 Group Prefix directly impact on the maximum number of distinct groups 4182 under the same Group Manager. 4184 The Group Epoch is set to 0 upon the group's initialization, and is 4185 incremented by 1 each time new keying material, together with a new 4186 Gid, is distributed to the group in order to establish a new Security 4187 Context (see Section 3.2). 4189 As an example, a 3-byte Gid can be composed of: i) a 1-byte Group 4190 Prefix '0xb1' interpreted as a raw byte string; and ii) a 2-byte 4191 Group Epoch interpreted as an unsigned integer ranging from 0 to 4192 65535. Then, after having established the Common Context 61532 times 4193 in the group, its Gid will assume value '0xb1f05c'. 4195 Using an immutable Group Prefix for a group assumes that enough time 4196 elapses before all possible Group Epoch values are used, i.e., before 4197 the Group Manager terminates the group or starts reassigning Gid 4198 values to the group (see Section 3.2). Thus, the expected highest 4199 rate for addition/removal of group members and consequent group 4200 rekeying should be taken into account for a proper dimensioning of 4201 the Group Epoch size. 4203 As discussed in Section 12.6, if endpoints are deployed in multiple 4204 groups managed by different non-synchronized Group Managers, it is 4205 possible that Group Identifiers of different groups coincide at some 4206 point in time. In this case, a recipient has to handle coinciding 4207 Group Identifiers, and has to try using different Security Contexts 4208 to process an incoming message, until the right one is found and the 4209 message is correctly verified. Therefore, it is favorable that Group 4210 Identifiers from different Group Managers have a size that result in 4211 a small probability of collision. How small this probability should 4212 be is up to system designers. 4214 Appendix D. Set-up of New Endpoints 4216 An endpoint joins a group by explicitly interacting with the 4217 responsible Group Manager. When becoming members of a group, 4218 endpoints are not required to know how many and what endpoints are in 4219 the same group. 4221 Communications between a joining endpoint and the Group Manager rely 4222 on the CoAP protocol and must be secured. Specific details on how to 4223 secure communications between joining endpoints and a Group Manager 4224 are out of the scope of this document. 4226 The Group Manager must verify that the joining endpoint is authorized 4227 to join the group. To this end, the Group Manager can directly 4228 authorize the joining endpoint, or expect it to provide authorization 4229 evidence previously obtained from a trusted entity. Further details 4230 about the authorization of joining endpoints are out of scope. 4232 In case of successful authorization check, the Group Manager 4233 generates a Sender ID assigned to the joining endpoint, before 4234 proceeding with the rest of the join process. That is, the Group 4235 Manager provides the joining endpoint with the keying material and 4236 parameters to initialize the Security Context, including its own 4237 authentication credential (see Section 2). The actual provisioning 4238 of keying material and parameters to the joining endpoint is out of 4239 the scope of this document. 4241 As mentioned in Section 3, the Group Manager and the join process can 4242 be as specified in [I-D.ietf-ace-key-groupcomm-oscore]. 4244 Appendix E. Document Updates 4246 RFC EDITOR: PLEASE REMOVE THIS SECTION. 4248 E.1. Version -13 to -14 4250 * Replaced "node" with "endpoint" where appropriate. 4252 * Replaced "owning" with "storing" (of keying material). 4254 * Distinction between "authentication credential" and "public key". 4256 * Considerations on storing whole authentication credentials. 4258 * Considerations on Denial of Service. 4260 * Recycling of Group IDs by tracking the "Birth Gid" of each group 4261 member is now optional to support and use for the Group Manager. 4263 * Fine-grained suppression of error responses. 4265 * Changed section title "Mandatory-to-Implement Compliance 4266 Requirements" to "Implementation Compliance". 4268 * "Challenge-Response Synchronization" moved to the document body. 4270 * RFC 7641 and draft-ietf-core-echo-request-tag as normative 4271 references. 4273 * Clarifications and editorial improvements. 4275 E.2. Version -12 to -13 4277 * Fixes in the derivation of the Group Encryption Key. 4279 * Added Mandatory-to-Implement compliance requirements. 4281 * Changed UCCS to CCS. 4283 E.3. Version -11 to -12 4285 * No mode of operation is mandatory to support. 4287 * Revised parameters of the Security Context, COSE object and 4288 external_aad. 4290 * Revised management of keying material for the Group Manager. 4292 * Informing of former members when rekeying the group. 4294 * Admit encryption-only algorithms in group mode. 4296 * Encrypted countersignature through a keystream. 4298 * Added public key of the Group Manager as key material and 4299 protected data. 4301 * Clarifications about message processing, especially notifications. 4303 * Guidance for message processing of external signature checkers. 4305 * Updated derivation of pairwise keys, with more security 4306 considerations. 4308 * Termination of ongoing observations as client, upon leaving or 4309 before re-joining the group. 4311 * Recycling Group IDs by tracking the "Birth Gid" of each group 4312 member. 4314 * Expanded security and privacy considerations about the group mode. 4316 * Removed appendices on skipping signature verification and on COSE 4317 capabilities. 4319 * Fixes and editorial improvements. 4321 E.4. Version -10 to -11 4323 * Loss of Recipient Contexts due to their overflow. 4325 * Added diagram on keying material components and their relation. 4327 * Distinction between anti-replay and freshness. 4329 * Preservation of Sender IDs over rekeying. 4331 * Clearer cause-effect about reset of SSN. 4333 * The GM provides public keys of group members with associated 4334 Sender IDs. 4336 * Removed 'par_countersign_key' from the external_aad. 4338 * One single format for the external_aad, both for encryption and 4339 signing. 4341 * Presence of 'kid' in responses to requests protected with the 4342 pairwise mode. 4344 * Inclusion of 'kid_context' in notifications following a group 4345 rekeying. 4347 * Pairwise mode presented with OSCORE as baseline. 4349 * Revised examples with signature values. 4351 * Decoupled growth of clients' Sender Sequence Numbers and loss of 4352 synchronization for server. 4354 * Sender IDs not recycled in the group under the same Gid. 4356 * Processing and description of the Group Flag bit in the OSCORE 4357 option. 4359 * Usage of the pairwise mode for multicast requests. 4361 * Clarifications on synchronization using the Echo option. 4363 * General format of context parameters and external_aad elements, 4364 supporting future registered COSE algorithms (new Appendix). 4366 * Fixes and editorial improvements. 4368 E.5. Version -09 to -10 4370 * Removed 'Counter Signature Key Parameters' from the Common 4371 Context. 4373 * New parameters in the Common Context covering the DH secret 4374 derivation. 4376 * New countersignature header parameter from draft-ietf-cose- 4377 countersign. 4379 * Stronger policies non non-recycling of Sender IDs and Gid. 4381 * The Sender Sequence Number is reset when establishing a new 4382 Security Context. 4384 * Added 'request_kid_context' in the aad_array. 4386 * The server can respond with 5.03 if the client's public key is not 4387 available. 4389 * The observer client stores an invariant identifier of the group. 4391 * Relaxed storing of original 'kid' for observer clients. 4393 * Both client and server store the 'kid_context' of the original 4394 observation request. 4396 * The server uses a fresh PIV if protecting the response with a 4397 Security Context different from the one used to protect the 4398 request. 4400 * Clarifications on MTI algorithms and curves. 4402 * Removed optimized requests. 4404 * Overall clarifications and editorial revision. 4406 E.6. Version -08 to -09 4408 * Pairwise keys are discarded after group rekeying. 4410 * Signature mode renamed to group mode. 4412 * The parameters for countersignatures use the updated COSE 4413 registries. Newly defined IANA registries have been removed. 4415 * Pairwise Flag bit renamed as Group Flag bit, set to 1 in group 4416 mode and set to 0 in pairwise mode. 4418 * Dedicated section on updating the Security Context. 4420 * By default, sender sequence numbers and replay windows are not 4421 reset upon group rekeying. 4423 * An endpoint implementing only a silent server does not support the 4424 pairwise mode. 4426 * Separate section on general message reception. 4428 * Pairwise mode moved to the document body. 4430 * Considerations on using the pairwise mode in non-multicast 4431 settings. 4433 * Optimized requests are moved as an appendix. 4435 * Normative support for the signature and pairwise mode. 4437 * Revised methods for synchronization with clients' sender sequence 4438 number. 4440 * Appendix with example values of parameters for countersignatures. 4442 * Clarifications and editorial improvements. 4444 E.7. Version -07 to -08 4446 * Clarified relation between pairwise mode and group communication 4447 (Section 1). 4449 * Improved definition of "silent server" (Section 1.1). 4451 * Clarified when a Recipient Context is needed (Section 2). 4453 * Signature checkers as entities supported by the Group Manager 4454 (Section 2.3). 4456 * Clarified that the Group Manager is under exclusive control of Gid 4457 and Sender ID values in a group, with Sender ID values under each 4458 Gid value (Section 2.3). 4460 * Mitigation policies in case of recycled 'kid' values 4461 (Section 2.4). 4463 * More generic exhaustion (not necessarily wrap-around) of sender 4464 sequence numbers (Sections 2.5 and 10.11). 4466 * Pairwise key considerations, as to group rekeying and Sender 4467 Sequence Numbers (Section 3). 4469 * Added reference to static-static Diffie-Hellman shared secret 4470 (Section 3). 4472 * Note for implementation about the external_aad for signing 4473 (Sectino 4.3.2). 4475 * Retransmission by the application for group requests over 4476 multicast as Non-confirmable (Section 7). 4478 * A server MUST use its own Partial IV in a response, if protecting 4479 it with a different context than the one used for the request 4480 (Section 7.3). 4482 * Security considerations: encryption of pairwise mode as 4483 alternative to group-level security (Section 10.1). 4485 * Security considerations: added approach to reduce the chance of 4486 global collisions of Gid values from different Group Managers 4487 (Section 10.5). 4489 * Security considerations: added implications for block-wise 4490 transfers when using the signature mode for requests over unicast 4491 (Section 10.7). 4493 * Security considerations: (multiple) supported signature algorithms 4494 (Section 10.13). 4496 * Security considerations: added privacy considerations on the 4497 approach for reducing global collisions of Gid values 4498 (Section 10.15). 4500 * Updates to the methods for synchronizing with clients' sequence 4501 number (Appendix E). 4503 * Simplified text on discovery services supporting the pairwise mode 4504 (Appendix G.1). 4506 * Editorial improvements. 4508 E.8. Version -06 to -07 4510 * Updated abstract and introduction. 4512 * Clarifications of what pertains a group rekeying. 4514 * Derivation of pairwise keying material. 4516 * Content re-organization for COSE Object and OSCORE header 4517 compression. 4519 * Defined the Pairwise Flag bit for the OSCORE option. 4521 * Supporting CoAP Observe for group requests and responses. 4523 * Considerations on message protection across switching to new 4524 keying material. 4526 * New optimized mode based on pairwise keying material. 4528 * More considerations on replay protection and Security Contexts 4529 upon key renewal. 4531 * Security considerations on Group OSCORE for unicast requests, also 4532 as affecting the usage of the Echo option. 4534 * Clarification on different types of groups considered 4535 (application/security/CoAP). 4537 * New pairwise mode, using pairwise keying material for both 4538 requests and responses. 4540 E.9. Version -05 to -06 4542 * Group IDs mandated to be unique under the same Group Manager. 4544 * Clarifications on parameter update upon group rekeying. 4546 * Updated external_aad structures. 4548 * Dynamic derivation of Recipient Contexts made optional and 4549 application specific. 4551 * Optional 4.00 response for failed signature verification on the 4552 server. 4554 * Removed client handling of duplicated responses to multicast 4555 requests. 4557 * Additional considerations on public key retrieval and group 4558 rekeying. 4560 * Added Group Manager responsibility on validating public keys. 4562 * Updates IANA registries. 4564 * Reference to RFC 8613. 4566 * Editorial improvements. 4568 E.10. Version -04 to -05 4570 * Added references to draft-dijk-core-groupcomm-bis. 4572 * New parameter Counter Signature Key Parameters (Section 2). 4574 * Clarification about Recipient Contexts (Section 2). 4576 * Two different external_aad for encrypting and signing 4577 (Section 3.1). 4579 * Updated response verification to handle Observe notifications 4580 (Section 6.4). 4582 * Extended Security Considerations (Section 8). 4584 * New "Counter Signature Key Parameters" IANA Registry 4585 (Section 9.2). 4587 E.11. Version -03 to -04 4589 * Added the new "Counter Signature Parameters" in the Common Context 4590 (see Section 2). 4592 * Added recommendation on using "deterministic ECDSA" if ECDSA is 4593 used as countersignature algorithm (see Section 2). 4595 * Clarified possible asynchronous retrieval of keying material from 4596 the Group Manager, in order to process incoming messages (see 4597 Section 2). 4599 * Structured Section 3 into subsections. 4601 * Added the new 'par_countersign' to the aad_array of the 4602 external_aad (see Section 3.1). 4604 * Clarified non reliability of 'kid' as identity identifier for a 4605 group member (see Section 2.1). 4607 * Described possible provisioning of new Sender ID in case of 4608 Partial IV wrap-around (see Section 2.2). 4610 * The former signature bit in the Flag Byte of the OSCORE option 4611 value is reverted to reserved (see Section 4.1). 4613 * Updated examples of compressed COSE object, now with the sixth 4614 less significant bit in the Flag Byte of the OSCORE option value 4615 set to 0 (see Section 4.3). 4617 * Relaxed statements on sending error messages (see Section 6). 4619 * Added explicit step on computing the countersignature for outgoing 4620 messages (see Sections 6.1 and 6.3). 4622 * Handling of just created Recipient Contexts in case of 4623 unsuccessful message verification (see Sections 6.2 and 6.4). 4625 * Handling of replied/repeated responses on the client (see 4626 Section 6.4). 4628 * New IANA Registry "Counter Signature Parameters" (see 4629 Section 9.1). 4631 E.12. Version -02 to -03 4633 * Revised structure and phrasing for improved readability and better 4634 alignment with draft-ietf-core-object-security. 4636 * Added discussion on wrap-Around of Partial IVs (see Section 2.2). 4638 * Separate sections for the COSE Object (Section 3) and the OSCORE 4639 Header Compression (Section 4). 4641 * The countersignature is now appended to the encrypted payload of 4642 the OSCORE message, rather than included in the OSCORE Option (see 4643 Section 4). 4645 * Extended scope of Section 5, now titled " Message Binding, 4646 Sequence Numbers, Freshness and Replay Protection". 4648 * Clarifications about Non-confirmable messages in Section 5.1 4649 "Synchronization of Sender Sequence Numbers". 4651 * Clarifications about error handling in Section 6 "Message 4652 Processing". 4654 * Compacted list of responsibilities of the Group Manager in 4655 Section 7. 4657 * Revised and extended security considerations in Section 8. 4659 * Added IANA considerations for the OSCORE Flag Bits Registry in 4660 Section 9. 4662 * Revised Appendix D, now giving a short high-level description of a 4663 new endpoint set-up. 4665 E.13. Version -01 to -02 4667 * Terminology has been made more aligned with RFC7252 and draft- 4668 ietf-core-object-security: i) "client" and "server" replace the 4669 old "multicaster" and "listener", respectively; ii) "silent 4670 server" replaces the old "pure listener". 4672 * Section 2 has been updated to have the Group Identifier stored in 4673 the 'ID Context' parameter defined in draft-ietf-core-object- 4674 security. 4676 * Section 3 has been updated with the new format of the Additional 4677 Authenticated Data. 4679 * Major rewriting of Section 4 to better highlight the differences 4680 with the message processing in draft-ietf-core-object-security. 4682 * Added Sections 7.2 and 7.3 discussing security considerations 4683 about uniqueness of (key, nonce) and collision of group 4684 identifiers, respectively. 4686 * Minor updates to Appendix A.1 about assumptions on multicast 4687 communication topology and group size. 4689 * Updated Appendix C on format of group identifiers, with practical 4690 implications of possible collisions of group identifiers. 4692 * Updated Appendix D.2, adding a pointer to draft-palombini-ace-key- 4693 groupcomm about retrieval of nodes' public keys through the Group 4694 Manager. 4696 * Minor updates to Appendix E.3 about Challenge-Response 4697 synchronization of sequence numbers based on the Echo option from 4698 draft-ietf-core-echo-request-tag. 4700 E.14. Version -00 to -01 4702 * Section 1.1 has been updated with the definition of group as 4703 "security group". 4705 * Section 2 has been updated with: 4707 - Clarifications on establishment/derivation of Security 4708 Contexts. 4710 - A table summarizing the the additional context elements 4711 compared to OSCORE. 4713 * Section 3 has been updated with: 4715 - Examples of request and response messages. 4717 - Use of CounterSignature0 rather than CounterSignature. 4719 - Additional Authenticated Data including also the signature 4720 algorithm, while not including the Group Identifier any longer. 4722 * Added Section 6, listing the responsibilities of the Group 4723 Manager. 4725 * Added Appendix A (former section), including assumptions and 4726 security objectives. 4728 * Appendix B has been updated with more details on the use cases. 4730 * Added Appendix C, providing an example of Group Identifier format. 4732 * Appendix D has been updated to be aligned with draft-palombini- 4733 ace-key-groupcomm. 4735 Acknowledgments 4737 The authors sincerely thank Christian Amsuess, Stefan Beck, Rolf 4738 Blom, Carsten Bormann, Esko Dijk, Martin Gunnarsson, Klaus Hartke, 4739 Rikard Hoeglund, Richard Kelsey, Dave Robin, Jim Schaad, Ludwig 4740 Seitz, Peter van der Stok and Erik Thormarker for their feedback and 4741 comments. 4743 The work on this document has been partly supported by VINNOVA and 4744 the Celtic-Next project CRITISEC; the H2020 project SIFIS-Home (Grant 4745 agreement 952652); the SSF project SEC4Factory under the grant 4746 RIT17-0032; and the EIT-Digital High Impact Initiative ACTIVE. 4748 Authors' Addresses 4750 Marco Tiloca 4751 RISE AB 4752 Isafjordsgatan 22 4753 SE-16440 Stockholm Kista 4754 Sweden 4755 Email: marco.tiloca@ri.se 4757 Göran Selander 4758 Ericsson AB 4759 Torshamnsgatan 23 4760 SE-16440 Stockholm Kista 4761 Sweden 4762 Email: goran.selander@ericsson.com 4764 Francesca Palombini 4765 Ericsson AB 4766 Torshamnsgatan 23 4767 SE-16440 Stockholm Kista 4768 Sweden 4769 Email: francesca.palombini@ericsson.com 4771 John Preuss Mattsson 4772 Ericsson AB 4773 Torshamnsgatan 23 4774 SE-16440 Stockholm Kista 4775 Sweden 4776 Email: john.mattsson@ericsson.com 4777 Jiye Park 4778 Universitaet Duisburg-Essen 4779 Schuetzenbahn 70 4780 45127 Essen 4781 Germany 4782 Email: ji-ye.park@uni-due.de