ACE Working Group                                              M. Tiloca
Internet-Draft                                                   RISE AB
Intended status: Standards Track                                 J. Park
Expires: May 7, July 18, 2020                       Universitaet Duisburg-Essen
                                                            F. Palombini
                                                             Ericsson AB
                                                       November 04, 2019
                                                        January 15, 2020

                Key Management for OSCORE Groups in ACE
                draft-ietf-ace-key-groupcomm-oscore-03
                draft-ietf-ace-key-groupcomm-oscore-04

Abstract

   This document describes a method specification defines an application profile of the ACE
   framework for Authentication and Authorization, to request and
   provision keying material in group communication scenarios where the group
   communication is that are
   based on CoAP and secured with Group Object Security for Constrained
   RESTful Environments (OSCORE).  The proposed method  This application profile delegates
   the authentication and authorization of new client nodes Clients that join an OSCORE
   group through a Resource Server acting as Group Manager server.  This
   approach builds on the ACE framework for Authentication and
   Authorization, and that
   group.  This application profile leverages protocol-specific
   transport profiles of ACE to achieve communication security, server
   authentication and proof-of-possession for a key owned by the Client
   and server
   authentication. bound to an OAuth 2.0 access token.

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 May 7, July 18, 2020.

Copyright Notice

   Copyright (c) 2019 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4   3
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Overview of the Joining Process . . . . . . . . . . . . .   7   5
     2.2.  Overview of the Group Rekeying Process  . . . . . . . . .   8   6
   3.  Joining Node to Authorization Server  . . . . . . . . . . . .   8   6
     3.1.  Authorization Request . . . . . . . . . . . . . . . . . .   9   6
     3.2.  Authorization Response  . . . . . . . . . . . . . . . . .   9   7
   4.  Joining Node to a Group Manager . . . . . . . . . . . . . . . .  10 . . . . . . .   7
     4.1.  Token Post  . . . . . . . . . . . . . . . . . . . . . . .  10   7
     4.2.  Sending the Joining Request . . . . . . . . . . . . . . .   8
       4.2.1.  Value of the N_S Challenge  . . . . . . . . . . . . .  12   9
     4.3.  Processing the Joining Request  . . . . . . . . . . . . .  10
     4.4.  Joining Response  . . . . . . . . . . . . . . . . . . . .  13  11
   5.  Public Keys of Joining Nodes  . . . . . . . . . . . . . . . .  17  14
   6.  Retrieval of Updated Keying Material  . . . . . . . . . . . .  19  15
     6.1.  Retrieval of Group Keying Material  . . . . . . . . . . .  16
     6.2.  Retrieval of Group Keying Material and Sender ID  . . . .  16
   7.  Retrieval of New Keying Material  . . . . . . . . . . . . . .  19  16
   8.  Retrieval of Public Keys of Group Members . . . . . . . . . .  20  17
   9.  Retrieval of Group Policies . . . . . . . . . . . . . . . . .  20  18
   10. Retrieval of Keying Material Version  . . . . . . . . . . . .  21  18
   11. Request to Leave the Group  . . . . . . . . . . . . . . . . .  21  18
   12. Removal of a Group Member . . . . . . . . . . . . . . . . . .  21  18
   13. Group Rekeying Process  . . . . . . . . . . . . . . . . . . .  22  19
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  23  20
   15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24  21
     15.1.  ACE Groupcomm Key Registry . . . . . . . . . . . . . . .  24  21
     15.2.  OSCORE Security Context Parameters Registry  . . . . . .  24  22
     15.3.  ACE Groupcomm Profile Registry . . . . . . . . . . . . .  26  23
     15.4.  Sequence Number Synchronization Method Registry  . . . .  26  23
     15.5.  ACE Groupcomm Parameters Registry  . . . . . . . . . . .  27  24
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27  24
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  27  24
     16.2.  Informative References . . . . . . . . . . . . . . . . .  28  26
   Appendix A.  Profile Requirements . . . . . . . . . . . . . . . .  29  27
   Appendix B.  Document Updates . . . . . . . . . . . . . . . . . .  31  29
     B.1.  Version -03 to -04  . . . . . . . . . . . . . . . . . . .  29
     B.2.  Version -02 to -03  . . . . . . . . . . . . . . . . . . .  31
     B.2.  29
     B.3.  Version -01 to -02  . . . . . . . . . . . . . . . . . . .  32
     B.3.  30
     B.4.  Version -00 to -01  . . . . . . . . . . . . . . . . . . .  32  31
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  33  31
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33  31

1.  Introduction

   Object Security for Constrained RESTful Environments (OSCORE)
   [RFC8613] is a method for application-layer protection of the
   Constrained Application Protocol (CoAP) [RFC7252], using CBOR Object
   Signing and Encryption (COSE) [RFC8152] and enabling end-to-end
   security of CoAP payload and options.

   As described in [I-D.ietf-core-oscore-groupcomm], Group OSCORE is
   used to protect CoAP group communication over IP multicast
   [RFC7390][I-D.dijk-core-groupcomm-bis].
   [I-D.dijk-core-groupcomm-bis].  This relies on a Group Manager, which
   is responsible for managing an OSCORE group, where members exchange
   CoAP messages secured with Group OSCORE.  The Group Manager can be
   responsible for multiple groups, coordinates the joining process of
   new group members, and is entrusted with the distribution and renewal
   of group keying material.

   This specification is an application profile of
   [I-D.ietf-ace-key-groupcomm], which itself builds on the ACE
   framework for Authentication and Authorization [I-D.ietf-ace-oauth-authz] and defines a method to:

   o  Authorize a node to join an OSCORE group, and provide it with the
      group keying material to communicate with other group members.

   o  Provide updated keying material to group members upon request.

   o  Renew the group keying material and distribute it to the OSCORE
      group (rekeying) upon changes in the group membership.

   A client node joins an OSCORE group through a resource server acting
   as Group Manager for that group.  The joining process relies on an
   Access Token, which is bound to a proof-of-possession key and
   authorizes the client to access a specific group-membership resource
   at the Group Manager.

   Message exchanges among the participants as well as message formats
   [I-D.ietf-ace-oauth-authz].  Message exchanges among the participants
   as well as message formats and processing follow what specified in
   [I-D.ietf-ace-key-groupcomm] for provisioning and renewing keying
   material in group communication
   scenarios.

   In order scenarios, where Group OSCORE is used
   to achieve protect CoAP group communication security, proof-of-possession and
   server authentication, the client and the Group Manager leverage
   protocol-specific transport profiles of ACE.  These include also
   possible forthcoming transport profiles that comply with the
   requirements in Appendix C of [I-D.ietf-ace-oauth-authz]. over IP multicast.

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 with:

   o  The terms and concepts described in the ACE framework for
      authentication and authorization [I-D.ietf-ace-oauth-authz].  The
      terminology for entities in the considered architecture is defined
      in OAuth 2.0 [RFC6749].  In particular, this includes Client (C),
      Resource Server (RS), and Authorization Server (AS).

   Readers are expected to be familiar with the

   o  The terms and concepts related to the CoAP protocol described in
   [RFC7252][RFC7390][I-D.dijk-core-groupcomm-bis].  Note that, unless
      [RFC7252][I-D.dijk-core-groupcomm-bis].  Unless otherwise
      indicated, the term "endpoint" is used here following its OAuth
      definition, aimed at denoting resources such as /token and
      /introspect at the AS and /authz-info at the RS.  This document
      does not use the CoAP definition of "endpoint", which is "An
      entity participating in the CoAP protocol".

   Readers are expected

   o  The terms and concept related to be familiar with the message formats and
      processing specified in [I-D.ietf-ace-key-groupcomm], for
      provisioning and renewing keying material in group communication
      scenarios.

   o  The terms and concepts for protection and processing of CoAP
      messages through OSCORE [RFC8613] and through Group OSCORE
      [I-D.ietf-core-oscore-groupcomm] in group communication scenarios.
      These include the concept of Group Manager, as the entity
      responsible for a set of groups where communications are secured
      with Group OSCORE.  In this specification, the Group Manager acts
      as Resource Server.

   This

   Additionally, this document refers also to makes use of the following terminology.

   o  Joining node: a network node intending to join an OSCORE group,
      where communication is based on CoAP
      [RFC7390][I-D.dijk-core-groupcomm-bis] and secured with  Group
      OSCORE name is used as described a synonym for group identifier in [I-D.ietf-core-oscore-groupcomm].
      [I-D.ietf-ace-key-groupcomm].

   o  Joining process:  GROUPNAME and NODENAME are used to indicate the process through which a joining node becomes
      a member of an OSCORE group.  The joining process is enforced and
      assisted by the Group Manager responsible for that group.

   o  Group name: stable and invariant identifier of an OSCORE group.
      The group name MUST be unique under the same Group Manager, and
      MUST include only characters that are valid for a url-path
      segment, namely unreserved and pct-encoded characters [RFC3986].

   o  Group-membership resource: a resource hosted by the Group Manager,
      associated to an OSCORE group under that Group Manager.  A group-
      membership resource is identifiable with the name of the
      respective OSCORE group.  A joining node accesses a group-
      membership resource to start the joining process and become a
      member of that group.  The url-path of a group-membership resource
      is fixed, and ends with the segments /group-oscore/NAME , where
      "NAME" is the name of the associated OSCORE group.  This replaces
      the url-path /ace-group/gid at the KDC used in
      [I-D.ietf-ace-key-groupcomm], with "gid" indicating the group
      identifier.  The url-path /group-oscore/NAME is a default name:
      implementations are not required to use this name, and can define
      their own instead.

   o  Group-membership endpoint: an endpoint at the Group Manager
      associated to a group-membership resource.

   o  Requester: variant parts of
      the resource endpoint, i.e. "gid" and "node" URI path in
      [I-D.ietf-ace-key-groupcomm].

   o  Requester: member of an OSCORE group that sends request messages
      to other members of the group.

   o  Responder: member of an OSCORE group that receives request
      messages from other members of the group.  A responder may reply
      back, by sending a response message to the requester which has
      sent the request message.

   o  Monitor: member of an OSCORE group that is configured as responder
      and never replies back to requesters after receiving request
      messages.  This corresponds to the term "silent server" used in
      [I-D.ietf-core-oscore-groupcomm].

   o  Group rekeying process: the process through which the Group
      Manager renews the security parameters and group keying material,
      and (re-)distributes them to the OSCORE group members.

