ACE Working Group                                           F. Palombini
Internet-Draft                                               Ericsson AB
Intended status: Standards Track                               M. Tiloca
Expires: 6 May August 26, 2021                                         RISE AB
                                                         2 November 2020
                                                       February 22, 2021

           Key Provisioning for Group Communication using ACE
                    draft-ietf-ace-key-groupcomm-10
                    draft-ietf-ace-key-groupcomm-11

Abstract

   This document defines message formats and procedures for requesting
   and distributing group keying material using the ACE framework, to
   protect communications between group members.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/ace-wg/ace-key-groupcomm.

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 6 May August 26, 2021.

Copyright Notice

   Copyright (c) 2020 2021 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)
   (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 . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Authorization to Join a Group . . . . . . . . . . . . . . . .   7
     3.1.  Authorization Request . . . . . . . . . . . . . . . . . .   8
     3.2.  Authorization Response  . . . . . . . . . . . . . . . . .  10
     3.3.  Token Post  . . . . . . . . . . . . . . . . . . . . . . .  10  11
   4.  Keying Material Provisioning and Group Membership Management  . . . . . . . . . . . . . . . . . . . . . . .   14
     4.1.  Interface at the KDC  . . . . . . . . . . . . . . . . . .  15  16
     4.2.  Retrieval of Group Names and URIs . . . . . . . . . . . .  33  38
     4.3.  Joining Exchange  . . . . . . . . . . . . . . . . . . . .  34  38
     4.4.  Retrieval of Updated Keying Material  . . . . . . . . . .  36  40
     4.5.  Requesting a Change of Keying Material  . . . . . . . . .  39  43
     4.6.  Retrieval of Public Keys and Roles for Group Members  . .  40  44
     4.7.  Update of Public Key  . . . . . . . . . . . . . . . . . .  42  46
     4.8.  Retrieval of Group Policies . . . . . . . . . . . . . . .  43  47
     4.9.  Retrieval of Keying Material Version  . . . . . . . . . .  44  48
     4.10. Group Leaving Request . . . . . . . . . . . . . . . . . .  45  49
   5.  Removal of a Node from the Group  . . . . . . . . . . . . . .  45  49
   6.  Extended Scope Format . . . . . . . . . . . . . . . . . . . .  51
   7.  ACE Groupcomm Parameters  . . . . . . . . . . . . . . . . . .  46
   7.  53
   8.  ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . .  54
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  48
     7.1.  55
     9.1.  Update of Keying Material . . . . . . . . . . . . . . . .  49
     7.2.  56
     9.2.  Block-Wise Considerations . . . . . . . . . . . . . . . .  50
   8.  57
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  50
     8.1.  57
     10.1.  Media Type Registrations . . . . . . . . . . . . . . . .  50
     8.2.  57
     10.2.  CoAP Content-Formats Registry  . . . . . . . . . . . . . .  51
     8.3.  58
     10.3.  OAuth Parameters Registry  . . . . . . . . . . . . . . . .  51
     8.4.  59
     10.4.  OAuth Parameters CBOR Mappings Registry  . . . . . . . . .  52
     8.5.  59
     10.5.  ACE Groupcomm Parameters Registry  . . . . . . . . . . . .  52
     8.6.  59
     10.6.  ACE Groupcomm Key Registry . . . . . . . . . . . . . . .  53
     8.7.  60
     10.7.  ACE Groupcomm Profile Registry . . . . . . . . . . . . .  53
     8.8.  60
     10.8.  ACE Groupcomm Policy Registry  . . . . . . . . . . . . . .  54
     8.9.  61
     10.9.  Sequence Number Synchronization Method Registry  . . . . .  55
     8.10.  62
     10.10. Interface Description (if=) Link Target Attribute Values
            Registry . . . . . . . . . . . . . . . . . . . . . . . .  55
     8.11.  62
     10.11. CBOR Tags Registry . . . . . . . . . . . . . . . . . . .  63
     10.12. ACE Scope Semantics  . . . . . . . . . . . . . . . . . .  63
     10.13. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . .  63
     10.14. Expert Review Instructions . . . . . . . . . . . . . . .  55
   9.  64
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  56
     9.1.  65
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  56
     9.2.  65
     11.2.  Informative References . . . . . . . . . . . . . . . . .  58  67
     11.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  68
   Appendix A.  Requirements on Application Profiles . . . . . . . .  60  68
   Appendix B.  Document Updates . . . . . . . . . . . . . . . . . .  63  71
     B.1.  Version -04 to -05  . . . . . . . . . . . . . . . . . . .  63  71
     B.2.  Version -03 to -04  . . . . . . . . . . . . . . . . . . .  63  72
     B.3.  Version -02 to -03  . . . . . . . . . . . . . . . . . . .  64  72
     B.4.  Version -01 to -02  . . . . . . . . . . . . . . . . . . .  64  73
     B.5.  Version -00 to -01  . . . . . . . . . . . . . . . . . . .  65  73
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  66  74
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  66  74

1.  Introduction

   This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to
   define the message exchanges used to request, distribute and renew
   the keying material in a group communication scenario, e.g. based on
   multicast [I-D.ietf-core-groupcomm-bis] or on publishing-subscribing
   [I-D.ietf-core-coap-pubsub].  The ACE framework is based on CBOR
   [I-D.ietf-cbor-7049bis],
   [RFC8949], so CBOR is the format used in this specification.
   However, using JSON [RFC8259] instead of CBOR is possible, using the
   conversion method specified in Sections 6.1 and 6.2 of [I-D.ietf-cbor-7049bis]. [RFC8949].

   Profiles that use group communication can build on this document, by
   defining a number of details such as the exact group communication
   protocol and security protocols used.  The specific list of details a
   profile needs to define is shown in Appendix A.

   If the application requires backward and forward security, new keying
   material is generated and distributed to the group upon membership
   changes.  A key management scheme performs the actual distribution of
   the new keying material to the group.  In particular, the key
   management scheme rekeys the current group members when a new node
   joins the group, and the remaining group members when a node leaves
   the group.  Rekeying mechanisms can be based on [RFC2093], [RFC2094]
   and [RFC2627].

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 [I-D.ietf-ace-oauth-authz][I-D.ietf-cose-rfc8152bis-stru
   ct][I-D.ietf-cose-rfc8152bis-algs], such as Authorization Server (AS)
   and Resource Server (RS).

   This document uses names or identifiers for groups and nodes.  Their
   different meanings are summarized here:

   *

   o  "Group name" is the invariant once established identifier of the
      group.  It is used in the communication between AS, RS and Client
      to identify the group.

   *

   o  "GROUPNAME" is the invariant once established text string used in
      URIs.  GROUPNAME maps to the group name of a group, although it is
      not necessarily the same.

   *

   o  "Group identifier" is the identifier of the group keying material.
      Opposite to group name and GROUPNAME, this identifier changes over
      time, when the keying material is updated.

   *

   o  "Node name" is the invariant once established identifier of the
      node.  It is used in the communication between AS, RS and Client
      to identify a member of the group.

   *

   o  "NODENAME" is the invariant once established text string used in
      URIs.  NODENAME is used to identify a node in a group.

   This document additionally uses the following terminology:

   *

   o  Transport profile, to indicate a profile of ACE as per
      Section 5.6.4.3 5.8.4.3 of [I-D.ietf-ace-oauth-authz].  A transport
      profile specifies the communication protocol and communication
      security protocol between an ACE Client and Resource Server, as
      well as proof-of-possession methods, if it supports proof-of-
      possession access tokens, etc.  Tranport profiles of ACE include,
      for instance, [I-D.ietf-ace-oscore-profile],
      [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile].

   *

   o  Application profile, that defines how applications enforce and use
      supporting security services they require.  These services may
      include, for instance, provisioning, revocation and distribution
      of keying material.  An application profile may define specific
      procedures and message formats.

2.  Overview

   The full procedure can be separated in two phases: the first one
   follows the ACE framework, between Client, AS and KDC; the second one
   is the key distribution between Client and KDC.  After the two phases
   are completed, the Client is able to participate in the group
   communication, via a Dispatcher entity.

       +------------+                  +-----------+
       |     AS     |                  |    KDC    |
       |            |        .-------->|           |
       +------------+       /          +-----------+
             ^             /
             |            /
             v           /                           +-----------+
       +------------+   /      +------------+        |+-----------+
       |   Client   |<-'       | Dispatcher |        ||+-----------+
       |            |<-------->|            |<------->||   Group   |
       +------------+          +------------+         +|  members  |
                                                       +-----------+

                  Figure 1: Key Distribution Participants

   The following participants (see Figure 1) take part in the
   authorization and key distribution.

   *

   o  Client (C): node that wants to join the group communication.  It
      can request write and/or read rights.

   *

   o  Authorization Server (AS): same as AS in the ACE Framework; it
      enforces access policies, and knows if a node is allowed to join a
      given group with write and/or read rights.

   *

   o  Key Distribution Center (KDC): maintains the keying material to
      protect group communications, and provides it to Clients
      authorized to join a given group.  During the first part of the
      exchange (Section 3), it takes the role of the RS in the ACE
      Framework.  During the second part (Section 4), which is not based
      on the ACE Framework, it distributes the keying material.  In
      addition, it provides the latest keying material to group members
      when requested or, if required by the application, when membership
      changes.

   *

   o  Dispatcher: entity through which the Clients communicate with the
      group and which distributes messages to the group members.
      Examples of dispatchers are: the Broker node in a pub-sub setting;
      a relayer node for group communication that delivers group
      messages as multiple unicast messages to all group members; an
      implicit entity as in a multicast communication setting, where
      messages are transmitted to a multicast IP address and delivered
      on the transport channel.

   This document specifies a mechanism for:

   *

   o  Authorizing a new node to join the group (Section 3), and
      providing it with the group keying material to communicate with
      the other group members (Section 4).

   *

   o  Allowing a group member to leave the group (Section 5).

   *

   o  Evicting a group member from the group (Section 5).

   *

   o  Allowing a group member to retrieve keying material (Section 4.4
      and Section 4.5).

   *

   o  Renewing and re-distributing the group keying material (rekeying)
      upon a membership change in the group (Section 4.10 and
      Section 5).

   Figure 2 provides a high level overview of the message flow for a
   node joining a group communication setting, which can be expanded as
   follows.

   1.  The joining node requests an Access Token from the AS, in order
       to access a specific group-membership resource on the KDC and
       hence join the associated group.  This exchange between Client
       and AS MUST be secured, as specified by the transport profile of
       ACE used between Client and KDC.  The joining node will start or
       continue using a secure communication association with the KDC,
       according to the response from the AS.

   2.  The joining node transfers authentication and authorization
       information to the KDC, by posting the obtained Access Token to
       the /authz-info endpoint at the KDC.  This exchange, and all
       further communications between the Client and the KDC, MUST occur
       over the secure channel established as a result of the transport
       profile of ACE used between Client and KDC.  After that, a
       joining node MUST have a secure communication association
       established with the KDC, before starting to join a group under
       that KDC.  Possible ways to provide a secure communication
       association are described in the DTLS transport profile
       [I-D.ietf-ace-dtls-authorize] and OSCORE transport profile
       [I-D.ietf-ace-oscore-profile] of ACE.

   3.  The joining node starts the joining process to become a member of
       the group, by accessing the related group-membership resource at
       the KDC.  At the end of the joining process, the joining node has
       received from the KDC the parameters and keying material to
       securely communicate with the other members of the group, and the
       KDC has stored the association between the authorization
       information from the access token and the secure session with the
       joining node.

   4.  The joining node and the KDC maintain the secure association, to
       support possible future communications.  These especially include
       key management operations, such as retrieval of updated keying
       material or participation to a group rekeying process.

   5.  The joining node can communicate securely with the other group
       members, using the keying material provided in step 3.

               C                           AS  KDC                Group
               |                           |    |                 Member
             / |                           |    |                     |
             | |   Authorization Request   |    |                     |
    Defined  | |-------------------------->|    |                     |
    in the   | |                           |    |                     |
      ACE    | |   Authorization Response  |    |                     |
   framework | |<--------------------------|    |                     |
             | |                                |                     |
             \ |---------- Token Post --------->|                     |
               |                                |                     |
               |------- Joining Request ------->|                     |
               |                                |                     |
               |<------ Joining Response -------|-- Group Rekeying -->|
               |                                |                     |
               |                                     Dispatcher       |
               |                                         |            |
               |<===== Secure group communication =======|===========>|
               |                                         |            |

              Figure 2: Message Flow Upon New Node's Joining

3.  Authorization to Join a Group

   This section describes in detail the format of messages exchanged by
   the participants when a node requests access to a given group.  This
   exchange is based on ACE [I-D.ietf-ace-oauth-authz].

   As defined in [I-D.ietf-ace-oauth-authz], the Client requests from
   the AS an authorization to join the group through the KDC (see
   Section 3.1).  If the request is approved and authorization is
   granted, the AS provides the Client with a proof-of-possession access
   token and parameters to securely communicate with the KDC (see
   Section 3.2).

   Communications between the Client and the AS MUST be secured, as
   defined by the transport profile of ACE used.  The Content-Format
   used in the message depends on the used transport profile of ACE.
   For example, this can be application/ace+cbor for the first two
   messages and application/cwt for the third message, which are defined
   in the ACE framework.  The transport profile of ACE also defines a
   number of details such as the communication and security protocols
   used with the KDC (see Appendix C of [I-D.ietf-ace-oauth-authz]).

   Figure 3 gives an overview of the exchange described above.

         Client                                            AS  KDC
            |                                               |   |
            |---- Authorization Request: POST /token ------>|   |
            |                                               |   |
            |<--- Authorization Response: 2.01 (Created) ---|   |
            |                                               |   |
            |----- POST Token: POST /authz-info --------------->|
            |                                                   |

               Figure 3: Message Flow of Join Authorization

3.1.  Authorization Request

   The Authorization Request sent from the Client to the AS is defined
   in Section 5.6.1 5.8.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the
   following parameters, which, if included, MUST have the corresponding
   values:

   *

   o  'scope', containing the identifier of the specific group(s), groups, or
      topic(s)
      topics in the case of pub-sub, that the Client wishes to access,
      and optionally the role(s) roles that the Client wishes to take.

      This value is a CBOR byte string, wrapping a CBOR array of one or
      more entries.

      By default, each entry is encoded as specified by
      [I-D.ietf-ace-aif].  The object identifier Toid corresponds to the
      group name and MUST be encoded as a tstr.  The permission set
      Tperm indicates the roles that the client wishes to take in the
      group.  It is up to the application profiles to define Tperm
      (REQ2) and register Toid and Tperm to fit the use case.  An
      example of scope using the AIF format is given in Figure 4.

      Otherwise, each scope entry can be defined as a CBOR array, which
      contains:

      -

      *  As first element, the identifier of the specific group or
         topic, encoded as a tstr.

      -

      *  Optionally, as second element, the role (or CBOR array of
         roles) that the Client wishes to take in the group.  This
         element is optional since roles may have been pre-assigned to
         the Client, as associated to its verifiable identity
         credentials.  Alternatively, the application may have defined a
         single, well-known role for the target resource(s) and
         audience(s).

      In each entry, the encoding of the role identifiers is application
      specific, and part of the requirements for the application profile
      (REQ2).  In particular, the application profile may specify CBOR
      values to use for abbreviating role identifiers (OPT7). (OPT8).

      An example of CDDL definition [RFC8610] of scope using the format
      above, with group name and role identifiers encoded as text
      strings is given in Figure 5.

   *

   o  'audience', with an identifier of a KDC.

   As defined in [I-D.ietf-ace-oauth-authz], other additional parameters
   can be included if necessary.

   gname = tstr

   permissions = uint . bits roles

   roles = &(
      Requester: 1,
      Responder: 2,
      Monitor: 3,
      Verifier: 4
   )

   scope_entry = AIF_Generic<gname, permissions>

   scope = << [ + scope_entry ] >>

       Figure 4: Example CDLL definition of scope, using the default
                     Authorization Information Format

   gname = tstr

   role = tstr

   scope_entry = [ gname , ? ( role / [ 2*role ] ) ]

   scope = << [ + scope_entry ] >>

      Figure 5: CDLL definition of scope, using as example group name
                     encoded as tstr and role as tstr

3.2.  Authorization Response

   The Authorization Response sent from the AS to the Client is defined
   in Section 5.6.2 5.8.2 of [I-D.ietf-ace-oauth-authz].  Note that the
   parameter 'expires_in' MAY be omitted if the application defines how
   the expiration time is communicated to the Client via other means, or
   if it establishes a default value.

   Additionally, when included, the following parameter MUST have the
   corresponding values:

   *

   o  'scope' has the same format and encoding of 'scope' in the
      Authorization Request, defined in Section 3.1.  If this parameter
      is not present, the granted scope is equal to the one requested in
      Section 3.1}.

   The proof-of-possession access token (in 'access_token' above) MUST
   contain the following parameters:

   *

   o  a confirmation claim (see for example 'cnf' defined in Section 3.1
      of [RFC8747] for CWT);

   *

   o  an expiration time claim (see for example 'exp' defined in
      Section 3.1.4 of [RFC8392] for CWT);

   *

   o  a scope claim (see for example 'scope' registered in Section 8.13 8.14
      of [I-D.ietf-ace-oauth-authz] for CWT).

      This claim has specifies the same
      encoding access control information as in the
      'scope' parameter above.  Additionally, this claim
      has the same value of the 'scope' parameter Authorization Response, if the parameter
      is present in the message, or it takes as in the value of 'scope' in parameter of the
      Authorization Request otherwise.

      By default, this claim has the same encoding as the 'scope'
      parameter in the Authorization Request, defined in Section 3.1.

      Optionally, an alternative extended format of scope defined in
      Section 6 can be used.  This format explicitly signals the
      semantics used to express the actual access control information,
      and according to which this has to be parsed.  This enables a
      Resource Server to correctly process a received access token, also
      in case:

      *  The Resource Server implements a KDC that supports multiple
         application profiles of this specification, using different
         scope semantics; and/or

      *  The Resource Server implements further services beyond a KDC
         for group communication, using different scope semantics.

      If the Authorization Server is aware that this applies to the
      Resource Server for which the access token is issued, the
      Authorization Server SHOULD use the extended format of scope
      defined in Section 6.

   The access token MAY additionally contain other claims that the
   transport profile of ACE requires, or other optional parameters.

   When receiving an Authorization Request from a Client that was
   previously authorized, and for which the AS still owns a valid non-
   expired access token, the AS MAY reply with that token.  Note that it
   is up to application profiles of ACE to make sure that re-posting the
   same token does not cause re-use of keying material between nodes
   (for example, that is done with the use of random nonces in
   [I-D.ietf-ace-oscore-profile]).

