Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE)
draft-ietf-ace-key-groupcomm-oscore-21
| Document | Type | Active Internet-Draft (ace WG) | |
|---|---|---|---|
| Authors | Marco Tiloca , Francesca Palombini | ||
| Last updated | 2026-03-26 (Latest revision 2026-03-14) | ||
| Replaces | draft-tiloca-ace-oscoap-joining | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Associated WG milestone |
|
||
| Document shepherd | Rikard Höglund | ||
| Shepherd write-up | Show Last changed 2023-02-21 | ||
| IESG | IESG state | RFC Ed Queue | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Paul Wouters | ||
| Send notices to | rikard.hoglund@ri.se | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA action state | RFC-Ed-Ack | ||
| IANA expert review state | Expert Reviews OK | ||
| IANA expert review comments | All expert approvals received. | ||
| RFC Editor | RFC Editor state | EDIT | |
| Details |
draft-ietf-ace-key-groupcomm-oscore-21
ACE Working Group M. Tiloca
Internet-Draft RISE AB
Intended status: Standards Track F. Palombini
Expires: 16 September 2026 Ericsson AB
15 March 2026
Key Management for Group Object Security for Constrained RESTful
Environments (Group OSCORE) Using Authentication and Authorization for
Constrained Environments (ACE)
draft-ietf-ace-key-groupcomm-oscore-21
Abstract
This document defines an application profile of the Authentication
and Authorization for Constrained Environments (ACE) framework, to
request and provision keying material in group communication
scenarios that are based on the Constrained Application Protocol
(CoAP) and are secured with Group Object Security for Constrained
RESTful Environments (Group OSCORE). This application profile
delegates the authentication and authorization of Clients, which join
an OSCORE group through a Resource Server acting as Group Manager for
that group. This application profile leverages protocol-specific
transport profiles of ACE to achieve communication security, server
authentication, and proof of possession of a key owned by the Client
and bound to an OAuth 2.0 access token.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 16 September 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Tiloca & Palombini Expires 16 September 2026 [Page 1]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
3. Format of Scope . . . . . . . . . . . . . . . . . . . . . . . 10
4. Authentication Credentials . . . . . . . . . . . . . . . . . 13
5. Authorization to Join a Group . . . . . . . . . . . . . . . . 15
5.1. Authorization Request . . . . . . . . . . . . . . . . . . 15
5.2. Authorization Response . . . . . . . . . . . . . . . . . 16
5.3. Token Transferring . . . . . . . . . . . . . . . . . . . 16
5.3.1. 'ecdh_info' Parameter . . . . . . . . . . . . . . . . 20
5.3.2. 'kdc_dh_creds' Parameter . . . . . . . . . . . . . . 22
6. Group Joining . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1. Send the Join Request . . . . . . . . . . . . . . . . . . 24
6.1.1. Value of the N_S Challenge . . . . . . . . . . . . . 27
6.2. Receive the Join Request . . . . . . . . . . . . . . . . 28
6.2.1. Follow-up to a 4.00 (Bad Request) Error Response . . 33
6.3. Send the Join Response . . . . . . . . . . . . . . . . . 33
6.4. Receive the Join Response . . . . . . . . . . . . . . . . 39
7. Overview of the Group Rekeying Process . . . . . . . . . . . 41
7.1. Stale OSCORE Sender IDs . . . . . . . . . . . . . . . . . 43
8. Interface at the Group Manager . . . . . . . . . . . . . . . 44
8.1. /ace-group/GROUPNAME/kdc-cred . . . . . . . . . . . . . . 45
8.1.1. FETCH Handler . . . . . . . . . . . . . . . . . . . . 45
8.2. /ace-group/GROUPNAME/active . . . . . . . . . . . . . . . 46
8.2.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 46
8.3. /ace-group/GROUPNAME/verif-data . . . . . . . . . . . . . 46
8.3.1. GET Handler . . . . . . . . . . . . . . . . . . . . . 46
8.4. /ace-group/GROUPNAME/stale-sids . . . . . . . . . . . . . 47
8.4.1. FETCH Handler . . . . . . . . . . . . . . . . . . . . 47
8.5. Permitted Methods . . . . . . . . . . . . . . . . . . . . 48
8.5.1. Signature Verifiers . . . . . . . . . . . . . . . . . 49
8.6. Operations Supported by Clients . . . . . . . . . . . . . 50
9. Additional Interactions with the Group Manager . . . . . . . 50
9.1. Retrieve Updated Keying Material . . . . . . . . . . . . 51
9.1.1. Get Group Keying Material . . . . . . . . . . . . . . 51
9.1.2. Get Group Keying Material and OSCORE Sender ID . . . 52
Tiloca & Palombini Expires 16 September 2026 [Page 2]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
9.2. Request to Change Individual Keying Material . . . . . . 53
9.3. Retrieve Authentication Credentials of Group Members . . 54
9.4. Upload a New Authentication Credential . . . . . . . . . 55
9.5. Retrieve the Group Manager's Authentication Credential . 57
9.5.1. Retrieval for Group Members . . . . . . . . . . . . . 57
9.5.2. Retrieval for Signature Verifiers . . . . . . . . . . 58
9.6. Retrieve Signature Verification Data . . . . . . . . . . 60
9.7. Retrieve the Group Policies . . . . . . . . . . . . . . . 63
9.8. Retrieve the Keying Material Version . . . . . . . . . . 63
9.9. Retrieve the Group Status . . . . . . . . . . . . . . . . 63
9.10. Retrieve Group Names . . . . . . . . . . . . . . . . . . 64
9.11. Leave the Group . . . . . . . . . . . . . . . . . . . . . 67
10. Removal of a Group Member . . . . . . . . . . . . . . . . . . 67
11. Group Rekeying Process . . . . . . . . . . . . . . . . . . . 69
11.1. Sending Rekeying Messages . . . . . . . . . . . . . . . 71
11.2. Receiving Rekeying Messages . . . . . . . . . . . . . . 73
11.3. Missed Rekeying Instances . . . . . . . . . . . . . . . 74
11.3.1. Retrieve Stale Sender IDs . . . . . . . . . . . . . 76
12. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 78
13. ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . . 80
14. Default Values for Group Configuration Parameters . . . . . . 81
14.1. Common . . . . . . . . . . . . . . . . . . . . . . . . . 82
14.2. Group Mode . . . . . . . . . . . . . . . . . . . . . . . 82
14.3. Pairwise Mode . . . . . . . . . . . . . . . . . . . . . 83
15. Operational Considerations . . . . . . . . . . . . . . . . . 84
15.1. Logging . . . . . . . . . . . . . . . . . . . . . . . . 84
15.2. Administration of Groups . . . . . . . . . . . . . . . . 88
15.3. Access Control . . . . . . . . . . . . . . . . . . . . . 88
16. Security Considerations . . . . . . . . . . . . . . . . . . . 89
16.1. Management of OSCORE Groups . . . . . . . . . . . . . . 89
16.2. Size of Proof-of-Possesion Challenges . . . . . . . . . 90
16.3. Reuse of Challenges for Proof-of-Possession Input . . . 91
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92
17.1. OAuth Parameters . . . . . . . . . . . . . . . . . . . . 92
17.2. OAuth Parameters CBOR Mappings . . . . . . . . . . . . . 92
17.3. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . 93
17.4. ACE Groupcomm Key Types . . . . . . . . . . . . . . . . 94
17.5. ACE Groupcomm Profiles . . . . . . . . . . . . . . . . . 95
17.6. OSCORE Security Context Parameters . . . . . . . . . . . 95
17.7. TLS Exporter Labels . . . . . . . . . . . . . . . . . . 97
17.8. AIF Media-Type Sub-Parameters . . . . . . . . . . . . . 98
17.9. CoAP Content-Formats . . . . . . . . . . . . . . . . . . 98
17.10. CoRE Resource Type . . . . . . . . . . . . . . . . . . . 99
17.11. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 99
17.12. Group OSCORE Roles . . . . . . . . . . . . . . . . . . . 100
17.13. Expert Review Instructions . . . . . . . . . . . . . . . 100
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 101
18.1. Normative References . . . . . . . . . . . . . . . . . . 101
Tiloca & Palombini Expires 16 September 2026 [Page 3]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
18.2. Informative References . . . . . . . . . . . . . . . . . 106
Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 108
A.1. Mandatory-to-Address Requirements . . . . . . . . . . . . 108
A.2. Optional-to-Address Requirements . . . . . . . . . . . . 111
Appendix B. Extensibility for Future COSE Algorithms . . . . . . 113
B.1. Format of 'ecdh_info_entry' . . . . . . . . . . . . . . . 113
B.2. Format of 'key' . . . . . . . . . . . . . . . . . . . . . 114
Appendix C. CDDL Model . . . . . . . . . . . . . . . . . . . . . 115
Appendix D. Document Updates . . . . . . . . . . . . . . . . . . 116
D.1. Version -20 to -21 . . . . . . . . . . . . . . . . . . . 116
D.2. Version -19 to -20 . . . . . . . . . . . . . . . . . . . 117
D.3. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 117
D.4. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 118
D.5. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 119
D.6. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 120
D.7. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 121
D.8. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 121
D.9. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 121
D.10. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 121
D.11. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 122
D.12. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 123
D.13. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 124
D.14. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 124
D.15. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 125
D.16. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 125
D.17. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 126
D.18. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 126
D.19. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 127
D.20. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 127
D.21. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 128
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 128
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 129
1. Introduction
The secure communication protocol Object Security for Constrained
RESTful Environments (OSCORE) [RFC8613] provides application-layer
protection for the Constrained Application Protocol (CoAP) [RFC7252],
using CBOR Object Signing and Encryption (COSE) [RFC9052][RFC9053]
and enabling end-to-end security of CoAP messages.
As defined in [I-D.ietf-core-oscore-groupcomm], Group Object Security
for Constrained RESTful Environments (Group OSCORE) enables end-to-
end security for CoAP group communication
[I-D.ietf-core-groupcomm-bis], which can employ, for example, IP
multicast as underlying data transport.
Tiloca & Palombini Expires 16 September 2026 [Page 4]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Group OSCORE relies on an entity called Group Manager, which is
responsible for managing an OSCORE group and enables the group
members to exchange CoAP messages secured with Group OSCORE. The
Group Manager can be responsible for multiple groups, coordinates the
joining process of new group members, and is entrusted with the
distribution and renewal of group keying material.
Building on the Authentication and Authorization for Constrained
Environments (ACE) framework [RFC9200], the document [RFC9594]
defines how to request, distribute, and renew keying material and
configuration parameters to protect message exchanges in a group
communication environment. That is, candidate group members that act
as ACE Clients and are authorized to join a group can interact with a
Key Distribution Center (KDC) that acts as ACE Resource Server and is
responsible for the group. The KDC provides the necessary keying
material and parameters to communicate with other group members.
While [RFC9594] defines the operations and interface available at the
KDC, as well as general message formats for the interactions between
Clients and the KDC, it delegates details on the communication and
security approaches used in a group to separate application profiles.
These are specialized instances of [RFC9594] that target a particular
group communication approach and define how communications in the
group are protected, as well as the specific keying material and
configuration parameters provided to group members.
This document specifies an application profile of [RFC9594]. Message
exchanges among the participants as well as message formats and
processing follow what is specified in [RFC9594], and enable the
provisioning and renewing of keying material in group communication
scenarios, where Group OSCORE is used to protect CoAP group
communication. In particular, network nodes that wish to join an
OSCORE group act as ACE Clients, while the Group Manager responsible
for managing the OSCORE group is the KDC acting as ACE Resource
Server.
This application profile leverages protocol-specific transport
profiles of ACE (e.g., [RFC9202][RFC9203]), in order to achieve
communication security, server authentication, and proof of
possession of a key owned by the Client and bound to an OAuth 2.0
access token.
Figure 1 overviews the relationships between this document and other
related documents mentioned above.
Tiloca & Palombini Expires 16 September 2026 [Page 5]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
+---------------------+ Communications +------------------+
| Group communication | are secured with ... | Group OSCORE (b) |
| for CoAP (a) |------------------------>| |
+---------------------+ +------------------+
|
| A realization
+----------------------+ | of Group Manager
| Transport profiles | | is defined in ...
| of ACE, e.g., (d)(e) | |
+----------------------+ |
^ |
| |
| Details about security v
| and secure communication o========================o
| among ACE participants | |
| are specified in ... | >>> This document <<< |
| | |
+--------------------+ | Key management for |
| ACE framework for | | Group OSCORE using ACE |
| authentication and | | |
| authorization (c) | | |
+--------------------+ o========================o
| ^
| Used to build ... |
| |
v |
+---------------------------------+ |
| Key provisioning for group | | Instanced by the
| communication using ACE (f) | | application profile
| | | defined in ...
| - General message formats | |
| - Operations and interface at a |---------------+
| Key Distribution Center (KDC) |
+---------------------------------+
(a) : [I-D.ietf-core-groupcomm-bis]
(b) : [I-D.ietf-core-oscore-groupcomm]
(c) : [RFC9200]
(d) : [RFC9202]
(e) : [RFC9203]
(f) : [RFC9594]
Figure 1: Overview of Document Relationships
Note to RFC Editor: At the bottom of Figure 1, "[I-D.ietf-core-
groupcomm-bis]" and "[I-D.ietf-core-oscore-groupcomm]" are the
reference labels that the present document is currently using for
those two referred documents. Before publishing as an RFC, please
Tiloca & Palombini Expires 16 September 2026 [Page 6]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
replace those reference labels with the ones eventually used for the
(RFCs resulting from) the two referred documents. Then, please
delete this note.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Readers are expected to be familiar with:
* The terms and concepts described in the ACE framework for
authentication and authorization [RFC9200] and in the
Authorization Information Format (AIF) [RFC9237] to express
authorization information. The terminology for entities in the
considered architecture is defined in OAuth 2.0 [RFC6749]. This
includes Client (C), Resource Server (RS), and Authorization
Server (AS).
* The terms and concepts related to the message formats and
processing specified in [RFC9594], for provisioning and renewing
keying material in group communication scenarios. These include
the abbreviations REQx and OPTx denoting the numbered mandatory-
to-address and optional-to-address requirements, respectively.
* The terms and concepts related to Concise Data Definition Language
(CDDL) [RFC8610], Concise Binary Object Representation (CBOR)
[RFC8949], and COSE [RFC9052][RFC9053].
* The terms and concepts related to CoAP [RFC7252] and group
communication for CoAP [I-D.ietf-core-groupcomm-bis]. Unless
otherwise indicated, the term "endpoint" is used here following
its OAuth definition [RFC6749], aimed at denoting resources such
as /token and /introspect at the AS, and /authz-info at the RS.
The CoAP definition, which is "[a]n entity participating in the
CoAP protocol" [RFC7252], is not used in this document.
* The terms and concepts for protection and processing of CoAP
messages through OSCORE [RFC8613] and through Group OSCORE
[I-D.ietf-core-oscore-groupcomm] in group communication scenarios.
These especially include:
- Group Manager, as the entity responsible for a set of groups
where communications are secured with Group OSCORE. In this
document, the Group Manager acts as Resource Server.
Tiloca & Palombini Expires 16 September 2026 [Page 7]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- Group Identifier (Gid): identifier assigned to an OSCORE group,
unique within the set of groups of a given Group Manager. The
Gid value changes every time the OSCORE group is rekeyed.
- Birth Gid: with respect to a group member, the Gid obtained by
that group member upon (re-)joining the OSCORE group.
- Authentication credential, as the set of information associated
with an entity, including that entity's public key and
parameters associated with the public key. Examples of
authentication credentials are CBOR Web Tokens (CWTs) and CWT
Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC5280], and
C509 certificates [I-D.ietf-cose-cbor-encoded-cert].
Additionally, this document makes use of the following terminology:
* Requester: member of an OSCORE group that sends request messages
to other members of the group.
* Responder: member of an OSCORE group that receives request
messages from other members of the group. A responder may reply,
by sending a response message to the requester which has sent the
request message.
* Monitor: member of an OSCORE group that is configured as a
responder and never sends response messages protected with Group
OSCORE. This corresponds to the term "silent server" used in
[I-D.ietf-core-oscore-groupcomm].
* Signature verifier: entity external to the OSCORE group and
intended to verify the signature of messages exchanged in the
group that are protected with the group mode (see Sections 12.3,
7, and 7.5 of [I-D.ietf-core-oscore-groupcomm]).
An authorized signature verifier does not join the OSCORE group as
an actual member. However, it can interact with the Group Manager
in order to retrieve what is needed to perform signature
verifications, e.g., the authentication credentials of the current
group members and of the Group Manager.
* Signature-only group: an OSCORE group that uses only the group
mode (see Section 7 of [I-D.ietf-core-oscore-groupcomm]).
* Pairwise-only group: an OSCORE group that uses only the pairwise
mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]).
Tiloca & Palombini Expires 16 September 2026 [Page 8]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
1.2. Notations
Throughout this document, examples for CBOR data items are expressed
in CBOR extended diagnostic notation as defined in Section 8 of
[RFC8949] and Appendix G of [RFC8610] ("diagnostic notation").
Diagnostic notation comments are often used to provide a textual
representation of the parameters' keys and values.
In the CBOR diagnostic notation used in this document, constructs of
the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME
in the CDDL model shown in Figure 13 of Appendix C. For example,
{e'gp_enc_alg': 10, e'sign_alg': -8} stands for {9: 10, 10: -8}.
Note to RFC Editor: Please delete the paragraph immediately preceding
this note. Also, in the CBOR diagnostic notation used in this
document, please replace the constructs of the form e'SOME_NAME' with
the value assigned to SOME_NAME in the CDDL model shown in Figure 13
of Appendix C. Finally, please delete this note.
2. Protocol Overview
Group communication for CoAP is defined in
[I-D.ietf-core-groupcomm-bis] and can be secured by using Group
OSCORE [I-D.ietf-core-oscore-groupcomm]. A network node can join an
OSCORE group by interacting with the responsible Group Manager. Once
registered in the group, the new node can securely exchange messages
with other group members.
This document describes how to use [RFC9594] and [RFC9200] to perform
a number of authentication, authorization, and key distribution
actions as overviewed in Section 2 of [RFC9594], when the considered
group is specifically an OSCORE group.
After joining the group as defined in this application profile, a
group member communicates with other group members using CoAP
[RFC7252] as well as CoAP for group communication
[I-D.ietf-core-groupcomm-bis] (REQ22). Such communications are
protected using the security protocol Group OSCORE
[I-D.ietf-core-oscore-groupcomm] (REQ23).
With reference to [RFC9594]:
* The node wishing to join the OSCORE group, i.e., the joining node,
is the Client.
* The Group Manager is the KDC, acting as a Resource Server.
Tiloca & Palombini Expires 16 September 2026 [Page 9]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* The Authorization Server associated with the Group Manager is the
AS.
A node performs the steps described in Sections 3 and 4.3.1.1 of
[RFC9594] in order to obtain an authorization for joining an OSCORE
group and then to join that group. The format and processing of
messages exchanged during such steps are further specified in
Section 5 and Section 6 of this document.
All communications between the involved entities (Client, Group
Manager, Authorization Server) MUST occur and be secured in
accordance with the protocol-specific transport profile of ACE used.
In particular, communications between the Client and the Group
Manager leverage transport profiles of ACE to achieve communication
security, proof of possession, and server authentication (REQ24). It
is expected that, in the commonly referred base-case of this
document, the transport profile to use is pre-configured and well-
known to nodes participating in constrained applications.
With respect to what is defined in [RFC9594]:
* The interface provided by the Group Manager extends the original
interface defined in Section 4.1 of [RFC9594] for the KDC, as
specified in Section 8 of this document.
* In addition to those defined in Section 8 of [RFC9594], additional
parameters are defined in this document and summarized in
Section 12.
* In addition to those defined in Section 9 of [RFC9594], additional
error identifiers are defined in this document and summarized in
Section 13.
Finally, Appendix A compiles the list of requirements for this
application profile of ACE and how they are fulfilled, consistent
with the list of requirements defined in Appendix A of [RFC9594].
3. Format of Scope
Building on the definition in Section 3.3 of [RFC6749] considered in
the ACE framework [RFC9200], scope denotes: the permissions that the
Client seeks to obtain from the AS for accessing resources at a
Resource Server; and the permissions that the AS actually issues to
the Client following its request. This process is detailed in
Sections 5.8.1 and 5.8.2 of [RFC9200].
Tiloca & Palombini Expires 16 September 2026 [Page 10]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Consistent with the above and building on Section 3.1 of [RFC9594],
this section defines the exact format and encoding of scope that is
used in this profile.
To this end, this profile uses the Authorization Information Format
(AIF) [RFC9237]. With reference to the generic AIF model
AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]]
the value of the CBOR byte string used as scope encodes the CBOR
array [* [Toid, Tperm]], where each [Toid, Tperm] element corresponds
to one scope entry.
This document defines the new AIF data model AIF-OSCORE-GROUPCOMM,
which this profile MUST use to format and encode scope entries.
For each scope entry:
* The object identifier ("Toid") is specialized as a CBOR data item
specifying the names of the groups pertaining to the scope entry.
* The permission set ("Tperm") is specialized as a CBOR unsigned
integer with value R, specifying the permissions that the Client
wishes to have in the groups indicated by "Toid".
For the application profile of [RFC9594] defined in this document, a
scope entry includes the name of an OSCORE group and the set of roles
to take in that OSCORE group as a set of permissions. Specifically:
* The object identifier ("Toid") is a CBOR text string, specifying
the group name for the scope entry. As defined later in
Section 8, a group's name matches with the GROUPNAME segment
within the URI path of the group-membership resource and
corresponding sub-resources that are associated with that group
and hosted at the Group Manager. Therefore, a group name has to
be consistent with the semantics of URI path segments (see
Section 3.3 of [RFC3986]).
* The permission set ("Tperm") is a CBOR unsigned integer with value
R, specifying the role(s) that the Client wishes to take in the
group (REQ1). The value R is computed as follows.
- Each role in the permission set is converted into the
corresponding numeric identifier X from the "Value" column of
the "Group OSCORE Roles" registry defined in Section 17.12 of
this document, for which the initial entries are specified in
Table 1.
Tiloca & Palombini Expires 16 September 2026 [Page 11]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- The set of N numbers is converted into the single value R, by
taking two to the power of each numeric identifier X_1, X_2,
..., X_N, and then computing the inclusive OR of the binary
representations of all the power values.
+===========+=======+========================================+
| Name | Value | Description |
+===========+=======+========================================+
| Reserved | 0 | This value is reserved |
+-----------+-------+----------------------------------------+
| Requester | 1 | Send protected requests; receive |
| | | protected responses |
+-----------+-------+----------------------------------------+
| Responder | 2 | Send protected responses; receive |
| | | protected requests |
+-----------+-------+----------------------------------------+
| Monitor | 3 | Receive protected requests; never send |
| | | protected messages |
+-----------+-------+----------------------------------------+
| Verifier | 4 | Verify signature of intercepted |
| | | messages protected with the group mode |
+-----------+-------+----------------------------------------+
Table 1: Numeric Identifier of Roles in an OSCORE Group
The following CDDL [RFC8610] notation defines a scope entry that uses
the AIF-OSCORE-GROUPCOMM data model and expresses a set of Group
OSCORE roles from those in Table 1.
;# include rfc9237
AIF-OSCORE-GROUPCOMM = AIF-Generic<oscore-gname, oscore-gperm>
oscore-gname = tstr ; Group name
oscore-gperm = uint .bits group-oscore-roles
group-oscore-roles = &(
Requester: 1,
Responder: 2,
Monitor: 3,
Verifier: 4
)
scope_entry = [oscore-gname, oscore-gperm]
Future specifications that define new Group OSCORE roles must
register a corresponding numeric identifier in the "Group OSCORE
Roles" registry defined in Section 17.12 of this document.
Tiloca & Palombini Expires 16 September 2026 [Page 12]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Note that the value 0 is not available to use as numeric identifier
to specify a Group OSCORE role. It follows that, when expressing
Group OSCORE roles to take in a group as per this document, a scope
entry has the least significant bit of "Tperm" always set to 0.
This is an explicit feature of the AIF-OSCORE-GROUPCOMM data model.
That is, for each scope entry, the least significant bit of "Tperm"
set to 0 explicitly identifies the scope entry as exactly expressing
a set of Group OSCORE roles ("Tperm"), which pertains to a single
group whose name is specified by the string literal in "Toid".
Instead, by relying on the same AIF-OSCORE-GROUPCOMM data model,
[I-D.ietf-ace-oscore-gm-admin] defines the format of scope entries
for Administrator Clients that wish to access an admin interface at
the Group Manager. In such scope entries, the least significant bit
of "Tperm" is always set to 1.
As per the guidelines in [RFC9237], Section 17.8 and Section 17.9
register the specific instance of "Toid" and "Tperm" as media type
parameters and a corresponding Content-Format (REQ2).
4. Authentication Credentials
Source authentication of a message sent within the group and
protected with Group OSCORE is ensured by means of a digital
signature embedded in the message (in group mode), or by integrity-
protecting the message with pairwise keying material derived from the
asymmetric keys of the sender and recipient (in pairwise mode).
Therefore, group members must be able to retrieve each other's
authentication credentials from a trusted repository, in order to
verify source authenticity of incoming group messages.
As discussed in [I-D.ietf-core-oscore-groupcomm], the Group Manager
acts as trusted repository of the authentication credentials of the
group members, and provides those authentication credentials to group
members if requested to.
Tiloca & Palombini Expires 16 September 2026 [Page 13]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Upon joining an OSCORE group, a joining node is thus expected to
provide its authentication credential to the Group Manager (see
Section 6.1). Later on as a group member, that node can provide the
Group Manager with a different authentication credential that
replaces the old one (see Section 9.4). In either situation, the
authentication credential can be provided within a chain or a bag
(e.g., as the end-entity certificate in a chain of certificates), in
which case the Group Manager stores the whole chain or bag.
Consistently, the Group Manager specifies the whole chain or bag when
providing that authentication credential, within the 'creds'
parameter of a Join Response (see Section 6.3) or of an
Authentication Credential Response (see Section 9.3).
In the following circumstances, a joining node is not required to
provide its authentication credential to the Group Manager when
joining an OSCORE group.
* The joining node is going to join the group exclusively as a
monitor, i.e., it is not going to send protected messages to the
group. Consequently, even if compatible with the group in
question, an authentication credential of such a joining node
plays no role in using Group OSCORE within that group.
Furthermore, such a joining node is not going to have a Sender
Context within its Group OSCORE Security Context, where a group
member stores its own private key and authentication credential
(see Section 2 of [I-D.ietf-core-oscore-groupcomm], where the term
"silent server" corresponds to the term "monitor" of the present
document). Also, no member of the group will create a Recipient
Context associated with such a joining node, as the latter never
sends protected messages.
Therefore, in this case, the joining node is not required to
provide its own authentication credential to the Group Manager,
which thus does not have to perform any check related to the
format of the authentication credential, to a signature or ECDH
algorithm, and to possible parameters associated with the
algorithm and the public key.
If the joining node still provides an authentication credential in
the 'client_cred' parameter of the Join Request (see Section 6.1),
the Group Manager silently ignores that parameter and the related
parameter 'client_cred_verify'.
* The joining node is currently a group member acting not
exclusively as a monitor, and it is re-joining the group not
exclusively as a monitor.
Tiloca & Palombini Expires 16 September 2026 [Page 14]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
In this case, if the joining node intends to use the same
authentication credential that it is currently using in the group,
i.e., its latest authentication credential provided to the Group
Manager (in a previous Join Request or Authentication Credential
Update Request, see Section 9.4), then the joining node MAY choose
to omit its current authentication credential in the Join Request.
As defined in Section 6.1, this is achieved by setting the value
of the 'client_cred' parameter in the Join Request to the empty
CBOR byte string (0x40) and omitting the 'client_cred_verify'
parameter in the Join Request (see Section 4.3.1.1 of [RFC9594]).
5. Authorization to Join a Group
This section builds on Section 3 of [RFC9594] and is organized as
follows.
First, Section 5.1 and Section 5.2 describe how the joining node
interacts with the AS, in order to be authorized to join an OSCORE
group under a given Group Manager and to obtain an access token.
Then, Section 5.3 describes how the joining node transfers the
obtained access token to the Group Manager.
This section considers a joining node that intends to contact the
Group Manager for the first time.
Note that what is defined in Section 3 of [RFC9594] applies, and only
additions or modifications to that specification are defined in this
document.
5.1. Authorization Request
The Authorization Request message is as defined in Section 3.1 of
[RFC9594], with the following additions.
* If the 'scope' parameter is present:
- The value of the CBOR byte string encodes a CBOR array, whose
format MUST follow the data model AIF-OSCORE-GROUPCOMM defined
in Section 3 of this document. For each OSCORE group to join:
o The group name is encoded as a CBOR text string.
o The set of requested roles is expressed as a single CBOR
unsigned integer. This is computed as defined in Section 3
of this document, from the numerical abbreviations of each
requested role defined in the "Group OSCORE Roles" registry
(REQ1).
Tiloca & Palombini Expires 16 September 2026 [Page 15]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
The textual format specified in Section 3.1 of [RFC9594] is not used
in this application profile (OPT1).
5.2. Authorization Response
The Authorization Response message is as defined in Section 3.2 of
[RFC9594], with the following additions:
* The AS MUST include the 'expires_in' parameter.
* The AS MUST include the 'scope' parameter, when the value included
in the access token differs from the one specified by the joining
node in the Authorization Request. In such a case, the second
element of each scope entry MUST be present and specifies the set
of roles that the joining node is actually authorized to take in
the OSCORE group for that scope entry, encoded as specified in
Section 5.1 of this document.
Furthermore, the AS MAY use the extended format of scope defined in
Section 7 of [RFC9594] for the 'scope' claim of the access token. In
such a case, the AS MUST use the CBOR tag with tag number TAG_NUMBER,
associated with the CoAP Content-Format CF_ID for the media type
"application/aif+cbor" registered in Section 17.9 of this document
(REQ28).
Note to RFC Editor: In the previous paragraph, please replace
"TAG_NUMBER" with the CBOR tag number computed as TN(ct) in
Section 4.3 of [RFC9277], where ct is the ID assigned to the CoAP
Content-Format registered in Section 17.9 of this document. Then,
please replace "CF_ID" with the ID assigned to that CoAP Content-
Format. Finally, please delete this paragraph.
This indicates that the binary encoded scope, as conveying the actual
access control information, follows the scope semantics defined for
this application profile in Section 3 of this document.
5.3. Token Transferring
The exchange of Token Transfer Request and Token Transfer Response is
defined in Section 3.3 of [RFC9594]. In addition to that, the
following applies.
* The Token Transfer Request MAY additionally contain the following
parameters, which, if included, MUST have the corresponding values
defined below (OPT2):
Tiloca & Palombini Expires 16 September 2026 [Page 16]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- 'ecdh_info' defined in Section 5.3.1 of this document, with
value the CBOR simple value null (0xf6) to request information
about the ECDH algorithm, the ECDH algorithm parameters, the
ECDH key parameters, and the exact format of authentication
credentials used in the OSCORE groups that the Client has been
authorized to join. This is relevant if the joining node
supports the pairwise mode of Group OSCORE
[I-D.ietf-core-oscore-groupcomm].
- 'kdc_dh_creds' defined in Section 5.3.2 of this document, with
value the CBOR simple value null (0xf6) to request the Diffie-
Hellman authentication credentials of the Group Manager for the
OSCORE groups that the Client has been authorized to join.
That is, each of such authentication credentials includes a
Diffie-Hellman public key of the Group Manager. This is
relevant if the joining node supports the pairwise mode of
Group OSCORE [I-D.ietf-core-oscore-groupcomm] and the access
token authorizes to join pairwise-only groups.
Alternatively, the joining node may retrieve this information by
other means.
* In the Token Transfer Response, the 'kdcchallenge' parameter
contains a fresh challenge N_S newly generated by the Group
Manager. As to the N_S value, it is RECOMMENDED to be at least 8
bytes long and it is RECOMMENDED to be a random value. The
joining node can use this challenge in order to prove the
possession of its own private key upon joining the group (see
Section 6.1 of this document).
The 'kdcchallenge' parameter MAY be omitted from the Token
Transfer Response, if the 'scope' of the access token specifies
only the role "monitor", or only the role "verifier", or only the
two roles combined, for each and every of the specified groups.
* If the 'sign_info' parameter is present in the Token Transfer
Response, the following applies for each element
'sign_info_entry'.
- 'id' is associated exclusively with OSCORE groups that are not
pairwise-only groups.
- 'sign_alg' takes value from the "Value" column of the "COSE
Algorithms" registry [COSE.Algorithms] (REQ3).
Tiloca & Palombini Expires 16 September 2026 [Page 17]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- 'sign_parameters' has the same format and value of the COSE
capabilities array for the algorithm indicated in 'sign_alg',
as specified for that algorithm in the "Capabilities" column of
the "COSE Algorithms" registry [COSE.Algorithms] (REQ4).
- 'sign_key_parameters' has the same format and value of the COSE
capabilities array for the COSE key type of the keys used with
the algorithm indicated in 'sign_alg', as specified for that
key type in the "Capabilities" column of the "COSE Key Types"
registry [COSE.Key.Types] (REQ5).
- 'cred_fmt' takes value from the "Label" column of the "COSE
Header Parameters" registry [COSE.Header.Parameters] (REQ6).
To align with Section 2.4 of [I-D.ietf-core-oscore-groupcomm],
acceptable values denote a format of authentication credential
that provides the public key as well as a comprehensive set of
information related to the public key algorithm, including,
e.g., the elliptic curve used.
At the time of writing this specification, acceptable formats
of authentication credentials are CBOR Web Tokens (CWTs) and
CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC5280],
and C509 certificates [I-D.ietf-cose-cbor-encoded-cert].
Further formats may be available in the future, and they would
be acceptable to use as long as they comply with the criteria
defined above.
This format is consistent with every signature algorithm currently
considered in [RFC9053], i.e., with algorithms that have only the
COSE key type as their COSE capability. Appendix B of [RFC9594]
describes how the format of each 'sign_info_entry' can be
generalized for possible future registered algorithms that have a
different set of COSE capabilities.
* If the 'ecdh_info' parameter is present in the Token Transfer
Response, the following applies for each element
'ecdh_info_entry'.
- 'id' is associated exclusively with OSCORE groups that are not
signature-only groups.
- 'ecdh_alg' takes value from the "Value" column of the "COSE
Algorithms" registry [COSE.Algorithms].
- 'ecdh_parameters' has the same format and value of the COSE
capabilities array for the algorithm indicated in 'ecdh_alg',
as specified for that algorithm in the "Capabilities" column of
the "COSE Algorithms" registry [COSE.Algorithms].
Tiloca & Palombini Expires 16 September 2026 [Page 18]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- 'ecdh_key_parameters' has the same format and value of the COSE
capabilities array for the COSE key type of the keys used with
the algorithm indicated in 'ecdh_alg', as specified for that
key type in the "Capabilities" column of the "COSE Key Types"
registry [COSE.Key.Types].
- 'cred_fmt' takes value from the "Label" column of the "COSE
Header Parameters" registry [COSE.Header.Parameters]. To align
with Section 2.4 of [I-D.ietf-core-oscore-groupcomm],
acceptable values denote a format of authentication credential
that provides the public key as well as a comprehensive set of
information related to the public key algorithm, including,
e.g., the elliptic curve used. The same considerations
provided above on acceptable formats currently available for
the 'cred_fmt' element of 'sign_info' apply.
The Group Manager omits the 'ecdh_info' parameter in the Token
Transfer Response even if 'ecdh_info' is included in the Token
Transfer Request, in the case that all the OSCORE groups that the
Client is authorized to join are signature-only groups.
* If the 'kdc_dh_creds' parameter is present in the Token Transfer
Response, the following applies for each element
'kdc_dh_creds_entry'.
- 'id' is associated exclusively with OSCORE groups that are
pairwise-only groups.
- 'cred_fmt' takes value from the "Label" column of the "COSE
Header Parameters" registry [COSE.Header.Parameters]. To align
with Section 2.4 of [I-D.ietf-core-oscore-groupcomm],
acceptable values denote a format of authentication credential
that provides the public key as well as a comprehensive set of
information related to the public key algorithm, including,
e.g., the elliptic curve used. The same considerations
provided above on acceptable formats currently available for
the 'cred_fmt' element of 'sign_info' apply.
The Group Manager omits the 'kdc_dh_creds' parameter in the Token
Transfer Response even if 'ecdh_info' is included in the Token
Transfer Request, in the case that none of the OSCORE groups that
the Client is authorized to join is a pairwise-only group.
Note that, other than through the above parameters as defined in
Section 3.3 of [RFC9594], the joining node may have obtained such
information by alternative means. For example, information conveyed
in the 'sign_info' and 'ecdh_info' parameters may have been pre-
configured, or the joining node may early retrieve it, e.g., by using
Tiloca & Palombini Expires 16 September 2026 [Page 19]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
the approach described in [I-D.tiloca-core-oscore-discovery] to
discover the OSCORE group and the link to the associated group-
membership resource at the Group Manager (OPT3).
5.3.1. 'ecdh_info' Parameter
The 'ecdh_info' parameter is an OPTIONAL parameter of the request and
response messages exchanged between the Client and the /authz-info
endpoint at the RS (see Section 5.10.1. of [RFC9200]).
This parameter allows the Client and the RS to exchange information
about an ECDH algorithm as well as about the authentication
credentials and public keys to accordingly use for deriving Diffie-
Hellman secrets. Its exact semantics and content are application
specific.
In application profiles that build on [RFC9594], this parameter is
used to exchange information about the ECDH algorithm as well as
about the authentication credentials and public keys to be used with
it, in the groups indicated by the transferred access token as per
its 'scope' claim (see Section 3.2 of [RFC9594]).
When used in the Token Transfer Request sent to the KDC (see
Section 3.3 of [RFC9594]), the 'ecdh_info' parameter specifies the
CBOR simple value null (0xf6). This is done to ask for information
about the ECDH algorithm and about the authentication credentials
used to compute static-static Diffie-Hellman shared secrets
[NIST-800-56A], in the groups that the Client has been authorized to
join or interact with.
When used in the following Token Transfer Response from the KDC (see
Section 3.3 of [RFC9594]), the 'ecdh_info' parameter is a CBOR array
of one or more elements. The number of elements is at most the
number of groups that the Client has been authorized to join or
interact with. Each element contains information about ECDH
parameters and about authentication credentials for one or more
groups and is formatted as follows.
* The first element 'id' is a group name or a CBOR array of group
names, which is associated with groups for which the next four
elements apply. Each specified group name is a CBOR text string
and is hereafter referred to as 'gname'.
* The second element 'ecdh_alg' is a CBOR integer or a text string
that indicates the ECDH algorithm used in the groups identified by
the 'gname' values.
Tiloca & Palombini Expires 16 September 2026 [Page 20]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
For application profiles of [RFC9594] that use the 'ecdh_info'
parameter, it is REQUIRED to define specific values that
'ecdh_alg' can take, which are selected from the set of signing
algorithms of the "COSE Algorithms" registry [COSE.Algorithms].
* The third element 'ecdh_parameters' is a CBOR array that indicates
the parameters of the ECDH algorithm used in the groups identified
by the 'gname' values. Its content depends on the value of
'ecdh_alg'.
For application profiles of [RFC9594] that use the 'ecdh_info'
parameter, it is REQUIRED to define the possible values and
structure for the elements of 'ecdh_parameters'.
* The fourth element 'ecdh_key_parameters' is a CBOR array that
indicates the parameters of the key used with the ECDH algorithm
in the groups identified by the 'gname' values. Its content
depends on the value of 'ecdh_alg'.
For application profiles of [RFC9594] that use the 'ecdh_info'
parameter, it is REQUIRED to define the possible values and
structure for the elements of 'ecdh_key_parameters'.
* The fifth element 'cred_fmt' either is a CBOR integer indicating
the format of authentication credentials used in the groups
identified by the 'gname' values or is the CBOR simple value null
(0xf6), which indicates that the KDC does not act as a repository
of authentication credentials for group members. Its acceptable
integer values are taken from the "Label" column of the "COSE
Header Parameters" registry [COSE.Header.Parameters], with some of
those values also indicating the type of container to use for
exchanging the authentication credentials with the KDC (e.g., a
chain or bag of certificates).
For application profiles of [RFC9594] that use the 'ecdh_info'
parameter, it is REQUIRED to define specific values to use for
'cred_fmt', consistent with the acceptable formats of
authentication credentials.
If 'ecdh_info' is included in the Token Transfer Request, the KDC
SHOULD include the 'ecdh_info' parameter in the Token Transfer
Response, as per the format defined above. Note that the field 'id'
of each 'ecdh_info_entry' specifies the name or array of group names
to which that 'ecdh_info_entry' applies. As an exception, the KDC
MAY omit the 'ecdh_info' parameter in the Token Transfer Response
even if 'ecdh_info' is included in the Token Transfer Request, in the
case that none of the groups that the Client is authorized to join
uses an ECDH algorithm to derive Diffie-Hellman secrets.
Tiloca & Palombini Expires 16 September 2026 [Page 21]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
The CDDL notation [RFC8610] of the 'ecdh_info' parameter is given
below.
ecdh_info = ecdh_info_req / ecdh_info_resp
ecdh_info_req = null ; in the Token Transfer
; Request to the KDC
ecdh_info_resp = [+ ecdh_info_entry] ; in the Token Transfer
; Response from the KDC
ecdh_info_entry =
[
id: gname / [+ gname],
ecdh_alg: int / tstr,
ecdh_parameters: [any],
ecdh_key_parameters: [+ parameter: any],
cred_fmt: int / null
]
gname = tstr
This format is consistent with every ECDH algorithm currently defined
in [RFC9053], i.e., with algorithms that have only the COSE key type
as their COSE capability. Appendix B of this document describes how
the format of each 'ecdh_info_entry' can be generalized for possible
future registered algorithms that have a different set of COSE
capabilities.
5.3.2. 'kdc_dh_creds' Parameter
The 'kdc_dh_creds' parameter is an OPTIONAL parameter of the request
and response messages exchanged between the Client and the /authz-
info endpoint at the RS (see Section 5.10.1. of [RFC9200]).
This parameter allows the Client to request and retrieve the Diffie-
Hellman authentication credentials of the RS, i.e., authentication
credentials including a Diffie-Hellman public key of the RS.
In application profiles that build on [RFC9594], this parameter is
used to request and retrieve from the KDC its Diffie-Hellman
authentication credentials to use, in the groups indicated by the
transferred access token as per its 'scope' claim (see Section 3.2 of
[RFC9594]).
Tiloca & Palombini Expires 16 September 2026 [Page 22]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
When used in the Token Transfer Request sent to the KDC (see
Section 3.3 of [RFC9594]), the 'kdc_dh_creds' parameter specifies the
CBOR simple value null (0xf6). This is done to ask for the Diffie-
Hellman authentication credentials that the KDC uses in the groups
that the Client has been authorized to join or interact with.
When used in the following Token Transfer Response from the KDC (see
Section 3.2 of [RFC9594]), the 'kdc_dh_creds' parameter is a CBOR
array of one or more elements. The number of elements is at most the
number of groups that the Client has been authorized to join or
interact with. Each element contains information about the KDC's
Diffie-Hellman authentication credentials for one or more groups and
is formatted as follows.
* The first element 'id' is a group name or a CBOR array of group
names, which is associated with groups for which the next two
elements apply. Each specified group name is a CBOR text string
and is hereafter referred to as 'gname'.
* The second element 'cred_fmt' is a CBOR integer indicating the
format of the KDC's authentication credential used in the groups
identified by the 'gname' values and specified by the following
element 'cred'. Its acceptable integer values are taken from the
"Label" column of the "COSE Header Parameters" registry
[COSE.Header.Parameters], with some of those values also
indicating the type of container to use for exchanging the
authentication credentials with the KDC (e.g., a chain or bag of
certificates).
For application profiles of [RFC9594] that use the 'kdc_dh_creds'
parameter, it is REQUIRED to define specific values to use for
'cred_fmt', consistent with the acceptable formats of the KDC's
authentication credentials.
* The third element 'cred' is a CBOR byte string encoding the
original binary representation of the Diffie-Hellman
authentication credential that the KDC uses in the groups
identified by the 'gname' values. The authentication credential
complies with the format specified by the 'cred_fmt' element.
Tiloca & Palombini Expires 16 September 2026 [Page 23]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
If 'kdc_dh_creds' is included in the Token Transfer Request, the KDC
SHOULD include the 'kdc_dh_creds' parameter in the Token Transfer
Response, as per the format defined above. Note that the field 'id'
of each 'kdc_dh_creds_entry' specifies the name or array of group
names to which that 'kdc_dh_creds_entry' applies. As an exception,
the KDC MAY omit the 'kdc_dh_creds' parameter in the Token Transfer
Response even if 'kdc_dh_creds' is included in the Token Transfer
Request, in the case that the KDC does not use a Diffie-Hellman
authentication credential in any of the groups that the Client is
authorized to join.
The CDDL notation [RFC8610] of the 'kdc_dh_creds' parameter is given
below.
kdc_dh_creds = kdc_dh_creds_req / kdc_dh_creds_resp
kdc_dh_creds_req = null ; in the Token Transfer
; Request to the KDC
kdc_dh_creds_resp = [+ kdc_dh_creds_entry] ; in the Token Transfer
; Response from the KDC
kdc_dh_creds_entry =
[
id: gname / [+ gname],
cred_fmt: int,
cred: bstr
]
gname = tstr
6. Group Joining
This section describes the interactions between the joining node and
the Group Manager to join an OSCORE group. The message exchange
between the joining node and the Group Manager consists of the
messages defined in Section 4.3.1.1 of [RFC9594]. Note that what is
defined in [RFC9594] applies, and only additions or modifications to
that specification are defined in this document.
6.1. Send the Join Request
The joining node requests to join the OSCORE group by sending a Join
Request message to the related group-membership resource at the Group
Manager, as per Section 4.3.1.1 of [RFC9594]. In addition to what is
defined in Section 4.3.1 of [RFC9594], the following applies.
Tiloca & Palombini Expires 16 September 2026 [Page 24]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* The 'scope' parameter MUST be included. Its value encodes one
scope entry with the format defined in Section 3, indicating the
group name and the role(s) that the joining node wants to take in
the group.
The 'scope' parameter MUST NOT specify any of the following sets
of roles: ("requester", "monitor") and ("responder", "monitor").
Future specifications that define a new role for members of OSCORE
groups MUST define possible sets of roles (including the new role
and existing roles) that are not acceptable to specify in the
'scope' parameter of a Join Request.
* The 'get_creds' parameter is present only if the joining node
wants to retrieve the authentication credentials of the group
members from the Group Manager during the joining process (see
Section 4). Otherwise, this parameter MUST NOT be present.
If this parameter is present and its value is not the CBOR simple
value null (0xf6), each element of the inner CBOR array
'role_filter' is encoded as a CBOR unsigned integer, with the same
value of a permission set ("Tperm") indicating that role or
combination of roles in a scope entry, as defined in Section 3.
* The 'cnonce' parameter contains a fresh challenge N_C newly
generated by the joining node. As to the N_C value, it is
RECOMMENDED to be at least 8 bytes long and it is RECOMMENDED to
be a random value.
* If the joining node intends to join the group exclusively as a
monitor, then the 'client_cred' parameter and the
'client_cred_verify' parameter MUST be omitted.
* If the joining node is currently a group member and intends to use
the same authentication credential that it is currently using in
the group, then the 'client_cred_verify' parameter MAY be omitted.
If the 'client_cred_verify' parameter is omitted, the value of the
'client_cred' parameter MAY specify an empty authentication
credential, i.e., its value is set to the empty CBOR byte string
(0x40).
* If the 'client_cred_verify' parameter is present, then the proof-
of-possession (PoP) evidence included therein is computed as
defined below (REQ14).
- Specifically in the case where the joining node is not a
current member of the group, the Group Manager might already
have achieved proof of possession of the joining node's private
key associated with the authentication credential AUTH_CRED_C
Tiloca & Palombini Expires 16 September 2026 [Page 25]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
that the joining node intends to use in the group. That is,
the joining node might have already proven the possession of
its own private key to the Group Manager.
For example, proof-of-possession could have been achieved upon
completing the establishment of the secure communication
association that is used to protect the Join Request, if the
joining node used AUTH_CRED_C to authenticate itself with the
Group Manager.
Under these circumstances, the joining node MAY specify an
empty PoP evidence, i.e., it sets the value of the
'client_cred_verify' parameter to the empty CBOR byte string
(0x40).
- If the conditions above do not hold or the joining node prefers
to compute a non-empty PoP evidence, then the joining node
proceeds as follows to prove the possession of its own private
key. In either case, the N_S used to build the PoP input is as
defined in Section 6.1.1.
o If the group is not a pairwise-only group, the PoP evidence
MUST be a signature. The joining node computes the
signature by using the same private key and signature
algorithm that it intends to use for signing messages in the
OSCORE group.
o If the group is a pairwise-only group, the PoP evidence MUST
be a MAC computed as follows, by using the HKDF Algorithm
HKDF SHA-256, which consists of composing the HKDF-Extract
and HKDF-Expand steps [RFC5869].
MAC = HKDF(salt, IKM, info, L)
The input parameters of HKDF are as follows:
+ salt takes as value the empty byte string.
+ IKM is computed as a cofactor Diffie-Hellman shared
secret, see Section 5.7.1.2 of [NIST-800-56A], using the
ECDH algorithm used in the OSCORE group. The joining
node uses its own Diffie-Hellman private key and the
Diffie-Hellman public key of the Group Manager. For
X25519 and X448, the procedure is described in Section 5
of [RFC7748].
+ info takes as value the PoP input.
Tiloca & Palombini Expires 16 September 2026 [Page 26]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
+ L is equal to 8, i.e., the size of the MAC, in bytes.
6.1.1. Value of the N_S Challenge
The value of the N_S challenge is determined as follows.
* If the joining node has provided the access token to the Group
Manager by means of a Token Transfer Request to the /authz-info
endpoint as in Section 5.3, then N_S takes the same value of the
most recent 'kdcchallenge' parameter received by the joining node
from the Group Manager. This can be either the one specified in
the Token Transfer Response, or the one possibly specified in a
4.00 (Bad Request) error response to a following Join Request (see
Section 6.2).
* If the provisioning of the access token to the Group Manager has
relied on the DTLS profile of ACE [RFC9202] and the access token
was specified in the "psk_identity" field of the ClientKeyExchange
message when using DTLS 1.2 [RFC6347], then N_S is an exporter
value computed as defined in Section 4 of [RFC5705] (REQ15).
Specifically, N_S is exported from the DTLS session between the
joining node and the Group Manager, using an empty context value
(i.e., a context value of zero-length), 32 as length value in
bytes, and the exporter label "EXPORTER-ACE-Pop-Input-coap-group-
oscore-app" registered in Section 17.7 of this document.
The same as above holds if TLS 1.2 [RFC5246] was used instead of
DTLS 1.2, as per [RFC9430].
* If the provisioning of the access token to the Group Manager has
relied on the DTLS profile of ACE [RFC9202] and the access token
was specified in the "identity" field of a PskIdentity within the
PreSharedKeyExtension of the ClientHello message when using DTLS
1.3 [RFC9147], then N_S is an exporter value computed as defined
in Section 7.5 of [RFC8446] (REQ15).
Specifically, N_S is exported from the DTLS session between the
joining node and the Group Manager, using an empty 'context_value'
(i.e., a 'context_value' of zero length), 32 as 'key_length' in
bytes, and the exporter label "EXPORTER-ACE-Pop-Input-coap-group-
oscore-app" registered in Section 17.7 of this document.
The same as above holds if TLS 1.3 [RFC8446] was used instead of
DTLS 1.3, as per [RFC9430].
It is up to applications or future specifications to define how N_S
is computed in further alternative settings.
Tiloca & Palombini Expires 16 September 2026 [Page 27]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Section 16.3 provides security considerations on the reuse of the N_S
challenge.
6.2. Receive the Join Request
The Group Manager processes the Join Request as defined in
Section 4.3.1 of [RFC9594], with the following additions. Note that
the Group Manager can determine whether the joining node is a current
group member, e.g., based on the ongoing secure communication
association that is used to protect the Join Request.
If the joining node is going to join the group exclusively as a
monitor, then the Group Manager silently ignores the parameters
'client_cred' and 'client_cred_verify', if present.
If the joining node is not going to join the group exclusively as a
monitor, it is a current member of the group, and the
'client_cred_verify' parameter is not present, then the following
applies:
* If the 'client_cred' parameter does not specify the empty CBOR
byte string (0x40), the Group Manager verifies that it is already
storing the authentication credential specified by the parameter,
as associated with the joining node in the group. If the
verification fails, the Group Manager MUST reply with a 4.00 (Bad
Request) error response (OPT8).
* If the 'client_cred' parameter specifies the empty CBOR byte
string (0x40), the Group Manager verifies that it is already
storing an authentication credential, as associated with the
joining node in the group. If the verification fails, the Group
Manager MUST reply with a 4.00 (Bad Request) error response
(OPT8).
Tiloca & Palombini Expires 16 September 2026 [Page 28]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
If the joining node is not going to join the group exclusively as a
monitor and the 'client_cred_verify' parameter specifies the empty
CBOR byte string (0x40), the Group Manager checks whether it has
already achieved proof of possession of the joining node's private
key associated with the authentication credential that is specified
in the 'client_cred' parameter. If such verification fails, then the
Group Manager MUST reply with a 4.00 (Bad Request) error response.
The response MUST have Content-Format set to "application/concise-
problem-details+cbor" [RFC9290] and is formatted as defined in
Section 4.1.2 of [RFC9594]. Within the Custom Problem Detail entry
'ace-groupcomm-error', the value of the 'error-id' field MUST be set
to 3 ("Invalid proof-of-possession evidence"). After receiving that
response, the client MUST NOT specify an empty PoP evidence in the
'client_cred_verify' parameter of a follow-up Join Request for
joining the same group.
Note to RFC Editor: Please make sure that "application/concise-
problem-details+cbor" is on one line (no line wrapping) on every
occurrence and delete this note.
If the joining node is not going to join the group exclusively as a
monitor and the 'client_cred_verify' parameter specifies a value
different from the empty CBOR byte string (0x40), then the Group
Manager verifies the PoP evidence therein as follows:
* As PoP input, the Group Manager uses the value of the 'scope'
parameter from the Join Request as a CBOR byte string,
concatenated with N_S encoded as a CBOR byte string, concatenated
with N_C encoded as a CBOR byte string. The value of N_S is
determined as described in Section 6.1.1, while N_C is the
challenge provided in the 'cnonce' parameter of the Join Request.
* As public key of the joining node, the Group Manager uses the one
included in the authentication credential retrieved from the
'client_cred' parameter of the Join Request.
* If the group is not a pairwise-only group, the PoP evidence is a
signature. The Group Manager verifies it by using the public key
of the joining node, as well as the signature algorithm used in
the OSCORE group and possible corresponding parameters.
Tiloca & Palombini Expires 16 September 2026 [Page 29]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* If the group is a pairwise-only group, the PoP evidence is a MAC.
The Group Manager recomputes the MAC through the same process that
is taken by the joining node when preparing the value of the
'client_cred_verify' parameter for the Join Request (see
Section 6.1), with the difference that the Group Manager uses its
own Diffie-Hellman private key and the Diffie-Hellman public key
of the joining node. The verification succeeds if and only if the
recomputed MAC is equal to the MAC conveyed as PoP evidence in the
Join Request.
The Group Manager MUST reply with a 5.03 (Service Unavailable) error
response in the following cases:
* There are currently no OSCORE Sender IDs available to assign in
the OSCORE group and, at the same time, the joining node is not
going to join the group exclusively as a monitor. The response
MUST have Content-Format set to "application/concise-problem-
details+cbor" [RFC9290] and is formatted as defined in
Section 4.1.2 of [RFC9594]. Within the Custom Problem Detail
entry 'ace-groupcomm-error', the value of the 'error-id' field
MUST be set to 4 ("No available individual keying material").
* The OSCORE group that the joining node has been trying to join is
currently inactive (see Section 8.2). The response MUST have
Content-Format set to "application/concise-problem-details+cbor"
[RFC9290] and is formatted as defined in Section 4.1.2 of
[RFC9594]. Within the Custom Problem Detail entry 'ace-groupcomm-
error', the value of the 'error-id' field MUST be set to 9 ("Group
currently not active").
The Group Manager MUST reply with a 4.00 (Bad Request) error response
in the following cases:
* The 'scope' parameter is not present in the Join Request, or it is
present and specifies any of the following sets of roles:
("requester", "monitor") and ("responder", "monitor").
* The joining node is not going to join the group exclusively as a
monitor, and any of the following holds:
- The joining node is not a current member of the group, and the
'client_cred' parameter and the 'client_cred_verify' parameter
are not both present in the Join Request.
- The 'client_cred_verify' parameter is present in the Join
Request, and the value of the 'client_cred' parameter in the
Join Request is not an eligible authentication credential
(e.g., it is not of the format accepted in the group).
Tiloca & Palombini Expires 16 September 2026 [Page 30]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- The 'client_cred_verify' parameter is not present in the Join
Request, and the value of the 'client_cred' parameter in the
Join Request is neither set to the empty CBOR byte string
(0x40) nor an eligible authentication credential (e.g., it is
not of the format accepted in the group).
If the Group Manager wants to prevent the acceptance and use of
Ed25519 and Ed448 public keys that cannot be successfully converted
to Montgomery coordinates, and thus cannot be used for the derivation
of pairwise keys (see Section 2.5.1 of
[I-D.ietf-core-oscore-groupcomm]), the Group Manager MUST reply with
a 4.00 (Bad Request) error response in the case that all the
following conditions hold:
* The OSCORE group uses the pairwise mode of Group OSCORE.
* The OSCORE group uses EdDSA public keys [RFC8032].
* The authentication credential of the joining node from the
'client_cred' parameter includes a public key which:
- Is for the elliptic curve Ed25519 and has its Y coordinate
equal to -1 or 1 (mod p), with p = (2^255 - 19), see
Section 4.1 of [RFC7748]; or
- Is for the elliptic curve Ed448 and has its Y coordinate equal
to -1 or 1 (mod p), with p = (2^448 - 2^224 - 1), see
Section 4.2 of [RFC7748].
For example, this situation can occur if the joining node does not
support the pairwise mode of Group OSCORE or does not intend to use
the pairwise mode within the OSCORE group.
Unless it is already intended to use Content-Format "application/
concise-problem-details+cbor", a 4.00 (Bad Request) error response
from the Group Manager to the joining node MUST have Content-Format
"application/ace-groupcomm+cbor". In such a case, the response
payload is a CBOR map formatted as follows (OPT4):
* If the group uses (also) the group mode of Group OSCORE, then the
CBOR map MUST contain the 'sign_info' parameter, whose CBOR label
is defined in Section 8 of [RFC9594]. This parameter has the same
format of 'sign_info_res' defined in Section 3.3.1 of [RFC9594]
and includes a single element 'sign_info_entry', which pertains to
the OSCORE group that the joining node has tried to join with the
Join Request.
Tiloca & Palombini Expires 16 September 2026 [Page 31]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* If the group uses (also) the pairwise mode of Group OSCORE, then
the CBOR map MUST contain the 'ecdh_info' parameter, whose CBOR
label is registered in Section 17.3. This parameter has the same
format of 'ecdh_info_res' defined in Section 5.3.1 and includes a
single element 'ecdh_info_entry', which pertains to the OSCORE
group that the joining node has tried to join with the Join
Request.
* If the group is a pairwise-only group, the CBOR map MUST contain
the 'kdc_dh_creds' parameter, whose CBOR label is registered in
Section 17.3. This parameter has the same format of
'kdc_dh_creds_res' defined in Section 5.3.2 and includes a single
element 'kdc_dh_creds_entry', which pertains to the OSCORE group
that the joining node has tried to join with the Join Request.
* The CBOR map MAY include the 'kdcchallenge' parameter, whose CBOR
label is defined in Section 8 of [RFC9594]. If present, this
parameter is a CBOR byte string, which encodes a newly generated
'kdcchallenge' value that the Client can use when preparing a new
Join Request (see Section 6.1). In such a case, the Group Manager
MUST store the newly generated value as the 'kdcchallenge' value
associated with the joining node, thus replacing the currently
stored value, if any.
The information conveyed in such a 4.00 (Bad Request) error response
with Content-Format "application/ace-groupcomm+cbor" can be
especially useful for the joining node, if the provisioning of the
access token to the Group Manager has not relied on a Token Transfer
Request to the /authz-info endpoint (see Section 5.3).
Furthermore, specifically if the group is a pairwise-only group, the
error response allows the joining node to obtain the Diffie-Hellman
authentication credential that the Group Manager uses in the group,
as encoded by the 'kdc_dh_creds' parameter. Consequently, the
joining node remains able to prove possession of its own private key
upon joining the group, through a MAC used as PoP evidence and
encoded by the 'client_cred_verify' parameter of the Join Request
(see Section 6.1).
Irrespective of the particular case, a joining node can trigger the
Group Manager to send such an error response by simply sending an
empty Join Request, i.e., a POST request targeting the group-
membership resource at the Group Manager and conveying no payload.
As per Section 4.1.2 of [RFC9594], the Group Manager replies with a
4.00 (Bad Request) error response, having received a request that
does not include required fields and thus is not formatted correctly.
Tiloca & Palombini Expires 16 September 2026 [Page 32]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
6.2.1. Follow-up to a 4.00 (Bad Request) Error Response
When receiving a 4.00 (Bad Request) error response, the joining node
MAY send a new Join Request to the Group Manager. In such a case:
* The 'cnonce' parameter contains a fresh challenge N_C newly
generated by the joining node. As to the N_C value, it is
RECOMMENDED to be at least 8 bytes long and it is RECOMMENDED to
be a random value.
* If the joining node is not going to join the group exclusively as
a monitor, then the following applies:
- The 'client_cred' parameter MUST include an authentication
credential in the format indicated by the Group Manager. Also,
the authentication credential as well as the included public
key MUST be compatible with the signature or ECDH algorithm,
and with possible associated parameters.
- If present, the 'client_cred_verify' parameter MUST include a
PoP evidence computed as described in Section 6.1. The private
key to use is the one associated with the authentication
credential specified in the current 'client_cred' parameter,
with the signature or ECDH algorithm, and with possible
associated parameters indicated by the Group Manager. If the
error response from the Group Manager includes the
'kdcchallenge' parameter, the joining node MUST use its content
as new N_S challenge to compute the PoP evidence.
6.3. Send the Join Response
If the processing of the Join Request described in Section 6.2 is
successful, the Group Manager updates the group membership by
registering the joining node NODENAME as a new member of the OSCORE
group GROUPNAME, as described in Section 4.3.1 of [RFC9594].
If the joining node has not taken exclusively the role of monitor,
the Group Manager performs also the following actions.
* The Group Manager selects an available OSCORE Sender ID in the
OSCORE group, and exclusively assigns it to the joining node. The
Group Manager MUST NOT assign an OSCORE Sender ID to the joining
node if this joins the group exclusively with the role of monitor,
according to what is specified in the access token (see
Section 5.2).
Tiloca & Palombini Expires 16 September 2026 [Page 33]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Consistent with Section 12.2.1.2 of
[I-D.ietf-core-oscore-groupcomm], the Group Manager MUST assign an
OSCORE Sender ID that has not been used in the OSCORE group since
the latest time when the current Gid value was assigned to the
group. The maximum length of a Sender ID in bytes is determined
as defined in Section 2.2 of [I-D.ietf-core-oscore-groupcomm].
If the joining node is recognized as a current group member, e.g.,
through the ongoing secure communication association that is used
to protect the Join Request, then the following also applies:
- The Group Manager MUST assign a new OSCORE Sender ID different
from the one currently used by the joining node in the OSCORE
group.
- The Group Manager MUST add the old, relinquished OSCORE Sender
ID of the joining node to the set of stale Sender IDs
associated with the current version of the group keying
material for the group (see Section 7.1).
* The Group Manager stores the association between: i) the
authentication credential of the joining node; and ii) the Group
Identifier (Gid), i.e., the OSCORE ID Context associated with the
OSCORE group, together with the OSCORE Sender ID assigned to the
joining node in the group. The Group Manager MUST keep this
association updated over time.
Then, the Group Manager replies to the joining node, providing the
updated security parameters and keying material necessary to
participate in the group communication. This success Join Response
is formatted as defined in Section 4.3.1 of [RFC9594], with the
following additions:
* The 'gkty' parameter identifies a key of type
"Group_OSCORE_Input_Material object", which is registered in
Section 17.4 of this document (REQ18).
* The 'key' parameter includes what the joining node needs in order
to set up the Group OSCORE Security Context as per Section 2 of
[I-D.ietf-core-oscore-groupcomm].
This parameter has as value a Group_OSCORE_Input_Material object
(REQ17), which is defined in this document and extends the
OSCORE_Input_Material object encoded in CBOR as defined in
Section 3.2.1 of [RFC9203]. In particular, it contains the
additional parameters 'group_senderId', 'cred_fmt', 'gp_enc_alg',
'sign_alg', 'sign_params', 'ecdh_alg', and 'ecdh_params', which
are registered in Section 17.6 of this document.
Tiloca & Palombini Expires 16 September 2026 [Page 34]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
More specifically, the 'key' parameter is composed as follows.
- The 'hkdf' parameter, if present, specifies the HKDF Algorithm
that is used in the OSCORE group. The HKDF Algorithm is
specified by the HMAC Algorithm value. For example, the HKDF
Algorithm HKDF SHA-256 is specified as the HMAC Algorithm HMAC
256/256. This parameter MAY be omitted, if the HKDF Algorithm
used in the group is HKDF SHA-256. Otherwise, this parameter
MUST be present.
- The 'salt' parameter, if present, has as value the OSCORE
Master Salt that is used in the OSCORE group. This parameter
MAY be omitted, if the Master Salt used in the group is the
empty byte string. Otherwise, this parameter MUST be present.
- The 'ms' parameter has as value the OSCORE Master Secret that
is used in the OSCORE group. This parameter MUST be present.
- The 'contextId' parameter has as value the Group Identifier
(Gid), i.e., the OSCORE ID Context of the OSCORE group. This
parameter MUST be present.
- The 'group_senderId' parameter has as value the OSCORE Sender
ID that the Group Manager has assigned to the joining node in
the OSCORE group, as described above. This parameter MUST be
present if the node does not join the OSCORE group exclusively
with the role of monitor, according to what is specified in the
access token (see Section 5.2). Otherwise, this parameter MUST
NOT be present.
- The 'cred_fmt' parameter specifies the Authentication
Credential Format used in the OSCORE group (see Section 2 of
[I-D.ietf-core-oscore-groupcomm]). This parameter MUST be
present and it takes value from the "Label" column of the "COSE
Header Parameters" registry [COSE.Header.Parameters] (REQ6),
with some of those values also indicating the type of container
to use for exchanging the authentication credentials with the
Group Manager (e.g., a chain or bag of certificates). To align
with Section 2.4 of [I-D.ietf-core-oscore-groupcomm],
acceptable values denote a format that provides the public key
as well as a comprehensive set of information related to the
public key algorithm. This information includes, e.g., the
elliptic curve used.
At the time of writing this specification, acceptable formats
of authentication credentials are CBOR Web Tokens (CWTs) and
CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC5280],
and C509 certificates [I-D.ietf-cose-cbor-encoded-cert].
Tiloca & Palombini Expires 16 September 2026 [Page 35]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Further formats may be available in the future, and they would
be acceptable to use as long as they comply with the criteria
defined above.
The 'key' parameter MUST also include the following parameters, if
and only if the OSCORE group is not a pairwise-only group.
- The 'gp_enc_alg' parameter, specifying the Group Encryption
Algorithm that is used in the OSCORE group to encrypt messages
protected with the group mode. This parameter takes values
from the "Value" column of the "COSE Algorithms" registry
[COSE.Algorithms].
- The 'sign_alg' parameter, specifying the Signature Algorithm
that is used in the OSCORE group to sign messages protected
with the group mode. This parameter takes values from the
"Value" column of the "COSE Algorithms" registry
[COSE.Algorithms].
- The 'sign_params' parameter, specifying the parameters of the
Signature Algorithm. This parameter is a CBOR array, which
includes the following two elements:
o 'sign_alg_capab': a CBOR array, with the same format and
value of the COSE capabilities array for the Signature
Algorithm indicated in 'sign_alg', as specified for that
algorithm in the "Capabilities" column of the "COSE
Algorithms" registry [COSE.Algorithms].
o 'sign_key_type_capab': a CBOR array, with the same format
and value of the COSE capabilities array for the COSE key
type of the keys used with the Signature Algorithm indicated
in 'sign_alg', as specified for that key type in the
"Capabilities" column of the "COSE Key Types" registry
[COSE.Key.Types].
The 'key' parameter MUST also include the following parameters, if
and only if the OSCORE group is not a signature-only group.
- The 'alg' parameter, specifying the AEAD Algorithm used in the
OSCORE group to encrypt messages protected with the pairwise
mode.
- The 'ecdh_alg' parameter, specifying the Pairwise Key Agreement
Algorithm used in the OSCORE group to derive the pairwise keys
for the pairwise mode. This parameter takes values from the
"Value" column of the "COSE Algorithms" registry
[COSE.Algorithms].
Tiloca & Palombini Expires 16 September 2026 [Page 36]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- The 'ecdh_params' parameter, specifying the parameters of the
Pairwise Key Agreement Algorithm. This parameter is a CBOR
array, which includes the following two elements:
o 'ecdh_alg_capab': a CBOR array, with the same format and
value of the COSE capabilities array for the algorithm
indicated in 'ecdh_alg', as specified for that algorithm in
the "Capabilities" column of the "COSE Algorithms" registry
[COSE.Algorithms].
o 'ecdh_key_type_capab': a CBOR array, with the same format
and value of the COSE capabilities array for the COSE key
type of the keys used with the algorithm indicated in
'ecdh_alg', as specified for that key type in the
"Capabilities" column of the "COSE Key Types" registry
[COSE.Key.Types].
The format of 'key' defined above is consistent with every
signature algorithm and ECDH algorithm currently considered in
[RFC9053], i.e., with algorithms that have only the COSE key type
as their COSE capability. Appendix B.2 of this document describes
how the format of the 'key' parameter can be generalized for
possible future registered algorithms that have a different set of
COSE capabilities.
Furthermore, the following applies.
* The 'exi' parameter MUST be present.
* The 'ace_groupcomm_profile' parameter MUST be present and has
value coap_group_oscore_app (PROFILE_TBD), which is registered in
Section 17.5 of this document (REQ19).
* The 'creds' parameter, if present, specifies the authentication
credentials requested by the joining node by means of the
'get_creds' parameter that was specified in the Join Request.
If the joining node has asked for the authentication credentials
of all the group members, i.e., the 'get_creds' parameter in the
Join Request had as value the CBOR Simple Value null (0xf6), then
the Group Manager provides only the authentication credentials of
the group members that are relevant to the joining node. That is,
in such a case, the 'creds' parameter specifies only: i) the
authentication credentials of the responders currently in the
OSCORE group, if the joining node is configured (also) as a
requester; and ii) the authentication credentials of the
requesters currently in the OSCORE group, if the joining node is
configured (also) as a responder or monitor.
Tiloca & Palombini Expires 16 September 2026 [Page 37]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* The 'peer_identifiers' parameter, if present, specifies the OSCORE
Sender ID of each group member whose authentication credential is
specified in the 'creds' parameter. That is, a group member's
Sender ID is used as identifier for that group member (REQ25).
* The 'group_policies' parameter SHOULD be present, and SHOULD
include the following elements (REQ20):
- "Key Update Check Interval" (see Section 4.3.1 of [RFC9594]),
with default value 3600;
- "Expiration Delta" (see Section 4.3.1 of [RFC9594]), with
default value 0.
* The 'kdc_cred' parameter MUST be present, specifying the Group
Manager's authentication credential in its original binary
representation (REQ8). The Group Manager's authentication
credential MUST be in the format used in the OSCORE group. Also,
the authentication credential as well as the included public key
MUST be compatible with the signature or ECDH algorithm, and with
possible associated parameters used in the OSCORE group.
* The 'kdc_nonce' parameter MUST be present, specifying the nonce
N_KDC generated by the Group Manager. As to the N_KDC value, it
is RECOMMENDED to be at least 8 bytes long and it is RECOMMENDED
to be a random value.
* The 'kdc_cred_verify' parameter MUST be present, specifying the
proof-of-possession (PoP) evidence computed by the Group Manager
to prove the possession of its own private key. The PoP evidence
is computed as defined below (REQ21).
- If the group is not a pairwise-only group, then the PoP
evidence MUST be a signature. The Group Manager computes the
signature by using the signature algorithm used in the OSCORE
group, as well as its own private key associated with the
authentication credential specified in the 'kdc_cred'
parameter.
- If the group is a pairwise-only group, then the PoP evidence
MUST be a MAC computed as follows, by using the HKDF Algorithm
HKDF SHA-256, which consists of composing the HKDF-Extract and
HKDF-Expand steps [RFC5869].
MAC = HKDF(salt, IKM, info, L)
The input parameters of HKDF are as follows.
Tiloca & Palombini Expires 16 September 2026 [Page 38]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
o salt takes as value the empty byte string.
o IKM is computed as a cofactor Diffie-Hellman shared secret,
see Section 5.7.1.2 of [NIST-800-56A], using the ECDH
algorithm used in the OSCORE group. The Group Manager uses
its own Diffie-Hellman private key and the Diffie-Hellman
public key of the joining node. For X25519 and X448, the
procedure is described in Section 5 of [RFC7748].
o info takes as value the PoP input.
o L is equal to 8, i.e., the size of the MAC, in bytes.
* The 'group_rekeying' parameter MAY be omitted, if the Group
Manager uses the "Point-to-Point" group rekeying scheme registered
in Section 11.13 of [RFC9594] as rekeying scheme in the OSCORE
group (OPT9). Its detailed use for this profile is defined in
Section 11 of this document. In any other case, the
'group_rekeying' parameter MUST be included.
As a last action, if the Group Manager reassigns Gid values during
the group's lifetime (see Section 12.2.1.1 of
[I-D.ietf-core-oscore-groupcomm]), then the Group Manager MUST store
the Gid specified in the 'contextId' parameter of the 'key'
parameter, as the Birth Gid of the joining node in the joined group
(see Section 12.2.1.1 of [I-D.ietf-core-oscore-groupcomm]). This
applies also if the joining node is in fact re-joining the group; in
such a case, the newly determined Birth Gid overwrites the one
currently stored.
6.4. Receive the Join Response
Upon receiving the Join Response, the joining node retrieves the
Group Manager's authentication credential from the 'kdc_cred'
parameter. The joining node MUST verify the proof-of-possession
(PoP) evidence specified in the 'kdc_cred_verify' parameter of the
Join Response as defined below (REQ21).
* If the group is not a pairwise-only group, the PoP evidence is a
signature. The joining node verifies it by using the public key
of the Group Manager from the received authentication credential,
as well as the signature algorithm used in the OSCORE group and
possible corresponding parameters.
* If the group is a pairwise-only group, the PoP evidence is a MAC.
The joining node recomputes the MAC through the same process that
is taken by the Group Manager when computing the value of the
'kdc_cred_verify' parameter (see Section 6.3), with the difference
Tiloca & Palombini Expires 16 September 2026 [Page 39]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
that the joining node uses its own Diffie-Hellman private key and
the Diffie-Hellman public key of the Group Manager from the
received authentication credential. The verification succeeds if
and only if the recomputed MAC is equal to the MAC conveyed as PoP
evidence in the Join Response.
If the verification of the PoP evidence fails, the joining node MUST
stop processing the Join Response and MAY send a new Join Request to
the Group Manager (see Section 6.1).
If the verification of the PoP evidence succeeds, the joining node
uses the information received in the Join Response to set up the
Group OSCORE Security Context, as described in Section 2 of
[I-D.ietf-core-oscore-groupcomm]. In particular, the following
applies.
If the following parameters were not included in the 'key' parameter
of the Join Response, then the joining node performs the following
actions.
* Absent the 'gp_enc_alg' parameter, the parameter Group Encryption
Algorithm in the Common Context of the Group OSCORE Security
Context is not set.
* Absent the 'sign_alg' parameter, the parameter Signature Algorithm
in the Common Context of the Group OSCORE Security Context is not
set.
* Absent the 'alg' parameter, the parameter AEAD Algorithm in the
Security Context of the Group OSCORE Security Context is not set.
* Absent the 'ecdh_alg' parameter, the parameter Pairwise Key
Agreement Algorithm in the Common Context of the Group OSCORE
Security Context is not set.
If the following parameters were not included in the 'key' parameter
of the Join Response, then the joining node considers the default
values specified below, consistent with Section 3.2 of [RFC8613].
* Absent the 'hkdf' parameter, the joining node considers HKDF
SHA-256 as the HKDF Algorithm to use in the OSCORE group.
* Absent the 'salt' parameter, the joining node considers the empty
byte string as the Master Salt to use in the OSCORE group.
Tiloca & Palombini Expires 16 September 2026 [Page 40]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* Absent the 'group_rekeying' parameter, the joining node considers
the "Point-to-Point" group rekeying scheme registered in
Section 11.13 of [RFC9594] as the rekeying scheme used in the
OSCORE group (OPT9). The detailed use of that rekeying scheme for
this profile is defined in Section 11 of this document.
In addition, the joining node maintains an association between each
authentication credential retrieved from the 'creds' parameter and
the role(s) that the corresponding group member has in the OSCORE
group.
From then on, the joining node can exchange group messages secured
with Group OSCORE as described in [I-D.ietf-core-oscore-groupcomm].
When doing so:
* The joining node MUST NOT process an incoming request message, if
protected by a group member whose authentication credential is not
associated with the role "Requester".
* The joining node MUST NOT process an incoming response message, if
protected by a group member whose authentication credential is not
associated with the role "Responder".
* The joining node MUST NOT use the group mode of Group OSCORE to
process messages in the group, if the Join Response did not
include both the 'gp_enc_alg' parameter and the 'sign_alg'
parameter.
* The joining node MUST NOT use the pairwise mode of Group OSCORE to
process messages in the group, if the Join Response did not
include both the 'alg' parameter and the 'ecdh_alg' parameter.
If the application requires backward security, the Group Manager MUST
generate updated security parameters and group keying material, and
provide it to the current group members, upon the new node's joining
(see Section 11). In such a case, the joining node is not able to
access secure communication in the OSCORE group that occurred prior
to its joining.
7. Overview of the Group Rekeying Process
In a number of cases, the Group Manager has to generate new keying
material and distribute it to the group (rekeying), as also discussed
in Section 12.2 of [I-D.ietf-core-oscore-groupcomm].
To this end the Group Manager MUST support the Group Rekeying Process
described in Section 11 of this document, as an instance of the
"Point-to-Point" rekeying scheme defined in Section 6.1 of [RFC9594]
Tiloca & Palombini Expires 16 September 2026 [Page 41]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
and whose identifier is registered in Section 11.13 of [RFC9594].
Future documents may define the use of alternative group rekeying
schemes for this application profile, together with the corresponding
rekeying message formats. The resulting group rekeying process MUST
comply with the functional steps defined in Section 12.2 of
[I-D.ietf-core-oscore-groupcomm].
The initial value of the version number of the group keying material
MUST be set to 0 when creating the group (REQ16), e.g., as in
[I-D.ietf-ace-oscore-gm-admin].
Upon generating the new group keying material and before starting its
distribution, the Group Manager MUST increment the version number of
the group keying material. When rekeying a group, the Group Manager
MUST preserve the current value of the OSCORE Sender ID of each
member in that group.
The data distributed to a group through a rekeying MUST include:
* The new version number of the group keying material for the group.
* A new Group Identifier (Gid) for the group as introduced in
[RFC9594], which is used as ID Context parameter of the Group
OSCORE Common Security Context of that group (see Section 2 of
[I-D.ietf-core-oscore-groupcomm]).
Note that the Gid differs from the group name also introduced in
[RFC9594], which is a plain, stable, and invariant identifier,
with no cryptographic relevance and meaning.
* A new value for the Master Secret parameter of the Group OSCORE
Common Security Context of that group (see Section 2 of
[I-D.ietf-core-oscore-groupcomm]).
* A set of stale Sender IDs, which allows each rekeyed node to purge
authentication credentials and Recipient Contexts used in the
group and associated with those Sender IDs. This in turn allows
every group member to rely on stored authentication credentials,
in order to confidently verify the group membership of other
sender nodes, when receiving protected messages in the group (see
Section 12.2 of [I-D.ietf-core-oscore-groupcomm]). More details
on the maintenance of stale Sender IDs are provided in
Section 7.1.
The data distributed through a group rekeying MAY also include a new
value for the Master Salt parameter of the Group OSCORE Common
Security Context of that group.
Tiloca & Palombini Expires 16 September 2026 [Page 42]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
The Group Manager MUST rekey the group in the following cases.
* The application requires backward security - In this case, the
group is rekeyed when a node joins the group as a new member.
Therefore, a joining node cannot access communications in the
group prior to its joining.
* One or more nodes leave the group - That is, the group is rekeyed
when one or more current members spontaneously request to leave
the group (see Section 9.11), or when the Group Manager forcibly
evicts them from the group, e.g., due to expired or revoked
authorization (see Section 10). Therefore, a leaving node cannot
access communications in the group after its leaving, thus
ensuring forward security in the group.
Due to the set of stale Sender IDs distributed through the
rekeying, this ensures that a node storing the latest group keying
material does not store the authentication credentials of former
group members (see Sections 12.2 and 13.1 of
[I-D.ietf-core-oscore-groupcomm]).
When the expiration time for the group keying material approaches or
has passed, the Group Manager may want to extend the secure group
operation, as considered appropriate. If the Group Manager does so,
the Group Manager MUST rekey the group.
The Group Manager MAY rekey the group for other reasons, e.g.,
according to an application-specific rekeying period or scheduling.
7.1. Stale OSCORE Sender IDs
For each OSCORE group, the Group Manager MUST maintain N > 1 sets of
"stale" OSCORE Sender IDs. It is up to the application to specify
the value of N, possibly on a per-group basis.
Each set is uniquely associated with one version of the group keying
material, and includes the OSCORE Sender IDs that have become "stale"
in the OSCORE group under that version of the group keying material.
In the following cases, the Group Manager MUST add an element to the
set X associated with the current version of the group keying
material.
* When a current group member obtains a new Sender ID, its old
Sender ID is added to X. This happens when the Group Manager
assigns a new Sender ID upon request from the group member (see
Section 9.2), or when the group member re-joins the group (see
Section 6.1 and Section 6.3), thus also obtaining a new Sender ID.
Tiloca & Palombini Expires 16 September 2026 [Page 43]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* When a current group member leaves the group, its current Sender
ID is added to X. This happens when a group member requests to
leave the group (see Section 9.11) or is forcibly evicted from the
group (see Section 10).
The value of N can change during the lifetime of the group. If the
new value N' is smaller than N, then the Group Manager MUST preserve
the sets associated with the (up to) N' most recent versions of the
group keying material.
When performing a group rekeying (see Section 11) for switching from
an old version V of the group keying material to a new version V' =
(V + 1), the Group Manager MUST perform the following actions.
* Before creating the new group keying material with version V', if
the number of sets of stale Sender IDs for the group is equal to
N, then the Group Manager deletes the oldest set.
* The Group Manager rekeys the group. This includes also
distributing the set of stale Sender IDs associated with the
version V of the group keying material (see Section 7).
* After completing the group rekeying, the Group Manager creates an
empty set of stale Sender IDs, as associated with the version V'
of the group keying material.
8. Interface at the Group Manager
The Group Manager provides the interface defined in Section 4.1 of
[RFC9594] in its entirety (REQ9), with the following additions:
* The new FETCH handler is defined for the sub-resource /ace-
group/GROUPNAME/kdc-cred (see Section 8.1 of this document).
* Three new sub-resources are defined (see Section 8.2, Section 8.3,
and Section 8.4 of this document).
Section 8.5 provides a summary of the CoAP methods that are permitted
to use for accessing different resources at the Group Manager, for
nodes with different roles in the group or as non-members (REQ11).
The GROUPNAME segment of the URI path MUST match with the group name
specified in the scope entry of the scope in the access token (i.e.,
'gname' in Section 3.1 of [RFC9594]) (REQ7). Therefore, a group name
has to be consistent with the semantics of URI path segments (see
Section 3.3 of [RFC3986]).
Tiloca & Palombini Expires 16 September 2026 [Page 44]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
The Resource Type (rt=) Link Target Attribute value "core.osc.gm" is
registered in Section 17.10 (REQ10), and can be used to describe
group-membership resources and its sub-resources at a Group Manager,
e.g., by using a CoRE link-format document [RFC6690].
Applications can use this common resource type to discover links to
group-membership resources for joining OSCORE groups, e.g., by using
the approach described in [I-D.tiloca-core-oscore-discovery].
8.1. /ace-group/GROUPNAME/kdc-cred
In addition to what is defined in Section 4.5 of [RFC9594], this
resource also implements a FETCH handler.
8.1.1. FETCH Handler
The handler expects a FETCH request, whose payload is a CBOR map
including a fresh challenge N_C (see Section 9.5.2).
In addition to what is defined in Section 4.1.2 of [RFC9594], the
Group Manager performs the following checks.
If the requesting Client is a current group member or is not
authorized to be signature verifier for the group, the Group Manager
MUST reply with a 4.03 (Forbidden) error response. The response MUST
have Content-Format set to "application/concise-problem-details+cbor"
[RFC9290] and is formatted as defined in Section 4.1.2 of [RFC9594].
Within the Custom Problem Detail entry 'ace-groupcomm-error', the
value of the 'error-id' field MUST be set to 8 ("Operation permitted
only to signature verifiers").
If GROUPNAME denotes a pairwise-only group, the Group Manager MUST
reply with a 4.00 (Bad Request) error response. The response MUST
have Content-Format set to "application/concise-problem-details+cbor"
[RFC9290] and is formatted as defined in Section 4.1.2 of [RFC9594].
Within the Custom Problem Detail entry 'ace-groupcomm-error', the
value of the 'error-id' field MUST be set to 7 ("Signatures not used
in the group").
If all verifications succeed, the handler replies with a 2.05
(Content) response, specifying the authentication credential of the
Group Manager together with a proof-of-possession (PoP) evidence as a
proof that the Group Manager possesses its own private key. The
payload of the response is formatted as defined in Section 9.5.2.
Tiloca & Palombini Expires 16 September 2026 [Page 45]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
8.2. /ace-group/GROUPNAME/active
This resource implements a GET handler.
8.2.1. GET Handler
The handler expects a GET request.
In addition to what is defined in Section 4.1.2 of [RFC9594], the
handler verifies that the requesting Client is a current member of
the group. If the verification fails, the KDC MUST reply with a 4.03
(Forbidden) error response. The response MUST have Content-Format
set to "application/concise-problem-details+cbor" [RFC9290] and is
formatted as defined in Section 4.1.2 of [RFC9594]. Within the
Custom Problem Detail entry 'ace-groupcomm-error', the value of the
'error-id' field MUST be set to 0 ("Operation permitted only to group
members").
If all verifications succeed, the handler replies with a 2.05
(Content) response, specifying the current status of the group, i.e.,
active or inactive. The payload of the response is formatted as
defined in Section 9.9.
The Group Manager SHOULD make the resource at /ace-group/GROUPNAME/
active also observable [RFC7641], thus making it possible for group
members to subscribe for updates about the status of the OSCORE
group, instead of limiting them to rely on polling.
The method to set the current group status is out of the scope of
this document, and is defined for the administrator interface of the
Group Manager specified in [I-D.ietf-ace-oscore-gm-admin].
8.3. /ace-group/GROUPNAME/verif-data
This resource implements a GET handler.
8.3.1. GET Handler
The handler expects a GET request.
In addition to what is defined in Section 4.1.2 of [RFC9594], the
handler performs the following actions.
If the requesting Client is a current group member or is not
authorized to be signature verifier for the group, the Group Manager
MUST reply with a 4.03 (Forbidden) error response. The response MUST
have Content-Format set to "application/concise-problem-details+cbor"
[RFC9290] and is formatted as defined in Section 4.1.2 of [RFC9594].
Tiloca & Palombini Expires 16 September 2026 [Page 46]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Within the Custom Problem Detail entry 'ace-groupcomm-error', the
value of the 'error-id' field MUST be set to 8 ("Operation permitted
only to signature verifiers").
If GROUPNAME denotes a pairwise-only group, the Group Manager MUST
reply with a 4.00 (Bad Request) error response. The response MUST
have Content-Format set to "application/concise-problem-details+cbor"
[RFC9290] and is formatted as defined in Section 4.1.2 of [RFC9594].
Within the Custom Problem Detail entry 'ace-groupcomm-error', the
value of the 'error-id' field MUST be set to 7 ("Signatures not used
in the group").
If all verifications succeed, the handler replies with a 2.05
(Content) response, specifying data that allow also an external
signature verifier to verify signatures of messages protected with
the group mode of Group OSCORE and sent to the group (see Sections
7.5 and 12.3 of [I-D.ietf-core-oscore-groupcomm]). The response MUST
have Content-Format set to "application/ace-groupcomm+cbor". The
payload of the response is a CBOR map, which is formatted as defined
in Section 9.6.
8.4. /ace-group/GROUPNAME/stale-sids
This resource implements a FETCH handler.
8.4.1. FETCH Handler
The handler expects a FETCH request, whose payload specifies a
version number of the group keying material, encoded as an unsigned
CBOR integer (see Section 11.3.1).
In addition to what is defined in Section 4.1.2 of [RFC9594], the
handler verifies that the requesting Client is a current member of
the group. If the verification fails, the Group Manager MUST reply
with a 4.03 (Forbidden) error response. The response MUST have
Content-Format set to "application/concise-problem-details+cbor"
[RFC9290] and is formatted as defined in Section 4.1.2 of [RFC9594].
Within the Custom Problem Detail entry 'ace-groupcomm-error', the
value of the 'error-id' field MUST be set to 0 ("Operation permitted
only to group members").
If all verifications succeed, the handler replies with a 2.05
(Content) response, specifying data that allow the requesting Client
to delete the Recipient Contexts and authentication credentials
associated with former members of the group (see Section 12.2 of
[I-D.ietf-core-oscore-groupcomm]. The payload of the response is
formatted as defined in Section 11.3.1.
Tiloca & Palombini Expires 16 September 2026 [Page 47]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
8.5. Permitted Methods
Table 2 summarizes the CoAP methods that are permitted for accessing
different resources at the Group Manager, for (non-)members of a
group with group name GROUPNAME, and considering different roles.
The last two rows of the table apply to a node with node name
NODENAME.
The table uses the following abbreviations.
* G = CoAP method GET
* F = CoAP method FETCH
* P = CoAP method POST
* D = CoAP method DELETE
* Type1 = Member as a Requester and/or Responder
* Type2 = Member as a Monitor
* Type3 = Non-member (authorized to be signature verifier)
* Type4 = Non-member (not authorized to be signature verifier)
* * = Cannot join the group as a signature verifier
Tiloca & Palombini Expires 16 September 2026 [Page 48]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
+=================================+=======+=======+=======+=======+
| Resource | Type1 | Type2 | Type3 | Type4 |
+=================================+=======+=======+=======+=======+
| /ace-group | F | F | F | F |
+---------------------------------+-------+-------+-------+-------+
| /ace-group/GROUPNAME | G P | G P | P * | P |
+---------------------------------+-------+-------+-------+-------+
| /ace-group/GROUPNAME/active | G | G | - | - |
+---------------------------------+-------+-------+-------+-------+
| /ace-group/GROUPNAME/verif-data | - | - | G | - |
+---------------------------------+-------+-------+-------+-------+
| /ace-group/GROUPNAME/creds | G F | G F | G F | - |
+---------------------------------+-------+-------+-------+-------+
| /ace-group/GROUPNAME/kdc-cred | G | G | F | - |
+---------------------------------+-------+-------+-------+-------+
| /ace-group/GROUPNAME/stale-sids | F | F | - | - |
+---------------------------------+-------+-------+-------+-------+
| /ace-group/GROUPNAME/policies | G | G | - | - |
+---------------------------------+-------+-------+-------+-------+
| /ace-group/GROUPNAME/num | G | G | - | - |
+---------------------------------+-------+-------+-------+-------+
| /ace-group/GROUPNAME/nodes/ | G P D | G D | - | - |
| NODENAME | | | | |
+---------------------------------+-------+-------+-------+-------+
| /ace- | P | - | - | - |
| group/GROUPNAME/nodes/NODENAME/ | | | | |
| cred | | | | |
+---------------------------------+-------+-------+-------+-------+
Table 2: Permitted CoAP Methods on the Group Manager Resources
8.5.1. Signature Verifiers
Just like any candidate group member, a signature verifier provides
the Group Manager with an access token, as described in Section 5.3.
However, unlike candidate group members, it does not join any OSCORE
group, i.e., it does not perform the joining process defined in
Section 6.
After successfully transferring an access token to the Group Manager,
a signature verifier is allowed to perform only some operations as
non-member of a group, and only for the OSCORE groups specified in
the validated access token. These are the operations specified in
Section 9.3, Section 9.5, Section 9.6, and Section 9.10.
Tiloca & Palombini Expires 16 September 2026 [Page 49]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Consistently, in the case that a node is not a member of the group
with group name GROUPNAME and is authorized to be only signature
verifier for that group, the Group Manager MUST reply with a 4.03
(Forbidden) error response if that node attempts to access any other
endpoint than the following ones:
* /ace-group
* /ace-group/GROUPNAME/verif-data
* /ace-group/GROUPNAME/creds
* /ace-group/GROUPNAME/kdc-cred
8.6. Operations Supported by Clients
Building on what is defined in Section 4.1.1 of [RFC9594] and with
reference to the additional resources at the Group Manager defined in
Section 8 of this document, it is expected that a Client minimally
supports also the following set of operations and corresponding
interactions with the Group Manager (REQ12).
* GET request to /ace-group/GROUPNAME/active, in order to check the
current status of the OSCORE group.
* GET request to /ace-group/GROUPNAME/verif-data, in order for a
signature verifier to retrieve data required to verify signatures
of messages protected with the group mode of Group OSCORE and sent
to a group (see Sections 12.3 and 7.5 of
[I-D.ietf-core-oscore-groupcomm]). Note that this operation is
relevant to support only to signature verifiers.
* FETCH request to /ace-group/GROUPNAME/stale-sids, in order to
retrieve from the Group Manager the data required to delete some
of the stored group members' authentication credentials and
associated Recipient Contexts (see Section 8.4.1). This data is
provided as an aggregated set of stale Sender IDs, which are used
as specified in Section 11.3.
9. Additional Interactions with the Group Manager
This section defines the possible interactions with the Group
Manager, in addition to the group joining specified in Section 6.
Tiloca & Palombini Expires 16 September 2026 [Page 50]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
9.1. Retrieve Updated Keying Material
At some point, it can happen that a group member considers the Group
OSCORE Security Context invalid and needs to renew it. This happens,
for instance, after a number of unsuccessful security processing of
incoming messages from other group members, or when the Security
Context expires as specified by the 'exp' or 'exi' parameter of the
Join Response.
When this happens, the group member retrieves updated security
parameters and group keying material. This can occur in the two
different ways described below.
9.1.1. Get Group Keying Material
If the group member wants to retrieve only the latest group keying
material, it sends a Key Distribution Request to the Group Manager.
That is, it sends a CoAP GET request to the endpoint /ace-group/
GROUPNAME at the Group Manager.
The Group Manager processes the Key Distribution Request according to
Section 4.3.2 of [RFC9594]. The Key Distribution Response is
formatted as defined in Section 4.3.2 of [RFC9594], with the
following additions.
* The 'key' parameter is formatted as defined in Section 6.3 of this
document, with the difference that it does not include the
'group_SenderId' parameter.
* The 'exi' parameter MUST be present.
* The 'exp' parameter SHOULD be present. Omitting the parameter is
not desirable for a requesting group member that has a reliable
way to synchronize its internal clock with UTC. That is, if the
'exp' parameter is not present, such a requesting group member
falls back on using the 'exi' parameter value to less accurately
determine the expiration time of the group keying material
conveyed by the 'key' parameter.
* The 'ace_groupcomm_profile' parameter MUST be present and has
value coap_group_oscore_app.
Upon receiving the Key Distribution Response, the group member
retrieves the updated security parameters and group keying material,
and, if they differ from the current ones, uses them to set up the
new Group OSCORE Security Context as described in Section 2 of
[I-D.ietf-core-oscore-groupcomm].
Tiloca & Palombini Expires 16 September 2026 [Page 51]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
This application profile does not specify policies that instruct
group members to retain messages and for how long, if those messages
are unsuccessfully decrypted (OPT11).
9.1.2. Get Group Keying Material and OSCORE Sender ID
If the group member wants to retrieve the latest group keying
material as well as the OSCORE Sender ID that it has in the OSCORE
group, it sends a Key Distribution Request to the Group Manager.
That is, it sends a CoAP GET request to the endpoint /ace-
group/GROUPNAME/nodes/NODENAME at the Group Manager.
The Group Manager processes the Key Distribution Request according to
Section 4.8.1 of [RFC9594]. The Key Distribution Response is
formatted as defined in Section 4.8.1 of [RFC9594], with the
following additions.
* The 'key' parameter is formatted as defined in Section 6.3 of this
document. If the requesting group member has exclusively the role
of monitor, then the 'key' parameter does not include the
'group_SenderId' parameter.
Note that, in any other case, the current Sender ID of the group
member is not specified as a separate parameter, but instead by
the 'group_SenderId' parameter within the 'key' parameter.
* The 'exi' parameter MUST be present.
* The 'exp' parameter SHOULD be present. Omitting the parameter is
not desirable for a requesting group member that has a reliable
way to synchronize its internal clock with UTC. That is, if the
'exp' parameter is not present, such a requesting group member
falls back on using the 'exi' parameter value to less accurately
determine the expiration time of the group keying material
conveyed by the 'key' parameter.
Upon receiving the Key Distribution Response, the group member
retrieves the updated security parameters, group keying material, and
Sender ID, and, if they differ from the current ones, uses them to
set up the new Group OSCORE Security Context as described in
Section 2 of [I-D.ietf-core-oscore-groupcomm].
This application profile does not specify policies that instruct
group members to retain messages and for how long, if those messages
are unsuccessfully decrypted (OPT11).
Tiloca & Palombini Expires 16 September 2026 [Page 52]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
9.2. Request to Change Individual Keying Material
As discussed in Section 2.6.2 of [I-D.ietf-core-oscore-groupcomm], a
group member could at some point exhaust its Sender Sequence Numbers
in the OSCORE group.
When this happens, the group member MUST send a Key Renewal Request
message to the Group Manager, as per Section 4.8.2.1 of [RFC9594].
That is, it sends a CoAP POST request to the endpoint /ace-
group/GROUPNAME/nodes/NODENAME at the Group Manager.
Upon receiving the Key Renewal Request, the Group Manager processes
it as defined in Section 4.8.2 of [RFC9594], with the following
additions.
The Group Manager MUST return a 5.03 (Service Unavailable) response
if the OSCORE group identified by GROUPNAME is currently inactive
(see Section 8.2). The response MUST have Content-Format set to
"application/concise-problem-details+cbor" [RFC9290] and is formatted
as defined in Section 4.1.2 of [RFC9594]. Within the Custom Problem
Detail entry 'ace-groupcomm-error', the value of the 'error-id' field
MUST be set to 9 ("Group currently not active").
Otherwise, the Group Manager performs one of the following actions.
1. If the requesting group member has exclusively the role of
monitor, the Group Manager replies with a 4.00 (Bad Request)
error response. The response MUST have Content-Format set to
"application/concise-problem-details+cbor" [RFC9290] and is
formatted as defined in Section 4.1.2 of [RFC9594]. Within the
Custom Problem Detail entry 'ace-groupcomm-error', the value of
the 'error-id' field MUST be set to 1 ("Request inconsistent with
the current roles").
2. Otherwise, the Group Manager takes one of the following actions.
* The Group Manager rekeys the OSCORE group. That is, the Group
Manager generates new group keying material for that group
(see Section 11), and replies to the group member with a group
rekeying message as defined in Section 11, providing the new
group keying material. Then, the Group Manager rekeys the
rest of the OSCORE group, as discussed in Section 11.
The Group Manager SHOULD perform a group rekeying if one is
already scheduled to occur within a time frame that is
acceptably short, as per application-specific policies at the
Group Manager. For instance, a group rekeying could be
already upcoming in accordance with an application-specific
Tiloca & Palombini Expires 16 September 2026 [Page 53]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
rekeying period or scheduling, or as a reaction to a recent
change in the group membership. If a group rekeying is not
already scheduled to occur within an acceptably short time
frame, the Group Manager SHOULD NOT rekey the OSCORE group
when receiving a Key Renewal Request (OPT12).
* The Group Manager selects and assigns a new OSCORE Sender ID
for that group member (REQ27), according to the same criteria
defined in Section 6.3 for selecting and assigning an OSCORE
Sender ID to include in a Join Response.
Then, the Group Manager replies with a Key Renewal Response
formatted as defined in Section 4.8.2 of [RFC9594]. The CBOR
map in the response payload only includes the 'group_SenderId'
parameter registered in Section 17.3 of this document,
specifying the new Sender ID of the group member encoded as a
CBOR byte string (REQ27).
Consistent with Section 2.6.3.1 of
[I-D.ietf-core-oscore-groupcomm], the Group Manager MUST
assign a new Sender ID that has not been used in the OSCORE
group since the latest time when the current Gid value was
assigned to the group.
Furthermore, the Group Manager MUST add the old, relinquished
Sender ID of the group member to the most recent set of stale
Sender IDs for the group (see Section 7.1).
The Group Manager MUST return a 5.03 (Service Unavailable)
response if there are currently no Sender IDs available to
assign in the OSCORE group. The response MUST have Content-
Format set to "application/concise-problem-details+cbor"
[RFC9290] and is formatted as defined in Section 4.1.2 of
[RFC9594]. Within the Custom Problem Detail entry 'ace-
groupcomm-error', the value of the 'error-id' field MUST be
set to 4 ("No available individual keying material").
9.3. Retrieve Authentication Credentials of Group Members
A group member or a signature verifier may need to retrieve the
authentication credentials of (other) group members. To this end,
the group member or signature verifier sends an Authentication
Credential Request message to the Group Manager, as per Sections
4.4.1.1 and 4.4.2.1 of [RFC9594]. That is, it sends the request to
the endpoint /ace-group/GROUPNAME/creds at the Group Manager.
Tiloca & Palombini Expires 16 September 2026 [Page 54]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
If the Authentication Credential Request uses the method FETCH, then
the Authentication Credential Request is formatted as defined in
Section 4.4.1 of [RFC9594]. That is:
* Each element (if any) of the inner CBOR array 'role_filter' is
formatted as in the inner CBOR array 'role_filter' of the
'get_creds' parameter of the Join Request when the parameter value
is not the CBOR simple value null (0xf6) (see Section 6.1).
* Each element (if any) of the inner CBOR array 'id_filter' is a
CBOR byte string, which encodes the OSCORE Sender ID of the group
member for which the associated authentication credential is
requested (REQ25).
Upon receiving the Authentication Credential Request, the Group
Manager processes it as per Section 4.4.1 of [RFC9594] or
Section 4.4.2 of [RFC9594], depending on the request method being
FETCH or GET, respectively. Additionally, if the Authentication
Credential Request uses the method FETCH, the Group Manager silently
ignores node identifiers included in the ’get_creds’ parameter of the
request that are not associated with any current group member
(REQ26).
The success Authentication Credential Response is formatted as
defined in Section 4.4.1 of [RFC9594] or Section 4.4.2 of [RFC9594],
depending on the request method being FETCH or GET, respectively.
9.4. Upload a New Authentication Credential
A group member may need to provide the Group Manager with its new
authentication credential to use in the group from then on, hence
replacing the current one. This can be the case, for instance, if
the signature or ECDH algorithm and possible associated parameters
used in the OSCORE group have been changed, and the current
authentication credential is not compatible with them.
To this end, the group member sends an Authentication Credential
Update Request message to the Group Manager, as per Section 4.9.1.1
of [RFC9594], with the following addition.
* To prove the possession of its own private key, the group member
computes the proof-of-possession (PoP) evidence included in
'client_cred_verify' in the same way defined in Section 6.1 when
preparing a Join Request for the OSCORE group in question (REQ14),
with the difference that the 'client_cred_verify' parameter MUST
NOT specify an empty PoP evidence.
Tiloca & Palombini Expires 16 September 2026 [Page 55]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
That is, the group member sends a CoAP POST request to the endpoint
/ace-group/GROUPNAME/nodes/NODENAME/cred at the Group Manager.
Upon receiving the Authentication Credential Update Request, the
Group Manager processes it as per Section 4.9.1 of [RFC9594], with
the following additions.
* The N_S challenge that is used to build the proof-of-possession
input is determined as described in Section 6.1.1 (REQ15).
* The Group Manager verifies the PoP evidence included in the
'client_cred_verify' parameter in the same way defined in
Section 6.2 when processing a Join Request for the OSCORE group in
question (REQ14), with the difference that the verification MUST
fail if the 'client_cred_verify' parameter specifies an empty PoP
evidence.
* According to the same criteria defined in Section 6.2 when
processing a Join Request for the OSCORE group in question, the
Group Manager MUST return a 4.00 (Bad Request) error response if
it wants to prevent the acceptance and use of Ed25519 and Ed448
public keys that cannot be successfully converted to Montgomery
coordinates.
* The Group Manager MUST return a 5.03 (Service Unavailable)
response if the OSCORE group identified by GROUPNAME is currently
inactive (see Section 8.2). The response MUST have Content-Format
set to "application/concise-problem-details+cbor" [RFC9290] and is
formatted as defined in Section 4.1.2 of [RFC9594]. Within the
Custom Problem Detail entry 'ace-groupcomm-error', the value of
the 'error-id' field MUST be set to 9 ("Group currently not
active").
* If the requesting group member has exclusively the role of
monitor, the Group Manager replies with a 4.00 (Bad request) error
response. The response MUST have Content-Format set to
"application/concise-problem-details+cbor" [RFC9290] and is
formatted as defined in Section 4.1.2 of [RFC9594]. Within the
Custom Problem Detail entry 'ace-groupcomm-error', the value of
the 'error-id' field MUST be set to 1 ("Request inconsistent with
the current roles").
* If the request is successfully processed, the Group Manager stores
the association between: i) the new authentication credential of
the group member; and ii) the Group Identifier (Gid), i.e., the
OSCORE ID Context associated with the OSCORE group, together with
the OSCORE Sender ID assigned to the group member in the group.
The Group Manager MUST keep this association updated over time.
Tiloca & Palombini Expires 16 September 2026 [Page 56]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
This application profile does not specify a method for the group
member to provide other group members with the identifier of its new
authentication credential (OPT13).
9.5. Retrieve the Group Manager's Authentication Credential
A group member or a signature verifier may need to retrieve the
authentication credential of the Group Manager. To this end, the
requesting Client sends a KDC Authentication Credential Request
message to the Group Manager.
Section 9.5.1 defines how this operation is performed by a group
member, building on Section 4.5.1.1 of [RFC9594].
Section 9.5.2 defines how this operation is performed by a signature
verifier, by relying on the additional FETCH handler defined in
Section 8.1.1 of this document.
9.5.1. Retrieval for Group Members
A group member sends a CoAP GET request to the endpoint /ace-
group/GROUPNAME/kdc-cred at the Group Manager as per Section 4.5.1.1
of [RFC9594], where GROUPNAME is the name of the OSCORE group.
In addition to what is defined in Section 4.5.1 of [RFC9594], the
Group Manager MUST respond with a 4.03 (Forbidden) error response, if
the requesting Client is not a current group member. The response
MUST have Content-Format set to "application/concise-problem-
details+cbor" [RFC9290] and is formatted as defined in Section 4.1.2
of [RFC9594]. Within the Custom Problem Detail entry 'ace-groupcomm-
error', the value of the 'error-id' field MUST be set to 0
("Operation permitted only to group members").
The payload of the 2.05 (Content) KDC Authentication Credential
Response is a CBOR map, which is formatted as defined in
Section 4.5.1 of [RFC9594]. The Group Manager specifies the
parameters 'kdc_cred', 'kdc_nonce', and 'kdc_cred_verify' as defined
for the Join Response in Section 6.3 of this document. This
especially applies to the computing of the proof-of-possession (PoP)
evidence included in 'kdc_cred_verify' (REQ21) that the Group Manager
uses to prove the possession of its own private key.
Tiloca & Palombini Expires 16 September 2026 [Page 57]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Upon receiving a 2.05 (Content) KDC Authentication Credential
Response, the requesting Client retrieves the Group Manager's
authentication credential from the 'kdc_cred' parameter, and proceeds
as defined in Section 4.5.1.1 of [RFC9594]. The requesting Client
verifies the PoP evidence included in 'kdc_cred_verify' by means of
the same method used when processing the Join Response, as defined in
Section 6.3 of this document (REQ21).
9.5.2. Retrieval for Signature Verifiers
A Client signature verifier sends a CoAP FETCH request to the
endpoint /ace-group/GROUPNAME/kdc-cred at the Group Manager defined
in Section 4.5 of [RFC9594], where GROUPNAME is the name of the
OSCORE group.
The request MUST have Content-Format "application/ace-
groupcomm+cbor". The payload of the request is formatted as a CBOR
map, which MUST contain the following field with the value specified
below:
* 'cnonce': encoded as a CBOR byte string, whose value is a fresh
challenge N_C newly generated by the Client signature verifier.
As to the N_C value, it is RECOMMENDED to be at least 8 bytes long
and it is RECOMMENDED to be a random value.
The payload of the 2.05 (Content) KDC Authentication Credential
Response is a CBOR map, which is formatted as defined in
Section 4.5.1 of [RFC9594], with the following difference:
* The 'kdc_cred_verify' field specifies the PoP evidence computed by
the Group Manager to prove the possession of its own private key.
The Group Manager computes the PoP evidence over the following PoP
input: the challenge N_C (encoded as a CBOR byte string)
concatenated with the nonce N_KDC (encoded as a CBOR byte string),
where:
- N_C is the challenge generated by the Client signature verifier
and specified in the 'cnonce' field of the received KDC
Authentication Credential Request.
- N_KDC is the nonce generated by the Group Manager and specified
in the 'kdc_nonce' field of the KDC Authentication Credential
Response.
Tiloca & Palombini Expires 16 September 2026 [Page 58]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
The Group Manager specifies the 'kdc_cred' field and 'kdc_nonce'
field as defined for the Join Response in Section 6.3 of this
document. The computed PoP evidence included in the
'kdc_cred_verify' field is always a signature computed over the PoP
input defined above (REQ21).
Upon receiving a 2.05 (Content) KDC Authentication Credential
Response, the requesting Client retrieves the Group Manager's
authentication credential from the 'kdc_cred' parameter. Then, it
proceeds as defined in Section 4.5.1.1 of [RFC9594], with the
difference that it verifies the PoP evidence included in
'kdc_cred_verify' field by verifying a signature and using the PoP
input defined above (REQ21)
Note that a signature verifier would not receive a successful
response from the Group Manager, if GROUPNAME denotes a pairwise-only
group (see Section 8.1.1).
Figure 2 gives an overview of the exchange described above, while
Figure 3 shows an example of Signature Verification Data Request-
Response.
Signature Group
Verifier Manager
| |
| KDC Authentication Credential Request |
|-------------------------------------------------------------->|
| FETCH /ace-group/GROUPNAME/kdc-cred |
| |
|<--- KDC Authentication Credential Response: 2.05 (Content) ---|
| |
Figure 2: Message Flow of KDC Authentication Credential Request-
Response, with a Signature Verifier as Requesting Client
Tiloca & Palombini Expires 16 September 2026 [Page 59]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Request:
Header: FETCH (Code=0.05)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "kdc-cred"
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
/ cnonce / 6: h'6c5a8891bbcf4199'
}
Response:
Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
/ kdc_cred / 17: h'a2026008a101a5010202419920012158
2065eda5a12577c2bae829437fe33870
1a10aaa375e1bb5b5de108de439c0855
1d2258201e52ed75701163f7f9e40ddf
9f341b3dc9ba860af7e0ca7ca7e9eecd
0084d19c',
/ kdc_nonce / 18: h'aff56da30b7db12a',
/ kdc_cred_verify / 19: h'f3e4be39445b1a3e83e1510d1aca2f2e
3fc54702aa56e1b2cb20284294c9106a
8a7c081c7645042b18aba9d1fad1bd9c
63f91bac658d69351210a031d8fc7c5f'
}
Figure 3: Example of KDC Authentication Credential Request-
Response, with a Signature Verifier as Requesting Client
9.6. Retrieve Signature Verification Data
A signature verifier may need to retrieve data required to verify
signatures of messages protected with the group mode of Group OSCORE
and sent to a group (see Sections 7.5 and 12.3 of
[I-D.ietf-core-oscore-groupcomm]). To this end, the signature
verifier sends a Signature Verification Data Request message to the
Group Manager.
Tiloca & Palombini Expires 16 September 2026 [Page 60]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
That is, it sends a CoAP GET request to the endpoint /ace-
group/GROUPNAME/verif-data at the Group Manager defined in
Section 8.3 of this document, where GROUPNAME is the name of the
OSCORE group.
The payload of the 2.05 (Content) Signature Verification Data
Response is a CBOR map, which has the format used for the Join
Response message in Section 6.3, with the following differences.
* Of the parameters present in the Join Response message, only the
parameters 'gkty', 'key', 'num', 'exp', 'exi', and
'ace_groupcomm_profile' are present in the Signature Verification
Data Response.
The 'key' parameter includes only the following data.
- The parameters 'hkdf', 'contextId', 'cred_fmt', 'gp_enc_alg',
'sign_alg', and 'sign_params'. These parameters MUST be
present.
- The parameters 'alg' and 'ecdh_alg'. These parameters MUST NOT
be present if the group is a signature-only group. Otherwise,
they MUST be present.
* The 'sign_enc_key' parameter is also included, with CBOR label
registered in Section 17.3. This parameter specifies the
Signature Encryption Key of the OSCORE Group, encoded as a CBOR
byte string. The Group Manager derives the Signature Encryption
Key from the group keying material, as per Section 2.1.9 of
[I-D.ietf-core-oscore-groupcomm]. This parameter MUST be present.
In order to verify signatures in the group (see Section 7.5 of
[I-D.ietf-core-oscore-groupcomm]), the signature verifier relies on:
the data retrieved from the 2.05 (Content) Signature Verification
Data Response; the public keys of the group members signing the
messages to verify, retrieved from those members' authentication
credentials that can be obtained as defined in Section 9.3; and the
public key of the Group Manager, retrieved from the Group Manager's
authentication credential that can be obtained as defined in
Section 9.5.2.
Figure 4 gives an overview of the exchange described above, while
Figure 5 shows an example of Signature Verification Data Request-
Response.
Tiloca & Palombini Expires 16 September 2026 [Page 61]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Signature Group
Verifier Manager
| |
| Signature Verification Data Request |
|------------------------------------------------------------>|
| GET /ace-group/GROUPNAME/verif-data |
| |
|<--- Signature Verification Data Response: 2.05 (Content) ---|
| |
Figure 4: Message Flow of Signature Verification Data Request-
Response
Request:
Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "verif-data"
Response:
Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
/ gkty / 7: e'group_oscore_input_material_obj',
/ key / 8: {
/ hkdf / 3: 5, / HMAC with SHA-256 /
/ contextId / 6: h'37fc',
e'cred_fmt': 33, / x5chain /
e'gp_enc_alg': 10, / AES-CCM-16-64-128 /
e'sign_alg': -8, / EdDSA /
e'sign_params': [[1], [1, 6]]
/ [[OKP], [OKP, Ed25519]] /
},
/ num / 9: 12,
/ ace_groupcomm_profile / 10: e'coap_group_oscore_app',
/ exp / 11: 1609459200,
/ exi / 12: 2592000,
e'sign_enc_key': h'bc661fae6742abc3dd01beda1142567c'
}
Figure 5: Example of Signature Verification Data Request-Response
Tiloca & Palombini Expires 16 September 2026 [Page 62]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
9.7. Retrieve the Group Policies
A group member can request the current policies used in the OSCORE
group. To this end, the group member sends a Policies Request, as
per Section 4.6.1.1 of [RFC9594]. That is, it sends a CoAP GET
request to the endpoint /ace-group/GROUPNAME/policies at the Group
Manager, where GROUPNAME is the name of the OSCORE group.
Upon receiving the Policies Request, the Group Manager processes it
as per Section 4.6.1 of [RFC9594]. The success Policies Response is
formatted as defined in Section 4.6.1 of [RFC9594].
9.8. Retrieve the Keying Material Version
A group member can request the current version of the keying material
used in the OSCORE group. To this end, the group member sends a
Version Request, as per Section 4.7.1.1 of [RFC9594]. That is, it
sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/num at
the Group Manager, where GROUPNAME is the name of the OSCORE group.
Upon receiving the Version Request, the Group Manager processes it as
per Section 4.7.1 of [RFC9594]. The success Version Response is
formatted as defined in Section 4.7.1 of [RFC9594].
9.9. Retrieve the Group Status
A group member can request the current status of the OSCORE group,
i.e., active or inactive. To this end, the group member sends a
Group Status Request to the Group Manager.
That is, the group member sends a CoAP GET request to the endpoint
/ace-group/GROUPNAME/active at the Group Manager defined in
Section 8.2 of this document, where GROUPNAME is the name of the
OSCORE group.
The payload of the 2.05 (Content) Group Status Response includes the
CBOR Simple Value true (0xf5) if the group is currently active, or
the CBOR Simple Value false (0xf4) otherwise. The group is
considered active if it is set to allow new members to join, and if
communication within the group is fine to occur.
Upon learning from a 2.05 (Content) Group Status Response that the
group is currently inactive, the group member SHOULD stop sending
messages to other group members and MUST stop processing messages
from other group members, until the group becomes active again. In
the meantime, the group member can still interact with the Group
Manager, e.g., in order to check whether the group has become active
again.
Tiloca & Palombini Expires 16 September 2026 [Page 63]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Upon learning from a 2.05 (Content) Group Status Response that the
group has become active again, the group member can resume taking
part in communications with other group members (i.e., sending
messages and processing incoming messages).
Besides simply polling the endpoint /ace-group/GROUPNAME/active at
the Group Manager, a group member can also use CoAP Observe [RFC7641]
and subscribe for updates about the status of the OSCORE group.
Figure 6 gives an overview of the exchange described above, while
Figure 7 shows an example of Group Status Request-Response.
Group Group
Member Manager
| |
|--- Group Status Request: GET /ace-group/GROUPNAME/active --->|
| |
|<----------- Group Status Response: 2.05 (Content) -----------|
| |
Figure 6: Message Flow of Group Status Request-Response
Request:
Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "active"
Response:
Header: Content (Code=2.05)
Content-Format: 60 (application/cbor)
Payload (in CBOR diagnostic notation):
true
Figure 7: Example of Group Status Request-Response
9.10. Retrieve Group Names
A node may want to retrieve from the Group Manager the group name and
the URI of the group-membership resource of a group. This is
relevant in the following cases.
Tiloca & Palombini Expires 16 September 2026 [Page 64]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* Before joining a group, a joining node may know only the current
Group Identifier (Gid) of that group, but not the group name and
the URI of the group-membership resource.
* As a current group member in several groups, the node has missed a
previous group rekeying in one of them (see Section 11). Hence,
it retains stale keying material and fails to decrypt received
messages exchanged in that group.
Such messages do not provide a direct hint to the correct group
name, which the node would need in order to retrieve the latest
keying material and authentication credentials from the Group
Manager (see Section 9.1.1, Section 9.1.2, and Section 9.3).
However, such messages could specify the current Gid of the group,
as the value of the 'kid_context' field of the OSCORE CoAP option
(see Section 6.1 of [RFC8613] and Section 3.2 of
[I-D.ietf-core-oscore-groupcomm]).
* As a signature verifier, the node also refers to a group name for
retrieving the required authentication credentials from the Group
Manager (see Section 9.3). As discussed above, intercepted
messages do not provide a direct hint to the correct group name,
while they could specify the current Gid of the group, as the
value of the 'kid_context' field of the OSCORE CoAP option. In
such a case, upon intercepting a message in the group, the node
requires to correctly map the Gid currently used in the group with
the invariant group name.
Since it is not a group member, the node does not take part to a
possible group rekeying. Thus, following a group rekeying and the
consequent change of Gid in a group, the node would retain the old
Gid value and cannot correctly associate intercepted messages with
the right group, especially if acting as a signature verifier in
several groups. This in turn prevents the efficient verification
of signatures, and especially the retrieval of required, new
authentication credentials from the Group Manager.
In either case, the node only knows the current Gid of the group, as
learned from received or intercepted messages exchanged in the group.
As detailed below, the node can contact the Group Manager, and
request the group name and URI of the group-membership resource
corresponding to that Gid. Then, it can use that information to join
the group, or get the latest keying material as a current group
member, or retrieve authentication credentials used in the group as a
signature verifier. To this end, the node sends a Group Name and URI
Retrieval Request, as per Section 4.2.1.1 of [RFC9594].
Tiloca & Palombini Expires 16 September 2026 [Page 65]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
That is, the node sends a CoAP FETCH request to the endpoint /ace-
group at the Group Manager formatted as defined in Section 4.2.1 of
[RFC9594]. Each element of the CBOR array 'gid' is a CBOR byte
string (REQ13), which encodes the Gid of the group for which the
group name and the URI of the group-membership resource are
requested.
Upon receiving the Group Name and URI Retrieval Request, the Group
Manager processes it as per Section 4.2.1 of [RFC9594]. The success
Group Name and URI Retrieval Response is formatted as defined in
Section 4.2.1 of [RFC9594]. Each element of the CBOR array 'gid' is
a CBOR byte string (REQ13), which encodes the Gid of the group for
which the group name and the URI of the group-membership resource are
provided.
For each of its groups, the Group Manager maintains an association
between the group name and the URI of the group-membership resource
on one hand, and only the current Gid for that group on the other
hand. That is, the Group Manager does not maintain an association
between the former pair and any other Gid for that group than the
current, most recent one.
Figure 8 gives an overview of the exchanges described above, while
Figure 9 shows an example of Group Name and URI Retrieval Request-
Response.
Group
Node Manager
| |
|--- Group Name and URI Retrieval Request: FETCH /ace-group ---->|
| |
|<--- Group Name and URI Retrieval Response: 2.05 (Content) -----|
| |
Figure 8: Message Flow of Group Name and URI Retrieval Request-
Response
Tiloca & Palombini Expires 16 September 2026 [Page 66]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Request:
Header: FETCH (Code=0.05)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
/ gid / 0: [h'37fc', h'84bd']
}
Response:
Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
/ gid / 0: [h'37fc', h'84bd'],
/ gname / 1: ["g1", "g2"],
/ guri / 2: ["/ace-group/g1", "/ace-group/g2"]
}
Figure 9: Example of Group Name and URI Retrieval Request-Response
9.11. Leave the Group
A group member may request to leave the OSCORE group. To this end,
the group member sends a Group Leaving Request, as per
Section 4.8.3.1 of [RFC9594]. That is, it sends a CoAP DELETE
request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the
Group Manager.
Upon receiving the Group Leaving Request, the Group Manager processes
it as per Section 4.8.3 of [RFC9594]. Then, the Group Manager
performs the follow-up actions defined in Section 10 of this
document.
10. Removal of a Group Member
Other than after a spontaneous request to the Group Manager as
described in Section 9.11, a node could be forcibly removed from the
OSCORE group, e.g., due to expired or revoked authorization.
In either case, if the Group Manager reassigns Gid values during the
group's lifetime (see Section 12.2.1.1 of
[I-D.ietf-core-oscore-groupcomm]), the Group Manager "forgets" the
Birth Gid currently associated with the leaving node in the OSCORE
Tiloca & Palombini Expires 16 September 2026 [Page 67]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
group. This was stored following the Join Response sent to that
node, after its latest (re-)joining of the OSCORE group (see
Section 6.3).
If any of the two conditions below holds, the Group Manager MUST
inform the leaving node of its eviction as follows. If both
conditions hold, the Group Manager MUST inform the leaving node by
using only the method corresponding to one of either conditions.
* If, upon joining the group (see Section 6.1), the leaving node
specified a URI in the 'control_uri' parameter defined in
Section 4.3.1 of [RFC9594], then the Group Manager sends a DELETE
request targeting the URI specified in the 'control_uri' parameter
(OPT7).
* If the leaving node has been observing the associated resource at
/ace-group/GROUPNAME/nodes/NODENAME, then the Group Manager sends
an unsolicited 4.04 (Not Found) error response to the leaving
node, as specified in Section 4.3.2 of [RFC9594].
Furthermore, the Group Manager might intend to evict all the current
group members from the group at once. In such a case, if the Join
Responses sent by the Group Manager to nodes joining the group (see
Section 6.3) specify a URI in the 'control_group_uri' parameter
defined in Section 4.3.1 of [RFC9594], then the Group Manager MUST
additionally send a DELETE request targeting the URI specified in the
'control_group_uri' parameter (OPT10).
If the leaving node has not exclusively the role of monitor, then the
Group Manager performs the following actions.
* The Group Manager frees the OSCORE Sender ID value of the leaving
node. This value MUST NOT become available for possible upcoming
joining nodes in the same group, until the group has been rekeyed
and assigned a new Group Identifier (Gid).
* The Group Manager MUST add the relinquished Sender ID of the
leaving node to the most recent set of stale Sender IDs for the
group (see Section 7.1).
* The Group Manager cancels the association between, on one hand,
the authentication credential of the leaving node and, on the
other hand, the Gid associated with the OSCORE group together with
the freed Sender ID value.
* The Group Manager deletes the authentication credential of the
leaving node, if that authentication credential has no remaining
association with any pair (Gid, Sender ID).
Tiloca & Palombini Expires 16 September 2026 [Page 68]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Then, the Group Manager MUST generate updated security parameters and
group keying material, and provide it to the remaining group members
(see Section 11). As a consequence, the leaving node is not able to
acquire the new security parameters and group keying material
distributed after its leaving.
The same considerations from Section 5 of [RFC9594] apply here as
well, considering the Group Manager acting as KDC.
11. Group Rekeying Process
In order to rekey an OSCORE group, the Group Manager distributes the
following information for that group:
* A new Group Identifier (Gid), i.e., a new OSCORE ID Context.
* A new OSCORE Master Secret.
* Optionally, a new OSCORE Master Salt.
Before starting such distribution, the Group Manager MUST increment
the version number of the group keying material used in the group.
As per Section 12.2.1.1 of [I-D.ietf-core-oscore-groupcomm], the
Group Manager MAY reassign a Gid to the same group over that group's
lifetime, e.g., once the whole space of Gid values has been used for
the group in question. If the Group Manager supports reassignment of
Gid values and performs it in a group, then the Group Manager
additionally takes the following actions.
* Before rekeying the group, the Group Manager MUST check if the new
Gid to be distributed coincides with the Birth Gid of any of the
current group members (see Section 6.3).
* If any such "elder members" are found in the group, then the Group
Manager MUST evict them from the group. That is, the Group
Manager MUST terminate their membership and MUST rekey the group
in such a way that the new keying material is not provided to
those evicted elder members. This also includes adding their
relinquished Sender IDs to the most recent set of stale Sender IDs
for the group (see Section 7.1), before rekeying the group.
Tiloca & Palombini Expires 16 September 2026 [Page 69]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Until a further following group rekeying, the Group Manager MUST
store the list of those latest-evicted elder members. If any of
those nodes re-joins the group before a further following group
rekeying occurs, the Group Manager MUST NOT rekey the group upon
their re-joining. When one of those nodes re-joins the group, the
Group Manager can rely on, e.g., the ongoing secure communication
association to recognize the node as included in the stored list.
Throughout the rekeying execution, the Group Manager MUST preserve
the same unchanged OSCORE Sender IDs for all group members that are
intended to remain in the group. This avoids affecting the retrieval
of authentication credentials from the Group Manager and the
verification of group messages.
The Group Manager MUST support the "Point-to-Point" group rekeying
scheme registered in Section 11.13 of [RFC9594], as per the detailed
use defined in Section 11.1 of this document. Future specifications
may define how this application profile can use alternative group
rekeying schemes, which MUST comply with the functional steps defined
in Section 12.2 of [I-D.ietf-core-oscore-groupcomm]. The Group
Manager MUST indicate the use of such an alternative group rekeying
scheme to joining nodes, by means of the 'group_rekeying' parameter
included in Join Response messages (see Section 6.3).
It is RECOMMENDED that the Group Manager gets confirmation of
successful distribution from the group members, and admits a maximum
number of individual retransmissions to non-confirming group members.
Once the group rekeying process has completed, the Group Manager
creates a new empty set of stale Sender IDs associated with the
version of the newly distributed group keying material (see
Section 7.1).
If the rekeying terminates and some group members have not received
the new keying material, such group members will not be able to
correctly process following secured messages exchanged in the group.
These group members will eventually contact the Group Manager, in
order to retrieve the current keying material and its version.
Some of these group members may be in multiple groups, each
associated with a different Group Manager. When failing to correctly
process messages secured with the new keying material, these group
members may not have sufficient information to determine which exact
Group Manager to contact, in order to retrieve the current keying
material that they are missing.
If the Gid is formatted as described in Appendix C of
[I-D.ietf-core-oscore-groupcomm], then the Group Prefix can be used
as a hint to determine the right Group Manager, as long as no
Tiloca & Palombini Expires 16 September 2026 [Page 70]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
collisions among Group Prefixes are experienced. Otherwise, a group
member needs to contact the Group Manager of each group, e.g., by
first requesting only the version of the current group keying
material (see Section 9.8) and then possibly requesting the current
keying material (see Section 9.1.1).
Furthermore, some of these group members can be in multiple groups,
all of which are associated with the same Group Manager. In this
case, these group members may also not have sufficient information to
determine which exact group to refer to, when contacting the right
Group Manager. Hence, these group members need to contact a Group
Manager multiple times, i.e., separately for each group they belong
to and associated with that Group Manager.
Section 11.2 defines the actions performed by a group member upon
receiving the new group keying material. Section 11.3 discusses how
a group member can realize that it has missed one or more rekeying
instances, and the actions that it is accordingly required to take.
11.1. Sending Rekeying Messages
When using the "Point-to-Point" group rekeying scheme, the group
rekeying messages MUST have Content-Format set to "application/ace-
groupcomm+cbor" and have the same format used for the Join Response
message in Section 6.3, with the following differences. Note that
this extends the minimal content of a rekeying message as defined in
Section 6 of [RFC9594] (OPT14).
* Of the parameters present in the Join Response message, only the
parameters 'gkty', 'key', 'num', 'exp', 'exi', and
'ace_groupcomm_profile' are present.
The 'key' parameter includes only the following data.
- The 'ms' parameter, specifying the new OSCORE Master Secret
value. This parameter MUST be present.
- The 'contextId' parameter, specifying the new Gid to use as
OSCORE ID Context value. This parameter MUST be present.
- The 'salt' value, specifying the new OSCORE Master Salt value.
This parameter MAY be present.
* The 'stale_node_ids' parameter MUST also be included, with CBOR
label registered in Section 17.3. This parameter is encoded as a
CBOR array, where each element is encoded as a CBOR byte string.
The order of elements in the CBOR array is irrelevant. The
parameter is populated as follows.
Tiloca & Palombini Expires 16 September 2026 [Page 71]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- The Group Manager creates an empty CBOR array ARRAY.
- The Group Manager considers the most recent set of stale Sender
IDs for the group (see Section 7.1), i.e., the set X associated
with the current version of the group keying material that is
about to be relinquished.
- For each Sender ID in X, the Group Manager encodes it as a CBOR
byte string and adds the result to ARRAY.
- The 'stale_node_ids' parameter takes ARRAY as value.
* The parameters 'creds', 'peer_roles', and 'peer_identifiers'
SHOULD be present, if the group rekeying is performed due to one
or multiple Clients that have requested to join the group.
Following the same semantics used in the Join Response message
(see Section 6.3), the three parameters specify the authentication
credential, roles in the group, and node identifier of each of the
Clients that have requested to join the group. The Group Manager
MUST NOT include a non-empty subset of these three parameters.
The Group Manager separately sends a group rekeying message formatted
as defined above to each group member to be rekeyed.
Each rekeying message MUST be secured with the pairwise secure
communication association between the Group Manager and the group
member used during the joining process. Each rekeying message can
target the 'control_uri' URI path defined in Section 4.3.1 of
[RFC9594] (OPT7), if provided by the intended recipient upon joining
the group (see Section 6.1).
This distribution approach requires group members to act as servers,
in order to correctly handle unsolicited group rekeying messages from
the Group Manager. If a group member and the Group Manager use
OSCORE [RFC8613] to secure their pairwise communications, then the
group member MUST create a Replay Window in its own Recipient Context
upon establishing the OSCORE Security Context with the Group Manager,
e.g., by means of the OSCORE profile of ACE [RFC9203].
Group members and the Group Manager SHOULD additionally support
alternative distribution approaches that do not require group members
to act as servers. A number of such approaches are defined in
Section 6 of [RFC9594]. In particular, a group member may use CoAP
Observe [RFC7641] and subscribe for updates to the group-membership
resource of the group, at the endpoint /ace-group/GROUPNAME of the
Group Manager (see Section 6.1 of [RFC9594]). Alternatively, a full-
fledged Pub-Sub model can be considered [I-D.ietf-core-coap-pubsub],
Tiloca & Palombini Expires 16 September 2026 [Page 72]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
where the Group Manager publishes to a rekeying topic hosted at a
Broker, while the group members subscribe to such topic (see
Section 6.2 of [RFC9594]).
11.2. Receiving Rekeying Messages
After having received the new group keying material, a group member
proceeds as follows. Unless otherwise specified, the following is
independent of the group rekeying scheme specifically used.
The group member considers the stale Sender IDs received from the
Group Manager. If the "Point-to-Point" group rekeying scheme as
detailed in Section 11.1 is used, the stale Sender IDs are specified
by the 'stale_node_ids' parameter.
After that, as per Section 12.2 of [I-D.ietf-core-oscore-groupcomm],
the group member MUST remove every authentication credential
associated with a stale Sender ID from its list of group members'
authentication credentials used in the group, and MUST delete each of
its Recipient Contexts used in the group whose corresponding
Recipient ID is a stale Sender ID.
Then, the following cases can occur, based on the version number V'
of the new group keying material distributed through the rekeying
process. If the "Point-to-Point" group rekeying scheme as detailed
in Section 11.1 is used, this information is specified by the 'num'
parameter.
* The group member has not missed any group rekeying. That is, the
old keying material stored by the group member has version number
V, while the received new keying material has version number V' =
(V + 1). In such a case, the group member simply installs the new
keying material and derives the corresponding new Security
Context.
* The group member has missed one or more group rekeying instances.
That is, the old keying material stored by the group member has
version number V, while the received new keying material has
version number V' > (V + 1). In such a case, the group member
MUST proceed as defined in Section 11.3.
* The group member has received keying material not newer than the
stored one. That is, the old keying material stored by the group
member has version number V, while the received keying material
has version number V' < (V + 1). In such a case, the group member
MUST ignore the received rekeying messages and MUST NOT install
the received keying material.
Tiloca & Palombini Expires 16 September 2026 [Page 73]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
11.3. Missed Rekeying Instances
A group member can realize to have missed one or more rekeying
instances in one of the ways discussed below. In the following, V
denotes the version number of the old keying material stored by the
group member, while V' denotes the version number of the latest,
possibly just distributed, keying material.
a. The group member has participated in a rekeying process that has
distributed new keying material with version number V' > (V + 1), as
discussed in Section 11.2.
b. The group member has obtained the latest keying material from the
Group Manager, as a response to a Key Distribution Request (see
Section 9.1.1) or to a Join Request when re-joining the group (see
Section 6.1). That is, V is different than V' specified by the 'num'
parameter in the response.
c. The group member has obtained the authentication credentials of
other group members, through an Authentication Credential Request-
Response exchange with the Group Manager (see Section 9.3). That is,
V is different than V' specified by the 'num' parameter in the
response.
d. The group member has performed a Version Request-Response
exchange with the Group Manager (see Section 9.8). That is, V is
different than V' specified by the 'num' parameter in the response.
In either case, the group member MUST delete the stored keying
material with version number V.
If case (a) or case (b) applies, the group member MUST perform the
following actions.
1. The group member MUST NOT install the latest keying material yet,
if that was already obtained.
2. The group member sends a Stale Sender IDs Request to the Group
Manager (see Section 11.3.1), specifying the version number V as
payload of the request.
If the Stale Sender IDs Response from the Group Manager has no
payload, the group member MUST remove all the authentication
credentials from its list of group members' authentication
credentials used in the group, and MUST delete all its Recipient
Contexts used in the group.
Tiloca & Palombini Expires 16 September 2026 [Page 74]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Otherwise, the group member considers the stale Sender IDs
specified in the Stale Sender IDs Response from the Group
Manager. Then, the group member MUST remove every authentication
credential associated with a stale Sender ID from its list of
group members' authentication credentials used in the group, and
MUST delete each of its Recipient Contexts used in the group
whose corresponding Recipient ID is a stale Sender ID.
3. The group member installs the latest keying material with version
number V' and derives the corresponding new Security Context.
If case (c) or case (d) applies, the group member SHOULD perform the
following actions.
1. The group member sends a Stale Sender IDs Request to the Group
Manager (see Section 11.3.1), specifying the version number V as
payload of the request.
If the Stale Sender IDs Response from the Group Manager has no
payload, the group member MUST remove all the authentication
credentials from its list of group members' authentication
credentials used in the group, and MUST delete all its Recipient
Contexts used in the group.
Otherwise, the group member considers the stale Sender IDs
specified in the Stale Sender IDs Response from the Group
Manager. Then, the group member MUST remove every authentication
credential associated with a stale Sender ID from its list of
group members' authentication credentials used in the group, and
MUST delete each of its Recipient Contexts used in the group
whose corresponding Recipient ID is a stale Sender ID.
2. The group member retrieves the latest keying material with
version number V' from the Group Manager. This can happen by
sending a Key Distribution Request to the Group Manager (see
Section 9.1.1) and Section 9.1.2).
3. The group member installs the latest keying material with version
number V' and derives the corresponding new Security Context.
If case (c) or case (d) applies, the group member can alternatively
perform the following actions.
Tiloca & Palombini Expires 16 September 2026 [Page 75]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
1. The group member re-joins the group (see Section 6.1). When
doing so, the group member MUST re-join with the same roles that
it currently has in the group, and MUST request from the Group
Manager the authentication credentials of all the current group
members. That is, the 'get_creds' parameter of the Join Request
MUST be present and MUST be set to the CBOR Simple Value null
(0xf6).
2. When receiving the Join Response (see Section 6.4), the group
member retrieves the set Z of authentication credentials
specified in the 'creds' parameter.
Then, the group member MUST remove every authentication
credential that is not in Z from its list of group members'
authentication credentials used in the group, and MUST delete
each of its Recipient Contexts used in the group that does not
include any of the authentication credentials in Z.
3. The group member installs the latest keying material with version
number V' and derives the corresponding new Security Context.
11.3.1. Retrieve Stale Sender IDs
When realizing that it has missed one or more group rekeying
instances (see Section 11.3), a node needs to retrieve from the Group
Manager the data required to delete some of its stored group members'
authentication credentials and Recipient Contexts (see
Section 8.4.1). These data are provided as an aggregated set of
stale Sender IDs, which are used as specified in Section 11.3.
That is, the node sends a CoAP FETCH request to the endpoint /ace-
group/GROUPNAME/stale-sids at the Group Manager defined in
Section 8.4 of this document, where GROUPNAME is the name of the
OSCORE group.
The payload of the Stale Sender IDs Request MUST include a CBOR
unsigned integer. This encodes the version number V of the most
recent group keying material stored and installed by the requesting
Client, which is older than the latest, possibly just distributed,
keying material with version number V'.
The handler MUST reply with a 4.00 (Bad Request) error response, if
the request is not formatted correctly. Also, the handler MUST
respond with a 4.00 (Bad Request) error response, if the specified
version number V is greater or equal than the version number V'
associated with the latest keying material in the group, i.e., if V
>= V'.
Tiloca & Palombini Expires 16 September 2026 [Page 76]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Otherwise, the handler responds with a 2.05 (Content) Stale Sender
IDs Response. The payload of the response is formatted as defined
below, where SKEW = (V' - V + 1).
* The Group Manager considers ITEMS as the current number of sets of
stale Sender IDs for the group (see Section 7.1).
* If SKEW > ITEMS, the Stale Sender IDs Response MUST NOT have a
payload.
* Otherwise, the payload of the Stale Sender IDs Response MUST
include a CBOR array, where each element is encoded as a CBOR byte
string. The order of elements in the CBOR array is irrelevant.
The Group Manager populates the CBOR array as follows.
- The Group Manager creates an empty CBOR array ARRAY and an
empty set X.
- The Group Manager considers the SKEW most recent sets of stale
Sender IDs for the group. Note that the most recent set is the
one associated with the latest version of the group keying
material.
- The Group Manager copies all the Sender IDs from the selected
sets into X. When doing so, the Group Manager MUST discard
duplicates. That is, the same Sender ID MUST NOT be present
more than once in the final content of X.
- For each Sender ID in X, the Group Manager encodes it as a CBOR
byte string and adds the result to ARRAY.
- Finally, ARRAY is specified as payload of the Stale Sender IDs
Response. Note that ARRAY might result in the empty CBOR
array.
Figure 10 gives an overview of the exchange described above, while
Figure 11 shows an example of Stale Sender IDs Request-Response.
Group
Node Manager
| |
| Stale Sender IDs Request |
|------------------------------------------------------------>|
| FETCH /ace-group/GROUPNAME/stale-sids |
| |
|<---------- Stale Sender IDs Response: 2.05 (Content) -------|
| |
Tiloca & Palombini Expires 16 September 2026 [Page 77]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Figure 10: Message Flow of Stale Sender IDs Request-Response
Request:
Header: FETCH (Code=0.05)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "stale-sids"
Content-Format: 60 (application/cbor)
Payload (in CBOR diagnostic notation):
42
Response:
Header: Content (Code=2.05)
Content-Format: 60 (application/cbor)
Payload (in CBOR diagnostic notation):
[h'01', h'fc', h'12ab', h'de44', h'ff']
Figure 11: Example of Stale Sender IDs Request-Response
12. ACE Groupcomm Parameters
In addition to what is defined in Section 8 of [RFC9594], this
application profile defines additional parameters used during the
second part of the message exchange with the Group Manager, i.e.,
after the exchange of Token Transfer Request and Response (see
Section 5.3). The table below summarizes them and specifies the CBOR
key to use instead of the full descriptive name.
Note that the media type "application/ace-groupcomm+cbor" MUST be
used when these parameters are transported in the respective message
fields.
Tiloca & Palombini Expires 16 September 2026 [Page 78]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
+================+==========+===========+============+
| Name | CBOR Key | CBOR Type | Reference |
+================+==========+===========+============+
| group_senderId | 21 | bstr | [RFC-XXXX] |
+----------------+----------+-----------+------------+
| ecdh_info | 31 | array | [RFC-XXXX] |
+----------------+----------+-----------+------------+
| kdc_dh_creds | 32 | array | [RFC-XXXX] |
+----------------+----------+-----------+------------+
| sign_enc_key | 33 | bstr | [RFC-XXXX] |
+----------------+----------+-----------+------------+
| stale_node_ids | 34 | array | [RFC-XXXX] |
+----------------+----------+-----------+------------+
Table 3: ACE Groupcomm Parameters
Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
with the RFC number of this specification and delete this paragraph.
The Group Manager is expected to support all the parameters above.
Instead, a Client is required to support the new parameters defined
in this application profile as specified below (REQ29).
* 'group_senderId' MUST be supported by a Client that intends to
join an OSCORE group with the role of Requester and/or Responder.
* 'ecdh_info' MUST be supported by a Client that intends to join a
group which uses the pairwise mode of Group OSCORE.
* 'kdc_dh_creds' MUST be supported by a Client that intends to join
a group which uses the pairwise mode of Group OSCORE and that does
not plan to or cannot rely on an early retrieval of the Group
Manager's Diffie-Hellman authentication credential.
* 'sign_enc_key' MUST be supported by a Client that intends to join
a group which uses the group mode of Group OSCORE or to be
signature verifier for that group.
* 'stale_node_ids' MUST be supported.
When the conditional parameters defined in Section 8 of [RFC9594] are
used with this application profile, a Client must, should, or may
support them as specified below (REQ30).
* 'client_cred' and 'client_cred_verify'. A Client that has an own
authentication credential to use in a group MUST support these
parameters.
Tiloca & Palombini Expires 16 September 2026 [Page 79]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* 'kdcchallenge'. A Client that has an own authentication
credential to use in a group and that provides the access token to
the Group Manager through a Token Transfer Request (see
Section 5.3) MUST support this parameter.
* 'creds_repo'. This parameter is not relevant for this application
profile, since the Group Manager always acts as repository of the
group members' authentication credentials. Consequently, no
encoding is defined for this parameter (OPT6).
* 'group_policies'. A Client that is interested in the specific
policies used in a group, but that does not know them or cannot
become aware of them before joining that group, SHOULD support
this parameter.
* 'peer_roles'. A Client MUST support this parameter, since in this
application profile it is relevant for Clients to know the roles
of the group member associated with each authentication
credential.
* 'kdc_nonce', 'kdc_cred', and 'kdc_cred_verify'. A Client MUST
support these parameters, since the Group Manager's authentication
credential is required to process messages protected with Group
OSCORE (see Section 2.1.6 of [I-D.ietf-core-oscore-groupcomm]).
* 'mgt_key_material'. A Client that supports an advanced rekeying
scheme possibly used in the group, such as based on one-to-many
rekeying messages sent by the Group Manager (e.g., over IP
multicast), MUST support this parameter.
* 'control_group_uri'. A Client that supports the hosting of local
resources each associated with a group (hence acting as CoAP
server) and the reception of one-to-many requests sent to those
resources by the Group Manager (e.g., over IP multicast) MUST
support this parameter.
13. ACE Groupcomm Error Identifiers
In addition to what is defined in Section 9 of [RFC9594], this
document defines new values that the Group Manager can use as error
identifiers (OPT5). These are used in error responses with Content-
Format "application/concise-problem-details+cbor" [RFC9290], as
values of the 'error-id' field within the Custom Problem Detail entry
'ace-groupcomm-error' (see Section 4.1.2 of [RFC9594]).
Tiloca & Palombini Expires 16 September 2026 [Page 80]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
+=======+=================================================+
| Value | Description |
+=======+=================================================+
| 7 | Signatures not used in the group |
+-------+-------------------------------------------------+
| 8 | Operation permitted only to signature verifiers |
+-------+-------------------------------------------------+
| 9 | Group currently not active |
+-------+-------------------------------------------------+
Table 4: ACE Groupcomm Error Identifiers
If the Client supports the problem-details format [RFC9290] and the
Custom Problem Detail entry 'ace-groupcomm-error' defined in
Section 4.1.2 of [RFC9594], and is able to understand the error
specified in the 'error-id' field therein, then the Client may use
that information to determine what actions to take next. If the
Concise Problem Details data item specified in the error response
includes the 'detail' entry and the Client supports it, such an entry
may provide additional context.
* In case of error 7, the Client should stop sending the request in
question to the Group Manager. In this application profile, this
error is relevant only for a signature verifier, if it tries to
access resources related to a pairwise-only group.
* In case of error 8, the Client should stop sending the request in
question to the Group Manager.
* In case of error 9, the Client should wait for a certain (pre-
configured) amount of time, before trying to re-send its request
to the Group Manager.
14. Default Values for Group Configuration Parameters
This section defines the default values that the Group Manager refers
to for the configuration parameters of an OSCORE group, in case
values for those parameters are not explicitly specified when
creating and configuring the group (for example, by means of the
admin interface defined in [I-D.ietf-ace-oscore-gm-admin]). These
default values are RECOMMENDED to use for the configuration
parameters.
Exceptionally, the Group Manager MAY choose different default values
instead of those recommended in this section. A possible reason is
to ensure that each of those are consistent with what the Group
Manager supports, e.g., in terms of signature algorithm and format of
authentication credentials used in the OSCORE group.
Tiloca & Palombini Expires 16 September 2026 [Page 81]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
This ensures that the Group Manager is able to perform the operations
defined in this document, e.g., to achieve proof of possession of a
joining node's private key (see Section 6.2), as well as to provide a
joining node with its own authentication credential and the
associated proof-of-possession challenge (see Section 6.3).
The following builds on the "COSE Header Parameters" registry
[COSE.Header.Parameters], the "COSE Algorithms" registry
[COSE.Algorithms], the "COSE Key Types" registry [COSE.Key.Types],
and the "COSE Elliptic Curves" registry [COSE.Elliptic.Curves].
14.1. Common
This section always applies, as related to common configuration
parameters.
* For the HKDF Algorithm 'hkdf', the Group Manager SHOULD use HKDF
SHA-256, defined as default in Section 3.2 of [RFC8613]. In the
'hkdf' parameter, this HKDF Algorithm is specified by the HMAC
Algorithm HMAC 256/256 (COSE algorithm encoding: 5).
* For the Authentication Credential Format 'cred_fmt', the Group
Manager SHOULD use CBOR Web Token Claims Set (CCS) [RFC8392],
i.e., the COSE Header Parameter 'kccs' (COSE header parameter
encoding: 14).
* For 'max_stale_sets', the Group Manager SHOULD consider N = 3 as
the maximum number of stored sets of stale Sender IDs for the
group (see Section 7.1).
14.2. Group Mode
This section applies if the group uses (also) the group mode of Group
OSCORE.
* For the Group Encryption Algorithm 'gp_enc_alg' used to encrypt
messages protected with the group mode, the Group Manager SHOULD
use AES-CCM-16-64-128 (COSE algorithm encoding: 10).
* For the Signature Algorithm 'sign_alg' used to sign messages
protected with the group mode, the Group Manager SHOULD use EdDSA
[RFC8032].
* For the parameters 'sign_params' of the Signature Algorithm, the
Group Manager SHOULD use the following:
Tiloca & Palombini Expires 16 September 2026 [Page 82]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- The array [[OKP], [OKP, Ed25519]], in case EdDSA is assumed or
specified for 'sign_alg'. This indicates to use the COSE key
type OKP and the elliptic curve Ed25519 [RFC8032].
- The array [[EC2], [EC2, P-256]], in case ES256 [RFC6979] is
specified for 'sign_alg'. This indicates to use the COSE key
type EC2 and the elliptic curve P-256.
- The array [[EC2], [EC2, P-384]], in case ES384 [RFC6979] is
specified for 'sign_alg'. This indicates to use the COSE key
type EC2 and the elliptic curve P-384.
- The array [[EC2], [EC2, P-521]], in case ES512 [RFC6979] is
specified for 'sign_alg'. This indicates to use the COSE key
type EC2 and the elliptic curve P-521.
- The array [[RSA], [RSA]], in case PS256, PS384, or PS512
[RFC8017] is specified for 'sign_alg'. This indicates to use
the COSE key type RSA.
14.3. Pairwise Mode
This section applies if the group uses (also) the pairwise mode of
Group OSCORE.
* For the AEAD Algorithm 'alg' used to encrypt messages protected
with the pairwise mode, the Group Manager SHOULD use the same
default value defined in Section 3.2 of [RFC8613], i.e., AES-CCM-
16-64-128 (COSE algorithm encoding: 10).
* For the Pairwise Key Agreement Algorithm 'ecdh_alg' used to
compute static-static Diffie-Hellman shared secrets, the Group
Manager SHOULD use the following:
- The ECDH algorithm ECDH-SS + HKDF-256 (COSE algorithm encoding:
-27), in case the HKDF Algorithm assumed or specified for
'hkdf' is HKDF SHA-256 (specified by the HMAC Algorithm HMAC
256/256).
- The ECDH algorithm ECDH-SS + HKDF-512 (COSE algorithm encoding:
-28), in case the HKDF Algorithm specified for 'hkdf' is HKDF
SHA-512 (specified by the HMAC Algorithm HMAC HMAC 512/512).
* For the parameter 'ecdh_params' of the Pairwise Key Agreement
Algorithm, the Group Manager SHOULD use the following:
Tiloca & Palombini Expires 16 September 2026 [Page 83]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- The array [[OKP], [OKP, X25519]], in case EdDSA is assumed or
specified for 'sign_alg', or in case the group is a pairwise-
only group. This indicates to use the COSE key type OKP and
the elliptic curve X25519 [RFC8032].
- The array [[EC2], [EC2, P-256]], in case ES256 [RFC6979] is
specified for 'sign_alg'. This indicates to use the COSE key
type EC2 and the elliptic curve P-256.
- The array [[EC2], [EC2, P-384]], in case ES384 [RFC6979] is
specified for 'sign_alg'. This indicates to use the COSE key
type EC2 and the elliptic curve P-384.
- The array [[EC2], [EC2, P-521]], in case ES512 [RFC6979] is
specified for 'sign_alg'. This indicates to use the COSE key
type EC2 and the elliptic curve P-521.
15. Operational Considerations
In addition to the considerations already discussed in this document
(e.g., regarding default values), this section compiles additional
operational considerations that hold for this document.
15.1. Logging
When performing its normal operations, the Group Manager is expected
to produce and store timestamped logs about the following:
* Any event that has resulted in the Group Manager sending an error
response, as a reply to a request received at any of the resources
exported by the interface specified in this document.
The logged information contains a description of the error
occurred in the context of the present application profile,
together with a description of the event related to the error and
relevant metadata about the Client that has sent the request. For
instance, possible metadata include: addressing information of the
Client; when applicable, the OSCORE Sender ID that is assigned to
the Client in the group; when applicable, (an identifier of) the
authentication credential of the Client (i.e., that the Client
uses in the group or has used to authenticate itself to the Group
Manager when establishing their secure communication association).
Tiloca & Palombini Expires 16 September 2026 [Page 84]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Note that, if the error response uses the format problem-details
defined in [RFC9290], then the optional "detail" entry in the
response payload is meant to convey the diagnostic description of
the error, which is meant to be part of the log entry for this
event. This is consistent with Section 4.1.2 of [RFC9594], which
states that the diagnostic description of the error should be
logged.
* Any event consisting in a successfully performed operation that is
triggered by a request received at any of the resources exported
by the interface specified in this document.
Such events include:
- A Client joining or re-joining a group.
- The upload of a new authentication credential for use within
the group.
- The acquisition of a new Sender ID for use within the group.
- A Client leaving a group.
The logged information contains a description of the operation
performed in the context of the present application profile,
together with relevant metadata about the Client that has sent the
request. For instance, possible metadata include: addressing
information of the Client; when applicable, the OSCORE Sender ID
that is assigned to the Client in the group; when applicable, (an
identifier of) the authentication credential of the Client (i.e.,
that the Client uses in the group or has used to authenticate
itself to the Group Manager when establishing their secure
communication association).
* The execution and successful/unsuccessful completion of a group
rekeying instance.
The logged information includes:
- The reason for the group rekeying (e.g., scheduled/periodic
occurrence, group joining of a new member, group leaving of a
current member).
- A description of the group rekeying operations performed (e.g.,
a list of steps performed throughout the rekeying process).
- The outcome of the group rekeying instance.
Tiloca & Palombini Expires 16 September 2026 [Page 85]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- In case of success, the version number of the newly established
group keying material and the newly established Group
Identifier (Gid).
* The addition of a group member to the group or the eviction of a
group member from the group.
The logged information also contains relevant metadata about the
Client that has been added to or removed from the group. For
instance, possible metadata include: addressing information of the
Client; when applicable, the OSCORE Sender ID that is currently
(was latest) assigned to the Client added to (removed from) the
group; when applicable, (an identifier of) the authentication
credential of the Client added to or removed from the group (i.e.,
that the Client uses in the group or has used to authenticate
itself to the Group Manager when establishing their secure
communication association).
* The creation, (re-)configuration, or termination of a group.
In addition to what is compiled above, the Group Manager could log
additional information. Further details about what the Group Manager
logs, with what granularity, and based on what triggering events and
conditions are application-specific and left to operators to define.
The Group Manager MUST NOT log any secret or confidential information
pertaining to a group, such as:
* The OSCORE Master Secret used in the group.
* The symmetric keying material derived from the OSCORE Master
Secret and used in the group, i.e., the Sender/Recipient Keys.
* The Signature Encryption Key used in the group, if the group uses
the group mode.
* The private key associated with the Group Manager’s authentication
credential used in the group.
* Rekeying messages that are exchanged in the group.
* If applicable, administrative keying material used to protect the
group rekeying process.
Tiloca & Palombini Expires 16 September 2026 [Page 86]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
It is up to the application to specify for how long a log entry is
retained from the time of its creation and until its deletion.
Different retention policies could be enforced for different groups.
For a given group, the oldest log entries are expected to be those
deleted first, and different retention policies could be enforced
depending on whether the group currently exists or has been deleted.
It is out of the scope of this document what specific semantics and
data model are used by the Group Manager for producing and processing
the logs. Specific semantics and data models can be defined by
applications and future specifications.
The Group Manager is expected to make the logs that it produces
available for secure access by authorized external management
applications and operators.
In particular, logged information could be retrieved in the following
ways.
* By accessing logs at the Group Manager through polling. This can
occur in an occasional, regular, or event-driven way.
* Through notifications sent by the Group Manager according to an
operator-defined frequency.
* Through notifications asynchronously sent by the Group Manager,
throttling them in order to prevent congestion and duplication and
to not create attack vectors.
Some of the logged information can be privacy-sensitive. This
especially holds for the metadata about a Client, i.e., addressing
information of the Client and, when applicable, (an identifier of)
the authentication credential of the Client (i.e., that the Client
uses in the group or has used to authenticate itself to the Group
Manager when establishing their secure communication association).
If external management applications and operators obtain such
metadata, they become able to track a given Client, as to its
interactions with one or multiple Group Managers and its membership
in groups under such Group Manager(s).
Tiloca & Palombini Expires 16 September 2026 [Page 87]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Therefore, the logged information that is effectively provided to
external management applications and operators SHOULD be redacted by
the Group Manager, by omitting any privacy-sensitive information
element that could enable or facilitate the impairment of Clients'
privacy, e.g., by tracking Clients across different groups and
different Group Managers. Exceptions could apply, e.g., if the Group
Manager can verify that the management application or operator in
question is specifically authorized to obtain such privacy-sensitive
information and appropriately entitled to obtain it according to
enforced privacy policies.
15.2. Administration of Groups
With respect to the creation, (re-)configuration, or termination of a
group at the Group Manager, the following applies:
* Default values for the group configuration parameters are
specified in Section 14.
* The specific method, tools, and data model used to create,
(re-)configure, and delete OSCORE groups are out of the scope of
this document.
A possible method relies on the RESTful admin interface specified
in [I-D.ietf-ace-oscore-gm-admin], which also uses the ACE
framework for Authentication and Authorization [RFC9200] and its
transport profiles. Also, it relies on a data model based on CBOR
and thus enables multiple administrators to perform administrative
operations at the same Group Manager in an interoperable way.
15.3. Access Control
Building on the ACE framework [RFC9200] and the foundation provided
in [RFC9594], this application profile enforces access control for
Clients that interact with the interface at the Group Manager
specified in this document.
In particular, the granularity of such access control takes into
account the resource specifically targeted at the Group Manager, the
operation requested by sending a request to that resource, and the
specific role(s) that the requesting Client is authorized to have
according to its corresponding access token.
Furthermore, the interactions between a Client and the Group Manager
are secured as per the specific transport profile of ACE used (e.g.,
[RFC9202] and [RFC9203]).
Tiloca & Palombini Expires 16 September 2026 [Page 88]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
16. Security Considerations
Security considerations for this profile are inherited from
[RFC9594], the ACE framework for Authentication and Authorization
[RFC9200], and the specific transport profile of ACE signaled by the
AS, such as [RFC9202] and [RFC9203].
The following security considerations also apply for this profile.
16.1. Management of OSCORE Groups
This profile leverages the following management aspects related to
OSCORE groups and discussed in the sections of
[I-D.ietf-core-oscore-groupcomm] referred below.
* Management of group keying material (see Section 12.2 of
[I-D.ietf-core-oscore-groupcomm]). The Group Manager is
responsible for the renewal and re-distribution of the keying
material in the groups of its competence (rekeying).
As defined in Section 7, the Group Manager performs a rekeying
when one or more members leave the group, thus preserving forward
security and ensuring that the security properties of Group OSCORE
are fulfilled. According to the specific application
requirements, the Group Manager can also rekey the group upon a
new node's joining, if backward security has also to be preserved.
The Group Manager can also rekey the group for further reasons,
e.g., according to an application-specific rekeying period or
scheduling.
* Provisioning and retrieval of authentication credentials (see
Section 12 of [I-D.ietf-core-oscore-groupcomm]). The Group
Manager acts as repository of authentication credentials of group
members, and provides them upon request.
* Freshness of messages (see Section 5.2 of
[I-D.ietf-core-oscore-groupcomm]). This concerns how a recipient
node can verify freshness of messages received within the group.
Before sending the Join Response, the Group Manager MUST verify that
the joining node actually owns the associated private key. To this
end, the Group Manager relies on the proof-of-possession challenge-
response defined in Section 6.
A node may have joined multiple OSCORE groups under different non-
synchronized Group Managers. Therefore, it can happen that those
OSCORE groups have the same Group Identifier (Gid). It follows that,
upon receiving a Group OSCORE message addressed to one of those
Tiloca & Palombini Expires 16 September 2026 [Page 89]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
groups, the node would have multiple Security Contexts matching with
the Gid in the incoming message. It is up to the application to
decide how to handle such collisions of Group Identifiers, e.g., by
trying to process the incoming message using one Security Context at
the time until the right one is found (i.e., the incoming message is
successfully decrypted and verified).
16.2. Size of Proof-of-Possesion Challenges
With reference to the Join Request message in Section 6.1, the proof-
of-possession (PoP) evidence included in 'client_cred_verify' is
computed over an input including also N_C | N_S, where | denotes
concatenation.
As to the N_C value, it is RECOMMENDED to be at least 8 bytes long
and it is RECOMMENDED to be a random value. Furthermore, N_C is
always conveyed in the 'cnonce' parameter of the Join Request, which
is always sent over the secure communication association between the
joining node and the Group Manager.
As defined in Section 6.1.1, the way the N_S value is computed
depends on the particular way the joining node provides the Group
Manager with the access token, as well as on following interactions
between the two.
* If the access token has not been provided to the Group Manager by
means of a Token Transfer Request to the /authz-info endpoint as
in Section 5.3, then N_S is computed as a 32 bytes long challenge.
For an example, see points (2) and (3) in Section 6.1.1.
* If the access token has been provided to the Group Manager by
means of a Token Transfer Request to the /authz-info endpoint as
in Section 5.3, then N_S takes the most recent value provided to
the Client by the Group Manager in the 'kdcchallenge' parameter,
as specified in point (1) of Section 6.1.1. This value is
provided either in the Token Transfer Response (see Section 5.3),
or in a 4.00 (Bad Request) error response to a following Join
Request (see Section 6.2). The N_S value is RECOMMENDED to be at
least 8 bytes long and it is RECOMMENDED to be a random value.
If we consider both N_C and N_S to take 8-byte random values, the
following considerations hold.
* Let us consider the case where the Group Manager never changes the
value of the N_S provided to a Client during the lifetime of an
access token. Then, as per the birthday paradox, the average
collision for N_S will happen after 2^32 new transferred access
tokens, while the average collision for N_C will happen after 2^32
Tiloca & Palombini Expires 16 September 2026 [Page 90]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
new Join Requests. This amounts to considerably more token
provisionings than the expected new joinings to OSCORE groups
under a same Group Manager, as well as to considerably more
requests to join OSCORE groups from a same Client using a same
access token under a same Group Manager.
* Section 7 of [RFC9203] and Appendix B.2 of [RFC8613] recommend the
use of 8-byte random values as well. Unlike in those cases, the
values of N_C and N_S considered in this document are not used for
as sensitive operations as the derivation of a Security Context,
and thus do not have possible implications in the security of AEAD
ciphers.
16.3. Reuse of Challenges for Proof-of-Possession Input
When a party A provides a challenge to the other party B, it is
beneficial that A does not offer a challenge previously used with B.
By doing so, A can verify the freshness of the PoP evidence computed
by B.
This is practically ensured if parties generate fresh challenges as
recommended in this document. If a party generates challenges that
are not random values (e.g., by using a counter), the party ought to
ensure that generated values were not used before with the other
party, even in case of reboot and loss of state.
As long as the Group Manager preserves the same N_S value currently
associated with an access token, i.e., the latest value provided to a
Client in a 'kdcchallenge' parameter or computed by other coordinated
means (e.g., see Section 6.1.1), the Client is able to successfully
reuse the same proof-of-possession (PoP) input for multiple Join
Requests to that Group Manager.
In particular, a misbehaving Client can reuse the same N_C value for
every Join Request to the Group Manager, and combine it with the same
unchanged N_S value. This results in reusing the same PoP input for
producing the PoP evidence to include in the 'client_cred_verify'
parameter of the Join Requests.
In such a case, the Group Manager would still attempt to verify the
PoP evidence in the 'client_cred_verify' parameter. However, the
Group Manager will then use the same unchanged N_C value when
preparing the following Join Response, as a challenge for computing
the PoP evidence to prove the possession of its own private key,
which would ultimately be against the Client's interest of freshness.
Tiloca & Palombini Expires 16 September 2026 [Page 91]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
17. IANA Considerations
This document has the following actions for IANA.
Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
with the RFC number of this specification and delete this paragraph.
17.1. OAuth Parameters
IANA is asked to register the following entries in the "OAuth
Parameters" registry [OAuth.Parameters] within the "OAuth Parameters"
registry group, following the procedure specified in Section 11.2 of
[RFC6749].
* Entry #1
- Name: ecdh_info
- Parameter Usage Location: client-rs request, rs-client response
- Change Controller: IETF
- Reference: [RFC-XXXX]
* Entry #2
- Name: kdc_dh_creds
- Parameter Usage Location: client-rs request, rs-client response
- Change Controller: IETF
- Reference: [RFC-XXXX]
17.2. OAuth Parameters CBOR Mappings
IANA is asked to register the following entries in the "OAuth
Parameters CBOR Mappings" registry [OAuth.CBOR.Mappings] within the
"Authentication and Authorization for Constrained Environments (ACE)"
registry group, following the procedure specified in Section 8.10 of
[RFC9200].
* Entry #1
- Name: ecdh_info
- CBOR Key: 47 (suggested)
Tiloca & Palombini Expires 16 September 2026 [Page 92]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- Value Type: Null or array
- Reference: [RFC-XXXX]
- Original Specification: [RFC-XXXX]
* Entry #2
- Name: kdc_dh_creds
- CBOR Key: 48 (suggested)
- Value Type: Null or array
- Reference: [RFC-XXXX]
- Original Specification: [RFC-XXXX]
17.3. ACE Groupcomm Parameters
IANA is asked to register the following entries to the "ACE Groupcomm
Parameters" registry [ACE.Groupcomm.Parameters] within the
"Authentication and Authorization for Constrained Environments (ACE)"
registry group.
* Entry #1
- Name: group_senderId
- CBOR Key: 21 (suggested)
- CBOR Type: bstr
- Reference: [RFC-XXXX]
* Entry #2
- Name: ecdh_info
- CBOR Key: 31 (suggested)
- CBOR Type: array
- Reference: [RFC-XXXX]
* Entry #3
- Name: kdc_dh_creds
Tiloca & Palombini Expires 16 September 2026 [Page 93]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- CBOR Key: 32 (suggested)
- CBOR Type: array
- Reference: [RFC-XXXX]
* Entry #4
- Name: sign_enc_key
- CBOR Key: 33 (suggested)
- CBOR Type: bstr
- Reference: [RFC-XXXX]
* Entry #5
- Name: stale_node_ids
- CBOR Key: 34 (suggested)
- CBOR Type: array
- Reference: [RFC-XXXX]
17.4. ACE Groupcomm Key Types
IANA is asked to register the following entry in the "ACE Groupcomm
Key Types" registry [ACE.Groupcomm.Key.Types] within the
"Authentication and Authorization for Constrained Environments (ACE)"
registry group.
* Name: Group_OSCORE_Input_Material object
* Key Type Value: GROUPCOMM_KEY_TBD (suggested value: 1)
* Profile: "coap_group_oscore_app", registered in Section 17.5 of
[RFC-XXXX].
* Description: A Group_OSCORE_Input_Material object encoded as
described in Section 6.3 of [RFC-XXXX].
* Reference: [RFC-XXXX]
Tiloca & Palombini Expires 16 September 2026 [Page 94]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
17.5. ACE Groupcomm Profiles
IANA is asked to register the following entry in the "ACE Groupcomm
Profiles" registry [ACE.Groupcomm.Profiles] within the
"Authentication and Authorization for Constrained Environments (ACE)"
registry group.
* Name: coap_group_oscore_app
* Description: Application profile to provision keying material for
participating in group communication protected with Group OSCORE
as per [I-D.ietf-core-oscore-groupcomm].
* CBOR Value: PROFILE_TBD (suggested value: 1)
* Reference: [RFC-XXXX]
17.6. OSCORE Security Context Parameters
IANA is asked to register the following entries in the "OSCORE
Security Context Parameters" registry [OSCORE.Sec.Ctx.Parameters]
within the "Authentication and Authorization for Constrained
Environments (ACE)" registry group.
* Entry #1
- Name: group_SenderId
- CBOR Label: 7 (suggested)
- CBOR Type: byte string
- Registry: -
- Description: OSCORE Sender ID assigned to a member of an OSCORE
group
- Reference: [RFC-XXXX]
* Entry #2
- Name: cred_fmt
- CBOR Label: 8 (suggested)
- CBOR Type: integer
- Registry: [COSE.Header.Parameters] Labels (integer)
Tiloca & Palombini Expires 16 September 2026 [Page 95]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- Description: Format of authentication credentials to be used in
the OSCORE group
- Reference: [RFC-XXXX]
* Entry #3
- Name: gp_enc_alg
- CBOR Label: 9 (suggested)
- CBOR Type: text string / integer
- Registry: [COSE.Algorithms] Values
- Description: OSCORE Group Encryption Algorithm Value
- Reference: [RFC-XXXX]
* Entry #4
- Name: sign_alg
- CBOR Label: 10 (suggested)
- CBOR Type: text string / integer
- Registry: [COSE.Algorithms] Values
- Description: OSCORE Signature Algorithm Value
- Reference: [RFC-XXXX]
* Entry #5
- Name: sign_params
- CBOR Label: 11 (suggested)
- CBOR Type: array
- Registry: [COSE.Algorithms] Capabilities, [COSE.Key.Types]
Capabilities, [COSE.Elliptic.Curves] Values
- Description: OSCORE Signature Algorithm Parameters
- Reference: [RFC-XXXX]
Tiloca & Palombini Expires 16 September 2026 [Page 96]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* Entry #6
- Name: ecdh_alg
- CBOR Label: 12 (suggested)
- CBOR Type: text string / integer
- Registry: [COSE.Algorithms] Values
- Description: OSCORE Pairwise Key Agreement Algorithm Value
- Reference: [RFC-XXXX]
* Entry #7
- Name: ecdh_params
- CBOR Label: 13 (suggested)
- CBOR Type: array
- Registry: [COSE.Algorithms] Capabilities, [COSE.Key.Types]
Capabilities, [COSE.Elliptic.Curves] Values
- Description: OSCORE Pairwise Key Agreement Algorithm Parameters
- Reference: [RFC-XXXX]
17.7. TLS Exporter Labels
IANA is asked to register the following entry in the "TLS Exporter
Labels" registry [TLS.Exporter.Labels] within the "Transport Layer
Security (TLS) Parameters" registry group, which is defined in
Section 6 of [RFC5705] and updated in Section 12 of [RFC8447].
* Value: EXPORTER-ACE-Pop-Input-coap-group-oscore-app
* DTLS-OK: Y
* Recommended: N
* Reference: [RFC-XXXX]
Tiloca & Palombini Expires 16 September 2026 [Page 97]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
17.8. AIF Media-Type Sub-Parameters
For the media-types "application/aif+cbor" and "application/aif+json"
defined in Section 5.1 of [RFC9237], IANA is requested to register
the following entries for the two media-type parameters Toid and
Tperm, in the respective sub-registry defined in Section 5.2 of
[RFC9237] within the "MIME Media Type Sub-Parameter" registry group.
* Entry #1
- Parameter: Toid
- Name: oscore-gname
- Description/Specification: OSCORE group name
- Reference: [RFC-XXXX]
* Entry #2
- Parameter: Tperm
- Name: oscore-gperm
- Description/Specification: permissions pertaining OSCORE groups
- Reference: [RFC-XXXX]
17.9. CoAP Content-Formats
IANA is asked to register the following entries in the "CoAP Content-
Formats" registry [CoAP.Content.Formats] within the "Constrained
RESTful Environments (CoRE) Parameters" registry group.
* Entry #1
- Content Type: application/aif+cbor;toid=oscore-
gname;tperm=oscore-gperm
- Content Coding: -
- ID: 295 (suggested)
- Reference: [RFC-XXXX]
* Entry #2
Tiloca & Palombini Expires 16 September 2026 [Page 98]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- Content Type: application/aif+json;toid=oscore-
gname;tperm=oscore-gperm
- Content Coding: -
- ID: 296 (suggested)
- Reference: [RFC-XXXX]
17.10. CoRE Resource Type
IANA is asked to register the following entry in the "Resource Type
(rt=) Link Target Attribute Values" registry [Resource.Type.Values]
within the "Constrained Restful Environments (CoRE) Parameters"
registry group.
* Value: "core.osc.gm"
* Description: Group-membership resource of an OSCORE Group Manager.
* Reference: [RFC-XXXX]
Client applications can use this resource type to discover a group-
membership resource at an OSCORE Group Manager, where to send a
request for joining the corresponding OSCORE group.
17.11. ACE Groupcomm Errors
IANA is asked to register the following entries in the "ACE Groupcomm
Errors" registry [ACE.Groupcomm.Errors] within the "Authentication
and Authorization for Constrained Environments (ACE)" registry group.
* Entry #1
- Value: 7 (suggested)
- Description: Signatures not used in the group.
- Reference: [RFC-XXXX]
* Entry #2
- Value: 8 (suggested)
- Description: Operation permitted only to signature verifiers.
- Reference: [RFC-XXXX]
Tiloca & Palombini Expires 16 September 2026 [Page 99]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* Entry #3
- Value: 9 (suggested)
- Description: Group currently not active.
- Reference: [RFC-XXXX]
17.12. Group OSCORE Roles
This document establishes the IANA "Group OSCORE Roles" registry,
within the "Authentication and Authorization for Constrained
Environments (ACE)" registry group. The registry has been created to
use the "Expert Review" registration procedure [RFC8126]. Expert
review guidelines are provided in Section 17.13.
This registry includes the possible roles that nodes can take in an
OSCORE group, each in combination with a numeric identifier. These
numeric identifiers are used to express authorization information
about joining OSCORE groups, as specified in Section 3 of [RFC-XXXX].
The columns of this registry are:
* Name: A value that can be used in documents for easier
comprehension, to identify a possible role that nodes can take in
an OSCORE group.
* Value: The numeric identifier for this role. These values MUST be
unique. The value can be an integer greater than or equal to 0.
Integer values greater than 65535 are marked as "Private Use" (see
Section 4.1 of [RFC8126]). All other values use the registration
policy "Expert Review" (see Section 4.5 of [RFC8126]).
* Description: This field contains a brief description of the role.
* Reference: This field contains a pointer to the public
specification for the role, if one exists.
This registry will be initially populated by the values in Table 1.
The Reference column for all of these entries will be [RFC-XXXX].
17.13. Expert Review Instructions
The IANA registry established in this document is defined as "Expert
Review". This section gives some general guidelines for what the
experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude.
Tiloca & Palombini Expires 16 September 2026 [Page 100]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
Expert reviewers should take into consideration the following points:
* Clarity and correctness of registrations. Experts are expected to
check the clarity of purpose and use of the requested entries.
Experts should inspect the entry for the considered role, to
verify the correctness of its description against the role as
intended in the specification that defined it. Experts should
consider requesting an opinion on the correctness of registered
parameters from the Authentication and Authorization for
Constrained Environments (ACE) Working Group and the Constrained
RESTful Environments (CoRE) Working Group.
Entries that do not meet these objectives of clarity and
completeness should not be registered.
* Duplicated registration and point squatting should be discouraged.
Reviewers are encouraged to get sufficient information for
registration requests to ensure that the usage is not going to
duplicate one that is already registered and that the point is
likely to be used in deployments.
* Experts should take into account the expected usage of roles when
approving point assignments. Given a 'Value' V as code point, the
length of the encoding of (2^(V+1) - 1) should be weighed against
the usage of the entry, considering the resources and capabilities
of devices it will be used on. Additionally, given a 'Value' V as
code point, the length of the encoding of (2^(V+1) - 1) should be
weighed against how many code points resulting in that encoding
length are left, and the resources and capabilities of devices it
will be used on.
* Specifications are recommended. When specifications are not
provided, the description provided needs to have sufficient
information to verify the points above.
18. References
18.1. Normative References
[ACE.Groupcomm.Errors]
IANA, "ACE Groupcomm Errors",
<https://www.iana.org/assignments/ace/ace.xhtml#ace-
groupcomm-errors>.
[ACE.Groupcomm.Key.Types]
IANA, "ACE Groupcomm Key Types",
<https://www.iana.org/assignments/ace/ace.xhtml#ace-
groupcomm-key-types>.
Tiloca & Palombini Expires 16 September 2026 [Page 101]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
[ACE.Groupcomm.Parameters]
IANA, "ACE Groupcomm Parameters",
<https://www.iana.org/assignments/ace/ace.xhtml#ace-
groupcomm-parameters>.
[ACE.Groupcomm.Profiles]
IANA, "ACE Groupcomm Profiles",
<https://www.iana.org/assignments/ace/ace.xhtml#ace-
groupcomm-profiles>.
[CoAP.Content.Formats]
IANA, "CoAP Content-Formats",
<https://www.iana.org/assignments/core-parameters/core-
parameters.xhtml#content-formats>.
[COSE.Algorithms]
IANA, "COSE Algorithms",
<https://www.iana.org/assignments/cose/
cose.xhtml#algorithms>.
[COSE.Elliptic.Curves]
IANA, "COSE Elliptic Curves",
<https://www.iana.org/assignments/cose/
cose.xhtml#elliptic-curves>.
[COSE.Header.Parameters]
IANA, "COSE Header Parameters",
<https://www.iana.org/assignments/cose/cose.xhtml#header-
parameters>.
[COSE.Key.Types]
IANA, "COSE Key Types",
<https://www.iana.org/assignments/cose/cose.xhtml#key-
type>.
[I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
and R. Höglund, "Group Object Security for Constrained
RESTful Environments (Group OSCORE)", Work in Progress,
Internet-Draft, draft-ietf-core-oscore-groupcomm-28, 23
December 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-oscore-groupcomm-28>.
Tiloca & Palombini Expires 16 September 2026 [Page 102]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
[NIST-800-56A]
Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
Davis, "Recommendation for Pair-Wise Key-Establishment
Schemes Using Discrete Logarithm Cryptography - NIST
Special Publication 800-56A, Revision 3", April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Ar3.pdf>.
[OAuth.CBOR.Mappings]
IANA, "OAuth Parameters CBOR Mappings",
<https://www.iana.org/assignments/ace/ace.xhtml#oauth-
parameters-cbor-mappings>.
[OAuth.Parameters]
IANA, "OAuth Parameters",
<https://www.iana.org/assignments/oauth-parameters/oauth-
parameters.xhtml#parameters>.
[OSCORE.Sec.Ctx.Parameters]
IANA, "OSCORE Security Context Parameters",
<https://www.iana.org/assignments/ace/ace.xhtml#oscore-
security-context-parameters>.
[Resource.Type.Values]
IANA, "Resource Type (rt=) Link Target Attribute Values",
<https://www.iana.org/assignments/core-parameters/core-
parameters.xhtml#rt-link-target-att-value>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/rfc/rfc5246>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/rfc/rfc5705>.
Tiloca & Palombini Expires 16 September 2026 [Page 103]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/rfc/rfc6347>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/rfc/rfc6979>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/rfc/rfc7641>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/rfc/rfc7748>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/rfc/rfc8017>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
Tiloca & Palombini Expires 16 September 2026 [Page 104]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/rfc/rfc8447>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/rfc/rfc8613>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/rfc/rfc9147>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/rfc/rfc9200>.
[RFC9202] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for
Constrained Environments (ACE)", RFC 9202,
DOI 10.17487/RFC9202, August 2022,
<https://www.rfc-editor.org/rfc/rfc9202>.
Tiloca & Palombini Expires 16 September 2026 [Page 105]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
[RFC9203] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"The Object Security for Constrained RESTful Environments
(OSCORE) Profile of the Authentication and Authorization
for Constrained Environments (ACE) Framework", RFC 9203,
DOI 10.17487/RFC9203, August 2022,
<https://www.rfc-editor.org/rfc/rfc9203>.
[RFC9237] Bormann, C., "An Authorization Information Format (AIF)
for Authentication and Authorization for Constrained
Environments (ACE)", RFC 9237, DOI 10.17487/RFC9237,
August 2022, <https://www.rfc-editor.org/rfc/rfc9237>.
[RFC9277] Richardson, M. and C. Bormann, "On Stable Storage for
Items in Concise Binary Object Representation (CBOR)",
RFC 9277, DOI 10.17487/RFC9277, August 2022,
<https://www.rfc-editor.org/rfc/rfc9277>.
[RFC9290] Fossati, T. and C. Bormann, "Concise Problem Details for
Constrained Application Protocol (CoAP) APIs", RFC 9290,
DOI 10.17487/RFC9290, October 2022,
<https://www.rfc-editor.org/rfc/rfc9290>.
[RFC9430] Bergmann, O., Preuß Mattsson, J., and G. Selander,
"Extension of the Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for
Constrained Environments (ACE) to Transport Layer Security
(TLS)", RFC 9430, DOI 10.17487/RFC9430, July 2023,
<https://www.rfc-editor.org/rfc/rfc9430>.
[RFC9594] Palombini, F. and M. Tiloca, "Key Provisioning for Group
Communication Using Authentication and Authorization for
Constrained Environments (ACE)", RFC 9594,
DOI 10.17487/RFC9594, September 2024,
<https://www.rfc-editor.org/rfc/rfc9594>.
[TLS.Exporter.Labels]
IANA, "TLS Exporter Labels",
<https://www.iana.org/assignments/tls-parameters/tls-
parameters.xhtml#exporter-labels>.
18.2. Informative References
Tiloca & Palombini Expires 16 September 2026 [Page 106]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
[I-D.ietf-ace-oscore-gm-admin]
Tiloca, M., Höglund, R., Van der Stok, P., and F.
Palombini, "Admin Interface for the OSCORE Group Manager",
Work in Progress, Internet-Draft, draft-ietf-ace-oscore-
gm-admin-16, 12 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ace-
oscore-gm-admin-16>.
[I-D.ietf-core-coap-pubsub]
Jimenez, J., Koster, M., and A. Keränen, "A publish-
subscribe architecture for the Constrained Application
Protocol (CoAP)", Work in Progress, Internet-Draft, draft-
ietf-core-coap-pubsub-19, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
coap-pubsub-19>.
[I-D.ietf-core-groupcomm-bis]
Dijk, E. and M. Tiloca, "Group Communication for the
Constrained Application Protocol (CoAP)", Work in
Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
18, 10 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
groupcomm-bis-18>.
[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-17, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
cbor-encoded-cert-17>.
[I-D.tiloca-core-oscore-discovery]
Tiloca, M., Amsüss, C., and P. Van der Stok, "Discovery of
OSCORE Groups with the CoRE Resource Directory", Work in
Progress, Internet-Draft, draft-tiloca-core-oscore-
discovery-19, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-tiloca-core-
oscore-discovery-19>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
Tiloca & Palombini Expires 16 September 2026 [Page 107]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/rfc/rfc6690>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.
Appendix A. Profile Requirements
This section lists how this application profile of ACE addresses the
requirements defined in Appendix A of [RFC9594].
A.1. Mandatory-to-Address Requirements
* REQ1: Specify the format and encoding of scope. This includes
defining the set of possible roles and their identifiers, as well
as the corresponding encoding to use in the scope entries
according to the used scope format: see Section 3 and Section 5.1.
* REQ2: If scope uses AIF, register its specific instance of "Toid"
and "Tperm" as media type parameters and a corresponding Content-
Format, as per the guidelines in [RFC9237]: see Section 17.8 and
Section 17.9.
* REQ3: If used, specify the acceptable values for the 'sign_alg'
parameter: values from the "Value" column of the "COSE Algorithms"
registry [COSE.Algorithms].
* REQ4: If used, specify the acceptable values and structure for the
'sign_parameters' parameter: values and structure from the COSE
algorithm capabilities as specified in the "COSE Algorithms"
registry [COSE.Algorithms].
* REQ5: If used, specify the acceptable values and structure for the
'sign_key_parameters' parameter: values and structure from the
COSE key type capabilities as specified in the "COSE Key Types"
registry [COSE.Key.Types].
Tiloca & Palombini Expires 16 September 2026 [Page 108]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* REQ6: Specify the acceptable formats for authentication
credentials and, if applicable, the acceptable values for the
'cred_fmt' parameter: acceptable formats explicitly provide the
public key as well as the comprehensive set of information related
to the public key algorithm (see Section 5.3 and Section 6.3).
Consistent acceptable values for 'cred_fmt' are taken from the
"Label" column of the "COSE Header Parameters" registry
[COSE.Header.Parameters], with some of those values also
indicating the type of container to use for exchanging the
authentication credentials with the Group Manager (e.g., a chain
or bag of certificates).
* REQ7: If the value of the GROUPNAME URI path and the group name in
the access token scope ('gname') are not required to coincide,
specify the mechanism to map the GROUPNAME value in the URI to the
group name: not applicable, since a perfect matching is required.
* REQ8: Define whether the KDC has an authentication credential as
required for the correct group operation and if this has to be
provided through the 'kdc_cred' parameter: yes, as required by the
Group OSCORE protocol [I-D.ietf-core-oscore-groupcomm], see
Section 6.3 of this document.
* REQ9: Specify if any part of the KDC interface as defined in
[RFC9594] is not supported by the KDC: not applicable.
* REQ10: Register a Resource Type for the group-membership
resources, which is used to discover the correct URL for sending a
Join Request to the KDC: the Resource Type (rt=) Link Target
Attribute value "core.osc.gm" is registered in Section 17.10.
* REQ11: Define what specific actions (e.g., CoAP methods) are
allowed on each resource accessible through the KDC interface,
depending on: whether the Client is a current group member; the
roles that a Client is authorized to take as per the obtained
access token; and the roles that the Client has as a current group
member: see Section 8.5.
* REQ12: Categorize possible newly defined operations for Clients
into primary operations expected to be minimally supported and
secondary operations, and provide accompanying considerations: see
Section 8.6.
* REQ13: Specify the encoding of group identifiers: CBOR byte string
(see Section 9.10).
Tiloca & Palombini Expires 16 September 2026 [Page 109]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* REQ14: Specify the approaches used to compute and verify the PoP
evidence to include in the 'client_cred_verify' parameter and
which of those approaches is used in which case: see Section 6.1
and Section 6.2.
* REQ15: Specify how N_S is generated, if the access token is not
provided to the KDC through the Token Transfer Request sent to the
/authz-info endpoint (e.g., the access token is instead
transferred during the establishment of a secure communication
association): see Section 6.1.1.
* REQ16: Define the initial value of the version number for the
group keying material: the initial value MUST be set to 0 when
creating the OSCORE group, e.g., as in
[I-D.ietf-ace-oscore-gm-admin].
* REQ17: Specify the format of the group keying material that is
conveyed in the 'key' parameter: see Section 6.3.
* REQ18: Specify the acceptable values of the 'gkty' parameter. For
each of them, register a corresponding entry in the "ACE Groupcomm
Key Types" IANA registry if such an entry does not exist already:
Group_OSCORE_Input_Material object (see Section 6.3).
* REQ19: Specify and register the application profile identifier:
coap_group_oscore_app (see Section 17.5).
* REQ20: If used, specify the format and default values of the
entries of the CBOR map to include in the 'group_policies'
parameter: see Section 6.3.
* REQ21: Specify the approaches used to compute and verify the PoP
evidence to include in the 'kdc_cred_verify' parameter and which
of those approaches is used in which case. If external signature
verifiers are supported, specify how those provide a nonce to the
KDC to be used for computing the PoP evidence: see Section 6.3,
Section 6.4 and Section 9.5.2.
* REQ22: Specify the communication protocol that members of the
group use to communicate with each other (e.g., CoAP for group
communication): CoAP [RFC7252], also for group communication
[I-D.ietf-core-groupcomm-bis].
* REQ23: Specify the security protocol that members of the group use
to protect the group communication (e.g., Group OSCORE). This
must provide encryption, integrity, and replay protection: Group
OSCORE [I-D.ietf-core-oscore-groupcomm].
Tiloca & Palombini Expires 16 September 2026 [Page 110]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* REQ24: Specify how the communication is secured between the Client
and the KDC. Optionally, specify a transport profile of ACE
[RFC9200] to use between the Client and the KDC: by means of any
transport profile of ACE [RFC9200] between Client and Group
Manager that complies with the requirements in Appendix C of
[RFC9200].
* REQ25: Specify the format of the node identifiers of group
members: the Sender ID used in the OSCORE group (see Section 6.3
and Section 9.3).
* REQ26: Specify policies at the KDC to handle node identifiers that
are included in the 'get_creds' parameter but are not associated
with any current group member: see Section 9.3.
* REQ27: Specify the format of (newly generated) individual keying
material for group members or of the information to derive such
keying material, as well as the corresponding CBOR map key that
has to be registered in the "ACE Groupcomm Parameters" registry:
see Section 9.2.
* REQ28: Specify which CBOR tag is used for identifying the
semantics of binary scopes, or register a new CBOR tag if a
suitable one does not exist already: see Section 5.2.
* REQ29: Categorize newly defined parameters according to the same
criteria of Section 8 of [RFC9594]: see Section 12.
* REQ30: Define whether Clients must, should, or may support the
conditional parameters defined in Section 8 of [RFC9594] and under
which circumstances: see Section 12.
A.2. Optional-to-Address Requirements
* OPT1: Optionally, if the textual format of scope is used, specify
CBOR values to use for abbreviating the role identifiers in the
group: not applicable.
* OPT2: Optionally, specify the additional parameters used in the
exchange of Token Transfer Request and Response:
- 'ecdh_info', to negotiate the ECDH algorithm, ECDH algorithm
parameters, ECDH key parameters, and exact format of
authentication credentials used in the group, in the case that
the joining node supports the pairwise mode of Group OSCORE
(see Section 5.3).
Tiloca & Palombini Expires 16 September 2026 [Page 111]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- 'kdc_dh_creds', to ask for and retrieve the Group Manager's
Diffie-Hellman authentication credentials, in the case that the
joining node supports the pairwise mode of Group OSCORE and the
access token authorizes to join pairwise-only groups (see
Section 5.3).
* OPT3: Optionally, specify the negotiation of parameter values for
signature algorithm and signature keys, if the 'sign_info'
parameter is not used: possible early discovery by using the
approach based on the CoRE Resource Directory and described in
[I-D.tiloca-core-oscore-discovery].
* OPT4: Optionally, specify possible or required payload formats for
specific error cases: send a 4.00 (Bad Request) error response to
a Join Request (see Section 6.2).
* OPT5: Optionally, specify additional identifiers of error types as
values of the 'error-id' field within the Custom Problem Detail
entry 'ace-groupcomm-error': see Section 13 and Section 17.11.
* OPT6: Optionally, specify the encoding of the 'creds_repo'
parameter if the default one is not used: no encoding is defined.
* OPT7: Optionally, specify the functionalities implemented at the
resource hosted by the Client at the URI indicated in the
'control_uri' parameter, including the encoding of exchanged
messages and other details: see Section 10 for the eviction of a
group member; see Section 11 for the group rekeying process.
* OPT8: Optionally, specify the behavior of the POST handler of
group-membership resources, for the case when it fails to retrieve
an authentication credential for the specific Client: send a 4.00
(Bad Request) error response to a Join Request (see Section 6.2).
* OPT9: Optionally, define a default group rekeying scheme to refer
to in case the 'rekeying_scheme' parameter is not included in the
Join Response: the "Point-to-Point" rekeying scheme registered in
Section 11.13 of [RFC9594], whose detailed use for this profile is
defined in Section 11 of this document.
* OPT10: Optionally, specify the functionalities implemented at the
resource hosted by the Client at the URI indicated in the
'control_group_uri' parameter, including the encoding of exchanged
messages and other details: see Section 10 for the eviction of
multiple group members.
Tiloca & Palombini Expires 16 September 2026 [Page 112]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* OPT11: Optionally, specify policies that instruct Clients to
retain messages and for how long, if those are unsuccessfully
decrypted: no such policies are specified.
* OPT12: Optionally, specify for the KDC to perform a group rekeying
when receiving a Key Renewal Request, together with or instead of
renewing individual keying material: the Group Manager SHOULD
perform a group rekeying if one is already scheduled to occur
within an acceptably short time frame, otherwise it SHOULD NOT
(see Section 9.2).
* OPT13: Optionally, specify how the identifier of a group member's
authentication credential is included in requests sent to other
group members: no such method is defined.
* OPT14: Optionally, specify additional information to include in
rekeying messages for the "Point-to-Point" group rekeying scheme
(see Section 6 of [RFC9594]): see Section 11.1.
Appendix B. Extensibility for Future COSE Algorithms
As defined in Section 8.1 of [RFC9053], future algorithms can be
registered in the "COSE Algorithms" registry [COSE.Algorithms] as
specifying none or multiple COSE capabilities.
To enable the seamless use of such future registered algorithms, this
section defines a general, agile format for:
* Each 'ecdh_info_entry' of the 'ecdh_info' parameter in the Token
Transfer Response (see Section 5.3.1).
Appendix B of [RFC9594] describes the analogous general format for
each 'sign_info_entry' of the 'sign_info' parameter in the Token
Transfer Response (see Section 5.3 of this document).
* The 'sign_params' and 'ecdh_params' parameters within the 'key'
parameter (see Section 6.3), as part of the response payloads used
in Section 6.3, Section 9.1.1, Section 9.1.2, and Section 11.
If any of the currently registered COSE algorithms is considered,
using this general format yields the same structure defined in this
document for the items above, thus ensuring backward compatibility.
B.1. Format of 'ecdh_info_entry'
The format of each 'ecdh_info_entry' (see Section 5.3 and
Section 5.3.1) is generalized as follows.
Tiloca & Palombini Expires 16 September 2026 [Page 113]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* 'ecdh_parameters' includes N >= 0 elements, each of which is a
COSE capability of the ECDH algorithm indicated in 'ecdh_alg'.
In particular, 'ecdh_parameters' has the same format and value of
the COSE capabilities array for the ECDH algorithm indicated in
'ecdh_alg', as specified for that algorithm in the 'Capabilities'
column of the "COSE Algorithms" registry [COSE.Algorithms].
* 'ecdh_key_parameters' is replaced by N elements 'ecdh_capab', each
of which is a CBOR array.
The i-th 'ecdh_capab' array (i = 0, ..., N-1) is the array of COSE
capabilities for the algorithm capability specified in
'ecdh_parameters'[i].
In particular, each 'ecdh_capab' array has the same format and
value of the COSE capabilities array for the algorithm capability
specified in 'ecdh_parameters'[i].
Such a COSE capabilities array is currently defined for the
algorithm capability COSE key type, in the "Capabilities" column
of the "COSE Key Types" registry [COSE.Key.Types].
The CDDL notation [RFC8610] of the 'ecdh_info_entry' parameter is
given below.
ecdh_info_entry =
[
id: gname / [+ gname],
ecdh_alg: int / tstr,
ecdh_parameters : [* ecdh_capab: any],
* ecdh_capab: [* capab: any],
cred_fmt: int / null
]
gname = tstr
Figure 12: 'ecdh_info_entry' with General Format
B.2. Format of 'key'
The format of 'key' (see Section 6.3) is generalized as follows.
* The 'sign_params' array includes N+1 elements, whose exact
structure and value depend on the value of the signature algorithm
specified in 'sign_alg'.
Tiloca & Palombini Expires 16 September 2026 [Page 114]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- The first element, i.e., 'sign_params'[0], is the array of the
N COSE capabilities for the signature algorithm, as specified
for that algorithm in the "Capabilities" column of the "COSE
Algorithms" registry [COSE.Algorithms] (see Section 8.1 of
[RFC9053]).
- Each following element 'sign_params'[i], i.e., with index i >
0, is the array of COSE capabilities for the algorithm
capability specified in 'sign_params'[0][i-1].
For example, if 'sign_params'[0][0] specifies the key type as
capability of the algorithm, then 'sign_params'[1] is the array of
COSE capabilities for the COSE key type associated with the
signature algorithm, as specified for that key type in the
"Capabilities" column of the "COSE Key Types" registry
[COSE.Key.Types] (see Section 8.2 of [RFC9053]).
* The 'ecdh_params' array includes M+1 elements, whose exact
structure and value depend on the value of the ECDH algorithm
specified in 'ecdh_alg'.
- The first element, i.e., 'ecdh_params'[0], is the array of the
M COSE capabilities for the ECDH algorithm, as specified for
that algorithm in the "Capabilities" column of the "COSE
Algorithms" registry [COSE.Algorithms] (see Section 8.1 of
[RFC9053]).
- Each following element 'ecdh_params'[i], i.e., with index i >
0, is the array of COSE capabilities for the algorithm
capability specified in 'ecdh_params'[0][i-1].
For example, if 'ecdh_params'[0][0] specifies the key type as
capability of the algorithm, then 'ecdh_params'[1] is the array of
COSE capabilities for the COSE key type associated with the ECDH
algorithm, as specified for that key type in the "Capabilities"
column of the "COSE Key Types" registry [COSE.Key.Types] (see
Section 8.2 of [RFC9053]).
Appendix C. CDDL Model
This section is to be removed before publishing as an RFC.
Tiloca & Palombini Expires 16 September 2026 [Page 115]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
; ACE Groupcomm Parameters
sign_enc_key = 33
; ACE Groupcomm Key Types
group_oscore_input_material_obj = 1
; ACE Groupcomm Profiles
coap_group_oscore_app = 1
; OSCORE Security Context Parameters
cred_fmt = 8
gp_enc_alg = 9
sign_alg = 10
sign_params = 11
Figure 13: CDDL Model
Appendix D. Document Updates
This section is to be removed before publishing as an RFC.
D.1. Version -20 to -21
* Separate Section 1.2 "Notations".
* Clarified that group names are consistent with the semantics of
URI path segments.
* Removed unnecessary normative language.
* Revised preamble on default values in Section 14:
- Aligned with that in Section 5.2 of draft-ietf-ace-oscore-gm-
admin-16.
- Clearer in terms of recommendations and reasons to deviate.
* Clarifications in the "Operational Considerations" section, also
aligned with draft-ietf-ace-oscore-gm-admin:
- Policies for log retention at the Group Manager.
- Logged authentication credentials are not only those used
within the OSCORE group.
- Editorial improvements.
* IANA considerations
Tiloca & Palombini Expires 16 September 2026 [Page 116]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- Added references to IANA registries.
- More details in the definition of a column in the new IANA
registry.
- Added reference to Section 4.1 of RFC 8126.
* Minor fixes and editorial improvements.
D.2. Version -19 to -20
* More consistent use of the terms "nonce" and "challenge".
* Clarified that a monitor-only group member does not have an
authentication credential in the group.
* Defined possible use of CoAP Observe with /ace-group/GROUPNAME/
active
* Updated suggested values for registrations in the "CoAP Content-
Formats" IANA registry.
* Minor fixes and editorial improvements.
D.3. Version -18 to -19
* Extended introduction: clarified relationships between this
document and related documents.
* Two more terms mentioned upfront in the terminology section.
* Ensured consistency with RFC 9594 when using an optimized Join
Request for re-joining a group if already a member (presence of
the 'client_cred' parameter).
* Mentioned also periodic/scheduled group rekeying in the security
considerations.
* Added the "Operational Considerations" section.
* Clarifications:
- Clearer wording about recommended randomness and size of
nonces.
- Rejection of Ed25519/Ed448 authentication credentials in corner
cases.
Tiloca & Palombini Expires 16 September 2026 [Page 117]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
- Nonce used in a retry Join Request after an error response.
- Secure communications required as per the transport profile of
ACE used.
- Consequences of not including a parameter in two response
messages from the Group Manager.
- Explicitly mentioned the rationale for computing a proof-of-
possession (PoP) evidence.
* IANA considerations:
- Suggested values for two registrations.
- Improved readability of registration requests.
- Definition of the new registry
o Mentioned the registry group including the new registry.
o Specifications are not required for Expert Review and one
might not exist for a registry entry.
- Fixed content types in the CoAP Content-Formats registrations.
* Minor fixes and editorial improvements.
D.4. Version -17 to -18
* Avoid unnecessary normative language.
* Added missing optional check at the Group Manager when receiving a
group member's updated authentication credential.
* Clarified the origin of the latest client's authentication
credential.
* Clarified meaning of the group becoming inactive and active again.
* Clarified usefulness of error responses to the Join Request.
* Clarified relation between a group rekeying and a Key Renewal
Request.
* Clarified checks on requests from a signature verifier.
* Refer to all the REQ and OPT profile requirements.
Tiloca & Palombini Expires 16 September 2026 [Page 118]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* Clarifications and editorial improvements.
D.5. Version -16 to -17
* CBOR diagnostic notation uses placeholders from a CDDL model.
* Fixes in the CDDL definitions.
* Fixes in the examples in CBOR diagnostic notation.
* Updated author list.
* Updated references and section numbers of referred documents.
* Use actual tables.
* Add high-level recap of the concept of scope.
* Fixed name of the error with error code 4.
* Renamed parameters to align with RFC 9594
- "Group Encryption Key" becomes "Signature Encryption Key"
- 'group_enc_key' becomes 'sign_enc_key'
- "Signature Encryption Algorithm" becomes "Group Encryption
Algorithm"
- 'sign_enc_alg' becomes 'gp_enc_alg'
* Added CBOR integer abbreviations for ACE Groupcomm Parameters.
* Considerations on authentication credentials consistent with RFC
9594.
* Revised alternative computing of N_S challenge when DTLS is used.
* Generalized definition of ecdh_info.
* Generalized definition of kdc_dh_creds.
* Clarified maximum size of the OSCORE Sender ID.
* Clarified parameters left "not set" in the Security Context.
* Clarified meaning of 'cred_fmt'.
Tiloca & Palombini Expires 16 September 2026 [Page 119]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* Consistent mandatory use of 'cnonce'.
* Relation between 'cred_fmt' and Authentication Credential Format.
* Implicit PoP evidence of the Client's authentication credential.
* Process of 'client_cred' and 'client_cred_verify' consistent with
RFC 9594.
* GET to ace-group/GROUPNAME/kdc-cred only for group members.
* Added FETCH handler for /ace-group/GROUPNAME/kdc-cred.
* PUT becomes POST for ace-group/GROUPNAME/nodes/NODENAME.
* Fixed error response code from /ace-group/GROUPNAME/nodes/
NODENAME.
* Consistent use of the 'exi' ACE Groupcomm Parameter.
* Use concise problem details (RFC9290) for error responses.
* Revised default values on group configuration parameters.
* Revised future-ready generalization of 'ecdh_info_entry'.
* CCS is used as default format of authentication credential.
* Updated name of TLS exporter label.
* Revised IANA considerations.
* Aligned requirement formulation with that in RFC 9594.
* Use of AASVG in message diagrams.
* Clarifications and editorial fixes.
D.6. Version -15 to -16
* Early mentioning of invalid combinations of roles.
* Revised presentation of handling of stale Sender IDs.
* Fixed CDDL notation.
* Fixed diagnostic notation in examples.
Tiloca & Palombini Expires 16 September 2026 [Page 120]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* Possible reason to deviate from default parameter values.
* Clarifications and editorial fixes.
D.7. Version -14 to -15
* Alignment with renaming in draft-ietf-ace-key-groupcomm.
* Updated signaling of semantics for binary encoded scopes.
* Considered the upload of access tokens in the DTLS 1.3 Handshake.
* Fixes in IANA registrations.
* Editorial fixes.
D.8. Version -13 to -14
* Major reordering of the document sections.
* The HKDF Algorithm is specified by the HMAC Algorithm.
* Group communication does not necessarily use IP multicast.
* Generalized AIF data model, also for draft-ace-oscore-gm-admin.
* Clarifications and editorial improvements.
D.9. Version -12 to -13
* Renamed parameters about authentication credentials.
* It is optional for the Group Manager to reassign Gids by tracking
"Birth Gids".
* Distinction between authentication credentials and public keys.
* Updated IANA considerations related to AIF.
* Updated textual description of registered ACE Scope Semantics
value.
D.10. Version -11 to -12
* Clarified semantics of 'ecdh_info' and 'kdc_dh_creds'.
* Definition of /ace-group/GROUPNAME/kdc-pub-key moved to draft-
ietf-ace-key-groupcomm.
Tiloca & Palombini Expires 16 September 2026 [Page 121]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* /ace-group accessible also to non-members that are not Verifiers.
* Clarified what resources are accessible to Verifiers.
* Revised error handling for the newly defined resources.
* Revised use of CoAP error codes.
* Use of "Token Transfer Request" and "Token Transfer Response".
* New parameter 'rekeying_scheme'.
* Categorization of new parameters and inherited conditional
parameters.
* Clarifications on what to do in case of enhanced error responses.
* Changed UCCS to CCS.
* Authentication credentials of just joined Clients can be in
rekeying messages.
* Revised names of new IANA registries.
* Clarified meaning of registered CoRE resource type.
* Alignment to new requirements from draft-ietf-ace-key-groupcomm.
* Fixes and editorial improvements.
D.11. Version -10 to -11
* Removed redundancy of key type capabilities, from 'sign_info',
'ecdh_info' and 'key'.
* New resource to retrieve the Group Manager's authentication
credential.
* New resource to retrieve material for Signature Verifiers.
* New parameter 'gp_enc_alg' related to the group mode.
* 'cred_fmt' takes value from the COSE Header Parameters registry.
* Improved alignment of the Join Response payload with the Group
OSCORE Security Context parameters.
* Recycling Group IDs by tracking "Birth GIDs".
Tiloca & Palombini Expires 16 September 2026 [Page 122]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* Error handling in case of non available Sender IDs upon joining.
* Error handling in case EdDSA public keys with invalid Y coordinate
when the pairwise mode of Group OSCORE is supported.
* Generalized proof-of-possession (PoP) for the joining node's
private key; defined Diffie-Hellman based PoP for OSCORE groups
using only the pairwise mode.
* Proof of possession of the Group Manager's private key in the Join
Response.
* Always use 'peer_identifiers' to convey Sender IDs as node
identifiers.
* Stale Sender IDs provided when rekeying the group.
* New resource for late retrieval of stale Sender IDs.
* Added examples of message exchanges.
* Revised default values of group configuration parameters.
* Fixes to IANA registrations.
* General format of parameters related to COSE capabilities,
supporting future registered COSE algorithms (new Appendix).
D.12. Version -09 to -10
* Updated non-recycling policy of Sender IDs.
* Removed policies about Sender Sequence Number synchronization.
* 'control_path' renamed to 'control_uri'.
* Format of 'get_pub_keys' aligned with draft-ietf-ace-key-
groupcomm.
* Additional way to inform of group eviction.
* Registered semantics identifier for extended scope format.
* Extended error handling, with error type specified in some error
responses.
* Renumbered requirements.
Tiloca & Palombini Expires 16 September 2026 [Page 123]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
D.13. Version -08 to -09
* The url-path "ace-group" is used.
* Added overview of permitted methods on the Group Manager
resources.
* Added exchange of parameters relevant for the pairwise mode of
Group OSCORE.
* The signed value for 'client_cred_verify' includes also the scope.
* Renamed the key material object as Group_OSCORE_Input_Material
object.
* Replaced 'clientId' with 'group_SenderId'.
* Added message exchange for Group Names request-response.
* No reassignment of Sender ID and Gid in the same OSCORE group.
* Updates on group rekeying contextual with request of new Sender
ID.
* Signature verifiers can also retrieve Group Names and URIs.
* Removed group policy about supporting Group OSCORE in pairwise
mode.
* Registration of the resource type rt="core.osc.gm".
* Update list of requirements.
* Clarifications and editorial revision.
D.14. Version -07 to -08
* AIF data model to express scope entries.
* A set of roles is checked as valid when processing the Join
Request.
* Updated format of 'get_pub_keys' in the Join Request.
* Payload format and default values of group policies in the Join
Response.
Tiloca & Palombini Expires 16 September 2026 [Page 124]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* Updated payload format of the FETCH request to retrieve
authentication credentials.
* Default values for group configuration parameters.
* IANA registrations to support the AIF data model.
D.15. Version -06 to -07
* Alignments with draft-ietf-core-oscore-groupcomm.
* New format of 'sign_info', using the COSE capabilities.
* New format of Join Response parameters, using the COSE
capabilities.
* Considerations on group rekeying.
* Editorial revision.
D.16. Version -05 to -06
* Added role of external signature verifier.
* Parameter 'rsnonce' renamed to 'kdcchallenge'.
* Parameter 'kdcchallenge' may be omitted in some cases.
* Clarified difference between group name and OSCORE Gid.
* Removed the role combination ["requester", "monitor"].
* Admit implicit scope and audience in the Authorization Request.
* New format for the 'sign_info' parameter.
* Scope not mandatory to include in the Join Request.
* Group policy about supporting Group OSCORE in pairwise mode.
* Possible individual rekeying of a single requesting node combined
with a group rekeying.
* Security considerations on reuse of signature challenges.
* Addressing optional requirement OPT12 from draft-ietf-ace-key-
groupcomm
Tiloca & Palombini Expires 16 September 2026 [Page 125]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* Editorial improvements.
D.17. Version -04 to -05
* Nonce N_S also in error responses to the Join Requests.
* Supporting single access token for multiple groups/topics.
* Supporting legal requesters/responders using the 'peer_roles'
parameter.
* Registered and used dedicated label for TLS Exporter.
* Added method for uploading a new authentication credential to the
Group Manager.
* Added resource and method for retrieving the current group status.
* Fixed inconsistency in retrieving group keying material only.
* Clarified retrieval of keying material for monitor-only members.
* Clarification on incrementing version number when rekeying the
group.
* Clarification on what is re-distributed with the group rekeying.
* Security considerations on the size of the nonces used for the
signature challenge.
* Added CBOR values to abbreviate role identifiers in the group.
D.18. Version -03 to -04
* New abstract.
* Moved general content to draft-ietf-ace-key-groupcomm
* Terminology: node name; node resource.
* Creation and pointing at node resource.
* Updated Group Manager API (REST methods and offered services).
* Size of challenges 'cnonce' and 'rsnonce'.
* Value of 'rsnonce' for reused or non-traditionally-posted tokens.
Tiloca & Palombini Expires 16 September 2026 [Page 126]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* Removed reference to RFC 7390.
* New requirements from draft-ietf-ace-key-groupcomm
* Editorial improvements.
D.19. Version -02 to -03
* New sections, aligned with the interface of ace-key-groupcomm .
* Exchange of information on the signature algorithm and related
parameters, during the Token POST (Section 4.1).
* Nonce 'rsnonce' from the Group Manager to the Client
(Section 4.1).
* Client PoP signature in the Key Distribution Request upon joining
(Section 4.2).
* Local actions on the Group Manager, upon a new node's joining
(Section 4.2).
* Local actions on the Group Manager, upon a node's leaving
(Section 12).
* IANA registration in ACE Groupcomm Parameters registry.
* More fulfilled profile requirements (Appendix A).
D.20. Version -01 to -02
* Editorial fixes.
* Changed: "listener" to "responder"; "pure listener" to "monitor".
* Changed profile name to "coap_group_oscore_app", to reflect it is
an application profile.
* Added the 'type' parameter for all requests to a Join Resource.
* Added parameters to indicate the encoding of authentication
credentials.
* Challenge-response for proof of possession of signature keys
(Section 4).
Tiloca & Palombini Expires 16 September 2026 [Page 127]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
* Renamed 'key_info' parameter to 'sign_info'; updated its format;
extended to include also parameters of the signature key
(Section 4.1).
* Code 4.00 (Bad request), in responses to joining nodes providing
an invalid authentication credential (Section 4.3).
* Clarifications on provisioning and checking of authentication
credentials (Sections 4 and 6).
* Extended discussion on group rekeying and possible different
approaches (Section 7).
* Extended security considerations: proof of possession of signature
keys; collision of OSCORE Group Identifiers (Section 8).
* Registered three entries in the IANA registry "Sequence Number
Synchronization Method" (Section 9).
* Registered one public key encoding in the "ACE Public Key
Encoding" IANA registry (Section 9).
D.21. Version -00 to -01
* Changed name of 'req_aud' to 'audience' in the Authorization
Request (Section 3.1).
* Added negotiation of signature algorithm/parameters between Client
and Group Manager (Section 4).
* Updated format of the Key Distribution Response as a whole
(Section 4.3).
* Added parameter 'cs_params' in the 'key' parameter of the Key
Distribution Response (Section 4.3).
* New IANA registrations in the "ACE Authorization Server Request
Creation Hints" registry, "ACE Groupcomm Key" registry, "OSCORE
Security Context Parameters" registry and "ACE Groupcomm Profile"
registry (Section 9).
Acknowledgments
Jiye Park contributed as a co-author of initial versions of this
document.
Tiloca & Palombini Expires 16 September 2026 [Page 128]
Internet-Draft Key Management for Group OSCORE Using AC March 2026
The authors sincerely thank Christian Amsüss, Santiago Aragón, Stefan
Beck, Mike Bishop, Carsten Bormann, Mohamed Boucadair, Deb Cooley,
Thomas Graf, Martin Gunnarsson, Russ Housley, Rikard Höglund, Watson
Ladd, Daniel Migault, Yoav Nir, Jim Schaad, Ludwig Seitz, Göran
Selander, Gunter Van de Velde, Peter van der Stok, Éric Vyncke, and
Paul Wouters for their comments and feedback.
The work on this document has been partly supported by the Sweden's
Innovation Agency VINNOVA and the Celtic-Next projects CRITISEC and
CYPRESS; by the H2020 project SIFIS-Home (Grant agreement 952652);
and by the EIT-Digital High Impact Initiative ACTIVE.
Authors' Addresses
Marco Tiloca
RISE AB
Isafjordsgatan 22
SE-164 40 Kista
Sweden
Email: marco.tiloca@ri.se
Francesca Palombini
Ericsson AB
Torshamnsgatan 23
SE-164 40 Kista
Sweden
Email: francesca.palombini@ericsson.com
Tiloca & Palombini Expires 16 September 2026 [Page 129]