2.  Protocol Overview

   Group communication for CoAP over IP multicast has been enabled in
   [RFC7390][I-D.dijk-core-groupcomm-bis]
   [I-D.dijk-core-groupcomm-bis] and can be secured with Group Object
   Security for Constrained RESTful Environments (OSCORE) [RFC8613] as
   described in [I-D.ietf-core-oscore-groupcomm].  A network node joins
   an OSCORE group by interacting with the responsible Group Manager.
   Once registered in the group, the new node can securely exchange
   messages with other group members.

   This specification describes how to use the ACE framework for
   authentication [I-D.ietf-ace-key-groupcomm]
   and authorization [I-D.ietf-ace-oauth-authz] to:

   o  Enable to perform a number of authentication,
   authorization and key distribution actions, as defined in Section 2.
   of [I-D.ietf-ace-key-groupcomm], for an OSCORE group.

   With reference to [I-D.ietf-ace-key-groupcomm]:

   o  The node wishing to join an joining the OSCORE group through group, i.e. the joining
      node, is the Client.

   o  The Group Manager
      and receive is the security parameters and keying material Key Distribution Center (KDC), acting as
      a Resource Server.

   o  The Authorization Server associated to
      communicate with the other members of Group Manager is the group.

   o  Enable members of OSCORE groups to retrieve updated group keying
      material and public key of other group members, from the Group
      Manager.

   o  Enable the Group Manager to renew the security parameters and
      group keying material, and to (re-)distribute them to the members
      of the OSCORE group (rekeying).

   With reference to the ACE framework and the terminology defined in
   OAuth 2.0 [RFC6749]:

   o  The Group Manager acts as Resource Server (RS), and hosts one
      group-membership resource for each OSCORE group it manages.  Each
      group-membership resource is exported by a distinct group-
      membership endpoint.  During the joining process, the Group
      Manager provides joining nodes with the parameters and keying
      material for taking part to secure communications in the OSCORE
      group.  The Group Manager also maintains the group keying material
      and performs the group rekeying process to distribute updated
      keying material to the group members.

   o  The joining node acts as Client (C), and requests to join an
      OSCORE group by accessing the related group-membership endpoint at
      the Group Manager.

   o  The Authorization Server (AS) authorizes joining nodes to join
      OSCORE groups under their respective Group Manager.  Multiple
      Group Managers can be associated to the same
      AS.  The AS MAY
      release Access Tokens for other purposes than joining OSCORE
      groups under registered Group Managers.  For example, the AS may
      also release Access Tokens for accessing resources hosted by
      members of OSCORE groups.

   All communications between the involved entities rely on the CoAP
   protocol and MUST be secured.

   In particular, communications between the joining node Client and the Group
   Manager leverage protocol-specific transport profiles of ACE to
   achieve communication security, proof-of-possession and server
   authentication.  To this end, the AS MAY signal the specific
   transport profile to use, consistently with requirements and
   assumptions defined in the ACE framework [I-D.ietf-ace-oauth-authz].  Note that it is expected that in the commonly
   referred base-case of this specification, the transport profile to
   use is pre-configured and well-known to nodes participating in
   constrained applications.

   With reference to the AS, communications between

2.1.  Overview of the joining Joining Process

   A node and
   the AS (/token endpoint) as well as between performs the Group Manager and the
   AS (/introspect endpoint) can be secured by different means, for
   instance using DTLS [RFC6347] or OSCORE [RFC8613].  Further details
   on how the AS secures communications (with the joining node and the
   Group Manager) depend on the specifically used transport profile of
   ACE, and are out of the scope of this specification.

2.1.  Overview of the Joining Process

   A node performs the following steps described in order to join an OSCORE group.
   The format and processing of messages exchanged among the
   participants follow what is defined in [I-D.ietf-ace-key-groupcomm],
   and are further specified in Section 3 and Section 4 4.2 of this
   document.  The Group Manager acts as the Key Distribution Center
   (KDC) defined in [I-D.ietf-ace-key-groupcomm].

   1.  The joining node requests an Access Token from the AS,
   [I-D.ietf-ace-key-groupcomm] in order to access a group-membership resource on the Group Manager and
       hence join the associated OSCORE group (see Section 3).  The
       joining node will start or continue using a secure communication
       association with the Group Manager, according to the response
       from the AS.

   2.  The joining node transfers authentication and authorization
       information to the Group Manager, by posting the obtained Access
       Token to the /authz-info endpoint at the Group Manager (see
       Section 4).  After that, a joining node MUST have a secure
       communication association established with the Group Manager,
       before starting to join an OSCORE group under that Group Manager
       (see Section 4).  Possible ways to provide a secure communication
       association are DTLS [RFC6347] and OSCORE [RFC8613].

   3.  The joining node starts the joining process to become a member of
       the OSCORE group, by accessing the related group-membership
       resource hosted by the Group Manager (see Section 4).

   4.  At the end of the joining process, the joining node has received
       from the Group Manager the parameters and keying material to
       securely communicate with the other members of the OSCORE group.

   5.  The joining node and the Group Manager maintain the secure
       association, to support possible future communications.  These
       especially include key management operations, such as retrieval
       of updated keying material from the Group Manager or
       participation to a group rekeying process (see Section 2.2).

   All further communications between the joining node  The
   format and processing of messages exchanged among the Group
   Manager MUST be secured, for instance with the same secure
   association mentioned participants
   are further specified in step 2. Section 3 and Section 4 of this document.

2.2.  Overview of the Group Rekeying Process

   If the application requires backward and forward security, the Group
   Manager MUST generate new security parameters and group keying
   material, and distribute them to the group (rekeying) upon membership
   changes.

   That is, the group is rekeyed when a node joins the group as a new
   member, or after a current member leaves the group.  By doing so, a
   joining node cannot access communications in the group prior its
   joining, while a leaving node cannot access communications in the
   group after its leaving.

   Parameters and group keying material include a new Group Identifier
   (Gid) for the group and a new Master Secret for the OSCORE Common
   Security Context of that group (see Section 2 of
   [I-D.ietf-core-oscore-groupcomm]).  Once completed a group rekeying,
   the GM MUST increment the version number of the group keying
   material.

   The Group Manager MUST support the Group Rekeying Process described
   in Section 13.  Future application profiles may define alternative
   message formats and distribution schemes to perform group rekeying.

3.  Joining Node to Authorization Server

   This section describes how the joining node interacts with the AS in
   order to be authorized to join an OSCORE group under a given Group
   Manager.  In particular, it considers a joining node that intends to
   contact that Group Manager for the first time.

   The message exchange between the joining node and the AS consists of
   the messages Authorization Request and Authorization Response defined
   in Section 3 of [I-D.ietf-ace-key-groupcomm].

   In case the specific AS associated to the Group Manager  Note that what is unknown to
   the joining node, the latter can rely on mechanisms like the
   Unauthorized Resource Request message described
   defined in Section 5.1.1 of
   [I-D.ietf-ace-oauth-authz] to discover the correct AS [I-D.ietf-ace-key-groupcomm] applies, and only additions
   or modifications to contact. that specification are defined here.