3.3.  Token Post

   The Client sends a CoAP POST request including the access token to
   the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz].

   This request differs from the one defined in
   [I-D.ietf-ace-oauth-authz], because it allows to transport additional
   encoding information about the public keys in the group, used for
   source authentication, as well as any other group parameters.

   The joining node MAY ask for this information from the KDC in the
   same message it uses to POST the token to the RS.

   The payload of  In such a case,
   the message MUST have Content-Format set to application/ace+cbor
   defined in Section 8.16 of [I-D.ietf-ace-oauth-authz].  The message
   payload MUST be formatted as a CBOR map including map, which MUST include the
   access token.

   Additionally, the CoAP POST request  The CBOR map MAY contain additionally include the following
   parameter, which, if included, MUST have the corresponding values:

   *

   o  'sign_info' defined in Section 3.3.1, encoding the CBOR simple
      value Null to require information about the signature algorithm,
      signature algorithm parameters, signature key parameters and on
      the exact encoding of public keys used in the group.

   Alternatively, the joining node may retrieve this information by
   other means.

   After successful verification, the Client is authorized to receive
   the group keying material from the KDC and join the group.

   The KDC replies to the Client with a 2.01 (Created) response, using
   Content-Format "application/ace+cbor" defined in Section 8.14 of
   [I-D.ietf-ace-oauth-authz]. "application/ace+cbor".

   The payload of the 2.01 response is a CBOR map.  If the access token
   contains a role that requires the Client to send its own public key
   to the KDC when joining the group, the CBOR map MUST include the
   parameter 'kdcchallenge' defined in Section 3.3.2, specifying a
   dedicated challenge N_S generated by the KDC.  The Client uses this
   challenge to prove possession of its own private key (see the
   'client_cred_verify' parameter in Section 4).  Note that the payload
   format of the response deviates from the one defined in the ACE
   framework (see Section 5.8.1 5.10.1 of [I-D.ietf-ace-oauth-authz]), which
   has no payload.

   The KDC MUST store the 'kdcchallenge' value associated to the Client
   at least until it receives a join request from it (see Section 4.3),
   to be able to verify that the Client possesses its own private key.
   The same challenge MAY be reused several times by the Client, to
   generate a new proof of possession, e.g. in case of update of the
   public key, or to join a different group with a different signing
   key, so it is RECOMMENDED that the KDC keeps storing the
   'kdcchallenge' after the first join is processed as well.  If the KDC
   has already discarded the 'kdcchallenge', that will trigger an error
   response with a newly generated 'kdcchallenge' that the Client can
   use to restart the join process, as specified in Section 4.3.

   If 'sign_info' is included in the request, the KDC MAY include the
   'sign_info' parameter defined in Section 3.3.1, with the same
   encoding.  Note that the field 'id' takes the value of the group name
   for which the 'sign_info_entry' applies to.

   Note that the CBOR map specified as payload of the 2.01 (Created)
   response may include further parameters, e.g. according to the
   signalled transport profile of ACE.  Application profiles MAY define
   the additional parameters to use within this exchange (OPT2b). (OPT3).

   Application profiles of this specification MAY define alternative
   specific negotiations of parameter values for the signature algorithm
   and signature keys, if 'sign_info' is not used (OPT2a). (OPT2).

3.3.1.  'sign_info' Parameter

   The 'sign_info' parameter is an OPTIONAL parameter of the Token Post
   response message defined in Section 5.1.2. 5.10.1. of
   [I-D.ietf-ace-oauth-authz].  This parameter contains information and
   parameters about the signature algorithm and the public keys to be
   used between the Client and the RS.  Its exact content is application
   specific.

   In this specification and in application profiles building on it,
   this parameter is used to ask and retrieve from the KDC information
   about the signature algorithm and related parameters used in the
   group.

   When used in the request, the 'sign_info' encodes the CBOR simple
   value Null, to require information and parameters on the signature
   algorithm and on the public keys used.

   The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as
   in the request is given below.

      sign_info_req = nil

   The 'sign_info' parameter of the 2.01 (Created) response is a CBOR
   array of one or more elements.  The number of elements is at most the
   number of groups that the client has been authorized to join.  Each
   element contains information about signing parameters and keys for
   one or more group or topic, and is formatted as follows.

   *

   o  The first element 'id' is a group name or an array of group names
      for the group(s) names,
      associated to groups for which this information applies.  Below, the next four elements apply.  In
      the following, each specified group name is referred to as
      'gname'.

   *

   o  The second element 'sign_alg' is an integer or a text string if
      the POST request included the 'sign_info' parameter with value
      Null, and indicates the signature algorithm used in the group(s) groups
      identified by (the set of) 'gname'. the 'gname' values.  It is REQUIRED of the
      application profiles to define specific values that this parameter
      can take (REQ3), selected from the set of signing algorithms of
      the COSE Algorithms registry [COSE.Algorithms].

   *

   o  The third element 'sign_parameters' is a CBOR array indicating the
      parameters of the signature algorithm used in the group(s) groups
      identified by (the set of) 'gname'. the 'gname' values.  Its content depends on the
      value of 'sign_alg'.  It is REQUIRED of the application profiles
      to define the possible values and structure for the elements of
      this parameter (REQ4).

   *

   o  The fourth element 'sign_key_parameters' is a CBOR array
      indicating the parameters of the key used with the signature
      algorithm, in the group(s) groups identified by (the set of) 'gname'. the 'gname' values.  Its
      content depends on the value of 'sign_alg'.  It is REQUIRED of the
      application profiles to define the possible values and structure
      for the elements of this parameter (REQ5).

   *

   o  The fifth element 'pub_key_enc' parameter is either a CBOR integer
      indicating the encoding of public keys used in the group(s) groups
      identified by (the set of) 'gname', the 'gname' values, or has value Null indicating
      that the KDC does not act as repository of public keys for group
      members.  Its acceptable values are taken from the "CWT
      Confirmation Method" Registry defined in [RFC8747].  It is
      REQUIRED of the application profiles to define specific values to
      use for this parameter (REQ6).

   The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as
   in the response is given below.

      sign_info_res = [ + sign_info_entry ]

      sign_info_entry =
      [
        id : gname / [ + gname ],
        sign_alg : int / tstr,
        sign_parameters : [ any ],
        sign_key_parameters : [ any ],
        pub_key_enc = int / nil
      ]

      gname = tstr

3.3.2.  'kdcchallenge' Parameter

   The 'kdcchallenge' parameter is an OPTIONAL parameter of the Token
   Post response message defined in Section 5.8.1 5.10.1 of
   [I-D.ietf-ace-oauth-authz].  This parameter contains a challenge
   generated by the KDC and provided to the Client.  The Client may use
   this challenge to prove possession of its own private key in the
   Joining Request (see the 'client_cred_verify' parameter in
   Section 4).

4.  Keying Material Provisioning and Group Membership Management

   This section defines the interface available at the KDC.  Moreover,
   this section specifies how the clients can use this interface to join
   a group, leave a group, retrieve the group policies or the new group
   keying material.

   During the first exchange with the KDC ("Joining") after posting the
   Token, the Client sends a request to the KDC, specifying the group it
   wishes to join (see Section 4.3).  Then, the KDC verifies the access
   token and that the Client is authorized to join that group.  If so,
   it provides the Client with the keying material to securely
   communicate with the other members of the group.  Whenever used, the
   Content-Format in messages containing a payload is set to
   application/ace-groupcomm+cbor, as defined in Section 8.2.

   When the Client is already a group member, the Client can use the
   interface at the KDC to perform the following actions:

   *

   o  The Client can get the current keying material, for cases such as
      expiration, loss or suspected mismatch, due to e.g. reboot or
      missed group rekeying.  This is described in Section 4.4.

   *

   o  The Client can retrieve new keying material for itself.  This is
      described in Section 4.5.

   *

   o  The Client can get the public keys of other group members.  This
      is described in Section 4.6.

   *

   o  The Client can upload a new, updated public key at the KDC.  This
      is described in Section 4.7.

   *

   o  The Client can get the group policies.  This is described in
      Section 4.8.

   *

   o  The Client can get the version number of the keying material
      currently used in the group.  This is described in Section 4.9.

   *

   o  The Client can request to leave the group.  This is further
      discussed in Section 4.10.

   Upon receiving a request from a Client, the KDC MUST check that it is
   storing a valid access token from that Client for the group name
   associated to the endpoint.  If that is not the case, i.e. the KDC
   does not store a valid access token or this is not valid for that
   Client for the group name, the KDC MUST respond to the Client with a
   4.01 (Unauthorized) error message.

   If they include a payload and specify a Content-Format, requests sent
   to the KDC and success responses from the KDC MUST have Content-
   Format set to application/ace-groupcomm+cbor, defined in
   Section 10.2.

   Some error responses from the KDC can have Content-Format set to
   application/ace-groupcomm+cbor.  In such a case, the paylod of the
   response MUST be a CBOR map, which includes the following fields.

   o  'error', with value a CBOR integer specifying the error occurred
      at the KDC.  The value is taken from the "Value" column of the
      "ACE Groupcomm Errors" registry defined in Section 10.13 of this
      specification.  This field MUST be present.

   o  'error_description', with value a CBOR text string specifying a
      human-readable description of the error occurred at the KDC.  This
      field MAY be present.

   CBOR labels for the 'error' and 'error_description' fields are
   defined in Section 7.

   Section 8 of this specification defines an initial set of error
   identifiers, as possible values for the 'error' field.  Application
   profiles of this specification MAY define additional value (OPT12).

