[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

ACE Working Group                                              M. Tiloca
Internet-Draft                                               R. Hoeglund
Intended status: Experimental                                    RISE AB
Expires: May 7, 2020                                     P. van der Stok
                                                              Consultant
                                                            F. Palombini
                                                             Ericsson AB
                                                       November 04, 2019


              Admin Interface for the OSCORE Group Manager
                  draft-tiloca-ace-oscore-gm-admin-00

Abstract

   Group communication for CoAP can be secured using Group Object
   Security for Constrained RESTful Environments (Group OSCORE).  A
   Group Manager is responsible to handle the joining of new group
   members, as well as to manage and distribute the group key material.
   This document defines a RESTful admin interface at the Group Manager,
   that allows an Administrator entity to create and delete OSCORE
   groups, as well as to retrieve and update their configuration.  The
   ACE framework for Authentication and Authorization is used to enforce
   authentication and authorization of the Administrator at the Group
   Manager.  Protocol-specific transport profiles of ACE are used to
   achieve communication security, proof-of-possession and server
   authentication.

Status of This Memo

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

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

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

   This Internet-Draft will expire on May 7, 2020.







Tiloca, et al.             Expires May 7, 2020                  [Page 1]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Overview of the Admin Interface . . . . . . . . . . . . . . .   6
   4.  Group-collection Resource . . . . . . . . . . . . . . . . . .   7
     4.1.  GET . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  POST  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Group-configuration Resource  . . . . . . . . . . . . . . . .  12
     5.1.  GET . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     5.2.  POST  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     5.3.  DELETE  . . . . . . . . . . . . . . . . . . . . . . . . .  14
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  ACE Groupcomm Parameters Registry . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252] can be used in
   group communication environments where messages are also exchanged
   over IP multicast [RFC7390][I-D.dijk-core-groupcomm-bis].
   Applications relying on CoAP can achieve end-to-end security at the
   application layer by using Object Security for Constrained RESTful
   Environments (OSCORE) [RFC8613], and especially Group OSCORE
   [I-D.ietf-core-oscore-groupcomm] in group communication scenarios.





Tiloca, et al.             Expires May 7, 2020                  [Page 2]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


   When group communication for CoAP is protected with Group OSCORE,
   nodes are required to explicitly join the correct OSCORE group.  To
   this end, a joining node interacts with a Group Manager (GM) entity
   responsible for that group, and retrieves the required key material
   to securely communicate with other group members using Group OSCORE.

   The method in [I-D.ietf-ace-key-groupcomm-oscore] specifies how nodes
   can join an OSCORE group through the respective Group Manager.  Such
   a method builds on the ACE framework for Authentication and
   Authorization [I-D.ietf-ace-oauth-authz], so ensuring a secure
   joining process as well as authentication and authorization of
   joining nodes (clients) at the Group Manager (resource server).

   This document specifies a RESTful admin interface at the Group
   Manager, intended for an Administrator entity.  This interface allows
   the Administrator to create and delete OSCORE groups, as well as to
   configure and update their configuration.  The ACE framework is used
   to ensure authentication and authorization of the Administrator
   (client) at the Group Manager (resource server).

   In order to achieve communication security, proof-of-possession and
   server authentication, the Administrator and the Group Manager
   leverage protocol-specific transport profiles of ACE, such as
   [I-D.ietf-ace-oscore-profile][I-D.ietf-ace-dtls-authorize].  These
   include also possible forthcoming transport profiles that comply with
   the requirements in Appendix C of [I-D.ietf-ace-oauth-authz].

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
   related to CBOR [RFC7049] and COSE [RFC8152], the CoAP protocol
   [RFC7252], as well as the protection and processing of CoAP messages
   using OSCORE [RFC8613], also in group communication scenarios using
   Group OSCORE [I-D.ietf-core-oscore-groupcomm].  These include the
   concept of Group Manager, as the entity responsible for a set of
   groups where communications among members are secured using Group
   OSCORE.

   Readers are also expected to be familiar with the terms and concept
   related to the management of keying material for groups in ACE
   defined in [I-D.ietf-ace-key-groupcomm], and in particular to the
   joining process for OSCORE groups defined in



