CoRE Working Group                                             M. Tiloca
Internet-Draft                                                   RISE AB
Intended status: Standards Track                             G. Selander
Expires: October 8, December 25, 2020                                  F. Palombini
                                                             Ericsson AB
                                                                 J. Park
                                             Universitaet Duisburg-Essen
                                                          April 06,
                                                           June 23, 2020

           Group OSCORE - Secure Group Communication for CoAP
                   draft-ietf-core-oscore-groupcomm-08
                  draft-ietf-core-oscore-groupcomm-09

Abstract

   This document defines Group Object Security for Constrained RESTful
   Environments (Group OSCORE), providing end-to-end security of CoAP
   messages exchanged between members of a group, e.g. using sent over IP
   multicast.  In particular, the described approach defines how OSCORE
   should be
   is used in a group communication setting to provide source
   authentication for CoAP group requests, sent by a client to multiple
   servers, and for protection of the corresponding CoAP responses.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 8, December 25, 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5   6
   2.  Security Context  . . . . . . . . . . . . . . . . . . . . . .   7
     2.1.  Common Context  . . . . . . . . . . . . . . . . . . . . .   7
     2.2.  Sender Context and Recipient   8
       2.1.1.  ID Context  . . . . . . . . . . . . . . . . . . . . .   8
     2.3.  The Group Manager
       2.1.2.  Counter Signature Algorithm . . . . . . . . . . . . .   9
       2.1.3.  Counter Signature Parameters  . . . . . . . . . . . .   9
     2.4.  Management of Group Keying Material
       2.1.4.  Counter Signature Key Parameters  . . . . . . . . . .  10
     2.2.  Sender Context and Recipient Context  . . . . . . . . . .  10
     2.5.  Exhaustion of Partial IV Values
     2.3.  Pairwise Keys . . . . . . . . . . . . . . . . . . . . . .  11
   3.
       2.3.1.  Derivation of Pairwise Keys . . . . . . . . . . . . .  11
       2.3.2.  Usage of Sequence Numbers . . . . . . . . . . . . . .  12
     3.1.  Key Derivation
       2.3.3.  Security Context for Pairwise Mode  . . . . . . . . .  12
     2.4.  Update of Security Context  . . . . . . . . . . . . . . .  12
     3.2.  Usage  13
       2.4.1.  Loss of Mutable Security Context  . . . . . . . . . .  13
       2.4.2.  Exhaustion of Sender Sequence Numbers . . . . . . . .  13
       2.4.3.  Retrieving New Security Context Parameters  . . . . .  14
   3.  The Group Manager . . . .  13
     3.3.  Note on Implementation . . . . . . . . . . . . . . . . .  13 .  15
     3.1.  Management of Group Keying Material . . . . . . . . . . .  16
     3.2.  Responsibilities of the Group Manager . . . . . . . . . .  17
   4.  The COSE Object . . . . . . . . . . . . . . . . . . . . . . .  14  18
     4.1.  Counter Signature . . . . . . . . . . . . . . . . . . . .  14  18
     4.2.  The 'kid' and 'kid context' parameters  . . . . . . . . .  14  19
     4.3.  external_aad  . . . . . . . . . . . . . . . . . . . . . .  15  19
       4.3.1.  external_aad for Encryption . . . . . . . . . . . . .  15  19
       4.3.2.  external_aad for Signing  . . . . . . . . . . . . . .  16  20
   5.  OSCORE Header Compression . . . . . . . . . . . . . . . . . .  17  21
     5.1.  Examples of Compressed COSE Objects . . . . . . . . . . .  17
   6.  Message Binding, Sequence Numbers, Freshness and Replay
       Protection  . . .  21
       5.1.1.  Examples in Group Mode  . . . . . . . . . . . . . . .  22
       5.1.2.  Examples in Pairwise Mode . . . . . . .  19
     6.1.  Synchronization of Sender Sequence Numbers . . . . . . .  19
   7.  23
   6.  Message Processing  . Binding, Sequence Numbers, Freshness and Replay
       Protection  . . . . . . . . . . . . . . . . . . . .  19
     7.1.  Protecting the Request . . . . .  24
     6.1.  Update of Replay Window . . . . . . . . . . . .  20
       7.1.1. . . . . .  24
   7.  Message Reception . . . . . . . . . . . . . . . . . . . . . .  24
   8.  Message Processing in Group Mode  . . . . . . . . . . . . . .  25
     8.1.  Protecting the Request  . . . . . . . . . . . . . . . . .  26
       8.1.1.  Supporting Observe  . . . . . . . . . . . . . . . . .  21
     7.2.  26
     8.2.  Verifying the Request . . . . . . . . . . . . . . . . . .  21
       7.2.1.  26
       8.2.1.  Supporting Observe  . . . . . . . . . . . . . . . . .  22
     7.3.  27

     8.3.  Protecting the Response . . . . . . . . . . . . . . . . .  22
       7.3.1.  28
       8.3.1.  Supporting Observe  . . . . . . . . . . . . . . . . .  23
     7.4.  28
     8.4.  Verifying the Response  . . . . . . . . . . . . . . . . .  23
       7.4.1.  29
       8.4.1.  Supporting Observe  . . . . . . . . . . . . . . . . .  24
   8.  Responsibilities of the Group Manager .  30
   9.  Message Processing in Pairwise Mode . . . . . . . . . . .  24
   9.  Optimized Mode . .  30
     9.1.  Pre-Conditions  . . . . . . . . . . . . . . . . . . . . .  25
     9.1.  Optimized  31
     9.2.  Protecting the Request  . . . . . . . . . . . . . . . . .  31
     9.3.  Verifying the Request . . .  25
       9.1.1.  Optimized Compressed Request . . . . . . . . . . . .  25
     9.2.  Optimized Response . . .  32
     9.4.  Protecting the Response . . . . . . . . . . . . . . . .  26
       9.2.1.  Optimized Compressed .  32
     9.5.  Verifying the Response  . . . . . . . . . . . .  26 . . . . .  33
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  26  33
     10.1.  Group-level Security . . . . . . . . . . . . . . . . . .  27  34
     10.2.  Uniqueness of (key, nonce) . . . . . . . . . . . . . . .  28  35
     10.3.  Management of Group Keying Material  . . . . . . . . . .  28  35
     10.4.  Update of Security Context and Key Rotation  . . . . . .  29  36
       10.4.1.  Late Update on the Sender  . . . . . . . . . . . . .  29  36
       10.4.2.  Late Update on the Recipient . . . . . . . . . . . .  30  37
     10.5.  Collision of Group Identifiers . . . . . . . . . . . . .  30  37
     10.6.  Cross-group Message Injection  . . . . . . . . . . . . .  30
     10.7.  Group OSCORE for Unicast Requests  38
       10.6.1.  Attack Description . . . . . . . . . . .  32
     10.8.  End-to-end Protection . . . . . .  38
       10.6.2.  Attack Prevention in Group Mode  . . . . . . . . . .  39
     10.7.  Group OSCORE for Unicast Requests  . . . .  33
     10.9.  Security Context Establishment . . . . . . .  40
     10.8.  End-to-end Protection  . . . . . .  33
     10.10. . . . . . . . . . . .  41
     10.9.  Master Secret  . . . . . . . . . . . . . . . . . . . . .  34
     10.11.  41
     10.10. Replay Protection  . . . . . . . . . . . . . . . . . . .  34
     10.12.  42
     10.11. Client Aliveness . . . . . . . . . . . . . . . . . . . .  35
     10.13.  43
     10.12. Cryptographic Considerations . . . . . . . . . . . . . .  35
     10.14.  43
     10.13. Message Segmentation . . . . . . . . . . . . . . . . . .  36
     10.15.  44
     10.14. Privacy Considerations . . . . . . . . . . . . . . . . .  36  44
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  37  45
     11.1.  Counter Signature Parameters  OSCORE Flag Bits Registry  . . . . . . . . .  37
     11.2.  Counter Signature Key Parameters Registry . . . . . .  45
   12. References  .  40
     11.3.  OSCORE Flag Bits Registry . . . . . . . . . . . . . . .  42
     11.4.  Expert Review Instructions . . . . . . . . .  45
     12.1.  Normative References . . . . . .  42
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  43
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  43  45
     12.2.  Informative References . . . . . . . . . . . . . . . . .  44  47
   Appendix A.  Assumptions and Security Objectives  . . . . . . . .  46  49
     A.1.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .  47  49
     A.2.  Security Objectives . . . . . . . . . . . . . . . . . . .  48  51
   Appendix B.  List of Use Cases  . . . . . . . . . . . . . . . . .  49  52
   Appendix C.  Example of Group Identifier Format . . . . . . . . .  51  54
   Appendix D.  Set-up of New Endpoints  . . . . . . . . . . . . . .  52  55
   Appendix E.  Examples of Synchronization Approaches . . . . . . .  53  56
     E.1.  Best-Effort Synchronization . . . . . . . . . . . . . . .  53  56
     E.2.  Baseline Synchronization  . . . . . . . . . . . . . . . .  53  56
     E.3.  Challenge-Response Synchronization  . . . . . . . . . . .  54  57
   Appendix F.  No Verification of Signatures in Group Mode  . . . . . . . . . . .  56  60
   Appendix G.  Pairwise Mode  . . . . . . . . . . . . . . . . . . .  57
     G.1.  Pre-Requirements  . . . . . . . . . . . . .  Optimized Request  . . . . . . .  57
     G.2.  Pairwise Protected Request . . . . . . . . . .  60
   Appendix H.  Example Values of Parameters for Countersignatures .  61
   Appendix I.  Document Updates . . . .  57
     G.3.  Pairwise Protected Response . . . . . . . . . . . . . .  61
     I.1.  Version -08 to -09  .  58
   Appendix H.  Document Updates . . . . . . . . . . . . . . . . . .  58
     H.1.  62
     I.2.  Version -07 to -08  . . . . . . . . . . . . . . . . . . .  58
     H.2.  62
     I.3.  Version -06 to -07  . . . . . . . . . . . . . . . . . . .  60
     H.3.  64
     I.4.  Version -05 to -06  . . . . . . . . . . . . . . . . . . .  60
     H.4.  64
     I.5.  Version -04 to -05  . . . . . . . . . . . . . . . . . . .  61
     H.5.  65
     I.6.  Version -03 to -04  . . . . . . . . . . . . . . . . . . .  61
     H.6.  65
     I.7.  Version -02 to -03  . . . . . . . . . . . . . . . . . . .  62
     H.7.  66
     I.8.  Version -01 to -02  . . . . . . . . . . . . . . . . . . .  63
     H.8.  67
     I.9.  Version -00 to -01  . . . . . . . . . . . . . . . . . . .  64  68
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  64  69
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  65  69

1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252] is a web
   transfer protocol specifically designed for constrained devices and
   networks [RFC7228].  Group communication for CoAP
   [I-D.ietf-core-groupcomm-bis] addresses use cases where deployed
   devices benefit from a group communication model, for example to
   reduce latencies, improve performance and reduce bandwidth
   utilization.  Use cases include lighting control, integrated building
   control, software and firmware updates, parameter and configuration
   updates, commissioning of constrained networks, and emergency
   multicast (see Appendix B).  This specification defines the security
   protocol for Group communication for CoAP
   [I-D.ietf-core-groupcomm-bis].

   Object Security for Constrained RESTful Environments (OSCORE)
   [RFC8613] describes a security protocol based on the exchange of
   protected CoAP messages.  OSCORE builds on CBOR Object Signing and
   Encryption (COSE) [RFC8152]
   [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] and
   provides end-to-end encryption, integrity, replay protection and
   binding of response to request between a sender and a recipient,
   independent of transport also in the presence of intermediaries.  To
   this end, a CoAP message is protected by including its payload (if
   any), certain options, and header fields in a COSE object, which
   replaces the authenticated and encrypted fields in the protected
   message.

   This document defines Group OSCORE, providing the same end-to-end
   security properties as OSCORE in the case where CoAP requests have
   multiple recipients.  In particular, the described approach defines
   how OSCORE should be is used in a group communication setting to provide source
   authentication for CoAP group requests, sent by a client to multiple
   servers, and for protection of the corresponding CoAP responses.

   Just like OSCORE, Group OSCORE provides source authentication is independent of transport layer and
   works wherever CoAP messages, by
   means of two does.  Group communication for CoAP
   [I-D.ietf-core-groupcomm-bis] uses UDP/IP multicast as the underlying
   data transport.

   As with OSCORE, it is possible methods.  The first method relies on a digital
   signature produced to combine Group OSCORE with the private key of the sender and embedded in
   the protected CoAP message.  The second method relies
   communication security on a symmetric
   key, which other layers.  One example is derived from a pairwise shared secred computed from the
   asymmetric keys use of the message sender and recipient.

   The second method is intended for one-to-one messages sent in the
   group.  These include all responses, as individually sent by servers,
   as well as requests addressed to an individual server.  For instance,
   such requests are sent as part of an exchange using the CoAP Echo
   option [I-D.ietf-core-echo-request-tag], or as part of a block-wise
   transfer [RFC7959] in the group, after the first block-wise request
   possibly targeting all servers in the group and including the CoAP
   Block2 option (see Section 2.3.6 of [I-D.ietf-core-groupcomm-bis]).

   Just like OSCORE, Group OSCORE is independent of transport layer and
   works wherever CoAP does.  Group communication for CoAP
   [I-D.ietf-core-groupcomm-bis] uses UDP/IP multicast as the underlying
   data transport.

   As with OSCORE, it is possible to combine Group OSCORE with
   communication security on other layers.  One example is the use of
   transport layer security, such as DTLS [RFC6347], between one client
   transport layer security, such as DTLS [RFC6347], between one client
   and one proxy (and vice versa), or between one proxy and one server
   (and vice versa), in order to protect the routing information of
   packets from observers.  Note that DTLS cannot be used [RFC6347] does not define how
   to secure messages sent over IP multicast.

   Group OSCORE defines different two modes of operation:

   o  In the signature group mode, Group OSCORE requests and responses are
      digitally signed.  The signed with the private key of the sender and the
      signature is embedded in the protected CoAP message.  The group
      mode supports all COSE algorithms as well as signature
      verification by intermediaries.  This mode is defined in Section 8
      and MUST be supported.

   o  The  In the pairwise mode allows mode, two group members to exchange unicast Group OSCORE
      requests and responses over unicast, and the messages are
      protected with symmetric keys.  These symmetric keys are derived
      from Diffie-Hellman shared secrets, calculated with the asymmetric
      keys of the two group
      members.  This allows sender and recipient, allowing for shorter integrity
      tags and therefore lower message overhead.

   o  In the (hybrid) optimized mode, the CoAP requests are digitally
      signed  This mode is OPTIONAL
      to support as defined in the signature mode, and the CoAP responses are
      integrity protected with the symmetric key of the pairwise mode.

   The signature and optimized Section 9.

   Both modes are detailed in the body provide source authentication of this
   document. CoAP messages.  The pairwise mode
   application decides what mode to use, potentially on a per-message
   basis.  Such decision can be based, for instance, on pre-configured
   policies or dynamic assessing of the target recipient and/or
   resource, among other things.  One important case is detailed when requests
   are protected with the group mode, and responses with the pairwise
   mode, since this significantly reduces the overhead in Appendix G.  Unless
   otherwise stated, case of many
   responses to one request.

   A special deployment of Group OSCORE is to use pairwise mode only.
   For example, consider the case of a constrained-node network
   [RFC7228] with a large number of CoAP endpoints and the objective to
   establish secure communication between any pair of endpoints with a
   small provisioning effort and message overhead.  Since the total
   number of security associations that needs to be established grows
   with the square of the number of nodes, it is desirable to restrict
   the provisioned keying material.  Moreover, a key establishment
   protocol would need to be executed for each security association.

   One solution to this specification refers is to deploy Group OSCORE with the signature endpoints
   being part of a group and use the pairwise mode.  This solution
   assumes a trusted third party called Group Manager (see Section 3),
   but has the benefit of restricting the symmetric keying material
   while distributing only the public key of each group member.  After
   that, a CoAP endpoint can locally derive the OSCORE Security Context
   for the other endpoint and protect the CoAP communication with very
   low overhead [I-D.ietf-lwig-security-protocol-comparison].

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Readers are expected to be familiar with the terms and concepts
   described in CoAP [RFC7252] including "endpoint", "client", "server",
   "sender" and "recipient"; group communication for CoAP
   [I-D.ietf-core-groupcomm-bis]; COSE and counter signatures [RFC8152].
   [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs].

   Readers are also expected to be familiar with the terms and concepts
   for protection and processing of CoAP messages through OSCORE, such
   as "Security Context" and "Master Secret", defined in [RFC8613].

   Terminology for constrained environments, such as "constrained
   device",
   device" and "constrained-node network", is defined in [RFC7228].

   This document refers also to the following terminology.

   o  Keying material: data that is necessary to establish and maintain
      secure communication among endpoints.  This includes, for
      instance, keys and IVs [RFC4949].

   o  Group: a set of endpoints that share group keying material and
      security parameters (Common Context, see Section 2).  Unless
      specified otherwise, the term group used in this specification
      refers thus to a "security group", group" (see Section 2.1 of
      [I-D.ietf-core-groupcomm-bis]), not to be confused with
      CoAP/network/multicast group "CoAP
      group" or application group. "application group".

   o  Group Manager: entity responsible for a group.  Each endpoint in a
      group communicates securely with the respective Group Manager,
      which is neither required to be an actual group member nor to take
      part in the group communication.  The full list of
      responsibilities of the Group Manager is provided in Section 8. 3.2.

   o  Silent server: member of a group that never responds sends protected
      responses in reply to requests.
      Given that, for  For CoAP group communications, messages
      requests are normally sent without requesting a confirmation, the idea of necessarily expecting a
      response.  A silent server
      silently acting on a message is not unreasonable. may send unprotected responses, as
      error responses reporting an OSCORE error.  Note that an endpoint
      can implement both a silent server and a client, i.e. the two
      roles are independent.  An endpoint implementing acting only as a silent server processes
      performs only Group OSCORE processing on incoming requests, and, in case it supports
      only the signature mode, it maintains requests.
      Silent servers maintain less keying material and
      especially does in particular do
      not have a Sender Context for the group.  Since silent servers do
      not have a Sender ID they cannot support pairwise mode.

   o  Group Identifier (Gid): identifier assigned to the group.  Group
      Identifiers must be group, unique
      within the set of groups of a given Group Manager.

   o  Group request: CoAP request message sent by a client in the group
      to all servers in that group.

   o  Source authentication: evidence that a received message in the
      group originated from a specific identified group member.  This
      also provides assurance that the message was not tampered with by
      anyone, be it a different legitimate group member or an endpoint
      which is not a group member.

2.  Security Context

   This specification refers to a group as a set of endpoints sharing
   keying material and security parameters for executing the Group
   OSCORE protocol (see Section 1.1).  Each endpoint registered as which is member of
   a group maintains a Security Context as defined in Section 3 of
   [RFC8613], extended as follows (see Figure 1):

   o  One Common Context, shared by all the endpoints in the group.
      Three new parameters are included in the Common Context: Counter
      Signature Algorithm, Counter Signature Parameters and Counter
      Signature Key Parameters. Parameters, which all relate to the signature of the
      message included in group mode (see Section 8).

   o  One Sender Context, extended with the endpoint's private key.  The
      private key is used to sign the message in group mode, and for
      calculating the pairwise keys in pairwise mode (see Section 2.3).
      If the pairwise mode is supported, the Sender Context is also
      extended with the Pairwise Sender Keys associated to the other
      endpoints (see Section 2.3).  The Sender Context is omitted if the
      endpoint is configured exclusively as silent server.

   o  One Recipient Context for each endpoint from which messages are
      received.  No  It is not necessary to maintain Recipient Contexts are maintained as
      associated to endpoints from which messages are not (expected to
      be) received.  The Recipient Context is extended with the public
      key of the associated endpoint.

       +---------------------------+----------------------------------+ endpoint, used to verify the signature in
      group mode and for calculating the pairwise keys in pairwise mode
      (see Section 2.3).  If the pairwise mode is supported, then the
      Recipient Context is also extended with the Pairwise Recipient Key
      associated to the other endpoint (see Section 2.3).

   +-------------------+-----------------------------------------------+
   | Context Component | New Information Elements                      |
       +---------------------------+----------------------------------+
   +-------------------+-----------------------------------------------+
   |                   | Counter Signature Algorithm                   |
   | Common Context    | Counter Signature Parameters                  |
   |                   | Counter Signature Key Parameters              |
       +---------------------------+----------------------------------+
   +-------------------+-----------------------------------------------+
   | Sender Context    | Endpoint's own private key                    |
       +---------------------------+----------------------------------+
   |                   | *Pairwise Sender Keys for the other endpoints |
   +-------------------+-----------------------------------------------+
   | Each Recipient Context              | Public key of the other endpoint              |
       +---------------------------+----------------------------------+
   | Recipient Context | *Pairwise Recipient Key of the other endpoint |
   +-------------------+-----------------------------------------------+

       Figure 1: Additions to the OSCORE Security Context.  Optional
                  additions are labeled with an asterisk.

   Further details about the Security Context

2.1.  Common Context

   The ID Context parameter (see Sections 3.3 and 5.1 of [RFC8613]) Group OSCORE are
   provided in the Common Context SHALL contain the Group Identifier (Gid) remainder of this section.  How the
   group. Security Context
   is established by the group members is out of scope for this
   specification, but if there is more than one Security Context
   applicable to a message, then the endpoints MUST be able to tell
   which Security Context was latest established.

   The default setting for how to manage information about the group is
   described in terms of a Group Manager (see Section 3).

2.1.  Common Context

   The Common Context may be acquired from the Group Manager (see
   Section 3).  The following sections define how the Common Context is
   extended, compared to [RFC8613].

2.1.1.  ID Context

   The ID Context parameter (see Sections 3.3 and 5.1 of [RFC8613]) in
   the Common Context SHALL contain the Group Identifier (Gid) of the
   group.  The choice of the Gid format is application specific.  An
   example of specific formatting of the Gid is given in Appendix C.

   The application needs to specify how to handle possible potential collisions
   between Gids, see Gids (see Section 10.5.

   The 10.5).

2.1.2.  Counter Signature Algorithm

   Counter Signature Algorithm identifies the digital signature
   algorithm used to compute a counter signature on the COSE object (see
   Section 4.5 5.2 of [RFC8152]).  Its value [I-D.ietf-cose-rfc8152bis-struct]).

   This parameter is immutable once the Common Context is established.  The used
   Counter Signature Algorithm MUST be
   selected among take value from the signing ones defined "Value" column
   of the "COSE Algorithms" Registry [COSE.Algorithms].  The value is
   associated to a COSE key type, specified in the "Capabilities" column
   of the Registry.  COSE Algorithms
   Registry (see section 16.4 capabilities for algorithms are defined in
   Section 8 of [RFC8152]). [I-D.ietf-cose-rfc8152bis-algs].

   The EdDSA signature algorithm Ed25519 [RFC8032] is mandatory to
   implement.  If Elliptic
   Curve Digital Signature Algorithm (ECDSA)  For endpoints that support the pairwise mode of Group
   OSCORE, the X25519 function [RFC7748] is also mandatory to implement.
   If elliptic curve signatures are used, it is RECOMMENDED
   that implementations to implement "deterministic ECDSA"
   deterministic signatures with additional randomness as specified in
   [RFC6979].

   The
   [I-D.mattsson-cfrg-det-sigs-with-noise].

2.1.3.  Counter Signature Parameters

   Counter Signature Parameters identifies the parameters associated to
   the digital signature algorithm specified in the Counter Signature
   Algorithm.  This parameter MAY be empty and is immutable once the Common Context is
   established.  The

   This parameter is a CBOR array including the following two elements,
   whose exact structure of this parameter
   depends and value depend on the value of Counter
   Signature Algorithm, and Algorithm:

   o  The first element is defined
   in the Counter Signature Parameters Registry (see Section 11.1),
   where each entry indicates a specified structure array of the COSE capabilities for Counter
      Signature Parameters. Algorithm, as specified for that algorithm in the
      "Capabilities" column of the "COSE Algorithms" Registry
      [COSE.Algorithms] (see Section 8.2 of
      [I-D.ietf-cose-rfc8152bis-algs]).

   o  The second element is the array of COSE capabilities for the COSE
      key type associated to Counter Signature Algorithm, as specified
      for that key type in the "Capabilities" column of the "COSE Key
      Types" Registry [COSE.Key.Types] (see Section 8.1 of
      [I-D.ietf-cose-rfc8152bis-algs]).

   Examples of Counter Signature Parameters are in Appendix H.