4.1.  Interface at the KDC

   The KDC is configured with the following resources.  Note that the
   root url-path "ace-group" given here are default names:
   implementations are not required to use these names, and can define
   their own instead.  Each application profile of this specification
   MUST register a Resource Type for the root url-path (REQ7a), (REQ7), and that
   Resource Type can be used to discover the correct url to access at
   the KDC.  This Resource Type can also be used at the GROUPNAME sub-
   resource, to indicate different application profiles for different
   groups.  The Interface Description (if=) Link Target Attribute value
   ace.group is registered (Section 8.10) 10.10) and can be used to describe
   this interface.

   *

   o  /ace-group: this resource is invariant once established and
      indicates that this specification is used.  If other applications
      run on a KDC implementing this specification and use this same
      resource, these applications will collide, and a mechanism will be
      needed to differentiate the endpoints.  This resource supports the
      FETCH method.

   *

   o  /ace-group/GROUPNAME: one sub-resource to /ace-group is
      implemented for each group the KDC manages.

      If the value of the GROUPNAME URI path and the group name in the
      access token scope ('gname' in Section 3.2) do not match, the KDC
      MUST implement a mechanism to map the GROUPNAME value in the URI
      to the group name, in order to retrieve the right group (REQ1).
      Each resource contains the symmetric group keying material for
      that group.  These resources support the GET and POST methods.

   *

   o  /ace-group/GROUPNAME/pub-key: this resource is invariant once
      established and contains the public keys of all group members.
      This resource supports the GET and FETCH methods.

   *

   o  /ace-group/GROUPNAME/policies: this resource is invariant once
      established and contains the group policies.  This resource
      supports the GET method.

   *

   o  /ace-group/GROUPNAME/num: this resource is invariant once
      established and contains the version number for the symmetric
      group keying material.  This sub-resource supports the GET method.

   *

   o  /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace-
      group/GROUPNAME is implemented for each node in the group the KDC
      manages.  These resources are identified by the node name (in this
      example, the node name has value "NODENAME").  Each resource
      contains the group and individual keying material for that node.
      These resources support the GET, PUT and DELETE methods.

   *

   o  /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one sub-resource to
      /ace-group/GROUPNAME/nodes/NODENAME is implemented for each node
      in the group the KDC manages.  These resources are identified by
      the node name (in this example, the node name has value
      "NODENAME").  Each resource contains the individual public keying
      material for that node.  These resources support the POST method.

   It is REQUIRED of the application profiles of this specification to
   define what operations (i.e. (e.g.  CoAP methods) are allowed on each
   resource, for each role defined in Section 3.1 according to REQ2
   (REQ7aa).
   (REQ8).

   The details for the handlers of each resource are given in the
   following sections.  These endpoints are used to perform the
   operations introduced in Section 4.

4.1.1.  ace-group

   This resource implements a FETCH handler.

4.1.1.1.  FETCH Handler

   The FETCH handler receives group identifiers and returns the
   corresponding group names and GROUPNAME URIs.

   The handler expects a request with payload formatted as a CBOR map.
   The payload of this request is a CBOR Map that map,
   which MUST contain the following fields:

   *

   o  'gid', whose value is encoded as a CBOR array, containing one or
      more group identifiers.  The exact encoding of group identifier
      MUST be specified by the application profile (REQ7b). (REQ9).  The Client
      indicates that it wishes to receive the group names and GROUPNAMEs
      of all groups having these identifiers.

   The handler identifies the groups that are secured by the keying
   material identified by those group identifiers.

   Then, the handler returns a 2.05 (Content) message response with
   payload formatted as a CBOR map that MUST contain the following
   fields:

   *

   o  'gid', whose value is encoded as a CBOR array, containing zero or
      more group identifiers.  The handler indicates that those are the
      identifiers it is sending group names and GROUPNAMEs for.  This
      CBOR array is a subset of the 'gid' array in the FETCH request.

   *

   o  'gname', whose value is encoded as a CBOR array, containing zero
      or more group names.  The elements of this array are encoded as
      text strings.  Each element of index i of this CBOR array
      corresponds to the element of group identifier i in the 'gid'
      array.

   *

   o  'guri', whose value is encoded as a CBOR array, containing zero or
      more URIs, each indicating a GROUPNAME resource.  The elements of
      this array are encoded as text strings.  Each element of index i
      of this CBOR array corresponds to the element of group identifier
      i in the 'gid' array.

   If the KDC does not find any group associated with the specified
   group identifiers, the handler returns a response with payload
   formatted as a CBOR byte string of zero length.

   Note that the KDC only verifies that the node is authorized by the AS
   to access this resource.  Nodes that are not members of the group but
   are authorized to do signature verifications verification on the group messages may
   be allowed to access this resource, if the application needs it.

4.1.2.  ace-group/GROUPNAME

   This resource implements GET and POST handlers.

4.1.2.1.  POST Handler

   The POST handler adds the public key of the client to the list of the
   group members' public keys and returns the symmetric group keying
   material for the group identified by "GROUPNAME".  Note that the
   group joining exchange is done by the client via this operation, as
   described in Section 4.3.

   The handler expects a request with payload formatted as a CBOR map map,
   which MAY contain the following fields, which, if included, MUST have
   the corresponding values:

   *

   o  'scope', with value the specific resource at the KDC that the
      Client is authorized to access, i.e. group or topic name, and
      role(s).  This value is a CBOR byte string wrapping one scope
      entry, as defined in Section 3.1.

   *

   o  'get_pub_keys', if the Client wishes to receive the public keys of
      the other nodes in the group from the KDC.  This parameter may be
      present if the KDC stores the public keys of the nodes in the
      group and distributes them to the Client; it is useless to have
      here if the set of public keys of the members of the group is
      known in another way, e.g. it was provided by the AS.  Note that
      including this parameter may result in a large message size for
      the following response, which can be inconvenient for resource-
      constrained devices.

      The parameter's value is either the CBOR simple value Null Null, or a
      non-empty CBOR array containing two CBOR
      arrays:

      - the following three elements.

      *  The first array element, namely 'inclusion_flag', encodes the CBOR
         simple value True.

      *  The second element, namely 'role_filter', is non-empty. a non-empty CBOR
         array.  Each element of the first array contains one role or a
         combination of roles for the group identified by "GROUPNAME".
         The Client indicates that it wishes to receive the public keys
         of all group members having any of the single roles, or at
         least all of the roles indicated in any
         combinations combination of roles.
         For example, the array ["role1", "role2+role3"] indicates that
         the Client wishes to receive the public keys of all group
         members that have at least "role1" or at least both "role2" and
         "role3".

      -

      *  The second array third element, namely 'id_filter', is empty. an empty CBOR array.

      If the Client wishes to receive all public keys of all group
      members, it encodes the 'get_pub_key' parameter as the CBOR simple
      value Null.

      The CDDL definition [RFC8610] of 'get_pub_keys' is given in
      Figure 6, using as example encoding: node identifier encoded as a
      CBOR byte string; role identifier encoded as a CBOR text string,
      and combination of roles encoded as a CBOR array of roles.

      Note that the second array (array of roles 'role_filter' is non-empty for this
      handler, but this is not necessarily the case for other handlers
      using this parameter: if this array is empty, it means that the
      client is not filtering public keys based on roles.

      Also note that the array of node identifiers) identifiers 'id_filter' is empty
      for this handler, because the joining node is not expected or
      capable to express a filter based on node identifiers, but identifiers at this
      point in time.  Consistently, the 'inclusion_flag' element is set
      to the CBOR simple value True.  However, the 'id_filter' array is
      not necessarily empty for the value of 'get_pub_keys' received by
      the handler of FETCH to ace-group/GROUPNAME/pub-key (see
      Section 4.1.3.1).

      Also note that the second array (array of roles) is non-empty for
      this handler, but that is not necessarily the case for other
      handlers using this parameter: if this array is empty it means
      that the client is not filtering public keys based on roles.

      Finally, the 'get_pub_keys' is never used as an array containing two
      empty parameter MUST NOT have the arrays (in
      'role_filter' and 'id_filter' as both empty, i.e. in CBOR
      diagnostic notation: [ bool, [ ], [ ] ] ), so ].  Thus, if this parameter
      is received as formatted in that way, it has to be considered
      malformed.

   id = bstr

   role = tstr

   comb_role = [ 2*role ]

   inclusion = bool

   get_pub_keys = null / [ [ inclusion, *(role / comb_role) ], [ *id ] ]

     Figure 6: CDLL definition of get_pub_keys, using as example node
                identifier encoded as bstr and role as tstr

   *

   o  'client_cred', with value the public key or certificate of the
      Client, encoded as a CBOR byte string.  This field contains the
      public key of the Client.  This field is used if the KDC is
      managing (collecting from/distributing to the Client) the public
      keys of the group members, and if the Client's role in the group
      will require for it to send messages to one or more group members.
      The default encoding for public keys is COSE Keys.  Alternative
      specific encodings of this parameter MAY be defined in
      applications of this specification (OPT1 in Appendix A).

   *

   o  'cnonce', encoded as a CBOR byte string, and including a dedicated
      nonce N_C generated by the Client.  This parameter MUST be present
      if the 'client_cred' parameter is present.

   *

   o  'client_cred_verify', encoded as a CBOR byte string.  This
      parameter MUST be present if the 'client_cred' parameter is
      present and no public key associated to the client's token can be
      retrieved for that group.  This parameter contains a signature
      computed by the Client over the following signature input: the
      scope (encoded as CBOR byte string), concatenated with N_S
      (encoded as CBOR byte string) concatenated with N_C (encoded as
      CBOR byte string), where:

      -

      *  scope is the CBOR byte string either specified in the 'scope'
         parameter above, if present, or as a default scope that the
         handler is expected to understand, if omitted.

      -

      *  N_S is the challenge received from the KDC in the
         'kdcchallenge' parameter of the 2.01 (Created) response to the
         token POST request (see Section 3.3), encoded as a CBOR byte
         string.

      -

      *  N_C is the nonce generated by the Client and specified in the
         'cnonce' parameter above, encoded as a CBOR byte string.

      An example of signature input construction to compute
      'client_cred_verify' using CBOR encoding is given in Figure 7.

      If the token was not posted (e.g. if it is used directly to
      validate TLS instead), it is REQUIRED of the specific profile to
      define how the challenge N_S is generated (REQ17). (REQ20).  The Client
      computes the signature by using its own private key, whose
      corresponding public key is either directly specified in the
      'client_cred' parameter or included in the certificate specified
      in the 'client_cred' parameter.

   *

   o  'pub_keys_repos', can be present if a certificate is present in
      the 'client_cred' field, with value the URI of the certificate of
      the Client.  This parameter is encoded as a CBOR text string.
      Alternative specific encodings of this parameter MAY be defined in
      applications of this specification (OPT3).

   *  'control_path', (OPT4).

   o  'control_uri', with value a full URI, encoded as a CBOR text
      string.  If 'control_path' 'control_uri' is supported by the Client, the Client
      acts as a CoAP server and hosts a resource at this specific URI.
      The KDC MAY use this URI to send CoAP requests to the Client
      (acting as CoAP server in this exchange), for example for
      individual provisioning of new keying material when performing a
      group rekeying (see Section 4.4), or to inform the Client of its
      removal from the group Section 5.  If the KDC does not implement
      mechanisms using this resource, it can just ignore this parameter.
      Other additional functionalities of this resource MAY be defined
      in application profiles of this specifications (OPT9). (OPT10).  In
      particular, this resource is intended for communications
      concerning exclusively the group or topic specified in the 'scope'
      parameter.

        scope, N_S, and N_C expressed in CBOR diagnostic notation:
              scope = h'826667726F7570316673656E646572'
              N_S = h'018a278f7faab55a'
              N_C = h'25a8991cd700ac01'

        scope, N_S, and N_C  as CBOR encoded byte strings:
              scope = 0x4f826667726F7570316673656E646572
              N_S = 0x48018a278f7faab55a
              N_C = 0x4825a8991cd700ac01

        input to client_cred_verify signature =
          0x4f 826667726F7570316673656E646572
            48 018a278f7faab55a 48 25a8991cd700ac01

       Figure 7: Example of signature input construction to compute
                 'client_cred_verify' using CBOR encoding

   The handler extracts the granted scope from the access token, and
   checks the requested one against the token one.  If the requested one
   is not a subset of the token one, the KDC MUST respond with a 4.01
   (Unauthorized) error message.

   If this join message the request does not include a 'scope' field, the KDC is expected
   to understand which group and role(s) the Client is requesting (e.g.
   there is only one the Client has been granted).  If the KDC can not
   recognize which scope the Client is requesting, it MUST respond with
   a 4.00 (Bad Request) error message.

   The KDC verifies that the group name of the /ace-group/GROUPNAME path
   is a subset of the 'scope' stored in the access token associated to
   this client.  The KDC also verifies that the roles the client is
   granted in the group allow it to perform this operation on this
   resource (REQ7aa). (REQ8).  If either verification fails, the KDC MUST respond
   with a 4.01 (Unauthorized) error message.  The KDC  This response MAY
   respond with be an AS
   Request Creation Hints, as defined in Section 5.1.2 5.3 of [I-D.ietf-ace-oauth-authz].  Note that
   [I-D.ietf-ace-oauth-authz], in this case, which case the content format MUST be
   set to application/ace+cbor.

   If the request is not formatted correctly (i.e. required fields non
   received or received with incorrect format), the handler MUST respond
   with a 4.00 (Bad Request) error message.  The response MAY contain have
   Content-Format set to application/ace+cbor and have a CBOR map in as
   payload.  For instance, the CBOR map can include the payload with content format application/ace+cbor,
   e.g. it could send back 'sign_info_res'
   parameter, with 'pub_key_enc' set to Null if the Client sent its own
   public key and the KDC is not set to store public keys of the group
   members.

   If the request contained unknown or non-expected fields present, the
   handler MUST silently drop them and continue processing.  Application
   profiles MAY define optional or mandatory payload formats for
   specific error cases
   (OPT6). (OPT7).

   If the KDC stores the group members' public keys, the handler checks
   if one is included in the 'client_cred' field, retrieves it and
   associates it to the access token received, after verifications
   succeeded.  In particular, the KDC verifies:

   *

   o  that such public key has an acceptable format for the group
      identified by "GROUPNAME", i.e. it is encoded as expected and is
      compatible with the signature algorithm and possible associated
      parameters.

   *

   o  that the signature contained in "client_cred_verify" passes
      verification.

   If that cannot be verified, it is RECOMMENDED that the handler stops
   the process and responds with a 4.00 (Bad Request) error message.
   Applications profiles MAY define alternatives (OPT5). (OPT6).

   If one public key is already associated to the access token and to
   that group, but the 'client_cred' is populated with a different
   public key, the handler MUST delete the previous one and replace it
   with this one, after verifying the points above.

   If no public key is included in the 'client_cred' field, the handler
   checks if one public key is already associated to the access token
   received (see Section 4.3 for an example) and to the group identified
   by "GROUPNAME".  If that is not the case, the handler responds with a
   4.00 Bad Request error response.

   If the token was posted but the KDC cannot retrieve the
   'kdcchallenge' associated to this Client (see Section 3.3), the KDC
   MUST respond with a 4.00 Bad Request error response, including a
   newly generated 'kdcchallenge' in a CBOR map in the payload.  This
   error response MUST also have Content-Format application/ace+cbor.

   If all verifications succeed, the handler:

   *

   o  Adds the node to the list of current members of the group.

   *

   o  Assigns a name NODENAME to the node, and creates a sub-resource to
      /ace-group/GROUPNAME/ at the KDC (e.g. "/ace-
      group/GROUPNAME/nodes/NODENAME").

   *

   o  Associates the identifier "NODENAME" with the access token and the
      secure session for that node.

   *

   o  If the KDC manages public keys for group members:

      -

      *  Adds the retrieved public key of the node to the list of public
         keys stored for the group identified by "GROUPNAME"

      -

      *  Associates the node's public key with its access token and the
         group identified by "GROUPNAME", if such association did not
         already exist.

   *

   o  Returns a 2.01 (Created) message containing the symmetric group
      keying material, the group policies and all the public keys of the
      current members of the group, if the KDC manages those and the
      Client requested them.

   The response message also contains the URI path to the sub-resource
   created for that node in a Location-Path CoAP option.  The payload of
   the response is formatted as a CBOR map which MUST contain the
   following fields and values:

   *

   o  'gkty', identifying the key type of the 'key' parameter.  The set
      of values can be found in the "Key Type" column of the "ACE
      Groupcomm Key" Registry.  Implementations MUST verify that the key
      type matches the application profile being used, if present, as
      registered in the "ACE Groupcomm Key" registry.

   *

   o  'key', containing the keying material for the group communication,
      or information required to derive it.

   *

   o  'num', containing the version number of the keying material for
      the group communication, formatted as an integer.  This is a
      strictly monotonic increasing field.  The application profile MUST
      define the initial version number (REQ19). (REQ22).

   The exact format of the 'key' value MUST be defined in applications
   of this specification (REQ7), (REQ10), as well as values of 'gkty' accepted
   by the application (REQ8). (REQ11).  Additionally, documents specifying the
   key format MUST register it in the "ACE Groupcomm Key" registry
   defined in Section 8.6, 10.6, including its name, type and application
   profile to be used with.

     +----------+----------------+---------+-------------------------+
     | Name     | Key Type Value | Profile | Description             |
     +----------+----------------+---------+-------------------------+
     | Reserved | 0              |         | This value is reserved  |
     +----------+----------------+---------+-------------------------+

                         Figure 8: Key Type Values

   The response SHOULD contain the following parameter:

   *

   o  'exp', with value the expiration time of the keying material for
      the group communication, encoded as a CBOR unsigned integer.  This
      field contains a numeric value representing the number of seconds
      from 1970-01-01T00:00:00Z UTC until the specified UTC date/time,
      ignoring leap seconds, analogous to what specified for NumericDate
      in Section 2 of [RFC7519].  Group members MUST stop using the
      keying material to protect outgoing messages and retrieve new
      keying material at the time indicated in this field.

   Optionally, the response MAY contain the following parameters, which,
   if included, MUST have the corresponding values:

   *

   o  'ace-groupcomm-profile', with value a CBOR integer that MUST be
      used to uniquely identify the application profile for group
      communication.  Applications of this specification MUST register
      an application profile identifier and the related value for this
      parameter in the "ACE Groupcomm Profile" Registry (REQ12).

   * (REQ15).

   o  'pub_keys', may only MUST be present if 'get_pub_keys' was present in the request.
      request, otherwise it MUST NOT be present.  This parameter is a
      CBOR byte string, which encodes the public keys of all the group
      members paired with the respective member identifiers.  The
      default encoding for public keys is COSE Keys, so the default
      encoding for 'pub_keys' is a CBOR byte string wrapping a
      COSE_KeySet (see [I-D.ietf-cose-rfc8152bis-struct]), which
      contains the public keys of all the members of the group.  In
      particular, each COSE Key in the COSE_KeySet includes the node
      identifier of the corresponding group member as value of its 'kid'
      key parameter.  Alternative specific encodings of this parameter
      MAY be defined in applications of this specification (OPT1).  The
      specific format of the node identifiers of group members MUST be
      specified in the application profile (REQ9).

   * (REQ12).

   o  'peer_roles', MUST be present if 'pub_keys' is also present,
      otherwise it MUST NOT be present.  This parameter is a CBOR array
      of n elements, with n the number of public keys included in the
      'pub_keys' parameter (at most the number of members in the group).
      The i-th element of the array specifies the role (or CBOR array of
      roles) that the group member associated to the i-th public key in
      'pub_keys' has in the group.  In particular, each array element is
      encoded as the role element of a scope entry, as defined in
      Section 3.1.

   *

   o  'peer_identifiers', MUST be present if 'pub_keys' is also present
      and, at the same time, the used encoding for public keys does not
      allow to specify a node identifier within the associated public
      key.  Otherwise, it MUST NOT be present.  This parameter is a CBOR
      array of n elements, with n the number of public keys included in
      the 'pub_keys' parameter (at most the number of members in the
      group).  The i-th element of the array specifies the node
      identifier that the group member associated to the i-th public key
      in 'pub_keys' has in the group.  In particular, the i-th array
      element is encoded as a CBOR byte string wrapping the node
      identifier of the group member.

   o  'group_policies', with value a CBOR map, whose entries specify how
      the group handles specific management aspects.  These include, for
      instance, approaches to achieve synchronization of sequence
      numbers among group members.  The elements of this field are
      registered in the "ACE Groupcomm Policy" Registry.  This
      specification defines the three elements "Sequence Number
      Synchronization Method", "Key Update Check Interval" and
      "Expiration Delta", which are summarized in Figure 9.  Application
      profiles that build on this document MUST specify the exact
      content format and default value of included map entries (REQ14). (REQ17).

  +--------------+-------+----------|---------------------|------------+
  |      Name    | CBOR  |   CBOR   |    Description      | Reference  |
  |              | label |   type   |                     |            |
  |--------------+-------+----------|---------------------|------------|
  | Sequence     | TBD1  | tstr/int | Method for a re-    | [[this     |
  | Number       |       |          | cipient node to     | document]] |
  | Synchroniza- |       |          | synchronize with    |            |
  | tion Method  |       |          | sequence numbers    |            |
  |              |       |          | of a sender node.   |            |
  |              |       |          | Its value is taken  |            |
  |              |       |          | from the 'Value'    |            |
  |              |       |          | column of the       |            |
  |              |       |          | Sequence Number     |            |
  |              |       |          | Synchronization     |            |
  |              |       |          | Method registry     |            |
  |              |       |          |                     |            |
  | Key Update   | TBD2  |   int    | Polling interval    | [[this     |
  | Check        |       |          | in seconds, to      | document]] |
  | Interval     |       |          | check for new       |            |
  |              |       |          | keying material at  |            |
  |              |       |          | the KDC             |            |
  |              |       |          |                     |            |
  | Expiration   | TBD3  |   uint   | Number of seconds   | [[this     |
  | Delta        |       |          | from 'exp' until    | document]] |
  |              |       |          | the specified UTC   |            |
  |              |       |          | date/time after     |            |
  |              |       |          | which group members |            |
  |              |       |          | MUST stop using the |            |
  |              |       |          | keying material to  |            |
  |              |       |          | verify incoming     |            |
  |              |       |          | messages.           |            |
  +--------------+-------+----------|---------------------|------------+

                     Figure 9: ACE Groupcomm Policies

   *

   o  'mgt_key_material', encoded as a CBOR byte string and containing
      the administrative keying material to participate in the group
      rekeying performed by the KDC.  The application profile MUST
      define if this field is used, and if used then MUST specify the
      exact format and content which depend on the specific rekeying
      scheme used in the group.  If the usage of 'mgt_key_material' is
      indicated and its format defined for a specific key management
      scheme, that format must explicitly indicate the key management
      scheme itself.  If a new rekeying scheme is defined to be used for
      an existing 'mgt_key_material' in an existing profile, then that
      profile will have to be updated accordingly, especially with
      respect to the usage of 'mgt_key_material' related format and
      content (REQ18). (REQ21).

   Specific application profiles that build on this document MUST
   specify the communication protocol that members of the group use to
   communicate with each other (REQ10) (REQ13) and how exactly the keying
   material is used to protect the group communication (REQ11). (REQ14).

   CBOR labels for these fields are defined in Section 6. 7.

4.1.2.2.  GET Handler

   The GET handler returns the symmetric group keying material for the
   group identified by "GROUPNAME".

   The handler expects a GET request.

   The KDC verifies that the group name of the /ace-group/GROUPNAME path
   is a subset of the 'scope' stored in the access token associated to
   this client.  The KDC also verifies that the roles the client is
   granted in the group allow it to perform this operation on this
   resource (REQ7aa). (REQ8).  If either verification fails, the KDC MUST respond
   with a 4.01 (Unauthorized) error message.  The KDC  This response MAY
   respond with be an AS
   Request Creation Hints, as defined in Section 5.1.2 5.3 of [I-D.ietf-ace-oauth-authz].  Note that
   [I-D.ietf-ace-oauth-authz], in this which case the content format MUST be
   set to application/ace+cbor.

   Additionally, the handler verifies that the node is a current member
   of the group.  If verification fails, the KDC MUST respond with a
   4.01 (Unauthorized) error message.  The response MUST have Content-
   Format set to application/ace-groupcomm+cbor and is formatted as
   defined in Section 4.  The value of the 'error' field MUST be set to
   0 ("Operation permitted only to group members").

   If verification succeeds, the handler returns a 2.05 (Content)
   message containing the symmetric group keying material.  The payload
   of the response is formatted as a CBOR map which MUST contain the
   parameters 'gkty', 'key' and 'num' specified in Section 4.1.2.1.

   The payload MAY also include the parameters 'ace-groupcomm-profile',
   'exp', and 'mgt_key_material' parameters specified in
   Section 4.1.2.1.

4.1.3.  ace-group/GROUPNAME/pub-key

   If the KDC does not maintain public keys for the group, the handler
   for any request on this resource returns a 4.05 (Method Not Allowed)
   error message.  If it does, the rest of this section applies.

   This resource implements GET and FETCH handlers.

4.1.3.1.  FETCH Handler

   The FETCH handler receives identifiers of group members for the group
   identified by "GROUPNAME" and returns the public keys of such group
   members.

   The handler expects a request with payload formatted as a CBOR map,
   that MUST contain the following fields:

   *

   o  'get_pub_keys', whose value is encoded as in Section 4.1.2.1 with
      the following modification:

      -

      *  The first array may be empty, element 'inclusion_flag' encodes the CBOR simple value True
         if the third element 'id_filter' specifies an empty CBOR array,
         or if the Client does not wish wishes to
         filter receive the requested public keys of the nodes
         having their node identifier specified in 'id_filter'.
         Instead, this element encodes the CBOR simple value False if
         the Client wishes to receive the public keys of the nodes not
         having the node identifiers specified in the third element
         'id_filter'.

      *  The array 'role_filter' may be empty, if the Client does not
         wish to filter the requested public keys based on the roles of
         the group members.

      -

      *  The second array 'id_filter' contains zero or more node identifiers of
         group members, for the group identified by "GROUPNAME".  The
         Client indicates that it wishes to receive the public keys of
         all
         the nodes having or not having these node identifiers.

      As mentioned, identifiers, in case
         the 'inclusion_flag' parameter encodes the CBOR simple value
         True or False, respectively.  The array may be empty, if the
         Client does not wish to filter the requested public keys based
         on the node identifiers of the group members.

   Note that, in case both arrays can the 'role_filter' array and the 'id_filter'
   array are not be empty empty:

   o  If the 'inclusion_flag' encodes the CBOR simple value True, the
      handler returns the public keys of group members whose roles match
      with 'role_filter' and/or having their node identifier specified
      in 'id_filter'.

   o  If the 'inclusion_flag' encodes the CBOR simple value False, the
      handler returns the public keys of group members whose roles match
      with 'role_filter' and, at the same time. time, not having their node
      identifier specified in 'id_filter'.

   Finally, as mentioned in Section 4.1.2.1, both arrays 'role_filter'
   and 'id_filter' MUST NOT be both empty.

   The specific format of public keys as well as identifiers, roles and
   combination of roles of group members MUST be specified by the
   application profile (OPT1, REQ2, REQ9). REQ12).

   The KDC verifies that the group name of the /ace-group/GROUPNAME path
   is a subset of the 'scope' stored in the access token associated to
   this client.  The KDC also verifies that the roles the client is
   granted in the group allow it to perform this operation on this
   resource (REQ7aa). (REQ8).  If either verification fails, the KDC MUST respond
   with a 4.01 (Unauthorized) error message.

   If verification succeeds, the handler identifies the public keys of
   the current group members for which either:

   *

   o  the role identifier matches with one of those indicated in the
      request; note that the request can contain a "combination of
      roles", where the handler select all group members who have all
      roles included in the combination.

   *

   o  the node identifier matches with one of those indicated in the
      request.

   Then, the handler returns a 2.05 (Content) message response with
   payload formatted as a CBOR map, containing only the 'pub_keys' and
   'peer_roles' parameters from Section 4.1.2.1.  In particular,
   'pub_keys' encodes the list of public keys of those group members
   including the respective member identifiers, while 'peer_roles'
   encodes their respective role (or CBOR array of roles) in the group.
   The specific format of public keys as well as of node identifiers of
   group members is specified by the application profile (OPT1, REQ9). REQ12).

   If the used encoding for public keys does not allow to specify a node
   identifier within the associated public key, the response payload
   MUST include also the 'peer_identifiers' parameter from
   Section 4.1.2.1.  Otherwise, this parameter MUST NOT be included.

   If the KDC does not store any public key associated with the
   specified node identifiers, the handler returns a response with
   payload formatted as a CBOR byte string of zero length.

   The handler MAY enforce one of the following policies, in order to
   handle possible node identifiers that are included in the 'id_filter'
   element of the 'get_pub_keys' parameter of the request but are not
   associated to any current group member.  Such a policy MUST be
   specified by the application profile (REQ13).

   * (REQ16).

   o  The KDC silently ignores those node identifiers.

   *

   o  The KDC retains public keys of group members for a given amount of
      time after their leaving, before discarding them.  As long as such
      public keys are retained, the KDC provides them to a requesting
      Client.

   Note that this resource handler only verifies that the node is
   authorized by the AS to access this resource.  Nodes that are not
   members of the group but are authorized to do signature verifications
   on the group messages may be allowed to access this resource, if the
   application needs it.

4.1.3.2.  GET Handler

   The handler expects a GET request.

   The KDC performs the same verifications as the FETCH handler in
   Section 4.1.3.1, and if successful returns the same response as in
   Section 4.1.3.1 but without filtering based on roles or node
   identifiers: all the group members' public keys are returned.

   Note that this resource handler, as the FETCH handler for the same
   resource, only verifies that the node is authorized by the AS to
   access this resource.  Nodes that are not members of the group but
   are authorized to do signature verifications on the group messages
   may be allowed to access this resource, if the application needs it.

4.1.4.  ace-group/GROUPNAME/policies

   This resource implements a GET handler.

4.1.4.1.  GET Handler

   The handler expects a GET request.

   The KDC verifies that the group name of the /ace-group/GROUPNAME path
   is a subset of the 'scope' stored in the access token associated to
   this client.  The KDC also verifies that the roles the client is
   granted in the group allow it to perform this operation on this
   resource (REQ7aa). (REQ8).  If either verification fails, the KDC MUST respond
   with a 4.01 (Unauthorized) error message.

   Additionally, the handler verifies that the node is a current member
   of the group.  If verification fails, the KDC MUST respond with a
   4.01 (Unauthorized) error message.

   If verification succeeds, the handler returns a 2.05 (Content)
   message containing the list of policies for the group identified  The response MUST have Content-
   Format set to application/ace-groupcomm+cbor and is formatted as
   defined in Section 4.  The value of the 'error' field MUST be set to
   0 ("Operation permitted only to group members").

   If verification succeeds, the handler returns a 2.05 (Content)
   message containing the list of policies for the group identified by
   "GROUPNAME".  The payload of the response is formatted as a CBOR map
   including only the parameter 'group_policies' defined in
   Section 4.1.2.1 and specifying the current policies in the group.  If
   the KDC does not store any policy, the payload is formatted as a
   zero-length CBOR byte string.

   The specific format and meaning of group policies MUST be specified
   in the application profile (REQ14). (REQ17).