3.1.  Authorization Request

   The joining node contacts the AS, in order to request an Access Token
   for accessing the group-membership resource hosted by the Group
   Manager and associated to the OSCORE group.  The Access Token request
   sent to the /token endpoint follows the format of the Authorization Request message defined in Section 3.1 of
   [I-D.ietf-ace-key-groupcomm].  In particular:
   [I-D.ietf-ace-key-groupcomm], with the following additions:

   o  The 'scope' parameter MUST be present and MUST include:

      *  in the first element, the present.

   o  The group name of the OSCORE group to join under the Group Manager, Manager
      is encoded as a CBOR text string.

      *  in the second element, the

   o  The role (encoded as a text string) or
         CBOR array of roles that the joining node intends to have in the OSCORE group it intends to join. join is encoded as a text string.
      Accepted values of roles are: "requester", "responder", and
      "monitor".  Possible combinations are: ["requester" ,
      "responder"]; ["requester" , "monitor"].

   o  The 'audience' parameter MUST be present and is set to the
      identifier of the Group Manager. present.

3.2.  Authorization Response

   The AS is responsible for authorizing the joining node to join
   specific OSCORE groups, according to join policies enforced on behalf
   of the respective Group Manager.

   In case of successful authorization, the AS releases an Access Token
   bound to a proof-of-possession key associated to the joining node.

   Then, the AS provides the joining node with the Access Token as part
   of an Access Token response, which follows the format of the Authorization Response message defined in Section 3.2 of
   [I-D.ietf-ace-key-groupcomm].
   [I-D.ietf-ace-key-groupcomm], with the following additions:

   o  The AS MUST include the 'exp' parameter in the response to the
   joining node. the 'exp' parameter.  Other means for the AS
      to specify the lifetime of Access Tokens are out of the scope of
      this specification.

   o  The AS must MUST include the 'scope' parameter in the response to the
   joining node, parameter, when the value included
      in the Access Token differs from the one specified by the joining
      node in the request.  In such a case, the second element of
      'scope' MUST be present and includes the role or CBOR array of
      roles that the joining node is actually authorized to take in the
      OSCORE group, encoded as specified in Section 3.1 of this
      document.

   The AS MAY also include the 'profile' parameter in the response to
   the joining node, in order to indicate the specific transport profile
   of ACE to use for securing communications between the joining node
   and the Group Manager (see Section 5.6.4.3 of
   [I-D.ietf-ace-oauth-authz]).

   In particular, if symmetric keys are used, the AS generates a proof-
   of-possession key, binds it to the Access Token, and provides it to
   the joining node in the 'cnf' parameter of the Access Token response.
   Instead, if asymmetric keys are used, the joining node provides its
   own public key to the AS in the 'req_cnf' parameter of the Access
   Token request.  Then, the AS uses it as proof-of-possession key bound
   to the Access Token, and provides the joining node with the Group
   Manager's public key in the 'rs_cnf' parameter of the Access Token
   response.

4.  Joining Node to a Group Manager

   The following subsections describe the interactions between the
   joining node and the Group Manager, i.e. the sending of the Access
   Token and the Request-Response exchange to join the OSCORE group.

4.1.  Token Post

   The joining node posts the Access Token to the /authz-info endpoint
   at the Group Manager, according to the Token post defined in
   Section 3.3 of [I-D.ietf-ace-key-groupcomm].

   At this point in time, the joining node might not have all the
   necessary information concerning the public keys in the OSCORE group,
   as well as concerning the algorithm and related parameters for
   computing countersignatures in the OSCORE group.  In such a case, the
   joining node MAY use the 'sign_info' and 'pub_key_enc' parameters
   defined in Section 3.3 of [I-D.ietf-ace-key-groupcomm] to ask for
   such information.

   Alternatively, subsections describe the interactions between the
   joining node may retrieve this information by
   other means, e.g. by using and the approach described in
   [I-D.tiloca-core-oscore-discovery].

   If Group Manager, i.e. the sending of the Access
   Token is valid, the Group Manager responds to and the POST
   request with a 2.01 (Created) response, according Request-Response exchange to what is
   specified in join the signalled transport profile of ACE. OSCORE group.
   The Group
   Manager MUST use message exchange between the Content-Format "application/ace+cbor" defined in
   Section 8.14 of [I-D.ietf-ace-oauth-authz].

   The payload of joining node and the 2.01 (Created) response is a CBOR map, which MUST
   include KDC consists of
   the 'rsnonce' parameter messages defined in Section 3.3.3 of

   [I-D.ietf-ace-key-groupcomm], 3.3 and MAY include the 'sign_info'
   parameter as well as the 'pub_key_enc' parameter, 4.2 of
   [I-D.ietf-ace-key-groupcomm].  Note that what is defined in its
   Sections 3.3.1
   [I-D.ietf-ace-key-groupcomm] applies, and 3.3.2, respectively.  Note only additions or
   modifications to that this deviates from
   the default payload format for this response message as specification are defined here.

4.1.  Token Post

   The Token post exchange is defined in
   the ACE framework (see Section 5.8.1 3.3 of [I-D.ietf-ace-oauth-authz]).
   [I-D.ietf-ace-key-groupcomm].

   Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the
   following applies.

   o  The 'rsnonce' parameter includes contains a dedicated 8-byte nonce N_S
      generated by the Group Manager.  The joining node may use this
      nonce in order to prove the possession of its own private key,
      upon joining the group (see Section 4.2).

   o  If 'sign_info' is present in the response:

   o  'sign_alg', i.e. the first element of the 'sign_info' parameter,

      *  'sign_alg' takes value from Tables 5 and 6 of [RFC8152].

   o  'sign_parameters', i.e. the second element of the 'sign_info'
      parameter,

      *  'sign_parameters' takes values from the "Counter Signature
         Parameters" Registry (see Section 9.1 of
         [I-D.ietf-core-oscore-groupcomm]).  Its structure depends on
         the value of 'sign_alg'.  If no parameters of the counter
         signature algorithm are specified, 'sign_parameters' MUST be
         encoding the CBOR simple value Null.

   o  'sign_key_parameters', i.e. the third element of the 'sign_info'
      parameter,

      *  'sign_key_parameters' takes values from the "Counter Signature
         Key Parameters" Registry (see Section 9.2 of
         [I-D.ietf-core-oscore-groupcomm]).  Its structure depends on
         the value of 'sign_alg'.  If no parameters of the key used with
         the counter signature algorithm are specified,
         'sign_key_parameters' MUST be encoding the CBOR simple value
         Null.

   o

      *  'pub_key_enc' takes value 1 ("COSE_Key") from the 'Confirmation
         Key' column of the "CWT Confirmation Method" Registry defined
         in [I-D.ietf-ace-cwt-proof-of-possession], so indicating that
         public keys in the OSCORE group are encoded as COSE Keys
         [RFC8152].  Future specifications may define additional values
         for this parameter.

   The CBOR map specified

      Note that, other than through the above parameters as payload defined in
      Section 3.3 of [I-D.ietf-ace-key-groupcomm], the 2.01 (Created) response may
   include further parameters, joining node MAY
      have previously retrieved this information by other means, e.g. according to by
      using the signalled approach described in
      [I-D.tiloca-core-oscore-discovery].

   Additionally, if allowed by the used transport profile of ACE.

   Finally, ACE, the
   joining node establishes a secure channel with the Group
   Manager, according to what is specified in may instead provide the Access Token response
   and to the signalled transport profile Group
   Manager by other means, e.g. during a secure session establishment
   (see Section 3.3.1 of ACE. [I-D.ietf-ace-dtls-authorize]).

4.2.  Sending the Joining Request

   Once a secure communication channel with the Group Manager has been
   established, the

   The joining node requests to join the OSCORE group, by sending a
   Joining Request message to the related group-membership resource at
   the Group Manager, as per Section 4.2 of
   [I-D.ietf-ace-key-groupcomm].

   In particular, the joining node sends a CoAP POST request

   Additionally to what defined in [I-D.ietf-ace-key-groupcomm], the
   endpoint /group-oscore/NAME at the Group Manager, where NAME
   following applies.

   o  The string "group-oscore" is the
   name used instead of "ace-group" (see
      Section 4.1 of [I-D.ietf-ace-key-groupcomm]) as the OSCORE group top level path
      to join.  This Joining Request the group-membership resource.  The url-path /group-oscore/ is formatted
   as defined in Section 4.1.2.1
      a default name of [I-D.ietf-ace-key-groupcomm].
   Specifically: this specifications: implementations are not
      required to use this name, and can define their own instead.

   o  The 'scope' parameter MUST be present.

   o  The 'get_pub_keys' parameter is present only if the joining node
      wants to retrieve the public keys of the group members from the
      Group Manager during the joining process (see Section 5).
      Otherwise, this parameter MUST NOT be present.

   o  The 'client_cred' parameter, if present, includes the public key
      of the joining node.  In case the joining node knows the encoding
      of public keys in the OSCORE group, as well as the
      countersignature algorithm and possible associated parameters used
      in the OSCORE group, the included public key MUST be compatible
      with those criteria.  That is, the public key MUST be encoded
      according to the encoding of public keys in the OSCORE group, and
      MUST be compatible with the countersignature algorithm and
      possible associated parameters used in the OSCORE group.  This
      parameter MAY be omitted if: i) the joining node is asking to
      access the group exclusively as monitor; or ii) the Group Manager
      already acquired this information, for instance during a past
      joining process.  In any other case, this parameter MUST be
      present.

   Furthermore, if the 'client_cred' parameter is present, the CBOR map
   specified as payload of the Joining Request MUST also include the
   following parameters.

   o  'cnonce', as defined in Section 5.1.2 of
      [I-D.ietf-ace-oauth-authz], and including

   o  'cnonce' contains a dedicated 8-byte nonce N_C generated by the Client.
      joining node.

   o  The 'client_cred_verify' parameter, including a signature encoded
      as a CBOR byte string, computed by the joining node to prove
      possession of its own private key.  The signature is computed over
      N_S concatenated with N_C, where N_S is the nonce received in the
      'rsnonce' 'client_cred_verify' parameter of the 2.01 (Created) response to the Token
      POST (see Section 4.1), while N_C is the nonce generated
      computed by the
      Client and specified in the 'cnonce' parameter above.  The joining node computes the signature by using the same private key and
      countersignature algorithm it intends to use for signing messages
      in the OSCORE group.