2.1.4.  Counter Signature Key Parameters

   Counter Signature Key Parameters identifies the parameters associated
   to the keys used with the digital signature algorithm specified in the
   Counter Signature Algorithm.  This parameter MAY be
   empty and is immutable once the
   Common Context is established.

   The exact structure and value of this parameter depends on the value
   of Counter Signature Algorithm, Algorithm.  In particular, this parameter takes
   the same structure and is defined in value of the array of COSE capabilities for
   the COSE key type associated to Counter Signature Algorithm, as
   specified for that key type in the "Capabilities" column of the "COSE
   Key
   Parameters Types" Registry [COSE.Key.Types] (see Section 11.2), where each entry indicates a
   specified structure 8.1 of
   [I-D.ietf-cose-rfc8152bis-algs]).

   Examples of the Counter Signature Key Parameters. Parameters are in Appendix H.

2.2.  Sender Context and Recipient Context

   OSCORE specifies the derivation of Sender Context and Recipient
   Context, specifically of Sender/Recipient Keys and Common IV, from a
   set of input parameters (see Section 3.2 of [RFC8613]).  This
   derivation applies also to Group OSCORE, and the mandatory-to-implement mandatory-to-
   implement HKDF and AEAD algorithms are the same as in [RFC8613].  However,  The
   Sender ID SHALL be unique for each endpoint in a group with a fixed
   Master Secret, Master Salt and Group Identifier (see Section 3.3 of
   [RFC8613]).

   For Group OSCORE the Sender Context and Recipient Context
   additionally contain asymmetric keys. keys, as described previously in
   Section 2.  The Sender Context needs to be configured with the private private/public key pair of the
   endpoint.  The private key is used to generate a signature (see
   Section 4) included in sender can, for
   example, be generated by the sent OSCORE message.  How endpoint or provisioned during
   manufacturing.

   With the private key
   is established is out exception of scope for this specification.

   Each Recipient Context needs to be configured with the public key of the associated endpoint.  The public key is used to verify sending endpoint, a
   receiving endpoint can derive a complete security context from a
   signature (see Section 4) included in the
   received Group OSCORE message.

   The input parameters for deriving the Recipient Context parameters message and the Common Context.  The public key of
   keys in the associated endpoint may Recipient Contexts can be provided to accessed from the
   recipient endpoint Group Manager
   (see Section 3) upon joining the group.  These parameters may  A public key can
   alternatively be acquired from the Group Manager at a later time, for
   example the first time a message is received from this a particular
   endpoint in the group (see Section 7.2 8.2 and Section 7.4).  The received message together with the
   Common Context contains the necessary information to derive a
   security context for verifying a message, except for the public key
   of the associated endpoint. 8.4).

   For severely constrained devices, it may be not feasible to
   simultaneously handle the ongoing processing of a recently received
   message in parallel with the retrieval of the associated endpoint's
   public key.  Such devices can be configured to drop a received
   message for which there is no (complete) Recipient Context, and
   retrieve the public key in order to have it available to verify
   subsequent messages from that endpoint.

2.3.  The Group Manager

   Endpoints communicating with  Pairwise Keys

   Certain signature schemes, such as EdDSA and ECDSA, support a secure
   combined signature and encryption scheme.  This section specifies the
   derivation of "pairwise keys", for use in the pairwise mode of Group
   OSCORE need, defined in addition to Section 9.

2.3.1.  Derivation of Pairwise Keys

   Using the Group OSCORE input parameters, also Security Context (see Section 2), a group
   member can derive AEAD keys to be provisioned with information
   about the group(s) protect point-to-point communication
   between itself and any other endpoints endpoint in the group(s). group.  The Group Manager is an entity responsible for the group, including
   the Group Identifier (Gid) used as ID Context, as well same AEAD
   algorithm as the Sender
   ID and Recipient ID of in the group members (see Section 8).

   The Group Manager mode is exclusively in control used.  The key derivation of these
   so-called pairwise keys follows the Gid values
   uniquely assigned to the different groups under its control, as well same construction as in
   Section 3.2.1 of the [RFC8613]:

   Pairwise Recipient Key = HKDF(Recipient Key, Shared Secret, info, L)
   Pairwise Sender ID and Key    = HKDF(Sender Key, Shared Secret, info, L)

   where:

   o  The Pairwise Recipient ID values uniquely assigned to Key is the
   members of each of those groups.  According to a hierarchical
   approach, AEAD key for receiving from
      endpoint X.

   o  The Pairwise Sender Key is the Gid value assigned AEAD key for sending to a group endpoint X.

   o  The Shared Secret is associated to computed as a
   dedicated space for static-static Diffie-Hellman
      shared secret [NIST-800-56A], where the values of Sender ID endpoint uses its private
      key and Recipient ID of the
   members public key of that group.  In addition, the Group Manager records other endpoint X.

   o  The Recipient Key and the public keys of endpoints joining a group, and provides information
   about key are from the group and its members Recipient
      Context associated to other members.

   An endpoint receives the Group Identifier and OSCORE input
   parameters, including its own X.

   o  The Sender ID, Key and private key are from the Group Manager upon
   joining the group.  That Sender ID is valid only within that group, Context.

   o  info and is unique within the group.  Endpoints which L are configured only defined as silent servers do not have a Sender ID.

   A group member can retrieve from in Section 3.2.1 of [RFC8613].

   If EdDSA asymmetric keys are used, the Group Manager Edward coordinates are mapped
   to Montgomery coordinates using the public key maps defined in Sections 4.1 and
   other information associated to another group member, with which it
   can generate
   4.2 of [RFC7748], before using the corresponding Recipient Context.  An application can
   configure X25519 and X448 functions defined
   in Section 5 of [RFC7748].

   After establishing a partially or completely new Security Context
   (see Section 3.1 and Section 2.4), the old pairwise keys MUST be
   deleted.  Since new Sender/Recipient Keys are derived from the new
   group keying material (see Section 2.2), every group member to asynchronously retrieve information about
   Recipient Contexts, e.g. by Observing [RFC7641] MUST use
   the Group Manager to
   get new Sender/Recipient Keys when deriving new pairwise keys.

   As long as any two group members preserve the same asymmetric keys,
   their Diffie-Hellman shared secret does not change across updates on of
   the group membership.

   According to this specification, it is RECOMMENDED to use keying material.

2.3.2.  Usage of Sequence Numbers

   When using any of its Pairwise Sender Keys, a Group
   Manager as described in [I-D.ietf-ace-key-groupcomm-oscore], where
   the join process is based on sender endpoint
   including the ACE framework for authentication and
   authorization in constrained environments [I-D.ietf-ace-oauth-authz].
   Further details about how public keys can be handled and retrieved 'Partial IV' parameter in the group is out of protected message MUST
   use the scope of this document.

   The Group Manager may serve additional entities acting as signature
   checkers, e.g. intermediary gateways.  These entities do not join a
   group as members, but can retrieve public keys current fresh value of group members the Sender Sequence Number from its
   Sender Context (see Section 2.2).  That is, the Group Manager, in order to verify counter signatures of group
   messages.  A signature checker same Sender Sequence
   Number space is required to be authorized used for
   retrieving public keys of members in a specific group from the all outgoing messages protected with Group
   Manager.  To this end,
   OSCORE, thus limiting both storage and complexity.

   On the same method mentioned above other hand, when combining group and based on pairwise communication
   modes, this may result in the ACE framework Partial IV values moving forward more
   often.  This can be used.

2.4.  Management of Group Keying Material

   In order to establish happen when a new Security Context client engages in a group, a new Group
   Identifier (Gid) for that group and a new value for the Master Secret
   parameter MUST be distributed.  An example frequent or long
   sequences of Gid format supporting
   this operation is provided one-to-one exchanges with servers in Appendix C.  When distributing the new
   Gid and Master Secret, the Group Manager MAY distribute also group, by
   sending requests over unicast.

   As a new
   value for consequence, replay checks may be invoked more often on the Master Salt parameter, and SHOULD preserve
   recipient side, where larger replay windows should be considered.

2.3.3.  Security Context for Pairwise Mode

   If the current
   value of pairwise mode is supported, the Sender ID of each group member.

   Then, each group member re-derives pairwise keys are added to the keying material stored in its
   own Sender Context and Recipient Contexts
   Security Context, as described in at the beginning of Section 2,
   using 2.

   The pairwise keys as well as the updated Gid and Master Secret parameter. shared secrets used in their
   derivation (see Section 2.3.1) may be stored in memory or recomputed
   each time they are needed.  The Master Salt shared secret changes only when a
   public/private key pair used for its derivation changes, which
   results in the re-derivations is pairwise keys also changing.  Additionally, the updated Master Salt parameter
   pairwise keys change if
   provided by the Group Manager, or the empty byte string otherwise.
   From then on, each group member MUST use its latest installed Sender
   Context to protect outgoing messages.

   After a new Gid has been distributed, a same Recipient ID ('kid')
   should not be considered as changes or if a persistent and reliable indicator of new Security
   Context is established for the same group member.  Such an indication can be actually achieved
   only by using that members's public key.  This occurs when verifying
   countersignatures of received messages (in signature mode), or when
   verifying messages integrity-protected with pairwise keying material (see Section 2.4.3).  In order
   to optimize protocol performance, an endpoint may store the derived from asymmetric
   pairwise keys (in for easy retrieval.

   In the pairwise mode).  As a consequence,
   group members may end up retaining stale Recipient Contexts, that are
   no longer useful to verify incoming secure messages. mode, the Sender Context includes the Pairwise Sender
   Keys for the other endpoints (see Figure 1).  In order to alleviate this issue, identify
   the Group Manager SHOULD NOT
   recycle 'kid' values within a same group, especially in right key to use, the short
   term.  Furthermore, applications Pairwise Sender Key for endpoint X may define policies to: i) delete
   (long-)unused Recipient Contexts and reduce be
   associated to the impact on storage
   space; as well Recipient ID of endpoint X, as ii) check with defined in the Group Manager that an owned
   public key is currently
   Recipient Context (i.e. the one associated to a 'kid' value, after a
   number Sender ID from the point of consecutive failed verifications.

   The distribution view of a new Gid and Master Secret may result in
   temporarily misaligned Security Contexts among group members.
   endpoint X).  In
   particular, this may result in a group member not able way, the Recipient ID can be used to process
   messages received lookup for
   the right after a new Gid and Master Secret have been
   distributed.  A discussion on practical consequences and possible
   ways to address them is provided Pairwise Sender Key. This association may be implemented in Section 10.4.

   If required
   different ways, e.g. by storing the application (see Appendix A.1), it is RECOMMENDED
   to adopt a group key management scheme, and securely distribute pair (Recipient ID, Pairwise
   Sender Key), or linking a new
   value for the Gid and for the Master Secret parameter Pairwise Sender Key to a Recipient Context.

2.4.  Update of Security Context

   The mutable parts of the group's Security Context, before a new joining endpoint is added to Context are updated by the group
   or after a currently present endpoint leaves
   when executing the group.  This is
   necessary to preserve backward security and forward security in the
   group, if the application requires it.

   The specific approach used to distribute the new Gid and Master
   Secret parameter protocol, but may nevertheless become
   outdated, e.g. due to the group is out of the scope of this document.
   However, it is RECOMMENDED that the Group Manager supports the
   distribution loss of the new Gid and Master Secret parameter to the group
   according to the Group Rekeying Process described in
   [I-D.ietf-ace-key-groupcomm-oscore].

2.5.  Exhaustion mutable Security Context (see
   Section 2.4.1) or exhaustion of Partial IV Values

   An endpoint can eventually exhaust its own Sender Sequence Number,
   which is incremented after sending each new message including Numbers (see
   Section 2.4.2).  The endpoint MUST be able to detect a
   Partial IV.  This is the case for all group requests, all Observe
   notifications [RFC7641] and, optionally, any other response. loss of
   mutable security context (see Section 2.4.1).  If an implementation's integers only support wrapping addition, the
   implementation MUST detect endpoint detects
   a wrap-around loss of the Sender Sequence
   Number value and treat that as exhausted instead.

   Upon exhausting its own mutable Sender Sequence Number, the endpoint Security Context, it MUST NOT
   transmit protect
   further messages for that group until it has derived a new
   Sender Context, in order using this Security Context to avoid reusing nonces a nonce
   with the same keys.

   Furthermore, AEAD key.

   It is RECOMMENDED that the endpoint SHOULD inform immutable part of the Group Manager, Security Context is
   stored in non-volatile memory, or that it can
   take one otherwise be reliably
   accessed throughout the operation of the following actions:

   o  The Group Manager renews group, e.g. after device
   reboot.  However, also immutable parts of the Security Context may
   need to be updated, for example due to scheduled key renewal, new or
   re-joining members in the group (see
      Section 2.4).

   o  The Group Manager provides a new Sender ID value to group, or the endpoint fact that has experienced the exhaustion.  Then, the endpoint derives a
      new Sender Context using the new
   changes Sender ID, as described in ID (see Section 3.2 2.4.3).

2.4.1.  Loss of [RFC8613].

   In either case, same considerations from Section 2.4 hold about
   possible retaining Mutable Security Context

   An endpoint losing its mutable Security Context, e.g., due to reboot,
   needs to prevent the re-use of stale Recipient Contexts.

3.  Pairwise Keys

   Certain signature schemes, such as EdDSA Sender Sequence Numbers, and ECDSA, support a to handle
   incoming replayed messages.  Appendix B.1 of [RFC8613] describes
   secure
   combined signature procedures for handling the loss of Sender Sequence Number and encryption scheme.  This section specifies
   the
   derivation update of pairwise encryption keys for use Replay Window.  The procedure in the pairwise and
   optimized modes Appendix B.1.1 of
   [RFC8613] applies also to servers in Group OSCORE.

3.1.  Key Derivation

   Two group members can derive a symmetric pairwise key, from their
   Sender/Recipient Key OSCORE and a static-static Diffe-Hellman shared secret
   [NIST-800-56A].  The key derivation is as follows, and uses the same
   construction used RECOMMENDED
   to use.  A variant of Appendix B.1.2 of [RFC8613] applicable to Group
   OSCORE is specified in Section 3.2.1 Appendix E.3 of [RFC8613].

   Pairwise key = HKDF(Sender/Recipient Key, Shared Secret, info, L)

   where:

   o  The Sender/Recipient key this specification.

   If an endpoint is the not able to establish an updated Sender Key Security
   Context, e.g. because of lack of connectivity with the sender, i.e. the
      Recipient Key that Group Manager,
   it MUST NOT protect further messages using this Security Context.
   The endpoint SHOULD inform the recipient stores in its own Recipient Group Manager and retrieve new
   Security Context corresponding to parameters from the sender.

   o  The Shared Secret is computed as Group Manager (see
   Section 2.4.3).

2.4.2.  Exhaustion of Sender Sequence Numbers

   An endpoint can eventually exhaust the Sender Sequence Numbers, which
   are incremented for each new outgoing message including a static-static Diffie-Hellman
      shared secret [NIST-800-56A], where Partial IV.
   This is the sender uses its own
      private key and case for group requests, Observe notifications [RFC7641]
   and, optionally, any other response.

   If an implementation's integers support wrapping addition, when a
   wrap-around is detected the recipient's public key, while implementation MUST treat Sender Sequence
   Numbers as exhausted.

   Upon exhausting the recipient
      uses its own private key and Sender Sequence Numbers, the senders's public key. endpoint MUST NOT
   protect further messages using this Security Context.  The Shared
      Secret may be stored in memory, rather than recomputed each time
      it is needed.

   o  info endpoint
   SHOULD inform the Group Manager and L are defined as in retrieve new Security Context
   parameters from the Group Manager (see Section 3.2.1 of [RFC8613]. 2.4.3).

2.4.3.  Retrieving New Security Context Parameters

   The security Group Manager can assist an endpoint with an incomplete Sender
   Security Context to retrieve missing data of using the same key pair for Diffie-Hellman Security Context and for
   signing is proven
   thereby become fully operational in [Degabriele]. the group again.  The derivation two main
   options are described in this section: i) assignment of pairwise keys
   defined above is compatible with ECDSA a new Sender
   ID (see Section 2.4.3.1); and EdDSA asymmetric keys, but
   is not compatible with RSA asymmetric keys.

   If EdDSA asymmetric keys are used, the Edward coordinates are mapped
   to Montgomery coordinates using the maps defined in Sections 4.1 and
   4.2 of [RFC7748], before using the X25519 and X448 functions defined
   in Section 5 of [RFC7748].

   After completing the ii) establishment of a new Security
   Context (see
   Section 2.4), every group member MUST delete all its pairwise keys.
   Since new Sender/Recipient keys are derived from for the new group keying
   material (see Section 2.2), every group member MUST use such new
   Sender/Recipient keys when possibly deriving new pairwise keys. 2.4.3.2).  Update of Replay Window
   in Recipient Contexts is discussed in Section 6.1.

   As long group membership changes, or as any two group members preserve the same asymmetric keys,
   the Diffie-Hellman shared secret does not change across updates of
   the group keying material.

3.2.  Usage of Sequence Numbers

   When using any of its pairwise keys, a sender endpoint MUST use the
   current fresh value of its own Sender Sequence Number, from its own get new Sender Context IDs
   (see Section 2.2).  That is, the same Sender Sequence
   Number space is used for all outgoing messages sent to the group and
   protected with Group OSCORE, thus limiting both storage and
   complexity.

   On the other hand, when combining one-to-many and one-to-one
   communication in the group, this may result in the Partial IV values
   moving forward more often.  Fundamentally, this is due to 2.4.3.1) so do the fact relevant Recipient IDs that not all the recipients receive all messages from a given sender.
   For instance, requests sent over multicast (in signature mode) are
   addressed other
   endpoints need to the whole group, while requests sent over unicast (in
   signature mode or pairwise mode) are not. keep track of.  As a consequence, replay checks group members may
   end up retaining stale Recipient Contexts, that are no longer useful
   to verify incoming secure messages.

   The Recipient ID ('kid') SHOULD NOT be invoked more often on the
   recipient side, where larger replay windows should considered as a persistent and
   reliable indicator of a group member.  Such an indication can be considered.

3.3.  Note
   achieved only by using that member's public key, when verifying
   countersignatures of received messages (in group mode), or when
   verifying messages integrity-protected with pairwise keying material
   derived from asymmetric keys (in pairwise mode).

   Furthermore, applications MAY define policies to: i) delete
   (long-)unused Recipient Contexts and reduce the impact on Implementation

   In order storage
   space; as well as ii) check with the Group Manager that a public key
   is currently the one associated to optimize performance, an endpoint A a 'kid' value, after a number of
   consecutive failed verifications.

2.4.3.1.  New Sender ID for the Endpoint

   The Group Manager may derive assign the endpoint a pairwise
   key used with new Sender ID, leaving
   the Gid, Master Secret and Master Salt unchanged.  In this case the
   Group Manager MUST assign an endpoint B in unused Sender ID.  Having retrieved the OSCORE group only once,
   new Sender ID, and then
   store it in its own potentially other missing data of the immutable
   Security Context for future retrieval.  This can
   work as follows.

   Endpoint A Context, the endpoint can have derive a Pairwise new Sender Context associated to B, within
   its own Sender Context.  This Pairwise (see
   Section 2.2).  The Sender Context includes:

   o Sequence Number is initialized to 0.

   The Recipient ID assignment of B for A, i.e. the a new Sender ID may be the result of B.

   o different
   processes.  The Pairwise Key derived as defined in Section 3, with A acting as
      sender and B acting as recipient.

   More generally, A has one of such Paiwise endpoint may request a new Sender Contexts within its
   own ID, e.g. because of
   exhaustion of Sender Context, for each different intended recipient.

   Furthermore, A can additionally store in its own Recipient Context
   associated Sequence Numbers (see Section 2.4.2).  An
   endpoint may request to B re-join the Pairwise Key to use for incoming traffic from B.
   That is, this Pairwise Key is derived as defined in group, e.g. because of losing its
   mutable Security Context (see Section 3, with A
   acting as recipient 2.4.1), and B acting receive as sender.

4.  The COSE Object

   Building on Section 5 of [RFC8613], this section defines how to use
   COSE [RFC8152] to wrap and protect data in the original message.
   OSCORE uses the untagged COSE_Encrypt0 structure with an
   Authenticated Encryption response
   a new Sender ID together with Associated Data (AEAD) algorithm.  For
   the signature mode of Group OSCORE the following modifications apply.

4.1.  Counter Signature latest immutable Security Context.

   The 'unprotected' field MUST additionally include the following
   parameter:

   o  CounterSignature0 : its value is set to the counter signature Recipient Context of the COSE object, computed by the sender as described in
      Appendix A.2 of [RFC8152], by using its own private key and
      according other group members corresponding to the Counter Signature Algorithm and Counter Signature
      Parameters in the
   old Sender ID becomes stale (see Section 3.1).

2.4.3.2.  New Security Context.  In particular, Context for the
      Sig_structure contains Group

   The Group Manager may establish a new Security Context for the external_aad as defined in group
   (see Section 4.3.2 and the ciphertext of the COSE_Encrypt0 object as
      payload.

4.2. 3.1).  The 'kid' and 'kid context' parameters

   The value of Group Manager does not necessarily establish
   a new Security Context for the 'kid' parameter group if one member has an outdated
   Security Context (see Section 2.4.3.1), unless that was already
   planned or required for other reasons.  All endpoints in the 'unprotected' field of
   response messages MUST be set group
   need to acquire new Security Context parameters from the Sender ID of the endpoint
   transmitting the message.  That is, unlike in [RFC8613], Group
   Manager.

   Having acquired new Security Context parameters, each member can re-
   derive the 'kid'
   parameter is always present keying material stored in all messages, i.e. both requests its Sender Context and
   responses. Recipient
   Contexts (see Section 2.2).  The value of Master Salt used for the 'kid context' re-
   derivations is the updated Master Salt parameter in if provided by the 'unprotected' field
   of requests messages MUST be set to
   Group Manager, or the ID Context, i.e. empty byte string otherwise.  Unless otherwise
   specified by the Group
   Identifier value (Gid) of application, a group member does not reset the group's Security Context.  That is,
   unlike
   Sender Sequence Number in [RFC8613], its Sender Context, and does not reset the 'kid context' parameter is always present
   Replay Windows in
   requests.

4.3.  external_aad its Recipient Contexts.  From then on, each group
   member MUST use its latest installed Sender Context to protect
   outgoing messages.

   The external_aad distribution of the Additional Authenticated Data (AAD) is built
   differently. a new Gid and Master Secret may result in
   temporarily misaligned Security Contexts among group members.  In
   particular, it has one structure used for the
   encryption process producing the ciphertext, and this may result in a second structure
   used for the signing group member not being able to
   process producing the counter signature.

4.3.1.  external_aad for Encryption

   The first external_aad structure used for the encryption process
   producing the ciphertext (see Section 5.3 of [RFC8152]) includes also
   the counter signature algorithm messages received right after a new Gid and related parameters used Master Secret
   have been distributed.  A discussion on practical consequences and
   possible ways to sign
   messages.  In particular, compared with Section 5.4 of [RFC8613], address them, as well as on how to handle the
   'algorithms' array old
   Security Context, is provided in Section 10.4.