4.1.5.  ace-group/GROUPNAME/num

   This resource implements a GET handler.

4.1.5.1.  GET Handler

   The handler expects a GET request.

   The KDC verifies that the group name of the /ace-group/GROUPNAME path
   is a subset of the 'scope' stored in the access token associated to
   this client.  The KDC also verifies that the roles the client is
   granted in the group allow it to perform this operation on this
   resource (REQ7aa). (REQ8).  If either verification fails, the KDC MUST respond
   with a 4.01 (Unauthorized) error message.

   Additionally, the handler verifies that the node is a current member
   of the group.  If verification fails, the KDC MUST respond with a
   4.01 (Unauthorized) error message.  The response MUST have Content-
   Format set to application/ace-groupcomm+cbor and is formatted as
   defined in Section 4.  The value of the 'error' field MUST be set to
   0 ("Operation permitted only to group members").

   If verification succeeds, the handler returns a 2.05 (Content)
   message containing an integer that represents the version number of
   the symmetric group keying material.  This number is incremented on
   the KDC every time the KDC updates the symmetric group keying
   material, before the new keying material is distributed.  This number
   is stored in persistent storage.

   The payload of the response is formatted as a CBOR integer.

4.1.6.  ace-group/GROUPNAME/nodes/NODENAME

   This resource implements GET, PUT and DELETE handlers.

4.1.6.1.  PUT Handler

   The PUT handler is used to get the KDC to produce and return
   individual keying material to protect outgoing messages for the node
   (identified by "NODENAME") for the group identified by "GROUPNAME".
   Application profiles MAY also use this handler to rekey the whole
   group.  It is up to the application profiles to specify if this
   handler supports renewal of individual keying material, renewal of
   the group keying material or both (OPT8). (OPT9).

   The handler expects a request with empty payload.  In case the
   request has a non-empty payload, the KDC MUST respond with a 4.00
   (Bad Request) error message.

   The KDC verifies that the group name of the /ace-group/GROUPNAME path
   is a subset of the 'scope' stored in the access token associated to
   this client,
   the client identified by "NODENAME".  The KDC also verifies that the
   roles the client is granted in the group allow it to perform this
   operation on this resource (REQ7aa). (REQ8).  If either verification fails, the
   KDC MUST respond with a 4.01 (Unauthorized) error message.

   The handler also verifies that the node sending the request and the
   node name used in the Uri-Path match.  If that is not the case, the
   handler responds with a 4.01 (Unauthorized) error response.

   Additionally, the handler verifies that the node is a current member
   of the group.  If the verification fails, the KDC MUST respond with a
   4.01 (Unauthorized) error message.

   If verification succeeds, the handler returns a 2.05 (Content)
   message containing newly-generated keying material for the Client,
   and/or, if the application profiles requires it (OPT8), starts the
   complete group rekeying.  The payload of the response MUST have Content-
   Format set to application/ace-groupcomm+cbor and is formatted as
   a CBOR map.
   defined in Section 4.  The specific format of newly-generated individual keying
   material for group members, or value of the information to derive it, and
   corresponding CBOR label, 'error' field MUST be specified in set to
   0 ("Operation permitted only to group members").

   Also, the application
   profile (REQ15) and registered in Section 8.5.

