draft-ietf-ace-key-groupcomm-09.txt   draft-ietf-ace-key-groupcomm-10.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: March 8, 2021 RISE AB Expires: 6 May 2021 RISE AB
September 4, 2020 2 November 2020
Key Provisioning for Group Communication using ACE Key Provisioning for Group Communication using ACE
draft-ietf-ace-key-groupcomm-09 draft-ietf-ace-key-groupcomm-10
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 March 8, 2021. This Internet-Draft will expire on 6 May 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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . . . . 8 3.1. Authorization Request . . . . . . . . . . . . . . . . . . 8
3.2. Authorization Response . . . . . . . . . . . . . . . . . 10 3.2. Authorization Response . . . . . . . . . . . . . . . . . 10
3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Token Post . . . . . . . . . . . . . . . . . . . . . . . 10
4. Keying Material Provisioning and Group Membership 4. Keying Material Provisioning and Group Membership
Management . . . . . . . . . . . . . . . . . . . . . . . 15 Management . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 16 4.1. Interface at the KDC . . . . . . . . . . . . . . . . . . 15
4.2. Retrieval of Group Names and URIs . . . . . . . . . . . . 33 4.2. Retrieval of Group Names and URIs . . . . . . . . . . . . 33
4.3. Joining Exchange . . . . . . . . . . . . . . . . . . . . 33 4.3. Joining Exchange . . . . . . . . . . . . . . . . . . . . 34
4.4. Retrieval of Updated Keying Material . . . . . . . . . . 35 4.4. Retrieval of Updated Keying Material . . . . . . . . . . 36
4.5. Requesting a Change of Keying Material . . . . . . . . . 37 4.5. Requesting a Change of Keying Material . . . . . . . . . 39
4.6. Retrieval of Public Keys and Roles for Group Members . . 37 4.6. Retrieval of Public Keys and Roles for Group Members . . 40
4.7. Update of Public Key . . . . . . . . . . . . . . . . . . 38 4.7. Update of Public Key . . . . . . . . . . . . . . . . . . 42
4.8. Retrieval of Group Policies . . . . . . . . . . . . . . . 39 4.8. Retrieval of Group Policies . . . . . . . . . . . . . . . 43
4.9. Retrieval of Keying Material Version . . . . . . . . . . 39 4.9. Retrieval of Keying Material Version . . . . . . . . . . 44
4.10. Group Leaving Request . . . . . . . . . . . . . . . . . . 40 4.10. Group Leaving Request . . . . . . . . . . . . . . . . . . 45
5. Removal of a Node from the Group . . . . . . . . . . . . . . 40 5. Removal of a Node from the Group . . . . . . . . . . . . . . 45
6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 41 6. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 46
7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 7. Security Considerations . . . . . . . . . . . . . . . . . . . 48
7.1. Update of Keying Material . . . . . . . . . . . . . . . . 43 7.1. Update of Keying Material . . . . . . . . . . . . . . . . 49
7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 44 7.2. Block-Wise Considerations . . . . . . . . . . . . . . . . 50
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
8.1. Media Type Registrations . . . . . . . . . . . . . . . . 45 8.1. Media Type Registrations . . . . . . . . . . . . . . . . 50
8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 46 8.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 51
8.3. OAuth Parameters Registry . . . . . . . . . . . . . . . . 46 8.3. OAuth Parameters Registry . . . . . . . . . . . . . . . . 51
8.4. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 46 8.4. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 52
8.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 47 8.5. ACE Groupcomm Parameters Registry . . . . . . . . . . . . 52
8.6. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 47 8.6. ACE Groupcomm Key Registry . . . . . . . . . . . . . . . 53
8.7. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 48 8.7. ACE Groupcomm Profile Registry . . . . . . . . . . . . . 53
8.8. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 49 8.8. ACE Groupcomm Policy Registry . . . . . . . . . . . . . . 54
8.9. Sequence Number Synchronization Method Registry . . . . . 49 8.9. Sequence Number Synchronization Method Registry . . . . . 55
8.10. Interface Description (if=) Link Target Attribute Values 8.10. Interface Description (if=) Link Target Attribute Values
Registry . . . . . . . . . . . . . . . . . . . . . . . . 50 Registry . . . . . . . . . . . . . . . . . . . . . . . . 55
8.11. Expert Review Instructions . . . . . . . . . . . . . . . 50 8.11. Expert Review Instructions . . . . . . . . . . . . . . . 55
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
9.1. Normative References . . . . . . . . . . . . . . . . . . 51 9.1. Normative References . . . . . . . . . . . . . . . . . . 56
9.2. Informative References . . . . . . . . . . . . . . . . . 53 9.2. Informative References . . . . . . . . . . . . . . . . . 58
Appendix A. Requirements on Application Profiles . . . . . . . . 55 Appendix A. Requirements on Application Profiles . . . . . . . . 60
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 57 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 63
B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 57 B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 63
B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 58 B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 63
B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 58 B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 64
B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 59 B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 64
B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 59 B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 65
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 60 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66
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. [I-D.ietf-cbor-7049bis], so CBOR is the format used in this
However, using JSON [RFC8259] instead of CBOR is possible, using the specification. However, using JSON [RFC8259] instead of CBOR is
conversion method specified in Sections 4.1 and 4.2 of [RFC7049]. possible, using the conversion method specified in Sections 6.1 and
6.2 of [I-D.ietf-cbor-7049bis].
Profiles that use group communication can build on this document, by Profiles that use group communication can build on this document, by
defining a number of details such as the exact group communication defining a number of details such as the exact group communication
protocol and security protocols used. The specific list of details a protocol and security protocols used. The specific list of details a
profile needs to define is shown in Appendix A. profile needs to define is shown in Appendix A.
If the application requires backward and forward security, new keying If the application requires backward and forward security, new keying
material is generated and distributed to the group upon membership material is generated and distributed to the group upon membership
changes. A key management scheme performs the actual distribution of changes. A key management scheme performs the actual distribution of
the new keying material to the group. In particular, the key the new keying material to the group. In particular, the key
skipping to change at page 4, line 20 skipping to change at page 4, line 20
to identify the group. to identify the group.
* "GROUPNAME" is the invariant once established text string used in * "GROUPNAME" is the invariant once established text string used in
URIs. GROUPNAME maps to the group name of a group, although it is URIs. GROUPNAME maps to the group name of a group, although it is
not necessarily the same. not necessarily the same.
* "Group identifier" is the identifier of the group keying material. * "Group identifier" is the identifier of the group keying material.
Opposite to group name and GROUPNAME, this identifier changes over Opposite to group name and GROUPNAME, this identifier changes over
time, when the keying material is updated. time, when the keying material is updated.
* "Node name" is the invariant once established identifier of the
node. It is used in the communication between AS, RS and Client
to identify a member of the group.
* "NODENAME" is the invariant once established text string used in * "NODENAME" is the invariant once established text string used in
URIs. NODENAME is used to identify a node in a group. 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-
skipping to change at page 4, line 42 skipping to change at page 4, line 46
[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 distribution include, for instance, provisioning, revocation and distribution
of keying material. An application profile may define specific of keying material. An application profile may 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 one
the ACE framework, between Client, AS and KDC. The second part is follows the ACE framework, between Client, AS and KDC; the second one
the key distribution between Client and KDC. After the two phases is the key distribution between Client and KDC. After the two phases
the Client is able to participate in the group communication, via a are completed, the Client is able to participate in the group
Dispatcher entity. communication, via a Dispatcher entity.
+------------+ +-----------+ +------------+ +-----------+
| AS | | KDC | | AS | | KDC |
| | .-------->| | | | .-------->| |
+------------+ / +-----------+ +------------+ / +-----------+
^ / ^ /
| / | /
v / +-----------+ v / +-----------+
+------------+ / +------------+ |+-----------+ +------------+ / +------------+ |+-----------+
| Client |<-' | Dispatcher | ||+-----------+ | Client |<-' | Dispatcher | ||+-----------+
skipping to change at page 6, line 52 skipping to change at page 6, line 52
[I-D.ietf-ace-dtls-authorize] and OSCORE transport profile [I-D.ietf-ace-dtls-authorize] and OSCORE transport profile
[I-D.ietf-ace-oscore-profile] of ACE. [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. joining node.
4. The joining node and the KDC maintain the secure association, to 4. The joining node and the KDC maintain the secure association, to
support possible future communications. These especially include support possible future communications. These especially include
key management operations, such as retrieval of updated keying key management operations, such as retrieval of updated keying
material or participation to a group rekeying process. material or participation to a group rekeying process.
5. The joining node can communicate securely with the other group 5. The joining node can communicate securely with the other group
members, using the keying material provided in step 3. members, using the keying material provided in step 3.
C AS KDC Group C AS KDC Group
skipping to change at page 8, line 32 skipping to change at page 8, line 32
The Authorization Request sent from the Client to the AS is defined The Authorization Request sent from the Client to the AS is defined
in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the
following parameters, which, if included, MUST have the corresponding following parameters, which, if included, MUST have the corresponding
values: values:
* '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, wrapping 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]. The object identifier Toid [I-D.ietf-ace-aif]. The object identifier Toid corresponds to the
corresponds to the group name and MUST be encoded as a tstr. The group name and MUST be encoded as a tstr. The permission set
permission set Tperm indicates the roles that the client wishes to Tperm indicates the roles that the client wishes to take in the
take in the group. It is up to the application profiles to define group. It is up to the application profiles to define Tperm
Tperm (REQ2) and register Toid and Tperm to fit the use case. An (REQ2) and register Toid and Tperm to fit the use case. An
example of scope using the AIF format is given in Figure 5. example of scope using the AIF format is given in Figure 4.
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, encoded as a tstr. 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
skipping to change at page 9, line 16 skipping to change at page 9, line 16
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 role identifiers is application In each entry, the encoding of the role identifiers is application
specific, and part of the requirements for the application profile specific, and part of the requirements for the application profile
(REQ2). In particular, the application profile may specify CBOR (REQ2). In particular, the application profile may specify CBOR
values to use for abbreviating role identifiers (OPT7). 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 5.
* 'audience', with an identifier of a KDC. * 'audience', with an identifier of a KDC.
* 'req_cnf', as defined in Section 3.1 of As defined in [I-D.ietf-ace-oauth-authz], other additional parameters
[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
communicate that to the AS.
Other additional parameters as defined in [I-D.ietf-ace-oauth-authz],
can be included if necessary. can be included if necessary.
As in [I-D.ietf-ace-oauth-authz], these parameters are included in
the payload, which is formatted as a CBOR map. The Content-Format
"application/ace+cbor" defined in Section 8.14 of
[I-D.ietf-ace-oauth-authz] is used.
gname = tstr
role = tstr
scope_entry = [ gname , ? ( role / [ 2*role ] ) ]
scope = << [ + scope_entry ] >>
Figure 4: CDLL definition of scope, using as example group name
encoded as tstr and role as tstr
gname = tstr gname = tstr
permissions = uint . bits roles permissions = uint . bits roles
roles = &( roles = &(
Requester: 1, Requester: 1,
Responder: 2, Responder: 2,
Monitor: 3, Monitor: 3,
Verifier: 4 Verifier: 4
) )
scope_entry = AIF_Generic<gname, permissions> scope_entry = AIF_Generic<gname, permissions>
scope = << [ + scope_entry ] >> scope = << [ + scope_entry ] >>
Figure 5: Example CDLL definition of scope, using the default Figure 4: Example CDLL definition of scope, using the default
Authorization Information Format Authorization Information Format
3.2. Authorization Response gname = tstr
The Authorization Response sent from the AS to the Client is defined role = tstr
in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST contain the
following parameters:
* 'access_token', containing the proof-of-possession access token. scope_entry = [ gname , ? ( role / [ 2*role ] ) ]
* 'cnf' if symmetric keys are used, not present if asymmetric keys scope = << [ + scope_entry ] >>
are used. This parameter is defined in Section 3.2 of
[I-D.ietf-ace-oauth-params] and contains the symmetric proof-of-
possession key that the Client is supposed to use with the KDC.
* 'rs_cnf' if asymmetric keys are used, not present if symmetric Figure 5: CDLL definition of scope, using as example group name
keys are used. This parameter is defined in Section 3.2 of encoded as tstr and role as tstr
[I-D.ietf-ace-oauth-params] and contains information about the
public key of the KDC.
* 'expires_in', contains the lifetime in seconds of the access 3.2. Authorization Response
token. This parameter MAY be omitted if the application defines
how the expiration time is communicated to the Client via other
means, or if it establishes a default value.
Additionally, the Authorization Response MAY contain the following The Authorization Response sent from the AS to the Client is defined
parameters, which, if included, MUST have the corresponding values: in Section 5.6.2 of [I-D.ietf-ace-oauth-authz]. Note that the
parameter 'expires_in' MAY be omitted if the application defines how
the expiration time is communicated to the Client via other means, or
if it establishes a default value.
* 'scope' containing the scope the AS grants access to. This Additionally, when included, the following parameter MUST have the
parameter has the same format and encoding of 'scope' in the corresponding values:
* 'scope' has the same format and encoding of 'scope' in the
Authorization Request, defined in Section 3.1. If this parameter Authorization Request, defined in Section 3.1. If this parameter
is not present the granted scope is equal to the one requested in is not present, the granted scope is equal to the one requested in
Section 3.1}. Section 3.1}.
Other additional parameters as defined in [I-D.ietf-ace-oauth-authz],
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);
* an expiration time claim (see for example 'exp' defined in * an expiration time claim (see for example 'exp' defined in
Section 3.1.4 of [RFC8392] for CWT); Section 3.1.4 of [RFC8392] for CWT);
* a scope claim (see for example 'scope' registered in Section 8.13 * a scope claim (see for example 'scope' registered in Section 8.13
of [I-D.ietf-ace-oauth-authz] for CWT). This claim has the same of [I-D.ietf-ace-oauth-authz] for CWT). This claim has the same
encoding as 'scope' parameter above. Additionally, this claim has encoding as the 'scope' parameter above. Additionally, this claim
the same value of the 'scope' parameter if the parameter is has the same value of the 'scope' parameter if the parameter is
present in the message, or it takes the value of 'scope' in the present in the message, or it takes the value of 'scope' in the
Authorization Request otherwise. Authorization Request otherwise.
The access token MAY additionally contain other claims that the The access token MAY additionally contain other claims that the
transport profile of ACE requires, or other optional parameters. transport profile of ACE requires, or other optional parameters.
As in [I-D.ietf-ace-oauth-authz], these parameters are included in
the payload, which is formatted as a CBOR map. The Content-Format
"application/ace+cbor" is used.
When receiving an Authorization Request from a Client that was When receiving an Authorization Request from a Client that was
previously authorized, and for which the AS still owns a valid non- previously authorized, and for which the AS still owns a valid non-
expired access token, the AS MAY reply with that token. Note that it expired access token, the AS MAY reply with that token. Note that it
is up to application profiles of ACE to make sure that re-posting the is up to application profiles of ACE to make sure that re-posting the
same token does not cause re-use of keying material between nodes same token does not cause re-use of keying material between nodes
(for example, that is done with the use of random nonces in (for example, that is done with the use of random nonces in
[I-D.ietf-ace-oscore-profile]). [I-D.ietf-ace-oscore-profile]).
3.3. Token Post 3.3. Token Post
The Client sends a CoAP POST request including the access token to The Client sends a CoAP POST request including the access token to
the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]. the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz].
If the specific transport profile of ACE defines it, the Client MAY
use a different endpoint than /authz-info at the KDC to post the
access token to.
Optionally, the Client might want to request encoding information This request differs from the one defined in
about the public keys in the group, used for source authentication, [I-D.ietf-ace-oauth-authz], because it allows to transport additional
as well as any other group parameters. The joining node MAY ask for encoding information about the public keys in the group, used for
this information from the KDC in the same message it uses to POST the source authentication, as well as any other group parameters. The
token to the RS. joining node MAY ask for this information from the KDC in the same
message it uses to POST the token to the RS.
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
skipping to change at page 12, line 35 skipping to change at page 11, line 36
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. the group keying material from the KDC and join the group.
The KDC replies to the Client with a 2.01 (Created) response, using The KDC replies to the Client with a 2.01 (Created) response, using
Content-Format "application/ace+cbor" defined in Section 8.14 of Content-Format "application/ace+cbor" defined in Section 8.14 of
[I-D.ietf-ace-oauth-authz]. [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 3.3.2, specifying a
a dedicated challenge N_S generated by the KDC. The Client uses this 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.3), 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 that the Client possesses its own private key.
be reused several times by the Client, to generate new proof of The same challenge MAY be reused several times by the Client, to
possessions, e.g. in case of update of the public key, or to join a generate a new proof of possession, e.g. in case of update of the
different group with a different signing key, so it is RECOMMENDED public key, or to join a different group with a different signing
that the KDC keeps storing the 'kdcchallenge' after the first join is key, so it is RECOMMENDED that the KDC keeps storing the
processed as well. If the KDC has already discarded the 'kdcchallenge' after the first join is processed as well. If the KDC
'kdcchallenge', that will trigger an error response with a newly has already discarded the 'kdcchallenge', that will trigger an error
generated 'kdcchallenge' that the client can use to restart the join response with a newly generated 'kdcchallenge' that the Client can
process, as specified in Section 4.3. use to restart the join 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. Application profiles MAY define
the additional parameters to use within this exchange (OPT2b).
Application profiles of this specification MAY define alternative Application profiles of this specification MAY define alternative
specific negotiations of parameter values for signature algorithm and specific negotiations of parameter values for the signature algorithm
signature keys, if 'sign_info' is not used (OPT2). and signature keys, if 'sign_info' is not used (OPT2a).
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 14, line 7 skipping to change at page 13, line 7
value Null, to require information and parameters on the signature value Null, to require information and parameters on the signature
algorithm and on the public keys used. algorithm and on the public keys used.
The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as
in the request is given below. in the request is given below.
sign_info_req = nil sign_info_req = nil
The 'sign_info' parameter of the 2.01 (Created) response is a CBOR The 'sign_info' parameter of the 2.01 (Created) response is a CBOR
array of one or more elements. The number of elements is at most the array of one or more elements. The number of elements is at most the
number of groups the client has been authorized to join. Each number of groups that the client has been authorized to join. Each
element contains information about signing parameters and keys for element contains information about signing parameters and keys for
one or more group or topic and is formatted as follows. one or more group or topic, and is formatted as follows.
* The first element 'id' is an identifier of the group or an array * The first element 'id' is a group name or an array of group names
of identifiers for the groups for which this information applies. for the group(s) for which this information applies. Below, each
specified group name is referred to as 'gname'.
* The second element 'sign_alg' is an integer or a text string if * The second element 'sign_alg' is an integer or a text string if
the POST request included the 'sign_info' parameter with value the POST request included the 'sign_info' parameter with value
Null, and indicates the signature algorithm used in the group Null, and indicates the signature algorithm used in the group(s)
identified by 'gname'. It is REQUIRED of the application profiles identified by (the set of) 'gname'. It is REQUIRED of the
to define specific values that this parameter can take (REQ3), application profiles to define specific values that this parameter
selected from the set of signing algorithms of the COSE Algorithms can take (REQ3), selected from the set of signing algorithms of
registry [COSE.Algorithms]. the COSE Algorithms registry [COSE.Algorithms].
* The third element 'sign_parameters' is a CBOR array indicating the * The third element 'sign_parameters' is a CBOR array indicating the
parameters of the signature algorithm. Its content depends on the parameters of the signature algorithm used in the group(s)
identified by (the set of) 'gname'. Its content depends on the
value of 'sign_alg'. It is REQUIRED of the application profiles value of 'sign_alg'. It is REQUIRED of the application profiles
to define the possible values and structure for the elements of to define the possible values and structure for the elements of
this parameter (REQ4). this parameter (REQ4).
* The fourth element 'sign_key_parameters' is a CBOR array * The fourth element 'sign_key_parameters' is a CBOR array
indicating the parameters of the key used with the signature indicating the parameters of the key used with the signature
algorithm. Its content depends on the value of 'sign_alg'. It is algorithm, in the group(s) identified by (the set of) 'gname'.
REQUIRED of the application profiles to define the possible values Its content depends on the value of 'sign_alg'. It is REQUIRED of
and structure for the elements of this parameter (REQ5). the application profiles to define the possible values and
structure for the elements of this parameter (REQ5).
* 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(s)
identified by 'gname', or has value Null indicating that the KDC identified by (the set of) 'gname', or has value Null indicating
does not act as repository of public keys for group members. Its that the KDC does not act as repository of public keys for group
acceptable values are taken from the "CWT Confirmation Method" members. Its acceptable values are taken from the "CWT
Registry defined in [RFC8747]. It is REQUIRED of the application Confirmation Method" Registry defined in [RFC8747]. It is
profiles to define specific values to use for this parameter REQUIRED of the application profiles to define specific values to
(REQ6). use for this parameter (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. in the response is given below.
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, sign_alg : int / tstr,
sign_parameters : [ any ], sign_parameters : [ any ],
sign_key_parameters : [ any ], 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.8.1 of
[I-D.ietf-ace-oauth-authz]. This parameter contains a challenge [I-D.ietf-ace-oauth-authz]. This parameter contains a challenge
generated by the KDC and provided to the Client. The Client may use generated by the KDC and provided to the Client. The Client may use
this challenge to prove possession of its own private key in the this challenge to prove possession of its own private key in the
Joining Request (see the 'client_cred_verify' parameter in Joining Request (see the 'client_cred_verify' parameter in
Section 4). Section 4).
4. Keying Material Provisioning and Group Membership Management 4. Keying Material Provisioning and Group Membership Management
This section defines the interface available at the KDC. Moreover, This section defines the interface available at the KDC. Moreover,
this section specifies how the clients can use this interface to join this section specifies how the clients can use this interface to join
skipping to change at page 16, line 8 skipping to change at page 15, line 8
* 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.4. missed group rekeying. This is described in Section 4.4.
* The Client can retrieve new keying material for itself. This is * The Client can retrieve new keying material for itself. This is
described in Section 4.5. 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.6. is described in Section 4.6.
* The Client can upload a new, updated public key at the KDC. This
is described in Section 4.7.
* The Client can get the group policies. This is described in * The Client can get the group policies. This is described in
Section 4.8. 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.9. 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.10. 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
skipping to change at page 16, line 42 skipping to change at page 15, line 45
the KDC. This Resource Type can also be used at the GROUPNAME sub- the KDC. This Resource Type can also be used at the GROUPNAME sub-
resource, to indicate different application profiles for different resource, to indicate different application profiles for different
groups. The Interface Description (if=) Link Target Attribute value groups. The Interface Description (if=) Link Target Attribute value
ace.group is registered (Section 8.10) and can be used to describe ace.group is registered (Section 8.10) and can be used to describe
this interface. this interface.
* /ace-group: this resource is invariant once established and * /ace-group: this resource is invariant once established and
indicates that this specification is used. If other applications indicates that this specification is used. If other applications
run on a KDC implementing this specification and use this same run on a KDC implementing this specification and use this same
resource, these applications will collide, and a mechanism will be resource, these applications will collide, and a mechanism will be
needed to differentiate the endpoints. This resource supports needed to differentiate the endpoints. This resource supports the
FETCH method. 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. If the value of the implemented for each group the KDC manages.
GROUPNAME URI path and the group name in the access token scope
(gname in Section 3.2) don't match, the KDC MUST implement a If the value of the GROUPNAME URI path and the group name in the
mechanism to map the GROUPNAME value in the URI to the group name, access token scope ('gname' in Section 3.2) do not match, the KDC
to retrieve the right group (REQ1). Each resource contains the MUST implement a mechanism to map the GROUPNAME value in the URI
symmetric group keying material for that group. These resources to the group name, in order to retrieve the right group (REQ1).
support GET and POST method. Each resource contains the symmetric group keying material for
that group. These resources support the GET and POST methods.
* /ace-group/GROUPNAME/pub-key: this resource is invariant once * /ace-group/GROUPNAME/pub-key: this resource is invariant once
established and contains the public keys of all group members. established and contains the public keys of all group members.
This resource supports GET and FETCH methods. This resource supports the GET and FETCH methods.
* /ace-group/GROUPNAME/policies: this resource is invariant once * /ace-group/GROUPNAME/policies: this resource is invariant once
established and contains the group policies. This 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 * /ace-group/GROUPNAME/num: this resource is invariant once
established and contains the version number for the symmetric established and contains the version number for the symmetric
group keying material. This sub-resource supports the GET method. 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 the 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.
It is REQUIRED of the application profiles of this specification to
define what operations (i.e. CoAP methods) are allowed on each
resource, for each role defined in Section 3.1 according to REQ2
(REQ7aa).
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
This resource implements a FETCH handler. This resource implements a FETCH handler.
4.1.1.1. FETCH Handler 4.1.1.1. FETCH Handler
skipping to change at page 18, line 33 skipping to change at page 17, line 48
* 'guri', whose value is encoded as a CBOR array, containing zero or * 'guri', whose value is encoded as a CBOR array, containing zero or
more URIs, each indicating a GROUPNAME resource. The elements of more URIs, each indicating a GROUPNAME resource. The elements of
this array are encoded as text strings. Each element of index i this array are encoded as text strings. Each element of index i
of this CBOR array corresponds to the element of group identifier of this CBOR array corresponds to the element of group identifier
i in the 'gid' array. i in the 'gid' array.
If the KDC does not find any group associated with the specified If the KDC does not find any group associated with the specified
group identifiers, the handler returns a response with payload group identifiers, the handler returns a response with payload
formatted as a CBOR byte string of zero length. formatted as a CBOR byte string of zero length.
Note that the KDC only verifies that the node is authorized by the AS
to access this resource. Nodes that are not members of the group but
are authorized to do signature verifications on the group messages
may be allowed to access this resource, if the application needs it.
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.3. 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 name, and
and role(s). This value is a CBOR byte string encoding one scope role(s). This value is a CBOR byte string wrapping one scope
entry, as defined in Section 3.1. entry, as defined in Section 3.1.
* 'get_pub_keys', if the Client wishes to receive the public keys of * 'get_pub_keys', if the Client wishes to receive the public keys of
the other nodes in the group from the KDC. This parameter may be the other nodes in the group from the KDC. This parameter may be
present if the KDC stores the public keys of the nodes in the present if the KDC stores the public keys of the nodes in the
group and distributes them to the Client; it is useless to have group and distributes them to the Client; it is useless to have
here if the set of public keys of the members of the group is here if the set of public keys of the members of the group is
known in another way, e.g. it was provided by the AS. Note that known in another way, e.g. it was provided by the AS. Note that
including this parameter may result in a large message size for including this parameter may result in a large message size for
the following response, which can be inconvenient for resource- the following response, which can be inconvenient for resource-
constrained devices. The parameter's value is a non-empty CBOR constrained devices. The parameter's value is either the CBOR
array containing two CBOR arrays: simple value Null or a non-empty CBOR array containing two CBOR
arrays:
- The first array contains zero or more roles (or combination of - The first array is non-empty. Each element of the first array
roles) of group members for the group identified by contains one role or a combination of roles for the group
"GROUPNAME". The Client indicates that it wishes to receive identified by "GROUPNAME". The Client indicates that it wishes
the public keys of all nodes having these roles. If empty, it to receive the public keys of all group members having any of
means the client wishes to receive the public keys of all the single roles, or at least all of the roles indicated in any
nodes. combinations of roles. For example, the array ["role1",
"role2+role3"] indicates that the Client wishes to receive the
public keys of all group members that have at least "role1" or
at least both "role2" and "role3".
- The second array is empty. - The second array is empty.
If the Client wishes to receive all public keys of all group
members, it encodes the 'get_pub_key' parameter as the CBOR simple
value Null.
The CDDL definition [RFC8610] of 'get_pub_keys' is given in The CDDL definition [RFC8610] of 'get_pub_keys' is given in
Figure 6 using as example encoding: node identifier encoded as Figure 6, using as example encoding: node identifier encoded as a
byte string, role identifier as text string, and combination of CBOR byte string; role identifier encoded as a CBOR text string,
roles encoded as a CBOR array of roles. Note that the array ids and combination of roles encoded as a CBOR array of roles.
is empty for this handler, but is not necessarily empty for the
value of "get_pub_keys" received by the handler of FETCH to ace-
group/GROUPNAME/pub-key (see Section 4.1.3.1).
id = bstr Note that the second array (array of node identifiers) is empty
for this handler, because the joining node is not expected to
filter based on node identifiers, but is not necessarily empty for
the value of 'get_pub_keys' received by the handler of FETCH to
ace-group/GROUPNAME/pub-key (see Section 4.1.3.1).
role = tstr Also note that the second array (array of roles) is non-empty for
this handler, but that is not necessarily the case for other
handlers using this parameter: if this array is empty it means
that the client is not filtering public keys based on roles.
comb_role = [ 2*role ] Finally, 'get_pub_keys' is never used as an array containing two
empty arrays (in CBOR diagnostic notation: [ [ ], [ ] ] ), so if
this parameter is received as formatted in that way, it has to be
considered malformed.
get_pub_keys = [ [ *(role / comb_role) ], [ *id ] ] id = bstr
role = tstr
comb_role = [ 2*role ]
get_pub_keys = null / [ [ *(role / comb_role) ], [ *id ] ]
Figure 6: 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.
skipping to change at page 20, line 13 skipping to change at page 20, line 9
applications of this specification (OPT1 in Appendix A). applications of this specification (OPT1 in Appendix A).
* 'cnonce', encoded as a CBOR byte string, and including a dedicated * 'cnonce', encoded as a CBOR byte string, and including a dedicated
nonce N_C generated by the Client. This parameter MUST be present nonce N_C generated by the Client. This parameter MUST be present
if the 'client_cred' parameter is 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 following signature input: the
concatenated with N_C, where: scope (encoded as CBOR byte string), concatenated with N_S
(encoded as CBOR byte string) concatenated with N_C (encoded as
CBOR byte string), where:
- scope is the byte string specified in the 'scope parameter - scope is the CBOR byte string either specified in the 'scope'
above'. parameter above, if present, or as a default scope that the
handler is expected to understand, if omitted.
- N_S is the challenge received from the KDC in the - N_S is the challenge received from the KDC in the
'kdcchallenge' parameter of the 2.01 (Created) response to the 'kdcchallenge' parameter of the 2.01 (Created) response to the
token POST request (see Section 3.3). token POST request (see Section 3.3), encoded as a CBOR byte
string.
- N_C is the nonce generated by the Client and specified in the - N_C is the nonce generated by the Client and specified in the
'cnonce' parameter above. 'cnonce' parameter above, encoded as a CBOR byte string.
An example of signature input construction to compute
'client_cred_verify' using CBOR encoding is given in Figure 7.
If the token was not posted (e.g. if it is used directly to If the token was not posted (e.g. if it is used directly to
validate TLS instead), it is REQUIRED of the specific profile to validate TLS instead), it is REQUIRED of the specific profile to
define how the challenge N_S is generated (REQ17). The Client define how the challenge N_S is generated (REQ17). The Client
computes the signature by using its own private key, whose computes the signature by using its own private key, whose
corresponding public key is either directly specified in the corresponding public key is either directly specified in the
'client_cred' parameter or included in the certificate specified 'client_cred' parameter or included in the certificate specified
in the 'client_cred' parameter. in the 'client_cred' parameter.
* 'pub_keys_repos', can be present if a certificate is present in * 'pub_keys_repos', can be present if a certificate is present in
skipping to change at page 21, line 20 skipping to change at page 21, line 9
individual provisioning of new keying material when performing a individual provisioning of new keying material when performing a
group rekeying (see Section 4.4), 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.
scope, N_S, and N_C expressed in CBOR diagnostic notation:
scope = h'826667726F7570316673656E646572'
N_S = h'018a278f7faab55a'
N_C = h'25a8991cd700ac01'
scope, N_S, and N_C as CBOR encoded byte strings:
scope = 0x4f826667726F7570316673656E646572
N_S = 0x48018a278f7faab55a
N_C = 0x4825a8991cd700ac01
input to client_cred_verify signature =
0x4f 826667726F7570316673656E646572 48 018a278f7faab55a 48 25a8991cd700ac01
Figure 7: Example of signature input construction to compute
'client_cred_verify' using CBOR encoding
The handler extracts the granted scope from the access token, and The handler extracts the granted scope from the access token, and
checks the requested one against the token one. If this join message checks the requested one against the token one. If the requested one
does not include a 'scope' field, the KDC is expected to understand is not a subset of the token one, the KDC MUST respond with a 4.01
which group and role the Client is requesting (e.g. there is only one (Unauthorized) error message. If this join message does not include
the Client has been granted). If the KDC can not recognize which a 'scope' field, the KDC is expected to understand which group and
scope the Client is requesting, it MUST respond with a 4.00 (Bad role(s) the Client is requesting (e.g. there is only one the Client
Request) error message. 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 KDC verifies that the group name of the /ace-group/GROUPNAME path
path is a subset of the 'scope' stored in the access token associated is a subset of the 'scope' stored in the access token associated to
to this client. If verification fails, the KDC MUST respond with a this client. The KDC also verifies that the roles the client is
4.01 (Unauthorized) error message. The KDC MAY respond with an AS granted in the group allow it to perform this operation on this
Request Creation Hints, as defined in Section 5.1.2 of resource (REQ7aa). If either verification fails, the KDC MUST
[I-D.ietf-ace-oauth-authz]. Note that in this case, the content respond with a 4.01 (Unauthorized) error message. The KDC MAY
format MUST be set to application/ace+cbor. respond with an AS Request Creation Hints, as defined in
Section 5.1.2 of [I-D.ietf-ace-oauth-authz]. Note that in this case,
the content 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 content format application/ace+cbor,
'sign_info_res' with 'pub_key_enc' set to Null if the Client sent its e.g. it could send back 'sign_info_res' with 'pub_key_enc' set to
own public key and the KDC is not set to store public keys of the Null if the Client sent its own public key and the KDC is not set to
group members. If the request contained unknown or non-expected store public keys of the group members. If the request contained
fields present, the handler MUST silently drop them and continue unknown or non-expected fields present, the handler MUST silently
processing. Application profiles MAY define optional or mandatory drop them and continue processing. Application profiles MAY define
payload formats for specific error cases (OPT6). optional or mandatory 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 '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. parameters.
skipping to change at page 22, line 32 skipping to change at page 22, line 42
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.3 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:
* Adds the node to the list of current members of the group. * Adds the node to the list of current members of the group.
* Assigns a name NODENAME to the node, and creates a sub-resource to * Assigns a name NODENAME to the node, and creates a sub-resource to
/ace-group/GROUPNAME/ at the KDC (e.g. "/ace- /ace-group/GROUPNAME/ at the KDC (e.g. "/ace-
group/GROUPNAME/nodes/NODENAME"). group/GROUPNAME/nodes/NODENAME").
* Associates the identifier "NODENAME" with the access token and the * Associates the identifier "NODENAME" with the access token and the
skipping to change at page 23, line 30 skipping to change at page 23, line 42
* 'key', containing the keying material for the group communication, * 'key', containing the keying material for the group communication,
or information required to derive it. or information required to derive it.
* 'num', containing the version number of the keying material for * 'num', containing the version number of the keying material for
the group communication, formatted as an integer. This is a the group communication, formatted as an integer. This is a
strictly monotonic increasing field. The application profile MUST strictly monotonic increasing field. The application profile MUST
define the initial version number (REQ19). define the initial version number (REQ19).
The exact format of the 'key' value MUST be defined in applications The exact format of the 'key' value MUST be defined in applications
of this specification (REQ7), as well as accepted values of 'gkty' by of this specification (REQ7), as well as values of 'gkty' accepted by
the application (REQ8). Additionally, documents specifying the key the application (REQ8). Additionally, documents specifying the key
format MUST register it in the "ACE Groupcomm Key" registry defined format MUST register it in the "ACE Groupcomm Key" registry defined
in Section 8.6, including its name, type and application profile to in Section 8.6, including its name, type and application profile to
be used with. be used with.
+----------+----------------+---------+-------------------------+ +----------+----------------+---------+-------------------------+
| Name | Key Type Value | Profile | Description | | Name | Key Type Value | Profile | Description |
+----------+----------------+---------+-------------------------+ +----------+----------------+---------+-------------------------+
| Reserved | 0 | | This value is reserved | | Reserved | 0 | | This value is reserved |
+----------+----------------+---------+-------------------------+ +----------+----------------+---------+-------------------------+
Figure 8: 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 24, line 31 skipping to change at page 24, line 34
parameter in the "ACE Groupcomm Profile" Registry (REQ12). parameter in the "ACE Groupcomm Profile" Registry (REQ12).
* 'pub_keys', may only be present if 'get_pub_keys' was present in * 'pub_keys', may only be present if 'get_pub_keys' was present in
the request. This parameter is a CBOR byte string, which encodes the request. This parameter is a CBOR byte string, which encodes
the public keys of all the group members paired with the the public keys of all the group members paired with the
respective member identifiers. The default encoding for public respective member identifiers. The default encoding for public
keys is COSE Keys, so the default encoding for 'pub_keys' is a keys is COSE Keys, so the default encoding for 'pub_keys' is a
CBOR byte string wrapping a COSE_KeySet (see CBOR byte string wrapping a COSE_KeySet (see
[I-D.ietf-cose-rfc8152bis-struct]), which contains the public keys [I-D.ietf-cose-rfc8152bis-struct]), which contains the public keys
of all the members of the group. In particular, each COSE Key in of all the members of the group. In particular, each COSE Key in
the COSE_KeySet includes the identifier of the corresponding group the COSE_KeySet includes the node identifier of the corresponding
member as value of its 'kid' key parameter. Alternative specific group member as value of its 'kid' key parameter. Alternative
encodings of this parameter MAY be defined in applications of this specific encodings of this parameter MAY be defined in
specification (OPT1). The specific format of the identifiers of applications of this specification (OPT1). The specific format of
group members MUST be specified in the application profile (REQ9). the node identifiers of group members MUST be specified in the
application profile (REQ9).
* 'peer_roles', MUST be present if 'pub_keys' is present. This * 'peer_roles', MUST be present if 'pub_keys' is present. This
parameter is a CBOR array of n elements, with n the number of parameter is a CBOR array of n elements, with n the number of
members in the group (and number of public keys included in the public keys included in the 'pub_keys' parameter (at most the
'pub_keys' parameter). The i-th element of the array specifies number of members in the group). The i-th element of the array
the role (or CBOR array of roles) that the group member associated specifies the role (or CBOR array of roles) that the group member
to the i-th public key in 'pub_keys' has in the group. In associated to the i-th public key in 'pub_keys' has in the group.
particular, each array element is encoded as the role element of a In particular, each array element is encoded as the role element
scope entry, as defined in Section 3.1. of a 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 8. Application "Expiration Delta", which are summarized in Figure 9. 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 | |
| tion Method | | | sequence numbers | | | tion Method | | | sequence numbers | |
| | | | of a sender node. | | | | | | of a sender node. | |
| | | | Its value is taken | | | | | | Its value is taken | |
| | | | from the 'Value' | | | | | | from the 'Value' | |
| | | | column of the | | | | | | column of the | |
| | | | Sequence Number | | | | | | Sequence Number | |
| | | | Synchronization | | | | | | Synchronization | |
| | | | Method registry | | | | | | Method registry | |
| | | | | | | | | | | |
| Key Update | TBD2 | int | Polling interval | [[this | | Key Update | TBD2 | int | Polling interval | [[this |
| Check | | | in seconds, to | document]] | | Check | | | in seconds, to | document]] |
| Interval | | | check for new | | | Interval | | | check for new | |
| | | | keying material at | | | | | | keying material at | |
| | | | the KDC | | | | | | the KDC | |
| | | | | | | | | | | |
| Expiration | TBD3 | uint | Number of seconds | [[this | | Expiration | TBD3 | uint | Number of seconds | [[this |
| 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 8: ACE Groupcomm Policies Figure 9: 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 26, line 23 skipping to change at page 26, line 33
CBOR labels for these fields are defined in Section 6. CBOR labels for these fields are defined in Section 6.
4.1.2.2. GET Handler 4.1.2.2. GET Handler
The GET handler returns the symmetric group keying material for the The GET handler returns the symmetric group keying material for the
group identified by "GROUPNAME". group identified by "GROUPNAME".
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group name of the /ace-group/GROUPNAME The KDC verifies that the group name of the /ace-group/GROUPNAME path
path is a subset of the 'scope' stored in the access token associated is a subset of the 'scope' stored in the access token associated to
to this client. If verification fails, the KDC MUST respond with a this client. The KDC also verifies that the roles the client is
4.01 (Unauthorized) error message. The KDC MAY respond with an AS granted in the group allow it to perform this operation on this
Request Creation Hints, as defined in Section 5.1.2 of resource (REQ7aa). If either verification fails, the KDC MUST
[I-D.ietf-ace-oauth-authz]. Note that in this case, the content respond with a 4.01 (Unauthorized) error message. The KDC MAY
format MUST be set to application/ace+cbor. respond with an AS Request Creation Hints, as defined in
Section 5.1.2 of [I-D.ietf-ace-oauth-authz]. Note that in this case
the content format MUST be set to application/ace+cbor.
Additionally, the handler verifies that the node is a current member Additionally, the handler verifies that the node is a current member
of the group. If verification fails, the KDC MUST respond with a of the group. If verification fails, the KDC MUST respond with a
4.00 (Bad Request) error message. 4.01 (Unauthorized) error message.
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing the symmetric group keying material. The payload message containing the symmetric group keying material. The payload
of the response is formatted as a CBOR map which MUST contain the of the response is formatted as a CBOR map which MUST contain the
parameters 'gkty','key' and 'num' specified in Section 4.1.2.1. parameters 'gkty', 'key' and 'num' specified in Section 4.1.2.1.
The payload MAY also include the parameters 'ace-groupcomm-profile', The payload MAY also include the parameters 'ace-groupcomm-profile',
'exp', and 'mgt_key_material' parameters specified in 'exp', and 'mgt_key_material' parameters specified in
Section 4.1.2.1. Section 4.1.2.1.
4.1.3. ace-group/GROUPNAME/pub-key 4.1.3. ace-group/GROUPNAME/pub-key
If the KDC does not maintain public keys for the group, the handler If the KDC does not maintain public keys for the group, the handler
for any request on this resource returns a 4.05 (Method Not Allowed) for any request on this resource returns a 4.05 (Method Not Allowed)
error message. If it does, the rest of this section applies. error message. If it does, the rest of this section applies.
This resource implements GET and FETCH handlers. This resource implements GET and FETCH handlers.
4.1.3.1. FETCH Handler 4.1.3.1. FETCH Handler
The FETCH handler receives identifiers of group members for the group The FETCH handler receives identifiers of group members for the group
identified by "GROUPNAME" and returns the public keys of such group identified by "GROUPNAME" and returns the public keys of such group
members. members.
The handler expects a request with payload formatted as a CBOR map. The handler expects a request with payload formatted as a CBOR map,
The payload of this request is a CBOR Map that MUST contain the that MUST contain the following fields:
following fields:
* 'get_pub_keys', whose value is encoded as in Section 4.1.2.1 with * 'get_pub_keys', whose value is encoded as in Section 4.1.2.1 with
the following modification: the following modification:
- The second array contains zero or more identifiers of group - The first array may be empty, if the Client does not wish to
members for the group identified by "GROUPNAME". The Client filter the requested public keys based on roles of group
indicates that it wishes to receive the public keys of all members.
nodes having these identifiers.
- The second array contains zero or more node identifiers of
group members, for the group identified by "GROUPNAME". The
Client indicates that it wishes to receive the public keys of
all nodes having these node identifiers.
As mentioned, both arrays can not be empty at the same time.
The specific format of public keys as well as identifiers, roles and The specific format of public keys as well as identifiers, roles and
combination of roles of group members MUST be specified by the combination of roles of group members MUST be specified by the
application profile (OPT1, REQ2, REQ9). application profile (OPT1, REQ2, REQ9).
The handler verifies that the group name of the /ace-group/GROUPNAME The KDC verifies that the group name of the /ace-group/GROUPNAME path
path is a subset of the 'scope' stored in the access token associated is a subset of the 'scope' stored in the access token associated to
to this client. If verification fails, the KDC MUST respond with a this client. The KDC also verifies that the roles the client is
4.01 (Unauthorized) error message. granted in the group allow it to perform this operation on this
resource (REQ7aa). If either verification fails, the KDC MUST
respond with a 4.01 (Unauthorized) error message.
If verification succeeds, the handler identifies the public keys of If verification succeeds, the handler identifies the public keys of
the current group members for which either: the current group members for which either:
* the role identifier matches with one of those indicated in the * the role identifier matches with one of those indicated in the
request; note that the request can contain a "combination of request; note that the request can contain a "combination of
roles", where the handler select all group members who have all roles", where the handler select all group members who have all
roles included in the combination. roles included in the combination.
* the identifier matches with one of those indicated in the request. * the node identifier matches with one of those indicated in the
request.
Then, the handler returns a 2.05 (Content) message response with Then, the handler returns a 2.05 (Content) message response with
payload formatted as a CBOR map, containing only the 'pub_keys' and payload formatted as a CBOR map, containing only the 'pub_keys' and
'peer_roles' parameters from Section 4.1.2.1. In particular, 'peer_roles' parameters from Section 4.1.2.1. In particular,
'pub_keys' encodes the list of public keys of those group members 'pub_keys' encodes the list of public keys of those group members
including the respective member identifiers, while 'peer_roles' including the respective member identifiers, while 'peer_roles'
encodes their respective role (or CBOR array of roles) in the group. encodes their respective role (or CBOR array of roles) in the group.
The specific format of public keys as well as of identifiers of group The specific format of public keys as well as of node identifiers of
members is specified by the application profile (OPT1, REQ9). group members is specified by the application profile (OPT1, REQ9).
If the KDC does not store any public key associated with the If the KDC does not store any public key associated with the
specified member identifiers, the handler returns a response with specified node identifiers, the handler returns a response with
payload formatted as a CBOR byte string of zero length. payload formatted as a CBOR byte string of zero length.
The handler MAY enforce one of the following policies, in order to The handler MAY enforce one of the following policies, in order to
handle possible identifiers that are included in the 'get_pub_keys' handle possible node identifiers that are included in the
parameter of the request but are not associated to any current group 'get_pub_keys' parameter of the request but are not associated to any
member. Such a policy MUST be specified by the application profile current group member. Such a policy MUST be specified by the
(REQ13) application profile (REQ13).
* The KDC silently ignores those identifiers. * The KDC silently ignores those node identifiers.
* The KDC retains public keys of group members for a given amount of * The KDC retains public keys of group members for a given amount of
time after their leaving, before discarding them. As long as such time after their leaving, before discarding them. As long as such
public keys are retained, the KDC provides them to a requesting public keys are retained, the KDC provides them to a requesting
Client. Client.
Note that this resource handler only verifies that the node is Note that this resource handler only verifies that the node is
authorized by the AS to access this resource. Nodes that are not authorized by the AS to access this resource. Nodes that are not
members of the group but are authorized to do signature verifications members of the group but are authorized to do signature verifications
on the group messages may be allowed to access this resource, if the on the group messages may be allowed to access this resource, if the
application needs it. application needs it.
4.1.3.2. GET Handler 4.1.3.2. GET Handler
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group name of the /ace-group/GROUPNAME The KDC performs the same verifications as the FETCH handler in
path is a subset of the 'scope' stored in the access token associated Section 4.1.3.1, and if successful returns the same response as in
to this client. If verification fails, the KDC MUST respond with a Section 4.1.3.1 but without filtering based on roles or node
4.01 (Unauthorized) error message. identifiers: all the group members' public keys are returned.
If verification succeeds, the handler returns a 2.05 (Content)
message containing the public keys of all the current group members,
for the group identified by "GROUPNAME". The payload of the response
is formatted as a CBOR map, containing only the 'pub_keys' and
'peer_roles' parameters from Section 4.1.2.1. In particular,
'pub_keys' encodes the list of public keys of those group members
including the respective member identifiers, while 'peer_roles'
encodes their respective role (or CBOR array of roles) in the group.
If the KDC does not store any public key for the group, the handler
returns a response with payload formatted as a CBOR byte string of
zero length. The specific format of public keys as well as of
identifiers of group members is specified by the application profile
(OPT1, REQ9).
Note that this resource handler only verifies that the node is Note that this resource handler, as the FETCH handler for the same
authorized by the AS to access this resource. Nodes that are not resource, only verifies that the node is authorized by the AS to
members of the group but are authorized to do signature verifications access this resource. Nodes that are not members of the group but
on the group messages may be allowed to access this resource, if the are authorized to do signature verifications on the group messages
application needs it. may be allowed to access this resource, if the application needs it.
4.1.4. ace-group/GROUPNAME/policies 4.1.4. ace-group/GROUPNAME/policies
This resource implements a GET handler. This resource implements a GET handler.
4.1.4.1. GET Handler 4.1.4.1. GET Handler
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group name of the /ace-group/GROUPNAME The KDC verifies that the group name of the /ace-group/GROUPNAME path
path is a subset of the 'scope' stored in the access token associated is a subset of the 'scope' stored in the access token associated to
to this client. If verification fails, the KDC MUST respond with a this client. The KDC also verifies that the roles the client is
4.01 (Unauthorized) error message. granted in the group allow it to perform this operation on this
resource (REQ7aa). If either verification fails, the 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.01 (Unauthorized) error message.
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing the list of policies for the group identified by message containing the list of policies for the group identified by
"GROUPNAME". The payload of the response is formatted as a CBOR map "GROUPNAME". The payload of the response is formatted as a CBOR map
including only the parameter 'group_policies' defined in including only the parameter 'group_policies' defined in
Section 4.1.2.1 and specifying the current policies in the group. If Section 4.1.2.1 and specifying the current policies in the group. If
the KDC does not store any policy, the payload is formatted as a the KDC does not store any policy, the payload is formatted as a
zero-length CBOR byte string. zero-length CBOR byte string.
The specific format and meaning of group policies MUST be specified The specific format and meaning of group policies MUST be specified
in the application profile (REQ14). in the application profile (REQ14).
4.1.5. ace-group/GROUPNAME/num 4.1.5. ace-group/GROUPNAME/num
This resource implements a GET handler. This resource implements a GET handler.
4.1.5.1. GET Handler 4.1.5.1. GET Handler
The handler expects a GET request. The handler expects a GET request.
The handler verifies that the group name of the /ace-group/GROUPNAME The KDC verifies that the group name of the /ace-group/GROUPNAME path
path is a subset of the 'scope' stored in the access token associated is a subset of the 'scope' stored in the access token associated to
to this client. If verification fails, the KDC MUST respond with a this client. The KDC also verifies that the roles the client is
4.01 (Unauthorized) error message. granted in the group allow it to perform this operation on this
resource (REQ7aa). If either verification fails, the 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.01 (Unauthorized) error message.
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing an integer that represents the version number of message containing an integer that represents the version number of
the symmetric group keying material. This number is incremented on the symmetric group keying material. This number is incremented on
the KDC every time the KDC updates the symmetric group keying the KDC every time the KDC updates the symmetric group keying
material, before the new keying material is distributed. This number material, before the new keying material is distributed. This number
is stored in persistent storage. is stored in persistent storage.
The payload of the response is formatted as a CBOR integer. The payload of the response is formatted as a CBOR integer.
4.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 Application profiles MAY also use this handler to rekey the whole
group. (OPT8) It is up to the application profiles to specify if group. It is up to the application profiles to specify if this
this handler supports renewal of individual keying material, renewal handler supports renewal of individual keying material, renewal of
of the group keying material or both. the group keying material or both (OPT8).
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 KDC verifies that the group name of the /ace-group/GROUPNAME path
path is a subset of the 'scope' stored in the access token associated is a subset of the 'scope' stored in the access token associated to
to this client, identified by "NODENAME". If verification fails, the this client, identified by "NODENAME". The KDC also verifies that
KDC MUST respond with a 4.01 (Unauthorized) error message. the roles the client is granted in the group allow it to perform this
operation on this resource (REQ7aa). If either verification fails,
the 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.01 (Unauthorized) error message.
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing newly-generated keying material for the Client, message containing newly-generated keying material for the Client,
and/or, if the application profiles requires it (OPT8), starts the and/or, if the application profiles requires it (OPT8), starts the
comprete group rekeying. The payload of the response is formatted as complete group rekeying. The payload of the response is formatted as
a CBOR map. The specific format of newly-generated individual keying a CBOR map. The specific format of newly-generated individual keying
material for group members, or of the information to derive it, and material for group members, or of the information to derive it, and
corresponding CBOR label, MUST be specified in the application corresponding CBOR label, MUST be specified in the application
profile (REQ15) and registered in 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 KDC verifies that the group name of the /ace-group/GROUPNAME path
path is a subset of the 'scope' stored in the access token associated is a subset of the 'scope' stored in the access token associated to
to this client, identified by "NODENAME". If verification fails, the this client, identified by "NODENAME". The KDC also verifies that
KDC MUST respond with a 4.01 (Unauthorized) error message. the roles the client is granted in the group allow it to perform this
operation on this resource (REQ7aa). If either 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.01 (Unauthorized) error message.
If verification succeeds, the handler returns a 2.05 (Content) If verification succeeds, the handler returns a 2.05 (Content)
message containing both the group keying material and the individual message containing both the group keying material and the individual
keying material for the Client, or information enabling the Client to keying material for the Client, or information enabling the Client to
derive it. The payload of the response is formatted as a CBOR map. derive it. The payload of the response is formatted as a CBOR map.
The format for the group keying material is the same as defined in The format for the group keying material is the same as defined in
the response of Section 4.1.2.2. The specific format of individual the response of Section 4.1.2.2. The specific format of individual
keying material for group members, or of the information to derive keying material for group members, or of the information to derive
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 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". The KDC also verifies that
KDC MUST respond with a 4.01 (Unauthorized) error message. the roles the client is granted in the group allow it to perform this
operation on this resource (REQ7aa). If either 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.01 (Unauthorized) error message.
If verification succeeds, the handler removes the client from the If verification succeeds, the handler removes the client from the
group identified by "GROUPNAME", for specific roles if roles were group identified by "GROUPNAME", for specific roles if roles were
specified in the 'scope' field, or for all roles. That includes specified in the 'scope' field, or for all roles. That includes
removing the public key of the client if the KDC keep tracks of that. removing the public key of the client if the KDC keep tracks of that.
Then, the handler delete the sub-resource nodes/NODENAME and returns Then, the handler delete the sub-resource nodes/NODENAME and returns
a 2.02 (Deleted) message with empty payload. a 2.02 (Deleted) message with empty payload.
4.1.7. ace-group/GROUPNAME/nodes/NODENAME/pub-key 4.1.7. ace-group/GROUPNAME/nodes/NODENAME/pub-key
skipping to change at page 32, line 34 skipping to change at page 32, line 45
The handler expects a POST request with payload as specified in The handler expects a POST request with payload as specified in
Section 4.1.2.1, with the difference that it includes only the Section 4.1.2.1, with the difference that it includes only the
parameters 'client_cred', 'cnonce' and 'client_cred_verify'. In parameters 'client_cred', 'cnonce' and 'client_cred_verify'. In
particular, the signature included in 'client_cred_verify' is particular, the signature included in 'client_cred_verify' is
expected to be computed as defined in Section 4.1.2.1, with a newly expected to be computed as defined in Section 4.1.2.1, with a newly
generated N_C nonce and the previously received N_S. The specific generated N_C nonce and the previously received N_S. The specific
format of public keys is specified by the application profile (OPT1). format of public keys is specified by the application profile (OPT1).
The handler verifies that the group name GROUPNAME is a subset of the The handler verifies that the group name GROUPNAME is a subset of the
'scope' stored in the access token associated to this client. If 'scope' stored in the access token associated to this client. The
verification fails, the KDC MUST respond with a 4.01 (Unauthorized) KDC also verifies that the roles the client is granted in the group
error message. allow it to perform this operation on this resource (REQ7aa). If
either verification fails, the KDC MUST respond with a 4.01
(Unauthorized) error message.
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. If the request contained with a 4.00 (Bad Request) error message. If the request contains
unknown or non-expected fields present, the handler MUST silently unknown or non-expected fields present, the handler MUST silently
drop them and continue processing. Application profiles MAY define ignore them and continue processing. Application profiles MAY define
optional or mandatory payload formats for specific error cases optional or mandatory payload formats for specific error cases
(OPT6). (OPT6).
Otherwise, the handler checks that the public key specified in the Otherwise, the handler checks that the public key specified in the
'client_cred' field has a valid format for the group identified by 'client_cred' field has a valid format for the group identified by
"GROUPNAME", i.e. it is encoded as expected and is compatible with "GROUPNAME", i.e. it is encoded as expected and is compatible with
the signature algorithm and possible associated parameters. If that the signature algorithm and possible associated parameters. If that
cannot be verified, the handler MUST respond with a 4.00 (Bad cannot be successfully verified, the handler MUST respond with a 4.00
Request) error message. Applications profiles MAY define (Bad Request) error message. Applications profiles MAY define
alternatives (OPT5). alternatives (OPT5).
Otherwise, the handler verifies the signature contained in the Otherwise, the handler verifies the signature contained in the
'client_cred_verify' field of the request, using the public key 'client_cred_verify' field of the request, using the public key
specified in the 'client_cred' field. If the signature does not pass specified in the 'client_cred' field. If the signature does not pass
verification, the handler MUST respond with a 4.00 (Bad Request) verification, the handler MUST respond with a 4.01 (Unauthorized)
error message. If the KDC cannot retrieve the 'kdcchallenge' error message. If the KDC cannot retrieve the 'kdcchallenge'
associated to this Client (see Section 3.3), the KDC MUST respond associated to this Client (see Section 3.3), the KDC MUST respond
with a 4.00 Bad Request error respons, including a newly generated with a 4.00 Bad Request error response, whose payload is a CBOR map
'kdcchallenge' in a CBOR map in the payload the payload. This error including a newly generated 'kdcchallenge'. This error response MUST
response MUST also have Content-Format "application/ace+cbor". 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. Retrieval of Group Names and URIs 4.2. Retrieval of Group Names and URIs
In case the joining node only knows the group identifier of the group In case the joining node only knows the group identifier of the group
it wishes to join or about which it wishes to get update information 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 from the KDC, the node can contact the KDC to request the
corresponding group name and joining resource URI. The node can corresponding group name and joining resource URI. The node can
request several group identifiers at once. It does so by sending a 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 CoAP FETCH request to the /ace-group endpoint at the KDC formatted as
defined in Section 4.1.1.1. defined in Section 4.1.1.1.
Figure 9 gives an overview of the exchanges described above. Figure 10 gives an overview of the exchanges described above, and
Figure 11 shows an example.
Client KDC Client KDC
| | | |
|-------- Group Name and URI Retrieval Request: -------->| |-------- Group Name and URI Retrieval Request: -------->|
| FETCH /ace-group | | FETCH /ace-group |
| | | |
|<-Group Name and URI Retrieval Response: 2.05 (Content)-| |<-Group Name and URI Retrieval Response: 2.05 (Content)-|
| | | |
Figure 9: Message Flow of Group Name and URI Retrieval Request- Figure 10: Message Flow of Group Name and URI Retrieval Request-
Response Response
Request:
Header: FETCH (Code=0.05)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation):
{ "gid": [01, 02] }
Response:
Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation):
{ "gid": [01, 02], "gname": ["group1", "group2"],
"guri": ["kdc.example.com/g1", "kdc.example.com/g2"] }
Figure 11: Example of Group Name and URI Retrieval Request-Response
4.3. Joining Exchange 4.3. Joining Exchange
Figure 10 gives an overview of the Joining exchange between Client Figure 12 gives an overview of the Joining exchange between Client
and KDC, when the Client first joins a group. and KDC, when the Client first joins a group, while Figure 13 shows
an example.
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 10: Message Flow of First Exchange for Group Joining Figure 12: Message Flow of First Exchange for Group Joining
Request:
Header: POST (Code=0.02)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation,
with PUB_KEY and SIG being CBOR byte strings):
{ "scope": << [ "group1", ["sender", "receiver"] ] >> ,
"get_pub_keys": [["sender"], []], "client_cred": PUB_KEY
"cnonce": h'6df49c495409a9b5', "client_cred_verify": SIG }
Response:
Header: Created (Code=2.01)
Content-Format: "application/ace-groupcomm+cbor"
Location-Path: "kdc.example.com"
Location-Path: "g1"
Location-Path: "nodes"
Location-Path: "c101"
Payload (in CBOR diagnostic notation,
with KEY being a CBOR byte strings):
{ "gkty": 13, "key": KEY, "num": 12, "exp": 1609459200,
"pub_keys": << [ PUB_KEY1, PUB_KEY2 ] >>,
"peer_roles": ["sender", ["sender", "receiver"]] }
Figure 13: Example 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 35, line 47 skipping to change at page 37, line 18
the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC,
formatted as specified in Section 4.1.6.2. formatted as specified in Section 4.1.6.2.
Note that policies can be set up, so that the Client sends a Key Re- Note that policies can be set up, so that the Client sends a Key Re-
Distribution request to the KDC only after a given number of received Distribution request to the KDC only after a given number of received
messages could not be decrypted (because of failed decryption messages could not be decrypted (because of failed decryption
processing or inability to retrieve the necessary keying material). processing or inability to retrieve the necessary keying material).
It is application dependent and pertaining to the particular message It is application dependent and pertaining to the particular message
exchange (e.g. [I-D.ietf-core-oscore-groupcomm]) to set up these exchange (e.g. [I-D.ietf-core-oscore-groupcomm]) to set up these
policies, to instruct clients to retain incoming messages and for how policies for instructing clients to retain incoming messages and for
long (OPT4). This allows clients to possibly decrypt such messages how long (OPT4). This allows clients to possibly decrypt such
after getting updated keying material, rather than just consider them messages after getting updated keying material, rather than just
non valid messages to discard right away. consider them 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 11 gives an overview of the exchange described above. Figure 14 gives an overview of the exchange described above, while
Figure 15 shows an example.
Client KDC Client KDC
| | | |
|------------------ Key Distribution Request: --------------->| |------------------ Key Distribution Request: --------------->|
| GET ace-group/GROUPNAME/nodes/NODENAME | | GET ace-group/GROUPNAME/nodes/NODENAME |
| | | |
|<-------- Key Distribution Response: 2.05 (Content) ---------| |<-------- Key Distribution Response: 2.05 (Content) ---------|
| | | |
Figure 11: Message Flow of Key Distribution Request-Response Figure 14: Message Flow of Key Distribution Request-Response
Request:
Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "nodes"
Uri-Path: "c101"
Payload: -
Response:
Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation,
with KEY and IND_KEY being CBOR byte strings,
and "ind-key" the profile-specified label
for individual keying material):
{ "gkty": 13, "key": KEY, "num": 12, "ind-key": IND_KEY }
Figure 15: Example 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 resource Observable [RFC7641],
Observable [RFC7641], and send notifications to Clients when the and send notifications to Clients when the keying material is
keying material is updated. 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,
using secure rekeying schemes such as [RFC2093][RFC2094][RFC2627]. using secure rekeying schemes such as [RFC2093][RFC2094][RFC2627].
* Can send unicast POST requests to each Client over a secure * Can send unicast POST requests to each Client over a secure
channel, with the same payload as the Key Distribution Response. channel, with the same payload as the Key Distribution Response.
When sending such requests, the KDC can target the URI path When sending such requests, the KDC can target the URI path
provided by the intended recipient upon joining the group, as provided by the intended recipient upon joining the group, as
specified in the 'control_path' parameter of the Joining Request specified in the 'control_path' parameter of the Joining Request
skipping to change at page 37, line 11 skipping to change at page 39, line 11
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.
4.5. Requesting a Change of Keying Material 4.5. Requesting a Change of 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 the keying material to be renewed, e.g. due to KDC its need for the keying material to be renewed, e.g. due to
exhaustion of AEAD nonces, if AEAD is used for protecting group exhaustion of AEAD nonces, if AEAD is used for protecting group
communnication. Depending on the application profile (OPT8), this communnication. Depending on the application profile (OPT8), this
can result in renewal of idividual keying material, group keying can result in renewal of individual keying material, group keying
material, or both. For example, if the Client uses an individual key material, or both.
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 For example, if the Client uses an individual key to protect outgoing
whole group keying material. 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 its node name, and formatted as
defined in Section 4.1.6.2. defined in Section 4.1.6.2.
Figure 12 gives an overview of the exchange described above. Figure 16 gives an overview of the exchange described above, while
Figure 17 shows an example.
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 12: Message Flow of Key Renewal Request-Response Figure 16: Message Flow of Key Renewal Request-Response
Request:
Header: PUT (Code=0.03)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "nodes"
Uri-Path: "c101"
Payload: -
Response:
Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation, with IND_KEY being
a CBOR byte string, and "ind-key" the profile-specified
label for individual keying material):
{ "ind-key": IND_KEY }
Figure 17: Example 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.
4.6. Retrieval of Public Keys and Roles for Group Members 4.6. 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.
Figure 13 and Figure 14 give an overview of the exchanges described Figure 18 and Figure 20 give an overview of the exchanges described
above. above, while Figure 19 and Figure 21 show an example for each
exchange.
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 13: Message Flow of Public Key Exchange to Request All Figure 18: Message Flow of Public Key Exchange to Request All
Members Public Keys Members Public Keys
Request:
Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "pub-key"
Payload: -
Response:
Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation):
{ "pub_keys": << [ PUB_KEY1, PUB_KEY2, PUB_KEY3 ] >>,
"peer_roles": ["sender", ["sender", "receiver"], "receiver"] }
Figure 19: Example of Public Key Exchange to Request All 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 14: Message Flow of Public Key Exchange to Request Figure 20: Message Flow of Public Key Exchange to Request
Specific Members Public Keys Specific Members Public Keys
Request:
Header: FETCH (Code=0.05)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "pub-key"
Content-Format: "application/ace-groupcomm+cbor"
Payload:
{ "get_pub_keys": [[], ["c3"]] }
Response:
Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation):
{ "pub_keys": << [ PUB_KEY3 ] >>,
"peer_roles": ["receiver"] }
Figure 21: Example of Public Key Exchange to Request Specific
Members Public Keys
4.7. 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 its node 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 15 gives an overview of the exchange described above. Figure Figure 22 gives an overview of the exchange described above,
while Figure 23 shows an example.
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 15: Message Flow of Public Key Update Request-Response Figure 22: Message Flow of Public Key Update Request-Response
Request:
Header: POST (Code=0.02)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "nodes"
Uri-Path: "c101"
Uri-Path: "pub-key"
Content-Format: "application/ace-groupcomm+cbor"
Payload (in CBOR diagnostic notation, with PUB_KEY
and SIG being CBOR byte strings):
{ "client_cred": PUB_KEY, "cnonce": h'9ff7684414affcc8',
"client_cred_verify": SIG }
Response:
Header: Changed (Code=2.04)
Payload: -
Figure 23: Example 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
skipping to change at page 39, line 26 skipping to change at page 44, line 4
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.8. 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 24 gives an overview of the exchange described above, while
Figure 16 gives an overview of the exchange described above. Figure 25 shows an example.
Client KDC Client KDC
| | | |
|-Policies Request: GET ace-group/GROUPNAME/policies ->| |-Policies Request: GET ace-group/GROUPNAME/policies ->|
| | | |
|<--------- Policies Response: 2.05 (Content) ---------| |<--------- Policies Response: 2.05 (Content) ---------|
| | | |
Figure 16: Message Flow of Policies Request-Response Figure 24: Message Flow of Policies Request-Response
Request:
Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "policies"
Payload: -
Response:
Header: Content (Code=2.05)
Content-Format: "application/ace-groupcomm+cbor"
Payload(in CBOR diagnostic notation):
{ "group_policies": {"exp-delta": 120} }
Figure 25: Example of Policies Request-Response
4.9. 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 17 gives an overview of the exchange described above. Figure 26 gives an overview of the exchange described above, while
Figure 27 shows an example.
Client KDC Client KDC
| | | |
|---- Version Request: GET ace-group/GROUPNAME/num ---->| |---- Version Request: GET ace-group/GROUPNAME/num ---->|
| | | |
|<--------- Version Response: 2.05 (Content) -----------| |<--------- Version Response: 2.05 (Content) -----------|
| | | |
Figure 17: Message Flow of Version Request-Response Figure 26: Message Flow of Version Request-Response
Request:
Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "num"
Payload: -
Response:
Header: Content (Code=2.05)
Content-Format: text/plain
Payload(in CBOR diagnostic notation):
13
Figure 27: Example of Version Request-Response
4.10. 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 its node 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.4). 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 request to re-
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.10. Section 4.10.
skipping to change at page 41, line 30 skipping to change at page 47, line 5
Joining Request. Joining Request.
6. ACE Groupcomm Parameters 6. ACE Groupcomm Parameters
This specification defines a number of fields used during the second This specification defines a number of fields used during the second
part of the message exchange, after the ACE Token POST exchange. The part of the message exchange, after the ACE Token POST exchange. The
table below summarizes them, and specifies the CBOR key to use table below summarizes them, and specifies the CBOR key to use
instead of the full descriptive name. Note that the media type ace- instead of the full descriptive name. Note that the media type ace-
groupcomm+cbor MUST be used when these fields are transported. groupcomm+cbor MUST be used when these fields are transported.
+=======================+======+===============+==================+ +=======================+======+================+==================+
| Name | CBOR | CBOR Type | Reference | | Name | CBOR | CBOR Type | Reference |
| | Key | | | | | Key | | |
+=======================+======+===============+==================+ +=======================+======+================+==================+
| scope | TBD | byte string | Section 4.1.2.1 | | scope | TBD | byte string | Section 4.1.2.1 |
+-----------------------+------+---------------+------------------+ +-----------------------+------+----------------+------------------+
| get_pub_keys | TBD | array | Section 4.1.2.1, | | get_pub_keys | TBD | array / simple | Section 4.1.2.1, |
| | | | Section 4.1.3.1 | | | | value null | Section 4.1.3.1 |
+-----------------------+------+---------------+------------------+ +-----------------------+------+----------------+------------------+
| client_cred | TBD | byte string | Section 4.1.2.1 | | client_cred | TBD | byte string | Section 4.1.2.1 |
+-----------------------+------+---------------+------------------+ +-----------------------+------+----------------+------------------+
| cnonce | TBD | byte string | Section 4.1.2.1 | | cnonce | TBD | byte string | Section 4.1.2.1 |
+-----------------------+------+---------------+------------------+ +-----------------------+------+----------------+------------------+
| client_cred_verify | TBD | byte string | Section 4.1.2.1 | | client_cred_verify | TBD | byte string | Section 4.1.2.1 |
+-----------------------+------+---------------+------------------+ +-----------------------+------+----------------+------------------+
| pub_keys_repos | TBD | text string | Section 4.1.2.1 | | pub_keys_repos | TBD | text string | Section 4.1.2.1 |
+-----------------------+------+---------------+------------------+ +-----------------------+------+----------------+------------------+
| control_path | TBD | text string | Section 4.1.2.1 | | control_path | TBD | text string | Section 4.1.2.1 |
+-----------------------+------+---------------+------------------+ +-----------------------+------+----------------+------------------+
| gkty | TBD | integer / | Section 4.1.2.1 | | gkty | TBD | integer / text | Section 4.1.2.1 |
| | | text string | | | | | string | |
+-----------------------+------+---------------+------------------+ +-----------------------+------+----------------+------------------+
| key | TBD | see "ACE | Section 4.1.2.1 | | key | TBD | see "ACE | Section 4.1.2.1 |
| | | Groupcomm | | | | | Groupcomm Key" | |
| | | Key" Registry | | | | | Registry | |
+-----------------------+------+---------------+------------------+ +-----------------------+------+----------------+------------------+
| num | TBD | integer | Section 4.1.2.1 | | num | TBD | int | Section 4.1.2.1 |
+-----------------------+------+---------------+------------------+ +-----------------------+------+----------------+------------------+
| ace-groupcomm-profile | TBD | int | Section 4.1.2.1 | | ace-groupcomm-profile | TBD | int | Section 4.1.2.1 |
+-----------------------+------+---------------+------------------+ +-----------------------+------+----------------+------------------+
| exp | TBD | int | Section 4.1.2.1 | | exp | TBD | int | Section 4.1.2.1 |
+-----------------------+------+---------------+------------------+ +-----------------------+------+----------------+------------------+
| 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 | | gid | TBD | array | Section 4.1.1.1 |
+-----------------------+------+---------------+------------------+ +-----------------------+------+----------------+------------------+
| gname | TBD | array of text | Section 4.1.1.1 | | gname | TBD | array of text | Section 4.1.1.1 |
| | | string | | | | | strings | |
+-----------------------+------+---------------+------------------+ +-----------------------+------+----------------+------------------+
| guri | TBD | array of text | Section 4.1.1.1 | | guri | TBD | array of text | Section 4.1.1.1 |
| | | string | | | | | strings | |
+-----------------------+------+---------------+------------------+ +-----------------------+------+----------------+------------------+
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
safe side. Besides, if the KDC has renewed the group keying safe side.
material, and the time interval between the end of the rekeying
process and the joining of the Client is sufficiently small, that Besides, if the KDC has renewed the group keying material, and the
Client is also on the safe side, since replayed older messages time interval between the end of the rekeying process and the joining
protected with the previous keying material will not be accepted. of the Client is sufficiently small, that Client is also on the safe
side, since replayed older messages protected with the previous
keying material will not be accepted.
The KDC must renew the group keying material upon its expiration. The KDC must renew the group keying material upon its expiration.
The KDC should renew the keying material upon group membership The KDC should renew the keying material upon group membership
change, and should provide it to the current group members through change, and should provide it to the current group members through
the rekeying scheme used in the group. the rekeying scheme used in the group.
The KDC should renew the group keying material after rebooting, even The KDC should renew the group keying material after rebooting, even
in the case where all keying material is stored in persistent in the case where all keying material is stored in persistent
storage. However, if the KDC relies on Observe responses to notify storage. However, if the KDC relies on Observe responses to notify
skipping to change at page 45, line 32 skipping to change at page 51, line 4
Optional parameters: none Optional parameters: none
Encoding considerations: Must be encoded as CBOR map containing the Encoding considerations: Must be encoded as CBOR map containing the
protocol parameters defined in [this document]. protocol parameters defined in [this document].
Security considerations: See Section 7 of this document. Security considerations: See Section 7 of this document.
Interoperability considerations: n/a Interoperability considerations: n/a
Published specification: [this document] Published specification: [this document]
Applications that use this media type: The type is used by Applications that use this media type: The type is used by
authorization servers, clients and resource servers that support the authorization servers, clients and resource servers that support the
ACE groupcomm framework as specified in [this document]. ACE groupcomm framework as specified in [this document].
Additional information: Additional information: n/a
Magic number(s): n/a
File extension(s): .ace-groupcomm
Macintosh file type code(s): n/a
Person & email address to contact for further information: Person & email address to contact for further information:
iesg@ietf.org (mailto:iesg@ietf.org) iesg@ietf.org (mailto:iesg@ietf.org)
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: None Restrictions on usage: None
Author: Francesca Palombini francesca.palombini@ericsson.com Author: Francesca Palombini francesca.palombini@ericsson.com
(mailto:francesca.palombini@ericsson.com) (mailto:francesca.palombini@ericsson.com)
Change controller: IESG Change controller: IESG
8.2. CoAP Content-Formats Registry 8.2. CoAP Content-Formats Registry
This specification registers the following entry to the "CoAP This specification registers the following entry to the "CoAP
Content-Formats" registry, within the "CoRE Parameters" registry: Content-Formats" registry, within the "CoRE Parameters" registry:
skipping to change at page 48, line 16 skipping to change at page 53, line 33
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 7. This Registry has been initially populated by the values in Figure 8.
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 49, line 39 skipping to change at page 55, line 5
* 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 8. This registry will be initially populated by the values in Figure 9.
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 51, line 32 skipping to change at page 56, line 46
[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, June 24, 2020, draft-ietf-ace-oauth-authz-35, 24 June 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-cbor-7049bis]
Seitz, L., "Additional OAuth Parameters for Authorization Bormann, C. and P. Hoffman, "Concise Binary Object
in Constrained Environments (ACE)", Work in Progress, Representation (CBOR)", Work in Progress, Internet-Draft,
Internet-Draft, draft-ietf-ace-oauth-params-13, April 28, draft-ietf-cbor-7049bis-16, 30 September 2020,
2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace- <http://www.ietf.org/internet-drafts/draft-ietf-cbor-
oauth-params-13.txt>. 7049bis-16.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, June 23, 2020, <http://www.ietf.org/ groupcomm-09, 23 June 2020, <http://www.ietf.org/internet-
internet-drafts/draft-ietf-core-oscore-groupcomm-09.txt>. 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, July 1, 2020, draft-ietf-cose-rfc8152bis-algs-12, 24 September 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-12.txt>.
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", Work in Progress, Internet-Draft, Structures and Process", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-struct-12, August 24, 2020, draft-ietf-cose-rfc8152bis-struct-14, 24 September 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-cose- <http://www.ietf.org/internet-drafts/draft-ietf-cose-
rfc8152bis-struct-12.txt>. rfc8152bis-struct-14.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>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
skipping to change at page 53, line 12 skipping to change at page 58, line 16
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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.ietf-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-ietf-
core-ace-aif-09, June 27, 2020, <http://www.ietf.org/ ace-aif-00, 29 July 2020, <http://www.ietf.org/internet-
internet-drafts/draft-bormann-core-ace-aif-09.txt>. drafts/draft-ietf-ace-aif-00.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, July 6, Internet-Draft, draft-ietf-ace-dtls-authorize-14, 29
2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace- October 2020, <http://www.ietf.org/internet-drafts/draft-
dtls-authorize-12.txt>. ietf-ace-dtls-authorize-14.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. and A. Kirby, "Message Queuing Telemetry
of ACE", Work in Progress, Internet-Draft, draft-ietf-ace- Transport (MQTT)-TLS profile of Authentication and
mqtt-tls-profile-06, July 13, 2020, <http://www.ietf.org/ Authorization for Constrained Environments (ACE)
internet-drafts/draft-ietf-ace-mqtt-tls-profile-06.txt>. Framework", Work in Progress, Internet-Draft, draft-ietf-
ace-mqtt-tls-profile-08, 1 November 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-ace-mqtt-
tls-profile-08.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, June 18, Internet-Draft, draft-ietf-ace-oscore-profile-13, 27
2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace- October 2020, <http://www.ietf.org/internet-drafts/draft-
oscore-profile-11.txt>. ietf-ace-oscore-profile-13.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, September 30, 2019, core-coap-pubsub-09, 30 September 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-
01, July 13, 2020, <http://www.ietf.org/internet-drafts/ 01, 13 July 2020, <http://www.ietf.org/internet-drafts/
draft-ietf-core-groupcomm-bis-01.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,
skipping to change at page 55, line 45 skipping to change at page 60, line 49
* 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 * REQ7a: Register a Resource Type for the root url-path, which is
used to discover the correct url to access at the KDC (see used to discover the correct url to access at the KDC (see
Section 4.1). Section 4.1).
* REQ7aa: Define what operations (i.e. CoAP methods) are allowed on
each resource, for each role defined in REQ2 (see Section 3.3).
* REQ7b: Specify the exact encoding of group identifier (see * REQ7b: Specify the exact encoding of group identifier (see
Section 4.1.1.1). 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
skipping to change at page 57, line 5 skipping to change at page 62, line 22
accordingly, especially with respect to the usage of accordingly, especially with respect to the usage of
'mgt_key_material' related format and content. 'mgt_key_material' related format and content.
* REQ19: Define the initial value of the 'num' parameter (sse * REQ19: Define the initial value of the 'num' parameter (sse
Section 4.1.2.1). Section 4.1.2.1).
* OPT1: Optionally, specify the encoding of public keys, of * OPT1: Optionally, specify the encoding of public keys, of
'client_cred', and of 'pub_keys' if COSE_Keys are not used (see 'client_cred', and of 'pub_keys' if COSE_Keys are not used (see
Section 4.1.2.1). Section 4.1.2.1).
* OPT2: Optionally, specify the negotiation of parameter values for * OPT2a: 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).
* OPT2b: Optionally, specify the additional parameters used in the
Token Post exchange (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.4). 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
skipping to change at page 60, line 40 skipping to change at page 66, line 11
* New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm * New IANA registries "ACE Groupcomm Key Registry", "ACE Groupcomm
Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence Profile Registry", "ACE Groupcomm Policy Registry" and "Sequence
Number Synchronization Method Registry" (Section 11). Number Synchronization Method Registry" (Section 11).
* Added appendix about requirements for application profiles of ACE * Added appendix about requirements for application profiles of ACE
on group communication (Appendix A). on group communication (Appendix A).
Acknowledgments Acknowledgments
The following individuals were helpful in shaping this document: The following individuals were helpful in shaping this document:
Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John Mattsson, Daniel Christian Amsuess, Carsten Bormann, Rikard Hoeglund, Ben Kaduk, John
Migault, Jim Schaad, Ludwig Seitz, Goeran Selander and Peter van der Mattsson, Daniel Migault, Jim Schaad, Ludwig Seitz, Goeran Selander
Stok. and Peter van der Stok.
The work on this document has been partly supported by VINNOVA and The work on this document has been partly supported by VINNOVA and
the Celtic-Next project CRITISEC; and by the EIT-Digital High Impact the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home
(Grant agreement 952652); and by the EIT-Digital High Impact
Initiative ACTIVE. Initiative ACTIVE.
Authors' Addresses Authors' Addresses
Francesca Palombini Francesca Palombini
Ericsson AB Ericsson AB
Torshamnsgatan 23 Torshamnsgatan 23
SE-16440 Stockholm Kista SE-16440 Stockholm Kista
Sweden Sweden
Email: francesca.palombini@ericsson.com Email: francesca.palombini@ericsson.com
Marco Tiloca Marco Tiloca
RISE AB RISE AB
 End of changes. 163 change blocks. 
494 lines changed or deleted 738 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/