3.  The Group Manager

   As with OSCORE, endpoints communicating with Group OSCORE need to
   establish the aad_array MUST also include:

   o  'alg_countersign', which contains relevant Security Context.  Group OSCORE endpoints need
   to acquire OSCORE input parameters, information about the Counter Signature Algorithm
      from group(s)
   and about other endpoints in the Common Context (see Section 2). group(s).  This parameter has the
      value specified in specification is
   based on the "Value" field existence of the Counter Signature
      Parameters Registry (see Section 11.1) for this counter signature
      algorithm.

   o  'par_countersign', an entity called Group Manager which contains the Counter Signature Parameters
      from is
   responsible for the Common Context (see Section 2).  This parameter contains group, but does not mandate how the counter signature parameters encoded as specified in Group Manager
   interacts with the
      "Parameters" field group members.  The responsibilities of the Counter Signature Parameters Registry
      (see Section 11.1), for the used counter signature algorithm.  If
      the Counter Signature Parameters Group
   Manager are compiled in the Common Context is empty,
      'par_countersign' MUST be encoding the CBOR simple value Null.

   o  'par_countersign_key', which contains the Counter Signature Key
      Parameters from the Common Context (see Section 2).  This
      parameter contains the counter signature key parameters encoded 3.2.

   It is RECOMMENDED to use a Group Manager as
      specified described in
   [I-D.ietf-ace-key-groupcomm-oscore], where the "Parameters" field of join process is based
   on the Counter Signature Key
      Parameters Registry (see Section 11.2), ACE framework for the used counter
      signature algorithm.  If the Counter Signature Key Parameters authentication and authorization in
   constrained environments [I-D.ietf-ace-oauth-authz].

   The Group Manager assigns unique Group Identifiers (Gids) to
   different groups under its control, as well as unique Sender IDs (and
   thereby Recipient IDs) to the Common Context is empty, 'par_countersign_key' MUST be
      encoding members of those groups.  According to
   a hierarchical approach, the CBOR simple Gid value Null.

   Thus, the following external_aad structure assigned to a group is used
   associated to a dedicated space for the encryption
   process producing values of Sender ID and
   Recipient ID of the ciphertext (see Section 5.3 members of [RFC8152]).

   external_aad = bstr .cbor aad_array

   aad_array = [
      oscore_version : uint,
      algorithms : [alg_aead : int / tstr,
                    alg_countersign : int / tstr,
                    par_countersign : any / nil,
                    par_countersign_key : any / nil],
      request_kid : bstr,
      request_piv : bstr,
      options : bstr
   ]

4.3.2.  external_aad for Signing

   The second external_aad structure used for that group.  In addition, the signing process
   producing Group
   Manager maintains records of the counter signature as defined below includes also:

   o public keys of endpoints in a group,
   and provides information about the counter signature algorithm group and related parameters used its members to
      sign messages, encoded as in the external_aad structure defined in
      Section 4.3.1;

   o other
   members and selected roles.  Upon nodes' joining, the value Group Manager
   collects such public keys and MUST verify proof-of-possession of the OSCORE Option included in
   respective private key.

   An endpoint acquires group data such as the Gid and OSCORE message,
      encoded as a binary string.

   Thus, input
   parameters including its own Sender ID from the following external_aad structure is used for the signing
   process producing Group Manager, and
   provides information about its public key to the counter signature, as defined below.

   external_aad = bstr .cbor aad_array

   aad_array = [
      oscore_version : uint,
      algorithms : [alg_aead : int / tstr,
                    alg_countersign : int / tstr,
                    par_countersign : any / nil,
                    par_countersign_key : any / nil],
      request_kid : bstr,
      request_piv : bstr,
      options : bstr,
      OSCORE_option: bstr
   ]

   Note Group Manager, for implementation: this requires
   example upon joining the value of group.

   A group member can retrieve from the OSCORE option
   to be fully ready, before starting Group Manager the signing process.  Also, this
   requires that public key and
   other information associated to another group member, with which it
   can generate the aad_array is long enough corresponding Recipient Context.  An application can
   configure a group member to contain asynchronously retrieve information about
   Recipient Contexts, e.g. by Observing [RFC7641] the longest
   possible OSCORE option.

5.  OSCORE Header Compression

   The OSCORE header compression defined in Section 6 of [RFC8613] is
   used, with Group Manager to
   get updates on the following differences.

   o group membership.

   The payload Group Manager MAY serve additional entities acting as signature
   checkers, e.g. intermediary gateways.  These entities do not join a
   group as members, but can retrieve public keys of group members from
   the OSCORE message SHALL encode the ciphertext Group Manager, in order to verify counter signatures of
      the COSE object.  In the group
   messages.  A signature mode as well as in the
      optimized compressed requests checker MUST be authorized for retrieving
   public keys of members in a specific group from the optimized mode (see
      Section 9.1.1), Group Manager.
   To this end, the ciphertext same method mentioned above is concatenated with based on the
      value ACE
   framework [I-D.ietf-ace-oauth-authz] can be used.

3.1.  Management of Group Keying Material

   In order to establish a new Security Context for a group, a new Group
   Identifier (Gid) for that group and a new value for the CounterSignature0 Master Secret
   parameter MUST be generated.  An example of the COSE object, computed as
      described Gid format supporting
   this operation is provided in Section 4.1.

   o  This specification defines Appendix C.  When distributing the usage of new
   Gid and Master Secret, the sixth least
      significant bit, namely Group Manager MAY distribute also a new
   value for the Pairwise Flag bit, in Master Salt parameter, and SHOULD preserve the first byte current
   value of the OSCORE option containing the OSCORE flag bits.  This flag
      bit is registered in Section 11.3 Sender ID of this specification.

   o each group member.

   The Pairwise Flag bit is set to 1 if the OSCORE message is
      protected using pairwise keying material, which is shared with Group Manager MUST NOT reassign a
      single group member as single intended recipient previously used Sender ID
   ('kid') with the same Gid, Master Secret and derived Master Salt.  Even if
   Gid and Master Secret are renewed as
      defined described in Section 3.  This is used, for instance, to send
      responses with this section, the optimized mode defined in Section 9.  In any
      other case,
   Group Manager SHOULD NOT reassign an endpoint's Sender ID ('kid')
   within a same group, especially when in the OSCORE message is protected as per
      Section 7.1 and Section 7.3, this bit MUST be set to 0. short term.

   If any of required by the following conditions holds, application (see Appendix A.1), it is RECOMMENDED
   to adopt a recipient MUST discard
      an incoming OSCORE message with the Pairwise Flag bit set to 1:

      *  The recipient does not support this feature, i.e. it is not
         capable or willing to process OSCORE messages protected using
         pairwise keying material.

      *  The recipient can not retrieve group key management scheme, and securely distribute a new
   value for the Gid and for the Master Secret parameter of the group's
   Security Context which Context, before a new joining endpoint is both
         valid added to process the message and also associated to an OSCORE group
   or after a currently present endpoint leaves the group.

5.1.  Examples of Compressed COSE Objects  This section covers a list of OSCORE Header Compression examples for
   group requests is
   necessary to preserve backward security and responses, with Group OSCORE used forward security in signature
   mode.

   The examples assume that the COSE_Encrypt0 object
   group, if the application requires it.

   The specific approach used to distribute new group data is set (which means out of the CoAP message and cryptographic material
   scope of this document.  However, it is known).  Note RECOMMENDED that the
   examples do not include Group
   Manager supports the full CoAP unprotected message or distribution of the full
   Security Context, but only new Gid and Master Secret
   parameter to the input necessary group according to the compression
   mechanism, i.e. Group Rekeying Process
   described in [I-D.ietf-ace-key-groupcomm-oscore].

3.2.  Responsibilities of the COSE_Encrypt0 object. Group Manager

   The output Group Manager is responsible for performing the
   compressed COSE object as defined in Section 5 following tasks:

   1.   Creating and divided into two
   parts, since the object is transported in two CoAP fields: managing OSCORE
   option and payload.

   The examples assume that the label for groups.  This includes the new kid context defined in
   [RFC8613] has value 10.  The examples also assume that
        assignment of a Gid to every newly created group, as well as
        ensuring uniqueness of Gids within the plaintext
   (see Section 5.3 set of [RFC8613]) is 6 bytes long, and that its OSCORE groups.

   2.   Defining policies for authorizing the AEAD tag
   is 8 bytes long, hence resulting in a ciphertext which is 14 bytes
   long.  Finally, COUNTERSIGN is joining of its OSCORE
        groups.

   3.   Handling the CounterSignature0 byte string join process to add new endpoints as
   described in Section 4 group members.

   4.   Establishing the Common Context part of the Security Context,
        and is 64 bytes long.

   1.  Request providing it to authorized group members during the join
        process, together with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid =
       0x25, Partial IV = 5 the corresponding Sender Context.

   5.   Generating and kid context = 0x44616c

   Before compression (96 bytes):

   [
   h'',
   { 4:h'25', 6:h'05', 10:h'44616c', 9:COUNTERSIGN },
   h'aea0155667924dff8a24e4cb35b9'
   ]

   After compression (85 bytes):

   Flag byte: 0b00011001 = 0x19

   Option Value: 19 05 03 44 61 6c 25 (7 bytes)

   Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 COUNTERSIGN
   (14 bytes + size managing Sender IDs within its OSCORE groups, as
        well as assigning and providing them to new endpoints during the
        join process.  This includes ensuring uniqueness of COUNTERSIGN)

   1.  Response with ciphertext = 0x60b035059d9ef5667c5a0710823b, kid =
       0x52 Sender IDs
        within each of its OSCORE groups.

   6.   Defining communication policies for each of its OSCORE groups,
        and no Partial IV.

   Before compression (88 bytes):

   [
   h'',
   { 4:h'52', 9:COUNTERSIGN },
   h'60b035059d9ef5667c5a0710823b'
   ]
   After compression (80 bytes):

   Flag byte: 0b00001000 = 0x08

   Option Value: 08 52 (2 bytes)

   Payload: 60 b0 35 05 9d 9e f5 66 7c 5a 07 10 82 3b COUNTERSIGN
   (14 bytes + size signalling them to new endpoints during the join process.

   7.   Renewing the Security Context of COUNTERSIGN)

6.  Message Binding, Sequence Numbers, Freshness an OSCORE group upon membership
        change, by revoking and Replay Protection

   The requirements renewing common security parameters and properties described in Section 7 of [RFC8613]
   also apply
        keying material (rekeying).

   8.   Providing the management keying material that a new endpoint
        requires to OSCORE participate in the rekeying process, consistent with
        the key management scheme used in the group communication.  In particular,
   group OSCORE provides message binding joined by the new
        endpoint.

   9.   Updating the Gid of responses its OSCORE groups, upon renewing the
        respective Security Context.

   10.  Acting as key repository, in order to requests, which
   provides relative freshness handle the public keys of responses, and replay protection
        the members of
   requests.

6.1.  Synchronization its OSCORE groups, and providing such public keys
        to other members of Sender Sequence Numbers

   Upon joining the group, new servers are not aware same group upon request.  The actual
        storage of the Sender
   Sequence Number values currently used by different clients public keys may be entrusted to
   transmit group requests.  This means that, when such servers receive a separate secure group request from a given client for
        storage device.

   11.  Validating that the first time, they format and parameters of public keys of
        group members are not able to verify if that request is fresh consistent with the countersignature algorithm
        and has not been
   replayed or (purposely) delayed. related parameters used in the respective OSCORE group.

   The same holds when a server loses
   synchronization with Sender Sequence Numbers of clients, for instance
   after a device reboot. Group Manager described in [I-D.ietf-ace-key-groupcomm-oscore]
   provides these functionalities.

4.  The exact way to address this issue is application specific, and
   depends COSE Object

   Building on the particular use case and its synchronization
   requirements.  The list Section 5 of methods [RFC8613], this section defines how to handle synchronization of
   Sender Sequence Numbers is part of the group communication policy,
   and different servers can use different methods.

   Appendix E describes three possible approaches that can be considered
   for synchronization of sequence numbers.

7.  Message Processing

   Each request message and response message is protected
   COSE [I-D.ietf-cose-rfc8152bis-struct] to wrap and processed
   as specified protect data in [RFC8613],
   the original message.  OSCORE uses the untagged COSE_Encrypt0
   structure with an Authenticated Encryption with Associated Data
   (AEAD) algorithm.  Unless otherwise specified, the following
   modifications described in apply for both the
   following sections.  In particular, group mode and the pairwise mode of
   Group OSCORE.

4.1.  Counter Signature

   For the group mode only, the 'unprotected' field MUST additionally
   include the following sections refer parameter:

   o  CounterSignature0: its value is set to the counter signature mode of Group OSCORE, while
      the optimized mode and COSE object, computed by the
   pairwise mode are sender as described in
      Section 9 5.2 of [I-D.ietf-cose-rfc8152bis-struct], by using the
      private key and Appendix G,
   respectively.

   The following security objectives are fulfilled, according to the Counter Signature Algorithm and
      Counter Signature Parameters in the Security Context.  In
      particular, the Sig_structure contains the external_aad as further discussed defined
      in Appendix A.2: data replay protection, group-level data
   confidentiality, source authentication Section 4.3.2 and message integrity.

   As per [RFC7252][I-D.ietf-core-groupcomm-bis], group requests sent
   over multicast MUST be Non-Confirmable, and thus cannot be
   retransmitted by the CoAP messaging layer.  Instead, applications
   should store such outgoing messages for a pre-defined, sufficient
   amount ciphertext of time, in order to correctly perform possible
   retransmissions at the application layer.  However, this does not
   prevent the acknowledgment COSE_Encrypt0 object as
      payload.

4.2.  The 'kid' and 'kid context' parameters

   The value of Confirmable group requests the 'kid' parameter in non-
   multicast environments.  Besides, according to Section 5.2.3 the 'unprotected' field of
   [RFC7252], responses to Non-Confirmable group requests SHOULD be also
   Non-Confirmable.  However, endpoints
   response messages MUST be prepared to receive
   Confirmable responses in reply set to a Non-Confirmable group request.

   Furthermore, endpoints in the group locally perform error handling
   and processing Sender ID of invalid messages according to the same principles
   adopted endpoint
   transmitting the message.  That is, unlike in [RFC8613].  However, a recipient MUST stop processing and
   silently reject any message which [RFC8613], the 'kid'
   parameter is malformed always present in all messages, both requests and does not follow
   responses.

   The value of the format specified in Section 4, or which is not cryptographically
   validated 'kid context' parameter in a successful way.  In either case, it is RECOMMENDED
   that the recipient does not send back any error message.  This
   prevents servers from replying with multiple error 'unprotected' field
   of requests messages MUST be set to a
   client sending a group request, so avoiding the risk ID Context, i.e. the Group
   Identifier value (Gid) of flooding and
   possibly congesting the group.

7.1.  Protecting the Request

   A client transmits a secure group request as described  That is, unlike in Section 8.1
   of [RFC8613], with
   the following modifications.

   o  In step 2, the 'algorithms' array 'kid context' parameter is always present in the requests.

4.3.  external_aad

   The external_aad of the Additional Authenticated Data (AAD) is modified as described in Section 4 of this specification.

   o
   different compared to OSCORE.  In step 4, the encryption of the COSE object particular, there is modified as
      described one
   external_aad used for encryption (both in Section 4 of this specification.  The encoding of the
      compressed COSE object is modified as described group mode and pairwise
   mode), and another external_aad used for signing (only in group
   mode).

4.3.1.  external_aad for Encryption

   The external_aad for encryption (see Section 5 6.3 of
      this specification.

   o  In step 5,
   [I-D.ietf-cose-rfc8152bis-struct]), used both in group mode and
   pairwise mode, includes also the counter signature is computed algorithm and the format
   related signature parameters, see Figure 2.

    external_aad = bstr .cbor aad_array

    aad_array = [
       oscore_version : uint,
       algorithms : [alg_aead : int / tstr,
                     alg_countersign : int / tstr,
                     par_countersign : [countersign_alg_capab,
                                        countersign_key_type_capab],
                     par_countersign_key : countersign_key_type_capab],
       request_kid : bstr,
       request_piv : bstr,
       options : bstr
    ]

                   Figure 2: external_aad for Encryption

   Compared with Section 5.4 of [RFC8613], the
      OSCORE message is modified as described 'algorithms' array in the
   aad_array additionally includes:

   o  'alg_countersign', which specifies Counter Signature Algorithm
      from the Common Context (see Section 4 and Section 5
      of this specification.  In particular, 2.1.2).  This parameter MUST
      encode the payload value of Counter Signature Algorithm as a CBOR integer
      or text string, consistently with the OSCORE
      message includes also "Value" field in the counter signature.

7.1.1.  Supporting Observe

   If Observe [RFC7641] is supported, "COSE
      Algorithms" Registry for each newly started
   observation, this counter signature algorithm.

   o  'par_countersign', which specifies the client MUST store CBOR array Counter
      Signature Parameters from the value Common Context (see Section 2.1.3).
      In particular:

      *  'countersign_alg_capab' is the array of COSE capabilities for
         the 'kid' parameter
   from countersignature algorithm indicated in 'alg_countersign'.

      *  'countersign_key_type_capab' is the original Observe request.

   The client MUST NOT update array of COSE capabilities
         for the stored value, even COSE key type used by the countersignature algorithm
         indicated in case it is
   individually rekeyed and receives a new Sender ID 'alg_countersign'.

   o  'par_countersign_key', which specifies Counter Signature Key
      Parameters from the Group
   Manager Common Context (see Section 2.5).

7.2.  Verifying 2.1.4).  In
      particular, 'countersign_key_type_capab' is the Request

   Upon receiving a secure group request, a server proceeds as described array of COSE
      capabilities for the COSE key type used by the countersignature
      algorithm indicated in 'alg_countersign'.

4.3.2.  external_aad for Signing

   The external_aad for signing (see Section 8.2 4.4 of [RFC8613],
   [I-D.ietf-cose-rfc8152bis-struct]) used in group mode is identical to
   the external_aad for encryption (see Section 4.3.1) with the following modifications.

   o  In step 2, addition
   of the decoding OSCORE option, see Figure 3.

    external_aad = bstr .cbor aad_array

    aad_array = [
       oscore_version : uint,
       algorithms : [alg_aead : int / tstr,
                     alg_countersign : int / tstr,
                     par_countersign : [countersign_alg_capab,
                                        countersign_key_type_capab],
                     par_countersign_key : countersign_key_type_capab],
       request_kid : bstr,
       request_piv : bstr,
       options : bstr,
       OSCORE_option: bstr
    ]

                    Figure 3: external_aad for Signing

   Compared with Section 5.4 of [RFC8613] the compressed COSE object follows aad_array additionally
   includes:

   o  the 'algorithms' array as defined in the external_aad for
      encryption, see Section 5 4.3.1;

   o  the value of the OSCORE Option encoded as a binary string.

   Note for implementation: this specification.  In particular:

      *  If construction requires the Pairwise Flag bit is set OSCORE option
   of the message to 1, and be generated before calculating the server discards signature.
   Also, the request due aad_array needs to not supporting this feature or not
         retrieving a Security Context associated be large enough to contain the largest
   possible OSCORE group,
         the server MAY respond with a 4.02 (Bad Option) error.  When
         doing so, the server MAY set an Outer Max-Age option with value
         zero, and MAY include a descriptive string as diagnostic
         payload.

      *  If the received Recipient ID ('kid') does not match with any
         Recipient Context for the retrieved Gid ('kid context'), then
         the server MAY create a new Recipient Context and initializes
         it according to option.

5.  OSCORE Header Compression

   The OSCORE header compression defined in Section 3 6 of [RFC8613], also retrieving the
         client's public key.  Such a configuration [RFC8613] is application
         specific.  If
   used, with the application does not specify dynamic
         derivation following differences.

   o  The payload of new Recipient Contexts, then the server OSCORE message SHALL
         stop processing encode the request.

   o ciphertext of
      the COSE object.  In step 4, the 'algorithms' array in group mode, the Additional Authenticated
      Data ciphertext above is modified
      concatenated with the value of the CounterSignature0 of the COSE
      object, computed as described in Section 4 of this specification. 4.1.

   o  In step 6, the server also verifies the counter signature using  This specification defines the public key usage of the client from sixth least
      significant bit, called the associated Recipient
      Context.  If "Group Flag", in the signature verification fails, first byte of the server MAY
      reply with a 4.00 (Bad Request) response.
      OSCORE option containing the OSCORE flag bits.  This flag bit is
      specified in Section 11.1.

   o  Additionally,  The Group Flag MUST be set to 1 if the used Recipient Context was created upon
      receiving this OSCORE message is protected
      using the group request and mode (see Section 8).

   o  The Group Flag MUST be set to 0 if the OSCORE message is not verified
      successfully, protected
      using the server MAY delete that Recipient Context.  Such pairwise mode (see Section 9).  The Group Flag MUST also
      be set to 0 for ordinary OSCORE messages processed according to
      [RFC8613].

5.1.  Examples of Compressed COSE Objects

   This section covers a configuration, which is specified by list of OSCORE Header Compression examples of
   Group OSCORE used in group mode (see Section 5.1.1) or in pairwise
   mode (see Section 5.1.2).

   The examples assume that the application, would
      prevent attackers from overloading COSE_Encrypt0 object is set (which means
   the server's storage CoAP message and
      creating processing overhead on cryptographic material is known).  Note that the server.

   A server SHOULD NOT process a request if
   examples do not include the received Recipient ID
   ('kid') is equal to its own Sender ID in its own Sender Context.

7.2.1.  Supporting Observe

   If Observe [RFC7641] is supported, for each newly started
   observation, full CoAP unprotected message or the server MUST store full
   Security Context, but only the value of input necessary to the 'kid' parameter
   from compression
   mechanism, i.e. the original Observe request. COSE_Encrypt0 object.  The server MUST NOT update output is the stored value, even
   compressed COSE object as defined in case Section 5 and divided into two
   parts, since the
   observer client object is individually rekeyed transported in two CoAP fields: OSCORE
   option and starts using a new Sender
   ID received from payload.

   The examples assume that the Group Manager plaintext (see Section 2.5).

7.3.  Protecting the Response

   A server 5.3 of [RFC8613])
   is 6 bytes long, and that has received a secure group request may reply with the AEAD tag is 8 bytes long, hence
   resulting in a
   secure response, ciphertext which is protected 14 bytes long.  When using the
   group mode, COUNTERSIGN denotes the CounterSignature0 byte string as
   described in Section 8.3 of
   [RFC8613], with the following modifications.

   o  In step 2, the 'algorithms' array in the Additional Authenticated
      Data is modified as described in Section 4 of this specification.

   o  In step 4, the encryption of the COSE object is modified as
      described in Section 4 of this specification.  The encoding of the
      compressed COSE object and is modified as described 64 bytes long.

5.1.1.  Examples in Section Group Mode

   o  Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid =
      0x25, Partial IV = 5 and kid context = 0x44616c

   Before compression (96 bytes):

   [
   h'',
   { 4:h'25', 6:h'05', 10:h'44616c', 9:COUNTERSIGN },
   h'aea0155667924dff8a24e4cb35b9'
   ]

   After compression (85 bytes):

   Flag byte: 0b00111001 = 0x39

   Option Value: 39 05 03 44 61 6c 25 (7 bytes)

   Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 COUNTERSIGN
   (14 bytes + size of
      this specification. COUNTERSIGN)

   o  In step 5, the counter signature is computed  Response with ciphertext = 0x60b035059d9ef5667c5a0710823b, kid =
      0x52 and the format no Partial IV.

   Before compression (88 bytes):

   [
   h'',
   { 4:h'52', 9:COUNTERSIGN },
   h'60b035059d9ef5667c5a0710823b'
   ]
   After compression (80 bytes):

   Flag byte: 0b00101000 = 0x28

   Option Value: 28 52 (2 bytes)

   Payload: 60 b0 35 05 9d 9e f5 66 7c 5a 07 10 82 3b COUNTERSIGN
   (14 bytes + size of the
      OSCORE mesage is modified as described COUNTERSIGN)

5.1.2.  Examples in Section Pairwise Mode

   o  Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid =
      0x25, Partial IV = 5 and kid context = 0x44616c

   Before compression (32 bytes):

   [
   h'',
   { 4:h'25', 6:h'05', 10:h'44616c' },
   h'aea0155667924dff8a24e4cb35b9'
   ]

   After compression (21 bytes):

   Flag byte: 0b00011001 = 0x19

   Option Value: 19 05 03 44 61 6c 25 (7 bytes)

   Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes)

   o  Response with ciphertext = 0x60b035059d9ef5667c5a0710823b, kid =
      0x52 and no Partial IV.

   Before compression (24 bytes):

   [
   h'',
   { 4:h'52'},
   h'60b035059d9ef5667c5a0710823b'
   ]
   After compression (16 bytes):

   Flag byte: 0b00001000 = 0x08

   Option Value: 08 52 (2 bytes)

   Payload: 60 b0 35 05 9d 9e f5 66 7c 5a 07 10 82 3b (14 bytes)