Tiloca, et al.             Expires May 7, 2020                  [Page 3]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


   [I-D.ietf-ace-key-groupcomm-oscore].  These include the concept of
   group-membership resource hosted by the Group Manager, that new
   members access to join the OSCORE group, while current members can
   access to retrieve updated keying material.

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

   Note that, unless otherwise indicated, the term "endpoint" is used
   here following its OAuth definition, aimed at denoting resources such
   as /token and /introspect at the AS, and /authz-info at the RS.  This
   document does not use the CoAP definition of "endpoint", which is "An
   entity participating in the CoAP protocol".

   This document also refers to the following terminology.

   o  Administrator: entity responsible to create, configure and delete
      OSCORE groups at a Group Manager.

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

   o  Group-collection resource: a single-instance resource hosted by
      the Group Manager.  An Administrator accesses a group-collection
      resource to create a new OSCORE group, or to retrieve the list of
      existing OSCORE groups, under that Group Manager.  The URI of the
      group-collection resource is fixed and has /manage as last path
      segment.  The url-path /manage is a default name: implementations
      are not required to use this name, and can define their own
      instead.

   o  Group-configuration resource: a resource hosted by the Group
      Manager, associated to an OSCORE group under that Group Manager.
      A group-configuration resource is identifiable with the invariant
      group name of the respective group.  An Administrator accesses a
      group-configuration resource to retrieve or update the
      configuration of the respective OSCORE group, or to delete that
      group.  The URI of a group-configuration resource is fixed and has
      /manage/NAME as last path segments, with NAME the invariant group
      name specified upon its creation.  The url-path /manage/NAME is a
      default name: implementations are not required to use this name,
      and can define their own instead.



Tiloca, et al.             Expires May 7, 2020                  [Page 4]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


   o  Admin endpoint: an endpoint at the Group Manager associated to the
      group-collection resource or to a group-configuration resource
      hosted by that Group Manager.

2.  Protocol Overview

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

   o  The Group Manager acts as Resource Server (RS).  It provides one
      single group-collection resource, and one group-configuration
      resource per existing OSCORE group.  Each of those is exported by
      a distinct admin endpoint.

   o  The Administrator acts as Client (C), and requests to access the
      group-collection resource and group-configuration resources, by
      accessing the respective admin endpoint at the Group Manager.

   o  The Authorization Server (AS) authorizes the Administrator to
      access the group-collection resources and group-configuration
      resources at a Group Manager.  Multiple Group Managers can be
      associated to the same AS.  The AS MAY release Access Tokens for
      other purposes than accessing admin endpoints of registered Group
      Managers.

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

   In particular, communications between the Administrator and the Group
   Manager leverage protocol-specific transport profiles of ACE to
   achieve communication security, proof-of-possession and server
   authentication.  To this end, the AS may explicitly signal the
   specific transport profile to use, consistently with requirements and
   assumptions defined in the ACE framework [I-D.ietf-ace-oauth-authz].

   With reference to the AS, communications between the Administrator
   and the AS (/token endpoint) as well as between the Group Manager and
   the AS (/introspect endpoint) can be secured by different means, for
   instance using DTLS [RFC6347][I-D.ietf-tls-dtls13] or OSCORE
   [RFC8613].  Further details on how the AS secures communications
   (with the Administrator and the Group Manager) depend on the
   specifically used transport profile of ACE, and are out of the scope
   of this specification.

   In order to manage OSCORE groups at a Group Manager, an Administrator
   performs the following steps.





Tiloca, et al.             Expires May 7, 2020                  [Page 5]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


   1.  The Administrator requests an Access Token from the AS, in order
       to access the group-collection and group-configuration resources
       on the Group Manager.  The Administrator will start or continue
       using secure communications with the Group Manager, according to
       the response from the AS.

   2.  The Administrator transfers authentication and authorization
       information to the Group Manager by posting the obtained Access
       Token, according to the used profile of ACE, such as
       [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-oscore-profile].
       After that, the Administrator must have secure communication
       established with the Group Manager, before performing any admin
       operation on that Group Manager.  Possible ways to provide secure
       communication are DTLS [RFC6347][I-D.ietf-tls-dtls13] and OSCORE
       [RFC8613].  The Administrator and the Group Manager maintain the
       secure association, to support possible future communications.

   3.  The Administrator performs admin operations at the Group Manager,
       as described in the following sections.  These include the
       retrieval of the existing OSCORE groups, the creation of new
       OSCORE groups, the update and retrieval of group configurations,
       and the removal of OSCORE groups.  Messages exchanged among the
       Administrator and the Group Manager are specified in Section 4
       and Section 5.