4.1.6.2.  GET Handler

   The handler expects a GET request.

   The KDC verifies that the group name of the /ace-group/GROUPNAME path this operation is a subset consistent with the
   set of roles that the 'scope' stored node has in the access token associated to
   this client, identified by "NODENAME".  The KDC also verifies that
   the roles the client is granted in the group allow it to perform this
   operation on this resource (REQ7aa). group.  If either the verification
   fails, the KDC MUST respond with a 4.01 (Unauthorized) 4.00 (Bad Request) error message.
   The handler also verifies that the node sending the request response MUST have Content-Format set to application/ace-
   groupcomm+cbor and the
   node name used in the Uri-Path match.  If that is not the case, formatted as defined in Section 4.  The value
   of the
   handler responds 'error' field MUST be set to 1 ("Request inconsistent with a 4.01 (Unauthorized) error response.

   Additionally, the handler verifies that
   current roles").

   If the node KDC is a current member
   of currently not able to serve this request, i.e. to
   generate new individual keying material for the group.  If verification fails, requesting client,
   the KDC MUST respond with a
   4.01 (Unauthorized) 5.03 (Service Unavailable) error message.
   The response MUST have Content-Format set to application/ace-
   groupcomm+cbor and is formatted as defined in Section 4.  The value
   of the 'error' field MUST be set to 4 ("No available node
   identifiers").

   If verification succeeds, all verifications succeed, the handler returns a 2.05 (Content)
   message containing both the group keying material and the individual newly-generated keying material for the Client, or information enabling
   and/or, if the Client to
   derive it. application profiles requires it (OPT9), starts the
   complete group rekeying.  The payload of the response is formatted as
   a CBOR map.  The format for the group keying material is the same as defined in
   the response of Section 4.1.2.2.  The specific format of newly-generated individual keying
   material for group members, or of the information to derive it, and
   corresponding CBOR label, MUST be specified in the application
   profile (REQ15) (REQ18) and registered in Section 8.5.

4.1.6.3.  DELETE 10.5.

4.1.6.2.  GET Handler

   The DELETE handler removes the node identified by "NODENAME" from the
   group identified by "GROUPNAME".

   The handler expects a request with method DELETE (and empty payload). GET request.

   The handler KDC verifies that the group name of the /ace-group/GROUPNAME path
   is a subset of the 'scope' stored in the access token associated to this client,
   the client identified by "NODENAME".  The KDC also verifies that the
   roles the client is granted in the group allow it to perform this
   operation on this resource (REQ7aa). (REQ8).  If either verification fails, the
   KDC MUST respond with a 4.01 (Unauthorized) error message.

   The handler also verifies that the node sending the request and the
   node name used in the Uri-Path match.  If that is not the case, the
   handler responds with a 4.01 (Unauthorized) error response.

   Additionally, the handler verifies that the node is a current member
   of the group.  If verification fails, the KDC MUST respond with a
   4.01 (Unauthorized) error message.

   If verification succeeds, the handler removes the client from the
   group identified by "GROUPNAME", for specific roles if roles were
   specified  The response MUST have Content-
   Format set to application/ace-groupcomm+cbor and is formatted as
   defined in the 'scope' field, or for all roles.  That includes
   removing the public key Section 4.  The value of the client if the KDC keep tracks of that.
   Then, 'error' field MUST be set to
   0 ("Operation permitted only to group members").

   If verification succeeds, the handler delete the sub-resource nodes/NODENAME and returns a 2.02 (Deleted) 2.05 (Content)
   message with empty payload.

4.1.7.  ace-group/GROUPNAME/nodes/NODENAME/pub-key

   This resource implements a POST handler, if the KDC stores containing both the public
   key of group members.  If keying material and the KDC does not store individual
   keying material for the public keys of
   group members, Client, or information enabling the handler does not implement any method, and every
   request returns a 4.05 Method Not Allowed error.

4.1.7.1.  POST Handler

   The POST handler is used Client to replace the stored public key
   derive it.  The payload of this
   client (identified by "NODENAME") with the one specified in the
   request at the KDC, response is formatted as a CBOR map.
   The format for the group identified by "GROUPNAME".

   The handler expects a POST request with payload as specified in
   Section 4.1.2.1, with the difference that it includes only the
   parameters 'client_cred', 'cnonce' and 'client_cred_verify'.  In
   particular, the signature included in 'client_cred_verify' keying material is
   expected to be computed the same as defined in Section 4.1.2.1, with a newly
   generated N_C nonce and
   the previously received N_S. response of Section 4.1.2.2.  The specific format of public keys is individual
   keying material for group members, or of the information to derive
   it, and corresponding CBOR label, MUST be specified by in the
   application profile (OPT1).

   The handler verifies that (REQ18) and registered in Section 10.5.

   Optionally, the group name KDC can make the sub-resource at ace-
   group/GROUPNAME/nodes/NODENAME also Observable [RFC7641] for the
   associated node.  In case the KDC removes that node from the group
   without having been explicitly asked for it, this allows the KDC to
   send an unsolicited 4.04 (Not Found) response to the node as a
   notification of eviction from the group (see Section 5).

   Note that the node could have been observing also the resource at
   ace-group/GROUPNAME, in order to be informed of changes in the keying
   material.  In such a case, this method would result in largely
   overlapping notifications received for the resource at ace-group/
   GROUPNAME and the sub-resource at ace-group/GROUPNAME/nodes/NODENAME.

   In order to mitigate this, a node that supports the No-Response
   option [RFC7967] can use it when starting the observation of the sub-
   resource at ace-group/GROUPNAME/nodes/NODENAME.  In particular, the
   GET observation request can also include the No-Response option, with
   value set to 2 (Not interested in 2.xx responses).

4.1.6.3.  DELETE Handler

   The DELETE handler removes the node identified by "NODENAME" from the
   group identified by "GROUPNAME".

   The handler expects a request with method DELETE (and empty payload).

   The handler verifies that the group name of the /ace-group/GROUPNAME
   path is a subset of the 'scope' stored in the access token associated
   to this client.  The
   KDC also verifies that the roles the client is granted in the group
   allow it to perform this operation on this resource (REQ7aa). identified by "NODENAME".  If
   either the verification fails,
   the KDC MUST respond with a 4.01 (Unauthorized) error message.

   If

   The handler also verifies that the node sending the request and the
   node name used in the Uri-Path match.  If that is not formatted correctly (i.e. required fields non
   received or received with incorrect format), the case, the
   handler MUST respond responds with a 4.00 (Bad Request) 4.01 (Unauthorized) error message.  If the request contains
   unknown or non-expected fields present, response.

   Additionally, the handler MUST silently
   ignore them and continue processing.  Application profiles MAY define
   optional or mandatory payload formats for specific error cases
   (OPT6).

   Otherwise, the handler checks verifies that the public key specified in the
   'client_cred' field has a valid format for the group identified by
   "GROUPNAME", i.e. it is encoded as expected and node is compatible with
   the signature algorithm and possible associated parameters.  If that
   cannot be successfully verified, the handler MUST respond with a 4.00
   (Bad Request) error message.  Applications profiles MAY define
   alternatives (OPT5).

   Otherwise, the handler verifies the signature contained in the
   'client_cred_verify' field current member
   of the request, using the public key
   specified in the 'client_cred' field. group.  If verification fails, the signature does not pass
   verification, the handler KDC MUST respond with a
   4.01 (Unauthorized) error message.  If the KDC cannot retrieve the 'kdcchallenge'
   associated  The response MUST have Content-
   Format set to this Client (see application/ace-groupcomm+cbor and is formatted as
   defined in Section 3.3), 4.  The value of the KDC MUST respond
   with a 4.00 Bad Request error response, whose payload is a CBOR map
   including a newly generated 'kdcchallenge'.  This error response 'error' field MUST
   also have Content-Format application/ace+cbor. be set to
   0 ("Operation permitted only to group members").

   If verification succeeds, the handler replaces removes the client from the
   group identified by "GROUPNAME".  That includes removing the old public
   key of the node NODENAME with the one specified in client if the 'client_cred' field KDC keep tracks of the request, that, and stores it as the new current public key of possibly
   removing the evicted node NODENAME, in from the list of group members' public keys for observers of the
   group identified by GROUPNAME. resource
   at ace-group/GROUPNAME (if observable).  Then, the handler replies with a 2.04
   (Changed) response, which does not include deletes
   the sub-resource nodes/NODENAME and returns a 2.02 (Deleted) message
   with empty payload.

4.2.  Retrieval of Group Names and URIs

   In case

4.1.7.  ace-group/GROUPNAME/nodes/NODENAME/pub-key

   This resource implements a POST handler, if the joining node only knows KDC stores the group identifier public
   key of the group
   it wishes to join or about which it wishes to get update information
   from the KDC, the node can contact members.  If the KDC to request does not store the
   corresponding public keys of
   group name members, the handler does not implement any method, and joining resource URI. every
   request returns a 4.05 Method Not Allowed error.

4.1.7.1.  POST Handler

   The node can POST handler is used to replace the stored public key of this
   client (identified by "NODENAME") with the one specified in the
   request several group identifiers at once.  It does so the KDC, for the group identified by sending "GROUPNAME".

   The handler expects a
   CoAP FETCH POST request to with payload as specified in
   Section 4.1.2.1, with the /ace-group endpoint at difference that it includes only the KDC formatted
   parameters 'client_cred', 'cnonce' and 'client_cred_verify'.  In
   particular, the signature included in 'client_cred_verify' is
   expected to be computed as defined in Section 4.1.1.1.

   Figure 10 gives an overview 4.1.2.1, with a newly
   generated N_C nonce and the previously received N_S.  The specific
   format of public keys is specified by the exchanges described above, and
   Figure 11 shows an example.

      Client                                                     KDC
         |                                                        |
         |-------- Group Name and URI Retrieval Request: -------->|
         |                   FETCH /ace-group                     |
         |                                                        |
         |<-Group Name and URI Retrieval Response: 2.05 (Content)-|
         |                                                        |

      Figure 10: Message Flow application profile (OPT1).

   The handler verifies that the group name GROUPNAME is a subset of Group Name and URI Retrieval Request-
                                  Response

        Request:

        Header: FETCH the
   'scope' stored in the access token associated to the client
   identified by "NODENAME".  The KDC also verifies that the roles the
   client is granted in the group allow it to perform this operation on
   this resource (REQ8).  If either verification fails, the KDC MUST
   respond with a 4.01 (Unauthorized) error message.

   The handler also verifies that the node sending the request and the
   node name used in the Uri-Path match.  If that is not the case, the
   handler responds with a 4.01 (Unauthorized) error response.

   Additionally, the handler verifies that the node is a current member
   of the group.  If the verification fails, the KDC MUST respond with a
   4.01 (Unauthorized) error message.  The response MUST have Content-
   Format set to application/ace-groupcomm+cbor and is formatted as
   defined in Section 4.  The value of the 'error' field MUST be set to
   0 ("Operation permitted only to group members").

   Also, the handler verifies that this operation is consistent with the
   set of roles that the node has in the group.  If the verification
   fails, the KDC MUST respond with a 4.00 (Bad Request) error message.
   The response MUST have Content-Format set to application/ace-
   groupcomm+cbor and is formatted as defined in Section 4.  The value
   of the 'error' field MUST be set to 1 ("Request inconsistent with the
   current roles")
   If the request is not formatted correctly (i.e. required fields non
   received or received with incorrect format), the handler MUST respond
   with a 4.00 (Bad Request) error message.  If the request contains
   unknown or non-expected fields present, the handler MUST silently
   ignore them and continue processing.  Application profiles MAY define
   optional or mandatory payload formats for specific error cases
   (OPT7).

   Otherwise, the handler checks that the public key specified in the
   'client_cred' field has a valid format for the group identified by
   "GROUPNAME", i.e. it is encoded as expected and is compatible with
   the signature algorithm and possible associated parameters.  If that
   cannot be successfully verified, the handler MUST respond with a 4.00
   (Bad Request) error message.  The response MUST have Content-Format
   set to application/ace-groupcomm+cbor and is formatted as defined in
   Section 4.  The value of the 'error' field MUST be set to 2 ("Public
   key incompatible with the group configuration").

   If the KDC cannot retrieve the 'kdcchallenge' associated to this
   Client (see Section 3.3), the KDC MUST respond with a 4.00 Bad
   Request error response, whose payload is a CBOR map including a newly
   generated 'kdcchallenge'.  This error response MUST also have
   Content-Format application/ace+cbor.

   Otherwise, the handler verifies the signature contained in the
   'client_cred_verify' field of the request, using the public key
   specified in the 'client_cred' field.  If the signature does not pass
   verification, the handler MUST respond with a 4.01 (Unauthorized)
   error message.  The response MUST have Content-Format set to
   application/ace-groupcomm+cbor and is formatted as defined in
   Section 4.  The value of the 'error' field MUST be set to 3 ("Invalid
   proof-of-possession signature").

   If verification succeeds, the handler replaces the old public key of
   the node NODENAME with the one specified in the 'client_cred' field
   of the request, and stores it as the new current public key of the
   node NODENAME, in the list of group members' public keys for the
   group identified by GROUPNAME.

   If COSE Keys are used as encoding of public keys in the group, the
   KDC MUST set the 'kid' key parameter of the new current public key to
   the node identifier that the client has in the group.  If an
   alternative encoding of public keys is used, the KDC MUST set the
   node identifier of the client in the new current public key as
   appropriate, if that encoding supports it.

   Then, the handler replies with a 2.04 (Changed) response, which does
   not include a payload.

4.2.  Retrieval of Group Names and URIs

   In case the joining node only knows the group identifier of the group
   it wishes to join or about which it wishes to get update information
   from the KDC, the node can contact the KDC to request the
   corresponding group name and joining resource URI.  The node can
   request several group identifiers at once.  It does so by sending a
   CoAP FETCH request to the /ace-group endpoint at the KDC formatted as
   defined in Section 4.1.1.1.

   Figure 10 gives an overview of the exchanges described above, and
   Figure 11 shows an example.

      Client                                                     KDC
         |                                                        |
         |-------- Group Name and URI Retrieval Request: -------->|
         |                   FETCH /ace-group                     |
         |                                                        |
         |<-Group Name and URI Retrieval Response: 2.05 (Content)-|
         |                                                        |

     Figure 10: Message Flow of Group Name and URI Retrieval Request-
                                 Response

            Request:

            Header: FETCH (Code=0.05)
            Uri-Host: "kdc.example.com"
            Uri-Path: "ace-group"
            Content-Format: "application/ace-groupcomm+cbor"
            Payload (in CBOR diagnostic notation):
              { "gid": [01, 02] }

            Response:

            Header: Content (Code=2.05) Content (Code=2.05)
            Content-Format: "application/ace-groupcomm+cbor"
            Payload (in CBOR diagnostic notation):
              { "gid": [01, 02], "gname": ["group1", "group2"],
                "guri": ["ace-group/g1", "ace-group/g2"] }

    Figure 11: Example of Group Name and URI Retrieval Request-Response

4.3.  Joining Exchange

   Figure 12 gives an overview of the Joining exchange between Client
   and KDC, when the Client first joins a group, while Figure 13 shows
   an example.

      Client                                                     KDC
         |                                                        |
         |----- Joining Request: POST /ace-group/GROUPNAME ------>|
         |                                                        |
         |<--------- Joining Response: 2.01 (Created) ----------- |
         | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME"  |

        Figure 12: Message Flow of First Exchange for Group Joining

    Request:

    Header: POST (Code=0.02)
    Uri-Host: "kdc.example.com"
    Uri-Path: "ace-group"
    Uri-Path: "g1"
    Content-Format: "application/ace-groupcomm+cbor"
    Payload (in CBOR diagnostic notation,
             with PUB_KEY and SIG being CBOR byte strings):
      { "scope": << [ "group1", ["sender", "receiver"] ] >> ,
        "get_pub_keys": [true, ["sender"], []], "client_cred": PUB_KEY
        "cnonce": h'6df49c495409a9b5', "client_cred_verify": SIG }

    Response:

    Header: Created (Code=2.01)
    Content-Format: "application/ace-groupcomm+cbor"
    Location-Path: "kdc.example.com"
    Location-Path: "g1"
    Location-Path: "nodes"
    Location-Path: "c101"
    Payload (in CBOR diagnostic notation): notation,
             with KEY being a CBOR byte strings):
      { "gid": [01, 02], "gname": ["group1", "group2"],
            "guri": ["kdc.example.com/g1", "kdc.example.com/g2"] "gkty": 13, "key": KEY, "num": 12, "exp": 1609459200,
        "pub_keys": << [ PUB_KEY1, PUB_KEY2 ] >>,
        "peer_roles": ["sender", ["sender", "receiver"]] }

          Figure 11: 13: Example of First Exchange for Group Name Joining

   If not previously established, the Client and URI Retrieval Request-Response

4.3. the KDC MUST first
   establish a pairwise secure communication channel (REQ19).  This can
   be achieved, for instance, by using a transport profile of ACE.  The
   Joining Exchange

   Figure 12 gives an overview exchange MUST occur over that secure channel.  The Client and
   the KDC MAY use that same secure channel to protect further pairwise
   communications that must be secured.

   The secure communication protocol is REQUIRED to establish the secure
   channel between Client and KDC by using the proof-of-possession key
   bound to the access token.  As a result, the proof-of-possession to
   bind the access token to the Client is performed by using the proof-
   of-possession key bound to the access token for establishing secure
   communication between the Client and the KDC.

   To join the group, the Client sends a CoAP POST request to the /ace-
   group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group
   name of the group to join, formatted as specified in Section 4.1.2.1.
   This group name is the same as in the scope entry corresponding to
   that group, specified in the 'scope' parameter of the Authorization
   Request/Response, or it can be retrieved from it.  Note that, in case
   of successful joining, the Joining exchange between Client will receive the URI to retrieve
   group keying material and KDC, when to leave the group in the Client first joins a group, while Figure 13 shows
   an example.

      Client                                                     KDC
         |                                                        |
         |----- Joining Request: POST /ace-group/GROUPNAME ------>|
         |                                                        |
         |<--------- Joining Response: 2.01 (Created) ----------- |
         | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME"  |

        Figure 12: Message Flow
   option of First Exchange the response.

   If the node is joining a group for Group Joining

      Request:

      Header: POST (Code=0.02)
      Uri-Host: "kdc.example.com"
      Uri-Path: "ace-group"
      Uri-Path: "g1"
      Content-Format: "application/ace-groupcomm+cbor"
      Payload (in CBOR diagnostic notation,
               with PUB_KEY the first time, and SIG being CBOR byte strings):
        { "scope": << [ "group1", ["sender", "receiver"] ] >> ,
          "get_pub_keys": [["sender"], []], "client_cred": PUB_KEY
          "cnonce": h'6df49c495409a9b5', "client_cred_verify": SIG }

      Response:

      Header: Created (Code=2.01)
      Content-Format: "application/ace-groupcomm+cbor"
      Location-Path: "kdc.example.com"
      Location-Path: "g1"
      Location-Path: "nodes"
      Location-Path: "c101"
      Payload (in CBOR diagnostic notation,
               with KEY being a CBOR byte strings):
        { "gkty": 13, "key": KEY, "num": 12, "exp": 1609459200,
          "pub_keys": << [ PUB_KEY1, PUB_KEY2 ] >>,
          "peer_roles": ["sender", ["sender", "receiver"]] }

           Figure 13: Example the KDC
   maintains the public keys of First Exchange for Group Joining the group members, the Client is
   REQUIRED to send its own public key and proof of possession
   ("client_cred" and "client_cred_verify" in Section 4.1.2.1).  The
   request is only accepted if both public key and proof of possession
   are provided.  If not previously established, a node re-joins a group with the same access token
   and the same public key, it can omit to send the public key and the
   proof of possession, or just omit the Client proof of possession, and the
   KDC MUST first
   establish a pairwise secure communication channel (REQ16).  This can will be achieved, able to retrieve its public key associated to its token
   for instance, by using that group (if the key has been discarded, the KDC will reply
   with 4.00 Bad Request, as specified in Section 4.1.2.1).  If a transport profile node
   re-joins a group but wants to update its own public key, it needs to
   send both public key and proof of ACE.  The
   Joining exchange possession.

   If the application requires backward security, the KDC MUST occur over that secure channel.  The Client generate
   new group keying material and securely distribute it to all the
   current group members, upon a new node's joining the group.  To this
   end, the KDC MAY use that same secure channel uses the message format of the response defined in
   Section 4.1.2.2.  Application profiles may define alternative ways of
   retrieving the keying material, such as sending separate requests to
   different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2,
   Section 4.1.4.1).  After distributing the new group keying material,
   the KDC MUST increment the version number of the keying material.

4.4.  Retrieval of Updated Keying Material

   When any of the following happens, a node MUST stop using the owned
   group keying material to protect further pairwise
   communications that must be secured.

   The secure communication protocol is REQUIRED outgoing messages, and SHOULD stop
   using it to decrypt and verify incoming messages.

   o  Upon expiration of the keying material, according to what
      indicated by the KDC with the 'exp' parameter in a Joining
      Response, or to establish a pre-configured value.

   o  Upon receiving a notification of revoked/renewed keying material
      from the secure
   channel between Client and KDC KDC, possibly as part of an update of the keying material
      (rekeying) triggered by using the proof-of-possession key
   bound KDC.

   o  Upon receiving messages from other group members without being
      able to retrieve the access token.  As a result, the proof-of-possession keying material to
   bind the access token correctly decrypt them.
      This may be due to the Client is performed rekeying messages previously sent by using the proof-
   of-possession key bound KDC,
      that the Client was not able to receive or decrypt.

   In either case, if it wants to continue participating in the access token for establishing secure
   communication between group
   communication, the Client and node has to request the latest keying material
   from the KDC.  To join the group, this end, the Client sends a CoAP POST GET request to
   the /ace-
   group/GROUPNAME /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME is the group
   name of the group to join,
   formatted as specified in Section 4.1.2.1.
   This group name 4.1.6.2.

   Note that policies can be set up, so that the Client sends a Key Re-
   Distribution request to the KDC only after a given number of received
   messages could not be decrypted (because of failed decryption
   processing or inability to retrieve the necessary keying material).

   It is application dependent and pertaining to the particular message
   exchange (e.g.  [I-D.ietf-core-oscore-groupcomm]) to set up these
   policies for instructing clients to retain incoming messages and for
   how long (OPT5).  This allows clients to possibly decrypt such
   messages after getting updated keying material, rather than just
   consider them non valid messages to discard right away.

   The same Key Distribution Request could also be sent by the same as in Client
   without being triggered by a failed decryption of a message, if the scope entry corresponding
   Client wants to be sure that group, specified in it has the 'scope' parameter of latest group keying material.
   If that is the Authorization
   Request/Response, or it can be retrieved from it.  Note that, in case
   of successful joining, case, the Client will receive from the URI to retrieve KDC the same
   group keying material and to leave the group it already has in the Location-Path
   option of the response.

   If the node is joining a group for the first time, and the KDC
   maintains the public keys memory.

   Figure 14 gives an overview of the group members, the exchange described above, while
   Figure 15 shows an example.

    Client is
   REQUIRED to send its own public key and proof                                                          KDC
       |                                                             |
       |------------------ Key Distribution Request: --------------->|
       |           GET ace-group/GROUPNAME/nodes/NODENAME            |
       |                                                             |
       |<-------- Key Distribution Response: 2.05 (Content) ---------|
       |                                                             |

       Figure 14: Message Flow of possession
   ("client_cred" Key Distribution Request-Response
        Request:

        Header: GET (Code=0.01)
        Uri-Host: "kdc.example.com"
        Uri-Path: "ace-group"
        Uri-Path: "g1"
        Uri-Path: "nodes"
        Uri-Path: "c101"
        Payload: -

        Response:

        Header: Content (Code=2.05)
        Content-Format: "application/ace-groupcomm+cbor"
        Payload (in CBOR diagnostic notation,
                 with KEY and "client_cred_verify" in Section 4.1.2.1).  The
   request is only accepted if both public key IND_KEY being CBOR byte strings,
                 and proof "ind-key" the profile-specified label
                 for individual keying material):
          { "gkty": 13, "key": KEY, "num": 12, "ind-key": IND_KEY }

          Figure 15: Example of possession
   are provided.  If a node re-joins a group with Key Distribution Request-Response

   Alternatively, the same access token
   and re-distribution of keying material can be
   initiated by the KDC, which e.g.:

   o  Can make the same public key, it can omit to ace-group/GROUPNAME resource Observable [RFC7641],
      and send notifications to observer Clients when the public key and keying
      material is updated.

      In case the
   proof of possession, or just omit KDC deletes the proof of possession, and group identified by "GROUPNAME", this
      also allows the KDC will be able to retrieve its public key associated send an unsolicited 4.04 (Not Found)
      response to its token
   for that each observer group (if the key has been discarded, the KDC will reply
   with 4.00 Bad Request, member, as specified in Section 4.1.2.1).  If a node
   re-joins a notification of group but wants to update its own public key, it needs
      termination.  The response MUST have Content-Format set to
   send both public key
      application/ace-groupcomm+cbor and proof is formatted as defined in
      Section 4.  The value of possession.

   If the application requires backward security, the KDC 'error' field MUST generate
   new group keying material and securely distribute it be set to all the
   current group members, upon a new node's joining the group.  To this
   end, the KDC uses 6
      ("Group deleted").

   o  Can send the message format payload of the response defined Key Distribution Response in
   Section 4.1.2.2.  Application profiles may define alternative ways one or
      multiple multicast POST requests to the members of
   retrieving the keying material, group,
      using secure rekeying schemes such as sending separate [RFC2093][RFC2094][RFC2627].

   o  Can send unicast POST requests to
   different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2,
   Section 4.1.4.1).  After distributing the new group keying material,
   the KDC MUST increment each Client over a secure
      channel, with the version number of same payload as the keying material.

4.4.  Retrieval of Updated Keying Material Key Distribution Response.
      When any of the following happens, a node MUST stop using sending such requests, the owned
   group keying material to protect outgoing messages, and SHOULD stop
   using it to decrypt and verify incoming messages.

   *  Upon expiration of KDC can target the keying material, according to what
      indicated URI path
      provided by the KDC with intended recipient upon joining the 'exp' parameter group, as
      specified in a Joining
      Response, or to a pre-configured value.

   *  Upon receiving a notification the 'control_uri' parameter of revoked/renewed keying material
      from the KDC, possibly Joining Request
      (see Section 4.1.2.1).

   o  Can act as part of an a publisher in a pub-sub scenario, and update of the
      keying material
      (rekeying) triggered by publishing on a specific topic on a broker,
      which all the KDC.

   *  Upon receiving messages from other group members without being
      able of the group are subscribed to.

   Note that these methods of KDC-initiated key distribution have
   different security properties and require different security
   associations.

4.5.  Requesting a Change of Keying Material

   Beside possible expiration, the client may need to communicate to retrieve the
   KDC its need for the keying material to correctly decrypt them.
      This may be renewed, e.g. due to rekeying messages previously sent by
   exhaustion of AEAD nonces, if AEAD is used for protecting group
   communication.  Depending on the KDC,
      that application profile (OPT9), this can
   result in renewal of individual keying material, group keying
   material, or both.

   For example, if the Client was not able uses an individual key to receive or decrypt.

   In either case, if it wants protect outgoing
   traffic and has to continue participating in the group
   communication, renew it, the node has to may request the latest keying a new one, or new
   input material
   from to derive it, without renewing the KDC. whole group keying
   material.

   To this end, the Client client performs a Key Renewal Request/Response
   exchange with the KDC, i.e. it sends a CoAP GET PUT request to the /ace-group/GROUPNAME/nodes/NODENAME /ace-
   group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME
   is the group name and NODENAME is its node name, and formatted as specified
   defined in Section 4.1.6.2.

   Note that policies can be set up, so that

   Figure 16 gives an overview of the exchange described above, while
   Figure 17 shows an example.

       Client sends a Key Re-
   Distribution request to the                                                    KDC only after a given number of received
   messages could not be decrypted (because
          |                                                       |
          |------------------ Key Renewal Request: -------------->|
          |           PUT ace-group/GROUPNAME/nodes/NODENAME      |
          |                                                       |
          |<-------- Key Renewal Response: 2.05 (Content) --------|
          |                                                       |

          Figure 16: Message Flow of failed decryption
   processing or inability to retrieve the necessary keying material).

   It is application dependent Key Renewal Request-Response

     Request:

     Header: PUT (Code=0.03)
     Uri-Host: "kdc.example.com"
     Uri-Path: "ace-group"
     Uri-Path: "g1"
     Uri-Path: "nodes"
     Uri-Path: "c101"
     Payload: -

     Response:

     Header: Content (Code=2.05)
     Content-Format: "application/ace-groupcomm+cbor"
     Payload (in CBOR diagnostic notation, with IND_KEY being
              a CBOR byte string, and pertaining to "ind-key" the particular message
   exchange (e.g.  [I-D.ietf-core-oscore-groupcomm]) to set up these
   policies for instructing clients to retain incoming messages and profile-specified
              label for
   how long (OPT4).  This allows clients to possibly decrypt such
   messages after getting updated individual keying material, rather than just
   consider them non valid messages to discard right away.

   The same material):
       { "ind-key": IND_KEY }

            Figure 17: Example of Key Renewal Request-Response

   Note the difference between the Key Distribution Request could also be sent by and the Client
   without being triggered by a failed decryption Key
   Renewal Request: while the first one only triggers distribution (the
   renewal might have happened independently, e.g. because of a message, if
   expiration), the
   Client wants to be sure that it has second one triggers the latest group KDC to produce new
   individual keying material.
   If that is material for the case, requesting node.

4.6.  Retrieval of Public Keys and Roles for Group Members

   In case the Client will receive from KDC maintains the public keys of group members, a node in
   the group can contact the KDC to request public keys and roles of
   either all group members or a specified subset, by sending a CoAP GET
   or FETCH request to the /ace-group/GROUPNAME/pub-key endpoint at the
   KDC, where GROUPNAME is the same group keying material it already has name, and formatted as defined in memory.
   Section 4.1.3.2 and Section 4.1.3.1.

   Figure 14 gives 18 and Figure 20 give an overview of the exchange exchanges described
   above, while Figure 15 shows 19 and Figure 21 show an example. example for each
   exchange.

      Client                                                     KDC
         |                                                        |
       |------------------
         |--Public Key Distribution Request: --------------->|
       | GET ace-group/GROUPNAME/nodes/NODENAME            | /ace-group/GROUPNAME/pub-key->|
         |                                                        |
       |<--------
         |<--------- Public Key Distribution Response: 2.05 (Content) ---------|
         |                                                        |

   Figure 14: 18: Message Flow of Public Key Distribution Request-Response Exchange to Request All Members
                                Public Keys

    Request:

    Header: GET (Code=0.01)
    Uri-Host: "kdc.example.com"
    Uri-Path: "ace-group"
    Uri-Path: "g1"
    Uri-Path: "nodes"
        Uri-Path: "c101" "pub-key"
    Payload: -

    Response:

    Header: Content (Code=2.05)
    Content-Format: "application/ace-groupcomm+cbor"
    Payload (in CBOR diagnostic notation,
                 with KEY and IND_KEY being notation):
      { "pub_keys": << [ PUB_KEY1, PUB_KEY2, PUB_KEY3 ] >>,
        "peer_roles": ["sender", ["sender", "receiver"], "receiver"] }

     Figure 19: Example of Public Key Exchange to Request All Members
                                Public Keys

      Client                                                      KDC
         |                                                         |
         |-Public Key Request: FETCH /ace-group/GROUPNAME/pub-key->|
         |                                                         |
         |<--------- Public Key Response: 2.05 (Created) ----------|
         |                                                         |

    Figure 20: Message Flow of Public Key Exchange to Request Specific
                            Members Public Keys

             Request:

             Header: FETCH (Code=0.05)
             Uri-Host: "kdc.example.com"
             Uri-Path: "ace-group"
             Uri-Path: "g1"
             Uri-Path: "pub-key"
             Content-Format: "application/ace-groupcomm+cbor"
             Payload:
               { "get_pub_keys": [true, [], ["c3"]] }

             Response:

             Header: Content (Code=2.05)
             Content-Format: "application/ace-groupcomm+cbor"
             Payload (in CBOR byte strings,
                 and "ind-key" the profile-specified label
                 for individual keying material): diagnostic notation):
               { "gkty": 13, "key": KEY, "num": 12, "ind-key": IND_KEY "pub_keys": << [ PUB_KEY3 ] >>,
                 "peer_roles": ["receiver"] }

   Figure 15: 21: Example of Public Key Distribution Request-Response

   Alternatively, the re-distribution of keying material can be
   initiated by the KDC, which e.g.:

   *  Can make the ace-group/GROUPNAME resource Observable [RFC7641],
      and send notifications to Clients when the keying material is
      updated.

   *  Can send the payload of the Key Distribution Response in one or
      multiple multicast POST requests to the members of the group,
      using secure rekeying schemes such as [RFC2093][RFC2094][RFC2627].

   *  Can send unicast POST requests Exchange to each Client over a secure
      channel, with the same payload as the Key Distribution Response.
      When sending such requests, the KDC can target the URI path
      provided by the intended recipient upon joining the group, as
      specified in the 'control_path' parameter of the Joining Request
      (see Section 4.1.2.1).

   *  Can act as a publisher in a pub-sub scenario, and update the
      keying material by publishing on a specific topic on a broker,
      which all the members of the group are subscribed to.

   Note that these methods of KDC-initiated key distribution have
   different security properties and require different security
   associations.

4.5.  Requesting a Change Specific Members
                                Public Keys

4.7.  Update of Keying Material

   Beside possible expiration, the client may need to communicate to Public Key

   In case the KDC its need for the keying material to be renewed, e.g. due to
   exhaustion of AEAD nonces, if AEAD is used for protecting group
   communnication.  Depending on maintains the application profile (OPT8), this
   can result in renewal public keys of individual keying material, group keying
   material, or both.

   For example, if members, a node in
   the Client uses an individual key to protect outgoing
   traffic and has to renew it, group can contact the node may request KDC to upload a new one, or new
   input material public key to derive it, without renewing use in
   the whole group keying
   material. group, and replace the currently stored one.

   To this end, the client Client performs a Public Key Renewal Update Request/Response
   exchange with the KDC, i.e. it sends a CoAP PUT POST request to the /ace-
   group/GROUPNAME/nodes/NODENAME
   group/GROUPNAME/nodes/NODENAME/pub-key endpoint at the KDC, where
   GROUPNAME is the group name and NODENAME is its node name, and name.

   The request is formatted as
   defined specified in Section 4.1.6.2. 4.1.7.1.

   Figure 16 Figure 22 gives an overview of the exchange described above,
   while Figure 17 23 shows an example.

   Client                                                           KDC
   |                                                                 |
          |------------------
   |-------------- Public Key Renewal Update Request: -------------->| ---------------------->|
   |           PUT ace-group/GROUPNAME/nodes/NODENAME      POST ace-group/GROUPNAME/nodes/NODENAME/pub-key            |
   |                                                                 |
          |<--------
   |<------- Public Key Renewal Update Response: 2.05 (Content) --------| 2.04 (Changed) -------------|
   |                                                                 |

       Figure 16: 22: Message Flow of Public Key Renewal Update Request-Response
        Request:

        Header: PUT (Code=0.03) POST (Code=0.02)
        Uri-Host: "kdc.example.com"
        Uri-Path: "ace-group"
        Uri-Path: "g1"
        Uri-Path: "nodes"
        Uri-Path: "c101"
     Payload: -

     Response:

     Header: Content (Code=2.05)
        Uri-Path: "pub-key"
        Content-Format: "application/ace-groupcomm+cbor"
        Payload (in CBOR diagnostic notation, with IND_KEY PUB_KEY
                 and SIG being
              a CBOR byte string, and "ind-key" the profile-specified
              label for individual keying material): strings):
          { "ind-key": IND_KEY "client_cred": PUB_KEY, "cnonce": h'9ff7684414affcc8',
            "client_cred_verify": SIG }

        Response:

        Header: Changed (Code=2.04)
        Payload: -

         Figure 17: 23: Example of Public Key Renewal Update Request-Response

   Note

   If the difference between application requires backward security, the Key Distribution Request KDC MUST generate
   new group keying material and securely distribute it to all the Key
   Renewal Request: while
   current group members, upon a group member updating its own public
   key.  To this end, the first one only triggers distribution (the
   renewal might have happened independently, e.g. because KDC uses the message format of the response
   defined in Section 4.1.2.2.  Application profiles may define
   alternative ways of retrieving the keying material, such as sending
   separate requests to different resources at the KDC (Section 4.1.2.2,
   Section 4.1.3.2, Section 4.1.4.1).  The KDC MUST increment the
   version number of
   expiration), the second one triggers current keying material, before distributing
   the KDC to produce new
   individual newly generated keying material for to the requesting node.