6.  Message Binding, Sequence Numbers, Freshness and Replay Protection

   The requirements and properties described in Section 7 of this
      specification.  In particular, the payload of the OSCORE message
      includes also the counter signature.

   Note that the server MUST always protect a response by using its own
   Sender Context from the latest owned Security Context.

   Consistently, upon the establishment of a new Security Context, the
   server may end up protecting a response by using a Security Context
   different from the one used [RFC8613]
   also apply to protect the OSCORE used in group request (see
   Section 10.4). communication.  In such a case:

   o  The particular,
   Group OSCORE provides message binding of responses to requests, which
   enables absolute freshness of responses that are not notifications,
   relative freshness of requests and notification responses, and replay
   protection of requests.

6.1.  Update of Replay Window

   A new server MUST encode joining a group may not be aware of the current Partial IV
   IVs (Sender Sequence Number in
      network byte order), which is set to the Sender Sequence Number Numbers of the server; increment the Sender Sequence Number by one; compute
      the AEAD nonce from the Sender ID, Common IV, and Partial IV.

   o clients).  The server MUST include in first time the response the 'Partial IV'
      parameter, which new
   server receives a request from a particular client, it is set not able to the encoded Partial IV value above.

   o
   verify if that request is a replay.  The same holds when a server SHOULD include in the response the 'kid context'
      parameter, which is set
   loses its mutable Security Context (see Section 2.4.1), for instance
   after a device reboot.

   The exact way to address this issue is application specific, and
   depends on the ID Context particular use case and its replay requirements.  The
   list of methods to handle the new Security
      Context, i.e. the new Group Identifier (Gid).

7.3.1.  Supporting Observe

   If Observe [RFC7641] update of a Replay Window is supported, part of
   the server may have ongoing
   observations, started by Observe requests group communication policy, and different servers can use
   different methods.

   Appendix E describes three possible approaches that can be considered
   to update a Replay Window.

7.  Message Reception

   Upon receiving a protected with an old
   Security Context.

   After completing the establishment of message, a recipient endpoint retrieves a new
   Security Context, the
   server MUST protect the following notifications with its own Sender Context from the new as in [RFC8613].  An endpoint MUST be able to
   distinguish between a Security Context.

   For each ongoing observation, the server SHOULD include Context to process OSCORE messages as
   in the first
   notification protected with the new [RFC8613] and a Security Context also the 'kid
   context' parameter, which is set to process Group OSCORE messages
   as defined in this specification.

   To this end, an endpoint can take into account the ID Context different
   structure of the new Security Context, i.e. the new Group Identifier (Gid).  It is
   OPTIONAL Context defined in Section 2, for example
   based on the server to include the 'kid context' parameter, as
   set to the new Gid, also presence of Counter Signature Algorithm in further following notifications for those
   observations.

   Furthermore, for each ongoing observation, the server MUST Common
   Context.  Alternatively implementations can use the
   stored value of the 'kid' parameter from the original Observe
   request, as value for the 'request_kid' an additional
   parameter in the two
   external_aad structures (see Section 4.3.1 and Section 4.3.2), when
   protecting notifications for Security Context, to explicitly signal that observation.

7.4.  Verifying the Response

   Upon receiving a secure response message, the client proceeds as
   described in Section 8.4 it is
   intended for processing Group OSCORE messages.

   If any of [RFC8613], with the following
   modifications.

   o  In step 2, the decoding of two conditions holds, a recipient endpoint
   MUST discard the compressed COSE object incoming protected message:

   o  The Group Flag is modified
      as described in Section 4 of this specification.  If set to 1, and the received
      Recipient ID ('kid') does recipient endpoint can not match with any Recipient
      retrieve a Security Context for which is both valid to process the retrieved Gid ('kid context'), then
      message and also associated to an OSCORE group.

   o  The Group Flag is set to 0, and the client MAY create recipient endpoint retrieves a
      new Recipient
      Security Context and initializes it according which is both valid to Section 3 of
      [RFC8613], also retrieving process the server's public key.  If message and
      also associated to an OSCORE group, but the
      application endpoint does not specify dynamic derivation of new Recipient
      Contexts, then the client SHALL stop processing
      support the response.

   o  In step 3, pairwise mode.

   Otherwise, if a Security Context associated to an OSCORE group and
   valid to process the 'algorithms' array in the Additional Authenticated
      Data message is modified as described in Section 4 of this specification.

   o  In step 5, retrieved, the client also verifies recipient endpoint
   processes the counter signature message with Group OSCORE, using the public key of group mode (see
   Section 8) if the server from Group Flag is set to 1, or the associated Recipient
      Context.

   o  Additionally, pairwise mode (see
   Section 9) if the used Recipient Context was created upon
      receiving this response and Group Flag is set to 0.

   Note that, if the message Group Flag is not verified
      successfully, set to 0, and the client MAY delete that Recipient Context.  Such recipient endpoint
   retrieves a configuration, Security Context which is specified by valid to process the application, would
      prevent attackers from overloading message
   but is not associated to an OSCORE group, then the client's storage and
      creating processing overhead on message is
   processed according to [RFC8613].

8.  Message Processing in Group Mode

   When using the client.

   Note that, group mode, messages are protected and processed as discussed
   specified in Section 10.4, a client may receive a
   response protected [RFC8613], with a Security Context different from the one modifications described in this
   section.  The security objectives of the group mode are discussed in
   Appendix A.2.  The group mode MUST be supported.

   The group mode MUST be used to protect the corresponding group request.

7.4.1.  Supporting Observe

   If Observe [RFC7641] is supported, requests intended for
   multiple recipients or for each ongoing observation, the
   client MUST use the stored value of the 'kid' parameter from whole group.  This includes both
   requests directly addressed to multiple recipients, e.g. sent by the
   original Observe request,
   client over multicast, as value for the 'request_kid' parameter in
   the two external_aad structures (see Section 4.3.1 and
   Section 4.3.2), when verifying notifications for that observation.

   This ensures that well as requests sent by the client can correctly verify notifications, even
   in case it is individually rekeyed and starts using over
   unicast to a new Sender ID
   received from the Group Manager (see Section 2.5).

8.  Responsibilities of the Group Manager

   The Group Manager is responsible for performing proxy, that forwards them to the following tasks:

   1.   Creating intended recipients
   over multicast [I-D.ietf-core-groupcomm-bis].

   As per [RFC7252][I-D.ietf-core-groupcomm-bis], group requests sent
   over multicast MUST be Non-Confirmable, and managing OSCORE groups.  This includes thus cannot be
   retransmitted by the
        assignment of CoAP messaging layer.  Instead, applications
   should store such outgoing messages for a Gid to every newly created group, as well as
        ensuring uniqueness of Gids within the set pre-defined, sufficient
   amount of its OSCORE groups.

   2.   Defining policies for authorizing time, in order to correctly perform possible
   retransmissions at the joining application layer.  According to Section 5.2.3
   of its OSCORE
        groups.

   3.   Handling the join process [RFC7252], responses to add new Non-Confirmable group requests SHOULD also
   be Non-Confirmable, but endpoints as MUST be prepared to receive
   Confirmable responses in reply to a Non-Confirmable group members.

   4.   Establishing the Common Context part of request.
   Confirmable group requests are acknowledged in non-multicast
   environments, as specified in [RFC7252].

   Furthermore, endpoints in the Security Context, group locally perform error handling
   and providing it processing of invalid messages according to authorized group members during the join
        process, together with the corresponding Sender Context.

   5.   Generating same principles
   adopted in [RFC8613].  However, a recipient MUST stop processing and managing Sender IDs within its OSCORE groups, as
        well as assigning
   silently reject any message which is malformed and providing them to new endpoints during does not follow
   the
        join process.  This includes ensuring uniqueness of Sender IDs
        within each of its OSCORE groups.

   6.   Defining format specified in Section 4, or which is not cryptographically
   validated in a communication policy for each of its OSCORE groups,
        and signalling successful way.  In either case, it to new endpoints during is RECOMMENDED
   that the join process.

   7.   Renewing recipient does not send back any error message.  This
   prevents servers from replying with multiple error messages to a
   client sending a group request, so avoiding the Security Context risk of an OSCORE group upon membership
        change, by revoking and renewing common security parameters flooding and
        keying material (rekeying).

   8.   Providing
   possibly congesting the management keying material that network.

8.1.  Protecting the Request

   A client transmits a new endpoint
        requires to participate secure group request as described in the rekeying process, consistent Section 8.1
   of [RFC8613], with the key management scheme used in following modifications.

   o  In step 2, the group joined by Additional Authenticated Data is modified as
      described in Section 4.

   o  In step 4, the new
        endpoint.

   9.   Updating encryption of the Gid COSE object is modified as
      described in Section 4.  The encoding of its OSCORE groups, upon renewing the
        respective Security Context.

   10.  Acting compressed COSE
      object is modified as key repository, described in order Section 5.  In particular, the
      Group Flag MUST be set to handle 1.

   o  In step 5, the public keys of counter signature is computed and the members format of its the
      OSCORE groups, message is modified as described in Section 4 and providing such public keys
        to other members
      Section 5.  In particular, the payload of the same group upon request.  The actual
        storage of public keys may be entrusted to a separate secure
        storage device.

   11.  Validating that OSCORE message
      includes also the format and parameters of public keys counter signature.

8.1.1.  Supporting Observe

   If Observe [RFC7641] is supported, for each newly started
   observation, the client MUST store the value of
        group members are consistent with the countersignature algorithm
        and related parameters used in 'kid' parameter
   from the respective OSCORE group.

9.  Optimized Mode

   For use cases that do not require an intermediary performing
   signature verification and that use a compatible signature algorithm, original Observe request.

   The client MUST NOT update the optimized mode defined stored value, even in this section provides significant
   smaller message sizes case it is
   individually rekeyed and increases receives a new Sender ID from the security by making responses
   confidential to other group members than Group
   Manager (see Section 2.4.3.1).

8.2.  Verifying the intended recipient.

9.1.  Optimized Request

   No changes.

9.1.1.  Optimized Compressed Request

   The OSCORE header compression defined in Section 5 is used,

   Upon receiving a secure group request with the Group Flag set to 1,
   following difference: the payload of the OSCORE message SHALL encode
   the ciphertext without the tag, concatenated with the value of the
   CounterSignature0 of the COSE object computed as described procedure in Section 4.1.

   The optimized compressed request is compatible with all AEAD
   algorithms defined in [RFC8152], but would not be compatible with
   AEAD algorithms that do not have 7, a well-defined tag.

9.2.  Optimized Response

   An optimized response is protected server proceeds as defined described
   in Section 7.3, 8.2 of [RFC8613], with the following differences. modifications.

   o  The server MUST set to 1  In step 2, the sixth least significant bit decoding of the
      OSCORE flag bits in compressed COSE object follows
      Section 5.  In particular:

      *  If the OSCORE option, i.e. server discards the Pairwise Flag.

   o  The COSE_Encrypt0 object included in request due to not retrieving a
         Security Context associated to the optimized response is
      encrypted using OSCORE group, the server MAY
         respond with a symmetric pairwise key K, that 4.02 (Bad Option) error.  When doing so, the
         server
      derives MAY set an Outer Max-Age option with value zero, and MAY
         include a descriptive string as defined in Section 3.  In particular, diagnostic payload.

      *  If the received 'kid context' matches an existing ID Context
         (Gid) but the Sender/ received 'kid' does not match any Recipient Key is ID in
         this Security Context, then the Sender Key server MAY create a new
         Recipient Context for this Recipient ID and initialize it
         according to Section 3 of [RFC8613], and also retrieve the server from its own Sender
      Context, i.e.
         associated public key.  Such a configuration is application
         specific.  If the application does not specify dynamic
         derivation of new Recipient Key that Contexts, then the client stores in its own
      Recipient Context corresponding to server SHALL
         stop processing the server. request.

   o  The Counter Signature  In step 4, the Additional Authenticated Data is not computed.  That is, unlike defined modified as
      described in Section 5, 4.

   o  In step 6, the payload of server also verifies the OSCORE message terminates with counter signature using
      the
      encoded ciphertext public key of the COSE object.

   Note that no changes are made to client from the AEAD nonce associated Recipient
      Context.  If the signature verification fails, the server SHALL
      stop processing the request and AAD.

   Upon receiving a response MAY respond with a 4.00 (Bad
      Request) response.  If the Pairwise Flag set to 1, verification fails, the client
   MUST process it same steps are
      taken as defined in Section 7.4, with if the following
   differences.

   o  No countersignature to verify decryption had failed.  In particular, the Replay
      Window is included. only updated if both the signature verification and the
      decryption succeed.

   o  The COSE_Encrypt0 object included in  Additionally, if the optimized response is
      decrypted used Recipient Context was created upon
      receiving this group request and the message is not verified using
      successfully, the same symmetric pairwise key K, server MAY delete that Recipient Context.  Such
      a configuration, which is specified by the client derives as described above for application, mitigates
      attacks that aim at overloading the server's storage.

   A server side and
      as defined SHOULD NOT process a request if the received Recipient ID
   ('kid') is equal to its own Sender ID in its own Sender Context.  For
   an example where this is not fulfilled, see Section 3.

9.2.1.  Optimized Compressed Response

   No changes.

10.  Security Considerations

   The same threat model discussed for OSCORE 5.2.1 in Appendix D.1 of
   [RFC8613] holds
   [I-D.tiloca-core-observe-multicast-notifications].

8.2.1.  Supporting Observe

   If Observe [RFC7641] is supported, for Group OSCORE.  In addition, source authentication each newly started
   observation, the server MUST store the value of messages is explicitly ensured by means the 'kid' parameter
   from the original Observe request.

   The server MUST NOT update the stored value of counter signatures, as
   discussed a 'kid' parameter
   associated to a particular Observe request, even in case the observer
   client is individually rekeyed and starts using a new Sender ID
   received from the Group Manager (see Section 10.1.

   The same considerations on supporting Proxy operations discussed for
   OSCORE 2.4.3.1).

8.3.  Protecting the Response

   If a server generates a CoAP message in Appendix D.2 of [RFC8613] hold for response to a Group OSCORE.

   The same considerations on protected message fields for OSCORE
   discussed in Appendix D.3 of [RFC8613] hold for Group OSCORE.

   The same considerations on uniqueness of (key, nonce) pairs for OSCORE discussed in Appendix D.4 of [RFC8613] hold for Group OSCORE.
   This is further discussed
   request, then the server SHALL follow the description in Section 10.2.

   The same considerations on unprotected message fields for OSCORE
   discussed in Appendix D.5 8.3
   of [RFC8613] hold for Group OSCORE, [RFC8613], with the following difference.  The countersignature included modifications described in this section.

   Note that the server always protects a Group
   OSCORE message is computed also over response with the value of Sender
   Context from its latest Security Context, and that a new Security
   Context does not reset the OSCORE option,
   which is part of Sender Sequence Number unless otherwise
   specified by the application (see Section 3.1).

   o  In step 2, the Additional Authenticated Data used in the
   signing process.  This is further discussed modified as
      described in Section 10.6.

   As discussed in 4.

   o  In step 3, if the server is using a different Security Context for
      the response compared to what was used to verify the request (see
      Section 6.2.3 3.1), then the AEAD nonce from the request MUST NOT be
      used.

   o  In step 4, the encryption of [I-D.ietf-core-groupcomm-bis], Group
   OSCORE addresses security attacks against CoAP listed the COSE object is modified as
      described in Sections
   11.2-11.6 of [RFC7252], especially when mounted over IP multicast. Section 4.  The rest encoding of this section first discusses security aspects to be taken
   into account when using Group OSCORE.  Then it goes through aspects
   covered in the security considerations of OSCORE (Section 12 of
   [RFC8613]), and discusses how they hold when Group OSCORE compressed COSE
      object is used.

10.1.  Group-level Security

   The signature mode modified as described in Section 7 relies on commonly shared
   group keying material 5.  In particular, the
      Group Flag MUST be set to protect communication within a group.  This
   has 1.  If the following implications.

   o  Messages are encrypted at server is using a group level (group-level data
      confidentiality), i.e. they can different
      ID Context (Gid) for the response compared to what was used to
      verify the request (see Section 3.1), then the new ID Context MUST
      be decrypted by any member included in the 'kid context' parameter of the
      group, but not by an external adversary or other external
      entities. response.

   o  The AEAD algorithm provides only group authentication, i.e. it
      ensures that a message sent to a group has been sent by a member
      of that group, but not by  In step 5, the alleged sender.  This is why source
      authentication of messages sent to a group is ensured through a counter signature, which signature is computed by the sender using its own
      private key and then appended to the message payload.

   Instead, format of the pairwise mode
      OSCORE message is modified as described in Appendix G protects messages
   by using pairwise symmetric keys, derived from the static-static
   Diffie-Hellman shared secret computed from Section 5.  In
      particular, the asymmetric keys payload of the
   sender and recipient endpoint (see Section 3).  Therefore, in the
   parwise mode, OSCORE message includes also the AEAD algorithm provides both pairwise data-
   confidentiality and source authentication of messages, without using
      counter signatures.

   Note that, even if an endpoint is authorized to be a group member and
   to take part in group communications, there signature.

8.3.1.  Supporting Observe

   If Observe [RFC7641] is supported, the server may have ongoing
   observations, started by Observe requests protected with an old
   Security Context.

   After completing the establishment of a risk that it behaves
   inappropriately.  For instance, it can forward new Security Context, the content
   server MUST protect the following notifications with the Sender
   Context of
   messages in the group to unauthorized entities.  However, in many use
   cases, new Security Context.

   For each ongoing observation, the devices server MUST include in the group belong to a common authority and are
   configured by a commissioner (see Appendix B), first
   notification protected with the new Security Context also the 'kid
   context' parameter, which results in a
   practically limited risk and enables a prompt detection/reaction in
   case of misbehaving.

10.2.  Uniqueness is set to the ID Context (Gid) of (key, nonce)

   The proof the new
   Security Context.  It is OPTIONAL for uniqueness of (key, nonce) pairs the server to include the ID
   Context (Gid) in Appendix D.4 of
   [RFC8613] is the 'kid context' parameter also valid in group communication scenarios.  That is,
   given an OSCORE group:

   o  Uniqueness of Sender IDs within further
   following notifications for those observations.

   Furthermore, for each ongoing observation, the group is enforced by server MUST use the Group
      Manager.

   o  The case A in Appendix D.4
   stored value of [RFC8613] concerns all group
      requests and responses including a Partial IV (e.g.  Observe
      notifications).  In this case, same considerations the 'kid' parameter from [RFC8613]
      apply here the original Observe
   request, as well.

   o  The case B value for the 'request_kid' parameter in Appendix D.4 of [RFC8613] concerns responses not
      including a Partial IV (e.g. single response to a group request).
      In this case, same considerations from [RFC8613] apply here as
      well.

   As a consequence, each message encrypted/decrypted with the same
   Sender Key is processed by using a different (ID_PIV, PIV) pair.
   This means two
   external_aad structures (see Section 4.3.1 and Section 4.3.2), when
   protecting notifications for that nonces used by any fixed encrypting endpoint are
   unique.  Thus, each message is processed with a different (key,
   nonce) pair.

10.3.  Management of Group Keying Material

   The approach described in this specification should take into account observation.

8.4.  Verifying the risk of compromise of group members.  In particular, this
   document specifies that Response

   Upon receiving a key management scheme for secure revocation
   and renewal of Security Contexts and group keying material should be
   adopted.

   Especially in dynamic, large-scale, groups where endpoints can join
   and leave at any time, it is important that the considered group key
   management scheme is efficient and highly scalable response message with the group
   size, in order Group Flag set to limit
   1, following the impact on performance due to procedure in Section 7, the Security
   Context and keying material update.

10.4.  Update client proceeds as
   described in Section 8.4 of Security Context and Key Rotation

   A group member can receive a message shortly after the group has been
   rekeyed, and new security parameters and keying material have been
   distributed by [RFC8613], with the Group Manager.

   This may result in following
   modifications.

   Note that a client using an old Security Context to protect
   a group request, and a server using a different new Security Context
   to protect a corresponding response.  That is, clients may receive a response protected with a Security
   Context different from the one used to protect the corresponding
   group request.

   In particular, a server may first get a group request protected with
   the old Security Context, then install request, and that, upon the establishment of a new Security
   Context, and
   only after that produce a response to send back to the client.  Since
   a sender always protects an outgoing message using client does not reset its own replay windows in its
   Recipient Contexts, unless otherwise specified by the latest owned
   Security Context, application
   (see Section 3.1).

   o  In step 2, the server discussed above protects decoding of the possible
   response using compressed COSE object is modified
      as described in Section 5.  If the new received 'kid context' matches
      an existing ID Context (Gid) but the received 'kid' does not match
      any Recipient ID in this Security Context.  Then, Context, then the client will
   process that response using the MAY
      create a new Security Context, provided that Recipient Context for this Recipient ID and
      initialize it has installed according to Section 3 of [RFC8613], and also
      retrieve the associated public key.  If the application does not
      specify dynamic derivation of new security parameters and keying material
   before Recipient Contexts, then the message reception.
      client SHALL stop processing the response.

   o  In case block-wise transfer [RFC7959] is used, step 3, the same
   considerations from Section 7.2 of [I-D.ietf-ace-key-groupcomm] hold.

   Furthermore, Additional Authenticated Data is modified as
      described below, a group rekeying may temporarily
   result in misaligned Security Contexts between the sender and
   recipient of a same message.

10.4.1.  Late Update on the Sender Section 4.

   o  In this case, step 5, the sender protects a message client also verifies the counter signature using
      the old Security
   Context, i.e. before having installed public key of the new Security Context.
   However, server from the recipient receives associated Recipient
      Context.  If the message after having installed verification fails, the new Security Context, hence not being able to correctly process
   it.

   A possible way to ameliorate same steps are taken as
      if the decryption had failed.

   o  Additionally, if the used Recipient Context was created upon
      receiving this issue response and the message is to preserve not verified
      successfully, the old,
   recent, Security Context for client MAY delete that Recipient Context.  Such
      a maximum amount of time defined configuration, which is specified by the
   application.  By doing so, application, mitigates
      attacks that aim at overloading the recipient can still try to process client's storage.

8.4.1.  Supporting Observe

   If Observe [RFC7641] is supported, for each ongoing observation, the
   received message using
   client MUST use the old retained Security Context stored value of the 'kid' parameter from the
   original Observe request, as second
   attempt.  This makes particular sense value for the 'request_kid' parameter in
   the two external_aad structures (see Section 4.3.1 and
   Section 4.3.2), when verifying notifications for that observation.

   This ensures that the recipient client can correctly verify notifications, even
   in case it is individually rekeyed and starts using a client,
   that would hence be able to process incoming responses new Sender ID
   received from the Group Manager (see Section 2.4.3.1).

9.  Message Processing in Pairwise Mode

   When using the pairwise mode of Group OSCORE, messages are protected
   and processed as in Section 8, with the old, recent, modifications described in
   this section.  The security objectives of the pairwise mode are
   discussed in Appendix A.2.

   The pairwise mode takes advantage of an existing Security Context used to protect for
   the associated group request.  Instead, mode to establish a recipient server would better and more
   simply discard an incoming group request which is not successfully
   processed Security Context shared exclusively
   with any other member.  In order to use the new Security Context.

   This tolerance preserves pairwise mode, the processing
   signature scheme of secure messages throughout
   a long-lasting key rotation, as group rekeying processes may likely
   take a long time to complete, especially in large scale groups.  On the other hand, a former (compromised) group member mode MUST support a combined signature
   and encryption scheme.  This can abusively
   take advantage of this, be, for example, signature using
   ECDSA, and send messages protected encryption using AES-CCM with the old
   retained Security Context.  Therefore, a conservative application
   policy should key derived with ECDH.
   The pairwise mode does not admit the retention support intermediary verification of old Security Contexts.