3.  Overview of the Admin Interface

   Figure 1 shows the admin interface provided by the Group Manager and
   available to an Administrator.

     +++++++++++++++++
     +               +
     + Group Manager + --- /manage       Group-collection resource
     +               +
     +++++++++++++++++            |

                                  /gp1   Group-configuration resource

                                  |

                                  /gp2   Group-configuration resource

                                  |

                                 ...                 ...


              Figure 1: Admin Interface at the Group Manager



Tiloca, et al.             Expires May 7, 2020                  [Page 6]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


   The Group Manager exports a single group-collection resource,
   accessible at /manage.  The full interface for the group-collection
   resource is described in Section 4, and it allows the Administrator
   to:

   o  Retrieve the list of existing OSCORE groups.

   o  Create a new OSCORE group, specifying its invariant group name
      and, optionally, its configuration.

   The Group Manager exports one group-configuration resource for each
   of its OSCORE groups.  Each group-configuration resource is
   identified by the group name specified upon creating the group.  In
   particular, the group-configuration resource for the OSCORE group
   with group name "gp1" is accessible at /manage/gp1.  The full
   interface for a group-configuration resource is described in
   Section 5, and it allows the Administrator to:

   o  Retrieve the current configuration of the OSCORE group.

   o  Update the current configuration of the OSCORE group.

   o  Delete the OSCORE group.

4.  Group-collection Resource

   This section describes the operations available on the group-
   collection resource.

   The examples below consider a Group Manager at coap://gm.example.com
   and with address 2001:db8::ab.

4.1.  GET

   The Administrator can send a GET request to the group-collection
   resource in order to retrieve the list of the existing OSCORE groups
   at the Group Manager.  This is returned as a list of links to the
   corresponding group-configuration resources.  Note that such links
   can be obtained also by sending a GET request to the Group Manager at
   /.well-known/core .

   Request: Administrator -> Group Manager

   Req: GET coap://gm.example.com/manage

   Response: Group Manager -> Administrator





Tiloca, et al.             Expires May 7, 2020                  [Page 7]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


   Res: 2.05 Content
   Payload:
   <coap://[2001:db8::ab]/manage/gp1>;ct=40,
   <coap://[2001:db8::ab]/manage/gp2>;ct=40,
   <coap://[2001:db8::ab]/manage/gp3>;ct=40

4.2.  POST

   The Administrator can send a POST request to the group-collection
   resource in order to create a new OSCORE group at the Group Manager.
   The request MUST specify the intended group name NAME, and MAY
   specify pieces of information concerning the group configuration.

   The request has content format application/cbor (ct=60), and its
   payload is a CBOR map which MUST include the following parameters:

   o  'group_name', with value the group name of the new OSCORE group to
      create, encoded as a CBOR text string or a CBOR byte string.  In
      the latter case, the byte string MUST be the utf-8 encoding of the
      group name.  This parameter is defined in Section 7.1 of this
      specification.

   The CBOR map in the request payload MAY also include the following
   parameters:

   o  'group_conf', with value a Group_OSCORE_Security_Context object as
      defined in Section 4.3 of [I-D.ietf-ace-key-groupcomm-oscore].
      This parameter is defined in Section 7.1 and MAY contain the
      following fields, which if included, MUST have the corresponding
      values:

      *  'hkdf', defined in Section 3.2.1 of
         [I-D.ietf-ace-oscore-profile].

      *  'alg', defined in Section 3.2.1 of
         [I-D.ietf-ace-oscore-profile].

      *  'rpl', defined in Section 3.2.1 of
         [I-D.ietf-ace-oscore-profile].

      *  'cs_alg', defined in Section 4.3 of
         [I-D.ietf-ace-key-groupcomm-oscore].

      *  'cs_params', defined in Section 4.3 of
         [I-D.ietf-ace-key-groupcomm-oscore].

      *  'cs_key_params', defined in Section 4.3 of
         [I-D.ietf-ace-key-groupcomm-oscore].