4.6.  Retrieval of Public Keys and Roles for Group Members

   In case group.  After that, the
   KDC maintains SHOULD store the distributed keying material in persistent
   storage.

   Additionally, after updating its own public keys of key, a group members, member MAY
   send a number of the later requests including an identifier of the
   updated public key, to signal nodes that they need to retrieve it.
   How that is done depends on the group communication protocol used,
   and therefore is application profile specific (OPT11).

4.8.  Retrieval of Group Policies

   A node in the group can contact the KDC to request public keys and roles of
   either all retrieve the current group members or a specified subset,
   policies, by sending a CoAP GET
   or FETCH request to the /ace-group/GROUPNAME/pub-key /ace-group/GROUPNAME/
   policies endpoint at the KDC, where GROUPNAME is the group name, and
   formatted as defined in Section 4.1.3.2 and Section 4.1.3.1.

   Figure 18 and 4.1.4.1
   Figure 20 give 24 gives an overview of the exchanges exchange described above, while
   Figure 19 and Figure 21 show 25 shows an example for each
   exchange.

      Client                                                     KDC
         |                                                        |
         |--Public Key Request: GET /ace-group/GROUPNAME/pub-key->|
         |                                                        |
         |<--------- Public Key Response: 2.05 (Content) ---------|
         |                                                        |

       Figure 18: Message Flow of Public Key Exchange to Request All
                            Members Public Keys

    Request:

    Header: GET (Code=0.01)
    Uri-Host: "kdc.example.com"
    Uri-Path: "ace-group"
    Uri-Path: "g1"
    Uri-Path: "pub-key"
    Payload: -

    Response:

    Header: Content (Code=2.05)
    Content-Format: "application/ace-groupcomm+cbor"
    Payload (in CBOR diagnostic notation):
      { "pub_keys": << [ PUB_KEY1, PUB_KEY2, PUB_KEY3 ] >>,
        "peer_roles": ["sender", ["sender", "receiver"], "receiver"] }

      Figure 19: Example of Public Key Exchange to Request All Members
                                Public Keys example.

       Client                                                   KDC
          |                                                      |
         |-Public Key
          |-Policies Request: FETCH /ace-group/GROUPNAME/pub-key->| GET ace-group/GROUPNAME/policies ->|
          |                                                      |
          |<--------- Public Key Policies Response: 2.05 (Created) ----------| (Content) ---------|
          |                                                      |

           Figure 20: 24: Message Flow of Public Key Exchange to Request
                        Specific Members Public Keys Policies Request-Response

             Request:

             Header: FETCH (Code=0.05) GET (Code=0.01)
             Uri-Host: "kdc.example.com"
             Uri-Path: "ace-group"
             Uri-Path: "g1"
             Uri-Path: "pub-key"
             Content-Format: "application/ace-groupcomm+cbor" "policies"
             Payload:
               { "get_pub_keys": [[], ["c3"]] } -

             Response:

             Header: Content (Code=2.05)
             Content-Format: "application/ace-groupcomm+cbor"
             Payload (in
             Payload(in CBOR diagnostic notation):
               { "pub_keys": << [ PUB_KEY3 ] >>,
                 "peer_roles": ["receiver"] "group_policies": {"exp-delta": 120} }

              Figure 21: 25: Example of Public Key Exchange to Request Specific
                            Members Public Keys

4.7.  Update of Public Key

   In case the KDC maintains the public keys Policies Request-Response

4.9.  Retrieval of group members, a Keying Material Version

   A node in the group can contact the KDC to upload a new public key to use in
   the group, and replace the currently stored one.

   To this end, request information about
   the Client performs a Public Key Update Request/Response
   exchange with version number of the KDC, i.e. it sends symmetric group keying material, by sending
   a CoAP POST GET request to the /ace-
   group/GROUPNAME/nodes/NODENAME/pub-key /ace-group/GROUPNAME/num endpoint at the
   KDC, where GROUPNAME is the group name and NODENAME is its node name.

   The request is name, formatted as specified defined in
   Section 4.1.7.1.

   Figure 4.1.5.1.  In particular, the version is incremented by the
   KDC every time the group keying material is renewed, before it's
   distributed to the group members.

   Figure 22 26 gives an overview of the exchange described above, while
   Figure 23 27 shows an example.

       Client                                                    KDC
          |                                                       |
   |-------------- Public Key Update
          |---- Version Request: ---------------------->|
   |      POST ace-group/GROUPNAME/nodes/NODENAME/pub-key            | GET ace-group/GROUPNAME/num ---->|
          |                                                       |
   |<------- Public Key Update
          |<--------- Version Response: 2.04 (Changed) -------------| 2.05 (Content) -----------|
          |                                                       |

            Figure 22: 26: Message Flow of Public Key Update Version Request-Response

                   Request:

                   Header: POST (Code=0.02) GET (Code=0.01)
                   Uri-Host: "kdc.example.com"
                   Uri-Path: "ace-group"
                   Uri-Path: "g1"
                   Uri-Path: "nodes"
        Uri-Path: "c101"
        Uri-Path: "pub-key" "num"
                   Payload: -

                   Response:

                   Header: Content (Code=2.05)
                   Content-Format: "application/ace-groupcomm+cbor"
        Payload (in text/plain
                   Payload(in CBOR diagnostic notation, with PUB_KEY
                 and SIG being CBOR byte strings):
          { "client_cred": PUB_KEY, "cnonce": h'9ff7684414affcc8',
            "client_cred_verify": SIG }

        Response:

        Header: Changed (Code=2.04)
        Payload: - notation):
                     13

              Figure 23: 27: Example of Public Key Update Version Request-Response

4.10.  Group Leaving Request

   A node can actively request to leave the group.  In this case, the
   Client sends a CoAP DELETE request to the endpoint /ace-
   group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME is the
   group name and NODENAME is its node name, formatted as defined in
   Section 4.1.6.3

   Alternatively, a node may be removed by the KDC, without having
   explicitly asked for it.  This is further discussed in Section 5.

5.  Removal of a Node from the Group

   This section describes the different scenarios according to which a
   node ends up being removed from the group.

   If the application requires backward forward security, the KDC MUST generate
   new group keying material and securely distribute it to all the
   current group members, upon a group member updating its own public
   key.  To this end, members but the KDC uses leaving node, using the message format
   of the response
   defined in Key Distribution Response (see Section 4.1.2.2. 4.4).  Application
   profiles may define alternative ways of retrieving message formats.  Before distributing
   the new group keying material, such as sending
   separate requests to different resources at the KDC (Section 4.1.2.2,
   Section 4.1.3.2, Section 4.1.4.1).  The KDC MUST increment the version
   number of the current keying material, before distributing
   the newly generated keying material to the group.  After material.

   Note that, the
   KDC SHOULD store the distributed keying material in persistent
   storage.

   Additionally, after updating its own public key, a group member MAY
   send a number of the later requests including an identifier of having left the
   updated public key, to signal nodes that they need group, a node may wish to retrieve it.
   How that is done depends on the group communication protocol used,
   and therefore is application profile specific (OPT10).

4.8.  Retrieval of Group Policies

   A join it
   again.  Then, as long as the node in is still authorized to join the group
   group, i.e. it still has a valid access token, it can contact request to re-
   join the group directly to the KDC without needing to retrieve the current group
   policies, by sending a CoAP GET request to new
   access token from the /ace-group/GROUPNAME/
   policies endpoint at AS.  This means that the KDC, where GROUPNAME is KDC might decide to
   keep track of nodes with valid access tokens, before deleting all
   information about the leaving node.

   A node may be evicted from the group name, and
   formatted in the following cases.

   1.  The node explicitly asks to leave the group, as defined in
       Section 4.1.4.1
   Figure 24 gives an overview 4.10.

   2.  The node has been found compromised or is suspected so.

   3.  The node's authorization to be a group member is not valid
       anymore, either because the access token has expired, or it has
       been revoked.  If the AS provides Token introspection (see
       Section 5.9 of [I-D.ietf-ace-oauth-authz]), the exchange described above, while
   Figure 25 shows an example.

       Client KDC
          |                                                      |
          |-Policies Request: GET ace-group/GROUPNAME/policies ->|
          |                                                      |
          |<--------- Policies Response: 2.05 (Content) ---------|
          |                                                      |

            Figure 24: Message Flow of Policies Request-Response

             Request:

             Header: GET (Code=0.01)
             Uri-Host: "kdc.example.com"
             Uri-Path: "ace-group"
             Uri-Path: "g1"
             Uri-Path: "policies"
             Payload: -

             Response:

             Header: Content (Code=2.05)
             Content-Format: "application/ace-groupcomm+cbor"
             Payload(in CBOR diagnostic notation):
               { "group_policies": {"exp-delta": 120} }

              Figure 25: Example of Policies Request-Response

4.9.  Retrieval of Keying Material Version

   A can
       optionally use it and check whether the node is still authorized
       for that group in that role.

       In either case, once aware that a node is not authorized anymore,
       the KDC has to remove the unauthorized node in from the list of
       group can contact members, if the KDC to request information about keeps track of that.

   Furthermore, in case of forced eviction, the version number KDC removes the public
   key of the symmetric group keying material, by sending
   a CoAP GET request to evicted node if the /ace-group/GROUPNAME/num endpoint at KDC keep tracks of that, and possibly
   removes the
   KDC, where GROUPNAME is evicted node from the group name, formatted as defined in
   Section 4.1.5.1.  In particular, list of observers of the version is incremented by resource
   at ace-group/GROUPNAME (if observable).

   Then, the KDC every time deletes the group keying material is renewed, before it's
   distributed sub-resource ace-group/GROUPNAME/nodes/
   NODENAME associated to the group members.

   Figure 26 gives an overview of evicted node.  After that, the exchange described above, while
   Figure 27 shows an example.

       Client KDC
          |                                                       |
          |---- Version Request: GET ace-group/GROUPNAME/num ---->|
          |                                                       |
          |<--------- Version Response: 2.05 (Content) -----------|
          |                                                       |

            Figure 26: Message Flow of Version Request-Response

                   Request:

                   Header: GET (Code=0.01)
                   Uri-Host: "kdc.example.com"
                   Uri-Path: "ace-group"
                   Uri-Path: "g1"
                   Uri-Path: "num"
                   Payload: -

                   Response:

                   Header: Content (Code=2.05)
                   Content-Format: text/plain
                   Payload(in CBOR diagnostic notation):
                     13

               Figure 27: Example MAY
   explicitly inform the evicted node, by means of Version Request-Response

4.10.  Group Leaving Request

   A the following
   methods.

   o  If the evicted node can actively request to leave implements the group.  In this case, 'control_uri' resource
      specified in Section 4.1.2.1, the
   Client KDC sends a CoAP DELETE request to request,
      targeting the endpoint /ace-
   group/GROUPNAME/nodes/NODENAME URI specified in the 'control_uri' parameter of the
      Joining Request (see Section 4.1.2.1).

   o  If the evicted node is observing its associated sub-resource at
      ace-group/GROUPNAME/nodes/NODENAME (see Section 4.1.6.2), the KDC
      sends an unsolicited 4.04 (Not Found) response, which does not
      include the KDC, where GROUPNAME is Observe option and indicates that the
   group name observed
      resource has been deleted (see Section 3.2 of [RFC7641]).

      The response MUST have Content-Format set to application/ace-
      groupcomm+cbor and NODENAME is its node name, formatted as defined in Section 4.1.6.3

   Alternatively, a node may 4.  The
      value of the 'error' field MUST be removed by set to 5 ("Group membership
      terminated").

      Consistently, the KDC, without having
   explicitly asked for it.  This is further discussed in Section 5.

5.  Removal of a Node KDC also removes the node's entry from the Group list
      of observers of the sub-resource.

6.  Extended Scope Format

   This section describes defines an extended format of binary encoded scope,
   which additionally specifies the different scenarios according semantics used to which a
   node ends up being removed express the same
   access control information from the group.

   If corresponding original scope.

   As also discussed in Section 3.2, this enables a Resource Server to
   unambiguously process a received access token, also in case the
   Resource Server runs multiple applications or application requires forward security, profiles
   that involve different scope semantics.

   The extended format is intended only for the KDC MUST generate
   new group keying material and securely distribute it to all 'scope' claim of access
   tokens, for the
   current group members but cases where the leaving node, using claim takes as value a CBOR byte
   string.  That is, the message extended format
   of does not apply to the Key Distribution 'scope'
   parameter included in ACE messages, i.e. the Authorization Request
   and Authorization Response exchanged between the client and the
   Authorization Server (see Section 4.4).  Application
   profiles may define alternative Sections 5.8.1 and 5.8.2 of
   [I-D.ietf-ace-oauth-authz]), the AS Request Creation Hints message formats.  Before distributing
   from the new group keying material, Resource Server (see Section 5.3 of
   [I-D.ietf-ace-oauth-authz]), and the KDC MUST increment Introspection Response from the version
   number
   Authorization Server (see Section 5.9.2 of
   [I-D.ietf-ace-oauth-authz]).

   The value of the keying material.

   Note that, after having left 'scope' claim following the group, extended format is
   composed as follows.  Given the original scope using a node may wish to join it
   again.  Then, semantics SEM
   and encoded as long a CBOR byte string, the corresponding extended scope
   is encoded as a tagged CBOR byte string, wrapping a CBOR sequence
   [RFC8742] of two elements.  In particular:

   o  The first element of the node sequence is still authorized to join a CBOR integer, and
      identifies the
   group, i.e. it still semantics SEM used for this scope.  The value of
      this element has a valid access token, it can request to re-
   join be taken from the group directly to "Value" column of the KDC without needing to retrieve "ACE
      Scope Semantics" registry defined in Section 10.12 of this
      specification.

      When defining a new
   access token from the AS.  This means that semantics for a binary scope, it is up to the KDC might decide
      applications and application profiles to
   keep track of nodes with valid access tokens, before deleting all
   information about define and register the leaving node.

   A node may be evicted from
      corresponding integer identifier (REQ23).

   o  The second element of the group in sequence is the following cases.

   1.  The node explicitly asks to leave original scope using the group,
      semantics SEM, encoded as a CBOR byte string.

   Finally, the CBOR byte string wrapping the CBOR sequence is tagged,
   and identified by the CBOR tag TBD_TAG "ACE Extended Scope Format",
   defined in Section 4.10.

   2.  The node has been found compromised or is suspected so.

   3. 10.11 of this specification.

   The node's authorization to be a group member resulting tagged CBOR byte string is not valid
       anymore, either because the access token has expired, or it has
       been revoked.  If used as value of the AS provides Token introspection (see
       Section 5.7 'scope'
   claim of [I-D.ietf-ace-oauth-authz]), the KDC can
       optionally use it and check whether access token.

   The usage of the node is still authorized
       for that group in that role.

   In either case, once aware that a node extended scope format is not authorized anymore, the
   KDC has limited to remove the unauthorized node from the list application
   profiles of this specification or to applications based on group
   members, if the KDC keeps track of that.

   In case of forced eviction, the KDC MAY explicitly inform the leaving
   node, if
   communication.  Rather, it is generally applicable to any application
   and application profile where access control information in the Client implements
   access token is expressed as a binary encoded scope.

   Figure 28 and Figure 29 build on the 'control_path' resource specified examples in Section 4.1.2.1.  To this end, 3.2, and
   show the KDC MAY send a DEL request,
   targeting corresponding extended scopes.

   gname = tstr

   permissions = uint . bits roles

   roles = &(
      Requester: 1,
      Responder: 2,
      Monitor: 3,
      Verifier: 4
   )

   scope_entry = AIF_Generic<gname, permissions>

   scope = << [ + scope_entry ] >>

   semantics = int

   ; This defines an array, the URI specified elements
   ; of which are to be used in the 'control_path' parameter a CBOR Sequence:
   sequence = [semantics, scope]

   extended_scope = #6.TBD_TAG(<< sequence >>)

      Figure 28: Example CDLL definition of scope, using the
   Joining Request.

6. default
                     Authorization Information Format

   gname = tstr

   role = tstr

   scope_entry = [ gname , ? ( role / [ 2*role ] ) ]

   scope = << [ + scope_entry ] >>

   semantics = int

   ; This defines an array, the elements
   ; of which are to be used in a CBOR Sequence:
   sequence = [semantics, scope]

   extended_scope = #6.TBD_TAG(<< sequence >>)

     Figure 29: CDLL definition of scope, using as example group name
                     encoded as tstr and role as tstr

7.  ACE Groupcomm Parameters

   This specification defines a number of fields used during the second
   part of the message exchange, after the ACE Token POST exchange.  The
   table below summarizes them, and specifies the CBOR key to use
   instead of the full descriptive name.

   Note that the media type ace-
   groupcomm+cbor application/ace-groupcomm+cbor MUST be used
   when these fields are transported.

   +=======================+======+================+==================+

   +-----------------------+------+-----------------+------------------+
   | Name                  | CBOR | CBOR Type       | Reference        |
   |                       | Key  |                 |                  |
   +=======================+======+================+==================+
   +-----------------------+------+-----------------+------------------+
   | scope                 | TBD  | byte string     | Section 4.1.2.1  |
   +-----------------------+------+----------------+------------------+
   |                       |      |                 |                  |
   | get_pub_keys          | TBD  | array / simple  | Section 4.1.2.1, |
   |                       |      | value null      | Section 4.1.3.1  |
   +-----------------------+------+----------------+------------------+
   |                       |      |                 |                  |
   | client_cred           | TBD  | byte string     | Section 4.1.2.1  |
   +-----------------------+------+----------------+------------------+
   |                       |      |                 |                  |
   | cnonce                | TBD  | byte string     | Section 4.1.2.1  |
   +-----------------------+------+----------------+------------------+
   |                       |      |                 |                  |
   | client_cred_verify    | TBD  | byte string     | Section 4.1.2.1  |
   +-----------------------+------+----------------+------------------+
   |                       |      |                 |                  |
   | pub_keys_repos        | TBD  | text string     | Section 4.1.2.1  |
   +-----------------------+------+----------------+------------------+
   | control_path                       |      |                 |                  |
   | control_uri           | TBD  | text string     | Section 4.1.2.1  |
   +-----------------------+------+----------------+------------------+
   |                       |      |                 |                  |
   | gkty                  | TBD  | integer / text  | Section 4.1.2.1  |
   |                       |      | string          |                  |
   +-----------------------+------+----------------+------------------+
   |                       |      |                 |                  |
   | key                   | TBD  | see "ACE        | Section 4.1.2.1  |
   |                       |      | Groupcomm Key"  |                  |
   |                       |      | Registry        |                  |
   +-----------------------+------+----------------+------------------+
   |                       |      |                 |                  |
   | num                   | TBD  | int             | Section 4.1.2.1  |
   +-----------------------+------+----------------+------------------+
   |                       |      |                 |                  |
   | ace-groupcomm-profile | TBD  | int             | Section 4.1.2.1  |
   +-----------------------+------+----------------+------------------+
   |                       |      |                 |                  |
   | exp                   | TBD  | int             | Section 4.1.2.1  |
   +-----------------------+------+----------------+------------------+
   |                       |      |                 |                  |
   | pub_keys              | TBD  | byte string     | Section 4.1.2.1  |
   +-----------------------+------+----------------+------------------+
   |                       |      |                 |                  |
   | peer_roles            | TBD  | array           | Section 4.1.2.1  |
   +-----------------------+------+----------------+------------------+
   |                       |      |                 |                  |
   | peer_identifiers      | TBD  | array           | Section 4.1.2.1  |
   |                       |      |                 |                  |
   | group_policies        | TBD  | map             | Section 4.1.2.1  |
   +-----------------------+------+----------------+------------------+
   |                       |      |                 |                  |
   | mgt_key_material      | TBD  | byte string     | Section 4.1.2.1  |
   +-----------------------+------+----------------+------------------+
   | gid                       | TBD      | array                 | Section 4.1.1.1                  |
   +-----------------------+------+----------------+------------------+
   | gname gid                   | TBD  | array           | Section 4.1.1.1  |
   |                       |      |                 |                  |
   | gname                 | TBD  | array of text   | Section 4.1.1.1  |
   |                       |      | strings         |                  |
   |                       |      |                 |                  |
   | guri                  | TBD  | array of text   | Section 4.1.1.1  |
   |                       |      | strings         |                  |
   |                       |      |                 |                  |
   | error                 | TBD  | int             | Section 4        |
   |                       |      |                 |                  |
   | error_description     | TBD  | text string     | Section 4        |
   +-----------------------+------+-----------------+------------------+

8.  ACE Groupcomm Error Identifiers

   This specification defines a number of values that the KDC can
   include as error identifiers, in the 'error' field of an error
   response with Content-Format application/ace-groupcomm+cbor.

     +-------+------------------------------------------------------+
     | Value | Description                                          |
     +-------+------------------------------------------------------+
     | 0     | Operation permitted only to group members            |
     |       |                                                      |
     | 1     | Request inconsistent with the current roles          |
     |       |                                                      |
     | 2     | Public key incompatible with the group configuration |
     |       |                                                      |
     | 3     | Invalid proof-of-possession signature                | TBD
     | array of text       | Section 4.1.1.1                                                      |
     | 4     | No available node identifiers                        | strings
     |       |
   +-----------------------+------+----------------+------------------+                                                      | guri
     | TBD 5     | array of text Group membership terminated                          | Section 4.1.1.1
     |       |                                                      |
     | strings 6     | Group deleted                                        |
   +-----------------------+------+----------------+------------------+
                                 Table 1

7.
     +-------+------------------------------------------------------+

9.  Security Considerations

   When a Client receives a message from a sender for the first time, it
   needs to have a mechanism in place to avoid replay, e.g.
   Appendix B.2 of [RFC8613].  In case the Client rebooted and lost the
   security state used to protect previous communication with that
   sender, such a mechanism is useful for the recipient to be on the
   safe side.

   Besides, if the KDC has renewed the group keying material, and the
   time interval between the end of the rekeying process and the joining
   of the Client is sufficiently small, that Client is also on the safe
   side, since replayed older messages protected with the previous
   keying material will not be accepted.

   The KDC must renew the group keying material upon its expiration.

   The KDC should renew the keying material upon group membership
   change, and should provide it to the current group members through
   the rekeying scheme used in the group.

   The KDC should renew the group keying material after rebooting, even
   in the case where all keying material is stored in persistent
   storage.  However, if the KDC relies on Observe responses to notify
   the group of renewed keying material, after rebooting the KDC will
   have lost all the current ongoing Observations with the group
   members, and the previous keying material will be used to protect
   messages in the group anyway.  The KDC will rely on each node
   requesting updates of the group keying material to establish the new
   keying material in the nodes, or, if implemented, it can push the
   update to the nodes in the group using the 'control_path' 'control_uri' resource.

   The KDC may enforce a rekeying policy that takes into account the
   overall time required to rekey the group, as well as the expected
   rate of changes in the group membership.

   That is, the KDC may not rekey the group at every membership change,
   for instance if members' joining and leaving occur frequently and
   performing a group rekeying takes too long.  The KDC may rekey the
   group after a minimum number of group members have joined or left
   within a given time interval, or after maximum amount of time since
   the last rekeying was completed, or yet during predictable network
   inactivity periods.

   However, this would result in the KDC not constantly preserving
   backward and forward security.  Newly joining group members could be
   able to access the keying material used before their joining, and
   thus could access past group communications.  Also, until the KDC
   performs a group rekeying, the newly leaving nodes would still be
   able to access upcoming group communications that are protected with
   the keying material that has not yet been updated.

   The KDC needs to have a mechanism in place to detect DoS attacks from
   nodes constantly initiating rekey events (for example by updating
   their public key), such as removing these nodes from the group.

   The KDC also needs to have a congestion control mechanism in place to
   avoid network congestion when the KDC renews the group keying
   material; CoAP and Observe give guidance on such mechanisms, see
   Section 4.7 of [RFC7252] and Section 4.5.1 of [RFC7641].

7.1.

9.1.  Update of Keying Material

   A group member can receive a message shortly after the group has been
   rekeyed, and new keying material has been distributed by the KDC.  In
   the following two cases, this may result in misaligned keying
   material between the group members.

   In the first case, the sender protects a message using the old keying
   material.  However, the recipient receives the message after having
   received the new keying material, hence not being able to correctly
   process it.  A possible way to ameliorate this issue is to preserve
   the old, recent, keying material for a maximum amount of time defined
   by the application.  By doing so, the recipient can still try to
   process the received message using the old retained keying material.
   Note that a former (compromised) group member can take advantage of
   this by sending messages protected with the old retained keying
   material.  Therefore, a conservative application policy should not
   admit the storage of old keying material.

   In the second case, the sender protects a message using the new
   keying material, but the recipient receives that request before
   having received the new keying material.  Therefore, the recipient
   would not be able to correctly process the request and hence discards
   it.  If the recipient receives the new keying material shortly after
   that and the application at the sender endpoint performs
   retransmissions, the former will still be able to receive and
   correctly process the message.  In any case, the recipient should
   actively ask the KDC for an updated keying material according to an
   application-defined policy, for instance after a given number of
   unsuccessfully decrypted incoming messages.

   A node that has left the group should not expect any of its outgoing
   messages to be successfully processed, if received after its leaving,
   due to a possible group rekeying occurred before the message
   reception.

7.2.

9.2.  Block-Wise Considerations

   If the block-wise options [RFC7959] are used, and the keying material
   is updated keying material
   is updated in the middle of a block-wise transfer, the sender of the
   blocks just changes the keying material to the updated one and
   continues the transfer.  As long as both sides get the new keying
   material, updating the keying material in the middle of a transfer
   will not cause any issue.  Otherwise, the sender will have to
   transmit the message again, when receiving an error message from the
   recipient.

   Compared to a scenario where the transfer does not use block-wise,
   depending on how fast the keying material is changed, the nodes might
   consume a larger amount of the network bandwidth resending the blocks
   again and again, which might be problematic.

10.  IANA Considerations

   This document has the following actions for IANA.

10.1.  Media Type Registrations

   This specification registers the 'application/ace-groupcomm+cbor'
   media type for messages of the protocols defined in this document
   following the ACE exchange and carrying parameters encoded in CBOR.
   This registration follows the procedures specified in [RFC6838].

   Type name: application
   Subtype name: ace-groupcomm+cbor

   Required parameters: N/A

   Optional parameters: N/A

   Encoding considerations: Must be encoded as CBOR map containing the
   protocol parameters defined in [this document].

   Security considerations: See Section 9 of this document.

   Interoperability considerations: n/a

   Published specification: [this document]

   Applications that use this media type: The type is used by
   authorization servers, clients and resource servers that support the
   ACE groupcomm framework as specified in [this document].

   Fragment identifier considerations: N/A

   Additional information: N/A

   Person & email address to contact for further information:
   iesg@ietf.org [1]

   Intended usage: COMMON

   Restrictions on usage: None

   Author: Francesca Palombini francesca.palombini@ericsson.com [2]

   Change controller: IESG

10.2.  CoAP Content-Formats Registry

   This specification registers the middle of a block-wise transfer, the sender of the
   blocks just changes the keying material following entry to the updated one and
   continues "CoAP
   Content-Formats" registry, within the transfer.  As long as both sides get "CoRE Parameters" registry:

   Media Type: application/ace-groupcomm+cbor

   Encoding: -

   ID: TBD

   Reference: [this document]

10.3.  OAuth Parameters Registry

   The following registrations are done for the new keying
   material, updating OAuth Parameters
   Registry following the keying material procedure specified in section 11.2 of
   [RFC6749]:

   o Parameter name: sign_info o Parameter usage location: token
   request, token response o Change Controller: IESG o Specification
   Document(s): [[This specification]]

   o Parameter name: kdcchallenge o Parameter usage location: token
   response o Change Controller: IESG o Specification Document(s):
   [[This specification]]

10.4.  OAuth Parameters CBOR Mappings Registry

   The following registrations are done for the middle OAuth Parameters CBOR
   Mappings Registry following the procedure specified in section 8.10
   of a transfer
   will not cause [I-D.ietf-ace-oauth-authz]:

   * Name: sign_info
   * CBOR Key: TBD (range -256 to 255)
   * Value Type: any issue.  Otherwise, the sender will have
   * Reference: \[\[This specification\]\]

   * Name: kdcchallenge
   * CBOR Key: TBD (range -256 to
   transmit the message again, when receiving an error message from 255)
   * Value Type: byte string
   * Reference: \[\[This specification\]\]

10.5.  ACE Groupcomm Parameters Registry

   This specification establishes the
   recipient.

   Compared "ACE Groupcomm Parameters" IANA
   Registry.  The Registry has been created to a scenario where the transfer does not use block-wise,
   depending on how fast the keying material "Expert Review"
   registration procedure [RFC8126].  Expert review guidelines are
   provided in Section 10.14.

   The columns of this Registry are:

   o  Name: This is changed, the nodes might
   consume a larger amount of the network bandwidth resending descriptive name that enables easier reference to
      the blocks
   again and again, which might item.  The name MUST be problematic.

8.  IANA Considerations

   This document has the following actions for IANA.

8.1.  Media Type Registrations

   This specification registers the 'application/ace-groupcomm+cbor'
   media type for messages of the protocols defined unique.  It is not used in this document
   following the ACE exchange and carrying parameters encoded in CBOR.
      encoding.

   o  CBOR Key: This registration follows is the procedures specified in [RFC6838].

   Type name: application

   Subtype name: ace-groupcomm+cbor

   Required parameters: none

   Optional parameters: none

   Encoding considerations: Must be encoded value used as CBOR map containing the
   protocol parameters defined in [this document].

   Security considerations: See Section 7 key of this document.

   Interoperability considerations: n/a

   Published specification: [this document]
   Applications that use this media type: the item.  These
      values MUST be unique.  The value can be a positive integer, a
      negative integer, or a string.

   o  CBOR Type: This contains the CBOR type is used by
   authorization servers, clients and resource servers that support of the
   ACE groupcomm framework as specified in [this document].

   Additional information: n/a

   Person & email address item, or a pointer
      to contact for further information:
   iesg@ietf.org (mailto:iesg@ietf.org)

   Intended usage: COMMON

   Restrictions the registry that defines its type, when that depends on usage: None

   Author: Francesca Palombini francesca.palombini@ericsson.com
   (mailto:francesca.palombini@ericsson.com)

   Change controller: IESG

8.2.  CoAP Content-Formats Registry
      another item.

   o  Reference: This specification registers the following entry contains a pointer to the "CoAP
   Content-Formats" registry, within public specification for
      the "CoRE Parameters" registry:

   Media Type: application/ace-groupcomm+cbor

   Encoding: -

   ID: TBD

   Reference: [this document]

8.3.  OAuth Parameters item.

   This Registry has been initially populated by the values in
   Section 7.  The following registrations are done Reference column for all of these entries refers to
   sections of this document.

10.6.  ACE Groupcomm Key Registry

   This specification establishes the OAuth ParametersRegistry
   following "ACE Groupcomm Key" IANA Registry.
   The Registry has been created to use the "Expert Review" registration
   procedure specified [RFC8126].  Expert review guidelines are provided in section 11.2
   Section 10.14.

   The columns of [RFC6749]:

   o Parameter name: sign_info o Parameter usage location: token
   request, token response o Change Controller: IESG this Registry are:

   o Specification
   Document(s): [[This specification]]  Name: This is a descriptive name that enables easier reference to
      the item.  The name MUST be unique.  It is not used in the
      encoding.

   o Parameter name: kdcchallenge  Key Type Value: This is the value used to identify the keying
      material.  These values MUST be unique.  The value can be a
      positive integer, a negative integer, or a text string.

   o Parameter usage location: token
   response  Profile: This field may contain one or more descriptive strings of
      application profiles to be used with this item.  The values should
      be taken from the Name column of the "ACE Groupcomm Profile"
      Registry.

   o Change Controller: IESG  Description: This field contains a brief description of the keying
      material.

   o Specification Document(s):
   [[This specification]]

8.4.  OAuth Parameters CBOR Mappings Registry

   The following registrations are done  References: This contains a pointer to the public specification
      for the OAuth Parameters CBOR
   Mappings format of the keying material, if one exists.

   This Registry following has been initially populated by the procedure specified values in section 8.9 Figure 8.
   The specification column for all of
   [I-D.ietf-ace-oauth-authz]:

   * Name: sign_info
   * CBOR Key: TBD (range -256 to 255)
   * Value Type: any
   * Reference: \[\[This specification\]\]

   * Name: kdcchallenge
   * CBOR Key: TBD (range -256 to 255)
   * Value Type: byte string
   * Reference: \[\[This specification\]\]

8.5. these entries will be this
   document.

10.7.  ACE Groupcomm Parameters Profile Registry

   This specification establishes the "ACE Groupcomm Parameters" Profile" IANA
   Registry.  The Registry has been created to use the "Expert Review
   Required" Review"
   registration procedure [RFC8126].  Expert review guidelines are
   provided in Section 8.11. 10.14.  It should be noted that, in addition to
   the expert review, some portions of the Registry require a
   specification, potentially a Standards Track RFC, to be supplied as
   well.

   The columns of this Registry are:

   *

   o  Name: This is a descriptive name that enables easier reference to
      the item. The name MUST be unique.  It is not used in the
      encoding.

   *  CBOR Key: This is of the value application profile, to be used as CBOR key value of
      the item.  These
      values MUST be unique.  The value can be a positive integer, a
      negative integer, or a string.

   *  CBOR Type: This contains profile attribute.

   o  Description: Text giving an overview of the application profile
      and the context it is developed for.

   o  CBOR type of Value: CBOR abbreviation for the item, or a pointer name of this application
      profile.  Different ranges of values use different registration
      policies [RFC8126].  Integer values from -256 to the registry that defines its type, when that depends on
      another item.

   * 255 are
      designated as Standards Action.  Integer values from -65536 to
      -257 and from 256 to 65535 are designated as Specification
      Required.  Integer values greater than 65535 are designated as
      Expert Review.  Integer values less than -65536 are marked as
      Private Use.

   o  Reference: This contains a pointer to the public specification for
      the item.

   This Registry has been initially populated by of
      the values in
   Section 6.  The Reference column abbreviation for all of these entries refers to
   sections of this document.

8.6. application profile, if one exists.

10.8.  ACE Groupcomm Key Policy Registry

   This specification establishes the "ACE Groupcomm Key" Policy" IANA
   Registry.  The Registry has been created to use the "Expert Review Required" Review"
   registration procedure [RFC8126].  Expert review guidelines are
   provided in Section 8.11. 10.14.  It should be noted that, in addition to
   the expert review, some portions of the Registry require a
   specification, potentially a Standards Track RFC, to be supplied as
   well.

   The columns of this Registry are:

   *

   o  Name: This is a descriptive name that enables easier reference to
      the item. The name MUST be unique.  It is not used in the
      encoding.

   *  Key Type Value: This is of the group communication policy.

   o  CBOR label: The value to be used to identify the keying
      material.  These values this group
      communication policy.  Key map labels MUST be unique.  The value label
      can be a positive integer, a negative integer, integer or a text string.

   *  Profile: This field may contain one or more descriptive
      Integer values between 0 and 255 and strings of
      application profiles to be used with this item.  The length 1 are
      designated as Standards Track Document required.  Integer values should
      be taken
      from the Name column 256 to 65535 and strings of length 2 are designated as
      Specification Required.  Integer values greater than 65535 and
      strings of length greater than 2 are designated as expert review.
      Integer values less than -65536 are marked as private use.

   o  CBOR type: the "ACE Groupcomm Profile"
      Registry.

   * CBOR type used to encode the value of this group
      communication policy.

   o  Description: This field contains a brief description of the keying
      material.

   *  References: for this
      group communication policy.

   o  Reference: This field contains a pointer to the public
      specification
      for providing the format of the keying material, group communication
      policy, if one exists.

   This Registry has been registry will be initially populated by the values in Figure 8.
   The specification column for all of these entries will be this
   document.

8.7.  ACE Groupcomm Profile 9.

10.9.  Sequence Number Synchronization Method Registry

   This specification establishes the "ACE Groupcomm Profile" "Sequence Number Synchronization
   Method" IANA Registry.  The Registry has been created to use the
   "Expert Review
   Required" Review" registration procedure [RFC8126].  Expert review
   guidelines are provided in Section 8.11. 10.14.  It should be noted that,
   in addition to the expert review, some portions of the Registry
   require a specification, potentially a Standards Track RFC, to be
   supplied as well.

   The columns of this Registry are:

   *

   o  Name: The name of the application profile, sequence number synchronization method.

   o  Value: The value to be used as value of
      the profile attribute.

   * to identify this sequence number
      synchronization method.

   o  Description: Text giving an overview of This field contains a brief description for this
      sequence number synchronization method.

   o  Reference: This field contains a pointer to the application profile
      and public
      specification describing the context it is developed for.

   *  CBOR Value: CBOR abbreviation for sequence number synchronization
      method.

10.10.  Interface Description (if=) Link Target Attribute Values
        Registry

   This specification registers the name of this application
      profile.  Different ranges of values use different registration
      policies [RFC8126].  Integer values from -256 following entry to 255 are
      designated as Standards Action.  Integer values from -65536 the "Interface
   Description (if=) Link Target Attribute Values Registry" registry,
   within the "CoRE Parameters" registry:

   o  Attribute Value: ace.group

   o  Description: The 'ace group' interface is used to
      -257 provision keying
      material and from 256 related information and policies to 65535 are designated as Specification
      Required.  Integer values greater than 65535 are designated as
      Expert Review.  Integer values less than -65536 are marked as
      Private Use.

   * members of a
      group using the Ace framework.

   o  Reference: [This Document]

10.11.  CBOR Tags Registry

   This contains a pointer specification registers the following entry to the public specification "CBOR Tags"
   registry:

   o  Tag : TBD_TAG

   o  Data Item: byte string

   o  Semantics: Extended ACE scope format, including the identifier of
      the abbreviation for this application profile, if one exists.

8.8. used scope semantics.

   o  Reference: [This Document]

10.12.  ACE Groupcomm Policy Registry Scope Semantics

   This specification establishes the "ACE Groupcomm Policy" Scope Semantics" IANA
   Registry.  The Registry has been created to use the "Expert Review
   Required" Review"
   registration procedure [RFC8126].  Expert review guidelines are
   provided in Section 8.11. 10.14.  It should be noted that, in addition to
   the expert review, some portions of the Registry require a
   specification, potentially a Standards Track RFC, to be supplied as
   well.

   The columns of this Registry are:

   *  Name: The name of the group communication policy.

   *  CBOR label:

   o  Value: The value to be used to identify this group
      communication policy.  Key map labels scope semantics.  The
      value MUST be unique.  The label value can be a positive integer, a negative integer or a string.
      negative integer.  Integer values between 0 and 255 and strings of length 1 are designated
      as Standards Track Document required.  Integer values from 256 to
      65535 and strings of length 2 are designated as Specification Required.  Integer values of
      greater than 65535 and
      strings of length greater than 2 are designated as expert review.  Integer
      values less than -65536 are marked as private use.

   *  CBOR type: the CBOR type used to encode the value of this group
      communication policy.

   *

   o  Description: This field contains a brief description for this
      group communication policy.

   * of the scope
      semantics.

   o  Reference: This field contains a pointer to the public
      specification providing the format of defining the group communication
      policy, scope semantics, if one exists.

   This registry will be initially populated by the values in Figure 9.

8.9.  Sequence Number Synchronization Method Registry

10.13.  ACE Groupcomm Errors

   This specification establishes the "Sequence Number Synchronization
   Method" "ACE Groupcomm Errors" IANA
   Registry.  The Registry has been created to use the "Expert Review Required" Review"
   registration procedure [RFC8126].  Expert review guidelines are
   provided in Section 8.11. 10.14.  It should be noted that, in addition to
   the expert review, some portions of the Registry require a
   specification, potentially a Standards Track RFC, to be supplied as
   well.

   The columns of this Registry are:

   *  Name: The name of the sequence number synchronization method.

   *

   o  Value: The value to be used to identify this sequence number
      synchronization method.

   * the error.  The value MUST
      be unique.  The value can be a positive integer or a negative
      integer.  Integer values between 0 and 255 are designated as
      Standards Track Document required.  Integer values from 256 to
      65535 are designated as Specification Required.  Integer values
      greater than 65535 are designated as expert review.  Integer
      values less than -65536 are marked as private use.

   o  Description: This field contains a brief description for this
      sequence number synchronization method.

   * of the error.

   o  Reference: This field contains a pointer to the public
      specification describing the sequence number synchronization
      method.

8.10.  Interface Description (if=) Link Target Attribute Values Registry

   This specification registers the following entry to defining the "Interface
   Description (if=) Link Target Attribute Values Registry" registry,
   within error, if one exists.

   This Registry has been initially populated by the "CoRE Parameters" registry:

   *  Attribute Value: ace.group

   *  Description: values in
   Section 8.  The 'ace group' interface is used to provision keying
      material and related informations and policies to members Reference column for all of a
      group using the Ace framework.

   *  Reference: [This Document]

8.11. these entries refers to
   this document.

10.14.  Expert Review Instructions

   The IANA Registries established in this document are defined as
   expert review.  This section gives some general guidelines for what
   the experts should be looking for, but they are being designated as
   experts for a reason so they should be given substantial latitude.

   Expert reviewers should take into consideration the following points:

   *

   o  Point squatting should be discouraged.  Reviewers are encouraged
      to get sufficient information for registration requests to ensure
      that the usage is not going to duplicate one that is already
      registered and that the point is likely to be used in deployments.
      The zones tagged as private use are intended for testing purposes
      and closed environments, code points in other ranges should not be
      assigned for testing.

   *

   o  Specifications are required for the standards track range of point
      assignment.  Specifications should exist for specification
      required ranges, but early assignment before a specification is
      available is considered to be permissible.  Specifications are
      needed for the first-come, first-serve range if they are expected
      to be used outside of closed environments in an interoperable way.
      When specifications are not provided, the description provided
      needs to have sufficient information to identify what the point is
      being used for.

   *

   o  Experts should take into account the expected usage of fields when
      approving point assignment.  The fact that there is a range for
      standards track documents does not mean that a standards track
      document cannot have points assigned outside of that range.  The
      length of the encoded value should be weighed against how many
      code points of that length are left, the size of device it will be
      used on, and the number of code points left that encode to that
      size.

9.

11.  References

9.1.

11.1.  Normative References

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

   [I-D.ietf-ace-aif]
              Bormann, C., "An Authorization Information Format (AIF)
              for ACE", draft-ietf-ace-aif-02 (work in progress),
              February 2021.

   [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)", Work in Progress, Internet-Draft,
              draft-ietf-ace-oauth-authz-35, 24 June 2020,
              <http://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-
              authz-35.txt>.

   [I-D.ietf-cbor-7049bis]
              Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", Work draft-ietf-ace-oauth-authz-37
              (work in Progress, Internet-Draft,
              draft-ietf-cbor-7049bis-16, 30 September 2020,
              <http://www.ietf.org/internet-drafts/draft-ietf-cbor-
              7049bis-16.txt>. progress), February 2021.

   [I-D.ietf-core-oscore-groupcomm]
              Tiloca, M., Selander, G., Palombini, F., Mattsson, J., and
              J. Park, "Group OSCORE - Secure Group Communication for
              CoAP", Work draft-ietf-core-oscore-groupcomm-11 (work in Progress, Internet-Draft, draft-ietf-core-oscore-
              groupcomm-09, 23 June 2020, <http://www.ietf.org/internet-
              drafts/draft-ietf-core-oscore-groupcomm-09.txt>.
              progress), February 2021.

   [I-D.ietf-cose-rfc8152bis-algs]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Initial Algorithms", Work draft-ietf-cose-rfc8152bis-algs-12
              (work in Progress, Internet-Draft,
              draft-ietf-cose-rfc8152bis-algs-12, 24 progress), September 2020,
              <http://www.ietf.org/internet-drafts/draft-ietf-cose-
              rfc8152bis-algs-12.txt>. 2020.

   [I-D.ietf-cose-rfc8152bis-struct]
              Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", Work draft-ietf-cose-rfc8152bis-
              struct-15 (work in Progress, Internet-Draft,
              draft-ietf-cose-rfc8152bis-struct-14, 24 September 2020,
              <http://www.ietf.org/internet-drafts/draft-ietf-cose-
              rfc8152bis-struct-14.txt>. progress), February 2021.

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

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

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/info/rfc6838>.

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

   [RFC7967]  Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
              Bose, "Constrained Application Protocol (CoAP) Option for
              No Server Response", RFC 7967, DOI 10.17487/RFC7967,
              August 2016, <https://www.rfc-editor.org/info/rfc7967>.

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

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

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://www.rfc-editor.org/info/rfc8610>.

   [RFC8742]  Bormann, C., "Concise Binary Object Representation (CBOR)
              Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
              <https://www.rfc-editor.org/info/rfc8742>.

   [RFC8747]  Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
              Tschofenig, "Proof-of-Possession Key Semantics for CBOR
              Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
              2020, <https://www.rfc-editor.org/info/rfc8747>.