10.4.2.  Late Update on the Recipient

   In this case, the sender protects a message using the new Security
   Context, but the recipient receives
   source authentication or integrity.

   The pairwise mode MAY be supported.  The pairwise mode MUST be
   supported by endpoints that message before having
   installed use the new Security Context.  Therefore, CoAP Echo Option
   [I-D.ietf-core-echo-request-tag] and/or block-wise transfers
   [RFC7959], for instance for responses after the recipient would
   not be able to correctly process first block-wise
   request, possibly targeting all servers in the message group and hence discards it.

   If including
   the recipient installs CoAP Block2 option (see Section 2.3.6 of
   [I-D.ietf-core-groupcomm-bis]).  An endpoint implementing only a
   silent server does not support the new Security Context shortly after that pairwise mode.

   The pairwise mode protects messages between two members of a group,
   essentially following [RFC8613], but with the following notable
   differences:

   o  The 'kid' and 'kid context' parameters of the sender endpoint uses CoAP retransmissions, the former will
   still be able to receive and correctly process the message.

   In any case, the recipient should actively ask the Group Manager for
   an updated Security Context according to an application-defined
   policy, for instance after a given number of unsuccessfully decrypted
   incoming messages.

10.5.  Collision of Group Identifiers

   In case endpoints COSE object are deployed used
      as defined in multiple groups managed by
   different non-synchronized Group Managers, it Section 4.2.

   o  The external_aad defined in Section 4.3.1 is possible used for Group
   Identifiers of different groups to coincide.

   This does not impair the security of
      encryption process.

   o  The Sender/Recipient Keys used in the AEAD algorithm.  In fact, as
   long pairwise mode are derived as
      defined in Section 2.3.

   Senders MUST NOT use the Master Secret is different pairwise mode to protect a message intended
   for different groups and this
   condition holds over time, AEAD keys are different among different
   groups. multiple recipients.  The entity assigning an IP multicast address may help limiting pairwise mode is defined only between
   two endpoints and the
   chances keying material is thus only available to experience such collisions of one
   recipient.

   The Group Identifiers.  In
   particular, it may allow Manager MAY indicate that the Group Managers group uses also the pairwise
   mode, as part of groups using the same
   IP multicast address group communication policies signalled to share their respective list of assigned Group
   Identifiers currently
   candidate group members when joining the group.

9.1.  Pre-Conditions

   In order to protect an outgoing message in use.

10.6.  Cross-group Message Injection

   A same endpoint is allowed pairwise mode, the sender
   needs to and would likely use know the same signature public key in multiple OSCORE groups, possibly administered by different
   Group Managers.  Also, and the same endpoint can register several times Recipient ID for the recipient
   endpoint, as stored in the same group, getting multiple unique Recipient Context associated to that
   endpoint (see Pairwise Sender IDs. Context of Section 2.3.3).

   Furthermore, the sender needs to know the individual address of the
   recipient endpoint.  This requires
   that, when information may not be known at any given
   point in time.  For instance, right after having joined the group, a sender endpoint sends
   client may know the public key and Recipient ID for a message given server,
   but not the addressing information required to reach it with an OSCORE group using
   a Sender ID, the countersignature included
   individual, one-to-one request.

   To make addressing information of individual endpoints available,
   servers in the message is
   explicitly bound also to that group and MAY expose a resource to which a client can send
   a group request targeting a server or a set of servers, identified by
   their 'kid' value(s).  The specified set may be empty, hence
   identifying all the used Sender ID.

   To this end, servers in the countersignature group.  Further details of each message protected with
   Group OSCORE is computed also over the value such an
   interface are out of scope for this document.

9.2.  Protecting the OSCORE option,
   which Request

   When using the pairwise mode, the request is part of protected as defined in
   Section 8.1, with the Additional Authenticated Data following differences.

   o  The Group Flag MUST be set to 0.

   o  The Sender Key used in is the
   signing process Pairwise Sender Key (see Section 4.3.2).  That is, the countersignature 2.3).

   o  The counter signature is not computed also over: the ID Context (Group ID) and the Partial IV,
   which are always present therefore not included
      in group requests; the message.  The payload of the protected request thus
      terminates with the encoded ciphertext of the COSE object, just as well
      in [RFC8613].

   Note that, just as in the Sender ID
   of group mode, the message originator, which external_aad for encryption
   is always present generated as in all group
   requests Section 4.3.1, and responses.

   Since the signing process takes as input also Partial IV is the ciphertext current
   fresh value of the
   COSE_Encrypt0 object, Sender Sequence Number (see Section 2.3.2).

9.3.  Verifying the countersignature is bound not only to Request

   Upon receiving a request with the
   intended OSCORE group, hence Group Flag set to 0, following the triplet (Master Secret, Master
   Salt, ID Context), but also to a specific Sender ID
   procedure in that group and
   to its specific symmetric key used for AEAD encryption, hence to Section 7, the
   quartet (Master Secret, Master Salt, ID Context, Sender ID).

   This makes server MUST process it practically infeasible to perform as defined in
   Section 8.2, with the attack described
   below, where a malicious group member injects forged messages following differences.

   o  If the server discards the request due to not retrieving a
   different OSCORE group than the originally intended one.  Let us
   consider:

   o  Two OSCORE groups G1 and G2, with ID
      Security Context (Group ID) Gid1 and
      Gid2, respectively.  Both G1 and G2 use associated to the AEAD cipher AES-CCM-
      16-64-128, i.e. OSCORE group or to not
      supporting the MAC of pairwise mode, the ciphertext is 8 bytes in size.

   o  A victim endpoint V which is member of both G1 and G2, and uses server MAY respond with a 4.02
      (Bad Option) error.  When doing so, the same signature key in both groups.  The endpoint V has Sender
      ID Sid1 in G1 server MAY set an Outer
      Max-Age option with value zero, and Sender ID Sid2 in G2. MAY include a descriptive
      string as diagnostic payload.

   o  If a new Recipient Context is created for this Recipient ID, new
      Pairwise Sender/Recipient Keys are also derived (see
      Section 2.3.1).  The pairs (Sid1, Gid1)
      and (Sid2, Gid2) identify new Pairwise Sender/Recipient Keys are
      deleted if the same public key Recipient Context is deleted as a result of V in G1 and G2,
      respectively. the
      message not being successfully verified.

   o  A malicious endpoint Z  The Recipient Key used is also member the Pairwise Recipient Key (see
      Section 2.3).

   o  No verification of both G1 and G2.  Hence, Z counter signature occurs, as there is able to derive none
      included in the symmetric keys associated to V message.

9.4.  Protecting the Response

   When using the pairwise mode, a response is protected as defined in G1 and G2.

   If countersignatures were
   Section 8.3, with the following differences.

   o  The Group Flag MUST be set to 0.

   o  The Sender Key used is the Pairwise Sender Key (see Section 2.3).

   o  The counter signature is not computed also over and therefore not included
      in the value message.  The payload of the
   OSCORE option protected response thus
      terminates with the encoded ciphertext of the COSE object, just as discussed above, Z can intercept a group message M1
   sent by V to G1, and forge
      in [RFC8613].

9.5.  Verifying the Response

   Upon receiving a valid signed message M2 response with the Group Flag set to be injected 0, following the
   procedure in G2, making Section 7, the client MUST process it appear as sent by V and valid to be accepted.

   More in detail, Z first intercepts a message M1 sent by V defined in G1, and
   tries to forge a message M2, by changing the value of the OSCORE
   option from M1 as follows: the 'kid context' is changed from G1 to
   G2; and
   Section 8.4, with the 'kid' is changed from Sid1 to Sid2. following differences.

   o  If M2 is used as a request message, there new Recipient Context is a probability equal to
   2^-64 that created for this Recipient ID, new
      Pairwise Sender/Recipient Keys are also derived (see
      Section 2.3.1).  The new Pairwise Sender/Recipient Keys are
      deleted if the same unchanged MAC Recipient Context is successfully verified by using
   Sid2 deleted as 'request_kid' and the symmetric key associated to V in G2.
   In such a case, result of the same unchanged signature would be also valid.
   Note that Z can check offline if a performed forgery
      message not being successfully verified.

   o  The Recipient Key used is actually
   valid before sending the forged message to G2.  That is, this attack
   has a complexity Pairwise Recipient Key (see
      Section 2.3).

   o  No verification of 2^64 offline calculations.

   If M2 is used counter signature occurs, as a response, Z can also change the response Partial
   IV, until there is none
      included in the message.

10.  Security Considerations

   The same unchanged MAC threat model discussed for OSCORE in Appendix D.1 of
   [RFC8613] holds for Group OSCORE.  In addition, when using the group
   mode, source authentication of messages is successfully verified explicitly ensured by using
   Sid2
   means of counter signatures, as 'request_kid' and the symmetric key associated to V discussed in G2.
   In such a case, the Section 10.1.

   The same unchanged signature would be also valid.
   Since the Partial IV is 5 bytes in size, this requires 2^40 considerations on supporting Proxy operations to test all the Partial IVs, which can be done in real-
   time.  Also, the probability that a single given message M1 can be
   used to forge a response M2 discussed for a given request is equal to 2^-24,
   since there are more MAC values (8 bytes in size) than Partial IV
   values (5 bytes
   OSCORE in size).

   Note that, by changing the Partial IV as discussed above, any member Appendix D.2 of G1 would also be able to forge a valid signed response [RFC8613] hold for Group OSCORE.

   The same considerations on protected message M2
   to be injected fields for OSCORE
   discussed in G1.

10.7. Appendix D.3 of [RFC8613] hold for Group OSCORE.

   The same considerations on uniqueness of (key, nonce) pairs for
   OSCORE discussed in Appendix D.4 of [RFC8613] hold for Unicast Requests

   With reference to the processing defined Group OSCORE.
   This is further discussed in Section 7.1 10.2.

   The same considerations on unprotected message fields for the
   signature mode and OSCORE
   discussed in Section 9.1.1 Appendix D.5 of [RFC8613] hold for Group OSCORE, with
   the optimized mode, it is NOT
   RECOMMENDED for following difference.  The counter signature included in a client to use Group
   OSCORE for securing a request
   sent to a single message protected in group member mode is computed also over unicast.

   If the client uses its own Sender Key to protect a unicast request to
   a group member, an on-path adversary can, right then or later on,
   redirect that request to one/many different group member(s) over
   unicast, or to
   value of the whole OSCORE group over multicast.  By doing so,
   the adversary can induce option, which is part of the target group member(s) Additional
   Authenticated Data used in the signing process.  This is further
   discussed in Section 10.6.

   As discussed in Section 6.2.3 of [I-D.ietf-core-groupcomm-bis], Group
   OSCORE addresses security attacks against CoAP listed in Sections
   11.2-11.6 of [RFC7252], especially when run over IP multicast.

   The rest of this section first discusses security aspects to perform
   actions intended be taken
   into account when using Group OSCORE.  Then it goes through aspects
   covered in the security considerations of OSCORE (Section 12 of
   [RFC8613]), and discusses how they hold when Group OSCORE is used.

10.1.  Group-level Security

   The group mode described in Section 8 relies on commonly shared group
   keying material to one protect communication within a group.  This has
   the following implications.

   o  Messages are encrypted at a group level (group-level data
      confidentiality), i.e. they can be decrypted by any member only.  Note that of the
      group, but not by an external adversary
   can be external, or other external
      entities.

   o  The AEAD algorithm provides only group authentication, i.e. (s)he does not need it
      ensures that a message sent to also be a group has been sent by a member
      of that group, but not by the
   OSCORE group. alleged sender.  This is due why source
      authentication of messages sent to the fact that the client a group is not able to indicate the
   single intended recipient in ensured through a way
      counter signature, which is secure computed by the sender using its own
      private key and possible then appended to
   process for Group OSCORE on the server side.  In particular, Group
   OSCORE does not protect network addressing information such as the IP
   address of the intended recipient server.  It follows that message payload.

   Instead, the
   server(s) receiving pairwise mode described in Section 9 protects messages
   by using pairwise symmetric keys, derived from the redirected request cannot assert whether that
   was static-static
   Diffie-Hellman shared secret computed from the original intention asymmetric keys of the client,
   sender and would thus simply
   assume so.

   With particular reference to block-wise transfers [RFC7959], recipient endpoint (see Section 2.3.6 2.3).  Therefore, in the
   parwise mode, the AEAD algorithm provides both pairwise data-
   confidentiality and source authentication of messages, without using
   counter signatures.

   The long-term storing of [I-D.ietf-core-groupcomm-bis] points out that, while
   an initial request including the CoAP Block2 option can be sent over
   multicast, any other request in Diffie-Hellman shared secret is a transfer has to occur over unicast,
   individually addressing the servers in
   potential security issue.  In fact, if the group.

   Additional considerations are discussed in Appendix E.3, with respect
   to requests including an Echo Option [I-D.ietf-core-echo-request-tag]
   that has to be sent over unicast, as shared secret of two group
   members is leaked, a challenge-response method for
   servers third group member can exploit it to achieve synchronization impersonate
   any of client Sender Sequence Numbers. those two group members, by deriving and using their pairwise
   key.  The impact possibility of such an attack depends especially on leakage should be contemplated, as more
   likely to happen than the REST method leakage of a private key, which could be
   rather protected at a significantly higher level than generic memory,
   e.g. by using a Trusted Platform Module.  Therefore, there is a
   trade-off between the request, i.e. the Inner CoAP Code maximum amount of the OSCORE request message.
   In particular, safe methods such as GET time a same shared secret is
   stored and FETCH would trigger
   (several) unintended responses from the targeted server(s), while not
   resulting in destructive behavior.  On the other hand, non safe
   methods such as PUT, POST and PATCH/iPATCH would result in the target
   server(s) taking active actions on their resources and possible
   cyber-physical environment, with the risk frequency of destructive consequences
   and possible implications for safety.

   A client may instead use the pairwise mode defined in Appendix G.2,
   in order to protect a request sent its re-computing.

   Note that, even if an endpoint is authorized to be a single group member by using
   pairwise keying material (see Section 3).  This prevents the attack
   discussed above by construction, as only the intended server is able and
   to derive take part in group communications, there is a risk that it behaves
   inappropriately.  For instance, it can forward the pairwise keying material used by content of
   messages in the client group to protect unauthorized entities.  However, in many use
   cases, the request.  A client supporting devices in the pairwise mode SHOULD use it to
   protect requests sent group belong to a single group member over unicast, instead common authority and are
   configured by a commissioner (see Appendix B), which results in a
   practically limited risk and enables a prompt detection/reaction in
   case of using the signature mode.

10.8.  End-to-end Protection misbehaving.

10.2.  Uniqueness of (key, nonce)

   The same considerations from Section 12.1 proof for uniqueness of (key, nonce) pairs in Appendix D.4 of
   [RFC8613] hold for Group
   OSCORE.

   Additionally, (D)TLS and Group OSCORE can be combined for protecting
   message exchanges occurring over unicast.  Instead, it is not
   possible to combine DTLS and Group also valid in group communication scenarios.  That is,
   given an OSCORE for protecting message
   exchanges where messages are (also) sent over multicast.

10.9.  Security Context Establishment

   The use of COSE_Encrypt0 and AEAD to protect messages as specified in
   this document requires an endpoint to be a member of an OSCORE group.

   That is, upon joining the group, the endpoint securely receives from
   the Group Manager the necessary input parameters, which are used to
   derive the Common Context and the Sender Context (see Section 2).
   The Group Manager ensures uniqueness group:

   o  Uniqueness of Sender IDs in the same group.

   Each different Recipient Context for decrypting messages from a
   particular sender can be derived at runtime, at the latest upon
   receiving a message from that sender for within the first time.

   Countersignatures of group messages are verified is enforced by means of the
   public key of the respective sender endpoint.  Upon nodes' joining, the Group Manager collects such public keys and MUST verify proof-of-
   possession
      Manager.

   o  The case A in Appendix D.4 of the respective private key.  Later on, a [RFC8613] concerns all group member
   can request
      requests and responses including a Partial IV (e.g.  Observe
      notifications).  In this case, same considerations from the Group Manager the public keys of other group
   members.

   The joining process can occur, for instance, [RFC8613]
      apply here as defined well.

   o  The case B in
   [I-D.ietf-ace-key-groupcomm-oscore].

10.10.  Master Secret

   Group OSCORE derives the Security Context using the same construction
   as OSCORE, and by using the Group Identifier Appendix D.4 of [RFC8613] concerns responses not
      including a Partial IV (e.g. single response to a group request).
      In this case, same considerations from [RFC8613] apply here as the
   related ID Context.  Hence,
      well.

   As a consequence, each message encrypted/decrypted with the same required properties
   Sender Key is processed by using a different (ID_PIV, PIV) pair.
   This means that nonces used by any fixed encrypting endpoint are
   unique.  Thus, each message is processed with a different (key,
   nonce) pair.

10.3.  Management of the
   Security Context parameters discussed Group Keying Material

   The approach described in Section 3.3 of [RFC8613]
   hold for this document.

   With particular reference to the OSCORE Master Secret, it has to be
   kept secret among specification should take into account
   the members risk of compromise of the respective OSCORE group and the
   Group Manager responsible for members.  In particular, this
   document specifies that group.  Also, the Master Secret
   must have a good amount key management scheme for secure revocation
   and renewal of randomness, Security Contexts and group keying material should be
   adopted.

   [I-D.ietf-ace-key-groupcomm-oscore] provides a simple rekeying scheme
   for renewing the Group Manager can
   generate it offline using Security Context in a good random number generator.  This
   includes group.

   Alternative rekeying schemes which are more scalable with the case group
   size may be needed in dynamic, large-scale, groups where endpoints
   can join and leave at any time, in order to limit the Group Manager rekeys impact on
   performance due to the group by
   generating Security Context and distributing keying material update.

10.4.  Update of Security Context and Key Rotation

   A group member can receive a message shortly after the group has been
   rekeyed, and new Master Secret.  Randomness
   requirements for security are described in [RFC4086].

10.11.  Replay Protection

   As in OSCORE, also parameters and keying material have been
   distributed by the Group OSCORE relies on sender sequence numbers
   included Manager.

   This may result in the COSE message field 'Partial IV' and used to build
   AEAD nonces.

   Note that the Partial IV of a client using an endpoint does not necessarily grow
   monotonically.  For instance, upon exhaustion of the endpoint Sender
   Sequence Number, the Partial IV also gets exhausted.  As discussed in
   Section 2.5, this results either in the endpoint being individually
   rekeyed old Security Context to protect
   a group request, and getting a new Sender ID, or in the establishment of server using a different new Security Context in the group.  Therefore, uniqueness of (key, nonce)
   pairs (see Section 10.2) is preserved also when
   to protect a new Security
   Context is established. corresponding response.  As discussed in Section 6.1, an endpoint that has just joined a group
   is exposed to replay attack, as it is not aware of consequence, clients may
   receive a response protected with a Security Context different from
   the sender
   sequence numbers currently one used by other to protect the corresponding group members.  Appendix E
   describes how endpoints can synchronize with senders' sequence
   numbers.

   Unless exchanges in request.

   In particular, a server may first get a group rely only on unicast messages, Group
   OSCORE cannot be used request protected with reliable transport.  Thus, unless only
   unicast messages are sent in
   the group, it cannot be defined that old Security Context, then install the new Security Context, and
   only messages with sequence numbers after that are equal produce a response to send back to the previous
   sequence number + 1 are accepted.

   The processing of response messages described client.  In
   such a case, as specified in Section 7.4 also
   ensures that a client accepts a single valid 8.3, the server MUST protect the
   potential response to a given
   request from each replying server, unless CoAP observation is used.

10.12.  Client Aliveness

   As discussed in Section 12.5 of [RFC8613], a using the new Security Context.  Specifically, the
   server may MUST use the Echo
   option [I-D.ietf-core-echo-request-tag] its own Sender Sequence Number as Partial IV to verify
   protect that response, and not the aliveness Partial IV from the request, in
   order to prevent reuse of AEAD nonces in the new Security Context.

   The client will process that originated a received request.  This would also allow
   the server to (re-)synchronize with response using the client's sequence number, as
   well as to ensure new Security Context,
   provided that it has installed the request is fresh new security parameters and has not been replayed
   or (purposely) delayed, if it is keying
   material before the first one received from that
   client after having joined message reception.

   In case block-wise transfer [RFC7959] is used, the group or rebooted (see Appendix E.3).

10.13.  Cryptographic Considerations

   The same
   considerations from Section 12.6 7.2 of [RFC8613] about the
   maximum Sender Sequence Number hold for Group OSCORE.

   As discussed in Section 2.5, an endpoint that experiences [I-D.ietf-ace-key-groupcomm] hold.

   Furthermore, as described below, a
   exhaustion group rekeying may temporarily
   result in misaligned Security Contexts between the sender and
   recipient of its own Sender Sequence Number MUST NOT transmit
   further messages including a Partial IV, until it has derived a new
   Sender Context.  This prevents the endpoint to reuse the same AEAD
   nonces with message.

10.4.1.  Late Update on the same Sender key.

   In order to renew its own Sender Context, this case, the endpoint SHOULD inform sender protects a message using the Group Manager, which can either renew old Security
   Context, i.e. before having installed the whole new Security Context
   by means of group rekeying, or provide only that endpoint with a new
   Sender ID value.  In either case, Context.
   However, the recipient receives the message after having installed
   the endpoint derives a new Sender Security Context, and in particular a new Sender Key.

   Additionally, hence not being able to correctly process
   it.

   A possible way to ameliorate this issue is to preserve the same considerations from Section 12.6 of [RFC8613]
   hold old,
   recent, Security Context for Group OSCORE, about building a maximum amount of time defined by the AEAD nonce and
   application.  By doing so, the secrecy
   of recipient can still try to process the
   received message using the old retained Security Context parameters.

   The EdDSA signature algorithm Ed25519 [RFC8032] is mandatory to
   implement.  For many constrained IoT devices, it is problematic to
   support more than one signature algorithm or multiple whole cipher
   suites. as second
   attempt.  This means that some deployments using, for instance, ECDSA
   with NIST P-256 may not support makes particular sense when the mandatory signature algorithm.
   However, this recipient is not a problem for local deployments.

10.14.  Message Segmentation

   The same considerations from Section 12.7 of [RFC8613] hold for Group
   OSCORE.

10.15.  Privacy Considerations

   Group OSCORE ensures end-to-end integrity protection and encryption
   of client,
   that would hence be able to process incoming responses protected with
   the message payload old, recent, Security Context used to protect the associated
   group request.  Instead, a recipient server would better and all options that are more
   simply discard an incoming group request which is not used for proxy
   operations.  In particular, options are successfully
   processed according to with the
   same class U/I/E that they have for OSCORE.  Therefore, new Security Context.

   This tolerance preserves the same
   privacy considerations from Section 12.8 processing of [RFC8613] hold for Group
   OSCORE.

   Furthermore, the following privacy considerations hold, about the
   OSCORE option that secure messages throughout
   a long-lasting key rotation, as group rekeying processes may reveal information on the communicating
   endpoints.

   o  The 'kid' parameter, which is intended to help likely
   take a recipient
      endpoint long time to find the right Recipient Context, may reveal
      information about the Sender Endpoint.  Since both requests and
      responses always include complete, especially in large scale groups.  On
   the 'kid' parameter, this may reveal
      information about both a client sending other hand, a former (compromised) group request member can abusively
   take advantage of this, and all send messages protected with the possibly replying servers sending their own individual
      response.

   o  The 'kid context' parameter, which is intended to help old
   retained Security Context.  Therefore, a recipient
      endpoint to find conservative application
   policy should not admit the right Recipient Context, reveals information
      about retention of old Security Contexts.

10.4.2.  Late Update on the sender endpoint. Recipient

   In particular, it reveals that this case, the sender endpoint is a member of protects a particular OSCORE group, whose
      current Group ID is indicated in the 'kid context' parameter.
      Moreover, this parameter explicitly relates two or more
      communicating endpoints, as members of the same OSCORE group.

   Also, message using the mechanisms described in Appendix E.3 to achieve
   sequence number synchronization with a client may reveal when a
   server device goes through a reboot.  This can be mitigated by the
   server device storing new Security
   Context, but the precise state of recipient receives that message before having
   installed the replay window of each
   known client on a clean shutdown.

   Finally, new Security Context.  Therefore, the mechanism described in Section 10.5 recipient would
   not be able to prevent
   collisions correctly process the message and hence discards it.

   If the recipient installs the new Security Context shortly after that
   and the sender endpoint uses CoAP retransmissions, the former will
   still be able to receive and correctly process the message.

   In any case, the recipient should actively ask the Group Manager for
   an updated Security Context according to an application-defined
   policy, for instance after a given number of unsuccessfully decrypted
   incoming messages.

