< draft-ietf-ace-oscore-gm-admin-04.txt   draft-ietf-ace-oscore-gm-admin-05.txt >
ACE Working Group M. Tiloca ACE Working Group M. Tiloca
Internet-Draft R. Höglund Internet-Draft R. Höglund
Intended status: Standards Track RISE AB Intended status: Standards Track RISE AB
Expires: 28 April 2022 P. van der Stok Expires: 8 September 2022 P. van der Stok
Consultant Consultant
F. Palombini F. Palombini
Ericsson AB Ericsson AB
25 October 2021 7 March 2022
Admin Interface for the OSCORE Group Manager Admin Interface for the OSCORE Group Manager
draft-ietf-ace-oscore-gm-admin-04 draft-ietf-ace-oscore-gm-admin-05
Abstract Abstract
Group communication for CoAP can be secured using Group Object Group communication for CoAP can be secured using Group Object
Security for Constrained RESTful Environments (Group OSCORE). A Security for Constrained RESTful Environments (Group OSCORE). A
Group Manager is responsible to handle the joining of new group Group Manager is responsible to handle the joining of new group
members, as well as to manage and distribute the group keying members, as well as to manage and distribute the group keying
material. This document defines a RESTful admin interface at the material. This document defines a RESTful admin interface at the
Group Manager, that allows an Administrator entity to create and Group Manager, that allows an Administrator entity to create and
delete OSCORE groups, as well as to retrieve and update their delete OSCORE groups, as well as to retrieve and update their
configuration. The ACE framework for Authentication and configuration. The ACE framework for Authentication and
Authorization is used to enforce authentication and authorization of Authorization is used to enforce authentication and authorization of
the Administrator at the Group Manager. Protocol-specific transport the Administrator at the Group Manager. Protocol-specific transport
profiles of ACE are used to achieve communication security, proof-of- profiles of ACE are used to achieve communication security, proof-of-
possession and server authentication. possession and server authentication.
Discussion Venues Discussion Venues
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the ACE Working Group Discussion of this document takes place on the Authentication and
mailing list (ace@ietf.org), which is archived at Authorization for Constrained Environments Working Group mailing list
(ace@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/ace/. https://mailarchive.ietf.org/arch/browse/ace/.
Source for this draft and an issue tracker can be found at Source for this draft and an issue tracker can be found at
https://github.com/ace-wg/ace-oscore-gm-admin. https://github.com/ace-wg/ace-oscore-gm-admin.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 April 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Group Administration . . . . . . . . . . . . . . . . . . . . 6 2. Group Administration . . . . . . . . . . . . . . . . . . . . 7
2.1. Getting Access to the Group Manager . . . . . . . . . . . 7 2.1. Managing OSCORE Groups . . . . . . . . . . . . . . . . . 7
2.1.1. Format of Scope . . . . . . . . . . . . . . . . . . . 8 2.2. Collection Representation . . . . . . . . . . . . . . . . 9
2.2. Managing OSCORE Groups . . . . . . . . . . . . . . . . . 9 2.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Collection Representation . . . . . . . . . . . . . . . . 10 3. Format of Scope . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Getting Access to the Group Manager . . . . . . . . . . . . . 13
3. Group Configurations . . . . . . . . . . . . . . . . . . . . 10 5. Group Configurations . . . . . . . . . . . . . . . . . . . . 17
3.1. Group Configuration Representation . . . . . . . . . . . 10 5.1. Group Configuration Representation . . . . . . . . . . . 17
3.1.1. Configuration Properties . . . . . . . . . . . . . . 11 5.1.1. Configuration Properties . . . . . . . . . . . . . . 17
3.1.2. Status Properties . . . . . . . . . . . . . . . . . . 13 5.1.2. Status Properties . . . . . . . . . . . . . . . . . . 19
3.2. Default Values . . . . . . . . . . . . . . . . . . . . . 14 5.2. Default Values . . . . . . . . . . . . . . . . . . . . . 21
3.2.1. Configuration Parameters . . . . . . . . . . . . . . 14 5.2.1. Configuration Parameters . . . . . . . . . . . . . . 21
3.2.2. Status Parameters . . . . . . . . . . . . . . . . . . 15 5.2.2. Status Parameters . . . . . . . . . . . . . . . . . . 21
4. Interactions with the Group Manager . . . . . . . . . . . . . 15 6. Interactions with the Group Manager . . . . . . . . . . . . . 22
4.1. Retrieve the Full List of Groups Configurations . . . . . 16 6.1. Retrieve the Full List of Group Configurations . . . . . 22
4.2. Retrieve a List of Group Configurations by Filters . . . 16 6.2. Retrieve a List of Group Configurations by Filters . . . 23
4.3. Create a New Group Configuration . . . . . . . . . . . . 18 6.3. Create a New Group Configuration . . . . . . . . . . . . 25
4.4. Retrieve a Group Configuration . . . . . . . . . . . . . 23 6.4. Retrieve a Group Configuration . . . . . . . . . . . . . 31
4.5. Retrieve Part of a Group Configuration by Filters . . . . 25 6.5. Retrieve Part of a Group Configuration by Filters . . . . 33
4.6. Overwrite a Group Configuration . . . . . . . . . . . . . 28 6.6. Overwrite a Group Configuration . . . . . . . . . . . . . 36
4.6.1. Effects on Joining Nodes . . . . . . . . . . . . . . 31 6.6.1. Effects on Joining Nodes . . . . . . . . . . . . . . 39
4.6.2. Effects on the Group Members . . . . . . . . . . . . 31 6.6.2. Effects on the Group Members . . . . . . . . . . . . 40
4.7. Selective Update of a Group Configuration . . . . . . . . 33 6.7. Selective Update of a Group Configuration . . . . . . . . 42
4.7.1. Effects on Joining Nodes . . . . . . . . . . . . . . 37 6.7.1. Effects on Joining Nodes . . . . . . . . . . . . . . 46
4.7.2. Effects on the Group Members . . . . . . . . . . . . 38 6.7.2. Effects on the Group Members . . . . . . . . . . . . 47
4.8. Delete a Group Configuration . . . . . . . . . . . . . . 38 6.8. Delete a Group Configuration . . . . . . . . . . . . . . 47
4.8.1. Effects on the Group Members . . . . . . . . . . . . 39 6.8.1. Effects on the Group Members . . . . . . . . . . . . 48
5. ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . . 39 7. ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . . 49
6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
7.1. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . 40 9.1. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . 50
7.2. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 42 9.2. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 51
7.3. Resource Types . . . . . . . . . . . . . . . . . . . . . 42 9.3. Resource Types . . . . . . . . . . . . . . . . . . . . . 51
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 9.4. Group OSCORE Admin Permissions . . . . . . . . . . . . . 51
8.1. Normative References . . . . . . . . . . . . . . . . . . 42 9.5. AIF . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.2. Informative References . . . . . . . . . . . . . . . . . 45 9.6. CoAP Content-Format . . . . . . . . . . . . . . . . . . . 53
Appendix A. Document Updates . . . . . . . . . . . . . . . . . . 46 9.7. ACE Scope Semantics . . . . . . . . . . . . . . . . . . . 53
A.1. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 46 9.8. Expert Review Instructions . . . . . . . . . . . . . . . 54
A.2. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 46 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.3. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 47 10.1. Normative References . . . . . . . . . . . . . . . . . . 54
A.4. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 47 10.2. Informative References . . . . . . . . . . . . . . . . . 57
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 47 Appendix A. Document Updates . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 A.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 59
A.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 60
A.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 60
A.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 60
A.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 60
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] can be used in The Constrained Application Protocol (CoAP) [RFC7252] can be used in
group communication environments where messages are also exchanged group communication environments where messages are also exchanged
over IP multicast [I-D.ietf-core-groupcomm-bis]. Applications over IP multicast [I-D.ietf-core-groupcomm-bis]. Applications
relying on CoAP can achieve end-to-end security at the application relying on CoAP can achieve end-to-end security at the application
layer by using Object Security for Constrained RESTful Environments layer by using Object Security for Constrained RESTful Environments
(OSCORE) [RFC8613], and especially Group OSCORE (OSCORE) [RFC8613], and especially Group OSCORE
[I-D.ietf-core-oscore-groupcomm] in group communication scenarios. [I-D.ietf-core-oscore-groupcomm] in group communication scenarios.
skipping to change at page 4, line 28 skipping to change at page 4, line 39
Manager, intended for an Administrator as a separate entity external Manager, intended for an Administrator as a separate entity external
to the Group Manager and its application. The interface allows the to the Group Manager and its application. The interface allows the
Administrator to create and delete OSCORE groups, as well as to Administrator to create and delete OSCORE groups, as well as to
configure and update their configuration. configure and update their configuration.
Interaction examples are provided, in Link Format [RFC6690] and CBOR Interaction examples are provided, in Link Format [RFC6690] and CBOR
[RFC8949], as well as in CoRAL [I-D.ietf-core-coral]. While all the [RFC8949], as well as in CoRAL [I-D.ietf-core-coral]. While all the
CoRAL examples show the CoRAL textual serialization format, its CoRAL examples show the CoRAL textual serialization format, its
binary serialization format is used on the wire. binary serialization format is used on the wire.
[ NOTE:
The reported CoRAL examples are based on the textual representation
used until version -03 of [I-D.ietf-core-coral]. These will be
revised to use the CBOR diagnostic notation instead.
]
The ACE framework is used to ensure authentication and authorization The ACE framework is used to ensure authentication and authorization
of the Administrator (client) at the Group Manager (resource server). of the Administrator (client) at the Group Manager (resource server).
In order to achieve communication security, proof-of-possession and In order to achieve communication security, proof-of-possession and
server authentication, the Administrator and the Group Manager server authentication, the Administrator and the Group Manager
leverage protocol-specific transport profiles of ACE, such as leverage protocol-specific transport profiles of ACE, such as
[I-D.ietf-ace-oscore-profile][I-D.ietf-ace-dtls-authorize]. These [I-D.ietf-ace-oscore-profile][I-D.ietf-ace-dtls-authorize]. These
include also possible forthcoming transport profiles that comply with include also possible forthcoming transport profiles that comply with
the requirements in Appendix C of [I-D.ietf-ace-oauth-authz]. the requirements in Appendix C of [I-D.ietf-ace-oauth-authz].
1.1. Terminology 1.1. Terminology
skipping to change at page 5, line 17 skipping to change at page 5, line 39
- "application group", as a set of CoAP nodes that share a common - "application group", as a set of CoAP nodes that share a common
set of resources; and of set of resources; and of
- "security group", as a set of CoAP nodes that share the same - "security group", as a set of CoAP nodes that share the same
security material, and use it to protect and verify exchanged security material, and use it to protect and verify exchanged
messages. messages.
* The OSCORE [RFC8613] and Group OSCORE * The OSCORE [RFC8613] and Group OSCORE
[I-D.ietf-core-oscore-groupcomm] security protocols. These [I-D.ietf-core-oscore-groupcomm] security protocols. These
include the concept of Group Manager, as the entity responsible especially include the concepts of:
for a set of OSCORE groups where communications among members are
secured using Group OSCORE. An OSCORE group is used as security - Group Manager, as the entity responsible for a set of OSCORE
group for one or many application groups. groups where communications among members are secured using
Group OSCORE. An OSCORE group is used as security group for
one or many application groups.
- Authentication credential, as the set of information associated
with an entity, including that entity's public key and
parameters associated with the public key. Examples of
authentication credentials are CBOR Web Tokens (CWTs) and CWT
Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC7925] and
C509 certificates [I-D.ietf-cose-cbor-encoded-cert].
* The ACE framework for authentication and authorization * The ACE framework for authentication and authorization
[I-D.ietf-ace-oauth-authz]. The terminology for entities in the [I-D.ietf-ace-oauth-authz]. The terminology for entities in the
considered architecture is defined in OAuth 2.0 [RFC6749]. In considered architecture is defined in OAuth 2.0 [RFC6749]. In
particular, this includes Client (C), Resource Server (RS), and particular, this includes Client (C), Resource Server (RS), and
Authorization Server (AS). Authorization Server (AS).
* The management of keying material for groups in ACE * The management of keying material for groups in ACE
[I-D.ietf-ace-key-groupcomm] and specifically for OSCORE groups [I-D.ietf-ace-key-groupcomm] and specifically for OSCORE groups
[I-D.ietf-ace-key-groupcomm-oscore]. These include the concept of [I-D.ietf-ace-key-groupcomm-oscore]. These include the concept of
skipping to change at page 5, line 52 skipping to change at page 6, line 35
* Administrator: entity responsible to create, configure and delete * Administrator: entity responsible to create, configure and delete
OSCORE groups at a Group Manager. OSCORE groups at a Group Manager.
* Group name: stable and invariant name of an OSCORE group. The * Group name: stable and invariant name of an OSCORE group. The
group name MUST be unique under the same Group Manager, and MUST group name MUST be unique under the same Group Manager, and MUST
include only characters that are valid for a URI path segment. include only characters that are valid for a URI path segment.
* Group-collection resource: a single-instance resource hosted by * Group-collection resource: a single-instance resource hosted by
the Group Manager. An Administrator accesses a group-collection the Group Manager. An Administrator accesses a group-collection
resource to create a new OSCORE group, or to retrieve the list of resource to retrieve the list of existing OSCORE groups, or to
existing OSCORE groups, under that Group Manager. As an example, create a new OSCORE group, under that Group Manager.
this document uses /manage as the url-path of the group-collection
resource; implementations are not required to use this name, and As an example, this document uses /manage as the url-path of the
can define their own instead. group-collection resource; implementations are not required to use
this name, and can define their own instead.
* Group-configuration resource: a resource hosted by the Group * Group-configuration resource: a resource hosted by the Group
Manager, associated to an OSCORE group under that Group Manager. Manager, associated with an OSCORE group under that Group Manager.
A group-configuration resource is identifiable with the invariant A group-configuration resource is identifiable with the invariant
group name of the respective OSCORE group. An Administrator group name of the respective OSCORE group. An Administrator
accesses a group-configuration resource to retrieve or update the accesses a group-configuration resource to retrieve or change the
configuration of the respective OSCORE group, or to delete that configuration of the respective OSCORE group, or to delete that
group. The url-path to a group-configuration resource has group.
GROUPNAME as last segment, with GROUPNAME the invariant group name
assigned upon its creation. Building on the considered url-path
of the group-collection resource, this document uses /manage/
GROUPNAME as the url-path of a group-configuration resource;
implementations are not required to use this name, and can define
their own instead.
* Admin endpoint: an endpoint at the Group Manager associated to the The url-path to a group-configuration resource has GROUPNAME as
group-collection resource or to a group-configuration resource last segment, with GROUPNAME the invariant group name assigned
upon its creation. Building on the considered url-path of the
group-collection resource, this document uses /manage/GROUPNAME as
the url-path of a group-configuration resource; implementations
are not required to use this name, and can define their own
instead.
* Admin endpoint: an endpoint at the Group Manager associated with
the group-collection resource or to a group-configuration resource
hosted by that Group Manager. hosted by that Group Manager.
2. Group Administration 2. Group Administration
With reference to the ACE framework and the terminology defined in With reference to the ACE framework and the terminology defined in
OAuth 2.0 [RFC6749]: OAuth 2.0 [RFC6749]:
* The Group Manager acts as Resource Server (RS). It provides one * The Group Manager acts as Resource Server (RS). It provides one
single group-collection resource, and one group-configuration single group-collection resource, and one group-configuration
resource per existing OSCORE group. Each of those is exported by resource per existing OSCORE group. Each of those is exported by
a distinct admin endpoint. a distinct admin endpoint.
* The Administrator acts as Client (C), and requests to access the * The Administrator acts as Client (C), and requests to access the
group-collection resource and group-configuration resources, by group-collection resource and group-configuration resources, by
accessing the respective admin endpoint at the Group Manager. accessing the respective admin endpoint at the Group Manager.
* The Authorization Server (AS) authorizes the Administrator to * The Authorization Server (AS) authorizes the Administrator to
access the group-collection resource and group-configuration access the group-collection resource and group-configuration
resources at a Group Manager. Multiple Group Managers can be resources at a Group Manager. Multiple Group Managers can be
associated to the same AS. associated with the same AS.
The authorized access for an Administrator can be limited to The authorized access for an Administrator can be limited to
performing only a subset of operations. The AS can authorize performing only a subset of operations, according to what is
multiple Administrators to access the collection resource and the allowed by the authorization information in the Access Token
(same) group-configuration resources at the Group Manager. issued to that Administrator (see Section 3 and Section 4). The
AS can authorize multiple Administrators to access the group-
[ NOTE: This will be enabled by defining the format to use for the collection resource and the (same) group-configuration resources
'scope' claim in the Access Token, as encoding permitted actions at the Group Manager.
on groups whose name matches with a name pattern. ]
The AS MAY release Access Tokens to the Administrator for other The AS MAY release Access Tokens to the Administrator for other
purposes than accessing admin endpoints of registered Group purposes than accessing admin endpoints of registered Group
Managers. Managers.
2.1. Getting Access to the Group Manager 2.1. Managing OSCORE Groups
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 document.
In order to get access to the Group Manager for managing OSCORE
groups, an Administrator performs the following steps.
The format and encoding of scope defined in Section 2.1.1 of this
document MUST be used, for both the 'scope' claim in the Access
Token, as well as for the 'scope' parameter in the Authorization
Request and Authorization Response exchanged with the AS (see
Sections 5.8.1 and 5.8.2 of [I-D.ietf-ace-oauth-authz]).
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. Consistently with what allowed by the authorization information
in the Access Token, 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 OSCORE
group configurations, and the removal of OSCORE groups. Messages
exchanged among the Administrator and the Group Manager are
specified in Section 4.
2.1.1. Format of Scope
This section defines the exact format and encoding of scope to use,
in order to express authorization information for the Administrator
(see Section 2.1).
TODO
[
DESIGN CONSIDERATIONS
* Define a new AIF specific data model, as loosely aligned with the
data model AIF-OSCORE-GROUPCOMM defined in Section 3 of
[I-D.ietf-ace-key-groupcomm-oscore].
- The overall scope is an array of scope entries, each as a pair
(Toid, Tperm).
- Toid is a text string, i.e., a wildcard pattern against which
group names can be matched.
- Tperm is a set of specific permissions encoded as a bitmap,
applied to groups whose name matches with the wildcard pattern.
* A valid Access Token should always allow to at least retrieve the
list of existing group configurations.
* An Administrator authorized to create a group, should later be
able to perform any possible operation on it.
* An Administrator can be authorized to perform selected operations
on a group earlier created by a different Administrator, still
barring the group name matching with the wildcard pattern.
]
2.2. Managing OSCORE Groups
Figure 1 shows the resources of a Group Manager available to an Figure 1 shows the resources of a Group Manager available to an
Administrator. Administrator.
___ ___
Group / \ Group / \
Collection \___/ Collection \___/
\ \
\____________________ \____________________
\___ \___ \___ \___ \___ \___
/ \ / \ ... / \ Group / \ / \ ... / \ Group
\___/ \___/ \___/ Configurations \___/ \___/ \___/ Configurations
Figure 1: Resources of a Group Manager Figure 1: Resources of a Group Manager
The Group Manager exports a single group-collection resource, with The Group Manager exports a single group-collection resource, with
resource type "core.osc.gcoll" defined in Section 7.3 of this resource type "core.osc.gcoll" defined in Section 9.3 of this
document. The interface for the group-collection resource defined in document. The interface for the group-collection resource defined in
Section 4 allows the Administrator to: Section 6 allows the Administrator to:
* Retrieve the complete list of existing OSCORE groups. * Retrieve the list of existing OSCORE groups.
* Retrieve a partial list of existing OSCORE groups, by applying * Retrieve the list of existing OSCORE groups matching with
filter criteria. specified filter criteria.
* Create a new OSCORE group, specifying its invariant group name * Create a new OSCORE group, specifying its invariant group name
and, optionally, its configuration. and, optionally, its configuration.
The Group Manager exports one group-configuration resource for each The Group Manager exports one group-configuration resource for each
of its OSCORE groups. Each group-configuration resource has resource of its OSCORE groups. Each group-configuration resource has resource
type "core.osc.gconf" defined in Section 7.3 of this document, and is type "core.osc.gconf" defined in Section 9.3 of this document, and is
identified by the group name specified upon creating the OSCORE identified by the group name specified upon creating the OSCORE
group. The interface for a group-configuration resource defined in group. The interface for a group-configuration resource defined in
Section 4 allows the Administrator to: Section 6 allows the Administrator to:
* Retrieve the complete current configuration of the OSCORE group. * Retrieve the complete current configuration of the OSCORE group.
* Retrieve part of the current configuration of the OSCORE group, by * Retrieve part of the current configuration of the OSCORE group, by
applying filter criteria. applying filter criteria.
* Overwrite the current configuration of the OSCORE group. * Overwrite the current configuration of the OSCORE group.
* Selectively update only part of the current configuration of the * Selectively update only part of the current configuration of the
OSCORE group. OSCORE group.
* Delete the OSCORE group. * Delete the OSCORE group.
2.3. Collection Representation 2.2. Collection Representation
A list of group configurations is represented as a document A list of group configurations is represented as a document
containing the corresponding group-configuration resources in the containing the corresponding group-configuration resources in the
list. Each group-configuration is represented as a link, where the list. Each group-configuration is represented as a link, where the
link target is the URI of the group-configuration resource. link target is the URI of the group-configuration resource.
The list can be represented as a Link Format document [RFC6690] or a The list can be represented as a Link Format document [RFC6690] or a
CoRAL document [I-D.ietf-core-coral]. CoRAL document [I-D.ietf-core-coral].
In the former case, the link to each group-configuration resource In the former case, the link to each group-configuration resource
specifies the link target attribute 'rt' (Resource Type), with value specifies the link target attribute 'rt' (Resource Type), with value
"core.osc.gconf" defined in Section 7.3 of this document. "core.osc.gconf" defined in Section 9.3 of this document.
In the latter case, the CoRAL document specifies the group- In the latter case, the CoRAL document specifies the group-
configuration resources in the list as top-level elements. In configuration resources in the list as top-level elements. In
particular, the link to each group-configuration resource has particular, the link to each group-configuration resource has
http://coreapps.org/core.osc.gcoll#item as relation type. http://coreapps.org/core.osc.gcoll#item as relation type.
2.4. Discovery 2.3. Discovery
The Administrator can discover the group-collection resource from a The Administrator can discover the group-collection resource from a
Resource Directory, for instance [I-D.ietf-core-resource-directory] Resource Directory, for instance [I-D.ietf-core-resource-directory]
and [I-D.hartke-t2trg-coral-reef], or from .well-known/core, by using and [I-D.hartke-t2trg-coral-reef], or from .well-known/core, by using
the resource type "core.osc.gcoll" defined in Section 7.3 of this the resource type "core.osc.gcoll" defined in Section 9.3 of this
document. document.
The Administrator can discover group-configuration resources for the The Administrator can discover group-configuration resources for the
group-collection resource as specified in Section 4.1 and group-collection resource as specified in Section 6.1 and
Section 4.2. Section 6.2.
3. Group Configurations 3. Format of Scope
This section defines the exact format and encoding of scope to use,
in order to express authorization information for the Administrator
(see Section 4).
To this end, this document uses the Authorization Information Format
(AIF) [I-D.ietf-ace-aif], and defines the following AIF specific data
model AIF-OSCORE-GROUPCOMM-ADMIN.
With reference to the generic AIF model
AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]]
the value of the CBOR byte string used as scope encodes the CBOR
array [* [Toid, Tperm]], where each [Toid, Tperm] element corresponds
to one scope entry.
Then, for each scope entry, the following applies.
* The object identifier ("Toid") is specialized as a CBOR text
string, specifying a wildcard pattern P for the scope entry. The
pattern P is intended as a template for group names.
* The permission set ("Tperm") is specialized as a CBOR unsigned
integer with value Q. This specifies the permissions that the
Administrator has to perform operations on the admin endpoints at
the Group Manager, as pertaining to any OSCORE group whose name
matches with the wildcard pattern P. The value Q is computed as
follows.
- Each permission in the permission set is converted into the
corresponding numeric identifier X from the "Value" column of
the "Group OSCORE Admin Permissions" registry, for which this
document defines the entries in Figure 2.
- The set of N numbers is converted into the single value Q, by
taking each numeric identifier X_1, X_2, ..., X_N to the power
of two, and then computing the inclusive OR of the binary
representations of all the power values.
In general, a single permission can be associated with multiple
different operations that are possible to be performed when
interacting with the Group Manager. For example, the "List"
permission allows the Administrator to retrieve a list of group
configurations (see Section 6.1) or only a subset of that
according to specified filter criteria (see Section 6.2), by
issuing a GET or FETCH request to the group-collection resource,
respectively.
+--------+-------+----------------------------------------+
| Name | Value | Description |
+========+=======+========================================+
| List | 0 | Retrieve list of group configurations |
+--------+-------+----------------------------------------+
| Create | 1 | Create new group configurations |
+--------+-------+----------------------------------------+
| Read | 2 | Retrieve group configurations |
+--------+-------+----------------------------------------+
| Write | 3 | Change group configurations |
+--------+-------+----------------------------------------+
| Delete | 4 | Delete group configurations |
+--------+-------+----------------------------------------+
Figure 2: Numeric identifier of permissions on the admin
endpoints at a Group Manager
The CDDL [RFC8610] definition of the AIF-OSCORE-GROUPCOMM-ADMIN data
model and the format of scope using such a data model is as follows:
AIF-OSCORE-GROUPCOMM-ADMIN = AIF-Generic<pattern, permissions>
pattern = tstr ; wilcard pattern of group names
permission_set = uint . bits permissions
permissions = &(
List: 0,
Create: 1,
Read: 2,
Write: 3,
Delete: 4
)
scope_entry = AIF-OSCORE-GROUPCOMM-ADMIN
scope = << [ + scope_entry ] >>
By relying on the scope format defined above and given an OSCORE
group G1 created by a "main" Administrator, then a second "assistant"
Administrator can be effectively authorized to perform some
operations on G1, in spite of not being the group creator.
Furthermore, having the object identifier ("Toid") specialized as a
wildcard pattern displays a number of advantages.
* The encoded scope can be compact in size, while allowing the
Administrator to operate on large pools of group names.
* The Administrator and the AS do not need to know exact group names
when requesting and issuing an Access Token, respectively (see
Section 4). In turn, the Group Manager can effectively take the
final decision about the name to assign to an OSCORE group, upon
its creation (see Section 6.3).
* The Administrator may have established a secure communication
association with the Group Manager based on a first Access Token
T1, and then created an OSCORE group G. Following the
invalidation of T1 (e.g., due to expiration) and the establishment
of a new secure communication association with the Group Manager
based on a new Access Token T2, the Administrator can seamlessly
perform authorized operations on the previously created group G.
When using the scope format defined in this section, the permission
set ("Tperm") of each scope entry MUST include the "List" permission
in order for the scope to be considered valid. That is, for each
scope entry, the unsigned integer Q MUST be odd. Therefore, an
Administrator is always allowed to retrieve a list of existing group
configurations. The exact elements included in the returned list are
determined by the Group Manager, based on the group name patterns
specified in the scope entries of the Administrator's Access Token,
as well as on possible filter criteria specified in the request from
the Administrator.
[ NOTE:
There is a potential follow-up building on this.
An ACE Client might want to interact with the same Group Manager to
be both Administrator for some groups and member for some other
groups.
In order to keep a single Access Token per Client, the scope would
have to generally include some "admin" scope entries as per the AIF
data model defined in this document, together with some "user" scope
entries as per the AIF data model defined in
[I-D.ietf-ace-key-groupcomm-oscore].
In the scope entries of the former type, the least significant bit of
the Tperm integer and denoting the "List" admin permission is always
set to 1 (see above). In the scope entries of the latter type, the
least significant bit of the Tperm integer is reserved and always 0
(see [I-D.ietf-ace-key-groupcomm-oscore]).
Therefore, "admin" and "user" scope entries can unambiguously coexist
in the same 'scope' claim and Authorization Request/Response
parameter, and can be easily distinguished by checking the least
significant bit of the Tperm integer.
In turn, this would require to accordingly revise the scope format
and the ACE scope semantics integer defined in this document, in
order to denote the certain presence of "admin" scope entries and the
optional additional presence of "user" scope entries, within a same
scope claim/parameter.
]
Future specifications that define new permissions on the admin
endpoints at the Group Manager MUST register a corresponding numeric
identifier in the "Group OSCORE Admin Permissions" registry defined
in Section 9.4 of this document.
4. Getting Access to the Group Manager
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 document.
The format and encoding of scope defined in Section 3 of this
document MUST be used, for both the 'scope' claim in the Access
Token, as well as for the 'scope' parameter in the Authorization
Request and Authorization Response exchanged with the AS (see
Sections 5.8.1 and 5.8.2 of [I-D.ietf-ace-oauth-authz]).
Furthermore, the AS MAY use the extended format of scope defined in
Section 7 of [I-D.ietf-ace-key-groupcomm] for the 'scope' claim of
the Access Token. In such a case, the first element of the CBOR
sequence [RFC8742] MUST be the CBOR integer with value SEM_ID_TBD,
defined in Section 9.7 of this document. This indicates that the
second element of the CBOR sequence, as conveying the actual access
control information, follows the scope semantics defined in Section 3
of this document.
In order to get access to the Group Manager for managing OSCORE
groups, an Administrator performs the following steps.
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. To this end, it sends to the AS an
Authorization Request as defined in Section 5.8.1 of
[I-D.ietf-ace-oauth-authz]. The Administrator will start or
continue using secure communications with the Group Manager,
according to the response from the AS.
2. The AS processes the Authorization Request as defined in
Section 5.8.2 of [I-D.ietf-ace-oauth-authz], especially verifying
that the Administrator is authorized to obtain the requested
permissions, or possibly a subset of those.
With reference to the scope format specified in Section 3, the AS
builds the value of the 'scope' claim to include in the Access
Token as follows.
1. The AS initializes three empty sets of scope entries, namely
S1, S2 and S3.
2. For each scope entry E in the 'scope' parameter of the
Authorization Request, the AS performs the following actions.
* In its access policies related to administrative
operations at the Group Manager for the Administrator, the
AS determines every group name superpattern P*, such that
every group name matching with the wildcard pattern P of
the scope entry E matches also with P*.
* If no superpatterns are found, the AS proceeds with the
next scope entry, if any. Otherwise, the AS computes
Tperm* as the union of the permission sets associated with
the superpatterns found at the previous step. That is,
Tperm* is the inclusive OR of the binary representations
of the Tperm values associated with the found
superpatterns and encoding the corresponding permission
sets as per Section 3.
* The AS adds to the set S1 a scope entry, such that its
Toid is the same as in the scope entry E, while its Tperm
is the AND of Tperm* with the Tperm in the scope entry E.
3. For each scope entry E in the 'scope' parameter of the
Authorization Request, the AS performs the following actions.
* In its access policies related to administrative
operations at the Group Manager for the Administrator, the
AS determines every group name subpattern P*, such that:
i) the wildcard pattern P of the scope entry E is
different from P*; and ii) every group name matching with
P* also matches with P.
* If no subpatterns are found, the AS proceeds with the next
scope entry, if any. Otherwise, for each found subpattern
P*, the AS adds to the set S2 a scope entry, such that its
Toid is the same as in the subpattern P*, while its Tperm
is the AND of the Tperm from the subpattern P* with the
Tperm in the scope entry E.
4. For each scope entry E in the 'scope' parameter of the
Authorization Request, the AS performs the following actions.
* For each group name pattern P* in its access policies
related to administrative operations at the Group Manager
for the Administrator, the AS performs the following
actions.
- The AS attempts to determine a crosspattern P** such
that: i) in the previous step, P** was not identified
as a superpattern or subpattern for the pattern P of
the scope entry E; ii) every group name matching with
P** also matches with both P and P*.
- If no crosspattern is built, the AS proceeds with the
next pattern in its access policies related to
administrative operations at the Group Manager for the
Administrator, if any. Otherwise, the AS adds to the
set S3 a scope entry, such that its Toid is the same as
in the crosspattern P**, while its Tperm is the AND of
the Tperm from the pattern P* and the Tperm in the
scope entry E.
5. If the sets S1, S2 and S3 are all empty, the Authorization
Request has not been successfully verified, and the AS
returns an error response as per Section 5.8.3 of
[I-D.ietf-ace-oauth-authz]. Otherwise, the AS uses the scope
entries in the sets S1, S2 and S3 as the scope entries for
the 'scope' claim to include in the Access Token, as per the
format defined in Section 3.
The AS MUST include the 'scope' parameter in the Authorization
Response defined in Section 5.8.2 of [I-D.ietf-ace-oauth-authz],
when the value included in the Access Token differs from the one
specified by the Administrator in the Authorization Response. In
such a case, the second element of each scope entry specifies a
set of permissions that the Administrator actually has to perform
operations at the Group Manager, encoded as specified in
Section 3.
3. 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 a secure communication
association established with the Group Manager, before performing
any administrative 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.
4. Consistently with what is allowed by the authorization
information in the Access Token, the Administrator performs
administrative operations at the Group Manager, as described in
Section 6. These include retrieving a list of existing OSCORE
groups, creating new OSCORE groups, retrieving and changing
OSCORE group configurations, and removing OSCORE groups.
Messages exchanged among the Administrator and the Group Manager
are specified in Section 6.
Upon receiving a request from the Administrator targeting the
group-configuration resource or a group-collection resource, the
Group Manager MUST check that it is storing a valid Access Token
for that Administrator. If this is not the case, the Group
Manager MUST reply with a 4.01 (Unauthorized) error response.
If the request targets the group-configuration resource
associated to a group with name GROUPNAME, the Group Manager MUST
check that it is storing a valid Access Token from that
Administrator, such that the 'scope' claim specified in the
Access Token has the format defined in Section 3 and includes a
scope entry where:
* The group name GROUPNAME matches with the wildcard pattern
specified in the scope entry; and
* The permission set specified in the scope entry allows the
Administrator to perform the requested operation on the
targeted group-configuration resource.
Further details are defined separately for each operation
specified in Section 6.
In case the Group Manager stores a valid Access Token but the
verifications above fail, the Group Manager MUST reply with a
4.03 (Forbidden) error response. This response MAY be an AS
Request Creation Hints, as defined in Section 5.3 of
[I-D.ietf-ace-oauth-authz], in which case the Content-Format MUST
be set to application/ace+cbor.
If the request is not formatted correctly (e.g., required fields
are not present or are not encoded as expected), the Group
Manager MUST reply with a 4.00 (Bad Request) error response.
5. Group Configurations
A group configuration consists of a set of parameters. A group configuration consists of a set of parameters.
3.1. Group Configuration Representation 5.1. Group Configuration Representation
The group configuration representation is a CBOR map which MUST The group configuration representation is a CBOR map which MUST
include configuration properties and status properties. include configuration properties and status properties.
3.1.1. Configuration Properties 5.1.1. Configuration Properties
The CBOR map MUST include the following configuration parameters, The CBOR map MUST include the following configuration parameters,
whose CBOR abbreviations are defined in Section 7.1 of this document. whose CBOR abbreviations are defined in Section 9.1 of this document.
* 'hkdf', which specifies the HKDF Algorithm used in the OSCORE * 'hkdf', which specifies the HKDF Algorithm used in the OSCORE
group, encoded as a CBOR text string or a CBOR integer. Possible group, encoded as a CBOR text string or a CBOR integer. Possible
values are the same ones admitted for the 'hkdf' parameter of the values are the same ones admitted for the 'hkdf' parameter of the
Group_OSCORE_Input_Material object, defined in Section 6.4 of Group_OSCORE_Input_Material object, defined in Section 6.4 of
[I-D.ietf-ace-key-groupcomm-oscore]. [I-D.ietf-ace-key-groupcomm-oscore].
* 'pub_key_enc', which specifies the encoding of public keys used in * 'cred_fmt', which specifies the format of authentication
the OSCORE group, encoded as a CBOR integer. Possible values are credentials used in the OSCORE group, encoded as a CBOR integer.
the same ones admitted for the 'pub_key_enc' parameter of the Possible values are the same ones admitted for the 'cred_fmt'
Group_OSCORE_Input_Material object, defined in Section 6.4 of parameter of the Group_OSCORE_Input_Material object, defined in
[I-D.ietf-ace-key-groupcomm-oscore]. Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore].
* 'group_mode', encoded as a CBOR simple value. Its value is True * 'group_mode', encoded as a CBOR simple value. Its value is "true"
if the OSCORE group uses the group mode of Group OSCORE (0xf5) if the OSCORE group uses the group mode of Group OSCORE
[I-D.ietf-core-oscore-groupcomm], or False otherwise. [I-D.ietf-core-oscore-groupcomm], or "false" (0xf4) otherwise.
* 'sign_enc_alg', which is formatted as follows. If the * 'sign_enc_alg', which is formatted as follows. If the
configuration parameter 'group_mode' has value False, this configuration parameter 'group_mode' has value "false" (0xf4),
parameter has as value the CBOR simple value Null. Otherwise, this parameter has as value the CBOR simple value "null" (0xf6).
this parameter specifies the Signature Encryption Algorithm used Otherwise, this parameter specifies the Signature Encryption
in the OSCORE group to encrypt messages protected with the group Algorithm used in the OSCORE group to encrypt messages protected
mode, encoded as a CBOR text string or a CBOR integer. Possible with the group mode, encoded as a CBOR text string or a CBOR
values are the same ones admitted for the 'sign_enc_alg' parameter integer. Possible values are the same ones admitted for the
of the Group_OSCORE_Input_Material object, defined in Section 6.4 'sign_enc_alg' parameter of the Group_OSCORE_Input_Material
of [I-D.ietf-ace-key-groupcomm-oscore]. object, defined in Section 6.4 of
[I-D.ietf-ace-key-groupcomm-oscore].
* 'sign_alg', which is formatted as follows. If the configuration * 'sign_alg', which is formatted as follows. If the configuration
parameter 'group_mode' has value False, this parameter has as parameter 'group_mode' has value "false" (0xf4), this parameter
value the CBOR simple value Null. Otherwise, this parameter has as value the CBOR simple value "null" (0xf6). Otherwise, this
specifies the Signature Algorithm used in the OSCORE group, parameter specifies the Signature Algorithm used in the OSCORE
encoded as a CBOR text string or a CBOR integer. Possible values group, encoded as a CBOR text string or a CBOR integer. Possible
are the same ones admitted for the 'sign_alg' parameter of the values are the same ones admitted for the 'sign_alg' parameter of
Group_OSCORE_Input_Material object, defined in Section 6.4 of the Group_OSCORE_Input_Material object, defined in Section 6.4 of
[I-D.ietf-ace-key-groupcomm-oscore]. [I-D.ietf-ace-key-groupcomm-oscore].
* 'sign_params', which is formatted as follows. If the * 'sign_params', which is formatted as follows. If the
configuration parameter 'group_mode' has value False, this configuration parameter 'group_mode' has value "false" (0xf4),
parameter has as value the CBOR simple value Null. Otherwise, this parameter has as value the CBOR simple value "null" (0xf6).
this parameter specifies the additional parameters for the Otherwise, this parameter specifies the additional parameters for
Signature Algorithm used in the OSCORE group, encoded as a CBOR the Signature Algorithm used in the OSCORE group, encoded as a
array. Possible formats and values are the same ones admitted for CBOR array. Possible formats and values are the same ones
the 'sign_params' parameter of the Group_OSCORE_Input_Material admitted for the 'sign_params' parameter of the
object, defined in Section 6.4 of Group_OSCORE_Input_Material object, defined in Section 6.4 of
[I-D.ietf-ace-key-groupcomm-oscore]. [I-D.ietf-ace-key-groupcomm-oscore].
* 'pairwise_mode', encoded as a CBOR simple value. Its value is * 'pairwise_mode', encoded as a CBOR simple value. Its value is
True if the OSCORE group uses the pairwise mode of Group OSCORE "true" (0xf5) if the OSCORE group uses the pairwise mode of Group
[I-D.ietf-core-oscore-groupcomm], or False otherwise. OSCORE [I-D.ietf-core-oscore-groupcomm], or "false" (0xf4)
otherwise.
* 'alg', which is formatted as follows. If the configuration * 'alg', which is formatted as follows. If the configuration
parameter 'pairwise_mode' has value False, this parameter has as parameter 'pairwise_mode' has value "false" (0xf4), this parameter
value the CBOR simple value Null. Otherwise, this parameter has as value the CBOR simple value "null" (0xf6). Otherwise, this
specifies the AEAD Algorithm used in the OSCORE group to encrypt parameter specifies the AEAD Algorithm used in the OSCORE group to
messages protected with the pairwise mode, encoded as a CBOR text encrypt messages protected with the pairwise mode, encoded as a
string or a CBOR integer. Possible values are the same ones CBOR text string or a CBOR integer. Possible values are the same
admitted for the 'alg' parameter of the ones admitted for the 'alg' parameter of the
Group_OSCORE_Input_Material object, defined in Section 6.4 of Group_OSCORE_Input_Material object, defined in Section 6.4 of
[I-D.ietf-ace-key-groupcomm-oscore]. [I-D.ietf-ace-key-groupcomm-oscore].
* 'ecdh_alg', which is formatted as follows. If the configuration * 'ecdh_alg', which is formatted as follows. If the configuration
parameter 'pairwise_mode' has value False, this parameter has as parameter 'pairwise_mode' has value "false" (0xf4), this parameter
value the CBOR simple value Null. Otherwise, this parameter has as value the CBOR simple value "null" (0xf6). Otherwise, this
specifies the Pairwise Key Agreement Algorithm used in the OSCORE parameter specifies the Pairwise Key Agreement Algorithm used in
group, encoded as a CBOR text string or a CBOR integer. Possible the OSCORE group, encoded as a CBOR text string or a CBOR integer.
values are the same ones admitted for the 'ecdh_alg' parameter of Possible values are the same ones admitted for the 'ecdh_alg'
the Group_OSCORE_Input_Material object, defined in Section 6.4 of parameter of the Group_OSCORE_Input_Material object, defined in
[I-D.ietf-ace-key-groupcomm-oscore]. Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore].
* 'ecdh_params', which is formatted as follows. If the * 'ecdh_params', which is formatted as follows. If the
configuration parameter 'pairwise_mode' has value False, this configuration parameter 'pairwise_mode' has value "false" (0xf4),
parameter has as value the CBOR simple value Null. Otherwise, this parameter has as value the CBOR simple value "null" (0xf6).
this parameter specifies the parameters for the Pairwise Key Otherwise, this parameter specifies the parameters for the
Agreement Algorithm used in the OSCORE group, encoded as a CBOR Pairwise Key Agreement Algorithm used in the OSCORE group, encoded
array. Possible formats and values are the same ones admitted for as a CBOR array. Possible formats and values are the same ones
the 'ecdh_params' parameter of the Group_OSCORE_Input_Material admitted for the 'ecdh_params' parameter of the
object, defined in Section 6.4 of Group_OSCORE_Input_Material object, defined in Section 6.4 of
[I-D.ietf-ace-key-groupcomm-oscore]. [I-D.ietf-ace-key-groupcomm-oscore].
The CBOR map MAY include the following configuration parameters, The CBOR map MAY include the following configuration parameters,
whose CBOR abbreviations are defined in Section 7.1 of this document. whose CBOR abbreviations are defined in Section 9.1 of this document.
* 'det_req', encoded as a CBOR simple value. Its value is True if * 'det_req', encoded as a CBOR simple value. Its value is "true"
the OSCORE group uses deterministic requests as defined in (0xf5) if the OSCORE group uses deterministic requests as defined
[I-D.amsuess-core-cachable-oscore], or False otherwise. This in [I-D.amsuess-core-cachable-oscore], or "false" (0xf4)
parameter MUST NOT be present if the configuration parameter otherwise. This parameter MUST NOT be present if the
'group_mode' has value False. configuration parameter 'group_mode' has value "false" (0xf4).
* 'det_hash_alg', encoded as a CBOR integer or text string. If * 'det_hash_alg', encoded as a CBOR integer or text string. If
present, this parameter specifies the Hash Algorithm used in the present, this parameter specifies the Hash Algorithm used in the
OSCORE group when producing deterministic requests, as defined in OSCORE group when producing deterministic requests, as defined in
[I-D.amsuess-core-cachable-oscore]. This parameter takes values [I-D.amsuess-core-cachable-oscore]. This parameter takes values
from the "Value" column of the "COSE Algorithms" Registry from the "Value" column of the "COSE Algorithms" Registry
[COSE.Algorithms]. [COSE.Algorithms].
This parameter MUST NOT be present if the configuration parameter This parameter MUST NOT be present if the configuration parameter
'det_req' is not present or if it is present with value False. If 'det_req' is not present or if it is present with value "false"
the configuration parameter 'det_req' is present with value True (0xf4). If the configuration parameter 'det_req' is present with
and 'det_hash_alg' is not present, the choice of the Hash value "true" (0xf5) and 'det_hash_alg' is not present, the choice
Algorithm to use when producing deterministic requests is left to of the Hash Algorithm to use when producing deterministic requests
the Group Manager. is left to the Group Manager.
3.1.2. Status Properties 5.1.2. Status Properties
The CBOR map MUST include the following status parameters: The CBOR map MUST include the following status parameters:
* 'rt', with value the resource type "core.osc.gconf" associated to * 'rt', with value the resource type "core.osc.gconf" associated
group-configuration resources, encoded as a CBOR text string. with group-configuration resources, encoded as a CBOR text string.
* 'active', encoding the CBOR simple value True if the OSCORE group * 'active', encoding the CBOR simple value "true" (0xf5) if the
is currently active, or the CBOR simple value False otherwise. OSCORE group is currently active, or the CBOR simple value "false"
This parameter is defined in Section 7.1 of this document. (0xf4) otherwise. This parameter is defined in Section 9.1 of
this document.
* 'group_name', with value the group name of the OSCORE group * 'group_name', with value the group name of the OSCORE group
encoded as a CBOR text string. This parameter is defined in encoded as a CBOR text string. This parameter is defined in
Section 7.1 of this document. Section 9.1 of this document.
* 'group_title', with value either a human-readable description of * 'group_title', with value either a human-readable description of
the OSCORE group encoded as a CBOR text string, or the CBOR simple the OSCORE group encoded as a CBOR text string, or the CBOR simple
value Null if no description is specified. This parameter is value "null" (0xf6) if no description is specified. This
defined in Section 7.1 of this document. parameter is defined in Section 9.1 of this document.
* 'ace-groupcomm-profile', defined in Section 4.3.1 of * 'ace-groupcomm-profile', defined in Section 4.3.1 of
[I-D.ietf-ace-key-groupcomm], with value "coap_group_oscore_app" [I-D.ietf-ace-key-groupcomm], with value "coap_group_oscore_app"
defined in Section 25.5 of [I-D.ietf-ace-key-groupcomm-oscore] defined in Section 25.5 of [I-D.ietf-ace-key-groupcomm-oscore]
encoded as a CBOR integer. encoded as a CBOR integer.
* 'exp', defined in Section 4.3.1 of [I-D.ietf-ace-key-groupcomm]. * 'exp', defined in Section 4.3.1 of [I-D.ietf-ace-key-groupcomm].
* 'app_groups', with value a list of names of application groups, * 'app_groups', with value a list of names of application groups,
encoded as a CBOR array. Each element of the array is a CBOR text encoded as a CBOR array. Each element of the array is a CBOR text
string, specifying the name of an application group using the string, specifying the name of an application group using the
OSCORE group as security group (see Section 2.1 of OSCORE group as security group (see Section 2.1 of
[I-D.ietf-core-groupcomm-bis]). [I-D.ietf-core-groupcomm-bis]).
* 'joining_uri', with value the URI of the group-membership resource * 'joining_uri', with value the URI of the group-membership resource
for joining the newly created OSCORE group as per Section 6.2 of for joining the newly created OSCORE group as per Section 6.2 of
[I-D.ietf-ace-key-groupcomm-oscore], encoded as a CBOR text [I-D.ietf-ace-key-groupcomm-oscore], encoded as a CBOR text
string. This parameter is defined in Section 7.1 of this string. This parameter is defined in Section 9.1 of this
document. document.
The CBOR map MAY include the following status parameters: The CBOR map MAY include the following status parameters:
* 'group_policies', defined in Section 4.3.1 of * 'group_policies', defined in Section 4.3.1 of
[I-D.ietf-ace-key-groupcomm], and consistent with the format and [I-D.ietf-ace-key-groupcomm], and consistent with the format and
content defined in Section 6.4 of content defined in Section 6.4 of
[I-D.ietf-ace-key-groupcomm-oscore]. [I-D.ietf-ace-key-groupcomm-oscore].
* 'max_stale_sets', defined in Section 7.1 of this document and * 'max_stale_sets', defined in Section 9.1 of this document and
encoded as a CBOR unsigned integer, with value strictly greater encoded as a CBOR unsigned integer, with value strictly greater
than 1. With reference to Section 2.2.1 of than 1. With reference to Section 2.2.1 of
[I-D.ietf-ace-key-groupcomm-oscore], this parameter specifies N, [I-D.ietf-ace-key-groupcomm-oscore], this parameter specifies N,
i.e., the maximum number of sets of stale OSCORE Sender IDs that i.e., the maximum number of sets of stale OSCORE Sender IDs that
the Group Manager stores in the collection associated to the the Group Manager stores in the collection associated with the
group. group.
* 'as_uri', defined in Section 7.1 of this document, specifies the * 'as_uri', defined in Section 9.1 of this document, specifies the
URI of the Authorization Server associated to the Group Manager URI of the Authorization Server associated with the Group Manager
for the OSCORE group, encoded as a CBOR text string. Candidate for the OSCORE group, encoded as a CBOR text string. Candidate
group members will have to obtain an Access Token from that group members will have to obtain an Access Token from that
Authorization Server, before starting the joining process with the Authorization Server, before starting the joining process with the
Group Manager to join the OSCORE group (see Sections 4 and 6 of Group Manager to join the OSCORE group (see Sections 4 and 6 of
[I-D.ietf-ace-key-groupcomm-oscore]). [I-D.ietf-ace-key-groupcomm-oscore]).
3.2. Default Values 5.2. Default Values
This section defines the default values that the Group Manager This section defines the default values that the Group Manager
assumes for configuration and status parameters. assumes for configuration and status parameters.
3.2.1. Configuration Parameters 5.2.1. Configuration Parameters
For each configuration parameter, the Group Manager MUST use a pre- For each configuration parameter, the Group Manager MUST use a pre-
configured default value, if none is specified by the Administrator. configured default value, if none is specified by the Administrator.
In particular: In particular:
* For 'group_mode', the Group Manager SHOULD use the CBOR simple * For 'group_mode', the Group Manager SHOULD use the CBOR simple
value True. value "true" (0xf5).
* If 'group_mode' has value True, the Group Manager SHOULD use the * If 'group_mode' has value "true" (0xf5), the Group Manager SHOULD
same default values defined in Section 23.2 of use the same default values defined in Section 23.2 of
[I-D.ietf-ace-key-groupcomm-oscore] for the parameters [I-D.ietf-ace-key-groupcomm-oscore] for the parameters
'sign_enc_alg', 'sign_alg' and 'sign_params'. 'sign_enc_alg', 'sign_alg' and 'sign_params'.
* If 'group_mode' has value True, the Group Manager SHOULD use the * If 'group_mode' has value "true" (0xf5), the Group Manager SHOULD
CBOR simple value False for the parameter 'det_req'. use the CBOR simple value "false" (0xf4) for the parameter
'det_req'.
* If 'det_req' has value True, the Group Manager SHOULD use SHA-256 * If 'det_req' has value "true" (0xf5), the Group Manager SHOULD use
(COSE algorithm encoding: -16) as default value for the parameter SHA-256 (COSE algorithm encoding: -16) as default value for the
'det_hash_alg'. parameter 'det_hash_alg'.
* For 'pairwise_mode', the Group Manager SHOULD use the CBOR simple * For 'pairwise_mode', the Group Manager SHOULD use the CBOR simple
value False. value "false" (0xf4).
* If 'pairwise_mode' has value True, the Group Manager SHOULD use * If 'pairwise_mode' has value "true" (0xf5), the Group Manager
the same default values defined in Section 23.3 of SHOULD use the same default values defined in Section 23.3 of
[I-D.ietf-ace-key-groupcomm-oscore] for the parameters 'alg', [I-D.ietf-ace-key-groupcomm-oscore] for the parameters 'alg',
'ecdh_alg' and 'ecdh_params'. 'ecdh_alg' and 'ecdh_params'.
* For any other configuration parameter, the Group Manager SHOULD * For any other configuration parameter, the Group Manager SHOULD
use the same default values defined in Section 23.1 of use the same default values defined in Section 23.1 of
[I-D.ietf-ace-key-groupcomm-oscore]. [I-D.ietf-ace-key-groupcomm-oscore].
3.2.2. Status Parameters 5.2.2. Status Parameters
For the following status parameters, the Group Manager MUST use a For the following status parameters, the Group Manager MUST use a
pre-configured default value, if none is specified by the pre-configured default value, if none is specified by the
Administrator. In particular: Administrator. In particular:
* For 'active', the Group Manager SHOULD use the CBOR simple value * For 'active', the Group Manager SHOULD use the CBOR simple value
False. "false" (0xf4).
* For 'group_title', the Group Manager SHOULD use the CBOR simple * For 'group_title', the Group Manager SHOULD use the CBOR simple
value Null. value "null" (0xf6).
* For 'app_groups', the Group Manager SHOULD use the empty CBOR * For 'app_groups', the Group Manager SHOULD use the empty CBOR
array. array.
* For 'group_policies', the Group Manager SHOULD use the default * For 'group_policies', the Group Manager SHOULD use the default
values defined in Section 6.4 of values defined in Section 6.4 of
[I-D.ietf-ace-key-groupcomm-oscore]. [I-D.ietf-ace-key-groupcomm-oscore].
4. Interactions with the Group Manager 6. Interactions with the Group Manager
This section describes the operations available on the group- This section describes the operations available on the group-
collection resource and the group-configuration resources. collection resource and the group-configuration resources.
When custom CBOR is used, the Content-Format in messages containing a When custom CBOR is used, the Content-Format in messages containing a
payload is set to application/ace-groupcomm+cbor, defined in payload is set to application/ace-groupcomm+cbor, defined in
Section 11.2 of [I-D.ietf-ace-key-groupcomm]. Furthermore, the entry Section 11.2 of [I-D.ietf-ace-key-groupcomm]. Furthermore, the entry
labels defined in Section 7.1 of this document MUST be used, when labels defined in Section 9.1 of this document MUST be used, when
specifying the corresponding configuration and status parameters. specifying the corresponding configuration and status parameters.
4.1. Retrieve the Full List of Groups Configurations 6.1. Retrieve the Full List of Group Configurations
The Administrator can send a GET request to the group-collection The Administrator can send a GET request to the group-collection
resource, in order to retrieve the complete list of the existing resource, in order to retrieve a list of the existing OSCORE groups
OSCORE groups at the Group Manager. This is returned as a list of at the Group Manager. This is returned as a list of links to the
links to the corresponding group-configuration resources. corresponding group-configuration resources.
The Group Manager MUST prepare the list L to include in the response
as follows. For each group-configuration resource R:
1. The Group Manager considers the group name GROUPNAME of the
OSCORE group associated to R.
2. The Group Manager retrieves the stored Access Token for the
Administrator. Then, it checks whether GROUPNAME matches with
the group name pattern specified in any scope entry of the
'scope' claim in the Access Token.
3. The link to the group-configuration resource R is added to the
list L only in case of a positive match.
Example in Link Format: Example in Link Format:
=> 0.01 GET => 0.01 GET
Uri-Path: manage Uri-Path: manage
<= 2.05 Content <= 2.05 Content
Content-Format: 40 (application/link-format) Content-Format: 40 (application/link-format)
<coap://[2001:db8::ab]/manage/gp1>;rt="core.osc.gconf", <coap://[2001:db8::ab]/manage/gp1>;rt="core.osc.gconf",
skipping to change at page 16, line 44 skipping to change at page 23, line 29
<= 2.05 Content <= 2.05 Content
Content-Format: TBD1 (application/coral+cbor) Content-Format: TBD1 (application/coral+cbor)
#using <http://coreapps.org/core.osc.gcoll#> #using <http://coreapps.org/core.osc.gcoll#>
#base </manage/> #base </manage/>
item <gp1> item <gp1>
item <gp2> item <gp2>
item <gp3> item <gp3>
4.2. Retrieve a List of Group Configurations by Filters 6.2. Retrieve a List of Group Configurations by Filters
The Administrator can send a FETCH request to the group-collection The Administrator can send a FETCH request to the group-collection
resource, in order to retrieve the list of the existing OSCORE groups resource, in order to retrieve a list of the existing OSCORE groups
that fully match a set of specified filter criteria. This is that fully match a set of specified filter criteria. This is
returned as a list of links to the corresponding group-configuration returned as a list of links to the corresponding group-configuration
resources. resources.
When custom CBOR is used, the set of filter criteria is specified in When custom CBOR is used, the set of filter criteria is specified in
the request payload as a CBOR map, whose possible entries are the request payload as a CBOR map, whose possible entries are
specified in Section 3.1 and use the same abbreviations defined in specified in Section 5.1 and use the same abbreviations defined in
Section 7.1. Entry values are the ones admitted for the Section 9.1. Entry values are the ones admitted for the
corresponding labels in the POST request for creating a group corresponding labels in the POST request for creating a group
configuration (see Section 4.3). A valid request MUST NOT include configuration (see Section 6.3). A valid request MUST NOT include
the same entry multiple times. the same entry multiple times.
When CoRAL is used, the filter criteria are specified in the request When CoRAL is used, the filter criteria are specified in the request
payload with top-level elements, each of which corresponds to an payload with top-level elements, each of which corresponds to an
entry specified in Section 3.1, with the exception of the entry specified in Section 5.1, with the exception of the
'app_groups' status parameter. If names of application groups are 'app_groups' status parameter. If names of application groups are
used as filter criteria, each element of the 'app_groups' array from used as filter criteria, each element of the 'app_groups' array from
the status properties is included as a separate element with name the status properties is included as a separate element with name
'app_group'. With the exception of the 'app_group' element, a valid 'app_group'. With the exception of the 'app_group' element, a valid
request MUST NOT include the same element multiple times. Element request MUST NOT include the same element multiple times. Element
values are the ones admitted for the corresponding labels in the POST values are the ones admitted for the corresponding labels in the POST
request for creating a group configuration (see Section 4.3). request for creating a group configuration (see Section 6.3).
The Group Manager MUST prepare the list L to include in the response
as follows.
1. The Group Manager prepares a preliminary version of the list L,
as specified in Section 6.1 for the processing of a GET request
to the group-collection resource.
2. The Group Manager applies the filter criteria specified in the
FETCH request to the list L from the previous step. The result
is the list L to include in the response.
Example in custom CBOR and Link Format: Example in custom CBOR and Link Format:
=> 0.05 FETCH => 0.05 FETCH
Uri-Path: manage Uri-Path: manage
Content-Format: TBD2 (application/ace-groupcomm+cbor) Content-Format: TBD2 (application/ace-groupcomm+cbor)
{ {
"group_mode" : True, "group_mode" : true,
"sign_enc_alg" : 10, "sign_enc_alg" : 10,
"hkdf" : 5 "hkdf" : 5
} }
<= 2.05 Content <= 2.05 Content
Content-Format: 40 (application/link-format) Content-Format: 40 (application/link-format)
<coap://[2001:db8::ab]/manage/gp1>;rt="core.osc.gconf", <coap://[2001:db8::ab]/manage/gp1>;rt="core.osc.gconf",
<coap://[2001:db8::ab]/manage/gp2>;rt="core.osc.gconf", <coap://[2001:db8::ab]/manage/gp2>;rt="core.osc.gconf",
<coap://[2001:db8::ab]/manage/gp3>;rt="core.osc.gconf" <coap://[2001:db8::ab]/manage/gp3>;rt="core.osc.gconf"
Example in CoRAL: Example in CoRAL:
=> 0.05 FETCH => 0.05 FETCH
Uri-Path: manage Uri-Path: manage
Content-Format: TBD1 (application/coral+cbor) Content-Format: TBD1 (application/coral+cbor)
group_mode True group_mode true
sign_enc_alg 10 sign_enc_alg 10
hkdf 5 hkdf 5
<= 2.05 Content <= 2.05 Content
Content-Format: TBD1 (application/coral+cbor) Content-Format: TBD1 (application/coral+cbor)
#using <http://coreapps.org/core.osc.gcoll#> #using <http://coreapps.org/core.osc.gcoll#>
#base </manage/> #base </manage/>
item <gp1> item <gp1>
item <gp2> item <gp2>
item <gp3> item <gp3>
4.3. Create a New Group Configuration 6.3. Create a New Group Configuration
The Administrator can send a POST request to the group-collection The Administrator can send a POST request to the group-collection
resource, in order to create a new OSCORE group at the Group Manager. resource, in order to create a new OSCORE group at the Group Manager.
The request MAY specify the intended group name GROUPNAME and group The request MUST specify the intended group name GROUPNAME, and MAY
title, and MAY specify pieces of information concerning the group specify the intended group title together with pieces of information
configuration. concerning the group configuration.
When custom CBOR is used, the request payload is a CBOR map, whose When custom CBOR is used, the request payload is a CBOR map, whose
possible entries are specified in Section 3.1 and use the same possible entries are specified in Section 5.1 and use the same
abbreviations defined in Section 7.1. abbreviations defined in Section 9.1.
When CoRAL is used, each element of the request payload corresponds When CoRAL is used, each element of the request payload corresponds
to an entry specified in Section 3.1, with the exception of the to an entry specified in Section 5.1, with the exception of the
'app_groups' status parameter (see below). 'app_groups' status parameter (see below).
In particular: In particular:
* The payload MAY include any of the configuration parameter defined * The payload MAY include any of the configuration parameter defined
in Section 3.1.1. in Section 5.1.1.
* The payload MAY include any of the status parameter 'group_name', * The payload MUST include the status parameter 'group_name' defined
'group_title', 'max_stale_sets', 'exp', 'app_groups, in Section 5.1.2 and specifying the intended group name.
'group_policies', 'as_uri' and 'active' defined in Section 3.1.2.
- When CoRAL is used, each element of the 'app_groups' array from * The payload MAY include any of the status parameter 'group_title',
the status properties is included as a separate element with 'max_stale_sets', 'exp', 'app_groups, 'group_policies', 'as_uri'
name 'app_group'. and 'active' defined in Section 5.1.2.
When CoRAL is used, each element of the 'app_groups' array from
the status properties is included as a separate element with name
'app_group'.
* The payload MUST NOT include any of the status parameter 'rt', * The payload MUST NOT include any of the status parameter 'rt',
'ace-groupcomm-profile' and 'joining_uri' defined in 'ace-groupcomm-profile' and 'joining_uri' defined in
Section 3.1.2. Section 5.1.2.
If any of the following occurs, the Group Manager MUST respond with a Consistently with what is defined at step 4 of Section 4, the Group
4.00 (Bad Request) response. Manager MUST check whether the group name specified in the
'group_name' parameter matches with the group name pattern specified
in any scope entry of the 'scope' claim in the stored Access Token
for the Administrator. In case of a positive match, the Group
Manager MUST check whether the permission set in the found scope
entry specifies the permission "Create".
If the verification above fails (i.e., there are no matching scope
entries specifying the "Create" permission), the Group Manager MUST
reply with a 4.03 (Forbidden) error response. The response MUST have
Content-Format set to application/ace-groupcomm+cbor and is formatted
as defined in Section 4.1.2 of [I-D.ietf-ace-key-groupcomm].
Otherwise, if any of the following occurs, the Group Manager MUST
respond with a 4.00 (Bad Request) response.
* Any of the received parameters is specified multiple times, with * Any of the received parameters is specified multiple times, with
the exception of the 'app_group' element when using CoRAL. the exception of the 'app_group' element when using CoRAL.
* Any of the received parameters is not recognized, or not valid, or * Any of the received parameters is not recognized, or not valid, or
not consistent with respect to other related parameters. not consistent with respect to other related parameters.
* The 'group_name' parameter specifies the group name of an already
existing OSCORE group.
* The Group Manager does not trust the Authorization Server with URI * The Group Manager does not trust the Authorization Server with URI
specified in the 'as_uri' parameter, and has no alternative specified in the 'as_uri' parameter, and has no alternative
Authorization Server to consider for the OSCORE group to create. Authorization Server to consider for the OSCORE group to create.
After a successful processing of the request above, the Group Manager After a successful processing of the POST request, the Group Manager
performs the following actions. performs the following actions.
First, the Group Manager creates a new group-configuration resource, If the 'group_name' parameter specifies the group name of an already
accessible to the Administrator at /manage/GROUPNAME, where GROUPNAME existing OSCORE group, the Group Manager MUST find an alternative
is the name of the OSCORE group as either indicated in the parameter name for the new OSCORE group to create. Note that the final
'group_name' of the request or uniquely assigned by the Group decision about the name assigned to the new OSCORE group is always of
Manager. Note that the final decision about the name assigned to the the Group Manager, which may have more constraints than the
OSCORE group is of the Group Manager, which may have more constraints Administrator can be aware of, possibly beyond the availability of
than the Administrator can be aware of, possibly beyond the suggested names.
availability of suggested names.
If the Group Manager has selected a name GROUPNAME different from the
name GROUPNAME* indicated in the parameter 'group_name' of the
request, then the following conditions MUST hold.
* The chosen name GROUPNAME is available to assign; and
* If GROUPNAME* matches with the group name pattern of certain scope
entries from the 'scope' claim in the stored Access Token for the
Administrator, then the chosen group name GROUPNAME also matches
with each of those group name patterns.
If the Group Manager does not find any group name for which both the
above conditions hold, the Group Manager MUST respond with a 5.03
(Service Unavailable) response.
Otherwise, the Group Manager creates a new group-configuration
resource, accessible to the Administrator at /manage/GROUPNAME, where
GROUPNAME is the name of the OSCORE group as either indicated in the
parameter 'group_name' of the request or uniquely assigned by the
Group Manager.
The value of the status parameter 'rt' is set to "core.osc.gconf". The value of the status parameter 'rt' is set to "core.osc.gconf".
The values of other parameters specified in the request are used as The values of other parameters specified in the request are used as
group configuration information for the newly created OSCORE group. group configuration information for the newly created OSCORE group.
For each parameter not specified in the request, the Group Manager For each parameter not specified in the request, the Group Manager
MUST use default values as specified in Section 3.2. MUST use default values as specified in Section 5.2.
After that, the Group Manager creates a new group-membership resource After that, the Group Manager creates a new group-membership resource
accessible at ace-group/GROUPNAME to nodes that want to join the accessible at ace-group/GROUPNAME to nodes that want to join the
OSCORE group, as specified in Section 6.2 of OSCORE group, as specified in Section 6.2 of
[I-D.ietf-ace-key-groupcomm-oscore]. Note that such group [I-D.ietf-ace-key-groupcomm-oscore]. Note that such group
membership-resource comprises a number of sub-resources intended to membership-resource comprises a number of sub-resources intended to
current group members, as defined in Section 4.1 of current group members, as defined in Section 4.1 of
[I-D.ietf-ace-key-groupcomm] and Section 5 of [I-D.ietf-ace-key-groupcomm] and Section 5 of
[I-D.ietf-ace-key-groupcomm-oscore]. [I-D.ietf-ace-key-groupcomm-oscore].
skipping to change at page 20, line 27 skipping to change at page 28, line 13
within the set of OSCORE groups under the Group Manager. within the set of OSCORE groups under the Group Manager.
Finally, the Group Manager replies to the Administrator with a 2.01 Finally, the Group Manager replies to the Administrator with a 2.01
(Created) response. The Location-Path option MUST be included in the (Created) response. The Location-Path option MUST be included in the
response, indicating the location of the just created group- response, indicating the location of the just created group-
configuration resource. The response MUST NOT include a Location- configuration resource. The response MUST NOT include a Location-
Query option. Query option.
The response payload specifies the parameters 'group_name', The response payload specifies the parameters 'group_name',
'joining_uri' and 'as_uri', from the status properties of the newly 'joining_uri' and 'as_uri', from the status properties of the newly
created OSCORE group (see Section 3.1), as detailed below. created OSCORE group (see Section 5.1), as detailed below.
When custom CBOR is used, the response payload is a CBOR map, where When custom CBOR is used, the response payload is a CBOR map, where
entries use the same abbreviations defined in Section 7.1. When entries use the same abbreviations defined in Section 9.1. When
CoRAL is used, the response payload includes one element for each CoRAL is used, the response payload includes one element for each
specified parameter. specified parameter.
* 'group_name', with value the group name of the OSCORE group. This * 'group_name', with value the group name of the OSCORE group. This
value can be different from the group name possibly specified by value can be different from the group name possibly specified by
the Administrator in the POST request, and reflects the final the Administrator in the POST request, and reflects the final
choice of the Group Manager as 'group_name' status property for choice of the Group Manager as 'group_name' status property for
the OSCORE group. This parameter MUST be included. the OSCORE group. This parameter MUST be included.
* 'joining_uri', with value the URI of the group-membership resource * 'joining_uri', with value the URI of the group-membership resource
for joining the newly created OSCORE group. This parameter MUST for joining the newly created OSCORE group. This parameter MUST
be included. be included.
* 'as_uri', with value the URI of the Authorization Server * 'as_uri', with value the URI of the Authorization Server
associated to the Group Manager for the newly created OSCORE associated with the Group Manager for the newly created OSCORE
group. This parameter MUST be included if specified in the status group. This parameter MUST be included if specified in the status
properties of the group. This value can be different from the URI properties of the group. This value can be different from the URI
possibly specified by the Administrator in the POST request, and possibly specified by the Administrator in the POST request, and
reflects the final choice of the Group Manager as 'as_uri' status reflects the final choice of the Group Manager as 'as_uri' status
property for the OSCORE group. property for the OSCORE group.
If the POST request did not specify certain parameters and the Group If the POST request did not specify certain parameters and the Group
Manager used default values different than the ones recommended in Manager used default values different from the ones recommended in
Section 3.2, then the response payload MUST include also those Section 5.2, then the response payload MUST include also those
parameters, specifying the values chosen by the Group Manager for the parameters, specifying the values chosen by the Group Manager for the
current group configuration. current group configuration.
The Group Manager can register the link to the group-membership The Group Manager can register the link to the group-membership
resource with URI specified in 'joining_uri' to a Resource Directory resource with URI specified in 'joining_uri' to a Resource Directory
[I-D.ietf-core-resource-directory][I-D.hartke-t2trg-coral-reef], as [I-D.ietf-core-resource-directory][I-D.hartke-t2trg-coral-reef], as
defined in Section 2 of [I-D.tiloca-core-oscore-discovery]. The defined in Section 2 of [I-D.tiloca-core-oscore-discovery]. The
Group Manager considers the current group configuration when Group Manager considers the current group configuration when
specifying additional information for the link to register. specifying additional information for the link to register.
Alternatively, the Administrator can perform the registration in the Alternatively, the Administrator can perform the registration in the
Resource Directory on behalf of the Group Manager, acting as Resource Directory on behalf of the Group Manager, acting as
Commissioning Tool. The Administrator considers the following when Commissioning Tool. The Administrator considers the following when
specifying additional information for the link to register. specifying additional information for the link to register.
* The name of the OSCORE group MUST take the value specified in * The name of the OSCORE group MUST take the value specified in
'group_name' from the 2.01 (Created) response above. 'group_name' from the 2.01 (Created) response.
* The names of the application groups using the OSCORE group MUST * The names of the application groups using the OSCORE group MUST
take the values possibly specified by the elements of the take the values possibly specified by the elements of the
'app_groups' parameter (when custom CBOR is used) or by the 'app_groups' parameter (when custom CBOR is used) or by the
different 'app_group' elements (when CoRAL is used) in the POST different 'app_group' elements (when CoRAL is used) in the POST
request above. request.
* If also registering a related link to the Authorization Server * If also registering a related link to the Authorization Server
associated to the OSCORE group, the related link MUST have as link associated with the OSCORE group, the related link MUST have as
target the URI in 'as_uri' from the 2.01 (Created) response above, link target the URI in 'as_uri' from the 2.01 (Created) response,
if the 'as_uri' parameter was included in the response. if the 'as_uri' parameter was included in the response.
* Every other information element describing the current group * Every other information element describing the current group
configuration MUST take the value that the Administrator specified configuration MUST take the value that the Administrator specified
in the POST request. If a certain parameter was not specified in in the POST request. If a certain parameter was not specified in
the POST request, the Administrator MUST use either the value the POST request, the Administrator MUST use either the value
specified in the the 2.01 (Created) response above, if the Group specified in the the 2.01 (Created) response, if the Group Manager
Manager specified one, or the corresponding default value specified one, or the corresponding default value recommended in
recommended in Section 3.2.1 otherwise. Section 5.2.1 otherwise.
Note that, compared to the Group Manager, the Administrator is less Note that, compared to the Group Manager, the Administrator is less
likely to remain closely aligned with possible changes and updates likely to remain closely aligned with possible changes and updates
that would require a prompt update to the registration in the that would require a prompt update to the registration in the
Resource Directory. This applies especially to the address of the Resource Directory. This applies especially to the address of the
Group Manager, as well as the URI of the group-membership resource or Group Manager, as well as the URI of the group-membership resource or
of the Authorization Server associated to the Group Manager. of the Authorization Server associated with the Group Manager.
Therefore, it is RECOMMENDED that registrations of links to group- Therefore, it is RECOMMENDED that registrations of links to group-
membership resources in the Resource Directory are made (and possibly membership resources in the Resource Directory are made (and possibly
updated) directly by the Group Manager, rather than by the updated) directly by the Group Manager, rather than by the
Administrator. Administrator.
Example in custom CBOR: Example in custom CBOR:
=> 0.02 POST => 0.02 POST
Uri-Path: manage Uri-Path: manage
Content-Format: TBD2 (application/ace-groupcomm+cbor) Content-Format: TBD2 (application/ace-groupcomm+cbor)
{ {
"sign_enc_alg" : 10, "sign_enc_alg" : 10,
"hkdf" : 5, "hkdf" : 5,
"pairwise_mode" : True, "pairwise_mode" : true,
"active" : True, "active" : true,
"group_name" : "gp4",
"group_title" : "rooms 1 and 2", "group_title" : "rooms 1 and 2",
"app_groups": : ["room1", "room2"], "app_groups": : ["room1", "room2"],
"as_uri" : "coap://as.example.com/token" "as_uri" : "coap://as.example.com/token"
} }
<= 2.01 Created <= 2.01 Created
Location-Path: manage Location-Path: manage
Location-Path: gp4 Location-Path: gp4
Content-Format: TBD2 (application/ace-groupcomm+cbor) Content-Format: TBD2 (application/ace-groupcomm+cbor)
skipping to change at page 23, line 12 skipping to change at page 31, line 12
Example in CoRAL: Example in CoRAL:
=> 0.02 POST => 0.02 POST
Uri-Path: manage Uri-Path: manage
Content-Format: TBD1 (application/coral+cbor) Content-Format: TBD1 (application/coral+cbor)
#using <http://coreapps.org/core.osc.gconf#> #using <http://coreapps.org/core.osc.gconf#>
sign_enc_alg 10 sign_enc_alg 10
hkdf 5 hkdf 5
pairwise_mode True pairwise_mode true
active True active true
group_name "gp4"
group_title "rooms 1 and 2" group_title "rooms 1 and 2"
app_group "room1" app_group "room1"
app_group "room2" app_group "room2"
as_uri <coap://as.example.com/token> as_uri <coap://as.example.com/token>
<= 2.01 Created <= 2.01 Created
Location-Path: manage Location-Path: manage
Location-Path: gp4 Location-Path: gp4
Content-Format: TBD1 (application/coral+cbor) Content-Format: TBD1 (application/coral+cbor)
#using <http://coreapps.org/core.osc.gconf#> #using <http://coreapps.org/core.osc.gconf#>
group_name "gp4" group_name "gp4"
joining_uri <coap://[2001:db8::ab]/ace-group/gp4/> joining_uri <coap://[2001:db8::ab]/ace-group/gp4/>
as_uri <coap://as.example.com/token> as_uri <coap://as.example.com/token>
4.4. Retrieve a Group Configuration 6.4. Retrieve a Group Configuration
The Administrator can send a GET request to the group-configuration The Administrator can send a GET request to the group-configuration
resource manage/GROUPNAME associated to an OSCORE group with group resource manage/GROUPNAME associated with an OSCORE group with group
name GROUPNAME, in order to retrieve the complete current name GROUPNAME, in order to retrieve the complete current
configuration of that group. configuration of that group.
After a successful processing of the request above, the Group Manager Consistently with what is defined at step 4 of Section 4, the Group
replies to the Administrator with a 2.05 (Content) response. The Manager MUST check whether GROUPNAME matches with the group name
response has as payload the representation of the group configuration pattern specified in any scope entry of the 'scope' claim in the
as specified in Section 3.1. The exact content of the payload stored Access Token for the Administrator. In case of a positive
reflects the current configuration of the OSCORE group. This match, the Group Manager MUST check whether the permission set in the
includes both configuration properties and status properties. found scope entry specifies the permission "Read".
If the verification above fails (i.e., there are no matching scope
entries specifying the "Read" permission), the Group Manager MUST
reply with a 4.03 (Forbidden) error response. The response MUST have
Content-Format set to application/ace-groupcomm+cbor and is formatted
as defined in Section 4.1.2 of [I-D.ietf-ace-key-groupcomm].
Otherwise, after a successful processing of the GET request, the
Group Manager replies to the Administrator with a 2.05 (Content)
response. The response has as payload the representation of the
group configuration as specified in Section 5.1. The exact content
of the payload reflects the current configuration of the OSCORE
group. This includes both configuration properties and status
properties.
When custom CBOR is used, the response payload is a CBOR map, whose When custom CBOR is used, the response payload is a CBOR map, whose
possible entries are specified in Section 3.1 and use the same possible entries are specified in Section 5.1 and use the same
abbreviations defined in Section 7.1. abbreviations defined in Section 9.1.
When CoRAL is used, the response payload includes one element for When CoRAL is used, the response payload includes one element for
each entry specified in Section 3.1, with the exception of the each entry specified in Section 5.1, with the exception of the
'app_groups' status parameter. That is, each element of the 'app_groups' status parameter. That is, each element of the
'app_groups' array from the status properties is included as a 'app_groups' array from the status properties is included as a
separate element with name 'app_group'. separate element with name 'app_group'.
Example in custom CBOR: Example in custom CBOR:
=> 0.01 GET => 0.01 GET
Uri-Path: manage Uri-Path: manage
Uri-Path: gp4 Uri-Path: gp4
<= 2.05 Content <= 2.05 Content
Content-Format: TBD2 (application/ace-groupcomm+cbor) Content-Format: TBD2 (application/ace-groupcomm+cbor)
{ {
"hkdf" : 5, "hkdf" : 5,
"pub_key_enc" : 33, "cred_fmt" : 33,
"group_mode" : True, "group_mode" : true,
"sign_enc_alg" : 10, "sign_enc_alg" : 10,
"sign_alg" : -8, "sign_alg" : -8,
"sign_params" : [[1], [1, 6]], "sign_params" : [[1], [1, 6]],
"pairwise_mode" : True, "pairwise_mode" : true,
"alg" : 10, "alg" : 10,
"ecdh_alg" : -27, "ecdh_alg" : -27,
"ecdh_params" : [[1], [1, 6]], "ecdh_params" : [[1], [1, 6]],
"rt" : "core.osc.gconf", "rt" : "core.osc.gconf",
"active" : True, "active" : true,
"group_name" : "gp4", "group_name" : "gp4",
"group_title" : "rooms 1 and 2", "group_title" : "rooms 1 and 2",
"ace-groupcomm-profile" : "coap_group_oscore_app", "ace-groupcomm-profile" : "coap_group_oscore_app",
"max_stale_sets" : 3, "max_stale_sets" : 3,
"exp" : 1360289224, "exp" : 1360289224,
"app_groups": : ["room1", "room2"], "app_groups": : ["room1", "room2"],
"joining_uri" : "coap://[2001:db8::ab]/ace-group/gp4/", "joining_uri" : "coap://[2001:db8::ab]/ace-group/gp4/",
"as_uri" : "coap://as.example.com/token" "as_uri" : "coap://as.example.com/token"
} }
skipping to change at page 25, line 14 skipping to change at page 33, line 14
=> 0.01 GET => 0.01 GET
Uri-Path: manage Uri-Path: manage
Uri-Path: gp4 Uri-Path: gp4
<= 2.05 Content <= 2.05 Content
Content-Format: TBD1 (application/coral+cbor) Content-Format: TBD1 (application/coral+cbor)
#using <http://coreapps.org/core.osc.gconf#> #using <http://coreapps.org/core.osc.gconf#>
hkdf 5 hkdf 5
pub_key_enc 33 cred_fmt 33
group_mode True group_mode true
sign_enc_alg 10 sign_enc_alg 10
sign_alg -8 sign_alg -8
sign_params.alg_capab.key_type 1 sign_params.alg_capab.key_type 1
sign_params.key_type_capab.key_type 1 sign_params.key_type_capab.key_type 1
sign_params.key_type_capab.curve 6 sign_params.key_type_capab.curve 6
pairwise_mode True pairwise_mode true
alg 10 alg 10
ecdh_alg -27 ecdh_alg -27
ecdh_params.alg_capab.key_type 1 ecdh_params.alg_capab.key_type 1
ecdh_params.key_type_capab.key_type 1 ecdh_params.key_type_capab.key_type 1
ecdh_params.key_type_capab.curve 6 ecdh_params.key_type_capab.curve 6
rt "core.osc.gconf", rt "core.osc.gconf",
active True active true
group_name "gp4" group_name "gp4"
group_title "rooms 1 and 2" group_title "rooms 1 and 2"
ace-groupcomm-profile "coap_group_oscore_app" ace-groupcomm-profile "coap_group_oscore_app"
max_stale_sets 3 max_stale_sets 3
exp 1360289224 exp 1360289224
app_group "room1" app_group "room1"
app_group "room2" app_group "room2"
joining_uri <coap://[2001:db8::ab]/ace-group/gp4/> joining_uri <coap://[2001:db8::ab]/ace-group/gp4/>
as_uri <coap://as.example.com/token> as_uri <coap://as.example.com/token>
4.5. Retrieve Part of a Group Configuration by Filters 6.5. Retrieve Part of a Group Configuration by Filters
The Administrator can send a FETCH request to the group-configuration The Administrator can send a FETCH request to the group-configuration
resource manage/GROUPNAME associated to an OSCORE group with group resource manage/GROUPNAME associated with an OSCORE group with group
name GROUPNAME, in order to retrieve part of the current name GROUPNAME, in order to retrieve part of the current
configuration of that group. configuration of that group.
When custom CBOR is used, the request payload is a CBOR map, which When custom CBOR is used, the request payload is a CBOR map, which
contains the following fields: contains the following fields:
* 'conf_filter', defined in Section 7.1 of this document and encoded * 'conf_filter', defined in Section 9.1 of this document and encoded
as a CBOR array. Each element of the array specifies one as a CBOR array. Each element of the array specifies one
requested configuration parameter or status parameter of the requested configuration parameter or status parameter of the
current group configuration (see Section 3.1), using the current group configuration (see Section 5.1), using the
corresponding abbreviation defined in Section 7.1. corresponding abbreviation defined in Section 9.1.
When CoRAL is used, the request payload includes one element for each When CoRAL is used, the request payload includes one element for each
requested configuration parameter or status parameter of the current requested configuration parameter or status parameter of the current
group configuration (see Section 3.1). All the specified elements group configuration (see Section 5.1). All the specified elements
have no value. have no value.
After a successful processing of the request above, the Group Manager The Group Manager MUST perform the same authorization checks defined
for the processing of a GET request to a group-configuration resource
in Section 6.4. That is, the Group Manager MUST verify that the
Administrator has been granted a "Read" permission applicable to the
targeted group-configuration resource.
After a successful processing of the FETCH request, the Group Manager
replies to the Administrator with a 2.05 (Content) response. The replies to the Administrator with a 2.05 (Content) response. The
response has as payload a partial representation of the group response has as payload a partial representation of the group
configuration (see Section 3.1). The exact content of the payload configuration (see Section 5.1). The exact content of the payload
reflects the current configuration of the OSCORE group, and is reflects the current configuration of the OSCORE group, and is
limited to the configuration properties and status properties limited to the configuration properties and status properties
requested by the Administrator in the FETCH request. requested by the Administrator in the FETCH request.
The response payload includes the requested configuration parameters The response payload includes the requested configuration parameters
and status parameters, and is formatted as in the response payload of and status parameters, and is formatted as in the response payload of
a GET request to a group-configuration resource (see Section 4.4). a GET request to a group-configuration resource (see Section 6.4).
Example in custom CBOR: Example in custom CBOR:
=> 0.05 FETCH => 0.05 FETCH
Uri-Path: manage Uri-Path: manage
Uri-Path: gp4 Uri-Path: gp4
Content-Format: TBD2 (application/ace-groupcomm+cbor) Content-Format: TBD2 (application/ace-groupcomm+cbor)
{ {
"conf_filter" : ["sign_enc_alg", "conf_filter" : ["sign_enc_alg",
skipping to change at page 27, line 25 skipping to change at page 35, line 25
"group_title", "group_title",
"app_groups"] "app_groups"]
} }
<= 2.05 Content <= 2.05 Content
Content-Format: TBD2 (application/ace-groupcomm+cbor) Content-Format: TBD2 (application/ace-groupcomm+cbor)
{ {
"sign_enc_alg" : 10, "sign_enc_alg" : 10,
"hkdf" : 5, "hkdf" : 5,
"pairwise_mode" : True, "pairwise_mode" : true,
"active" : True, "active" : true,
"group_title" : "rooms 1 and 2", "group_title" : "rooms 1 and 2",
"app_groups": : ["room1", "room2"] "app_groups": : ["room1", "room2"]
} }
Example in CoRAL: Example in CoRAL:
=> 0.05 FETCH => 0.05 FETCH
Uri-Path: manage Uri-Path: manage
Uri-Path: gp4 Uri-Path: gp4
Content-Format: TBD1 (application/coral+cbor) Content-Format: TBD1 (application/coral+cbor)
skipping to change at page 28, line 24 skipping to change at page 36, line 24
active active
group_title group_title
app_groups app_groups
<= 2.05 Content <= 2.05 Content
Content-Format: TBD1 (application/coral+cbor) Content-Format: TBD1 (application/coral+cbor)
#using <http://coreapps.org/core.osc.gconf#> #using <http://coreapps.org/core.osc.gconf#>
sign_enc_alg 10 sign_enc_alg 10
hkdf 5 hkdf 5
pairwise_mode True pairwise_mode true
active True active true
group_title "rooms 1 and 2" group_title "rooms 1 and 2"
app_group "room1" app_group "room1"
app_group "room2" app_group "room2"
4.6. Overwrite a Group Configuration 6.6. Overwrite a Group Configuration
The Administrator can send a PUT request to the group-configuration The Administrator can send a PUT request to the group-configuration
resource associated to an OSCORE group, in order to overwrite the resource associated with an OSCORE group, in order to overwrite the
current configuration of that group with a new one. The payload of current configuration of that group with a new one. The payload of
the request has the same format of the POST request defined in the request has the same format of the POST request defined in
Section 4.3, with the exception that the configuration parameters Section 6.3, with the exception that the configuration parameters
'group_mode' and 'pairwise_mode' as well as the status parameter 'group_mode' and 'pairwise_mode' as well as the status parameter
'group_name' MUST NOT be included. 'group_name' MUST NOT be included.
The error handling for the PUT request is the same as for the POST The error handling for the PUT request is the same as for the POST
request defined in Section 4.3. If no error occurs, the Group request defined in Section 6.3, with the following difference in
Manager performs the following actions. terms of authorization checks.
Consistently with what is defined at step 4 of Section 4, the Group
Manager MUST check whether GROUPNAME matches with the group name
pattern specified in any scope entry of the 'scope' claim in the
stored Access Token for the Administrator. In case of a positive
match, the Group Manager MUST check whether the permission set in the
found scope entry specifies the permission "Write".
If the verification above fails (i.e., there are no matching scope
entries specifying the "Write" permission), the Group Manager MUST
reply with a 4.03 (Forbidden) error response. The response MUST have
Content-Format set to application/ace-groupcomm+cbor and is formatted
as defined in Section 4.1.2 of [I-D.ietf-ace-key-groupcomm].
If no error occurs and the PUT request is successfully processed, the
Group Manager performs the following actions.
First, the Group Manager updates the group-configuration resource, First, the Group Manager updates the group-configuration resource,
consistently with the values indicated in the PUT request from the consistently with the values indicated in the PUT request from the
Administrator. For each parameter not specified in the PUT request, Administrator. For each parameter not specified in the PUT request,
the Group Manager MUST use default values as specified in the Group Manager MUST use default values as specified in
Section 3.2. Section 5.2.
If a new value N' is specified for the 'max_stale_sets' status If a new value N' is specified for the 'max_stale_sets' status
parameter and N' is smaller than the current value N, the Group parameter and N' is smaller than the current value N, the Group
Manager preserves the (up to) N' most recent sets in the collection Manager preserves the (up to) N' most recent sets in the collection
of sets of stale OSCORE Sender IDs associated to the group, and of sets of stale OSCORE Sender IDs associated with the group, and
deletes any possible older set from the collection (see Section 2.2.1 deletes any possible older set from the collection (see Section 2.2.1
of [I-D.ietf-ace-key-groupcomm-oscore]). of [I-D.ietf-ace-key-groupcomm-oscore]).
From then on, the Group Manager relies on the latest updated From then on, the Group Manager relies on the latest updated
configuration to build the Joining Response message defined in configuration to build the Joining Response message defined in
Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore], when handling the Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore], when handling the
joining of a new group member. Similarly, the Group Manager relies joining of a new group member. Similarly, the Group Manager relies
on the new group configuration when building responses specifying on the new group configuration when building responses specifying
(part of) the group configuration to a current group member. For (part of) the group configuration to a current group member. For
instance, this applies when a group member retrieves from the Group instance, this applies when a group member retrieves from the Group
Manager the updated group keying material (see Section 8 of Manager the updated group keying material (see Section 8 of
[I-D.ietf-ace-key-groupcomm-oscore]) or the current group status (see [I-D.ietf-ace-key-groupcomm-oscore]) or the current group status (see
Section 16 of [I-D.ietf-ace-key-groupcomm-oscore]). Section 16 of [I-D.ietf-ace-key-groupcomm-oscore]).
Then, the Group Manager replies to the Administrator with a 2.04 Then, the Group Manager replies to the Administrator with a 2.04
(Changed) response. The payload of the response has the same format (Changed) response. The payload of the response has the same format
of the 2.01 (Created) response defined in Section 4.3. of the 2.01 (Created) response defined in Section 6.3.
If the PUT request did not specify certain parameters and the Group If the PUT request did not specify certain parameters and the Group
Manager used default values different than the ones recommended in Manager used default values different from the ones recommended in
Section 3.2, then the response payload MUST include also those Section 5.2, then the response payload MUST include also those
parameters, specifying the values chosen by the Group Manager for the parameters, specifying the values chosen by the Group Manager for the
current group configuration. current group configuration.
If the link to the group-membership resource was registered in the If the link to the group-membership resource was registered in the
Resource Directory [I-D.ietf-core-resource-directory], the GM is Resource Directory [I-D.ietf-core-resource-directory], the GM is
responsible to refresh the registration, as defined in Section 3 of responsible to refresh the registration, as defined in Section 3 of
[I-D.tiloca-core-oscore-discovery]. [I-D.tiloca-core-oscore-discovery].
Alternatively, the Administrator can update the registration in the Alternatively, the Administrator can update the registration in the
Resource Directory on behalf of the Group Manager, acting as Resource Directory on behalf of the Group Manager, acting as
Commissioning Tool. The Administrator considers the following when Commissioning Tool. The Administrator considers the following when
specifying additional information for the link to update. specifying additional information for the link to update.
* The name of the OSCORE group MUST take the value specified in * The name of the OSCORE group MUST take the value specified in
'group_name' from the 2.04 (Changed) response above. 'group_name' from the 2.04 (Changed) response.
* The names of the application groups using the OSCORE group MUST * The names of the application groups using the OSCORE group MUST
take the values possibly specified by the elements of the take the values possibly specified by the elements of the
'app_groups' parameter (when custom CBOR is used) or by the 'app_groups' parameter (when custom CBOR is used) or by the
different 'app_group' elements (when CoRAL is used) in the PUT different 'app_group' elements (when CoRAL is used) in the PUT
request above. request.
* If also registering a related link to the Authorization Server * If also registering a related link to the Authorization Server
associated to the OSCORE group, the related link MUST have as link associated with the OSCORE group, the related link MUST have as
target the URI in 'as_uri' from the 2.04 (Changed) response above, link target the URI in 'as_uri' from the 2.04 (Changed) response,
if the 'as_uri' parameter was included in the response. if the 'as_uri' parameter was included in the response.
* Every other information element describing the current group * Every other information element describing the current group
configuration MUST take the value that the Administrator specified configuration MUST take the value that the Administrator specified
in the PUT request. If a certain parameter was not specified in in the PUT request. If a certain parameter was not specified in
the PUT request, the Administrator MUST use either the value the PUT request, the Administrator MUST use either the value
specified in the the 2.04 (Changed) response above, if the Group specified in the the 2.04 (Changed) response, if the Group Manager
Manager specified one, or the corresponding default value specified one, or the corresponding default value recommended in
recommended in Section 3.2.1 otherwise. Section 5.2.1 otherwise.
As discussed in Section 4.3, it is RECOMMENDED that registrations of As discussed in Section 6.3, it is RECOMMENDED that registrations of
links to group-membership resources in the Resource Directory are links to group-membership resources in the Resource Directory are
made (and possibly updated) directly by the Group Manager, rather made (and possibly updated) directly by the Group Manager, rather
than by the Administrator. than by the Administrator.
Example in custom CBOR: Example in custom CBOR:
=> 0.03 PUT => 0.03 PUT
Uri-Path: manage Uri-Path: manage
Uri-Path: gp4 Uri-Path: gp4
Content-Format: TBD2 (application/ace-groupcomm+cbor) Content-Format: TBD2 (application/ace-groupcomm+cbor)
skipping to change at page 31, line 22 skipping to change at page 39, line 43
hkdf 5 hkdf 5
<= 2.04 Changed <= 2.04 Changed
Content-Format: TBD1 (application/coral+cbor) Content-Format: TBD1 (application/coral+cbor)
#using <http://coreapps.org/core.osc.gconf#> #using <http://coreapps.org/core.osc.gconf#>
group_name "gp4" group_name "gp4"
joining_uri <coap://[2001:db8::ab]/ace-group/gp4/> joining_uri <coap://[2001:db8::ab]/ace-group/gp4/>
as_uri <coap://as.example.com/token> as_uri <coap://as.example.com/token>
4.6.1. Effects on Joining Nodes 6.6.1. Effects on Joining Nodes
After having overwritten a group configuration, if the value of the After having overwritten a group configuration, if the value of the
status parameter 'active' is changed from True to False, the Group status parameter 'active' is changed from "true" (0xf5) to "false"
Manager MUST stop admitting new members in the OSCORE group. In (0xf4), the Group Manager MUST stop admitting new members in the
particular, until the status parameter 'active' is changed back to OSCORE group. In particular, until the status parameter 'active' is
True, the Group Manager MUST respond to a Joining Request with a 5.03 changed back to "true" (0xf5), the Group Manager MUST respond to a
(Service Unavailable) response, as defined in Section 6.3 of Joining Request with a 5.03 (Service Unavailable) response, as
[I-D.ietf-ace-key-groupcomm-oscore]. defined in Section 6.3 of [I-D.ietf-ace-key-groupcomm-oscore].
If the value of the status parameter 'active' is changed from False If the value of the status parameter 'active' is changed from "false"
to True, the Group Manager resumes admitting new members in the (0xf4) to "true" (0xf5), the Group Manager resumes admitting new
OSCORE group, by processing their Joining Requests (see Section 6.3 members in the OSCORE group, by processing their Joining Requests
of [I-D.ietf-ace-key-groupcomm-oscore]). (see Section 6.3 of [I-D.ietf-ace-key-groupcomm-oscore]).
4.6.2. Effects on the Group Members 6.6.2. Effects on the Group Members
After having overwritten a group configuration, the Group Manager After having overwritten a group configuration, the Group Manager
informs the members of the OSCORE group, over the pairwise secure informs the members of the OSCORE group, over the pairwise secure
communication channels established when joining the group (see communication channels established when joining the group (see
Section 6 of [I-D.ietf-ace-key-groupcomm-oscore]). Section 6 of [I-D.ietf-ace-key-groupcomm-oscore]).
To this end, the Group Manager can individually target the To this end, the Group Manager can individually target the
'control_uri' URI of each group member (see Section 4.3.1 of 'control_uri' URI of each group member (see Section 4.3.1 of
[I-D.ietf-ace-key-groupcomm]), if provided by the intended recipient [I-D.ietf-ace-key-groupcomm]), if provided by the intended recipient
upon joining the OSCORE group (see Section 6.2 of upon joining the OSCORE group (see Section 6.2 of
[I-D.ietf-ace-key-groupcomm-oscore]). Alternatively, group members [I-D.ietf-ace-key-groupcomm-oscore]). To this end, messages sent by
can subscribe for updates to the group-membership resource of the the Group Manager to each group member MUST have Content-Format set
OSCORE group, e.g., by using CoAP Observe [RFC7641]. to application/ace-groupcomm+cbor, and MUST be formatted as the
Joining Response defined in Section 6.4 of
[I-D.ietf-ace-key-groupcomm-oscore], with the following differences.
If the value of the status parameter 'active' is changed from True to * Only the parameters 'gkty', 'key', 'num', 'exp' and 'ace-
False: groupcomm-profile' are present.
* The 'key' parameter includes only the parameters 'hkdf',
'cred_fmt', 'sign_enc_alg', 'sign_alg', 'sign_params', 'alg',
'ecdh_alg' and 'ecdh_params', with values reflecting the new
configuration of the OSCORE group.
Alternatively, group members can subscribe for updates to the group-
membership resource of the OSCORE group, e.g., by using CoAP Observe
[RFC7641].
If the value of the status parameter 'active' is changed from "true"
(0xf5) to "false" (0xf4):
* The Group Manager MUST stop accepting requests for new individual * The Group Manager MUST stop accepting requests for new individual
keying material from current group members (see Section 9 of keying material from current group members (see Section 9 of
[I-D.ietf-ace-key-groupcomm-oscore]). In particular, until the [I-D.ietf-ace-key-groupcomm-oscore]). In particular, until the
status parameter 'active' is changed back to True, the Group status parameter 'active' is changed back to "true" (0xf5), the
Manager MUST respond to a Key Renewal Request with a 5.03 (Service Group Manager MUST respond to a Key Renewal Request with a 5.03
Unavailable) response, as defined in Section 9 of (Service Unavailable) response, as defined in Section 9 of
[I-D.ietf-ace-key-groupcomm-oscore]. [I-D.ietf-ace-key-groupcomm-oscore].
* The Group Manager MUST stop accepting updated public keys uploaded * The Group Manager MUST stop accepting updated authentication
by current group members (see Section 11 of credentials uploaded by current group members (see Section 11 of
[I-D.ietf-ace-key-groupcomm-oscore]). In particular, until the [I-D.ietf-ace-key-groupcomm-oscore]). In particular, until the
status parameter 'active' is changed back to True, the Group status parameter 'active' is changed back to "true" (0xf5), the
Manager MUST respond to a Public Key Update Request with a 5.03 Group Manager MUST respond to a Public Key Update Request with a
(Service Unavailable) response, as defined in Section 11 of 5.03 (Service Unavailable) response, as defined in Section 11 of
[I-D.ietf-ace-key-groupcomm-oscore]. [I-D.ietf-ace-key-groupcomm-oscore].
Every group member, upon learning that the OSCORE group has been Every group member, upon learning that the OSCORE group has been
deactivated (i.e., 'active' has value False), SHOULD stop deactivated (i.e., 'active' has value "false" (0xf4)), SHOULD stop
communicating in the group. communicating in the group.
Every group member, upon learning that the OSCORE group has been Every group member, upon learning that the OSCORE group has been
reactivated (i.e., 'active' has value True again), can resume reactivated (i.e., 'active' has value "true" (0xf5) again), can
communicating in the group. resume communicating in the group.
Every group member, upon receiving updated values for 'hkdf', Every group member, upon receiving updated values for 'hkdf',
'sign_enc_alg' and 'alg', MUST either: 'sign_enc_alg' and 'alg', MUST either:
* Leave the OSCORE group (see Section 18 of * Leave the OSCORE group (see Section 18 of
[I-D.ietf-ace-key-groupcomm-oscore]), e.g., if not supporting the [I-D.ietf-ace-key-groupcomm-oscore]), e.g., if not supporting the
indicated new algorithms; or indicated new algorithms; or
* Use the new parameter values, and accordingly re-derive the OSCORE * Use the new parameter values, and accordingly re-derive the OSCORE
Security Context for the OSCORE group (see Section 2 of Security Context for the OSCORE group (see Section 2 of
[I-D.ietf-core-oscore-groupcomm]). [I-D.ietf-core-oscore-groupcomm]).
Every group member, upon receiving updated values for 'pub_key_enc', Every group member, upon receiving updated values for 'cred_fmt',
'sign_alg', 'sign_params', 'ecdh_alg' and 'ecdh_params' MUST either: 'sign_alg', 'sign_params', 'ecdh_alg' and 'ecdh_params' MUST either:
* Leave the OSCORE group, e.g., if not supporting the indicated new * Leave the OSCORE group, e.g., if not supporting the indicated new
algorithms, parameters and encoding; or format, algorithms, parameters and encoding; or
* Leave the OSCORE group and rejoin it (see Section 6 of * Leave the OSCORE group and rejoin it (see Section 6 of
[I-D.ietf-ace-key-groupcomm-oscore]), providing the Group Manager [I-D.ietf-ace-key-groupcomm-oscore]). When rejoining the group, a
with a public key which is compatible with the indicated new new authentication credential in the indicated format used in the
algorithms, parameters and encoding; or OSCORE group MUST be provided to the Group Manager. The
authentication credential as well as the included public key MUST
be compatible with the indicated algorithms and parameters.
* Use the new parameter values, and, if required, performs the * Use the new parameter values, and, if required, perform the
following actions: i) provide the Group Manager with a new public following actions.
key to use in the OSCORE group, as compatible with the indicated
parameters (see Section 11 of
[I-D.ietf-ace-key-groupcomm-oscore]); ii) retrieve from the Group
Manager the new Group Manager's public key (see Section 12 of
[I-D.ietf-ace-key-groupcomm-oscore]), as also compatible with the
indicated new algorithms, parameters and encoding.
4.7. Selective Update of a Group Configuration - Provide the Group Manager with a new authentication credential
to use in the OSCORE group (see Section 11 of
[I-D.ietf-ace-key-groupcomm-oscore]). The new authentication
credential MUST be in the indicated format used in the OSCORE
group. The new authentication credential as well as the
included public key MUST be compatible with the indicated
algorithms and parameters.
- Retrieve from the Group Manager the new Group Manager's
authentication credential (see Section 12 of
[I-D.ietf-ace-key-groupcomm-oscore]). The new Group Manager's
authentication credential is in the indicated format used in
the OSCORE group. The new authentication credential as well as
the included public key are compatible with the indicated
algorithms and parameters.
6.7. Selective Update of a Group Configuration
The Administrator can send a PATCH/iPATCH request [RFC8132] to the The Administrator can send a PATCH/iPATCH request [RFC8132] to the
group-configuration resource associated to an OSCORE group, in order group-configuration resource associated with an OSCORE group, in
to update the value of only part of the group configuration. order to update the value of only part of the group configuration.
The request payload has the same format of the PUT request defined in The request payload has the same format of the PUT request defined in
Section 4.6, with the difference that it MAY also specify names of Section 6.6, with the difference that it MAY also specify names of
application groups to be removed from or added to the 'app_groups' application groups to be removed from or added to the 'app_groups'
status parameter. The names of such application groups are provided status parameter. The names of such application groups are provided
as defined below. as defined below.
* When custom CBOR is used, the CBOR map in the request payload * When custom CBOR is used, the CBOR map in the request payload
includes the field 'app_groups_diff'. This field MUST NOT be includes the field 'app_groups_diff'. This field MUST NOT be
present multiple times, and it is encoded as a CBOR array present multiple times, and it is encoded as a CBOR array
including the following two elements. including the following two elements.
- The first element is a CBOR array, namely 'app_groups_del'. - The first element is a CBOR array, namely 'app_groups_del'.
skipping to change at page 33, line 50 skipping to change at page 42, line 49
The CDDL definition [RFC8610] of the CBOR array 'app_groups_diff' The CDDL definition [RFC8610] of the CBOR array 'app_groups_diff'
formatted as in the response from the Group Manager is provided formatted as in the response from the Group Manager is provided
below. below.
app-group-name = tstr app-group-name = tstr
name-patch = [* app-group-name] name-patch = [* app-group-name]
app_groups_diff = [app_groups_del: name-patch, app_groups_diff = [app_groups_del: name-patch,
app_groups_add: name-patch] app_groups_add: name-patch]
Figure 2: CDDL definition of the 'app_groups_diff' field Figure 3: CDDL definition of the 'app_groups_diff' field
The Group Manager MUST respond with a 4.00 (Bad Request) response, in The Group Manager MUST respond with a 4.00 (Bad Request) response, in
case both the inner CBOR arrays 'app_groups_del' and 'app_groups_add' case both the inner CBOR arrays 'app_groups_del' and 'app_groups_add'
are empty, or in case the 'app_groups_diff' field occurs more than are empty, or in case the 'app_groups_diff' field occurs more than
once. once.
The Group Manager MUST respond with a 4.00 (Bad Request) response, in The Group Manager MUST respond with a 4.00 (Bad Request) response, in
case the CBOR map in the request payload includes both the case the CBOR map in the request payload includes both the
'app_groups' field and the 'app_groups_diff' field. 'app_groups' field and the 'app_groups_diff' field.
skipping to change at page 34, line 30 skipping to change at page 43, line 30
- 'app_group_add', with value a text string specifying the name - 'app_group_add', with value a text string specifying the name
of an application group to add to the 'app_groups' status of an application group to add to the 'app_groups' status
parameter. This element can be included multiple times. parameter. This element can be included multiple times.
The Group Manager MUST respond with a 4.00 (Bad Request) response, The Group Manager MUST respond with a 4.00 (Bad Request) response,
in case the request payload includes both any 'app_group' element in case the request payload includes both any 'app_group' element
as well as any 'app_group_del' and/or 'app_group_add' element. as well as any 'app_group_del' and/or 'app_group_add' element.
The error handling for the PATCH/iPATCH request is the same as for The error handling for the PATCH/iPATCH request is the same as for
the PUT request defined in Section 4.6, with the following additions. the PUT request defined in Section 6.6, with the following additions.
* The set of group configuration parameters to update MUST NOT be * The set of group configuration parameters to update MUST NOT be
empty. That is, the Group Manager MUST respond with a 4.00 (Bad empty. That is, the Group Manager MUST respond with a 4.00 (Bad
Request) response, if the request payload includes an empty CBOR Request) response, if the request payload includes an empty CBOR
map (when custom CBOR is used) or no elements (when CoRAL is map (when custom CBOR is used) or no elements (when CoRAL is
used). used).
* If the Request-URI does not point to an existing group- * If the Request-URI does not point to an existing group-
configuration resource, the Group Manager MUST NOT create a new configuration resource, the Group Manager MUST NOT create a new
resource, and MUST respond with a 4.04 (Not Found) response. resource, and MUST respond with a 4.04 (Not Found) response.
* When applying the specified updated values would yield an * When applying the specified updated values would yield an
inconsistent group configuration, the Group Manager MUST respond inconsistent group configuration, the Group Manager MUST respond
with a 4.09 (Conflict) response. with a 4.09 (Conflict) response.
The response, MAY include the current representation of the group The response, MAY include the current representation of the group
configuration resource, like when responding to a GET request as configuration resource, like when responding to a GET request as
defined in Section 4.4. Otherwise, the response SHOULD include a defined in Section 6.4. Otherwise, the response SHOULD include a
diagnostic payload with additional information for the diagnostic payload with additional information for the
Administrator to recognize the source of the conflict. Administrator to recognize the source of the conflict.
* When the request uses specifically the iPATCH method, the Group * When the request uses specifically the iPATCH method, the Group
Manager MUST respond with a 4.00 (Bad Request) response, in case: Manager MUST respond with a 4.00 (Bad Request) response, in case:
- When custom CBOR is used, the CBOR map includes the parameter - When custom CBOR is used, the CBOR map includes the parameter
'app_groups_diff'; or 'app_groups_diff'; or
- When CoRAL is used, any element 'app_group_del' and/or - When CoRAL is used, any element 'app_group_del' and/or
'app_group_add' is included. 'app_group_add' is included.
If no error occurs, the Group Manager performs the following actions. Furthermore, the Group Manager MUST perform the same authorization
checks defined for the processing of a PUT request to a group-
configuration resource in Section 6.6. That is, the Group Manager
MUST verify that the Administrator has been granted a "Write"
permission applicable to the targeted group-configuration resource.
If no error occurs and the PATCH/iPATCH request is successfully
processed, the Group Manager performs the following actions.
First, the Group Manager updates the group-configuration resource, First, the Group Manager updates the group-configuration resource,
consistently with the values indicated in the PATCH/iPATCH request consistently with the values indicated in the PATCH/iPATCH request
from the Administrator. from the Administrator.
Unlike for the PUT request defined in Section 4.6, the Group Manager Unlike for the PUT request defined in Section 6.6, the Group Manager
does not alter the value of configuration parameters and status does not alter the value of configuration parameters and status
parameters for which updated values are not specified in the request parameters for which updated values are not specified in the request
payload. In particular, the Group Manager does not assign possible payload. In particular, the Group Manager does not assign possible
default values to those parameters. default values to those parameters.
Special processing occurs when updating the 'app_groups' status Special processing occurs when updating the 'app_groups' status
parameter by difference, as defined below. The Administrator should parameter by difference, as defined below. The Administrator should
not expect the Group Manager to add or delete names of application not expect the Group Manager to add or delete names of application
group names according to any particular order. group names according to any particular order.
skipping to change at page 36, line 29 skipping to change at page 45, line 37
new group member. Similarly, the Group Manager relies on the new new group member. Similarly, the Group Manager relies on the new
group configuration when building responses specifying (part of) the group configuration when building responses specifying (part of) the
group configuration to a current group member. For instance, this group configuration to a current group member. For instance, this
applies when a group member retrieves from the Group Manager the applies when a group member retrieves from the Group Manager the
updated group keying material (see Section 8 of updated group keying material (see Section 8 of
[I-D.ietf-ace-key-groupcomm-oscore]) or the current group status (see [I-D.ietf-ace-key-groupcomm-oscore]) or the current group status (see
Section 16 of [I-D.ietf-ace-key-groupcomm-oscore]). Section 16 of [I-D.ietf-ace-key-groupcomm-oscore]).
Finally, the Group Manager replies to the Administrator with a 2.04 Finally, the Group Manager replies to the Administrator with a 2.04
(Changed) response. The payload of the response has the same format (Changed) response. The payload of the response has the same format
of the 2.01 (Created) response defined in Section 4.3. of the 2.01 (Created) response defined in Section 6.3.
The same considerations as for the PUT request defined in Section 4.6 The same considerations as for the PUT request defined in Section 6.6
hold also in this case, with respect to refreshing a possible hold also in this case, with respect to refreshing a possible
registration of the link to the group-membership resource in the registration of the link to the group-membership resource in the
Resource Directory [I-D.ietf-core-resource-directory]. Resource Directory [I-D.ietf-core-resource-directory].
Example in custom CBOR: Example in custom CBOR:
=> 0.06 PATCH => 0.06 PATCH
Uri-Path: manage Uri-Path: manage
Uri-Path: gp4 Uri-Path: gp4
Content-Format: TBD2 (application/ace-groupcomm+cbor) Content-Format: TBD2 (application/ace-groupcomm+cbor)
skipping to change at page 37, line 46 skipping to change at page 46, line 46
app_group_add "room4" app_group_add "room4"
<= 2.04 Changed <= 2.04 Changed
Content-Format: TBD1 (application/coral+cbor) Content-Format: TBD1 (application/coral+cbor)
#using <http://coreapps.org/core.osc.gconf#> #using <http://coreapps.org/core.osc.gconf#>
group_name "gp4" group_name "gp4"
joining_uri <coap://[2001:db8::ab]/ace-group/gp4/> joining_uri <coap://[2001:db8::ab]/ace-group/gp4/>
as_uri <coap://as.example.com/token> as_uri <coap://as.example.com/token>
4.7.1. Effects on Joining Nodes 6.7.1. Effects on Joining Nodes
After having selectively updated part of a group configuration, the After having selectively updated part of a group configuration, the
effects on candidate joining nodes are the same as defined in effects on candidate joining nodes are the same as defined in
Section 4.6.1 for the case of group configuration overwriting. Section 6.6.1 for the case of group configuration overwriting.
4.7.2. Effects on the Group Members 6.7.2. Effects on the Group Members
After having selectively updated part of a group configuration, the After having selectively updated part of a group configuration, the
effects on the current group members are the same as defined in effects on the current group members are the same as defined in
Section 4.6.2 for the case of group configuration overwriting. Section 6.6.2 for the case of group configuration overwriting.
4.8. Delete a Group Configuration 6.8. Delete a Group Configuration
The Administrator can send a DELETE request to the group- The Administrator can send a DELETE request to the group-
configuration resource, in order to delete that OSCORE group. The configuration resource, in order to delete that OSCORE group.
deletion would be successful only on an inactive OSCORE group.
That is, the DELETE request actually yields a successful deletion of Consistently with what is defined at step 4 of Section 4, the Group
the OSCORE group, only if the corresponding status parameter 'active' Manager MUST check whether GROUPNAME matches with the group name
has current value False. The Administrator can ensure that, by first pattern specified in any scope entry of the 'scope' claim in the
performing an update of the group-configuration resource associated stored Access Token for the Administrator. In case of a positive
to the OSCORE group (see Section 4.6), and setting the corresponding match, the Group Manager MUST check whether the permission set in the
status parameter 'active' to False. found scope entry specifies the permission "Delete".
If the verification above fails (i.e., there are no matching scope
entries specifying the "Delete" permission), the Group Manager MUST
reply with a 4.03 (Forbidden) error response. The response MUST have
Content-Format set to application/ace-groupcomm+cbor and is formatted
as defined in Section 4.1.2 of [I-D.ietf-ace-key-groupcomm].
Otherwise, the Group Manager continues processing the request, which
would be successful only on an inactive OSCORE group. That is, the
DELETE request actually yields a successful deletion of the OSCORE
group, only if the corresponding status parameter 'active' has
current value "false" (0xf4). The Administrator can ensure that, by
first performing an update of the group-configuration resource
associated with the OSCORE group (see Section 6.6), and setting the
corresponding status parameter 'active' to "false" (0xf4).
If, upon receiving the DELETE request, the current value of the If, upon receiving the DELETE request, the current value of the
status parameter 'active' is True, the Group Manager MUST respond status parameter 'active' is "true" (0xf5), the Group Manager MUST
with a 4.09 (Conflict) response. The response MUST have Content- respond with a 4.09 (Conflict) response. The response MUST have
Format set to application/ace-groupcomm+cbor and is formatted as Content-Format set to application/ace-groupcomm+cbor and is formatted
defined in Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The value as defined in Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The
of the 'error' field MUST be set to 8 ("Group currently active"). value of the 'error' field MUST be set to 8 ("Group currently
active").
After a successful processing of the request above, the Group Manager After a successful processing of the DELETE request, the Group
performs the following actions. Manager performs the following actions.
First, the Group Manager deletes the OSCORE group and deallocates First, the Group Manager deletes the OSCORE group and deallocates
both the group-configuration resource as well as the group-membership both the group-configuration resource as well as the group-membership
resource associated to that group. resource associated with that group.
Then, the Group Manager replies to the Administrator with a 2.02 Then, the Group Manager replies to the Administrator with a 2.02
(Deleted) response. (Deleted) response.
Example: Example:
=> 0.04 DELETE => 0.04 DELETE
Uri-Path: manage Uri-Path: manage
Uri-Path: gp4 Uri-Path: gp4
<= 2.02 Deleted <= 2.02 Deleted
4.8.1. Effects on the Group Members 6.8.1. Effects on the Group Members
After having deleted an OSCORE group, the Group Manager can inform After having deleted an OSCORE group, the Group Manager can inform
the group members by means of the following two methods. When the group members by means of the following two methods. When
contacting a group member, the Group Manager uses the pairwise secure contacting a group member, the Group Manager uses the pairwise secure
communication association established with that member during its communication association established with that member during its
joining process (see Section 6 of joining process (see Section 6 of
[I-D.ietf-ace-key-groupcomm-oscore]). [I-D.ietf-ace-key-groupcomm-oscore]).
* The Group Manager sends an individual request message to each * The Group Manager sends an individual request message to each
group member, targeting the respective resource used to perform group member, targeting the respective resource used to perform
the group rekeying process (see Section 20.1 of the group rekeying process (see Section 20.1 of
[I-D.ietf-ace-key-groupcomm-oscore]). The Group Manager uses the [I-D.ietf-ace-key-groupcomm-oscore]). The Group Manager uses the
same format of the Joining Response message in Section 6.4 of same format of the Joining Response message in Section 6.4 of
[I-D.ietf-ace-key-groupcomm-oscore], where only the parameters [I-D.ietf-ace-key-groupcomm-oscore], where only the parameters
'gkty', 'key' and 'ace-groupcomm-profile' are present, and the 'gkty', 'key' and 'ace-groupcomm-profile' are present, and the
'key' parameter is the empty CBOR map. 'key' parameter is the empty CBOR map.
* A group member may subscribe for updates to the group-membership * A group member may subscribe for updates to the group-membership
resource associated to the OSCORE group. In particular, if this resource associated with the OSCORE group. In particular, if this
relies on CoAP Observe [RFC7641], a group member would receive a relies on CoAP Observe [RFC7641], a group member would receive a
4.04 (Not Found) notification response from the Group Manager, 4.04 (Not Found) notification response from the Group Manager,
since the group-configuration resource has been deallocated upon since the group-configuration resource has been deallocated upon
deleting the OSCORE group (see Section 6.1 of deleting the OSCORE group (see Section 6.1 of
[I-D.ietf-ace-key-groupcomm]). The response MUST have Content- [I-D.ietf-ace-key-groupcomm]). The response MUST have Content-
Format set to application/ace-groupcomm+cbor and is formatted as Format set to application/ace-groupcomm+cbor and is formatted as
defined in Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The defined in Section 4.1.2 of [I-D.ietf-ace-key-groupcomm]. The
value of the 'error' field MUST be set to 5 ("Group deleted"). value of the 'error' field MUST be set to 5 ("Group deleted").
When being informed about the deletion of the OSCORE group, a group When being informed about the deletion of the OSCORE group, a group
member deletes the OSCORE Security Context that it stores as member deletes the OSCORE Security Context that it stores as
associated to that group, and possibly deallocates any dedicated associated with that group, and possibly deallocates any dedicated
control resource intended for the Group Manager that it has for that control resource intended for the Group Manager that it has for that
group. group.
5. ACE Groupcomm Error Identifiers 7. ACE Groupcomm Error Identifiers
In addition to what is defined in Section 9 of In addition to what is defined in Section 9 of
[I-D.ietf-ace-key-groupcomm], this document defines a new value that [I-D.ietf-ace-key-groupcomm], this document defines a new value that
the Group Manager can include as error identifiers, in the 'error' the Group Manager can include as error identifiers, in the 'error'
field of an error response with Content-Format application/ace- field of an error response with Content-Format application/ace-
groupcomm+cbor. groupcomm+cbor.
+-------+------------------------+ +-------+------------------------+
| Value | Description | | Value | Description |
+-------+------------------------+ +-------+------------------------+
| 10 | Group currently active | | 10 | Group currently active |
+-------+------------------------+ +-------+------------------------+
Figure 3: ACE Groupcomm Error Identifiers Figure 4: ACE Groupcomm Error Identifiers
A Client supporting the 'error' parameter (see Sections 4.1.2 and 8 A Client supporting the 'error' parameter (see Sections 4.1.2 and 8
of [I-D.ietf-ace-key-groupcomm]) and able to understand the specified of [I-D.ietf-ace-key-groupcomm]) and able to understand the specified
error may use that information to determine what actions to take error may use that information to determine what actions to take
next. If it is included in the error response and supported by the next. If it is included in the error response and supported by the
Client, the 'error_description' parameter may provide additional Client, the 'error_description' parameter may provide additional
context. In particular, the following guidelines apply. context. In particular, the following guidelines apply.
* In case of error 10, the Client should stop sending the request in * In case of error 10, the Client should stop sending the request in
question to the Group Manager, until the group becomes inactive. question to the Group Manager, until the group becomes inactive.
As per this document, this error is relevant only for the As per this document, this error is relevant only for the
Administrator, if it tries to delete a group without having set Administrator, if it tries to delete a group without having set
its status to inactive first (see Section 4.8). In such a case, its status to inactive first (see Section 6.8). In such a case,
the Administrator should take the expected course of actions, and the Administrator should take the expected course of actions, and
set the group status to inactive first (see Section 4.6 and set the group status to inactive first (see Section 6.6 and
Section 4.7), before proceeding with the group deletion. Section 6.7), before proceeding with the group deletion.
6. Security Considerations 8. Security Considerations
Security considerations are inherited from the ACE framework for Security considerations are inherited from the ACE framework for
Authentication and Authorization [I-D.ietf-ace-oauth-authz], and from Authentication and Authorization [I-D.ietf-ace-oauth-authz], and from
the specific transport profile of ACE used between the Administrator the specific transport profile of ACE used between the Administrator
and the Group Manager, such as [I-D.ietf-ace-dtls-authorize] and and the Group Manager, such as [I-D.ietf-ace-dtls-authorize] and
[I-D.ietf-ace-oscore-profile]. [I-D.ietf-ace-oscore-profile].
7. IANA Considerations 9. IANA Considerations
RFC Editor: Please replace "[[this document]]" with the RFC number of RFC Editor: Please replace "[[this document]]" with the RFC number of
this document and delete this paragraph. this document and delete this paragraph.
This document has the following actions for IANA. This document has the following actions for IANA.
7.1. ACE Groupcomm Parameters 9.1. ACE Groupcomm Parameters
IANA is asked to register the following entries in the "ACE Groupcomm IANA is asked to register the following entries in the "ACE Groupcomm
Parameters" registry defined in Section 11.7 of Parameters" registry defined in Section 11.7 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
+-----------------+----------+--------------+-------------------+ +-----------------+----------+--------------+-------------------+
| Name | CBOR Key | CBOR Type | Reference | | Name | CBOR Key | CBOR Type | Reference |
+-----------------+----------+--------------+-------------------+ +-----------------+----------+--------------+-------------------+
| hkdf | TBD | tstr / int | [[this document]] | | hkdf | TBD | tstr / int | [[this document]] |
+-----------------+----------+--------------+-------------------+ +-----------------+----------+--------------+-------------------+
| pub_key_enc | TBD | int | [[this document]] | | cred_fmt | TBD | int | [[this document]] |
+-----------------+----------+--------------+-------------------+ +-----------------+----------+--------------+-------------------+
| group_mode | TBD | simple value | [[this document]] | | group_mode | TBD | simple value | [[this document]] |
+-----------------+----------+--------------+-------------------+ +-----------------+----------+--------------+-------------------+
| sign_enc_alg | TBD | tstr / int / | [[this document]] | | sign_enc_alg | TBD | tstr / int / | [[this document]] |
| | | simple value | | | | | simple value | |
+-----------------+----------+--------------+-------------------+ +-----------------+----------+--------------+-------------------+
| sign_alg | TBD | tstr / int / | [[this document]] | | sign_alg | TBD | tstr / int / | [[this document]] |
| | | simple value | | | | | simple value | |
+-----------------+----------+--------------+-------------------+ +-----------------+----------+--------------+-------------------+
| sign_params | TBD | array / | [[this document]] | | sign_params | TBD | array / | [[this document]] |
skipping to change at page 41, line 48 skipping to change at page 51, line 15
+-----------------+----------+--------------+-------------------+ +-----------------+----------+--------------+-------------------+
| max_stale_sets | TBD | uint | [[this document]] | | max_stale_sets | TBD | uint | [[this document]] |
+-----------------+----------+--------------+-------------------+ +-----------------+----------+--------------+-------------------+
| as_uri | TBD | tstr | [[this document]] | | as_uri | TBD | tstr | [[this document]] |
+-----------------+----------+--------------+-------------------+ +-----------------+----------+--------------+-------------------+
| conf_filter | TBD | array | [[this document]] | | conf_filter | TBD | array | [[this document]] |
+-----------------+----------+--------------+-------------------+ +-----------------+----------+--------------+-------------------+
| app_groups_diff | TBD | array | [[this document]] | | app_groups_diff | TBD | array | [[this document]] |
+-----------------+----------+--------------+-------------------+ +-----------------+----------+--------------+-------------------+
Figure 4: ACE Groupcomm Parameters Figure 5: ACE Groupcomm Parameters
7.2. ACE Groupcomm Errors 9.2. ACE Groupcomm Errors
IANA is asked to register the following entry in the "ACE Groupcomm IANA is asked to register the following entry in the "ACE Groupcomm
Errors" registry defined in Section 11.13 of Errors" registry defined in Section 11.13 of
[I-D.ietf-ace-key-groupcomm]. [I-D.ietf-ace-key-groupcomm].
* Value: 10 * Value: 10
* Description: Group currently active. * Description: Group currently active.
* Reference: [[This document]] * Reference: [[This document]]
7.3. Resource Types 9.3. Resource Types
IANA is asked to enter the following values in the "Resource Type IANA is asked to enter the following values in the "Resource Type
(rt=) Link Target Attribute Values" registry within the "Constrained (rt=) Link Target Attribute Values" registry within the "Constrained
Restful Environments (CoRE) Parameters" registry group. Restful Environments (CoRE) Parameters" registry group.
+----------------+------------------------------+-------------------+ +----------------+------------------------------+-------------------+
| Value | Description | Reference | | Value | Description | Reference |
+----------------+------------------------------+-------------------+ +----------------+------------------------------+-------------------+
| core.osc.gcoll | Group-collection resource | [[this document]] | | core.osc.gcoll | Group-collection resource | [[this document]] |
| | of an OSCORE Group Manager | | | | of an OSCORE Group Manager | |
| | | | | | | |
| core.osc.gconf | Group-configuration resource | [[this document]] | | core.osc.gconf | Group-configuration resource | [[this document]] |
| | of an OSCORE Group Manager | | | | of an OSCORE Group Manager | |
+----------------+------------------------------+-------------------+ +----------------+------------------------------+-------------------+
8. References 9.4. Group OSCORE Admin Permissions
8.1. Normative References This document establishes the IANA "Group OSCORE Admin Permissions"
registry. The registry has been created to use the "Expert Review"
registration procedure [RFC8126]. Expert review guidelines are
provided in Section 9.8.
This registry includes the possible permissions that Administrators
can have to perform operations on an OSCORE Group Manager, each in
combination with a numeric identifier. These numeric identifiers are
used to express authorization information about performing
administrative operations concerning OSCORE groups under the control
of the Group Manager, as specified in Section 3 of [[this document]].
The columns of this registry are:
* Name: A value that can be used in documents for easier
comprehension, to identify a possible permission that
Administrators can perform when interacting with an OSCORE Group
Manager.
* Value: The numeric identifier for this permission. Integer values
greater than 65535 are marked as "Private Use", all other values
use the registration policy "Expert Review" [RFC8126].
Note that, in general, a single permission can be associated with
multiple different operations that are possible to be performed
when interacting with the Group Manager.
* Description: This field contains a brief description of the
permission.
* Reference: This contains a pointer to the public specification for
the permission.
This registry will be initially populated by the values in Figure 2.
The Reference column for all of these entries will be [[this
document]].
9.5. AIF
For the media-types application/aif+cbor and application/aif+json
defined in Section 5.1 of [I-D.ietf-ace-aif], IANA is requested to
register the following entries for the two media-type parameters Toid
and Tperm, in the respective sub-registry defined in Section 5.2 of
[I-D.ietf-ace-aif] within the "MIME Media Type Sub-Parameter"
registry group.
* Name: oscore-group-name-pattern
* Description/Specification: wildcard pattern of OSCORE group names
* Reference: [[This document]]
* Name: oscore-group-admin-permissions
* Description/Specification: permission(s) to perform administrative
operations at the OSCORE Group Manager
* Reference: [[This document]]
9.6. CoAP Content-Format
IANA is asked to register the following entries to the "CoAP Content-
Formats" registry within the "Constrained RESTful Environments (CoRE)
Parameters" registry group.
* Media Type: application/aif+cbor;Toid="oscore-group-name-
pattern",Tperm="oscore-group-admin-permissions"
* Encoding: -
* ID: TBD
* Reference: [[This document]]
* Media Type: application/aif+json;Toid="oscore-group-name-
pattern",Tperm="oscore-group-admin-permissions"
* Encoding: -
* ID: TBD
* Reference: [[This document]]
9.7. ACE Scope Semantics
IANA is asked to register the following entry in the "ACE Scope
Semantics" registry defined in Section 11.12 of
[I-D.ietf-ace-key-groupcomm].
* Value: SEM_ID_TBD
* Description: Permissions to perform administrative operations at
the ACE Group Manager for Group OSCORE.
* Reference: [[This document]]
9.8. Expert Review Instructions
The IANA registry established in this document is 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:
* Clarity and correctness of registrations. Experts are expected to
check the clarity of purpose and use of the requested entries.
Experts should inspect the entry for the considered permission, to
verify the correctness of its description against the permission
as intended in the specification that defined it. Expert should
consider requesting an opinion on the correctness of registered
parameters from the Authentication and Authorization for
Constrained Environments (ACE) Working Group and the Constrained
RESTful Environments (CoRE) Working Group.
Entries that do not meet these objective of clarity and
completeness should not be registered.
* Duplicated registration and 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.
* Experts should take into account the expected usage of permissions
when approving point assignment. Given a 'Value' V as code point,
the length of the encoding of (2^(V+1) - 1) should be weighed
against the usage of the entry, considering the resources and
capabilities of devices it will be used on. Additionally, given a
'Value' V as code point, the length of the encoding of (2^(V+1) -
1) should be weighed against how many code points resulting in
that encoding length are left, and the resources and capabilities
of devices it will be used on.
* Specifications are recommended. When specifications are not
provided, the description provided needs to have sufficient
information to verify the points above.
10. References
10.1. Normative References
[COSE.Algorithms] [COSE.Algorithms]
IANA, "COSE Algorithms", IANA, "COSE Algorithms",
<https://www.iana.org/assignments/cose/ <https://www.iana.org/assignments/cose/
cose.xhtml#algorithms>. cose.xhtml#algorithms>.
[I-D.ietf-ace-aif]
Bormann, C., "An Authorization Information Format (AIF)
for ACE", Work in Progress, Internet-Draft, draft-ietf-
ace-aif-06, 4 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-ace-aif-
06.txt>.
[I-D.ietf-ace-key-groupcomm] [I-D.ietf-ace-key-groupcomm]
Palombini, F. and M. Tiloca, "Key Provisioning for Group Palombini, F. and M. Tiloca, "Key Provisioning for Group
Communication using ACE", Work in Progress, Internet- Communication using ACE", Work in Progress, Internet-
Draft, draft-ietf-ace-key-groupcomm-14, 25 October 2021, Draft, draft-ietf-ace-key-groupcomm-15, 23 December 2021,
<https://www.ietf.org/archive/id/draft-ietf-ace-key- <https://www.ietf.org/archive/id/draft-ietf-ace-key-
groupcomm-14.txt>. groupcomm-15.txt>.
[I-D.ietf-ace-key-groupcomm-oscore] [I-D.ietf-ace-key-groupcomm-oscore]
Tiloca, M., Park, J., and F. Palombini, "Key Management Tiloca, M., Park, J., and F. Palombini, "Key Management
for OSCORE Groups in ACE", Work in Progress, Internet- for OSCORE Groups in ACE", Work in Progress, Internet-
Draft, draft-ietf-ace-key-groupcomm-oscore-12, 25 October Draft, draft-ietf-ace-key-groupcomm-oscore-13, 7 March
2021, <https://www.ietf.org/archive/id/draft-ietf-ace-key- 2022, <https://www.ietf.org/archive/id/draft-ietf-ace-key-
groupcomm-oscore-12.txt>. groupcomm-oscore-13.txt>.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", Work in Progress, Internet-Draft, Framework (ACE-OAuth)", Work in Progress, Internet-Draft,
draft-ietf-ace-oauth-authz-45, 29 August 2021, draft-ietf-ace-oauth-authz-46, 8 November 2021,
<https://www.ietf.org/archive/id/draft-ietf-ace-oauth- <https://www.ietf.org/archive/id/draft-ietf-ace-oauth-
authz-45.txt>. authz-46.txt>.
[I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE Profile of the Authentication and Authorization "OSCORE Profile of the Authentication and Authorization
for Constrained Environments Framework", Work in Progress, for Constrained Environments Framework", Work in Progress,
Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May
2021, <https://www.ietf.org/archive/id/draft-ietf-ace- 2021, <https://www.ietf.org/archive/id/draft-ietf-ace-
oscore-profile-19.txt>. oscore-profile-19.txt>.
[I-D.ietf-core-coral] [I-D.ietf-core-coral]
Hartke, K., "The Constrained RESTful Application Language Amsüss, C. and T. Fossati, "The Constrained RESTful
(CoRAL)", Work in Progress, Internet-Draft, draft-ietf- Application Language (CoRAL)", Work in Progress, Internet-
core-coral-03, 9 March 2020, Draft, draft-ietf-core-coral-04, 25 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-core-coral- <https://www.ietf.org/archive/id/draft-ietf-core-coral-
03.txt>. 04.txt>.
[I-D.ietf-core-groupcomm-bis] [I-D.ietf-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", Work in for the Constrained Application Protocol (CoAP)", Work in
Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
05, 25 October 2021, <https://www.ietf.org/archive/id/ 06, 7 March 2022, <https://www.ietf.org/archive/id/draft-
draft-ietf-core-groupcomm-bis-05.txt>. ietf-core-groupcomm-bis-06.txt>.
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
and J. Park, "Group OSCORE - Secure Group Communication and J. Park, "Group OSCORE - Secure Group Communication
for CoAP", Work in Progress, Internet-Draft, draft-ietf- for CoAP", Work in Progress, Internet-Draft, draft-ietf-
core-oscore-groupcomm-13, 25 October 2021, core-oscore-groupcomm-14, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-core-oscore- <https://www.ietf.org/archive/id/draft-ietf-core-oscore-
groupcomm-13.txt>. groupcomm-14.txt>.
[I-D.ietf-cose-rfc8152bis-algs] [I-D.ietf-cose-rfc8152bis-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", Work in Progress, Internet-Draft, Initial Algorithms", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020,
<https://www.ietf.org/archive/id/draft-ietf-cose- <https://www.ietf.org/archive/id/draft-ietf-cose-
rfc8152bis-algs-12.txt>. rfc8152bis-algs-12.txt>.
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
skipping to change at page 44, line 42 skipping to change at page 57, line 15
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
[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>.
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
FETCH Methods for the Constrained Application Protocol FETCH Methods for the Constrained Application Protocol
(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
<https://www.rfc-editor.org/info/rfc8132>. <https://www.rfc-editor.org/info/rfc8132>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
8.2. Informative References 10.2. Informative References
[I-D.amsuess-core-cachable-oscore] [I-D.amsuess-core-cachable-oscore]
Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in
Progress, Internet-Draft, draft-amsuess-core-cachable- Progress, Internet-Draft, draft-amsuess-core-cachable-
oscore-02, 12 July 2021, <https://www.ietf.org/archive/id/ oscore-04, 6 March 2022, <https://www.ietf.org/archive/id/
draft-amsuess-core-cachable-oscore-02.txt>. draft-amsuess-core-cachable-oscore-04.txt>.
[I-D.hartke-t2trg-coral-reef] [I-D.hartke-t2trg-coral-reef]
Hartke, K., "Resource Discovery in Constrained RESTful Hartke, K., "Resource Discovery in Constrained RESTful
Environments (CoRE) using the Constrained RESTful Environments (CoRE) using the Constrained RESTful
Application Language (CoRAL)", Work in Progress, Internet- Application Language (CoRAL)", Work in Progress, Internet-
Draft, draft-hartke-t2trg-coral-reef-04, 9 May 2020, Draft, draft-hartke-t2trg-coral-reef-04, 9 May 2020,
<https://www.ietf.org/archive/id/draft-hartke-t2trg-coral- <https://www.ietf.org/archive/id/draft-hartke-t2trg-coral-
reef-04.txt>. reef-04.txt>.
[I-D.ietf-ace-dtls-authorize] [I-D.ietf-ace-dtls-authorize]
skipping to change at page 46, line 5 skipping to change at page 58, line 35
2021, <https://www.ietf.org/archive/id/draft-ietf-ace- 2021, <https://www.ietf.org/archive/id/draft-ietf-ace-
dtls-authorize-18.txt>. dtls-authorize-18.txt>.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V.
D. Stok, "CoRE Resource Directory", Work in Progress, D. Stok, "CoRE Resource Directory", Work in Progress,
Internet-Draft, draft-ietf-core-resource-directory-28, 7 Internet-Draft, draft-ietf-core-resource-directory-28, 7
March 2021, <https://www.ietf.org/archive/id/draft-ietf- March 2021, <https://www.ietf.org/archive/id/draft-ietf-
core-resource-directory-28.txt>. core-resource-directory-28.txt>.
[I-D.ietf-cose-cbor-encoded-cert]
Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
M. Furuhed, "CBOR Encoded X.509 Certificates (C509
Certificates)", Work in Progress, Internet-Draft, draft-
ietf-cose-cbor-encoded-cert-03, 10 January 2022,
<https://www.ietf.org/archive/id/draft-ietf-cose-cbor-
encoded-cert-03.txt>.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-43, 30 April 2021, <https://www.ietf.org/internet- dtls13-43, 30 April 2021, <https://www.ietf.org/internet-
drafts/draft-ietf-tls-dtls13-43.txt>. drafts/draft-ietf-tls-dtls13-43.txt>.
[I-D.tiloca-core-oscore-discovery] [I-D.tiloca-core-oscore-discovery]
Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of
OSCORE Groups with the CoRE Resource Directory", Work in OSCORE Groups with the CoRE Resource Directory", Work in
Progress, Internet-Draft, draft-tiloca-core-oscore- Progress, Internet-Draft, draft-tiloca-core-oscore-
discovery-10, 25 October 2021, discovery-11, 7 March 2022,
<https://www.ietf.org/archive/id/draft-tiloca-core-oscore- <https://www.ietf.org/archive/id/draft-tiloca-core-oscore-
discovery-10.txt>. discovery-11.txt>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016,
<https://www.rfc-editor.org/info/rfc7925>.
[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>.
Appendix A. Document Updates Appendix A. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION. RFC EDITOR: PLEASE REMOVE THIS SECTION.
A.1. Version -03 to -04 A.1. Version -04 to -05
* Defined format of scope based on a new AIF data model.
* Specified authorization checks at the Group Manager.
* Revised resource handlers based on the new scope format.
* Renamed 'pub_key_enc' to 'cred_fmt'.
* Mandatory to include 'group_name' in the group creation request.
* Suggesting a used 'group_name' results in a new name, not in an
error.
* Distinction between authentication credentials and public keys.
* More details on informing group members about changes in the group
configuration.
* Revised order of sections; editorial improvements.
A.2. Version -03 to -04
* Clarifications on what to do in case of enhanced error responses. * Clarifications on what to do in case of enhanced error responses.
* Clarifications on handling default values for group parameters. * Clarifications on handling default values for group parameters.
* New configuration parameters to support OSCORE deterministic * New configuration parameters to support OSCORE deterministic
requests. requests.
* IANA considerations - Use RFC8126 terminology. * IANA considerations - Use RFC8126 terminology.
* Author's change of address. * Author's change of address.
* Editorial improvements. * Editorial improvements.
A.2. Version -02 to -03 A.3. Version -02 to -03
* Aligned new and old parameters to core-groupcomm-oscore and ace- * Aligned new and old parameters to core-groupcomm-oscore and ace-
key-groupcomm-oscore. key-groupcomm-oscore.
* Removed 'cs_key_params' and 'ecdh_key_params' to avoid redundant * Removed 'cs_key_params' and 'ecdh_key_params' to avoid redundant
COSE capabilities of key types, consistently with draft-ietf-ace- COSE capabilities of key types, consistently with draft-ietf-ace-
key-groupcomm-oscore. key-groupcomm-oscore.
* Revised examples and side effects due to parameter changes. * Revised examples and side effects due to parameter changes.
* New error type "Group currently active". * New error type "Group currently active".
A.3. Version -01 to -02 A.4. Version -01 to -02
* Admit multiple Administrators and limited access to admin * Admit multiple Administrators and limited access to admin
resources. resources.
* Early design considerations for defining the format of scope. * Early design considerations for defining the format of scope.
* Additional error handling, using also error types. * Additional error handling, using also error types.
* Selective update of group-configuration resources with PATCH/ * Selective update of group-configuration resources with PATCH/
iPATCH. iPATCH.
* Editorial improvements. * Editorial improvements.
A.4. Version -00 to -01 A.5. Version -00 to -01
* Names of application groups as status parameter. * Names of application groups as status parameter.
* Parameters related to the pairwise mode of Group OSCORE. * Parameters related to the pairwise mode of Group OSCORE.
* Defined FETCH for group-configuration resources. * Defined FETCH for group-configuration resources.
* Policies on registration of links to the Resource Directory. * Policies on registration of links to the Resource Directory.
* Added resource type for group-configuration resources. * Added resource type for group-configuration resources.
 End of changes. 209 change blocks. 
512 lines changed or deleted 1140 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/