4.3.  Joining Response  Moreover, N_S is as defined in
      Section 4.2.1.

4.2.1.  Value of the N_S Challenge

   The N_S challenge takes one of the following values.

   1.  If the joining node has posted the Access Token to the /authz-
       info endpoint of the Group Manager processes as in Section 4.1, N_S takes
       the Joining Request same value of the 'rsnonce' parameter in the 2.01 (Created)
       response to the Token POST.

   2.  If the Token posting has relied on the DTLS profile of ACE
       [I-D.ietf-ace-dtls-authorize] and the joining node included the
       Access Token as content of the "psk_identity" field of the
       ClientKeyExchange message [RFC6347], N_S is an exporter value
       computed as defined in Section 4.1.2.1 7.5 of [I-D.ietf-ace-key-groupcomm].  Also, [RFC8446].  Specifically,
       N_S is exported from the DTLS session between the joining node
       and the Group
   Manager MUST return a 4.00 (Bad Request) response Manager, using an empty 'context_value', 32 bytes
       as 'key_length', and the exporter label "EXPORTER-ACE-Sign-
       Challenge" defined in case Section 7 of
       [I-D.ietf-ace-mqtt-tls-profile].

   3.  If the Joining
   Request includes joining node is in fact re-joining the 'client_cred' parameter but does not include
   both group, without
       posting again the 'cnonce' same and 'client_cred_verify' parameters. still valid Access Token:

       *  If the request processing yields a positive outcome, joining node and the Group Manager performs communicates using
          DTLS, N_S is an exporter value, computed as described in point
          (2) above.

       *  If the joining node and the Group Manager communicates using
          OSCORE [RFC8613], the N_S is the further following checks.

   o output PRK of a HKDF-Extract
          step [RFC5869], i.e. PRK = HMAC-Hash(salt, IKM).  In case
          particular, 'salt' takes (x1 | x2), where x1 is the Joining Request includes ID Context
          of the 'client_cred' parameter, OSCORE Security Context between the joining node and
          the Group Manager checks that Manager, x2 is the public key Sender ID of the joining node
      has an accepted format.  That is, the public key has to be encoded
      as expected in
          that Context, and | denotes byte string concatenation.  Also,
          'IKM' is the OSCORE group, Master Secret of the OSCORE Security
          Context between the joining node and has to the Group Manager.  The
          HKDF MUST be compatible with one of the
      counter signature algorithm and possible associated parameters
      used HMAC-based HKDF [RFC5869] algorithms
          defined for COSE [RFC8152].  HKDF SHA-256 is mandatory to
          implement.

   It is up to applications to define how N_S is computed in further
   alternative settings.

4.3.  Processing the OSCORE group. Joining Request

   The joining process fails if Group Manager processes the public
      key Joining Request as defined in
   Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm].  Additionally, the joining node does not have an accepted format.
   following applies.

   o  In case the Joining Request does not include the 'client_cred'
      parameter, the Group Manager checks whether it is storing a public
      key for the joining node, which is compatible with the encoding,
      counter signature algorithm and possible associated parameters
      used in the OSCORE group.  The joining process fails if the Group Manager either:
      i) does not store a public key with an accepted format for the
      joining node; or ii) stores multiple public keys with an accepted
      format for the joining node.

   o  In case the Joining Request includes the 'client_cred_verify'
      parameter, the Group Manager verifies  To compute the signature contained in 'client_cred_verify', the parameter.  To this end, it GM
      considers: i) as signed value, N_S concatenated with N_C, where
      N_S is the nonce previously provided determined as described in the 'rsnonce' parameter of the 2.01 (Created) response to the
      Token POST (see Section 4.1), 4.2.1, while N_C is the
      nonce provided in the 'cnonce' parameter of the Joining Request;
      ii) the countersignature algorithm used in the OSCORE group, and
      possible correponding parameters; and iii) the public key of the
      joining node, either retrieved from the 'client_cred' parameter,
      or already stored as acquired from previous interactions with the
      joining node.  The

   o  A 4.00 Bad Request response from the Group Manager to the joining process fails if
      node MUST have content format application/ace-group+cbor.  The
      response payload is a CBOR map which MUST contain the 'sign_info'
      as well as the 'pub_key_enc' parameters.

   o  The Group Manager MUST return a 4.00 (Bad Request) response in
      case the Group Manager Joining Request includes the 'client_cred' parameter but
      does not successfully verify the signature.

   If the joining process has failed, include both the 'cnonce' and 'client_cred_verify'
      parameters.

   o  The Group Manager MUST reply to
   the joining node with return a 4.00 (Bad Request) response.  The payload of
   this response is a CBOR map, which includes in
      case it cannot retrieve a 'sign_info' public key with an accepted format for
      the joining node, either from the 'client_cred' parameter
   and a 'pub_key_enc' parameter, formatted or as in the Token POST
   response in Section 4.1.

   Upon
      already stored.

   o  When receiving this a 4.00 Bad Request response, the joining node
      SHOULD send a new Joining Request to the Group Manager, which contains:

   o
      containing:

      *  The 'client_cred' parameter, including a public key compatible
         with the encoding, countersignature algorithm and possible
         associated parameters indicated by the Group Manager.

   o

      *  The 'client_cred_verify' parameter, including a signature
         computed as described in Section 4.2, by using the public key
         indicated in the current 'client_cred' parameter, with the
         countersignature algorithm and possible associated parameters
         indicated by the Group Manager.

   Otherwise, in case

