draft-ietf-ace-key-groupcomm-08.txt   draft-ietf-ace-key-groupcomm-09.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: 14 January 2021 RISE AB Expires: March 8, 2021 RISE AB
13 July 2020 September 4, 2020
Key Provisioning for Group Communication using ACE Key Provisioning for Group Communication using ACE
draft-ietf-ace-key-groupcomm-08 draft-ietf-ace-key-groupcomm-09
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 Discussion Venues
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 14 January 2021. This Internet-Draft will expire on March 8, 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the 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 . . . . . . . . . . . . . . . . 7 3. Authorization to Join a Group . . . . . . . . . . . . . . . . 7
3.1. Authorization Request . . . . . . . . . . . . . . . . . . 7 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 8
3.2. Authorization Response . . . . . . . . . . . . . . . . . 9 3.2. Authorization Response . . . . . . . . . . . . . . . . . 10
3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 11
4. Keying Material Provisioning and Group Membership 4. Keying Material Provisioning and Group Membership
Management . . . . . . . . . . . . . . . . . . . . . . . 14 Management . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 15 4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 16
4.2. Joining Exchange . . . . . . . . . . . . . . . . . . . . 31 4.2. Retrieval of Group Names and URIs . . . . . . . . . . . . 33
4.3. Retrieval of Updated Keying Material . . . . . . . . . . 32 4.3. Joining Exchange . . . . . . . . . . . . . . . . . . . . 33
4.4. Retrieval of New Individual Keying Material . . . . . . . 34 4.4. Retrieval of Updated Keying Material . . . . . . . . . . 35
4.5. Retrieval of Public Keys and Roles for Group Members . . 35 4.5. Requesting a Change of Keying Material . . . . . . . . . 37
4.6. Update of Public Key . . . . . . . . . . . . . . . . . . 35 4.6. Retrieval of Public Keys and Roles for Group Members . . 37
4.7. Retrieval of Group Policies . . . . . . . . . . . . . . . 36 4.7. Update of Public Key . . . . . . . . . . . . . . . . . . 38
4.8. Retrieval of Keying Material Version . . . . . . . . . . 37 4.8. Retrieval of Group Policies . . . . . . . . . . . . . . . 39
4.9. Group Leaving Request . . . . . . . . . . . . . . . . . . 37 4.9. Retrieval of Keying Material Version . . . . . . . . . . 39
5. Removal of a Node from the Group . . . . . . . . . . . . . . 37 4.10. Group Leaving Request . . . . . . . . . . . . . . . . . . 40
6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 38 5. Removal of a Node from the Group . . . . . . . . . . . . . . 40
7. Security Considerations . . . . . . . . . . . . . . . . . . . 40 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 41
7.1. Update of Keying Material . . . . . . . . . . . . . . . . 41 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42
7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 42 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 43
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 44
8.1. Media Type Registrations . . . . . . . . . . . . . . . . 42 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 43 8.1. Media Type Registrations . . . . . . . . . . . . . . . . 45
8.3. OAuth Parameters Registry . . . . . . . . . . . . . . . . 43 8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 46
8.4. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 44 8.3. OAuth Parameters Registry . . . . . . . . . . . . . . . . 46
8.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 44 8.4. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 46
8.6. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 45 8.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 47
8.7. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 45 8.6. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 47
8.8. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 46 8.7. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 48
8.9. Sequence Number Synchronization Method Registry . . . . . 47 8.8. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 49
8.9. Sequence Number Synchronization Method Registry . . . . . 49
8.10. Interface Description (if=) Link Target Attribute Values 8.10. Interface Description (if=) Link Target Attribute Values
Registry . . . . . . . . . . . . . . . . . . . . . . . . 47 Registry . . . . . . . . . . . . . . . . . . . . . . . . 50
8.11. Expert Review Instructions . . . . . . . . . . . . . . . 47 8.11. Expert Review Instructions . . . . . . . . . . . . . . . 50
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
9.1. Normative References . . . . . . . . . . . . . . . . . . 48 9.1. Normative References . . . . . . . . . . . . . . . . . . 51
9.2. Informative References . . . . . . . . . . . . . . . . . 50 9.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix A. Requirements on Application Profiles . . . . . . . . 52
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 54 Appendix A. Requirements on Application Profiles . . . . . . . . 55
B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 54 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 57
B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 55 B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 57
B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 55 B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 58
B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 56 B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 58
B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 56 B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 59
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57 B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
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 51 skipping to change at page 4, line 5
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with 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 uses names or identifiers for groups and nodes. Their
different meanings are summarized here:
* "Group name" is the invariant once established identifier of the
group. It is used in the communication between AS, RS and Client
to identify the group.
* "GROUPNAME" is the invariant once established text string used in
URIs. GROUPNAME maps to the group name of a group, although it is
not necessarily the same.
* "Group identifier" is the identifier of the group keying material.
Opposite to group name and GROUPNAME, this identifier changes over
time, when the keying material is updated.
* "NODENAME" is the invariant once established text string used in
URIs. NODENAME is used to identify a node in a group.
This document additionally uses the following terminology: This document additionally uses the following terminology:
* 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].
* 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 distribution
(re-)distribution of keying material. An application profile may of keying material. An application profile may define specific
define specific procedures and message formats. procedures and message formats.
2. Overview 2. Overview
The full procedure can be separated in two phases: the first follows 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 ACE framework, between Client, AS and KDC. The second part is
the key distribution between Client and KDC. After the two phases the key distribution between Client and KDC. After the two phases
the Client is able to participate in the group communication, via a the Client is able to participate in the group communication, via a
Dispatcher entity. Dispatcher entity.
+------------+ +-----------+ +------------+ +-----------+
skipping to change at page 5, line 34 skipping to change at page 6, line 13
This document specifies a mechanism for: This document specifies a mechanism for:
* 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).
* Allowing a group member to leave the group (Section 5). * Allowing a group member to leave the group (Section 5).
* Evicting a group member from the group (Section 5). * Evicting a group member from the group (Section 5).
* Allowing a group member to retrieve keying material (Section 4.3 * Allowing a group member to retrieve keying material (Section 4.4
and Section 4.4). and Section 4.5).
* Renewing and re-distributing the group keying material (rekeying) * 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.10 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. This exchange between Client hence join the associated group. This exchange between Client
and AS MUST be secured, as specified by the transport profile of and AS MUST be secured, as specified by the transport profile of
ACE used between Client and KDC. The joining node will start or ACE used between Client and KDC. The joining node will start or
skipping to change at page 6, line 14 skipping to change at page 6, line 41
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. This exchange, and all the /authz-info endpoint at the KDC. This exchange, and all
further communications between the Client and the KDC, MUST occur further communications between the Client and the KDC, MUST occur
over the secure channel established as a result of the transport over the secure channel established as a result of the transport
profile of ACE used between Client and KDC. After that, a profile of ACE used between Client and KDC. After that, a
joining node MUST have a secure communication association joining node MUST have a secure communication association
established with the KDC, before starting to join a group under established with the KDC, before starting to join a group under
that KDC. Possible ways to provide a secure communication that KDC. Possible ways to provide a secure communication
association are DTLS [RFC6347] and OSCORE [RFC8613]. association are described in the DTLS transport profile
[I-D.ietf-ace-dtls-authorize] and OSCORE transport profile
[I-D.ietf-ace-oscore-profile] of ACE.
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.
skipping to change at page 7, line 21 skipping to change at page 7, line 50
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 message is the one indicated by the used transport used in the message depends on the used transport profile of ACE.
profile of ACE. For example, this can be application/ace+cbor for For example, this can be application/ace+cbor for the first two
the first two messages and application/cwt for the third message, messages and application/cwt for the third message, which are defined
which are defined in the ACE framework. The transport profile of ACE in the ACE framework. The transport profile of ACE also defines a
also defines a number of details such as the communication and number of details such as the communication and security protocols
security protocols used with the KDC (see Appendix C of used with the KDC (see Appendix C of [I-D.ietf-ace-oauth-authz]).
[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 --------------->|
skipping to change at page 8, line 9 skipping to change at page 8, line 36
values: values:
* '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.
By default, each entry is encoded as specified by By default, each entry is encoded as specified by
[I-D.bormann-core-ace-aif]. It is up to the application profiles [I-D.bormann-core-ace-aif]. The object identifier Toid
to define and register Toid and Tperm to fit the use case. The corresponds to the group name and MUST be encoded as a tstr. The
object identifier Toid corresponds to the group name, while the
permission set Tperm indicates the roles that the client wishes to permission set Tperm indicates the roles that the client wishes to
take in the group. take in the group. It is up to the application profiles to define
Tperm (REQ2) and register Toid and Tperm to fit the use case. An
example of scope using the AIF format is given in Figure 5.
Otherwise, each scope entry can be defined as a CBOR array, which Otherwise, each scope entry can be defined as a CBOR array, which
contains: contains:
- As first element, the identifier of the specific group or - As first element, the identifier of the specific group or
topic. topic, encoded as a tstr.
- 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). audience(s).
In each entry, the encoding of the group or topic identifier (REQ1 In each entry, the encoding of the role identifiers is application
in Appendix A) and of the role identifiers (REQ2) is application specific, and part of the requirements for the application profile
specific, and part of the requirements for the application (REQ2). In particular, the application profile may specify CBOR
profile. values to use for abbreviating role identifiers (OPT7).
In particular, the application profile may specify CBOR values to
use for abbreviating role identifiers (OPT7).
An example of CDDL definition [RFC8610] of scope using the format An example of CDDL definition [RFC8610] of scope using the format
above, with group name and role identifiers encoded as text above, with group name and role identifiers encoded as text
strings is given in Figure 4. strings is given in Figure 4.
* 'audience', with an identifier of a KDC. * 'audience', with an identifier of a KDC.
* '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
skipping to change at page 9, line 21 skipping to change at page 10, line 5
role = tstr role = tstr
scope_entry = [ gname , ? ( 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 name Figure 4: CDLL definition of scope, using as example group name
encoded as tstr and role as tstr encoded as tstr and role as tstr
gname = tstr
permissions = uint . bits roles
roles = &(
Requester: 1,
Responder: 2,
Monitor: 3,
Verifier: 4
)
scope_entry = AIF_Generic<gname, permissions>
scope = << [ + scope_entry ] >>
Figure 5: Example CDLL definition of scope, using the default
Authorization Information Format
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:
* 'access_token', containing the proof-of-possession access token. * 'access_token', containing the proof-of-possession access token.
* '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
skipping to change at page 9, line 49 skipping to change at page 11, line 7
* '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:
* 'scope' containing the scope the AS grants access to. This * 'scope' containing the scope the AS grants access to. This
parameter has the same format and encoding of 'scope' in the parameter has the same format and encoding of 'scope' in the
Authorization Request, defined in Section 3.1. Authorization Request, defined in Section 3.1. If this parameter
is not present the granted scope is equal to the one requested in
Section 3.1}.
Other additional parameters as defined in [I-D.ietf-ace-oauth-authz], Other additional parameters as defined in [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:
* 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);
skipping to change at page 10, line 44 skipping to change at page 12, line 5
[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 information concerning Optionally, the Client might want to request encoding information
the public keys in the group, as well as concerning the algorithm and about the public keys in the group, used for source authentication,
related parameters for computing signatures in the group. In such a as well as any other group parameters. The joining node MAY ask for
case, the joining node MAY ask for that information to the KDC in this information from the KDC in the same message it uses to POST the
this same request. To this end, it sends the CoAP POST request to token to the RS.
the /authz-info endpoint using the Content-Format "application/
ace+cbor".
The payload of the message MUST be formatted as a CBOR map including The payload of the message MUST be formatted as a CBOR map including
the access token. the access token.
Additionally, the CoAP POST request MAY contain the following Additionally, the CoAP POST request MAY contain the following
parameter, which, if included, MUST have the corresponding values: parameter, which, if included, MUST have the corresponding values:
* 'sign_info' defined in Section 3.3.1, encoding the CBOR simple * 'sign_info' defined in Section 3.3.1, encoding the CBOR simple
value Null to require information about the signature algorithm, value Null to require information about the signature algorithm,
signature algorithm parameters, signature key parameters and on signature algorithm parameters, signature key parameters and on
the exact encoding of public keys used in the group. 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.
particular, the KDC replies to the Client with a 2.01 (Created)
response, using Content-Format "application/ace+cbor" defined in The KDC replies to the Client with a 2.01 (Created) response, using
Section 8.14 of [I-D.ietf-ace-oauth-authz]. Content-Format "application/ace+cbor" defined in 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.2, 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 one defined in the ACE format of the response deviates from the one defined in the ACE
framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]), which framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]), which
has no payload. 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.3),
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 signing key, so it is RECOMMENDED
KDC keeps storing the 'kdcchallenge' after the first join is that the 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.3.
If 'sign_info' is included in the request, the KDC MAY include the If 'sign_info' is included in the request, the KDC MAY include the
'sign_info' parameter defined in Section 3.3.1, with the same 'sign_info' parameter defined in Section 3.3.1, with the same
encoding. Note that the field 'id' takes the value of the group name encoding. Note that the field 'id' takes the value of the group name
for which the 'sign_info_entry' applies to. for which the 'sign_info_entry' applies to.
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 Application profiles of this specification MAY define alternative
negotiations of parameter values for signature algorithm and specific negotiations of parameter values for signature algorithm and
signature keys, if 'sign_info' is 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 13, line 27 skipping to change at page 14, line 44
* The fifth element 'pub_key_enc' parameter is either a CBOR integer * The fifth element 'pub_key_enc' parameter is either a CBOR integer
indicating the encoding of public keys used in the group indicating the encoding of public keys used in the group
identified by 'gname', or has value Null indicating that the KDC identified by 'gname', 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 gname formatted as a bstr (note in the response is given below.
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 : gname / [ + gname ], id : gname / [ + gname ],
sign_alg : int / tstr / nil, sign_alg : int / tstr,
sign_parameters : [ any ] / nil, sign_parameters : [ any ],
sign_key_parameters : [ any ] / nil, sign_key_parameters : [ any ],
pub_key_enc = int / nil pub_key_enc = int / nil
] ]
gname = tstr gname = tstr
3.3.2. '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
skipping to change at page 14, line 14 skipping to change at page 15, line 37
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 the group policies or the new keying a group, leave a group, retrieve the group policies or the new keying
material. material.
During the first exchange with the KDC ("Joining") after posting the During the first exchange with the KDC ("Joining") after posting the
Token, the Client sends a request to the KDC, specifying the group it Token, the Client sends a request to the KDC, specifying the group it
wishes to join (see Section 4.2). Then, the KDC verifies the access wishes to join (see Section 4.3). Then, the KDC verifies the access
token and that the Client is authorized to join that group. If so, token and that the Client is authorized to join that group. If so,
it provides the Client with the keying material to securely it provides the Client with the keying material to securely
communicate with the other members of the group. Whenever used, the communicate with the other members of the group. Whenever used, the
Content-Format in messages containing a payload is set to Content-Format in messages containing a payload is set to
application/ace-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:
* The Client can get the current keying material, for cases such as * The Client can get the current keying material, for cases such as
expiration, loss or suspected mismatch, due to e.g. reboot or expiration, loss or suspected mismatch, due to e.g. reboot or
missed group rekeying. This is described in Section 4.3. missed group rekeying. This is described in Section 4.4.
* The Client can retrieve a new individual key, or new input * The Client can retrieve new keying material for itself. This is
material to derive it. This is described in Section 4.4. described in Section 4.5.
* The Client can get the public keys of other group members. This * The Client can get the public keys of other group members. This
is described in Section 4.5. is described in Section 4.6.
* The Client can get the group policies. This is described in * The Client can get the group policies. This is described in
Section 4.7. Section 4.8.
* The Client can 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.9.
* 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.10.
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 name storing a valid access token from that Client for the group name
associated to the endpoint. If that is not the case, i.e. the KDC associated to the endpoint. If that is not the case, i.e. the KDC
does not store a valid access token or this is not valid for that does not store a valid access token or this is not valid for that
Client for the group name, the KDC MUST respond to the Client with a Client for the group name, the KDC MUST respond to 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. Each application profile of this specification
Attribute value ace.group is registered (Section 8.10) and can be MUST register a Resource Type for the root url-path (REQ7a), and that
used to describe this interface. Resource Type can be used to discover the correct url to access at
the KDC. This Resource Type can also be used at the GROUPNAME sub-
resource, to indicate different application profiles for different
groups. The Interface Description (if=) Link Target Attribute value
ace.group is registered (Section 8.10) and can be used to describe
this interface.
* /ace-group: this resource indicates that this specification is * /ace-group: this resource is invariant once established and
used. If other applications run on a KDC implementing this indicates that this specification is used. If other applications
specification and use this same resource, these applications will run on a KDC implementing this specification and use this same
collide, and a mechanism will be needed to differentiate the resource, these applications will collide, and a mechanism will be
endpoints. needed to differentiate the endpoints. This resource supports
FETCH method.
* /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. If the value of the
identified by the group names of the groups the KDC manages (in GROUPNAME URI path and the group name in the access token scope
this example, the group name has value "GROUPNAME"). Each (gname in Section 3.2) don't match, the KDC MUST implement a
resource contains the symmetric group keying material for that mechanism to map the GROUPNAME value in the URI to the group name,
group. These resources support GET and POST method. to retrieve the right group (REQ1). Each resource contains the
symmetric group keying material for that group. These resources
* /ace-group/GROUPNAME/pub-key: this resource contains the public support GET and POST method.
keys of all group members. This resource supports GET and FETCH
methods.
* /ace-group/GROUPNAME/policies: this resource contains the group * /ace-group/GROUPNAME/pub-key: this resource is invariant once
policies. This resource supports the GET method. established and contains the public keys of all group members.
This resource supports GET and FETCH methods.
* /ace-group/GROUPNAME/num: this resource contains the version * /ace-group/GROUPNAME/policies: this resource is invariant once
number for the symmetric group keying material. This sub-resource established and contains the group policies. This resource
supports the GET method. supports the GET method.
* /ace-group/GROUPNAME/num: this resource is invariant once
established and contains the version number for the symmetric
group keying material. This sub-resource supports the GET method.
* /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"). Each resource example, the node name has value "NODENAME"). Each resource
contains the group and individual keying material for that node. contains the group and individual keying material for that node.
These resources support GET, PUT and DELETE methods. These resources support GET, PUT and DELETE methods.
* /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"). Each resource contains the individual public keying "NODENAME"). Each resource contains the individual public keying
material for that node. These resources support the POST method. 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. This resource implements a FETCH handler.
4.1.1.1. FETCH Handler
The FETCH handler receives group identifiers and returns the
corresponding group names and GROUPNAME URIs.
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
following fields:
* 'gid', whose value is encoded as a CBOR array, containing one or
more group identifiers. The exact encoding of group identifier
MUST be specified by the application profile (REQ7b). The Client
indicates that it wishes to receive the group names and GROUPNAMEs
of all groups having these identifiers.
The handler identifies the groups that are secured by the keying
material identified by those group identifiers.
Then, the handler returns a 2.05 (Content) message response with
payload formatted as a CBOR map that MUST contain the following
fields:
* 'gid', whose value is encoded as a CBOR array, containing zero or
more group identifiers. The handler indicates that those are the
identifiers it is sending group names and GROUPNAMEs for. This
CBOR array is a subset of the 'gid' array in the FETCH request.
* 'gname', whose value is encoded as a CBOR array, containing zero
or more group names. The elements of this array are encoded as
text strings. Each element of index i of this CBOR array
corresponds to the element of group identifier i in the 'gid'
array.
* 'guri', whose value is encoded as a CBOR array, containing zero or
more URIs, each indicating a GROUPNAME resource. The elements of
this array are encoded as text strings. Each element of index i
of this CBOR array corresponds to the element of group identifier
i in the 'gid' array.
If the KDC does not find any group associated with the specified
group identifiers, the handler returns a response with payload
formatted as a CBOR byte string of zero length.
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". Note that the material for the group identified by "GROUPNAME". Note that the
group joining exchange is done by the client via this operation, as group joining exchange is done by the client via this operation, as
described in Section 4.2. described in Section 4.3.
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:
* '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.
skipping to change at page 17, line 6 skipping to change at page 19, line 26
- The first array contains zero or more roles (or combination of - The first array contains zero or more roles (or combination of
roles) of group members for the group identified by roles) of group members for the group identified by
"GROUPNAME". The Client indicates that it wishes to receive "GROUPNAME". The Client indicates that it wishes to receive
the public keys of all nodes having these roles. If empty, it the public keys of all nodes having these roles. If empty, it
means the client wishes to receive the public keys of all means the client wishes to receive the public keys of all
nodes. nodes.
- The second array is empty. - The second array is empty.
The CDDL definition [RFC8610] of 'get_pub_keys' is given in The CDDL definition [RFC8610] of 'get_pub_keys' is given in
Figure 5 using as example encoding: node identifier encoded as Figure 6 using as example encoding: node identifier encoded as
byte string, role identifier as text string, and combination of byte string, role identifier as text string, and combination of
roles encoded as a CBOR array of roles. Note that the array ids 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 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- value of "get_pub_keys" received by the handler of FETCH to ace-
group/GROUPNAME/pub-key (see Section 4.1.3.1). group/GROUPNAME/pub-key (see Section 4.1.3.1).
id = bstr id = bstr
role = tstr role = tstr
comb_role = [ 2*role ] comb_role = [ 2*role ]
get_pub_keys = [ [ *(role / comb_role) ], [ *id ] ] get_pub_keys = [ [ *(role / comb_role) ], [ *id ] ]
Figure 5: CDLL definition of get_pub_keys, using as example node Figure 6: CDLL definition of get_pub_keys, using as example node
identifier encoded as bstr and role as tstr identifier encoded as bstr and role as tstr
* 'client_cred', with value the public key or certificate of the * '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 one or more group members. will require for it to send messages to one or more group members.
The default encoding for public keys is COSE Keys. Alternative The default encoding for public keys is COSE Keys. Alternative
specific encodings of this parameter MAY be defined in specific encodings of this parameter MAY be defined in
applications of this specification (OPT1 in Appendix A). applications of this specification (OPT1 in Appendix A).
* 'cnonce', with the same encoding as defined for the "cnonce" * 'cnonce', encoded as a CBOR byte string, and including a dedicated
parameter of Ace, in Section 5.1.2 of [I-D.ietf-ace-oauth-authz], nonce N_C generated by the Client. This parameter MUST be present
and including a dedicated nonce N_C generated by the Client. This if the 'client_cred' parameter is present.
parameter MUST be present if the 'client_cred' parameter is
present.
* 'client_cred_verify', encoded as a CBOR byte string. This * 'client_cred_verify', encoded as a CBOR byte string. This
parameter MUST be present if the 'client_cred' parameter is parameter MUST be present if the 'client_cred' parameter is
present and no 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'.
skipping to change at page 18, line 28 skipping to change at page 21, line 11
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).
* '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.4), 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 extracts the granted scope from the access token, and
checks the requested one against the token one. If this join message
does not include a 'scope' field, the KDC is expected to understand
which group and role the Client is requesting (e.g. there is only one
the Client has been granted). If the KDC can not recognize which
scope the Client is requesting, it MUST respond with a 4.00 (Bad
Request) error message.
The handler verifies that the group name of the /ace-group/GROUPNAME The handler verifies that the group name of the /ace-group/GROUPNAME
path is a subset of the 'scope' stored in the access token associated path is a subset of the 'scope' stored in the access token associated
to this client. If verification fails, the KDC MUST respond with a to this client. If verification fails, the KDC MUST respond with a
4.01 (Unauthorized) error message. The KDC MAY respond with an AS 4.01 (Unauthorized) error message. The KDC MAY respond with an AS
Request Creation Hints, as defined in Section 5.1.2 of Request Creation Hints, as defined in Section 5.1.2 of
[I-D.ietf-ace-oauth-authz]. Note that in this case, the content [I-D.ietf-ace-oauth-authz]. Note that in this case, the content
format MUST be set to application/ace+cbor. format MUST be set to application/ace+cbor.
If the request is not formatted correctly (i.e. required fields non If the request is not formatted correctly (i.e. required fields non
received or received with incorrect format), the handler MUST respond received or received with incorrect format), the handler MUST respond
with a 4.00 (Bad Request) error message. The response MAY contain a with a 4.00 (Bad Request) error message. The response MAY contain a
CBOR map in the payload with ace+cbor format, e.g. it could send back CBOR map in the payload with ace+cbor format, e.g. it could send back
'sign_info_res' with 'pub_key_enc' set to Null if the Client sent its 'sign_info_res' with 'pub_key_enc' set to Null if the Client sent 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. If the request contained unknown or non-expected group members. If the request contained unknown or non-expected
fields present, the handler MUST silently drop them and continue fields present, the handler MUST silently drop them and continue
processing. Application profiles MAY define optional or mandatory 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 is included in the the 'client_cred' field, retrieves it and if one is included in the 'client_cred' field, retrieves it and
associates it to the access token received, after verifications associates it to the access token received, after verifications
succeeded. In particular, the KDC verifies: succeeded. In particular, the KDC verifies:
* 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.
the handler stops the process and responds with a 4.00 (Bad
Request) error message. Applications profiles MAY define
alternatives (OPT5).
* 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.
respond with a 4.00 (Bad Request) error message, and if the token
was posted (see REQ17) including the 'kdcchallenge' associated to If that cannot be verified, it is RECOMMENDED that the handler stops
this Client (see Section 3.3) if it can be retrieved, or otherwise the process and responds with a 4.00 (Bad Request) error message.
newly generated, in a CBOR map in the payload. This error Applications profiles MAY define alternatives (OPT5).
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 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 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 received (see Section 4.3 for an example) and to the group identified
by "GROUPNAME". If that is not the case, the handler responds with a by "GROUPNAME". If that is not the case, the handler responds with a
4.00 Bad Request error response. 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:
skipping to change at page 21, line 18 skipping to change at page 23, line 42
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 6: Key Type Values Figure 7: Key Type Values
The response SHOULD contain the following parameter: The response SHOULD contain the following parameter:
* '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
skipping to change at page 22, line 21 skipping to change at page 25, line 4
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.
* '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 three elements "Sequence Number specification defines the three elements "Sequence Number
Synchronization Method", "Key Update Check Interval" and Synchronization Method", "Key Update Check Interval" and
"Expiration Delta", which are summarized in Figure 7. Application "Expiration Delta", which are summarized in Figure 8. Application
profiles that build on this document MUST specify the exact profiles that build on this document MUST specify the exact
content format and default value of included map 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 | |
skipping to change at page 23, line 38 skipping to change at page 25, line 41
| Delta | | | from 'exp' until | document]] | | Delta | | | from 'exp' until | document]] |
| | | | the specified UTC | | | | | | the specified UTC | |
| | | | date/time after | | | | | | date/time after | |
| | | | which group members| | | | | | which group members| |
| | | | MUST stop using the| | | | | | MUST stop using the| |
| | | | keying material to | | | | | | keying material to | |
| | | | verify incoming | | | | | | verify incoming | |
| | | | messages. | | | | | | messages. | |
+--------------+-------+----------|--------------------|------------+ +--------------+-------+----------|--------------------|------------+
Figure 7: ACE Groupcomm Policies Figure 8: ACE Groupcomm Policies
* '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
skipping to change at page 28, line 19 skipping to change at page 30, line 27
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".
Application profiles MAY also use this handler to rekey the whole
group. (OPT8) It is up to the application profiles to specify if
this handler supports renewal of individual keying material, renewal
of the group keying material or both.
The handler expects a request with empty payload. The handler expects a request with empty payload.
The handler verifies that the group name of the /ace-group/GROUPNAME The handler verifies that the group name of the /ace-group/GROUPNAME
path is a subset of the 'scope' stored in the access token associated path is a subset of the 'scope' stored in the access token associated
to this client, identified by "NODENAME". If verification fails, the to this client, identified by "NODENAME". If verification 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 keying material for the Client,
Client, or information enabling the Client to derive it. The payload and/or, if the application profiles requires it (OPT8), starts the
of the response is formatted as a CBOR map. The specific format of comprete group rekeying. The payload of the response is formatted as
newly-generated individual keying material for group members, or of a CBOR map. The specific format of newly-generated individual keying
the information to derive it, and corresponding CBOR label, MUST be material for group members, or of the information to derive it, and
specified in the application profile (REQ15) and registered in corresponding CBOR label, MUST be specified in the application
Section 8.5. profile (REQ15) and registered in 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 name of the /ace-group/GROUPNAME The handler verifies that the group name of the /ace-group/GROUPNAME
path is a subset of the 'scope' stored in the access token associated path is a subset of the 'scope' stored in the access token associated
to this client, identified by "NODENAME". If verification fails, the to this client, identified by "NODENAME". If verification fails, the
KDC MUST respond with a 4.01 (Unauthorized) error message. KDC MUST respond with a 4.01 (Unauthorized) error message.
skipping to change at page 29, line 26 skipping to change at page 31, line 39
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 accepts a request from the node identified by The handler verifies that the group name of the /ace-group/GROUPNAME
"NODENAME" via the secure session, where NODENAME is used in Uri- path is a subset of the 'scope' stored in the access token associated
Path, and that is part of the "GROUPNAME" group: the handler verifies to this client, identified by "NODENAME". If verification fails, the
that the group name "GROUPNAME" is a subset of the 'scope' stored in KDC MUST respond with a 4.01 (Unauthorized) error message.
the access token associated to this client, and that this client is
identified by "NODENAME". If verification fails, the 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 removes the client from the If verification succeeds, the handler removes the client from the
skipping to change at page 31, line 15 skipping to change at page 33, line 22
'kdcchallenge' in a CBOR map in the payload the payload. This error 'kdcchallenge' in a CBOR map in the payload the payload. This error
response MUST also have Content-Format "application/ace+cbor". response MUST also have Content-Format "application/ace+cbor".
If verification succeeds, the handler replaces the old public key of If verification succeeds, the handler replaces the old public key of
the node NODENAME with the one specified in the 'client_cred' field the node NODENAME with the one specified in the 'client_cred' field
of the request, and stores it as the new current public key of the of the request, and stores it as the new current public key of the
node NODENAME, in the list of group members' public keys for the node NODENAME, in the list of group members' public keys for the
group identified by GROUPNAME. Then, the handler replies with a 2.04 group identified by GROUPNAME. Then, the handler replies with a 2.04
(Changed) response, which does not include a payload. (Changed) response, which does not include a payload.
4.2. Joining Exchange 4.2. Retrieval of Group Names and URIs
Figure 8 gives an overview of the Joining exchange between Client and In case the joining node only knows the group identifier of the group
KDC, when the Client first joins a group. it wishes to join or about which it wishes to get update information
from the KDC, the node can contact the KDC to request the
corresponding group name and joining resource URI. The node can
request several group identifiers at once. It does so by sending a
CoAP FETCH request to the /ace-group endpoint at the KDC formatted as
defined in Section 4.1.1.1.
Figure 9 gives an overview of the exchanges described above.
Client KDC
| |
|-------- Group Name and URI Retrieval Request: -------->|
| FETCH /ace-group |
| |
|<-Group Name and URI Retrieval Response: 2.05 (Content)-|
| |
Figure 9: Message Flow of Group Name and URI Retrieval Request-
Response
4.3. Joining Exchange
Figure 10 gives an overview of the Joining exchange between Client
and 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 10: 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
skipping to change at page 31, line 50 skipping to change at page 34, line 35
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
name of the group to join, formatted as specified in Section 4.1.2.1. name of the group to join, formatted as specified in Section 4.1.2.1.
This group name is the same as in the scope entry corresponding to This group name is the same as in the scope entry corresponding to
that group, specified in the 'scope' parameter of the Authorization that group, specified in the 'scope' parameter of the Authorization
Request/Response, or it can be retrieved from it. Note that, in case Request/Response, or it can be retrieved from it. Note that, in case
of successful joining, the Client will receive the URI to retrieve of successful joining, the Client will receive the URI to retrieve
individual or group keying material and to leave the group in the group keying material and to leave the group in the Location-Path
Location-Path option of the response. 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 32, line 29 skipping to change at page 35, line 15
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 new node's joining the group. To this current group members, upon a new node's joining the group. To this
end, the KDC uses the message format of the response defined in end, the KDC uses the message format of the response defined in
Section 4.1.2.2. Application profiles may define alternative ways of Section 4.1.2.2. Application profiles may define alternative ways of
retrieving the keying material, such as sending separate requests to retrieving the keying material, such as sending separate requests to
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.4. 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.
* 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' parameter in a Joining indicated by the KDC with the 'exp' parameter in a Joining
Response, or to a pre-configured value. Response, or to a pre-configured value.
* Upon receiving a notification of revoked/renewed keying material * Upon receiving a notification of revoked/renewed keying material
skipping to change at page 33, line 23 skipping to change at page 36, line 11
long (OPT4). This allows clients to possibly decrypt such messages long (OPT4). This allows clients to possibly decrypt such messages
after getting updated keying material, rather than just consider them after getting updated keying material, rather than just consider them
non valid messages to discard right away. non valid messages to discard right away.
The same Key Distribution Request could also be sent by the Client The same Key Distribution Request could also be sent by the Client
without being triggered by a failed decryption of a message, if the without being triggered by a failed decryption of a message, if the
Client wants to be sure that it has the latest group keying material. Client wants to be sure that it has the latest group keying material.
If that is the case, the Client will receive from the KDC the same If that is the case, the Client will receive from the KDC the same
group keying material it already has in memory. group keying material it already has in memory.
Figure 9 gives an overview of the exchange described above. Figure 11 gives an overview of the exchange described above.
Client KDC Client KDC
| | | |
|------------------ Key Distribution Request: --------------->| |------------------ Key Distribution Request: --------------->|
| GET ace-group/GROUPNAME/nodes/NODENAME | | GET ace-group/GROUPNAME/nodes/NODENAME |
| | | |
|<-------- Key Distribution Response: 2.05 (Content) ---------| |<-------- Key Distribution Response: 2.05 (Content) ---------|
| | | |
Figure 9: Message Flow of Key Distribution Request-Response Figure 11: 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.:
* 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.
* 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,
skipping to change at page 34, line 13 skipping to change at page 37, line 5
(see Section 4.1.2.1). (see Section 4.1.2.1).
* 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. associations.
Congestion control mechanisms need to be implemented: see Section 4.7 4.5. Requesting a Change of Keying Material
of [RFC7252] and, where Observe is used, Section 4.5.1 of [RFC7641].
4.4. Retrieval of New Individual Keying Material
Beside possible expiration, the client may need to communicate to the Beside possible expiration, the client may need to communicate to the
KDC its need for part of the keying material to be renewed. For KDC its need for the keying material to be renewed, e.g. due to
example, if the Client uses an individual key to protect outgoing exhaustion of AEAD nonces, if AEAD is used for protecting group
traffic and has to renew it, the node may request a new one, or new communnication. Depending on the application profile (OPT8), this
input material to derive it, without renewing the whole group keying can result in renewal of idividual keying material, group keying
material. material, or both. For 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 input material to derive it, without renewing the
whole group keying 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 name and NODENAME is the node's name, and formatted as is the group name and NODENAME is the node's name, and 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 12 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 12: 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 4.6. Retrieval of Public Keys and Roles for Group Members
Renewal Request, the KDC performs a complete group rekeying before or
after replying to the client (OPT8).
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 name, and formatted as defined in KDC, where GROUPNAME is the group name, and formatted as 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 Figure 13 and Figure 14 give an overview of the exchanges described
stores (or updates) the public keys (in the 'pub_keys' parameter) and
roles (in the 'peer_roles' parameter) of the group members.
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 Figure 13: Message Flow of Public Key Exchange to Request All
Members 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 Figure 14: Message Flow of Public Key Exchange to Request
Specific Members Public Keys Specific Members Public Keys
4.6. Update of Public Key 4.7. 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 name 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 15 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 |
| | | |
|<------- Public Key Update Response: 2.04 (Changed) -------------| |<------- Public Key Update Response: 2.04 (Changed) -------------|
| | | |
Figure 13: Message Flow of Public Key Update Request-Response Figure 15: 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). The KDC MUST increment the Section 4.1.3.2, Section 4.1.4.1). The KDC MUST increment the
version number of the current keying material, before distributing version number of the current keying material, before distributing
the newly generated keying material to the group. After that, the the newly generated keying material to the group. After that, the
KDC SHOULD store the distributed keying material in persistent KDC SHOULD store the distributed keying material in persistent
storage. 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.8. 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 name, and policies endpoint at the KDC, where GROUPNAME is the group name, 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 16 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 16: Message Flow of Policies Request-Response
4.8. Retrieval of Keying Material Version 4.9. 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/num endpoint at the a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the
KDC, where GROUPNAME is the group name, formatted as defined in KDC, where GROUPNAME is the group name, formatted as defined in
Section 4.1.5.1. In particular, the version is incremented by the Section 4.1.5.1. In particular, the version is incremented by the
KDC every time the group keying material is renewed, before it's KDC every time the group keying material is renewed, before it's
distributed to the group members. distributed to the group members.
Figure 15 gives an overview of the exchange described above. Figure 17 gives an overview of the exchange described above.
Client KDC Client KDC
| | | |
|---- Version Request: GET ace-group/GROUPNAME/num ---->| |---- Version Request: GET ace-group/GROUPNAME/num ---->|
| | | |
|<--------- Version Response: 2.05 (Content) -----------| |<--------- Version Response: 2.05 (Content) -----------|
| | | |
Figure 15: Message Flow of Version Request-Response Figure 17: Message Flow of Version Request-Response
4.9. Group Leaving Request 4.10. 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 name and NODENAME is the node's name, formatted as defined in group name and NODENAME is the node's name, formatted as 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.4). Application
profiles may define alternative message formats. Before distributing 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.
A node may be evicted from the group in the following cases. A node may be evicted from the group in the following cases.
1. The node explicitly asks to leave the group, as defined in 1. The node explicitly asks to leave the group, as defined in
Section 4.9. Section 4.10.
2. The node has been found compromised or is suspected so. 2. The node has been found compromised or is suspected so.
3. The node's authorization to be a group member is not valid 3. The node's authorization to be a group member is not valid
anymore, either because the access token has expired, or it has anymore, either because the access token has expired, or it has
been revoked. If the AS provides Token introspection (see been revoked. If the AS provides Token introspection (see
Section 5.7 of [I-D.ietf-ace-oauth-authz]), the KDC can Section 5.7 of [I-D.ietf-ace-oauth-authz]), the KDC can
optionally use it and check whether the node is still authorized optionally use it and check whether the node is still authorized
for that group in that role. for that group in that role.
skipping to change at page 39, line 24 skipping to change at page 41, line 49
| 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 | integer / | Section 4.1.2.1 |
| | | string | | | | | text string | |
+-----------------------+------+---------------+------------------+ +-----------------------+------+---------------+------------------+
| key | TBD | see "ACE | Section 4.1.2.1 | | key | TBD | see "ACE | Section 4.1.2.1 |
| | | Groupcomm | | | | | Groupcomm | |
| | | Key" Registry | | | | | Key" Registry | |
+-----------------------+------+---------------+------------------+ +-----------------------+------+---------------+------------------+
| num | TBD | int | Section 4.1.2.1 | | num | TBD | integer | 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 |
+-----------------------+------+---------------+------------------+ +-----------------------+------+---------------+------------------+
| 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 |
+-----------------------+------+---------------+------------------+ +-----------------------+------+---------------+------------------+
| gid | TBD | array | Section 4.1.1.1 |
+-----------------------+------+---------------+------------------+
| gname | TBD | array of text | Section 4.1.1.1 |
| | | string | |
+-----------------------+------+---------------+------------------+
| guri | TBD | array of text | Section 4.1.1.1 |
| | | string | |
+-----------------------+------+---------------+------------------+
Table 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
skipping to change at page 45, line 33 skipping to change at page 48, line 16
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.
* Description: This field contains a brief description of the keying * Description: This field contains a brief description of the keying
material. material.
* 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 6. This Registry has been initially populated by the values in Figure 7.
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
skipping to change at page 47, line 5 skipping to change at page 49, line 39
* CBOR type: the CBOR type used to encode the value of this group * CBOR type: the CBOR type used to encode the value of this group
communication policy. communication policy.
* Description: This field contains a brief description for this * Description: This field contains a brief description for this
group communication policy. group communication policy.
* 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 7. This registry will be initially populated by the values in Figure 8.
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.
skipping to change at page 48, line 46 skipping to change at page 51, line 32
[COSE.Algorithms] [COSE.Algorithms]
IANA, "COSE Algorithms", IANA, "COSE Algorithms",
<https://www.iana.org/assignments/cose/ <https://www.iana.org/assignments/cose/
cose.xhtml#algorithms>. cose.xhtml#algorithms>.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", Work in Progress, Internet-Draft, Framework (ACE-OAuth)", Work in Progress, Internet-Draft,
draft-ietf-ace-oauth-authz-35, 24 June 2020, draft-ietf-ace-oauth-authz-35, June 24, 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-ace-oauth- <http://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-
authz-35.txt>. 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)", Work in Progress, in Constrained Environments (ACE)", Work in Progress,
Internet-Draft, draft-ietf-ace-oauth-params-13, 28 April Internet-Draft, draft-ietf-ace-oauth-params-13, April 28,
2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace- 2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace-
oauth-params-13.txt>. 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", Work "Group OSCORE - Secure Group Communication for CoAP", Work
in Progress, Internet-Draft, draft-ietf-core-oscore- in Progress, Internet-Draft, draft-ietf-core-oscore-
groupcomm-09, 23 June 2020, <http://www.ietf.org/internet- groupcomm-09, June 23, 2020, <http://www.ietf.org/
drafts/draft-ietf-core-oscore-groupcomm-09.txt>. 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", Work in Progress, Internet-Draft, Initial Algorithms", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-algs-11, 1 July 2020, draft-ietf-cose-rfc8152bis-algs-11, July 1, 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-cose- <http://www.ietf.org/internet-drafts/draft-ietf-cose-
rfc8152bis-algs-11.txt>. 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", Work in Progress, Internet-Draft, Structures and Process", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-struct-11, 1 July 2020, draft-ietf-cose-rfc8152bis-struct-12, August 24, 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-cose- <http://www.ietf.org/internet-drafts/draft-ietf-cose-
rfc8152bis-struct-11.txt>. rfc8152bis-struct-12.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 50, line 24 skipping to change at page 53, line 15
[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", Work in Progress, Internet-Draft, draft-bormann- for ACE", Work in Progress, Internet-Draft, draft-bormann-
core-ace-aif-09, 27 June 2020, <http://www.ietf.org/ core-ace-aif-09, June 27, 2020, <http://www.ietf.org/
internet-drafts/draft-bormann-core-ace-aif-09.txt>. 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)", Work in Progress, Constrained Environments (ACE)", Work in Progress,
Internet-Draft, draft-ietf-ace-dtls-authorize-12, 6 July Internet-Draft, draft-ietf-ace-dtls-authorize-12, July 6,
2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace- 2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace-
dtls-authorize-12.txt>. 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", Work in Progress, Internet-Draft, draft-ietf-ace- of ACE", Work in Progress, Internet-Draft, draft-ietf-ace-
mqtt-tls-profile-05, 28 May 2020, <http://www.ietf.org/ mqtt-tls-profile-06, July 13, 2020, <http://www.ietf.org/
internet-drafts/draft-ietf-ace-mqtt-tls-profile-05.txt>. internet-drafts/draft-ietf-ace-mqtt-tls-profile-06.txt>.
[I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE profile of the Authentication and Authorization "OSCORE profile of the Authentication and Authorization
for Constrained Environments Framework", Work in Progress, for Constrained Environments Framework", Work in Progress,
Internet-Draft, draft-ietf-ace-oscore-profile-11, 18 June Internet-Draft, draft-ietf-ace-oscore-profile-11, June 18,
2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace- 2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace-
oscore-profile-11.txt>. 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)", Work in Progress, Internet-Draft, draft-ietf- (CoAP)", Work in Progress, Internet-Draft, draft-ietf-
core-coap-pubsub-09, 30 September 2019, core-coap-pubsub-09, September 30, 2019,
<http://www.ietf.org/internet-drafts/draft-ietf-core-coap- <http://www.ietf.org/internet-drafts/draft-ietf-core-coap-
pubsub-09.txt>. 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)", Work in for the Constrained Application Protocol (CoAP)", Work in
Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
00, 30 March 2020, <http://www.ietf.org/internet-drafts/ 01, July 13, 2020, <http://www.ietf.org/internet-drafts/
draft-ietf-core-groupcomm-bis-00.txt>. draft-ietf-core-groupcomm-bis-01.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>.
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627, Multicast: Issues and Architectures", RFC 2627,
DOI 10.17487/RFC2627, June 1999, DOI 10.17487/RFC2627, June 1999,
<https://www.rfc-editor.org/info/rfc2627>. <https://www.rfc-editor.org/info/rfc2627>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
skipping to change at page 52, line 30 skipping to change at page 55, line 21
[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>.
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.
* REQ1: Specify the encoding and value of the identifier of group or * REQ1: If the value of the GROUPNAME URI path and the group name in
topic, for scope entries of 'scope' (see Section 3.1). the access token scope (gname in Section 3.2) don't match, specify
the mechanism to map the GROUPNAME value in the URI to the group
name (REQ1) (see Section 4.1).
* 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).
* 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).
* 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).
* 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).
* 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).
* REQ7a: Register a Resource Type for the root url-path, which is
used to discover the correct url to access at the KDC (see
Section 4.1).
* REQ7b: Specify the exact encoding of group identifier (see
Section 4.1.1.1).
* 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).
* 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).
* 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).
* REQ10: Specify the communication protocol the members of the group * REQ10: Specify the communication protocol the members of the group
skipping to change at page 53, line 32 skipping to change at page 56, line 32
and its entries. Specify the policies default values (see and its entries. Specify the policies default values (see
Section 4.1.2.1). Section 4.1.2.1).
* 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).
* 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.3.
* REQ17: Specify how the nonce N_S is generated, if the token was * REQ17: Specify how the nonce N_S is generated, if the token was
not posted (e.g. if it is used directly to validate TLS instead). not posted (e.g. if it is used directly to validate TLS instead).
* 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
skipping to change at page 54, line 14 skipping to change at page 57, line 14
* 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' is not used signature algorithm and signature keys, if 'sign_info' is not used
(see Section 3.3). (see Section 3.3).
* 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).
* 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.4). This makes it possible to decrypt such
messages after getting updated keying material. messages after getting updated keying material.
* 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).
* OPT6: Optionally, specify possible or required payload formats for * OPT6: Optionally, specify possible or required payload formats for
specific error cases. specific error cases.
* 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).
* OPT8: Optionally, specify policies for the KDC to perform group * OPT8: Optionally, specify for the KDC to perform group rekeying
rekeying after receiving a Key Renewal Request (see Section 4.4). (together or instead of renewing individual keying material) when
receiving a Key Renewal Request (see Section 4.5).
* 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).
* 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.7).
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
* Updated uppercase/lowercase URI segments for KDC resources. * Updated uppercase/lowercase URI segments for KDC resources.
* Supporting single Access Token for multiple groups/topics. * Supporting single Access Token for multiple groups/topics.
 End of changes. 107 change blocks. 
238 lines changed or deleted 360 lines changed or added

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