Tiloca, et al.             Expires May 7, 2020                  [Page 8]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


      *  'cs_key_enc', defined in Section 4.3 of
         [I-D.ietf-ace-key-groupcomm-oscore].

   o  'profile', defined in Section 4.1.2.1 of
      [I-D.ietf-ace-key-groupcomm].  If present, this parameter has
      value "coap_group_oscore_app".

   o  'exp', defined in Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm].

   o  'group_policies', defined in Section 4.1.2.1 of
      [I-D.ietf-ace-key-groupcomm], and consistent with the format and
      content defined in Section 4.3 of
      [I-D.ietf-ace-key-groupcomm-oscore].

   Request: Administrator -> Group Manager

   Req: POST coap://gm.example.com/manage
   Content-Format: 60
   Payload:
     {
       "group_name" : "gp4",
       "group_conf" : {
          (remainder of 'group_conf' omitted for brevity)
       }
     }

   If any of the following occurs, the Group Manager MUST respond with a
   4.00 (Bad Request) response, which MAY include additional information
   to clarify what went wrong.

   o  Any of the expected parameters is missing in the request, or any
      of the received parameters is not recognized or not valid.

   o  The 'group_name' parameter in the request specifies the group name
      of an already existing OSCORE group.

   After a successful processing of the request above, the Group Manager
   performs the following actions.

   First, the Group Manager creates a new group-configuration resource,
   accessible to the administrator at /manage/NAME , where NAME is the
   group name indicated in the parameter 'group_name' above.  The values
   specified in the request are used as group configuration information
   for the newly created OSCORE group.  For each configuration parameter
   not specified in the request, the Group Manager MUST assume a pre-
   configured default value when creating the group-configuration
   resource.




Tiloca, et al.             Expires May 7, 2020                  [Page 9]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


   In particular, the Group Manager SHOULD use the same default values
   in Section 3.2 of [RFC8613] for 'hkdf', 'alg' and 'rpl'.  Also, the
   Group Manager SHOULD use the following as default values for
   'cs_alg', 'cs_params', 'cs_key_params' and 'cs_key_enc', consistently
   with the "COSE Algorithms" Registry defined in Section 16.4 of
   [RFC8152], as well as with the "Counter Signature Parameters"
   Registry and "Counter Signature Key Parameters" Registry defined in
   Sections 9.1 and 9.2 of [I-D.ietf-core-oscore-groupcomm].

   o  For 'cs_alg', the countersignature algorithm EdDSA [RFC8032].

   o  For 'cs_params':

      *  The elliptic curve Ed25519 [RFC8032], in case EdDSA is assumed
         or specified for 'cs_alg'.

      *  The elliptic curve P-256/P-384/P-521, in case ES256/ES384/ES521
         [RFC6979] is specified for 'cs_alg'.

   o  For 'cs_key_params':

      *  The array [OKP, Ed25519] as pair (key type, elliptic curve), in
         case EdDSA is assumed or specified for 'cs_alg' and Ed25519 is
         assumed or specified for 'cs_params'.

      *  The array [OKP, Ed448] as pair (key type, elliptic curve), in
         case EdDSA is assumed or specified for 'cs_alg' and the
         elliptic curve Ed448 [RFC8032] is specified for 'cs_params'.

      *  The array [EC2, P-256] as pair (key type, elliptic curve), in
         case ES256 [RFC6979] is specified for 'cs_alg' and the elliptic
         curve P-256 is assumed or specified for 'cs_params'.

      *  The array [EC2, P-384] as pair (key type, elliptic curve), in
         case ES384 [RFC6979] is specified for 'cs_alg' and the elliptic
         curve P-384 is specified for 'cs_params'.

      *  The array [EC2, P-521] as pair (key type, elliptic curve), in
         case ES512 [RFC6979] is specified for 'cs_alg' and the elliptic
         curve P-521 is specified for 'cs_params'.

      *  RSA as key type, if PS256, PS384 or PS512 [RFC8017] is
         specified for 'cs_alg'.

   o  For 'cs_key_enc', the value 1 ("COSE_Key") from the "CWT
      Confirmation Methods" Registry defined in Section 7.2 of
      [I-D.ietf-ace-cwt-proof-of-possession].