4.4.  Joining Response

   If the processing of success, the Joining Request described in Section 4.3 is
   successful, the Group Manager updates the group membership by
   registering the joining node NODENAME as a new member of the OSCORE group.
   group GROUPNAME, as described in Section 4.1.2.1 of
   [I-D.ietf-ace-key-groupcomm].

   If the joining node is not exclusively configured as monitor, the
   Group Manager performs also the following actions.

   o  The Group Manager selects an available OSCORE Sender ID in the
      OSCORE group, and exclusively assigns it to the joining node.

   o  If the 'client_cred' parameter was present in the request, the
      Group Manager adds the specified public key of the joining node to
      the list of public keys of the current group members.

   o  If the 'client_cred' parameter was not present in the request, the
      Group Manager retrieves the already stored public key of the
      joining node, as acquired from previous interactions (see also
      Section 5).  Then, the Group Manager adds the retrieved public key
      to the list of public keys of the current group members.

   o  The Group Manager stores the association between i) the public key
      of the joining node; and ii) the Group Identifier (Gid) (Gid), i.e. the
      OSCORE ID Context, associated to the OSCORE group together with
      the OSCORE Sender ID assigned to the joining node in the group.
      The Group Manager MUST keep this association updated over time.

   Then, the Group Manager replies to the joining node node, providing the
   updated security parameters and keying meterial necessary to
   participate in the group communication.  This success Joining
   Response is formatted as defined in Section 4.1.2.1 of
   [I-D.ietf-ace-key-groupcomm].  In particular:
   [I-D.ietf-ace-key-groupcomm], with the following additions:

   o  The 'kty' 'gkty' parameter identifies a key of type
      "Group_OSCORE_Security_Context object", defined in Section 15.1 of
      this specification.

   o  The 'key' parameter includes what the joining node needs in order
      to set up the OSCORE Security Context as per Section 2 of
      [I-D.ietf-core-oscore-groupcomm].  This parameter has as value a
      Group_OSCORE_Security_Context object, which is defined in this
      specification and extends the OSCORE_Security_Context object
      encoded in CBOR as defined in Section 3.2.1 of
      [I-D.ietf-ace-oscore-profile].  In particular, it contains the
      additional parameters 'cs_alg', 'cs_params', 'cs_key_params' and
      'cs_key_enc' defined in Section 15.2 of this specification.  More
      specifically, the 'key' parameter is composed as follows.

      *  The 'ms' parameter MUST be present and includes the OSCORE
         Master Secret value.

      *  The 'clientId' parameter, if present, has as value the OSCORE
         Sender ID assigned to the joining node by the Group Manager, as
         described above.  This parameter is not present if the node
         joins the group exclusively as monitor, according to what
         specified in the Access Token (see Section 3.2).  In any other
         case, this parameter MUST be present.

      *  The 'hkdf' parameter, if present, has as value the KDF
         algorithm used in the group.

      *  The 'alg' parameter, if present, has as value the AEAD
         algorithm used in the group.

      *  The 'salt' parameter, if present, has as value the OSCORE
         Master Salt.

      *  The 'contextId' parameter MUST be present and has as value the
         Group Identifier (Gid) associated to (Gid), i.e. the OSCORE ID Context of the
         OSCORE group.

      *  The 'rpl' parameter, if present, specifies the OSCORE Replay
         Window Size and Type value.

      *  The 'cs_alg' parameter MUST be present and specifies the
         algorithm used to countersign messages in the group.  This
         parameter takes values from Tables 5 and 6 of [RFC8152].

      *  The 'cs_params' parameter MAY be present and specifies the
         additional parameters for the counter signature algorithm.
         This parameter is a CBOR map whose content depends on the
         counter signature algorithm, as specified in Section 2 and
         Section 9.1 of [I-D.ietf-core-oscore-groupcomm].

      *  The 'cs_key_params' parameter MAY be present and specifies the
         additional parameters for the key used with the counter
         signature algorithm.  This parameter is a CBOR map whose
         content depends on the counter signature algorithm, as
         specified in Section 2 and Section 9.2 of
         [I-D.ietf-core-oscore-groupcomm].

      *  The 'cs_key_enc' parameter MAY be present and specifies the
         encoding of the public keys of the group members.  This
         parameter is a CBOR integer, whose value is 1 ("COSE_Key")
         taken from the 'Confirmation Key' column of the "CWT
         Confirmation Method" Registry defined in
         [I-D.ietf-ace-cwt-proof-of-possession], so indicating that
         public keys in the OSCORE group are encoded as COSE Keys
         [RFC8152].  Future specifications may define additional values
         for this parameter.  If this parameter is not present, 1
         ("COSE_Key") MUST be assumed as default value.

   o  The 'num' parameter MUST be present and specifies the current
      version number of the group keying material. present.

   o  The 'profile' 'ace-groupcomm-profile' parameter MUST be present and has
      value coap_group_oscore_app (TBD), which is defined in
      Section 15.3 of
      this specification.

   o  The 'exp' parameter MUST be present and specifies the expiration
      time in seconds after which the OSCORE Security Context derived
      from the 'key' of this specification.

   o  The 'exp' parameter is not valid anymore. MUST be present.

   o  The 'pub_keys' parameter is present only parameter, if the 'get_pub_keys'
      parameter was present in the Joining Request.  If present, this
      parameter includes the public keys of
      the group members that are relevant to the joining node.  That is,
      it includes: i) the public keys of the responders currently in the
      group, in case the joining node is configured (also) as requester;
      and ii) the public keys of the requesters currently in the group,
      in case the joining node is configured (also) as responder or
      monitor.  If public keys are encoded as COSE_Keys, each of them
      has as 'kid' the Sender ID that the corresponding owner has in the
      group, thus used as group member identifier.

   o  The 'group_policies' parameter SHOULD be present and includes a
      list of parameters indicating particular policies enforced in the
      group.  In particular, if the field "Sequence Number
      Synchronization Method" is present, it indicates the method to
      achieve synchronization of sequence numbers among group members
      (see Appendix E of [I-D.ietf-core-oscore-groupcomm]), by
      specifying the corresponding value from and SHOULD
      include the elements "Sequence Number Synchronization Method" Registry and
      "Key Update Check Interval" defined in Section 8.6 4.1.2. of
      [I-D.ietf-ace-key-groupcomm].

   Finally, the joining node uses the information received in the
   Joining Response to set up the OSCORE Security Context, as described
   in Section 2 of [I-D.ietf-core-oscore-groupcomm].  From then on, the
   joining node can exchange group messages secured with Group OSCORE as
   described in [I-D.ietf-core-oscore-groupcomm].

   If the application requires backward security, the Group Manager MUST
   generate updated security parameters and group keying material, and
   provide it to all the current group members upon the new node's joining
   (see Section 13).  As a consequence, the joining node is not able to
   access secure communication in the group occurred prior its joining.

5.  Public Keys of Joining Nodes

   Source authentication of OSCORE messages exchanged within the group
   is ensured by means of digital counter signatures (see Sections 2 and
   3 of [I-D.ietf-core-oscore-groupcomm]).  Therefore, group members
   must be able to retrieve each other's public key from a trusted key
   repository, in order to verify source authenticity of incoming group
   messages.

   As also discussed in [I-D.ietf-core-oscore-groupcomm], the Group
   Manager acts as trusted repository of the public keys of the group
   members, and provides those public keys to group members if requested
   to.  Upon joining an OSCORE group, a joining node is thus expected to
   provide its own public key to the Group Manager.

   In particular, one of the following four cases can occur when a new
   node joins an OSCORE group.

   o  The joining node is going to join the group exclusively as
      monitor.  That is, it is not going to send messages to the group,
      and hence to produce signatures with its own private key.  In this
      case, the joining node is not required to provide its own public
      key to the Group Manager, which thus does not have to perform any
      check related to the public key encoding, or to a countersignature
      algorithm and possible associated parameters for that joining
      node.

   o  The Group Manager already acquired the public key of the joining
      node during a past joining process.  In this case, the joining
      node MAY choose not to provide again its own public key to the
      Group Manager, in order to limit the size of the Joining Request.
      The joining node MUST provide its own public key again if it has
      provided the Group Manager with multiple public keys during past
      joining processes, intended for different OSCORE groups.  If the
      joining node provides its own public key, the Group Manager
      performs consistency checks as per Section 4.3 and, in case of
      success, considers it as the public key associated to the joining
      node in the OSCORE group.

   o  The joining node and the Group Manager use an asymmetric proof-of-
      possession key to establish a secure communication channel.  Then,
      two cases can occur.

      1.  The proof-of-possession key is compatible with the encoding as
          well as with the counter signature algorithm and possible
          associated parameters used in the OSCORE group.  Then, the
          Group Manager considers the proof-of-possession key as the
          public key associated to the joining node in the OSCORE group.
          If the joining node is aware that the proof-of-possession key
          is also valid for the OSCORE group, it MAY not provide it
          again as its own public key to the Group Manager.  The joining
          node MUST provide its own public key again if it has provided
          the Group Manager with multiple public keys during past
          joining processes, intended for different OSCORE groups.  If
          the joining node provides its own public key in the
          'client_cred' parameter of the Joining Request (see
          Section 4.2), the Group Manager performs consistency checks as
          per Section 4.3 and, in case of success, considers it as the
          public key associated to the joining node in the OSCORE group.

      2.  The proof-of-possession key is not compatible with the
          encoding or with the counter signature algorithm and possible
          associated parameters used in the OSCORE group.  In this case,
          the joining node MUST provide a different compatible public
          key to the Group Manager in the 'client_cred' parameter of the
          Joining Request (see Section 4.2).  Then, the Group Manager
          performs consistency checks on this latest provided public key
          as per Section 4.3 and, in case of success, considers it as
          the public key associated to the joining node in the OSCORE
          group.

   o  The joining node and the Group Manager use a symmetric proof-of-
      possession key to establish a secure communication channel.  In
      this case, upon performing a joining process with that Group
      Manager for the first time, the joining node specifies its own
      public key in the 'client_cred' parameter of the Joining Request
      targeting the group-membership endpoint (see Section 4.2).

6.  Retrieval of Updated Keying Material

   At some point, a group member considers the OSCORE Security Context
   invalid and to be renewed.  This happens, for instance, after a
   number of unsuccessful security processing of incoming messages from
   other group members, or when the Security Context expires as
   specified by the 'exp' parameter of the Joining Response.

   When this happens, the group member retrieves updated security
   parameters and group keying material.  This can occur in the two
   different ways described below.

6.1.  Retrieval of Group Keying Material

   If the group member wants to retrieve only the latest group keying
   material, it sends a Key Distribution Request to the Group Manager.

   In particular, it sends a CoAP GET request to the endpoint /group-
   oscore/GROUPNAME at the Group Manager.

   The Group Manager processes the Key Distribution Request according to
   Section 4.1.2.2 of [I-D.ietf-ace-key-groupcomm].  The Key
   Distribution Response is formatted as defined in Section 4.1.2.2 of
   [I-D.ietf-ace-key-groupcomm].

   Upon receiving the Key Distribution Response, the group member
   retrieves the updated security parameters and group keying material, by sending
   and, if they differ from the current ones, use them to set up the new
   OSCORE Security Context as described in Section 2 of
   [I-D.ietf-core-oscore-groupcomm].

