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]