draft-ietf-ace-key-groupcomm-07.txt   draft-ietf-ace-key-groupcomm-08.txt 
ACE Working Group F. Palombini ACE Working Group F. Palombini
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Standards Track M. Tiloca Intended status: Standards Track M. Tiloca
Expires: December 20, 2020 RISE AB Expires: 14 January 2021 RISE AB
June 18, 2020 13 July 2020
Key Provisioning for Group Communication using ACE Key Provisioning for Group Communication using ACE
draft-ietf-ace-key-groupcomm-07 draft-ietf-ace-key-groupcomm-08
Abstract Abstract
This document defines message formats and procedures for requesting This document defines message formats and procedures for requesting
and distributing group keying material using the ACE framework, to and distributing group keying material using the ACE framework, to
protect communications between group members. protect communications between group members.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/ace-wg/ace-key-groupcomm.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 20, 2020. This Internet-Draft will expire on 14 January 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect Please review these documents carefully, as they describe your rights
to this document. Code Components extracted from this document must and restrictions with respect to this document. Code Components
include Simplified BSD License text as described in Section 4.e of extracted from this document must include Simplified BSD License text
the Trust Legal Provisions and are provided without warranty as as described in Section 4.e of the Trust Legal Provisions and are
described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Authorization to Join a Group . . . . . . . . . . . . . . . . 6 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 7
3.1. Authorization Request . . . . . . . . . . . . . . . . . . 7 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 7
3.2. Authorization Response . . . . . . . . . . . . . . . . . 9 3.2. Authorization Response . . . . . . . . . . . . . . . . . 9
3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10
4. Keying Material Provisioning and Group Membership Management 14 4. Keying Material Provisioning and Group Membership
Management . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 15 4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 15
4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 30 4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 31
4.3. Retrieval of Updated Keying Material . . . . . . . . . . 31 4.3. Retrieval of Updated Keying Material . . . . . . . . . . 32
4.4. Retrieval of New Keying Material . . . . . . . . . . . . 33 4.4. Retrieval of New Individual Keying Material . . . . . . . 34
4.5. Retrieval of Public Keys and Roles for Group Members . . 34 4.5. Retrieval of Public Keys and Roles for Group Members . . 35
4.6. Update of Public Key . . . . . . . . . . . . . . . . . . 34 4.6. Update of Public Key . . . . . . . . . . . . . . . . . . 35
4.7. Retrieval of Group Policies . . . . . . . . . . . . . . . 35 4.7. Retrieval of Group Policies . . . . . . . . . . . . . . . 36
4.8. Retrieval of Keying Material Version . . . . . . . . . . 36 4.8. Retrieval of Keying Material Version . . . . . . . . . . 37
4.9. Group Leaving Request . . . . . . . . . . . . . . . . . . 36 4.9. Group Leaving Request . . . . . . . . . . . . . . . . . . 37
5. Removal of a Node from the Group . . . . . . . . . . . . . . 36 5. Removal of a Node from the Group . . . . . . . . . . . . . . 37
6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 37 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . . 38 7. Security Considerations . . . . . . . . . . . . . . . . . . . 40
7.1. Update of Keying Material . . . . . . . . . . . . . . . . 40 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 41
7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 40 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 42
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
8.1. Media Type Registrations . . . . . . . . . . . . . . . . 41 8.1. Media Type Registrations . . . . . . . . . . . . . . . . 42
8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 42 8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 43
8.3. OAuth Parameters Registry . . . . . . . . . . . . . . . . 42 8.3. OAuth Parameters Registry . . . . . . . . . . . . . . . . 43
8.4. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 42 8.4. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 44
8.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 43 8.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 44
8.6. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 43 8.6. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 45
8.7. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 44 8.7. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 45
8.8. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 45 8.8. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 46
8.9. Sequence Number Synchronization Method Registry . . . . . 46 8.9. Sequence Number Synchronization Method Registry . . . . . 47
8.10. Interface Description (if=) Link Target Attribute Values 8.10. Interface Description (if=) Link Target Attribute Values
Registry . . . . . . . . . . . . . . . . . . . . . . . . 46 Registry . . . . . . . . . . . . . . . . . . . . . . . . 47
8.11. Expert Review Instructions . . . . . . . . . . . . . . . 46 8.11. Expert Review Instructions . . . . . . . . . . . . . . . 47
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
9.1. Normative References . . . . . . . . . . . . . . . . . . 47 9.1. Normative References . . . . . . . . . . . . . . . . . . 48
9.2. Informative References . . . . . . . . . . . . . . . . . 49 9.2. Informative References . . . . . . . . . . . . . . . . . 50
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Appendix A. Requirements on Application Profiles . . . . . . . . 52
Appendix A. Requirements on Application Profiles . . . . . . . . 51 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 54
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 53 B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 54
B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 53 B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 55
B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 54 B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 55
B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 54 B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 56
B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 54 B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 56
B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 55 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to This document expands the ACE framework [I-D.ietf-ace-oauth-authz] to
define the message exchanges used to request, distribute and renew define the message exchanges used to request, distribute and renew
the keying material in a group communication scenario, e.g. based on the keying material in a group communication scenario, e.g. based on
multicast [I-D.ietf-core-groupcomm-bis] or on publishing-subscribing multicast [I-D.ietf-core-groupcomm-bis] or on publishing-subscribing
[I-D.ietf-core-coap-pubsub]. The ACE framework is based on CBOR [I-D.ietf-core-coap-pubsub]. The ACE framework is based on CBOR
[RFC7049], so CBOR is the format used in this specification. [RFC7049], so CBOR is the format used in this specification.
However, using JSON [RFC8259] instead of CBOR is possible, using the However, using JSON [RFC8259] instead of CBOR is possible, using the
skipping to change at page 3, line 48 skipping to change at page 4, line 5
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with the terms and concepts
described in [I-D.ietf-ace-oauth-authz][I-D.ietf-cose-rfc8152bis-stru described in [I-D.ietf-ace-oauth-authz][I-D.ietf-cose-rfc8152bis-stru
ct][I-D.ietf-cose-rfc8152bis-algs], such as Authorization Server (AS) ct][I-D.ietf-cose-rfc8152bis-algs], such as Authorization Server (AS)
and Resource Server (RS). and Resource Server (RS).
This document additionally uses the following terminology: This document additionally uses the following terminology:
o Transport profile, to indicate a profile of ACE as per * Transport profile, to indicate a profile of ACE as per
Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]. A transport Section 5.6.4.3 of [I-D.ietf-ace-oauth-authz]. A transport
profile specifies the communication protocol and communication profile specifies the communication protocol and communication
security protocol between an ACE Client and Resource Server, as security protocol between an ACE Client and Resource Server, as
well as proof-of-possession methods, if it supports proof-of- well as proof-of-possession methods, if it supports proof-of-
possession access tokens, etc. Tranport profiles of ACE include, possession access tokens, etc. Tranport profiles of ACE include,
for instance, [I-D.ietf-ace-oscore-profile], for instance, [I-D.ietf-ace-oscore-profile],
[I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile]. [I-D.ietf-ace-dtls-authorize] and [I-D.ietf-ace-mqtt-tls-profile].
o Application profile, that defines how applications enforce and use * Application profile, that defines how applications enforce and use
supporting security services they require. These services may supporting security services they require. These services may
include, for instance, provisioning, revocation and include, for instance, provisioning, revocation and
(re-)distribution of keying material. An application profile may (re-)distribution of keying material. An application profile may
define specific procedures and message formats. define specific procedures and message formats.
2. Overview 2. Overview
The full procedure can be separated in two phases: the first follows
the ACE framework, between Client, AS and KDC. The second part is
the key distribution between Client and KDC. After the two phases
the Client is able to participate in the group communication, via a
Dispatcher entity.
+------------+ +-----------+ +------------+ +-----------+
| AS | | KDC | | AS | | KDC |
| | .-------->| | | | .-------->| |
+------------+ / +-----------+ +------------+ / +-----------+
^ / ^ /
| / | /
v / +-----------+ v / +-----------+
+------------+ / +------------+ |+-----------+ +------------+ / +------------+ |+-----------+
| Client |<-' | Dispatcher | ||+-----------+ | Client |<-' | Dispatcher | ||+-----------+
| |<-------->| (RS) |<------->|| Group | | |<-------->| |<------->|| Group |
+------------+ +------------+ +| members | +------------+ +------------+ +| members |
+-----------+ +-----------+
Figure 1: Key Distribution Participants Figure 1: Key Distribution Participants
The following participants (see Figure 1) take part in the The following participants (see Figure 1) take part in the
authorization and key distribution. authorization and key distribution.
o Client (C): node that wants to join the group communication. It * Client (C): node that wants to join the group communication. It
can request write and/or read rights. can request write and/or read rights.
o Authorization Server (AS): same as AS in the ACE Framework; it * Authorization Server (AS): same as AS in the ACE Framework; it
enforces access policies, and knows if a node is allowed to join a enforces access policies, and knows if a node is allowed to join a
given group with write and/or read rights. given group with write and/or read rights.
o Key Distribution Center (KDC): maintains the keying material to * Key Distribution Center (KDC): maintains the keying material to
protect group communications, and provides it to Clients protect group communications, and provides it to Clients
authorized to join a given group. During the first part of the authorized to join a given group. During the first part of the
exchange (Section 3), it takes the role of the RS in the ACE exchange (Section 3), it takes the role of the RS in the ACE
Framework. During the second part (Section 4), which is not based Framework. During the second part (Section 4), which is not based
on the ACE Framework, it distributes the keying material. In on the ACE Framework, it distributes the keying material. In
addition, it provides the latest keying material to group members addition, it provides the latest keying material to group members
when requested or, if required by the application, when membership when requested or, if required by the application, when membership
changes. changes.
o Dispatcher: entity through which the Clients communicate with the * Dispatcher: entity through which the Clients communicate with the
group and which distributes messages to the group members. group and which distributes messages to the group members.
Examples of dispatchers are: the Broker node in a pub-sub setting; Examples of dispatchers are: the Broker node in a pub-sub setting;
a relayer node for group communication that delivers group a relayer node for group communication that delivers group
messages as multiple unicast messages to all group members; an messages as multiple unicast messages to all group members; an
implicit entity as in a multicast communication setting, where implicit entity as in a multicast communication setting, where
messages are transmitted to a multicast IP address and delivered messages are transmitted to a multicast IP address and delivered
on the transport channel. on the transport channel.
This document specifies a mechanism for: This document specifies a mechanism for:
o Authorizing a new node to join the group (Section 3), and * Authorizing a new node to join the group (Section 3), and
providing it with the group keying material to communicate with providing it with the group keying material to communicate with
the other group members (Section 4). the other group members (Section 4).
o Leaving or removing a current group member from the group * Allowing a group member to leave the group (Section 5).
(Section 5).
o Retrieval of keying material by a group member (Section 4.3 and * Evicting a group member from the group (Section 5).
Section 4.4).
o Renewing and re-distributing the group keying material (rekeying) * Allowing a group member to retrieve keying material (Section 4.3
and Section 4.4).
* Renewing and re-distributing the group keying material (rekeying)
upon a membership change in the group (Section 4.9 and Section 5). upon a membership change in the group (Section 4.9 and Section 5).
Figure 2 provides a high level overview of the message flow for a Figure 2 provides a high level overview of the message flow for a
node joining a group communication setting, which can be expanded as node joining a group communication setting, which can be expanded as
follows. follows.
1. The joining node requests an Access Token from the AS, in order 1. The joining node requests an Access Token from the AS, in order
to access a specific group-membership resource on the KDC and to access a specific group-membership resource on the KDC and
hence join the associated group. The joining node will start or hence join the associated group. This exchange between Client
and AS MUST be secured, as specified by the transport profile of
ACE used between Client and KDC. The joining node will start or
continue using a secure communication association with the KDC, continue using a secure communication association with the KDC,
according to the response from the AS. according to the response from the AS.
2. The joining node transfers authentication and authorization 2. The joining node transfers authentication and authorization
information to the KDC, by posting the obtained Access Token to information to the KDC, by posting the obtained Access Token to
the /authz-info endpoint at the KDC. After that, a joining node the /authz-info endpoint at the KDC. This exchange, and all
MUST have a secure communication association established with the further communications between the Client and the KDC, MUST occur
KDC, before starting to join a group under that KDC. Possible over the secure channel established as a result of the transport
ways to provide a secure communication association are DTLS profile of ACE used between Client and KDC. After that, a
[RFC6347] and OSCORE [RFC8613]. joining node MUST have a secure communication association
established with the KDC, before starting to join a group under
that KDC. Possible ways to provide a secure communication
association are DTLS [RFC6347] and OSCORE [RFC8613].
3. The joining node starts the joining process to become a member of 3. The joining node starts the joining process to become a member of
the group, by accessing the related group-membership resource at the group, by accessing the related group-membership resource at
the KDC. At the end of the joining process, the joining node has the KDC. At the end of the joining process, the joining node has
received from the KDC the parameters and keying material to received from the KDC the parameters and keying material to
securely communicate with the other members of the group, and the securely communicate with the other members of the group, and the
KDC has stored the association between the authorization KDC has stored the association between the authorization
information from the access token and the secure session with the information from the access token and the secure session with the
client. client.
4. The joining node and the KDC maintain the secure association, to 4. The joining node and the KDC maintain the secure association, to
support possible future communications. These especially include support possible future communications. These especially include
key management operations, such as retrieval of updated keying key management operations, such as retrieval of updated keying
material or participation to a group rekeying process. material or participation to a group rekeying process.
5. The joining node can communicate securely with the other group
members, using the keying material provided in step 3.
C AS KDC Group C AS KDC Group
| | | Member | | | Member
/ | | | | / | | | |
| | Authorization Request | | | | | Authorization Request | | |
Defined | |-------------------------->| | | Defined | |-------------------------->| | |
in the | | | | | in the | | | | |
ACE | | Authorization Response | | | ACE | | Authorization Response | | |
framework | |<--------------------------| | | framework | |<--------------------------| | |
| | | | | | | |
\ |---------- Token Post --------->| | \ |---------- Token Post --------->| |
| | | | | |
|------- Joining Request ------->| | |------- Joining Request ------->| |
| | | | | |
|<------ Joining Response -------|-- Group Rekeying -->| |<------ Joining Response -------|-- Group Rekeying -->|
| | | | | |
| Dispatcher | | Dispatcher |
| | | | | |
|<===== Secure group communication =======|===========>| |<===== Secure group communication =======|===========>|
| | | | | |
Figure 2: Message Flow Upon New Node's Joining
Figure 2: Message Flow Upon New Node's Joining
The exchange of Authorization Request and Authorization Response
between Client and AS MUST be secured, as specified by the transport
profile of ACE used between Client and KDC.
The Joining Request and Joining Response, and all further
communications between the Client and the KDC MUST be sent over the
secure channel established as a result of the transport profile of
ACE used between Client and KDC.
All communications between a Client and the other group members MUST
be secured using the keying material provided in Section 4.
3. Authorization to Join a Group 3. Authorization to Join a Group
This section describes in detail the format of messages exchanged by This section describes in detail the format of messages exchanged by
the participants when a node requests access to a given group. This the participants when a node requests access to a given group. This
exchange is based on ACE [I-D.ietf-ace-oauth-authz]. exchange is based on ACE [I-D.ietf-ace-oauth-authz].
As defined in [I-D.ietf-ace-oauth-authz], the Client requests from As defined in [I-D.ietf-ace-oauth-authz], the Client requests from
the AS an authorization to join the group through the KDC (see the AS an authorization to join the group through the KDC (see
Section 3.1). If the request is approved and authorization is Section 3.1). If the request is approved and authorization is
granted, the AS provides the Client with a proof-of-possession access granted, the AS provides the Client with a proof-of-possession access
token and parameters to securely communicate with the KDC (see token and parameters to securely communicate with the KDC (see
Section 3.2). Section 3.2).
Communications between the Client and the AS MUST be secured, as Communications between the Client and the AS MUST be secured, as
defined by the transport profile of ACE used. The Content-Format defined by the transport profile of ACE used. The Content-Format
used in the messages is the one specified by the used transport used in the message is the one indicated by the used transport
profile of ACE (e.g. application/ace+cbor for the first two messages profile of ACE. For example, this can be application/ace+cbor for
and application/cwt for the third message, depending on the format of the first two messages and application/cwt for the third message,
the access token). The transport profile of ACE also defines a which are defined in the ACE framework. The transport profile of ACE
number of details such as the communication and security protocols also defines a number of details such as the communication and
used with the KDC (see Appendix C of [I-D.ietf-ace-oauth-authz]). security protocols used with the KDC (see Appendix C of
[I-D.ietf-ace-oauth-authz]).
Figure 3 gives an overview of the exchange described above. Figure 3 gives an overview of the exchange described above.
Client AS KDC Client AS KDC
| | | | | |
|---- Authorization Request: POST /token ------>| | |---- Authorization Request: POST /token ------>| |
| | | | | |
|<--- Authorization Response: 2.01 (Created) ---| | |<--- Authorization Response: 2.01 (Created) ---| |
| | | | | |
|----- POST Token: POST /authz-info --------------->| |----- POST Token: POST /authz-info --------------->|
| | | |
Figure 3: Message Flow of Join Authorization Figure 3: Message Flow of Join Authorization
3.1. Authorization Request 3.1. Authorization Request
The Authorization Request sent from the Client to the AS is defined The Authorization Request sent from the Client to the AS is defined
in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the
following parameters, which, if included, MUST have the corresponding following parameters, which, if included, MUST have the corresponding
values: values:
o 'scope', containing the identifier of the specific group(s), or * 'scope', containing the identifier of the specific group(s), or
topic(s) in the case of pub-sub, that the Client wishes to access, topic(s) in the case of pub-sub, that the Client wishes to access,
and optionally the role(s) that the Client wishes to take. and optionally the role(s) that the Client wishes to take.
This value is a CBOR byte string, encoding a CBOR array of one or This value is a CBOR byte string, encoding a CBOR array of one or
more entries. more entries.
An entry has as value a CBOR array, which contains: By default, each entry is encoded as specified by
[I-D.bormann-core-ace-aif]. It is up to the application profiles
to define and register Toid and Tperm to fit the use case. The
object identifier Toid corresponds to the group name, while the
permission set Tperm indicates the roles that the client wishes to
take in the group.
* As first element, the identifier of the specific group or Otherwise, each scope entry can be defined as a CBOR array, which
contains:
- As first element, the identifier of the specific group or
topic. topic.
* Optionally, as second element, the role (or CBOR array of - Optionally, as second element, the role (or CBOR array of
roles) that the Client wishes to take in the group. This roles) that the Client wishes to take in the group. This
element is optional since roles may have been pre-assigned to element is optional since roles may have been pre-assigned to
the Client, as associated to its verifiable identity the Client, as associated to its verifiable identity
credentials. Alternatively, the application may have defined a credentials. Alternatively, the application may have defined a
single, well-known role for the target resource(s) and single, well-known role for the target resource(s) and
audience(s). Note that, if applicable in the application use audience(s).
cases, the application profile can define a format for the role
as the one defined in [I-D.bormann-core-ace-aif].
In each entry, the encoding of the group or topic identifier (REQ1 In each entry, the encoding of the group or topic identifier (REQ1
in Appendix A) and of the role identifiers (REQ2) is application in Appendix A) and of the role identifiers (REQ2) is application
specific, and part of the requirements for the application specific, and part of the requirements for the application
profile. profile.
In particular, the application profile may specify CBOR values to In particular, the application profile may specify CBOR values to
use for abbreviating role identifiers (OPT7). use for abbreviating role identifiers (OPT7).
The CDDL definition [RFC8610] of scope, using as example group An example of CDDL definition [RFC8610] of scope using the format
identifier encoded as byte string and role identifier as text above, with group name and role identifiers encoded as text
string, is given in Figure 4. strings is given in Figure 4.
o 'audience', with an identifier of a KDC. * 'audience', with an identifier of a KDC.
o 'req_cnf', as defined in Section 3.1 of * 'req_cnf', as defined in Section 3.1 of
[I-D.ietf-ace-oauth-params], optionally containing the public key [I-D.ietf-ace-oauth-params], optionally containing the public key
or a reference to the public key of the Client, if it wishes to or a reference to the public key of the Client, if it wishes to
communicate that to the AS. communicate that to the AS.
o Other additional parameters as defined in Other additional parameters as defined in [I-D.ietf-ace-oauth-authz],
[I-D.ietf-ace-oauth-authz], if necessary. can be included if necessary.
As in [I-D.ietf-ace-oauth-authz], these parameters are included in As in [I-D.ietf-ace-oauth-authz], these parameters are included in
the payload, which is formatted as a CBOR map. The Content-Format the payload, which is formatted as a CBOR map. The Content-Format
"application/ace+cbor" defined in Section 8.14 of "application/ace+cbor" defined in Section 8.14 of
[I-D.ietf-ace-oauth-authz] is used. [I-D.ietf-ace-oauth-authz] is used.
gid = bstr gname = tstr
role = tstr role = tstr
scope_entry = [ gid , ? ( role / [ 2*role ] ) ] scope_entry = [ gname , ? ( role / [ 2*role ] ) ]
scope = << [ + scope_entry ] >> scope = << [ + scope_entry ] >>
Figure 4: CDLL definition of scope, using as example group identifier Figure 4: CDLL definition of scope, using as example group name
encoded as bstr and role as tstr encoded as tstr and role as tstr
3.2. Authorization Response 3.2. Authorization Response
The Authorization Response sent from the AS to the Client is defined The Authorization Response sent from the AS to the Client is defined
in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST contain the in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST contain the
following parameters: following parameters:
o 'access_token', containing the proof-of-possession access token. * 'access_token', containing the proof-of-possession access token.
o 'cnf' if symmetric keys are used, not present if asymmetric keys * 'cnf' if symmetric keys are used, not present if asymmetric keys
are used. This parameter is defined in Section 3.2 of are used. This parameter is defined in Section 3.2 of
[I-D.ietf-ace-oauth-params] and contains the symmetric proof-of- [I-D.ietf-ace-oauth-params] and contains the symmetric proof-of-
possession key that the Client is supposed to use with the KDC. possession key that the Client is supposed to use with the KDC.
o 'rs_cnf' if asymmetric keys are used, not present if symmetric * 'rs_cnf' if asymmetric keys are used, not present if symmetric
keys are used. This parameter is defined in Section 3.2 of keys are used. This parameter is defined in Section 3.2 of
[I-D.ietf-ace-oauth-params] and contains information about the [I-D.ietf-ace-oauth-params] and contains information about the
public key of the KDC. public key of the KDC.
o 'expires_in', contains the lifetime in seconds of the access * 'expires_in', contains the lifetime in seconds of the access
token. This parameter MAY be omitted if the application defines token. This parameter MAY be omitted if the application defines
how the expiration time is communicated to the Client via other how the expiration time is communicated to the Client via other
means, or if it establishes a default value. means, or if it establishes a default value.
Additionally, the Authorization Response MAY contain the following Additionally, the Authorization Response MAY contain the following
parameters, which, if included, MUST have the corresponding values: parameters, which, if included, MUST have the corresponding values:
o 'scope' containing the granted scope, if different from the scope * 'scope' containing the scope the AS grants access to. This
requested by the client. This parameter has the same format and parameter has the same format and encoding of 'scope' in the
encoding of 'scope' in the Authorization Request, defined in Authorization Request, defined in Section 3.1.
Section 3.1.
o Other additional parameters as defined in Other additional parameters as defined in [I-D.ietf-ace-oauth-authz],
[I-D.ietf-ace-oauth-authz], if necessary. if necessary.
The proof-of-possession access token (in 'access_token' above) MUST The proof-of-possession access token (in 'access_token' above) MUST
contain the following parameters: contain the following parameters:
o a confirmation claim (see for example 'cnf' defined in Section 3.1 * a confirmation claim (see for example 'cnf' defined in Section 3.1
of [RFC8747] for CWT); of [RFC8747] for CWT);
o an expiration time claim (see for example 'exp' defined in * an expiration time claim (see for example 'exp' defined in
Section 3.1.4 of [RFC8392] for CWT); Section 3.1.4 of [RFC8392] for CWT);
o a scope claim (see for example 'scope' registered in Section 8.13 * a scope claim (see for example 'scope' registered in Section 8.13
of [I-D.ietf-ace-oauth-authz] for CWT). This claim has the same of [I-D.ietf-ace-oauth-authz] for CWT). This claim has the same
encoding as 'scope' parameter above. Additionally, this claim has encoding as 'scope' parameter above. Additionally, this claim has
the same value of the 'scope' parameter if the parameter is the same value of the 'scope' parameter if the parameter is
present in the message, or it takes the value of 'scope' in the present in the message, or it takes the value of 'scope' in the
Authorization Request otherwise. Authorization Request otherwise.
The access token MAY additionally contain other claims that the The access token MAY additionally contain other claims that the
transport profile of ACE requires, or other optional parameters. transport profile of ACE requires, or other optional parameters.
As in [I-D.ietf-ace-oauth-authz], these parameters are included in As in [I-D.ietf-ace-oauth-authz], these parameters are included in
the payload, which is formatted as a CBOR map. The Content-Format the payload, which is formatted as a CBOR map. The Content-Format
"application/ace+cbor" is used. "application/ace+cbor" is used.
When receiving an Authorization Request from a Client that was When receiving an Authorization Request from a Client that was
previously authorized, and for which the AS still owns a valid non previously authorized, and for which the AS still owns a valid non-
expired access token, the AS MAY reply with that token. Note that it expired access token, the AS MAY reply with that token. Note that it
is up to application profiles of ACE to make sure that re-posting the is up to application profiles of ACE to make sure that re-posting the
same token does not cause re-use of keying material between nodes same token does not cause re-use of keying material between nodes
(for example, that is done with the use of random nonces in (for example, that is done with the use of random nonces in
[I-D.ietf-ace-oscore-profile]). [I-D.ietf-ace-oscore-profile]).
3.3. Token Post 3.3. Token Post
The Client sends a CoAP POST request including the access token to The Client sends a CoAP POST request including the access token to
the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz].
If the specific transport profile of ACE defines it, the Client MAY If the specific transport profile of ACE defines it, the Client MAY
use a different endpoint than /authz-info at the KDC to post the use a different endpoint than /authz-info at the KDC to post the
access token to. access token to.
Optionally, the Client might want to request necessary information Optionally, the Client might want to request information concerning
concerning the public keys in the group, as well as concerning the the public keys in the group, as well as concerning the algorithm and
algorithm and related parameters for computing signatures in the related parameters for computing signatures in the group. In such a
group. In such a case, the joining node MAY ask for that information case, the joining node MAY ask for that information to the KDC in
to the KDC in this same request. To this end, it sends the CoAP POST this same request. To this end, it sends the CoAP POST request to
request to the /authz-info endpoint using the Content-Format the /authz-info endpoint using the Content-Format "application/
"application/ace+cbor". The payload of the message MUST be formatted ace+cbor".
as a CBOR map, including the access token and the following
parameters:
o 'sign_info' defined in Section 3.3.1. The payload of the message MUST be formatted as a CBOR map including
the access token.
o 'pub_key_enc' defined in Section 3.3.2, encoding the CBOR simple Additionally, the CoAP POST request MAY contain the following
value Null, to require information on the exact encoding of public parameter, which, if included, MUST have the corresponding values:
keys used in the group.
* 'sign_info' defined in Section 3.3.1, encoding the CBOR simple
value Null to require information about the signature algorithm,
signature algorithm parameters, signature key parameters and on
the exact encoding of public keys used in the group.
Alternatively, the joining node may retrieve this information by Alternatively, the joining node may retrieve this information by
other means. other means.
After successful verification, the Client is authorized to receive After successful verification, the Client is authorized to receive
the group keying material from the KDC and join the group. In the group keying material from the KDC and join the group. In
particular, the KDC replies to the Client with a 2.01 (Created) particular, the KDC replies to the Client with a 2.01 (Created)
response, using Content-Format "application/ace+cbor" defined in response, using Content-Format "application/ace+cbor" defined in
Section 8.14 of [I-D.ietf-ace-oauth-authz]. Section 8.14 of [I-D.ietf-ace-oauth-authz].
The payload of the 2.01 response is a CBOR map. If the access token The payload of the 2.01 response is a CBOR map. If the access token
contains a role that requires the Client to send its own public key contains a role that requires the Client to send its own public key
to the KDC when joining the group, the CBOR map MUST include the to the KDC when joining the group, the CBOR map MUST include the
parameter 'kdcchallenge' defined in Section Section 3.3.3, specifying parameter 'kdcchallenge' defined in Section Section 3.3.2, specifying
a dedicated challenge N_S generated by the KDC. The Client uses this a dedicated challenge N_S generated by the KDC. The Client uses this
challenge to prove possession of its own private key (see the challenge to prove possession of its own private key (see the
'client_cred_verify' parameter in Section 4). Note that the payload 'client_cred_verify' parameter in Section 4). Note that the payload
format of the response deviates from the default as defined in the format of the response deviates from the one defined in the ACE
ACE framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]). framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]), which
has no payload.
The KDC MUST store the 'kdcchallenge' value associated to the Client The KDC MUST store the 'kdcchallenge' value associated to the Client
at least until it receives a join request from it (see Section 4.2), at least until it receives a join request from it (see Section 4.2),
to be able to verify the proof of possession. The same challenge MAY to be able to verify the proof of possession. The same challenge MAY
be reused several times by the Client, to generate new proof of be reused several times by the Client, to generate new proof of
possessions, e.g. in case of update of the public key, or to join a possessions, e.g. in case of update of the public key, or to join a
different group with a different key, so it is RECOMMENDED that the different group with a different key, so it is RECOMMENDED that the
KDC keeps storing the 'kdcchallenge' after the first join is KDC keeps storing the 'kdcchallenge' after the first join is
processed as well. If the KDC has already discarded the processed as well. If the KDC has already discarded the
'kdcchallenge', that will trigger an error response with a newly 'kdcchallenge', that will trigger an error response with a newly
generated 'kdcchallenge' that the client can use to restart the join generated 'kdcchallenge' that the client can use to restart the join
process, as specified in Section 4.2. process, as specified in Section 4.2.
If either of 'sign_info' or 'pub_key_enc' were included in the If 'sign_info' is included in the request, the KDC MAY include the
request, the KDC MAY include the 'sign_info' parameter defined in 'sign_info' parameter defined in Section 3.3.1, with the same
Section 3.3.1, optionally including the 'pub_key_enc' parameter encoding. Note that the field 'id' takes the value of the group name
Section 3.3.2. for which the 'sign_info_entry' applies to.
The 'sign_info' parameter MUST be present if the POST request
included the 'sign_info' parameter and/or the pub_key_enc with value
Null. The encoding of the 'sign_info' parameter in the response is
defined in Section 3.3.2. Note that the field 'id' takes the value
of the group identifier for which the 'sign_info' applies to, in this
specification.
Note that the CBOR map specified as payload of the 2.01 (Created) Note that the CBOR map specified as payload of the 2.01 (Created)
response may include further parameters, e.g. according to the response may include further parameters, e.g. according to the
signalled transport profile of ACE. signalled transport profile of ACE.
Applications of this specification MAY define alternative specific Applications of this specification MAY define alternative specific
negotiations of parameter values for signature algorithm and negotiations of parameter values for signature algorithm and
signature keys, if 'sign_info' and 'pub_key_enc' are not used (OPT2). signature keys, if 'sign_info' is not used (OPT2).
3.3.1. 'sign_info' Parameter 3.3.1. 'sign_info' Parameter
The 'sign_info' parameter is an OPTIONAL parameter of the Token Post The 'sign_info' parameter is an OPTIONAL parameter of the Token Post
response message defined in Section 5.1.2. of response message defined in Section 5.1.2. of
[I-D.ietf-ace-oauth-authz]. This parameter contains information and [I-D.ietf-ace-oauth-authz]. This parameter contains information and
parameters about the signature algorithm and the public keys to be parameters about the signature algorithm and the public keys to be
used between the Client and the RS. Its exact content is application used between the Client and the RS. Its exact content is application
specific. specific.
skipping to change at page 12, line 29 skipping to change at page 12, line 37
When used in the request, the 'sign_info' encodes the CBOR simple When used in the request, the 'sign_info' encodes the CBOR simple
value Null, to require information and parameters on the signature value Null, to require information and parameters on the signature
algorithm and on the public keys used. algorithm and on the public keys used.
The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as
in the request is given below. in the request is given below.
sign_info_req = nil sign_info_req = nil
The 'sign_info' parameter of the 2.01 (Created) response is a CBOR The 'sign_info' parameter of the 2.01 (Created) response is a CBOR
array of one ore more elements. The number of elements is lower or array of one or more elements. The number of elements is at most the
at most equal to the number of groups the client has been authorized number of groups the client has been authorized to join. Each
to join. Each element contains information about signing parameters element contains information about signing parameters and keys for
and keys for one or more group or topic and is formatted as follows. one or more group or topic and is formatted as follows.
o The first element 'id' is an identifier of the group or an array * The first element 'id' is an identifier of the group or an array
of identifiers for the groups for which this information applies. of identifiers for the groups for which this information applies.
o The second element 'sign_alg' is an integer or a text string if * The second element 'sign_alg' is an integer or a text string if
the POST request included the 'sign_info' parameter with value the POST request included the 'sign_info' parameter with value
Null, and indicates the signature algorithm used in the group Null, and indicates the signature algorithm used in the group
identified by 'gid'. It is REQUIRED of the application profiles identified by 'gname'. It is REQUIRED of the application profiles
to define specific values that this parameter can take (REQ3), to define specific values that this parameter can take (REQ3),
selected from the set of signing algorithms of the COSE Algorithms selected from the set of signing algorithms of the COSE Algorithms
registry [COSE.Algorithms]. If the POST request did not include registry [COSE.Algorithms].
the 'sing_info' parameter, this element is encoded as the CBOR
simple value Null.
o The third element 'sign_parameters' is a CBOR array indicating the * The third element 'sign_parameters' is a CBOR array indicating the
parameters of the signature algorithm. Its content depends on the parameters of the signature algorithm. Its content depends on the
value of 'sign_alg'. It is REQUIRED of the application profiles value of 'sign_alg'. It is REQUIRED of the application profiles
to define the possible values and structure for the elements of to define the possible values and structure for the elements of
this parameter (REQ4). If the POST request did not include the this parameter (REQ4).
'sign_info' parameter, this element is encoded as the CBOR simple
value Null.
o The fourth element 'sign_key_parameters' is a CBOR array * The fourth element 'sign_key_parameters' is a CBOR array
indicating the parameters of the key used with the signature indicating the parameters of the key used with the signature
algorithm. Its content depends on the value of 'sign_alg'. It is algorithm. Its content depends on the value of 'sign_alg'. It is
REQUIRED of the application profiles to define the possible values REQUIRED of the application profiles to define the possible values
and structure for the elements of this parameter (REQ5). If the and structure for the elements of this parameter (REQ5).
POST request did not include the 'sing_info' parameter, this
element is encoded as the CBOR simple value Null.
o The fifth element 'pub_key_enc' parameter is optional and MUST * The fifth element 'pub_key_enc' parameter is either a CBOR integer
only be present if the POST request included the 'pub_key_enc' indicating the encoding of public keys used in the group
parameter with value Null. If present, it is either a CBOR identified by 'gname', or has value Null indicating that the KDC
integer indicating the encoding of public keys used in the group
identified by 'gid', or has value Null indicating that the KDC
does not act as repository of public keys for group members. Its does not act as repository of public keys for group members. Its
acceptable values are taken from the "CWT Confirmation Method" acceptable values are taken from the "CWT Confirmation Method"
Registry defined in [RFC8747]. It is REQUIRED of the application Registry defined in [RFC8747]. It is REQUIRED of the application
profiles to define specific values to use for this parameter profiles to define specific values to use for this parameter
(REQ6). (REQ6).
The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as
in the response is given below, with gid formatted as a bstr (note in the response is given below, with gname formatted as a bstr (note
that gid can be encoded differently, see REQ1). that gname can be encoded differently, see REQ1).
sign_info_res = [ + sign_info_entry ] sign_info_res = [ + sign_info_entry ]
sign_info_entry = sign_info_entry =
[ [
id : gid / [ + gid ], id : gname / [ + gname ],
sign_alg : int / tstr / nil, sign_alg : int / tstr / nil,
sign_parameters : [ any ] / nil, sign_parameters : [ any ] / nil,
sign_key_parameters : [ any ] / nil, sign_key_parameters : [ any ] / nil,
? pub_key_enc_res = int / nil pub_key_enc = int / nil
] ]
gid = bstr gname = tstr
3.3.2. 'pub_key_enc' Parameter
The 'pub_key_enc' parameter is an OPTIONAL parameter of the Token
Post response message defined in Section 5.1.2. of
[I-D.ietf-ace-oauth-authz]. This parameter contains information
about the exact encoding of public keys to be used between the Client
and the RS. Its exact content is application specific.
In this specification and in application profiles building on it,
this parameter is used to ask the KDC information about the encoding
of public keys used in the group.
The CDDL notation [RFC8610] of the 'pub_key_enc' parameter formatted
as in the request is given below.
pub_key_enc_req = nil
3.3.3. 'kdcchallenge' Parameter 3.3.2. 'kdcchallenge' Parameter
The 'kdcchallenge' parameter is an OPTIONAL parameter of the Token The 'kdcchallenge' parameter is an OPTIONAL parameter of the Token
Post response message defined in Section 5.1.2. of Post response message defined in Section 5.1.2. of
[I-D.ietf-ace-oauth-authz]. This parameter contains a challenge [I-D.ietf-ace-oauth-authz]. This parameter contains a challenge
generated by the KDC and provided to the Client. The Client may use generated by the KDC and provided to the Client. The Client may use
this challenge to prove possession of its own private key in the this challenge to prove possession of its own private key in the
Joining Request ((see the 'client_cred_verify' parameter in Joining Request (see the 'client_cred_verify' parameter in
Section 4). Section 4).
4. Keying Material Provisioning and Group Membership Management 4. Keying Material Provisioning and Group Membership Management
This section defines the interface available at the KDC. Moreover, This section defines the interface available at the KDC. Moreover,
this section specifies how the clients can use this interface to join this section specifies how the clients can use this interface to join
a group, leave a group, retrieve new keying material or policies. a group, leave a group, retrieve the group policies or the new keying
material.
During the first exchange with the KDC ("Joining"), the Client sends During the first exchange with the KDC ("Joining") after posting the
a request to the KDC, specifying the group it wishes to join (see Token, the Client sends a request to the KDC, specifying the group it
Section 4.2). Then, the KDC verifies the access token and that the wishes to join (see Section 4.2). Then, the KDC verifies the access
Client is authorized to join that group. If so, it provides the token and that the Client is authorized to join that group. If so,
Client with the keying material to securely communicate with the it provides the Client with the keying material to securely
other members of the group. Whenever used, the Content-Format in communicate with the other members of the group. Whenever used, the
messages containing a payload is set to application/ace- Content-Format in messages containing a payload is set to
groupcomm+cbor, as defined in Section 8.2. application/ace-groupcomm+cbor, as defined in Section 8.2.
When the Client is already a group member, the Client can use the When the Client is already a group member, the Client can use the
interface at the KDC to perform the following actions: interface at the KDC to perform the following actions:
o The Client can (re-)get the current keying material, for cases * The Client can get the current keying material, for cases such as
such as expiration, loss or suspected mismatch, due to e.g. reboot expiration, loss or suspected mismatch, due to e.g. reboot or
or missed group rekeying. This is described in Section 4.3. missed group rekeying. This is described in Section 4.3.
o The Client can retrieve a new individual key, or new input * The Client can retrieve a new individual key, or new input
material to derive it. This is described in Section 4.4. material to derive it. This is described in Section 4.4.
o The Client can (re-)get the public keys of other group members, * The Client can get the public keys of other group members. This
e.g. if it is aware of new nodes joining the group after itself. is described in Section 4.5.
This is described in Section 4.5.
o The Client can (re-)get the policies currently enforced in the * The Client can get the group policies. This is described in
group. This is described in Section 4.7. Section 4.7.
o The Client can (re-)get the version number of the keying material * The Client can get the version number of the keying material
currently used in the group. This is described in Section 4.8. currently used in the group. This is described in Section 4.8.
o The Client can request to leave the group. This is further * The Client can request to leave the group. This is further
discussed in Section 4.9. discussed in Section 4.9.
Upon receiving a request from a Client, the KDC MUST check that it is Upon receiving a request from a Client, the KDC MUST check that it is
storing a valid access token from that Client for the group storing a valid access token from that Client for the group name
identifier associated to the endpoint. If that is not the case, i.e. associated to the endpoint. If that is not the case, i.e. the KDC
the KDC does not store a valid access token or this is not valid for does not store a valid access token or this is not valid for that
that Client for the group identifier at hand, the KDC MUST respond to Client for the group name, the KDC MUST respond to the Client with a
the Client with a 4.01 (Unauthorized) error message. 4.01 (Unauthorized) error message.
4.1. Interface at the KDC 4.1. Interface at the KDC
The KDC is configured with the following resources. Note that the The KDC is configured with the following resources. Note that the
root url-path "ace-group" given here are default names: root url-path "ace-group" given here are default names:
implementations are not required to use these names, and can define implementations are not required to use these names, and can define
their own instead. The Interface Description (if=) Link Target their own instead. The Interface Description (if=) Link Target
Attribute value ace-group is registered (Section 8.10) and can be Attribute value ace.group is registered (Section 8.10) and can be
used to describe this interface. used to describe this interface.
o /ace-group : this resource is fixed and indicates that this * /ace-group: this resource indicates that this specification is
specification is used. If other applications run on a KDC used. If other applications run on a KDC implementing this
implementing this specification and use this same resource, these specification and use this same resource, these applications will
applications will collide, and a mechanism will be needed to collide, and a mechanism will be needed to differentiate the
differentiate the endpoints. endpoints.
o /ace-group/GROUPNAME : one sub-resource to /ace-group is * /ace-group/GROUPNAME: one sub-resource to /ace-group is
implemented for each group the KDC manages. These resources are implemented for each group the KDC manages. These resources are
identified by the group identifiers of the groups the KDC manages identified by the group names of the groups the KDC manages (in
(in this example, the group identifier has value "GROUPNAME"). this example, the group name has value "GROUPNAME"). Each
These resources support GET and POST method. resource contains the symmetric group keying material for that
group. These resources support GET and POST method.
o /ace-group/GROUPNAME/pub-key : this sub-resource is fixed and * /ace-group/GROUPNAME/pub-key: this resource contains the public
supports GET and FETCH methods. keys of all group members. This resource supports GET and FETCH
methods.
o /ace-group/GROUPNAME/policies: this sub-resource is fixed and * /ace-group/GROUPNAME/policies: this resource contains the group
supports the GET method. policies. This resource supports the GET method.
o /ace-group/GROUPNAME/ctx-num: this sub-resource is fixed and * /ace-group/GROUPNAME/num: this resource contains the version
number for the symmetric group keying material. This sub-resource
supports the GET method. supports the GET method.
o /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace- * /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace-
group/GROUPNAME is implemented for each node in the group the KDC group/GROUPNAME is implemented for each node in the group the KDC
manages. These resources are identified by the node name (in this manages. These resources are identified by the node name (in this
example, the node name has value "NODENAME"). These resources example, the node name has value "NODENAME"). Each resource
support GET, PUT and DELETE methods. contains the group and individual keying material for that node.
These resources support GET, PUT and DELETE methods.
o /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one sub-resource to * /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one sub-resource to
/ace-group/GROUPNAME/nodes/NODENAME is implemented for each node /ace-group/GROUPNAME/nodes/NODENAME is implemented for each node
in the group the KDC manages. These resources are identified by in the group the KDC manages. These resources are identified by
the node name (in this example, the node name has value the node name (in this example, the node name has value
"NODENAME"). These resources support the POST method. "NODENAME"). Each resource contains the individual public keying
material for that node. These resources support the POST method.
The details for the handlers of each resource are given in the The details for the handlers of each resource are given in the
following sections. These endpoints are used to perform the following sections. These endpoints are used to perform the
operations introduced in Section 4. operations introduced in Section 4.
4.1.1. ace-group 4.1.1. ace-group
No handlers are implemented for this resource. No handlers are implemented for this resource.
4.1.2. ace-group/GROUPNAME 4.1.2. ace-group/GROUPNAME
This resource implements GET and POST handlers. This resource implements GET and POST handlers.
4.1.2.1. POST Handler 4.1.2.1. POST Handler
The POST handler adds the public key of the client to the list of the The POST handler adds the public key of the client to the list of the
group members' public keys and returns the symmetric group keying group members' public keys and returns the symmetric group keying
material for the group identified by "GROUPNAME". material for the group identified by "GROUPNAME". Note that the
group joining exchange is done by the client via this operation, as
described in Section 4.2.
The handler expects a request with payload formatted as a CBOR map The handler expects a request with payload formatted as a CBOR map
which MAY contain the following fields, which, if included, MUST have which MAY contain the following fields, which, if included, MUST have
the corresponding values: the corresponding values:
o 'scope', with value the specific resource at the KDC that the * 'scope', with value the specific resource at the KDC that the
Client is authorized to access, i.e. group or topic identifier, Client is authorized to access, i.e. group or topic identifier,
and role(s). This value is a CBOR byte string encoding one scope and role(s). This value is a CBOR byte string encoding one scope
entry, as defined in Section 3.1. entry, as defined in Section 3.1.
o 'get_pub_keys', if the Client wishes to receive the public keys of * 'get_pub_keys', if the Client wishes to receive the public keys of
the other nodes in the group from the KDC. The value is an empty the other nodes in the group from the KDC. This parameter may be
CBOR array. This parameter may be present if the KDC stores the present if the KDC stores the public keys of the nodes in the
public keys of the nodes in the group and distributes them to the group and distributes them to the Client; it is useless to have
Client; it is useless to have here if the set of public keys of here if the set of public keys of the members of the group is
the members of the group is known in another way, e.g. it was known in another way, e.g. it was provided by the AS. Note that
provided by the AS. including this parameter may result in a large message size for
the following response, which can be inconvenient for resource-
constrained devices. The parameter's value is a non-empty CBOR
array containing two CBOR arrays:
o 'client_cred', with value the public key or certificate of the - The first array contains zero or more roles (or combination of
roles) of group members for the group identified by
"GROUPNAME". The Client indicates that it wishes to receive
the public keys of all nodes having these roles. If empty, it
means the client wishes to receive the public keys of all
nodes.
- The second array is empty.
The CDDL definition [RFC8610] of 'get_pub_keys' is given in
Figure 5 using as example encoding: node identifier encoded as
byte string, role identifier as text string, and combination of
roles encoded as a CBOR array of roles. Note that the array ids
is empty for this handler, but is not necessarily empty for the
value of "get_pub_keys" received by the handler of FETCH to ace-
group/GROUPNAME/pub-key (see Section 4.1.3.1).
id = bstr
role = tstr
comb_role = [ 2*role ]
get_pub_keys = [ [ *(role / comb_role) ], [ *id ] ]
Figure 5: CDLL definition of get_pub_keys, using as example node
identifier encoded as bstr and role as tstr
* 'client_cred', with value the public key or certificate of the
Client, encoded as a CBOR byte string. This field contains the Client, encoded as a CBOR byte string. This field contains the
public key of the Client. This field is used if the KDC is public key of the Client. This field is used if the KDC is
managing (collecting from/distributing to the Client) the public managing (collecting from/distributing to the Client) the public
keys of the group members, and if the Client's role in the group keys of the group members, and if the Client's role in the group
will require for it to send messages to the group. The default will require for it to send messages to one or more group members.
encoding for public keys is COSE Keys. Alternative specific The default encoding for public keys is COSE Keys. Alternative
encodings of this parameter MAY be defined in applications of this specific encodings of this parameter MAY be defined in
specification (OPT1 in Appendix A). applications of this specification (OPT1 in Appendix A).
o 'cnonce', with the same encoding as defined for the "cnonce" * 'cnonce', with the same encoding as defined for the "cnonce"
parameter of Ace, in Section 5.1.2 of [I-D.ietf-ace-oauth-authz], parameter of Ace, in Section 5.1.2 of [I-D.ietf-ace-oauth-authz],
and including a dedicated nonce N_C generated by the Client. This and including a dedicated nonce N_C generated by the Client. This
parameter MUST be present if the 'client_cred' parameter is parameter MUST be present if the 'client_cred' parameter is
present. present.
o 'client_cred_verify', encoded as a CBOR byte string. This * 'client_cred_verify', encoded as a CBOR byte string. This
parameter MUST be present if the 'client_cred' parameter is parameter MUST be present if the 'client_cred' parameter is
present and no public key associated to the client's token can be present and no public key associated to the client's token can be
retrieved for that group. This parameter contains a signature retrieved for that group. This parameter contains a signature
computed by the Client over the scope concatenated with N_S computed by the Client over the scope concatenated with N_S
concatenated with N_C, where: concatenated with N_C, where:
* scope is the byte string specified in the 'scope parameter - scope is the byte string specified in the 'scope parameter
above'. above'.
* N_S is the challenge received from the KDC in the - N_S is the challenge received from the KDC in the
'kdcchallenge' parameter of the 2.01 (Created) response to the 'kdcchallenge' parameter of the 2.01 (Created) response to the
token POST request (see Section 3.3). token POST request (see Section 3.3).
* N_C is the nonce generated by the Client and specified in the - N_C is the nonce generated by the Client and specified in the
'cnonce' parameter above. 'cnonce' parameter above.
If the token is not being posted (e.g. if it is used directly to If the token was not posted (e.g. if it is used directly to
validate TLS instead), it is REQUIRED of the specific profile to validate TLS instead), it is REQUIRED of the specific profile to
define how the challenge N_S is generated (REQ17). The Client define how the challenge N_S is generated (REQ17). The Client
computes the signature by using its own private key, whose computes the signature by using its own private key, whose
corresponding public key is either directly specified in the corresponding public key is either directly specified in the
'client_cred' parameter or included in the certificate specified in 'client_cred' parameter or included in the certificate specified
the 'client_cred' parameter. in the 'client_cred' parameter.
o 'pub_keys_repos', can be present if a certificate is present in * 'pub_keys_repos', can be present if a certificate is present in
the 'client_cred' field, with value the URI of the certificate of the 'client_cred' field, with value the URI of the certificate of
the Client. This parameter is encoded as a CBOR text string. the Client. This parameter is encoded as a CBOR text string.
Alternative specific encodings of this parameter MAY be defined in Alternative specific encodings of this parameter MAY be defined in
applications of this specification (OPT3). applications of this specification (OPT3).
o 'control_path', with value a full URI, encoded as a CBOR text * 'control_path', with value a full URI, encoded as a CBOR text
string. If 'control_path' is supported by the Client, the Client string. If 'control_path' is supported by the Client, the Client
acts as a CoAP server and hosts a resource at this specific URI. acts as a CoAP server and hosts a resource at this specific URI.
The KDC MAY use this URI to send CoAP requests to the Client The KDC MAY use this URI to send CoAP requests to the Client
(acting as CoAP server in this exchange), for example for (acting as CoAP server in this exchange), for example for
individual provisioning of new keying material when performing a individual provisioning of new keying material when performing a
group rekeying (see Section 4.3), or to inform the Client of its group rekeying (see Section 4.3), or to inform the Client of its
removal from the group Section 5. If the KDC does not implement removal from the group Section 5. If the KDC does not implement
mechanisms using this resource, it can just ignore this parameter. mechanisms using this resource, it can just ignore this parameter.
Other additional functionalities of this resource MAY be defined Other additional functionalities of this resource MAY be defined
in application profiles of this specifications (OPT9). In in application profiles of this specifications (OPT9). In
particular, this resource is intended for communications particular, this resource is intended for communications
concerning exclusively the group or topic specified in the 'scope' concerning exclusively the group or topic specified in the 'scope'
parameter. parameter.
The handler verifies that the group identifier of the /ace-group/ The handler verifies that the group name of the /ace-group/GROUPNAME
GROUPNAME path is a subset of the 'scope' stored in the access token path is a subset of the 'scope' stored in the access token associated
associated to this client. If verification fails, the KDC MUST to this client. If verification fails, the KDC MUST respond with a
respond with a 4.01 (Unauthorized) error message. The KDC MAY set 4.01 (Unauthorized) error message. The KDC MAY respond with an AS
the payload with the 'sign_info' and 'pub_key_enc' parameter, Request Creation Hints, as defined in Section 5.1.2 of
formatted as 'sign_info_res' and 'pub_key_enc_res' in the payload of [I-D.ietf-ace-oauth-authz]. Note that in this case, the content
the 2.01 (Created) response to the Token Post as defined in format MUST be set to application/ace+cbor.
Section 3.3. Note that in this case, the content format MUST be set
to application/ace+cbor.
If the request is not formatted correctly (e.g. unknown, not-expected If the request is not formatted correctly (i.e. required fields non
fields present, or expected fields with incorrect format), the received or received with incorrect format), the handler MUST respond
handler MUST respond with a 4.00 (Bad Request) error message. The with a 4.00 (Bad Request) error message. The response MAY contain a
response MAY contain a CBOR map in the payload with ace+cbor format, CBOR map in the payload with ace+cbor format, e.g. it could send back
e.g. it could send back "pub_key_enc" set to Null if the Client sent 'sign_info_res' with 'pub_key_enc' set to Null if the Client sent its
its own public key and the KDC is not set to store public keys of the own public key and the KDC is not set to store public keys of the
group members. Application profiles MAY define optional or mandatory group members. If the request contained unknown or non-expected
fields present, the handler MUST silently drop them and continue
processing. Application profiles MAY define optional or mandatory
payload formats for specific error cases (OPT6). payload formats for specific error cases (OPT6).
If the KDC stores the group members' public keys, the handler checks If the KDC stores the group members' public keys, the handler checks
if one public key is already associated to the access token received if one is included in the the 'client_cred' field, retrieves it and
(see Section 4.2 for an example) and to the group identified by associates it to the access token received, after verifications
"GROUPNAME". If that is not the case, it retrieves it from the succeeded. In particular, the KDC verifies:
'client_cred' field and associates it to the access token received,
after verifications succed. In particular, the KDC verifies:
o that such public key has an acceptable format for the group * that such public key has an acceptable format for the group
identified by "GROUPNAME", i.e. it is encoded as expected and is identified by "GROUPNAME", i.e. it is encoded as expected and is
compatible with the signature algorithm and possible associated compatible with the signature algorithm and possible associated
parameters. If that cannot be verified, it is RECOMMENDED that parameters. If that cannot be verified, it is RECOMMENDED that
the handler stops the process and responds with a 4.00 (Bad the handler stops the process and responds with a 4.00 (Bad
Request) error message. Applications profiles MAY define Request) error message. Applications profiles MAY define
alternatives (OPT5). alternatives (OPT5).
o that the signature contained in "client_cred_verify" passes * that the signature contained in "client_cred_verify" passes
verification. If that cannot be verified, the handler MUST verification. If that cannot be verified, the handler MUST
respond with a 4.00 (Bad Request) error message, and if the token respond with a 4.00 (Bad Request) error message, and if the token
was posted (see REQ17) including the 'kdcchallenge' associated to was posted (see REQ17) including the 'kdcchallenge' associated to
this Client (see Section 3.3) if it can be retrieved, or otherwise this Client (see Section 3.3) if it can be retrieved, or otherwise
newly generated, in a CBOR map in the payload. This error newly generated, in a CBOR map in the payload. This error
response MUST also have Content-Format "application/ace+cbor". response MUST also have Content-Format "application/ace+cbor".
If one public key is already associated to the access token and to If one public key is already associated to the access token and to
that group, but the 'client_cred' is populated with a different that group, but the 'client_cred' is populated with a different
public key, the handler MUST delete the previous one and replace it public key, the handler MUST delete the previous one and replace it
with this one, after verifying the points above. with this one, after verifying the points above.
If no public key is included in the 'client_cred' field, the handler
checks if one public key is already associated to the access token
received (see Section 4.2 for an example) and to the group identified
by "GROUPNAME". If that is not the case, the handler responds with a
4.00 Bad Request error response.
If the token was posted but the KDC cannot retrieve the If the token was posted but the KDC cannot retrieve the
'kdcchallenge' associated to this Client (see Section 3.3), the KDC 'kdcchallenge' associated to this Client (see Section 3.3), the KDC
MUST respond with a 4.00 Bad Request error response, including a MUST respond with a 4.00 Bad Request error response, including a
newly generated 'kdcchallenge' in a CBOR map in the payload. This newly generated 'kdcchallenge' in a CBOR map in the payload. This
error response MUST also have Content-Format "application/ace+cbor". error response MUST also have Content-Format "application/ace+cbor".
If all verifications succeed, the handler: If all verifications succeed, the handler:
o Adds the node to the list of current members of the group. * Adds the node to the list of current members of the group.
o Assigns a name NODENAME to the node, and creates a sub-resource to * Assigns a name NODENAME to the node, and creates a sub-resource to
/ace-group/GROUPNAME/ at the KDC (e.g. "/ace- /ace-group/GROUPNAME/ at the KDC (e.g. "/ace-
group/GROUPNAME/nodes/NODENAME"). group/GROUPNAME/nodes/NODENAME").
o Associates the identifier "NODENAME" with the access token and the * Associates the identifier "NODENAME" with the access token and the
secure session for that node. secure session for that node.
o If the KDC manages public keys for group members: * If the KDC manages public keys for group members:
* Adds the retrieved public key of the node to the list of public - Adds the retrieved public key of the node to the list of public
keys stored for the group identified by "GROUPNAME" keys stored for the group identified by "GROUPNAME"
* Associates the node's public key with its access token and the - Associates the node's public key with its access token and the
group identified by "GROUPNAME", if such association did not group identified by "GROUPNAME", if such association did not
already exist. already exist.
o Returns a 2.01 (Created) message containing the symmetric group * Returns a 2.01 (Created) message containing the symmetric group
keying material, the group policies and all the public keys of the keying material, the group policies and all the public keys of the
current members of the group, if the KDC manages those and the current members of the group, if the KDC manages those and the
Client requested them. Client requested them.
The response message also contains the URI path to the sub-resource The response message also contains the URI path to the sub-resource
created for that node in a Location-Path CoAP option. The payload of created for that node in a Location-Path CoAP option. The payload of
the response is formatted as a CBOR map which MUST contain the the response is formatted as a CBOR map which MUST contain the
following fields and values: following fields and values:
o 'gkty', identifying the key type of the 'key' parameter. The set * 'gkty', identifying the key type of the 'key' parameter. The set
of values can be found in the "Key Type" column of the "ACE of values can be found in the "Key Type" column of the "ACE
Groupcomm Key" Registry. Implementations MUST verify that the key Groupcomm Key" Registry. Implementations MUST verify that the key
type matches the application profile being used, if present, as type matches the application profile being used, if present, as
registered in the "ACE Groupcomm Key" registry. registered in the "ACE Groupcomm Key" registry.
o 'key', containing the keying material for the group communication, * 'key', containing the keying material for the group communication,
or information required to derive it. or information required to derive it.
o 'num', containing the version number of the keying material for * 'num', containing the version number of the keying material for
the group communication, formatted as an integer. The initial the group communication, formatted as an integer. This is a
version MUST be set to 0 at the KDC. This is a strictly monotonic strictly monotonic increasing field. The application profile MUST
increasing field. define the initial version number (REQ19).
The exact format of the 'key' value MUST be defined in applications The exact format of the 'key' value MUST be defined in applications
of this specification (REQ7), as well as accepted values of 'gkty' by of this specification (REQ7), as well as accepted values of 'gkty' by
the application (REQ8). Additionally, documents specifying the key the application (REQ8). Additionally, documents specifying the key
format MUST register it in the "ACE Groupcomm Key" registry defined format MUST register it in the "ACE Groupcomm Key" registry defined
in Section 8.6, including its name, type and application profile to in Section 8.6, including its name, type and application profile to
be used with. be used with.
+----------+----------------+---------+-------------------------+ +----------+----------------+---------+-------------------------+
| Name | Key Type Value | Profile | Description | | Name | Key Type Value | Profile | Description |
+----------+----------------+---------+-------------------------+ +----------+----------------+---------+-------------------------+
| Reserved | 0 | | This value is reserved | | Reserved | 0 | | This value is reserved |
+----------+----------------+---------+-------------------------+ +----------+----------------+---------+-------------------------+
Figure 5: Key Type Values Figure 6: Key Type Values
Optionally, the response MAY contain the following parameters, which,
if included, MUST have the corresponding values:
o 'ace-groupcomm-profile', with value a CBOR integer that MUST be The response SHOULD contain the following parameter:
used to uniquely identify the application profile for group
communication. Applications of this specification MUST register
an application profile identifier and the related value for this
parameter in the "ACE Groupcomm Profile" Registry (REQ12).
o 'exp', with value the expiration time of the keying material for * 'exp', with value the expiration time of the keying material for
the group communication, encoded as a CBOR unsigned integer. This the group communication, encoded as a CBOR unsigned integer. This
field contains a numeric value representing the number of seconds field contains a numeric value representing the number of seconds
from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, from 1970-01-01T00:00:00Z UTC until the specified UTC date/time,
ignoring leap seconds, analogous to what specified for NumericDate ignoring leap seconds, analogous to what specified for NumericDate
in Section 2 of [RFC7519]. Group members MUST stop using the in Section 2 of [RFC7519]. Group members MUST stop using the
keying material to protect outgoing messages and retrieve new keying material to protect outgoing messages and retrieve new
keying material at the time indicated in this field. keying material at the time indicated in this field.
o 'exp_delta', with value the time interval (starting at 'exp') Optionally, the response MAY contain the following parameters, which,
during which the keying material for the group communication can if included, MUST have the corresponding values:
still be used for verifying incoming messages, encoded as a CBOR
unsigned integer. This field contains a numeric value
representing the number of seconds from 'exp' until the specified
UTC date/time after which group members MUST stop using the keying
material to verify incoming messages.
o 'pub_keys', may only be present if 'get_pub_keys' was present in * 'ace-groupcomm-profile', with value a CBOR integer that MUST be
used to uniquely identify the application profile for group
communication. Applications of this specification MUST register
an application profile identifier and the related value for this
parameter in the "ACE Groupcomm Profile" Registry (REQ12).
* 'pub_keys', may only be present if 'get_pub_keys' was present in
the request. This parameter is a CBOR byte string, which encodes the request. This parameter is a CBOR byte string, which encodes
the public keys of all the group members paired with the the public keys of all the group members paired with the
respective member identifiers. The default encoding for public respective member identifiers. The default encoding for public
keys is COSE Keys, so the default encoding for 'pub_keys' is a keys is COSE Keys, so the default encoding for 'pub_keys' is a
CBOR byte string wrapping a COSE_KeySet (see CBOR byte string wrapping a COSE_KeySet (see
[I-D.ietf-cose-rfc8152bis-struct]), which contains the public keys [I-D.ietf-cose-rfc8152bis-struct]), which contains the public keys
of all the members of the group. In particular, each COSE Key in of all the members of the group. In particular, each COSE Key in
the COSE_KeySet includes the identifier of the corresponding group the COSE_KeySet includes the identifier of the corresponding group
member as value of its 'kid' key parameter. Alternative specific member as value of its 'kid' key parameter. Alternative specific
encodings of this parameter MAY be defined in applications of this encodings of this parameter MAY be defined in applications of this
specification (OPT1). The specific format of the identifiers of specification (OPT1). The specific format of the identifiers of
group members MUST be specified in the application profile (REQ9). group members MUST be specified in the application profile (REQ9).
o 'peer_roles', MUST be present if 'pub_keys' is present. This * 'peer_roles', MUST be present if 'pub_keys' is present. This
parameter is a CBOR array of n elements, with n the number of parameter is a CBOR array of n elements, with n the number of
members in the group (and number of public keys included in the members in the group (and number of public keys included in the
'pub_keys' parameter). The i-th element of the array specifies 'pub_keys' parameter). The i-th element of the array specifies
the role (or CBOR array of roles) that the group member associated the role (or CBOR array of roles) that the group member associated
to the i-th public key in 'pub_keys' has in the group. In to the i-th public key in 'pub_keys' has in the group. In
particular, each array element is encoded as the role element of a particular, each array element is encoded as the role element of a
scope entry, as defined in Section 3.1. scope entry, as defined in Section 3.1.
o 'group_policies', with value a CBOR map, whose entries specify how * 'group_policies', with value a CBOR map, whose entries specify how
the group handles specific management aspects. These include, for the group handles specific management aspects. These include, for
instance, approaches to achieve synchronization of sequence instance, approaches to achieve synchronization of sequence
numbers among group members. The elements of this field are numbers among group members. The elements of this field are
registered in the "ACE Groupcomm Policy" Registry. This registered in the "ACE Groupcomm Policy" Registry. This
specification defines the two elements "Sequence Number specification defines the three elements "Sequence Number
Synchronization Method" and "Key Update Check Interval", which are Synchronization Method", "Key Update Check Interval" and
summarized in Figure 6. Application profiles that build on this "Expiration Delta", which are summarized in Figure 7. Application
document MUST specify the exact content format of included map profiles that build on this document MUST specify the exact
entries (REQ14). content format and default value of included map entries (REQ14).
+--------------+-------+----------|--------------------|------------+ +--------------+-------+----------|--------------------|------------+
| Name | CBOR | CBOR | Description | Reference | | Name | CBOR | CBOR | Description | Reference |
| | label | type | | | | | label | type | | |
|--------------+-------+----------|--------------------|------------| |--------------+-------+----------|--------------------|------------|
| Sequence | TBD1 | tstr/int | Method for a re- | [[this | | Sequence | TBD1 | tstr/int | Method for a re- | [[this |
| Number | | | cipient node to | document]] | | Number | | | cipient node to | document]] |
| Synchroniza- | | | synchronize with | | | Synchroniza- | | | synchronize with | |
| tion Method | | | sequence numbers | | | tion Method | | | sequence numbers | |
| | | | of a sender node. | | | | | | of a sender node. | |
skipping to change at page 22, line 26 skipping to change at page 23, line 26
| | | | column of the | | | | | | column of the | |
| | | | Sequence Number | | | | | | Sequence Number | |
| | | | Synchronization | | | | | | Synchronization | |
| | | | Method registry | | | | | | Method registry | |
| | | | | | | | | | | |
| Key Update | TBD2 | int | Polling interval | [[this | | Key Update | TBD2 | int | Polling interval | [[this |
| Check | | | in seconds, to | document]] | | Check | | | in seconds, to | document]] |
| Interval | | | check for new | | | Interval | | | check for new | |
| | | | keying material at | | | | | | keying material at | |
| | | | the KDC | | | | | | the KDC | |
| | | | | |
| Expiration | TBD3 | uint | Number of seconds | [[this |
| Delta | | | from 'exp' until | document]] |
| | | | the specified UTC | |
| | | | date/time after | |
| | | | which group members| |
| | | | MUST stop using the| |
| | | | keying material to | |
| | | | verify incoming | |
| | | | messages. | |
+--------------+-------+----------|--------------------|------------+ +--------------+-------+----------|--------------------|------------+
Figure 6: ACE Groupcomm Policies Figure 7: ACE Groupcomm Policies
o 'mgt_key_material', encoded as a CBOR byte string and containing * 'mgt_key_material', encoded as a CBOR byte string and containing
the administrative keying material to participate in the group the administrative keying material to participate in the group
rekeying performed by the KDC. The application profile MUST rekeying performed by the KDC. The application profile MUST
define if this field is used, and if used then MUST specify the define if this field is used, and if used then MUST specify the
exact format and content which depend on the specific rekeying exact format and content which depend on the specific rekeying
scheme used in the group. If the usage of 'mgt_key_material' is scheme used in the group. If the usage of 'mgt_key_material' is
indicated and its format defined for a specific key management indicated and its format defined for a specific key management
scheme, that format must explicitly indicate the key management scheme, that format must explicitly indicate the key management
scheme itself. If a new rekeying scheme is defined to be used for scheme itself. If a new rekeying scheme is defined to be used for
an existing 'mgt_key_material' in an existing profile, then that an existing 'mgt_key_material' in an existing profile, then that
profile will have to be updated accordingly, especially with profile will have to be updated accordingly, especially with
skipping to change at page 23, line 12 skipping to change at page 24, line 19
CBOR labels for these fields are defined in Section 6. CBOR labels for these fields are defined in Section 6.
4.1.2.2. GET Handler 4.1.2.2. GET Handler
The GET handler returns the symmetric group keying material for the The GET handler returns the symmetric group keying material for the
group identified by "GROUPNAME". group identified by "GROUPNAME".
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/ The handler verifies that the group name of the /ace-group/GROUPNAME
GROUPNAME path is a subset of the 'scope' stored in the access token path is a subset of the 'scope' stored in the access token associated
associated to this client. If verification fails, the KDC MUST to this client. If verification fails, the KDC MUST respond with a
respond with a 4.01 (Unauthorized) error message. The KDC MAY set 4.01 (Unauthorized) error message. The KDC MAY respond with an AS
the payload with the 'sign_info' and 'pub_key_enc' parameter, Request Creation Hints, as defined in Section 5.1.2 of
formatted as 'sign_info_res' and 'pub_key_enc_res' in the payload of [I-D.ietf-ace-oauth-authz]. Note that in this case, the content
the 2.01 (Created) response to the Token Post as defined in format MUST be set to application/ace+cbor.
Section 3.3. Note that in this case, the content format MUST be set
to application/ace+cbor.
Additionally, the handler verifies that the node is a current member Additionally, the handler verifies that the node is a current member
of the group. If verification fails, the KDC MUST respond with a of the group. If verification fails, the KDC MUST respond with a
4.00 (Bad Request) error message. 4.00 (Bad Request) error message.
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing the symmetric group keying material. The payload message containing the symmetric group keying material. The payload
of the response is formatted as a CBOR map which MUST contain the of the response is formatted as a CBOR map which MUST contain the
parameters 'gkty','key' and 'num' specified in Section 4.1.2.1. parameters 'gkty','key' and 'num' specified in Section 4.1.2.1.
The payload MAY also include the parameters 'ace-groupcomm-profile', The payload MAY also include the parameters 'ace-groupcomm-profile',
'exp', 'exp_delta' and 'mgt_key_material' parameters specified in 'exp', and 'mgt_key_material' parameters specified in
Section 4.1.2.1. Section 4.1.2.1.
4.1.3. ace-group/GROUPNAME/pub-key 4.1.3. ace-group/GROUPNAME/pub-key
If the KDC does not maintain public keys for the group, the handler
for any request on this resource returns a 4.05 (Method Not Allowed)
error message. If it does, the rest of this section applies.
This resource implements GET and FETCH handlers. This resource implements GET and FETCH handlers.
4.1.3.1. FETCH Handler 4.1.3.1. FETCH Handler
The FETCH handler receives identifiers of group members for the group The FETCH handler receives identifiers of group members for the group
identified by "GROUPNAME" and returns the public keys of such group identified by "GROUPNAME" and returns the public keys of such group
members. members.
The handler expects a request with payload formatted as a CBOR map. The handler expects a request with payload formatted as a CBOR map.
The payload of this request is a CBOR Map that MUST contain the The payload of this request is a CBOR Map that MUST contain the
following fields: following fields:
o 'get_pub_keys', whose value is a non-empty CBOR array containing * 'get_pub_keys', whose value is encoded as in Section 4.1.2.1 with
two CBOR arrays: the following modification:
* The first array contains zero or more roles (or combination of
roles) of group members for the group identified by
"GROUPNAME".
* The second array contains zero or more identifiers of group
members for the group identified by "GROUPNAME".
The CDDL definition [RFC8610] of 'get_pub_keys' is given in Figure 7
using as example encoding: node identifier encoded as byte string,
role identifier as text string, and combination of roles encoded as a
CBOR array of roles. Note that the empty array is not valid for this
handler, but is valid for the value of "get_pub_keys" received by the
handler of POST to ace-group/GROUPNAME (see Section 4.1.2.1).
id = bstr
role = tstr
comb_role = [ 2*role ]
get_pub_keys = [ [ *(role / comb_role) ], [ *id ] ] / [ ]
Figure 7: CDLL definition of get_pub_keys, using as example node - The second array contains zero or more identifiers of group
identifier encoded as bstr and role as tstr members for the group identified by "GROUPNAME". The Client
indicates that it wishes to receive the public keys of all
nodes having these identifiers.
The specific format of public keys as well as identifiers, roles and The specific format of public keys as well as identifiers, roles and
combination of roles of group members MUST be specified by the combination of roles of group members MUST be specified by the
application profile (OPT1, REQ2, REQ9). application profile (OPT1, REQ2, REQ9).
The handler verifies that the group identifier of the /ace-group/ The handler verifies that the group name of the /ace-group/GROUPNAME
GROUPNAME path is a subset of the 'scope' stored in the access token path is a subset of the 'scope' stored in the access token associated
associated to this client. If verification fails, the KDC MUST to this client. If verification fails, the KDC MUST respond with a
respond with a 4.01 (Unauthorized) error message. 4.01 (Unauthorized) error message.
If verification succeeds, the handler identifies the public keys of If verification succeeds, the handler identifies the public keys of
the current group members for which either: - the role identifier the current group members for which either:
matches with one of those indicated in the request (including the
exact combination of roles requested), or - the identifier matches * the role identifier matches with one of those indicated in the
with one of those indicated in the request. request; note that the request can contain a "combination of
roles", where the handler select all group members who have all
roles included in the combination.
* the identifier matches with one of those indicated in the request.
Then, the handler returns a 2.05 (Content) message response with Then, the handler returns a 2.05 (Content) message response with
payload formatted as a CBOR map, containing only the 'pub_keys' and payload formatted as a CBOR map, containing only the 'pub_keys' and
'peer_roles' parameters from Section 4.1.2.1. In particular, 'peer_roles' parameters from Section 4.1.2.1. In particular,
'pub_keys' encodes the list of public keys of those group members 'pub_keys' encodes the list of public keys of those group members
including the respective member identifiers, while 'peer_roles' including the respective member identifiers, while 'peer_roles'
encodes their respective role (or CBOR array of roles) in the group. encodes their respective role (or CBOR array of roles) in the group.
The specific format of public keys as well as of identifiers of group
members is specified by the application profile (OPT1, REQ9).
If the KDC does not store any public key associated with the If the KDC does not store any public key associated with the
specified member identifiers, the handler returns a response with specified member identifiers, the handler returns a response with
payload formatted as a CBOR byte string of zero length. The specific payload formatted as a CBOR byte string of zero length.
format of public keys as well as of identifiers of group members is
specified by the application profile (OPT1, REQ9).
The handler MAY enforce one of the following policies, in order to The handler MAY enforce one of the following policies, in order to
handle possible identifiers that are included in the 'get_pub_keys' handle possible identifiers that are included in the 'get_pub_keys'
parameter of the request but are not associated to any current group parameter of the request but are not associated to any current group
member. Such a policy MUST be specified by the application profile member. Such a policy MUST be specified by the application profile
(REQ13) (REQ13)
o The KDC silently ignores those identifiers. * The KDC silently ignores those identifiers.
o The KDC retains public keys of group members for a given amount of * The KDC retains public keys of group members for a given amount of
time after their leaving, before discarding them. As long as such time after their leaving, before discarding them. As long as such
public keys are retained, the KDC provides them to a requesting public keys are retained, the KDC provides them to a requesting
Client. Client.
Note that this resource handlers only verify that the node is Note that this resource handler only verifies that the node is
authorized by the AS to access this resource. Nodes that are not authorized by the AS to access this resource. Nodes that are not
members of the group but are authorized to do signature verifications members of the group but are authorized to do signature verifications
on the group messages may be allowed to access this resource, if the on the group messages may be allowed to access this resource, if the
application needs it. application needs it.
4.1.3.2. GET Handler 4.1.3.2. GET Handler
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/ The handler verifies that the group name of the /ace-group/GROUPNAME
GROUPNAME path is a subset of the 'scope' stored in the access token path is a subset of the 'scope' stored in the access token associated
associated to this client. If verification fails, the KDC MUST to this client. If verification fails, the KDC MUST respond with a
respond with a 4.01 (Unauthorized) error message. 4.01 (Unauthorized) error message.
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing the public keys of all the current group members, message containing the public keys of all the current group members,
for the group identified by "GROUPNAME". The payload of the response for the group identified by "GROUPNAME". The payload of the response
is formatted as a CBOR map, containing only the 'pub_keys' and is formatted as a CBOR map, containing only the 'pub_keys' and
'peer_roles' parameters from Section 4.1.2.1. In particular, 'peer_roles' parameters from Section 4.1.2.1. In particular,
'pub_keys' encodes the list of public keys of those group members 'pub_keys' encodes the list of public keys of those group members
including the respective member identifiers, while 'peer_roles' including the respective member identifiers, while 'peer_roles'
encodes their respective role (or CBOR array of roles) in the group. encodes their respective role (or CBOR array of roles) in the group.
If the KDC does not store any public key for the group, the handler If the KDC does not store any public key for the group, the handler
returns a response with payload formatted as a CBOR byte string of returns a response with payload formatted as a CBOR byte string of
zero length. The specific format of public keys as well as of zero length. The specific format of public keys as well as of
identifiers of group members is specified by the application profile identifiers of group members is specified by the application profile
(OPT1, REQ9). (OPT1, REQ9).
Note that this resource handlers only verify that the node is Note that this resource handler only verifies that the node is
authorized by the AS to access this resource. Nodes that are not authorized by the AS to access this resource. Nodes that are not
members of the group but are authorized to do signature verifications members of the group but are authorized to do signature verifications
on the group messages may be allowed to access this resource, if the on the group messages may be allowed to access this resource, if the
application needs it. application needs it.
4.1.4. ace-group/GROUPNAME/policies 4.1.4. ace-group/GROUPNAME/policies
This resource implements a GET handler. This resource implements a GET handler.
4.1.4.1. GET Handler 4.1.4.1. GET Handler
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/ The handler verifies that the group name of the /ace-group/GROUPNAME
GROUPNAME path is a subset of the 'scope' stored in the access token path is a subset of the 'scope' stored in the access token associated
associated to this client. If verification fails, the KDC MUST to this client. If verification fails, the KDC MUST respond with a
respond with a 4.01 (Unauthorized) error message. 4.01 (Unauthorized) error message.
Additionally, the handler verifies that the node is a current member Additionally, the handler verifies that the node is a current member
of the group. If verification fails, the KDC MUST respond with a of the group. If verification fails, the KDC MUST respond with a
4.00 (Bad Request) error message. 4.00 (Bad Request) error message.
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing the list of policies for the group identified by message containing the list of policies for the group identified by
"GROUPNAME". The payload of the response is formatted as a CBOR map "GROUPNAME". The payload of the response is formatted as a CBOR map
including only the parameter 'group_policies' defined in including only the parameter 'group_policies' defined in
Section 4.1.2.1 and specifying the current policies in the group. If Section 4.1.2.1 and specifying the current policies in the group. If
the KDC does not store any policy, the payload is formatted as a the KDC does not store any policy, the payload is formatted as a
zero-length CBOR byte string. zero-length CBOR byte string.
The specific format and meaning of group policies MUST be specified The specific format and meaning of group policies MUST be specified
in the application profile (REQ14). in the application profile (REQ14).
4.1.5. ace-group/GROUPNAME/ctx-num 4.1.5. ace-group/GROUPNAME/num
This resource implements a GET handler. This resource implements a GET handler.
4.1.5.1. GET Handler 4.1.5.1. GET Handler
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/ The handler verifies that the group name of the /ace-group/GROUPNAME
GROUPNAME path is a subset of the 'scope' stored in the access token path is a subset of the 'scope' stored in the access token associated
associated to this client. If verification fails, the KDC MUST to this client. If verification fails, the KDC MUST respond with a
respond with a 4.01 (Unauthorized) error message. 4.01 (Unauthorized) error message.
Additionally, the handler verifies that the node is a current member Additionally, the handler verifies that the node is a current member
of the group. If verification fails, the KDC MUST respond with a of the group. If verification fails, the KDC MUST respond with a
4.00 (Bad Request) error message. 4.00 (Bad Request) error message.
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing an integer that represents the version number of message containing an integer that represents the version number of
the symmetric group keying material. This number is incremented on the symmetric group keying material. This number is incremented on
the KDC every time the KDC updates the symmetric group keying the KDC every time the KDC updates the symmetric group keying
material. The payload of the response is formatted as a CBOR material, before the new keying material is distributed. This number
integer. is stored in persistent storage.
The payload of the response is formatted as a CBOR integer.
4.1.6. ace-group/GROUPNAME/nodes/NODENAME 4.1.6. ace-group/GROUPNAME/nodes/NODENAME
This resource implements GET, PUT and DELETE handlers. This resource implements GET, PUT and DELETE handlers.
4.1.6.1. PUT Handler 4.1.6.1. PUT Handler
The PUT handler is used to get the KDC to produce and return The PUT handler is used to get the KDC to produce and return
individual keying material to protect outgoing messages for the node individual keying material to protect outgoing messages for the node
(identified by "NODENAME") for the group identified by "GROUPNAME". (identified by "NODENAME") for the group identified by "GROUPNAME".
The handler expects a request with empty payload. The handler expects a request with empty payload.
The handler verifies that the group identifier of the /ace-group/ The handler verifies that the group name of the /ace-group/GROUPNAME
GROUPNAME path is a subset of the 'scope' stored in the access token path is a subset of the 'scope' stored in the access token associated
associated to this client, identified by "NODENAME". If verification to this client, identified by "NODENAME". If verification fails, the
fails, the KDC MUST respond with a 4.01 (Unauthorized) error message. KDC MUST respond with a 4.01 (Unauthorized) error message.
Additionally, the handler verifies that the node is a current member Additionally, the handler verifies that the node is a current member
of the group. If verification fails, the KDC MUST respond with a of the group. If verification fails, the KDC MUST respond with a
4.00 (Bad Request) error message. 4.00 (Bad Request) error message.
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing newly-generated individual keying material for the message containing newly-generated individual keying material for the
Client, or information enabling the Client to derive it. The payload Client, or information enabling the Client to derive it. The payload
of the response is formatted as a CBOR map. The specific format of of the response is formatted as a CBOR map. The specific format of
newly-generated individual keying material for group members, or of newly-generated individual keying material for group members, or of
the information to derive it, and corresponding CBOR label, MUST be the information to derive it, and corresponding CBOR label, MUST be
specified in the application profile (REQ15) and registered in specified in the application profile (REQ15) and registered in
Section 8.5. Section 8.5.
4.1.6.2. GET Handler 4.1.6.2. GET Handler
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group identifier of the /ace-group/ The handler verifies that the group name of the /ace-group/GROUPNAME
GROUPNAME path is a subset of the 'scope' stored in the access token path is a subset of the 'scope' stored in the access token associated
associated to this client, identified by "NODENAME". If verification to this client, identified by "NODENAME". If verification fails, the
fails, the KDC MUST respond with a 4.01 (Unauthorized) error message. KDC MUST respond with a 4.01 (Unauthorized) error message.
The handler also verifies that the node sending the request and the The handler also verifies that the node sending the request and the
node name used in the Uri-Path match. If that is not the case, the node name used in the Uri-Path match. If that is not the case, the
handler responds with a 4.01 (Unauthorized) error response. handler responds with a 4.01 (Unauthorized) error response.
Additionally, the handler verifies that the node is a current member Additionally, the handler verifies that the node is a current member
of the group. If verification fails, the KDC MUST respond with a of the group. If verification fails, the KDC MUST respond with a
4.00 (Bad Request) error message. 4.00 (Bad Request) error message.
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
skipping to change at page 28, line 32 skipping to change at page 29, line 26
it, and corresponding CBOR label, MUST be specified in the it, and corresponding CBOR label, MUST be specified in the
application profile (REQ15) and registered in Section 8.5. application profile (REQ15) and registered in Section 8.5.
4.1.6.3. DELETE Handler 4.1.6.3. DELETE Handler
The DELETE handler removes the node identified by "NODENAME" from the The DELETE handler removes the node identified by "NODENAME" from the
group identified by "GROUPNAME". group identified by "GROUPNAME".
The handler expects a request with method DELETE (and empty payload). The handler expects a request with method DELETE (and empty payload).
The handler only accept a request from the node that matches the The handler only accepts a request from the node identified by
"NODENAME" used in Uri-Path, and that is part of the "GROUPNAME" "NODENAME" via the secure session, where NODENAME is used in Uri-
group: the handler verifies that the group identifier "GROUPNAME" is Path, and that is part of the "GROUPNAME" group: the handler verifies
a subset of the 'scope' stored in the access token associated to this that the group name "GROUPNAME" is a subset of the 'scope' stored in
client, and that this client is identified by "NODENAME". If the access token associated to this client, and that this client is
verification fails, the KDC MUST respond with a 4.01 (Unauthorized) identified by "NODENAME". If verification fails, the KDC MUST
error message. respond with a 4.01 (Unauthorized) error message.
The handler also verifies that the node sending the request and the The handler also verifies that the node sending the request and the
node name used in the Uri-Path match. If that is not the case, the node name used in the Uri-Path match. If that is not the case, the
handler responds with a 4.01 (Unauthorized) error response. handler responds with a 4.01 (Unauthorized) error response.
Additionally, the handler verifies that the node is a current member Additionally, the handler verifies that the node is a current member
of the group. If verification fails, the KDC MUST respond with a of the group. If verification fails, the KDC MUST respond with a
4.00 (Bad Request) error message. 4.00 (Bad Request) error message.
If verification succeeds, the handler removes the client from the If verification succeeds, the handler removes the client from the
skipping to change at page 29, line 29 skipping to change at page 30, line 26
request at the KDC, for the group identified by "GROUPNAME". request at the KDC, for the group identified by "GROUPNAME".
The handler expects a POST request with payload as specified in The handler expects a POST request with payload as specified in
Section 4.1.2.1, with the difference that it includes only the Section 4.1.2.1, with the difference that it includes only the
parameters 'client_cred', 'cnonce' and 'client_cred_verify'. In parameters 'client_cred', 'cnonce' and 'client_cred_verify'. In
particular, the signature included in 'client_cred_verify' is particular, the signature included in 'client_cred_verify' is
expected to be computed as defined in Section 4.1.2.1, with a newly expected to be computed as defined in Section 4.1.2.1, with a newly
generated N_C nonce and the previously received N_S. The specific generated N_C nonce and the previously received N_S. The specific
format of public keys is specified by the application profile (OPT1). format of public keys is specified by the application profile (OPT1).
The handler verifies that the group identifier GROUPNAME is a subset The handler verifies that the group name GROUPNAME is a subset of the
of the 'scope' stored in the access token associated to this client. 'scope' stored in the access token associated to this client. If
If verification fails, the KDC MUST respond with a 4.01 verification fails, the KDC MUST respond with a 4.01 (Unauthorized)
(Unauthorized) error message. error message.
If the request is not formatted correctly (e.g. unknown, not-expected If the request is not formatted correctly (i.e. required fields non
fields present, or expected fields with incorrect format), the received or received with incorrect format), the handler MUST respond
handler MUST respond with a 4.00 (Bad Request) error message. with a 4.00 (Bad Request) error message. If the request contained
Application profiles MAY define optional or mandatory payload formats unknown or non-expected fields present, the handler MUST silently
for specific error cases (OPT6). drop them and continue processing. Application profiles MAY define
optional or mandatory payload formats for specific error cases
(OPT6).
Otherwise, the handler checks that the public key specified in the Otherwise, the handler checks that the public key specified in the
'client_cred' field has a valid format for the group identified by 'client_cred' field has a valid format for the group identified by
"GROUPNAME", i.e. it is encoded as expected and is compatible with "GROUPNAME", i.e. it is encoded as expected and is compatible with
the signature algorithm and possible associated parameters. If that the signature algorithm and possible associated parameters. If that
cannot be verified, the handler MUST respond with a 4.00 (Bad cannot be verified, the handler MUST respond with a 4.00 (Bad
Request) error message. Applications profiles MAY define Request) error message. Applications profiles MAY define
alternatives (OPT5). alternatives (OPT5).
Otherwise, the handler verifies the signature contained in the Otherwise, the handler verifies the signature contained in the
skipping to change at page 30, line 28 skipping to change at page 31, line 27
Figure 8 gives an overview of the Joining exchange between Client and Figure 8 gives an overview of the Joining exchange between Client and
KDC, when the Client first joins a group. KDC, when the Client first joins a group.
Client KDC Client KDC
| | | |
|----- Joining Request: POST /ace-group/GROUPNAME ------>| |----- Joining Request: POST /ace-group/GROUPNAME ------>|
| | | |
|<--------- Joining Response: 2.01 (Created) ----------- | |<--------- Joining Response: 2.01 (Created) ----------- |
| Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" | | Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" |
Figure 8: Message Flow of First Exchange for Group Joining Figure 8: Message Flow of First Exchange for Group Joining
If not previously established, the Client and the KDC MUST first If not previously established, the Client and the KDC MUST first
establish a pairwise secure communication channel (REQ16). This can establish a pairwise secure communication channel (REQ16). This can
be achieved, for instance, by using a transport profile of ACE. The be achieved, for instance, by using a transport profile of ACE. The
Joining exchange MUST occur over that secure channel. The Client and Joining exchange MUST occur over that secure channel. The Client and
the KDC MAY use that same secure channel to protect further pairwise the KDC MAY use that same secure channel to protect further pairwise
communications that must be secured. communications that must be secured.
The secure communication protocol is REQUIRED to establish the secure The secure communication protocol is REQUIRED to establish the secure
channel between Client and KDC by using the proof-of-possession key channel between Client and KDC by using the proof-of-possession key
bound to the access token. As a result, the proof-of-possession to bound to the access token. As a result, the proof-of-possession to
bind the access token to the Client is performed by using the proof- bind the access token to the Client is performed by using the proof-
of-possession key bound to the access token for establishing secure of-possession key bound to the access token for establishing secure
communication between the Client and the KDC. communication between the Client and the KDC.
To join the group, the Client sends a CoAP POST request to the /ace- To join the group, the Client sends a CoAP POST request to the /ace-
group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group group/GROUPNAME endpoint at the KDC, where GROUPNAME is the group
identifier of the group to join, formatted as specified in name of the group to join, formatted as specified in Section 4.1.2.1.
Section 4.1.2.1. This group identifier is the same as in the scope This group name is the same as in the scope entry corresponding to
entry corresponding to that group, specified in the 'scope' parameter that group, specified in the 'scope' parameter of the Authorization
of the Authorization Request/Response, or it can be retrieved from Request/Response, or it can be retrieved from it. Note that, in case
it. Note that, in case of successful joining, the Client will of successful joining, the Client will receive the URI to retrieve
receive the URI to retrieve individual or group keying material and individual or group keying material and to leave the group in the
to leave the group in the Location-Path option of the response. Location-Path option of the response.
If the node is joining a group for the first time, and the KDC If the node is joining a group for the first time, and the KDC
maintains the public keys of the group members, the Client is maintains the public keys of the group members, the Client is
REQUIRED to send its own public key and proof of possession REQUIRED to send its own public key and proof of possession
("client_cred" and "client_cred_verify" in Section 4.1.2.1). The ("client_cred" and "client_cred_verify" in Section 4.1.2.1). The
request is only accepted if both public key and proof of possession request is only accepted if both public key and proof of possession
are provided. If a node re-joins a group with the same access token are provided. If a node re-joins a group with the same access token
and the same public key, it can omit to send the public key and the and the same public key, it can omit to send the public key and the
proof of possession, or just omit the proof of possession, and the proof of possession, or just omit the proof of possession, and the
KDC will be able to retrieve its public key associated to its token KDC will be able to retrieve its public key associated to its token
skipping to change at page 31, line 37 skipping to change at page 32, line 35
different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2, different resources at the KDC (Section 4.1.2.2, Section 4.1.3.2,
Section 4.1.4.1). After distributing the new group keying material, Section 4.1.4.1). After distributing the new group keying material,
the KDC MUST increment the version number of the keying material. the KDC MUST increment the version number of the keying material.
4.3. Retrieval of Updated Keying Material 4.3. Retrieval of Updated Keying Material
When any of the following happens, a node MUST stop using the owned When any of the following happens, a node MUST stop using the owned
group keying material to protect outgoing messages, and SHOULD stop group keying material to protect outgoing messages, and SHOULD stop
using it to decrypt and verify incoming messages. using it to decrypt and verify incoming messages.
o Upon expiration of the keying material, according to what * Upon expiration of the keying material, according to what
indicated by the KDC with the 'exp' (and possibly the 'exp_delta') indicated by the KDC with the 'exp' parameter in a Joining
parameter in a Joining Response, or to a pre-configured value. Response, or to a pre-configured value.
o Upon receiving a notification of revoked/renewed keying material * Upon receiving a notification of revoked/renewed keying material
from the KDC, possibly as part of an update of the keying material from the KDC, possibly as part of an update of the keying material
(rekeying) triggered by the KDC. (rekeying) triggered by the KDC.
o Upon receiving messages from other group members without being * Upon receiving messages from other group members without being
able to retrieve the keying material to correctly decrypt them. able to retrieve the keying material to correctly decrypt them.
This may be due to rekeying messages previously sent by the KDC, This may be due to rekeying messages previously sent by the KDC,
that the Client was not able to receive or decrypt. that the Client was not able to receive or decrypt.
In either case, if it wants to continue participating in the group In either case, if it wants to continue participating in the group
communication, the node has to request the latest keying material communication, the node has to request the latest keying material
from the KDC. To this end, the Client sends a CoAP GET request to from the KDC. To this end, the Client sends a CoAP GET request to
the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC,
formatted as specified in Section 4.1.6.2. formatted as specified in Section 4.1.6.2.
skipping to change at page 32, line 41 skipping to change at page 33, line 38
| GET ace-group/GROUPNAME/nodes/NODENAME | | GET ace-group/GROUPNAME/nodes/NODENAME |
| | | |
|<-------- Key Distribution Response: 2.05 (Content) ---------| |<-------- Key Distribution Response: 2.05 (Content) ---------|
| | | |
Figure 9: Message Flow of Key Distribution Request-Response Figure 9: Message Flow of Key Distribution Request-Response
Alternatively, the re-distribution of keying material can be Alternatively, the re-distribution of keying material can be
initiated by the KDC, which e.g.: initiated by the KDC, which e.g.:
o Can make the ace-group/GROUPNAME/nodes/NODENAME resource * Can make the ace-group/GROUPNAME/nodes/NODENAME resource
Observable [RFC7641], and send notifications to Clients when the Observable [RFC7641], and send notifications to Clients when the
keying material is updated. keying material is updated.
o Can send the payload of the Key Distribution Response in one or * Can send the payload of the Key Distribution Response in one or
multiple multicast POST requests to the members of the group, multiple multicast POST requests to the members of the group,
using secure rekeying schemes such as [RFC2093][RFC2094][RFC2627]. using secure rekeying schemes such as [RFC2093][RFC2094][RFC2627].
o Can send unicast POST requests to each Client over a secure * Can send unicast POST requests to each Client over a secure
channel, with the same payload as the Key Distribution Response. channel, with the same payload as the Key Distribution Response.
When sending such requests, the KDC can target the URI path When sending such requests, the KDC can target the URI path
possibly provided by the intended recipient upon joining the provided by the intended recipient upon joining the group, as
group, as specified in the 'control_path' parameter of the Joining specified in the 'control_path' parameter of the Joining Request
Request (see Section 4.1.2.1). (see Section 4.1.2.1).
o Can act as a publisher in a pub-sub scenario, and update the * Can act as a publisher in a pub-sub scenario, and update the
keying material by publishing on a specific topic on a broker, keying material by publishing on a specific topic on a broker,
which all the members of the group are subscribed to. which all the members of the group are subscribed to.
Note that these methods of KDC-initiated key distribution have Note that these methods of KDC-initiated key distribution have
different security properties and require different security different security properties and require different security
associations. Moreover, congestion control mechanism need to be associations.
implemented where Observe is used, see Section 4.5.1 of [RFC7641].
4.4. Retrieval of New Keying Material Congestion control mechanisms need to be implemented: see Section 4.7
of [RFC7252] and, where Observe is used, Section 4.5.1 of [RFC7641].
Beside possible expiration and depending on what part of the keying 4.4. Retrieval of New Individual Keying Material
material is no longer eligible to be used, the client may need to
communicate to the KDC its need for that part to be renewed. For Beside possible expiration, the client may need to communicate to the
KDC its need for part of the keying material to be renewed. For
example, if the Client uses an individual key to protect outgoing example, if the Client uses an individual key to protect outgoing
traffic and has to renew it, the node may request a new one, or new traffic and has to renew it, the node may request a new one, or new
input material to derive it, without renewing the whole group keying input material to derive it, without renewing the whole group keying
material. material.
To this end, the client performs a Key Renewal Request/Response To this end, the client performs a Key Renewal Request/Response
exchange with the KDC, i.e. it sends a CoAP PUT request to the /ace- exchange with the KDC, i.e. it sends a CoAP PUT request to the /ace-
group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME group/GROUPNAME/nodes/NODENAME endpoint at the KDC, where GROUPNAME
is the group identifier and NODENAME is the node's name, and is the group name and NODENAME is the node's name, and formatted as
formatted as defined in Section 4.1.6.2. defined in Section 4.1.6.2.
Figure 10 gives an overview of the exchange described above. Figure 10 gives an overview of the exchange described above.
Client KDC Client KDC
| | | |
|------------------ Key Renewal Request: -------------->| |------------------ Key Renewal Request: -------------->|
| PUT ace-group/GROUPNAME/nodes/NODENAME | | PUT ace-group/GROUPNAME/nodes/NODENAME |
| | | |
|<-------- Key Renewal Response: 2.05 (Content) --------| |<-------- Key Renewal Response: 2.05 (Content) --------|
| | | |
Figure 10: Message Flow of Key Renewal Request-Response Figure 10: Message Flow of Key Renewal Request-Response
Note the difference between the Key Distribution Request and the Key Note the difference between the Key Distribution Request and the Key
Renewal Request: while the first one only triggers distribution (the Renewal Request: while the first one only triggers distribution (the
renewal might have happened independently, e.g. because of renewal might have happened independently, e.g. because of
expiration), the second one triggers the KDC to produce new expiration), the second one triggers the KDC to produce new
individual keying material for the requesting node. individual keying material for the requesting node.
Furthermore, policies can be set up so that, upon receiving a Key Furthermore, policies can be set up so that, upon receiving a Key
Renewal Request, the KDC replies to the client with an error Renewal Request, the KDC performs a complete group rekeying before or
response, and then performs a complete group rekeying (OPT8). after replying to the client (OPT8).
4.5. Retrieval of Public Keys and Roles for Group Members 4.5. Retrieval of Public Keys and Roles for Group Members
In case the KDC maintains the public keys of group members, a node in In case the KDC maintains the public keys of group members, a node in
the group can contact the KDC to request public keys and roles of the group can contact the KDC to request public keys and roles of
either all group members or a specified subset, by sending a CoAP GET either all group members or a specified subset, by sending a CoAP GET
or FETCH request to the /ace-group/GROUPNAME/pub-key endpoint at the or FETCH request to the /ace-group/GROUPNAME/pub-key endpoint at the
KDC, where GROUPNAME is the group identifier, and formatted as KDC, where GROUPNAME is the group name, and formatted as defined in
defined in Section 4.1.3.2 and Section 4.1.3.1. Section 4.1.3.2 and Section 4.1.3.1.
When receiving a Public Key Response, the requesting group member When receiving a Public Key Response, the requesting group member
stores (or updates) the public keys (in the 'pub_keys' parameter) and stores (or updates) the public keys (in the 'pub_keys' parameter) and
roles (in the 'peer_roles' parameter) of the group members. roles (in the 'peer_roles' parameter) of the group members.
Figure 11 and Figure 12 give an overview of the exchanges described Figure 11 and Figure 12 give an overview of the exchanges described
above. above.
Client KDC Client KDC
| | | |
|--Public Key Request: GET /ace-group/GROUPNAME/pub-key->| |--Public Key Request: GET /ace-group/GROUPNAME/pub-key->|
| | | |
|<--------- Public Key Response: 2.05 (Content) ---------| |<--------- Public Key Response: 2.05 (Content) ---------|
| | | |
Figure 11: Message Flow of Public Key Exchange to Request All Members Figure 11: Message Flow of Public Key Exchange to Request All
Public Keys Members Public Keys
Client KDC Client KDC
| | | |
|-Public Key Request: FETCH /ace-group/GROUPNAME/pub-key->| |-Public Key Request: FETCH /ace-group/GROUPNAME/pub-key->|
| | | |
|<--------- Public Key Response: 2.05 (Created) ----------| |<--------- Public Key Response: 2.05 (Created) ----------|
| | | |
Figure 12: Message Flow of Public Key Exchange to Request Specific Figure 12: Message Flow of Public Key Exchange to Request
Members Public Keys Specific Members Public Keys
4.6. Update of Public Key 4.6. Update of Public Key
In case the KDC maintains the public keys of group members, a node in In case the KDC maintains the public keys of group members, a node in
the group can contact the KDC to upload a new public key to use in the group can contact the KDC to upload a new public key to use in
the group, and replace the currently stored one. the group, and replace the currently stored one.
To this end, the Client performs a Public Key Update Request/Response To this end, the Client performs a Public Key Update Request/Response
exchange with the KDC, i.e. it sends a CoAP POST request to the /ace- exchange with the KDC, i.e. it sends a CoAP POST request to the /ace-
group/GROUPNAME/nodes/NODENAME/pub-key endpoint at the KDC, where group/GROUPNAME/nodes/NODENAME/pub-key endpoint at the KDC, where
GROUPNAME is the group identifier and NODENAME is the node's name. GROUPNAME is the group name and NODENAME is the node's name.
The request is formatted as specified in Section 4.1.7.1. The request is formatted as specified in Section 4.1.7.1.
Figure Figure 13 gives an overview of the exchange described above. Figure Figure 13 gives an overview of the exchange described above.
Client KDC Client KDC
| | | |
|-------------- Public Key Update Request: ---------------------->| |-------------- Public Key Update Request: ---------------------->|
| POST ace-group/GROUPNAME/nodes/NODENAME/pub-key | | POST ace-group/GROUPNAME/nodes/NODENAME/pub-key |
| | | |
skipping to change at page 35, line 28 skipping to change at page 36, line 24
Figure 13: Message Flow of Public Key Update Request-Response Figure 13: Message Flow of Public Key Update Request-Response
If the application requires backward security, the KDC MUST generate If the application requires backward security, the KDC MUST generate
new group keying material and securely distribute it to all the new group keying material and securely distribute it to all the
current group members, upon a group member updating its own public current group members, upon a group member updating its own public
key. To this end, the KDC uses the message format of the response key. To this end, the KDC uses the message format of the response
defined in Section 4.1.2.2. Application profiles may define defined in Section 4.1.2.2. Application profiles may define
alternative ways of retrieving the keying material, such as sending alternative ways of retrieving the keying material, such as sending
separate requests to different resources at the KDC (Section 4.1.2.2, separate requests to different resources at the KDC (Section 4.1.2.2,
Section 4.1.3.2, Section 4.1.4.1). After distributing the new group Section 4.1.3.2, Section 4.1.4.1). The KDC MUST increment the
keying material, the KDC MUST increment the version number of the version number of the current keying material, before distributing
keying material. the newly generated keying material to the group. After that, the
KDC SHOULD store the distributed keying material in persistent
storage.
Additionally, after updating its own public key, a group member MAY Additionally, after updating its own public key, a group member MAY
send a number of the later requests including an identifier of the send a number of the later requests including an identifier of the
updated public key, to signal nodes that they need to retrieve it. updated public key, to signal nodes that they need to retrieve it.
How that is done depends on the group communication protocol used, How that is done depends on the group communication protocol used,
and therefore is application profile specific (OPT10). and therefore is application profile specific (OPT10).
4.7. Retrieval of Group Policies 4.7. Retrieval of Group Policies
A node in the group can contact the KDC to retrieve the current group A node in the group can contact the KDC to retrieve the current group
policies, by sending a CoAP GET request to the /ace-group/GROUPNAME/ policies, by sending a CoAP GET request to the /ace-group/GROUPNAME/
policies endpoint at the KDC, where GROUPNAME is the group policies endpoint at the KDC, where GROUPNAME is the group name, and
identifier, and formatted as defined in Section 4.1.4.1 formatted as defined in Section 4.1.4.1
Figure 14 gives an overview of the exchange described above. Figure 14 gives an overview of the exchange described above.
Client KDC Client KDC
| | | |
|-Policies Request: GET ace-group/GROUPNAME/policies ->| |-Policies Request: GET ace-group/GROUPNAME/policies ->|
| | | |
|<--------- Policies Response: 2.05 (Content) ---------| |<--------- Policies Response: 2.05 (Content) ---------|
| | | |
Figure 14: Message Flow of Policies Request-Response Figure 14: Message Flow of Policies Request-Response
4.8. Retrieval of Keying Material Version 4.8. Retrieval of Keying Material Version
A node in the group can contact the KDC to request information about A node in the group can contact the KDC to request information about
the version number of the symmetric group keying material, by sending the version number of the symmetric group keying material, by sending
a CoAP GET request to the /ace-group/GROUPNAME/ctx-num endpoint at a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the
the KDC, where GROUPNAME is the group identifier, formatted as KDC, where GROUPNAME is the group name, formatted as defined in
defined in Section 4.1.5.1. In particular, the version is Section 4.1.5.1. In particular, the version is incremented by the
incremented by the KDC every time the group keying material is KDC every time the group keying material is renewed, before it's
renewed. distributed to the group members.
Figure 15 gives an overview of the exchange described above. Figure 15 gives an overview of the exchange described above.
Client KDC Client KDC
| | | |
|-- Version Request: GET ace-group/GROUPNAME/ctx-num -->| |---- Version Request: GET ace-group/GROUPNAME/num ---->|
| | | |
|<--------- Version Response: 2.05 (Content) -----------| |<--------- Version Response: 2.05 (Content) -----------|
| | | |
Figure 15: Message Flow of Version Request-Response Figure 15: Message Flow of Version Request-Response
4.9. Group Leaving Request 4.9. Group Leaving Request
A node can actively request to leave the group. In this case, the A node can actively request to leave the group. In this case, the
Client sends a CoAP DELETE request to the endpoint /ace- Client sends a CoAP DELETE request to the endpoint /ace-
group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME is the group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME is the
group identifier and NODENAME is the node's name, formatted as group name and NODENAME is the node's name, formatted as defined in
defined in Section 4.1.6.3 Section 4.1.6.3
Alternatively, a node may be removed by the KDC, without having Alternatively, a node may be removed by the KDC, without having
explicitly asked for it. This is further discussed in Section 5. explicitly asked for it. This is further discussed in Section 5.
5. Removal of a Node from the Group 5. Removal of a Node from the Group
This section describes the different scenarios according to which a This section describes the different scenarios according to which a
node ends up being removed from the group. node ends up being removed from the group.
If the application requires forward security, the KDC MUST generate If the application requires forward security, the KDC MUST generate
new group keying material and securely distribute it to all the new group keying material and securely distribute it to all the
current group members but the leaving node, using the message format current group members but the leaving node, using the message format
of the Key Distribution Response (see Section 4.3). Application of the Key Distribution Response (see Section 4.3). Application
profiles may define alternative message formats. Once distributed profiles may define alternative message formats. Before distributing
the new group keying material, the KDC MUST increment the version the new group keying material, the KDC MUST increment the version
number of the keying material. number of the keying material.
Note that, after having left the group, a node may wish to join it Note that, after having left the group, a node may wish to join it
again. Then, as long as the node is still authorized to join the again. Then, as long as the node is still authorized to join the
group, i.e. it still has a valid access token, it can re-request to group, i.e. it still has a valid access token, it can re-request to
join the group directly to the KDC without needing to retrieve a new join the group directly to the KDC without needing to retrieve a new
access token from the AS. This means that the KDC might decide to access token from the AS. This means that the KDC might decide to
keep track of nodes with valid access tokens, before deleting all keep track of nodes with valid access tokens, before deleting all
information about the leaving node. information about the leaving node.
skipping to change at page 38, line 5 skipping to change at page 39, line 5
Joining Request. Joining Request.
6. ACE Groupcomm Parameters 6. ACE Groupcomm Parameters
This specification defines a number of fields used during the second This specification defines a number of fields used during the second
part of the message exchange, after the ACE Token POST exchange. The part of the message exchange, after the ACE Token POST exchange. The
table below summarizes them, and specifies the CBOR key to use table below summarizes them, and specifies the CBOR key to use
instead of the full descriptive name. Note that the media type ace- instead of the full descriptive name. Note that the media type ace-
groupcomm+cbor MUST be used when these fields are transported. groupcomm+cbor MUST be used when these fields are transported.
+-----------------------+------+-----------------+------------------+ +=======================+======+===============+==================+
| Name | CBOR | CBOR Type | Reference | | Name | CBOR | CBOR Type | Reference |
| | Key | | | | | Key | | |
+-----------------------+------+-----------------+------------------+ +=======================+======+===============+==================+
| scope | TBD | byte string | Section 4.1.2.1 | | scope | TBD | byte string | Section 4.1.2.1 |
| | | | | +-----------------------+------+---------------+------------------+
| get_pub_keys | TBD | array | Section 4.1.2.1, | | get_pub_keys | TBD | array | Section 4.1.2.1, |
| | | | Section 4.1.3.1 | | | | | Section 4.1.3.1 |
| | | | | +-----------------------+------+---------------+------------------+
| client_cred | TBD | byte string | Section 4.1.2.1 | | client_cred | TBD | byte string | Section 4.1.2.1 |
| | | | | +-----------------------+------+---------------+------------------+
| cnonce | TBD | byte string | Section 4.1.2.1 | | cnonce | TBD | byte string | Section 4.1.2.1 |
| | | | | +-----------------------+------+---------------+------------------+
| client_cred_verify | TBD | byte string | Section 4.1.2.1 | | client_cred_verify | TBD | byte string | Section 4.1.2.1 |
| | | | | +-----------------------+------+---------------+------------------+
| pub_keys_repos | TBD | text string | Section 4.1.2.1 | | pub_keys_repos | TBD | text string | Section 4.1.2.1 |
| | | | | +-----------------------+------+---------------+------------------+
| control_path | TBD | text string | Section 4.1.2.1 | | control_path | TBD | text string | Section 4.1.2.1 |
| | | | | +-----------------------+------+---------------+------------------+
| gkty | TBD | int / text | Section 4.1.2.1 | | gkty | TBD | int / text | Section 4.1.2.1 |
| | | string | | | | | string | |
| | | | | +-----------------------+------+---------------+------------------+
| key | TBD | see "ACE | Section 4.1.2.1 | | key | TBD | see "ACE | Section 4.1.2.1 |
| | | Groupcomm Key" | | | | | Groupcomm | |
| | | Registry | | | | | Key" Registry | |
| | | | | +-----------------------+------+---------------+------------------+
| num | TBD | int | Section 4.1.2.1 | | num | TBD | int | Section 4.1.2.1 |
| | | | | +-----------------------+------+---------------+------------------+
| ace-groupcomm-profile | TBD | int | Section 4.1.2.1 | | ace-groupcomm-profile | TBD | int | Section 4.1.2.1 |
| | | | | +-----------------------+------+---------------+------------------+
| exp | TBD | int | Section 4.1.2.1 | | exp | TBD | int | Section 4.1.2.1 |
| | | | | +-----------------------+------+---------------+------------------+
| exp_delta | TBD | int | Section 4.1.2.1 | | pub_keys | TBD | byte string | Section 4.1.2.1 |
| | | | | +-----------------------+------+---------------+------------------+
| pub_keys | TBD | byte string | Section 4.1.2.1 | | peer_roles | TBD | array | Section 4.1.2.1 |
| | | | | +-----------------------+------+---------------+------------------+
| peer_roles | TBD | array | Section 4.1.2.1 | | group_policies | TBD | map | Section 4.1.2.1 |
| | | | | +-----------------------+------+---------------+------------------+
| group_policies | TBD | map | Section 4.1.2.1 | | mgt_key_material | TBD | byte string | Section 4.1.2.1 |
| | | | | +-----------------------+------+---------------+------------------+
| mgt_key_material | TBD | byte string | Section 4.1.2.1 |
+-----------------------+------+-----------------+------------------+ Table 1
7. Security Considerations 7. Security Considerations
When a Client receives a message from a sender for the first time, it When a Client receives a message from a sender for the first time, it
needs to have a mechanism in place to avoid replay, e.g. needs to have a mechanism in place to avoid replay, e.g.
Appendix B.2 of [RFC8613]. In case the Client rebooted and lost the Appendix B.2 of [RFC8613]. In case the Client rebooted and lost the
security state used to protect previous communication with that security state used to protect previous communication with that
sender, such a mechanism is useful for the recipient to be on the sender, such a mechanism is useful for the recipient to be on the
safe side. If the group has renewed its group keying material, the safe side. Besides, if the KDC has renewed the group keying
time window between the end of the rekeying process and the next loss material, and the time interval between the end of the rekeying
of security state is safe for recipients, as replayed older messages process and the joining of the Client is sufficiently small, that
protected with previous keying material will not be accepted. Client is also on the safe side, since replayed older messages
protected with the previous keying material will not be accepted.
The KDC must renew the group keying material upon its expiration. The KDC must renew the group keying material upon its expiration.
The KDC should renew the keying material upon group membership The KDC should renew the keying material upon group membership
change, and should provide it to the current group members through change, and should provide it to the current group members through
the rekeying scheme used in the group. the rekeying scheme used in the group.
The KDC should renew the group keying material after rebooting, even The KDC should renew the group keying material after rebooting, even
in the case where all keying material is stored in persistent in the case where all keying material is stored in persistent
storage. However, if the KDC relies on Observe responses to notify storage. However, if the KDC relies on Observe responses to notify
the group of renewed keying material, after rebooting the KDC will the group of renewed keying material, after rebooting the KDC will
have lost all the Observations up to that point, and the previous have lost all the current ongoing Observations with the group
keying material will be used to protect messages in the group anyway. members, and the previous keying material will be used to protect
The KDC will rely on each node requesting updates of the group keying messages in the group anyway. The KDC will rely on each node
material to establish the new keying material in the nodes, or, if requesting updates of the group keying material to establish the new
implemented, it can push the update to the nodes in the group using keying material in the nodes, or, if implemented, it can push the
the 'control_path' resource. update to the nodes in the group using the 'control_path' resource.
The KDC may enforce a rekeying policy that takes into account the The KDC may enforce a rekeying policy that takes into account the
overall time required to rekey the group, as well as the expected overall time required to rekey the group, as well as the expected
rate of changes in the group membership. rate of changes in the group membership.
That is, the KDC may not rekey the group at every membership change, That is, the KDC may not rekey the group at every membership change,
for instance if members' joining and leaving occur frequently and for instance if members' joining and leaving occur frequently and
performing a group rekeying takes too long. Instead, the KDC may performing a group rekeying takes too long. The KDC may rekey the
rekey the group after a minimum number of group members have joined group after a minimum number of group members have joined or left
or left within a given time interval, or during predictable network within a given time interval, or after maximum amount of time since
the last rekeying was completed, or yet during predictable network
inactivity periods. inactivity periods.
However, this would result in the KDC not constantly preserving However, this would result in the KDC not constantly preserving
backward and forward security. In fact, newly joining group members backward and forward security. Newly joining group members could be
could be able to access the keying material used before their able to access the keying material used before their joining, and
joining, and thus could access past group communications. Also, thus could access past group communications. Also, until the KDC
until the KDC performs a group rekeying, the newly leaving nodes performs a group rekeying, the newly leaving nodes would still be
would still be able to access upcoming group communications that are able to access upcoming group communications that are protected with
protected with the keying material that has not yet been updated. the keying material that has not yet been updated.
The KDC needs to have a mechanism in place to detect DoS attacks from The KDC needs to have a mechanism in place to detect DoS attacks from
nodes constantly initiating rekeys (for example by updating their nodes constantly initiating rekey events (for example by updating
public key), such as removing these nodes from the group. their public key), such as removing these nodes from the group.
The KDC also needs to have a congestion control mechanism in place to The KDC also needs to have a congestion control mechanism in place to
avoid network congestion when the KDC renews the group keying avoid network congestion when the KDC renews the group keying
material; CoAP and Observe give guidancee on such mechanisms, see material; CoAP and Observe give guidance on such mechanisms, see
Section 4.7 of [RFC7252] and Section 4.5.1 of [RFC7641]. Section 4.7 of [RFC7252] and Section 4.5.1 of [RFC7641].
7.1. Update of Keying Material 7.1. Update of Keying Material
A group member can receive a message shortly after the group has been A group member can receive a message shortly after the group has been
rekeyed, and new keying material has been distributed by the KDC. In rekeyed, and new keying material has been distributed by the KDC. In
the following two cases, this may result in misaligned keying the following two cases, this may result in misaligned keying
material between the group members. material between the group members.
In the first case, the sender protects a message using the old keying In the first case, the sender protects a message using the old keying
material. However, the recipient receives the message after having material. However, the recipient receives the message after having
received the new keying material, hence not being able to correctly received the new keying material, hence not being able to correctly
process it. A possible way to ameliorate this issue is to preserve process it. A possible way to ameliorate this issue is to preserve
the old, recent, keying material for a maximum amount of time defined the old, recent, keying material for a maximum amount of time defined
by the application. By doing so, the recipient can still try to by the application. By doing so, the recipient can still try to
process the received message using the old retained keying material process the received message using the old retained keying material.
as second attempt. Note that a former (compromised) group member can Note that a former (compromised) group member can take advantage of
take advantage of this by sending messages protected with the old this by sending messages protected with the old retained keying
retained keying material. Therefore, a conservative application material. Therefore, a conservative application policy should not
policy should not admit the storage of old keying material. admit the storage of old keying material.
In the second case, the sender protects a message using the new In the second case, the sender protects a message using the new
keying material, but the recipient receives that request before keying material, but the recipient receives that request before
having received the new keying material. Therefore, the recipient having received the new keying material. Therefore, the recipient
would not be able to correctly process the request and hence discards would not be able to correctly process the request and hence discards
it. If the recipient receives the new keying material shortly after it. If the recipient receives the new keying material shortly after
that and the application at the sender endpoint performs that and the application at the sender endpoint performs
retransmissions, the former will still be able to receive and retransmissions, the former will still be able to receive and
correctly process the message. In any case, the recipient should correctly process the message. In any case, the recipient should
actively ask the KDC for an updated keying material according to an actively ask the KDC for an updated keying material according to an
skipping to change at page 42, line 4 skipping to change at page 43, line 15
authorization servers, clients and resource servers that support the authorization servers, clients and resource servers that support the
ACE groupcomm framework as specified in [this document]. ACE groupcomm framework as specified in [this document].
Additional information: Additional information:
Magic number(s): n/a Magic number(s): n/a
File extension(s): .ace-groupcomm File extension(s): .ace-groupcomm
Macintosh file type code(s): n/a Macintosh file type code(s): n/a
Person & email address to contact for further information: Person & email address to contact for further information:
iesg@ietf.org [1] iesg@ietf.org (mailto:iesg@ietf.org)
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: None Restrictions on usage: None
Author: Francesca Palombini francesca.palombini@ericsson.com [2] Author: Francesca Palombini francesca.palombini@ericsson.com
(mailto:francesca.palombini@ericsson.com)
Change controller: IESG Change controller: IESG
8.2. CoAP Content-Formats Registry 8.2. CoAP Content-Formats Registry
This specification registers the following entry to the "CoAP This specification registers the following entry to the "CoAP
Content-Formats" registry, within the "CoRE Parameters" registry: Content-Formats" registry, within the "CoRE Parameters" registry:
Media Type: application/ace-groupcomm+cbor Media Type: application/ace-groupcomm+cbor
skipping to change at page 42, line 36 skipping to change at page 44, line 4
Reference: [this document] Reference: [this document]
8.3. OAuth Parameters Registry 8.3. OAuth Parameters Registry
The following registrations are done for the OAuth ParametersRegistry The following registrations are done for the OAuth ParametersRegistry
following the procedure specified in section 11.2 of [RFC6749]: following the procedure specified in section 11.2 of [RFC6749]:
o Parameter name: sign_info o Parameter usage location: token o Parameter name: sign_info o Parameter usage location: token
request, token response o Change Controller: IESG o Specification request, token response o Change Controller: IESG o Specification
Document(s): [[This specification]] Document(s): [[This specification]]
o Parameter name: pub_key_enc o Parameter usage location: token
request, token response o Change Controller: IESG o Specification
Document(s): [[This specification]]
o Parameter name: kdcchallenge o Parameter usage location: token o Parameter name: kdcchallenge o Parameter usage location: token
response o Change Controller: IESG o Specification Document(s): response o Change Controller: IESG o Specification Document(s):
[[This specification]] [[This specification]]
8.4. OAuth Parameters CBOR Mappings Registry 8.4. OAuth Parameters CBOR Mappings Registry
The following registrations are done for the OAuth Parameters CBOR The following registrations are done for the OAuth Parameters CBOR
Mappings Registry following the procedure specified in section 8.9 of Mappings Registry following the procedure specified in section 8.9 of
[I-D.ietf-ace-oauth-authz]: [I-D.ietf-ace-oauth-authz]:
* Name: sign_info * Name: sign_info
* CBOR Key: TBD (range -256 to 255) * CBOR Key: TBD (range -256 to 255)
* Value Type: any * Value Type: any
* Reference: \[\[This specification\]\] * Reference: \[\[This specification\]\]
* Name: pub_key_enc
* CBOR Key: TBD (range -256 to 255)
* Value Type: integer
* Reference: \[\[This specification\]\]
* Name: kdcchallenge * Name: kdcchallenge
* CBOR Key: TBD (range -256 to 255) * CBOR Key: TBD (range -256 to 255)
* Value Type: byte string * Value Type: byte string
* Reference: \[\[This specification\]\] * Reference: \[\[This specification\]\]
8.5. ACE Groupcomm Parameters Registry 8.5. ACE Groupcomm Parameters Registry
This specification establishes the "ACE Groupcomm Parameters" IANA This specification establishes the "ACE Groupcomm Parameters" IANA
Registry. The Registry has been created to use the "Expert Review Registry. The Registry has been created to use the "Expert Review
Required" registration procedure [RFC8126]. Expert review guidelines Required" registration procedure [RFC8126]. Expert review guidelines
are provided in Section 8.11. are provided in Section 8.11.
The columns of this Registry are: The columns of this Registry are:
o Name: This is a descriptive name that enables easier reference to * Name: This is a descriptive name that enables easier reference to
the item. The name MUST be unique. It is not used in the the item. The name MUST be unique. It is not used in the
encoding. encoding.
o CBOR Key: This is the value used as CBOR key of the item. These * CBOR Key: This is the value used as CBOR key of the item. These
values MUST be unique. The value can be a positive integer, a values MUST be unique. The value can be a positive integer, a
negative integer, or a string. negative integer, or a string.
o CBOR Type: This contains the CBOR type of the item, or a pointer * CBOR Type: This contains the CBOR type of the item, or a pointer
to the registry that defines its type, when that depends on to the registry that defines its type, when that depends on
another item. another item.
o Reference: This contains a pointer to the public specification for * Reference: This contains a pointer to the public specification for
the item. the item.
This Registry has been initially populated by the values in This Registry has been initially populated by the values in
Section 6. The Reference column for all of these entries refers to Section 6. The Reference column for all of these entries refers to
sections of this document. sections of this document.
8.6. ACE Groupcomm Key Registry 8.6. ACE Groupcomm Key Registry
This specification establishes the "ACE Groupcomm Key" IANA Registry. This specification establishes the "ACE Groupcomm Key" IANA Registry.
The Registry has been created to use the "Expert Review Required" The Registry has been created to use the "Expert Review Required"
registration procedure [RFC8126]. Expert review guidelines are registration procedure [RFC8126]. Expert review guidelines are
provided in Section 8.11. provided in Section 8.11.
The columns of this Registry are: The columns of this Registry are:
o Name: This is a descriptive name that enables easier reference to * Name: This is a descriptive name that enables easier reference to
the item. The name MUST be unique. It is not used in the the item. The name MUST be unique. It is not used in the
encoding. encoding.
o Key Type Value: This is the value used to identify the keying * Key Type Value: This is the value used to identify the keying
material. These values MUST be unique. The value can be a material. These values MUST be unique. The value can be a
positive integer, a negative integer, or a text string. positive integer, a negative integer, or a text string.
o Profile: This field may contain one or more descriptive strings of * Profile: This field may contain one or more descriptive strings of
application profiles to be used with this item. The values should application profiles to be used with this item. The values should
be taken from the Name column of the "ACE Groupcomm Profile" be taken from the Name column of the "ACE Groupcomm Profile"
Registry. Registry.
o Description: This field contains a brief description of the keying * Description: This field contains a brief description of the keying
material. material.
o References: This contains a pointer to the public specification * References: This contains a pointer to the public specification
for the format of the keying material, if one exists. for the format of the keying material, if one exists.
This Registry has been initially populated by the values in Figure 5. This Registry has been initially populated by the values in Figure 6.
The specification column for all of these entries will be this The specification column for all of these entries will be this
document. document.
8.7. ACE Groupcomm Profile Registry 8.7. ACE Groupcomm Profile Registry
This specification establishes the "ACE Groupcomm Profile" IANA This specification establishes the "ACE Groupcomm Profile" IANA
Registry. The Registry has been created to use the "Expert Review Registry. The Registry has been created to use the "Expert Review
Required" registration procedure [RFC8126]. Expert review guidelines Required" registration procedure [RFC8126]. Expert review guidelines
are provided in Section 8.11. It should be noted that, in addition are provided in Section 8.11. It should be noted that, in addition
to the expert review, some portions of the Registry require a to the expert review, some portions of the Registry require a
specification, potentially a Standards Track RFC, be supplied as specification, potentially a Standards Track RFC, be supplied as
well. well.
The columns of this Registry are: The columns of this Registry are:
o Name: The name of the application profile, to be used as value of * Name: The name of the application profile, to be used as value of
the profile attribute. the profile attribute.
o Description: Text giving an overview of the application profile * Description: Text giving an overview of the application profile
and the context it is developed for. and the context it is developed for.
o CBOR Value: CBOR abbreviation for the name of this application * CBOR Value: CBOR abbreviation for the name of this application
profile. Different ranges of values use different registration profile. Different ranges of values use different registration
policies [RFC8126]. Integer values from -256 to 255 are policies [RFC8126]. Integer values from -256 to 255 are
designated as Standards Action. Integer values from -65536 to designated as Standards Action. Integer values from -65536 to
-257 and from 256 to 65535 are designated as Specification -257 and from 256 to 65535 are designated as Specification
Required. Integer values greater than 65535 are designated as Required. Integer values greater than 65535 are designated as
Expert Review. Integer values less than -65536 are marked as Expert Review. Integer values less than -65536 are marked as
Private Use. Private Use.
o Reference: This contains a pointer to the public specification of * Reference: This contains a pointer to the public specification of
the abbreviation for this application profile, if one exists. the abbreviation for this application profile, if one exists.
8.8. ACE Groupcomm Policy Registry 8.8. ACE Groupcomm Policy Registry
This specification establishes the "ACE Groupcomm Policy" IANA This specification establishes the "ACE Groupcomm Policy" IANA
Registry. The Registry has been created to use the "Expert Review Registry. The Registry has been created to use the "Expert Review
Required" registration procedure [RFC8126]. Expert review guidelines Required" registration procedure [RFC8126]. Expert review guidelines
are provided in Section 8.11. It should be noted that, in addition are provided in Section 8.11. It should be noted that, in addition
to the expert review, some portions of the Registry require a to the expert review, some portions of the Registry require a
specification, potentially a Standards Track RFC, be supplied as specification, potentially a Standards Track RFC, be supplied as
well. well.
The columns of this Registry are: The columns of this Registry are:
o Name: The name of the group communication policy. * Name: The name of the group communication policy.
o CBOR label: The value to be used to identify this group * CBOR label: The value to be used to identify this group
communication policy. Key map labels MUST be unique. The label communication policy. Key map labels MUST be unique. The label
can be a positive integer, a negative integer or a string. can be a positive integer, a negative integer or a string.
Integer values between 0 and 255 and strings of length 1 are Integer values between 0 and 255 and strings of length 1 are
designated as Standards Track Document required. Integer values designated as Standards Track Document required. Integer values
from 256 to 65535 and strings of length 2 are designated as from 256 to 65535 and strings of length 2 are designated as
Specification Required. Integer values of greater than 65535 and Specification Required. Integer values of greater than 65535 and
strings of length greater than 2 are designated as expert review. strings of length greater than 2 are designated as expert review.
Integer values less than -65536 are marked as private use. Integer values less than -65536 are marked as private use.
o CBOR type: the CBOR type used to encode the value of this group * CBOR type: the CBOR type used to encode the value of this group
communication policy. communication policy.
o Description: This field contains a brief description for this * Description: This field contains a brief description for this
group communication policy. group communication policy.
o Reference: This field contains a pointer to the public * Reference: This field contains a pointer to the public
specification providing the format of the group communication specification providing the format of the group communication
policy, if one exists. policy, if one exists.
This registry will be initially populated by the values in Figure 6. This registry will be initially populated by the values in Figure 7.
8.9. Sequence Number Synchronization Method Registry 8.9. Sequence Number Synchronization Method Registry
This specification establishes the "Sequence Number Synchronization This specification establishes the "Sequence Number Synchronization
Method" IANA Registry. The Registry has been created to use the Method" IANA Registry. The Registry has been created to use the
"Expert Review Required" registration procedure [RFC8126]. Expert "Expert Review Required" registration procedure [RFC8126]. Expert
review guidelines are provided in Section 8.11. It should be noted review guidelines are provided in Section 8.11. It should be noted
that, in addition to the expert review, some portions of the Registry that, in addition to the expert review, some portions of the Registry
require a specification, potentially a Standards Track RFC, be require a specification, potentially a Standards Track RFC, be
supplied as well. supplied as well.
The columns of this Registry are: The columns of this Registry are:
o Name: The name of the sequence number synchronization method. * Name: The name of the sequence number synchronization method.
o Value: The value to be used to identify this sequence number * Value: The value to be used to identify this sequence number
synchronization method. synchronization method.
o Description: This field contains a brief description for this * Description: This field contains a brief description for this
sequence number synchronization method. sequence number synchronization method.
o Reference: This field contains a pointer to the public * Reference: This field contains a pointer to the public
specification describing the sequence number synchronization specification describing the sequence number synchronization
method. method.
8.10. Interface Description (if=) Link Target Attribute Values Registry 8.10. Interface Description (if=) Link Target Attribute Values Registry
This specification registers the following entry to the "Interface This specification registers the following entry to the "Interface
Description (if=) Link Target Attribute Values Registry" registry, Description (if=) Link Target Attribute Values Registry" registry,
within the "CoRE Parameters" registry: within the "CoRE Parameters" registry:
o Attribute Value: ace-group * Attribute Value: ace.group
o Description: The 'ace group' interface is used to provision keying * Description: The 'ace group' interface is used to provision keying
material and related informations and policies to members of a material and related informations and policies to members of a
group using the Ace framework. group using the Ace framework.
o Reference: [This Document] * Reference: [This Document]
8.11. Expert Review Instructions 8.11. Expert Review Instructions
The IANA Registries established in this document are defined as The IANA Registries established in this document are defined as
expert review. This section gives some general guidelines for what expert review. This section gives some general guidelines for what
the experts should be looking for, but they are being designated as the experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude. experts for a reason so they should be given substantial latitude.
Expert reviewers should take into consideration the following points: Expert reviewers should take into consideration the following points:
o Point squatting should be discouraged. Reviewers are encouraged * Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure to get sufficient information for registration requests to ensure
that the usage is not going to duplicate one that is already that the usage is not going to duplicate one that is already
registered and that the point is likely to be used in deployments. registered and that the point is likely to be used in deployments.
The zones tagged as private use are intended for testing purposes The zones tagged as private use are intended for testing purposes
and closed environments, code points in other ranges should not be and closed environments, code points in other ranges should not be
assigned for testing. assigned for testing.
o Specifications are required for the standards track range of point * Specifications are required for the standards track range of point
assignment. Specifications should exist for specification assignment. Specifications should exist for specification
required ranges, but early assignment before a specification is required ranges, but early assignment before a specification is
available is considered to be permissible. Specifications are available is considered to be permissible. Specifications are
needed for the first-come, first-serve range if they are expected needed for the first-come, first-serve range if they are expected
to be used outside of closed environments in an interoperable way. to be used outside of closed environments in an interoperable way.
When specifications are not provided, the description provided When specifications are not provided, the description provided
needs to have sufficient information to identify what the point is needs to have sufficient information to identify what the point is
being used for. being used for.
o Experts should take into account the expected usage of fields when * Experts should take into account the expected usage of fields when
approving point assignment. The fact that there is a range for approving point assignment. The fact that there is a range for
standards track documents does not mean that a standards track standards track documents does not mean that a standards track
document cannot have points assigned outside of that range. The document cannot have points assigned outside of that range. The
length of the encoded value should be weighed against how many length of the encoded value should be weighed against how many
code points of that length are left, the size of device it will be code points of that length are left, the size of device it will be
used on, and the number of code points left that encode to that used on, and the number of code points left that encode to that
size. size.
9. References 9. References
9.1. Normative References 9.1. Normative References
[COSE.Algorithms] [COSE.Algorithms]
IANA, "COSE Algorithms", IANA, "COSE Algorithms",
<https://www.iana.org/assignments/cose/ <https://www.iana.org/assignments/cose/
cose.xhtml#algorithms>. cose.xhtml#algorithms>.
[COSE.Key.Types]
IANA, "COSE Key Types",
<https://www.iana.org/assignments/cose/
cose.xhtml#key-type>.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 Framework (ACE-OAuth)", Work in Progress, Internet-Draft,
(work in progress), February 2020. draft-ietf-ace-oauth-authz-35, 24 June 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-
authz-35.txt>.
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth- in Constrained Environments (ACE)", Work in Progress,
params-13 (work in progress), April 2020. Internet-Draft, draft-ietf-ace-oauth-params-13, 28 April
2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace-
oauth-params-13.txt>.
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Group OSCORE - Secure Group Communication for CoAP", "Group OSCORE - Secure Group Communication for CoAP", Work
draft-ietf-core-oscore-groupcomm-08 (work in progress), in Progress, Internet-Draft, draft-ietf-core-oscore-
April 2020. groupcomm-09, 23 June 2020, <http://www.ietf.org/internet-
drafts/draft-ietf-core-oscore-groupcomm-09.txt>.
[I-D.ietf-cose-rfc8152bis-algs] [I-D.ietf-cose-rfc8152bis-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-09 Initial Algorithms", Work in Progress, Internet-Draft,
(work in progress), June 2020. draft-ietf-cose-rfc8152bis-algs-11, 1 July 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-cose-
rfc8152bis-algs-11.txt>.
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", draft-ietf-cose-rfc8152bis- Structures and Process", Work in Progress, Internet-Draft,
struct-10 (work in progress), June 2020. draft-ietf-cose-rfc8152bis-struct-11, 1 July 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-cose-
rfc8152bis-struct-11.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
skipping to change at page 49, line 18 skipping to change at page 50, line 23
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>. 2020, <https://www.rfc-editor.org/info/rfc8747>.
9.2. Informative References 9.2. Informative References
[I-D.bormann-core-ace-aif] [I-D.bormann-core-ace-aif]
Bormann, C., "An Authorization Information Format (AIF) Bormann, C., "An Authorization Information Format (AIF)
for ACE", draft-bormann-core-ace-aif-07 (work in for ACE", Work in Progress, Internet-Draft, draft-bormann-
progress), February 2020. core-ace-aif-09, 27 June 2020, <http://www.ietf.org/
internet-drafts/draft-bormann-core-ace-aif-09.txt>.
[I-D.ietf-ace-dtls-authorize] [I-D.ietf-ace-dtls-authorize]
Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS) L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for Profile for Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-dtls- Constrained Environments (ACE)", Work in Progress,
authorize-10 (work in progress), May 2020. Internet-Draft, draft-ietf-ace-dtls-authorize-12, 6 July
2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace-
dtls-authorize-12.txt>.
[I-D.ietf-ace-mqtt-tls-profile] [I-D.ietf-ace-mqtt-tls-profile]
Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile Sengul, C., Kirby, A., and P. Fremantle, "MQTT-TLS profile
of ACE", draft-ietf-ace-mqtt-tls-profile-05 (work in of ACE", Work in Progress, Internet-Draft, draft-ietf-ace-
progress), May 2020. mqtt-tls-profile-05, 28 May 2020, <http://www.ietf.org/
internet-drafts/draft-ietf-ace-mqtt-tls-profile-05.txt>.
[I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE profile of the Authentication and Authorization "OSCORE profile of the Authentication and Authorization
for Constrained Environments Framework", draft-ietf-ace- for Constrained Environments Framework", Work in Progress,
oscore-profile-10 (work in progress), March 2020. Internet-Draft, draft-ietf-ace-oscore-profile-11, 18 June
2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace-
oscore-profile-11.txt>.
[I-D.ietf-core-coap-pubsub] [I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-ietf-core-coap-pubsub-09 (work in (CoAP)", Work in Progress, Internet-Draft, draft-ietf-
progress), September 2019. core-coap-pubsub-09, 30 September 2019,
<http://www.ietf.org/internet-drafts/draft-ietf-core-coap-
pubsub-09.txt>.
[I-D.ietf-core-groupcomm-bis] [I-D.ietf-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", draft- for the Constrained Application Protocol (CoAP)", Work in
ietf-core-groupcomm-bis-00 (work in progress), March 2020. Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
00, 30 March 2020, <http://www.ietf.org/internet-drafts/
draft-ietf-core-groupcomm-bis-00.txt>.
[RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Specification", RFC 2093, Protocol (GKMP) Specification", RFC 2093,
DOI 10.17487/RFC2093, July 1997, DOI 10.17487/RFC2093, July 1997,
<https://www.rfc-editor.org/info/rfc2093>. <https://www.rfc-editor.org/info/rfc2093>.
[RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC 2094, Protocol (GKMP) Architecture", RFC 2094,
DOI 10.17487/RFC2094, July 1997, DOI 10.17487/RFC2094, July 1997,
<https://www.rfc-editor.org/info/rfc2094>. <https://www.rfc-editor.org/info/rfc2094>.
skipping to change at page 51, line 10 skipping to change at page 52, line 25
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
9.3. URIs
[1] mailto:iesg@ietf.org
[2] mailto:francesca.palombini@ericsson.com
Appendix A. Requirements on Application Profiles Appendix A. Requirements on Application Profiles
This section lists the requirements on application profiles of this This section lists the requirements on application profiles of this
specification,for the convenience of application profile designers. specification,for the convenience of application profile designers.
o REQ1: Specify the encoding and value of the identifier of group or * REQ1: Specify the encoding and value of the identifier of group or
topic, for scope entries of 'scope' (see Section 3.1). topic, for scope entries of 'scope' (see Section 3.1).
o REQ2: Specify the encoding and value of roles, for scope entries * REQ2: Specify the encoding and value of roles, for scope entries
of 'scope' (see Section 3.1). of 'scope' (see Section 3.1).
o REQ3: If used, specify the acceptable values for 'sign_alg' (see * REQ3: If used, specify the acceptable values for 'sign_alg' (see
Section 3.3). Section 3.3).
o REQ4: If used, specify the acceptable values for 'sign_parameters' * REQ4: If used, specify the acceptable values for 'sign_parameters'
(see Section 3.3). (see Section 3.3).
o REQ5: If used, specify the acceptable values for * REQ5: If used, specify the acceptable values for
'sign_key_parameters' (see Section 3.3). 'sign_key_parameters' (see Section 3.3).
o REQ6: If used, specify the acceptable values for 'pub_key_enc' * REQ6: If used, specify the acceptable values for 'pub_key_enc'
(see Section 3.3). (see Section 3.3).
o REQ7: Specify the exact format of the 'key' value (see * REQ7: Specify the exact format of the 'key' value (see
Section 4.1.2.1). Section 4.1.2.1).
o REQ8: Specify the acceptable values of 'gkty' (see * REQ8: Specify the acceptable values of 'gkty' (see
Section 4.1.2.1). Section 4.1.2.1).
o REQ9: Specify the format of the identifiers of group members (see * REQ9: Specify the format of the identifiers of group members (see
Section 4.1.2.1). Section 4.1.2.1).
o REQ10: Specify the communication protocol the members of the group * REQ10: Specify the communication protocol the members of the group
must use (e.g., multicast CoAP). must use (e.g., multicast CoAP).
o REQ11: Specify the security protocol the group members must use to * REQ11: Specify the security protocol the group members must use to
protect their communication (e.g., group OSCORE). This must protect their communication (e.g., group OSCORE). This must
provide encryption, integrity and replay protection. provide encryption, integrity and replay protection.
o REQ12: Specify and register the application profile identifier * REQ12: Specify and register the application profile identifier
(see Section 4.1.2.1). (see Section 4.1.2.1).
o REQ13: Specify policies at the KDC to handle ids that are not * REQ13: Specify policies at the KDC to handle ids that are not
included in get_pub_keys (see Section 4.1.3.1). included in get_pub_keys (see Section 4.1.3.1).
o REQ14: If used, specify the format and content of 'group_policies' * REQ14: If used, specify the format and content of 'group_policies'
and its entries (see Section 4.1.2.1). and its entries. Specify the policies default values (see
Section 4.1.2.1).
o REQ15: Specify the format of newly-generated individual keying * REQ15: Specify the format of newly-generated individual keying
material for group members, or of the information to derive it, material for group members, or of the information to derive it,
and corresponding CBOR label (see Section 4.1.6.2). and corresponding CBOR label (see Section 4.1.6.2).
o REQ16: Specify how the communication is secured between Client and * REQ16: Specify how the communication is secured between Client and
KDC. Optionally, specify tranport profile of ACE KDC. Optionally, specify tranport profile of ACE
[I-D.ietf-ace-oauth-authz] to use between Client and KDC (see [I-D.ietf-ace-oauth-authz] to use between Client and KDC (see
Section 4.2. Section 4.2.
o REQ17: Specify how the nonce N_S is generated, if the token is not * REQ17: Specify how the nonce N_S is generated, if the token was
being posted (e.g. if it is used directly to validate TLS not posted (e.g. if it is used directly to validate TLS instead).
instead).
o REQ18: Specify if 'mgt_key_material' used, and if yes specify its * REQ18: Specify if 'mgt_key_material' used, and if yes specify its
format and content (see Section 4.1.2.1). If the usage of format and content (see Section 4.1.2.1). If the usage of
'mgt_key_material' is indicated and its format defined for a 'mgt_key_material' is indicated and its format defined for a
specific key management scheme, that format must explicitly specific key management scheme, that format must explicitly
indicate the key management scheme itself. If a new rekeying indicate the key management scheme itself. If a new rekeying
scheme is defined to be used for an existing 'mgt_key_material' in scheme is defined to be used for an existing 'mgt_key_material' in
an existing profile, then that profile will have to be updated an existing profile, then that profile will have to be updated
accordingly, especially with respect to the usage of accordingly, especially with respect to the usage of
'mgt_key_material' related format and content. 'mgt_key_material' related format and content.
o OPT1: Optionally, specify the encoding of public keys, of * REQ19: Define the initial value of the 'num' parameter (sse
Section 4.1.2.1).
* OPT1: Optionally, specify the encoding of public keys, of
'client_cred', and of 'pub_keys' if COSE_Keys are not used (see 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see
Section 4.1.2.1). Section 4.1.2.1).
o OPT2: Optionally, specify the negotiation of parameter values for * OPT2: Optionally, specify the negotiation of parameter values for
signature algorithm and signature keys, if 'sign_info' and signature algorithm and signature keys, if 'sign_info' is not used
'pub_key_enc' are not used (see Section 3.3). (see Section 3.3).
o OPT3: Optionally, specify the encoding of 'pub_keys_repos' if the * OPT3: Optionally, specify the encoding of 'pub_keys_repos' if the
default is not used (see Section 4.1.2.1). default is not used (see Section 4.1.2.1).
o OPT4: Optionally, specify policies that instruct clients to retain * OPT4: Optionally, specify policies that instruct clients to retain
messages and for how long, if they are unsuccessfully decrypted messages and for how long, if they are unsuccessfully decrypted
(see Section 4.3). This makes it possible to decrypt such (see Section 4.3). This makes it possible to decrypt such
messages after getting updated keying material. messages after getting updated keying material.
o OPT5: Optionally, specify the behavior of the handler in case of * OPT5: Optionally, specify the behavior of the handler in case of
failure to retrieve a public key for the specific node (see failure to retrieve a public key for the specific node (see
Section 4.1.2.1). Section 4.1.2.1).
o OPT6: Optionally, specify possible or required payload formats for * OPT6: Optionally, specify possible or required payload formats for
specific error cases. specific error cases.
o OPT7: Optionally, specify CBOR values to use for abbreviating * OPT7: Optionally, specify CBOR values to use for abbreviating
identifiers of roles in the group or topic (see Section 3.1). identifiers of roles in the group or topic (see Section 3.1).
o OPT8: Optionally, specify policies for the KDC to perform group * OPT8: Optionally, specify policies for the KDC to perform group
rekeying after receiving a Key Renewal Request (see Section 4.4). rekeying after receiving a Key Renewal Request (see Section 4.4).
o OPT9: Optionally, specify the functionalities implemented at the * OPT9: Optionally, specify the functionalities implemented at the
'control_path' resource hosted at the Client, including message 'control_path' resource hosted at the Client, including message
exchange encoding and other details (see Section 4.1.2.1). exchange encoding and other details (see Section 4.1.2.1).
o OPT10: Optionally, specify how the identifier of the sender's * OPT10: Optionally, specify how the identifier of the sender's
public key is included in the group request (see Section 4.6). public key is included in the group request (see Section 4.6).
Appendix B. Document Updates Appendix B. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION. RFC EDITOR: PLEASE REMOVE THIS SECTION.
B.1. Version -04 to -05 B.1. Version -04 to -05
o Updated uppercase/lowercase URI segments for KDC resources. * Updated uppercase/lowercase URI segments for KDC resources.
o Supporting single Access Token for multiple groups/topics. * Supporting single Access Token for multiple groups/topics.
o Added 'control_path' parameter in the Joining Request. * Added 'control_path' parameter in the Joining Request.
o Added 'peer_roles' parameter to support legal requesters/ * Added 'peer_roles' parameter to support legal requesters/
responders. responders.
o Clarification on stopping using owned keying material. * Clarification on stopping using owned keying material.
o Clarification on different reasons for processing failures, * Clarification on different reasons for processing failures,
related policies, and requirement OPT4. related policies, and requirement OPT4.
o Added a KDC sub-resource for group members to upload a new public * Added a KDC sub-resource for group members to upload a new public
key. key.
o Possible group rekeying following an individual Key Renewal * Possible group rekeying following an individual Key Renewal
Request. Request.
o Clarified meaning of requirement REQ3; added requirement OPT8. * Clarified meaning of requirement REQ3; added requirement OPT8.
o Editorial improvements. * Editorial improvements.
B.2. Version -03 to -04 B.2. Version -03 to -04
o Revised RESTful interface, as to methods and parameters. * Revised RESTful interface, as to methods and parameters.
o Extended processing of joining request, as to check/retrieval of * Extended processing of joining request, as to check/retrieval of
public keys. public keys.
o Revised and extended profile requirements. * Revised and extended profile requirements.
o Clarified specific usage of parameters related to signature * Clarified specific usage of parameters related to signature
algorithms/keys. algorithms/keys.
o Included general content previously in draft-ietf-ace-key- * Included general content previously in draft-ietf-ace-key-
groupcomm-oscore groupcomm-oscore
o Registration of media type and content format application/ace- * Registration of media type and content format application/ace-
group+cbor group+cbor
o Editorial improvements. * Editorial improvements.
B.3. Version -02 to -03 B.3. Version -02 to -03
o Exchange of information on the countersignature algorithm and * Exchange of information on the countersignature algorithm and
related parameters, during the Token POST (Section 3.3). related parameters, during the Token POST (Section 3.3).
o Restructured KDC interface, with new possible operations * Restructured KDC interface, with new possible operations
(Section 4). (Section 4).
o Client PoP signature for the Joining Request upon joining * Client PoP signature for the Joining Request upon joining
(Section 4.1.2.1). (Section 4.1.2.1).
o Revised text on group member removal (Section 5). * Revised text on group member removal (Section 5).
o Added more profile requirements (Appendix A). * Added more profile requirements (Appendix A).
B.4. Version -01 to -02 B.4. Version -01 to -02
o Editorial fixes. * Editorial fixes.
o Distinction between transport profile and application profile * Distinction between transport profile and application profile
(Section 1.1). (Section 1.1).
o New parameters 'sign_info' and 'pub_key_enc' to negotiate * New parameters 'sign_info' and 'pub_key_enc' to negotiate
parameter values for signature algorithm and signature keys parameter values for signature algorithm and signature keys
(Section 3.3). (Section 3.3).
o New parameter 'type' to distinguish different Key Distribution * New parameter 'type' to distinguish different Key Distribution
Request messages (Section 4.1). Request messages (Section 4.1).
o New parameter 'client_cred_verify' in the Key Distribution Request * New parameter 'client_cred_verify' in the Key Distribution Request
to convey a Client signature (Section 4.1). to convey a Client signature (Section 4.1).
o Encoding of 'pub_keys_repos' (Section 4.1). * Encoding of 'pub_keys_repos' (Section 4.1).
o Encoding of 'mgt_key_material' (Section 4.1). * Encoding of 'mgt_key_material' (Section 4.1).
o Improved description on retrieval of new or updated keying * Improved description on retrieval of new or updated keying
material (Section 6). material (Section 6).
o Encoding of 'get_pub_keys' in Public Key Request (Section 7.1). * Encoding of 'get_pub_keys' in Public Key Request (Section 7.1).
o Extended security considerations (Sections 10.1 and 10.2). * Extended security considerations (Sections 10.1 and 10.2).
o New "ACE Public Key Encoding" IANA Registry (Section 11.2). * New "ACE Public Key Encoding" IANA Registry (Section 11.2).
o New "ACE Groupcomm Parameters" IANA Registry (Section 11.3), * New "ACE Groupcomm Parameters" IANA Registry (Section 11.3),
populated with the entries in Section 8. populated with the entries in Section 8.
o New "Ace Groupcomm Request Type" IANA Registry (Section 11.4), * New "Ace Groupcomm Request Type" IANA Registry (Section 11.4),
populated with the values in Section 9. populated with the values in Section 9.
o New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated * New "ACE Groupcomm Policy" IANA Registry (Section 11.7) populated
with two entries "Sequence Number Synchronization Method" and "Key with two entries "Sequence Number Synchronization Method" and "Key
Update Check Interval" (Section 4.2). Update Check Interval" (Section 4.2).
o Improved list of requirements for application profiles * Improved list of requirements for application profiles
(Appendix A). (Appendix A).
B.5. Version -00 to -01 B.5. Version -00 to -01
o Changed name of 'req_aud' to 'audience' in the Authorization * Changed name of 'req_aud' to 'audience' in the Authorization
Request (Section 3.1). Request (Section 3.1).
o Defined error handling on the KDC (Sections 4.2 and 6.2). * Defined error handling on the KDC (Sections 4.2 and 6.2).
o Updated format of the Key Distribution Response as a whole * Updated format of the Key Distribution Response as a whole
(Section 4.2). (Section 4.2).
o Generalized format of 'pub_keys' in the Key Distribution Response * Generalized format of 'pub_keys' in the Key Distribution Response
(Section 4.2). (Section 4.2).
o Defined format for the message to request leaving the group * Defined format for the message to request leaving the group
(Section 5.2). (Section 5.2).
o Renewal of individual keying material and methods for group * Renewal of individual keying material and methods for group
rekeying initiated by the KDC (Section 6). rekeying initiated by the KDC (Section 6).
o CBOR type for node identifiers in 'get_pub_keys' (Section 7.1). * CBOR type for node identifiers in 'get_pub_keys' (Section 7.1).
o Added section on parameter identifiers and their CBOR keys * Added section on parameter identifiers and their CBOR keys
(Section 8). (Section 8).
o Added request types for requests to a Join Response (Section 9). * Added request types for requests to a Join Response (Section 9).
o Extended security considerations (Section 10). * Extended security considerations (Section 10).
o New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm * New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm
Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence
Number Synchronization Method Registry" (Section 11). Number Synchronization Method Registry" (Section 11).
o Added appendix about requirements for application profiles of ACE * Added appendix about requirements for application profiles of ACE
on group communication (Appendix A). on group communication (Appendix A).
Acknowledgments Acknowledgments
The following individuals were helpful in shaping this document: The following individuals were helpful in shaping this document:
Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John Mattsson, Daniel Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John Mattsson, Daniel
Migault, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van der Migault, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van der
Stok. Stok.
The work on this document has been partly supported by VINNOVA and The work on this document has been partly supported by VINNOVA and
skipping to change at page 56, line 39 skipping to change at page 58, line 4
The following individuals were helpful in shaping this document: The following individuals were helpful in shaping this document:
Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John Mattsson, Daniel Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John Mattsson, Daniel
Migault, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van der Migault, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van der
Stok. Stok.
The work on this document has been partly supported by VINNOVA and The work on this document has been partly supported by VINNOVA and
the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact
Initiative ACTIVE. Initiative ACTIVE.
Authors' Addresses Authors' Addresses
Francesca Palombini Francesca Palombini
Ericsson AB Ericsson AB
Torshamnsgatan 23 Torshamnsgatan 23
Kista SE-16440 Stockholm SE-16440 Stockholm Kista
Sweden Sweden
Email: francesca.palombini@ericsson.com Email: francesca.palombini@ericsson.com
Marco Tiloca Marco Tiloca
RISE AB RISE AB
Isafjordsgatan 22 Isafjordsgatan 22
Kista SE-16440 Stockholm SE-16440 Stockholm Kista
Sweden Sweden
Email: marco.tiloca@ri.se Email: marco.tiloca@ri.se
 End of changes. 320 change blocks. 
710 lines changed or deleted 740 lines changed or added

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