10.5.  Collision of Group Identifiers from different Group Managers may
   reveal information about events in the respective OSCORE groups.

   In
   particular, a case endpoints are deployed in multiple groups managed by
   different non-synchronized Group Idenfier changes when the corresponding group Managers, it is
   rekeyed.  Thus, changes in the shared list of possible for Group
   Identifiers may
   be used of different groups to infer about coincide.

   This does not impair the rate and patterns security of group membership
   changes triggering a group rekeying, e.g. due to newly joined members
   or evicted (compromised) members. the AEAD algorithm.  In order fact, as
   long as the Master Secret is different for different groups and this
   condition holds over time, AEAD keys are different among different
   groups.

   The entity assigning an IP multicast address may help limiting the
   chances to alleviate experience such privacy
   concerns, collisions of Group Identifiers.  In
   particular, it should be hidden from may allow the Group Managers which exact
   Group Manager has currently of groups using the same
   IP multicast address to share their respective list of assigned which Group
   Identifiers currently in its
   OSCORE groups.

11.  IANA Considerations

   Note use.

10.6.  Cross-group Message Injection

   A same endpoint is allowed to RFC Editor: Please replace all occurrences of "[This
   Document]" with the RFC number of this specification and delete this
   paragraph.

   This document has the following actions for IANA.

11.1.  Counter Signature Parameters Registry

   This specification establishes the IANA "Counter Signature
   Parameters" Registry.  The Registry has been created to would likely use the
   "Expert Review Required" registration procedure [RFC8126].  Expert
   review guidelines are provided same public/
   private key pair in Section 11.4.

   This registry specifies the parameters of each admitted
   countersignature algorithm, as well as the possible structure they
   are organized into.  This information is used multiple OSCORE groups, possibly administered by
   different Group Managers.

   When a sender endpoint sends a message protected in pairwise mode to
   a recipient endpoint in an OSCORE group, a malicious group member may
   attempt to populate inject the
   parameter Counter Signature Parameters of message to a different OSCORE group also
   including the Common Context same endpoints (see Section 2).

   The columns of this table are:

   o  Name: A value that can be used to identify an algorithm in
      documents for easier comprehension.  Its value is taken from the
      'Name' column of 10.6.1).

   This practically relies on altering the "COSE Algorithms" Registry.

   o  Value: The value to be used to identify this algorithm.  Its content is taken from the 'Value' column of the "COSE Algorithms"
      Registry.  The value MUST be OSCORE option,
   and having the same one used MAC in the "COSE
      Algorithms" Registry for ciphertext still correctly validating,
   which has a success probability depending on the entry with size of the same 'Name' field.

   o  Parameters: This indicates MAC.

   As discussed in Section 10.6.2, the CBOR encoding of attack is practically infeasible
   if the parameters (if
      any) for message is protected in group mode, since the counter
   signature algorithm indicated by is bound also to the 'Value'
      field. OSCORE option, through the Additional
   Authenticated Data used in the signing process (see Section 4.3.2).

10.6.1.  Attack Description

   Let us consider:

   o  Two OSCORE groups G1 and G2, with ID Context (Group ID) Gid1 and
      Gid2, respectively.  Both G1 and G2 use the AEAD cipher AES-CCM-
      16-64-128, i.e. the MAC of the ciphertext is 8 bytes in size.

   o  Description:  A short description sender endpoint X which is member of both G1 and G2, and uses
      the parameters encoded same public/private key pair in both groups.  The endpoint X
      has Sender ID Sid1 in G1 and Sender ID Sid2 in G2.  The pairs
      (Sid1, Gid1) and (Sid2, Gid2) identify the
      'Parameters' field (if any). same public key of X in
      G1 and G2, respectively.

   o  Reference: This contains a pointer to  A recipient endpoint Y which is member of both G1 and G2, and uses
      the same public/private key pair in both groups.  The endpoint Y
      has Sender ID Sid3 in G1 and Sender ID Sid4 in G2.  The pairs
      (Sid3, Gid1) and (Sid4, Gid2) identify the same public specification for key of Y in
      G1 and G2, respectively.

   o  A malicious endpoint Z is also member of both G1 and G2.  Hence, Z
      is able to derive the field, if one exists.

   Initial entries symmetric keys associated to X in G1 and G2.

   When X sends a message M1 addressed to Y in G1 and protected in
   pairwise mode, Z can intercept M1, and forge a valid message M2 to be
   injected in G2, making it appear as still sent by X to Y and valid to
   be accepted.

   More in detail, Z intercepts and stops message M1, and forges a
   message M2 by changing the registry are value of the OSCORE option from M1 as follows.

   +-------------+-------+--------------+-----------------+-----------+
   |    Name     | Value |  Parameters  |   Description   | Reference |
   +-------------+-------+--------------+-----------------+-----------+
   |             |       |              |                 |           |
   |    EdDSA    |  -8   |  crv : int   | crv value taken | [This     |
   |             |       |              | from
   follows: the COSE   | Document] |
   |             |       |              | Elliptic Curve  |           |
   |             |       |              | Registry        |           |
   |             |       |              |                 |           |
   +-------------+-------+--------------+-----------------+-----------+
   |             |       |              |                 |           |
   |    ES256    |  -7   |  crv : int   | crv value taken | [This     |
   |             |       |              | 'kid context' is changed from G1 to G2; and the COSE   | Document] |
   |             |       |              | Elliptic Curve  |           |
   |             |       |              | Registry        |           |
   |             |       |              |                 |           |
   +-------------+-------+--------------+-----------------+-----------+
   |             |       |              |                 |           |
   |    ES384    |  -35  |  crv : int   | crv value taken | [This     |
   |             |       |              | 'kid' is
   changed from Sid1 to Sid2.  Then, Z injects message M2 as addressed
   to Y in G2.

   Upon receiving M2, there is a probability equal to 2^-64 that Y
   successfully verifies the COSE   | Document] |
   |             |       |              | Elliptic Curve  |           |
   |             |       |              | Registry        |           |
   |             |       |              |                 |           |
   +-------------+-------+--------------+-----------------+-----------+
   |             |       |              |                 |           |
   |    ES512    |  -36  |  crv : int   | crv value taken | [This     |
   |             |       |              | from same unchanged MAC by using Sid2 as
   'request_kid' and using the COSE   | Document] |
   |             |       |              | Elliptic Curve  |           |
   |             |       |              | Registry        |           |
   |             |       |              |                 |           |
   +-------------+-------+--------------+-----------------+-----------+
   |             |       |              |                 |           |
   |    PS256    |  -37  |              | Parameters Pairwise Recipient Key associated to X in
   G2.

   Note that Z does not  | [This     |
   |             |       |              | present         | Document] |
   |             |       |              |                 |           |
   +-------------+-------+--------------+-----------------+-----------+
   |             |       |              |                 |           |
   |    PS384    |  -38  |              | Parameters know the pairwise keys of X and Y, since it does
   not  | [This     |
   |             |       |              | present         | Document] |
   |             |       |              |                 |           |
   +-------------+-------+--------------+-----------------+-----------+
   |             |       |              |                 |           |
   |    PS512    |  -39  |              | Parameters know and is not  | [This     |
   |             |       |              | able to compute their shared Diffie-Hellman
   secret.  Therefore, Z is not able to check offline if a performed
   forgery is actually valid, before sending the forged message to G2.

10.6.2.  Attack Prevention in Group Mode

   When a Group OSCORE message is protected with the group mode, the
   counter signature is computed also over the value of the OSCORE
   option, which is part of the Additional Authenticated Data used in
   the signing process (see Section 4.3.2).

   That is, the countersignature is computed also over: the ID Context
   (Group ID) and the Partial IV, which are always present         | Document] |
   |             |       |              |                 |           |
   +-------------+-------+--------------+-----------------+-----------+

11.2.  Counter Signature Key Parameters Registry in group
   requests; as well as the Sender ID of the message originator, which
   is always present in all group requests and responses.

   Since the signing process takes as input also the ciphertext of the
   COSE_Encrypt0 object, the countersignature is bound not only to the
   intended OSCORE group, hence to the triplet (Master Secret, Master
   Salt, ID Context), but also to a specific Sender ID in that group and
   to its specific symmetric key used for AEAD encryption, hence to the
   quartet (Master Secret, Master Salt, ID Context, Sender ID).

   This makes it practically infeasible to perform the attack described
   in Section 10.6.1, since it would require the adversary to
   additionally forge a valid countersignature that replaces the
   original one in the forged message M2.

   If the countersignature did not cover the OSCORE option, the attack
   would be possible also in group mode, since the same unchanged
   countersignature from messsage M1 would be also valid in message M2.
   Also, the following attack simplifications would hold, since Z is
   able to derive the Sender/Recipient Keys of X and Y in G1 and G2.

   o  If M2 is used as a request, Z can check offline if a performed
      forgery is actually valid before sending the forged message to G2.

      That is, this attack would have a complexity of 2^64 offline
      calculations.

   o  If M2 is used as a response, Z can also change the response
      Partial IV, until the same unchanged MAC is successfully verified
      by using Sid2 as 'request_kid' and the symmetric key associated to
      X in G2.  Since the Partial IV is 5 bytes in size, this requires
      2^40 operations to test all the Partial IVs, which can be done in
      real-time.  Also, the probability that a single given message M1
      can be used to forge a response M2 for a given request would be
      equal to 2^-24, since there are more MAC values (8 bytes in size)
      than Partial IV values (5 bytes in size).

      Note that, by changing the Partial IV as discussed above, any
      member of G1 would also be able to forge a valid signed response
      message M2 to be injected in G1.

10.7.  Group OSCORE for Unicast Requests

   With reference to the processing defined in Section 8.1 for the group
   mode and in Appendix G for the optimized request, it is NOT
   RECOMMENDED for a client to use the group mode for securing a request
   intended for a single group member and sent over unicast.

   This does not include the case where the client sends a request over
   unicast to a proxy, to be forwarded to multiple intended recipients
   over multicast [I-D.ietf-core-groupcomm-bis].  In this case, the
   client MUST protect the request with the group mode, even though it
   is sent to the proxy over unicast (see Section 8).

   If the client uses the group mode with its own Sender Key to protect
   a unicast request to a group member, an on-path adversary can, right
   then or later on, redirect that request to one/many different group
   member(s) over unicast, or to the whole OSCORE group over multicast.
   By doing so, the adversary can induce the target group member(s) to
   perform actions intended for one group member only.  Note that the
   adversary can be external, i.e. (s)he does not need to also be a
   member of the OSCORE group.

   This is due to the fact that the client is not able to indicate the
   single intended recipient in a way which is secure and possible to
   process for Group OSCORE on the server side.  In particular, Group
   OSCORE does not protect network addressing information such as the IP
   address of the intended recipient server.  It follows that the
   server(s) receiving the redirected request cannot assert whether that
   was the original intention of the client, and would thus simply
   assume so.

   The impact of such an attack depends especially on the REST method of
   the request, i.e. the Inner CoAP Code of the OSCORE request message.
   In particular, safe methods such as GET and FETCH would trigger
   (several) unintended responses from the targeted server(s), while not
   resulting in destructive behavior.  On the other hand, non safe
   methods such as PUT, POST and PATCH/iPATCH would result in the target
   server(s) taking active actions on their resources and possible
   cyber-physical environment, with the risk of destructive consequences
   and possible implications for safety.

   A client can instead use the pairwise mode defined in Section 9.2, in
   order to protect a request sent to a single group member by using
   pairwise keying material (see Section 2.3).  This prevents the attack
   discussed above by construction, as only the intended server is able
   to derive the pairwise keying material used by the client to protect
   the request.  A client supporting the pairwise mode SHOULD use it to
   protect requests sent to a single group member over unicast, instead
   of using the group mode.  For an example where this is not fulfilled,
   see Section 5.2.1 in
   [I-D.tiloca-core-observe-multicast-notifications].

   With particular reference to block-wise transfers [RFC7959],
   Section 2.3.6 of [I-D.ietf-core-groupcomm-bis] points out that, while
   an initial request including the CoAP Block2 option can be sent over
   multicast, any other request in a transfer has to occur over unicast,
   individually addressing the servers in the group.

   Additional considerations are discussed in Appendix E.3, with respect
   to requests including a CoAP Echo Option
   [I-D.ietf-core-echo-request-tag] that has to be sent over unicast, as
   a challenge-response method for servers to achieve synchronization of
   client Sender Sequence Numbers.

10.8.  End-to-end Protection

   The same considerations from Section 12.1 of [RFC8613] hold for Group
   OSCORE.

   Additionally, (D)TLS and Group OSCORE can be combined for protecting
   message exchanges occurring over unicast.  However, it is not
   possible to combine DTLS and Group OSCORE for protecting message
   exchanges where messages are (also) sent over multicast.

10.9.  Master Secret

   Group OSCORE derives the Security Context using the same construction
   as OSCORE, and by using the Group Identifier of a group as the
   related ID Context.  Hence, the same required properties of the
   Security Context parameters discussed in Section 3.3 of [RFC8613]
   hold for this document.

   With particular reference to the OSCORE Master Secret, it has to be
   kept secret among the members of the respective OSCORE group and the
   Group Manager responsible for that group.  Also, the Master Secret
   must have a good amount of randomness, and the Group Manager can
   generate it offline using a good random number generator.  This specification establishes
   includes the IANA "Counter Signature Key
   Parameters" Registry.  The Registry has been created to use case where the
   "Expert Review Required" registration procedure [RFC8126].  Expert
   review guidelines Group Manager rekeys the group by
   generating and distributing a new Master Secret.  Randomness
   requirements for security are provided described in [RFC4086].

10.10.  Replay Protection

   As in OSCORE, also Group OSCORE relies on sender sequence numbers
   included in the COSE message field 'Partial IV' and used to build
   AEAD nonces.

   Note that the Partial IV of an endpoint does not necessarily grow
   monotonically.  For instance, upon exhaustion of the endpoint Sender
   Sequence Number, the Partial IV also gets exhausted.  As discussed in
   Section 11.4.

   This registry specifies 2.4.3, this results either in the parameters endpoint being individually
   rekeyed and getting a new Sender ID, or in the establishment of countersignature keys for
   each admitted countersignature algorithm, as well a new
   Security Context in the group.  Therefore, uniqueness of (key, nonce)
   pairs (see Section 10.2) is preserved also when a new Security
   Context is established.

   As discussed in Section 6.1, an endpoint that has just joined a group
   is exposed to replay attack, as it is not aware of the possible
   structure they sender
   sequence numbers currently used by other group members.  Appendix E
   describes how endpoints can synchronize with senders' sequence
   numbers.

   Unless exchanges in a group rely only on unicast messages, Group
   OSCORE cannot be used with reliable transport.  Thus, unless only
   unicast messages are sent in the group, it cannot be defined that
   only messages with sequence numbers that are organized into.  This information is used equal to
   populate the parameter Counter Signature Key Parameters previous
   sequence number + 1 are accepted.

   The processing of the Common
   Context (see response messages described in Section 2).

   The columns 2.3.1 of this table are:

   o  Name: A value
   [I-D.ietf-core-groupcomm-bis] also ensures that can be used a client accepts a
   single valid response to identify an algorithm in
      documents for easier comprehension.  Its value is taken a given request from the
      'Name' column each replying server,
   unless CoAP observation is used.

10.11.  Client Aliveness

   As discussed in Section 12.5 of [RFC8613], a server may use the "COSE Algorithms" Registry.

   o  Value: The value to be used CoAP
   Echo Option [I-D.ietf-core-echo-request-tag] to identify this algorithm.  Its
      content is taken from verify the 'Value' column aliveness
   of the "COSE Algorithms"
      Registry.  The value MUST be the same one used in the "COSE
      Algorithms" Registry for client that originated a received request.  This would also
   allow the entry server to (re-)synchronize with the same 'Name' field.

   o  Parameters: This indicates the CBOR encoding of client's sequence
   number, as well as to ensure that the key parameters
      (if any) for request is fresh and has not
   been replayed or (purposely) delayed, if it is the counter signature algorithm indicated by first one received
   from that client after having joined the
      'Value' field.

   o  Description: A short description group or rebooted (see
   Appendix E.3).

10.12.  Cryptographic Considerations

   The same considerations from Section 12.6 of [RFC8613] about the parameters encoded
   maximum Sender Sequence Number hold for Group OSCORE.

   As discussed in the
      'Parameters' field (if any).

   o  Reference: This contains Section 2.4.2, an endpoint that experiences an
   exhaustion of its own Sender Sequence Number MUST NOT transmit
   further messages including a pointer Partial IV, until it has derived a new
   Sender Context.  This prevents the endpoint to reuse the public specification for same AEAD
   nonces with the field, if one exists.

   Initial entries in same Sender Key.

   In order to renew its own Sender Context, the registry are as follows.

  +-------------+-------+--------------+-------------------+-----------+
  |    Name     | Value |  Parameters  |   Description     | Reference |
  +-------------+-------+--------------+-------------------+-----------+
  |             |       |              |                   |           |
  |    EdDSA    |  -8   | [kty : int , | kty value is 1,   | [This     |
  |             |       |              | as Key Type "OKP" | Document] |
  |             |       |              | from endpoint SHOULD inform
   the COSE Key |           |
  |             |       |              | Types Registry    |           |
  |             |       |              |                   |           |
  |             |       |              |                   |           |
  |             |       |  crv : int]  | crv value taken   |           |
  |             |       |              | from Group Manager, which can either renew the COSE     |           |
  |             |       |              | Elliptic Curve    |           |
  |             |       |              | Registry          |           |
  |             |       |              |                   |           |
  +-------------+-------+--------------+-------------------+-----------+
  |             |       |              |                   |           |
  |    ES256    |  -7   | [kty : int , | kty value is 2,   | [This     |
  |             |       |              | as Key Type "EC2" | Document] |
  |             |       |              | from whole Security Context
   by means of group rekeying, or provide only that endpoint with a new
   Sender ID value.  In either case, the COSE Key |           |
  |             |       |              | Types Registry    |           |
  |             |       |              |                   |           |
  |             |       |              |                   |           |
  |             |       |  crv : int]  | crv value taken   |           |
  |             |       |              | from endpoint derives a new Sender
   Context, and in particular a new Sender Key.

   Additionally, the COSE     |           |
  |             |       |              | Elliptic Curve    |           |
  |             |       |              | Registry          |           |
  |             |       |              |                   |           |
  +-------------+-------+--------------+-------------------+-----------+
  |             |       |              |                   |           |
  |    ES384    |  -35  | [kty : int , | kty value is 2,   | [This     |
  |             |       |              | as Key Type "EC2" | Document] |
  |             |       |              | same considerations from Section 12.6 of [RFC8613]
   hold for Group OSCORE, about building the COSE Key |           |
  |             |       |              | Types Registry    |           |
  |             |       |              |                   |           |
  |             |       |  crv : int]  | crv value taken   |           |
  |             |       |              | from AEAD nonce and the COSE     |           |
  |             |       |              | Elliptic Curve    |           |
  |             |       |              | Registry          |           |
  |             |       |              |                   |           |
  +-------------+-------+--------------+-------------------+-----------+
  |             |       |              |                   |           |
  |    ES512    |  -36  | [kty : int , | kty value is 2,   | [This     |
  |             |       |              | as Key Type "EC2" | Document] |
  |             |       |              | from secrecy
   of the COSE Key |           |
  |             |       |              | Types Registry    |           |
  |             |       |              |                   |           |
  |             |       |  crv : int]  | crv value taken   |           |
  |             |       |              | from Security Context parameters.

   The EdDSA signature algorithm Ed25519 [RFC8032] is mandatory to
   implement.  For endpoints that support the COSE     |           |
  |             |       |              | Elliptic Curve    |           |
  |             |       |              | Registry          |           |
  |             |       |              |                   |           |
  +-------------+-------+--------------+-------------------+-----------+
  |             |       |              |                   |           |
  |    PS256    |  -37  |  kty : int   | kty value pairwise mode of Group
   OSCORE, the X25519 function [RFC7748] is 3,   | [This     |
  |             |       |              | also mandatory to implement.
   Montgomery curves and (twisted) Edwards curves [RFC7748] can be
   alternatively represented in short-Weierstrass form as Key Type "RSA" | Document] |
  |             |       |              | from described in
   [I-D.ietf-lwig-curve-representations].

   For many constrained IoT devices, it is problematic to support more
   than one signature algorithm or multiple whole cipher suites.  As a
   consequence, some deployments using, for instance, ECDSA with NIST
   P-256 may not support the COSE Key |           |
  |             |       |              | Types Registry    |           |
  |             |       |              |                   |           |
  +-------------+-------+--------------+-------------------+-----------+
  |             |       |              |                   |           |
  |    PS384    |  -38  |  kty : int   | kty value mandatory signature algorithm but that
   should not be an issue for local deployments.

   The derivation of pairwise keys defined in Section 2.3.1 is 3,   | [This     |
  |             |       |              | as Key Type "RSA" | Document] |
  |             |       |              | from
   compatible with ECDSA and EdDSA asymmetric keys, but is not
   compatible with RSA asymmetric keys.  The security of using the COSE Key |           |
  |             |       |              | Types Registry    |           |
  |             |       |              |                   |           |
  +-------------+-------+--------------+-------------------+-----------+
  |             |       |              |                   |           |
  |    PS512    |  -39  |  kty : int   | kty value same
   key pair for Diffie-Hellman and for signing is 3,   | [This     |
  |             |       |              | as Key Type "RSA" | Document] |
  |             |       |              | demonstrated in
   [Degabriele].

10.13.  Message Segmentation

   The same considerations from the COSE Key |           |
  |             |       |              | Types Registry    |           |
  |             |       |              |                   |           |
  +-------------+-------+--------------+-------------------+-----------+

11.3. Section 12.7 of [RFC8613] hold for Group
   OSCORE.

10.14.  Privacy Considerations

   Group OSCORE Flag Bits Registry

   IANA is asked to add ensures end-to-end integrity protection and encryption
   of the following value entry message payload and all options that are not used for proxy
   operations.  In particular, options are processed according to the "OSCORE Flag
   Bits" subregistry defined in
   same class U/I/E that they have for OSCORE.  Therefore, the same
   privacy considerations from Section 13.7 12.8 of [RFC8613] as part of hold for Group
   OSCORE.

   Furthermore, the
   "CoRE Parameters" registry.

   +--------------+-------------+--------------------------+-----------+
   | Bit Position |     Name    |        Description       | Reference |
   +--------------+-------------+--------------------------+-----------+
   |       2      | Pairwise    | Set to 1 if following privacy considerations hold, about the message  | [This     |
   |              | Protection  |
   OSCORE option that may reveal information on the communicating
   endpoints.

   o  The 'kid' parameter, which is protected with        | Document] |
   |              | Flag        | pairwise keying material |           |
   +--------------+-------------+--------------------------+-----------+