6.2.  Retrieval of Group Keying Material and Sender ID

   If the group member wants to retrieve the latest group keying
   material as well as the Sender ID that it has in the OSCORE group, it
   sends a Key Distribution Request message to the Group Manager, as per Section 4.3 of
   [I-D.ietf-ace-key-groupcomm]. Manager.

   In particular, it sends a CoAP GET request to the endpoint /group-oscore/NAME /group-
   oscore/GROUPNAME/NODENAME at the Group Manager,
   where NAME is the name of the OSCORE group.  The Key Distribution
   Request is formatted as defined in Section 4.1.2.2 of
   [I-D.ietf-ace-key-groupcomm]. Manager.

   The Group Manager processes the Key Distribution Request according to
   Section 4.1.2.2 4.1.6.2 of [I-D.ietf-ace-key-groupcomm].  The Key
   Distribution Response is formatted as defined in Section 4.1.2.2 4.1.6.2 of
   [I-D.ietf-ace-key-groupcomm].  Note that the current Sender ID of the
   group member is not specified as a separate parameter, but rather
   included as 'clientId' in the 'key' parameter.

   Upon receiving the Key Distribution Response, the group member
   retrieves the updated security parameters and parameters, group keying material, material and
   Sender ID, and, if they differ from the current ones, use them to set
   up the new OSCORE Security Context as described in Section 2 of
   [I-D.ietf-core-oscore-groupcomm].

7.  Retrieval of New Keying Material

   As discussed in Section 2.2 of [I-D.ietf-core-oscore-groupcomm], a
   group member may at some point experience a wrap-around of its own
   Sender Sequence Number in the group.

   When this happens, the group member MUST send a Key Renewal Request
   message to the Group Manager, as per Section 4.4 of
   [I-D.ietf-ace-key-groupcomm].  In particular, it sends a CoAP GET PUT
   request to the endpoint /group-oscore/NAME/node /group-oscore/GROUPNAME/NODENAME at the Group Manager,
   where NAME is the name of the OSCORE group.
   Manager.

   Upon receiving the Key Renewal Request, the Group Manager processes
   it as defined in Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm], and
   performs one of the following actions.

   1.  The Group Manager replies to the group member with a 4.06 (Not
       Acceptable) error response, and rekeys the whole OSCORE group as
       discussed in Section 13.

   2.  The Group Manager generates a new Sender ID for that group member
       and replies with a Key Renewal Response, formatted as defined in
       Section 4.1.6.2 of [I-D.ietf-ace-key-groupcomm].  In particular,
       the CBOR Map in the response payload includes a single parameter
       'clientId' defined in Section 15.5 of this document, specifying
       the new Sender ID of the group member encoded as a CBOR byte
       string.

8.  Retrieval of Public Keys of Group Members

   A group member may need to retrieve the public keys of other group
   members.  To this end, the group member sends a Public Key Request
   message to the Group Manager, as per Section 4.5 of
   [I-D.ietf-ace-key-groupcomm].  In particular, it sends the request to
   the endpoint /group-oscore/NAME/pub-key /group-oscore/GROUPNAME/pub-key at the Group Manager, where
   NAME is the name of the OSCORE group. Manager.

   If the Public Key Request uses the method POST, FETCH, the Public Key
   Request is formatted as defined in Section 4.1.3.1 of
   [I-D.ietf-ace-key-groupcomm].  In particular, each element of the
   'get_pub_keys' parameter is a CBOR byte string, which encodes the
   Sender ID of the group member for which the associated public key is
   requested.

   Upon receiving the Public Key Request, the Group Manager processes it
   as per Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm],
   depending on the request method being POST FETCH or GET, respectively.  If
   Additionally, if the Public Key Request uses the method POST, FETCH, the
   Group Manager silently ignores identifiers included in the
   'get_pub_keys' parameter of the request that are not associated to
   any current group member.

   The success Public Key Response is formatted as defined in
   Section 4.1.3.1 or 4.1.3.2 of [I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm], depending
   on the request method being FETCH or GET, respectively.

9.  Retrieval of Group Policies

   A group member may request the current policies used in the OSCORE
   group.  To this end, the group member sends a Policies Request, as
   per Section 4.6 of [I-D.ietf-ace-key-groupcomm].  In particular, it
   sends a CoAP GET request to the endpoint /group-oscore/NAME/policies /group-oscore/GROUPNAME/
   policies at the Group Manager, where NAME GROUPNAME is the name of the
   OSCORE group.

   Upon receiving the Policies Request, the Group Manager processes it
   as per Section 4.1.4.1 of [I-D.ietf-ace-key-groupcomm].  The success
   Policies Response is formatted as defined in Section 4.1.4.1 of
   [I-D.ietf-ace-key-groupcomm].

10.  Retrieval of Keying Material Version

   A group member may request the current version of the keying material
   used in the OSCORE group.  To this end, the group member sends a
   Version Request, as per Section 4.7 of [I-D.ietf-ace-key-groupcomm].
   In particular, it sends a CoAP GET request to the endpoint /group-
   oscore/NAME/ctx-num
   oscore/GROUPNAME/ctx-num at the Group Manager, where NAME GROUPNAME is the
   name of the OSCORE group.

   Upon receiving the Version Request, the Group Manager processes it as
   per Section 4.1.5.1 of [I-D.ietf-ace-key-groupcomm].  The success
   Version Response is formatted as defined in Section 4.1.5.1 of
   [I-D.ietf-ace-key-groupcomm].

11.  Request to Leave the Group

   A group member may request to leave the OSCORE group.  To this end,
   the group member sends a Group Leaving Request, as per Section 4.8 of
   [I-D.ietf-ace-key-groupcomm].  In particular, it sends a CoAP POST DELETE
   request to the endpoint /group-oscore/NAME/node /group-oscore/GROUPNAME/NODENAME at the Group Manager,
   where NAME is the name of the OSCORE group to leave.

   The Leaving Request is formatted as defined in Section 4.1.6.1 of
   [I-D.ietf-ace-key-groupcomm], and MUST have an empty CBOR Map as
   payload.
   Manager.

   Upon receiving the Group Leaving Request, the Group Manager processes
   it as per Section 4.1.6.1 4.1.6.3 of [I-D.ietf-ace-key-groupcomm].

12.  Removal of a Group Member

   Other than after a spontaneous request to the Group Manager as
   described in Section 11, a node may be forcibly removed from the
   OSCORE group, e.g. due to expired or revoked authorization.

   In either case, if the leaving node is not configured exclusively as
   monitor, the Group Manager performs the following actions.

   o  The Group Manager frees the OSCORE Sender ID value of the leaving
      node, which becomes available for possible upcoming joining nodes.

   o  The Group Manager cancels the association between, on one hand,
      the public key of the leaving node and, on the other hand, the
      Group Identifier (Gid) associated to the OSCORE group together
      with the freed OSCORE Sender ID value.  The Group Manager deletes
      the public key of the leaving node, if that public key has no
      remaining association with any pair (Group ID, (Gid, Sender ID).

   If the application requires forward security, the Group Manager MUST
   generate updated security parameters and group keying material, and
   provide it to the remaining group members (see Section 13).  As a
   consequence, the leaving node is not able to acquire the new security
   parameters and group keying material distributed after its leaving.

   Same considerations in Section 5 of [I-D.ietf-ace-key-groupcomm]
   apply here as well, considering the Group Manager acting as KDC.

13.  Group Rekeying Process

   In order to rekey the OSCORE group, the Group Manager distributes a
   new Group Identifier (Gid), i.e. a new OSCORE ID of the group Context, and a new
   OSCORE Master Secret for that group.  When doing so, the Group
   Manager MUST increment the version number of the group keying
   material.  Also, the Group Manager MUST preserve the same unchanged
   Sender IDs for all group members.  This avoids affecting the
   retrieval of public keys from the Group Manager as well as the
   verification of message countersignatures.

   The Group Manager MUST support at least the following group rekeying
   scheme.  Future application profiles may define alternative message
   formats and distribution schemes.

   The Group Manager uses the same format of the Joining Response
   message in Section 4.3. 4.4.  In particular:

   o  Only the parameters 'kty', 'gkty', 'key', 'num', 'profile' 'ace-groupcomm-profile'
      and 'exp' are present.

   o  The 'ms' parameter of the 'key' parameter specifies the new OSCORE
      Master Secret value.

   o  The 'contextId' parameter of the 'key' parameter specifies the new
      Group ID.

   The Group Manager separately sends a group rekeying message to each
   group member to be rekeyed.  Each rekeying message MUST be secured
   with the pairwise secure communication channel between the Group
   Manager and the group member used during the joining process.

   This approach requires group members to act (also) as servers, in
   order to correctly handle unsolicited group rekeying messages from
   the Group Manager.  In particular, if a group member and the Group
   Manager use OSCORE [RFC8613] to secure their pairwise communications,
   the group member MUST create a Replay Window in its own Recipient
   Context upon establishing the OSCORE Security Context with the Group
   Manager, e.g. by means of the OSCORE profile of ACE
   [I-D.ietf-ace-oscore-profile].

   Group members and the Group Manager SHOULD additionally support
   alternative rekeying approaches that do not require group members to
   act (also) as servers.  A number of such approaches are defined in
   Section 4 4.3 of [I-D.ietf-ace-key-groupcomm].  In particular, a group
   member may subscribe for updates to the group-membership resource of
   the group, at the endpoint /group-oscore/NAME /group-oscore/GROUPNAME/NODENAME of the
   Group Manager,
   where NAME is the name of the OSCORE group. Manager.  This can rely on CoAP Observe [RFC7641] or on a full-fledged full-
   fledged Pub-Sub model [I-D.ietf-core-coap-pubsub] with the Group
   Manager acting as Broker.

14.  Security Considerations

   The method described in this document leverages the following
   management aspects related to OSCORE groups and discussed in the
   sections of [I-D.ietf-core-oscore-groupcomm] referred below.

   o  Management of group keying material (see Section 2.1 of
      [I-D.ietf-core-oscore-groupcomm]).  The Group Manager is
      responsible for the renewal and re-distribution of the keying
      material in the groups of its competence (rekeying).  According to
      the specific application requirements, this can include rekeying
      the group upon changes in its membership.  In particular, renewing
      the group keying material is required upon a new node's joining or
      a current node's leaving, in case backward security and forward
      security have to be preserved, respectively.

   o  Provisioning and retrieval of public keys (see Section 2 of
      [I-D.ietf-core-oscore-groupcomm]).  The Group Manager acts as key
      repository of public keys of group members, and provides them upon
      request.

   o  Synchronization of sequence numbers (see Section 5 5.1 of
      [I-D.ietf-core-oscore-groupcomm]).  This concerns how a responder
      node that has just joined an OSCORE group can synchronize with the
      sequence number of requesters in the same group.

   Before sending the Joining Response, the Group Manager MUST verify
   that the joining node actually owns the associated private key.  To
   this end, the Group Manager can rely on the proof-of-possession
   challenge-response defined in Section 4.  Alternatively, the joining
   node can use its own public key as asymmetric proof-of-possession key
   to establish a secure channel with the Group Manager, e.g. as in
   Section 3.2 of [I-D.ietf-ace-dtls-authorize].  However, this requires
   such proof-of-possession key to be compatible with the encoding as
   well as with the countersignature algorithm and possible associated
   parameters used in the OSCORE group.

   A node may have joined multiple OSCORE groups under different non-
   synchronized Group Managers.  Therefore, it can happen that those
   OSCORE groups have the same Group Identifier (Gid).  It follows that,
   upon receiving a Group OSCORE message addressed to one of those
   groups, the node would have multiple Security Contexts matching with
   the Gid in the incoming message.  It is up to the application to
   decide how to handle such collisions of Group Identifiers, e.g. by
   trying to process the incoming message using one Security Context at
   the time until the right one is found.

   Further security considerations are inherited from
   [I-D.ietf-ace-key-groupcomm], the ACE framework for Authentication
   and Authorization [I-D.ietf-ace-oauth-authz], and the specific
   transport profile of ACE signalled by the AS, such as
   [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile].

15.  IANA Considerations

   Note to RFC Editor: Please replace all occurrences of "[[This
   specification]]" with the RFC number of this specification and delete
   this paragraph.

   This document has the following actions for IANA.