Tiloca, et al.             Expires May 7, 2020                 [Page 10]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


   After that, the Group Manager creates a new group-membership
   resource, accessible to joining nodes and future group members at
   group-oscore/NAME , as specified in
   [I-D.ietf-ace-key-groupcomm-oscore].  In particular, the Group
   Manager will rely on the current group configuration to build the
   Joining Response message defined in Section 4.3 of
   [I-D.ietf-ace-key-groupcomm-oscore], when handling the joining of a
   new group member.  Furthermore, the Group Manager generates the
   following pieces of information, and assigns them to the newly
   created OSCORE group.

   o  The OSCORE Master Secret.

   o  The OSCORE Master Salt (optionally).

   o  The OSCORE ID Context, acting as Group ID, which MUST be unique
      within the set of OSCORE groups under the Group Manager.

   Finally, the Group Manager replies to the Administrator with a 2.01
   (Created) response.  The Location-Path option MUST be included in the
   response, indicating the location of the just created group-
   configuration resource.  The response MUST NOT include a Location-
   Query option.  The response has content format application/cbor
   (ct=60), and its payload is a CBOR map which MUST include the
   following parameters:

   o  'group_name', with value the group name of the newly created
      OSCORE group, encoded as in the POST request defined above.

   o  'group_conf', with value a Group_OSCORE_Security_Context object as
      defined in Section 4.3 of [I-D.ietf-ace-key-groupcomm-oscore].
      This parameters MUST contain the following fields, which specify
      the configuration of the newly created OSCORE group:

      *  'hkdf', defined in Section 3.2.1 of
         [I-D.ietf-ace-oscore-profile].

      *  'alg', defined in Section 3.2.1 of
         [I-D.ietf-ace-oscore-profile].

      *  'rpl', defined in Section 3.2.1 of
         [I-D.ietf-ace-oscore-profile].

      *  'cs_alg', defined in Section 4.3 of
         [I-D.ietf-ace-key-groupcomm-oscore].

      *  'cs_params', defined in Section 4.3 of
         [I-D.ietf-ace-key-groupcomm-oscore].



Tiloca, et al.             Expires May 7, 2020                 [Page 11]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


      *  'cs_key_params', defined in Section 4.3 of
         [I-D.ietf-ace-key-groupcomm-oscore].

      *  'cs_key_enc', defined in Section 4.3 of
         [I-D.ietf-ace-key-groupcomm-oscore].

   o  'profile', defined in Section 4.1.2.1 of
      [I-D.ietf-ace-key-groupcomm].  This parameter has value
      "coap_group_oscore_app".

   o  'exp', defined in Section 4.1.2.1 of [I-D.ietf-ace-key-groupcomm].

   o  'joining_path', with value the URI of the group-membership
      resource for joining the newly created OSCORE group, encoded as a
      CBOR text string.  This parameter is defined in Section 7.1 of
      this specification.

   The response MAY also include the following parameters:

   o  'group_policies', defined in Section 4.1.2.1 of
      [I-D.ietf-ace-key-groupcomm], and consistent with the format and
      content defined in Section 4.3 of
      [I-D.ietf-ace-key-groupcomm-oscore].

   Response: Group Manager -> Administrator

   Res: 2.01 Created
   Content-Format: 60
   Location-Path: /manage/gp4
   Payload:
     {
       "group_name" : "gp4",
       "group_conf" : {
          (remainder of 'group_conf' omitted for brevity)
       }
       "profile" : "coap_group_oscore_app",
       "exp" : "1360289224",
       "joining_path" : "coap://[2001:db8::ab]/group-oscore/gp4/",
     }

5.  Group-configuration Resource

   This section describes the operations available on a group-
   configuration resource.

   The examples below refer to the same Group Manager considered in
   Section 4.2.




Tiloca, et al.             Expires May 7, 2020                 [Page 12]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


5.1.  GET

   The Administrator can send a GET request to the group-configuration
   resource manage/NAME associated to an OSCORE group with group name
   NAME, in order to retrieve the current configuration of that group.

   Request: Administrator -> Group Manager

   Req: GET coap://gm.example.com/manage/gp2

   If the request refers to a non-existing OSCORE group, i.e. is sent to
   a non-existing group-configuration resource, the Group Manager MUST
   respond with a 4.04 (Not Found) response.

   After a successful processing of the request above, the Group Manager
   replies to the Administrator with a 2.05 (Content) response.  The
   response has content format application/cbor (ct=60), and its payload
   has the same format of the 2.01 (Created) response in Section 4.2.
   The exact content of the payload reflects the current configuration
   of the OSCORE group.

5.2.  POST

   The Administrator can send a POST request to the group-configuration
   resource manage/NAME associated to an OSCORE group with group name
   NAME.  The payload of the request has the same format of the POST
   request defined in Section 4.2, except for the 'group_name' parameter
   that MUST NOT be included.

   If the request refers to a non-existing OSCORE group, i.e. is sent to
   a non-existing group-configuration resource, the Group Manager MUST
   respond with a 4.04 (Not Found) response.

   After a successful processing of the request above, the Group Manager
   performs the following actions.

   First, it updates the configuration of the OSCORE group with group
   name NAME, consistently with the values indicated in the request from
   the Administrator.  For each configuration parameter not specified in
   the request, the Group Manager MUST retain the current value for that
   parameter in the configuration of that group.  From then on, the
   Group Manager relies on the latest update configuration to build the
   Join Response message defined in Section 4.3 of
   [I-D.ietf-ace-key-groupcomm-oscore], when handling the joining of a
   new group member.

   Second, the Group Manager replies to the Administrator with a 2.04
   (Changed) response.  The response has content format application/cbor



