rfc9594.original   rfc9594.txt 
ACE Working Group F. Palombini Internet Engineering Task Force (IETF) F. Palombini
Internet-Draft Ericsson AB Request for Comments: 9594 Ericsson AB
Intended status: Standards Track M. Tiloca Category: Standards Track M. Tiloca
Expires: 19 July 2024 RISE AB ISSN: 2070-1721 RISE AB
16 January 2024 September 2024
Key Provisioning for Group Communication using ACE Key Provisioning for Group Communication Using Authentication and
draft-ietf-ace-key-groupcomm-18 Authorization for Constrained Environments (ACE)
Abstract Abstract
This document defines how to use the Authentication and Authorization This document defines how to use the Authentication and Authorization
for Constrained Environments (ACE) framework to distribute keying for Constrained Environments (ACE) framework to distribute keying
material and configuration parameters for secure group communication. material and configuration parameters for secure group communication.
Candidate group members acting as Clients and authorized to join a Candidate group members that act as Clients and are authorized to
group can do so by interacting with a Key Distribution Center (KDC) join a group can do so by interacting with a Key Distribution Center
acting as Resource Server, from which they obtain the keying material (KDC) acting as the Resource Server, from which they obtain the
to communicate with other group members. While defining general keying material to communicate with other group members. While
message formats as well as the interface and operations available at defining general message formats as well as the interface and
the KDC, this document supports different approaches and protocols operations available at the KDC, this document supports different
for secure group communication. Therefore, details are delegated to approaches and protocols for secure group communication. Therefore,
separate application profiles of this document, as specialized details are delegated to separate application profiles of this
instances that target a particular group communication approach and document as specialized instances that target a particular group
define how communications in the group are protected. Compliance communication approach and define how communications in the group are
requirements for such application profiles are also specified. protected. Compliance requirements for such application profiles are
also specified.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/ace-wg/ace-key-groupcomm.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9594.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 July 2024.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 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
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Overview
3. Authorization to Join a Group . . . . . . . . . . . . . . . . 12 3. Authorization to Join a Group
3.1. Authorization Request . . . . . . . . . . . . . . . . . . 12 3.1. Authorization Request
3.2. Authorization Response . . . . . . . . . . . . . . . . . 15 3.2. Authorization Response
3.3. Token Transferring . . . . . . . . . . . . . . . . . . . 16 3.3. Token Transferring
3.3.1. 'sign_info' Parameter . . . . . . . . . . . . . . . . 18 3.3.1. 'sign_info' Parameter
3.3.2. 'kdcchallenge' Parameter . . . . . . . . . . . . . . 21 3.3.2. 'kdcchallenge' Parameter
4. KDC Functionalities . . . . . . . . . . . . . . . . . . . . . 21 4. KDC Functionalities
4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 21 4.1. Interface at the KDC
4.1.1. Operations Supported by Clients . . . . . . . . . . . 26 4.1.1. Operations Supported by Clients
4.1.2. Error Handling . . . . . . . . . . . . . . . . . . . 27 4.1.2. Error Handling
4.2. /ace-group . . . . . . . . . . . . . . . . . . . . . . . 29 4.2. /ace-group
4.2.1. FETCH Handler . . . . . . . . . . . . . . . . . . . . 29 4.2.1. FETCH Handler
4.2.1.1. Retrieve Group Names . . . . . . . . . . . . . . 30 4.2.1.1. Retrieve Group Names
4.3. /ace-group/GROUPNAME . . . . . . . . . . . . . . . . . . 31 4.3. /ace-group/GROUPNAME
4.3.1. POST Handler . . . . . . . . . . . . . . . . . . . . 31 4.3.1. POST Handler
4.3.1.1. Join the Group . . . . . . . . . . . . . . . . . 47 4.3.1.1. Join the Group
4.3.2. GET Handler . . . . . . . . . . . . . . . . . . . . . 49 4.3.2. GET Handler
4.3.2.1. Retrieve Group Keying Material . . . . . . . . . 50 4.3.2.1. Retrieve Group Keying Material
4.4. /ace-group/GROUPNAME/creds . . . . . . . . . . . . . . . 51 4.4. /ace-group/GROUPNAME/creds
4.4.1. FETCH Handler . . . . . . . . . . . . . . . . . . . . 51 4.4.1. FETCH Handler
4.4.1.1. Retrieve a Subset of Authentication Credentials in 4.4.1.1. Retrieve a Subset of Authentication Credentials in
the Group . . . . . . . . . . . . . . . . . . . . . 54 the Group
4.4.2. GET Handler . . . . . . . . . . . . . . . . . . . . . 55 4.4.2. GET Handler
4.4.2.1. Retrieve All Authentication Credentials in the 4.4.2.1. Retrieve All Authentication Credentials in the
Group . . . . . . . . . . . . . . . . . . . . . . . 55 Group
4.5. /ace-group/GROUPNAME/kdc-cred . . . . . . . . . . . . . . 56 4.5. /ace-group/GROUPNAME/kdc-cred
4.5.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 56 4.5.1. GET Handler
4.5.1.1. Retrieve the KDC's Authentication Credential . . 58 4.5.1.1. Retrieve the KDC's Authentication Credential
4.6. /ace-group/GROUPNAME/policies . . . . . . . . . . . . . . 59 4.6. /ace-group/GROUPNAME/policies
4.6.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 59 4.6.1. GET Handler
4.6.1.1. Retrieve the Group Policies . . . . . . . . . . . 60 4.6.1.1. Retrieve the Group Policies
4.7. /ace-group/GROUPNAME/num . . . . . . . . . . . . . . . . 60 4.7. /ace-group/GROUPNAME/num
4.7.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 60 4.7.1. GET Handler
4.7.1.1. Retrieve the Keying Material Version . . . . . . 61 4.7.1.1. Retrieve the Keying Material Version
4.8. /ace-group/GROUPNAME/nodes/NODENAME . . . . . . . . . . . 62 4.8. /ace-group/GROUPNAME/nodes/NODENAME
4.8.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 62 4.8.1. GET Handler
4.8.1.1. Retrieve Group and Individual Keying Material . . 63 4.8.1.1. Retrieve Group and Individual Keying Material
4.8.2. PUT Handler . . . . . . . . . . . . . . . . . . . . . 65 4.8.2. POST Handler
4.8.2.1. Request to Change Individual Keying Material . . 67 4.8.2.1. Request to Change Individual Keying Material
4.8.3. DELETE Handler . . . . . . . . . . . . . . . . . . . 68 4.8.3. DELETE Handler
4.8.3.1. Leave the Group . . . . . . . . . . . . . . . . . 69 4.8.3.1. Leave the Group
4.9. /ace-group/GROUPNAME/nodes/NODENAME/cred . . . . . . . . 69 4.9. /ace-group/GROUPNAME/nodes/NODENAME/cred
4.9.1. POST Handler . . . . . . . . . . . . . . . . . . . . 69 4.9.1. POST Handler
4.9.1.1. Uploading an Authentication Credential . . . . . 72 4.9.1.1. Uploading an Authentication Credential
5. Removal of a Group Member . . . . . . . . . . . . . . . . . . 73 5. Removal of a Group Member
6. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 74 6. Group Rekeying Process
6.1. Point-to-Point Group Rekeying . . . . . . . . . . . . . . 76 6.1. Point-to-Point Group Rekeying
6.2. One-to-Many Group Rekeying . . . . . . . . . . . . . . . 78 6.2. One-to-Many Group Rekeying
6.2.1. Protection of Rekeying Messages . . . . . . . . . . . 82 6.2.1. Protection of Rekeying Messages
6.3. Misalignment of Group Keying Material . . . . . . . . . . 85 6.3. Misalignment of Group Keying Material
7. Extended Scope Format . . . . . . . . . . . . . . . . . . . . 85 7. Extended Scope Format
8. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 87 8. ACE Groupcomm Parameters
9. ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . . 91 9. ACE Groupcomm Error Identifiers
10. Security Considerations . . . . . . . . . . . . . . . . . . . 93 10. Security Considerations
10.1. Secure Communication in the Group . . . . . . . . . . . 93 10.1. Secure Communication in the Group
10.2. Update of Group Keying Material . . . . . . . . . . . . 94 10.2. Update of Group Keying Material
10.3. Block-Wise Considerations . . . . . . . . . . . . . . . 96 10.3. Block-Wise Considerations
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96 11. IANA Considerations
11.1. Media Type Registrations . . . . . . . . . . . . . . . . 97 11.1. Media Type Registrations
11.2. CoAP Content-Formats . . . . . . . . . . . . . . . . . . 97 11.2. CoAP Content-Formats
11.3. OAuth Parameters . . . . . . . . . . . . . . . . . . . . 98 11.3. OAuth Parameters
11.4. OAuth Parameters CBOR Mappings . . . . . . . . . . . . . 98 11.4. OAuth Parameters CBOR Mappings
11.5. Interface Description (if=) Link Target Attribute 11.5. Interface Description (if=) Link Target Attribute Values
Values . . . . . . . . . . . . . . . . . . . . . . . . 99 11.6. Custom Problem Detail Keys Registry
11.6. Custom Problem Detail Keys Registry . . . . . . . . . . 99 11.7. ACE Groupcomm Parameters
11.7. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . 100 11.8. ACE Groupcomm Key Types
11.8. ACE Groupcomm Key Types . . . . . . . . . . . . . . . . 100 11.9. ACE Groupcomm Profiles
11.9. ACE Groupcomm Profiles . . . . . . . . . . . . . . . . . 101 11.10. ACE Groupcomm Policies
11.10. ACE Groupcomm Policies . . . . . . . . . . . . . . . . . 102 11.11. Sequence Number Synchronization Methods
11.11. Sequence Number Synchronization Methods . . . . . . . . 103 11.12. ACE Groupcomm Errors
11.12. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 104 11.13. ACE Groupcomm Rekeying Schemes
11.13. ACE Groupcomm Rekeying Schemes . . . . . . . . . . . . . 105 11.14. Expert Review Instructions
11.14. Expert Review Instructions . . . . . . . . . . . . . . . 106 12. References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 106 12.1. Normative References
12.1. Normative References . . . . . . . . . . . . . . . . . . 106 12.2. Informative References
12.2. Informative References . . . . . . . . . . . . . . . . . 109 Appendix A. Requirements for Application Profiles
Appendix A. Requirements for Application Profiles . . . . . . . 111 A.1. Mandatory-to-Address Requirements
A.1. Mandatory-to-Address Requirements . . . . . . . . . . . . 111 A.2. Optional-to-Address Requirements
A.2. Optional-to-Address Requirements . . . . . . . . . . . . 114 Appendix B. Extensibility for Future COSE Algorithms
Appendix B. Extensibility for Future COSE Algorithms . . . . . . 115 B.1. Format of 'sign_info_entry'
B.1. Format of 'sign_info_entry' . . . . . . . . . . . . . . . 115 Acknowledgments
Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 116 Authors' Addresses
C.1. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 116
C.2. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 118
C.3. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 119
C.4. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 119
C.5. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 119
C.6. Version -05 to -13 . . . . . . . . . . . . . . . . . . . 120
C.7. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 120
C.8. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 121
C.9. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 121
C.10. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 122
C.11. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 122
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 123
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 124
1. Introduction 1. Introduction
This document builds on the Authentication and Authorization for This document builds on the Authentication and Authorization for
Constrained Environments (ACE) framework and defines how to request, Constrained Environments (ACE) framework and defines how to request,
distribute, and renew keying material and configuration parameters to distribute, and renew keying material and configuration parameters to
protect message exchanges in a group communication environment. protect message exchanges in a group communication environment.
Candidate group members acting as ACE Clients and authorized to join Candidate group members that act as ACE Clients and are authorized to
a group can interact with the Key Distribution Center (KDC) acting as join a group can interact with the Key Distribution Center (KDC)
ACE Resource Server and responsible for that group, in order to acting as the ACE Resource Server that is responsible for that group
obtain the necessary keying material and parameters to communicate in order to obtain the necessary keying material and parameters to
with other group members. communicate with other group members.
In particular, this document defines the operations and interface In particular, this document defines the operations and interface
available at the KDC, as well as general message formats for the available at the KDC, as well as general message formats for the
interactions between Clients and KDC. At the same time, interactions between Clients and the KDC. At the same time,
communications in the group can rely on different approaches, e.g., communications in the group can rely on different approaches, e.g.,
based on multicast [I-D.ietf-core-groupcomm-bis] or on publish- based on multicast [GROUP-CoAP] or publish-subscribe (pub-sub)
subscribe messaging [I-D.ietf-core-coap-pubsub], and can be protected messaging [CoAP-PUBSUB], and can be protected in different ways.
in different ways.
Therefore, this document delegates details on the communication and Therefore, this document delegates details on the communication and
security approaches used in a group to separate application profiles. security approaches used in a group to separate application profiles.
These are specialized instances of this document, targeting a These are specialized instances of this document that target a
particular group communication approach and defining how particular group communication approach and define how communications
communications in the group are protected, as well as the specific in the group are protected, as well as the specific keying material
keying material and configuration parameters provided to group and configuration parameters provided to group members.
members.
In order to ensure consistency and aid the development of such In order to ensure consistency and aid the development of such
application profiles, Appendix A of this document defines a number of application profiles, Appendix A of this document defines a number of
related compliance requirements. In particular, Appendix A.1 related compliance requirements. In particular, Appendix A.1
compiles the requirements that application profiles are REQUIRED to compiles the requirements that application profiles are REQUIRED to
fulfill; these are referred to by an identifier that starts with fulfill; these are referred to by an identifier that starts with
"REQ". Instead, Appendix A.2 compiles the requirements that "REQ". Instead, Appendix A.2 compiles the requirements that
application profiles MAY fulfill; these are referred to by an application profiles MAY fulfill; these are referred to by an
identifier that starts with "OPT". identifier that starts with "OPT".
skipping to change at page 5, line 33 skipping to change at line 193
the group upon membership changes (rekeying). If the application the group upon membership changes (rekeying). If the application
requires backward security (i.e., new group members must be prevented requires backward security (i.e., new group members must be prevented
from accessing communications in the group prior to their joining), from accessing communications in the group prior to their joining),
then a rekeying has to occur every time new members join the group. then a rekeying has to occur every time new members join the group.
If the application requires forward security (i.e., former group If the application requires forward security (i.e., former group
members must be prevented from accessing communications in the group members must be prevented from accessing communications in the group
after their leaving), then a rekeying has to occur every time current after their leaving), then a rekeying has to occur every time current
members leave or are evicted from the group. members leave or are evicted from the group.
A group rekeying scheme performs the actual distribution of the new A group rekeying scheme performs the actual distribution of the new
keying material, by rekeying the current group members when a new keying material by rekeying the current group members when a new
Client joins the group, and the remaining group members when a Client Client joins the group and rekeying the remaining group members when
leaves the group. This can rely on different approaches, including a Client leaves the group. This can rely on different approaches,
efficient group rekeying schemes such as [RFC2093], [RFC2094], and including efficient group rekeying schemes such as those described in
[RFC2627]. [RFC2093], [RFC2094], and [RFC2627].
Consistently with what is recommended in the ACE framework, this Consistently with what is recommended in the ACE framework, this
document uses CBOR [RFC8949] for data encoding. However, using JSON document uses Concise Binary Object Representation (CBOR) [RFC8949]
[RFC8259] instead of CBOR is possible, by relying on the conversion for data encoding. However, using JSON [RFC8259] instead of CBOR is
method specified in Sections 6.1 and 6.2 of [RFC8949]. possible by relying on the conversion method specified in Sections
6.1 and 6.2 of [RFC8949].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with: Readers are expected to be familiar with the following:
* The terms and concepts described in the ACE framework [RFC9200] * The terms and concepts described in the ACE framework [RFC9200]
and in the Authorization Information Format (AIF) [RFC9237] to and in the Authorization Information Format (AIF) [RFC9237] to
express authorization information. The terminology for entities express authorization information. The terminology for entities
in the considered architecture is defined in OAuth 2.0 [RFC6749]. in the considered architecture is defined in OAuth 2.0 [RFC6749].
In particular, this includes Client (C), Resource Server (RS), and In particular, this includes Client (C), Resource Server (RS), and
Authorization Server (AS). Authorization Server (AS).
* The terms and concepts described in CoAP [RFC7252]. Unless * The terms and concepts described in the Constrained Application
otherwise indicated, the term "endpoint" is used here following Protocol (CoAP) [RFC7252]. The term "endpoint" is used here
its OAuth definition, aimed at denoting resources such as /token following its OAuth definition, aimed at denoting resources such
and /introspect at the AS, and /authz-info at the RS. This as /token and /introspect at the AS and /authz-info at the RS.
document does not use the CoAP definition of "endpoint", which is This document does not use the CoAP definition of "endpoint",
"An entity participating in the CoAP protocol". which is "An entity participating in the CoAP protocol".
* The terms and concepts described in CDDL [RFC8610], CBOR * The terms and concepts described in Concise Data Definition
[RFC8949], and COSE [RFC9052][RFC9053][RFC9338]. Language (CDDL) [RFC8610], CBOR [RFC8949], and CBOR Object Signing
and Encryption (COSE) [RFC9052] [RFC9053] [RFC9338].
A node interested to participate in group communication as well as A node interested in participating in group communication, as well as
already participating as a group member is interchangeably denoted as one that is already participating as a group member, is
"Client". interchangeably denoted as "Client".
This document also uses the following terms. This document also uses the following terms.
* Group: a set of nodes that share common keying material and Group: A set of nodes that share common keying material and security
security parameters used to protect their communications with one parameters used to protect their communications with one another.
another. That is, the term refers to a "security group". That is, the term refers to a "security group".
This term is not to be confused with an "application group", which This term is not to be confused with an "application group", which
has relevance at the application level and whose members share a has relevance at the application level and whose members share a
common pool of resources or content. Examples of application common pool of resources or content. Examples of application
groups are the set of all nodes deployed in a same physical room, groups are the set of all nodes deployed in a same physical room
or the set of nodes registered to a pub-sub topic. or the set of nodes registered to a pub-sub topic.
This term is also not to be confused with a "multicast group", This term is also not to be confused with a "multicast group",
which has relevance at the network level and whose members all which has relevance at the network level and whose members all
listen to a group network address for receiving messages sent to listen to a group network address for receiving messages sent to
that group. An example of multicast group is the set of nodes that group. An example of a multicast group is the set of nodes
that are configured to receive messages that are sent to the that are configured to receive messages that are sent to the
group's associated IP multicast address. group's associated IP multicast address.
The same security group might be associated with multiple The same security group might be associated with multiple
application groups. Also, the same application group can be application groups. Also, the same application group might be
associated with multiple security groups. Further details and associated with multiple security groups. Further details and
considerations on the mapping between the three types of group are considerations on the mapping between the three types of groups
out of the scope of this document. are out of the scope of this document.
* Key Distribution Center (KDC): the entity responsible for managing Key Distribution Center (KDC): The entity responsible for managing
one or multiple groups, with particular reference to the group one or multiple groups, with particular reference to the group
membership and the keying material to use for protecting group membership and the keying material to use for protecting group
communications. communications.
Furthermore, this document uses "names" or "identifiers" for groups Furthermore, this document uses "names" or "identifiers" for groups
and nodes. Their different meanings are summarized below. and nodes. Their different meanings are summarized below.
* Group name: The identifier of a group, as a text string encoded as Group name: The identifier of a group as a text string encoded as
UTF-8 [RFC3629]. Once established, it is invariant. It is used UTF-8 [RFC3629]. Once established, it is invariant. It is used
in the interactions between Client, AS, and RS to identify a in the interactions between the Client, AS, and RS to identify a
group. A group name is always unique among the group names of the group. A group name is always unique among the group names of the
existing groups under the same KDC. existing groups under the same KDC.
* GROUPNAME: The text string used in URIs to identify a group. Once GROUPNAME: The text string used in URIs to identify a group. Once
established, it is invariant. GROUPNAME uniquely maps to the established, it is invariant. GROUPNAME uniquely maps to the
group name of a group, although they do not necessarily coincide. group name of a group, although they do not necessarily coincide.
* Group identifier: the identifier of the group keying material used Group identifier: The identifier of the group keying material used
in a group. Unlike group name and GROUPNAME, this identifier in a group. Unlike group name and GROUPNAME, this identifier
changes over time, when the group keying material is updated. changes over time when the group keying material is updated.
* Node name: The identifier of a node, as a text string encoded as Node name: The identifier of a node as a text string encoded as
UTF-8 [RFC3629] and consistent with the semantics of URI path UTF-8 [RFC3629] and consistent with the semantics of URI path
segments (see Section 3.3 of [RFC3986]). Once established, it is segments (see Section 3.3 of [RFC3986]). Once established, it is
invariant. It is used in the interactions between Client and RS, invariant. It is used in the interactions between the Client and
as well as to identify a member of a group. A node name is always RS, as well as to identify a member of a group. A node name is
unique among the node names of the current nodes within a group. always unique among the node names of the current nodes within a
group.
* NODENAME: The text string used in URIs to identify a member of a NODENAME: The text string used in URIs to identify a member of a
group. Once established, it is invariant. Its value coincides group. Once established, it is invariant. Its value coincides
with the node name of the associated group member. with the node name of the associated group member.
This document additionally uses the following terminology: This document additionally uses the following terminology:
* Transport profile: a profile of ACE as per Section 5.8.4.3 of Transport profile: A profile of the ACE framework as per
[RFC9200]. A transport profile specifies the communication Section 5.8.4.3 of [RFC9200]. A transport profile specifies the
protocol and communication security protocol between an ACE Client communication protocol and communication security protocol between
and Resource Server, as well as proof-of-possession methods, if it an ACE Client and Resource Server, as well as proof-of-possession
supports proof-of-possession access tokens, etc. Transport methods if it supports proof-of-possession access tokens.
profiles of ACE include, for instance, [RFC9203], [RFC9202], and Transport profiles of ACE include, for instance, those described
[RFC9431]. in [RFC9202], [RFC9203], and [RFC9431].
* Application profile: a profile that defines how applications Application profile: A profile that defines how applications enforce
enforce and use supporting security services they require. These and use supporting security services they require. These services
services may include, for instance, provisioning, revocation, and may include, for instance, provisioning, revocation, and
distribution of keying material. An application profile may distribution of keying material. An application profile may
define specific procedures and message formats. define specific procedures and message formats.
* Authentication credential: the set of information associated with Authentication credential: The set of information associated with an
an entity, including that entity's public key and parameters entity, including that entity's public key and parameters
associated with the public key. Examples of authentication associated with the public key. Examples of authentication
credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs)
[RFC8392], X.509 certificates [RFC5280], and C509 certificates [RFC8392], X.509 certificates [RFC5280], and C509 certificates
[I-D.ietf-cose-cbor-encoded-cert]. [C509-CERT].
* Individual keying material: information pertaining exclusively to Individual keying material: Information pertaining exclusively to a
a group member, as associated with its group membership and group member, as associated with its group membership and related
related to other keying material and parameters used in the group. to other keying material and parameters used in the group. For
For example, this can be an identifier that the secure example, this can be an identifier that the secure communication
communication protocol employs to uniquely identify a node as a protocol employs to uniquely identify a node as a group member
group member (e.g., a cryptographic key identifier uniquely (e.g., a cryptographic key identifier uniquely associated with the
associated with the group member in question). The specific group member in question). The specific nature and format of
nature and format of individual keying material used in a group is individual keying material used in a group is defined in the
defined in application profiles of this specification. The application profiles of this specification. The individual keying
individual keying material of a group member is not related to the material of a group member is not related to the secure
secure association between that group member and the KDC. association between that group member and the KDC.
Examples throughout this document are expressed in CBOR diagnostic Throughout this document, examples for CBOR data items are expressed
notation without the tag and value abbreviations. in CBOR extended diagnostic notation as defined in Section 8 of
[RFC8949] and Appendix G of [RFC8610] ("diagnostic notation"), unless
noted otherwise. We often use diagnostic notation comments to
provide a textual representation of the parameters' keys and values.
2. Overview 2. Overview
At a high level, the key provisioning process is separated in two At a high level, the key provisioning process is separated in two
phases: the first one follows the ACE Framework between Client, AS, phases: the first one follows the ACE framework between the Client,
and KDC; the second one is the actual key distribution between Client AS, and KDC, while the second one is the actual key distribution
and KDC. After the two phases are completed, the Client is able to between the Client and KDC. After the two phases are completed, the
participate in the group communication, via a Dispatcher entity. Client is able to participate in the group communication via a
Dispatcher entity.
.------------. .------------. .------------. .------------.
| AS | .----->| KDC | | AS | .----->| KDC |
'------------' | '------------' '------------' | '------------'
^ | ^ |
| | | |
v | v |
.------------. | .-----------. .------------. | .-----------.
| Client |<-------' .------------. | .---------+-. | Client |<-------' .------------. | .---------+-.
| |<------------->| Dispatcher |<----->| | .---------+-. | |<------------->| Dispatcher |<----->| | .---------+-.
'------------' '------------' '-+ | Group | '------------' '------------' '-+ | Group |
'-+ members | '-+ members |
'-----------' '-----------'
Figure 1: Key Distribution Participants Figure 1: Key Distribution Participants
The following participants (see Figure 1) take part in the The following participants (see Figure 1) take part in the
authorization and key distribution. authorization and key distribution.
* Client (C): node that wants to join a group and take part in group * Client (C): A node that wants to join a group and take part in
communication with other group members. Within the group, the group communication with other group members. Within the group,
Client can have different roles. the Client can have different roles.
* Authorization Server (AS): as per the AS defined in the ACE * Authorization Server (AS): As per the AS defined in the ACE
Framework [RFC9200], it enforces access policies that prescribe framework [RFC9200], it enforces access policies that prescribe
whether a node is allowed to join a given group and with what whether a node is allowed to join a given group or not and with
roles and rights (e.g., write and/or read). what roles and rights (e.g., write and/or read).
* Key Distribution Center (KDC): entity that maintains the keying * Key Distribution Center (KDC): An entity that maintains the keying
material to protect group communications, and provides it to material to protect group communications and provides it to
Clients authorized to join a given group. During the first part Clients authorized to join a given group. During the first phase
of the exchange (Section 3), the KDC takes the role of the RS in of the process (Section 3), the KDC takes the role of the RS in
the ACE Framework. During the second part (Section 4), which is the ACE framework. During the second phase of the process
not based on the ACE Framework, the KDC distributes the keying (Section 4), which is not based on the ACE framework, the KDC
material. In addition, the KDC provides the latest keying distributes the keying material. In addition, the KDC provides
material to group members when requested or, if required by the the latest keying material to group members when requested or, if
application, when group membership changes. required by the application, when group membership changes.
* Dispatcher: entity through which the Clients communicate with the * Group members: Nodes that have joined a group where they take part
group when sending a message intended for multiple group members. in group communication with one another, protecting it with the
That is, the Dispatcher distributes such a one-to-many message to group keying material obtained from the KDC.
the group members as intended recipients. The Dispatcher does not
have access to the group keying material. A single-recipient * Dispatcher: An entity through which the Clients communicate with
message intended for only one group member may be delivered by the group when sending a message intended for multiple group
alternative means, with no assistance from the Dispatcher. members. That is, the Dispatcher distributes such a one-to-many
message to the group members as intended recipients. The
Dispatcher does not have access to the group keying material. A
single-recipient message intended for only one group member may be
delivered by alternative means, i.e., with no assistance from the
Dispatcher.
Examples of a Dispatcher are: the Broker in a pub-sub setting; a Examples of a Dispatcher are: the Broker in a pub-sub setting; a
relayer for group communication that delivers group messages as relayer for group communication that delivers group messages as
multiple unicast messages to all group members; an implicit entity multiple unicast messages to all group members; and an implicit
as in a multicast communication setting, where messages are entity as in a multicast communication setting, where messages are
transmitted to a multicast IP address and delivered on the transmitted to a multicast IP address and delivered on the
transport channel. transport channel.
If it consists of an explicit entity such as a pub-sub Broker or a If it consists of an explicit entity, such as a pub-sub Broker or
message relayer, the Dispatcher is comparable to an untrusted on- a message relayer, the Dispatcher is comparable to an untrusted
path intermediary, and as such it is able to see the messages sent on-path intermediary; as such, it is able to see the messages sent
by Clients in the group, but not to decrypt them and read their by Clients in the group but not able to decrypt them and read
plain content. their plain content.
This document specifies a mechanism for: This document specifies a mechanism for:
* Authorizing a Client to join the group (Section 3), and providing * Authorizing a Client to join the group (Section 3) and providing
it with the group keying material to communicate with the other it with the group keying material to communicate with the other
group members (Section 4). group members (Section 4),
* Allowing a group member to retrieve group keying material * Allowing a group member to retrieve group keying material
(Section 4.3.2.1 and Section 4.8.1.1). (Sections 4.3.2.1 and 4.8.1.1),
* Allowing a group member to retrieve authentication credentials of * Allowing a group member to retrieve authentication credentials of
other group members (Section 4.4.1.1) and to provide an updated other group members (Section 4.4.1.1) and to provide an updated
authentication credential (Section 4.9.1.1). authentication credential (Section 4.9.1.1),
* Allowing a group member to leave the group (Section 4.8.3.1). * Allowing a group member to leave the group (Section 4.8.3.1),
* Evicting a group member from the group (Section 5). * Evicting a group member from the group (Section 5), and
* Renewing and re-distributing the group keying material (rekeying), * Renewing and redistributing the group keying material (rekeying),
e.g., upon a membership change in the group (Section 6). e.g., upon a membership change in the group (Section 6).
Rekeying the group may result in a temporary misalignment of the Rekeying the group may result in a temporary misalignment of the
keying material stored by the different group members. Different keying material stored by the different group members. Different
situations where this can happen and how they can be handled are situations where this can happen and how they can be handled are
discussed in Section 6.3. discussed in Section 6.3.
Figure 2 provides a high level overview of the message flow for a Figure 2 provides a high-level overview of the message flow for a
node joining a group. The message flow can be expanded as follows. node joining a group. The message flow can be expanded as follows.
1. The joining node requests an access token from the AS, in order 1. The joining node requests an access token from the AS in order to
to access one or more group-membership resources at the KDC and access one or more group-membership resources at the KDC and
hence join the associated groups. hence join the associated groups.
This exchange between Client and AS MUST be secured, as specified This exchange between the Client and AS MUST be secured, as
by the transport profile of ACE used between Client and KDC. specified by the transport profile of ACE used between the Client
Based on the response from the AS, the joining node will and KDC. Based on the response from the AS, the joining node
establish or continue using a secure communication association will establish or continue using a secure communication
with the KDC. association with the KDC.
2. The joining node transfers authentication and authorization 2. The joining node transfers authentication and authorization
information to the KDC, by transferring the obtained access information to the KDC by transferring the obtained access token.
token. This is typically achieved by including the access token This is typically achieved by including the access token in a
in a request sent to the /authz-info endpoint at the KDC. request sent to the /authz-info endpoint at the KDC.
Once this exchange is completed, the joining node MUST have a Once this exchange is completed, the joining node MUST have a
secure communication association established with the KDC, before secure communication association established with the KDC before
joining a group under that KDC. joining a group under that KDC.
This exchange and the following secure communications between the This exchange and the following secure communications between the
Client and the KDC MUST occur in accordance with the transport Client and the KDC MUST occur in accordance with the transport
profile of ACE used between Client and KDC, such as the DTLS profile of ACE used between the Client and KDC, such as the DTLS
transport profile [RFC9202] and OSCORE transport profile transport profile of ACE [RFC9202] or the OSCORE transport
[RFC9203] of ACE. profile of ACE [RFC9203].
3. The joining node starts the joining process to become a member of 3. The joining node starts the joining process to become a member of
the group, by sending a request to the related group-membership the group by sending a request to the related group-membership
resource at the KDC. Based on the application requirements and resource at the KDC. Based on the application requirements and
policies, the KDC may perform a group rekeying, by generating new policies, the KDC may perform a group rekeying by generating new
group keying material and distributing it to the current group group keying material and distributing it to the current group
members through the rekeying scheme used in the group. members through the rekeying scheme used in the group.
At the end of the joining process, the joining node has received At the end of the joining process, the joining node has received
from the KDC the parameters and group keying material to securely the parameters and group keying material from the KDC to securely
communicate with the other group members. Also, the KDC has communicate with the other group members. Also, the KDC has
stored the association between the authorization information from stored the association between the authorization information from
the access token and the secure session with the joining node. the access token and the secure communication association with
the joining node.
4. The joining node and the KDC maintain the secure association, to 4. The joining node and the KDC maintain the secure communication
support possible future communications. These especially include association to support possible future communications. These
key management operations, such as retrieval of updated keying especially include key management operations, such as the
material or participation to a group rekeying process. retrieval of updated keying material or the participation in a
group rekeying process.
5. The joining node can communicate securely with the other group 5. The joining node can communicate securely with the other group
members, using the keying material provided in step 3. members by using the keying material obtained in step 3.
C AS KDC Group C AS KDC Group
| | | Members | | | Members
/ | | | | / | | | |
| |--- Authorization Request -->| | | | |--- Authorization Request -->| | |
| | | | | | | | | |
| |<-- Authorization Response --| | | | |<-- Authorization Response --| | |
(*) < | | | | (*) < | | | |
| | | | | | | | | |
| |--- Token Transfer Request ---->| | | |--- Token Transfer Request ---->| |
skipping to change at page 12, line 4 skipping to change at line 511
| | | (optional) | | | | (optional) |
|<-------- Join Response ---------| | |<-------- Join Response ---------| |
| | | | | | | |
| | | | | | | |
| | | Dispatcher | | | | Dispatcher |
| | | | | |
|<======= Secure group communication =========|=========>| |<======= Secure group communication =========|=========>|
| | | | | |
(*) Defined in the ACE framework (*) Defined in the ACE framework
Figure 2: Message Flow Upon New Node's Joining
Figure 2: Message Flow upon a New Node's Joining
3. Authorization to Join a Group 3. Authorization to Join a Group
This section describes in detail the format of messages exchanged by This section describes in detail the format of messages exchanged by
the participants when a node requests access to a given group. This the participants when a node requests access to a given group. This
exchange is based on ACE [RFC9200]. exchange is based on ACE [RFC9200].
As defined in [RFC9200], the Client asks the AS for the authorization As defined in [RFC9200], the Client asks the AS for the authorization
to join the group through the KDC (see Section 3.1). If the request to join the group through the KDC (see Section 3.1). If the request
is approved and authorization is granted, the AS provides the Client is approved and authorization is granted, the AS provides the Client
with a proof-of-possession access token and parameters to securely with a proof-of-possession access token and parameters to securely
communicate with the KDC (see Section 3.2). communicate with the KDC (see Section 3.2).
Communications between the Client and the AS MUST be secured, Communications between the Client and the AS MUST be secured
according to what is defined by the used transport profile of ACE. according to what is defined by the used transport profile of ACE.
The Content-Format used in the message also depends on the used The Content-Format used in the message also depends on the used
transport profile of ACE. For example, it can be application/ transport profile of ACE. For example, it can be "application/
ace+cbor for the first two messages and application/cwt for the third ace+cbor" for the first two messages and "application/cwt" for the
message, which are defined in the ACE framework. third message, which are defined in the ACE framework.
The transport profile of ACE also defines a number of details such as The transport profile of ACE also defines a number of details, such
the communication and security protocols used with the KDC (see as the communication and security protocols used with the KDC (see
Appendix C of [RFC9200]). Appendix C of [RFC9200]).
Figure 3 gives an overview of the exchange described above. Figure 3 gives an overview of the exchange described above.
Client AS KDC Client AS KDC
| | | | | |
|---- Authorization Request: POST /token ------->| | |---- Authorization Request: POST /token ------->| |
| | | | | |
|<--- Authorization Response: 2.01 (Created) ----| | |<--- Authorization Response: 2.01 (Created) ----| |
| | | | | |
skipping to change at page 13, line 5 skipping to change at line 559
Figure 3: Message Flow of Join Authorization Figure 3: Message Flow of Join Authorization
3.1. Authorization Request 3.1. Authorization Request
The Authorization Request sent from the Client to the AS is defined The Authorization Request sent from the Client to the AS is defined
in Section 5.8.1 of [RFC9200] and MAY contain the following in Section 5.8.1 of [RFC9200] and MAY contain the following
parameters, which, if included, MUST have the format and value as parameters, which, if included, MUST have the format and value as
specified below. specified below.
* 'scope', specifying the names of the groups that the Client * 'scope': specifying the names of the groups that the Client
requests to access, and optionally the roles that the Client requests to access and optionally the roles that the Client
requests to have in those groups. requests to have in those groups.
This parameter is encoded as a CBOR byte string, which wraps a This parameter is encoded as a CBOR byte string, which wraps a
CBOR array of scope entries. All the scope entries are specified CBOR array of scope entries. All the scope entries are specified
according to a same format, i.e., either the AIF format or the according to the same format, i.e., either the Authorization
textual format defined below. Information Format (AIF) or the textual format defined below.
- If the AIF format is used, each scope entry is encoded as per - If AIF is used, each scope entry is encoded as per [RFC9237],
[RFC9237], i.e., as a CBOR array [Toid, Tperm]. If a scope i.e., as a CBOR array [Toid, Tperm]. If a scope entry
entry expresses a set of roles to take in a group as per this expresses a set of roles to take in a group as per this
document, the object identifier "Toid" specifies the group name document, the object identifier "Toid" specifies the group name
and MUST be encoded as a CBOR text string, while the permission and MUST be encoded as a CBOR text string, while the permission
set "Tperm" specifies the roles that the Client wishes to take set "Tperm" specifies the roles that the Client wishes to take
in the group. in the group.
The AIF format is the default format for application profiles AIF is the default format for application profiles of this
of this specification, and is preferable for those that aim for specification and is preferable for those that aim for a
a compact encoding of scope. This is desirable especially for compact encoding of scope. This is especially desirable for
application profiles defining several roles, with the Client application profiles defining several roles, with the Client
possibly asking for multiple roles combined. possibly asking for multiple roles combined.
Figure 4 shows an example in CDDL notation [RFC8610] where Figure 4 shows an example in CDDL notation [RFC8610] where
scope uses the AIF format. scope uses AIF.
- If the textual format is used, each scope entry is a CBOR array - If the textual format is used, each scope entry is a CBOR array
formatted as follows. formatted as follows.
o As first element, the group name, encoded as a CBOR text o As the first element, the group name, encoded as a CBOR text
string. string.
o Optionally, as second element, the role or CBOR array of o Optionally, as the second element, the role or CBOR array of
roles that the Client wishes to take in the group. This roles that the Client wishes to take in the group. This
element is optional since roles may have been pre-assigned element is optional since roles may have been pre-assigned
to the Client, as associated with its verifiable identity to the Client, as associated with its verifiable identity
credentials. Alternatively, the application may have credentials. Alternatively, the application may have
defined a single, well-known role for the target resource(s) defined a single, well-known role for the target resource(s)
and audience(s). and audience(s).
Figure 5 shows an example in CDDL notation where scope uses the Figure 5 shows an example in CDDL notation where scope uses the
textual format, with group name and role identifiers encoded as textual format with the group name and role identifiers encoded
CBOR text strings. as CBOR text strings.
It is REQUIRED of application profiles of this specification to It is REQUIRED for application profiles of this specification to
specify the exact format and encoding of scope (REQ1). This specify the exact format and encoding of scope (REQ1). This
includes defining the set of possible roles and their identifiers, includes defining the set of possible roles and their identifiers,
as well as the corresponding encoding to use in the scope entries as well as the corresponding encoding to use in the scope entries
according to the used scope format. according to the used scope format.
If the application profile uses the AIF format, it is also If the application profile uses AIF, it is also REQUIRED to
REQUIRED to register its specific instance of "Toid" and "Tperm", register its specific instance of "Toid" and "Tperm", as well as
as well as the corresponding Media Type and Content-Format, as per the corresponding media type and Content-Format, as per the
the guidelines in [RFC9237] (REQ2). guidelines in [RFC9237] (REQ2).
If the application profile uses the textual format, it MAY If the application profile uses the textual format, it MAY
additionally specify CBOR values to use for abbreviating the role additionally specify CBOR values to use for abbreviating the role
identifiers (OPT1). identifiers (OPT1).
* 'audience', with an identifier of the KDC. * 'audience': with an identifier of the KDC.
As defined in [RFC9200], other additional parameters can be included As defined in [RFC9200], other additional parameters can be included
if necessary. if necessary.
;# include rfc9237 ;# include rfc9237
gname = tstr gname = tstr
permissions = uint .bits roles permissions = uint .bits roles
skipping to change at page 14, line 42 skipping to change at line 640
Requester: 1, Requester: 1,
Responder: 2, Responder: 2,
Monitor: 3, Monitor: 3,
Verifier: 4 Verifier: 4
) )
scope_entries = AIF-Generic<gname, permissions> scope_entries = AIF-Generic<gname, permissions>
scope = bstr .cbor scope_entries scope = bstr .cbor scope_entries
Figure 4: Example of scope using the AIF format Figure 4: Example of scope Using AIF
gname = tstr gname = tstr
role = tstr role = tstr
scope_entry = [ gname , ? ( role / [ 2*role ] ) ] scope_entry = [gname, ? ( role / [2* role] )]
scope_entries = [ * scope_entry ] scope_entries = [* scope_entry]
scope = bstr .cbor scope_entries scope = bstr .cbor scope_entries
Figure 5: Example of scope using the textual format, with the
role identifiers encoded as text strings Figure 5: Example of scope Using the Textual Format, with the
Role Identifiers Encoded as Text Strings
3.2. Authorization Response 3.2. Authorization Response
The AS processes the Authorization Request as defined in The AS processes the Authorization Request as defined in
Section 5.8.2 of [RFC9200], especially verifying that the Client is Section 5.8.2 of [RFC9200], especially verifying that the Client is
authorized to access the specified groups with the requested roles, authorized to access the specified groups with the requested roles or
or possibly a subset of those. possibly a subset of those.
In case of successful verification, the Authorization Response sent In case of successful verification, the Authorization Response sent
from the AS to the Client is also defined in Section 5.8.2 of from the AS to the Client is also defined in Section 5.8.2 of
[RFC9200]. Note that the parameter 'expires_in' MAY be omitted if [RFC9200]. Note that the 'expires_in' parameter MAY be omitted if
the application defines how the expiration time is communicated to the application defines how the expiration time is communicated to
the Client via other means, or if it establishes a default value. the Client via other means or if it establishes a default value.
Additionally, when included, the following parameter MUST have the Additionally, when included, the following parameter MUST have the
corresponding values: corresponding values:
* 'scope' has the same format and encoding of 'scope' in the * 'scope' has the same format and encoding of 'scope' in the
Authorization Request, defined in Section 3.1. If this parameter Authorization Request, as defined in Section 3.1. If this
is not present, the granted scope is equal to the one requested in parameter is not present, the granted scope is equal to the one
Section 3.1. requested in Section 3.1.
The proof-of-possession access token (in 'access_token' above) MUST The proof-of-possession access token in the 'access_token' parameter
contain the following parameters: MUST contain the following:
* a confirmation claim (see, for example 'cnf' defined in * a confirmation claim (for example, see 'cnf' defined in
Section 3.1 of [RFC8747] for CWT); Section 3.1 of [RFC8747] for CWTs)
* an expiration time claim (see, for example 'exp' defined in * an expiration time claim (for example, see 'exp' defined in
Section 3.1.4 of [RFC8392] for CWT); Section 3.1.4 of [RFC8392] for CWTs)
* a scope claim (see, for example 'scope' registered in Section 8.14 * a scope claim (for example, see 'scope' registered in Section 8.14
of [RFC9200] for CWT). of [RFC9200] for CWTs)
This claim specifies the same access control information as in the If the 'scope' parameter is present in the Authorization Response,
'scope' parameter of the Authorization Response, if the parameter this claim specifies the same access control information as in the
is present in the message. If the parameter is not present, the 'scope' parameter. Instead, if the 'scope' parameter is not
claim specifies the access control information as in the 'scope' present in the Authorization Response, this claim specifies the
parameter of the Authorization Request, if present, or the default same access control information as in the 'scope' parameter of the
scope that the AS is granting the Client, if not present. Authorization Request, if the parameter is present therein, or the
default scope that the AS is granting the Client otherwise.
By default, this claim has the same encoding as the 'scope' By default, this claim has the same encoding as the 'scope'
parameter in the Authorization Request, defined in Section 3.1. parameter in the Authorization Request, as defined in Section 3.1.
Optionally, an alternative extended format of scope defined in Optionally, an alternative extended format of scope defined in
Section 7 can be used. This format explicitly signals the Section 7 can be used. This format explicitly signals the
semantics used to express the actual access control information, semantics used to express the actual access control information,
and according to which this has to be parsed. This enables a which has to be parsed. This enables a Resource Server to
Resource Server to correctly process a received access token, also correctly process a received access token, also in case:
in case:
- The Resource Server implements a KDC that supports multiple - The Resource Server implements a KDC that supports multiple
application profiles of this specification, using different application profiles of this specification using different
scope semantics; and/or scope semantics and/or
- The Resource Server implements further services beyond a KDC - The Resource Server implements further services beyond a KDC
for group communication, using different scope semantics. for group communication using different scope semantics.
If the Authorization Server is aware that this applies to the If the Authorization Server is aware that this applies to the
Resource Server for which the access token is issued, the Resource Server for which the access token is issued, the
Authorization Server SHOULD use the extended format of scope Authorization Server SHOULD use the extended format of scope
defined in Section 7. defined in Section 7.
The access token MAY additionally contain other claims that the The access token MAY additionally contain other claims that the
transport profile of ACE requires, or other optional parameters. transport profile of ACE or other optional parameters require.
When receiving an Authorization Request from a Client that was When receiving an Authorization Request from a Client that was
previously authorized, and for which the AS still stores a valid non- previously authorized and for which the AS still stores a valid non-
expired access token, the AS MAY reply with that token. Note that it expired access token, the AS MAY reply with that token. Note that it
is up to application profiles of ACE to make sure that re-posting the is up to application profiles of ACE to make sure that reposting the
same access token does not cause re-use of keying material between same access token does not cause reuse of keying material between
nodes (for example, that is accomplished with the use of random nodes (for example, that is accomplished with the use of random
nonces in [RFC9203]). nonces in [RFC9203]).
3.3. Token Transferring 3.3. Token Transferring
The Client sends a Token Transfer Request to the KDC, i.e., a CoAP The Client sends a Token Transfer Request to the KDC, i.e., a CoAP
POST request including the access token and targeting the authz-info POST request including the access token and targeting the /authz-info
endpoint (see Section 5.10.1 of [RFC9200]). endpoint (see Section 5.10.1 of [RFC9200]).
Note that this request deviates from the one defined in [RFC9200], Note that this request deviates from the one defined in [RFC9200],
since it allows asking the KDC for additional information concerning since it allows asking the KDC for additional information concerning
the authentication credentials used in the group to ensure source the authentication credentials used in the group to ensure source
authentication, as well as for possible additional group parameters. authentication, as well as for possible additional group parameters.
The joining node MAY ask for this information from the KDC through The joining node MAY ask for this information from the KDC through
the same Token Transfer Request. In this case, the message MUST have the same Token Transfer Request. In this case, the message MUST have
Content-Format set to application/ace+cbor defined in Section 8.16 of Content-Format "application/ace+cbor" registered in Section 8.16 of
[RFC9200], and the message payload MUST be formatted as a CBOR map, [RFC9200], and the message payload MUST be formatted as a CBOR map,
which MUST include the access token. The CBOR map MAY additionally which MUST include the access token. The CBOR map MAY additionally
include the following parameter, which, if included, MUST have the include the following parameter, which, if included, MUST have the
format and value as specified below. format and value as specified below.
* 'sign_info' defined in Section 3.3.1, specifying the CBOR simple * 'sign_info': defined in Section 3.3.1, specifying the CBOR simple
value "null" (0xf6) to request information about the signature value null (0xf6) to request information about the signature
algorithm, the signature algorithm parameters, the signature key algorithm, the signature algorithm parameters, the signature key
parameters, and the exact format of authentication credentials parameters, and the exact format of authentication credentials
used in the groups that the Client has been authorized to join. used in the groups that the Client has been authorized to join.
Alternatively, such information may be pre-configured on the joining Alternatively, such information may be pre-configured on the joining
node, or may be retrieved by alternative means. For example, the node or may be retrieved by alternative means. For example, the
joining node may have performed an early group discovery process and joining node may have performed an early group discovery process and
obtained the link to the associated group-membership resource at the obtained the link to the associated group-membership resource at the
KDC, together with attributes descriptive of the group configuration KDC, along with attributes that describe the group configuration
(see, e.g., [I-D.tiloca-core-oscore-discovery]). (e.g., see [OSCORE-DISCOVERY]).
After successful verification, the Client is authorized to receive After successful verification, the Client is authorized to receive
the group keying material from the KDC and join the group. Hence, the group keying material from the KDC and join the group. Hence,
the KDC replies to the Client with a Token Transfer Response, i.e., a the KDC replies to the Client with a Token Transfer Response, i.e., a
CoAP 2.01 (Created) response. CoAP 2.01 (Created) response.
The Token Transfer Response MUST have Content-Format "application/ The Token Transfer Response MUST have Content-Format "application/
ace+cbor", and its payload is a CBOR map. Note that this deviates ace+cbor", and its payload is a CBOR map. Note that this deviates
from what is defined in the ACE framework, where the response from from what is defined in the ACE framework, where the response from
the authz-info endpoint is defined as conveying no payload (see the /authz-info endpoint is defined as conveying no payload (see
Section 5.10.1 of [RFC9200]). Section 5.10.1 of [RFC9200]).
If a scope entry in the access token specifies a role that requires If a scope entry in the access token specifies a role that requires
the Client to send its own authentication credential to the KDC when the Client to send its own authentication credential to the KDC when
joining the related group, then the CBOR map MUST include the joining the related group, then the CBOR map MUST include the
parameter 'kdcchallenge' defined in Section 3.3.2, specifying a 'kdcchallenge' parameter defined in Section 3.3.2, specifying a
dedicated challenge N_S generated by the KDC. dedicated challenge N_S generated by the KDC.
Later, when joining the group (see Section 4.3.1.1), the Client uses Later, when joining the group (see Section 4.3.1.1), the Client uses
the 'kdcchallenge' value and additional information to build a proof- the 'kdcchallenge' value and additional information to build a proof-
of-possession (PoP) input. This is in turn used to compute a PoP of-possession (PoP) input. In turn, this is used to compute the PoP
evidence, which the Client also provides to the KDC in order to prove evidence that the Client also provides to the KDC, in order to prove
possession of its own private key (see the 'client_cred_verify' possession of its own private key (see the 'client_cred_verify'
parameter in Section 4.3.1). parameter in Section 4.3.1).
While storing the access token, the KDC MUST store the 'kdcchallenge' While storing the access token, the KDC MUST store the 'kdcchallenge'
value associated with the Client at least until it receives a Join value associated with the Client at least until it receives a Join
Request from the Client (see Section 4.3.1.1), to be able to verify Request from the Client (see Section 4.3.1.1) to be able to verify
the PoP evidence provided during the join process, and thus that the the PoP evidence provided during the join process and thus that the
Client possesses its own private key. The KDC deletes the Client possesses its own private key. The KDC deletes the
'kdcchallenge' value associated with the Client upon deleting the 'kdcchallenge' value associated with the Client upon deleting the
access token (e.g., upon its expiration, see Section 5.10.3 of access token (e.g., upon its expiration, see Section 5.10.3 of
[RFC9200]). [RFC9200]).
The same 'kdcchallenge' value MAY be reused several times by the The same 'kdcchallenge' value MAY be reused several times by the
Client, to generate a new PoP evidence, e.g., in case the Client Client to generate new PoP evidence, e.g., in case the Client
provides the KDC with a new authentication credential while being a provides the KDC with a new authentication credential while being a
group member (see Section 4.9.1.1), or joins a different group where group member (see Section 4.9.1.1) or joins a different group where
it intends to use a different authentication credential. Therefore, it intends to use a different authentication credential. Therefore,
it is RECOMMENDED that the KDC keeps storing the 'kdcchallenge' value it is RECOMMENDED that the KDC keeps storing the 'kdcchallenge' value
after the first join is processed as well. If, upon receiving a Join after the first join is processed as well. If, upon receiving a Join
Request from a Client, the KDC has already discarded the Request from a Client, the KDC has already discarded the
'kdcchallenge' value, that will trigger an error response with a 'kdcchallenge' value, that will trigger an error response with a
newly generated 'kdcchallenge' value that the Client can use to newly generated 'kdcchallenge' value that the Client can use to
restart the join process, as specified in Section 4.3.1.1. restart the join process, as specified in Section 4.3.1.1.
If 'sign_info' is included in the Token Transfer Request, the KDC If 'sign_info' is included in the Token Transfer Request, the KDC
SHOULD include the 'sign_info' parameter in the Token Transfer SHOULD include the 'sign_info' parameter in the Token Transfer
Response, as per the format defined in Section 3.3.1. Note that the Response, as per the format defined in Section 3.3.1. Note that the
field 'id' of each 'sign_info_entry' specifies the name, or array of field 'id' of each 'sign_info_entry' specifies the name or array of
group names, to which that 'sign_info_entry' applies. As an group names to which that 'sign_info_entry' applies. As an
exception, the KDC MAY omit the 'sign_info' parameter in the Token exception, the KDC MAY omit the 'sign_info' parameter in the Token
Transfer Response even if 'sign_info' is included in the Token Transfer Response even if 'sign_info' is included in the Token
Transfer Request, in case none of the groups that the Client is Transfer Request in case none of the groups that the Client is
authorized to join uses signatures to achieve source authentication. authorized to join use signatures to achieve source authentication.
Note that the CBOR map specified as payload of the 2.01 (Created) Note that the CBOR map specified as payload of the 2.01 (Created)
response may include further parameters, e.g., according to the used response may include further parameters, e.g., according to the used
transport profile of ACE. Application profiles of this specification transport profile of ACE. Application profiles of this specification
MAY define additional parameters to use within this exchange (OPT2). MAY define additional parameters to use within this exchange (OPT2).
Application profiles of this specification MAY define alternative Application profiles of this specification MAY define alternative
specific negotiations of parameter values for the signature algorithm specific negotiations of parameter values for the signature algorithm
and signature keys, if 'sign_info' is not used (OPT3). and signature keys if 'sign_info' is not used (OPT3).
If allowed by the used transport profile of ACE, the Client may If allowed by the used transport profile of ACE, the Client may
provide the Access Token to the KDC by other means than the Token provide the access token to the KDC by other means than the Token
Transfer Request. An example is the DTLS transport profile of ACE, Transfer Request. An example is the DTLS transport profile of ACE,
where the Client can provide the access token to the KDC during the where the Client can provide the access token to the KDC during the
secure session establishment (see Section 3.3.2 of [RFC9202]). secure session establishment (see Section 3.3.2 of [RFC9202]).
3.3.1. 'sign_info' Parameter 3.3.1. 'sign_info' Parameter
The 'sign_info' parameter is an OPTIONAL parameter of the request and The 'sign_info' parameter is an OPTIONAL parameter of the request and
response messages exchanged between the Client and the authz-info response messages exchanged between the Client and the /authz-info
endpoint at the RS (see Section 5.10.1. of [RFC9200]). endpoint at the RS (see Section 5.10.1 of [RFC9200]).
This parameter allows the Client and the RS to exchange information This parameter allows the Client and the RS to exchange information
about a signature algorithm and about authentication credentials to about a signature algorithm and about authentication credentials to
accordingly use for signature verification. Its exact semantics and accordingly use for signature verification. Its exact semantics and
content are application specific. content are application specific.
In this specification and in application profiles building on it, In this specification and in application profiles building on it,
this parameter is used to exchange information about the signature this parameter is used to exchange information about the signature
algorithm and about authentication credentials to be used with it, in algorithm and about authentication credentials to be used with it in
the groups indicated by the transferred access token as per its the groups indicated by the transferred access token as per its
'scope' claim (see Section 3.2). 'scope' claim (see Section 3.2).
When used in the Token Transfer Request sent to the KDC (see When used in the Token Transfer Request sent to the KDC (see
Section 3.3), the 'sign_info' parameter specifies the CBOR simple Section 3.3), the 'sign_info' parameter specifies the CBOR simple
value "null" (0xf6). This is done to ask for information about the value null (0xf6). This is done to ask for information about the
signature algorithm and about the authentication credentials used in signature algorithm and about the authentication credentials used in
the groups that, as per the granted roles, the Client has been the groups that, as per the granted roles, the Client has been
authorized to join or interact with (e.g., as an external signature authorized to join or interact with (e.g., as an external signature
verifier). verifier).
When used in the following Token Transfer Response from the KDC (see When used in the following Token Transfer Response from the KDC (see
Section 3.3), the 'sign_info' parameter is a CBOR array of one or Section 3.3), the 'sign_info' parameter is a CBOR array of one or
more elements. The number of elements is at most the number of more elements. The number of elements is at most the number of
groups that the Client has been authorized to join or interact with. groups that the Client has been authorized to join or interact with.
Each element contains information about signing parameters and about Each element contains information about signing parameters and about
authentication credentials for one or more groups, and is formatted authentication credentials for one or more groups and is formatted as
as follows. follows.
* The first element 'id' is a group name or a CBOR array of group * The first element 'id' is a group name or a CBOR array of group
names, associated with groups for which the next four elements names, which is associated with groups for which the next four
apply. Each specified group name is a CBOR text string and is elements apply. Each specified group name is a CBOR text string
hereafter referred to as 'gname'. and is hereafter referred to as 'gname'.
* The second element 'sign_alg' is a CBOR integer or a text string, * The second element 'sign_alg' is a CBOR integer or a text string
indicating the signature algorithm used in the groups identified that indicates the signature algorithm used in the groups
by the 'gname' values. It is REQUIRED of application profiles to identified by the 'gname' values. It is REQUIRED for application
define specific values that this parameter can take (REQ3), profiles to define specific values that this parameter can take
selected from the set of signing algorithms of the COSE Algorithms (REQ3), which are selected from the set of signing algorithms of
registry [COSE.Algorithms]. the "COSE Algorithms" registry [COSE.Algorithms].
* The third element 'sign_parameters' is a CBOR array indicating the * The third element 'sign_parameters' is a CBOR array that indicates
parameters of the signature algorithm used in the groups the parameters of the signature algorithm used in the groups
identified by the 'gname' values. Its content depends on the identified by the 'gname' values. Its content depends on the
value of 'sign_alg'. It is REQUIRED of application profiles to value of 'sign_alg'. It is REQUIRED for application profiles to
define the possible values and structure for the elements of this define the possible values and structure for the elements of this
parameter (REQ4). parameter (REQ4).
* The fourth element 'sign_key_parameters' is a CBOR array * The fourth element 'sign_key_parameters' is a CBOR array that
indicating the parameters of the key used with the signature indicates the parameters of the key used with the signature
algorithm, in the groups identified by the 'gname' values. Its algorithm in the groups identified by the 'gname' values. Its
content depends on the value of 'sign_alg'. It is REQUIRED of content depends on the value of 'sign_alg'. It is REQUIRED for
application profiles to define the possible values and structure application profiles to define the possible values and structure
for the elements of this parameter (REQ5). for the elements of this parameter (REQ5).
* The fifth element 'cred_fmt' is either a CBOR integer indicating * The fifth element 'cred_fmt' either is a CBOR integer indicating
the format of authentication credentials used in the groups the format of authentication credentials used in the groups
identified by the 'gname' values, or has value the CBOR simple identified by the 'gname' values or is the CBOR simple value null
value "null" (0xf6) indicating that the KDC does not act as (0xf6), which indicates that the KDC does not act as a repository
repository of authentication credentials for group members. Its of authentication credentials for group members. Its acceptable
acceptable integer values are taken from the 'Label' column of the integer values are taken from the "Label" column of the "COSE
"COSE Header Parameters" registry [COSE.Header.Parameters], with Header Parameters" registry [COSE.Header.Parameters], with some of
some of those values also indicating the type of container to use those values also indicating the type of container to use for
for exchanging the authentication credentials with the KDC (e.g., exchanging the authentication credentials with the KDC (e.g., a
a chain or bag of certificates). It is REQUIRED of application chain or bag of certificates). It is REQUIRED for application
profiles to define specific values to use for this parameter, profiles to define specific values to use for this parameter,
consistently with the acceptable formats of authentication consistently with the acceptable formats of authentication
credentials (REQ6). credentials (REQ6).
The CDDL notation [RFC8610] of the 'sign_info' parameter is given The CDDL notation [RFC8610] of the 'sign_info' parameter is given
below. below.
sign_info = sign_info_req / sign_info_resp sign_info = sign_info_req / sign_info_resp
sign_info_req = null ; in the Token Transfer sign_info_req = null ; in the Token Transfer
; Request to the KDC ; Request to the KDC
sign_info_resp = [ + sign_info_entry ] ; in the Token Transfer sign_info_resp = [+ sign_info_entry] ; in the Token Transfer
; Response from the KDC ; Response from the KDC
sign_info_entry = sign_info_entry =
[ [
id : gname / [ + gname ], id: gname / [+ gname],
sign_alg : int / tstr, sign_alg: int / tstr,
sign_parameters : [ any ], sign_parameters: [any],
sign_key_parameters : [ + parameter : any ], sign_key_parameters: [+ parameter: any],
cred_fmt : int / null cred_fmt: int / null
] ]
gname = tstr gname = tstr
This format is consistent with every signature algorithm currently This format is consistent with every signature algorithm currently
defined in [RFC9053], i.e., with algorithms that have only the COSE defined in [RFC9053], i.e., with algorithms that have only the COSE
key type as their COSE capability. Appendix B describes how the key type as their COSE capability. Appendix B describes how the
format of each 'sign_info_entry' can be generalized for possible format of each 'sign_info_entry' can be generalized for possible
future registered algorithms having a different set of COSE future registered algorithms having a different set of COSE
capabilities. capabilities.
3.3.2. 'kdcchallenge' Parameter 3.3.2. 'kdcchallenge' Parameter
The 'kdcchallenge' parameter is an OPTIONAL parameter of the response The 'kdcchallenge' parameter is an OPTIONAL parameter of the response
message returned from the authz-info endpoint at the RS, as defined message returned from the /authz-info endpoint at the RS, as defined
in Section 5.10.1 of [RFC9200]. This parameter contains a challenge in Section 5.10.1 of [RFC9200]. This parameter contains a challenge
generated by the RS and provided to the Client. generated by the RS and provided to the Client.
In this specification and in application profiles building on it, the In this specification and in application profiles building on it, the
Client can use this challenge to prove possession of its own private Client can use this challenge to prove possession of its own private
key in the Join Request (see the 'client_cred_verify' parameter in key in the Join Request (see the 'client_cred_verify' parameter in
Section 4.3.1). Section 4.3.1).
4. KDC Functionalities 4. KDC Functionalities
This section describes the functionalities provided by the KDC, as This section describes the functionalities provided by the KDC, as
related to the provisioning of the keying material as well as to the related to the provisioning of the keying material as well as to the
group membership management. group membership management.
In particular, this section defines the interface available at the In particular, this section defines the interface available at the
KDC; specifies the handlers of each resource provided by the KDC KDC, specifies the handlers of each resource provided by the KDC
interface; and describes how Clients interact with those resources to interface, and describes how Clients interact with those resources to
join a group and to perform additional operations as group members. join a group and to perform additional operations as group members.
A key operation that the Client can perform after transferring the A key operation that the Client can perform after transferring the
access token to the KDC is a Join Request-Response exchange with the access token to the KDC is a Join Request-Response exchange with the
KDC. In the Join Request, the Client specifies the group it requests KDC. In the Join Request, the Client specifies the group it requests
to join (see Section 4.3.1.1). The KDC will then verify the access to join (see Section 4.3.1.1). The KDC will then check the stored
token and that the Client is authorized to join the specified group. access token associated with the Client and verify that the Client is
If so, the KDC provides the Client with the keying material to accordingly authorized to join the specified group. In case of
securely communicate with the other members of the group. successful verification, the KDC provides the Client with the keying
material to securely communicate with the other members of the group.
Later on as a group member, the Client can also rely on the interface Later on as a group member, the Client can also rely on the interface
at the KDC to perform additional operations, consistent with the at the KDC to perform additional operations consistent with the roles
roles it has in the group. it has in the group.
4.1. Interface at the KDC 4.1. Interface at the KDC
The KDC provides its interface by hosting the following resources. The KDC provides its interface by hosting the following resources.
Note that the root url-path "ace-group" used hereafter is a default Note that the root url-path "ace-group" used hereafter is a default
name; implementations are not required to use this name, and can name; implementations are not required to use this name and can
define their own instead. define their own instead.
If request messages sent to the KDC as well as success response If request messages sent to the KDC as well as success response
messages from the KDC include a payload and specify a Content-Format, messages from the KDC include a payload and specify a Content-Format,
those messages MUST have Content-Format set to application/ace- those messages MUST have Content-Format "application/ace-
groupcomm+cbor, defined in Section 11.2. CBOR labels for the message groupcomm+cbor", which is registered in Section 11.2. CBOR map keys
parameters are defined in Section 8. used for the message parameters are defined in Section 8.
* /ace-group : the path of this root resource is invariant once the * /ace-group : the path of this root resource is invariant once the
resource is established, and indicates that this specification is resource is established. Its employment indicates that this
used. If other applications run on a KDC implementing this specification is used. If other applications run on a KDC
specification and use this same path, those applications will implementing this specification and use this same path, those
collide, and a mechanism will be needed to differentiate the applications will collide, and a mechanism will be needed to
endpoints. differentiate the endpoints.
A Client can access this resource in order to retrieve a set of A Client can access this resource in order to retrieve a set of
group names, each corresponding to one of the specified group group names, each corresponding to one of the specified group
identifiers. This operation is described in Section 4.2.1.1. identifiers. This operation is described in Section 4.2.1.1.
Clients may be authorized to access this resource even without Clients may be authorized to access this resource even without
being members of any group at the KDC, and even if they are not being members of any group managed by the KDC and even if they are
authorized to become group members (e.g., when authorized to be not authorized to become group members (e.g., when authorized to
external signature verifiers). be external signature verifiers).
The Interface Description (if=) Link Target Attribute value The Interface Description (if=) Link Target Attribute value
"ace.groups" is registered in Section 11.5 and can be used to "ace.groups" is registered in Section 11.5 and can be used to
describe the interface provided by this root resource. describe the interface provided by this root resource.
The example below shows an exchange with a KDC with address The example below shows an exchange with a KDC with address
2001:db8::ab that hosts the resource /ace-group and returns a link 2001:db8::ab that hosts the resource /ace-group and returns a link
to such a resource in link-format [RFC6690]. to such a resource in link-format [RFC6690].
Request: Request:
skipping to change at page 22, line 45 skipping to change at line 1021
Uri-Query: "if=ace.groups" Uri-Query: "if=ace.groups"
Response: Response:
Header: Content (Code=2.05) Header: Content (Code=2.05)
Content-Format: 40 (application/link-format) Content-Format: 40 (application/link-format)
Payload: Payload:
<coap://[2001:db8::ab]/ace-group>;if="ace.groups" <coap://[2001:db8::ab]/ace-group>;if="ace.groups"
* /ace-group/GROUPNAME : one such sub-resource to /ace-group is * /ace-group/GROUPNAME : one such sub-resource to /ace-group is
hosted for each group with name GROUPNAME that the KDC manages. hosted for each group with the name GROUPNAME that the KDC
In particular, it is the group-membership resource associated with manages. In particular, it is the group-membership resource
that group, of which it contains the symmetric group keying associated with that group, and it contains the symmetric group
material. keying material of that group.
A Client can access this resource in order to join the group with A Client can access this resource in order to join the group with
name GROUPNAME, or later as a group member to retrieve the current name GROUPNAME or later as a group member to retrieve the current
group keying material. These operations are described in group keying material. These operations are described in Sections
Section 4.3.1.1 and Section 4.3.2.1, respectively. 4.3.1.1 and 4.3.2.1, respectively.
The Interface Description (if=) Link Target Attribute value The Interface Description (if=) Link Target Attribute value
"ace.group" is registered in Section 11.5 and can be used to "ace.group" is registered in Section 11.5 and can be used to
describe the interface provided by a group-membership resource. describe the interface provided by a group-membership resource.
The example below shows an exchange with a KDC with address The example below shows an exchange with a KDC with address
2001:db8::ab that hosts the group-membership resource /ace-group/ 2001:db8::ab that hosts the group-membership resource /ace-group/
gp1 and returns a link to such a resource in link-format gp1 and returns a link to such a resource in link-format
[RFC6690]. [RFC6690].
skipping to change at page 23, line 35 skipping to change at line 1056
Uri-Query: "if=ace.group" Uri-Query: "if=ace.group"
Response: Response:
Header: Content (Code=2.05) Header: Content (Code=2.05)
Content-Format: 40 (application/link-format) Content-Format: 40 (application/link-format)
Payload: Payload:
<coap://[2001:db8::ab]/ace-group/gp1>;if="ace.group" <coap://[2001:db8::ab]/ace-group/gp1>;if="ace.group"
If it is not required that the value of the GROUPNAME URI path and If it is not required that the value of the GROUPNAME URI path and
the group name in the access token scope ('gname' in Section 3.2) the group name in the access token scope ('gname' in Section 3.1)
coincide, the KDC MUST implement a mechanism to map the GROUPNAME coincide, the KDC MUST implement a mechanism to map the GROUPNAME
value in the URI to the group name, in order to refer to the value in the URI to the group name in order to refer to the
correct group (REQ7). correct group (REQ7).
* /ace-group/GROUPNAME/creds : the path of this resource is * /ace-group/GROUPNAME/creds : the path of this resource is
invariant once the resource is established. This resource invariant once the resource is established. This resource
contains the authentication credentials of all the members of the contains the authentication credentials of all the members of the
group with name GROUPNAME. group with the name GROUPNAME.
This resource is created only in case the KDC acts as a repository This resource is created only in case the KDC acts as a repository
of authentication credentials for group members. of authentication credentials for group members.
As a group member, a Client can access this resource in order to As a group member, a Client can access this resource in order to
retrieve the authentication credentials of other group members. retrieve the authentication credentials of other group members.
That is, the Client can retrieve the authentication credentials of That is, the Client can retrieve the authentication credentials of
all the current group members, or a subset of them by specifying all the current group members or a subset of them by specifying
filter criteria. These operations are described in filter criteria. These operations are described in Sections
Section 4.4.2.1 and Section 4.4.1.1, respectively. 4.4.2.1 and 4.4.1.1, respectively.
Clients may be authorized to access this resource even without Clients may be authorized to access this resource even without
being group members, e.g., if authorized to be external signature being group members, e.g., if authorized to be external signature
verifiers for the group. verifiers for the group.
* /ace-group/GROUPNAME/kdc-cred : the path of this resource is * /ace-group/GROUPNAME/kdc-cred : the path of this resource is
invariant once the resource is established. This resource invariant once the resource is established. This resource
contains the authentication credential of the KDC for the group contains the authentication credential of the KDC for the group
with name GROUPNAME. with the name GROUPNAME.
This resource is created only in case the KDC has an associated This resource is created only in case the KDC has an associated
authentication credential and this is required for the correct authentication credential and this is required for the correct
group operation. It is REQUIRED of application profiles to define group operation. It is REQUIRED for application profiles to
whether the KDC has such an associated authentication credential define whether the KDC has such an associated authentication
(REQ8). credential (REQ8).
As a group member, a Client can access this resource in order to As a group member, a Client can access this resource in order to
retrieve the current authentication credential of the KDC. retrieve the current authentication credential of the KDC. This
operation is described in Section 4.5.1.1.
Clients may be authorized to access this resource even without Clients may be authorized to access this resource even without
being group members, e.g., if authorized to be external signature being group members, e.g., if authorized to be external signature
verifiers for the group. verifiers for the group.
* /ace-group/GROUPNAME/policies : the path of this resource is * /ace-group/GROUPNAME/policies : the path of this resource is
invariant once the resource is established. This resource invariant once the resource is established. This resource
contains the group policies of the group with name GROUPNAME. contains the group policies of the group with the name GROUPNAME.
A Client can access this resource as a group member in order to A Client can access this resource as a group member in order to
retrieve the group policies. This operation is described in retrieve the group policies. This operation is described in
Section 4.6.1.1. Section 4.6.1.1.
* /ace-group/GROUPNAME/num : the path of this resource is invariant * /ace-group/GROUPNAME/num : the path of this resource is invariant
once the resource is established. This resource contains the once the resource is established. This resource contains the
current version number for the symmetric group keying material of current version number for the symmetric group keying material of
the group with name GROUPNAME. the group with the name GROUPNAME.
A Client can access this resource as a group member in order to A Client can access this resource as a group member in order to
retrieve the version number of the keying material currently used retrieve the version number of the keying material currently used
in the group. This operation is described in Section 4.7.1.1. in the group. This operation is described in Section 4.7.1.1.
* /ace-group/GROUPNAME/nodes/NODENAME : one such sub-resource of * /ace-group/GROUPNAME/nodes/NODENAME : one such sub-resource of
/ace-group/GROUPNAME is hosted for each group member of the group /ace-group/GROUPNAME is hosted for each group member of the group
with name GROUPNAME. Each such resource is identified by the node with the name GROUPNAME. Each such resource is identified by the
name NODENAME of the associated group member, and contains the node name NODENAME of the associated group member and contains the
group keying material and the individual keying material for that group keying material and the individual keying material for that
group member. group member.
A Client as a group member can access this resource in order to A Client as a group member can access this resource in order to
retrieve the current group keying material together with its retrieve the current group keying material together with its
individual keying material; request new individual keying material individual keying material, request new individual keying material
to use in the group; and leave the group. These operations are to use in the group, and leave the group. These operations are
described in Section 4.8.1.1, Section 4.8.2.1, and described in Sections 4.8.1.1, 4.8.2.1, and 4.8.3.1, respectively.
Section 4.8.3.1, respectively.
* /ace-group/GROUPNAME/nodes/NODENAME/cred : the path of this * /ace-group/GROUPNAME/nodes/NODENAME/cred : the path of this
resource is invariant once the resource is established. This resource is invariant once the resource is established. This
resource contains the individual authentication credential for the resource contains the individual authentication credential for the
node with name NODENAME, as group member of the group with name node with the name NODENAME as a group member of the group with
GROUPNAME. the name GROUPNAME.
A Client can access this resource in order to upload at the KDC a A Client can access this resource in order to upload at the KDC a
new authentication credential to use in the group. This operation new authentication credential to use in the group. This operation
is described in Section 4.9.1.1. is described in Section 4.9.1.1.
This resource is not created if the group member does not have an This resource is not created if the group member does not have an
authentication credential to use in the group, or if the KDC does authentication credential to use in the group or if the KDC does
not store the authentication credentials of group members. not store the authentication credentials of group members.
The KDC is expected to fully provide the interface defined above. It The KDC is expected to fully provide the interface defined above. It
is otherwise REQUIRED of the application profiles of this is otherwise REQUIRED for the application profiles of this
specification to indicate which resources are not hosted, i.e., which specification to indicate which resources are not hosted, i.e., which
parts of the interface defined in this section are not supported by parts of the interface defined in this section are not supported by
the KDC (REQ9). Application profiles of this specification MAY the KDC (REQ9). Application profiles of this specification MAY
extend the KDC interface, by defining additional handlers, as well as extend the KDC interface by defining additional handlers, as well as
defining additional resources and their handlers. defining additional resources and their handlers.
It is REQUIRED of application profiles of this specification to It is REQUIRED for application profiles of this specification to
register a Resource Type for the group-membership resource (REQ10), register a Resource Type for the group-membership resources (REQ10).
i.e., the group-membership resource at /ace-group/GROUPNAME. This This Resource Type can be used to discover the correct URL for
Resource Type can be used to discover the correct URL for sending a sending a Join Request to the KDC. This Resource Type can also be
Join Request to the KDC. This Resource Type can also be used to used to indicate which specific application profile of this
indicate which specific application profile of this specification is specification is used by a specific group-membership resource at the
used by a specific group-membership resource at the KDC. KDC.
It is REQUIRED of application profiles of this specification to It is REQUIRED for application profiles of this specification to
define what specific actions (e.g., CoAP methods) are allowed on each define what specific actions (e.g., CoAP methods) are allowed on each
resource provided by the KDC interface, depending on whether the resource provided by the KDC interface, depending on whether the
Client is a current group member; the roles that a Client is Client is a current group member, the roles that a Client is
authorized to take as per the obtained access token (see authorized to take as per the obtained access token (see
Section 3.1); and the roles that the Client has as current group Section 3.1), and the roles that the Client has as current group
member (REQ11). member (REQ11).
4.1.1. Operations Supported by Clients 4.1.1. Operations Supported by Clients
It is expected that a Client minimally supports the following set of It is expected that a Client minimally supports the following set of
primary operations and corresponding interactions with the KDC. primary operations and corresponding interactions with the KDC.
* FETCH request to /ace-group/ , in order to retrieve group names * FETCH request to /ace-group/ in order to retrieve group names
associated with group identifiers. associated with group identifiers.
* POST and GET requests to /ace-group/GROUPNAME/ , in order to join * POST and GET requests to /ace-group/GROUPNAME/ in order to join a
a group (POST) and later retrieve the current group key material group (POST) and later retrieve the current group keying material
as a group member (GET). as a group member (GET).
* GET and FETCH requests to /ace-group/GROUPNAME/creds , in order to * GET and FETCH requests to /ace-group/GROUPNAME/creds in order to
retrieve the authentication credentials of all the other group retrieve the authentication credentials of all the other group
members (GET) or only some of them by filtering (FETCH). While members (GET) or only some of them by filtering (FETCH). While
retrieving authentication credentials remains possible by using retrieving authentication credentials remains possible by using
GET requests, retrieval by filtering allows Clients to greatly GET requests, retrieval by filtering allows Clients to greatly
limit the size of exchanged messages. limit the size of exchanged messages.
* GET request to /ace-group/GROUPNAME/num , in order to retrieve the * GET request to /ace-group/GROUPNAME/num in order to retrieve the
current version of the group key material as a group member. current version of the group keying material as a group member.
* DELETE request to /ace-group/GROUPNAME/nodes/NODENAME , in order * DELETE request to /ace-group/GROUPNAME/nodes/NODENAME in order to
to leave the group. leave the group.
In addition, some Clients may rather not support the following set of In addition, some Clients may rather not support the following set of
secondary operations and corresponding interactions with the KDC. secondary operations and corresponding interactions with the KDC.
This can be specified, for instance, in compliance documents defining This can be specified, for instance, in compliance documents defining
minimalistic Clients and their capabilities in specific deployments. minimalistic Clients and their capabilities in specific deployments.
In turn, these might also have to consider the used application In turn, these might also have to consider the used application
profile of this specification. profile of this specification.
* GET request to /ace-group/GROUPNAME/kdc-cred , in order to * GET request to /ace-group/GROUPNAME/kdc-cred in order to retrieve
retrieve the current authentication credential of the KDC. This the current authentication credential of the KDC. This is
is relevant only if the KDC has an associated authentication relevant only if the KDC has an associated authentication
credential and this is required for the correct group operation. credential and this is required for the correct group operation.
* GET request to /ace-group/GROUPNAME/policies , in order to * GET request to /ace-group/GROUPNAME/policies in order to retrieve
retrieve the current group policies as a group member. the current group policies as a group member.
* GET request to /ace-group/GROUPNAME/nodes/NODENAME , in order to * GET request to /ace-group/GROUPNAME/nodes/NODENAME in order to
retrieve the current group keying material and individual keying retrieve the current group keying material and individual keying
material. The former can also be retrieved through a GET request material. The former can also be retrieved through a GET request
to /ace-group/GROUPNAME/ (see above). to /ace-group/GROUPNAME/ (see above).
* PUT request to /ace-group/GROUPNAME/nodes/NODENAME , in order to * POST request to /ace-group/GROUPNAME/nodes/NODENAME in order to
ask for new individual keying material. Alternatively, the Client ask for new individual keying material. Alternatively, the Client
could obtain new individual keying material by re-joining the could obtain new individual keying material by rejoining the group
group through a POST request to /ace-group/GROUPNAME/ (see above). through a POST request to /ace-group/GROUPNAME/ (see above).
Furthermore, depending on its roles in the group or on the Furthermore, depending on its roles in the group or on the
application profile of this specification, the Client might simply application profile of this specification, the Client might simply
not be associated with any individual keying material. not be associated with any individual keying material.
* POST request to /ace-group/GROUPNAME/nodes/NODENAME/cred , in * POST request to /ace-group/GROUPNAME/nodes/NODENAME/cred in order
order to provide the KDC with a new authentication credential. to provide the KDC with a new authentication credential.
Alternatively, the Client could provide a new authentication Alternatively, the Client could provide a new authentication
credential by re-joining the group through a POST request to /ace- credential by rejoining the group through a POST request to /ace-
group/GROUPNAME/ (see above). Furthermore, depending on its roles group/GROUPNAME/ (see above). Furthermore, depending on its roles
in the group, the Client might simply not have an associated in the group, the Client might simply not have an associated
authentication credential to provide. authentication credential to provide.
It is REQUIRED of application profiles of this specification to It is REQUIRED for application profiles of this specification to
categorize possible newly defined operations for Clients into primary categorize possible newly defined operations for Clients into primary
operations and secondary operations, and to provide accompanying and secondary operations and to provide accompanying considerations
considerations (REQ12). (REQ12).
4.1.2. Error Handling 4.1.2. Error Handling
Upon receiving a request from a Client, the KDC MUST check that it is Upon receiving a request from a Client, the KDC MUST check that it is
storing a valid access token from that Client. If this is not the storing a valid access token from that Client. If this is not the
case, the KDC MUST reply with a 4.01 (Unauthorized) error response. case, the KDC MUST reply with a 4.01 (Unauthorized) error response.
Unless the request targets the /ace-group resource, the KDC MUST Unless the request targets the /ace-group resource, the KDC MUST
check that it is storing a valid access token from that Client such check that it is storing a valid access token for that Client such
that: that:
* The scope specified in the access token includes a scope entry * the scope specified in the access token includes a scope entry
related to the group name GROUPNAME associated with the targeted related to the group name GROUPNAME associated with the targeted
resource; and resource and
* The set of roles specified in that scope entry allows the Client * the set of roles specified in that scope entry allows the Client
to perform the requested operation on the targeted resource to perform the requested operation on the targeted resource
(REQ11). (REQ11).
In case the KDC stores a valid access token but the verifications In case the KDC stores a valid access token but the verifications
above fail, the KDC MUST reply with a 4.03 (Forbidden) error above fail, the KDC MUST reply with a 4.03 (Forbidden) error
response. This response MAY be an AS Request Creation Hints, as response. This response MAY be an AS Request Creation Hints, as
defined in Section 5.3 of [RFC9200], in which case the Content-Format defined in Section 5.3 of [RFC9200], in which case the Content-Format
MUST be set to application/ace+cbor. MUST be "application/ace+cbor".
If the request is not formatted correctly (e.g., required fields are If the request is not formatted correctly (e.g., required fields are
not present or are not encoded as expected), the handler MUST reply not present or are not encoded as expected), the KDC MUST reply with
with a 4.00 (Bad Request) error response. a 4.00 (Bad Request) error response.
If the request includes unknown or non-expected fields, the handler If the request includes unknown or unexpected fields, the KDC MUST
MUST silently ignore them and continue processing the request. silently ignore them and continue processing the request.
Application profiles of this specification MAY define optional or Application profiles of this specification MAY define optional or
mandatory payload formats for specific error cases (OPT4). mandatory payload formats for specific error cases (OPT4).
Some error responses from the KDC can convey error-specific Some error responses from the KDC can convey error-specific
information according to the problem-details format defined in information according to the problem-details format defined in
[RFC9290]. Such error responses MUST have Content-Format set to [RFC9290]. Such error responses MUST have Content-Format
application/concise-problem-details+cbor. The payload of these error "application/concise-problem-details+cbor". The payload of these
responses MUST be a CBOR map specifying a Concise Problem Details error responses MUST be a CBOR map specifying a Concise Problem
data item (see Section 2 of [RFC9290]). The CBOR map is formatted as Details data item (see Section 2 of [RFC9290]). The CBOR map is
follows. formatted as follows.
* It MUST include the Custom Problem Detail entry 'ace-groupcomm- * It MUST include the Custom Problem Detail entry 'ace-groupcomm-
error' registered in Section 11.6 of this document. error', which is registered in Section 11.6 of this document.
This entry is formatted as a CBOR map including only one field, This entry is formatted as a CBOR map including only one field,
namely 'error-id'. The map key for 'error-id' is the CBOR namely 'error-id'. The map key for 'error-id' is the CBOR
unsigned integer with value 0. The value of 'error-id' is a CBOR unsigned integer with value 0. The value of 'error-id' is a CBOR
integer specifying the error occurred at the KDC. This value is integer specifying the error that occurred at the KDC. This value
taken from the 'Value' column of the "ACE Groupcomm Errors" is taken from the "Value" column of the "ACE Groupcomm Errors"
registry defined in Section 11.12 of this document. registry defined in Section 11.12 of this document.
The CDDL notation [RFC8610] of the 'ace-groupcomm-error' entry is The CDDL notation [RFC8610] of the 'ace-groupcomm-error' entry is
given below. given below.
ace-groupcomm-error = { ace-groupcomm-error = {
&(error-id: 0) => int &(error-id: 0) => int
} }
* It MAY include further Standard Problem Detail entries or Custom * It MAY include further Standard Problem Detail entries or Custom
Problem Detail entries (see [RFC9290]). Problem Detail entries (see [RFC9290]).
In particular, it can include the Standard Problem Detail entry In particular, it can include the Standard Problem Detail entry
'detail' (map key -2), whose value is a CBOR text string that 'detail' (map key -2), whose value is a CBOR text string that
specifies a human-readable, diagnostic description of the error specifies a human-readable, diagnostic description of the error
occurred at the KDC. The diagnostic text is intended for software occurred at the KDC. The diagnostic text is intended for software
engineers as well as for device and network operators, in order to engineers as well as for device and network operators in order to
aid debugging and provide context for possible intervention. The aid debugging and provide context for possible intervention. The
diagnostic message SHOULD be logged by the KDC. The 'detail' diagnostic message SHOULD be logged by the KDC. The 'detail'
entry is unlikely relevant in an unattended setup where human entry is unlikely relevant in an unattended setup where human
intervention is not expected. intervention is not expected.
An example of error response using the problem-details format is An example of an error response using the problem-details format is
shown in Figure 6. shown in Figure 6.
Response: Response:
Header: Service Unavailable (Code=5.03)
Content-Format: application/concise-problem-details+cbor
Payload:
{
/ title / -1: "No available node identifiers",
/ detail / -2: "Things will change after a
group rekeying; try later",
/ ace-groupcomm-error / TBD: {
/ error-id / 0: 4 / "No available node identifiers" /,
}
}
Figure 6: Example of Error Response with Problem Details Header: Service Unavailable (Code=5.03)
Content-Format: 257 (application/concise-problem-details+cbor)
Payload:
{
/ title / -1: "No available individual keying material",
/ detail / -2: "Things will change after a
group rekeying; try later",
/ ace-groupcomm-error / 0: {
/ error-id / 0: 4 / "No available individual keying material" /
}
}
Note to RFC Editor: In the figure above, please replace "TBD" with Figure 6: Example of an Error Response with Problem Details
the unsigned integer assigned as key value to the Custom Problem
Detail entry 'ace-groupcomm-error' (see Section 11.6). Then, please
delete this paragraph.
The problem-details format in general and the Custom Problem Detail The problem-details format (in general) and the Custom Problem Detail
entry 'ace-groupcomm-error' in particular are OPTIONAL to support for entry 'ace-groupcomm-error' (in particular) are OPTIONAL for Clients
Clients. A Client supporting the entry 'ace-groupcomm-error' and to support. A Client supporting the entry 'ace-groupcomm-error' and
able to understand the specified error may use that information to that can understand the specified error may use that information to
determine what actions to take next. determine what actions to take next.
Section 9 of this specification defines an initial set of error Section 9 of this specification defines an initial set of error
identifiers, as possible values for the 'error-id' field. identifiers as possible values for the 'error-id' field. Application
Application profiles of this specification inherit this initial set profiles of this specification inherit this initial set of error
of error identifiers and MAY define additional values (OPT5). identifiers and MAY define additional values (OPT5).
4.2. /ace-group 4.2. /ace-group
This resource implements the FETCH handler. This resource implements the FETCH handler.
4.2.1. FETCH Handler 4.2.1. FETCH Handler
The FETCH handler receives group identifiers and returns the The FETCH handler receives group identifiers and returns the
corresponding group names and GROUPNAME URIs. corresponding group names and GROUPNAME URIs.
The handler expects a request with payload formatted as a CBOR map, The handler expects a request with the payload formatted as a CBOR
which MUST contain the following fields: map, which MUST contain the following fields:
* 'gid', whose value is encoded as a CBOR array, containing one or * 'gid': its value is encoded as a CBOR array, containing one or
more group identifiers. The exact encoding of the group more group identifiers. The exact encoding of the group
identifier MUST be specified by the application profile (REQ13). identifier MUST be specified by the application profile (REQ13).
The Client indicates that it wishes to receive the group names of The Client indicates that it wishes to receive the group names of
all the groups having these identifiers. all the groups having these identifiers.
The handler identifies the groups where communications are secured by The handler identifies the groups where communications are secured by
using the keying material identified by those group identifiers. using the keying material identified by those group identifiers.
If all verifications succeed, the handler replies with a 2.05 If all verifications succeed, the handler replies with a 2.05
(Content) response, whose payload is formatted as a CBOR map that (Content) response, whose payload is formatted as a CBOR map that
MUST contain the following fields: MUST contain the following fields:
* 'gid', whose value is encoded as a CBOR array, containing zero or * 'gid': its value is encoded as a CBOR array, containing zero or
more group identifiers. The handler indicates that those are the more group identifiers. The handler indicates that those are the
identifiers it is sending group names for. This CBOR array is a identifiers it is sending group names for. This CBOR array is a
subset of the 'gid' array in the FETCH request. subset of the 'gid' array in the FETCH request.
* 'gname', whose value is encoded as a CBOR array, containing zero * 'gname': its value is encoded as a CBOR array, containing zero or
or more group names. The elements of this array are encoded as more group names. The elements of this array are encoded as text
text strings. Each element of index i in this CBOR array is strings. Each element of index i in this CBOR array is associated
associated with the element of index i in the 'gid' array. with the element of index i in the 'gid' array.
* 'guri', whose value is encoded as a CBOR array, containing zero or * 'guri': its value is encoded as a CBOR array, containing zero or
more URIs, each indicating a group-membership resource. The more URIs, each indicating a group-membership resource. The
elements of this array are encoded as text strings. Each element elements of this array are encoded as text strings. Each element
of index i in this CBOR array is associated with the element of of index i in this CBOR array is associated with the element of
index i in the 'gid' array. index i in the 'gid' array.
If the KDC does not find any group associated with the specified If the KDC does not find any group associated with the specified
group identifiers, the handler returns a response with payload group identifiers, the handler returns a response with the payload
formatted as a CBOR byte string of zero length. formatted as a CBOR byte string of zero length (0x40).
Note that the KDC only verifies that the node is authorized by the AS Note that the KDC only verifies that the node is authorized by the AS
to access this resource. Nodes that are not members of the group but to access this resource. Nodes that are not members of the group but
are authorized to do signature verification on the group messages may are authorized to do signature verification on the group messages may
be allowed to access this resource, if the application needs it. be allowed to access this resource if the application needs it.
4.2.1.1. Retrieve Group Names 4.2.1.1. Retrieve Group Names
In case the joining node only knows the group identifier of the group In case the joining node only knows the group identifier of the group
it wishes to join or about which it wishes to get updated information it wishes to join or about which it wishes to get updated information
from the KDC, the node can contact the KDC to request the from the KDC, the node can contact the KDC to request the
corresponding group name and group-membership resource URI. The node corresponding group name and group-membership resource URI. In
can request several group identifiers at once. It does so by sending particular, it does so by sending a CoAP FETCH request to the /ace-
a CoAP FETCH request to the /ace-group endpoint at the KDC formatted group endpoint at the KDC formatted as defined in Section 4.2.1. The
as defined in Section 4.2.1. node can specify several group identifiers at once.
Figure 7 gives an overview of the exchanges described above, and Figure 7 gives an overview of the exchanges described above, and
Figure 8 shows an example. Figure 8 shows an example.
Client KDC Client KDC
| | | |
|------------ Group Name and URI Retrieval Request: -------->| |------------ Group Name and URI Retrieval Request: -------->|
| FETCH /ace-group | | FETCH /ace-group |
| | | |
|<-- Group Name and URI Retrieval Response: 2.05 (Content) --| |<-- Group Name and URI Retrieval Response: 2.05 (Content) --|
| | | |
Figure 7: Message Flow of Group Name and URI Retrieval Request- Figure 7: Message Flow of Group Name and URI Retrieval Request-
Response Response
Request: Request:
Header: FETCH (Code=0.05) Header: FETCH (Code=0.05)
Uri-Host: "kdc.example.com" Uri-Host: "kdc.example.com"
Uri-Path: "ace-group" Uri-Path: "ace-group"
Content-Format: "application/ace-groupcomm+cbor" Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation): Payload (in CBOR diagnostic notation):
{ "gid": [1, 2] } {
/ gid / 0: [1, 2]
}
Response: Response:
Header: Content (Code=2.05) Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor" Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation): Payload (in CBOR diagnostic notation):
{ "gid": [1, 2], "gname": ["group1", "group2"], {
"guri": ["/ace-group/g1", "/ace-group/g2"] } / gid / 0: [1, 2],
/ gname / 1: ["group1", "group2"],
/ guri / 2: ["/ace-group/g1", "/ace-group/g2"]
}
Figure 8: Example of Group Name and URI Retrieval Request-Response Figure 8: Example of Group Name and URI Retrieval Request-Response
4.3. /ace-group/GROUPNAME 4.3. /ace-group/GROUPNAME
This resource implements the POST and GET handlers. This resource implements the POST and GET handlers.
4.3.1. POST Handler 4.3.1. POST Handler
The POST handler processes the Join Request sent by a Client to join The POST handler processes the Join Request sent by a Client to join
a group, and returns a Join Response as successful result of the a group and returns a Join Response as a successful result of the
joining process (see Section 4.3.1.1). At a high level, the POST joining process (see Section 4.3.1.1). At a high level, the POST
handler adds the Client to the list of current group members, adds handler adds the Client to the list of current group members, adds
the authentication credential of the Client to the list of the group the authentication credential of the Client to the list of the group
members' authentication credentials, and returns the symmetric group members' authentication credentials, and returns the symmetric group
keying material for the group identified by GROUPNAME. keying material for the group identified by GROUPNAME.
The handler expects a request with payload formatted as a CBOR map, The handler expects a request with payload formatted as a CBOR map,
which MAY contain the following fields, which, if included, MUST have which MAY contain the following fields, which, if included, MUST have
the format and value as specified below. the format and value as specified below.
* 'scope', with value the specific group that the Client is * 'scope': its value specifies the name of the group that the Client
attempting to join, i.e., the group name, and the roles it wishes is attempting to join and the roles that the client wishes to have
to have in the group. This value is a CBOR byte string wrapping in the group. This value is encoded as a CBOR byte string
one scope entry, as defined in Section 3.1. wrapping one scope entry, as defined in Section 3.1.
* 'get_creds', if the Client wishes to receive the authentication * 'get_creds': it is included if the Client wishes to receive the
credentials of the current group members from the KDC. This authentication credentials of the current group members from the
parameter may be included in the Join Request if the KDC stores KDC. This parameter may be included in the Join Request if the
the authentication credentials of the group members, while it is KDC stores the authentication credentials of the group members,
not useful to include it if the Client obtains those while it is not useful to include it if the Client obtains those
authentication credentials through alternative means, e.g., from authentication credentials through alternative means, e.g., from
the AS. Note that including this parameter might result in a the AS. Note that including this parameter might result in a
following Join Response of large size, which can be inconvenient following Join Response of a large size, which can be inconvenient
for resource-constrained devices. for resource-constrained devices.
If the Client wishes to retrieve the authentication credentials of If the Client wishes to retrieve the authentication credentials of
all the current group members, the 'get_creds' parameter MUST all the current group members, the 'get_creds' parameter MUST
encode the CBOR simple value "null" (0xf6). Otherwise, if the encode the CBOR simple value null (0xf6). Otherwise, if the
Client wishes to retrieve the authentication credentials of nodes Client wishes to retrieve the authentication credentials of nodes
with specific roles, the 'get_creds' parameter MUST encode a non- with specific roles, the 'get_creds' parameter MUST encode a non-
empty CBOR array, containing the three elements 'inclusion_flag', empty CBOR array containing the three elements 'inclusion_flag',
'role_filter', and 'id_filter' as defined below. 'role_filter', and 'id_filter', as defined below.
- The first element, namely 'inclusion_flag', encodes the CBOR - The first element, namely 'inclusion_flag', encodes the CBOR
simple value "true" (0xf5) if the Client wishes to receive the simple value true (0xf5) if the Client wishes to receive the
authentication credentials of the nodes having their node authentication credentials of the nodes having their node
identifier specified in 'id_filter' (i.e., selection by identifier specified in 'id_filter' (i.e., selection by
inclusive filtering). Instead, this element encodes the CBOR inclusive filtering). Instead, this element encodes the CBOR
simple value "false" (0xf4) if the Client wishes to receive the simple value false (0xf4) if the Client wishes to receive the
authentication credentials of the nodes not having the node authentication credentials of the nodes that do not have the
identifiers specified in the third element 'id_filter' (i.e., node identifiers specified in the third element 'id_filter'
selection by exclusive filtering). In the Join Request, this (i.e., selection by exclusive filtering). In the Join Request,
parameter encodes the CBOR simple value "true" (0xf5). this parameter encodes the CBOR simple value true (0xf5).
- The second element, namely 'role_filter', is a CBOR array. - The second element, namely 'role_filter', is a CBOR array.
Each element of the array contains one role or a combination of Each element of the array contains one role or a combination of
roles for the group identified by GROUPNAME. This parameter roles for the group identified by GROUPNAME. This parameter
indicates that the Client wishes to receive the authentication indicates that the Client wishes to receive the authentication
credentials of all the group members having any of the credentials of all the group members having any of the
specified roles or combination of roles (i.e., having any of specified roles or combination of roles (i.e., having any of
those single roles, or at least all the roles indicated in any those single roles or at least all the roles indicated in any
of those combinations of roles). of those combinations of roles).
For example, the array ["role1", "role2+role3"] indicates that For example, the array ["role1", "role2+role3"] indicates that
the Client wishes to receive the authentication credentials of the Client wishes to receive the authentication credentials of
all group members that have at least "role1" or at least both all group members that have at least "role1" or at least both
"role2" and "role3". In the Join Request this parameter is a "role2" and "role3". In the Join Request, this parameter is a
non-empty array. non-empty array.
- The third element, namely 'id_filter', is a CBOR array. Each - The third element, namely 'id_filter', is a CBOR array. Each
element of the array contains a node identifier of a group element of the array contains a node identifier of a group
member for the group identified by GROUPNAME. This parameter member for the group identified by GROUPNAME. This parameter
indicates that the Client wishes to receive the authentication indicates that the Client wishes to receive the authentication
credentials of the nodes that have or do not have the specified credentials of the nodes that have or do not have the specified
node identifiers, based on the value of 'inclusion_flag' (i.e., node identifiers based on the value of 'inclusion_flag' (i.e.,
as a selection by inclusive or exclusive filtering). In the as a selection by inclusive or exclusive filtering). In the
Join Request, the Client does not filter authentication Join Request, the Client does not filter authentication
credentials based on node identifiers, so this parameter is an credentials based on node identifiers, so this parameter is an
empty array. empty array.
In fact, when first joining the group, the Client is not In fact, when first joining the group, the Client is not
expected or capable to express a filter based on node expected or capable to express a filter based on node
identifiers of other group members. Instead, when already a identifiers of other group members. Instead, when already a
group member and sending a Join Request to re-join, the Client group member and sending a Join Request to rejoin, the Client
is not expected to include the 'get_creds' parameter in the is not expected to include the 'get_creds' parameter in the
Join Request altogether, since it can rather retrieve Join Request altogether, since it can rather retrieve
authentication credentials associated with specific group authentication credentials associated with specific group
identifiers as defined in Section 4.4.1.1. identifiers as defined in Section 4.4.1.1.
The CDDL definition [RFC8610] of 'get_creds' is given in Figure 9, The CDDL definition [RFC8610] of 'get_creds' is given in Figure 9;
using as example encoding: node identifier encoded as a CBOR byte as an example, it uses node identifiers encoded as CBOR byte
string; role identifier encoded as a CBOR text string, and strings, role identifiers encoded as CBOR text strings, and
combination of roles encoded as a CBOR array of roles. combinations of roles encoded as CBOR arrays of role identifiers.
Note that, for this handler, 'inclusion_flag' is always set to Note that, for this handler, 'inclusion_flag' is always set to
true, the array of roles 'role_filter' is always non-empty, while true and the array of roles 'role_filter' is always non-empty,
the array of node identifiers 'id_filter' is always empty. while the array of node identifiers 'id_filter' is always empty.
However, this is not necessarily the case for other handlers using However, this is not necessarily the case for other handlers using
the 'get_creds' parameter. the 'get_creds' parameter.
inclusion_flag = bool inclusion_flag = bool
role = tstr role = tstr
comb_role = [ 2*role ] comb_role = [2* role]
role_filter = [ *(role / comb_role) ] role_filter = [* ( role / comb_role )]
id = bstr id = bstr
id_filter = [ *id ] id_filter = [* id]
get_creds = null / [ inclusion_flag, role_filter, id_filter] get_creds = null / [inclusion_flag, role_filter, id_filter]
Figure 9: CDDL definition of 'get_creds', using as example node
identifier encoded as bstr and role as tstr
* 'client_cred', encoded as a CBOR byte string, whose value is the Figure 9: CDDL Definition of 'get_creds', Using an Example
Node Identifier Encoded as bstr and Role as tstr
* 'client_cred': encoded as a CBOR byte string, whose value is the
original binary representation of the Client's authentication original binary representation of the Client's authentication
credential. This parameter MUST be present if the KDC is managing credential. This parameter MUST be present if the KDC is managing
(collecting from/distributing to the Client) the authentication (collecting from and distributing to Clients) the authentication
credentials of the group members and the Client's role in the credentials of the group members and the Client's role in the
group will require the Client to send messages to one or more group will require the Client to send messages to one or more
group members. It is REQUIRED of application profiles to define group members. It is REQUIRED for application profiles to define
the specific formats that are acceptable to use for authentication the specific formats that are acceptable to use for authentication
credentials in the group (REQ6). credentials in the group (REQ6).
* 'cnonce', encoded as a CBOR byte string, and including a dedicated * 'cnonce': encoded as a CBOR byte string, whose value is a
nonce N_C generated by the Client. This parameter MUST be dedicated nonce N_C generated by the Client. This parameter MUST
present. be present.
* 'client_cred_verify', encoded as a CBOR byte string. This * 'client_cred_verify': encoded as a CBOR byte string. This
parameter MUST be present if the 'client_cred' parameter is parameter MUST be present if the 'client_cred' parameter is
present and no authentication credential associated with the present and no authentication credential associated with the
Client's token can be retrieved for that group. Client's access token can be retrieved for that group.
This parameter contains a proof-of-possession (PoP) evidence The value of the CBOR byte string is the proof-of-possession (PoP)
computed by the Client over the following PoP input: the scope evidence computed by the Client over the following PoP input: the
(encoded as a CBOR byte string), concatenated with N_S (encoded as scope (encoded as a CBOR byte string) concatenated with N_S
a CBOR byte string) concatenated with N_C (encoded as a CBOR byte (encoded as a CBOR byte string) concatenated with N_C (encoded as
string), where: a CBOR byte string), where:
- scope is the CBOR byte string either specified in the 'scope' - scope is either specified in the 'scope' parameter above, if
parameter above, if present, or encoding a default scope entry present, or a default scope entry that the handler is expected
that the handler is expected to know, if omitted. to know otherwise;
- N_S is the challenge received from the KDC in the - N_S is the challenge received from the KDC in the
'kdcchallenge' parameter of the 2.01 (Created) response to the 'kdcchallenge' parameter of the 2.01 (Created) response to the
Token Transfer Request (see Section 3.3), encoded as a CBOR Token Transfer Request (see Section 3.3), encoded as a CBOR
byte string. byte string; and
- N_C is the nonce generated by the Client and specified in the - N_C is the nonce generated by the Client and specified in the
'cnonce' parameter above, encoded as a CBOR byte string. 'cnonce' parameter above, encoded as a CBOR byte string.
An example of PoP input to compute 'client_cred_verify' using CBOR An example of PoP input to compute 'client_cred_verify' using CBOR
encoding is given in Figure 10. encoding is given in Figure 10.
A possible type of PoP evidence is a signature that the Client A possible type of PoP evidence is a signature that the Client
computes by using its own private key, whose corresponding public computes by using its own private key, whose corresponding public
key is specified in the authentication credential carried in the key is specified in the authentication credential carried in the
'client_cred' parameter. Application profiles of this 'client_cred' parameter. Application profiles of this
specification MUST specify the exact approaches used to compute specification MUST specify the exact approaches used to compute
the PoP evidence to include in 'client_cred_verify', and MUST the PoP evidence to include in 'client_cred_verify' and MUST
specify which of those approaches is used in which case (REQ14). specify which of those approaches is used in which case (REQ14).
If the token was not provided to the KDC through a Token Transfer If the access token was not provided to the KDC through a Token
Request (e.g., it is used directly to validate TLS instead), it is Transfer Request (e.g., the access token is instead transferred
REQUIRED of the specific application profile to define how the during the establishment of a secure communication association),
challenge N_S is generated (REQ15). it is REQUIRED of the specific application profile to define how
the challenge N_S is generated (REQ15).
* 'creds_repo', which can be present if the format of the Client's * 'creds_repo': it can be present if the format of the Client's
authentication credential in the 'client_cred' parameter is a authentication credential conveyed in the 'client_cred' parameter
certificate. In such a case, this parameter has as value the URI is a certificate. In such a case, this parameter has as its value
of the certificate. This parameter is encoded as a CBOR text the URI of the certificate. This parameter is encoded as a CBOR
string. Alternative specific encodings of this parameter MAY be text string. Alternative specific encodings of this parameter MAY
defined in application profiles of this specification (OPT6). be defined in application profiles of this specification (OPT6).
* 'control_uri', whose value is a full URI, encoded as a CBOR text * 'control_uri': its value is a full URI, encoded as a CBOR text
string. A default url-path is /ace-group/GROUPNAME/node, although string. A default url-path is /ace-group/GROUPNAME/node, although
implementations can use different ones instead. The URI MUST NOT implementations can use different ones instead. The URI MUST NOT
have url-path /ace-group/GROUPNAME. have url-path /ace-group/GROUPNAME.
If 'control_uri' is specified in the Join Request, the Client acts If 'control_uri' is specified in the Join Request, the Client acts
as a CoAP server and hosts a resource at this specific URI. The as a CoAP server and hosts a resource at this specific URI. The
KDC MAY use this URI to send CoAP requests to the Client (acting KDC MAY use this URI to send CoAP requests to the Client (acting
as CoAP server in this exchange), for example for one-to-one as a CoAP server in this exchange), for example, for one-to-one
provisioning of new group keying material when performing a group provisioning of new group keying material when performing a group
rekeying (see Section 4.8.1.1), or to inform the Client of its rekeying (see Section 6.1) or to inform the Client of its removal
removal from the group (see Section 5). from the group (see Section 5).
In particular, this resource is intended for communications In particular, this resource is intended for communications
concerning exclusively the group identified by GROUPNAME and whose exclusively concerning the group identified by GROUPNAME and whose
group name is specified in the 'scope' parameter, if present. If group name is specified in the 'scope' parameter of the Join
the KDC does not implement mechanisms using this resource for that Request, if present therein. If the KDC does not implement
group, it can ignore this parameter. Other additional mechanisms using this resource for that group, it can ignore this
functionalities of this resource MAY be defined in application parameter. Other additional functionalities of this resource MAY
profiles of this specifications (OPT7). be defined in application profiles of this specifications (OPT7).
scope, N_S, and N_C expressed in CBOR diagnostic notation: scope, N_S, and N_C expressed in CBOR diagnostic notation:
scope = h'826667726f7570316673656e646572' scope = h'826667726f7570316673656e646572'
N_S = h'018a278f7faab55a' N_S = h'018a278f7faab55a'
N_C = h'25a8991cd700ac01' N_C = h'25a8991cd700ac01'
scope, N_S, and N_C as CBOR encoded byte strings: scope, N_S, and N_C as CBOR encoded byte strings:
scope = 0x4f826667726f7570316673656e646572 scope = 0x4f826667726f7570316673656e646572
N_S = 0x48018a278f7faab55a N_S = 0x48018a278f7faab55a
N_C = 0x4825a8991cd700ac01 N_C = 0x4825a8991cd700ac01
PoP input: PoP input:
0x4f 826667726f7570316673656e646572 0x4f 826667726f7570316673656e646572
48 018a278f7faab55a 48 25a8991cd700ac01 48 018a278f7faab55a 48 25a8991cd700ac01
Figure 10: Example of PoP input to compute 'client_cred_verify' Figure 10: Example of PoP Input to Compute 'client_cred_verify'
using CBOR encoding Using CBOR Encoding
If the request does not include a 'scope' field, the KDC is expected If the request does not include the 'scope' parameter, the KDC is
to understand what roles the Client is requesting to join the group expected to understand what roles the Client is requesting to join
with. For example, as per the access token, the Client might have the group with. For example, as per the access token, the Client
been granted access to the group with only one role. If the KDC might have been granted access to the group with only one role. If
cannot determine which exact roles should be considered for the the KDC cannot determine which exact roles should be considered for
Client, it MUST reply with a 4.00 (Bad Request) error response. the Client, it MUST reply with a 4.00 (Bad Request) error response.
The handler considers the scope specified in the access token The handler considers the scope specified in the access token
associated with the Client, and checks the scope entry related to the associated with the Client and checks the scope entry related to the
group identified by the GROUPNAME associated with the endpoint. In group identified by the GROUPNAME associated with the endpoint. In
particular, the handler checks whether the set of roles specified in particular, the handler checks whether the set of roles specified in
that scope entry includes all the roles that the Client wishes to that scope entry includes all the roles that the Client wishes to
have in the group as per the Join Request. If this is not the case, have in the group as per the Join Request. If this is not the case,
the KDC MUST reply with a 4.03 (Forbidden) error response. the KDC MUST reply with a 4.03 (Forbidden) error response.
If the KDC manages the group members' authentication credentials, the If the KDC manages the group members' authentication credentials, the
handler checks if one is included in the 'client_cred' field. If so, handler checks if one is included in the 'client_cred' parameter. If
the KDC retrieves the authentication credential and performs the so, the KDC retrieves the authentication credential and performs the
following actions. following actions.
* If the access token was provided through a Token Transfer Request * If the access token was provided through a Token Transfer Request
(see Section 3.3) but the KDC cannot retrieve the 'kdcchallenge' (see Section 3.3) but the KDC cannot retrieve the 'kdcchallenge'
associated with this Client (see Section 3.3), the KDC MUST reply associated with this Client (see Section 3.3), the KDC MUST reply
with a 4.00 (Bad Request) error response, which MUST also have with a 4.00 (Bad Request) error response, which MUST also have
Content-Format application/ace-groupcomm+cbor. The payload of the Content-Format "application/ace-groupcomm+cbor". The payload of
error response is a CBOR map including a newly generated the error response is a CBOR map including a newly generated
'kdcchallenge' value, which is specified in the 'kdcchallenge' 'kdcchallenge' value, which is specified in the 'kdcchallenge'
parameter. The KDC MUST store the newly generated value as the parameter. The KDC MUST store the newly generated value as the
'kdcchallenge' value associated with this Client, replacing the 'kdcchallenge' value associated with this Client, replacing the
currently stored value (if any). currently stored value (if any).
* The KDC checks the authentication credential to be valid for the * The KDC checks the authentication credential to be valid for the
group identified by GROUPNAME. That is, it checks that the group identified by GROUPNAME. That is, it checks that the
authentication credential has the format used in the group, is authentication credential has the format used in the group, is
intended for the public key algorithm used in the group, and is intended for the public key algorithm used in the group, and is
aligned with the possible associated parameters used in the group. aligned with the possible associated parameters used in the group.
If this verification fails, the handler MUST reply with a 4.00 If this verification fails, the handler MUST reply with a 4.00
(Bad Request) error response. The response MUST have Content- (Bad Request) error response. The response MUST have Content-
Format set to application/concise-problem-details+cbor and is Format "application/concise-problem-details+cbor" and is formatted
formatted as defined in Section 4.1.2. Within the Custom Problem as defined in Section 4.1.2. Within the Custom Problem Detail
Detail entry 'ace-groupcomm-error', the value of the 'error-id' entry 'ace-groupcomm-error', the value of the 'error-id' field
field MUST be set to 2 ("Authentication credential incompatible MUST be set to 2 ("Authentication credential incompatible with the
with the group configuration"). group configuration").
* The KDC verifies the PoP evidence contained in the * The KDC verifies the PoP evidence conveyed in the
'client_cred_verify' field. Application profiles of this 'client_cred_verify' parameter. Application profiles of this
specification MUST specify the exact approaches used to verify the specification MUST specify the exact approaches used to verify the
PoP evidence, and MUST specify which of those approaches is used PoP evidence and MUST specify which of those approaches is used in
in which case (REQ14). which case (REQ14).
If the PoP evidence does not pass verification, the handler MUST If the PoP evidence does not pass verification, the handler MUST
reply with a 4.00 (Bad Request) error response. The response MUST reply with a 4.00 (Bad Request) error response. The response MUST
have Content-Format set to application/concise-problem- have Content-Format "application/concise-problem-details+cbor" and
details+cbor and is formatted as defined in Section 4.1.2. Within is formatted as defined in Section 4.1.2. Within the Custom
the Custom Problem Detail entry 'ace-groupcomm-error', the value Problem Detail entry 'ace-groupcomm-error', the value of the
of the 'error-id' field MUST be set to 3 ("Invalid Proof-of- 'error-id' field MUST be set to 3 ("Invalid proof-of-possession
Possession evidence"). evidence").
If no authentication credential is included in the 'client_cred' If no authentication credential is conveyed in the 'client_cred'
field, the handler checks if an authentication credential is already parameter, the handler checks if the KDC currently stores an
associated with the received access token and to the group identified authentication credential that is associated with the access token
by GROUPNAME (see also Section 4.3.1.1). Note that the same joining and with the group identified by GROUPNAME (see also
node may use different authentication credentials in different Section 4.3.1.1). Note that the same joining node may use different
groups, and all those authentication credentials would be associated authentication credentials in different groups, and all those
with the same access token. authentication credentials would be associated with the same access
token.
If an eligible authentication credential for the Client is neither If an eligible authentication credential for the Client is neither
present in the 'client_cred' field nor retrieved from the stored ones present in the 'client_cred' parameter nor retrieved from the stored
at the KDC, it is RECOMMENDED that the handler stops the processing ones at the KDC, it is RECOMMENDED that the handler stops the
and replies with a 4.00 (Bad Request) error response. Application processing and replies with a 4.00 (Bad Request) error response.
profiles MAY define alternatives (OPT8). Application profiles MAY define alternatives (OPT8).
If, regardless of the reason, the KDC replies with a 4.00 (Bad If, regardless of the reason, the KDC replies with a 4.00 (Bad
Request) error response, the payload of the response MAY be a CBOR Request) error response, the payload of the response MAY be a CBOR
map. For instance, the CBOR map can include a 'sign_info' parameter map. For instance, the CBOR map can include a 'sign_info' parameter
formatted as 'sign_info_res' defined in Section 3.3.1, with the formatted as 'sign_info_resp' defined in Section 3.3.1, with the
'cred_fmt' element set to the CBOR simple value "null" (0xf6) if the 'cred_fmt' element set to the CBOR simple value null (0xf6) if the
Client sent its own authentication credential and the KDC is not set Client sent its own authentication credential and the KDC is not set
to store authentication credentials of the group members. When the to store authentication credentials of the group members. When the
response payload is a CBOR map including such parameters, the error response payload is a CBOR map including such parameters, the error
response has Content-Format set to application/ace-groupcomm+cbor. response has Content-Format "application/ace-groupcomm+cbor".
If all the verifications above succeed, the KDC proceeds as follows. If all the verifications above succeed, the KDC proceeds as follows.
First, only in case the Client is not already a group member, the First, only in case the Client is not already a group member, the
handler performs the following actions: handler performs the following actions:
* The handler adds the Client to the list of current members of the * The handler adds the Client to the list of current members of the
group. group.
* The handler assigns a name NODENAME to the Client, and creates a * The handler assigns a name NODENAME to the Client and creates a
sub-resource to /ace-group/GROUPNAME at the KDC, i.e., "/ace- sub-resource to /ace-group/GROUPNAME at the KDC, i.e., /ace-
group/GROUPNAME/nodes/NODENAME". group/GROUPNAME/nodes/NODENAME.
* The handler associates the node identifier NODENAME with the * The handler associates the node identifier NODENAME with the
access token and the secure communication association for the access token and the secure communication association for the
Client. Client.
Then, the handler performs the following actions. Then, the handler performs the following actions.
* If the KDC manages the group members' authentication credentials: * If the KDC manages the group members' authentication credentials:
- The handler associates the retrieved Client's authentication - The handler associates the retrieved Client's authentication
credential to the tuple composed of the node name NODENAME, the credential with the tuple composed of the node name NODENAME,
group name GROUPNAME, and the received access token. the group name GROUPNAME, and the access token.
- The handler adds the retrieved Client's authentication - The handler adds the retrieved Client's authentication
credential to the stored list of authentication credentials credential to the list of authentication credentials stored for
stored for the group identified by GROUPNAME. If such list the group identified by GROUPNAME. If such a list already
already includes an authentication credential for the Client, includes an authentication credential for the Client, but a
but a different authentication credential is specified in the different authentication credential is specified in the
'client_cred' field, then the handler MUST replace the old 'client_cred' parameter, then the handler MUST replace the old
authentication credential in the list with the one specified in authentication credential in the list with the one specified in
the 'client_cred' field. the 'client_cred' parameter.
* If backward security is prescribed by application policies * If backward security is prescribed by application policies
installed at the KDC or by the used application profile of this installed at the KDC or by the used application profile of this
specification, then the KDC MUST generate new group keying specification, then the KDC MUST generate new group keying
material and securely distribute it to the current group members material and securely distribute it to the current group members
(see Section 6). (see Section 6).
* The handler returns a successful Join Response as defined below, * The handler returns a successful Join Response, as defined below,
containing the symmetric group keying material; the group which contains the symmetric group keying material, the group
policies; and the authentication credentials of the current policies, and the authentication credentials of the current
members of the group, if the KDC manages those and the Client members of the group if the KDC manages those and the Client
requested them. requested those.
The Join Response MUST have response code 2.01 (Created) if the The Join Response MUST have response code 2.01 (Created) if the
Client has been added to the list of group members in this join Client has been added to the list of group members in this join
exchange (see above), or 2.04 (Changed) otherwise, i.e., if the exchange (see above) or 2.04 (Changed) otherwise, i.e., if the Client
Client is re-joining the group without having left it. is rejoining the group without having left it.
The Join Response message MUST include the Location-Path CoAP option, The Join Response message MUST include the Location-Path CoAP
specifying the URI path to the sub-resource associated with the Options, specifying the path to the sub-resource associated with the
Client, i.e., "/ace-group/GROUPNAME/nodes/NODENAME". Client, i.e., /ace-group/GROUPNAME/nodes/NODENAME.
The Join Response message MUST have Content-Format application/ace- The Join Response message MUST have Content-Format "application/ace-
groupcomm+cbor. The payload of the response is formatted as a CBOR groupcomm+cbor". The payload of the response is formatted as a CBOR
map, which MUST contain the following fields and values. map, which MUST contain the following fields with the values
specified below:
* 'gkty', identifying the key type of the keying material specified * 'gkty': identifying the key type of the keying material specified
in the 'key' parameter. This parameter is encoded as a CBOR in the 'key' parameter. This parameter is encoded as a CBOR
integer or a CBOR text string. The set of values can be found in integer or a CBOR text string. Possible values are taken from the
the "Key Type" column of the "ACE Groupcomm Key Types" registry. "Key Type Value" column of the "ACE Groupcomm Key Types" registry
Implementations MUST verify that the key type matches the defined in Section 11.8 of this specification. Implementations
application profile being used, if present, as registered in the MUST verify that the key type specified by this parameter matches
"ACE Groupcomm Key Types" registry. the application profile being used and, if applicable, that such
an application profile is listed in the "Profile" column of the
* 'key', containing the keying material for the group communication, "ACE Groupcomm Key Types" registry for the key type in question.
or information required to derive it.
* 'num', containing the version number of the keying material for * 'key': containing the keying material used for securing the group
the group communication, formatted as a CBOR integer. This is a communication or information required to derive such keying
strictly monotonic increasing field. The application profile MUST material.
define the initial version number (REQ16).
The exact type of the keying material specified in the 'key' * 'num': containing the current version number of the group keying
parameter MUST be defined in application profiles of this material, encoded as a CBOR integer. The version number has a
specification (REQ17), together with values of 'gkty' accepted by the value that increases in a strictly monotonic way as the group
application (REQ18). Additionally, documents specifying a type of keying material changes. The application profile MUST define the
keying material MUST register an entry in the "ACE Groupcomm Key initial value of the version number (REQ16).
Types" registry defined in Section 11.8, including its name, the
corresponding value for the 'gkty parameter', and the application
profile to be used with.
+----------+----------------+---------+-------------+------------+ The format of the keying material conveyed in the 'key' parameter
| Name | Key Type Value | Profile | Description | Reference | MUST be defined in application profiles of this specification
+----------+----------------+---------+-------------+------------+ (REQ17), together with corresponding key types to specify as value of
| Reserved | 0 | | This value | [RFC-XXXX] | the 'gkty' parameter and that are accepted by the application
| | | | is reserved | | (REQ18). Additionally, documents specifying a type of keying
+----------+----------------+---------+-------------+------------+ material MUST register an entry in the "ACE Groupcomm Key Types"
registry defined in Section 11.8, including its name, the
corresponding key type to specify as value for the 'gkty' parameter,
and the application profile to be used with.
Figure 11: ACE Groupcomm Key Types +==========+================+=========+=============+===========+
| Name | Key Type Value | Profile | Description | Reference |
+==========+================+=========+=============+===========+
| Reserved | 0 | | This value | RFC 9594 |
| | | | is reserved | |
+----------+----------------+---------+-------------+-----------+
Note to RFC Editor: In Figure 11, please replace "[RFC-XXXX]" with Table 1: ACE Groupcomm Key Types
the RFC number of this specification and delete this paragraph.
The Join Response SHOULD contain the following parameters: The Join Response SHOULD contain the following fields with the values
specified below:
* 'exp', with value the expiration time of the keying material for * 'exp': its value specifies the expiration time of the group keying
the group communication, encoded as a CBOR unsigned integer. This material specified in the 'key' parameter, encoded as a CBOR
field contains a numeric value representing the number of seconds unsigned integer. The value is the number of seconds from
from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, 1970-01-01T00:00:00Z UTC until the specified UTC date/time,
ignoring leap seconds, analogous to what is specified for ignoring leap seconds, analogous to what is specified for
NumericDate in Section 2 of [RFC7519]. Group members MUST NOT use NumericDate in Section 2 of [RFC7519]. After the time indicated
the keying material after the time indicated in this field, and in this parameter, group members MUST NOT use the group keying
they can retrieve the new group keying material from the KDC. material specified in the 'key' parameter. The group members can
retrieve the latest group keying material from the KDC.
* 'exi', with value the residual lifetime of the keying material for * 'exi': its value specifies the residual lifetime of the group
the group communication, encoded as a CBOR unsigned integer. If keying material, encoded as a CBOR unsigned integer. If the 'exp'
the 'exp' parameter is included, this parameter MUST also be parameter is included, this parameter MUST also be included. The
included. This field contains a numeric value representing the value represents the residual lifetime of the group keying
residual lifetime of the keying material in seconds, i.e., the material specified in the 'key' parameter, i.e., it is the number
number of seconds between the current time at the KDC and the time of seconds between the current time at the KDC and the time when
when the keying material expires (as specified in the 'exp' the keying material expires (as specified in the 'exp' parameter,
parameter, if present). A Client determines the expiration time if present). A Client determines the expiration time of the
of the keying material by adding the seconds specified in the keying material by adding the seconds specified in the 'exi'
'exi' parameter to its current time upon receiving the response parameter to its current time upon receiving the Join Response
containing the 'exi' parameter. The Client MUST NOT use the containing the 'exi' parameter. After such an expiration time,
keying material after such an expiration time, and it can retrieve the Client MUST NOT use the group keying material specified in the
the new group keying material from the KDC. 'key' parameter. The Client can retrieve the latest group keying
material from the KDC.
If a Client has a reliable way to synchronize its internal clock with If a Client has a reliable way to synchronize its internal clock with
UTC, and both the 'exp' and 'exi' parameters are present, then the UTC, and both the 'exp' and 'exi' parameters are present, then the
Client MUST use the 'exp' parameter value as expiration time for the Client MUST use the 'exp' parameter value as expiration time for the
group keying material. Otherwise, the Client uses the 'exi' group keying material. Otherwise, the Client uses the 'exi'
parameter value. parameter value to determine the expiration time as defined above.
When a Client relies on the 'exi' parameter, the expiration time that When a Client relies on the 'exi' parameter, the expiration time that
it computes is offset in the future with respect to the actual it computes is offset in the future with respect to the actual
expiration time as intended by the KDC and specified in the 'exp' expiration time as intended by the KDC and specified in the 'exp'
parameter (if present). Such an offset is the amount of time between parameter (if present). Such an offset is the amount of time between
when the KDC sends the response message including the 'exi' parameter when the KDC sends the response message including the 'exi' parameter
and when the Client receives that message. That is, especially if and when the Client receives that message. That is, especially if
the delivery of the response to the Client is delayed, the Client the delivery of the response to the Client is delayed, the Client
will believe the keying material to be valid for a longer time than will believe the keying material to be valid for a longer time than
the KDC actually means. However, before approaching the actual the KDC actually means. However, before approaching the actual
expiration time, the KDC is expected to rekey the group and expiration time, the KDC is expected to rekey the group and
distribute new keying material (see Section 6). distribute new keying material (see Section 6).
Optionally, the Join Response MAY contain the following parameters, Optionally, the Join Response MAY contain the following parameters,
which, if included, MUST have the format and value as specified which, if included, MUST have the format and value as specified
below. below.
* 'ace_groupcomm_profile', with value a CBOR integer that MUST be * 'ace_groupcomm_profile': its value is encoded as a CBOR integer
used to uniquely identify the application profile for group and MUST be used to uniquely identify the application profile for
communication. Applications of this specification MUST register group communication. Applications of this specification MUST
an application profile identifier and the related value for this register an application profile identifier and the related value
parameter in the "ACE Groupcomm Profiles" registry (REQ19). for this parameter in the "ACE Groupcomm Profiles" registry
(REQ19).
+----------+------------------------+------------+------------+
| Name | Description | CBOR Value | Reference |
+----------+------------------------+------------+------------+
| Reserved | This value is reserved | 0 | [RFC-XXXX] |
+----------+------------------------+------------+------------+
Figure 12: ACE Groupcomm Profiles +==========+========================+============+===========+
| Name | Description | CBOR Value | Reference |
+==========+========================+============+===========+
| Reserved | This value is reserved | 0 | RFC 9594 |
+----------+------------------------+------------+-----------+
Note to RFC Editor: In Figure 12, please replace "[RFC-XXXX]" with Table 2: ACE Groupcomm Profiles
the RFC number of this specification and delete this paragraph.
* 'creds', which MUST be present if 'get_creds' was present in the * 'creds': it MUST be present if 'get_creds' was present in the Join
request, otherwise it MUST NOT be present. This parameter is a Request; otherwise, it MUST NOT be present. Its value is encoded
CBOR array specifying the authentication credentials of the group as a CBOR array specifying the authentication credentials of the
members, i.e., of all of them or of the ones selected according to group members, i.e., of all of them or of the ones selected
the 'get_creds' parameter in the request. In particular, each according to the 'get_creds' parameter in the Join Request. In
element of the array is a CBOR byte string, whose value is the particular, each element of the array is a CBOR byte string, whose
original binary representation of a group member's authentication value is the original binary representation of a group member's
credential. It is REQUIRED of application profiles to define the authentication credential. It is REQUIRED for application
specific formats of authentication credentials that are acceptable profiles to define the specific formats of authentication
to use in the group (REQ6). credentials that are acceptable to use in the group (REQ6).
* 'peer_roles', which SHOULD be present if 'creds' is also present, * 'peer_roles': it SHOULD be present if 'creds' is also present;
otherwise it MUST NOT be present. This parameter is a CBOR array otherwise, it MUST NOT be present. Its value is encoded as a CBOR
of n elements, where n is the number of authentication credentials array of n elements, where n is the number of authentication
included in the 'creds' parameter (at most the number of members credentials included in the 'creds' parameter (at most, the number
in the group). The i-th element of the array specifies the of members in the group). The i-th element of the array specifies
role(s) that the group member associated with the i-th the role(s) that the group member associated with the i-th
authentication credential in 'creds' has in the group. In authentication credential in 'creds' has in the group. In
particular, each array element is encoded like the role element of particular, each array element is encoded like the role element of
a scope entry, consistent with the used format (see Section 3.1). a scope entry, which is consistent with the used format (see
Section 3.1).
This parameter MAY be omitted if the Client can rely on other This parameter MAY be omitted if the Client can rely on other
means to unambiguously gain knowledge of the role of each group means to unambiguously gain knowledge of the role of each group
member whose associated authentication credential is specified in member whose associated authentication credential is specified in
the 'creds' parameter. For example, all such group members may the 'creds' parameter. For example, all such group members may
have the same role in the group joined by the Client, and such a have the same role in the group joined by the Client, and such a
role can be unambiguously assumed by the Client (e.g., based on role can be unambiguously assumed by the Client (e.g., based on
what is defined in the used application profile of this what is defined in the used application profile of this
specification). As another example, each of the authentication specification). As another example, each of the authentication
credentials specified in the 'creds' parameter can indicate the credentials specified in the 'creds' parameter can indicate the
role(s) that the corresponding group member has in the group role(s) that the corresponding group member has in the group
joined by the Client. joined by the Client.
When receiving the authentication credential of a Client in the When receiving the authentication credential of a Client in the
'client_cred' parameter of a Join Request (see Section 4.3.1.1) or 'client_cred' parameter of a Join Request (see Section 4.3.1.1) or
of an Authentication Credential Update Request (see of an Authentication Credential Update Request (see
Section 4.9.1.1), the KDC is not expected to check that the Section 4.9.1.1), the KDC is not expected to check that the
authentication credential indicates the role(s) that the Client authentication credential indicates the role(s) that the Client
can have or has in the group in question. When preparing a Join can have or has in the group in question. When preparing a Join
Response, the KDC can decide whether to include the 'peer_roles' Response, the KDC can decide whether to include the 'peer_roles'
parameter depending on the specific set of authentication parameter, depending on the specific set of authentication
credentials specified in the 'creds' parameter of that Join credentials specified in the 'creds' parameter of that Join
Response. Response.
* 'peer_identifiers', which MUST be present if 'creds' is also * 'peer_identifiers': it MUST be present if 'creds' is also present;
present, otherwise it MUST NOT be present. This parameter is a otherwise, it MUST NOT be present. Its value is encoded as a CBOR
CBOR array of n elements, where n is the number of authentication array of n elements, where n is the number of authentication
credentials included in the 'creds' parameter (at most the number credentials included in the 'creds' parameter (at most, the number
of members in the group). The i-th element of the array specifies of members in the group). The i-th element of the array specifies
the node identifier that the group member associated with the i-th the node identifier that the group member associated with the i-th
authentication credential in 'creds' has in the group. In authentication credential in 'creds' has in the group. In
particular, the i-th array element is encoded as a CBOR byte particular, the i-th array element is encoded as a CBOR byte
string, whose value is the node identifier of the group member. string, whose value is the node identifier of the group member.
The specific format of node identifiers of group members is The specific format of node identifiers of group members is
specified by the application profile (REQ25). specified by the application profile (REQ25).
* 'group_policies', with value a CBOR map, whose entries specify how * 'group_policies': its value is encoded as a CBOR map, whose
the group handles specific management aspects. These include, for elements specify how the group handles specific management
instance, approaches to achieve synchronization of sequence aspects. These include, for instance, approaches to achieve
numbers among group members. The elements of this field are synchronization of sequence numbers among group members. The
registered in the "ACE Groupcomm Policies" registry. This possible elements of the CBOR map are registered in the "ACE
specification defines the three elements "Sequence Number Groupcomm Policies" registry defined in Section 11.10 of this
Synchronization Methods", "Key Update Check Interval", and specification. This specification defines the three elements
"Expiration Delta", which are summarized in Figure 13. "Sequence Number Synchronization Methods", "Key Update Check
Application profiles that build on this document MUST specify the Interval", and "Expiration Delta", which are summarized in
exact content format and default value of included map entries Table 3. Application profiles of this specification MUST specify
(REQ20). the format and default values for the entries of the CBOR map
conveyed in the 'group_policies' parameter (REQ20).
+--------------+-------+----------+----------------------+------------+
| Name | CBOR | CBOR | Description | Reference |
| | label | type | | |
+--------------+-------+----------+----------------------+------------+
| Sequence | 0 | tstr/int | Method for recipient | [RFC-XXXX] |
| Number | | | group members to | |
| Synchroniza- | | | synchronize with | |
| tion Method | | | sequence numbers of | |
| | | | sender group | |
| | | | members. Its value | |
| | | | is taken from the | |
| | | | 'Value' column of | |
| | | | the Sequence Number | |
| | | | Synchronization | |
| | | | Method registry | |
+--------------+-------+----------+----------------------+------------+
| Key Update | 1 | int | Polling interval in | [RFC-XXXX] |
| Check | | | seconds, for group | |
| Interval | | | members to check at | |
| | | | the KDC if the | |
| | | | latest group keying | |
| | | | material is the one | |
| | | | that they store | |
+--------------+-------+----------+----------------------+------------+
| Expiration | 2 | uint | Number of seconds | [RFC-XXXX] |
| Delta | | | from 'exp' until a | |
| | | | UTC date/time, after | |
| | | | which group members | |
| | | | MUST stop using the | |
| | | | group keying | |
| | | | material that they | |
| | | | store to decrypt | |
| | | | incoming messages | |
+--------------+-------+----------|----------------------|------------+
Figure 13: ACE Groupcomm Policies +=================+=======+======+===================+===========+
| Name | CBOR | CBOR | Description | Reference |
| | Label | Type | | |
+=================+=======+======+===================+===========+
| Sequence Number | 0 | int | Method for | RFC 9594 |
| Synchronization | | or | recipient group | |
| Method | | tstr | members to | |
| | | | synchronize with | |
| | | | sequence numbers | |
| | | | of sender group | |
| | | | members. Its | |
| | | | value is taken | |
| | | | from the "Value" | |
| | | | column of the | |
| | | | "Sequence Number | |
| | | | Synchronization | |
| | | | Method" | |
| | | | registry. | |
+-----------------+-------+------+-------------------+-----------+
| Key Update | 1 | int | Polling interval | RFC 9594 |
| Check Interval | | | in seconds, for | |
| | | | group members to | |
| | | | check at the KDC | |
| | | | if the latest | |
| | | | group keying | |
| | | | material is the | |
| | | | one that they | |
| | | | store. | |
+-----------------+-------+------+-------------------+-----------+
| Expiration | 2 | uint | Number of | RFC 9594 |
| Delta | | | seconds from | |
| | | | 'exp' until a | |
| | | | UTC date/time, | |
| | | | after which | |
| | | | group members | |
| | | | MUST stop using | |
| | | | the group keying | |
| | | | material that | |
| | | | they store to | |
| | | | decrypt incoming | |
| | | | messages. | |
+-----------------+-------+------+-------------------+-----------+
Note to RFC Editor: In Figure 13, please replace all occurrences of Table 3: ACE Groupcomm Policies
"[RFC-XXXX]" with the RFC number of this specification and delete
this paragraph.
* 'kdc_cred', encoded as a CBOR byte string, whose value is the * 'kdc_cred': its value is the original binary representation of the
original binary representation of the KDC's authentication KDC's authentication credential, encoded as a CBOR byte string.
credential. This parameter is used if the KDC has an associated This parameter is used if the KDC has an associated authentication
authentication credential and this is required for the correct credential and this is required for the correct group operation.
group operation. It is REQUIRED of application profiles to define It is REQUIRED for application profiles to define whether the KDC
whether the KDC has an authentication credential and if this has has an authentication credential as required for the correct group
to be provided through the 'kdc_cred' parameter (REQ8). operation and if this has to be provided through the 'kdc_cred'
parameter (REQ8).
In such a case, the KDC's authentication credential MUST have the If the KDC has an authentication credential as required for the
same format used for the authentication credentials of the group correct group operation, the KDC's authentication credential MUST
members. It is REQUIRED of application profiles to define the have the same format used for the authentication credentials of
specific formats that are acceptable to use for the authentication the group members. It is REQUIRED for application profiles to
credentials in the group (REQ6). define the specific formats that are acceptable to use for the
authentication credentials in the group (REQ6).
* 'kdc_nonce', encoded as a CBOR byte string, and including a * 'kdc_nonce': its value is a dedicated nonce N_KDC generated by the
dedicated nonce N_KDC generated by the KDC. This parameter MUST KDC, encoded as a CBOR byte string. This parameter MUST be
be present if the 'kdc_cred' parameter is present. present if the 'kdc_cred' parameter is present.
* 'kdc_cred_verify', encoded as a CBOR byte string. This parameter * 'kdc_cred_verify': its value is as defined below and is encoded as
MUST be present if the 'kdc_cred' parameter is present. a CBOR byte string. This parameter MUST be present if the
'kdc_cred' parameter is present.
This parameter contains a proof-of-possession (PoP) evidence The value of this parameter is the proof-of-possession (PoP)
computed by the KDC over the following PoP input: the nonce N_C evidence computed by the KDC over the following PoP input: the
(encoded as a CBOR byte string) concatenated with the nonce N_KDC nonce N_C (encoded as a CBOR byte string) concatenated with the
(encoded as a CBOR byte string), where: nonce N_KDC (encoded as a CBOR byte string), where:
- N_C is the nonce generated by the Client and specified in the - N_C is the nonce generated by the Client and specified in the
'cnonce' parameter of the Join Request, encoded as a CBOR byte 'cnonce' parameter of the Join Request.
string.
- N_KDC is the nonce generated by the KDC and specified in the - N_KDC is the nonce generated by the KDC and specified in the
'kdc_nonce' parameter, encoded as a CBOR byte string. 'kdc_nonce' parameter.
An example of PoP input to compute 'kdc_cred_verify' using CBOR An example of PoP input to compute 'kdc_cred_verify' using CBOR
encoding is given in Figure 15. encoding is given in Figure 11.
A possible type of PoP evidence is a signature that the KDC A possible type of PoP evidence is a signature that the KDC
computes by using its own private key, whose corresponding public computes by using its own private key, whose corresponding public
key is specified in the authentication credential carried in the key is specified in the authentication credential conveyed in the
'kdc_cred' parameter. Application profiles of this specification 'kdc_cred' parameter. Application profiles of this specification
MUST specify the exact approaches used by the KDC to compute the MUST specify the approaches used by the KDC to compute the PoP
PoP evidence to include in 'kdc_cred_verify', and MUST specify evidence to include in 'kdc_cred_verify' and MUST specify which of
which of those approaches is used in which case (REQ21). those approaches is used in which case (REQ21).
* 'rekeying_scheme', identifying the rekeying scheme that the KDC * 'rekeying_scheme': identifying the rekeying scheme that the KDC
uses to provide new group keying material to the group members. uses to provide new group keying material to the group members.
This parameter is encoded as a CBOR integer, whose value is taken The value of this parameter is encoded as a CBOR integer and is
from the "Value" column of the "ACE Groupcomm Rekeying Schemes" taken from the "Value" column of the "ACE Groupcomm Rekeying
registry defined in Section 11.13 of this specification. Schemes" registry defined in Section 11.13 of this specification.
+-------+----------------+-------------------------------+------------+
| Value | Name | Description | Reference |
+-------+----------------+-------------------------------+------------+
| 0 | Point-to-Point | The KDC individually targets | [RFC-XXXX] |
| | | each node to rekey, using the | |
| | | pairwise secure communication | |
| | | association with that node | |
+-------+----------------+-------------------------------+------------+
Figure 14: ACE Groupcomm Rekeying Schemes +=======+================+===========================+===========+
| Value | Name | Description | Reference |
+=======+================+===========================+===========+
| 0 | Point-to-Point | The KDC individually | RFC 9594 |
| | | targets each node to | |
| | | rekey, using the | |
| | | pairwise secure | |
| | | communication | |
| | | association with | |
| | | that node | |
+-------+----------------+---------------------------+-----------+
Application profiles of this specification MAY define a default group Table 4: ACE Groupcomm Rekeying Schemes
rekeying scheme, to refer to in case the 'rekeying_scheme' parameter
is not included in the Join Response (OPT9).
Note to RFC Editor: In Figure 14, please replace "[RFC-XXXX]" with Application profiles of this specification MAY define a default
the RFC number of this specification and delete this paragraph. group rekeying scheme to refer to in case the 'rekeying_scheme'
parameter is not included in the Join Response (OPT9).
* 'mgt_key_material', encoded as a CBOR byte string and containing * 'mgt_key_material': encoded as a CBOR byte string and containing
the specific administrative keying material that the joining node the specific administrative keying material that the joining node
requires in order to participate in the group rekeying process requires in order to participate in the group rekeying process
performed by the KDC. This parameter MUST NOT be present if the performed by the KDC. This parameter MUST NOT be present if the
'rekeying_scheme' parameter is not present and the application 'rekeying_scheme' parameter is not present and the application
profile does not specify a default group rekeying scheme to use in profile does not specify a default group rekeying scheme to use in
the group. Some simple rekeying schemes may not require specific the group. Some simple rekeying schemes may not require specific
administrative keying material to be provided, e.g., the basic administrative keying material to be provided, e.g., the basic
"Point-to-Point" group rekeying scheme (see Section 6.1). "Point-to-Point" group rekeying scheme (see Section 6.1).
In more advanced group rekeying schemes, the administrative keying In more advanced group rekeying schemes, the administrative keying
material can be composed of multiple keys organized, for instance, material can be composed of multiple keys organized, for instance,
into a logical tree hierarchy, whose root key is the only into a logical tree hierarchy, whose root key is the only
administrative key shared by all the group members. In such a administrative key shared by all the group members. In such a
case, each group member is exclusively associated with one leaf case, each group member is exclusively associated with one leaf
key in the hierarchy, and stores only the administrative keys from key in the hierarchy and stores only the administrative keys from
the associated leaf key all the way up along the path to the root the associated leaf key all the way up along the path to the root
key. That is, different group members can be provided with a key. That is, different group members can be provided with a
different subset of the overall administrative keying material. different subset of the overall administrative keying material.
It is expected from separate documents to define how the advanced It is expected from separate documents to define how the advanced
group rekeying scheme possibly indicated in the 'rekeying_scheme' group rekeying scheme, possibly indicated in the 'rekeying_scheme'
parameter is used by an application profile of this specification. parameter, is used by an application profile of this
This includes defining the format of the administrative keying specification. This includes defining the format of the
material to specify in 'mgt_key_material', consistently with the administrative keying material to specify in 'mgt_key_material'
group rekeying scheme and the application profile in question. consistently with the group rekeying scheme and the application
profile in question.
* 'control_group_uri', with a full URI as value, encoded as a CBOR * 'control_group_uri': its value is a full URI, encoded as a CBOR
text string. The URI MUST specify addressing information intended text string. The URI MUST specify addressing information intended
to reach all the members in the group. For example, this can be a to reach all the members in the group. For example, this can be a
multicast IP address, optionally together with a port number that, multicast IP address, optionally together with a port number that,
if omitted, defaults to 5683, i.e., the default port number for if omitted, defaults to 5683, i.e., the default port number for
the "coap" URI scheme (see Section 6.1 of [RFC7252]). The URI the "coap" URI scheme (see Section 6.1 of [RFC7252]). The URI
MUST include GROUPNAME in the url-path. A default url-path is MUST include GROUPNAME in the url-path. A default url-path is
/ace-group/GROUPNAME, although implementations can use different /ace-group/GROUPNAME, although implementations can use different
ones instead. The URI MUST NOT have url-path /ace- ones instead. The URI MUST NOT have url-path /ace-
group/GROUPNAME/node. group/GROUPNAME/nodes.
If 'control_group_uri' is included in the Join Response, the If 'control_group_uri' is included in the Join Response, the
Clients supporting this parameter act as CoAP servers, host a Clients supporting this parameter act as CoAP servers, host a
resource at this specific URI, and listen to the specified resource at this specific URI, and listen to the specified
addressing information. addressing information.
The KDC MAY use this URI to send one-to-many CoAP requests to the The KDC MAY use this URI to send one-to-many CoAP requests to the
Client group members (acting as CoAP servers in this exchange), Client group members (acting as CoAP servers in this exchange),
for example for one-to-many provisioning of new group keying for example, for one-to-many provisioning of new group keying
material when performing a group rekeying (see Section 4.8.1.1), material when performing a group rekeying (see Section 6.2) or to
or to inform the Clients of their removal from the group (see inform the Clients of their removal from the group (see
Section 5). Section 5).
In particular, this resource is intended for communications In particular, this resource is intended for communications
concerning exclusively the group identified by GROUPNAME and whose exclusively concerning the group identified by GROUPNAME and whose
group name was specified in the 'scope' parameter of the Join group name was specified in the 'scope' parameter of the Join
Request, if present. If the KDC does not implement mechanisms Request, if present. If the KDC does not implement mechanisms
using this resource for that group, it can ignore this parameter. using this resource for that group, it can ignore this parameter.
Other additional functionalities of this resource MAY be defined Other additional functionalities of this resource MAY be defined
in application profiles of this specifications (OPT10). in application profiles of this specifications (OPT10).
N_C and N_KDC expressed in CBOR diagnostic notation: N_C and N_KDC expressed in CBOR diagnostic notation:
N_C = h'25a8991cd700ac01' N_C = h'25a8991cd700ac01'
N_KDC = h'cef04b2aa791bc6d' N_KDC = h'cef04b2aa791bc6d'
N_C and N_KDC as CBOR encoded byte strings: N_C and N_KDC as CBOR encoded byte strings:
N_C = 0x4825a8991cd700ac01 N_C = 0x4825a8991cd700ac01
N_KDC = 0x48cef04b2aa791bc6d N_KDC = 0x48cef04b2aa791bc6d
PoP input: PoP input:
0x48 25a8991cd700ac01 48 cef04b2aa791bc6d 0x48 25a8991cd700ac01 48 cef04b2aa791bc6d
Figure 15: Example of PoP input to compute 'kdc_cred_verify' Figure 11: Example of PoP Input to Compute 'kdc_cred_verify'
using CBOR encoding Using CBOR Encoding
After sending the Join Response, if the KDC has an associated After sending the Join Response, if the KDC has an associated
authentication credential, the KDC MUST store the N_C value specified authentication credential as required for the correct group
in the 'cnonce' parameter of the Join Request, as a 'clientchallenge' operation, then the KDC MUST store the N_C value specified in the
value associated with the Client, replacing the currently stored 'cnonce' parameter of the Join Request as a 'clientchallenge' value
value (if any). If, as a group member, the Client later sends a GET associated with the Client, replacing the currently stored value (if
request to the /ace-group/GROUPNAME/kdc-cred resource for retrieving any). If, as a group member, the Client later sends a GET request to
the latest KDC's authentication credential (see Section 4.5.1), then the /ace-group/GROUPNAME/kdc-cred resource for retrieving the latest
the KDC is able to use the stored 'clientchallenge' for computing a KDC's authentication credential (see Section 4.5.1), then the KDC
PoP evidence to include in the response sent to the Client, hence uses the stored 'clientchallenge' for computing the PoP evidence to
proving the possession of its own private key. include in the response sent to the Client, hence proving the
possession of its own private key.
If the Join Response includes the 'kdc_cred_verify' parameter, the If the Join Response includes the 'kdc_cred_verify' parameter, the
Client verifies the conveyed PoP evidence and considers the group Client verifies the conveyed PoP evidence and considers the group
joining unsuccessful in case of failed verification. Application joining unsuccessful in case of failed verification. Application
profiles of this specification MUST specify the exact approaches used profiles of this specification MUST specify the exact approaches used
by the Client to verify the PoP evidence in 'kdc_cred_verify', and by the Client to verify the PoP evidence in 'kdc_cred_verify' and
MUST specify which of those approaches is used in which case (REQ21). MUST specify which of those approaches is used in which case (REQ21).
Specific application profiles that build on this document MUST Application profiles of this specification MUST specify the
specify the communication protocol that members of the group use to communication protocol that members of the group use to communicate
communicate with each other (REQ22) and how exactly the keying with each other (REQ22) and the security protocol that they use to
material is used to protect the group communication (REQ23). protect the group communication (REQ23).
4.3.1.1. Join the Group 4.3.1.1. Join the Group
Figure 16 gives an overview of the join exchange between the Client Figure 12 gives an overview of the join exchange between the Client
and the KDC, when the Client first joins a group, while Figure 17 and the KDC when the Client first joins a group, while Figure 13
shows an example. shows an example.
Client KDC Client KDC
| | | |
|-------- Join Request: POST /ace-group/GROUPNAME ------>| |-------- Join Request: POST /ace-group/GROUPNAME ------>|
| | | |
|<------------ Join Response: 2.01 (Created) ----------- | |<------------ Join Response: 2.01 (Created) ----------- |
| Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" | | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" |
Figure 16: Message Flow of the Join Request-Response Figure 12: Message Flow of the Join Request-Response
Request: Request:
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "kdc.example.com" Uri-Host: "kdc.example.com"
Uri-Path: "ace-group" Uri-Path: "ace-group"
Uri-Path: "g1" Uri-Path: "g1"
Content-Format: "application/ace-groupcomm+cbor" Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation, Payload (in CBOR diagnostic notation):
with AUTH_CRED and POP_EVIDENCE being CBOR byte strings): {
{ "scope": << [ "group1", ["sender", "receiver"] ] >> , / scope / 3: <<["group1", ["sender", "receiver"]]>>,
"get_creds": [true, ["sender"], []], "client_cred": AUTH_CRED, / get_creds / 4: [true, ["sender"], []],
"cnonce": h'25a8991cd700ac01', "client_cred_verify": POP_EVIDENCE } / client_cred / 5: h'a2026008a101a5010202410a20012158
20bbc34960526ea4d32e940cad2a2341
48ddc21791a12afbcbac93622046dd44
f02258204519e257236b2a0ce2023f09
31f1f386ca7afda64fcde0108c224c51
eabf6072',
/ cnonce / 6: h'25a8991cd700ac01',
/ client_cred_verify / 24: h'66e6d9b0db009f3e105a673f88556117
26caed57f530f8cae9d0b168513ab949
fedc3e80a96ebe94ba08d3f8d3bf8348
7458e2ab4c2f936ff78b50e33c885e35'
}
Response: Response:
Header: Created (Code=2.01) Header: Created (Code=2.01)
Content-Format: "application/ace-groupcomm+cbor" Content-Format: 261 (application/ace-groupcomm+cbor)
Location-Path: "kdc.example.com" Location-Path: "ace-group"
Location-Path: "g1" Location-Path: "g1"
Location-Path: "nodes" Location-Path: "nodes"
Location-Path: "c101" Location-Path: "c101"
Payload (in CBOR diagnostic notation, Payload (in CBOR diagnostic notation):
with KEY, AUTH_CRED_1, AUTH_CRED_2, {
ID_1, and ID_2 being CBOR byte strings): / gkty / 7: 65600,
{ "gkty": 13, "key": KEY, "num": 12, "exp": 1924992000, / key / 8: h'73657373696f6e6b6579',
"exi": 2592000, "creds": [ AUTH_CRED_1, AUTH_CRED_2 ], / num / 9: 12,
"peer_roles": ["sender", ["sender", "receiver"]], / exp / 11: 1924992000,
"peer_identifiers": [ ID1, ID2 ] } / exi / 12: 2592000,
/ creds / 13: [h'a2026008a101a5010202410220012158
20cd4177ba62433375ede279b5e18e8b
91bc3ed8f1e174474a26fc0edb44ea53
73225820a0391de29c5c5badda610d4e
301eaaa18422367722289cd18cbe6624
e89b9cfd',
h'a2026008a101a5010202410320012158
20ac75e9ece3e50bfc8ed60399889522
405c47bf16df96660a41298cb4307f7e
b62258206e5de611388a4b8a8211334a
c7d37ecb52a387d257e6db3c2a93df21
ff3affc8'],
/ peer_roles / 14: ["sender", ["sender", "receiver"]],
/ peer_identifiers / 15: [h'01', h'02']
}
Figure 17: Example of First Join Request-Response for Group Joining Figure 13: Example of the First Join Request-Response for Group
Joining
If not previously established, the Client and the KDC MUST first If not previously established, the Client and the KDC MUST first
establish a pairwise secure communication association (REQ24). This establish a pairwise secure communication association (REQ24). This
can be achieved, for instance, by using a transport profile of ACE. can be achieved, for instance, by using a transport profile of ACE.
The join exchange MUST occur over that secure communication The join exchange MUST occur over that secure communication
association. The Client and the KDC MAY use that same secure association. The Client and the KDC MAY use that same secure
communication association to protect further pairwise communications communication association to protect further pairwise communications
that must be protected. that must be protected.
It is REQUIRED that the secure communication association between the It is REQUIRED that the secure communication association between the
Client and the KDC is established by using the proof-of-possession Client and the KDC is established by using the proof-of-possession
key bound to the access token. As a result, the proof-of-possession key bound to the access token. As a result, the proof of possession
to bind the access token to the Client is performed by using the to bind the access token to the Client is performed by using the
proof-of-possession key bound to the access token for establishing proof-of-possession key bound to the access token for establishing
secure communication between the Client and the KDC. the pairwise secure communication association between the Client and
the KDC.
To join the group, the Client sends a CoAP POST request to the /ace- To join the group, the Client sends a CoAP POST request to the /ace-
group/GROUPNAME endpoint at the KDC, where the group to join is group/GROUPNAME endpoint at the KDC, where the group to join is
identified by GROUPNAME. The group name is specified in the scope identified by GROUPNAME. The group name is specified in the scope
entry conveyed by the 'scope' parameter of the request (if present), entry conveyed by the 'scope' parameter of the request (if present),
formatted as specified in Section 4.3.1. This group name is the same formatted as specified in Section 4.3.1. This group name is the same
as in the scope entry corresponding to that group, specified in the as in the scope entry corresponding to that group, specified in the
'scope' parameter of the Authorization Request/Response, or it can be 'scope' parameter of the Authorization Request/Response, or it can be
retrieved from it. Note that, in case of successful joining, the determined from it. Note that, in case of successful joining, the
Client will receive the URI to retrieve individual keying material Location-Path Options in the Join Response provide the Client with
and to leave the group in the Location-Path option of the response. the path of the URI to use for retrieving individual keying material
and for leaving the group.
If the node is joining a group for the first time and the KDC If the node is joining a group for the first time and the KDC
maintains the authentication credentials of the group members, the maintains the authentication credentials of the group members, the
Client is REQUIRED to send its own authentication credential and Client is REQUIRED to send its own authentication credential and
proof-of-possession (PoP) evidence in the Join Request (see the proof-of-possession (PoP) evidence in the Join Request (see the
'client_cred' and 'client_cred_verify' parameters in Section 4.3.1). 'client_cred' and 'client_cred_verify' parameters in Section 4.3.1).
The request is accepted only if both the authentication credential is The request is accepted only if both the authentication credential is
provided and the PoP evidence is successfully verified. provided and the PoP evidence is successfully verified.
If a node re-joins a group as authorized by the same access token and If a node rejoins a group as authorized by the same access token and
using the same authentication credential, it can omit the using the same authentication credential, it can omit the
authentication credential and the PoP evidence, or just the PoP authentication credential and the PoP evidence, or just the PoP
evidence, from the Join Request. Then, the KDC will be able to evidence, from the Join Request. Then, the KDC will be able to
retrieve the node's authentication credential associated with the retrieve the node's authentication credential associated with the
access token for that group. If the authentication credential has access token for that group. If the authentication credential has
been discarded, the KDC replies with a 4.00 (Bad Request) error been discarded, the KDC replies with a 4.00 (Bad Request) error
response, as specified in Section 4.3.1. If a node re-joins a group response, as specified in Section 4.3.1. If a node rejoins a group
but wants to update its own authentication credential, it needs to but wants to update its own authentication credential, it needs to
include both its authentication credential and the PoP evidence in include both its authentication credential and the PoP evidence in
the Join Request like when it joined the group for the first time. the Join Request, like when it joined the group for the first time.
4.3.2. GET Handler 4.3.2. GET Handler
The GET handler returns the symmetric group keying material for the The GET handler returns the symmetric group keying material for the
group identified by GROUPNAME. group identified by GROUPNAME.
The handler expects a GET request. The handler expects a GET request.
In addition to what is defined in Section 4.1.2, the handler verifies In addition to what is defined in Section 4.1.2, the handler verifies
that the Client is a current member of the group. If the that the Client is a current member of the group. If the
verification fails, the KDC MUST reply with a 4.03 (Forbidden) error verification fails, the KDC MUST reply with a 4.03 (Forbidden) error
response. The response MUST have Content-Format set to application/ response. The response MUST have Content-Format "application/
concise-problem-details+cbor and is formatted as defined in concise-problem-details+cbor" and is formatted as defined in
Section 4.1.2. Within the Custom Problem Detail entry 'ace- Section 4.1.2. Within the Custom Problem Detail entry 'ace-
groupcomm-error', the value of the 'error-id' field MUST be set to 0 groupcomm-error', the value of the 'error-id' field MUST be set to 0
("Operation permitted only to group members"). ("Operation permitted only to group members").
If all verifications succeed, the handler replies with a 2.05 If all verifications succeed, the handler replies with a 2.05
(Content) response containing the symmetric group keying material. (Content) response containing the symmetric group keying material.
The payload of the response is formatted as a CBOR map which MUST The payload of the response is formatted as a CBOR map that MUST
contain the parameters 'gkty', 'key', and 'num' specified in contain the parameters 'gkty', 'key', and 'num', as specified in
Section 4.3.1. Section 4.3.1.
Each of the following parameters specified in Section 4.3.1 MUST also The payload MUST also include the parameters 'rekeying_scheme' and
be included in the payload of the response, if they are included in 'mgt_key_material' as specified in Section 4.3.1, if they are
the payload of the Join Responses sent for the group: included in the payload of the Join Responses sent for the group.
'rekeying_scheme', 'mgt_key_material'.
The payload MAY also include the parameters 'ace_groupcomm_profile', The payload MAY also include the parameters 'ace_groupcomm_profile',
'exp', and 'exi' specified in Section 4.3.1. If the 'exp' parameter 'exp', and 'exi', as specified in Section 4.3.1. If the 'exp'
is included, the 'exi' parameter MUST also be included. If the parameter is included, the 'exi' parameter MUST also be included. If
parameter 'exi' is included, its value specifies the residual the 'exi' parameter is included, its value specifies the residual
lifetime of the group keying material from the current time at the lifetime of the group keying material from the current time at the
KDC. KDC.
4.3.2.1. Retrieve Group Keying Material 4.3.2.1. Retrieve Group Keying Material
A node in the group can contact the KDC to retrieve the current group A node in the group can contact the KDC to retrieve the current group
keying material, by sending a CoAP GET request to the /ace-group/ keying material by sending a CoAP GET request to the /ace-group/
GROUPNAME endpoint at the KDC, where the group is identified by GROUPNAME endpoint at the KDC, where the group is identified by
GROUPNAME. GROUPNAME.
Figure 18 gives an overview of the key distribution exchange between Figure 14 gives an overview of the key distribution exchange between
the Client and the KDC, when the Client first joins a group, while the Client and the KDC, while Figure 15 shows an example.
Figure 19 shows an example.
Client KDC Client KDC
| | | |
|------ Key Distribution Request: GET /ace-group/GROUPNAME ------>| |------ Key Distribution Request: GET /ace-group/GROUPNAME ------>|
| | | |
|<----------- Key Distribution Response: 2.05 (Content) --------- | |<----------- Key Distribution Response: 2.05 (Content) --------- |
| | | |
Figure 18: Message Flow of Key Distribution Request-Response Figure 14: Message Flow of Key Distribution Request-Response
Request: Request:
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "kdc.example.com" Uri-Host: "kdc.example.com"
Uri-Path: "ace-group" Uri-Path: "ace-group"
Uri-Path: "g1" Uri-Path: "g1"
Payload: -
Response: Response:
Header: Content (Code=2.05) Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor" Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation, Payload (in CBOR diagnostic notation):
with KEY being a CBOR byte strings): {
{ "gkty": 13, "key": KEY, "num": 12 } / gkty / 7: 65600,
/ key / 8: h'73657373696f6e6b6579',
/ num / 9: 12
}
Figure 19: Example of Key Distribution Request-Response Figure 15: Example of Key Distribution Request-Response
4.4. /ace-group/GROUPNAME/creds 4.4. /ace-group/GROUPNAME/creds
This resource implements the GET and FETCH handlers. This resource implements the GET and FETCH handlers.
4.4.1. FETCH Handler 4.4.1. FETCH Handler
The FETCH handler receives identifiers of group members for the group The FETCH handler receives identifiers of group members for the group
identified by GROUPNAME and returns the authentication credentials of identified by GROUPNAME and returns the authentication credentials of
such group members. such group members.
The handler expects a request with payload formatted as a CBOR map, The handler expects a request with the payload formatted as a CBOR
which MUST contain the following field. map, which MUST contain the following field.
* 'get_creds', whose value is encoded as in Section 4.3.1 with the * 'get_creds': its value is encoded as in Section 4.3.1, with the
following modifications. following modifications.
- The arrays 'role_filter' and 'id_filter' MUST NOT both be - The arrays 'role_filter' and 'id_filter' MUST NOT both be
empty, i.e., in CDDL notation: [ bool, [ ], [ ] ]. If the empty, i.e., in CDDL notation: [ bool, [ ], [ ] ]. If the
'get_creds' parameter has such a format, the request MUST be 'get_creds' parameter has such a format, the request MUST be
considered malformed, and the KDC MUST reply with a 4.00 (Bad considered malformed, and the KDC MUST reply with a 4.00 (Bad
Request) error response. Request) error response.
Note that a group member can retrieve the authentication Note that a group member can retrieve the authentication
credentials of all the current group members by sending a GET credentials of all the current group members by sending a GET
request to the same KDC resource instead (see Section 4.4.2.1). request to the same KDC resource instead (see Section 4.4.2.1).
- The element 'inclusion_flag' encodes the CBOR simple value - The element 'inclusion_flag' encodes the CBOR simple value true
"true" (0xf5) or "false" (0xf4), as defined in Section 4.3.1. (0xf5) or false (0xf4), as defined in Section 4.3.1.
- The array 'role_filter' can be empty, if the Client does not - The array 'role_filter' can be empty if the Client does not
wish to filter the requested authentication credentials based wish to filter the requested authentication credentials based
on the roles of the group members. on the roles of the group members.
- The array 'id_filter' contains zero or more node identifiers of - The array 'id_filter' contains zero or more node identifiers of
group members, for the group identified by GROUPNAME, as group members for the group identified by GROUPNAME, as defined
defined in Section 4.3.1. The array may be empty, if the in Section 4.3.1. The array may be empty if the Client does
Client does not wish to filter the requested authentication not wish to filter the requested authentication credentials
credentials based on the node identifiers of the group members. based on the node identifiers of the group members.
Note that, in case the 'role_filter' array and the 'id_filter' array Note that, in case the 'role_filter' array and the 'id_filter' array
are both non-empty: are both non-empty:
* If the 'inclusion_flag' encodes the CBOR simple value "true" * If the 'inclusion_flag' encodes the CBOR simple value true (0xf5),
(0xf5), the handler returns the authentication credentials of the handler returns the authentication credentials of group
group members whose roles match with 'role_filter' and/or having members whose roles match with 'role_filter' and/or have their
their node identifier specified in 'id_filter'. node identifier specified in 'id_filter'.
* If the 'inclusion_flag' encodes the CBOR simple value "false" * If the 'inclusion_flag' encodes the CBOR simple value false
(0xf4), the handler returns the authentication credentials of (0xf4), the handler returns the authentication credentials of
group members whose roles match with 'role_filter' and, at the group members whose roles match with 'role_filter' and, at the
same time, not having their node identifier specified in same time, do not have their node identifier specified in
'id_filter'. 'id_filter'.
The specific format of authentication credentials as well as The specific format of authentication credentials as well as the
identifiers, roles, and combination of roles of group members MUST be identifiers, roles, and combination of roles of group members MUST be
specified by application profiles of this specification (REQ1, REQ6, specified by application profiles of this specification (REQ1, REQ6,
REQ25). REQ25).
The handler identifies the authentication credentials of the current The handler identifies the authentication credentials of the current
group members for which either of the following holds: group members for which either of the following holds:
* the role identifier matches with one of those indicated in the * The role identifier matches with one of those indicated in the
request; note that the request can specify a combination of roles, request; note that the request can specify a combination of roles,
in which case the handler selects only the group members that have in which case the handler selects only the group members that have
all the roles included in the combination. all the roles included in the combination.
* the node identifier matches with one of those indicated in the * The node identifier matches with one of those indicated in the
request, or does not match with any of those, consistent with the request or does not match with any of those, which is consistent
value of the element 'inclusion_flag'. with the value of the element 'inclusion_flag'.
If all verifications succeed, the handler returns a 2.05 (Content) If all verifications succeed, the handler returns a 2.05 (Content)
message response with payload formatted as a CBOR map, containing message response with the payload formatted as a CBOR map, containing
only the following parameters from Section 4.3.1. only the following parameters from Section 4.3.1.
* 'num', which encodes the version number of the current group * 'num': encoding the version number of the current group keying
keying material. material.
* 'creds', which encodes the list of authentication credentials of * 'creds': encoding the list of authentication credentials of the
the selected group members. selected group members.
* 'peer_roles', which encodes the role(s) that each of the selected * 'peer_roles': encoding the role(s) that each of the selected group
group members has in the group. members has in the group.
This parameter SHOULD be present and it MAY be omitted, according This parameter SHOULD be present, and it MAY be omitted according
to the same criteria defined for the Join Response (see to the same criteria defined for the Join Response (see
Section 4.3.1). Section 4.3.1).
* 'peer_identifiers', which encodes the node identifier that each of * 'peer_identifiers': encoding the node identifier that each of the
the selected group members has in the group. selected group members has in the group.
The specific format of authentication credentials as well as of node The specific format of authentication credentials as well as of node
identifiers of group members is specified by the application profile identifiers of group members is specified by the application profile
(REQ6, REQ25). (REQ6, REQ25).
If the KDC does not store any authentication credential associated If the KDC does not store any authentication credential associated
with the specified node identifiers, the handler returns a response with the specified node identifiers, the handler returns a response
with payload formatted as a CBOR byte string of zero length. with the payload formatted as a CBOR byte string of zero length
(0x40).
The handler MAY enforce one of the following policies, in order to The handler MAY enforce one of the following policies in order to
handle possible node identifiers that are included in the 'id_filter' handle possible node identifiers that are included in the 'id_filter'
element of the 'get_creds' parameter of the request but are not element of the 'get_creds' parameter of the request but are not
associated with any current group member. Such a policy MUST be associated with any current group member. Such a policy MUST be
specified by the application profile (REQ26). specified by application profiles of this specification (REQ26).
* The KDC silently ignores those node identifiers. * The KDC silently ignores those node identifiers.
* The KDC retains authentication credentials of group members for a * The KDC retains authentication credentials of group members for a
given amount of time after their leaving, before discarding them. given amount of time after their leaving before discarding them.
As long as such authentication credentials are retained, the KDC As long as such authentication credentials are retained, the KDC
provides them to a requesting Client. provides them to a requesting Client.
If the KDC adopts this policy, the application profile MUST also If the KDC adopts this policy, the application profile MUST also
specify the amount of time during which the KDC retains the specify the amount of time during which the KDC retains the
authentication credential of a former group member after its authentication credential of a former group member after its
leaving, possibly on a per-member basis. leaving, possibly on a per-member basis.
Note that this resource handler only verifies that the node is Note that this resource handler only verifies that the node is
authorized by the AS to access this resource. Nodes that are not authorized by the AS to access this resource. Nodes that are not
members of the group but are authorized to do signature verifications members of the group but are authorized to do signature verifications
on the group messages may be allowed to access this resource, if the on the group messages may be allowed to access this resource if the
application needs it. application needs it.
4.4.1.1. Retrieve a Subset of Authentication Credentials in the Group 4.4.1.1. Retrieve a Subset of Authentication Credentials in the Group
In case the KDC maintains the authentication credentials of group In case the KDC maintains the authentication credentials of group
members, a node in the group can contact the KDC to request the members, a node in the group can contact the KDC to request the
authentication credentials, roles, and node identifiers of a authentication credentials, roles, and node identifiers of a
specified subset of group members, by sending a CoAP FETCH request to specified subset of group members by sending a CoAP FETCH request to
the /ace-group/GROUPNAME/creds endpoint at the KDC, where the group the /ace-group/GROUPNAME/creds endpoint at the KDC, which is
is identified by GROUPNAME, and formatted as defined in formatted as defined in Section 4.4.1 and where GROUPNAME identifies
Section 4.4.1. the group.
Figure 20 gives an overview of the exchange mentioned above, while Figure 16 gives an overview of the exchange mentioned above, while
Figure 21 shows an example of such an exchange. Figure 17 shows an example of such an exchange.
Client KDC Client KDC
| | | |
| Authentication Credential Request: | | Authentication Credential Request: |
|-------------------------------------------------------->| |-------------------------------------------------------->|
| FETCH /ace-group/GROUPNAME/creds | | FETCH /ace-group/GROUPNAME/creds |
| | | |
|<-- Authentication Credential Response: 2.05 (Created) --| |<-- Authentication Credential Response: 2.05 (Content) --|
| | | |
Figure 20: Message Flow of Authentication Credential Request- Figure 16: Message Flow of Authentication Credential Request-
Response to Obtain the Authentication Credentials of Specific Response to Obtain the Authentication Credentials of Specific
Group Members Group Members
Request: Request:
Header: FETCH (Code=0.05) Header: FETCH (Code=0.05)
Uri-Host: "kdc.example.com" Uri-Host: "kdc.example.com"
Uri-Path: "ace-group" Uri-Path: "ace-group"
Uri-Path: "g1" Uri-Path: "g1"
Uri-Path: "creds" Uri-Path: "creds"
Content-Format: "application/ace-groupcomm+cbor" Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation): Payload (in CBOR diagnostic notation):
{ "get_creds": [true, [], [ ID_2, ID_3 ]] } {
/ get_creds / 4: [true, [], [h'02', h'03']]
}
Response: Response:
Header: Content (Code=2.05) Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor" Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation, Payload (in CBOR diagnostic notation):
with AUTH_CRED_2, AUTH_CRED_3, {
ID_2, and ID_3 being CBOR byte strings): / creds / 13: [h'a2026008a101a5010202410320012158
{ "creds": [ AUTH_CRED_2, AUTH_CRED_3, ], 20ac75e9ece3e50bfc8ed60399889522
"peer_roles": [ ["sender", "receiver"], "receiver" ], 405c47bf16df96660a41298cb4307f7e
"peer_identifiers": [ ID_2, ID_3 ] } b62258206e5de611388a4b8a8211334a
c7d37ecb52a387d257e6db3c2a93df21
ff3affc8',
h'a2026008a101a5010202410920012158
206f9702a66602d78f5e81bac1e0af01
f8b52810c502e87ebb7c926c07426fd0
2f225820c8d33274c71c9b3ee57d842b
bf2238b8283cb410eca216fb72a78ea7
a870f800'],
/ peer_roles / 14: [["sender", "receiver"], "receiver"],
/ peer_identifiers / 15: [h'02', h'03']
}
Figure 21: Example of Authentication Credential Request-Response Figure 17: Example of Authentication Credential Request-Response
to Obtain the Authentication Credentials of Specific Group to Obtain the Authentication Credentials of Specific Group
Members Members
4.4.2. GET Handler 4.4.2. GET Handler
The handler expects a GET request. The handler expects a GET request.
If all verifications succeed, the KDC replies with a 2.05 (Content) If all verifications succeed, the KDC replies with a 2.05 (Content)
response as in the FETCH handler in Section 4.4.1, but specifying in response as in the FETCH handler in Section 4.4.1, but its payload
the payload the authentication credentials of all the group members, specifies the authentication credentials of all the group members,
together with their roles and node identifiers. together with their roles and node identifiers.
The parameter 'peer_roles' SHOULD be present in the payload of the The 'peer_roles' parameter SHOULD be present in the payload of the
response and it MAY be omitted, according to the same criteria response, and it MAY be omitted according to the same criteria
defined for the Join Response (see Section 4.3.1). defined for the Join Response (see Section 4.3.1).
4.4.2.1. Retrieve All Authentication Credentials in the Group 4.4.2.1. Retrieve All Authentication Credentials in the Group
In case the KDC maintains the authentication credentials of group In case the KDC maintains the authentication credentials of group
members, a group or an external signature verifier can contact the members, a node in the group or an external signature verifier can
KDC to request the authentication credentials, roles, and node contact the KDC to request the authentication credentials, roles, and
identifiers of all the current group members, by sending a CoAP GET node identifiers of all the current group members, by sending a CoAP
request to the /ace-group/GROUPNAME/creds endpoint at the KDC, where GET request to the /ace-group/GROUPNAME/creds endpoint at the KDC,
the group is identified by GROUPNAME. where the group is identified by GROUPNAME.
Figure 22 gives an overview of the message exchange, while Figure 23 Figure 18 gives an overview of the message exchange, while Figure 19
shows an example of such an exchange. shows an example of such an exchange.
Client KDC Client KDC
| | | |
| Authentication Credential Request: | | Authentication Credential Request: |
|-------------------------------------------------------->| |-------------------------------------------------------->|
| GET /ace-group/GROUPNAME/creds | | GET /ace-group/GROUPNAME/creds |
| | | |
|<-- Authentication Credential Response: 2.05 (Content) --| |<-- Authentication Credential Response: 2.05 (Content) --|
| | | |
Figure 22: Message Flow of Authentication Credential Request- Figure 18: Message Flow of Authentication Credential Request-
Response to Obtain the Authentication Credentials of all the Response to Obtain the Authentication Credentials of All the
Group Members Group Members
Request: Request:
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "kdc.example.com" Uri-Host: "kdc.example.com"
Uri-Path: "ace-group" Uri-Path: "ace-group"
Uri-Path: "g1" Uri-Path: "g1"
Uri-Path: "creds" Uri-Path: "creds"
Payload: -
Response: Response:
Header: Content (Code=2.05) Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor" Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation, Payload (in CBOR diagnostic notation):
with AUTH_CRED_1, AUTH_CRED_2, AUTH_CRED_3, {
ID_1, ID_2, and ID_3 being CBOR byte strings): / num / 9: 12,
{ "num": 5, / creds / 13: [h'a2026008a101a5010202410220012158
"creds": [ AUTH_CRED_1, AUTH_CRED_2, AUTH_CRED_3 ], 20cd4177ba62433375ede279b5e18e8b
"peer_roles": ["sender", ["sender", "receiver"], "receiver"], 91bc3ed8f1e174474a26fc0edb44ea53
"peer_identifiers": [ ID_1, ID_2, ID_3 ] } 73225820a0391de29c5c5badda610d4e
301eaaa18422367722289cd18cbe6624
e89b9cfd',
h'a2026008a101a5010202410320012158
20ac75e9ece3e50bfc8ed60399889522
405c47bf16df96660a41298cb4307f7e
b62258206e5de611388a4b8a8211334a
c7d37ecb52a387d257e6db3c2a93df21
ff3affc8',
h'a2026008a101a5010202410920012158
206f9702a66602d78f5e81bac1e0af01
f8b52810c502e87ebb7c926c07426fd0
2f225820c8d33274c71c9b3ee57d842b
bf2238b8283cb410eca216fb72a78ea7
a870f800'],
/ peer_roles / 14: ["sender", ["sender", "receiver"],
"receiver"],
/ peer_identifiers / 15: [h'01', h'02', h'03']
}
Figure 23: Example of Authentication Credential Request-Response Figure 19: Example of Authentication Credential Request-Response
to Obtain the Authentication Credentials of all the Group Members to Obtain the Authentication Credentials of All the Group Members
4.5. /ace-group/GROUPNAME/kdc-cred 4.5. /ace-group/GROUPNAME/kdc-cred
This resource implements a GET handler. This resource implements a GET handler.
4.5.1. GET Handler 4.5.1. GET Handler
The handler expects a GET request. The handler expects a GET request.
If all verifications succeed, the handler returns a 2.05 (Content) If all verifications succeed, the handler returns a 2.05 (Content)
message containing the KDC's authentication credential together with message containing the KDC's authentication credential together with
a proof-of-possession (PoP) evidence. The response MUST have the proof-of-possession (PoP) evidence. The response MUST have
Content-Format set to application/ace-groupcomm+cbor. The payload of Content-Format "application/ace-groupcomm+cbor". The payload of the
the response is a CBOR map, which includes the following fields. response is a CBOR map, which includes the following fields.
* The 'kdc_cred' parameter, specifying the KDC's authentication * 'kdc_cred: specifying the KDC's authentication credential. This
credential. This parameter is encoded like the 'kdc_cred' parameter is encoded like the 'kdc_cred' parameter in the Join
parameter in the Join Response (see Section 4.3.1). Response (see Section 4.3.1).
* The 'kdc_nonce' parameter, specifying a nonce generated by the * 'kdc_nonce': specifying a nonce generated by the KDC. This
KDC. This parameter is encoded like the 'kdc_nonce' parameter in parameter is encoded like the 'kdc_nonce' parameter in the Join
the Join Response (see Section 4.3.1). Response (see Section 4.3.1).
* The 'kdc_cred_verify' parameter, specifying a PoP evidence * 'kdc_cred_verify': specifying the PoP evidence computed by the KDC
computed by the KDC over the following PoP input: the nonce N_C over the following PoP input: the nonce N_C (encoded as a CBOR
(encoded as a CBOR byte string) concatenated with the nonce N_KDC byte string) concatenated with the nonce N_KDC (encoded as a CBOR
(encoded as a CBOR byte string), where: byte string), where:
- N_C is the nonce generated by the Client group member such - N_C is the nonce generated by the Client group member such
that: i) the nonce was specified in the 'cnonce' parameter of that: i) the nonce was specified in the 'cnonce' parameter of
the latest Join Request that the Client sent to the KDC in the latest Join Request that the Client sent to the KDC in
order to join the group identified by GROUPNAME; and ii) the order to join the group identified by GROUPNAME; and ii) the
KDC stored the nonce as 'clientchallenge' value associated with KDC stored the nonce as a 'clientchallenge' value associated
this Client as group member after sending the corresponding with the Client after sending the corresponding Join Response
Join Response (see Section 4.3.1). This nonce is encoded as a (see Section 4.3.1).
CBOR byte string.
- N_KDC is the nonce generated by the KDC and specified in the - N_KDC is the nonce generated by the KDC and specified in the
'kdc_nonce' parameter, encoded as a CBOR byte string. 'kdc_nonce' parameter.
An example of PoP input to compute 'kdc_cred_verify' using CBOR An example of PoP input to compute 'kdc_cred_verify' using CBOR
encoding is given in Figure 24. encoding is given in Figure 20.
The PoP evidence is computed by means of the same method used for The PoP evidence is computed by means of the same method used for
computing the PoP evidence that was included in the Join Response computing the PoP evidence that was included in the Join Response
for this Client (see Section 4.3.1). for this Client (see Section 4.3.1).
Application profiles of this specification MUST specify the exact Application profiles of this specification MUST specify the exact
approaches used by the KDC to compute the PoP evidence to include approaches used by the KDC to compute the PoP evidence to include
in 'kdc_cred_verify', and MUST specify which of those approaches in the 'kdc_cred_verify' parameter and MUST specify which of those
is used in which case (REQ21). approaches is used in which case (REQ21).
If an application profile supports the presence of external If an application profile supports the presence of external
signature verifiers that send GET requests to this resource, then signature verifiers that send GET requests to this resource, then
the application profile MUST specify how external signature the application profile MUST specify how external signature
verifiers provide the KDC with a self-generated nonce to use as verifiers provide the KDC with a self-generated nonce to use as
N_C (REQ21). N_C (REQ21).
N_C and N_KDC expressed in CBOR diagnostic notation: N_C and N_KDC expressed in CBOR diagnostic notation:
N_C = h'25a8991cd700ac01' N_C = h'25a8991cd700ac01'
N_KDC = h'0b7db12aaff56da3' N_KDC = h'0b7db12aaff56da3'
N_C and N_KDC as CBOR encoded byte strings: N_C and N_KDC as CBOR encoded byte strings:
N_C = 0x4825a8991cd700ac01 N_C = 0x4825a8991cd700ac01
N_KDC = 0x480b7db12aaff56da3 N_KDC = 0x480b7db12aaff56da3
PoP input: PoP input:
0x48 25a8991cd700ac01 48 0b7db12aaff56da3 0x48 25a8991cd700ac01 48 0b7db12aaff56da3
Figure 24: Example of PoP input to compute 'kdc_cred_verify'
using CBOR encoding Figure 20: Example of PoP Input to Compute 'kdc_cred_verify'
Using CBOR Encoding
4.5.1.1. Retrieve the KDC's Authentication Credential 4.5.1.1. Retrieve the KDC's Authentication Credential
In case the KDC has an associated authentication credential as In case the KDC has an associated authentication credential as
required for the correct group operation, a group member or an required for the correct group operation, a group member or an
external signature verifier can contact the KDC to request the KDC's external signature verifier can contact the KDC to request the KDC's
authentication credential, by sending a CoAP GET request to the /ace- authentication credential by sending a CoAP GET request to the /ace-
group/GROUPNAME/kdc-cred endpoint at the KDC, where GROUPNAME group/GROUPNAME/kdc-cred endpoint at the KDC, where GROUPNAME
identifies the group. identifies the group.
Upon receiving the 2.05 (Content) response, the Client retrieves the Upon receiving the 2.05 (Content) response, the Client retrieves the
KDC's authentication credential from the 'kdc_cred' parameter, and KDC's authentication credential from the 'kdc_cred' parameter and
MUST verify the proof-of-possession (PoP) evidence specified in the MUST verify the proof-of-possession (PoP) evidence specified in the
'kdc_cred_verify' parameter. In case of successful verification of 'kdc_cred_verify' parameter. In case of successful verification of
the PoP evidence, the Client MUST store the obtained KDC's the PoP evidence, the Client MUST store the obtained KDC's
authentication credential and replace the currently stored one. authentication credential and replace the currently stored one.
The PoP evidence is verified by means of the same method used when The PoP evidence is verified by means of the same method used when
processing the Join Response (see Section 4.3.1). Application processing the Join Response (see Section 4.3.1). Application
profiles of this specification MUST specify the exact approaches used profiles of this specification MUST specify the exact approaches used
by the Client to verify the PoP evidence in 'kdc_cred_verify', and by the Client to verify the PoP evidence in 'kdc_cred_verify' and
MUST specify which of those approaches is used in which case (REQ21). MUST specify which of those approaches is used in which case (REQ21).
Figure 25 gives an overview of the exchange described above, while Figure 21 gives an overview of the exchange described above, while
Figure 26 shows an example. Figure 22 shows an example.
Group Group
Member KDC Member KDC
| | | |
| KDC Authentication Credential Request | | KDC Authentication Credential Request |
|------------------------------------------------------------>| |------------------------------------------------------------>|
| GET /ace-group/GROUPNAME/kdc-cred | | GET /ace-group/GROUPNAME/kdc-cred |
| | | |
|<-- KDC Authentication Credential Response: 2.05 (Content) --| |<-- KDC Authentication Credential Response: 2.05 (Content) --|
| | | |
Figure 25: Message Flow of KDC Authentication Credential Request- Figure 21: Message Flow of KDC Authentication Credential Request-
Response to Obtain the Authentication Credential of the KDC Response to Obtain the Authentication Credential of the KDC
Request: Request:
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "kdc.example.com" Uri-Host: "kdc.example.com"
Uri-Path: "ace-group" Uri-Path: "ace-group"
Uri-Path: "g1" Uri-Path: "g1"
Uri-Path: "kdc-cred" Uri-Path: "kdc-cred"
Payload: -
Response: Response:
Header: Content (Code=2.05) Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor" Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation, with AUTH_CRED_KDC Payload (in CBOR diagnostic notation):
and POP_EVIDENCE being CBOR byte strings): {
{ / kdc_cred / 17: h'a2026008a101a5010202419920012158
"kdc_nonce": h'0b7db12aaff56da3', 2065eda5a12577c2bae829437fe33870
"kdc_cred": AUTH_CRED_KDC, 1a10aaa375e1bb5b5de108de439c0855
"kdc_cred_verify": POP_EVIDENCE 1d2258201e52ed75701163f7f9e40ddf
} 9f341b3dc9ba860af7e0ca7ca7e9eecd
0084d19c',
/ kdc_nonce / 18: h'0b7db12aaff56da3',
/ kdc_cred_verify / 19: h'3fc54702aa56e1b2cb20284294c9106a
63f91bac658d69351210a031d8fc7c5f
f3e4be39445b1a3e83e1510d1aca2f2e
8a7c081c7645042b18aba9d1fad1bd9c'
}
Figure 26: Example of KDC Authentication Credential Request- Figure 22: Example of KDC Authentication Credential Request-
Response to Obtain the Authentication Credential of the KDC Response to Obtain the Authentication Credential of the KDC
4.6. /ace-group/GROUPNAME/policies 4.6. /ace-group/GROUPNAME/policies
This resource implements the GET handler. This resource implements the GET handler.
4.6.1. GET Handler 4.6.1. GET Handler
The handler expects a GET request. The handler expects a GET request.
In addition to what is defined in Section 4.1.2, the handler verifies In addition to what is defined in Section 4.1.2, the handler verifies
that the Client is a current member of the group. If the that the Client is a current member of the group. If the
verification fails, the KDC MUST reply with a 4.03 (Forbidden) error verification fails, the KDC MUST reply with a 4.03 (Forbidden) error
response. The response MUST have Content-Format set to application/ response. The response MUST have Content-Format "application/
concise-problem-details+cbor and is formatted as defined in concise-problem-details+cbor" and is formatted as defined in
Section 4.1.2. Within the Custom Problem Detail entry 'ace- Section 4.1.2. Within the Custom Problem Detail entry 'ace-
groupcomm-error', the value of the 'error-id' field MUST be set to 0 groupcomm-error', the value of the 'error-id' field MUST be set to 0
("Operation permitted only to group members"). ("Operation permitted only to group members").
If all verifications succeed, the handler replies with a 2.05 If all verifications succeed, the handler replies with a 2.05
(Content) response containing the list of policies for the group (Content) response containing the list of policies for the group
identified by GROUPNAME. The payload of the response is formatted as identified by GROUPNAME. The payload of the response is formatted as
a CBOR map including only the parameter 'group_policies' defined in a CBOR map including only the 'group_policies' parameter defined in
Section 4.3.1 and specifying the current policies in the group. If Section 4.3.1 and specifying the current policies in the group. If
the KDC does not store any policy, the payload is formatted as a the KDC does not store any policy, the payload is formatted as a CBOR
zero-length CBOR byte string. byte string of zero length (0x40).
The specific format and meaning of group policies MUST be specified The specific format and meaning of group policies MUST be specified
in the application profile (REQ20). in application profiles of this specification (REQ20).
4.6.1.1. Retrieve the Group Policies 4.6.1.1. Retrieve the Group Policies
A node in the group can contact the KDC to retrieve the current group A node in the group can contact the KDC to retrieve the current group
policies, by sending a CoAP GET request to the /ace-group/GROUPNAME/ policies by sending a CoAP GET request to the /ace-group/GROUPNAME/
policies endpoint at the KDC, where GROUPNAME identifies the group, policies endpoint at the KDC, which is formatted as defined in
and formatted as defined in Section 4.6.1 Section 4.6.1 and where GROUPNAME identifies the group.
Figure 27 gives an overview of the exchange described above, while Figure 23 gives an overview of the exchange described above, while
Figure 28 shows an example. Figure 24 shows an example.
Client KDC Client KDC
| | | |
|-- Policies Request: GET /ace-group/GROUPNAME/policies -->| |-- Policies Request: GET /ace-group/GROUPNAME/policies -->|
| | | |
|<----------- Policies Response: 2.05 (Content) -----------| |<----------- Policies Response: 2.05 (Content) -----------|
| | | |
Figure 27: Message Flow of Policies Request-Response Figure 23: Message Flow of Policies Request-Response
Request: Request:
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "kdc.example.com" Uri-Host: "kdc.example.com"
Uri-Path: "ace-group" Uri-Path: "ace-group"
Uri-Path: "g1" Uri-Path: "g1"
Uri-Path: "policies" Uri-Path: "policies"
Payload: -
Response: Response:
Header: Content (Code=2.05) Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor" Content-Format: 261 (application/ace-groupcomm+cbor)
Payload(in CBOR diagnostic notation): Payload(in CBOR diagnostic notation):
{ "group_policies": {"exp-delta": 120} } {
/ group_policies / 16: {
/ Expiration Delta / 2: 120
}
}
Figure 28: Example of Policies Request-Response Figure 24: Example of Policies Request-Response
4.7. /ace-group/GROUPNAME/num 4.7. /ace-group/GROUPNAME/num
This resource implements the GET handler. This resource implements the GET handler.
4.7.1. GET Handler 4.7.1. GET Handler
The handler expects a GET request. The handler expects a GET request.
In addition to what is defined in Section 4.1.2, the handler verifies In addition to what is defined in Section 4.1.2, the handler verifies
that the Client is a current member of the group. If the that the Client is a current member of the group. If the
verification fails, the KDC MUST reply with a 4.03 (Forbidden) error verification fails, the KDC MUST reply with a 4.03 (Forbidden) error
response. The response MUST have Content-Format set to application/ response. The response MUST have Content-Format "application/
concise-problem-details+cbor and is formatted as defined in concise-problem-details+cbor" and is formatted as defined in
Section 4.1.2. Within the Custom Problem Detail entry 'ace- Section 4.1.2. Within the Custom Problem Detail entry 'ace-
groupcomm-error', the value of the 'error-id' field MUST be set to 0 groupcomm-error', the value of the 'error-id' field MUST be set to 0
("Operation permitted only to group members"). ("Operation permitted only to group members").
If all verifications succeed, the handler returns a 2.05 (Content) If all verifications succeed, the handler returns a 2.05 (Content)
message containing an integer that represents the version number of message containing an integer that represents the version number of
the symmetric group keying material. This number is incremented on the symmetric group keying material. This number is incremented on
the KDC every time the KDC updates the symmetric group keying the KDC every time the KDC updates the symmetric group keying
material, before the new keying material is distributed. This number material before the new keying material is distributed. This number
is stored in persistent storage. is stored in persistent storage.
The payload of the response is formatted as a CBOR integer. The payload of the response is formatted as a CBOR integer.
4.7.1.1. Retrieve the Keying Material Version 4.7.1.1. Retrieve the Keying Material Version
A node in the group can contact the KDC to request information about A node in the group can contact the KDC to request information about
the version number of the symmetric group keying material, by sending the version number of the symmetric group keying material by sending
a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the
KDC, where GROUPNAME identifies the group, formatted as defined in KDC, which is formatted as defined in Section 4.7.1 and where
Section 4.7.1. In particular, the version is incremented by the KDC GROUPNAME identifies the group. In particular, the version is
every time the group keying material is renewed, before it is incremented by the KDC every time the group keying material is
distributed to the group members. renewed before it is distributed to the group members.
Figure 29 gives an overview of the exchange described above, while Figure 25 gives an overview of the exchange described above, while
Figure 30 shows an example. Figure 26 shows an example.
Client KDC Client KDC
| | | |
|---- Version Request: GET /ace-group/GROUPNAME/num ---->| |---- Version Request: GET /ace-group/GROUPNAME/num ---->|
| | | |
|<---------- Version Response: 2.05 (Content) -----------| |<---------- Version Response: 2.05 (Content) -----------|
| | | |
Figure 29: Message Flow of Version Request-Response Figure 25: Message Flow of Version Request-Response
Request: Request:
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "kdc.example.com" Uri-Host: "kdc.example.com"
Uri-Path: "ace-group" Uri-Path: "ace-group"
Uri-Path: "g1" Uri-Path: "g1"
Uri-Path: "num" Uri-Path: "num"
Payload: -
Response: Response:
Header: Content (Code=2.05) Header: Content (Code=2.05)
Payload(in CBOR diagnostic notation): Content-Format: 60 (application/cbor)
Payload (in CBOR diagnostic notation):
13 13
Figure 30: Example of Version Request-Response Figure 26: Example of Version Request-Response
4.8. /ace-group/GROUPNAME/nodes/NODENAME 4.8. /ace-group/GROUPNAME/nodes/NODENAME
This resource implements the GET, PUT, and DELETE handlers. This resource implements the GET, POST, and DELETE handlers.
In addition to what is defined in Section 4.1.2, each of the handlers In addition to what is defined in Section 4.1.2, each of the handlers
performs the following two verifications. performs the following two verifications.
* The handler verifies that the Client is a current member of the * The handler verifies that the Client is a current member of the
group. If the verification fails, the KDC MUST reply with a 4.03 group. If the verification fails, the KDC MUST reply with a 4.03
(Forbidden) error response. The response MUST have Content-Format (Forbidden) error response. The response MUST have Content-Format
set to application/concise-problem-details+cbor and is formatted "application/concise-problem-details+cbor" and is formatted as
as defined in Section 4.1.2. Within the Custom Problem Detail defined in Section 4.1.2. Within the Custom Problem Detail entry
entry 'ace-groupcomm-error', the value of the 'error-id' field 'ace-groupcomm-error', the value of the 'error-id' field MUST be
MUST be set to 0 ("Operation permitted only to group members"). set to 0 ("Operation permitted only to group members").
* The handler verifies that the node name of the Client is equal to * The handler verifies that the node name of the Client is equal to
NODENAME used in the url-path. If the verification fails, the NODENAME used in the url-path. If the verification fails, the
handler replies with a 4.03 (Forbidden) error response. handler replies with a 4.03 (Forbidden) error response.
4.8.1. GET Handler 4.8.1. GET Handler
The handler expects a GET request. The handler expects a GET request.
If all verifications succeed, the handler replies with a 2.05 If all verifications succeed, the handler replies with a 2.05
(Content) response containing both the group keying material and the (Content) response containing both the group keying material and the
individual keying material for the Client, or information enabling individual keying material for the Client or information enabling the
the Client to derive it. Client to derive it.
The payload of the response is formatted as a CBOR map, which The payload of the response is formatted as a CBOR map, which
includes the same fields of the response defined in Section 4.3.2. includes the same fields of the response defined in Section 4.3.2.
In particular, the format for the group keying material is the same In particular, the format for the group keying material is the same
as defined in the response of Section 4.3.2. If the 'exp' parameter as defined in the response of Section 4.3.2. If the 'exp' parameter
is included, the 'exi' parameter MUST also be included. If the is included, the 'exi' parameter MUST also be included. If the
parameter 'exi' is included, its value specifies the residual parameter 'exi' is included, its value specifies the residual
lifetime of the group keying material from the current time at the lifetime of the group keying material from the current time at the
KDC. KDC.
The CBOR map can include additional parameters that specify the The CBOR map can include additional parameters that specify the
individual keying material for the Client. The specific format of individual keying material for the Client. The specific format of
individual keying material for group members, or of the information individual keying material for group members or of the information to
to derive it, and corresponding CBOR label, MUST be specified in the derive such keying material MUST be defined in application profiles
application profile (REQ27) and registered in Section 11.7. of this specification (REQ27), together with the corresponding CBOR
map key that has to be registered in the "ACE Groupcomm Parameters"
registry defined in Section 11.7.
Optionally, the KDC can make the sub-resource at /ace- Optionally, the KDC can make the sub-resource at /ace-
group/GROUPNAME/nodes/NODENAME also Observable [RFC7641] for the group/GROUPNAME/nodes/NODENAME also observable [RFC7641] for the
associated node. In case the KDC removes that node from the group associated node. In case the KDC removes that node from the group
without having been explicitly asked for it, this allows the KDC to without having been explicitly asked for it, this allows the KDC to
send an unsolicited 4.04 (Not Found) response to the node as a send an unsolicited 4.04 (Not Found) response to the node as a
notification of eviction from the group (see Section 5). notification of eviction from the group (see Section 5).
Note that the node could have also been observing the resource at Note that the node could have also been observing the resource at
/ace-group/GROUPNAME, in order to be informed of changes in the /ace-group/GROUPNAME in order to be informed of changes in the group
keying material. In such a case, this method would result in largely keying material. In such a case, this method would result in largely
overlapping notifications received for the resource at /ace-group/ overlapping notifications received for the resource at /ace-group/
GROUPNAME and the sub-resource at /ace-group/GROUPNAME/nodes/ GROUPNAME and the sub-resource at /ace-group/GROUPNAME/nodes/
NODENAME. NODENAME.
In order to mitigate this, a node that supports the No-Response In order to mitigate this, a node that supports the CoAP No-Response
option [RFC7967] can use it when starting the observation of the sub- Option [RFC7967] can use it when starting the observation of the sub-
resource at /ace-group/GROUPNAME/nodes/NODENAME. In particular, the resource at /ace-group/GROUPNAME/nodes/NODENAME. In particular, the
GET observation request can also include the No-Response option, with GET observation request can also include the No-Response option, with
value set to 2 (Not interested in 2.xx responses). value set to 2 (Not interested in 2.xx responses).
4.8.1.1. Retrieve Group and Individual Keying Material 4.8.1.1. Retrieve Group and Individual Keying Material
When any of the following happens, a node MUST stop using the stored When any of the following happens, a node MUST stop using the stored
group keying material to protect outgoing messages, and SHOULD stop group keying material to protect outgoing messages and SHOULD stop
using it to decrypt and verify incoming messages. using it to decrypt and verify incoming messages.
* Upon expiration of the keying material, according to what is * Upon expiration of the keying material, according to what is
indicated by the KDC with the 'exp' and/or 'exi' parameter (e.g., indicated by the KDC through the 'exp' and/or 'exi' parameter
in a Join Response), or to a pre-configured value. (e.g., in a Join Response) or to a pre-configured value.
* Upon receiving a notification of revoked/renewed keying material * Upon receiving a notification of revoked/renewed keying material
from the KDC, possibly as part of an update of the keying material from the KDC, possibly as part of an update of the keying material
(rekeying) triggered by the KDC. (rekeying) triggered by the KDC.
* Upon receiving messages from other group members without being * Upon receiving messages from other group members without being
able to retrieve the keying material to correctly decrypt them. able to retrieve the keying material to correctly decrypt them.
This may be due to rekeying messages previously sent by the KDC, This may be due to rekeying messages previously sent by the KDC
that the Client was not able to receive or decrypt. that the Client was not able to receive or decrypt.
In either case, if it wants to continue participating in the group In either case, if it wants to continue participating in the group
communication, the Client has to request the latest keying material communication, the Client has to request the latest keying material
from the KDC. To this end, the Client sends a CoAP GET request to from the KDC. To this end, the Client sends a CoAP GET request to
the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC,
formatted as specified in Section 4.8.1. The Client can request the formatted as specified in Section 4.8.1. The Client can request the
latest keying material from the KDC before the currently stored, old latest keying material from the KDC before the currently stored, old
keying material reaches its expiration time. keying material reaches its expiration time.
Note that policies can be set up, so that the Client sends a Key Note that policies can be set up so that the Client sends a Key
Distribution Request to the KDC only after a given number of received Distribution Request to the KDC only after a given number of received
messages could not be decrypted (because of failed decryption messages could not be decrypted (because of failed decryption
processing or inability to retrieve the necessary keying material). processing or the inability to retrieve the necessary keying
material).
It is application dependent and pertaining to the particular message It is application dependent and pertaining to the used secure message
exchange (e.g., [I-D.ietf-core-oscore-groupcomm]) to set up these exchange (e.g., [GROUP-OSCORE]) to set up these policies for
policies for instructing Clients to retain incoming messages and for instructing Clients to retain incoming messages and for how long
how long (OPT11). This allows Clients to possibly decrypt such (OPT11). This allows Clients to possibly decrypt such messages after
messages after getting updated keying material, rather than just getting updated keying material, rather than just consider them
consider them invalid messages to discard right away. invalid messages to discard right away.
After having failed to decrypt messages from another group member and After having failed to decrypt messages from another group member and
having sent a Key Distribution Request to the KDC, the Client might having sent a Key Distribution Request to the KDC, the Client might
end up retrieving the same, latest group keying material that it end up retrieving the same, latest group keying material that it
already stores. In such a case, multiple failed decryptions might be already stores. In such a case, multiple failed decryptions might be
due to the message sender and/or the KDC that have changed their due to the message sender and/or the KDC that have changed their
authentication credential. Hence, the Client can retrieve such authentication credential. Hence, the Client can retrieve such
latest authentication credentials, by sending to the KDC an latest authentication credentials by sending to the KDC an
Authentication Credential Request (see Section 4.4.1.1 and Authentication Credential Request (see Sections 4.4.1.1 and 4.4.2.1)
Section 4.4.2.1) and a KDC Authentication Credential Request (see and a KDC Authentication Credential Request (see Section 4.5.1.1),
Section 4.5.1.1), respectively. respectively.
The Client can also send to the KDC a Key Distribution Request The Client can also send to the KDC a Key Distribution Request
without having been triggered by a failed decryption of a message without having been triggered by a failed decryption of a message
from another group member, if the Client wants to be sure that it from another group member, if the Client wants to be sure that it
currently stores the latest group keying material. If that is the currently stores the latest group keying material. If that is the
case, the Client will receive from the KDC the same group keying case, the Client will receive from the KDC the same group keying
material it already stores. material it already stores.
Figure 31 gives an overview of the exchange described above, while Figure 27 gives an overview of the exchange described above, while
Figure 32 shows an example. Figure 28 shows an example.
Client KDC Client KDC
| | | |
|------------------ Key Distribution Request: --------------->| |------------------ Key Distribution Request: --------------->|
| GET /ace-group/GROUPNAME/nodes/NODENAME | | GET /ace-group/GROUPNAME/nodes/NODENAME |
| | | |
|<-------- Key Distribution Response: 2.05 (Content) ---------| |<-------- Key Distribution Response: 2.05 (Content) ---------|
| | | |
Figure 31: Message Flow of Key Distribution Request-Response Figure 27: Message Flow of Key Distribution Request-Response
Request: Request:
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "kdc.example.com" Uri-Host: "kdc.example.com"
Uri-Path: "ace-group" Uri-Path: "ace-group"
Uri-Path: "g1" Uri-Path: "g1"
Uri-Path: "nodes" Uri-Path: "nodes"
Uri-Path: "c101" Uri-Path: "c101"
Payload: -
Response: Response:
Header: Content (Code=2.05) Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor" Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation, Payload (in CBOR diagnostic notation, with "ind-key" being the
with KEY and IND_KEY being CBOR byte strings, profile-specified label for individual keying material):
and "ind-key" being the profile-specified label {
for individual keying material): / gkty / 7: 65600,
{ "gkty": 13, "key": KEY, "num": 12, "ind-key": IND_KEY } / key / 8: h'73657373696f6e6b6579',
/ num / 9: 12,
"ind-key": h'fcae9023'
}
Figure 32: Example of Key Distribution Request-Response Figure 28: Example of Key Distribution Request-Response
4.8.2. PUT Handler 4.8.2. POST Handler
The PUT handler processes requests from a Client that asks for new The POST handler processes requests from a Client that asks for new
individual keying material, as required to process messages exchanged individual keying material, as required to process messages exchanged
in the group. in the group.
The handler expects a PUT request with empty payload. The handler expects a POST request with an empty payload.
In addition to what is defined in Section 4.1.2 and at the beginning In addition to what is defined in Section 4.1.2 and at the beginning
of Section 4.8, the handler verifies that this operation is of Section 4.8, the handler verifies that this operation is
consistent with the set of roles that the Client has in the group consistent with the set of roles that the Client has in the group
(REQ11). If the verification fails, the KDC MUST reply with a 4.00 (REQ11). If the verification fails, the KDC MUST reply with a 4.00
(Bad Request) error response. The response MUST have Content-Format (Bad Request) error response. The response MUST have Content-Format
set to application/concise-problem-details+cbor and is formatted as "application/concise-problem-details+cbor" and is formatted as
defined in Section 4.1.2. Within the Custom Problem Detail entry defined in Section 4.1.2. Within the Custom Problem Detail entry
'ace-groupcomm-error', the value of the 'error-id' field MUST be set 'ace-groupcomm-error', the value of the 'error-id' field MUST be set
to 1 ("Request inconsistent with the current roles"). to 1 ("Request inconsistent with the current roles").
If the KDC is currently not able to serve this request, i.e., to If the KDC is currently not able to serve this request, i.e., to
generate new individual keying material for the requesting Client, generate new individual keying material for the requesting Client,
the KDC MUST reply with a 5.03 (Service Unavailable) error response. the KDC MUST reply with a 5.03 (Service unavailable) error response.
The response MUST have Content-Format set to application/concise- The response MUST have Content-Format "application/concise-problem-
problem-details+cbor and is formatted as defined in Section 4.1.2. details+cbor" and is formatted as defined in Section 4.1.2. Within
Within the Custom Problem Detail entry 'ace-groupcomm-error', the the Custom Problem Detail entry 'ace-groupcomm-error', the value of
value of the 'error-id' field MUST be set to 4 ("No available node the 'error-id' field MUST be set to 4 ("No available individual
identifiers"). keying material").
If all verifications succeed, the handler replies with a 2.05 If all verifications succeed, the handler replies with a 2.04
(Content) response containing newly generated, individual keying (Changed) response containing newly generated individual keying
material for the Client. The payload of the response is formatted as material for the Client. The payload of the response is formatted as
a CBOR map. The specific format of newly-generated individual keying a CBOR map. The specific format of newly generated individual keying
material for group members, or of the information to derive it, and material for group members or of the information to derive such
corresponding CBOR label, MUST be specified in the application keying material MUST be defined in application profiles of this
profile (REQ27) and registered in Section 11.7. specification (REQ27), together with the corresponding CBOR map key
that has to be registered in the "ACE Groupcomm Parameters" registry
defined in Section 11.7.
The typical successful outcome consists in replying with newly The typical successful outcome consists in replying with newly
generated, individual keying material for the Client, as defined generated individual keying material for the Client, as defined
above. However, application profiles of this specification MAY also above. However, application profiles of this specification MAY also
extend this handler in order to achieve different akin outcomes extend this handler in order to achieve different akin outcomes
(OPT12), for instance: (OPT12), for instance:
* Not providing the Client with newly generated, individual keying * Not providing the Client with newly generated individual keying
material, but rather rekeying the whole group, i.e., providing all material, but rather rekeying the whole group, i.e., providing all
the current group members with newly generated group keying the current group members with newly generated group keying
material. material.
* Both providing the Client with newly generated, individual keying * Both providing the Client with newly generated individual keying
material, as well as rekeying the whole group, i.e., providing all material, as well as rekeying the whole group, i.e., providing all
the current group members with newly generated group keying the current group members with newly generated group keying
material. material.
In either case, the handler may specify the new group keying material In either case, the handler may specify the new group keying material
as part of the 2.05 (Content) response. as part of the 2.04 (Changed) response.
Note that this handler is not intended to accommodate requests from a Note that this handler is not intended to accommodate requests from a
group member to trigger a group rekeying, whose scheduling and group member to trigger a group rekeying, whose scheduling and
execution is an exclusive prerogative of the KDC (see also related execution is an exclusive prerogative of the KDC (also see related
security considerations in Section 10.2). security considerations in Section 10.2).
4.8.2.1. Request to Change Individual Keying Material 4.8.2.1. Request to Change Individual Keying Material
A Client may ask the KDC for new, individual keying material. For A Client may ask the KDC for new individual keying material. For
instance, this can be due to the expiration of such individual keying instance, this can be due to the expiration of such individual keying
material, or to the exhaustion of AEAD nonces, if an AEAD encryption material or to the exhaustion of Authenticated Encryption with
algorithm is used for protecting communications in the group. An Associated Data (AEAD) nonces if an AEAD encryption algorithm is used
example of individual keying material can simply be an individual for protecting communications in the group. An example of individual
encryption key associated with the Client. Hence, the Client may ask keying material can simply be an individual encryption key associated
for a new individual encryption key, or for new input material to with the Client. Hence, the Client may ask for a new individual
derive it. encryption key or for new input material to derive it.
To this end, the Client performs a Key Renewal Request-Response To this end, the Client performs a Key Renewal Request-Response
exchange with the KDC, i.e., it sends a CoAP PUT request to the /ace- exchange with the KDC, i.e., it sends a CoAP POST request to the
group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, which is
identifies the group and NODENAME is its node name, and formatted as formatted as defined in Section 4.8.1, where GROUPNAME identifies the
defined in Section 4.8.1. group and NODENAME is the node name of the Client.
Figure 33 gives an overview of the exchange described above, while Figure 29 gives an overview of the exchange described above, while
Figure 34 shows an example. Figure 30 shows an example.
Client KDC Client KDC
| | | |
|---------------- Key Renewal Request: ---------------->| |---------------- Key Renewal Request: ---------------->|
| PUT /ace-group/GROUPNAME/nodes/NODENAME | | POST /ace-group/GROUPNAME/nodes/NODENAME |
| | | |
|<-------- Key Renewal Response: 2.05 (Content) --------| |<-------- Key Renewal Response: 2.04 (Changed) --------|
| | | |
Figure 33: Message Flow of Key Renewal Request-Response Figure 29: Message Flow of Key Renewal Request-Response
Request: Request:
Header: PUT (Code=0.03) Header: POST (Code=0.02)
Uri-Host: "kdc.example.com" Uri-Host: "kdc.example.com"
Uri-Path: "ace-group" Uri-Path: "ace-group"
Uri-Path: "g1" Uri-Path: "g1"
Uri-Path: "nodes" Uri-Path: "nodes"
Uri-Path: "c101" Uri-Path: "c101"
Payload: -
Response: Response:
Header: Content (Code=2.05) Header: Changed (Code=2.04)
Content-Format: "application/ace-groupcomm+cbor" Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation, with IND_KEY being a Payload (in CBOR diagnostic notation, with "ind-key" being the
CBOR byte string, and "ind-key" being the profile-specified profile-specified label for individual keying material):
label for individual keying material): {
{ "ind-key": IND_KEY } "ind-key": h'b71acc28'
}
Figure 34: Example of Key Renewal Request-Response Figure 30: Example of Key Renewal Request-Response
Note that there is a difference between the Key Renewal Request in Note that there is a difference between the Key Renewal Request in
this section and the Key Distribution Request in Section 4.8.1.1. this section and the Key Distribution Request in Section 4.8.1.1.
The former asks the KDC for new individual keying material, while the The former asks the KDC for new individual keying material, while the
latter asks the KDC for the current group keying material together latter asks the KDC for the current group keying material together
with the current individual keying material. with the current individual keying material.
As discussed in Section 4.8.2, application profiles of this As discussed in Section 4.8.2, application profiles of this
specification may define alternative outcomes for the Key Renewal specification may define alternative outcomes for the Key Renewal
Request-Response exchange (OPT12), where the provisioning of new Request-Response exchange (OPT12), where the provisioning of new
individual keying material is replaced by or combined with the individual keying material is replaced by or combined with the
execution of a whole group rekeying. execution of a whole group rekeying.
4.8.3. DELETE Handler 4.8.3. DELETE Handler
The DELETE handler removes the node identified by NODENAME from the The DELETE handler removes the node identified by NODENAME from the
group identified by GROUPNAME. group identified by GROUPNAME.
The handler expects a DELETE request with empty payload. The handler expects a DELETE request with an empty payload.
In addition to what is defined in Section 4.1.2, the handler verifies In addition to what is defined in Section 4.1.2, the handler verifies
that the Client is a current member of the group. If the that the Client is a current member of the group. If the
verification fails, the KDC MUST reply with a 4.03 (Forbidden) error verification fails, the KDC MUST reply with a 4.03 (Forbidden) error
response. The response MUST have Content-Format set to application/ response. The response MUST have Content-Format "application/
concise-problem-details+cbor and is formatted as defined in concise-problem-details+cbor" and is formatted as defined in
Section 4.1.2. Within the Custom Problem Detail entry 'ace- Section 4.1.2. Within the Custom Problem Detail entry 'ace-
groupcomm-error', the value of the 'error-id' field MUST be set to 0 groupcomm-error', the value of the 'error-id' field MUST be set to 0
("Operation permitted only to group members"). ("Operation permitted only to group members").
If all verification succeeds, the handler performs the actions If all verification succeeds, the handler performs the actions
defined in Section 5 and replies with a 2.02 (Deleted) response with defined in Section 5 and replies with a 2.02 (Deleted) response with
empty payload. an empty payload.
4.8.3.1. Leave the Group 4.8.3.1. Leave the Group
A Client can actively request to leave the group. In this case, the A Client can actively request to leave the group. In this case, the
Client sends a CoAP DELETE request to the endpoint /ace- Client sends a CoAP DELETE request to the endpoint /ace-
group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME identifies group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME identifies
the group and NODENAME is its node name, formatted as defined in the group and NODENAME is the Client's node name.
Section 4.8.3
Note that, after having left the group, the Client may wish to join Note that, after having left the group, the Client may wish to join
it again. Then, as long as the Client is still authorized to join it again. Then, as long as the Client is still authorized to join
the group, i.e., the associated access token is still valid, the the group, i.e., the associated access token is still valid, the
Client can request to re-join the group directly to the KDC (see Client can request to rejoin the group directly to the KDC (see
Section 4.3.1.1), without having to retrieve a new access token from Section 4.3.1.1) without having to retrieve a new access token from
the AS. the AS.
4.9. /ace-group/GROUPNAME/nodes/NODENAME/cred 4.9. /ace-group/GROUPNAME/nodes/NODENAME/cred
This resource implements the POST handler. This resource implements the POST handler.
4.9.1. POST Handler 4.9.1. POST Handler
The POST handler is used to replace the stored authentication The POST handler is used to replace the stored authentication
credential of this Client (identified by NODENAME) with the one credential of this Client (identified by NODENAME) with the one
specified in the request at the KDC, for the group identified by specified in the request at the KDC for the group identified by
GROUPNAME. GROUPNAME.
The handler expects a POST request with payload as specified in The handler expects a POST request with the payload as specified in
Section 4.3.1, with the difference that it includes only the Section 4.3.1, with the difference that the payload includes only the
parameters 'client_cred', 'cnonce', and 'client_cred_verify'. parameters 'client_cred', 'cnonce', and 'client_cred_verify'.
The PoP evidence included in the 'client_cred_verify' parameter is The PoP evidence included in the 'client_cred_verify' parameter is
computed in the same way considered in Section 4.3.1 and defined by computed in the same way considered in Section 4.3.1 and defined by
the specific application profile (REQ14), by using the following to the specific application profile (REQ14) by using the following to
build the PoP input: i) the same scope entry specified by the Client build the PoP input: i) the same scope entry specified by the Client
in the 'scope' parameter of the latest Join Request that the Client in the 'scope' parameter of the latest Join Request that the Client
sent to the KDC in order to join the group identified by GROUPNAME; sent to the KDC in order to join the group identified by GROUPNAME;
ii) the latest N_S value stored by the Client; iii) a new N_C nonce ii) the latest N_S value stored by the Client; and iii) a new N_C
generated by the Client and specified in the parameter 'cnonce' of nonce generated by the Client and specified in the parameter 'cnonce'
this request. of this request.
An example of PoP input to compute 'client_cred_verify' using CBOR An example of PoP input to compute 'client_cred_verify' using CBOR
encoding is given in Figure 35. encoding is given in Figure 31.
It is REQUIRED of application profiles to define the specific formats It is REQUIRED for application profiles to define the specific
of authentication credentials that are acceptable to use in the group formats of authentication credentials that are acceptable to use in
(REQ6). the group (REQ6).
In addition to what is defined in Section 4.1.2 and at the beginning In addition to what is defined in Section 4.1.2 and at the beginning
of Section 4.8, the handler verifies that this operation is of Section 4.8, the handler verifies that this operation is
consistent with the set of roles that the node has in the group. If consistent with the set of roles that the node has in the group. If
the verification fails, the KDC MUST reply with a 4.00 (Bad Request) the verification fails, the KDC MUST reply with a 4.00 (Bad Request)
error response. The response MUST have Content-Format set to error response. The response MUST have Content-Format "application/
application/concise-problem-details+cbor and is formatted as defined concise-problem-details+cbor" and is formatted as defined in
in Section 4.1.2. Within the Custom Problem Detail entry 'ace- Section 4.1.2. Within the Custom Problem Detail entry 'ace-
groupcomm-error', the value of the 'error-id' field MUST be set to 1 groupcomm-error', the value of the 'error-id' field MUST be set to 1
("Request inconsistent with the current roles"). ("Request inconsistent with the current roles").
If the KDC cannot retrieve the 'kdcchallenge' associated with this If the KDC cannot retrieve the 'kdcchallenge' associated with this
Client (see Section 3.3), the KDC MUST reply with a 4.00 (Bad Client (see Section 3.3), the KDC MUST reply with a 4.00 (Bad
Request) error response, which MUST also have Content-Format Request) error response, which MUST also have Content-Format
application/ace-groupcomm+cbor. The payload of the error response is "application/ace-groupcomm+cbor". The payload of the error response
a CBOR map including a newly generated 'kdcchallenge' value. This is is a CBOR map including the 'kdcchallenge' parameter, which specifies
specified in the 'kdcchallenge' parameter. In such a case the KDC a newly generated 'kdcchallenge' value. In such a case, the KDC MUST
MUST store the newly generated value as the 'kdcchallenge' value store the newly generated value as the 'kdcchallenge' value
associated with this Client, replacing the currently stored value (if associated with this Client, replacing the currently stored value (if
any). any).
Otherwise, the handler checks that the authentication credential Otherwise, the handler checks that the authentication credential
specified in the 'client_cred' field is valid for the group specified in the 'client_cred' field is valid for the group
identified by GROUPNAME. That is, the handler checks that the identified by GROUPNAME. That is, the handler checks that the
authentication credential is encoded according to the format used in authentication credential is encoded according to the format used in
the group, is intended for the public key algorithm used in the the group, is intended for the public key algorithm used in the
group, and is aligned with the possible associated parameters used in group, and is aligned with the possible associated parameters used in
the group. If that cannot be successfully verified, the handler MUST the group. If that cannot be successfully verified, the handler MUST
reply with a 4.00 (Bad Request) error response. The response MUST reply with a 4.00 (Bad Request) error response. The response MUST
have Content-Format set to application/concise-problem-details+cbor have Content-Format "application/concise-problem-details+cbor" and is
and is formatted as defined in Section 4.1.2. Within the Custom formatted as defined in Section 4.1.2. Within the Custom Problem
Problem Detail entry 'ace-groupcomm-error', the value of the 'error- Detail entry 'ace-groupcomm-error', the value of the 'error-id' field
id' field MUST be set to 2 ("Authentication credential incompatible MUST be set to 2 ("Authentication credential incompatible with the
with the group configuration"). group configuration").
Otherwise, the handler verifies the PoP evidence contained in the Otherwise, the handler verifies the PoP evidence conveyed in the
'client_cred_verify' field of the request, by using the 'client_cred_verify' parameter of the request, by using the
authentication credential specified in the 'client_cred' field, as authentication credential specified in the 'client_cred' parameter as
well as the same way considered in Section 4.3.1 and defined by the well as the same way considered in Section 4.3.1 and defined by the
specific application profile (REQ14). If the PoP evidence does not specific application profile (REQ14). If the PoP evidence does not
pass verification, the handler MUST reply with a 4.00 (Bad Request) pass verification, the handler MUST reply with a 4.00 (Bad Request)
error response. The response MUST have Content-Format set to error response. The response MUST have Content-Format "application/
application/concise-problem-details+cbor and is formatted as defined concise-problem-details+cbor" and is formatted as defined in
in Section 4.1.2. Within the Custom Problem Detail entry 'ace- Section 4.1.2. Within the Custom Problem Detail entry 'ace-
groupcomm-error', the value of the 'error-id' field MUST be set to 3 groupcomm-error', the value of the 'error-id' field MUST be set to 3
("Invalid Proof-of-Possession evidence"). ("Invalid proof-of-possession evidence").
If all verifications succeed, the handler performs the following If all verifications succeed, the handler performs the following
actions. actions.
* The handler associates the authentication credential from the * The handler associates the authentication credential from the
'client_cred' field of the request with the node identifier 'client_cred' parameter of the request with the node identifier
NODENAME, as well as with the access token associated with the NODENAME, as well as with the access token associated with the
node identified by NODENAME. node identified by NODENAME.
* In the stored list of group members' authentication credentials * In the stored list of group members' authentication credentials
for the group identified by GROUPNAME, the handler replaces the for the group identified by GROUPNAME, the handler replaces the
authentication credential of the node identified by NODENAME with authentication credential of the node identified by NODENAME with
the authentication credential specified in the 'client_cred' field the authentication credential specified in the 'client_cred'
of the request. parameter of the request.
Then, the handler replies with a 2.04 (Changed) response, which does Then, the handler replies with a 2.04 (Changed) response, which does
not include a payload. not include a payload.
scope, N_S, and N_C expressed in CBOR diagnostic notation: scope, N_S, and N_C expressed in CBOR diagnostic notation:
scope = h'826667726f7570316673656e646572' scope = h'826667726f7570316673656e646572'
N_S = h'018a278f7faab55a' N_S = h'018a278f7faab55a'
N_C = h'0446baefc56111bf' N_C = h'0446baefc56111bf'
scope, N_S, and N_C as CBOR encoded byte strings: scope, N_S, and N_C as CBOR encoded byte strings:
scope = 0x4f826667726F7570316673656E646572 scope = 0x4f826667726F7570316673656E646572
N_S = 0x48018a278f7faab55a N_S = 0x48018a278f7faab55a
N_C = 0x480446baefc56111bf N_C = 0x480446baefc56111bf
PoP input: PoP input:
0x4f 826667726f7570316673656e646572 0x4f 826667726f7570316673656e646572
48 018a278f7faab55a 48 0446baefc56111bf 48 018a278f7faab55a 48 0446baefc56111bf
Figure 35: Example of PoP input to compute 'client_cred_verify' Figure 31: Example of PoP Input to Compute 'client_cred_verify'
using CBOR encoding Using CBOR Encoding
4.9.1.1. Uploading an Authentication Credential 4.9.1.1. Uploading an Authentication Credential
In case the KDC maintains the authentication credentials of group In case the KDC maintains the authentication credentials of group
members, a node in the group can contact the KDC to upload a new members, a node in the group can contact the KDC to upload a new
authentication credential to use in the group, and to replace the authentication credential to use in the group and to replace the
currently stored one. currently stored one.
To this end, the Client performs an Authentication Credential Update To this end, the Client performs an Authentication Credential Update
Request-Response exchange with the KDC, i.e., it sends a CoAP POST Request-Response exchange with the KDC, i.e., it sends a CoAP POST
request to the /ace-group/GROUPNAME/nodes/NODENAME/cred endpoint at request to the /ace-group/GROUPNAME/nodes/NODENAME/cred endpoint at
the KDC, where GROUPNAME identifies the group and NODENAME is its the KDC, where GROUPNAME identifies the group and NODENAME is the
node name. Client's node name.
The request is formatted as specified in Section 4.9.1. The request is formatted as specified in Section 4.9.1.
Figure 36 gives an overview of the exchange described above, while Figure 32 gives an overview of the exchange described above, while
Figure 37 shows an example. Figure 33 shows an example.
Client KDC Client KDC
| | | |
|----------- Authentication Credential Update Request: --------->| |----------- Authentication Credential Update Request: --------->|
| POST /ace-group/GROUPNAME/nodes/NODENAME/cred | | POST /ace-group/GROUPNAME/nodes/NODENAME/cred |
| | | |
|<-- Authentication Credential Update Response: 2.04 (Changed) --| |<-- Authentication Credential Update Response: 2.04 (Changed) --|
| | | |
Figure 36: Message Flow of Authentication Credential Update Figure 32: Message Flow of Authentication Credential Update
Request-Response Request-Response
Request: Request:
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "kdc.example.com" Uri-Host: "kdc.example.com"
Uri-Path: "ace-group" Uri-Path: "ace-group"
Uri-Path: "g1" Uri-Path: "g1"
Uri-Path: "nodes" Uri-Path: "nodes"
Uri-Path: "c101" Uri-Path: "c101"
Uri-Path: "cred" Uri-Path: "cred"
Content-Format: "application/ace-groupcomm+cbor" Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation, with AUTH_CRED Payload (in CBOR diagnostic notation):
and POP_EVIDENCE being CBOR byte strings): {
{ "client_cred": AUTH_CRED, "cnonce": h'0446baefc56111bf', / client_cred / 5: h'a2026008a101a501020241fc20012158
"client_cred_verify": POP_EVIDENCE } 20bac5b11cad8f99f9c72b05cf4b9e26
d244dc189f745228255a219a86d6a09e
ff22582020138bf82dc1b6d562be0fa5
4ab7804a3a64b6d72ccfed6b6fb6ed28
bbfc117e',
/ cnonce / 6: h'0446baefc56111bf',
/ client_cred_verify / 24: h'e2aeafd40d69d19dfe6e52077c5d7ff4
e408282cbefb5d06cbf414af2e19d982
ac45ac98b8544c908b4507de1e90b717
c3d34816fe926a2b98f53afd2fa0f30a'
}
Response: Response:
Header: Changed (Code=2.04) Header: Changed (Code=2.04)
Payload: -
Figure 37: Example of Authentication Credential Update Request- Figure 33: Example of Authentication Credential Update Request-
Response Response
Additionally, after updating its own authentication credential, a Additionally, after updating its own authentication credential, a
group member MAY send to the group a number of requests including an group member MAY send to the group a number of requests, including an
identifier of the updated authentication credential, to notify other identifier of the updated authentication credential, to notify other
group members that they have to retrieve it. How this is done group members that they have to retrieve it. How this is done
depends on the group communication protocol used, and therefore is depends on the group communication protocol used and therefore is
application profile specific (OPT13). application profile specific (OPT13).
5. Removal of a Group Member 5. Removal of a Group Member
A Client identified by NODENAME may be removed from a group A Client identified by NODENAME may be removed from a group
identified by GROUPNAME where it is a member, for example due to the identified by GROUPNAME where it is a member, for example, due to the
following reasons. following reasons.
1. The Client explicitly asks to leave the group, as defined in 1. The Client explicitly asks to leave the group, as defined in
Section 4.8.3.1. Section 4.8.3.1.
2. The node has been found compromised or is suspected so. The KDC 2. The node has been found compromised or is suspected so. The KDC
is expected to determine that a group member has to be evicted is expected to determine that a group member has to be evicted
either through its own means, or based on information that it either through its own means or based on information that it
obtains from a trusted source (e.g., an Intrusion Detection obtains from a trusted source (e.g., an Intrusion Detection
System, or an issuer of authentication credentials). Additional System or an issuer of authentication credentials). Additional
mechanics, protocols, and interfaces at the KDC that can support mechanics, protocols, and interfaces at the KDC that can support
this are out of the scope of this document. this are out of the scope of this document.
3. The Client's authorization to be a group member with the current 3. The Client's authorization to be a group member with the current
roles is not valid anymore, i.e., the access token has expired or roles is not valid anymore, i.e., the access token has expired or
has been revoked. If the AS provides token introspection (see has been revoked. If the AS provides token introspection (see
Section 5.9 of [RFC9200]), the KDC can optionally use it and Section 5.9 of [RFC9200]), the KDC can optionally use it and
check whether the Client is still authorized. check whether the Client is still authorized.
In either case, the KDC performs the following actions. In all cases, the KDC performs the following actions.
* The KDC removes the Client from the list of current members of the * The KDC removes the Client from the list of current members of the
group. When doing so, the KDC deletes the currently stored value group. When doing so, the KDC deletes the currently stored value
of 'clientchallenge' for that Client, which was specified in the of 'clientchallenge' for that Client, which was specified in the
latest Join Request that the Client sent to the KDC in order to latest Join Request that the Client sent to the KDC in order to
join the group (see Section 4.3.1). join the group (see Section 4.3.1).
* In case of forced eviction, i.e., for cases 2 and 3 above, the KDC * In case of forced eviction, i.e., for cases 2 and 3 above, the KDC
deletes the authentication credential of the removed Client, if it deletes the authentication credential of the removed Client if it
acts as a repository of authentication credentials for group acts as a repository of authentication credentials for group
members. members.
* If the removed Client is registered as an observer of the group- * If the removed Client is registered as an observer of the group-
membership resource at /ace-group/GROUPNAME, the KDC removes the membership resource at /ace-group/GROUPNAME, the KDC removes the
Client from the list of observers of that resource. Client from the list of observers of that resource.
* If the sub-resource nodes/NODENAME was created for the removed * If the sub-resource /nodes/NODENAME was created for the removed
Client, the KDC deletes that sub-resource. Client, the KDC deletes that sub-resource.
In case of forced eviction, i.e., for cases 2 and 3 above, the KDC In case of forced eviction, i.e., for cases 2 and 3 above, the KDC
MAY explicitly inform the removed Client, by means of the MAY explicitly inform the removed Client by means of the following
following methods. methods.
- If the evicted Client implements the 'control_uri' resource - If the evicted Client implements the 'control_uri' resource
specified in Section 4.3.1, the KDC sends a DELETE request, (see Section 4.3.1), the KDC sends a DELETE request to that
targeting the URI specified in the 'control_uri' parameter of resource, targeting the URI specified in the 'control_uri'
the Join Request (see Section 4.3.1). parameter of the Join Request (see Section 4.3.1).
- If the evicted Client is observing its associated sub-resource - If the evicted Client is observing its associated sub-resource
at /ace-group/GROUPNAME/nodes/NODENAME (see Section 4.8.1), the at /ace-group/GROUPNAME/nodes/NODENAME (see Section 4.8.1), the
KDC sends an unsolicited 4.04 (Not Found) error response, which KDC sends an unsolicited 4.04 (Not Found) error response, which
does not include the Observe option and indicates that the does not include the Observe Option and indicates that the
observed resource has been deleted (see Section 3.2 of observed resource has been deleted (see Section 3.2 of
[RFC7641]). [RFC7641]).
The response MUST have Content-Format set to application/ The response MUST have Content-Format "application/concise-
concise-problem-details+cbor and is formatted as defined in problem-details+cbor" and is formatted as defined in
Section 4.1.2. Within the Custom Problem Detail entry 'ace- Section 4.1.2. Within the Custom Problem Detail entry 'ace-
groupcomm-error', the value of the 'error-id' field MUST be set groupcomm-error', the value of the 'error-id' field MUST be set
to 5 ("Group membership terminated"). to 5 ("Group membership terminated").
* If forward security is prescribed by application policies * If forward security is prescribed by application policies
installed at the KDC or by the used application profile of this installed at the KDC or by the used application profile of this
specification, then the KDC MUST generate new group keying specification, then the KDC MUST generate new group keying
material and securely distribute it to all the current group material and securely distribute it to all the current group
members except the leaving node (see Section 6). members except the leaving node (see Section 6).
6. Group Rekeying Process 6. Group Rekeying Process
A group rekeying is started and driven by the KDC. The KDC is not A group rekeying is started and driven by the KDC. The KDC is not
intended to accommodate explicit requests from group members to intended to accommodate explicit requests from group members to
trigger a group rekeying. That is, the scheduling and execution of a trigger a group rekeying. That is, the scheduling and execution of a
group rekeying is an exclusive prerogative of the KDC. Reasons that group rekeying is an exclusive prerogative of the KDC. Some reasons
can trigger a group rekeying are a change in the group membership, that can trigger a group rekeying include a change in the group
the current group keying material approaching its expiration time, or membership, the current group keying material approaching its
a regularly scheduled update of the group keying material. expiration time, or a regularly scheduled update of the group keying
material.
The KDC can perform a group rekeying before the current group keying The KDC can perform a group rekeying before the current group keying
material expires, unless it is acceptable or there are reasons to material expires, unless it is acceptable or there are reasons to
temporarily pause secure communications in the group, following the temporarily pause secure communications in the group, following the
expiration of the current keying material. For example, a pause in expiration of the current keying material. For example, a pause in
the group communication might have been scheduled to start anyway the group communication might have been scheduled to start anyway
when the group keying material expires, e.g., to allow maintenance when the group keying material expires, e.g., to allow maintenance
operations on the group members. As another example, the KDC might operations on the group members. As another example, the KDC might
be carrying out a verification that some group members are seemingly be carrying out a verification that some group members are seemingly
compromised and to be evicted, and this requires to be completed in compromised and to be evicted, and this needs to be completed in
order to appropriately define and schedule the exact rekeying process order to appropriately define and schedule the exact rekeying process
to perform. As a result, the KDC could delay the execution of the to perform. As a result, the KDC could delay the execution of the
group rekeying. group rekeying.
The KDC MUST increment the version number NUM of the current keying The KDC MUST increment the version number NUM of the current keying
material, before distributing the newly generated keying material material before distributing the newly generated keying material with
with version number NUM+1 to the group. Once the group rekeying is version number NUM+1 to the group. Once the group rekeying is
completed, the KDC MUST delete the old keying material and SHOULD completed, the KDC MUST delete the old keying material and SHOULD
store the newly distributed keying material in persistent storage. store the newly distributed keying material in persistent storage.
Distributing the new group keying material requires the KDC to send Distributing the new group keying material requires the KDC to send
multiple rekeying messages to the group members. Depending on the multiple rekeying messages to the group members. Depending on the
rekeying scheme used in the group and the reason that has triggered rekeying scheme used in the group and the reason that has triggered
the rekeying process, each rekeying message can be intended for one the rekeying process, each rekeying message can be intended for one
or multiple group members, hereafter referred to as target group or multiple group members, hereafter referred to as target group
members. The KDC MUST support at least the "Point-to-Point" group members. The KDC MUST support at least the "Point-to-Point" group
rekeying scheme in Section 6.1 and MAY support additional ones. rekeying scheme described in Section 6.1 and MAY support additional
ones.
Each rekeying message MUST have Content-Format set to application/ Each rekeying message MUST have Content-Format "application/ace-
ace-groupcomm+cbor and its payload formatted as a CBOR map, which groupcomm+cbor" and its payload is formatted as a CBOR map, which
MUST include at least the information specified in the Key MUST include at least the information specified in the Key
Distribution Response message (see Section 4.3.2), i.e., the Distribution Response message (see Section 4.3.2), i.e., the
parameters 'gkty', 'key', and 'num' defined in Section 4.3.1. The parameters 'gkty', 'key', and 'num' defined in Section 4.3.1. The
CBOR map SHOULD also include the parameters 'exp' and 'exi'. If the CBOR map SHOULD also include the parameters 'exp' and 'exi'. If the
'exp' parameter is included, the 'exi' parameter MUST also be 'exp' parameter is included, the 'exi' parameter MUST also be
included. The CBOR map MAY include the parameter 'mgt_key_material' included. The CBOR map MAY include the parameter 'mgt_key_material'
specifying new administrative keying material for the target group to specify new administrative keying material for the target group
members, if relevant for the used rekeying scheme. members if it is relevant for the used rekeying scheme.
A rekeying message may include additional information, depending on A rekeying message may include additional information, depending on
the rekeying scheme used in the group, the reason that has triggered the rekeying scheme used in the group, the reason that has triggered
the rekeying process, and the specific target group members. In the rekeying process, and the specific target group members. In
particular, if the group rekeying is performed due to one or multiple particular, if the group rekeying is performed due to one or multiple
Clients that have joined the group and the KDC acts as a repository Clients that have joined the group and the KDC acts as a repository
of authentication credentials of the group members, then a rekeying of authentication credentials of the group members, then a rekeying
message MAY also include the authentication credentials that those message MAY also include the authentication credentials that those
Clients use in the group, together with the roles and node identifier Clients use in the group, together with the roles and node identifier
that the corresponding Client has in the group. It is RECOMMENDED to that each of such Clients has in the group. It is RECOMMENDED to
specify this information by means of the parameters 'creds', specify this information by means of the parameters 'creds',
'peer_roles', and 'peer_identifiers', like it is done in the Join 'peer_roles', and 'peer_identifiers', like it is done in the Join
Response message (see Section 4.3.1). Response message (see Section 4.3.1).
The complete format of a rekeying message, including the encoding and The complete format of a rekeying message, including the encoding and
content of the 'mgt_key_material' parameter, has to be defined in content of the 'mgt_key_material' parameter, has to be defined in
separate specifications aimed at profiling the used rekeying scheme separate specifications aimed at profiling the used rekeying scheme
in the context of the used application profile of this specification. in the context of the used application profile of this specification.
As a particular case, an application profile of this specification As a particular case, an application profile of this specification
MAY define additional information to include in rekeying messages for MAY define additional information to include in rekeying messages for
the "Point-to-Point" group rekeying scheme in Section 6.1 (OPT14). the "Point-to-Point" group rekeying scheme defined in Section 6.1
(OPT14).
Consistently with the used group rekeying scheme, the actual delivery Consistently with the used group rekeying scheme, the actual delivery
of rekeying messages can occur through different approaches, as of rekeying messages can occur through different approaches, as
discussed in the following Section 6.1 and Section 6.2. discussed in Sections 6.1 and 6.2.
The possible, temporary misalignment of the keying material stored by The possible, temporary misalignment of the keying material stored by
the different group members due to a group rekeying is discussed in the different group members due to a group rekeying is discussed in
Section 6.3. Further security considerations related to the group Section 6.3. Further security considerations related to the group
rekeying process are compiled in Section 10.2. rekeying process are compiled in Section 10.2.
6.1. Point-to-Point Group Rekeying 6.1. Point-to-Point Group Rekeying
A point-to-point group rekeying consists in the KDC sending one A point-to-point group rekeying consists in the KDC sending one
individual rekeying message to each target group member. In individual rekeying message to each target group member. In
particular, the rekeying message is protected by means of the particular, the rekeying message is protected by means of the secure
security association between the KDC and the target group member in communication association between the KDC and the target group member
question, as per the used application profile of this specification in question, as per the used application profile of this
and the used transport profile of ACE. specification and the used transport profile of ACE.
This is the approach taken by the basic "Point-to-Point" group This is the approach taken by the basic "Point-to-Point" group
rekeying scheme, that the KDC can explicitly signal in the Join rekeying scheme, which the KDC can explicitly indicate in the Join
Response (see Section 4.3.1), through the 'rekeying_scheme' parameter Response (see Section 4.3.1), through the 'rekeying_scheme' parameter
specifying the value 0. specifying the value 0.
When taking this approach in the group identified by GROUPNAME, the When taking this approach in the group identified by GROUPNAME, the
KDC can practically deliver the rekeying messages to the target group KDC can practically deliver the rekeying messages to the target group
members in different, co-existing ways. members in different, coexisting ways.
* The KDC SHOULD make the /ace-group/GROUPNAME resource Observable * The KDC SHOULD make the /ace-group/GROUPNAME resource observable
[RFC7641]. Thus, upon performing a group rekeying, the KDC can [RFC7641]. Thus, upon performing a group rekeying, the KDC can
distribute the new group keying material through individual distribute the new group keying material through individual
notification responses sent to the target group members that are notification responses sent to the target group members that are
also observing that resource. also observing that resource.
In case the KDC deletes the group (and thus deletes the /ace- In case the KDC deletes the group (and thus deletes the /ace-
group/GROUPNAME resource), relying on CoAP Observe as discussed group/GROUPNAME resource), relying on CoAP Observe as discussed
above also allows the KDC to send an unsolicited 4.04 (Not Found) above also allows the KDC to send an unsolicited 4.04 (Not Found)
response to each observer group member, as a notification of group response to each observer group member as a notification of group
termination. The response MUST have Content-Format set to termination. The response MUST have Content-Format "application/
application/concise-problem-details+cbor and is formatted as concise-problem-details+cbor" and is formatted as defined in
defined in Section 4.1.2. Within the Custom Problem Detail entry Section 4.1.2. Within the Custom Problem Detail entry 'ace-
'ace-groupcomm-error', the value of the 'error-id' field MUST be groupcomm-error', the value of the 'error-id' field MUST be set to
set to 6 ("Group deleted"). 6 ("Group deleted").
* If a target group member specified a URI in the 'control_uri' * If a target group member specified a URI in the 'control_uri'
parameter of the Join Request upon joining the group (see parameter of the Join Request upon joining the group (see
Section 4.3.1), the KDC can provide that group member with the new Section 4.3.1), the KDC can provide that group member with the new
group keying material by sending a unicast POST request to that group keying material by sending a unicast POST request to that
URI. URI.
A Client that does not plan to observe the /ace-group/GROUPNAME A Client that does not plan to observe the /ace-group/GROUPNAME
resource at the KDC SHOULD provide a URI in the 'control_uri' resource at the KDC SHOULD specify a URI in the 'control_uri'
parameter of the Join Request upon joining the group. parameter of the Join Request upon joining the group.
If the KDC has to send a rekeying message to a target group member, If the KDC has to send a rekeying message to a target group member,
but this did not include the 'control_uri' parameter in the Join but this did not include the 'control_uri' parameter in the Join
Request and is not a registered observer for the /ace-group/GROUPNAME Request and is not a registered observer for the /ace-group/GROUPNAME
resource, then that target group member would not be able to resource, then that target group member will not be able to
participate in the group rekeying. Later on, after having repeatedly participate in the group rekeying. Later on, after having repeatedly
failed to successfully exchange secure messages in the group, that failed to successfully exchange secure messages in the group, that
group member can retrieve the current group keying material from the group member can retrieve the current group keying material from the
KDC, by sending a GET request to /ace-group/GROUPNAME or /ace- KDC, by sending a GET request to the /ace-group/GROUPNAME or /ace-
group/GROUPNAME/nodes/NODENAME (see Section 4.3.2 and Section 4.8.1, group/GROUPNAME/nodes/NODENAME resource at the KDC (see Sections
respectively). 4.3.2 and 4.8.1, respectively).
Figure 38 provides an example of point-to-point group rekeying. In Figure 34 provides an example of point-to-point group rekeying. In
particular, the example makes the following assumptions. particular, the example makes the following assumptions:
* The group currently consists of four group members, namely C1, C2, * The group currently consists of four group members, namely C1, C2,
C3, and C4. C3, and C4.
* Each group member, when joining the group, provided the KDC with a * Each group member, when joining the group, provided the KDC with a
URI in the 'control_uri' parameter, with url-path "grp-rek". URI in the 'control_uri' parameter with url-path "grp-rek".
* Before the group rekeying is performed, the keying material used * Before the group rekeying is performed, the keying material used
in the group has version number num=5. in the group has version number num=5.
* The KDC performs the group rekeying in such a way to evict the * The KDC performs the group rekeying in such a way to evict the
group member C3, which has been found to be compromised. group member C3, which has been found to be compromised.
In the example, the KDC individually rekeys the group members In the example, the KDC individually rekeys the group members
intended to remain in the group (i.e., C1, C2, and C4), by means of intended to remain in the group (i.e., C1, C2, and C4) by means of
one rekeying message each. one rekeying message each.
.----------------------------------------------------------------. .----------------------------------------------------------------.
| KDC | | KDC |
'----------------------------------------------------------------' '----------------------------------------------------------------'
| | | | | |
Group | Group | Group | Group | Group | Group |
keying | keying | keying | keying | keying | keying |
material | material | material | material | material | material |
(num=6) | (num=6) | (num=6) | (num=6) | (num=6) | (num=6) |
skipping to change at page 78, line 30 skipping to change at line 3648
v v v v v v
/grp-rek /grp-rek /grp-rek /grp-rek /grp-rek /grp-rek /grp-rek /grp-rek
.--------. .--------. .--------. .--------. .--------. .--------. .--------. .--------.
| C1 | | C2 | | C3 | | C4 | | C1 | | C2 | | C3 | | C4 |
'--------' '--------' '--------' '--------' '--------' '--------' '--------' '--------'
[TO BE EVICTED] [TO BE EVICTED]
| | | |
\____________ Stored group keying material (num=5) _____________/ \____________ Stored group keying material (num=5) _____________/
Figure 38: Example of Message Exchanges for a Point-to-Point Figure 34: Example of Message Exchanges for a Point-to-Point
Group Rekeying Group Rekeying
6.2. One-to-Many Group Rekeying 6.2. One-to-Many Group Rekeying
This section provides high-level recommendations on how the KDC can This section provides high-level recommendations on how the KDC can
rekey a group by means of a more efficient and scalable group rekey a group by means of a more efficient and scalable group
rekeying scheme, e.g., [RFC2093][RFC2094][RFC2627]. That is, each rekeying scheme, e.g., [RFC2093], [RFC2094], and [RFC2627]. That is,
rekeying message might be, and likely is, intended for multiple each rekeying message might be, and likely is, intended for multiple
target group members, and thus can be delivered to the whole group, target group members, and thus can be delivered to the whole group,
although possible to decrypt only for the actual target group although possible to decrypt only for the actual target group
members. members.
This yields an overall lower number of rekeying messages, thus This yields an overall lower number of rekeying messages, thus
potentially reducing the overall time required to rekey the group. potentially reducing the overall time required to rekey the group.
On the other hand, it requires the KDC to provide and use additional On the other hand, it requires the KDC to provide and use additional
administrative keying material to protect the rekeying messages, and administrative keying material to protect the rekeying messages and
to additionally sign them to ensure source authentication (see to additionally sign them to ensure source authentication (see
Section 6.2.1). Section 6.2.1).
Compared to a group rekeying performed in a point-to-point fashion Compared to a group rekeying performed in a point-to-point fashion
(see Section 6.1), a one-to-many group rekeying typically pays off in (see Section 6.1), a one-to-many group rekeying typically pays off in
large-scale groups, due to the reduced time for completing the large-scale groups due to the reduced time for completing the
rekeying, a more efficient utilization of network resources, and a rekeying, a more efficient utilization of network resources, and a
reduced performance overhead at the KDC. To different extents, it reduced performance overhead at the KDC. To different extents, it
also requires individual group members to locally perform additional also requires individual group members to locally perform additional
operations, in order to handle the administrative keying material and operations in order to handle the administrative keying material and
verify source authentication of rekeying messages. Therefore, one- verify source authentication of rekeying messages. Therefore, one-
to-many group rekeying schemes and their employment ought to ensure to-many group rekeying schemes and their employment ought to ensure
that the experienced performance overhead on the group members that the experienced performance overhead on the group members also
remains bearable also for resource-constrained devices. remains bearable for resource-constrained devices.
The exact set of rekeying messages to send, their content and format, The exact set of rekeying messages to send, their content and format,
the administrative keying material to use to protect them, as well as the administrative keying material to use to protect them, as well as
the set of target group members depend on the specific group rekeying the set of target group members depend on the specific group rekeying
scheme, and are typically affected by the reason that has triggered scheme and are typically affected by the reason that has triggered
the group rekeying. Details about the data content and format of the group rekeying. Details about the data content and format of
rekeying messages have to be defined by separate documents profiling rekeying messages have to be defined by separate documents profiling
the use of the group rekeying scheme, in the context of the used the use of the group rekeying scheme in the context of the used
application profile of this specification. application profile of this specification.
When one of these group rekeying schemes is used, the KDC provides a When one of these group rekeying schemes is used, the KDC provides
number of related information to a Client joining the group in the related information to a Client joining the group in the Join
Join Response message (see Section 4.3.1). In particular, Response message (see Section 4.3.1). In particular, the
'rekeying_scheme' identifies the rekeying scheme used in the group 'rekeying_scheme' parameter indicates the rekeying scheme used in the
(if no default can be assumed); 'control_group_uri', if present, group (if no default scheme can be assumed); the 'control_group_uri'
specifies a URI whose addressing information is, e.g., a multicast IP parameter, if present, specifies a URI whose addressing information
address, and where the KDC will send the rekeying messages for that is, e.g., a multicast IP address where the KDC will send the rekeying
group by reaching all the group members; 'mgt_key_material' specifies messages for that group as intended to reach all the group members;
a subset of the administrative keying material intended for that and the 'mgt_key_material' parameter specifies a subset of the
particular joining Client to have, as used to protect the rekeying administrative keying material intended for that particular joining
messages sent to the group when intended also to that joining Client. Client to have, as used to protect the rekeying messages sent to the
group when also intended for that joining Client.
Rekeying messages can be protected at the application layer, by using Rekeying messages can be protected at the application layer by using
COSE and the administrative keying material as prescribed by the COSE [RFC9052] and the administrative keying material as prescribed
specific group rekeying scheme (see Section 6.2.1). After that, the by the specific group rekeying scheme (see Section 6.2.1). After
delivery of protected rekeying messages to the intended target group that, the delivery of protected rekeying messages to the intended
members can occur in different ways, such as the following ones. target group members can occur in different ways, such as the
following ones.
* Over multicast - In this case, the KDC simply sends a rekeying Over multicast - In this case, the KDC simply sends a rekeying
message as a CoAP request addressed to the URI specified in the message as a CoAP request addressed to the URI specified in the
'control_group_uri' parameter of the Join Response (see 'control_group_uri' parameter of the Join Response (see
Section 4.3.1). Section 4.3.1).
If a particular rekeying message is intended for a single target If a particular rekeying message is intended for a single target
group member, the KDC may alternatively protect the message using group member, the KDC may alternatively protect the message using
the security association with that group member, and deliver the the secure communication association with that group member and
message like when using the "Point-to-Point" group rekeying scheme deliver the message like when using the "Point-to-Point" group
(see Section 6.1). rekeying scheme (see Section 6.1).
* Through a pub-sub communication model - In this case, the KDC acts Through a pub-sub communication model - In this case, the KDC acts
as a publisher and publishes each rekeying message to a specific as a publisher and publishes each rekeying message to a specific
"rekeying topic", which is associated with the group and is hosted "rekeying topic", which is associated with the group and is hosted
at a broker server. Following their group joining, the group at a Broker server. Following their group joining, the group
members subscribe to the rekeying topic at the broker, thus members subscribe to the rekeying topic at the Broker, thus
receiving the group rekeying messages as they are published by the receiving the group rekeying messages as they are published by the
KDC. KDC.
In order to make such message delivery more efficient, the In order to make such message delivery more efficient, the
rekeying topic associated with a group can be further organized rekeying topic associated with a group can be further organized
into subtopics. For instance, the KDC can use a particular into subtopics. For instance, the KDC can use a particular
subtopic to address a particular set of target group members subtopic to address a particular set of target group members
during the rekeying process, as possibly aligned to a similar during the rekeying process as possibly aligned to a similar
organization of the administrative keying material (e.g., a key organization of the administrative keying material (e.g., a key
hierarchy). hierarchy).
The setup of rekeying topics at the broker as well as the The setup of rekeying topics at the Broker as well as the
discovery of the topics at the broker for group members are discovery of the topics at the Broker for group members are
application specific. A possible way is for the KDC to provide application specific. A possible way is for the KDC to provide
such information in the Join Response message (see Section 4.3.1), such information in the Join Response message (see Section 4.3.1)
by means of a new parameter analogous to 'control_group_uri' and by means of a new parameter analogous to 'control_group_uri' and
specifying the URI(s) of the rekeying topic(s) that a group member specifying the URI(s) of the rekeying topic(s) that a group member
has to subscribe to at the broker. has to subscribe to at the Broker.
Regardless of the specifically used delivery method, the group Regardless of the specifically used delivery method, the group
rekeying scheme can perform a possible roll-over of the rekeying scheme can perform a possible rollover of the administrative
administrative keying material through the same sent rekeying keying material through the same sent rekeying messages. Actually,
messages. Actually, such a roll-over occurs every time a group such a rollover occurs every time a group rekeying is performed upon
rekeying is performed upon the leaving of group members, which have the leaving of group members, which have to be excluded from future
to be excluded from future communications in the group. communications in the group.
From a high level point of view, each group member stores only a From a high-level point of view, each group member stores only a
subset of the overall administrative keying material, obtained upon subset of the overall administrative keying material, which is
joining the group. Then, when a group rekeying occurs: obtained upon joining the group. Then, when a group rekeying occurs:
* Each rekeying message is protected by using a (most convenient) * Each rekeying message is protected by using a (most convenient)
key from the administrative keying material such that: i) the used key from the administrative keying material such that: i) the used
key is not stored by any node leaving the group, i.e., the key is key is not stored by any node leaving the group, i.e., the key is
safe to use and does not have to be renewed; and ii) the used key safe to use and does not have to be renewed; and ii) the used key
is stored by all the target group members, that indeed have to be is stored by all the target group members that indeed have to be
provided with new group keying material to protect communications provided with new group keying material to protect communications
in the group. in the group.
* Each rekeying message includes not only the new group keying * Each rekeying message includes not only the new group keying
material intended for all the rekeyed group members, but also any material intended for all the rekeyed group members but also any
new administrative keys that: i) are pertaining to and supposed to new administrative keys that: i) are pertaining to and supposed to
be stored by the target group members; and ii) had to be updated be stored by the target group members; and ii) had to be updated
since leaving group members store the previous version. because leaving group members do store the previous version.
Further details depend on the specific rekeying scheme used in the Further details depend on the specific rekeying scheme used in the
group. group.
Figure 39 provides an example of one-to-many group rekeying over Figure 35 provides an example of a one-to-many group rekeying over
multicast. In particular, the example makes the following multicast. In particular, the example makes the following
assumptions. assumptions:
* The group currently consists of four group members, namely C1, C2, * The group currently consists of four group members, namely C1, C2,
C3, and C4. C3, and C4.
* Each group member, when joining the group, provided the KDC with a * Each group member, when joining the group, provided the KDC with a
URI in the 'control_uri' parameter, with url-path "grp-rek". URI in the 'control_uri' parameter with url-path "grp-rek".
* Each group member, when joining the group, received from the KDC a * Each group member, when joining the group, received from the KDC a
URI in the 'control_group_uri' parameter, specifying the multicast URI in the 'control_group_uri' parameter, specifying the multicast
address MULT_ADDR and url-path "grp-mrek". address MULT_ADDR and url-path "grp-mrek".
* Before the group rekeying is performed, the keying material used * Before the group rekeying is performed, the keying material used
in the group has version number num=5. in the group has version number num=5.
* The KDC performs the group rekeying in such a way to evict the * The KDC performs the group rekeying in such a way to evict the
group member C3, which has been found to be compromised. group member C3, which has been found to be compromised.
In the example, the KDC determines that the most convenient way to In the example, the KDC determines that the most convenient way to
perform a group rekeying that evicts C3 is as follows. perform a group rekeying that evicts C3 is as follows.
First, the KDC sends one rekeying message over multicast, to the First, the KDC sends one rekeying message over multicast to the
multicast address MULT_ADDR and the url-path "grp-mrek". In the multicast address MULT_ADDR and the url-path "grp-mrek". In the
figure, the message is denoted with dashed lines. The message is figure, the message is denoted with solid arrows. The message is
protected with a non-compromised key from the administrative keying protected with a non-compromised key from the administrative keying
material that only C1 and C2 store. Therefore, even though all the material that only C1 and C2 store. Therefore, even though all the
group members receive this message, only C1 and C2 are able to group members receive this message, only C1 and C2 are able to
decrypt it. The message includes: the new group keying material with decrypt it. The message includes: the new group keying material with
version number num=6; and new keys from the administrative keying version number num=6 and new keys from the administrative keying
material to replace those stored by the group members C1, C2, and C3. material to replace those stored by the group members C1, C2, and C3.
After that, the KDC sends one rekeying message addressed individually After that, the KDC sends one rekeying message addressed individually
to C4 and with url-path "grp-rek". In the figure, the message is to C4 and with url-path "grp-rek". In the figure, the message is
denoted with a dotted line. The message is protected with the secure denoted with a dotted arrow. The message is protected with the
association shared between C4 and the KDC. The message includes: the secure association shared between C4 and the KDC. The message
new group keying material with version number num=6; and new keys includes: the new group keying material with version number num=6 and
from the administrative keying material to replace those stored by new keys from the administrative keying material to replace those
both C4 and C3. stored by both C4 and C3.
.---------------------------------------------------------------------. .---------------------------------------------------------------------.
| KDC | | KDC |
'---------------------------------------------------------------------' '---------------------------------------------------------------------'
| : | :
* Group keying material (num=6) | * Group keying : * Group keying material (num=6) | * Group keying :
* Updated administrative | material (num=6) : * Updated administrative | material (num=6) :
keying material for C1 and C2 | * Updated administrative : keying material for C1 and C2 | * Updated administrative :
| keying material for C4 : | keying material for C4 :
| : | :
skipping to change at page 82, line 28 skipping to change at line 3836
v v v v v v v v v v
/grp-mrek /grp-mrek /grp-mrek /grp-mrek /grp-rek /grp-mrek /grp-mrek /grp-mrek /grp-mrek /grp-rek
.--------. .--------. .-----------. .---------------------------. .--------. .--------. .-----------. .---------------------------.
| C1 | | C2 | | C3 | | C4 | | C1 | | C2 | | C3 | | C4 |
'--------' '--------' '-----------' '---------------------------' '--------' '--------' '-----------' '---------------------------'
[TO BE EVICTED] [TO BE EVICTED]
| | | |
\_______________ Stored group keying material (num=5) ________________/ \_______________ Stored group keying material (num=5) ________________/
Figure 39: Example of Message Exchanges for a One-to-Many Group Figure 35: Example of Message Exchanges for a One-to-Many Group
Rekeying Rekeying
6.2.1. Protection of Rekeying Messages 6.2.1. Protection of Rekeying Messages
When using a group rekeying scheme relying on one-to-many rekeying When using a group rekeying scheme relying on one-to-many rekeying
messages, the actual data content of each rekeying message is messages, the actual data content of each rekeying message is
prepared according to what the rekeying scheme prescribes. prepared according to what the rekeying scheme prescribes.
The following describes one possible method for the KDC to protect The following describes one possible method for the KDC to protect
the rekeying messages when using the administrative keying material. the rekeying messages when using the administrative keying material.
skipping to change at page 82, line 50 skipping to change at line 3858
The method assumes that the following holds for the administrative The method assumes that the following holds for the administrative
keying material specified in the 'mgt_key_material' parameter of the keying material specified in the 'mgt_key_material' parameter of the
Join Response (see Section 4.3.1). Join Response (see Section 4.3.1).
* The encryption algorithm SHOULD be the same one used to protect * The encryption algorithm SHOULD be the same one used to protect
communications in the group. communications in the group.
* The included symmetric encryption keys are accompanied by a * The included symmetric encryption keys are accompanied by a
corresponding and unique key identifier assigned by the KDC. corresponding and unique key identifier assigned by the KDC.
* A Base IV is also included, with the same size of the AEAD nonce * A Base IV is also included with the same size of the AEAD nonce
considered by the encryption algorithm to use. considered by the encryption algorithm to use.
First, the KDC computes a COSE_Encrypt0 object as follows. First, the KDC computes a COSE_Encrypt0 object as follows.
* The encryption key to use is selected from the administrative * The encryption key to use is selected from the administrative
keying material, as defined by the rekeying scheme used in the keying material, as defined by the rekeying scheme used in the
group. group.
* The plaintext is the actual data content of the rekeying message. * The plaintext is the actual data content of the current rekeying
message.
* The Additional Authenticated Data (AAD) is empty, unless otherwise * The Additional Authenticated Data (AAD) is empty unless otherwise
specified by separate documents profiling the use of the group specified by separate documents profiling the use of the group
rekeying scheme. rekeying scheme.
* Since the KDC is the only sender of rekeying messages, the AEAD * Since the KDC is the only sender of rekeying messages, the AEAD
nonce can be computed as follows, where NONCE_SIZE is the size in nonce can be computed as follows, where NONCE_SIZE is the size in
bytes of the AEAD nonce. Separate documents profiling the use of bytes of the AEAD nonce. Separate documents profiling the use of
the group rekeying scheme may define alternative ways to compute the group rekeying scheme may define alternative ways to compute
the AEAD nonce. the AEAD nonce.
The KDC considers the following values. The KDC considers the following values.
- COUNT, as a 2-byte unsigned integer associated with the used - COUNT: as a 2-byte unsigned integer associated with the used
encryption key. Its value is set to 0 when starting to perform encryption key. Its value is set to 0 when starting to perform
a new group rekeying instance, and is incremented after each a new group rekeying instance and is incremented after each use
use of the encryption key. of the encryption key.
- NEW_NUM, as the version number of the new group keying material - NEW_NUM: as the version number of the new group keying material
to distribute in this rekeying instance, left-padded with zeros to distribute in this rekeying instance, left-padded with zeros
to exactly NONCE_SIZE - 2 bytes. to exactly NONCE_SIZE - 2 bytes.
Then, the KDC computes a Partial IV as the byte string Then, the KDC computes a Partial IV as the byte string
concatenation of COUNT and NEW_NUM, in this order. Finally, the concatenation of COUNT and NEW_NUM in this order. Finally, the
AEAD nonce is computed as the XOR between the Base IV and the AEAD nonce is computed as the XOR between the Base IV and the
Partial IV. Partial IV.
In order to comply with the security requirements of AEAD In order to comply with the security requirements of AEAD
encryption algorithms, the KDC MUST NOT reuse the same pair (AEAD encryption algorithms, the KDC MUST NOT reuse the same pair (AEAD
encryption key, AEAD nonce). For example, this includes not using encryption key, AEAD nonce). For example, this includes not using
the same encryption key from the administrative keying material the same encryption key from the administrative keying material
more than 2^16 times during the same rekeying instance. more than 2^16 times during the same rekeying instance.
* The protected header of the COSE_Encrypt0 object MUST include the * The protected header of the COSE_Encrypt0 object MUST include the
following parameters. following parameters.
- 'alg', specifying the used encryption algorithm. - 'alg': specifying the used encryption algorithm.
- 'kid', specifying the identifier of the encryption key from the - 'kid': specifying the identifier of the encryption key from the
administrative keying material used to protect this rekeying administrative keying material used to protect the current
message. rekeying message.
* The unprotected header of the COSE_Encrypt0 object MUST include * The unprotected header of the COSE_Encrypt0 object MUST include
the 'Partial IV' parameter, with value the Partial IV computed the 'Partial IV' parameter with the value of the Partial IV
above. computed above.
In order to ensure source authentication, each rekeying message In order to ensure source authentication, each rekeying message
protected with the administrative keying material MUST be signed by protected with the administrative keying material MUST be signed by
the KDC. To this end, the KDC computes a countersignature of the the KDC. To this end, the KDC computes a countersignature of the
COSE_Encrypt0 object, as described in Sections 3.2 and 3.3 of COSE_Encrypt0 object, as described in Sections 3.2 and 3.3 of
[RFC9338]. In particular, the following applies when computing the [RFC9338]. In particular, the following applies when computing the
countersignature. countersignature.
* The Countersign_structure contains the context text string * The Countersign_structure contains the context text string
"CounterSignature0". "CounterSignature0".
* The private key of the KDC is used as signing key. * The private key of the KDC is used as the signing key.
* The payload is the ciphertext of the COSE_Encrypt0 object. * The payload is the ciphertext of the COSE_Encrypt0 object.
* The Additional Authenticated Data (AAD) is empty, unless otherwise * The Additional Authenticated Data (AAD) is empty, unless otherwise
specified by separate documents profiling the use of a group specified by separate documents profiling the use of a group
rekeying scheme. rekeying scheme.
* The protected header of the signing object MUST include the * The protected header of the signing object MUST include the
parameter 'alg', specifying the used signature algorithm. parameter 'alg', which specifies the used signature algorithm.
If source authentication of messages exchanged in the group is also If the source authentication of messages exchanged in the group is
ensured by means of signatures, then rekeying messages MUST be signed also ensured by means of signatures, then rekeying messages MUST be
using the same signature algorithm and related parameters. Also, the signed using the same signature algorithm and related parameters.
KDC's authentication credential including the public key to use for Also, the KDC's authentication credential including the public key to
signature verification MUST be provided in the Join Response through use for signature verification MUST be provided in the Join Response
the 'kdc_cred' parameter, together with the corresponding proof-of- through the 'kdc_cred' parameter, together with the corresponding
possession (PoP) evidence in the 'kdc_cred_verify' parameter. proof-of-possession (PoP) evidence in the 'kdc_cred_verify'
parameter.
If source authentication of messages exchanged in the group is not If source authentication of messages exchanged in the group is not
ensured by means of signatures, then the administrative keying ensured by means of signatures, then the administrative keying
material conveyed in the 'mgt_key_material' parameter of the Join material conveyed in the 'mgt_key_material' parameter of the Join
Response sent by KDC (see Section 4.3.1) MUST also comprise a KDC's Response sent by KDC (see Section 4.3.1) MUST also comprise a KDC's
authentication credential including the public key to use for authentication credential including the public key to use for
signature verification, together with a corresponding PoP evidence. signature verification, together with the corresponding PoP evidence.
Within the 'mgt_key_material' parameter, it is RECOMMENDED to specify Within the 'mgt_key_material' parameter, it is RECOMMENDED to specify
this information by using the same format and encoding used for the this information by using the same format and encoding used for the
parameters 'kdc_cred', 'kdc_nonce', and 'kdc_cred_verify' in the Join parameters 'kdc_cred', 'kdc_nonce', and 'kdc_cred_verify' in the Join
Response. It is up to separate documents profiling the use of the Response. It is up to separate documents profiling the use of the
group rekeying scheme to specify such details. group rekeying scheme to specify such details.
After that, the KDC specifies the computed countersignature in the After that, the KDC specifies the computed countersignature in the
'Countersignature0 version 2' header parameter of the COSE_Encrypt0 'Countersignature0 version 2' header parameter of the COSE_Encrypt0
object. object.
Finally, the KDC specifies the COSE_Encrypt0 object as payload of a Finally, the KDC specifies the COSE_Encrypt0 object as payload of a
CoAP request, which is sent to the target group members as per the CoAP request, which is sent to the target group members as per the
used message delivery method. used message delivery method.
6.3. Misalignment of Group Keying Material 6.3. Misalignment of Group Keying Material
A group member can receive a message shortly after the group has been A group member can receive a message shortly after the group has been
rekeyed, and new keying material has been distributed by the KDC. In rekeyed and new keying material has been distributed by the KDC. In
the following two cases, this may result in misaligned keying the following two cases, this may result in misaligned keying
material between the group members. material between the group members.
In the first case, the sender protects a message using the old group In the first case, the sender protects a message using the old group
keying material. However, the recipient receives the message after keying material. However, the recipient receives the message after
having received the new group keying material, hence not being able having received the new group keying material, hence it is not able
to correctly process it. A possible way to limit the impact of this to correctly process the message. A possible way to limit the impact
issue is to preserve the old, recent group keying material for a of this issue is to preserve the old, retained group keying material
maximum amount of time defined by the application, during which it is for a maximum amount of time defined by the application, during which
used solely for processing incoming messages. By doing so, the such group keying material is used solely for processing incoming
recipient can still temporarily process received messages also by messages. By doing so, the recipient can still temporarily process
using the old, retained group keying material. Note that a former received messages also by using the old, retained group keying
(compromised) group member can take advantage of this by sending material. Note that a former (compromised) group member can take
messages protected with the old, retained group keying material. advantage of this by sending messages protected with the old,
Therefore, a conservative application policy should not admit the retained group keying material. Therefore, a conservative
storage of old group keying material. Eventually, the sender will application policy should not admit the storage of old group keying
have obtained the new group keying material too, and can possibly re- material. Eventually, the sender will have obtained the new group
send the message protected with such keying material. keying material too and can possibly resend the message protected
with such keying material.
In the second case, the sender protects a message using the new group In the second case, the sender protects a message using the new group
keying material, but the recipient receives that message before keying material, but the recipient receives that message before
having received the new group keying material. Therefore, the having received the new group keying material. Therefore, the
recipient would not be able to correctly process the message and recipient will not be able to correctly process the message and hence
hence discards it. If the recipient receives the new group keying will discard it. If the recipient receives the new group keying
material shortly after that and the application at the sender material shortly after that and the application at the sender
endpoint performs retransmissions, the former will still be able to endpoint performs retransmissions, the former will still be able to
receive and correctly process the message. In any case, the receive and correctly process the message. In any case, the
recipient should actively ask the KDC for the latest group keying recipient should actively ask the KDC for the latest group keying
material according to an application-defined policy, for instance material according to an application-defined policy, for instance,
after a given number of unsuccessfully decrypted incoming messages. after a given number of unsuccessfully decrypted incoming messages.
7. Extended Scope Format 7. Extended Scope Format
This section defines an extended format of binary encoded scope, This section defines an extended format of binary-encoded scope,
which additionally specifies the semantics used to express the same which additionally specifies the semantics used to express the same
access control information from the corresponding original scope. access control information from the corresponding original scope.
As also discussed in Section 3.2, this enables a Resource Server to As also discussed in Section 3.2, this enables a Resource Server to
unambiguously process a received access token, also in case the unambiguously process a received access token, also in case the
Resource Server runs multiple applications or application profiles Resource Server runs multiple applications or application profiles
that involve different scope semantics. that involve different scope semantics.
The extended format is intended only for the 'scope' claim of access The extended format is intended only for the 'scope' claim of access
tokens, for the cases where the claim takes as value a CBOR byte tokens for the cases where the claim takes a CBOR byte string as the
string. That is, the extended format does not apply to the 'scope' value. That is, the extended format does not apply to the 'scope'
parameter included in ACE messages, i.e., the Authorization Request parameter included in ACE messages, i.e., the Authorization Request
and Authorization Response exchanged between the Client and the and Authorization Response exchanged between the Client and the
Authorization Server (see Sections 5.8.1 and 5.8.2 of [RFC9200]), the Authorization Server (see Sections 5.8.1 and 5.8.2 of [RFC9200]), the
AS Request Creation Hints message from the Resource Server (see AS Request Creation Hints message from the Resource Server (see
Section 5.3 of [RFC9200]), and the Introspection Response from the Section 5.3 of [RFC9200]), and the Introspection Response from the
Authorization Server (see Section 5.9.2 of [RFC9200]). Authorization Server (see Section 5.9.2 of [RFC9200]).
The value of the 'scope' claim following the extended format is The value of the 'scope' claim following the extended format is
composed as follows. Given the original scope using a semantics SEM composed as follows. Given the original scope using semantics SEM
and encoded as a CBOR byte string, the corresponding extended scope and encoded as a CBOR byte string, the corresponding extended scope
consists of the same CBOR byte string enclosed by a CBOR tag consists of the same CBOR byte string enclosed by a CBOR tag
[RFC8949], whose tag number identifies the semantics SEM. [RFC8949], whose tag number identifies the semantics SEM.
The resulting tagged CBOR byte string is used as value of the 'scope' The resulting tagged CBOR byte string is used as the value of the
claim of the access token. 'scope' claim of the access token.
Figure 40 and Figure 41 build on the examples in Section 3.2, and Figures 36 and 37 build on the examples in Section 3.1 and show the
show the corresponding extended scopes. corresponding extended scopes.
;# include rfc9237 ;# include rfc9237
gname = tstr gname = tstr
permissions = uint .bits roles permissions = uint .bits roles
roles = &( roles = &(
Requester: 1, Requester: 1,
Responder: 2, Responder: 2,
Monitor: 3, Monitor: 3,
Verifier: 4 Verifier: 4
) )
scope_entries = AIF-Generic<gname, permissions> scope_entries = AIF-Generic<gname, permissions>
scope = bstr .cbor scope_entries scope = bstr .cbor scope_entries
extended_scope = #6.TAG_FOR_THIS_SEMANTICS(scope) extended_scope = #6.<TAG_FOR_THIS_SEMANTICS>(scope)
Figure 40: Example CDDL definition of scope, using the default TAG_FOR_THIS_SEMANTICS = uint
Authorization Information Format
Figure 36: Example of Extended scope Using AIF
gname = tstr gname = tstr
role = tstr role = tstr
scope_entry = [ gname , ? ( role / [ 2*role ] ) ] scope_entry = [ gname , ? ( role / [ 2*role ] ) ]
scope_entries = [ * scope_entry ] scope_entries = [ * scope_entry ]
scope = bstr .cbor scope_entries scope = bstr .cbor scope_entries
extended_scope = #6.TAG_FOR_THIS_SEMANTICS(scope) extended_scope = #6.<TAG_FOR_THIS_SEMANTICS>(scope)
Figure 41: CDDL definition of scope, using as example group name TAG_FOR_THIS_SEMANTICS = uint
encoded as tstr and role as tstr
Figure 37: Example of Extended scope Using the Textual Format,
with the Role Identifiers Encoded as Text Strings
The usage of the extended scope format is not limited to application The usage of the extended scope format is not limited to application
profiles of this specification or to applications based on group profiles of this specification or to applications based on group
communication. Rather, it is generally applicable to any application communication. Rather, it is generally applicable to any application
and application profile where access control information in the and application profile where access control information in the
access token is expressed as a binary encoded scope. access token is expressed as a binary-encoded scope.
Applications and application profiles using the extended format of Applications and application profiles using the extended format of
scope have to specify which CBOR tag from [CBOR.Tags] is used for scope have to specify which CBOR tag from [CBOR.Tags] is used for
identifying the scope semantics, or to register a new CBOR tag if a identifying the scope semantics or to register a new CBOR tag if a
suitable one does not exist already (REQ28). In case there is an suitable one does not exist already (REQ28). In case there is an
already existing, suitable CBOR tag, a new CBOR tag should not be already existing, suitable CBOR tag, a new CBOR tag should not be
registered in order to avoid codepoint squatting. registered in order to avoid code point squatting.
If the binary encoded scope uses a semantics associated with a If the binary-encoded scope uses semantics associated with a
registered CoAP Content-Format [RFC7252][CoAP.Content.Formats], then registered CoAP Content-Format [RFC7252] [CoAP.Content.Formats], then
a suitable CBOR tag associated with that CoAP Content-Format would a suitable CBOR tag associated with that CoAP Content-Format would
already be registered, as defined in Section 4.3 of [RFC9277]. already be registered, as defined in Section 4.3 of [RFC9277].
This is especially relevant when the binary encoded scope uses the This is especially relevant when the binary encoded scope uses AIF.
AIF format. That is, it is expected that the definition of an AIF That is, it is expected that the definition of an AIF-specific data
specific data model comes together with the registration of CoAP model comes together with the registration of CoAP Content-Formats
Content-Formats for the relevant combinations of its Toid and Tperm for the relevant combinations of its Toid and Tperm values. As
values. As discussed above, this yields the automatic registration discussed above, this yields the automatic registration of the CBOR
of the CBOR tags associated with those CoAP Content-Formats. tags associated with those CoAP Content-Formats.
8. ACE Groupcomm Parameters 8. ACE Groupcomm Parameters
This specification defines a number of parameters used during the This specification defines a number of parameters used during the
second part of the message exchange, after the exchange of Token second phase of the key provisioning process, i.e., after the
Transfer Request and Response. The table below summarizes them, and exchange after the exchange of Token Transfer Request and Response.
specifies the CBOR key to use instead of the full descriptive name. The table below summarizes them and specifies the CBOR map keys to
use instead of the full descriptive names.
Note that the media type application/ace-groupcomm+cbor MUST be used
when these parameters are transported in the respective message
fields.
+-----------------------+------+---------------------+------------+ Note that the media type "application/ace-groupcomm+cbor" MUST be
| Name | CBOR | CBOR Type | Reference | used when these parameters are transported in the respective CBOR map
| | Key | | | entries.
+-----------------------+------+---------------------+------------+
| gid | 0 | array | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| gname | 1 | array of tstr | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| guri | 2 | array of tstr | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| scope | 3 | bstr | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| get_creds | 4 | array / | [RFC-XXXX] |
| | | Simple value "null" | |
+-----------------------+------+---------------------+------------+
| client_cred | 5 | bstr | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| cnonce | 6 | bstr | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| client_cred_verify | 24 | bstr | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| creds_repo | 25 | tstr | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| control_uri | 26 | tstr | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| gkty | 7 | int / tstr | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| key | 8 | See the "ACE | [RFC-XXXX] |
| | | Groupcomm Key | |
| | | Types" registry | |
+-----------------------+------+---------------------+------------+
| num | 9 | int | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| ace_groupcomm_profile | 10 | int | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| exp | 11 | uint | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| exi | 12 | uint | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| creds | 13 | array | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| peer_roles | 14 | array | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| peer_identifiers | 15 | array | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| group_policies | 16 | map | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| kdc_cred | 17 | bstr | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| kdc_nonce | 18 | bstr | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| kdc_cred_verify | 19 | bstr | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| rekeying_scheme | 20 | int | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| mgt_key_material | 27 | bstr | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| control_group_uri | 28 | tstr | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
| sign_info | 29 | array / | [RFC-XXXX] |
| | | Simple value "null" | |
+-----------------------+------+---------------------+------------+
| kdcchallenge | 30 | bstr | [RFC-XXXX] |
+-----------------------+------+---------------------+------------+
Figure 42: ACE Groupcomm Parameters +=======================+======+========================+===========+
| Name | CBOR | CBOR Type | Reference |
| | Key | | |
+=======================+======+========================+===========+
| gid | 0 | array | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| gname | 1 | array of tstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| guri | 2 | array of tstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| scope | 3 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| get_creds | 4 | Null or array | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| client_cred | 5 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| cnonce | 6 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| gkty | 7 | int or tstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| key | 8 | See the "ACE | RFC 9594 |
| | | Groupcomm Key | |
| | | Types" registry | |
+-----------------------+------+------------------------+-----------+
| num | 9 | int | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| ace_groupcomm_profile | 10 | int | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| exp | 11 | uint | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| exi | 12 | uint | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| creds | 13 | array | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| peer_roles | 14 | array | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| peer_identifiers | 15 | array | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| group_policies | 16 | map | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| kdc_cred | 17 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| kdc_nonce | 18 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| kdc_cred_verify | 19 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| rekeying_scheme | 20 | int | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| client_cred_verify | 24 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| creds_repo | 25 | tstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| control_uri | 26 | tstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| mgt_key_material | 27 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| control_group_uri | 28 | tstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| sign_info | 29 | Null or array | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| kdcchallenge | 30 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
Note to RFC Editor: In Figure 42, please replace all occurrences of Table 5: ACE Groupcomm Parameters
"[RFC-XXXX]" with the RFC number of this specification and delete
this paragraph.
The KDC is expected to support all the parameters above. Instead, a The KDC is expected to support all the parameters above. Instead, a
Client can support only a subset of such parameters, depending on the Client can support only a subset of such parameters, depending on the
roles it expects to take in the joined groups or on other conditions roles it expects to take in the joined groups or on other conditions
defined in application profiles of this specification. defined in application profiles of this specification.
In the following, the parameters are categorized according to the In the following, the parameters are categorized according to the
support expected by Clients. That is, a Client that supports a support expected by Clients. That is, a Client that supports a
parameter is able to: i) use and specify it in a request message to parameter is able to: i) use and specify it in a request message to
the KDC; and ii) understand and process it if specified in a response the KDC; and ii) understand and process it if specified in a response
skipping to change at page 90, line 5 skipping to change at line 4196
specification to sort their newly defined parameters according to the specification to sort their newly defined parameters according to the
same categorization (REQ29). same categorization (REQ29).
Note that the actual use of a parameter and its inclusion in a Note that the actual use of a parameter and its inclusion in a
message depends on the specific exchange, the specific Client and message depends on the specific exchange, the specific Client and
group involved, as well as what is defined in the used application group involved, as well as what is defined in the used application
profile of this specification. profile of this specification.
A Client MUST support the following parameters. A Client MUST support the following parameters.
* 'scope', 'cnonce', 'gkty', 'key', 'num', 'exp', 'exi', 'gid', * 'scope'
'gname', 'guri', 'creds', 'peer_identifiers',
'ace_groupcomm_profile', 'control_uri', 'rekeying_scheme'. * 'cnonce'
* 'gkty'
* 'key'
* 'num'
* 'exp'
* 'exi'
* 'gid'
* 'gname'
* 'guri'
* 'creds'
* 'peer_identifiers'
* 'ace_groupcomm_profile'
* 'control_uri'
* 'rekeying_scheme'
A Client SHOULD support the following parameter. A Client SHOULD support the following parameter.
* 'get_creds'. That is, not supporting this parameter would yield * 'get_creds': That is, not supporting this parameter would yield
the inconvenient and undesirable behavior where: i) the Client the inconvenient and undesirable behavior where: i) the Client
does not ask for the other group members' authentication does not ask for the other group members' authentication
credentials upon joining the group (see Section 4.3.1.1); and ii) credentials upon joining the group (see Section 4.3.1.1); and ii)
later on as a group member, the Client only retrieves the later on as a group member, the Client only retrieves the
authentication credentials of all group members (see authentication credentials of all group members (see
Section 4.4.2.1). Section 4.4.2.1).
The following conditional parameters are relevant only if specific The following conditional parameters are relevant only if specific
conditions hold. It is REQUIRED of application profiles of this conditions hold. It is REQUIRED of application profiles of this
specification to define whether Clients must, should, or may support specification to define whether Clients must, should, or may support
these parameters, and under which circumstances (REQ30). these parameters and under which circumstances (REQ30).
* 'client_cred' and 'client_cred_verify'. These parameters are * 'client_cred' and 'client_cred_verify': These parameters are
relevant for a Client that has an authentication credential to use relevant for a Client that has an authentication credential to use
in a joined group. in a joined group.
* 'kdcchallenge'. This parameter is relevant for a Client that has * 'kdcchallenge': This parameter is relevant for a Client that has
an authentication credential to use in a joined group and that an authentication credential to use in a joined group and that
provides the access token to the KDC through a Token Transfer provides the access token to the KDC through a Token Transfer
Request (see Section 3.3). Request (see Section 3.3).
* 'creds_repo'. This parameter is relevant for a Client that has an * 'creds_repo': This parameter is relevant for a Client that has an
authentication credential to use in a joined group and that makes authentication credential to use in a joined group and that makes
it available from a key repository different than the KDC. it available from a key repository different than the KDC.
* 'group_policies'. This parameter is relevant for a Client that is * 'group_policies': This parameter is relevant for a Client that is
interested in the specific policies used in a group, but it does interested in the specific policies used in a group, but it does
not know them or cannot become aware of them before joining that not know them or cannot become aware of them before joining that
group. group.
* 'peer_roles'. This parameter is relevant for a Client that has to * 'peer_roles': This parameter is relevant for a Client that has to
know about the roles of other group members, especially when know about the roles of other group members, especially when
retrieving and handling their corresponding authentication retrieving and handling their corresponding authentication
credentials. credentials.
* 'kdc_nonce', 'kdc_cred', 'kdc_cred_verify'. These parameters are * 'kdc_nonce', 'kdc_cred', and 'kdc_cred_verify': These parameters
relevant for a Client that joins a group for which, as per the are relevant for a Client that joins a group for which, as per the
used application profile of this specification, the KDC has an used application profile of this specification, the KDC has an
associated authentication credential and this is required for the associated authentication credential and this is required for the
correct group operation. correct group operation.
* 'mgt_key_material'. This parameter is relevant for a Client that * 'mgt_key_material': This parameter is relevant for a Client that
supports an advanced rekeying scheme possibly used in the group, supports an advanced rekeying scheme possibly used in the group,
such as based on one-to-many rekeying messages sent over IP such as based on one-to-many rekeying messages sent over IP
multicast. multicast.
* 'control_group_uri'. This parameter is relevant for a Client that * 'control_group_uri': This parameter is relevant for a Client that
supports the hosting of local resources each associated with a also acts as a CoAP server supporting: i) the hosting of a
group (hence acting as CoAP server) and the reception of one-to- dedicated resource for each group that the Client is interested to
many requests sent to those resources by the KDC (e.g., over IP be a part of; and ii) the reception of one-to-many requests sent
multicast), targeting multiple members of the corresponding group. to those resources by the KDC (e.g., over IP multicast), as
Examples of related management operations that the KDC can perform targeting multiple members of the corresponding group. Examples
by this means are the eviction of group members and the execution of related management operations that the KDC can perform by this
of a group rekeying process through an advanced rekeying scheme, means are the eviction of group members and the execution of a
such as based on one-to-many rekeying messages. group rekeying process through an advanced rekeying scheme, such
as based on one-to-many rekeying messages.
9. ACE Groupcomm Error Identifiers 9. ACE Groupcomm Error Identifiers
This specification defines a number of values that the KDC can use as This specification defines a number of values that the KDC can use as
error identifiers. These are used in error responses with Content- error identifiers. These are used in error responses with Content-
Format application/concise-problem-details+cbor, as values of the Format "application/concise-problem-details+cbor", as values of the
'error-id' field within the Custom Problem Detail entry 'ace- 'error-id' field within the Custom Problem Detail entry 'ace-
groupcomm-error' (see Section 4.1.2). groupcomm-error' (see Section 4.1.2).
+=======+=============================================+
| Value | Description |
+=======+=============================================+
| 0 | Operation permitted only to group members |
+-------+---------------------------------------------+ +-------+---------------------------------------------+
| Value | Description | | 1 | Request inconsistent with the current roles |
+-------+---------------------------------------------+
| 0 | Operation permitted only to group members |
+-------+---------------------------------------------+
| 1 | Request inconsistent with the current roles |
+-------+---------------------------------------------+ +-------+---------------------------------------------+
| 2 | Authentication credential incompatible with | | 2 | Authentication credential incompatible with |
| | the group configuration | | | the group configuration |
+-------+---------------------------------------------+ +-------+---------------------------------------------+
| 3 | Invalid proof-of-possession evidence | | 3 | Invalid proof-of-possession evidence |
+-------+---------------------------------------------+ +-------+---------------------------------------------+
| 4 | No available node identifiers | | 4 | No available individual keying material |
+-------+---------------------------------------------+ +-------+---------------------------------------------+
| 5 | Group membership terminated | | 5 | Group membership terminated |
+-------+---------------------------------------------+ +-------+---------------------------------------------+
| 6 | Group deleted | | 6 | Group deleted |
+-------+---------------------------------------------+ +-------+---------------------------------------------+
Figure 43: ACE Groupcomm Error Identifiers Table 6: ACE Groupcomm Error Identifiers
If a Client supports the problem-details format [RFC9290] and the If a Client supports the problem-details format [RFC9290] and the
Custom Problem Detail entry 'ace-groupcomm-error' defined in Custom Problem Detail entry 'ace-groupcomm-error' defined in
Section 4.1.2, and is able to understand the error specified in the Section 4.1.2 of this document and is able to understand the error
'error-id' field therein, then the Client can use that information to specified in the 'error-id' field therein, then the Client can use
determine what actions to take next. If the Concise Problem Details that information to determine what actions to take next. If the
data item specified in the error response includes the 'detail' entry Concise Problem Details data item specified in the error response
and the Client supports it, such an entry may provide additional includes the 'detail' entry and the Client supports it, such an entry
context. may provide additional context.
In particular, the following guidelines apply, and application In particular, the following guidelines apply, and application
profiles of this specification can define more detailed actions for profiles of this specification can define more detailed actions for
the Client to take when learning that a specific error has occurred. the Client to take when learning that a specific error has occurred.
* In case of error 0, the Client should stop sending the request in * In case of error 0, the Client should stop sending the request in
question to the KDC. Rather, the Client should first join the question to the KDC. Rather, the Client should first join the
targeted group. If it has not happened already, this first targeted group. If it has not happened already, this first
requires the Client to obtain an appropriate access token requires the Client to obtain an appropriate access token
authorizing access to the group and provide it to the KDC. authorizing access to the group and provide it to the KDC.
* In case of error 1, the Client as a group member should re-join * In case of error 1, the Client as a group member should rejoin the
the group with all the roles needed to perform the operation in group with all the roles needed to perform the operation in
question. This might require the Client to first obtain a new question. This might require the Client to first obtain a new
access token and provide it to the KDC, if the current access access token and provide it to the KDC, if the current access
token does not authorize it to take those roles in the group. For token does not authorize the Client to take those roles in the
operations admitted to a Client which is not a group member (e.g., group. For operations admitted to a Client that is not a group
an external signature verifier), the Client should first obtain a member (e.g., an external signature verifier), the Client should
new access token authorizing to also have the missing roles. first obtain a new access token authorizing to also have the
missing roles.
* In case of error 2, the Client has to obtain or self-generate a * In case of error 2, the Client has to obtain or self-generate a
different asymmetric key pair, as aligned to the public key different asymmetric key pair, as aligned to the public key
algorithms and parameters used in the targeted group. After that, algorithm and parameters used in the targeted group. After that,
the Client should provide the KDC with its new authentication the Client should provide the KDC with its new authentication
credential, consistent with the format used in the targeted group credential, which is consistent with the format used in the
and including the new public key. targeted group and including the new public key.
* In case of error 3, the Client should ensure to be computing its * In case of error 3, the Client should ensure to compute its proof-
proof-of-possession evidence by correctly using the parameters and of-possession evidence by correctly using the parameters and
procedures defined in the used application profile of this procedures defined in the used application profile of this
specification. In an unattended setup, it might be not possible specification. In an unattended setup, it might not be possible
for a Client to autonomously diagnose the error and take an for a Client to autonomously diagnose the error and take an
effective next action to address it. effective next action to address it.
* In case of error 4, the Client should wait for a certain (pre- * In case of error 4, the Client should wait for a certain (pre-
configured) amount of time, before trying re-sending its request configured) amount of time before trying to resend its request to
to the KDC. the KDC.
* In case of error 5, the Client may try joining the group again. * In case of error 5, the Client may try joining the group again.
This might require the Client to first obtain a new access token This might require the Client to first obtain a new access token
and provide it to the KDC, e.g., if the current access token has and provide it to the KDC, e.g., if the current access token has
expired. expired.
* In case of error 6, the Client should clean up its state regarding * In case of error 6, the Client should clean up its state regarding
the group, just like if it has left the group with no intention to the group, just like if it has left the group with no intention to
re-join it. rejoin it.
10. Security Considerations 10. Security Considerations
Security considerations are inherited from the ACE framework Security considerations are inherited from the ACE framework
[RFC9200], and from the specific transport profile of ACE used [RFC9200] and from the specific transport profile of ACE used between
between the Clients and the KDC, e.g., [RFC9202] and [RFC9203]. the Clients and the KDC, e.g., [RFC9202] and [RFC9203].
When using the problem-details format defined in [RFC9290] for error When using the problem-details format defined in [RFC9290] for error
responses, then the privacy and security considerations from Sections responses, then the privacy and security considerations from Sections
4 and 5 of [RFC9290] also apply. 4 and 5 of [RFC9290] also apply.
Furthermore, the following security considerations apply. Furthermore, the following security considerations apply.
10.1. Secure Communication in the Group 10.1. Secure Communication in the Group
When a group member receives a message from a certain sender for the When a group member receives a message from a certain sender for the
first time since joining the group, it needs to have a mechanism in first time since joining the group, it needs to have a mechanism in
place to avoid replayed messages and to assert their freshness, e.g., place to avoid replayed messages and to assert their freshness, e.g.,
Appendix B.1.2 of [RFC8613] or Section 10 of as described in Appendix B.1.2 of [RFC8613] or Section 10 of
[I-D.ietf-core-oscore-groupcomm]. Such a mechanism aids the [GROUP-OSCORE]. Such a mechanism also aids the recipient group
recipient group member also in case it has rebooted and lost the member in case it has rebooted and lost the security state used to
security state used to protect previous group communications with protect previous group communications with that sender.
that sender.
By its nature, the KDC is invested with a large amount of trust, By its nature, the KDC is invested with a large amount of trust,
since it acts as a generator and provider of the symmetric keying since it acts as a generator and provider of the symmetric keying
material used to protect communications in each of its groups. While material used to protect communications in each of its groups. While
details depend on the specific communication and security protocols details depend on the specific communication and security protocols
used in the group, the KDC is in the position to decrypt messages used in the group, the KDC is in the position to decrypt messages
exchanged in the group as if it was also a group member, as long as exchanged in the group as if it was also a group member, as long as
those are protected through commonly shared group keying material. those are protected through commonly shared group keying material.
A compromised KDC would thus put the attacker in the same position, A compromised KDC would thus put the attacker in the same position,
which also means that: which also means that:
* The attacker can generate and control new group keying material, * The attacker can generate and control new group keying material,
hence possibly rekeying the group and evicting certain group hence possibly rekeying the group and evicting certain group
members as part of a broader attack. members as part of a broader attack.
* The attacker can actively participate in communications in a group * The attacker can actively participate in communications in a
even without been authorized to join it, and can allow further group, even without having been authorized to join it, and can
unauthorized entities to do so. allow further unauthorized entities to do so.
* The attacker can build erroneous associations between node * The attacker can build erroneous associations between node
identifiers and group members' authentication credentials. identifiers and group members' authentication credentials.
On the other hand, as long as the security protocol used in the group On the other hand, as long as the security protocol used in the group
ensures source authentication of messages (e.g., by means of ensures source authentication of messages (e.g., by means of
signatures), the KDC is not able to impersonate group members since signatures), the KDC is not able to impersonate group members since
it does not have their private keys. it does not have their private keys.
Further security considerations are specific to the communication and Further security considerations are specific to the communication and
security protocols used in the group, and thus have to be provided by security protocols used in the group, and thus have to be provided by
those protocols and complemented by the application profiles of this those protocols and complemented by the application profiles of this
specification using them. specification using them.
10.2. Update of Group Keying Material 10.2. Update of Group Keying Material
The KDC can generate new group keying material and provide it to the The KDC can generate new group keying material and provide it to the
group members (rekeying) through the rekeying scheme used in the group members (rekeying) through the rekeying scheme used in the
group, as discussed in Section 6. group, as discussed in Section 6.
In particular, the KDC must renew the group keying material latest In particular, the KDC must renew the latest group keying material
upon its expiration. Before then, the KDC MAY also renew the group upon its expiration. Before then, the KDC MAY also renew the group
keying material on a regular or periodical fashion. keying material on a regular or periodical fashion.
Unless otherwise defined by an application profile of this Unless otherwise defined by an application profile of this
specification, the KDC SHOULD renew the group keying material upon a specification, the KDC SHOULD renew the group keying material upon a
group membership change. As a possible exception, the KDC may not group membership change. As a possible exception, the KDC may not
rekey the group upon the joining of a new group member, if the rekey the group upon the joining of a new group member if the
application does not require backward security. As another possible application does not require backward security. As another possible
exception discussed more in detail later in this section, the KDC may exception discussed more in detail later in this section, the KDC may
rely on a rekeying policy that reasonably take into account the rely on a rekeying policy that reasonably takes into account the
expected rate of group membership changes and the duration of a group expected rate of group membership changes and the duration of a group
rekeying. rekeying.
Since the minimum number of group members is one, the KDC SHOULD Since the minimum number of group members is one, the KDC SHOULD
provide even a Client joining an empty group with new keying material provide even a Client joining an empty group with new keying material
never used before in that group. Similarly, the KDC SHOULD provide never used before in that group. Similarly, the KDC SHOULD also
new group keying material also to a Client that remains the only provide new group keying material to a Client that remains the only
member in the group after the leaving of other group members. member in the group after the leaving of other group members.
Note that the considerations in Section 10.1 about dealing with Note that the considerations in Section 10.1 about dealing with
replayed messages still hold, even in case the KDC rekeys the group replayed messages still hold, even in case the KDC rekeys the group
upon every single joining of a new group member. However, if the KDC upon every single joining of a new group member. However, if the KDC
has renewed the group keying material upon a group member's joining, has renewed the group keying material upon a group member's joining
and the time interval between the end of the rekeying process and and the time interval between the end of the rekeying process and
that member's joining is sufficiently small, then that group member that member's joining is sufficiently small, then that group member
is also on the safe side, since it would not accept replayed messages is also on the safe side, since it would not accept replayed messages
protected with the old group keying material previous to its joining. protected with the old group keying material previous to its joining.
Once a joining node has obtained the new, latest keying material Once a joining node has obtained the new, latest keying material
through a Join Response from the KDC (see Section 4.3.1.1), the through a Join Response from the KDC (see Section 4.3.1.1), the
joining node becomes able to read any message that was exchanged in joining node becomes able to read any message that was exchanged in
the group and protected with that keying material. This is the case the group and protected with that keying material. This is the case
if the KDC provides the current group members with the new, latest if the KDC provides the current group members with the new, latest
keying material before completing the joining procedure. However, keying material before completing the joining procedure. However,
the joining node is not able to read messages exchanged in the group the joining node is not able to read messages exchanged in the group
and protected with keying material older than the one provided in the and protected with keying material older than the one provided in the
Join Response, i.e., having a strictly lower version number NUM. Join Response, i.e., having a strictly lower version number NUM.
A node that has left the group should not expect any of its outgoing A node that has left the group should not expect any of its outgoing
messages to be successfully processed, if received by other nodes in messages to be successfully processed if received by other nodes in
the group after its leaving, due to a possible group rekeying the group after its leaving due to a possible group rekeying
occurred before the message reception. occurring before the message reception.
The KDC may enforce a rekeying policy that takes into account the The KDC may enforce a rekeying policy that takes into account the
overall time required to rekey the group, as well as the expected overall time required to rekey the group, as well as the expected
rate of changes in the group membership. That is, the KDC may not rate of changes in the group membership. That is, the KDC may not
rekey the group at each and every group membership change, for rekey the group at each and every group membership change, for
instance if members' joining and leaving occur frequently and instance, if members' joining and leaving occur frequently and
performing a group rekeying takes too long. Instead, the KDC might performing a group rekeying takes too long. Instead, the KDC might
rekey the group after a minimum number of group members have joined rekey the group after a minimum number of group members have joined
or left within a given time interval, or after a maximum amount of or left within a given time interval, after a maximum amount of time
time since the last group rekeying was completed, or yet during since the last group rekeying was completed, or yet during
predictable network inactivity periods. predictable network inactivity periods.
However, this would result in the KDC not constantly preserving However, this would result in the KDC not constantly preserving
backward and forward security in the group. That is: backward and forward security in the group. That is:
* Newly joining group members would be able to access the keying * Newly joining group members would be able to access the keying
material used before their joining, and thus they could access material used before their joining, and thus they could access
past group communications if they have recorded old exchanged past group communications if they have recorded old exchanged
messages. This might still be acceptable for some applications messages. This might still be acceptable for some applications
and in situations where the new group members are freshly deployed and in situations where the new group members are freshly deployed
through strictly controlled procedures. through strictly controlled procedures.
* The leaving group members would remain able to access upcoming * The leaving group members would remain able to access upcoming
group communications, as protected with the current keying group communications, as protected with the current keying
material that has not been updated. This is typically material that has not been updated. This is typically
undesirable, especially if the leaving group member is compromised undesirable, especially if the leaving group member is compromised
or suspected to be, and it might have an impact or compromise the or suspected to be, and it might impact or compromise the security
security properties of the protocols used in the group to protect properties of the protocols used in the group to protect messages
messages exchanged among the group members. exchanged among the group members.
The KDC should renew the group keying material in case it has The KDC should renew the group keying material in case it has
rebooted, even if it stores the whole group keying material in rebooted, even if it stores the whole group keying material in
persistent storage. This assumes that the secure associations with persistent storage. This assumes that the secure communication
the current group members as well as any administrative keying associations with the current group members as well as any
material required to rekey the group are also stored in persistent administrative keying material required to rekey the group are also
storage. stored in persistent storage.
However, if the KDC relies on Observe notifications to distribute the However, if the KDC relies on Observe notifications to distribute the
new group keying material, the KDC would have lost all the current new group keying material, the KDC would have lost all the current
ongoing Observations with the group members after rebooting, and the ongoing Observations with the group members after rebooting, and the
group members would continue using the old group keying material. group members would continue using the old group keying material.
Therefore, the KDC will rather rely on each group member asking for Therefore, the KDC will rely on each group member asking for the new
the new group keying material (see Section 4.3.2.1 and group keying material (see Sections 4.3.2.1 and 4.8.1.1) or perform a
Section 4.8.1.1), or rather perform a group rekeying by actively group rekeying by actively sending rekeying messages to group members
sending rekeying messages to group members as discussed in Section 6. as discussed in Section 6.
The KDC needs to have a mechanism in place to detect DoS attacks from The KDC needs to have a mechanism in place to detect DoS attacks from
nodes repeatedly performing actions that might trigger a group nodes repeatedly performing actions that might trigger a group
rekeying. Such actions can include leaving and/or re-joining the rekeying. Such actions can include leaving and/or rejoining the
group at high rates, or often asking the KDC for new individual group at high rates or often asking the KDC for new individual keying
keying material. Ultimately, the KDC can resort to removing these material. Ultimately, the KDC can resort to removing these nodes
nodes from the group and (temporarily) preventing them from joining from the group and (temporarily) preventing them from joining the
the group again. group again.
The KDC also needs to have a congestion control mechanism in place, The KDC also needs to have a congestion control mechanism in place in
in order to avoid network congestion upon distributing new group order to avoid network congestion upon distributing new group keying
keying material. For example, CoAP and Observe give guidance on such material. For example, CoAP and Observe give guidance on such
mechanisms, see Section 4.7 of [RFC7252] and Section 4.5.1 of mechanisms, see Section 4.7 of [RFC7252] and Section 4.5.1 of
[RFC7641]. [RFC7641].
10.3. Block-Wise Considerations 10.3. Block-Wise Considerations
If the Block-Wise CoAP options [RFC7959] are used, and the keying If the Block-Wise CoAP options [RFC7959] are used and the keying
material is updated in the middle of a Block-Wise transfer, the material is updated in the middle of a Block-Wise transfer, the
sender of the blocks just changes the group keying material to the sender of the blocks just changes the group keying material to the
updated one and continues the transfer. As long as both sides get updated one and continues the transfer. As long as both sides get
the new group keying material, updating the group keying material in the new group keying material, updating the group keying material in
the middle of a transfer will not cause any issue. Otherwise, the the middle of a transfer will not cause any issue. Otherwise, the
sender will have to transmit the message again, when receiving an sender will have to transmit the message again when receiving an
error message from the recipient. error message from the recipient.
Compared to a scenario where the transfer does not use Block-Wise, Compared to a scenario where the transfer does not use Block-Wise,
depending on how fast the group keying material is changed, the group and depending on how fast the group keying material is changed, the
members might consume a larger amount of the network bandwidth by group members might consume a larger amount of the network bandwidth
repeatedly resending the same blocks, which might be problematic. by repeatedly resending the same blocks, which might be problematic.
11. IANA Considerations 11. IANA Considerations
This document has the following actions for IANA. Per this document, IANA has completed the following actions.
Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
with the RFC number of this specification and delete this paragraph.
11.1. Media Type Registrations 11.1. Media Type Registrations
This specification registers the 'application/ace-groupcomm+cbor' This specification has registered the "application/ace-
media type for messages of the protocols defined in this document groupcomm+cbor" media type for messages of the protocols defined in
following the ACE exchange and carrying parameters encoded in CBOR. this document following the ACE exchange and carrying parameters
This registration follows the procedures specified in [RFC6838]. encoded in CBOR. This registration follows the procedures specified
in [RFC6838].
Type name: application Type name: application
Subtype name: ace-groupcomm+cbor Subtype name: ace-groupcomm+cbor
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: Must be encoded as a CBOR map containing the Encoding considerations: Must be encoded as a CBOR map containing
parameters defined in [RFC-XXXX]. the parameters defined in RFC 9594.
Security considerations: See Section 10 of [RFC-XXXX]. Security considerations: See Section 10 of RFC 9594.
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: [RFC-XXXX] Published specification: RFC 9594
Applications that use this media type: The type is used by Applications that use this media type: The type is used by
Authorization Servers, Clients, and Resource Servers that support the Authorization Servers, Clients, and Resource Servers that support
ACE groupcomm framework as specified in [RFC-XXXX]. the ACE groupcomm framework as specified in RFC 9594.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: N/A Additional information: N/A
Person & email address to contact for further information: ACE WG Person & email address to contact for further information: ACE WG
mailing list (ace@ietf.org) or IETF Applications and Real-Time Area mailing list (ace@ietf.org) or IETF Applications and Real-Time
(art@ietf.org) Area (art@ietf.org)
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: None Restrictions on usage: None
Author/Change controller: IETF Author/Change controller: IETF
Provisional registration: No Provisional registration: No
11.2. CoAP Content-Formats 11.2. CoAP Content-Formats
IANA is asked to register the following entry to the "CoAP Content- IANA has registered the following entry in the "CoAP Content-Formats"
Formats" registry within the "CoRE Parameters" registry group. registry within the "CoRE Parameters" registry group.
Content Type: application/ace-groupcomm+cbor
Content Coding: -
ID: TBD
Reference: [RFC-XXXX] Content Type: application/ace-groupcomm+cbor
Content Coding: -
ID: 261
Reference: RFC 9594
11.3. OAuth Parameters 11.3. OAuth Parameters
IANA is asked to register the following entries in the "OAuth IANA has registered the following entries in the "OAuth Parameters"
Parameters" registry following the procedure specified in registry, following the procedure specified in Section 11.2 of
Section 11.2 of [RFC6749]. [RFC6749].
* Parameter name: sign_info
* Parameter usage location: client-rs request, rs-client response
* Change Controller: IETF
* Specification Document(s): [RFC-XXXX]
* Parameter name: kdcchallenge
* Parameter usage location: rs-client response
* Change Controller: IETF Name: sign_info
Parameter Usage Location: client-rs request, rs-client response
Change Controller: IETF
Reference: RFC 9594
* Specification Document(s): [RFC-XXXX] Name: kdcchallenge
Parameter Usage Location: rs-client response
Change Controller: IETF
Reference: RFC 9594
11.4. OAuth Parameters CBOR Mappings 11.4. OAuth Parameters CBOR Mappings
IANA is asked to register the following entries in the "OAuth IANA has registered the following entries in the "OAuth Parameters
Parameters CBOR Mappings" registry following the procedure specified CBOR Mappings" registry, following the procedure specified in
in Section 8.10 of [RFC9200]. Section 8.10 of [RFC9200].
* Name: sign_info
* CBOR Key: TBD (range -256 to 255)
* Value Type: Simple value "null" / array
* Reference: [RFC-XXXX]
* Name: kdcchallenge
* CBOR Key: TBD (range -256 to 255)
* Value Type: Byte string Name: sign_info
CBOR Key: 45
Value Type: Null or array
Reference: RFC 9594
* Reference: [RFC-XXXX] Name: kdcchallenge
CBOR Key: 46
Value Type: byte string
Reference: RFC 9594
11.5. Interface Description (if=) Link Target Attribute Values 11.5. Interface Description (if=) Link Target Attribute Values
IANA is asked to register the following entry in the "Interface IANA has registered the following entry in the "Interface Description
Description (if=) Link Target Attribute Values" registry within the (if=) Link Target Attribute Values" registry within the "Constrained
"CoRE Parameters" registry group. RESTful Environments (CoRE) Parameters" registry group.
* Value: ace.groups
* Description: The KDC interface at the parent resource of group- Value: ace.groups
Description: The KDC interface at the parent resource of group-
membership resources is used to retrieve names of security groups membership resources is used to retrieve names of security groups
using the ACE framework. using the ACE framework.
Reference: Section 4.1 of RFC 9594
* Reference: Section 4.1 of [RFC-XXXX] Value: ace.group
Description: The KDC interface at a group-membership resource is
* Value: ace.group
* Description: The KDC interface at a group-membership resource is
used to provision keying material and related information and used to provision keying material and related information and
policies to members of the corresponding security group using the policies to members of the corresponding security group using the
ACE framework. ACE framework.
Reference: Section 4.1 of RFC 9594
* Reference: Section 4.1 of [RFC-XXXX]
11.6. Custom Problem Detail Keys Registry 11.6. Custom Problem Detail Keys Registry
IANA is asked to register the following entry in the "Custom Problem IANA has registered the following entry in the "Custom Problem Detail
Detail Keys" registry within the "CoRE Parameters" registry group. Keys" registry within the "Constrained RESTful Environments (CoRE)
Parameters" registry group.
* Key Value: TBD
* Name: ace-groupcomm-error
* Brief Description: Carry [RFC-XXXX] problem details in a Concise Key Value: 0
Name: ace-groupcomm-error
Brief Description: Carry RFC 9594 problem details in a Concise
Problem Details data item. Problem Details data item.
Change Controller: IETF
* Change Controller: IETF Reference: RFC 9594, Section 4.1.2
* Reference: Section 4.1.2 of [RFC-XXXX]
11.7. ACE Groupcomm Parameters 11.7. ACE Groupcomm Parameters
This specification establishes the "ACE Groupcomm Parameters" IANA This specification has established the "ACE Groupcomm Parameters"
registry within the "Authentication and Authorization for Constrained IANA registry within the "Authentication and Authorization for
Environments (ACE)" registry group. Constrained Environments (ACE)" registry group.
The registry has been created to use the "Expert Review" registration Values in this registry are covered by different registration
procedure [RFC8126]. Expert review guidelines are provided in policies as indicated below. Some policies require Expert Review;
Section 11.14. Values in this registry are covered by different guidelines are provided in Section 11.14
registration policies as indicated. It should be noted that, in
addition to the expert review, some portions of the registry require
a specification, potentially a Standards Track RFC, to be supplied as
well.
The columns of this registry are: The columns of this registry are:
* Name: This is a descriptive name that enables easier reference to Name: This is a descriptive name that enables easier reference to
the item. The name MUST be unique. It is not used in the the item. The name MUST be unique. It is not used in the
encoding. encoding.
* CBOR Key: This is the value used as the CBOR key of the item. CBOR Key: This is the value used as the CBOR map key of the item.
These values MUST be unique. The value can be a positive integer, These values MUST be unique. The value can be a positive integer,
a negative integer, or a text string. Different ranges of values a negative integer, or a text string. Different ranges of values
use different registration policies [RFC8126]. Integer values use different registration policies [RFC8126]. Integer values
from -256 to 255 as well as text strings of length 1 are from -256 to 255 as well as text strings of length 1 are
designated as "Standards Action With Expert Review". Integer designated as "Standards Action With Expert Review". Integer
values from -65536 to -257 and from 256 to 65535, as well as text values from -65536 to -257 and from 256 to 65535 as well as text
strings of length 2 are designated as "Specification Required". strings of length 2 are designated as "Specification Required".
Integer values greater than 65535 as well as text strings of Integer values greater than 65535 as well as text strings of
length greater than 2 are designated as "Expert Review". Integer length greater than 2 are designated as "Expert Review". Integer
values less than -65536 are marked as "Private Use". values less than -65536 are marked as "Private Use".
* CBOR Type: This contains the CBOR type of the item, or a pointer CBOR Type: This field contains the CBOR type of the item or a
to the registry that defines its type, when that depends on pointer to the registry that defines its type when that depends on
another item. another item.
* Reference: This contains a pointer to the public specification for Reference: This field contains a pointer to the public specification
the item. for the item.
This registry has been initially populated with the values in This registry has been initially populated with the values in
Figure 42. Table 5.
11.8. ACE Groupcomm Key Types 11.8. ACE Groupcomm Key Types
This specification establishes the "ACE Groupcomm Key Types" IANA This specification establishes the "ACE Groupcomm Key Types" IANA
registry within the "Authentication and Authorization for Constrained registry within the "Authentication and Authorization for Constrained
Environments (ACE)" registry group. Environments (ACE)" registry group.
The registry has been created to use the "Expert Review" registration Values in this registry are covered by different registration
procedure [RFC8126]. Expert review guidelines are provided in policies as indicated below. Some policies require Expert Review;
Section 11.14. Values in this registry are covered by different guidelines are provided in Section 11.14.
registration policies as indicated. It should be noted that, in
addition to the expert review, some portions of the registry require
a specification, potentially a Standards Track RFC, to be supplied as
well.
The columns of this registry are: The columns of this registry are:
* Name: This is a descriptive name that enables easier reference to Name: This is a descriptive name that enables easier reference to
the item. The name MUST be unique. It is not used in the the item. The name MUST be unique. It is not used in the
encoding. encoding.
* Key Type Value: This is the value used to identify the keying Key Type Value: This is the value used to identify the keying
material. These values MUST be unique. The value can be a material. These values MUST be unique. The value can be a
positive integer, a negative integer, or a text string. Different positive integer, a negative integer, or a text string. Different
ranges of values use different registration policies [RFC8126]. ranges of values use different registration policies [RFC8126].
Integer values from -256 to 255 as well as text strings of length Integer values from -256 to 255 as well as text strings of length
1 are designated as "Standards Action With Expert Review". 1 are designated as "Standards Action With Expert Review".
Integer values from -65536 to -257 and from 256 to 65535, as well Integer values from -65536 to -257 and from 256 to 65535 as well
as text strings of length 2 are designated as "Specification as text strings of length 2 are designated as "Specification
Required". Integer values greater than 65535 as well as text Required". Integer values greater than 65535 as well as text
strings of length greater than 2 are designated as "Expert strings of length greater than 2 are designated as "Expert
Review". Integer values less than -65536 are marked as "Private Review". Integer values less than -65536 are marked as "Private
Use". Use".
* Profile: This field may contain one or more descriptive strings of Profile: This field may contain one or more descriptive strings of
application profiles to be used with this item. The values should application profiles to be used with this item. The values should
be taken from the Name column of the "ACE Groupcomm Profiles" be taken from the "Name" column of the "ACE Groupcomm Profiles"
registry. registry.
* Description: This field contains a brief description of the keying Description: This field contains a brief description of the keying
material. material.
* Reference: This contains a pointer to the public specification for Reference: This field contains a pointer to the public specification
the format of the keying material, if one exists. for the format of the keying material, if one exists.
This registry has been initially populated with the value in This registry has been initially populated with the value in Table 1.
Figure 11.
11.9. ACE Groupcomm Profiles 11.9. ACE Groupcomm Profiles
This specification establishes the "ACE Groupcomm Profiles" IANA This specification establishes the "ACE Groupcomm Profiles" IANA
registry within the "Authentication and Authorization for Constrained registry within the "Authentication and Authorization for Constrained
Environments (ACE)" registry group. Environments (ACE)" registry group.
The registry has been created to use the "Expert Review" registration Values in this registry are covered by different registration
procedure [RFC8126]. Expert review guidelines are provided in policies as indicated below. Some policies require Expert Review;
Section 11.14. Values in this registry are covered by different guidelines are provided in Section 11.14.
registration policies as indicated. It should be noted that, in
addition to the expert review, some portions of the registry require
a specification, potentially a Standards Track RFC, to be supplied as
well.
The columns of this registry are: The columns of this registry are:
* Name: The name of the application profile, to be used as value of Name: The name of the application profile.
the profile attribute.
* Description: Text giving an overview of the application profile Description: Text giving an overview of the application profile and
and the context it is developed for. the context it is developed for.
* CBOR Value: CBOR abbreviation for the name of this application CBOR Value: CBOR abbreviation for the name of this application
profile. These values MUST be unique. The value can be a profile. These values MUST be unique. The value can be a
positive integer or a negative integer. Different ranges of positive integer or a negative integer. Different ranges of
values use different registration policies [RFC8126]. Integer values use different registration policies [RFC8126]. Integer
values from -256 to 255 are designated as "Standards Action With values from -256 to 255 are designated as "Standards Action With
Expert Review". Integer values from -65536 to -257 and from 256 Expert Review". Integer values from -65536 to -257 and from 256
to 65535 are designated as "Specification Required". Integer to 65535 are designated as "Specification Required". Integer
values greater than 65535 are designated as "Expert Review". values greater than 65535 are designated as "Expert Review".
Integer values less than -65536 are marked as "Private Use". Integer values less than -65536 are marked as "Private Use".
* Reference: This contains a pointer to the public specification of Reference: This field contains a pointer to the public specification
the abbreviation for this application profile, if one exists. for this application profile, if one exists.
This registry has been initially populated with the value in This registry has been initially populated with the value in Table 2.
Figure 12.
11.10. ACE Groupcomm Policies 11.10. ACE Groupcomm Policies
This specification establishes the "ACE Groupcomm Policies" IANA This specification establishes the "ACE Groupcomm Policies" IANA
registry within the "Authentication and Authorization for Constrained registry within the "Authentication and Authorization for Constrained
Environments (ACE)" registry group. Environments (ACE)" registry group.
The registry has been created to use the "Expert Review" registration Values in this registry are covered by different registration
procedure [RFC8126]. Expert review guidelines are provided in policies as indicated below. Some policies require Expert Review;
Section 11.14. Values in this registry are covered by different guidelines are provided in Section 11.14.
registration policies as indicated. It should be noted that, in
addition to the expert review, some portions of the registry require
a specification, potentially a Standards Track RFC, to be supplied as
well.
The columns of this registry are: The columns of this registry are:
* Name: The name of the group communication policy. Name: The name of the group communication policy.
* CBOR label: The value to be used to identify this group CBOR Label: The value to be used to identify this group
communication policy. These values MUST be unique. The value can communication policy. These values MUST be unique. The value can
be a positive integer, a negative integer, or a text string. be a positive integer, a negative integer, or a text string.
Different ranges of values use different registration policies Different ranges of values use different registration policies
[RFC8126]. Integer values from -256 to 255 as well as text [RFC8126]. Integer values from -256 to 255 as well as text
strings of length 1 are designated as "Standards Action With strings of length 1 are designated as "Standards Action With
Expert Review". Integer values from -65536 to -257 and from 256 Expert Review". Integer values from -65536 to -257 and from 256
to 65535, as well as text strings of length 2 are designated as to 65535 as well as text strings of length 2 are designated as
"Specification Required". Integer values greater than 65535 as "Specification Required". Integer values greater than 65535 as
well as text strings of length greater than 2 are designated as well as text strings of length greater than 2 are designated as
"Expert Review". Integer values less than -65536 are marked as "Expert Review". Integer values less than -65536 are marked as
"Private Use". "Private Use".
* CBOR type: the CBOR type used to encode the value of this group CBOR Type: The CBOR type used to encode the value of this group
communication policy. communication policy.
* Description: This field contains a brief description for this Description: This field contains a brief description for this group
group communication policy. communication policy.
* Reference: This field contains a pointer to the public Reference: This field contains a pointer to the public specification
specification providing the format of the group communication for this group communication policy and its format, if one exists.
policy, if one exists.
This registry has been initially populated with the values in This registry has been initially populated with the values in
Figure 13. Table 3.
11.11. Sequence Number Synchronization Methods 11.11. Sequence Number Synchronization Methods
This specification establishes the "Sequence Number Synchronization This specification establishes the "Sequence Number Synchronization
Methods" IANA registry within the "Authentication and Authorization Methods" IANA registry within the "Authentication and Authorization
for Constrained Environments (ACE)" registry group. for Constrained Environments (ACE)" registry group.
The registry has been created to use the "Expert Review" registration Values in this registry are covered by different registration
procedure [RFC8126]. Expert review guidelines are provided in policies as indicated below. Some policies require Expert Review;
Section 11.14. Values in this registry are covered by different guidelines are provided in Section 11.14.
registration policies as indicated. It should be noted that, in
addition to the expert review, some portions of the registry require
a specification, potentially a Standards Track RFC, to be supplied as
well.
The columns of this registry are: The columns of this registry are:
* Name: The name of the sequence number synchronization method. Name: The name of the sequence number synchronization method.
* Value: The value to be used to identify this sequence number Value: The value to be used to identify this sequence number
synchronization method. These values MUST be unique. The value synchronization method. These values MUST be unique. The value
can be a positive integer, a negative integer, or a text string. can be a positive integer, a negative integer, or a text string.
Different ranges of values use different registration policies Different ranges of values use different registration policies
[RFC8126]. Integer values from -256 to 255 as well as text [RFC8126]. Integer values from -256 to 255 as well as text
strings of length 1 are designated as "Standards Action With strings of length 1 are designated as "Standards Action With
Expert Review". Integer values from -65536 to -257 and from 256 Expert Review". Integer values from -65536 to -257 and from 256
to 65535, as well as text strings of length 2 are designated as to 65535 as well as text strings of length 2 are designated as
"Specification Required". Integer values greater than 65535 as "Specification Required". Integer values greater than 65535 as
well as text strings of length greater than 2 are designated as well as text strings of length greater than 2 are designated as
"Expert Review". Integer values less than -65536 are marked as "Expert Review". Integer values less than -65536 are marked as
"Private Use". "Private Use".
* Description: This field contains a brief description for this Description: This field contains a brief description for this
sequence number synchronization method. sequence number synchronization method.
* Reference: This field contains a pointer to the public Reference: This field contains a pointer to the public specification
specification describing the sequence number synchronization describing the sequence number synchronization method.
method.
11.12. ACE Groupcomm Errors 11.12. ACE Groupcomm Errors
This specification establishes the "ACE Groupcomm Errors" IANA This specification establishes the "ACE Groupcomm Errors" IANA
registry within the "Authentication and Authorization for Constrained registry within the "Authentication and Authorization for Constrained
Environments (ACE)" registry group. Environments (ACE)" registry group.
The registry has been created to use the "Expert Review" registration Values in this registry are covered by different registration
procedure [RFC8126]. Expert review guidelines are provided in policies as indicated below. Some policies require Expert Review;
Section 11.14. Values in this registry are covered by different guidelines are provided in Section 11.14.
registration policies as indicated. It should be noted that, in
addition to the expert review, some portions of the registry require
a specification, potentially a Standards Track RFC, to be supplied as
well.
The columns of this registry are: The columns of this registry are:
* Value: The value to be used to identify the error. These values Value: The value to be used to identify the error. These values
MUST be unique. The value can be a positive integer or a negative MUST be unique. The value can be a positive integer or a negative
integer. Different ranges of values use different registration integer. Different ranges of values use different registration
policies [RFC8126]. Integer values from -256 to 255 are policies [RFC8126]. Integer values from -256 to 255 are
designated as "Standards Action With Expert Review". Integer designated as "Standards Action With Expert Review". Integer
values from -65536 to -257 and from 256 to 65535 are designated as values from -65536 to -257 and from 256 to 65535 are designated as
"Specification Required". Integer values greater than 65535 are "Specification Required". Integer values greater than 65535 are
designated as "Expert Review". Integer values less than -65536 designated as "Expert Review". Integer values less than -65536
are marked as "Private Use". are marked as "Private Use".
* Description: This field contains a brief description of the error. Description: This field contains a brief description of the error.
* Reference: This field contains a pointer to the public Reference: This field contains a pointer to the public specification
specification defining the error, if one exists. defining the error, if one exists.
This registry has been initially populated with the values in This registry has been initially populated with the values in
Figure 43. The Reference column for all of these entries refers to Table 6. The "Reference" column for all of these entries refers to
this document. this document.
11.13. ACE Groupcomm Rekeying Schemes 11.13. ACE Groupcomm Rekeying Schemes
This specification establishes the "ACE Groupcomm Rekeying Schemes" This specification establishes the "ACE Groupcomm Rekeying Schemes"
IANA registry within the "Authentication and Authorization for IANA registry within the "Authentication and Authorization for
Constrained Environments (ACE)" registry group. Constrained Environments (ACE)" registry group.
The registry has been created to use the "Expert Review" registration Values in this registry are covered by different registration
procedure [RFC8126]. Expert review guidelines are provided in policies as indicated below. Some policies require Expert Review;
Section 11.14. Values in this registry are covered by different guidelines are provided in Section 11.14.
registration policies as indicated. It should be noted that, in
addition to the expert review, some portions of the registry require
a specification, potentially a Standards Track RFC, to be supplied as
well.
The columns of this registry are: The columns of this registry are:
* Value: The value to be used to identify the group rekeying scheme. Value: The value to be used to identify the group rekeying scheme.
These values MUST be unique. The value can be a positive integer These values MUST be unique. The value can be a positive integer
or a negative integer. Different ranges of values use different or a negative integer. Different ranges of values use different
registration policies [RFC8126]. Integer values from -256 to 255 registration policies [RFC8126]. Integer values from -256 to 255
are designated as "Standards Action With Expert Review". Integer are designated as "Standards Action With Expert Review". Integer
values from -65536 to -257 and from 256 to 65535 are designated as values from -65536 to -257 and from 256 to 65535 are designated as
"Specification Required". Integer values greater than 65535 are "Specification Required". Integer values greater than 65535 are
designated as "Expert Review". Integer values less than -65536 designated as "Expert Review". Integer values less than -65536
are marked as "Private Use". are marked as "Private Use".
* Name: The name of the group rekeying scheme. Name: The name of the group rekeying scheme.
* Description: This field contains a brief description of the group Description: This field contains a brief description of the group
rekeying scheme. rekeying scheme.
* Reference: This field contains a pointer to the public Reference: This field contains a pointer to the public specification
specification defining the group rekeying scheme, if one exists. defining the group rekeying scheme, if one exists.
This registry has been initially populated with the value in This registry has been initially populated with the value in Table 4.
Figure 14.
11.14. Expert Review Instructions 11.14. Expert Review Instructions
The IANA Registries established in this document are defined as The IANA registries established in this document are defined as
expert review. This section gives some general guidelines for what Expert Review. This section gives some general guidelines for what
the experts should be looking for, but they are being designated as the experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude. experts for a reason so they should be given substantial latitude.
Expert reviewers should take into consideration the following points: Expert Reviewers should take into consideration the following points:
* Point squatting should be discouraged. Reviewers are encouraged * Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure to get sufficient information for registration requests to ensure
that the usage is not going to duplicate one that is already that the usage is not going to duplicate one that is already
registered and that the point is likely to be used in deployments. registered and that the point is likely to be used in deployments.
The zones tagged as private use are intended for testing purposes The zones tagged as "Private Use" are intended for testing
and closed environments, code points in other ranges should not be purposes and closed environments; code points in other ranges
assigned for testing. should not be assigned for testing.
* Specifications are required for the standards track range of point * Specifications are required for the Standards Track range of point
assignment. Specifications should exist for specification assignment. Specifications should exist for Specification
required ranges, but early assignment before a specification is Required ranges, but early assignment before a specification is
available is considered to be permissible. When specifications available is considered to be permissible. When specifications
are not provided, the description provided needs to have are not provided, the description provided needs to have
sufficient information to identify what the point is being used sufficient information to identify what the point is being used
for. for.
* Experts should take into account the expected usage of fields when * Experts should take into account the expected usage of fields when
approving point assignments. The fact that there is a range for approving point assignments. The fact that there is a range for
Standards Track documents does not mean that a Standards Track Standards Track documents does not mean that a Standards Track
document cannot have points assigned outside of that range. The document cannot have points assigned outside of that range. The
length of the encoded value should be weighed against how many length of the encoded value should be weighed against how many
code points of that length are left, the size of device it will be code points of that length are left, the size of the device it
used on, and the number of code points left that encode to that will be used on, and the number of code points left that encode to
size. that size.
12. References 12. References
12.1. Normative References 12.1. Normative References
[CBOR.Tags] [CBOR.Tags]
IANA, "Concise Binary Object Representation (CBOR) Tags", IANA, "Concise Binary Object Representation (CBOR) Tags",
<https://www.iana.org/assignments/cbor-tags/cbor- <https://www.iana.org/assignments/cbor-tags/>.
tags.xhtml>.
[CoAP.Content.Formats] [CoAP.Content.Formats]
IANA, "CoAP Content-Formats", IANA, "CoAP Content-Formats",
<https://www.iana.org/assignments/core-parameters/core- <https://www.iana.org/assignments/core-parameters/>.
parameters.xhtml#content-formats>.
[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.Header.Parameters] [COSE.Header.Parameters]
IANA, "COSE Header Parameters", IANA, "COSE Header Parameters",
<https://www.iana.org/assignments/cose/cose.xhtml#header- <https://www.iana.org/assignments/cose/>.
parameters>.
[COSE.Key.Types] [COSE.Key.Types]
IANA, "COSE key Types", IANA, "COSE Key Types",
<https://www.iana.org/assignments/cose/cose.xhtml#key- <https://www.iana.org/assignments/cose/>.
type>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/rfc/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/rfc/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[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/rfc/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
Bose, "Constrained Application Protocol (CoAP) Option for Bose, "Constrained Application Protocol (CoAP) Option for
No Server Response", RFC 7967, DOI 10.17487/RFC7967, No Server Response", RFC 7967, DOI 10.17487/RFC7967,
August 2016, <https://www.rfc-editor.org/rfc/rfc7967>. August 2016, <https://www.rfc-editor.org/info/rfc7967>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[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/rfc/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/rfc/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/rfc/rfc8747>. 2020, <https://www.rfc-editor.org/info/rfc8747>.
[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/rfc/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052, Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022, DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>. <https://www.rfc-editor.org/info/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/rfc/rfc9053>. August 2022, <https://www.rfc-editor.org/info/rfc9053>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and [RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022, (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/rfc/rfc9200>. <https://www.rfc-editor.org/info/rfc9200>.
[RFC9237] Bormann, C., "An Authorization Information Format (AIF) [RFC9237] Bormann, C., "An Authorization Information Format (AIF)
for Authentication and Authorization for Constrained for Authentication and Authorization for Constrained
Environments (ACE)", RFC 9237, DOI 10.17487/RFC9237, Environments (ACE)", RFC 9237, DOI 10.17487/RFC9237,
August 2022, <https://www.rfc-editor.org/rfc/rfc9237>. August 2022, <https://www.rfc-editor.org/info/rfc9237>.
[RFC9290] Fossati, T. and C. Bormann, "Concise Problem Details for [RFC9290] Fossati, T. and C. Bormann, "Concise Problem Details for
Constrained Application Protocol (CoAP) APIs", RFC 9290, Constrained Application Protocol (CoAP) APIs", RFC 9290,
DOI 10.17487/RFC9290, October 2022, DOI 10.17487/RFC9290, October 2022,
<https://www.rfc-editor.org/rfc/rfc9290>. <https://www.rfc-editor.org/info/rfc9290>.
[RFC9338] Schaad, J., "CBOR Object Signing and Encryption (COSE): [RFC9338] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Countersignatures", STD 96, RFC 9338, Countersignatures", STD 96, RFC 9338,
DOI 10.17487/RFC9338, December 2022, DOI 10.17487/RFC9338, December 2022,
<https://www.rfc-editor.org/rfc/rfc9338>. <https://www.rfc-editor.org/info/rfc9338>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-core-coap-pubsub] [C509-CERT]
Preuß Mattsson, J., 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-11, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
cbor-encoded-cert-11>.
[CoAP-PUBSUB]
Jimenez, J., Koster, M., and A. Keränen, "A publish- Jimenez, J., Koster, M., and A. Keränen, "A publish-
subscribe architecture for the Constrained Application subscribe architecture for the Constrained Application
Protocol (CoAP)", Work in Progress, Internet-Draft, draft- Protocol (CoAP)", Work in Progress, Internet-Draft, draft-
ietf-core-coap-pubsub-13, 20 October 2023, ietf-core-coap-pubsub-14, 18 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-core- <https://datatracker.ietf.org/doc/html/draft-ietf-core-
coap-pubsub-13>. coap-pubsub-14>.
[I-D.ietf-core-groupcomm-bis] [GROUP-CoAP]
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-
10, 23 October 2023, 11, 24 April 2024, <https://datatracker.ietf.org/doc/html/
<https://datatracker.ietf.org/doc/html/draft-ietf-core- draft-ietf-core-groupcomm-bis-11>.
groupcomm-bis-10>.
[I-D.ietf-core-oscore-groupcomm] [GROUP-OSCORE]
Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., Tiloca, M., Selander, G., Palombini, F., Preuß Mattsson,
and J. Park, "Group Object Security for Constrained J., and R. Höglund, "Group Object Security for Constrained
RESTful Environments (Group OSCORE)", Work in Progress, RESTful Environments (Group OSCORE)", Work in Progress,
Internet-Draft, draft-ietf-core-oscore-groupcomm-20, 2 Internet-Draft, draft-ietf-core-oscore-groupcomm-22, 28
September 2023, <https://datatracker.ietf.org/doc/html/ August 2024, <https://datatracker.ietf.org/doc/html/draft-
draft-ietf-core-oscore-groupcomm-20>. ietf-core-oscore-groupcomm-21>.
[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-07, 20 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
cbor-encoded-cert-07>.
[I-D.tiloca-core-oscore-discovery] [OSCORE-DISCOVERY]
Tiloca, M., Amsüss, C., and P. Van der Stok, "Discovery of Tiloca, M., Amsüss, C., and P. Van der 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-14, 8 September 2023, discovery-16, 4 September 2024,
<https://datatracker.ietf.org/doc/html/draft-tiloca-core- <https://datatracker.ietf.org/doc/html/draft-tiloca-core-
oscore-discovery-14>. oscore-discovery-16>.
[RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Specification", RFC 2093, Protocol (GKMP) Specification", RFC 2093,
DOI 10.17487/RFC2093, July 1997, DOI 10.17487/RFC2093, July 1997,
<https://www.rfc-editor.org/rfc/rfc2093>. <https://www.rfc-editor.org/info/rfc2093>.
[RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC 2094, Protocol (GKMP) Architecture", RFC 2094,
DOI 10.17487/RFC2094, July 1997, DOI 10.17487/RFC2094, July 1997,
<https://www.rfc-editor.org/rfc/rfc2094>. <https://www.rfc-editor.org/info/rfc2094>.
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627, Multicast: Issues and Architectures", RFC 2627,
DOI 10.17487/RFC2627, June 1999, DOI 10.17487/RFC2627, June 1999,
<https://www.rfc-editor.org/rfc/rfc2627>. <https://www.rfc-editor.org/info/rfc2627>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[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/rfc/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959, the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016, DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/rfc/rfc7959>. <https://www.rfc-editor.org/info/rfc7959>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[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/rfc/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
[RFC9202] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and [RFC9202] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS) L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for Profile for Authentication and Authorization for
Constrained Environments (ACE)", RFC 9202, Constrained Environments (ACE)", RFC 9202,
DOI 10.17487/RFC9202, August 2022, DOI 10.17487/RFC9202, August 2022,
<https://www.rfc-editor.org/rfc/rfc9202>. <https://www.rfc-editor.org/info/rfc9202>.
[RFC9203] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, [RFC9203] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"The Object Security for Constrained RESTful Environments "The Object Security for Constrained RESTful Environments
(OSCORE) Profile of the Authentication and Authorization (OSCORE) Profile of the Authentication and Authorization
for Constrained Environments (ACE) Framework", RFC 9203, for Constrained Environments (ACE) Framework", RFC 9203,
DOI 10.17487/RFC9203, August 2022, DOI 10.17487/RFC9203, August 2022,
<https://www.rfc-editor.org/rfc/rfc9203>. <https://www.rfc-editor.org/info/rfc9203>.
[RFC9277] Richardson, M. and C. Bormann, "On Stable Storage for [RFC9277] Richardson, M. and C. Bormann, "On Stable Storage for
Items in Concise Binary Object Representation (CBOR)", Items in Concise Binary Object Representation (CBOR)",
RFC 9277, DOI 10.17487/RFC9277, August 2022, RFC 9277, DOI 10.17487/RFC9277, August 2022,
<https://www.rfc-editor.org/rfc/rfc9277>. <https://www.rfc-editor.org/info/rfc9277>.
[RFC9431] Sengul, C. and A. Kirby, "Message Queuing Telemetry [RFC9431] Sengul, C. and A. Kirby, "Message Queuing Telemetry
Transport (MQTT) and Transport Layer Security (TLS) Transport (MQTT) and Transport Layer Security (TLS)
Profile of Authentication and Authorization for Profile of Authentication and Authorization for
Constrained Environments (ACE) Framework", RFC 9431, Constrained Environments (ACE) Framework", RFC 9431,
DOI 10.17487/RFC9431, July 2023, DOI 10.17487/RFC9431, July 2023,
<https://www.rfc-editor.org/rfc/rfc9431>. <https://www.rfc-editor.org/info/rfc9431>.
Appendix A. Requirements for Application Profiles Appendix A. Requirements for Application Profiles
This section lists the requirements for application profiles of this This section lists the requirements for application profiles of this
specification, for the convenience of application profile designers. specification for the convenience of application profile designers.
A.1. Mandatory-to-Address Requirements A.1. Mandatory-to-Address Requirements
* REQ1: Specify the format and encoding of 'scope'. This includes REQ1: Specify the format and encoding of scope. This includes
defining the set of possible roles and their identifiers, as well defining the set of possible roles and their identifiers, as
as the corresponding encoding to use in the scope entries well as the corresponding encoding to use in the scope
according to the used scope format (see Section 3.1). entries according to the used scope format (see Section 3.1).
* REQ2: If the AIF format of 'scope' is used, register its specific REQ2: If scope uses AIF, register its specific instance of "Toid"
instance of "Toid" and "Tperm" as Media Type parameters and a and "Tperm" as media type parameters and a corresponding
corresponding Content-Format, as per the guidelines in [RFC9237]. Content-Format, as per the guidelines in [RFC9237].
* REQ3: If used, specify the acceptable values for 'sign_alg' (see REQ3: If used, specify the acceptable values for the 'sign_alg'
Section 3.3). parameter (see Section 3.3.1).
* REQ4: If used, specify the acceptable values for 'sign_parameters' REQ4: If used, specify the acceptable values and structure for the
(see Section 3.3). 'sign_parameters' parameter (see Section 3.3.1).
* REQ5: If used, specify the acceptable values for REQ5: If used, specify the acceptable values and structure for the
'sign_key_parameters' (see Section 3.3). 'sign_key_parameters' parameter (see Section 3.3.1).
* REQ6: Specify the acceptable formats for authentication REQ6: Specify the acceptable formats for authentication credentials
credentials and, if used, the acceptable values for 'cred_fmt' and, if applicable, the acceptable values for the 'cred_fmt'
(see Section 3.3). parameter (see Section 3.3.1).
* REQ7: If the value of the GROUPNAME URI path and the group name in REQ7: If the value of the GROUPNAME URI path and the group name in
the access token scope (gname in Section 3.2) are not required to the access token scope ('gname' in Section 3.1) are not
coincide, specify the mechanism to map the GROUPNAME value in the required to coincide, specify the mechanism to map the
URI to the group name (see Section 4.1). GROUPNAME value in the URI to the group name (see
Section 4.1).
* REQ8: Define whether the KDC has an authentication credential and REQ8: Define whether the KDC has an authentication credential as
if this has to be provided through the 'kdc_cred' parameter, see required for the correct group operation and if this has to
Section 4.3.1. be provided through the 'kdc_cred' parameter (see Sections
4.1 and 4.3.1).
* REQ9: Specify if any part of the KDC interface as defined in this REQ9: Specify if any part of the KDC interface as defined in this
document is not supported by the KDC (see Section 4.1). document is not supported by the KDC (see Section 4.1).
* REQ10: Register a Resource Type for the group-membership resource, REQ10: Register a Resource Type for the group-membership resources,
which is used to discover the correct URL for sending a Join which is used to discover the correct URL for sending a Join
Request to the KDC (see Section 4.1). Request to the KDC (see Section 4.1).
* REQ11: Define what specific actions (e.g., CoAP methods) are REQ11: Define what specific actions (e.g., CoAP methods) are allowed
allowed on each resource provided by the KDC interface, depending on each resource that are accessible through the KDC
on whether the Client is a current group member; the roles that a interface, depending on: whether the Client is a current
Client is authorized to take as per the obtained access token (see group member; the roles that a Client is authorized to take
Section 3.1); and the roles that the Client has as current group as per the obtained access token (see Section 3.1); and the
member. roles that the Client has as a current group member.
* REQ12: Categorize possible newly defined operations for Clients REQ12: Categorize possible newly defined operations for Clients into
into primary operations expected to be minimally supported and primary operations expected to be minimally supported and
secondary operations, and provide accompanying considerations (see secondary operations, and provide accompanying considerations
Section 4.1.1). (see Section 4.1.1).
* REQ13: Specify the encoding of group identifier (see REQ13: Specify the encoding of group identifiers (see
Section 4.2.1). Section 4.2.1).
* REQ14: Specify the approaches used to compute and verify the PoP REQ14: Specify the approaches used to compute and verify the PoP
evidence to include in 'client_cred_verify', and which of those evidence to include in the 'client_cred_verify' parameter and
approaches is used in which case (see Section 4.3.1). which of those approaches is used in which case (see
Section 4.3.1).
* REQ15: Specify how the nonce N_S is generated, if the token is not REQ15: Specify how the nonce N_S is generated, if the access token
provided to the KDC through the Token Transfer Request to the is not provided to the KDC through the Token Transfer Request
authz-info endpoint (e.g., if it is used directly to validate TLS sent to the /authz-info endpoint (e.g., the access token is
instead). instead transferred during the establishment of a secure
communication association).
* REQ16 Define the initial value of the 'num' parameter (see REQ16: Define the initial value of the version number for the group
Section 4.3.1). keying material (see Section 4.3.1).
* REQ17: Specify the format of the 'key' parameter and register a REQ17: Specify the format of the group keying material that is
corresponding entry in the "ACE Groupcomm Key Types" IANA registry conveyed in the 'key' parameter (see Section 4.3.1).
(see Section 4.3.1).
* REQ18: Specify the acceptable values of the 'gkty' parameter (see REQ18: Specify the acceptable values of the 'gkty' parameter (see
Section 4.3.1). Section 4.3.1). For each of them, register a corresponding
entry in the "ACE Groupcomm Key Types" IANA registry if such
an entry does not exist already.
* REQ19: Specify and register the application profile identifier REQ19: Specify and register the application profile identifier (see
(see Section 4.3.1). Section 4.3.1).
* REQ20: If used, specify the format and content of 'group_policies' REQ20: If used, specify the format and default values of the entries
and its entries. Specify the policies default values (see of the CBOR map to include in the 'group_policies' parameter
Section 4.3.1). (see Section 4.3.1).
* REQ21: Specify the approaches used to compute and verify the PoP REQ21: Specify the approaches used to compute and verify the PoP
evidence to include in 'kdc_cred_verify', and which of those evidence to include in the 'kdc_cred_verify' parameter and
approaches is used in which case (see Section 4.3.1 and which of those approaches is used in which case (see Sections
Section 4.5.1). If external signature verifiers are supported, 4.3.1 and 4.5.1). If external signature verifiers are
specify how those provide a nonce to the KDC to be used for supported, specify how those provide a nonce to the KDC to be
computing the PoP evidence (see Section 4.5.1). used for computing the PoP evidence (see Section 4.5.1).
* REQ22: Specify the communication protocol that the members of the REQ22: Specify the communication protocol that members of the group
group must use (e.g., CoAP for group communication). use to communicate with each other (e.g., CoAP for group
communication).
* REQ23: Specify the security protocol the group members must use to REQ23: Specify the security protocol that members of the group use
protect their communication (e.g., group OSCORE). This must to protect the group communication (e.g., Group OSCORE).
provide encryption, integrity, and replay protection. This must provide encryption, integrity, and replay
protection.
* REQ24: Specify how the communication is secured between Client and REQ24: Specify how the communication is secured between the Client
KDC. Optionally, specify a transport profile of ACE [RFC9200] to and the KDC. Optionally, specify a transport profile of ACE
use between Client and KDC (see Section 4.3.1.1). [RFC9200] to use between the Client and the KDC (see
Section 4.3.1.1).
* REQ25: Specify the format of the identifiers of group members (see REQ25: Specify the format of the node identifiers of group members
Section 4.3.1 and Section 4.4.1). (see Sections 4.3.1 and 4.4.1).
* REQ26: Specify policies at the KDC to handle ids that are not REQ26: Specify policies at the KDC to handle node identifiers that
included in 'get_creds' (see Section 4.4.1). are included in the 'get_creds' parameter but are not
associated with any current group member (see Section 4.4.1).
* REQ27: Specify the format of newly-generated individual keying REQ27: Specify the format of (newly generated) individual keying
material for group members, or of the information to derive it, material for group members or of the information to derive
and corresponding CBOR label (see Section 4.8.1). such keying material, as well as the corresponding CBOR map
key that has to be registered in the "ACE Groupcomm
Parameters" registry (see Sections 4.8.1 and 4.8.2).
* REQ28: Specify which CBOR tag is used for identifying the REQ28: Specify which CBOR tag is used for identifying the semantics
semantics of binary scopes, or register a new CBOR tag if a of binary scopes, or register a new CBOR tag if a suitable
suitable one does not exist already (see Section 7). one does not exist already (see Section 7).
* REQ29: Categorize newly defined parameters according to the same REQ29: Categorize newly defined parameters according to the same
criteria of Section 8. criteria of Section 8.
* REQ30: Define whether Clients must, should, or may support the REQ30: Define whether Clients must, should, or may support the
conditional parameters defined in Section 8, and under which conditional parameters defined in Section 8 and under which
circumstances. circumstances.
A.2. Optional-to-Address Requirements A.2. Optional-to-Address Requirements
* OPT1: Optionally, if the textual format of 'scope' is used, OPT1: Optionally, if the textual format of scope is used, specify
specify CBOR values to use for abbreviating the role identifiers CBOR values to use for abbreviating the role identifiers in
in the group (see Section 3.1). the group (see Section 3.1).
* OPT2: Optionally, specify the additional parameters used in the OPT2: Optionally, specify the additional parameters used in the
exchange of Token Transfer Request and Response (see Section 3.3). exchange of Token Transfer Request and Response (see
Section 3.3).
* OPT3: Optionally, specify the negotiation of parameter values for OPT3: Optionally, specify the negotiation of parameter values for
signature algorithm and signature keys, if 'sign_info' is not used signature algorithm and signature keys, if the 'sign_info'
(see Section 3.3). parameter is not used (see Section 3.3).
* OPT4: Optionally, specify possible or required payload formats for OPT4: Optionally, specify possible or required payload formats for
specific error cases. specific error cases (see Section 4.1.2).
* OPT5: Optionally, specify additional identifiers of error types, OPT5: Optionally, specify additional identifiers of error types as
as values of the 'error-id' field within the Custom Problem Detail values of the 'error-id' field within the Custom Problem
entry 'ace-groupcomm-error' (see Section 4.1.2). Detail entry 'ace-groupcomm-error' (see Section 4.1.2).
* OPT6: Optionally, specify the encoding of 'creds_repo' if the OPT6: Optionally, specify the encoding of the 'creds_repo'
default is not used (see Section 4.3.1). parameter if the default one is not used (see Section 4.3.1).
* OPT7: Optionally, specify the functionalities implemented at the OPT7: Optionally, specify the functionalities implemented at the
'control_uri' resource hosted at the Client, including message resource hosted by the Client at the URI indicated in the
exchange encoding and other details (see Section 4.3.1). 'control_uri' parameter, including the encoding of exchanged
messages and other details (see Section 4.3.1).
* OPT8: Optionally, specify the behavior of the handler in case of OPT8: Optionally, specify the behavior of the POST handler of
failure to retrieve an authentication credential for the specific group-membership resources, for the case when it fails to
node (see Section 4.3.1). retrieve an authentication credential for the specific Client
(see Section 4.3.1).
* OPT9: Optionally, define a default group rekeying scheme, to refer OPT9: Optionally, define a default group rekeying scheme to refer
to in case the 'rekeying_scheme' parameter is not included in the to in case the 'rekeying_scheme' parameter is not included in
Join Response (see Section 4.3.1). the Join Response (see Section 4.3.1).
* OPT10: Optionally, specify the functionalities implemented at the OPT10: Optionally, specify the functionalities implemented at the
'control_group_uri' resource hosted at the Client, including resource hosted by the Client at the URI indicated in the
message exchange encoding and other details (see Section 4.3.1). 'control_group_uri' parameter, including the encoding of
exchanged messages and other details (see Section 4.3.1).
* OPT11: Optionally, specify policies that instruct Clients to OPT11: Optionally, specify policies that instruct Clients to retain
retain messages and for how long, if they are unsuccessfully messages and for how long, if those are unsuccessfully
decrypted (see Section 4.8.1.1). This makes it possible to decrypted (see Section 4.8.1.1). This makes it possible for
decrypt such messages after getting updated keying material. Clients to decrypt such messages after obtaining updated
keying material.
* OPT12: Optionally, specify for the KDC to perform group rekeying OPT12: Optionally, specify for the KDC to perform a group rekeying
(together or instead of renewing individual keying material) when when receiving a Key Renewal Request, together with or
receiving a Key Renewal Request (see Section 4.8.2.1). instead of renewing individual keying material (see
Section 4.8.2.1).
* OPT13: Optionally, specify how the identifier of a group member's OPT13: Optionally, specify how the identifier of a group member's
authentication credential is included in requests sent to other authentication credential is included in requests sent to
group members (see Section 4.9.1.1). other group members (see Section 4.9.1.1).
* OPT14: Optionally, specify additional information to include in OPT14: Optionally, specify additional information to include in
rekeying messages for the "Point-to-Point" group rekeying scheme rekeying messages for the "Point-to-Point" group rekeying
(see Section 6). scheme (see Section 6).
Appendix B. Extensibility for Future COSE Algorithms Appendix B. Extensibility for Future COSE Algorithms
As defined in Section 8.1 of [RFC9053], future algorithms can be As defined in Section 8.1 of [RFC9053], future algorithms can be
registered in the "COSE Algorithms" registry [COSE.Algorithms] as registered in the "COSE Algorithms" registry [COSE.Algorithms] as
specifying none or multiple COSE capabilities. specifying none or multiple COSE capabilities.
To enable the seamless use of such future registered algorithms, this To enable the seamless use of such future registered algorithms, this
section defines a general, agile format for each 'sign_info_entry' of section defines a general, agile format for each 'sign_info_entry' of
the 'sign_info' parameter in the Token Transfer Response, see the 'sign_info' parameter in the Token Transfer Response; see
Section 3.3.1. Section 3.3.1.
If any of the currently registered COSE algorithms is considered, If any of the currently registered COSE algorithms are considered,
using this general format yields the same structure of using this general format yields the same structure of
'sign_info_entry' defined in this document, thus ensuring backward 'sign_info_entry' defined in this document, thus ensuring backward
compatibility. compatibility.
B.1. Format of 'sign_info_entry' B.1. Format of 'sign_info_entry'
The format of each 'sign_info_entry' (see Section 3.3.1) is The format of each 'sign_info_entry' (see Section 3.3.1) is
generalized as follows. generalized as follows.
* 'sign_parameters' includes N >= 0 elements, each of which is a * 'sign_parameters' includes N >= 0 elements, each of which is a
COSE capability of the signature algorithm indicated in COSE capability of the signature algorithm indicated in
'sign_alg'. 'sign_alg'.
In particular, 'sign_parameters' has the same format and value of In particular, 'sign_parameters' has the same format and value of
the COSE capabilities array for the signature algorithm indicated the COSE capabilities array for the signature algorithm indicated
in 'sign_alg', as specified for that algorithm in the in 'sign_alg', as specified for that algorithm in the
'Capabilities' column of the "COSE Algorithms" registry "Capabilities" column of the "COSE Algorithms" registry
[COSE.Algorithms]. [COSE.Algorithms].
* 'sign_key_parameters' is replaced by N elements 'sign_capab', each * 'sign_key_parameters' is replaced by N elements 'sign_capab', each
of which is a CBOR array. of which is a CBOR array.
The i-th 'sign_capab' array (i = 0, ..., N-1) is the array of COSE The i-th 'sign_capab' array (i = 0, ..., N-1) is the array of COSE
capabilities for the algorithm capability specified in capabilities for the algorithm capability specified in
'sign_parameters'[i]. 'sign_parameters'[i].
In particular, each 'sign_capab' array has the same format and In particular, each 'sign_capab' array has the same format and
value of the COSE capabilities array for the algorithm capability value of the COSE capabilities array for the algorithm capability
specified in 'sign_parameters'[i]. specified in 'sign_parameters'[i].
Such a COSE capabilities array is currently defined for the Such a COSE capabilities array is currently defined for the
algorithm capability COSE key type, in the "Capabilities" column algorithm capability COSE key type in the "Capabilities" column of
of the "COSE Key Types" registry [COSE.Key.Types]. the "COSE Key Types" registry [COSE.Key.Types].
sign_info_entry = sign_info_entry =
[ [
id : gname / [ + gname ], id : gname / [+ gname],
sign_alg : int / tstr, sign_alg : int / tstr,
sign_parameters : [ * alg_capab : any ], sign_parameters : [* alg_capab : any],
* sign_capab : [ * capab : any ], * sign_capab : [* capab : any],
cred_fmt : int / null cred_fmt : int / null
] ]
gname = tstr gname = tstr
Figure 44: 'sign_info_entry' with general format Figure 38: 'sign_info_entry' with a General Format
Appendix C. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION.
C.1. Version -17 to -18
* Provided more details when early introducing "backward security"
and "forward security".
* Clarified definition and semantics of "group name" and "node
name".
* Clarified definition of "individual keying material".
* Clarified definition of "Dispatcher".
* Enforced consistent use of leading slash in URI paths.
* Fixed CDDL definitions and examples in CBOR diagnostic notation.
* RFC 9290 is used instead of the custom format for error responses.
* Clarified which operations are limited to group members and which
are allowed also to non group members.
* Improved examples of message exchange.
* Added ASCII-art diagrams with examples of group rekeying.
* Clarified for how long nonces are stored at the KDC.
* Clarified that the KDC might not have to store the 'cnonce' from a
Join Request.
* Consistency fix: Clients always support the 'cnonce' parameter.
* Added new parameter 'exi' providing the residual lifetime of the
current group keying material.
* Clarified text about the KDC knowledge of compromised nodes.
* Clarified the impact on performance of a one-to-many group
rekeying.
* Mentioned explicit exceptions to a group rekeying at each group
membership change.
* Explained reasons for delaying a rekeying and halting
communications.
* Fixes in current IANA registrations.
* Added integer abbreviation values for registrations in new IANA
registries.
* IANA registration of two CoRE if= values: "ace.group" and
"ace.groups".
* Editorial fixes and improvements.
C.2. Version -16 to -17
* Expanded definition of "Dispatcher".
* Added definition of "Individual keying material" to the
terminology.
* Early definition of "backward security" and "forward security".
* Clarified high-level breakdown of the key provisioning process in
two phases.
* Fixed the CDDL definition of 'sign_info_entry'.
* Clarified meaning of the 'cred_fmt' and 'exp' parameters.
* Clarified that invariance applies to resources paths, not to
resources.
* Relaxed rule about including the 'peer_roles' parameter.
* Ensured that the KDC always has a Client-side challenge for
computing a proof-of-possession evidence.
* More guidelines for group members that fail to decrypt messages.
* Fetching the latest keying material can happen before the old,
stored one expires.
* Renewing the current keying material can happen before it expires.
* Moved up the discussion on misalignment of group keying material.
* Expanded security considerations on group rekeying for joining
nodes.
* Revised size of integer for building AEAD nonces for group
rekeying.
* Added reserved value to the "ACE Groupcomm Profiles" IANA
registry.
* Revised the future-ready generalization of 'sign_info_entry'.
* Revised and fixed IANA considerations.
* Fixes and editorial improvements.
C.3. Version -15 to -16
* Distinction between authentication credentials and public keys.
* Consistent renaming of parameters and URI paths.
* Updated format of scope entries when using AIF.
* Updated signaling of semantics for binary encoded scopes.
* Editorial fixes.
C.4. Version -14 to -15
* Fixed nits.
C.5. Version -13 to -14
* Clarified scope and goal of the document in abstract and
introduction.
* Overall clarifications on semantics of operations and parameters.
* Major restructuring in the presentation of the KDC interface.
* Revised error handling, also removing redundant text.
* Imported parameters and KDC resource about the KDC's public key
from draft-ietf-ace-key-groupcomm-oscore.
* New parameters 'group_rekeying_scheme' and 'control_group_uri'.
* Provided example of administrative keying material transported in
'mgt_key_material'.
* Reasoned categorization of parameters, as expected support by ACE
Clients.
* Reasoned categorization of KDC functionalities, as minimally/
optional to support for ACE Clients.
* Guidelines on enhanced error responses using 'error' and
'error_description'.
* New section on group rekeying, discussing at a high-level a basic
one-to-one approach and possible one-to-many approaches.
* Revised and expanded security considerations, also about the KDC.
* Updated list of requirements for application profiles.
* Several further clarifications and editorial improvements.
C.6. Version -05 to -13
* Incremental revision of the KDC interface.
* Removed redundancy in parameters about signature algorithm and
signature keys.
* Node identifiers always indicated with 'peer_identifiers'.
* Format of public keys changed from raw COSE Keys to be
certificates, CWTs or CWT Claims Set (CCS). Adapted parameter
'pub_key_enc'.
* Parameters and functionalities imported from draft-ietf-key-
groupcomm-oscore where early defined.
* Possible provisioning of the KDC's Diffie-Hellman public key in
response to the Token transferring to /authz-info.
* Generalized proof-of-possession evidence, to be not necessarily a
signature.
* Public keys of group members may be retrieved filtering by role
and/or node identifier.
* Enhanced error handling with error code and error description.
* Extended "typed" format for the 'scope' claim, optional to use.
* Editorial improvements.
C.7. Version -04 to -05
* Updated uppercase/lowercase URI segments for KDC resources.
* Supporting single Access Token for multiple groups/topics.
* Added 'control_uri' parameter in the Join Request.
* Added 'peer_roles' parameter to support legal requesters/
responders.
* Clarification on stopping using owned keying material.
* Clarification on different reasons for processing failures,
related policies, and requirement OPT11.
* Added a KDC sub-resource for group members to upload a new public
key.
* Possible group rekeying following an individual Key Renewal
Request.
* Clarified meaning of requirement REQ3; added requirement OPT12.
* Editorial improvements.
C.8. Version -03 to -04
* Revised RESTful interface, as to methods and parameters.
* Extended processing of Join Request, as to check/retrieval of
public keys.
* Revised and extended profile requirements.
* Clarified specific usage of parameters related to signature
algorithms/keys.
* Included general content previously in draft-ietf-ace-key-
groupcomm-oscore
* Registration of media type and content format application/ace-
group+cbor
* Editorial improvements.
C.9. Version -02 to -03
* Exchange of information on the signature algorithm and related
parameters, during the Token POST (Section 3.3).
* Restructured KDC interface, with new possible operations
(Section 4).
* Client PoP signature for the Join Request upon joining
(Section 4.1.2.1).
* Revised text on group member removal (Section 5).
* Added more profile requirements (Appendix A).
C.10. Version -01 to -02
* Editorial fixes.
* Distinction between transport profile and application profile
(Section 1.1).
* New parameters 'sign_info' and 'pub_key_enc' to negotiate
parameter values for signature algorithm and signature keys
(Section 3.3).
* New parameter 'type' to distinguish different Key Distribution
Request messages (Section 4.1).
* New parameter 'client_cred_verify' in the Key Distribution Request
to convey a Client signature (Section 4.1).
* Encoding of 'pub_keys_repos' (Section 4.1).
* Encoding of 'mgt_key_material' (Section 4.1).
* Improved description on retrieval of new or updated keying
material (Section 6).
* Encoding of 'get_pub_keys' in Public Key Request (Section 7.1).
* Extended security considerations (Sections 10.1 and 10.2).
* New "ACE Public Key Encoding" IANA registry (Section 11.2).
* New "ACE Groupcomm Parameters" IANA registry (Section 11.3),
populated with the entries in Section 8.
* New "Ace Groupcomm Request Type" IANA registry (Section 11.4),
populated with the values in Section 9.
* New "ACE Groupcomm Policy" IANA registry (Section 11.7) populated
with two entries "Sequence Number Synchronization Method" and "Key
Update Check Interval" (Section 4.2).
* Improved list of requirements for application profiles
(Appendix A).
C.11. Version -00 to -01
* Changed name of 'req_aud' to 'audience' in the Authorization
Request (Section 3.1).
* Defined error handling on the KDC (Sections 4.2 and 6.2).
* Updated format of the Key Distribution Response as a whole
(Section 4.2).
* Generalized format of 'pub_keys' in the Key Distribution Response
(Section 4.2).
* Defined format for the message to request leaving the group
(Section 5.2).
* Renewal of individual keying material and methods for group
rekeying initiated by the KDC (Section 6).
* CBOR type for node identifiers in 'get_pub_keys' (Section 7.1).
* Added section on parameter identifiers and their CBOR keys
(Section 8).
* Added request types for requests to a Join Response (Section 9).
* Extended security considerations (Section 10).
* New IANA registries "ACE Groupcomm Key registry", "ACE Groupcomm
Profile registry", "ACE Groupcomm Policy registry" and "Sequence
Number Synchronization Method registry" (Section 11).
* Added appendix about requirements for application profiles of ACE
on group communication (Appendix A).
Acknowledgments Acknowledgments
The following individuals were helpful in shaping this document: The following individuals were helpful in shaping this document:
Christian Amsüss, Carsten Bormann, Roman Danyliw, Martin Duke, Thomas Christian Amsüss, Carsten Bormann, Roman Danyliw, Martin Duke, Thomas
Fossati, Vidhi Goel, Rikard Höglund, Ben Kaduk, Erik Kline, Warren Fossati, Vidhi Goel, Rikard Höglund, Ben Kaduk, Erik Kline, Warren
Kumari, Watson Ladd, John Preuß Mattsson, Daniel Migault, Kumari, Watson Ladd, Daniel Migault, John Preuß Mattsson,
Zaheduzzaman Sarker, Jim Schaad, Ludwig Seitz, Göran Selander, Cigdem Zaheduzzaman Sarker, Jim Schaad, Ludwig Seitz, Göran Selander, Cigdem
Sengul, Dave Thaler, Henry Thompson, Peter van der Stok, and Paul Sengul, Dave Thaler, Henry Thompson, Peter van der Stok, and Paul
Wouters. Wouters.
The work on this document has been partly supported by VINNOVA and The work on this document has been partly supported by the Sweden's
the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home Innovation Agency VINNOVA and the Celtic-Next project CRITISEC, by
(Grant agreement 952652); and by the EIT-Digital High Impact the H2020 project SIFIS-Home (Grant agreement 952652), and by the
Initiative ACTIVE. EIT-Digital High Impact Initiative ACTIVE.
Authors' Addresses Authors' Addresses
Francesca Palombini Francesca Palombini
Ericsson AB Ericsson AB
Torshamnsgatan 23 Torshamnsgatan 23
SE-16440 Stockholm Kista SE-164 40 Kista
Sweden Sweden
Email: francesca.palombini@ericsson.com Email: francesca.palombini@ericsson.com
Marco Tiloca Marco Tiloca
RISE AB RISE AB
Isafjordsgatan 22 Isafjordsgatan 22
SE-16440 Stockholm Kista SE-164 40 Kista
Sweden Sweden
Email: marco.tiloca@ri.se Email: marco.tiloca@ri.se
 End of changes. 811 change blocks. 
2380 lines changed or deleted 2134 lines changed or added

This html diff was produced by rfcdiff 1.48.