15.1.  ACE Groupcomm Key Registry

   IANA is asked to register the following entry in the "ACE Groupcomm
   Key" Registry defined in Section 8.3 8.4 of [I-D.ietf-ace-key-groupcomm].

   o  Name: Group_OSCORE_Security_Context object

   o  Key Type Value: TBD

   o  Profile: "coap_group_oscore_app", defined in Section 15.3 of this
      specification.

   o  Description: A Group_OSCORE_Security_Context object encoded as
      described in Section 4.3 4.4 of this specification.

   o  Reference: [[This specification]]

15.2.  OSCORE Security Context Parameters Registry

   IANA is asked to register the following entries in the "OSCORE
   Security Context Parameters" Registry defined in Section 9.2 of
   [I-D.ietf-ace-oscore-profile].

   o  Name: cs_alg

   o  CBOR Label: TBD

   o  CBOR Type: tstr / int

   o  Registry: COSE Algorithm Values (ECDSA, EdDSA)

   o  Description: OSCORE Counter Signature Algorithm Value

   o  Reference: [[This specification]]

   o  Name: cs_params

   o  CBOR Label: TBD

   o  CBOR Type: map

   o  Registry: Counter Signatures Parameters

   o  Description: OSCORE Counter Signature Algorithm Additional
      Parameters

   o  Reference: [[This specification]]

   o  Name: cs_key_params

   o  CBOR Label: TBD

   o  CBOR Type: map

   o  Registry: Counter Signatures Key Parameters

   o  Description: OSCORE Counter Signature Key Additional Parameters

   o  Reference: [[This specification]]
   o  Name: cs_key_enc

   o  CBOR Label: TBD

   o  CBOR Type: integer

   o  Registry: ACE Public Key Encoding

   o  Description: Encoding of Public Keys to be used with the OSCORE
      Counter Signature Algorithm

   o  Reference: [[This specification]]

15.3.  ACE Groupcomm Profile Registry

   IANA is asked to register the following entry in the "ACE Groupcomm
   Profile" Registry defined in Section 8.4 8.5 of
   [I-D.ietf-ace-key-groupcomm].

   o  Name: coap_group_oscore_app

   o  Description: Application profile to provision keying material for
      participating in group communication protected with Group OSCORE
      as per [I-D.ietf-core-oscore-groupcomm].

   o  CBOR Value: TBD

   o  Reference: [[This specification]]

15.4.  Sequence Number Synchronization Method Registry

   IANA is asked to register the following entries in the "Sequence
   Number Synchronization Method" Registry defined in Section 8.6 8.7 of
   [I-D.ietf-ace-key-groupcomm].

   o  Name: Best effort

   o  Value: 1

   o  Description: No action is taken.

   o  Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.1).

   o  Name: Baseline

   o  Value: 2
   o  Description: The first received request sets the baseline
      reference point, and is discarded with no delivery to the
      application.

   o  Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.2).

   o  Name: Echo challenge-response

   o  Value: 3

   o  Description: Challenge response using the Echo Option for CoAP
      from [I-D.ietf-core-echo-request-tag].

   o  Reference: [I-D.ietf-core-oscore-groupcomm] (Appendix E.3).

15.5.  ACE Groupcomm Parameters Registry

   IANA is asked to register the following entry in the "ACE Groupcomm
   Parameters" Registry defined in Section 8.2 8.3 of
   [I-D.ietf-ace-key-groupcomm].

   o  Name: clientId

   o  CBOR Key: TBD

   o  CBOR Type: Byte string

   o  Reference: [[This document]] (Section 7).

16.  References