9.2.  Informative References

   [I-D.ietf-ace-aif]

   [RFC8949]  Bormann, C., "An Authorization Information Format (AIF)
              for ACE", Work in Progress, Internet-Draft, draft-ietf-
              ace-aif-00, 29 July C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020, <http://www.ietf.org/internet-
              drafts/draft-ietf-ace-aif-00.txt>.
              <https://www.rfc-editor.org/info/rfc8949>.

11.2.  Informative References

   [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)", Work draft-ietf-ace-dtls-
              authorize-15 (work in Progress,
              Internet-Draft, draft-ietf-ace-dtls-authorize-14, 29
              October 2020, <http://www.ietf.org/internet-drafts/draft-
              ietf-ace-dtls-authorize-14.txt>. progress), January 2021.

   [I-D.ietf-ace-mqtt-tls-profile]
              Sengul, C. and A. Kirby, "Message Queuing Telemetry
              Transport (MQTT)-TLS profile of Authentication and
              Authorization for Constrained Environments (ACE)
              Framework", Work draft-ietf-ace-mqtt-tls-profile-10 (work in Progress, Internet-Draft, draft-ietf-
              ace-mqtt-tls-profile-08, 1 November 2020,
              <http://www.ietf.org/internet-drafts/draft-ietf-ace-mqtt-
              tls-profile-08.txt>.
              progress), December 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", Work draft-ietf-ace-
              oscore-profile-16 (work in Progress,
              Internet-Draft, draft-ietf-ace-oscore-profile-13, 27
              October 2020, <http://www.ietf.org/internet-drafts/draft-
              ietf-ace-oscore-profile-13.txt>. progress), January 2021.

   [I-D.ietf-core-coap-pubsub]
              Koster, M., Keranen, A., and J. Jimenez, "Publish-
              Subscribe Broker for the Constrained Application Protocol
              (CoAP)", Work draft-ietf-core-coap-pubsub-09 (work in Progress, Internet-Draft, draft-ietf-
              core-coap-pubsub-09, 30
              progress), September 2019,
              <http://www.ietf.org/internet-drafts/draft-ietf-core-coap-
              pubsub-09.txt>. 2019.

   [I-D.ietf-core-groupcomm-bis]
              Dijk, E., Wang, C., and M. Tiloca, "Group Communication
              for the Constrained Application Protocol (CoAP)", Work draft-
              ietf-core-groupcomm-bis-03 (work in
              Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
              01, 13 July 2020, <http://www.ietf.org/internet-drafts/
              draft-ietf-core-groupcomm-bis-01.txt>. progress), February
              2021.

   [RFC2093]  Harney, H. and C. Muckenhirn, "Group Key Management
              Protocol (GKMP) Specification", RFC 2093,
              DOI 10.17487/RFC2093, July 1997,
              <https://www.rfc-editor.org/info/rfc2093>.

   [RFC2094]  Harney, H. and C. Muckenhirn, "Group Key Management
              Protocol (GKMP) Architecture", RFC 2094,
              DOI 10.17487/RFC2094, July 1997,
              <https://www.rfc-editor.org/info/rfc2094>.

   [RFC2627]  Wallner, D., Harder, E., and R. Agee, "Key Management for
              Multicast: Issues and Architectures", RFC 2627,
              DOI 10.17487/RFC2627, June 1999,
              <https://www.rfc-editor.org/info/rfc2627>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

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

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
              "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
              May 2018, <https://www.rfc-editor.org/info/rfc8392>.

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://www.rfc-editor.org/info/rfc8610>. 10.17487/RFC8392,
              May 2018, <https://www.rfc-editor.org/info/rfc8392>.

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