11.4.  Expert Review Instructions intended to help a recipient
      endpoint to find the right Recipient Context, may reveal
      information about the Sender Endpoint.  Since both requests and
      responses always include the 'kid' parameter, this may reveal
      information about both a client sending a group request and all
      the possibly replying servers sending their own individual
      response.

   o  The IANA Registries established 'kid context' parameter, which is intended to help a recipient
      endpoint to find the right Recipient Context, reveals information
      about the sender endpoint.  In particular, it reveals that the
      sender endpoint is a member of a particular OSCORE group, whose
      current Group ID is indicated in this document are defined the 'kid context' parameter.

   When receiving a group request, each of the recipient endpoints can
   reply with a response that includes its Sender ID as
   "Expert Review".  This section gives some general guidelines for what
   the experts should 'kid' parameter.
   All these responses will be looking for, but they are being designated as
   experts for matchable with the request through the
   Token.  Thus, even if these responses do not include a reason so they should be given substantial latitude.

   Expert reviewers should take into consideration 'kid context'
   parameter, it becomes possible to understand that the following points:

   o  Clarity and correctness of registrations.  Experts responder
   endpoints are expected to
      check in the clarity of purpose and use same group of the requested entries.
      Experts should inspect the entry for requester endpoint.

   Furthermore, using the algorithm considered, mechanisms described in Appendix E.3 to
      verify the conformity of
   achieve sequence number synchronization with a client may reveal when
   a server device goes through a reboot.  This can be mitigated by the encoding proposed against
   server device storing the
      theoretical algorithm, including completeness precise state of the 'Parameters'
      column.  Expert needs to make sure values are taken from the right
      registry, when that's required.  Expert should consider requesting
      an opinion replay window of each
   known client on a clean shutdown.

   Finally, the correctness mechanism described in Section 10.5 to prevent
   collisions of registered parameters Group Identifiers from the
      CBOR Object Signing and Encryption Working different Group (COSE).

      Encodings that do not meet these objective of clarity and
      completeness should not be registered.

   o  Duplicated registration and point squatting should be discouraged.
      Reviewers are encouraged to get sufficient Managers may
   reveal information for
      registration requests to ensure that about events in the usage is not going to
      duplicate one that is already registered and that respective OSCORE groups.  In
   particular, a Group Identifier changes when the point corresponding group
   is
      likely to be used in deployments.

   o  Experts should take into account rekeyed.  Thus, Group Managers might use the expected usage of fields when
      approving point assignment.  The length shared list of Group
   Identifiers to infer the 'Parameters'
      encoding rate and patterns of group membership
   changes triggering a group rekeying, e.g. due to newly joined members
   or evicted (compromised) members.  In order to alleviate this privacy
   concern, it should be weighed against hidden from the usage Group Managers which exact
   Group Manager has currently assigned which Group Identifiers in its
   OSCORE groups.

11.  IANA Considerations

   Note to RFC Editor: Please replace all occurrences of "[This
   Document]" with the entry,
      considering the size RFC number of device it will be used on.  Additionally, this specification and delete this
   paragraph.

   This document has the length of following actions for IANA.

11.1.  OSCORE Flag Bits Registry

   IANA is asked to add the encoded following value should be weighed against how many
      code points of that length are left, entry to the size "OSCORE Flag
   Bits" subregistry defined in Section 13.7 of device it will be
      used on, and the number [RFC8613] as part of code points left that encode to that
      size.

   o  Specifications are recommended.  When specifications are not
      provided, the description provided needs to have sufficient
      information
   "CoRE Parameters" registry.

+--------------+------------+-------------------------------+-----------+
| Bit Position |    Name    |         Description           | Reference |
+--------------+------------+-------------------------------+-----------+
|       2      | Group Flag | Set to verify 1 if the points above. message is    | [This     |
|              |            | protected with the group mode | Document] |
|              |            | of Group OSCORE               |           |
+--------------+------------+-------------------------------+-----------+

12.  References

12.1.  Normative References

   [COSE.Algorithms]
              IANA, "COSE Algorithms",
              <https://www.iana.org/assignments/cose/
              cose.xhtml#algorithms>.

   [COSE.Key.Types]
              IANA, "COSE Key Types",
              <https://www.iana.org/assignments/cose/
              cose.xhtml#key-type>.

   [I-D.ietf-core-groupcomm-bis]
              Dijk, E., Wang, C., and M. Tiloca, "Group Communication
              for the Constrained Application Protocol (CoAP)", draft-
              ietf-core-groupcomm-bis-00 (work in progress), March 2020.

   [I-D.ietf-cose-rfc8152bis-algs]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-09
              (work in progress), June 2020.

   [I-D.ietf-cose-rfc8152bis-struct]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", draft-ietf-cose-rfc8152bis-
              struct-10 (work in progress), June 2020.

   [NIST-800-56A]
              Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
              Davis, "Recommendation for Pair-Wise Key-Establishment
              Schemes Using Discrete Logarithm Cryptography - NIST
              Special Publication 800-56A, Revision 3", April 2018,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-56Ar3.pdf>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.

   [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
              Algorithm (DSA) and Elliptic Curve Digital Signature
              Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
              2013, <https://www.rfc-editor.org/info/rfc6979>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.
              <https://www.rfc-editor.org/info/rfc8032>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/info/rfc8613>.

12.2.  Informative References

   [Degabriele]
              Degabriele, J., Lehmann, A., Paterson, K., Smart, N., and
              M. Strefler, "On the Joint Security of Encryption and
              Signature in EMV", December 2011,
              <https://eprint.iacr.org/2011/615>.

   [I-D.ietf-ace-key-groupcomm]
              Palombini, F. and M. Tiloca, "Key Provisioning for Group
              Communication using ACE", draft-ietf-ace-key-groupcomm-05 draft-ietf-ace-key-groupcomm-07
              (work in progress), March June 2020.

   [I-D.ietf-ace-key-groupcomm-oscore]
              Tiloca, M., Park, J., and F. Palombini, "Key Management
              for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm-
              oscore-05
              oscore-07 (work in progress), March June 2020.

   [I-D.ietf-ace-oauth-authz]
              Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
              H. Tschofenig, "Authentication and Authorization for
              Constrained Environments (ACE) using the OAuth 2.0
              Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 draft-ietf-ace-oauth-authz-34
              (work in progress), February June 2020.

   [I-D.ietf-core-echo-request-tag]
              Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,
              Request-Tag, and Token Processing", draft-ietf-core-echo-
              request-tag-09 (work in progress), March 2020.

   [I-D.ietf-lwig-curve-representations]
              Struik, R., "Alternative Elliptic Curve Representations",
              draft-ietf-lwig-curve-representations-10 (work in
              progress), April 2020.

   [I-D.ietf-lwig-security-protocol-comparison]
              Mattsson, J., Palombini, F., and M. Vucinic, "Comparison
              of CoAP Security Protocols", draft-ietf-lwig-security-
              protocol-comparison-04 (work in progress), March 2020.

   [I-D.mattsson-cfrg-det-sigs-with-noise]
              Mattsson, J., Thormarker, E., and S. Ruohomaa,
              "Deterministic ECDSA and EdDSA Signatures with Additional
              Randomness", draft-mattsson-cfrg-det-sigs-with-noise-02
              (work in progress), March 2020.

   [I-D.somaraju-ace-multicast]
              Somaraju, A., Kumar, S., Tschofenig, H., and W. Werner,
              "Security for Low-Latency Group Communication", draft-
              somaraju-ace-multicast-02 (work in progress), October
              2016.

   [I-D.tiloca-core-observe-multicast-notifications]
              Tiloca, M., Hoeglund, R., Amsuess, C., and F. Palombini,
              "Observe Notifications as CoAP Multicast Responses",
              draft-tiloca-core-observe-multicast-notifications-02 (work
              in progress), March 2020.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <https://www.rfc-editor.org/info/rfc4944>.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <https://www.rfc-editor.org/info/rfc4949>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <https://www.rfc-editor.org/info/rfc6282>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <https://www.rfc-editor.org/info/rfc6347>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [RFC7641]  Hartke, K., "Observing Resources in the Constrained
              Application Protocol (CoAP)", RFC 7641,
              DOI 10.17487/RFC7641, September 2015,
              <https://www.rfc-editor.org/info/rfc7641>.

   [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
              the Constrained Application Protocol (CoAP)", RFC 7959,
              DOI 10.17487/RFC7959, August 2016,
              <https://www.rfc-editor.org/info/rfc7959>.

Appendix A.  Assumptions and Security Objectives

   This section presents a set of assumptions and security objectives
   for the approach described in this document.  The rest of this
   section refers to three types of groups:

   o  Application group, i.e. a set of CoAP endpoints that share a
      common pool of resources.

   o  Security group, as defined in Section 1.1 of this specification.
      There can be a one-to-one or a one-to-many relation between
      security groups and application groups. groups, and vice versa.  Any two
      application groups associated to the same security group do not
      share any same resource.

   o  CoAP group, as defined in [I-D.ietf-core-groupcomm-bis] i.e. a set
      of CoAP endpoints, where each endpoint is configured to receive
      CoAP multicast requests that are sent to the group's associated IP
      multicast address and UDP port.  An endpoint may be a member of
      multiple CoAP groups.  There can be a one-to-one or a one-to-many
      relation between CoAP application groups and application CoAP groups.  Note that a
      device sending a CoAP request to a CoAP group is not necessarily
      itself a member of that group: it is a member only if it also has
      a CoAP server endpoint listening to requests for this CoAP group,
      sent to the associated IP multicast address and port.  In order to
      provide secure group communication, all members of a CoAP group as
      well as all further endpoints configured only as clients sending
      CoAP (multicast) requests to the CoAP group have to be member of a
      security group.  There can be a one-to-one or a one-to-many
      relation between security groups and CoAP groups, and vice versa.

A.1.  Assumptions

   The following assumptions are assumed to be already addressed and are
   out of the scope of this document.

   o  Multicast communication topology: this document considers both
      1-to-N (one sender and multiple recipients) and M-to-N (multiple
      senders and multiple recipients) communication topologies.  The
      1-to-N communication topology is the simplest group communication
      scenario that would serve the needs of a typical Low-power and
      Lossy Network (LLN).  Examples of use cases that benefit from
      secure group communication are provided in Appendix B.

      In a 1-to-N communication model, only a single client transmits
      data to the CoAP group, in the form of request messages; in an
      M-to-N communication model (where M and N do not necessarily have
      the same value), M clients transmit data to the CoAP group.
      According to [I-D.ietf-core-groupcomm-bis], any possible proxy
      entity is supposed to know about the clients and to not perform
      aggregation of response messages from multiple servers.  Also,
      every client expects and is able to handle multiple response
      messages associated to a same request sent to the CoAP group.

   o  Group size: security solutions for group communication should be
      able to adequately support different and possibly large security
      groups.  The group size is the current number of members in a
      security group.  In the use cases mentioned in this document, the
      number of clients (normally the controlling devices) is expected
      to be much smaller than the number of servers (i.e. the controlled
      devices).  A security solution for group communication that
      supports 1 to 50 clients would be able to properly cover the group
      sizes required for most use cases that are relevant for this
      document.  The maximum group size is expected to be in the range
      of 2 to 100 devices.  Security groups larger than that should be
      divided into smaller independent groups.

   o  Communication with the Group Manager: an endpoint must use a
      secure dedicated channel when communicating with the Group
      Manager, also when not registered as a member of the security
      group.

   o  Provisioning and management of Security Contexts: a Security
      Context must be established among the members of the security
      group.  A secure mechanism must be used to generate, revoke and
      (re-)distribute keying material, multicast security communication policies and
      security parameters in the security group.  The actual
      provisioning and management of the Security Context is out of the
      scope of this document.

   o  Multicast data security ciphersuite: all members of a security
      group must agree on a ciphersuite to provide authenticity,
      integrity and confidentiality of messages in the group.  The
      ciphersuite is specified as part of the Security Context.

   o  Backward security: a new device joining the security group should
      not have access to any old Security Contexts used before its
      joining.  This ensures that a new member of the security group is
      not able to decrypt confidential data sent before it has joined
      the security group.  The adopted key management scheme should
      ensure that the Security Context is updated to ensure backward
      confidentiality.  The actual mechanism to update the Security
      Context and renew the group keying material in the security group
      upon a new member's joining has to be defined as part of the group
      key management scheme.

   o  Forward security: entities that leave the security group should
      not have access to any future Security Contexts or message
      exchanged within the security group after their leaving.  This
      ensures that a former member of the security group is not able to
      decrypt confidential data sent within the security group anymore.
      Also, it ensures that a former member is not able to send
      encrypted and/or integrity
      protected messages to the security group anymore.  The actual
      mechanism to update the Security Context and renew the group
      keying material in the security group upon a member's leaving has
      to be defined as part of the group key management scheme.

A.2.  Security Objectives

   The approach described in this document aims at fulfilling the
   following security objectives:

   o  Data replay protection: group request messages or response
      messages replayed within the security group must be detected.

   o  Group-level data  Data confidentiality: messages sent within the security group
      shall be encrypted if privacy sensitive encrypted.

   o  Group-level data is
      exchanged within confidentiality: the security group.  This document considers
      group-level group mode provides group-
      level data confidentiality since messages are encrypted at a group
      level, i.e. in such a way that they can be decrypted by any member
      of the security group, but not by an external adversary or other
      external entities.

   o  Pairwise data confidentiality: the pairwise mode especially
      provides pairwise data confidentiality, since messages are
      encrypted using pairwise keying material shared between any two
      group members, hence they can be decrypted only by the intended
      single recipient.

   o  Source message authentication: messages sent within the security
      group shall be authenticated.  That is, it is essential to ensure
      that a message is originated by a member of the security group in
      the first place, and in particular by a specific specific, identifiable
      member of the security group.

   o  Message integrity: messages sent within the security group shall
      be integrity protected.  That is, it is essential to ensure that a
      message has not been tampered with with, either by a group member, or
      by an external adversary or other external entities which are not
      members of the security group.

   o  Message ordering: it must be possible to determine the ordering of
      messages coming from a single sender.  In accordance with OSCORE
      [RFC8613], this results in providing absolute freshness of
      responses that are not notifications, as well as relative
      freshness of group requests and absolute freshness of notification responses.  It is not
      required to determine ordering of messages from different senders.

Appendix B.  List of Use Cases

   Group Communication for CoAP [I-D.ietf-core-groupcomm-bis] provides
   the necessary background for multicast-based CoAP communication, with
   particular reference to low-power and lossy networks (LLNs) and
   resource constrained environments.  The interested reader is
   encouraged to first read [I-D.ietf-core-groupcomm-bis] to understand
   the non-security related details.  This section discusses a number of
   use cases that benefit from secure group communication, and refers to
   the three types of groups from Appendix A.  Specific security
   requirements for these use cases are discussed in Appendix A.

   o  Lighting control: consider a building equipped with IP-connected
      lighting devices, switches, and border routers.  The lighting
      devices acting as servers are organized into application groups
      and CoAP groups, according to their physical location in the
      building.  For instance, lighting devices in a room or corridor
      can be configured as members of a single application group and
      corresponding CoAP group.  Those ligthing devices together with
      the switches acting as clients in the same room or corridor can be
      configured as members of the corresponding security group.
      Switches are then used to control the lighting devices by sending
      on/off/dimming commands to all lighting devices in the CoAP group,
      while border routers connected to an IP network backbone (which is
      also multicast-enabled) can be used to interconnect routers in the
      building.  Consequently, this would also enable logical groups to
      be formed even if devices with a role in the lighting application
      may be physically in different subnets (e.g. on wired and wireless
      networks).  Connectivity between lighting devices may be realized,
      for instance, by means of IPv6 and (border) routers supporting
      6LoWPAN [RFC4944][RFC6282].  Group communication enables
      synchronous operation of a set of connected lights, ensuring that
      the light preset (e.g. dimming level or color) of a large set of
      luminaires are changed at the same perceived time.  This is
      especially useful for providing a visual synchronicity of light
      effects to the user.  As a practical guideline, events within a
      200 ms interval are perceived as simultaneous by humans, which is
      necessary to ensure in many setups.  Devices may reply back to the
      switches that issue on/off/dimming commands, in order to report
      about the execution of the requested operation (e.g.  OK, failure,
      error) and their current operational status.  In a typical
      lighting control scenario, a single switch is the only entity
      responsible for sending commands to a set of lighting devices.  In
      more advanced lighting control use cases, a M-to-N communication
      topology would be required, for instance in case multiple sensors
      (presence or day-light) are responsible to trigger events to a set
      of lighting devices.  Especially in professional lighting
      scenarios, the roles of client and server are configured by the
      lighting commissioner, and devices strictly follow those roles.

   o  Integrated building control: enabling Building Automation and
      Control Systems (BACSs) to control multiple heating, ventilation
      and air-conditioning units to pre-defined presets.  Controlled
      units can be organized into application groups and CoAP groups in
      order to reflect their physical position in the building, e.g.
      devices in the same room can be configured as members of a single
      application group and corresponding CoAP group.  As a practical
      guideline, events within intervals of seconds are typically
      acceptable.  Controlled units are expected to possibly reply back
      to the BACS issuing control commands, in order to report about the
      execution of the requested operation (e.g.  OK, failure, error)
      and their current operational status.

   o  Software and firmware updates: software and firmware updates often
      comprise quite a large amount of data.  This can overload a Low-
      power and Lossy Network (LLN) that is otherwise typically used to
      deal with only small amounts of data, on an infrequent base.
      Rather than sending software and firmware updates as unicast
      messages to each individual device, multicasting such updated data
      to a larger set of devices at once displays a number of benefits.
      For instance, it can significantly reduce the network load and
      decrease the overall time latency for propagating this data to all
      devices.  Even if the complete whole update process itself is
      secured, securing the individual messages is important, in case
      updates consist of relatively large amounts of data.  In fact,
      checking individual received data piecemeal for tampering avoids
      that devices store large amounts of partially corrupted data and
      that they detect tampering hereof only after all data has been
      received.  Devices receiving software and firmware updates are
      expected to possibly reply back, in order to provide a feedback
      about the execution of the update operation (e.g.  OK, failure,
      error) and their current operational status.

   o  Parameter and configuration update: by means of multicast
      communication, it is possible to update the settings of a set of
      similar devices, both simultaneously and efficiently.  Possible
      parameters are related, for instance, to network load management
      or network access controls.  Devices receiving parameter and
      configuration updates are expected to possibly reply back, to
      provide a feedback about the execution of the update operation
      (e.g.  OK, failure, error) and their current operational status.

   o  Commissioning of Low-power and Lossy Network (LLN) systems: a
      commissioning device is responsible for querying all devices in
      the local network or a selected subset of them, in order to
      discover their presence, and be aware of their capabilities,
      default configuration, and operating conditions.  Queried devices
      displaying similarities in their capabilities and features, or
      sharing a common physical location can be configured as members of
      a single application group and corresponding CoAP group.  Queried
      devices are expected to reply back to the commissioning device, in
      order to notify their presence, and provide the requested
      information and their current operational status.

   o  Emergency multicast: a particular emergency related information
      (e.g. natural disaster) is generated and multicast by an emergency
      notifier, and relayed to multiple devices.  The latter may reply
      back to the emergency notifier, in order to provide their feedback
      and local information related to the ongoing emergency.  This kind
      of setups should additionally rely on a fault tolerance multicast
      algorithm, such as Multicast Protocol for Low-Power and Lossy
      Networks (MPL).

Appendix C.  Example of Group Identifier Format

   This section provides an example of how the Group Identifier (Gid)
   can be specifically formatted.  That is, the Gid can be composed of
   two parts, namely a Group Prefix and a Group Epoch.

   For each group, the Group Prefix is constant over time and is
   uniquely defined in the set of all the groups associated to the same
   Group Manager.  The choice of the Group Prefix for a given group's
   Security Context is application specific.  The size of the Group
   Prefix directly impact on the maximum number of distinct groups under
   the same Group Manager.

   The Group Epoch is set to 0 upon the group's initialization, and is
   incremented by 1 upon completing each renewal of the Security Context
   and time new keying material in the group (see Section 2.4).  In particular,
   once material, including a new Master Secret has been Gid,
   is distributed to the group, all the group members increment by 1 the Group Epoch in the Group Identifier
   of that group. order to establish a new Security
   Context (see Section 3.1).

   As an example, a 3-byte Group Identifier Gid can be composed of: i) a 1-byte Group
   Prefix '0xb1' interpreted as a raw byte string; and ii) a 2-byte
   Group Epoch interpreted as an unsigned integer ranging from 0 to
   65535.  Then, after having established the Common Context 61532 times
   in the group, its Group Identifier Gid will assume value '0xb1f05c'.

   Using an immutable Group Prefix for a group assumes that enough time
   elapses between two consecutive usages of the same Group Epoch value
   in that group.  This ensures that the Gid value is temporally unique
   during the lifetime of a given message.  Thus, the expected highest
   rate for addition/removal of group members and consequent group
   rekeying should be taken into account for a proper dimensioning of
   the Group Epoch size.

   As discussed in Section 10.5, if endpoints are deployed in multiple
   groups managed by different non-synchronized Group Managers, it is
   possible that Group Identifiers of different groups coincide at some
   point in time.  In this case, a recipient has to handle coinciding
   Group Identifiers, and has to try using different Security Contexts
   to process an incoming message, until the right one is found and the
   message is correctly verified.  Therefore, it is favourable that
   Group Identifiers from different Group Managers have a size that
   result in a small probability of collision.  How small this
   probability should be is up to system designers.