16.1.  Normative References

   [I-D.ietf-ace-cwt-proof-of-possession]
              Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
              Tschofenig, "Proof-of-Possession Key Semantics for CBOR
              Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
              possession-11 (work in progress), October 2019.

   [I-D.ietf-ace-key-groupcomm]
              Palombini, F. and M. Tiloca, "Key Provisioning for Group
              Communication using ACE", draft-ietf-ace-key-groupcomm-03 draft-ietf-ace-key-groupcomm-04
              (work in progress), November 2019. January 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-25 draft-ietf-ace-oauth-authz-30
              (work in progress), October 2019. January 2020.

   [I-D.ietf-ace-oscore-profile]
              Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
              "OSCORE profile of the Authentication and Authorization
              for Constrained Environments Framework", draft-ietf-ace-
              oscore-profile-08 (work in progress), July 2019.

   [I-D.ietf-core-oscore-groupcomm]
              Tiloca, M., Selander, G., Palombini, F., and J. Park,
              "Group OSCORE - Secure Group Communication for CoAP",
              draft-ietf-core-oscore-groupcomm-05
              draft-ietf-core-oscore-groupcomm-06 (work in progress),
              July
              November 2019.

   [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>.

   [RFC3986]  Berners-Lee, T., Fielding, R.,

   [RFC5869]  Krawczyk, H. and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 3986, 5869,
              DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>. 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.

   [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>.

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

   [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>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [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>.

16.2.  Informative References

   [I-D.dijk-core-groupcomm-bis]
              Dijk, E., Wang, C., and M. Tiloca, "Group Communication
              for the Constrained Application Protocol (CoAP)", draft-
              dijk-core-groupcomm-bis-01
              dijk-core-groupcomm-bis-02 (work in progress), July November
              2019.

   [I-D.ietf-ace-dtls-authorize]
              Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
              L. Seitz, "Datagram Transport Layer Security (DTLS)
              Profile for Authentication and Authorization for
              Constrained Environments (ACE)", draft-ietf-ace-dtls-
              authorize-08
              authorize-09 (work in progress), December 2019.

   [I-D.ietf-ace-mqtt-tls-profile]
              Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile
              of ACE", draft-ietf-ace-mqtt-tls-profile-03 (work in
              progress), April December 2019.

   [I-D.ietf-core-coap-pubsub]
              Koster, M., Keranen, A., and J. Jimenez, "Publish-
              Subscribe Broker for the Constrained Application Protocol
              (CoAP)", draft-ietf-core-coap-pubsub-09 (work in
              progress), September 2019.

   [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-08 (work in progress), November 2019.

   [I-D.tiloca-core-oscore-discovery]
              Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE
              Groups with the CoRE Resource Directory", draft-tiloca-
              core-oscore-discovery-03
              core-oscore-discovery-04 (work in progress), July November
              2019.

   [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>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC7390]  Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
              the Constrained Application Protocol (CoAP)", RFC 7390,
              DOI 10.17487/RFC7390, October 2014,
              <https://www.rfc-editor.org/info/rfc7390>.

   [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>.

Appendix A.  Profile Requirements

   This appendix lists the specifications on this application profile of
   ACE, based on the requiremens defined in Appendix A of
   [I-D.ietf-ace-key-groupcomm].

   o  REQ1 - Specify the encoding and value of the identifier of group
      of 'scope': see Section 3.1.

   o  REQ2 - Specify the encoding and value of the identifier of roles
      of 'scope': see Section 3.1.

   o  REQ3 (Optional) - Specify if used, specify the acceptable values for 'sign_alg':
      values from Tables 5 and 6 of [RFC8152].

   o  REQ4 (Optional) - Specify If used, specify the acceptable values for
      'sign_parameters': values from the "Counter Signature Parameters"
      Registry (see Section 9.1 of [I-D.ietf-core-oscore-groupcomm]).

   o  REQ5 (Optional) - Specify If used, specify the acceptable values for
      'sign_key_parameters': values from the "Counter Signature Key
      Parameters" Registry (see Section 9.2 of
      [I-D.ietf-core-oscore-groupcomm]).

   o  REQ6 (Optional) - Specify If used, specify the acceptable values for 'pub_key_enc': 1
      ("COSE_Key") from the 'Confirmation Key' column of the "CWT
      Confirmation Method" Registry defined in
      [I-D.ietf-ace-cwt-proof-of-possession].  Future specifications may
      define additional values for this parameter.

   o  REQ7 - Format of the 'key' value: see Section 4.3. 4.4.

   o  REQ8 - Acceptable values of 'kty': 'gkty': Group_OSCORE_Security_Context
      object (see Section 4.3). 4.4).

   o  REQ9: Specify the format of the identifiers of group members: see
      Section 4.3 4.4 and Section 8.

   o  REQ10 (Optional) - Specify the format and content of
      'group_policies' entries: three values are defined and registered,
      as content of the entry "Sequence Number Synchronization Method"
      (see Section 15.4).

   o  REQ11 - Communication communication protocol that the members of the
      group must use: CoAP, possibly over IP multicast.

   o  REQ12  REQ11 - Security Specify the security protocols that the group members must
      use to protect their communication: Group OSCORE.

   o  REQ13 - Profile identifier: coap_group_oscore_app

   o  REQ14 (Optional)  REQ12 - Specify the encoding of public keys, of
      'client_cred', and of 'pub_keys' if COSE_Keys are not used: no. register the application profile identifier:
      coap_group_oscore_app (see Section 15.3).

   o  REQ15  REQ13 - Specify policies at the KDC to handle member ids that are
      not included in 'get_pub_keys': see Section 8.

   o  REQ16  REQ14 - Specify If used, specify the format and content of 'group_policies':
      'group_policies' and its entries: see Section 4.3. 4.4, and the three
      values defined and registered, as content of the entry "Sequence
      Number Synchronization Method" (see Section 15.4).

   o  REQ17  REQ15 - Specify the format of newly-generated individual keying
      material for group members, or of the information to derive it,
      and corresponding CBOR label: see Section 7.

   o  REQ18  REQ16 - Specify how the communication is secured between the
      Client and KDC: by means of any transport profile of ACE
      [I-D.ietf-ace-oauth-authz] between Client and Group Manager that
      complies with the requirements in Appendix C of
      [I-D.ietf-ace-oauth-authz].

   o  REQ17: Specify how the nonce N_S is generated, if the token is not
      being posted (e.g. if it is used directly to validate TLS
      instead): see Section 4.2.1.

   o  REQ18: Specify if 'mgt_key_material' used, and if yes specify its
      format and content: not used in this version of the profile.

   o  OPT1 (Optional) - Specify the encoding of public keys, of
      'client_cred', and of 'pub_keys' if COSE_Keys are not used: no.

   o  OPT2 (Optional) - Specify the negotiation of parameter values for
      signature algorithm and signature keys, if 'sign_info' and
      'pub_key_enc' are not used: possible early discovery by using the
      approach based on the CoRE Resource Directory described in
      [I-D.tiloca-core-oscore-discovery].

   o  OPT3 (Optional) - Specify the format and content encoding of
      'mgt_key_material': 'pub_keys_repos' if the
      default is not used: no.

   o  OPT4 (Optional) - Specify policies that instruct clients to retain
      unsuccessfully decrypted messages and for how long, so that they
      can be decrypted after getting updated keying material: no.

   o  OPT5 (Optional) - Specify the behavior of the handler in case of
      failure to retrieve a public key for the specific node: send a
      4.00 Bad Request response to a Joining Request (see Section 4.3).

   o  OPT6 (Optional) - Specify possible or required payload formats for
      specific error cases: send a 4.00 Bad Request response to a
      Joining Request (see Section 4.3).

Appendix B.  Document Updates

   RFC EDITOR: PLEASE REMOVE THIS SECTION.

B.1.  Version -03 to -04

   o  New abstract.

   o  Moved general content to draft-ietf-ace-key-groupcomm

   o  Terminology: node name; node resource.

   o  Creation and pointing at node resource.

   o  Updated Group Manager API (REST methods and offered services).

   o  Size of challenges 'cnonce' and 'rsnonce'.

   o  Value of 'rsnonce' for reused or non-traditionally-posted tokens.

   o  Removed reference to RFC 7390.

   o  New requirements from draft-ietf-ace-key-groupcomm

   o  Editorial improvements.

B.2.  Version -02 to -03

   o  New sections, aligned with the interface of ace-key-groupcomm .

   o  Exchange of information on the countersignature algorithm and
      related parameters, during the Token POST (Section 4.1).

   o  Nonce 'rsnonce' from the Group Manager to the Client
      (Section 4.1).

   o  Client PoP signature in the Key Distribution Request upon joining
      (Section 4.2).

   o  Local actions on the Group Manager, upon a new node's joining
      (Section 4.2).

   o  Local actions on the Group Manager, upon a node's leaving
      (Section 12).

   o  IANA registration in ACE Groupcomm Parameters Registry.

   o  More fulfilled profile requirements (Appendix A).

B.2.

B.3.  Version -01 to -02

   o  Editorial fixes.

   o  Changed: "listener" to "responder"; "pure listener" to "monitor".

   o  Changed profile name to "coap_group_oscore_app", to reflect it is
      an application profile.

   o  Added the 'type' parameter for all requests to a Join Resource.

   o  Added parameters to indicate the encoding of public keys.

   o  Challenge-response for proof-of-possession of signature keys
      (Section 4).

   o  Renamed 'key_info' parameter to 'sign_info'; updated its format;
      extended to include also parameters of the countersignature key
      (Section 4.1).

   o  Code 4.00 (Bad request), in responses to joining nodes providing
      an invalid public key (Section 4.3).

   o  Clarifications on provisioning and checking of public keys
      (Sections 4 and 6).

   o  Extended discussion on group rekeying and possible different
      approaches (Section 7).

   o  Extended security considerations: proof-of-possession of signature
      keys; collision of OSCORE Group Identifiers (Section 8).

   o  Registered three entries in the IANA Registry "Sequence Number
      Synchronization Method Registry" (Section 9).

   o  Registered one public key encoding in the "ACE Public Key
      Encoding" IANA Registry (Section 9).

B.3.

B.4.  Version -00 to -01

   o  Changed name of 'req_aud' to 'audience' in the Authorization
      Request (Section 3.1).

   o  Added negotiation of countersignature algorithm/parameters between
      Client and Group Manager (Section 4).

   o  Updated format of the Key Distribution Response as a whole
      (Section 4.3).

   o  Added parameter 'cs_params' in the 'key' parameter of the Key
      Distribution Response (Section 4.3).

   o  New IANA registrations in the "ACE Authorization Server Request
      Creation Hints" Registry, "ACE Groupcomm Key" Registry, "OSCORE
      Security Context Parameters" Registry and "ACE Groupcomm Profile"
      Registry (Section 9).

Acknowledgments

   The authors sincerely thank Santiago Aragon, Stefan Beck, Carsten
   Bormann, Martin Gunnarsson, Rikard Hoeglund, Daniel Migault, Jim
   Schaad, Ludwig Seitz, Goeran Selander and Peter van der Stok for
   their comments and feedback.

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

Authors' Addresses

   Marco Tiloca
   RISE AB
   Isafjordsgatan 22
   Kista  SE-164 29 Stockholm
   Sweden

   Email: marco.tiloca@ri.se
   Jiye Park
   Universitaet Duisburg-Essen
   Schuetzenbahn 70
   Essen  45127
   Germany

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

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

   Email: francesca.palombini@ericsson.com