11.3.  URIs

   [1] mailto:iesg@ietf.org

   [2] mailto:francesca.palombini@ericsson.com

Appendix A.  Requirements on Application Profiles

   This section lists the requirements on application profiles of this
   specification,for the convenience of application profile designers.

   *

   o  REQ1: If the value of the GROUPNAME URI path and the group name in
      the access token scope (gname in Section 3.2) don't match, specify
      the mechanism to map the GROUPNAME value in the URI to the group
      name (REQ1) (see Section 4.1).

   *

   o  REQ2: Specify the encoding and value of roles, for scope entries
      of 'scope' (see Section 3.1).

   *

   o  REQ3: If used, specify the acceptable values for 'sign_alg' (see
      Section 3.3).

   *

   o  REQ4: If used, specify the acceptable values for 'sign_parameters'
      (see Section 3.3).

   *

   o  REQ5: If used, specify the acceptable values for
      'sign_key_parameters' (see Section 3.3).

   *

   o  REQ6: If used, specify the acceptable values for 'pub_key_enc'
      (see Section 3.3).

   *  REQ7a:

   o  REQ7: Register a Resource Type for the root url-path, which is
      used to discover the correct url to access at the KDC (see
      Section 4.1).

   *  REQ7aa:

   o  REQ8: Define what operations (i.e. (e.g.  CoAP methods) are allowed on
      each resource, for each role defined in REQ2 (see Section 3.3).

   *  REQ7b:

   o  REQ9: Specify the exact encoding of group identifier (see
      Section 4.1.1.1).

   *  REQ7:

   o  REQ10: Specify the exact format of the 'key' value (see
      Section 4.1.2.1).

   *  REQ8:

   o  REQ11: Specify the acceptable values of 'gkty' (see
      Section 4.1.2.1).

   *  REQ9:

   o  REQ12: Specify the format of the identifiers of group members (see
      Section 4.1.2.1).

   *  REQ10:

   o  REQ13: Specify the communication protocol the members of the group
      must use (e.g., multicast CoAP).

   *  REQ11:

   o  REQ14: Specify the security protocol the group members must use to
      protect their communication (e.g., group OSCORE).  This must
      provide encryption, integrity and replay protection.

   *  REQ12:

   o  REQ15: Specify and register the application profile identifier
      (see Section 4.1.2.1).

   *  REQ13:

   o  REQ16: Specify policies at the KDC to handle ids that are not
      included in get_pub_keys 'get_pub_keys' (see Section 4.1.3.1).

   *  REQ14:

   o  REQ17: If used, specify the format and content of 'group_policies'
      and its entries.  Specify the policies default values (see
      Section 4.1.2.1).

   *  REQ15:

   o  REQ18: 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 4.1.6.2).

   *  REQ16:

   o  REQ19: Specify how the communication is secured between Client and
      KDC.  Optionally, specify tranport profile of ACE
      [I-D.ietf-ace-oauth-authz] to use between Client and KDC (see
      Section 4.3.

   *  REQ17:

   o  REQ20: Specify how the nonce N_S is generated, if the token was
      not posted (e.g. if it is used directly to validate TLS instead).

   *  REQ18:

   o  REQ21: Specify if 'mgt_key_material' used, and if yes specify its
      format and content (see Section 4.1.2.1).  If the usage of
      'mgt_key_material' is indicated and its format defined for a
      specific key management scheme, that format must explicitly
      indicate the key management scheme itself.  If a new rekeying
      scheme is defined to be used for an existing 'mgt_key_material' in
      an existing profile, then that profile will have to be updated
      accordingly, especially with respect to the usage of
      'mgt_key_material' related format and content.

   *  REQ19:

   o  REQ22: Define the initial value of the 'num' parameter (sse (see
      Section 4.1.2.1).

   *

   o  REQ23: Specify and register the identifier of newly defined
      semantics for binary scopes (see Section 6).

   o  OPT1: Optionally, specify the encoding of public keys, of
      'client_cred', and of 'pub_keys' if COSE_Keys are not used (see
      Section 4.1.2.1).

   *  OPT2a:

   o  OPT2: Optionally, specify the negotiation of parameter values for
      signature algorithm and signature keys, if 'sign_info' is not used
      (see Section 3.3).

   *  OPT2b:

   o  OPT3: Optionally, specify the additional parameters used in the
      Token Post exchange (see Section 3.3).

   *  OPT3:

   o  OPT4: Optionally, specify the encoding of 'pub_keys_repos' if the
      default is not used (see Section 4.1.2.1).

   *  OPT4:

   o  OPT5: Optionally, specify policies that instruct clients to retain
      messages and for how long, if they are unsuccessfully decrypted
      (see Section 4.4).  This makes it possible to decrypt such
      messages after getting updated keying material.

   *  OPT5:

   o  OPT6: Optionally, specify the behavior of the handler in case of
      failure to retrieve a public key for the specific node (see
      Section 4.1.2.1).

   *  OPT6:

   o  OPT7: Optionally, specify possible or required payload formats for
      specific error cases.

   *  OPT7:

   o  OPT8: Optionally, specify CBOR values to use for abbreviating
      identifiers of roles in the group or topic (see Section 3.1).

   *  OPT8:

   o  OPT9: Optionally, specify for the KDC to perform group rekeying
      (together or instead of renewing individual keying material) when
      receiving a Key Renewal Request (see Section 4.5).

   *  OPT9:

   o  OPT10: Optionally, specify the functionalities implemented at the
      'control_path'
      'control_uri' resource hosted at the Client, including message
      exchange encoding and other details (see Section 4.1.2.1).

   *  OPT10:

   o  OPT11: Optionally, specify how the identifier of the sender's
      public key is included in the group request (see Section 4.7).

   o  OPT12: Optionally, specify additional identifiers of error types,
      as values of the 'error' field in an error response from the KDC.

Appendix B.  Document Updates

   RFC EDITOR: PLEASE REMOVE THIS SECTION.

B.1.  Version -04 to -05

   *

   o  Updated uppercase/lowercase URI segments for KDC resources.

   *

   o  Supporting single Access Token for multiple groups/topics.

   *

   o  Added 'control_path' 'control_uri' parameter in the Joining Request.

   *

   o  Added 'peer_roles' parameter to support legal requesters/
      responders.

   *

   o  Clarification on stopping using owned keying material.

   *

   o  Clarification on different reasons for processing failures,
      related policies, and requirement OPT4.

   *

   o  Added a KDC sub-resource for group members to upload a new public
      key.

   *

   o  Possible group rekeying following an individual Key Renewal
      Request.

   *

   o  Clarified meaning of requirement REQ3; added requirement OPT8.

   *

   o  Editorial improvements.

B.2.  Version -03 to -04

   *

   o  Revised RESTful interface, as to methods and parameters.

   *

   o  Extended processing of joining request, as to check/retrieval of
      public keys.

   *

   o  Revised and extended profile requirements.

   *

   o  Clarified specific usage of parameters related to signature
      algorithms/keys.

   *

   o  Included general content previously in draft-ietf-ace-key-
      groupcomm-oscore

   *

   o  Registration of media type and content format application/ace-
      group+cbor

   *

   o  Editorial improvements.

B.3.  Version -02 to -03

   *

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

   *

   o  Restructured KDC interface, with new possible operations
      (Section 4).

   *

   o  Client PoP signature for the Joining Request upon joining
      (Section 4.1.2.1).

   *

   o  Revised text on group member removal (Section 5).

   *

   o  Added more profile requirements (Appendix A).

B.4.  Version -01 to -02

   *

   o  Editorial fixes.

   *

   o  Distinction between transport profile and application profile
      (Section 1.1).

   *

   o  New parameters 'sign_info' and 'pub_key_enc' to negotiate
      parameter values for signature algorithm and signature keys
      (Section 3.3).

   *

   o  New parameter 'type' to distinguish different Key Distribution
      Request messages (Section 4.1).

   *

   o  New parameter 'client_cred_verify' in the Key Distribution Request
      to convey a Client signature (Section 4.1).

   *

   o  Encoding of 'pub_keys_repos' (Section 4.1).

   *

   o  Encoding of 'mgt_key_material' (Section 4.1).

   *

   o  Improved description on retrieval of new or updated keying
      material (Section 6).

   *

   o  Encoding of 'get_pub_keys' in Public Key Request (Section 7.1).

   *

   o  Extended security considerations (Sections 10.1 and 10.2).

   *

   o  New "ACE Public Key Encoding" IANA Registry (Section 11.2).

   *

   o  New "ACE Groupcomm Parameters" IANA Registry (Section 11.3),
      populated with the entries in Section 8.

   *

   o  New "Ace Groupcomm Request Type" IANA Registry (Section 11.4),
      populated with the values in Section 9.

   *

   o  New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated
      with two entries "Sequence Number Synchronization Method" and "Key
      Update Check Interval" (Section 4.2).

   *

   o  Improved list of requirements for application profiles
      (Appendix A).

B.5.  Version -00 to -01

   *

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

   *

   o  Defined error handling on the KDC (Sections 4.2 and 6.2).

   *

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

   *

   o  Generalized format of 'pub_keys' in the Key Distribution Response
      (Section 4.2).

   *

   o  Defined format for the message to request leaving the group
      (Section 5.2).

   *

   o  Renewal of individual keying material and methods for group
      rekeying initiated by the KDC (Section 6).

   *

   o  CBOR type for node identifiers in 'get_pub_keys' (Section 7.1).

   *

   o  Added section on parameter identifiers and their CBOR keys
      (Section 8).

   *

   o  Added request types for requests to a Join Response (Section 9).

   *

   o  Extended security considerations (Section 10).

   *

   o  New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm
      Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence
      Number Synchronization Method Registry" (Section 11).

   *

   o  Added appendix about requirements for application profiles of ACE
      on group communication (Appendix A).

Acknowledgments

   The following individuals were helpful in shaping this document:
   Christian Amsuess, Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John
   Mattsson, Daniel Migault, Jim Schaad, Ludwig Seitz, Goeran Selander
   and Peter van der Stok.

   The work on this document has been partly supported by VINNOVA and
   the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home
   (Grant agreement 952652); and by the EIT-Digital High Impact
   Initiative ACTIVE.

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

   Email: francesca.palombini@ericsson.com

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

   Email: marco.tiloca@ri.se