Tiloca, et al.             Expires May 7, 2020                 [Page 13]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


   (ct=60), and its payload has the same format of the 2.01 (Created)
   response in Section 4.2.  The exact content of the payload reflects
   the latest configuration of the OSCORE group, after the requested
   update.

5.3.  DELETE

   The Administrator can send a DELETE request to the group-
   configuration resource manage/NAME associated to an OSCORE group with
   group name NAME, in order to delete that group.

   Request: Administrator -> Group Manager

   Req: DELETE coap://gm.example.com/manage/gp1

   If the request refers to a non-existing OSCORE group, i.e. is sent to
   a non-existing group-configuration resource, the Group Manager MUST
   respond with a 4.04 (Not Found) response.

   After a successful processing of the request above, the Group Manager
   performs the following actions.

   First, the Group Manager deletes the OSCORE group and deallocates
   both the group-configuration resource at manage/NAME as well as the
   group-membership resource group-oscore/NAME .

   Second, the Group Manager replies to the Administrator with a 2.02
   (Deleted) response.

   Response: Group Manager -> Administrator

   Res: 2.02 Deleted

6.  Security Considerations

   Security considerations are inherited from the ACE framework for
   Authentication and Authorization [I-D.ietf-ace-oauth-authz], and from
   the specific transport profile of ACE used between the Administrator
   and the Group Manager, such as [I-D.ietf-ace-dtls-authorize] and
   [I-D.ietf-ace-oscore-profile].

7.  IANA Considerations

   This document has the following actions for IANA.







Tiloca, et al.             Expires May 7, 2020                 [Page 14]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


7.1.  ACE Groupcomm Parameters Registry

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

   Name: group_name

   CBOR Key: TBD

   CBOR Type: tstr / bstr

   Reference: [[This specification]]

   Name: group_conf

   CBOR Key: TBD

   CBOR Type: map

   Reference: [[This specification]]

   Name: joining_path

   CBOR Key: TBD

   CBOR Type: tstr

   Reference: [[This specification]]

8.  References

8.1.  Normative References

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

   [I-D.ietf-ace-key-groupcomm]
              Palombini, F. and M. Tiloca, "Key Provisioning for Group
              Communication using ACE", draft-ietf-ace-key-groupcomm-02
              (work in progress), July 2019.







Tiloca, et al.             Expires May 7, 2020                 [Page 15]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


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

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

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

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

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

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

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

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

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <https://www.rfc-editor.org/info/rfc7049>.





Tiloca, et al.             Expires May 7, 2020                 [Page 16]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


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

   [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
              "PKCS #1: RSA Cryptography Specifications Version 2.2",
              RFC 8017, DOI 10.17487/RFC8017, November 2016,
              <https://www.rfc-editor.org/info/rfc8017>.

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

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

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

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

8.2.  Informative References

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

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

   [I-D.ietf-tls-dtls13]
              Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", draft-ietf-tls-dtls13-33 (work in progress), October
              2019.




Tiloca, et al.             Expires May 7, 2020                 [Page 17]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


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

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

Acknowledgments

   The authors sincerely thank Jim Schaad for his comments and feedback.

   The work on this document has been partly supported by VINNOVA and
   the Celtic-Next project CRITISEC.

Authors' Addresses

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

   Email: marco.tiloca@ri.se


   Rikard Hoeglund
   RISE AB
   Isafjordsgatan 22
   Kista  SE-16440 Stockholm
   Sweden

   Email: rikard.hoglund@ri.se


   Peter van der Stok
   Consultant

   Phone: +31-492474673 (Netherlands), +33-966015248 (France)
   Email: consultancy@vanderstok.org
   URI:   www.vanderstok.org









Tiloca, et al.             Expires May 7, 2020                 [Page 18]


Internet-Draft      Admin Interface for the OSCORE GM      November 2019


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

   Email: francesca.palombini@ericsson.com












































Tiloca, et al.             Expires May 7, 2020                 [Page 19]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/