Appendix D.  Set-up of New Endpoints

   An endpoint joins a group by explicitly interacting with the
   responsible Group Manager.  When becoming members of a group,
   endpoints are not required to know how many and what endpoints are in
   the same group.

   Communications between a joining endpoint and the Group Manager rely
   on the CoAP protocol and must be secured.  Specific details on how to
   secure communications between joining endpoints and a Group Manager
   are out of the scope of this document.

   The Group Manager must verify that the joining endpoint is authorized
   to join the group.  To this end, the Group Manager can directly
   authorize the joining endpoint, or expect it to provide authorization
   evidence previously obtained from a trusted entity.  Further details
   about the authorization of joining endpoints are out of scope.

   In case of successful authorization check, the Group Manager
   generates a Sender ID assigned to the joining endpoint, before
   proceeding with the rest of the join process.  That is, the Group
   Manager provides the joining endpoint with the keying material and
   parameters to initialize the Security Context (see Section 2).  The
   actual provisioning of keying material and parameters to the joining
   endpoint is out of the scope of this document.

   It is RECOMMENDED that the join process adopts the approach described
   in [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework
   for Authentication and Authorization in constrained environments
   [I-D.ietf-ace-oauth-authz].

Appendix E.  Examples of Synchronization Approaches

   This section describes three possible approaches that can be
   considered by server endpoints to synchronize with sender sequence
   numbers Sender Sequence
   Numbers of client endpoints sending group requests.

   The Group Manager MAY indicate which of such approaches are used in
   the group, as part of client endpoints sending the group requests. communication policies signalled to
   candidate group members upon their group joining.

E.1.  Best-Effort Synchronization

   Upon receiving a group request from a client, a server does not take
   any action to synchonize synchronize with the sender sequence number of that
   client.  This provides no assurance at all as to message freshness,
   which can be acceptable in non-critical use cases.

   With the notable exception of Observe notifications and responses
   following a group rekeying, it is optional for the server to use its
   own the
   sender sequence number as Partial IV.  Instead, for efficiency
   reasons, the server may rather use the request's Partial IV when
   protecting a response.

   Since it provides no assurance as to freshness of requests, it is
   thus RECOMMENDED that a server using this synchronization approach
   always uses its own sender sequence number as Partial IV when
   protecting a response.

E.2.  Baseline Synchronization

   Upon receiving a group request from a given client for the first
   time, a server initializes its last-seen sender sequence number Sender Sequence Number in
   its Recipient Context associated to that client.  The server may also
   drop the group request without delivering it to the application.
   This method provides a reference point to identify if future group
   requests from the same client are fresher than the last one received.

   A replay time interval exists, between when a possibly replayed or
   delayed message is originally transmitted by a given client and the
   first authentic fresh message from that same client is received.
   This can be acceptable for use cases where servers admit such a
   trade-off between performance and assurance of message freshness.

   With the notable exception of Observe notifications and responses
   following a group rekeying, it is optional for the server to use its
   own sender sequence number Sender Sequence Number as Partial IV.  Instead, for efficiency
   reasons, the server may rather use the request's Partial IV when
   protecting a response.

   In case the baseline synchronization state related to a client is
   lost, it is RECOMMENDED that the server uses its own sender sequence
   number as Partial IV when protecting a response to that client, until
   a new baseline synchronization state for that client is established.

E.3.  Challenge-Response Synchronization

   A server performs a challenge-response exchange with a client, by
   using the Echo Option for CoAP described in Section 2 of
   [I-D.ietf-core-echo-request-tag] and according to Appendix B.1.2 of
   [RFC8613].

   That is, upon receiving a group request from a particular client for
   the first time, the server processes the message as described in this
   specification, but, even if valid, does not deliver it to the
   application.  Instead, the server replies to the client with an
   OSCORE protected 4.01 (Unauthorized) response message, including only
   the Echo Option and no diagnostic payload.  Since this response is
   protected with the Security Context used in the group, the client
   will consider the response valid upon successfully decrypting and
   verifying it.

   The server stores the
   option Echo Option value included therein. therein, together
   with the pair (gid,kid), where 'gid' is the Group Identifier of the
   OSCORE group and 'kid' is the Sender ID of the client in the group,
   as specified in the 'kid context' and 'kid' fields of the OSCORE
   Option of the group request, respectively.  After a group rekeying
   has been completed and a new Security Context has been established in
   the group, which results also in a new Group Identifier (see
   Section 3.1), the server MUST delete all the stored Echo values
   associated to members of that group.

   Upon receiving a 4.01 (Unauthorized) response that includes an Echo
   Option and originates from a verified group member, a client sends a
   request as a unicast message addressed to the same server, echoing same server, echoing
   the Echo Option value.  The client MUST NOT send the request
   including the Echo Option value. over multicast.

   In particular, the client does not necessarily resend the same group
   request, but can instead send a more recent one, if the application
   permits it.  This makes it possible for the client to not retain
   previously sent group requests for full retransmission, unless the
   application explicitly requires otherwise.  In either case, the
   client uses the sender sequence
   number Sender Sequence Number value currently stored in its
   own Sender Context.  If the client stores group requests for possible
   retransmission with the Echo Option, it should not store a given
   request for longer than a pre-configured time interval.  Note that
   the unicast request echoing the Echo Option is correctly treated and
   processed as a message, since the 'kid context' field including the
   Group Identifier of the OSCORE group is still present in the OSCORE
   Option as part of the COSE object (see Section 4).

   Upon receiving the unicast request including the Echo Option, the
   server performs the following verifications.

   o  If the server does not store an Echo Option value for the pair
      (gid,kid), it considers: i) the time t1 when it has established
      the Security Context used to protect the received request; and ii)
      the time t2 when the request has been received.  Since a valid
      request cannot be older than the Security Context used to protect
      it, the server verifies that (t2 - t1) is less than the largest
      amount of time acceptable to consider the request fresh.

   o  If the server stores an Echo Option value for the pair (gid,kid)
      associated to that same client in the same group, the server
      verifies that the option value equals the that same stored and value
      previously sent value. by that client.

   If not, the verifications above fail, the server MUST NOT process the
   request further and MAY send a 4.01 (Unauthorized) response including
   an Echo option. Option.

   In case of positive verification, the request is further processed
   and verified.  Finally, the server updates the Recipient Context
   associated to that client, by setting the Replay Window according to
   the Sequence Number from the unicast request conveying the Echo
   Option.  The server either delivers the request to the application if
   it is an actual retransmission of the original one, or discards it
   otherwise.  Mechanisms to signal whether the resent request is a full
   retransmission of the original one are out of the scope of this
   specification.

   A server should not deliver group requests from a given client to the
   application until one valid request from that same client has been
   verified as fresh, as conveying an echoed Echo Option
   [I-D.ietf-core-echo-request-tag].  Also, a server may perform the
   challenge-response described above at any time, if synchronization
   with sender sequence numbers Sender Sequence Numbers of clients is (believed to be) lost, for
   instance after a device reboot.  A client has to be always ready to
   perform the challenge-response based on the Echo Option in case a
   server starts it.

   It is the role of the application to
   define under what circumstances sender sequence numbers lose
   synchronization.  This can include server application to define under what
   circumstances Sender Sequence Numbers lose synchronization.  This can
   include experiencing a "large enough" gap D = (SN2 - SN1), between
   the Sender Sequence Number SN1 of the latest accepted group request
   from a client and the Sender Sequence Number SN2 of a group request
   just received from that client.  However, a client may send several
   unicast requests to different group members as protected with the
   pairwise mode (see Section 9.2), which may consume the gap D at the
   server relatively fast.  This would induce the server to perform more
   challenge-response exchanges than actually needed.

   To ameliorate this, the server may rather rely on a trade-off between
   the Sender Sequence Number gap D and a minimum time gap between T = (t2 - t1), where
   t1 is the sender
   sequence number of time when the latest accepted group request from a client was
   accepted and t2 is the sender sequence number of a time when the latest group request just received from
   the same client.  A that
   client has to be always ready to perform been received, respectively.  Then, the server can start a
   challenge-response based on the Echo Option in case when experiencing a time gap T larger than a
   given, pre-configured threshold.  Also, the server starts
   it.

   This can start a
   challenge-response when experiencing a Sender Sequence Number gap D
   greater than a different threshold, computed as a monotonically
   increasing function of the currently experienced time gap T.

   The challenge-response approach described in this appendix provides
   an assurance of absolute message freshness.  However, it can result
   in an impact on performance which is undesirable or unbearable,
   especially in large groups where many endpoints at the same time
   might join as new members or lose synchronization.

   Note that endpoints configured as silent servers are not able to
   perform the challenge-response described above, as they do not store
   a Sender Context to secure the 4.01 (Unauthorized) response to the
   client.  Therefore, silent servers should adopt alternative
   approaches to achieve and maintain synchronization with sender
   sequence numbers of clients.

   Since requests including the Echo Option are sent over unicast, a
   server can be a victim of the attack discussed in Section 10.7, when
   such requests are protected with the signature group mode of Group OSCORE, as
   described in Section 7.1. 8.1.

   Instead, protecting requests with the Echo Option by using the
   pairwise mode of Group OSCORE as described in Appendix G.2 Section 9.2 prevents
   the attack in Section 10.7.  In fact, only the exact server involved
   in the Echo exchange is able to derive the correct pairwise key used
   by the client to protect the request including the Echo Option.

   In either case, an internal on-path adversary would not be able to
   mix up the Echo Option value of two different unicast requests, sent
   by a same client to any two different servers in the group.  In fact,
   if the group mode was used, this would require the adversary to forge
   the client's counter signature in both such requests.  As a
   consequence, each of the two servers remains able to selectively
   accept a request with the Echo Option only if it is waiting for that
   exact integrity-protected Echo Option value, and is thus the intended
   recipient.

Appendix F.  No Verification of Signatures in Group Mode

   There are some application scenarios using group communication that
   have particularly strict requirements.  One example of this is the
   requirement of low message latency in non-emergency lighting
   applications [I-D.somaraju-ace-multicast].  For those applications
   which have tight performance constraints and relaxed security
   requirements, it can be inconvenient for some endpoints to verify
   digital signatures in order to assert source authenticity of received
   messages.
   messages protected with the group mode.  In other cases, the
   signature verification can be deferred or only checked for specific
   actions.  For instance, a command to turn a bulb on where the bulb is
   already on does not need the signature to be checked.  In such
   situations, the counter signature needs to be included anyway as part of the message, so that an
   endpoint that needs to validate the signature for any reason has the
   ability to do so.

   In this specification, it is NOT RECOMMENDED that endpoints do not
   verify the counter signature of received messages.  However, it is
   recognized that there may be situations where it is not always
   required.  The consequence of not doing the signature validation is
   that security in the group is based only on the group-authenticity of
   the shared keying material used for encryption.  That is, endpoints
   in the group have evidence that a received message has been
   originated by a group member, although not specifically identifiable
   in a secure way.  This can violate a number of security requirements, be included anyway as the compromise part
   of any element in a message protected with the group means mode, so that an endpoint that
   needs to validate the attacker signature for any reason has the ability to control do
   so.

   In this specification, it is NOT RECOMMENDED that endpoints do not
   verify the entire group.  Even worse, counter signature of received messages protected with the
   group mode.  However, it is recognized that there may not be limited in scope, and hence the same keying material might
   be used not only for light bulbs but for locks as well.  Therefore,
   extreme care must be taken in situations
   where the security
   requirements are relaxed, so that deployment of the system will it is not always be done safely.

Appendix G.  Pairwise Mode

   For use cases that do required.  The consequence of not require an intermediary performing
   signature verification and that use a compatible signature algorithm,
   the pairwise mode defined in this section can be used for unicast
   communication.

   This mode uses doing the derivation process defined
   signature validation in Section 3, and
   allows two group members to protect requests and responses exchanged messages protected with each other using pairwise keying material.

   Senders MUST NOT use the pairwise group mode to protect a message addressed
   to multiple recipients or to the whole group.  This prevents a client
   that wants to address one specific server from protecting a request
   with the pairwise key associated to is
   that server, and then send the
   request over multicast.

   The pairwise mode results in the same performance and security
   improvements displayed by optimized responses (see Section 9.2).

G.1.  Pre-Requirements

   In order to protect an outgoing message in pairwise mode, a sender
   needs to know the public key and group is based only on the group-authenticity of
   the Recipient ID shared keying material used for encryption.  That is, endpoints
   in the group would have evidence that the received message
   recipient, has been
   originated by a group member, although not specifically identifiable
   in a secure way.  This can violate a number of security requirements,
   as stored the compromise of any element in its own Recipient Context associated to the group means that
   recipient.

   Furthermore, the sender needs attacker
   has the ability to know control the individual address of entire group.  Even worse, the
   message recipient.  This information group
   may not be known at any given
   point limited in time.  For instance, right after having joined the group, a
   client may know the public key scope, and Recipient ID hence the same keying material might
   be used not only for a given server, light bulbs but not the addressing information required to reach it with an
   individual, one-to-one request.

   To make this information available, servers MAY provide a resource to
   which a client can send a request for a server identified by its
   'kid' value, or a set thereof.  The specified set may locks as well.  Therefore,
   extreme care must be empty, hence
   identifying all the servers taken in situations where the group.  Further details of such an
   interface security
   requirements are out relaxed, so that deployment of scope for this document.

G.2.  Pairwise Protected the system will
   always be done safely.

Appendix G.  Optimized Request

   A

   An optimized request in pairwise mode is protected processed as a request in group mode
   (Section 8.1) and uses the OSCORE header compression defined in
   Section 7.1,
   with 5 for the following differences.

   o  The client MUST set to 1 group mode, with the sixth least significant bit following difference: the
   payload of the OSCORE flag bits in message SHALL encode the OSCORE option, i.e. ciphertext without the Pairwise Flag.

   o  The COSE_Encrypt0
   tag, concatenated with the value of the CounterSignature0 of the COSE
   object included computed as described in the Section 4.1.

   The optimized request is encrypted
      using a symmetric pairwise key K, that the client derives as compatible with all AEAD algorithms defined
   in Section 3.  In particular, [I-D.ietf-cose-rfc8152bis-algs], but would not be compatible with
   AEAD algorithms that do not have a well-defined tag.

Appendix H.  Example Values of Parameters for Countersignatures

   The table below provides examples of values for Counter Signature
   Parameters in the Sender/Recipient Common Context (see Section 2.1.3), for different
   values of Counter Signature Algorithm.

    +-------------------+---------------------------------------------+
    | Counter Signature | Example Values for Counter                  |
    | Algorithm         | Signature Parameters                        |
    +-------------------+---------------------------------------------+
    |  (-8)   // EdDSA  | [1], [1, 6]  // 1: OKP ; 1: OKP, 6: Ed25519 |
    |  (-7)   // ES256  | [2], [2, 1]  // 2: EC2 ; 2: EC2, 1: P-256   |
    |  (-35)  // ES384  | [2], [2, 2]  // 2: EC2 ; 2: EC2, 2: P-384   |
    |  (-36)  // ES512  | [2], [2, 3]  // 2: EC2 ; 2: EC2, 3: P-512   |
    |  (-37)  // PS256  | [], [3]      // empty  ; 3: RSA             |
    |  (-38)  // PS384  | [], [3]      // empty  ; 3: RSA             |
    |  (-39)  // PS512  | [], [3]      // empty  ; 3: RSA             |
    +-------------------+---------------------------------------------+

            Figure 4: Examples of Counter Signature Parameters

   The table below provides examples of values for Counter Signature Key is
   Parameters in the Sender Common Context (see Section 2.1.4), for different
   values of Counter Signature Algorithm.

          +-------------------+---------------------------------+
          | Counter Signature | Example Values for Counter      |
          | Algorithm         | Signature Key Parameters        |
          +-------------------+---------------------------------+
          | (-8)    // EdDSA  | [1, 6]   // 1: OKP , 6: Ed25519 |
          | (-7)    // ES256  | [2, 1]   // 2: EC2 , 1: P-256   |
          | (-35)   // ES384  | [2, 2]   // 2: EC2 , 2: P-384   |
          | (-36)   // ES512  | [2, 3]   // 2: EC2 , 3: P-512   |
          | (-37)   // PS256  | [3]      // 3: RSA              |
          | (-38)   // PS384  | [3]      // 3: RSA              |
          | (-39)   // PS512  | [3]      // 3: RSA              |
          +-------------------+---------------------------------+

          Figure 5: Examples of the client from its own Sender Context, i.e. the
      Recipient Counter Signature Key that the server stores in its own Recipient Context
      corresponding Parameters

Appendix I.  Document Updates

   RFC EDITOR: PLEASE REMOVE THIS SECTION.

I.1.  Version -08 to the client. -09

   o  The Counter Signature is not computed.  That is, unlike defined in
      Section 5, the payload of the OSCORE message terminates with the
      encoded ciphertext of the COSE object.

   Note that no changes  Pairwise keys are made discarded after group rekeying.

   o  Signature mode renamed to group mode.

   o  The parameters for countersignatures use the AEAD nonce and AAD.

   Upon receiving a request with the updated COSE
      registries.  Newly defined IANA registries have been removed.

   o  Pairwise Flag bit renamed as Group Flag bit, set to 1, 1 in group
      mode and set to 0 in pairwise mode.

   o  Dedicated section on updating the Security Context.

   o  By default, sender sequence numbers and replay windows are not
      reset upon group rekeying.

   o  An endpoint implementing only a silent server
   MUST process it as defined in Section 7.2, with does not support the following
   differences.
      pairwise mode.

   o  No countersignature to verify is included.  Separate section on general message reception.

   o  The COSE_Encrypt0 object included in  Pairwise mode moved to the request is decrypted and
      verified document body.

   o  Considerations on using the same symmetric pairwise key K, that the server
      derives mode in non-multicast
      settings.

   o  Optimized requests are moved as described above an appendix.

   o  Normative support for the client side signature and as defined in
      Section 3.

G.3.  Pairwise Protected Response

   When using the pairwise mode, the processing of a response occurs as
   described in Section 9.2 mode.

   o  Revised methods for an optimized response. synchronization with clients' sender sequence
      number.

   o  Appendix H.  Document Updates

   RFC EDITOR: PLEASE REMOVE THIS SECTION.

H.1. with example values of parameters for countersignatures.

   o  Clarifications and editorial improvements.

I.2.  Version -07 to -08

   o  Clarified relation between pairwise mode and group communication
      (Section 1).

   o  Improved definition of "silent server" (Section 1.1).

   o  Clarified when a Recipient Context is needed (Section 2).

   o  Signature checkers as entities supported by the Group Manager
      (Section 2.3).

   o  Clarified that the Group Manager is under exclusive control of Gid
      and Sender ID values in a group, with Sender ID values under each
      Gid value (Section 2.3).

   o  Mitigation policies in case of recycled 'kid' values
      (Section 2.4).

   o  More generic exhaustion (not necessarily wrap-around) of sender
      sequence numbers (Sections 2.5 and 10.11).

   o  Pairwise key considerations, as to group rekeying and Sender
      Sequence Numbers (Section 3).

   o  Added reference to static-static Diffie-Hellman shared secret
      (Section 3).

   o  Note for implementation about the external_aad for signing
      (Sectino 4.3.2).

   o  Retransmission by the application for group requests over
      multicast as Non-Confirmable (Section 7).

   o  A server MUST use its own Partial IV in a response, if protecting
      it with a different context than the one used for the request
      (Section 7.3).

   o  Security considerations: encryption of pairwise mode as
      alternative to group-level security (Section 10.1).

   o  Security considerations: added approach to reduce the chance of
      global collisions of Gid values from different Group Managers
      (Section 10.5).

   o  Security considerations: added implications for block-wise
      transfers when using the signature mode for requests over unicast
      (Section 10.7).

   o  Security considerations: (multiple) supported signature algorithms
      (Section 10.13).

   o  Security considerations: added privacy considerations on the
      approach for reducing global collisions of Gid values
      (Section 10.15).

   o  Updates to the methods for synchronizing with clients' sequence
      number (Appendix E).

   o  Simplified text on discovery services supporting the pairwise mode
      (Appendix G.1).

   o  Editorial improvements.

H.2.

I.3.  Version -06 to -07

   o  Updated abstract and introduction.

   o  Clarifications of what pertains a group rekeying.

   o  Derivation of pairwise keying material.

   o  Content re-organization for COSE Object and OSCORE header
      compression.

   o  Defined the Pairwise Flag bit for the OSCORE option.

   o  Supporting CoAP Observe for group requests and responses.

   o  Considerations on message protection across switching to new
      keying material.

   o  New optimized mode based on pairwise keying material.

   o  More considerations on replay protection and Security Contexts
      upon key renewal.

   o  Security considerations on Group OSCORE for unicast requests, also
      as affecting the usage of the Echo option.

   o  Clarification on different types of groups considered
      (application/security/CoAP).

   o  New pairwise mode, using pairwise keying material for both
      requests and responses.

H.3.

I.4.  Version -05 to -06

   o  Group IDs mandated to be unique under the same Group Manager.

   o  Clarifications on parameter update upon group rekeying.

   o  Updated external_aad structures.

   o  Dynamic derivation of Recipient Contexts made optional and
      application specific.

   o  Optional 4.00 response for failed signature verification on the
      server.

   o  Removed client handling of duplicated responses to multicast
      requests.

   o  Additional considerations on public key retrieval and group
      rekeying.

   o  Added Group Manager responsibility on validating public keys.

   o  Updates IANA registries.

   o  Reference to RFC 8613.

   o  Editorial improvements.

H.4.

I.5.  Version -04 to -05

   o  Added references to draft-dijk-core-groupcomm-bis.

   o  New parameter Counter Signature Key Parameters (Section 2).

   o  Clarification about Recipient Contexts (Section 2).

   o  Two different external_aad for encrypting and signing
      (Section 3.1).

   o  Updated response verification to handle Observe notifications
      (Section 6.4).

   o  Extended Security Considerations (Section 8).

   o  New "Counter Signature Key Parameters" IANA Registry
      (Section 9.2).

H.5.

I.6.  Version -03 to -04

   o  Added the new "Counter Signature Parameters" in the Common Context
      (see Section 2).

   o  Added recommendation on using "deterministic ECDSA" if ECDSA is
      used as counter signature algorithm (see Section 2).

   o  Clarified possible asynchronous retrieval of keying material from
      the Group Manager, in order to process incoming messages (see
      Section 2).

   o  Structured Section 3 into subsections.

   o  Added the new 'par_countersign' to the aad_array of the
      external_aad (see Section 3.1).

   o  Clarified non reliability of 'kid' as identity indicator for a
      group member (see Section 2.1).

   o  Described possible provisioning of new Sender ID in case of
      Partial IV wrap-around (see Section 2.2).

   o  The former signature bit in the Flag Byte of the OSCORE option
      value is reverted to reserved (see Section 4.1).

   o  Updated examples of compressed COSE object, now with the sixth
      less significant bit in the Flag Byte of the OSCORE option value
      set to 0 (see Section 4.3).

   o  Relaxed statements on sending error messages (see Section 6).

   o  Added explicit step on computing the counter signature for
      outgoing messages (see Setions 6.1 and 6.3).

   o  Handling of just created Recipient Contexts in case of
      unsuccessful message verification (see Sections 6.2 and 6.4).

   o  Handling of replied/repeated responses on the client (see
      Section 6.4).

   o  New IANA Registry "Counter Signature Parameters" (see
      Section 9.1).

H.6.

I.7.  Version -02 to -03

   o  Revised structure and phrasing for improved readability and better
      alignment with draft-ietf-core-object-security.

   o  Added discussion on wrap-Around of Partial IVs (see Section 2.2).

   o  Separate sections for the COSE Object (Section 3) and the OSCORE
      Header Compression (Section 4).

   o  The countersignature is now appended to the encrypted payload of
      the OSCORE message, rather than included in the OSCORE Option (see
      Section 4).

   o  Extended scope of Section 5, now titled " Message Binding,
      Sequence Numbers, Freshness and Replay Protection".

   o  Clarifications about Non-Confirmable messages in Section 5.1
      "Synchronization of Sender Sequence Numbers".

   o  Clarifications about error handling in Section 6 "Message
      Processing".

   o  Compacted list of responsibilities of the Group Manager in
      Section 7.

   o  Revised and extended security considerations in Section 8.

   o  Added IANA considerations for the OSCORE Flag Bits Registry in
      Section 9.

   o  Revised Appendix D, now giving a short high-level description of a
      new endpoint set-up.

H.7.

I.8.  Version -01 to -02

   o  Terminology has been made more aligned with RFC7252 and draft-
      ietf-core-object-security: i) "client" and "server" replace the
      old "multicaster" and "listener", respectively; ii) "silent
      server" replaces the old "pure listener".

   o  Section 2 has been updated to have the Group Identifier stored in
      the 'ID Context' parameter defined in draft-ietf-core-object-
      security.

   o  Section 3 has been updated with the new format of the Additional
      Authenticated Data.

   o  Major rewriting of Section 4 to better highlight the differences
      with the message processing in draft-ietf-core-object-security.

   o  Added Sections 7.2 and 7.3 discussing security considerations
      about uniqueness of (key, nonce) and collision of group
      identifiers, respectively.

   o  Minor updates to Appendix A.1 about assumptions on multicast
      communication topology and group size.

   o  Updated Appendix C on format of group identifiers, with practical
      implications of possible collisions of group identifiers.

   o  Updated Appendix D.2, adding a pointer to draft-palombini-ace-key-
      groupcomm about retrieval of nodes' public keys through the Group
      Manager.

   o  Minor updates to Appendix E.3 about Challenge-Response
      synchronization of sequence numbers based on the Echo option from
      draft-ietf-core-echo-request-tag.

H.8.

I.9.  Version -00 to -01

   o  Section 1.1 has been updated with the definition of group as
      "security group".

   o  Section 2 has been updated with:

      *  Clarifications on etablishment/derivation of Security Contexts.

      *  A table summarizing the the additional context elements
         compared to OSCORE.

   o  Section 3 has been updated with:

      *  Examples of request and response messages.

      *  Use of CounterSignature0 rather than CounterSignature.

      *  Additional Authenticated Data including also the signature
         algorithm, while not including the Group Identifier any longer.

   o  Added Section 6, listing the responsibilities of the Group
      Manager.

   o  Added Appendix A (former section), including assumptions and
      security objectives.

   o  Appendix B has been updated with more details on the use cases.

   o  Added Appendix C, providing an example of Group Identifier format.

   o  Appendix D has been updated to be aligned with draft-palombini-
      ace-key-groupcomm.

Acknowledgments

   The authors sincerely thank Christian Amsuess, Stefan Beck, Rolf
   Blom, Carsten Bormann, Esko Dijk, Klaus Hartke, Rikard Hoeglund,
   Richard Kelsey, John Mattsson, Dave Robin, Jim Schaad, Ludwig Seitz,
   Peter van der Stok and Erik Thormarker for their feedback and
   comments.

   The work on this document has been partly supported by VINNOVA and
   the Celtic-Next project CRITISEC; the SSF project SEC4Factory under
   the grant RIT17-0032; and by the EIT-Digital High Impact Initiative
   ACTIVE.

Authors' Addresses

   Marco Tiloca
   RISE AB
   Isafjordsgatan 22
   Kista  SE-16440 Stockholm
   Sweden

   Email: marco.tiloca@ri.se

   Goeran Selander
   Ericsson AB
   Torshamnsgatan 23
   Kista  SE-16440 Stockholm
   Sweden

   Email: goran.selander@ericsson.com

   Francesca Palombini
   Ericsson AB
   Torshamnsgatan 23
   Kista  SE-16440 Stockholm
   Sweden

   Email: francesca.palombini@ericsson.com
   Jiye Park
   Universitaet Duisburg-Essen
   Schuetzenbahn 70
   Essen  45127
   Germany

   Email: ji-ye.park@uni-due.de